過剰接待をしなくてもオフショア開発で生き残る方法：現地からお届け！中国オフショア最新事情（12）（2/4 ページ）

[幸地司，アイコーチ株式会社]

独自の標準開発プロセス「TPMS」とは

――貴社と取引を始めるに当たり、お客さまはどんな点に留意すればよいのでしょうか

高氏　初回発注時は、必ずお客さまに当社に来社していただきます。そして、両社のマネージャレベルが一緒に設計方針を策定します。同時に、品質保証や進ちょく管理の手順を詳細に決めます。当社は、独自の標準開発プロセス（Touchdown Project Management System：TPMS）を持っていますので、お客さまが指定される報告・連絡ルート、途中段階の設計が終わったら、誰が何をどのような手順でやるか、構成管理の手順などとTPMSをすり合わせて、最適な枠組みを一緒に決めます。

　TPMSは、よくある開発標準規約やプロジェクトマネジメント知識体系と以下の点で異なります。最も異なる点は精度が細かい点です。TPMSは、実際のオフショア開発プロジェクトで適応されながら、当社の社風や実態に合わせて最適化されつつあります。

　例えば、構成管理は、どういう手順でどのタイミングでチェックイン／チェックアウトするかなどの当たり前の動作が、数十ステップにわたり詳細に定義されています。通常は、お客さまごとに異なる構成管理のルールが存在します。賢い人なら、すぐに構成管理を覚えられると思われるかもしれませんが、初めて取引するお客さまの基準を知らないと間違いなく現場は混乱します。

　われわれのような知名度のない小規模ベンダは、初回取引で失敗すると次の機会がありません。ですから、構成管理の手順を細かく定め、各メンバーの役割と権限を厳密に定義します。もちろん、お客さまの意思を確認した上でTPMSを運用します。

――お客さまがひと言「構成管理をちゃんとやってください」と指示すればいいような気がします。なぜ、お客さまに手間を掛けさせてまで、詳細なTPMSを策定するのでしょうか

高氏　私が直接プロジェクトを担当する場合は、ひと言「構成管理をやりましょう」と指示すれば終わります。ですが、私は社長ですからすべてのプロジェクトに介入できません。当社のチームリーダーは20歳代後半が中心です。実務経験は5年くらいです。日本語の読み書きには不自由しませんが、顔を見ないで話す電話会議は難しいレベルです。プログラマは、23歳か24歳くらいです。実務経験は2年ほどにすぎません。

　このような若手主体のチームメンバーに「構成管理をちゃんとしましょう」といっても、残念ながらお客さまの真意は伝わりません。つまり、過去にきちんとしたプロジェクト管理を経験していなければ、とても日本企業の要求には応えられません。

　リーダー1人とプログラマ2人の小さなチームなら、TPMSがなくても大きな問題は生じないでしょう。ですが、チームが大所帯になると混乱が起きます。しかも、お客さまの担当窓口が変わってしまうと、そのたびに説明し直さなくてはいけないとしたら、それこそ大変です。

　日本企業も、中国と同様に構成管理が徹底されていないと思います。中国人でも日本人でも、頭では理解しているものの、実際には「面倒だからいいや」という感じでやってしまうこともあるでしょう。

　今後、組織が大きくなると頻繁に人が入れ替わるようになるでしょう。この状況は避けられないと思います。しかし、絶対に崩れない仕組みを作っておけば安心だという発想です。組織が小さいうちにしっかりとした基盤、仕組みを作っておきたいのです。

　若手プログラマにとって、構成管理は面倒な存在です。でも、慣れれば楽になるし、操作も簡単です。受注から納品まで、そして納品後もいつ修正されたかなど、すべて状況が記録されるので、状況を正確に把握できます。

――構成管理のほかにもTPMSはどのように役立ちますか

高氏　実は当社独自のTPMSといっていますが、マネジメント上の新しい概念はありません。繰り返しになりますが、TPMSの特長は当社の実態に最適化されていることです。例えば、「CMMI（capability maturity model）」に取り組んだとしても、概念が抽象的過ぎるといまの中国では運用されません。でもTPMSなら、確実に運用できます。

　例えば、Q＆A票を使って日本に質問するのは当たり前ですが、どのように質問すればいいか、などの詳細な手順を22ステップのフロー図で定義しています。この22ステップ数が多いか少ないかは別として、中国では定義する必要があるのです。

　例えば、5人チームでお客さまから基本設計書をもらったとき、5人が同じQ＆A票を起票することがあります。もしも、5件のQ＆A票がすべてお客さまに届いてしまうと、お客さまは「この会社はどういう会社なんだ、まったく管理できていない！」と憤慨なさるでしょう。

