コレだけ準備すれば分散開発に失敗しない：分散開発のABC（前編）（3/3 ページ）

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

どうやってプロジェクト全体を運営するか？（プロジェクトの運営と分散開発）

検討ポイント

• 分散している環境でのドキュメントやソースの管理手法→どうやってセキュアな分散管理を行うか
• コミュニケーションの手段→コミュニケーションツールの選定方法
• 分散開発で開発環境をどうするか→開発環境の準備方針
• 特筆すべきCVSの効用→CVSは分散開発に特に効果的である

ドキュメントとソースの管理

　J2EE環境では、IDEやデプロイにかかわる多くのツールがCVSをサポートしています。CVSはもともと多数の……場合によっては世界中の開発者が1つのプロダクト開発に参加することを前提としたオープンソースプロダクトのサポートのために設計されています。すなわちその状況を小規模で再現したものが分散開発プロジェクトだとすると、CVSこそ（分散開発に）「非常によくマッチした」ツールといえます。

CVS＋WinCVSによる運用

　今回、CVSはソースファイルとドキュメントの管理を目的として設置しました。遠隔開発であったためにSSHを利用し、秘密キーと公開キーを使用した認証方式を採用してセキュリティを高めました。これにより、福岡、東京、福島あるいは自宅からでもCVSへ接続でき、同じ情報を全員が共有することが可能となりました。

　「JavaソースのクライアントはEclipse」「ドキュメント系のクライアントがWinCVS」という使い分けを行い、CVSにはコミットメールを送信するように設定を行いました。CVSにコミットメールを設定することで、ソースファイルのどこにどのような修正が入ったのかをメールで知ることができます。

コミュニケーションツールの選定（コミュニケーションツールの比較検討）

　東京、福岡間でのコミュニケーション手段として、ドキュメント外の情報を効率よく伝えるために、MSNMessengerを使って音声によるコミュニケーション環境の構築を試みました。

　MSNMessengerによってノートPCにヘッドセットを接続し、通話することが可能となり、東京―福岡間で通話することが会社でも自宅でも可能となりました。実際の使われ方は次のような感じでした。通話したい相手にメッセンジャーを使ってこれから通話することを伝え、ヘッドセットなどを準備してもらってから通話します。なお、メールと違ってリアルタイムに相手がいないとコミュニケーションが成立しませんので、アポ取りは欠かせません。無料のIP電話状態なので、通話料などを気にすることなく納得いくまで話し合いができます。ホワイトボードや一時的ファイルの送受信を併用することによってさらに効果的になります。

　その結果、正式なドキュメント類はCVSを利用し、必要に応じてメッセンジャーでチャットするという方法で落ち着きました。また、メッセンジャーは開発者だけでなく元請にも利用してもらい、仕様の確認やそのほかの質問事項の受け答えなども頻繁にメッセンジャー上で行いました。

開発環境の準備

　各開発者のPC上で別々に開発を行い、PostgreSQLも開発者のPC上で動作させ、同時に単体テストも行いました。運用環境がLinuxということもあり、OSの文字コードやファイルシステムを意識しなければならない場合を除いて、ほとんどの部分をWindows上で行い、最終的な動作確認をLinuxで行うといった方法での開発作業となりました。ただし、共通のサーバを利用しなかったので、開発者間のテストデータの食い違いやDBの定義更新漏れなどの対応は注意が必要でした。開発者のPCに環境を分散することによってネットワークが使用できない環境でも開発を行うことが可能となり、テストデータが別の開発者によって書き換えられるといったことも発生しないために運用面での問題が非常に少なく、良好でした。

CVSの利用と効用

　遠隔からの利用を許可したCVSサーバにソースファイルとドキュメントを集中管理していくことによってCVSサーバから必要な情報をいつでもどこからでも取得することが可能となり、自宅での作業と出社しての作業の違いさえもほとんどなくなりました。コーディングという側面だけで考えれば両者に決定的な差はなくなりました。

　最終的に出社する主目的は開発者同士で迅速なコミュニケーションを取るためであり、仕様が明確な部分や実装上問題の生じる余地のない個所や事前に打ち合わせが終わっている個所を開発する際には、必ずしも出社する必要がない環境を構築することができました。

作業分担はどうするか？（開発範囲の振り分けとチーム編成）

検討ポイント

