勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

コタツモデル・リローデッド

ソフトウェアさかばさんでコタツモデルが取り上げられていた。コタツモデルは、要求開発で比較的よく持ち出されるメタファーの一種。要求開発は前身がUMLによるビジネスモデリングの研究会であったこともあり、基本的にUML指向・モデリング指向の方法論となっている。しかしこの「コタツモデル」自体は一種独立した発想であって、UMLモデリングとは独立した思考法として成り立っている。あらためて、コタツモデルについて整理してみようと思った次第。

タツモデルとは

タツモデルに関する解説については、2008年に日経ITProに記事を書いていたが、これが一番わかりやすいと思う(そんな記事を書いたことはすっかり忘れていた)。

書籍『要求開発』には書かれていない秘訣がある
 要求開発アライアンスでは、同じような悩みを持つ人々が、ユーザー企業やシステムベンダーの垣根を越えて集まり、月例勉強会や合宿を開催してシステム開発についての悩みを議論しています。「要求はあるものではなく、開発するものである」──このコンセプトに共感する参加者の発表や意見には、刺激的なものが少なくありません。
 要求開発アライアンスの議論の成果は、2006年に『要求開発 価値ある要求を導き出すプロセスとモデリング』(日経BP社 発行)という形で書籍にまとめられました。この書籍には、要求開発を実践するためのプロセス(進め方)とテクニック・手法が詳細に記述されています。本書を参考にすれば、誰でもが要求開発を実現することができるようになったのです。
 しかし、冒頭に述べたように、要求開発・要件定義といったコンセプトを決める工程では、決められた方法や手順を実施するだけで同じように成功するとは限りません。要求開発も、書籍に書かれた通りに実施したからといって、必ず成功するというわけではないのです。
 実は、書籍には書かれていない秘訣が存在しています。今回は、要求開発アライアンスの会員にしか知られていない、プロジェクト成功のための秘訣をご紹介します。この秘訣は要求開発アライアンスの中では「コタツモデル」と呼ばれています。
要求開発とコタツモデル(1)--失敗パターンに陥らないために | 日経クロステック(xTECH)

実はこの記事には元ネタがある。要求開発アライアンスの定例会で発表した以下の資料がそうである。

内輪(?)の勉強会向けの発表だったので笑いを狙いすぎている感もあるが、それまで暗黙知的に語られていた「コタツモデル」を取り上げたので当時はそれなりに好評だったような記憶がある。

タツモデルの派生:スクラムにおける活用

冒頭で紹介したソフトウェアさかばさんの記事でも、スクラムとコタツモデルについて言及されているが、私が知る限りは2011年ころからこのネタも出ていたような気がする。

スライド124ページ(大杉!)あたりから、スクラムにおけるロールモデルとコタツモデルの補完に関する話題が出ていて興味深い。

スクラムの要求に関する弱点
・業務戦略の視点と現場担当の視点の区別がないため、プロダクトオーナーの責務が重すぎる。
スクラムに要求開発を持ち込むことでPOによるROI判断をより明確に行うことができる。
→要求開発モデルを使うことでPOとしての意識付けができる。
要求開発アライアンス定例会スクラム特集

タツモデルの派生:UXにおけるロールモデル・サイクロン

実際に派生したものなのかは確認していないが、類似のものとしてはクラスメソッドさんが提唱している「サイクロン」というものもある。

タツモデルの本質的価値

要求開発アライアンスの最近の勉強会で、萩本理事が「コタツモデルの本質的価値」ということについても触れていた。

以下、個人的な考え。

  • 最近では否定的な見方も多いけれども、いわゆる旧来のエンタープライズ開発における「システム部」「ユーザー部」「ベンダー」という関係性は多様な観点の相互牽制で一つのバランスを取っていたのではないか
  • 特にアジャイル型の開発プロセス適用が増えていく中で、相互牽制するのうな役割分担が無くなることのデメリットはおそらく存在する(スクラムで言えば、プロダクトオーナーの決定への依存度が高すぎる等)
  • これを解決する手段の一つとして、上記のコタツモデルのような考え方の再考が必要なのではないか

このあたりを、もうすこし時間をかけて考えてみたい(しかし、時間が無いという罠)