オフショア開発失敗事例７　独自開発フレームワークの開発者が退職

突然、あるWebシステムを支援するよう上司より指示されました。
別の事業部で開発中のシステムの総合テストで不良が多発して手が足りないとのことです。
「不良修正なら若手を行かせましょうか」と上司にいうと「技術的に厄介らしいから、お前が直接見てこい」と言われました。そんなことは普段言われることはありません。相当大きなトラブルに違いありません。

会議室に行くとJavaのエキスパートが集められていました

支援者が集められている会議室に行って驚きました。グループの中からJavaの得意な人が集められていました。
しかも管理職の人までみんなソースコードを追っています。
これはますます尋常ではありません。これまでどんなに大きなトラブル・プロジェクトでもこんな顔ぶれが集まっているのはみたことがありません。

顔見知りになぜこんなことになっているか聞いてみます。
私　「すごいメンバーですね。何が起きているんですか？」
相手「プログラムが難しいんだよ。」
私　「まさか！このメンバーで難しいなんてありえないでしょ。」
相手「そういうなら自分の目で見てみろよ。」

独自開発のフレームワークがくせものだった

早速プログラムを見てみました。
確かに難しい。パッと見ただけでは何をやっているのか分かりません。
なぜ難しいかというと、プロジェクトで独自に開発したフレームワークが、処理を中途半端に隠しているからです。
そのフレームワークの流儀に従って、クラス分けされているらしいのですが、その流儀が分からないので、ある処理がどこのクラスに実装されているのか見当もつきません。
Strutsと同じように画面遷移を管理するフレームワークのようですが、作り方が非常に独特で、他のフレームワークとはまったく違うもののようです。

混乱の始まりは開発者の退職だった

まずはフレームワークの説明書を入手するのが先だと思い、担当者に聞きました。
すると一言「ありません」と返ってきました。
私　　「簡単な説明書もないの？」
担当者「ありません。」
私　　「誰か、説明できる人はいないの？」
担当者「いないんですよ。」
私　　「そんなことはないでしょ。このフレームワークを作った人は？」
担当者「会社を辞めてしまったんですよ。」

この混乱の原因は、フレームワーク開発者の退職でした。

そもそもこのプロジェクトは中国のある会社にオフショア開発を委託していました。
その会社の優秀な技術者がこのフレームワークを作ったそうです。

製造中は、この技術者の指示に従って実装し、分からないことがあるとこの技術者に聞いていたそうです。
不良は、この技術者が自分で直すことが多かったらしいです。

ところがこの技術者が突然辞めてしまうと、残った人たちは自分たちがフレームワークのことを何も知らないことに気づきました。
結局、自分たちではどうすることもできず、発注元に泣きついたということでした。

フレームワークの情報はないと分かったので、他の支援者と分担して、フレームワークのドキュメント化から始めました。仕様がわかった後も、フレームワークの不自然な作りのせいで、なかなかプログラムの解析は進まず、解決までに時間が掛かってしまいました。

この事例から得た教訓

オフショア開発では、プロジェクトの途中で開発者が退職するというのは珍しくありません。
そのような事態に備えて、普段からドキュメント化をしっかりやってもらうことと、キーマンは一人だけに絞らず、常に二人以上おいてもらい、打ち合わせにも必ず一緒に出てもらう等の対策をとりましょう。

私自身が強く感じたのは、フレームワークや重要な共通クラスの設計を他人任せにしてはいけないということでした。もし、開発者が退職しなかったとしても、保守作業で大きな支障が出たことは間違いありません。

ただ、このプロジェクトの担当部署は、業務設計には強いのですが技術に強いＳＥがおらず、止むを得ずまる投げする格好になったようです。
そのような場合でもフレームワークの設計だけでも他部署の支援を受けるか、それも無理ならば、独自フレームワークなど作らず、有名なオープンソースを活用すべきだと思います。