「アーキテクチャ設計の難しさについて」というエントリをしましたが、続きとして「未決定を決定する」という話を。
決定していないことを決める
アーキテクチャは「作り方」を示すものなので作り始める前に決定している必要があります。つまり、アーキテクチャ設計はプロジェクトの最初に行います。ところが、皆さんもご存知の通りプロジェクト開始時点で全ての要件が出ることはありません。要件定義＞基本設計と進んで行き、さらには実装も後半になってからアーキテクチャ上で対応すべき問題が発覚することもあります（後工程で問題が発覚するというのはアジャイルでも同じことです）。
ですから、アーキテクチャ設計では「決定していないことを決める」必要があります。
どう決定していないかを決める
決定していないことの設計方法は「どう決定していないかを決める」ということです。
前回のエントリで「接続先のサーバが決まっていない」という例を出しましたが、これに対して「IPアドレスを設定ファイルに追い出す」というのは「IPが決まっていない」というように決めたことになります。
なので、プロトコルも決まっていないような状態でファイル交換をするのであれば「CSVファイルをtmpに出力して、送信は別プログラムにする」と決めれば良いでしょう。送信処理そのものが丸ごと決まっていない、と決めたのです。
さらにファイルのフォーマットも決まっていないなら...というように「どう未決定であるか」というのを、その時点で得られた情報によって判断していくのです。
もちろん、なるべく分かっていた方が効率的ですから、決めてもらう努力はします。それでも決まらない場合は「どう決まっていないかを決める」というのがアーキテクチャ設計の進め方です。
マネジメントに選択肢を残す
こうした「未決定を決定」が適切になされたアーキテクチャ設計はプロジェクトマネジメントに貢献します。プロジェクトを進める中で未確定な物事は「リスク」と呼ばれます。リスクへの対応策は
- 回避：問題の原因を排除する （その製品を使わない）
- 抑止：問題の発生を抑える手法を用意する （その製品の独自マニュアルを用意する）
- 軽減：問題発生後の影響を抑える （代替製品を用意しておく）
- 移転：問題対応を外部化する （専門会社に管理を委託する）
- 分散：問題発生してもフェイルオーバーできるようにする （別の製品でおなじことをしておく）
というような方法が知られていますが、適切なアーキテクチャはリスク対応に選択肢を残すことができます。
上述の例では接続先サーバとの通信手段が未確定でリスクであった場合、送信部分を分離したようなアーキテクチャにしておけば以下のような選択肢を残せます（他にもあると思いますが）。
- 回避：ファイルを置くだけにして相手サーバから取りに来てもらうようにする（送信しない）
- 抑止：接続先サーバの仮サーバを立てる（仮でも構築する）
- 軽減：別スケジュールで送信機能を作る（決まるまで待つ）
- 移転：データ送受信パッケージ製品を買う（コストは掛かるが接続方式は自由）
- 分散：物理媒体伝送ルートを確保する（別の受け渡し手段でやる）
接続サーバがどうなるか分からない状態でFTPで送信するモジュールをがっつり作ってしまうのは、後の選択肢を減らし、リスクを高める結果になります。もちろん、あえてそういう手段を取って強引に進めるのも技の1つです。
なんにせよ、PMとアーキテクトが協業し、プロジェクトマネジメント上のリスク対応力を高めるのが優れたアーキテクチャの特徴です。
問題を解決してはいけない
この未決定を決定する上で大事なのは「この部分は作らない」という勇気を持つことです。僕は「問題を解決していけない」という表現が好きですが、エンジニアという職種は課題が目の前に現れると、どうしてもそれを解決したくなってしまいます。そして、結果的には「あらゆる可能性に対応できる複雑な解決策」を作ってしまうのです。
上述の例では「サーバとの接続プロトコルすら決まっていないんだ」という話を聞くと「あらゆる通信手段に対応できるコンポーネントを開発する」みたいなことを考えてしまいがちです（僕もですが）。
こういうときに「じゃ、作らないで分離しておこう」という一歩退いた判断が出来るかどうかが大事です。問題を解決せずに先送りしてしまうんですね。
アーキテクチャ設計のポイントは可能な限りシンプルに保つことであり、代替手段のある状況に置くことです。もちろん、固有ドメインの本当に特殊な課題は先送りしても解決されないでしょうが、多くの問題は「未決定の決定」による先送りが良い結果を生むと思います。
まとめ
- アーキテクチャ設計を始める時点では全ての要件は出そろっていない
- だから、不確定な物事については「どう未決定であるか」を決定する必要がある
- これが正しく出来ているとプロジェクトマネジメント上のリスク対応力に貢献する
- 勇気を持って問題をすぐに解決しようとせず、未決定なまま先送りするのが大事
本エントリはプロジェクトの新規開発時点のことばかりですが「カットオーバーされたシステムに起きる変化に適応するアーキテクチャをいかに設計するか」みたいな話は次回に。
