”ちょうど良い事前設計”を位置づける

この記事は、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で、この質問に答えるためのセッションを開催した(スライド)。これは、聴衆にどれぐらいか「行き過ぎた事前設計」であり、どれくらいが「不十分な事前設計」か、彼らの考えを尋ねることで行なわれた。

これらの質問に対する回答の写真はオンラインで見ることができるが、要約すると次のようになる。

どれくらいの事前設計が不十分か? どれくらいの事前設計が行き過ぎか?

  • 何が、そしてどこがシステムの境界かに対する理解の不在
  • チーム内における”全体像”の理解の不在
  • チーム間における”全体像”の共通理解の不在
  • 全体的な展望の伝達ができない
  • やるべきことについて、チームメンバーが明確に理解していない、もしくは満足していない
  • 非機能要件や品質属性に関する考慮がない
  • (実世界の)環境制約が、どのようにソフトウェアに影響を及ぼすかの考慮がない(例. 配置環境)
  • リスクの主要領域、例えば非機能要件や外部インターフェースなどに関する考慮がない
  • 重要な問題 と/または それらへの回答が特定されていない
  • 関心事の分離、適切なレベルの抽象化、階層化、変更容易性、変曲点などに関する考慮がない
  • アーキテクトが果たすべき役割に関する共通理解がない
  • 問題解決への不整合なアプローチ
  • チームへの統制と規約の不在
  • 予測できたはずの、プロジェクトのライフサイクルにおける、アーキテクチャへの重大な変更
  • 多すぎる設計の代替案と選択肢、ソリューションまたは方法に対する、チームメンバーの不賛同
  • 設計がどのように動くかが不確定(設計の一部としてのプロトタイピングが一切実施されていない)
  • 技術選択の欠如(不必要な繰り延べ
  • 多すぎる情報(長い文書 と/または 情報過多)
  • 多すぎる抽象化レベルでの、細かすぎる設計
  • 多すぎる図
  • 文書中に、コードまたは擬似コードを書くこと
  • 硬すぎて柔軟性のないアーキテクチャ
  • 全ての抽象レベルにおいて、全ての決定が行われる
  • 全ての相互作用に対する、クラスレベルでの設計とシーケンス図
  • 詳細なER図とデータベース設計(テーブル、ビュー、ストアド・プロシージャ、インデックス)
  • 分析麻痺と、取るに足らないことに執着するチーム
  • チームにとって退屈でモチベーションを下がるようなコーディング(設計局面の成果物からコードへの単純な変換)
  • 境界のない”設計局面”(時間 と/または 予算において)
  • コーディング無しに到達してしまったデッドライン
どのくらいが”ちょうど良い”のか?

上の回答に共感するのは簡単ではある。ただ、”ちょうど良い”はこれらの両極端の間の、グレーゾーンに位置している。私自身の定義は、専門のアーキテクトがいる場合でも、全員がアーキテクトの場合でも適用できるものであり、以下のようなものだ。

  • あなたのアーキテクチャの重要な要素が、どのように組み合わさっているかを理解すること(つまり、構造 … コンポーネントやそれらの相互作用)
  • 主要なリスクを特定し、軽減することを保証すること(例えば、非機能要件や環境制約など)
  • 確かな基礎を置き、全員が全体の見通しを理解できるようにすること(つまり、”全体像”)



これでさえ単にガイドラインのセットに過ぎない。”どれくらいがちょうど良い事前設計なのか?”という質問は、”場合によりけり”といった種類の回答を要するようなものの一つである。なぜなら、全てのソフトウェアチームは異なるからである。あるチームはより経験があり、あるチームはより助言を必要とし、あるチームは継続して一緒に働き、あるチームは頻繁に交代/変化し、あるソフトウェアシステムは本質的な複雑さを多く持ち・・・などなど。

あなたにとっての”ちょうど良い”を位置づける

実際のところ、”どのくらいがちょうど良い事前設計なのか?”という質問は、あなたによって答えられなければならない。以下は私からのアドバイスである。ソフトウェア・システムのアーキテクティングを練習しなさい。私のカンファレンス・ワークショップや、Software Architecture for Developersトレーニング・コースに参加した人は、この活動を通じて、練習を実践できるだろう。小・中規模の大きさのソフトウェア・プロジェクトを見つけるか作るかして、それを記述するような、ハイレベルな要件(機能・非機能)の、非常に簡潔なドラフトを作りなさい。これは、あなたが関与した、存在するシステムかもしれないし、あなたのドメインに関連しない、新しいものかもしれない。 実施に当たっては、その要件を用いて、2~3人からなる2つ以上のグループに、技術の選択や、構想を伝達するための設計や図を作成することで、ソリューションを考え出すよう頼んでみなさい。活動をタイムボックス化し、オープンなレビューセッションを開催し、以下のような質問を各ソリューションに対してしてみなさい。

  • アーキテクチャは動くだろうか?そうでない場合、なぜだろうか?
  • 全ての主要なリスクは特定されているだろうか?
  • アーキテクチャはシンプルすぎ、または複雑すぎないだろうか?
  • アーキテクチャは効果的に伝達できるだろうか?
  • 人々はそのダイアグラムを好きだろうか?どこを改善できるだろうか?
  • 細かすぎるところはないだろうか?十分に詳細なところはどこだろうか?
  • これをあなたのチームにスタート地点として提示できるだろうか?
  • 統制が利きすぎているところはないだろうか?ガイダンスが十分ではないところはあるだろうか?
  • なされた、もしくは延期された技術的な決定のレベルに満足しているだろうか?

あなたが体験したプロセス、そしてアーキテクチャそのものというよりアウトプットについて焦点を当てたレビューを実施したことを除いて、この練習を”アーキテクチャの型”として考えなさい。あなたの発見を捕らえ、それを今後のアーキテクチャ・プロセスに対するアプローチのガイドラインとして、精製しなさい。 どれくらい詳細まで行うのかについて合意し、例を含め、そして図の標記についても合意し、良い図の例を含めなさい。また、あなた自身の環境における共通的な制約を決定するなどしなさい。もし可能ならば、作成したガイドラインを使用して、それがどのように物事を変えるのかを心に留めながら、もう一度練習を実施してみなさい。私たちはこれを、初回のイテレーションでは助言付きで、2、3回のイテレーションでのSoftware Architecture for Developersトレーニングコースを行っている。訓練は全体で4~7時間程度である。

私が述べたとおり、一つとして同じソフトウェアチームはない。あなたの環境で、この練習を行うための時間を割り当てることは、将来ソフトウェア・アーキテクチャ・プロセスに取り組むための、一貫性のあるスタート地点をあなたに与えるだろう。そして、あなたとあなたのチームにとって、何が正確に”ちょうど良い”事前設計を意味するのかを位置付けるだろう。ソフトウェア・アーキテクチャのプロセスを練習することの追加の利点は、他人がよりアーキテクチャ的に自覚するためのコーチング、またはメンタリングの良い方法にもなるということだろう。 自己組織化チームの人は誰かいるかい?


(翻訳者のコメント)
Big Design Up Frontには、誰もが苦しめられたことがあると思います。このような経験から、アーキテクトを”象牙の塔の住人”とみなし、アーキテクチャや事前の設計を、不要なものと考えてしまう開発者が多いのかもしれません。

しかしながら、前回の記事にもあったとおり、事前設計をせずにシステム開発を行うのは、あまりに極端すぎる揺り戻しだと思います。設計図無しに良い家は建ちません。ある程度の規模のシステム保守を経験したことのある人であれば、いわゆる”Big Picture”や、ある程度の粒度での設計文書が非常に役立つことは、容易に想像できると思います。*2


個々のシステムの特性を判断し、開発から保守までを考慮に入れ、どの程度のアーキテクティング、事前設計を行うべきかを決めること、これがアーキテクトの重要な仕事の一つだと考えています。

*1:原文公開日:2012年1月5日。

*2:逆に、複雑な連携やビジネスルールなどを含むシステムを引継ぐ際に、「特にドキュメントはありません。動くもの(コード)こそが正しいものです。詳しくはコード中のコメントを読んでください。」と言われたらと思うと、ぞっとします。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です