現場から届けるアジャイル開発(9) オフショア開発の進め方

オフショア開発の進め方

「オフショア開発」とは主に、設計と実装が異なる拠点で開発される方式として話を進めます。この方法は、作業場所が異なるため同一オフィスでの開発に比べ仕様の認識違いなどが起きやすく、また成果物の品質に問題も起きやすいと言われています。システム開発をする場合離れた地域で開発を行うべきでは無いのですが、予算の都合や組織の戦略などによりどうしても避けられない場合もあります。自分も過去多くのプロジェクトをオフショア開発してきました。その経験から今回はオフショア開発の効果的な進め方をご紹介できればと思います。

ビッグバンテスト

すでにオフショア開発をされている方や、明確なウォーターフォール開発を実施している方たちは感じていると思いますが、出来上がったモジュールを一気に結合してテストをするビッグバンテストでは期待通りの成果は得られなかったと思います。よほど要件が明確で認識に相違が出にくい単純で小規模な開発ならば期待通りに進む場合もあるでしょうが、ほとんどの案件はそうはいきません。オフショア開発の場合は"全てを一括で受け入れて一気にテストをする"といった方式はやめたほうが良いでしょう。基本的には、イテレーションで開発するか、以前ご紹介したパラレルプログラミングなどの手法を組み合わせる必要があるはずです。受け入れにはそれなりに工夫は必要ですが、細かく何度も受け入れを実施すればこの問題は解決できるので、今回は深く検討はしません。

コミュニケーションの問題

それよりは、やはり場所が離れていることによるコミュニケーションの問題を今回は取り上げていきたいと思います。

すぐ近くに開発者が揃っていれば気軽に口頭などでコミュニケーションをとることができます。設計担当が開発担当者に声をかけ、都度状況などを確認することも容易に行えますし、逆に開発側から設計者に質問もしやすいでしょう。お客様とのやり取りも同じですが、遠隔地に離れているとそうはいきません。

以前は、メールや電話で質問や回答のやり取りをすることが多かったかもしれませんが、現在ではTV会議やSkype、Slackなどのチャットツールを使うことで以前よりはコミュニケーションが取りやすくなりました。ところが、実はそれらによる弊害も出ているようです。

過剰なコミュニケーション

オフショア開発をする場合は「コミュニケーションが問題になる」とたいていのプロジェクトでは気付いています。そのため、密なコミュニケーションをするために、定例報告をしてもらったり、定期的に電話や音声チャットで質疑応答したりしているのではないでしょうか。ただ最近、幾つかのプロジェクトで過剰なコミュニケーションが発生しているのでは、と思える状況を見かけました。

あるプロジェクトのリーダーの方はとにかく忙しそうで、1日のうちの半分ぐらいの時間は電話かチャットをしているという状況にみえました。リーダーの役割は確かにプロジェクトを円滑に進めることですから、コミュニケーションを密にとることはむしろ効果的であり、本人も忙しいけれどプロジェクトに役立っていると感じていたでしょう。しかし、電話やチャットだけの時間が1日のうち大半を締めている、という状況は適切で効果的かは疑問です。

自分がリーダーを努めていたプロジェクトは、それらのプロジェクトより規模も大きく要件も複雑で、オフショア側のメンバーも多くいました。しかし電話やメール、チャットなどはそれほど頻繁ではなく、チャットは1日10通程度という感じだったと思います。そして自分のプロジェクトは、(大変ではありましたが)大きなコミュニケーションの問題もなく、期待通りにサービスインできました。しかし、自分の知る幾つかのプロジェクトでは、密なコミュニケーションを取っていたにも関わらず、要件や品質の問題が収まらず、なかなか思い通りには進まなかったようです。

問合せに対しその場で回答

どうやら電話やメール、チャットで質問や確認がくると、その場で回答をすることを心掛けていたようです。同様に気になることがあるとその場ですぐに連絡もしていたということでした。悪くはないのですが、仕様の確認などのやりとりを電話やチャット、メールで行うとその内容がそこにしか残らないという問題が出てきます。そもそも質問や確認がくるということは「仕様に記載されていない」「仕様が曖昧でわかりにくい」「仕様が間違えている」などドキュメントに不備があるからではないでしょうか。もちろん、「確認していなかった」という場合もあるでしょうが、それなら「ココに書いてある」と回答するだけでOKなはずです。さらに仕様がメールやチャット履歴にしか残されていないと、そのうち「何が正しかったのか」が分からなくなり、同じような質問が起きたり、その状態を前提にすれば分かるのに前提の記載がないために、さらに問題が起きてしまう場合などもあります。

言葉が中心のコミュニケーション

