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

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

ネットミーティングの功罪

　前編では、ネットミーティングを以下の理由から分散開発には必須だと述べました。

• 無料のIP電話状態なので、通話料などを気にすることなく納得いくまで話し合いができます
• ホワイトボードや一時的ファイルの送受信を併用することによってさらに効果的になります

　しかし、実際にネットミーティングにより、プロジェクトが運営されていくうちに、問題点が生まれてきました。これまで「仕様」とは仕様書であり、そこにQA表が付け加えられたというのがプロジェクト全体の認識でした。しかし、ネットミーティングは別の問題を発生させてしまいました。

　通常、プロジェクトでは、ホワイトボードを前にした打ち合わせを行い、その内容を可能であればプリントアウトし、あるいは、議事録に残すなどして仕様の一部として取り込みます。ところが、今回分散開発により、その議事録やホワイトボードの印刷物に当たるものは、各個人のネットミーティングのログに押し込まれてしまったのです。

　ネットミーティングのログはチーム全体への情報伝搬性に著しく欠けます。メールではCCで意図してチーム全体へ情報を送ることもできますが、ネットミーティングは「話し合った仕様」が他者に伝播することなく、ほとんどの情報がそっと各個人のログファイルにしまわれていったのです。

　このように、徐々に非公式のドキュメントに仕様の断片が記述されるような状況が続いたことによってさまざまな影響が表れました。これまでは、主な仕様の確認対象は仕様書であり各種設計書でしたが、QA表やチャットのログなどに分散したことにより、仕様が断片化し仕様のよりどころが、ぐらつき始めてしまったのです。

　コミュニケーションツールは確かに即時的な意思疎通を可能し、ログを残せば記録することもできます。しかし、これらの情報は分散しやすく整理もされていません。この分散を防いでいたのが仕様書と設計書であったのですが、東京の元請けの負荷の高まりと比例して徐々に形骸化してしまいました。

図4 仕様が仕様書や、チャットログ、QA表に分散してごちゃごちゃしている

　同じころ、東京と福岡の開発のスタイルに違いが生じ始めました。東京では、開発の進度に応じて必要な情報をネットミーティングやQA表で東京の元請けから毎日聞き出すスタイル、福岡ではポイントポイントでその時点で想定される細かな仕様まで片っ端から確認して、一度確認が終わるとしばらくは開発に専念するというスタイルです。

　どちらの方法が良いとは一概にいえないのですが、顧客、開発者ともに定期的にネットミーティングで待ち合わせて全員でミーティングをすることはなかなか実現できませんでした。やはり、「各社（または各者）の得意なスタイル」で開発を行いたいというわけです。

　そのため、ネットワークミーティング空間に全体がそろうことはほとんどなく、時間差で入れ代わり立ち代わり参加するというのが実情でした。常に何人かが発言し、そのほかの関係者はそのなりゆきを横目に開発作業をしているという感じです。もちろん、実装するうえで東京と福岡で依存関係が発生する個所の仕様の決定や全体的な詰めの部分では東京側が決定していきましたが、これらの差異を埋めていく作業に予想以上に労力を必要としました。

コミュニケーションについてのまとめ

　分散開発を行ううえで、すべてのフェイズを通じて同じコミュニケーションの取り方で有効かということ、やはり、その時々の状況に応じて変化させた方がよいようです。

・概要設計、詳細設計フェイズのコミュニケーション

　仕様書をベースに不明確な部分をネットミーティングで補完していくような利用の仕方で、常時ネットミーティングに参加し、積極的に開発者間で情報を共有するようにしていました。

・実装時のコミュニケーション

　詳細設計がほぼ終了し、本格的に実装に入った場合、仕様変更の連絡や定期的な進ちょく状況や問題の共有などのように定期的な連絡事項が中心となり、即時性の高いコミュニケーション手段は相手の作業を中断させることにもなりかねないので、緩やかなコミュニケーションが適します。メールやメーリングリスト、などが主なコミュニケーション手段となりました。

・単体テスト時のコミュニケーション

　ほとんどの場合、実装と並行して実施されていると思われますが、仕様漏れや仕様変更でバタバタするのもこのころなので、早期に連絡を取り、対処する必要があります。ネットミーティングのような即時性の高いコミュニケーションが必要となりました。

・結合テスト以降のコミュニケーション

　これ以降のフェイズは、バグ管理ツールが主体となり、徐々にコミュニケーションツールの利用頻度は下がっていきました。

図5 コミュニュケーションを3つ使い分ける

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

・仕様、設計の伝達／顧客からの仕様の伝達不備

• 未確定の仕様による伝達不備・未確定による整合性などの不備
• ミーティング内容を後から引っくり返す仕様書
• 大量の仕様変更と、追加仕様

　どのプロジェクトでも多少の仕様の伝達不備はあるもので、資料やミーティングの内容だけで顧客と100％同じ仕様イメージを共有することは現実的には困難です。そこで、顧客とのミーティングを繰り返し、各種設計書など目に見える形でお互いの想定が一致していることを確認しながら、仕様の精度を上げていくことが必要となります。

