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

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

分散開発におけるテストフェイズ

分散開発におけるテストフェイズのポイント

• テストデータの作成
• バグの管理

テストデータの作成

・開発用のデータ、業務データの意義

　新システムを開発している場合、既存のデータ形式がそのまま使用できる場合は少ないといえます。このような場合、開発環境での動作確認のために開発用のデータをDB定義書の摘要などを参考に作成します。

　このような開発環境用のデータと結合テスト用データ、業務データでは、単純にレコード数の違いだけでなく、データの精度においても大きな隔たりがあります。開発環境用のデータは開発者自身が作成するため、DBの仕様や開発言語の特性を理解したうえで作成されています。いわば「システムが動くように作られたデータ」です。しかし、実際の業務データはこの限りではなく、非常に不可解なレコードが存在することがあります。

　では、この結合テスト用データ、業務データの作成は誰が行うべきでしょうか？ このプロジェクトでは当初、福岡の顧客が70％程度のデータ作成を行うことになっていました。

　確かに、業務を知っている福岡の顧客がテストデータを作成するのが最適という判断でしたが、実際には満足なテストデータは作成できませんでした。福岡の顧客は新システムの詳細（データ項目レベルの仕様）を知っているわけではないので仕方ない結果かもしれません。結局、東京の元請けと基幹開発会社が大急ぎでテストデータを作成することになりました。

　すべてのパターンを網羅した業務データの作成は容易ではありません。特に他社の業務データとなればなおさらです。今度は東京の元請けに大きな負担が掛かる次第となりました。

　一般的にテストデータの作成は今回のように顧客任せにされることがありますが、開発とテスト工数のほかにテストデータの作成のための工数を別途見積もっておくのが望ましいと考えています。

バグの管理

　単体テストフェイズ以降、バグの管理のためにbugzillaを使用しました。もともと、オープンソースのバグ管理を目的に開発されていることから分散開発での利用は容易でした。運用当初は、バグのトラッキングが目的で使用していましたが、実際には仕様変更の発生時や、不明確な個所が見つかったときの記録や担当を一元管理するための役割も兼ねていたように思います。このような側面からの利用も考えると、実装以前の設計フェイズから、bugzillaなどのトラッキングツールを運用して、設計からリリースまで使っていくという使用方法も効果的なのではないかと思われます。

　カテゴリ分けされた状態で情報が累積されていくというのは、ほかのコミュニケーションツールと違った切り口になるので有意義だと思います。

分散開発の有効性

分散開発と通所の開発の比較

　実際に、分散開発を振り返るとさまざまな問題が発生したものの、これらのほとんどはウォーターフォール型の開発手法そのものの問題と人為的なミスに起因するものが多く、分散開発を行わなかった場合でも同様に発生したと考えられる内容です。決して、分散開発は苦労するということではありません。以下は純粋に分散開発の使いどころは何かという点で考えてみました。

（1）分業したときの開発リスクを下げることができる

　各拠点のマネージャの元で対面による開発環境が運営されているような場合は、拠点間の依存関係や実装の依存関係に注意して分業化する。成果物を、逐一一元管理することで問題の早期発見ができると思われます。常に、開発者は所在地に関係なく同じソースを基に開発を行っていますので、あるマイルストーンで結合してから動作しなくなるなどのリスクを減らすことができます。

（2）外部リソースを活用するための手段となる

　現在のようにブロードバンドが定着した環境であれば、東京、福岡間でも距離による不便さはほとんど発生しません。エンジニアの出向などに変わる方法としての活用も可能でしょう

分散開発と拠点開発の効率について

　開発者のスキルにバラツキがある場合のように、一方的に教える側と教えられる側のような情報の流れが生じる場合は拠点開発の方が適しています。逆に、一定以上の開発経験のある開発者で構成される場合、自分のリズムで開発を行うことができることや通勤時間が不要または短縮されることで24時間のうちの有効時間が数時間延びます。開発のピーク時にはこの数時間の存在は意外と大きな差となります。

　在宅での開発であってもモチベーションを持ち続けられる自制心が必要ですが、自立した開発者向けには効果がある方法だと思われます。分散開発を実際に経験してみて、率直なところコミュニケーションのために時間や工夫を必要としたり、対面であれば手書きで済むような使い捨てのドキュメントなども、意思疎通のためにはドキュメント化した方がよかったりと、多少手間が掛かるのは間違いありません。感覚的には20％程度の工数増といったところでしょうか。

　いろいろなコミュニケーション手段を使い分けたとしても、やはり、対面の場合の効率には及びません。実際に、メンバーを1つの拠点に集め、プロジェクトを運営していくことができるのであれば、わざわざ優先的に分散開発を行う必要はないでしょう。

　しかし、分散開発的な開発手法そのものは従来型の拠点固定型開発においても有効に活用することができるはずです。

　このような視点から拠点内の開発環境を見直すと新たな発見があるかもしれません。今回は非常に限られた範囲の経験を基にしているので、ApacheSoftwareFoundation（ASF）のような分散開発のお手本とは程遠い内容となりました。興味のある方はASFの運営方法などを調べてみることをお勧めします。きっと、参考になると思います。

　今回の事例が、今後、皆さんが分散開発をするときに多少なりとも参考になれば幸いです。

メリット	デメリット
（1） 時間を有効利用できる （2） 分散したリソースが利用できる （3） 2拠点内でも分散の応用が可能になる （4） 開発組織、開発者の自由度が高まる	（1） 各拠点ごとの開発要員に十分なスキルが必要 （2） コミュニケーションが複雑でドキュメント化がいちいち必要
メリットとデメリットの比較

まとめ

1. オブジェクト指向言語は遠隔分散開発に向いている
2. 特にオープン指向（Javaなど）の言語は、思想が分散開発を基盤に作られており、IDEをはじめとするさまざまなツールが分散開発に対応している
3. 顧客→元請け（上流工程のみ）→分散開発会社は無理、必ず元請け（上流工程）の後ろに実装全体を取りまとめる組織が必要。顧客→元請け（上流工程のみ）→開発会社（詳細仕様から実装を担当）→分散開発会社（実装を担当）のように
4. メッセンジャーなどを有効利用して、チャットやホワイトボードなどをフル利用したうえで「無料」でミーティングを行う
5. 分担は機能とシステムのレイヤで分ける方法がある。分散の場合は機能で分けて別のシステムというくらい疎結合にしておいた方がよい
6. 分散開発の結合テストは第2の開発作業としてのコストとリスクを見ておくこと
7. コミュニュケーションの使い分けが必要。初期は、メッセンジャーや会話を通して密なコミュニュケーションを。中盤の開発佳境時は逆にコミュニケーションをメール等で緩くして、再び終盤では密なコミュニケーションを心掛ける
8. 顧客と元請け（上流工程）が分散してしまうと「業務上の常識」など仕様であらためて説明されないような、仕様がどうしても実装後に出てくる
9. QA表には全体仕様の把握が困難になる問題がある。ネットミーティングにはチャットログに仕様がうずもれる恐れがある
10. 遠隔での確認は常にあいまいになる。相手が嫌がっても何度でも聞き返す
11. 遠隔分散開発の工数は、通常の開発よりも（工数が）20％程度増しになる

「分散開発のABC」バックナンバー

• やってはいけない、設計と実装の並行作業
• コレだけ準備すれば分散開発に失敗しない