• 分散開発状況におけるチーム編成→どの機能をどのチームに割り振るか
• 分散開発状況における担当→機能で分けるか、アーキテクチャのレイヤで分けるか
• 分散開発状況に実装方針→インターフェイスの局所化による分散開発の方針

チーム編成

　BtoCサイトの開発は東京をメインの担当とし、一部を福岡で開発するようにしました。管理機能と基幹連携バッチは福岡担当で開発することにしました。

　主な理由としては、BtoCサイトは「最もView的に重要な部分」に関しては頻繁に元請との打ち合わせが発生すること、また、非常に仕様が事細かいことからこの対応を福岡で行うのは困難だと思われたためです。

　BtoCのうちでも必要とされる、その時点で考え得るすべての機能（ユースケース）を一覧表にし、それに対してほかの機能に依存する度合いの少ないものを抽出して福岡の開発担当としました。管理機能と基幹バッチに関しては機能的に独立性が高く、仕様的にも割合ふらつきが少ないと思われたので、これらの評価を行うことなく福岡の開発担当としました。

　作業ボリューム的には東京6：福岡4程度の作業配分となりました。作業配分を行うに当たっては、開発者間の疎結合が実現可能になるように配分することを意識しました。

　福岡―東京間で、何らかのコミュニケーション手段によって開発者間の意思疎通を図ることはもちろん可能ですが、面と向かって話をする場合と比べて同じ認識を得るまでにかかる時間と労力には明らかに差があります。作業効率を上げるためには、なるべく東京―福岡間の調整を減らすことが必要でした。開発を円滑に行うためには、東京―福岡間の意識合わせが重要である半面、作業効率的にはそれぞれが独立している方が効率的といえます。

垂直分割と水平分割

　福岡の開発者に関しては、各自がプロジェクトマネジメント・スキルを有するほどのメンバーであったため、機能単位での割り振りを前提とし、開発者への詳細な作業分担の決定は福岡側に一任しました。東京側では、機能単位での分割をメンバー間で協議したところ、開発対象が業務内容の影響を強く受ける部分であること、仕様の理解に時間がかかることなどを考慮して、

• 仕様を理解しているメンバーがビジネスロジックとエンティティを実装する
• 仕様を理解していないメンバーはプレゼンテーション層を実装する

というレイヤによる担当範囲の切り分けを行いました。担当範囲の境界は以下のように決定しました。

図3 担当範囲の境界

　今回のフレームワークはStrutsであったため、JSP、Action、Formまでをプレゼンテーション担当、Actionから呼び出すビジネスロジック以下をビジネスロジック担当範囲とし、最初にすべての機能に対してモック実装を行い、順次、本実装に切り替える方法で実装することにしました。仮とはいえモックの実装とプレゼン層の表示用のデータを開発、初期の段階で作成するのは、オーバーヘッドになりますが、最終的には有効な手法だと思われます。

　プレゼンテーション担当の作業とビジネスロジック担当の作業が相互依存しないように配慮したことで、それぞれの開発の進ちょくの影響を受けることなく開発を進めることができ、各自の開発範囲に集中することができました。機能単位で分割する場合はモック実装することの効果はさほど目に見えないかもしれませんが、レイヤ別で作業範囲を区切る場合にはモックは有効だと思われます。

インターフェイスによる責務の局所化の効果

　Seasar 2をフレームワークとして採用することによって、機能単位でのインターフェイスの実装、レイヤ別でのインターフェイスの実装を徹底しました。このことによって実装クラスへの依存部分が少なくなり、仕様変更による影響を局所化することができました。

　特に、Viewに関する修正が業務ロジックへ影響を与えにくくなること、また、DAOへの修正がViewまで波及しにくくなることから、レイヤ別で作業範囲を分担した東京側の開発では大きな効果がありました。

　また、モックオブジェクトを併用したことにより、モックから実装クラスにSeasar 2の定義ファイルを書き換えるだけでスムーズに業務ロジックを切り替えることができ、それぞれの開発進度の影響を受けることなく、各自の開発対象に注力することができました。

---

　最後に、分散開発を行うにあたっては、同時並行での開発作業が可能となるように準備することが重要であり、そのための開発環境、フレームワーク、アーキテクチャを意識しておく必要があるということで前編を締めたいと思います。前編に関しては、用意周到に準備し、割とうまくいった部分を中心に記述しましたが、後編ではその後、具体的にどのような展開となっていったのかを示しながら、遠隔開発の有効性に関して述べていきます。

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

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