プロジェクトマネジャーに贈るプロセス改善事例　第6回言語や文化の違いだけではない「オフショア開発が成功しない」理由

問題の原因分析で浮かび上がってきたもの

　まず、WGメンバーは今までの失敗経験に基づき、オフショア開発で起こりがちな問題点を挙げた。契約に関する法的な問題も含まれていたが、優先して検討すべきと判断された「開発業務で起こりがちな問題」が多く挙がった。 以下にその一部を紹介する。

双方の認識のずれによる作業漏れが発生した

　中国企業との共同作業であるオフショア開発では、中国側の要員と日本側の要員との間に認識のずれが起こりがちである。

仕様の理解不足や誤解により成果物の品質が悪くなった

　中国ベンダーでは日本語教育にも注力しており、日本語に堪能な要員が増えているが、やはり双方には言語的・文化的なギャップがある。仕様のあいまいな説明や日本語の難しい表現で書かれたドキュメントでは、十分な理解を得ることは難しい。

開発の状況が不透明で対応が遅れた

　中国はオフショア開発の候補地の中では、比較的日本との距離が近い。しかし、オンサイト（社内など1カ所）での開発に比べると、プロジェクトマネジャーが現場の状況を把握することは難しい。

国家関係や輸送、移動のトラブルにより成果物が確保できなかった

　国外での共同作業を行うため、国家的な政情不安や国家関係の悪化によってプロジェクトの継続が不可能となり、成果物のやりとりができなくなる事態が起こり得る。また、輸送や移動手段がプロジェクトへ与える影響も考慮する必要がある。特に、要員の移動が不可能になると、プロジェクトの継続も難しくなってしまう。

　推進チームは、WGメンバーから随時フィードバックを受けながら、これらの問題の原因を分析した。その結果、問題の原因が「開発・管理の標準的なプロセスの定義があいまいである」点に集約されることを突き止めた。

オフショア開発上の問題とその原因の追跡

プロセス整備と意識改革の必要性

　オフショア開発では開発プロセスの定義があいまいになると、双方が互いに想定している作業が明示的に確認できず、認識の食い違いが発生して作業に漏れができてしまう。

　その場合の対応策として、各工程の作業内容を明文化し、双方で作業内容を確認することでその認識を統一することが挙げられる。また、作業の進ちょくや品質管理の状況報告、その確認方法、コミュニケーションの窓口、成果物の納品方法などを管理プロセスに明確に定義し、統一したルールで実行すれば、各種調整やトラブルへの対応も迅速に行うことが可能になる。

　しかし、こうしたプロセス定義のあいまいさは、オフショア開発だけに限ったものではない。今まで標準的なプロセスが定義されていなくてもこのような問題が発生しなかったのは、従来のX社の開発形態が「オンサイトにおける作業委託」であることに由来するとも考えられる。

　この形態では、委託側と受託側でコミュニケーションを密に取ることができ、効率的で融通が利く。しかし、委託側であるX社による作業状況の把握や品質管理が「なれ合い状態」になっている可能性も十分に考えられる。

　一方、オフショア開発は「オフサイトにおける一括発注」の形態で行われるのが一般的である。遠隔地で納品成果物を一括して開発するため、厳密な開発作業の定義や管理作業の定義に基づいてプロジェクトを遂行しなければ、異文化・異言語間によるコミュニケーションの困難さも相まって、さまざまな問題が生じる。

従来のX社の開発とオフショア開発の違い

　推進チームとWGでは「関係者間の作業認識を統一する」という観点からも、「標準的なプロセスの設定は、オフショア開発プロジェクトを遂行するための土台となる」と認識していた。

　そこでN氏は、オフショアでの開発プロジェクトを遂行する上で「共通認識の確認や活動の土台となる『開発・管理プロセスの再整理』と、その展開を全社レベルで行うことが必要だ」と経営陣に報告し、標準推進部署への協力を要請した。

