コタツモデル・アンチパターンズ(1)

■はじめに
2008年3月の要求開発アライアンス定例会で「コタツモデル再考」という発表をしたのですが、予想外に好評だったので調子に乗って、発表内容をベースに「コタツモデル・アンチパターンズ」という標題で詳しい内容を書いてみようと思います。週1回ペースくらいで書いていこうと思いますので、興味のある方はRSSリーダ等に当ブログを登録お願いします。

■コタツモデル
システム開発プロジェクトは沢山の人によって進められます。特にシステムそのものの目的や方向性そして仕様を決めるプロセスは重要で、ここで失敗するとシステム開発プロジェクト自体が失敗するといっても過言ではありません(実際に、システム開発プロジェクトの7割は失敗しているという調査もあります)。

失敗する要因には様々なものがありますが、特に次の3種類のプロジェクト参加者が、システムの目的や方向性について合意形成していることがプロジェクトを失敗させない為には重要です。

• ビジネスオーナー (ビジネスの方向性や方針を決めるが、システム開発や現場業務には詳しくない)
• 現場担当者 (実際に業務を担当している現場担当者)
• システム担当者 (システム部門の担当者または開発ベンダ)

この３者が「コタツに一緒に入るように」ひとつのテーブルで議論を行い合意形成することを、コタツモデルと呼んでいます。

ソフトウェアはコミュニケーションで出来ている

とはチェンジビジョンの平鍋さんの言葉ですが、特にシステムの目的や方向性の決定、要件定義について、コタツモデルを形成することが、システム開発の成功確率を高める一つのポイントではないでしょうか。

■コタツモデルとアンチパターン

ソフトウェア開発において「こうあるべきだ」という典型例を集めたものデザインパターンであるのに対し、「こうあってはならない」という典型例を集めたテンプレート集がアンチパターン。
はてなダイアリー：アンチパターンとは

デザインパターンと言うと、設計やプログラムコードのお手本として捉えられることが多いのですが、これに対してアンチパターンは組織やプロジェクトマネジメントまで非常に幅広く取扱うことができます。書籍「アンチパターン -ソフトウェア既得患者の救出-」や、Wikipedia(英)のAnti-Patternには様々なレベルのアンチパターンが言及されています。

さて、コタツモデルは人間関係のメタファーであるため、次のような難しさがあります。

• 容易に修正したり、制御することは出来ない
• コタツモデルではない事はすぐにわかるが、簡単には是正できない
• 対症療法をとるしかない。

コタツモデルのようなアンコントローラブルな問題に対しては、HOWTOを語る事は困難です。しかし、アンチパターンのように「こうあってはならない」典型を示し、改善のためのアイデアを提示することは可能だと考えています。

■コタツモデルの良いところ
要求開発では、そもそも「要求はあるものではなく，開発するものである」という前提をおいています。過去のシステム開発プロジェクトの焦点は電子化や自動化が多く、既存の業務の仕組みを調査分析をすることでシステムの目的や仕様を決定することができました。しかし現在においては、システム化の対象範囲は広がり、人間系とシステム系が複雑に入り組み混在化したビジネス系そのものを扱う事もしばしあります。こういったシステムの要求は調査分析をしても見つけることはできず、プロジェクトメンバーによって検討(開発)しなければならない、ということです。

限られた期間、限られたメンバーで要求を検討(開発)する際に重要となるのはバランスです。

• 視野のバランス ・・・ 複数の視点から見て、合理的かつ効果的な検討を行うため
• 権威のバランス ・・・ 特定の発案者の意見に従うのではなく、参加者がフラットに意見交換を行う為

えてしてシステム開発においては、「発注者 vs 受注者」「要求を出す人 vs 作る人」といった形の上下関係になりがちで、これが原因で前向きな議論や関係が築きにくい。また、仕様を決めるユーザも人間ですから間違えることもあるわけで、そこから端を発した仕様変更の泥沼なども、権威のバランスを欠いた結果なのではないでしょうか。

コタツモデルでは、ここで(実現可能かは別にして)ビジネスオーナー、現場担当者、システム担当者が対等な立場で議論を行い合意する関係性を提示しています。これは、単なる絵的なもの以上の価値があるのではないか、と考える今日この頃です。

長くなってしまいましたが、次回からはさっそくアンチパターンについて紹介していきたいと思います。興味のある方は引続きおつきあいくださいませ。