要求開発超入門

コンピューターシステムはビジネス価値を高めるもの

今回は、この問題をじっくり探っていきましょう。

システム開発者は牢屋に閉じこもる

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

図1 要求クレ〜

ビジネス価値を高めるようなITが作れない原因

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

これが、ビジネス価値を高めるようなITが作れない原因だと僕は思っています。
なぜなら、業務チームだけでは、業務オペレーションの見える化はできたとしても、最適にITを活用した業務オペレーションを描くことは困難なのです。つまりは、業務オペレーションを見える化できたとしても、最適なIT活用が描かれていない業務オペレーションを描いてしまいます。その結果、しっかりと業務を"見える化"しても、ビジネス価値を高めるようなIT活用はできず、単なる帳票の削減、画面レベルでの操作性の向上に留まってしまっています。ましてや、現状のように業務の"見える化"さえうまくいっていない状況においては、ビジネス価値を高めるようなITが作れることは稀なことなのかもしれません。

図2 要求はHowでもある

ビジネスを戦場に戦う

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

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

図3 今回の一言！

前ページへ

次号へ進む