　さらに、決められたプロセスに準拠してプロジェクトを計画し、その管理や運営を行うように「従来の開発慣行の見直し」を提案した。その際、N氏は「開発要員の意識を変えていくことが重要な課題である」と経営陣に説明した。

オフショア開発用の標準プロセスの整備

　次にN氏は、オフショア開発の導入を促進するための優先施策として、オフショア開発のプロセス整備と、社内の意識変革を目的とした活動に取り組むことを決めた。

　オフショア開発向けプロセスの整備活動は、推進チームを中心にWGと標準推進部署とで協力して行われた。WGメンバーは、過去のプロジェクトでの成功経験に基づくベストプラクティスを提供した。また、標準推進部署は定義済みの開発標準の文書や各種資料を提供し、その内容の情報共有を支援した。

　推進チームは既存の標準定義をベースにして、ベストプラクティスや検討結果を盛り込みながら、プロセス定義資料をまとめた。その内容については随時、WGや標準推進部署のレビューを受けた。

　以下に、X社が整備した「オフショア開発向け標準プロセス」の内容を一部挙げる。

開発プロセス

• ウォータフォール型の工程定義をベースに、委託する工程とその関連作業の内容を詳細に定義する
• 発注側がガバナンスを取るためにデータ設計工程のマイルストーンを設定する
• 工程別の実施タスクをリストで定義し、プロジェクトにおける双方の役割分担を明確にする
• 納品文書に対する確認・修正タスクを明示する
• 仕様や設計文書に関する記述方法、省略不可項目などのルールを盛り込んだ補足文書を定義する

管理プロセス

• オフショア開発用の計画文書作成に関する作業内容や時期を定義した「ひな型」を提供する。これにより、以下の事項の順守を徹底できる

• 計画文書の内容に関する合意時期や手続きを定義する
• 祝日やカレンダーの違いを考慮した進ちょく管理の内容を定義する
• 品質確認や教育などを実施したかどうかを確認するタスクを定義し、そのチェックリストを策定する

求められる「発注者」としての意識とスキル

　推進チームはプロセスの整備作業と並行し、プロセスの周知とその理解の促進、X社内部のオフショア開発に対する意識付けなどを目的とした説明会やセミナーを開催した。そこではWGが中心となり、再定義されたプロセスの概要や特徴、中国オフショア開発の全体の手順や実情、X社の担当者に求められる姿勢などを説明した。

　こうした活動を開発部署ごとに進める中で、N氏は「プロセス定義の内容を理解できない」「どのように利用してよいか分からない」という開発要員が多く存在することに問題があると考えた。

　そこでN氏は、オフショア開発の推進に必要なプロセスを理解して実際に利用するためには、X社の開発要員にもある程度のエンジニアリングやマネジメントの知識が必要であることを経営陣に説明した。また、先に課題として挙げられた「従来の開発慣行からの脱却」と併せて、X社の開発要員に求められる「発注者」としてのスキルを身に付けるべきだと強調した。

オフショア開発成功のための「発注者」としての条件

　N氏の提案を受けて、X社では、既に決定していたオフショア開発の試行プロジェクト要員に対して、他社が提供する教育プログラムを実施することにした。また、その成果を収集した上で、X社の人材教育コースやCDP（キャリアデベロップメントプログラム）に、オフショア開発に関する項目を盛り込むことが検討された。

　また、推進チームと人材資源部署が連携して、経営陣の指示と調整の下で将来的な教育プログラムの整備が進められることになった。

　その後、X社では推進チームの支援の下、複数のオフショア開発プロジェクトが遂行された。全社展開にはまだ至っていないが、いずれのプロジェクトでもWGが挙げていた問題の発生や大きなトラブルには見舞われていない。

オフショア開発が成功しない本当の理由とは？

　X社では、オフショア開発の全社導入に挑戦したことでプロセス改善活動に着手し、「従来の開発慣行の見直し」「開発に臨む意識の変革」「企業レベルでの開発生産性の向上」に取り組んだ。

