未決定を決定する - アーキテクトの考え方 - arclamp

「アーキテクチャ設計の難しさについて」というエントリをしましたが、続きとして「未決定を決定する」という話を。 決定していないことを決める アーキテクチャは「作り方」を示すものなので作り始める前に決定している必要があります。つまり、アーキテクチャ設計はプロジェクトの最初に行います。ところが、皆さんもご存知の通りプロジェクト開始時点で全ての要件が出ることはありません。要件定義＞基本設計と進んで行き、さらには実装も後半になってからアーキテクチャ上で対応すべき問題が発覚することもあります（後工程で問題が発覚するというのはアジャイルでも同じことです）。 ですから、アーキテクチャ設計では「決定していないことを決める」必要があります。 どう決定していないかを決める 決定していないことの設計方法は「どう決定していないかを決める」ということです。 前回のエントリで「接続先のサーバが決まっていない」という例を

[northlight]

「この部分は作らない」という勇気を持つこと

[SHAKARIKI]

良記事。 ポイントは、システムの構造は「変に複雑化せず、なるだけシンプルにすること。」 それにより、構築後に起こりうるであろう要件追加、変更に対して 臨機な対応が可能となる。このメリットは大きい。

[nyop]

未決定であることをきちんと管理出来てなかったり、決めないという決定のレベルが粗すぎると、結局後工程で死にそうになるっていう。

[kaji_3]

「あらゆる可能性に対応できる複雑な解決策」は陥りがちだなぁ。

[namisk]

つい目の前の未決を片付けてしまいたくなるけど、先送りで綺麗に収まるケースも、きっと少なからずあるはず。

[terazzo]

「早すぎる最適化は諸悪の根源」の設計版という感じ

[hirsato]

アーキテクチャ設計を始める時点では全ての要件は出そろっていない だから、不確定な物事については「どう未決定であるか」を決定する必要がある これが正しく出来ているとプロジェクトマネジメント上のリスク対応力

[ohnishiakira]

"問題を解決してはいけない"

[kimutansk]

「プロトコルが決まっていない」なら生データを吐いておいて先送りなど、未決定の個所を切り出して基本をシンプルに保つのがポイント、ですか。

[usadamasa]

"アーキテクチャ設計のポイントは可能な限りシンプルに保つことであり、代替手段のある状況に置くことです。"