やってはいけない、設計と実装の並行作業：分散開発のABC（後編）（1/4 ページ）

[三橋和広，株式会社オープントーン]

“常識的な判断”って何？

　前編（「コレだけ準備すれば分散開発に失敗しない」）では、（遠隔）分散開発に携わる、アーキテクチャやチーム運営、設計手法に主な視点を当ててきました。後編ではむしろ、実装からリリースまでのより現場の中で起きていたことに焦点を当ててゆきます。この分散開発中に東京の元請けから発せられた言葉で非常に印象に残っているものがあります。興味深いと思われるので紹介します。プロジェクトの初期に画面設計書の記述をするに当たって、仕様の確認をしていたときに顧客から“そこは常識的な判断でお願いします”と仕様の不明確な部分に関して言葉を濁されてしまったことが何度かありました。

　システムを作るうえで“常識的な判断”って何でしょうか？ 複数のラジオボタンが並んでいてもある人は当然単一選択だと思い、また別の人は複数選択できるかもしれないと考えるでしょう。この企業間、個人間の“常識”という言葉の食い違いを埋めていく作業がプロジェクトにおける「設計」のすべてだったような気がします。

コミュニケーション（仕様の伝達方法）

コミュニケーション（仕様の伝達方法）の検討ポイント

• QA表と仕様書の功罪
• ネットミーティングの功罪

顧客からの仕様の伝達

　東京の元請けから東京の開発チームへの正式な仕様の伝達手段は“仕様書に明文化された内容”であり、ネットミーティングとオフラインミーティングでこれを補足していく予定で考えていました。しかし、3カ月目の詳細設計フェイズくらいから、次のような理由で東京の元請けの作業量が徐々に増加し始め、開発進行のボトルネックとなりつつありました。

• 東京の元請けは福岡の顧客からヒアリングを行った結果を仕様書としてまとめる作業をしていたこと
• 東京の元請けは東京の開発チームと仕様書に先行して、開発を止めないためにオンライン、オフラインでのミーティングを並行していたこと
• 作成した仕様書を福岡の顧客に確認するという作業も同時に行っていたこと

　近年の開発期間は、年々いや日々短くなっています。しかし、開発規模がだんだんと小さくなっているわけではありません。むしろIDEなどで効率化されて生じた分の作業時間で新たな機能の実現が要求されます。つまり、アプリケーション規模は大きくなり、一方で開発期間はどんどん短くなっているというのが現状といえます。

　そのため、実際に現場でよく使われているのが「設計しながら実装していく」方式です。大抵最初に開発元と顧客の間では「スケジュール」が取り交わされ、それによると、どこかできっちりと設計が終わり、それに引き続く作業として実装が開始されるという流れが計画されています。しかし、現実には「時間がないので」「実装可能なところから実装を開始する」という方式が非常によく使われます。

　ところが、そもそも開発作業というのは、開発側と顧客、さらには要件定義を担当する上流工程の元請け、おのおのがすべて自分の役割を果たさないと順調には進めません。「工期の圧縮」による「しわ寄せ」は、なにも徹夜で機械の前に向かう実装作業者やそのリーダーだけに及ぶものではありません。「設計しながら実装する」方式による工期の圧縮は、開発側だけでなく、仕様策定を担当する顧客や上流工程の担当者にも多大な負担が掛かることになるのです。

　今回の案件においても、仕様策定などの上流作業が一時期に集中してしまったために、東京の元請け担当者の作業負担が急激に増えてしまいました。

　東京の元請けがボトルネック化したことによって、仕様書の完成を待っていては開発が進まない状況となったため、プロジェクト運営方法を大きく見直して、別の方法を探ることになりました。

　それまでは、東京の開発チームのリーダーが、東京の元請けの元に常駐して、あるいはメールなどで仕様書を受け取り、それをトリガにして福岡まで含めた開発チーム全体に仕様を一斉に伝播させていました。しかし、東京の元請けがボトルネック化したことにより、この方法を見直して、各開発者・チームがそれぞれにQA表に書き込む方式に変えていきました。もちろん、ボトルネックの解消のためだけではなく、この段階になると東京の開発チーム側の判断、あるいは東京の元請けで判断できる内容が減少し、福岡の顧客の決定待ちという内容がほとんどの割合を占め、QA表に記載すべき事柄が増えていったためともいえます。

　つまり、各開発担当者が東京の元請けの担当者と電話あるいはチャットなどで緊密に連絡を取り合い、決定事項をQA表に転記してCVS上で共有するというような運営に変わっていきました。これにより、元請けの担当者による仕様確定を待ち、東京のリーダーが受け、それを開発担当者全員へ一斉に伝播させる、という従来の方法が招いていたボトルネックの解消を目指しました。一見効果的に見えたこの方法ですが、新たな大きな問題が発生しました。このことは分散開発の場合特に顕著に表れる問題でした。

　QA表により、開発担当者が個々に進められるようになった半面、実装全体をふかんして仕様を見渡す「アーキテクチャ」の不在を招き、その結果、開発担当者ごとに元請けとやりとりした確認・決定事項が、別の機能の仕様と矛盾しているという問題がしばしば発生するようになったのです。

　分散開発でなくても発生する可能性のある問題点ではありますが、分散開発環境でなければ比較的発生頻度を抑えられたことでしょう。チームが昼食を共にし、日々仕様について意識・無意識に調整している環境と違い、特にこういったQA表の内容のような、「細かい仕様」での差異が調整されることなく積み上がっていったのです。このことは、より大規模な分散開発では、この問題をより顕著に発生させる恐れがあるということも暗示していました。