　オフショア開発の特徴として「一括発注で委託する形式を取る」「オフサイト（多拠点分散型）開発である」「異文化・異言語間でのやりとりがある」という3点が挙げられる。しかし、最初の2点は、国内ベンダーへの一括発注でも大きくは変わらないものだ。

　つまり、プロジェクトを遂行する上でトラブルが頻発した場合は、コミュニケーションに起因する問題だけでなく、開発に関するスキルや姿勢などにそもそも問題がある可能性が高いと考えられる。

　またX社では、オフショア開発に関する標準的なプロセスの整備や教育などを全社展開することと並行して、十分なスキルを持った社内の開発要員の育成を進めている。これはオフショア開発にとどまらず、国内ベンダーへの発注時にもプロジェクトの成功率を高めることにつながる。

　以下に、X社のプロセス改善の成功要因を挙げる。

トップマネジメントの後ろ盾を得ていた

　組織に新しい方法や制度を導入する際には、現場の意見を取り入れて推進するべきである。しかし、部署間の連携や協力、組織内の意識付けの面を考えると、ある程度トップダウンで推し進めなければ、全社レベルでのスムーズな導入は難しい。

　X社の事例では、オフショア開発を推進する部隊は経営陣の直轄であった。また、リーダーであるN氏は、頻繁に経営陣へ報告・提案を行い、必要なバックアップを得ていた。

　このように、必要な指示や調整をトップダウンで実施することで、部署間の協力体制を迅速に築き、プロセスの展開や教育の推進をスムーズに行うことができた。

経験者を改善活動に巻き込んだ

　これにより、経験者の経験やノウハウに基づくエッセンスを改善内容に盛り込むことができる。改善内容がより実効的で現実的なものとなり、導入に説得力を持たせることもできる。

　X社では、オフショア開発の経験者を推進チームのリーダーとし、経験者から構成されるWGと連携させたことが、導入推進の大きな原動力となった。

各領域の主管部署を改善活動に巻き込んだ

　大規模な組織にはさまざまな主管部署が存在する。これらの部署から賛同を得られなければ、調整や修正により大きな手戻りが発生してしまう。

　N氏は経営陣の後ろ盾を得て、必要な部署を積極的に改善活動に巻き込むことで、整備検討の段階から協力体制を築き、部門間の調整や手戻りの発生を防いだ。

最終的には「人」

　本連載の第1回「サービスインに間に合わなかった原因は何だったのか？」で「プロセス改善成功の3要素（知識、スキル、やる気）」を説明した。今回のオフショア開発導入の事例でも、最終的には開発要員にこれらの3要素が必要であると認識され、意識改革や教育の施策を打つことになった。

プロセス改善を成功させる3要素

　特に組織のプロセス改善を考える際には、この3要素の中でも「やる気」、つまり「人」を動かす部分にその成否を分ける最大のポイントがあるといえる。なぜなら、組織の標準プロセスや共有された知識、スキルを使って業務を回すのは「人」であるからだ。

　これまで紹介してきた成功事例では「整備した開発標準やプロセスを、いかにして開発の現場に認知してもらい、利用してもらうか」について、多くの工夫が施されている。プロセス改善活動において「人」に対する訴え掛けや意識付けの重要性は極めて大きいといえる。

　プロセス改善を推進するチームや部署は、プロセスの整備と併せて、教育や情報の共有やプロモーションなどを通してプロセス改善の必要性や有用性を訴え、現場の背中を押すことで「人」のやる気を醸成することを怠ってはならない。

　しかし、現場側の協力なしに「人」の意識の向上は実現できない。プロジェクトマネジャーの業務は多忙を極めていると思うが、プロセス改善の最後の一押しは、現場のキーパーソンである皆さんに懸かっていることを忘れないでいただきたい。

　本連載の内容が読者の心に少しでも残り、組織全体の改善に向けて背中を押す結果につながれば幸いである。