分散開発に向いているアーキテクチャとは？（アーキテクチャの選定と分散開発）
分散開発におけるアーキテクチャ選定のポイント
- 業務の複雑さの度合い
- パフォーマンス
- 開発者の錬度
上記の点は通常のプロジェクトにおけるアーキテクチャの選定方針となんら変わるところはありません。しかし、分散開発として特筆しても良い点が1つあります。それは「オブジェクト指向言語は分散開発に向いている。特にJavaはその思想から向いている」という点です。
どんな開発プロジェクトでも、業務要件に沿ったアーキテクチャの決定が最初の命題となります。もちろんBtoCサイトであればCGIで十分にその要件を満たしますが、今回はCGI系の言語ではなく、あえてJ2EEを利用しました。それは、本案件の非常に大きなポイントとして「分散開発」が前提だったからです。
もう一度述べておきましょう。Javaは分散開発に向いています。もちろん、オブジェクト指向そのものが分散開発に向いているといえます。疎な結合によって作られた「機能」はモックやスタブでの個々の開発を容易にして、結合のリスクも少ないでしょう。
さらに、同じような言語のC#と比較しても決定的な違いがあります。Javaは基本的な思想として、サン・マイクロシステムズなどのVMベンダですらAPIの1ベンダでしかないという発想に基づいている点です。そのことは、いくつものVMベンダが提供するAPIのパッケージを確認するとすぐに理解できるでしょう。
sun.com……というパッケージ構造の思想は、明らかにあらゆるAPIが分散コンポーネントとして多くの開発組織（開発会社）から提供されることが前提になっているのです。この問題は、むろんC#でも単にネームスペースを同じような形式にすれば済む話です。しかし、そういった枝葉末節のコードの書き方について議論したいわけではなく、「そもそもアーキテクチャの思想の根底に何があるか」が問題なのです。
このことは、ツールやIDEに付随するプロセスなど多岐にわたってその影響を及ぼしています。結果としてJava、J2EEというアーキテクチャは非常に分散開発に向いているオブジェクト指向言語だといえます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
どうやって仕様を分散チームに伝えるか？（要件定義・概要設計から分散開発における詳細設計へ）
要件定義と概要設計（分散したプロジェクトが実装作業を行うためには、設計書の記述精度はどこまで必要か）
本案件のプロジェクト初期に存在したドキュメントは、
- 仕様書……要件定義フェイズでヒアリングされた内容をまとめた文書
- 画面HTML……デザインされたHTMLが先行してユーザーと元請での調整が進行中の状態
- 画面遷移図……画面を並べて線を引いたものが存在
- DB定義書……連携する基幹用に作成しているDB定義書
でした。
どの段階から開発会社に委託するかという問題は常にありますが、通常「作りをお願いする」場合、これぐらいの仕様の精度であることは一般的といえます。よって、通常のプロセスにおいての設計フェイズのインプットとしては普通のレベルでしょう。しかし、本案件では実装が東京と福岡に分散していました。このインプットを福岡のチームに手渡すだけでは、効率の良い実装が行われないことは確実でしょう。
そのため、次の設計フェイズでは、分散した東京と福岡の実装チームに対して、どのように「仕様」を作成し、伝播（でんぱ）させるか、が問題となります。つまり、必須要件といえるのは、
- 顔の見えない実装者に対して、可能な限り効率的に仕様を伝播させること
- スケジュールに影響を与えず、伝播可能な資料を作成すること
- 東京の元請すらまとめ切れていない情報をいかに仕様としてくみ上げるか
といった点です。
（1）仕様書
機能仕様の理解に関して。当初、仕様書の記述は内容的に不十分でした。東京の元請の担当者が福岡のユーザーにヒアリングした内容をドキュメントに落とせていない状態だったのです。そのため、ミーティングによる口頭での伝達を中心に、東京の元請の担当者によってドキュメント化していく作業を並行して行いました。つまり、手元にあったのは暫定版の機能仕様書でした。最終的な機能仕様の確定には3カ月以上もかかっていたので、機能仕様の確定を待たずに開発に入ったことになります。
（2）画面HTML
画面がある程度（HTML化などによって）可視化されている状態というのは、システム構築におけるインプットとして非常に有意義です。画面が可視化されているということは、要件が可視化されていることと同じ意味だといえます。つまり、要件の発散を防ぐ最も有効な手段なのです。ただし、注意しなければいけないのは、BtoCであれ、業務システムであれ、顧客のシステム担当者が検討している「画面」というのは、結局、担当者が注目している機能に限られる場合が多いということです。このことは、「管理上必要な機能」が欠落している場合が多いことを意味します。また、その「重要な機能」を利用するために必要な「間（あいだ）にある画面」（先に検索をしないと顧客情報が入力できなかったり）が欠落している場合が多いということも意味します。
このことはなにも分散開発に限ったことではありません。しかし、東京の元請と東京の開発会社の間でなら「よくある暗黙の了解不足」で片付けられるでしょうが、開発拠点が分散している福岡の開発先にとっては「その都度打ち合わせて決めていく」ことができないため、資料から必要な機能を類推して作成せざるを得ない状況に陥ります。そのためどうしても、「これでいいですか？」というフィードバックが必要になってしまうのです。
スケジュールに余裕がある場合は、プロトタイプなどを作成しながら少しずつ作業を進める方法も可能ですが、スケジュールに迫られている場合、東京の元請と分散開発先（福岡など）の間には必ず実装の分かる組織（会社）を介在させ、「暗黙の了解不足」を補わなければなりません。つまり、実装に関与しない東京の元請から福岡の分散開発先に直接要件を振るのは非常に危険だということです。実装に関与する組織（会社）をかませ、「差分」を吸収することが重要なのです。
（3）画面遷移図
通常、元請から提供される（初期の）画面遷移図は、実装作業を行う上で必要な情報がそろっているとはいい難い状態のものがほとんどです。本プロジェクトも例外ではありませんでした。なので、まずは画面遷移図を詳細化し、システム開発で利用できる状態にする作業から着手しました。
あらかじめ画面HTMLが作成されていたので、発生するイベントを矢印で結合し、システム全体としてどのような遷移になるのかを把握しました。画面遷移図はWeb開発初期において作成される最も基礎的な仕様書の1つです。
この際、重要なポイントは「Webシステムとしての実現可能性」「システムとしての統一性」「再利用性」といった点が挙げられます。多くの場合、顧客が作成し、元請がHTML化しただけの画面と遷移図は、システム的な観点での正規化や実現の困難性が考慮されていません。今回のような分散開発に限らず、画面遷移図は常に作成しておくべき重要な仕様書なのです。
画面遷移図と同じように初期のフェイズで必要な資料に画面設計書があります。今回のプロジェクトでは存在していなかったので、新規に作成することにしました。画面遷移図中の全画面について、1画面ごとにどのような項目で構成されているのかを逐次拾い出し、それらがどのような振る舞いをするのか、また振る舞いの際にいくつの選択肢が存在し、それぞれの場合においてどんな振る舞いが期待されるのかを記述していきました。
初期設計時における設計者の客先常駐の意義
開発初期、東京の開発チームのリーダーでもある設計者が福岡の顧客と東京の元請の意図を把握するため、東京の元請の社内に常駐しました。彼は、文書化されていない仕様を洗い出し、課題の抽出を行いました。並行して、不足しているドキュメントの作成を中心に作業を行いました。ミーティングでの問題点の検討とチーム間の情報共有を重点的に行ったため、ドキュメント作成に取り掛かる前に関係者間で同じ課題認識を持つことができ、概要設計へとスムーズにシフトすることができました。設計者が常駐したことにより、ドキュメント化が間に合わない仕様を東京の元請からそのまま引き継ぎ、仕様書の完成を待たずに設計、開発に着手することができました。
詳細設計（分散開発プロジェクトにおける詳細設計はどこまで行うべきか？）
詳細設計は2カ月目から、段階的に実施していきました。この作業はアーキテクチャ決定やフレームワークの構築と同時進行で行いました。現実的な問題として、概要設計がまだ途中の段階であったこともあり、いつからいつまでが詳細設計の期間なのか明確な区切りはありませんでした。開発着手時にも一部の機能は詳細設計と並行して行っている状況だったのです。
設計と実装の作業が一部重複している期間があったため、機能的なブレが少なそうな個所から開発に着手し始めました。今回、スケジュール的な問題から詳細設計に関しては正式なドキュメント化をあきらめ、簡易的なドキュメント作成にとどめ、機能設計書の記述レベルを詳細にすることにより詳細設計書の代用としました。
開発者が常駐していたこともあり、彼に業務ロジック部分の詳細設計を任せ、開発しながらその都度、東京の元請のシステム担当者に確認を取っていくという方針で進めました。
機能仕様書における記述の不足部分については質疑応答の結果を共有するためのQ＆Aシートを作成し、これをCVS上で管理することで補っていきました。結果的に、東京と福岡の開発者は、開発前に説明を受けたフレームワークに関する情報と各人が担当する範囲の仕様を機能仕様書から読み取りました。それでも情報が不足している場合は、常駐していた東京の開発者から詳細設計情報を聞き出しながら作業することになりました。
以上、ここでのやりとりは、東京と福岡の開発者同士の遠隔コミュニケーション、開発側と福岡の顧客間の遠隔コミュニケーションを中心に解説しました。
Copyright © ITmedia, Inc. All Rights Reserved.