この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。
今回の内容は、リーダーシップトライアングルのManagementに関係します。Managementについては、連載第9回「ソフトウェアは目に見えない」を参照いただければと思います。
 |
| 図1 リーダーシップトライアングル。今回は「Management」に関連する内容を紹介 |
■オフショアの理屈は分かったが
前回の記事「何でオフショア開発しなくちゃいけないの？」では、マネジメントの視点から、オフショア開発の有効性を説明しました。「少子高齢化、グローバル化の潮流の中で、オフショアが有効な手段となり得る」という趣旨です。
私の経験では、このような説明で、多くの方にある程度納得してもらうことができます。
しかし、実際のシステム設計・開発現場のリーダー、メンバーに、「本音のところではなかなか納得できない」という意見をもらうこともあります。典型的な現 場の意見は、「理屈は分かった。でも、なぜ、私がオフショアの当事者にならなくてはいけないの？ 正直、面倒なだけ。できれば避けたい」というところでしょう。
例えば、オフショアのパイロットプロジェクトのメンバーを選定する、大規模プロジェクトで一部の開発をオフショア化するに当たり、チームを決定するという場面では、「私はやりたくない。ほかの人が対応してほしい」という本音を聞くことがあります。
■オフショアを嫌う人の理由
このようにオフショアを避けたいと思う人たちが、その理由として挙げるのは、以下のようなことでしょう。
・気心の知れた人と仕事をした方が生産的
まず、「気心の知れたメンバーと仕事をしたい」という理由を聞くことがあります。
例えば、何年も付き合いのある協力会社がある場合、その会社のメンバーと仕事をすれば、過去に共に作業をした経験に基づいて作業を依頼することができます。
「前回のプロジェクトの設計成果物と同じレベル感で成果物を作ろう」「3年前のあのプロジェクトで使ったテスト手順書を活用してテストを計画しよう」のように、作業を円滑かつ正確に行うことができるでしょう。
「国内の気心の知れたメンバーとなら、生産性の高い作業ができる」「オフショア化してしまうと生産性が低くなり、結果としてのトータルコストが割高になる」という理論を展開する人は少なからずいます。
・言語の壁がある
「言葉の壁があるから」という主張をする人もいます。
中国でオフショア開発をする場合、一般的に、中国側メンバーに日本語ができる人がいるといわれます。しかし、中国のプロジェクトメンバー全員が日本語を話せるということはないです。一部のメンバーのみということが通例です。
日本語ができるといわれるメンバーでも、日本語のレベルが低いこともあります。「てにをは」が少々おかしいくらいであればいいのですが、何をいっているのか分からない、日本語でこちらが伝えたことが正しく伝わらない、というケースはあります。
一方、インドのような英語圏でのオフショア開発では、英語でのコミュニケーションがメインとなります。ITエンジニアに英語の読み書きが得意な人は多いで すが、会話となるとちょっと厳しい、という人が多いのも事実です。さらに、インド人の英語は、発音やイントネーションが欧米人と異なることがあります。
ですので、「わざわざ言葉の壁を乗り越えてまでオフショア開発するのは正直面倒だし、品質にも問題が出てしまう」と考える人が多いのでしょう。
・文化の違いから来るストレスがある
さらに、「そもそも文化が違うから」という意見を聞くこともあります。
例えば「納期についての考え方が違う」などです。私の経験からもいえますが、欧米でのプロジェクト経験を基礎としたオフショア開発メンバーは、平気で納期 をずらす傾向にあります。仕様が変わった、仕様に追加があった、他チームのスケジュール遅延が自分に影響したなどの場合、悪びれずに「納期が延びます」と いう一方的な通告をしてくることがあります。
確かに、オフショア開発メンバーのいうことも、理屈としては理解できます。自分のチームの作業に影響する現象が発生した場合、作業の納期が後ろにずれるのは当然というわけです。
しかし日本人の感覚としては、納期をずらすということは重要な意思決定事項です。すべての考えられ得る回避策を講じたうえで、やむを得ず発動する最後の手段と考えるのが通例ではないでしょうか。
オフショア開発メンバーが、簡単に「納期が延びます」と決定してしまうと、いちいち納期の重要性や回避策を講じたかどうかなどの確認をしなければなりません。
このように、感覚のずれている相手とのコミュニケーションは、ストレスはたまり、コミュニケーションコストも過多となり、プロジェクトの進ちょく・予算にも影響を与える場合があります。
それでも、オフショア化のメリットは大きい
なるほど、オフショアを避けたい気持ちは分かります。理由についても、確かにおっしゃるとおりです。「面倒だ」という単なる感覚論ではなく、実際にプロジェクト運営上のリスクとなり得る理由があると思います。
しかし、だからといってオフショアを避けていいのでしょうか。オフショア化を回避することが、本当に得策なのでしょうか。
私の意見ですが、オフショアプロジェクトを円滑に遂行するために必要な段取りを整えることで、プロジェクト自体の運営を円滑にできるという側面があると思っています。
具体的に見ていきましょう。
・オフショアでは、成果物、作業段取り（方法論）の事前定義が必要
オフショアプロジェクトを円滑に遂行するには、成果物の定義が重要です。
オンショアで作成する成果物を定義し、オフショアにおける作業のインプット・アウトプット成果物を定義します。成果物の書式のみならず、詳細度（どのレベルまで記述するか）についても、作業の依頼前に定義することで、オフショアでの作業が円滑になります。
また、成果物を作成する段取り、つまり開発の方法論も重要です。方法論のどのタイミングでオフショアに作業を依頼することが最善かを事前に決定しておくことで、オンショア・オフショア双方の意識合わせが事前にできるからです。
・作業の分担や手続きの明確化も重要
作業範囲、役割分担の明確化も、重要な要素です。
オフショアに仕事を依頼する場合でも、国内の協力会社に仕事を依頼する場合でも、複数の組織がプロジェクト作業に関与する際は、作業範囲や役割分担の定義 が重要となります。お互いにどういった作業を実施するのかが明確になれば、おのずと分担が明確になり、作業の抜けや漏れがなくなりますので。
また、オフショアプロジェクトを推進するうえで重要な項目として、仕様変更管理の手続きを明確化し、同時に構成管理を明文化することがあります。ロケー ションが離れているため、これらの手続きを明文化して運営しないと、仕様変更が適切に反映されず、成果物・プログラム資源などの管理が不十分となり、品質 が保証できなくなるなどの影響が出るのです。
・結果として、開発能力の成熟度レベルが向上する
以上で挙げた、「成果物、作業段取りの事前定義」「作業の分担や手続きの明確化」は、オフショア開発をする、しないという前に、そもそもプロジェクトの作業品質を保証するうえで非常に重要です。
見方を変えれば、オフショア開発を前提とすることでこれらが習慣化されれば、プロジェクトの作業品質保証に貢献できることになります。
このように考えると、「オフショアプロジェクトが運営できれば、国内の協力会社に作業を依頼する場合にも、作業品質と効率がアップできる」といえるのでは ないでしょうか。つまり、「協力会社のスキル・経験に深く依存しないプロジェクトの体質を築き上げることができる」ことになるのではないでしょうか。
■オフショアを経験し、チーム全体の設計・開発能力を上げよう
記事冒頭で紹介した典型的な現場の意見は、「理屈は分かった。でも、なぜ、私がオフショアの当事者にならなくてはいけないの？ 正直、面倒なだけ。できれば避けたい」でした。
避けたいと思わず、「オフショア化を推進することで、プロジェクトチームとしての設計・開発の能力、組織としての成熟度が向上する」と認識してみてはどうでしょうか。
さらにいうと、いったんオフショア開発を経験すれば、そのプロジェクトメンバーは、オフショアの経験者として認識されるわけです。「少子高齢化、グローバ ル化の潮流の中で、オフショアが有効な手段となり得る」という現在において、オフショア経験者として重宝されるようになるわけです。
まとめると、オフショアを経験すれば、
- 組織としての設計・開発能力が向上し、成熟度が上がる
- さらに、オフショア経験者として重宝される
のです。決して悪い話ではないと思いますよ。
皆さんのオフショアへの認識に、新たな視点を加えることができればと思い、オフショアの効能・効果を説明しました。皆さんの日ごろの仕事や、今後のキャリアを考えるうえでの1つの視点として活用していただきたいと思っています。
●●コメント●●
0 件のコメント:
コメントを投稿