モデル利用で「腹割り」型委託を実現

モデリングにより上流工程からの委託が可能に

　すでにオフショア開発を経験された方は、「比較的簡単な下流工程でさえうまくいかないのに、より難易度が高い上流工程を任せて本当に大丈夫だろうか？」と疑問をお持ちでしょう。コストダウンが実現できても、品質や納期が及第点でなければプロジェクトとしては失敗です。

　ここでモデリングの出番です。モデルを利用することで、業務内容・システムの大枠を視覚的にとらえることができます。例えば、分析モデルを用いて対象システムの背景を説明・理解することにより、システム化する際の条件や制約が明確になります。

　また、オフショア側の作成したモデルをレビューすることで、実装前に大きな問題点がないかどうかを確認することができます。

　以前にインドへ開発委託した際に、機能要件は満たしていたのですが、5分以上応答が戻ってこないクライアントサーバシステムが納品されたことがあります。オフショア開発では「常識」が常識として通用しないため、非機能要件を明確にするのは常道ですが、正しく伝えるのは機能要件以上に難しくモデルをレビューする方が近道です。

　Elapizプロジェクトでも中国側で作成した設計モデルをレビューして、不用意にクラスが追加されているのを発見し、パフォーマンスやスケーラビリティへの影響を再考するように求めたことが一度ならずあります。

　オフショア開発ではプロジェクトの状況把握に苦労することが多いですが、モデルの作成状況をウォッチすることで、進捗状況の把握の助けにもなります。

　確かに私自身も上流工程を任せられるのかという不安もありましたが、中国のエンジニアは技術に貪欲で勉強熱心です。最初は、いろいろと教えてあげる必要はありますが、信頼して任せることができれば見返りは大きいと思います。

オフショア開発でのモデリング利用の工夫

　モデリング技術を利用することで上流工程から安心して委託することができると述べましたが、オフショア開発では物理的に開発拠点が離れているが故に誤解を生まないための工夫、効率よく伝えるための工夫も必要です。

　オフショア開発のノウハウ集などには「仕様書のカタカナ用語の乱用は避けましょう」とありますが、これはモデルを利用する場合でも当てはまります。例えば、クラス名を「トレーサビリティ」とするのと「Traceability」もしくは「追跡可能性」とするのでは理解してもらえる確率が大きく異なります。

　またイテレーション（繰り返し）型開発プロセスではモデルが徐々に成長していく訳ですが、モデリング作業やレビュー範囲を明確にするためにイテレーションごとの差分を色の違いで表すのも1つの工夫です（図3）。

　中国の開発委託先に作業進捗の確認をしたところ、仕様の背景を理解してもらうために記載しておいた周辺部分の参考モデルも作業範囲と誤認して作業に着手していたことがあり、上記のような工夫を取り入れました。

　今回は私が経験して有用だったノウハウの一部をご紹介しましたが、次回は会社やプロジェクトを超えて経験やノウハウを取りまとめた「オフショア開発向けUML適用ガイドライン」についてお話しすることにします。