はじめに
この記事では、ソフトウェア開発における組織の構造が、ソフトウェアデザインにおける意思決定プロセスに与える影響を考察します。
John Gero さんによれば、工学におけるデザインのプロセスには、以下の側面があります[1]。
goal-oriented, constrained, decision-making, exploration and learning activity which operates within a context, which depends on the designer's perception of the context.
- (1) ゴール指向
- (2) 制約がある
- (3) 意思決定
- (4) 探索
- (5) 学習
この記事では、ソフトウェアデザインでの「意思決定」の側面に着目します。
ソフトウェアデザインにおける意思決定
ソフトウェアデザインでの意思決定とは、ここでは、プログラム構造に影響を与える以下の決定であるとします。
- (1) 抽象度の高いレベル。アーキテクチャスタイル（もしくはデザインパターン）の選択に関わる決定など。
- (2) 抽象度の低いレベル。プログラムの変数の名前付けに関わる決定など。
次に、どのような状況で意思決定を行うのかについては考えます。状況の一つは、意思決定者の数です。
- (a) 一人の開発者が意思決定を行う。
- (b) 二人以上の開発者が意思決定を行う。
通常、ソフトウェア開発ではbの状況ですので、この記事ではbの場合を考察します。
次の状況は、意思決定者の間の関係です。
- (i) ある意思決定者の決定は、他の意思決定者の影響を受けない。
- (ii) ある意思決定者の決定は、他の意思決定者の影響を受ける。
iで言いたいことは、ある決定されたことAとBとが依存していないというわけでなく、意思決定が必要なことについて、意思決定者XとYが共同して最終的な決定を行わない、ということです。
ソフトウェア開発における組織構造
ここで、意思決定の権限の強さは、技術的な能力で決まるのではないと仮定します。意志結果が得られる過程には次が考えられます。
- (1) 権限が低いものにとって（部下）技術的に適切だと思われる意思決定が、権限が高いもの（上司）に受け入れられる。
- (2) 権限が低いものにとって（部下）にとって技術的に適切だと思われる意思決定が、権限が高いもの（上司）に受け入れられない。
ただし、ここでは、デザインは、個人的な経験や知識によって行われるため、「技術的に適切」というのが実際に「技術的に適切」かどうかの判断は難しいとします。
また、意思決定は、「技術的に適切」かどうかだけでなく、スケジュールやコストといった開発状況の考慮も必要です。そのため、そのような考慮が欠けている部下の意思決定を、上司が受け入れないというのは現実的です。
まとめと課題
この記事では、ソフトウェア開発での組織構造が意思決定に影響を与えるとするなら、ソフトウェア開発での最終的な成果物である「コード」もしくは「プログラム構造」を技術的に適切な観点からアウトプットするのは難しいということを議論しました。
今後調査したいと思っているのは、オープンソースソフトウェア開発の組織構造での意思決定プロセスとの比較です。
参考文献
[1] J. S. Gero, Design prototypes: a knowledge representation schema for design, AI Magazine, 11(4): 26-36, (1990).