筆者は，建設業界向け業務ソフトの開発ベンダーでソフトウエア開発に携わってきた。ここでは，自社における要求開発の事例を紹介したい。受託開発や社内システムの開発などと違い，不特定多数のユーザーが使う製品の開発では，要求開発にも多少異なる点がある。とはいえ，Openthologyが提唱する手法の多くは，製品開発における要求開発においても有効だ。読者の方々が要求開発に取り組む際に，参考になれば幸いである。
たまったバックログは3000件以上
当社では，営業部門やカスタマ・サポート部門が顧客からの要求を受け付けている。起案される要求は，多い月で100件程度。これが整理されないまま乱雑に積み残された結果，バックログの数は3000件以上にも達していた。現場では，このバックログの中で「何をやって，何をやらないのか，やるとしたら何からやるべきなのか」を判断しきれずに，混沌としていたのである。さらに，要求の価値について合意しないままにプロジェクトが乱立していたのも大きな問題だった。経営戦略的に重要な要求が，大量のバックログの中に埋もれてしまっていたのだ。
そこで，これらの問題を解決するべく社内で立ち上げたのが，要求開発プロジェクト「プロジェクト・ノア」である。プロジェクトには，営業・開発・カスタマ・サポート部門の代表者と経営者が集結。過去の習慣を捨て去って新たな仕組みを築くことを目指した。
「プロジェクト・ノア」の目標は，以下の通りである。
(1)ユーザー要求を正しく導き出すためのプロセスを構築すること
(2)戦略的な狙いや製品コンセプトを策定するためのプロセスを構築すること
(3)開発した要求に基づいてしっかりとシステムを構築できるよう，開発プロセスを改善すること
当社では，昨年まず(1)に着手。その後順調に作業が進み，現在は(3)の開発プロセスの改善に取り組んでいる。ここでは，(1)のユーザー要求を開発するためのプロセスについて紹介する。
コタツモデルで納得できるシステムを作る
最初に取り組んだ課題は，大量に積み残された要求を整理し，本当に重要な価値の高い要求を抽出していくためのプロセスを策定することだ。そのために，当社では以下の3ステップで要求を早い段階で見える化することに取り組んだ。
(a)顧客から要求を受け付けた部門で重要な要求を抽出し，他部門でも分かるような説明を追加する
(b)抽出した要求について，開発部門で実現方法を検討し，仮見積もりをすることでさらに洗練させる
(c)洗練された要求を，要求のジャッジメントに責任を持つ，経営者と各部門の代表者で構成されるチーム（つまりコタツモデル）で議論して，要求の採否を決定する
顧客の目的や要求の背景を理解せずに開発を進めてしまうと，「使えないシステム」を生み出してしまう。これは，基幹系システムだろうと業務ソフトだろうと同じだ。当社では，上記の要求開発プロセスを整備し，各部門で要求を整理・洗練してくことで，「価値の高い要求」だけに開発リソースを集中できるようにした。
さらに重要な点は，経営戦略を現場の作業レベルに落とし込む仕組みを構築できたことである。経営戦略は抽象的な表現になっているものがほとんどだ。またいくら具体的な戦略だったとしても，現場は常に変化しているので，徐々に経営と現場が乖離（かいり）してしまう。このギャップを埋める仕組みとして，プロジェクト・ノアで導入したコタツモデルが非常に有効であった。
他部門も意識した自己主張が盛んに
コタツモデルの実践により，「誰かが決めてくれるだろう」という「待ち」の意識から，「決めるために自分たちが今何をすべきか」という「攻め」の意識に変わりつつある。今まで開発部門は売り上げに対して無頓着であったため，声の大きな営業の意見が通っていた。しかし，「それで本当に売り上げにつながるのか？」「お客様はこう言っているけど，本当はこうしたいんじゃないか？」ということを考え，意見するようになってきた。一方の営業部門でも，これまではどうせ起案しても対応できないというあきらめがあった。しかし，プロセスを整備し要求を見える化したことで，営業部門が起案する要求が増えてきた。営業部門が起案する要求は，以前は3割程度だったのが，今では7割を占めるようになっている。
つまり，各部門が自部門だけでなく，他部門も意識して健全に自己主張するようになったのだ。これはまさしく同じコタツでひざを突き合わせて要求の価値を共有・合意した効果である。
要求開発のデメリットらしきものを1つ挙げるとすれば，要求開発をすると非常に疲れることだ。要求開発では本質面でモノを考え，必要であれば摩擦を恐れず意見しなければならない。普段は半分休んでいる脳をフル回転させるため，活動を開始したばかりのころは，会議終了後にメンバーがぐったりしていたことが多々あった。同僚からは，何か悪いことがあったのではないかとよく心配されたものである。
要求開発を行うためには，勇気とエネルギー，そして継続するためのモチベーションが必要である。しかし，実践を通してそれに余りある効果があることを実感している。
読者の中には，要求開発について難しそうだと感じている方も多いと思う。まずはコタツモデルから実践してみてはいかがだろうか。経営者や業務部門を巻き込んで要求について話し合う---その一歩を踏み出せば，要求開発のメリットを十分享受できるだろう。
| （立川 預嗣也＝建設システム） |
