読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

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

要求開発のホームグラウンドについての考察

要求開発はソフトウェア開発の企画・要件定義向けの方法論ということになっている。しかしわたしはこれが適用できる領域は限られていると考えている(詳細はこちらのエントリを参照)。では、要求開発が適用できる分野はどこか。

要求開発のおさらい

本論に入る前に、いくつか要求開発のエッセンスをさらっておく。詳しくは以下の書籍やサイトも参考に。

要求開発のことを一言で言うと「企業の経営者・業務担当者・システム部の3者で、後のソフトウェア開発の結果が予想出来るくらいまでイメージをすり合わせて合意する(工程)」になる。逆にいえばイメージが合意できていないとソフトウェア開発はうまくいかないということだ。要求開発のコンセプト資料は公開されているのでそこから抜粋すると、要求開発が念頭に置いている失敗パターンがわかる。

たとえばトップダウンで強力に推進して失敗するパターン。大きめの流行りのパッケージソフトウェアやバズワード的なものが目に浮かぶイメージ。f:id:kent4989:20120409155017j:plain

逆に現場に擦り寄ったシステム開発をして現状最適に過ぎて、目的を達成できないパターン。経営レビューあたりでちゃぶ台をひっくり返されそう。f:id:kent4989:20120409155036j:plain

このような失敗を避けようというのが要求開発の狙いの一つで、経営・現場・開発の三位一体で取り組むことを「要求を開発する」といっているのである。f:id:kent4989:20120409155047j:plain

もう一つあわせて紹介したいのが次のスライド。
f:id:kent4989:20120409155114j:plain
なぜわざわざ「要求を開発する」必要があるのかというと、ベンダーに相対するシステム部の担当者も、すべてが見通せているわけではない。ステークホルダー各人の頭の中にあるシステム像は違っていることがしばしなのである。だからこそ、三位一体でシステム像を改めて可視化することが重要なのである。

ここまで読んで「なるほどそうだ」と思えるのか、「そこまではやらなくても」と感じるか。人それぞれだと思う。それは、要求開発が念頭に置いている前提と読者の環境がどこまで近いかによって変わってくるのではないか。

要求開発のホームグラウンド

要求開発が念頭に置いているものは以下の点だと思っている。

  • 複雑度が高いエンタープライズ系のシステム
  • (人系を含む)ビジネスシステムのリプレース
  • 対象企業の規模は大きめ

複雑度が高いエンタープライズ系のシステム

対象システムの複雑度はまず高いものを念頭に置いているのは良いだろうと思う。そもそも要求開発という工程を追加して構築するソフトウェアを可視化することが必要な複雑度が無いと、要求開発する必然性があらわれない。多部門や多システムと連携しつつ利害関係を調整や合意形成をするといった局面が必要でないなら、あまり要求開発の用は無いような気がする。

要求開発の構想の背景のひとつに、大規模システムの要件定義〜設計フェーズを人海戦術・御用聞き型で突入していく(当時の)大手SIerのイメージがある。大量にドキュメントを作成したあとにコンセプトレベルの見落としや誤りによる手戻りが発生することを、前工程でコンパクトに対策するというのが要求開発の内なる狙いなのではないだろうか。

(人系を含む)ビジネスシステムのリプレース

基本的に想定されているのは既存システムまたは業務のシステム化(ここで言うシステムはITシステムに限定した話ではなく、ヒト・システム混合の業務システム)である。なぜなら企業内にまったくノウハウの無い新規ビジネスであれば、関係者でそもそも『要求を開発』できない。
f:id:kent4989:20120409155132j:plain
例えばマス顧客向けのWebサービスを開発するのであれば、組織内の利害関係者間で『要求を開発』することよりも、素早くシステムをリリースして少しずつ改善するといったアプローチのほうが適しているだろう。スタート時点のゴールイメージを共有するために要求開発的な手法を一部適用するなどの工夫は可能かもしれないが、『要求を開発』するといったイメージとは少し異なるのではないか。

対象企業の規模は大きめ

要求開発は、ソフトウェア開発のための要件定義工程を手厚くする(もしくは要件定義の前工程を行う)ということになる。当初の発想では『ビジネスコンサルとベンダーの間の領域を埋める』もあり、やはり(最近はあまり聞かないような気もするが)ビジネスコンサルを活用するような対象希望にフィットするイメージがある。
f:id:kent4989:20120409155144j:plain
また複雑度のところで述べたことと重複するが、多部門や多システムと連携しつつ利害関係を調整や合意形成をするような状況が無いのであれば、要求開発の用は無いのだと思う。

要求開発の出自などを踏まえて、改めて要求開発のホームグラウンドについて考えてみたが、やはり適用範囲については限定的であると考えている(こんな事を書くと諸氏から厳しいご意見もいただきそうだが)。もちろん、要求開発に含まれる各種のプラクティスや原則にもそれぞれ特徴やメリットも大きく、それを個別にプロジェクトに活用するといった話は充分にあると思う。しかし、トータルパッケージの「要求開発」を導入するかについては、手法ありきではなくプロジェクトのホームグラウンドがどこにあるのかという点について充分に考察する必要があると思う。

参考

要求開発~価値ある要求を導き出すプロセスとモデリング

要求開発~価値ある要求を導き出すプロセスとモデリング

  • 作者: 山岸耕二,安井昌男,萩本順三,河野正幸,野田伊佐夫,平鍋健児,細川努,依田智夫,[要求開発アライアンス]
  • 出版社/メーカー: 日経BP
  • 発売日: 2006/03/02
  • メディア: 単行本
  • クリック: 13回
  • この商品を含むブログ (18件) を見る