この記事は、Simon Brown氏による、”Contextualising just enough up front design”を、ご本人の許可を得て翻訳したものです。*1
This article is translated from ”Contextualising just enough up front design” written by Mr. Simon Brown, with his permission.
”ちょうど良い事前設計”とは、具体的に何を意味するのか？
ウォーターフォールによるソフトウェア開発からの脱出という流れの中、どれくらいの事前設計を行うべきであるかという問いは、ソフトウェアチームにとって一般的なものである。”ちょうど良いくらい”というのは良いスタート地点かもしれないが、それは正確には何を意味しているのだろうか？
不十分 対 行き過ぎ
私はロンドンにおけるSoftware Architect 2011 conferenceで、この質問に答えるためのセッションを開催した（スライド）。これは、聴衆にどれぐらいか「行き過ぎた事前設計」であり、どれくらいが「不十分な事前設計」か、彼らの考えを尋ねることで行なわれた。
これらの質問に対する回答の写真はオンラインで見ることができるが、要約すると次のようになる。
| どれくらいの事前設計が不十分か？ | どれくらいの事前設計が行き過ぎか？ |
|---|---|
|
|
どのくらいが”ちょうど良い”のか？
上の回答に共感するのは簡単ではある。ただ、”ちょうど良い”はこれらの両極端の間の、グレーゾーンに位置している。私自身の定義は、専門のアーキテクトがいる場合でも、全員がアーキテクトの場合でも適用できるものであり、以下のようなものだ。
- あなたのアーキテクチャの重要な要素が、どのように組み合わさっているかを理解すること（つまり、構造 … コンポーネントやそれらの相互作用）
- 主要なリスクを特定し、軽減することを保証すること（例えば、非機能要件や環境制約など）
- 確かな基礎を置き、全員が全体の見通しを理解できるようにすること（つまり、”全体像”）
これでさえ単にガイドラインのセットに過ぎない。”どれくらいがちょうど良い事前設計なのか？”という質問は、”場合によりけり”といった種類の回答を要するようなものの一つである。なぜなら、全てのソフトウェアチームは異なるからである。あるチームはより経験があり、あるチームはより助言を必要とし、あるチームは継続して一緒に働き、あるチームは頻繁に交代／変化し、あるソフトウェアシステムは本質的な複雑さを多く持ち・・・などなど。
あなたにとっての”ちょうど良い”を位置づける
実際のところ、”どのくらいがちょうど良い事前設計なのか？”という質問は、あなたによって答えられなければならない。以下は私からのアドバイスである。ソフトウェア・システムのアーキテクティングを練習しなさい。私のカンファレンス・ワークショップや、Software Architecture for Developersトレーニング・コースに参加した人は、この活動を通じて、練習を実践できるだろう。小・中規模の大きさのソフトウェア・プロジェクトを見つけるか作るかして、それを記述するような、ハイレベルな要件（機能・非機能）の、非常に簡潔なドラフトを作りなさい。これは、あなたが関与した、存在するシステムかもしれないし、あなたのドメインに関連しない、新しいものかもしれない。 実施に当たっては、その要件を用いて、2～3人からなる2つ以上のグループに、技術の選択や、構想を伝達するための設計や図を作成することで、ソリューションを考え出すよう頼んでみなさい。活動をタイムボックス化し、オープンなレビューセッションを開催し、以下のような質問を各ソリューションに対してしてみなさい。
- アーキテクチャは動くだろうか？そうでない場合、なぜだろうか？
- 全ての主要なリスクは特定されているだろうか？
- アーキテクチャはシンプルすぎ、または複雑すぎないだろうか？
- アーキテクチャは効果的に伝達できるだろうか？
- 人々はそのダイアグラムを好きだろうか？どこを改善できるだろうか？
- 細かすぎるところはないだろうか？十分に詳細なところはどこだろうか？
- これをあなたのチームにスタート地点として提示できるだろうか？
- 統制が利きすぎているところはないだろうか？ガイダンスが十分ではないところはあるだろうか？
- なされた、もしくは延期された技術的な決定のレベルに満足しているだろうか？
あなたが体験したプロセス、そしてアーキテクチャそのものというよりアウトプットについて焦点を当てたレビューを実施したことを除いて、この練習を”アーキテクチャの型”として考えなさい。あなたの発見を捕らえ、それを今後のアーキテクチャ・プロセスに対するアプローチのガイドラインとして、精製しなさい。 どれくらい詳細まで行うのかについて合意し、例を含め、そして図の標記についても合意し、良い図の例を含めなさい。また、あなた自身の環境における共通的な制約を決定するなどしなさい。もし可能ならば、作成したガイドラインを使用して、それがどのように物事を変えるのかを心に留めながら、もう一度練習を実施してみなさい。私たちはこれを、初回のイテレーションでは助言付きで、2、3回のイテレーションでのSoftware Architecture for Developersトレーニングコースを行っている。訓練は全体で4～7時間程度である。
私が述べたとおり、一つとして同じソフトウェアチームはない。あなたの環境で、この練習を行うための時間を割り当てることは、将来ソフトウェア・アーキテクチャ・プロセスに取り組むための、一貫性のあるスタート地点をあなたに与えるだろう。そして、あなたとあなたのチームにとって、何が正確に”ちょうど良い”事前設計を意味するのかを位置付けるだろう。ソフトウェア・アーキテクチャのプロセスを練習することの追加の利点は、他人がよりアーキテクチャ的に自覚するためのコーチング、またはメンタリングの良い方法にもなるということだろう。 自己組織化チームの人は誰かいるかい？
（翻訳者のコメント）
Big Design Up Frontには、誰もが苦しめられたことがあると思います。このような経験から、アーキテクトを”象牙の塔の住人”とみなし、アーキテクチャや事前の設計を、不要なものと考えてしまう開発者が多いのかもしれません。
しかしながら、前回の記事にもあったとおり、事前設計をせずにシステム開発を行うのは、あまりに極端すぎる揺り戻しだと思います。設計図無しに良い家は建ちません。ある程度の規模のシステム保守を経験したことのある人であれば、いわゆる”Big Picture”や、ある程度の粒度での設計文書が非常に役立つことは、容易に想像できると思います。*2
個々のシステムの特性を判断し、開発から保守までを考慮に入れ、どの程度のアーキテクティング、事前設計を行うべきかを決めること、これがアーキテクトの重要な仕事の一つだと考えています。
