[#TiDD] 分類と制約から自律・協調へ #xpjugkansai #devsumi: ソフトウェアさかば

アジャイル開発ブームに見られる様に、ソフトウェア開発の世界は大きく変わろうとしています。このような変化はソフトウェア開発だけではなく、複雑化する中でコミュニケーションが発達した社会全体の大きな流れです。人を律して管理するのではなく、尊重して助け合う事で個々の能力を活かす社会に変わりつつあります。

ソフトウェア開発技術のふりかえり

ソフトウェア工学の歴史は制約から始まりました。まず、初期のプログラミング言語には制御構造のパターンがなく、自由度が高過ぎたので、スペゲッティプログラムが蔓延しました。

そこで、ダイクストラ先生が混乱を導き易いGOTO文がなくてもプログラムが書ける事を論理的に示したことから、構造化プログラミングが始まりました。プログラミングに制約を加える事で、ロジックの分割統治を図ったのです。

分割統治の考え方は設計にも利用され構造化設計・分析になりました。それはトップダウンに機能で分割してしたが、共通化がうまくいかないという問題がありました。そこで、データやデータの流れに注目してボトムアップに共通化する方法と組み合わせて実現される様になりました。

しかし、この方法にもいくつかの問題がありました。ソフトウェアが階層構造を持つ場合、一つのモジュールの下位モジュールとの情報のやり取り（ファンアウトおよびファンイン）を一定に押さえないと理解が容易なプログラムにならない事です。

全体をピラミッドのようなきれいな構造にすると、理解が容易になるので実装や不具合の修正が容易になります。その反面、上位のモジュールに修正が必要となる仕様変更が発生した場合、大規模な改修が必要となりました。

そこで、システム全体を一つの大きな構造にするのではなく、独立したオブジェクトが連携する構造が主流になりました。

組織構造のふりかえり

組織構造にも同じような歴史がありました。会社が大きくなるに従って仕事はルールに従って実施するものとなり、機能的に分割された階層的な組織が作られました。しかし、1980年代の経済誌には「ピラミッド型組織からネットワーク組織へ」といった記事が書かれていました。

そこでは、巨大なピラミッド組織では社会の変化についていけないからと、上層部の意思がすぐに伝わるネットワーク構造が良いとされました。しかし、単純に高さの低いピラミッドにしただけでは、中間層の負担が大変でした。

そこで、事業部にはじまって、やがて部門ごとに独立採算制度を取って、それぞれの部門が決定を行う様になりました。独自にビジネスの実践が容易な様に、営業部門が単独ではなく、事業部や各部門の中にある所も多い様です。

ソフトウェアプロセスの振り返り

ソフトウェアプロセスも同じような進化をしました。プロジェクトは外科医チームと呼ばれる執刀医にあたるリーダーを中心に実施されていました（実際の外科医はこのようなものではないそうです）。

スーパーエンジニアに依存する方法は、時にして大成功をおさめました。しかし、ソフトウェアの規模が大きくなるに従って、個人の個人に依存した失敗が増えました。そこで、全体を機能ごとに工程に分けて、確認作業や管理作業が加えられました。

しかし、機能的に工程分割したので変化への対応が難しくなり、独立した単位で実装を繰り返す様になりました。

共通の方向へ

このように、ソフトウェア開発技術、組織構造、ソフトウェアプロセスは、ピラミッドや管理から自律・協調へと向かっています。これらの流れを読み解くには、細胞をモチーフにしたと言われるオブジェクト指向が参考になるかもしれません。

オブジェクト指向では、オブジェクトをカプセル化して外乱を避け、責務を実施し、それらが協調して、全体が構成されます。そのように考えると、以下のようなものも同じ流れであると思えます。

このような視点で見ると、別の世界が現れるかもしれません。もちろん、これは一方向のものではなく、機能指向とデータ指向のように振り子の様な揺り戻しもあると思われます。

アジャイル開発やチケット駆動開発もこのような流れで見直すと、単にプラクティスを実践するだけでは得られないさらに多くの効果が得られるでしょう。

【告知】
2013年4月27日（土）に開催されるXP祭り関西2013で上記の流れを踏まえて
「能力を活かすアジャイルの風～規律から自律＋協調へ～」
と題して基調講演します。ぜひお越し下さい。

ソフトウェアさかば