　このような初歩的なトラブルを防ぐために、22ステップものQ＆A手順が必要になります。当社では、すべてのQ＆Aをプロジェクトリーダーがチェックします。社内で解決できるものは、お客さまには絶対に流れないように仕組み化しています。単純ですが、絶対にミスを起こさないような仕組みになっています。

　なぜ、TPMSでそこまでやるかというと、人材流動性が激しい中国では手順をきちんと定義しないと、後から入社した者が必ず問題を起こすからです。当社では、過去に何度も同様のミスを発生させていました。ですから、TPMSを策定し運用を徹底しているのです。

　ほかにもTPMSには特徴的な取り決めがあります。TPMSには、「すべてのタスクを2日以下にする」という厳格な基準があります。当社のWBSでは、最下位のアクティビティはすべて2日以内の作業量に収めます。これを実現するには、高等なテクニックを要します。例えば、画面モジュールを作るのに、ベテランのリーダーでもこの作業に5日ほど費やしてしまうような作業があるとします。それを当社では3つのタスクに分割する独自のノウハウで実施することで、これを2日以下にするのです。

　「すべてのタスクを2日以下にする」ことが実現できれば、万が一のことがあってもリカバリーは単純です。そして、進ちょく報告では0％か100％だけが許されます。たとえ10年選手でも、進ちょく報告に主観が混じると間違いを起こします。ですので、当社では100％完成しない限り、進ちょく率は0％と見なされます。

　今年は河南省開発センターでもTPMSを適用させます。当面は、上海本社からリーダーを派遣して、プロジェクト単位でOJTによる指導を図ります。

見切り発車への対応策は？

――どのような開発スタイルを採られていますか

高氏　一括請負開発が多いので、基本的にはウォーターフォール型です。ですが、日本のお客さまは仕様変更が多いので、アジャイルのような繰り返し型を併用します。当社が自信を持っている金融系プロジェクトでは、仕様変更に時間がかかるものや仕様自体に問題の多い場合は、中国で作れるものから先に作ることができます。

――中国側の判断で勝手に見切り発車すると、ものすごくリスクが高いと思われますが、いかがでしょうか

高氏　当社の場合、リソースやコストの心配はありませんが、スコープのリスクが顕在化すると影響は大きいです。そのために、TPMSで仕様変更を管理しています。

　従来は、電話やメールで簡単に仕様変更の依頼を受け付けていました。当然ながら、誰も管理できなくなり、納品後に「言った、言わない」のトラブルが発生しました。いまでは「全角文字から半角文字への修正」といった小さな対応まで、すべての仕様変更において仕様変更依頼書を作成して管理するよう心掛けています。このような仕様変更依頼書が必要な理由は、先ほど申し上げた通りです。

　また、当社の仕様変更依頼書はExcelで運用しています。仕様変更があれば、お客さまから仕様変更依頼書をメールでいただきます。ですが、一部では仕様変更を記録しないプロジェクトもあって、やはりそこだけトラブルに陥ってしまうことがあるのです。

――変更管理の徹底は素晴らしい概念ですが、ラボ契約のメリットを殺すような気がします。いかがでしょうか？

高氏　ラボでも、仕様変更管理を実行します。はたからは、面倒に見えるかもしれませんが、当事者にとっては苦になりません。人数が増えれば増えるほど、変更管理の徹底が威力を発揮します。

　当社のラボでは、仕様変更を随時受け付けています。当社が受注する範囲は基本設計から結合試験までです。成功したプロジェクトでの仕様変更の割合は約30％です。見積もりと実績がずれる最大の原因は「仕様変更」です。次に、お客さまの都合で最初から予算枠が決まっていることがあります。取引実績を増やすためにやむを得ず、少ない工数で見積もりを出します。

　そのほかの要因には、コンポーネントがうまく動かないなど、外部要因による工数超過が見受けられます。最近はPHPなどの新しいフレームワークを使うことが多いので、経験不足によって担当するフレームワークのバグを理解できていない、などがあります。

　また、小規模プロジェクトの見積もりは、現場のリーダーに任せっ切りになるため、どうしても仕様確認の詰めが甘くなりがちでした。粗過ぎる仕様を、お客さまに質問しないまま判断して見積もりを提出してしまうと、後になってトラブルになってしまいます。この場合、工数超過分はすべてオフショア側が負担すべきだと考えています。それでも、30％までの工数増なら許容範囲となるように生産性を高める努力を続けています。

――オフショア開発として受託する平均的な仕事の大きさは、どのくらいですか？

高氏　平均的には20人月の案件が多いです。過去最大は200人月です。組み込み系開発では、1人月からでも仕事を請けます。初めての取引では、無償評価してもらう制度があります。業務系アプリケーション開発では無償評価制度なんて不要ですが、拡大余地のある組み込み系案件では挑戦する価値があると思っています。