さらに電話やメール、チャットにその場で回答しようとすると、どうしても言葉中心で伝えることになります。図や表があれば伝わりやすい内容でも言葉だけだと伝わりにくく、結局時間をかけて丁寧に説明する、という状態も起きていました。回答内容が記載された仕様書を見ながら説明できれば、もっと効率よく少ない時間で目的を達成できていたように思います。

緊急度を判断する

問題に気付いたり、確認が必要になったらすぐに連携したほうがよい、と考えている方は多いと思います。また、問合せを受けるとすぐに回答したほうがよい(回答したくなる)という方も多くいそうです。しかし内容によっては、緊急な問合せや回答が必要なものばかりではないはずです。慌てて電話、メール、チャットで伝えてしまうことを優先するのではなく、きちんと緊急度を判断して伝え合うべきです。とはいえ、聞きたいことをそのままにしておくと、気になってしまい作業がはかどらない、という方もいるでしょう。また回答する側としても同じです。その場合はチケットを期日付きで登録したり、朝会議事録にメモを書いて次回の朝会でに伝わるようにしておけば確実に伝えることができるはずです。緊急で伝えなければならないことはもちろんその場で連携すべきですが、そうでない場合はまとめて翌日の朝会の二次会で検討するように調整すれば、全員に内容も伝わるし、その問題を朝会の前に事前に緩やかに共有することもできます。また、コミュニケーションや打ち合わせをある程度適切なメンバーにしぼり、まとめて実施することで効率よくコミュニケーションを取ることができるはずです。

効率的コミュニケーション

過剰なコミュニケーションを避け、効率的なコミュニケーションをとるには以下を意識して進めていく必要があります。

緊急度を判断し、緊急ではければチケットや朝会議事録を利用する
メール、チャットに回答を書かず、仕様書などに記載しそれを利用して回答する

こうしておけば過剰なコミュニケーションは起きにくくなり、その分有効な作業に時間を割り当てることができます。ただ慣れないとついついメールやチャットに回答を書いてしまいがちです。実は自分も気が付くと、メールやチャットに回答を書いていて「はっ」と気づくことがいまだにあります。そのような場合はやはりチームみんなで協力することで解決できそうです。たとえば、

Aさん:「XXXの仕様だとYYYと矛盾するのですが、どうしたらよいですか?」
Bさん:「それはXXXの仕様の前提条件にZZZがあるからです。ZZZとは……」

というチャットが流れていたら

Cさん:「ZZZの前提条件は仕様に書いてありますか?」

という感じです。

ちょっと意地悪な気もしますが、こういうやり取りが増えると徐々に質問する側も回答する側も意識が高まっていきます。ちなみに上記のやりとりではBさんが心情的に面白くないかもしれませんが、プロジェクトの価値観として浸透すればそれほど気にならなくなります。もちろんBさんがすぐ隣にいれば口頭で確認するほうが良いとは思います。

「気軽なコミュニケーションが阻害されているように感じる。そのうち質問や確認自体が消極的になって提示されなくなるのでは?」という懸念もあるかもしれませんが、朝会が毎日行われていればそのような懸念も払拭できます。

まとめ

効率的なコミュニケーションを取ることで、本来やらなければならない作業により時間を割り当てられますし、この方法ならドキュメントが古い、という問題もそれなりに解決できます。

ちなみに開発は、お客様も含め全員が同じ場所で作業するのが理想だと思っています。また、オフショア開発であっても定期的にメンバーはお互いの作業場所を訪問しあって一時的にでも対面作業をするべきとも思っています。ただ、それらの点についての異論は少なそうなので今回は割愛しました。

今回は、オフショア開発のコツとして効率的なコミュニケーションの方法をご紹介しましたが、過剰なコミュニケーションはオフショア開発に限らず発生する可能性があります。自分のプロジェクトでも「ふりかえり」などでコミュニケーションが過剰ではないか、という問題提起が何度かされています。コミュニケーションはどんなプロジェクトでも必須ですが、効率のよいコミュニケーションを継続するのはなかなか難しいものです。皆様の周りでも過剰なコミュニケーションが発生していないかを一度確認してはいかがでしょうか。

次回は「軽量議事録」をお伝えしたいと思います。

執筆者紹介

川上文夫

パッケージベンダーのグループマネージャーとして複数プロジェクトのPM、PLを兼務。要件定義からプログラミング、テスト、運用を担当している。数多くのプロジェクトのリーダーとして20年のキャリアがあり、オフショア開発の経験も豊富。独自プラクティスに軽量議事録、朝会Wiki、設計実装並列手法などがある。アジャイル系コミュニティにも所属し、記事の執筆やワークショップ登壇など精力的に活動を続けている。