要求開発超入門

システム開発者は、「システム開発」という牢屋に入っていることに気がついていないのではないでしょうか？
しかもたちが悪いことに、牢に入っていることに気がつかないだけでなく、そこが快適だと勘違いしている。そして牢屋の中から、「シャバの世界」にいるユーザーに向かって要求クレ～と叫んでいるのです。
ユーザーには、その牢屋は見えていません。だから、開発者から要求クレ～と叫ばれても、どうしてこちらに来て要求を一緒に考えることをしてくれないのか？と思われるのです。「要求に対する提案がなぜ開発側から的確にでないの？」と思われているのです。

図1 要求クレ～

図2を見てください。
これは僕が要求開発の全体像を説明するためによく使っている図です。
この図では、システム開発者の居住地域は図中の下方です。ここにとどまって要求定義をしています。しかし、要求の根拠（What）は業務オペレーションにあります。
業務オペレーションとは、業務を実施するためのオペレーションのことです。ここで必要とされるITシステムの要求が出るわけです。すなわち、システム開発という牢屋を出てToBeの業務オペレーションを見えるようにして、そこから要求を出さなければならないはずです。しかし、現状ほとんどのシステム開発者は、牢の中で過しているかのごとく、この図の下方に留まっているのです。

図2 要求はHowでもある

「Vol.2 うまくいかない要求定義」の最後で説明したように、システム化した後の結果イメージがもっと早い段階で予測できれば、それに対する変更やチューニングが容易になるのです。
最近のビジネスでは、ITによりビジネス価値が拡大することが多くあります。そのほとんどの現象として、目的自体（要求）が価値を持つのではなく、目的（要求）の手段（IT化方式）によって価値が決まることが多いのです。また、手段のチューニングこそが価値をもたらしていると僕は思っています。
みなさんも、この事をよく考えると、なるほどと思っていただけるでしょう。
そうです、手段のチューニングとは、ITのユーザー利用のための実現方法やパフォーマンス向上の試行錯誤によってユーザー数を獲得できるようなWebビジネスなどがそれにあたります。

よって、目的と手段を切り離しながらも、セットで考えることを、開発着手前の要求開発段階で、できるだけ早く行うことが大事になります。ToBe業務の結果イメージを早い段階から予測することが重要なのです。
そのためにもエンジニアが、システム開発という牢屋を壊して、ビジネスを戦場として戦うことが望まれるわけです。
さあ、要求開発マイスターのスゴーくん、一言発言の出番ですよ～。

図3 今回の一言！