　しかし、残念なことに、顧客からは、ドキュメントは開発の主対象ではなく副産物と思われていることが多く、開発側はドキュメントの重要さを認識していながらも、ドキュメント作成作業に多くの工数を割り当てられず、非常に精度の高い仕様書を作成するのが困難という実情があります。

　そこで、どの程度の精度で実装に入ることができると判断するかが1つのポイントになります。幸いこのプロジェクトでは、東京の元請けはドキュメントの重要性を十分に理解していたために、最終的には完成度の高い仕様書を作成することができました。ただし、内容だけでなく体裁等も非常に細かく意識して作成を行ったため、開発が進んだ後の改変に弱かったのも事実です。というのは、改変が生じた際には、実装の変更だけではなく、仕様書にも当然反映させなければならず、体裁までを含めた仕様書ドキュメントの保守に多くの時間を要することになってしまったのです。

　また、仕様書の記述がミーティング実施より後に行われたために、ミーティングでの合意事項が勝手に破棄され、最終的に仕様書に記述された内容が正しいとされたこともありました。このことにより、ミーティングでの合意内容を基に先行して実装に入っていた部分に手戻りが発生し、開発対象がより深く、広くなりました。仕様が膨らみ、工数が増大したことに関しては後々大きな問題になりました。

大量の仕様変更と、追加仕様

　このプロジェクトではQA表に掲載されたような、仕様の詰めの甘い個所や福岡の顧客の確認待ちなどで先送りにした事項が軒並み後で仕様修正事項となってしまいました。QA表に取り上げられた仕様については、繰り返し修正が発生しないように影響の予想される範囲を想定して、あらかじめ事細かく東京の元請け経由で福岡の顧客に確認を行います。

　すると、仕様書中に十分に明記されていなかった“業務上の常識”が見つかり、理解が難しい条件分岐や、特殊な実装パターンが必要になりました。このようなやりとりが何度もあり、始めから分かっていれば一度で終わっていた実装を何度もやり直すことになってしまいました。事前にインターフェイスを使って責務を分割していたとはいえ、あまり好ましい状況ではありません。

　結果からいえば、東京の元請けと福岡の顧客とのコミュニケーションが不十分だったといえますが、初めての顧客の業務仕様を、漏れや誤りがほとんどない十分な精度まで仕様を引き出すというのは至難の業です。特に、分散開発のような状況では一層難しいものとなります。

　この点は、元請けと顧客が遠く隔てられているという状況から発生した大きなリスクポイントといえます。遠隔で仕様を詰めるという行為は、コミュニュケーションの機会や方法が限られることで、仕様書の外にある情報、例えば“業界の常識”等の情報を得にくくなり、そのことがあいまいな仕様や、開発者からは理解しにくい仕様を残すことにつながってしまいます。このプロジェクトでも、このことが、開発者に多くの仕様変更の負担を与えることになってしまいました。

図6 ミーティングで出てこない業界の常識

・仕様、設計の伝達／設計者から開発者への仕様の伝達不備

• 伝えた・受け取った「つもり」のミーティング
• 用語の統一

　通常分散開発のコミュニュケーションのトラブルポイントとして、予想されるのは、開発拠点が遠く隔たっているゆえの情報伝達の難しさ、少なさ、あいまいさ等による仕様齟齬が挙げられます。しかし、これらのポイントにはむしろ十分に注意を払ったため、比較的トラブルにはなりませんでした。

　今回このプロジェクトのコミュニュケーションの手法自体はうまくいったようなのでご紹介しておきます。

コミュニュケーションの手法

• あいまいさを排除する（何度でも聞く）
• 図を用いる
• 条件を限定する
• 設計者にとって「当然のこと（既知）」が開発者にとっては「知らないこと」であることに注意する

　特に対面でミーティングや説明を行っていると直接話したことによって、聞いている側はなんとなく分かったような気になることがありますが、時間がたってから理解できていないことに気付き、再度聞き直すことになった経験はないでしょうか？

　このようなことを避けるために、自分のイメージしているものと相手のイメージしているものが同じであると判断できるまで繰り返し、遠慮なく確認するようにしました。“それって　結局　XXとYYの組み合わせしかないということですね”などとなるべく、条件を限定して断定的に確認するようにしています。

　また、言葉で説明されるより手書きでもいいので積極的に図解するようにしました。言葉で説明された場合に即座にイメージできるのは、これまでの経験がある既知の内容に関してであって、新規の内容の場合、言葉からイメージするには時間がかかります。遠隔で開発者間でコミュニケーションを行う場合、どうしても言葉と音声による伝達が主体となります。

　ホワイトボードなどで図が使えるとはいえ、ある程度以上複雑なものは別にドキュメントを作成するようにしました。このような点に注意しながら進めていったことにより、“こういう感じに実装してほしかったのだけど”といった仕様プラスαの希望的な部分以外には、開発者間で大きな狂いは生じませんでした。

　それよりも、個人的に既知のものとなっている事項をほかの開発者が知らないことを忘れていて説明が不十分となり、後から質問を受けたことが何度かあります。

　東京の元請けへ常駐していたこともあり、そのときに打ち合わせた内容などは、すべてがドキュメント化されていたわけではなかったので、しばらくこの傾向がありました。自分が知っていて、ほかの人が知らないということになかなか気付かないものです。