ObectSquare [2010 年 1 月号]

[技術講座]


アーキテクト解体ショー(前編)

株式会社オージス総研
山内 亨和

 

1. はじめに

アーキテクト解体ショーとはアーキテクトの頭の中で行われている設計プロセスを解体して見える化し、設計プロセス自体やノウハウの共有などに役立てるための手法です。

本稿は前後編に分けてアーキテクト解体ショーを紹介します。
前編ではアーキテクト解体ショーの基本概念や表記法、単純な事例、利用場面を解説します。
後編では複雑な事例を用いて表記法を掘り下げて解説し、またアーキテクト解体ショーの様々な Tips を紹介します。

2. アーキテクト解体ショーの基本概念

アーキテクチャ設計には、(1) 仮説としてアーキテクチャを設計し、(2) プロジェクトの要求と制約に照らし合わせて、(3) 仮説のアーキテクチャを採用するか否か判断を下す、というプロセスがあると仮定し、アーキテクト解体ショーではこのプロセスに合わせ「設計(結果)」「要求と制約」「設計判断」を見える化します。

3. 用語の定義

「設計」「要求と制約」「設計判断」の用語を以下のように定義します。

「設計」とは「システムをこうやって作るよという宣言」とします。例を挙げれば「 OR マッピングのために Hibernate を利用する」ということが「設計」に当たります。

「要求と制約」とは「システム/プロジェクト/ビジネスの要求と制約」とします。例を挙げれば「 RDB の採用が決まっている」「 Java の採用が決まっている」「すぐに開発に着手したい」などが「要求と制約」に当たります。

「設計判断」とは「その設計を採用した理由(採用しなかった理由)」とします。例を挙げれば「開発者に利用経験がある OR マッピングフレームワークを採用したい」が「設計判断」となります。

なお、「要求と制約」に「システム」の要求と制約だけでなく「プロジェクト」や「ビジネス」も要求と制約に含めている点には注意が必要です。
アーキテクチャ設計では体制やスケジュールや予算等のプロジェクトの制約も考慮しなければいけません。
また、システムは要求どおりに完成し、プロジェクトも要求どおりに完了しても、顧客のビジネス(または SIer のビジネス)に悪影響を及ぼすアーキテクチャではいけません。システムやプロジェクトの背景となっている顧客や自社のビジネスも気にかけるべきです。

4. 表記法(基本)

図 1 で示す表記法で、アーキテクトの頭の中にある「設計」「要求と制約」「設計判断」を見える化します。

図 1 : 表記法

5. アーキテクト解体ショーの実演

コマンドラインプログラムを例に、アーキテクト解体ショーの大まかな流れを実演します(サンプルコードはありません)。

例とするコマンドラインプログラムは、コマンドライン引数をとるプログラムで、引数に指定された値に応じてプログラムの動作が変わります。

まず、採用した「設計」を赤い四角形で書き出します(図 2 )。今回の例では「引数の利用」が「設計」となります。

図 2 : 採用した設計候補を書き出す

次に、他に候補となった「設計」を書き出します(図 3 )。今回の例では「設定ファイルの利用」「環境変数の利用」が設計候補にありました。

図 3 : 他の設計候補を書き出す

次に、複数の設計候補の中から一つを採用した理由、他を不採用とした理由を「設計判断」として書き出します。(図 4 )
今回の例では「ユーザーが簡単に利用できる」「余計な設定ファイルを利用しない方がいい」「ユーザーに環境変数などの余計な設定を強いない方がいい」という「設計判断」がありました。

図 4 : 設計判断を書き出す

ここで、どんな「要求と制約」を考慮して「設計判断」を下したのかを思い返します(図 5 )。
この時点で思い出すのは「ユーザーの要求に応じてプログラムの動作を変える」だけだったとします。残念ながら、この要求だけでは 3 つの設計から 1 つを選んだ説明にはなっていません。

図 5 : 要求と制約を思い出す

このようなことはアーキテクチャ設計においてよくあります。アーキテクトは直感や経験から最適と思われる設計を見つけられるのです。しかし、その選択が常に正しいとは限りません。

もしアーキテクト解体ショーが、見える化するためだけの手法であれば、ここで作業は終わりです。アーキテクトの頭の中は見える化できました。アーキテクトは直感で判断したと分かったのですから。

しかし前述したとおり、アーキテクト解体ショーは設計プロセス自体に役立てるための手法でもあります。ここで手を止めるのではなく、より適切な設計判断を下すために深く考えます。

「余計な設定ファイルを利用しない方がいい」のはなぜでしょうか。実行ファイル以外のファイルを利用するとインストールが複雑になるからです。
「ユーザーに環境変数などの余計な設定を強いない方がいい」のはなぜでしょうか。環境変数の設定などプログラム起動前の事前準備をユーザーに課さない方がユーザビリティが高いからです。

このように「設計判断」がクリアになったら、図を更新します(図 6 )。

図 6 : 設計判断を深く考える

ここまで「設計判断」を考え抜けば、隠れていたもう一つの「要求と制約」、「できればプログラムのインストールを簡単にしたい」が見つかります(図 7 )。

アーキテクトが直感で考慮していた「要求と制約」はいわゆる「インストーラビリティ」だったのです。

図 7 : 隠れていた「要求と制約」が見つかる

6. アーキテクト解体ショーの利用場面

アーキテクト解体ショーの利用場面には、「アーキテクチャ設計」「アーキテクチャ設計レビュー」「後続工程への引き継ぎ(伝承)」「ノウハウの共有」があります。

6.1. アーキテクチャ設計

実演でも示したように、アーキテクチャ解体ショーによって、設計判断なき根拠のない設計に気付くことができたり、思い込みによる無理のある設計判断に気付くことができたりします。また、採用した設計以外の候補を洗いなおすことで、設計の違う可能性を模索することにもつながります。

6.3. アーキテクチャ設計レビュー

基本的にはアーキテクチャ設計と同じ効果がありますが、見える化できることで第三者からも有益な指摘を得ることができます。

6.3. 後続工程への引き継ぎ(伝承)

従来ならアーキテクチャドキュメント等でアーキテクチャの設計情報だけを引き継いでいたところ、アーキテクト解体ショーにより設計判断も伝承できるようになりました。設計判断を伝承することで、アーキテクチャを劣化させるような設計・実装を回避しやすくなります。
なお、後続工程とは詳細設計や実装だけでなく、開発の後に控えている保守も含んでいます。システムの寿命の限り設計判断が受け継がれていくことを重視し、「伝承」という言葉を使っています。

6.4. ノウハウの共有

アーキテクト解体ショーにより、設計だけでなく設計判断もノウハウとして共有できるようになります。
また設計ノウハウの活用自体も一層進みます。設計ノウハウだけが共有されている頃はそのノウハウが自分のプロジェクトにも当てはまるのか判断しづらかったけれども、設計判断が見える化されることで判断が容易になるからです。

 


© 2010 Michitaka Yamauchi
Index
Index