asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ソフトウェアデザインの理論:組織構造と意思決定プロセス

この記事では、ソフトウェア開発における組織の構造が、ソフトウェアデザインにおける意思決定プロセスに与える影響を考察します。

デザインプロセスの側面

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が共同して最終的な決定を行わない、ということです。

ソフトウェア開発における組織構造

ここでは、組織構造とは、意思決定者とその間の関係からなる構造です。関係は、意思決定の権限がどちらが強いのか、ということに着目します。意思決定の権限の強さは、開発チームでの上司・部下の関係で決まると仮定します。

org_design.png

ここで、意思決定の権限の強さは、技術的な能力で決まるのではないと仮定していることに注意してください。意志結果が得られる過程には次がありえます。

(1) 部下にとって技術的に適切だと思われる意思決定が、上司に受け入れられる。

(2) 部下にとって技術的に適切だと思われる意思決定が、上司に受け入れられない。

ただし、ここでは、デザインは、個人的な経験や知識によって行われるため、「技術的に適切」というのが実際に「技術的に適切」かどうかの判断は難しいとします。

また、意思決定は、「技術的に適切」かどうかだけでなく、スケジュールやコストといった開発状況の考慮も必要です。そのため、そのような考慮が欠けている部下の意思決定を、上司が受け入れないというのは現実的です。

まとめ

ソフトウェア開発での組織構造が意思決定に影響を与えるとするなら、ソフトウェア開発での最終的な成果物であるコードorプログラム構造を技術的に適切な観点からアウトプットするのは難しいということを議論しました。

今後調査したいと思っているのは、オープンソースソフトウェア開発の組織構造での意思決定プロセスとの比較です。

参考文献
[1]
J. S. Gero, Design prototypes: a knowledge representation schema for design, AI Magazine, 11(4): 26-36, (1990).
スポンサーサイト

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。