前回までに「なぜ要求を発明する必要があるのか」「何をどうやって発明するのか」について筆者の考えを述べた。最終回の今回は「要求の発明に役立つ思考方法」を考察して，本連載を締めくくることにしたい。
システム開発＝顧客の問題解決
長年システム開発に携わってきて，何度も思い知らされたことがある。それは「システム開発とは，顧客の問題解決そのものである」ということだ。別の言い方をすると，顧客の問題解決につながらないシステム開発は，投資に対する見返りが少なく，スポンサー（＝経営者）の期待に十分に応えられないということだ。
思い返してみると，結果的に顧客に満足してもらえたシステム開発プロジェクトは，何らかの形で顧客の問題解決に貢献していた。一方，顧客の満足を得られなかったプロジェクトでは，業務やシステムの「現状保証」ばかりが論じられ，問題解決の視点や変革マインドがすっぽりと欠落していた。
そもそも顧客側に問題解決や変革の意識が乏しいのだから仕方なかったのだと，言い訳をしたくなる気持ちも少なからずある。しかし，そこに積極的に踏み込んで業務やシステムの改善をリードすることこそ，システム開発のプロフェッショナルに求められている仕事だと最近強く感じるようになった。
このように「システム開発＝顧客の問題解決」ととらえると，要求の重要性がますます際立って見えてくる。なぜなら，システム開発の一連の作業分野（要求，設計，実装，テスト）のうち，顧客の問題解決というゴールをめざすうえでの司令塔役は，どう考えても要求が担わざるをえないからだ。
より価値の高いシステムを提供することを目指す「要求開発」や「要求の発明」に取り組むつもりなら，なおさらのこと問題解決指向で要求をとらえることが重要になる。そういった意味で，システム開発チーム（業務担当者とシステム開発者の両方を含む）が備えておくべき最も重要な基礎能力は「問題解決力」だと筆者は確信している。
要求の発明に役立つ問題解決思考の三つのポイント
ただし，本稿では「問題解決思考」そのものを深く論じるつもりはない。誌面が足りないことも理由の一つだが，問題解決思考そのものを知りたい方は，優れたテキストが書籍やインターネットを通じて数多く出回っているので，そちらをご覧いただいくほうが良いと思うからだ。
むしろ，本稿では「問題解決思考」をシステム開発の屋台骨を成す最重要のプラクティスだと位置付けたうえで，「要求の発明」という次元でそれを実践するために役立つ，以下の三つのポイントに焦点を絞って説明したいと考えている。
| 1. | プロジェクト内の情報や知識を構造化する |
| 2. | ビジネスイベントの真の起点に発明のネタを探る |
| 3. | ものごとの本質を素直にシンプルに考える |
1.プロジェクト内の情報や知識を構造化する
問題解決思考は，頭で理解するぶんには容易に感じられるが，いざ体を動かして現場で実践しようとすると途端に難しく感じられる厄介な代物だ。
問題解決の教科書にはたいてい「理想と現実のギャップが問題である」「目に見える現象を問題と勘違いせずに，その背後に潜む本質的問題を発見する」と書かれている。しかし，頭ではこれを理解できても，現実にプロジェクトで実践しようとすると，何をどうやれば本質的問題が見えてくるのかがさっぱりわからずに，途方に暮れてしまうことが多い。筆者も幾度となくそんな挫折を味わってきた。
さらに，せっかく本質的問題を発見したと思っても，それを他人が納得できるように説明するのが，これまた一苦労だ。問題の本質を他人に納得してもらうには，事実やデータで裏付けて論理的に説明することが必要だが，これは実際にやってみるとかなり難しいことがわかる。
特に関係者の間に何らかの利害の対立が有る場合は，互いの意見をよっぽどうまく説明し合わないと，必要以上に対立がエスカレートしてしまい，本来は双方にメリットがある本質的な問題解決の機会であったにもかかわらず，それがお蔵入りになってしまうことも少なくない。
このようなコミュニケーション不全に冒されたプロジェクトでは，メンバーが積極的な議論を避けるようになり，誰もが共通に目に見えて理解できる「表層的な現象」だけを問題解決の対象にしてお茶を濁すことになる。しかし，こんなすぐに化けの皮がはがされるような，対症療法的な解決策にもとづいて開発された情報システムが，投資に見合うほどの価値を生み出さないのは言うまでもない。
これら幾多の失敗の経験から学んだことは，「本質的問題が発見できない」「他人が納得できるように問題を説明できない」「メンバー間で本質的問題を共有できない」といった問題解決の阻害要因を解消するには，プロジェクト内の情報や知識を構造化して全員がよく理解できるように可視化するのが有用だということだ。
問題解決は一般に「目的を明確にする」「情報を収集して分析する」「本質的問題を発見して特定する」「解決策を考案（発明）する」「解決策を評価して決定する」という手順で進める。特に，最初の「目的を明確にする」「情報を収集して分析する」という二つのステップで，目的や情報や知識を全員で共通認識しておかないと，その後の本質的問題の発見や解決策の考案や評価において，互いが納得できる形で意見を交わすことは難しい。
それを解消するには，プロジェクトが取り扱う知識や情報の体系とその表現方法，それをベースとした問題解決の手順について，関係者全員が事前にしっかりと合意したうえで活動を開始することが重要だ。例えば，図1の要求知識モデルをベースとした問題解決は以下のような手順で進めることができる。
| |
|
図1●『ソフトウエアの要求「発明」学 誰も書かなかった要求仕様の勘違い』（日経BP社 発行）で紹介されている「要求知識モデル」の例（一部の用語は本稿に合わせて筆者が変更している）。このような知識/情報体系を問題解決活動のベースにするとよい [画像のクリックで拡大表示] |
まずは，「業務スコープ」「プロジェクトの目的」「ステークホルダー」に関する知識と情報を収集し整理する。これらは問題解決の前提となる情報ならびに知識であり，ここをきちんと押さえておくことが，問題解決のスタートポイントになる。
次に「業務スコープ」の内部に含まれる「ビジネスイベント」を識別する。さらに，これら「ビジネスイベント」に対して業務がどのように反応するのかを「ビジネスユースケース」として整理する。
対象業務の内部にどのような業務上のイベント（事象）が存在するのか？ そのイベントに応えるために誰がどんなリソースや情報を使い，どういう手順で仕事を進めているのか？ これらの疑問に答えるための情報や知識を，現状とあるべき姿の両方の観点から構造化して表現し，両者のギャップを分析して業務の本質的問題を発見する。
さらに，識別した本質的問題の解決策に深くかかわる「ビジネス要求」を「ビジネスユースケース」との関連性（追跡可能性）を強く意識しながら導き出して「業務要件」として定義する。これが後に「システムスコープ」「システムユースケース」「システム要求」を検討するときのインプットとなる。
ここまで読んですでにお気づきの読者もいるだろうが，上記の手順はいわゆる「ビジネスモデリング」の手順そのものである。つまり「プロジェクト内の情報や知識を構造化する」という最初のポイントは，ビジネスモデリングを適用することとほぼ同義だと言える。
そもそもビジネスモデリングの目的は，対象業務に関連する情報や知識を構造化して関係者が共通認識を得やすくするように可視化することなので，業務の問題解決を強力にサポートするツールとして利用するのは正しいあり方だといえる。
ところが現実には，業務フローや概念クラス図などのビジネスモデリング成果物を作ること自体を主目的だと勘違いして，問題解決の意識が希薄なプロジェクトも少なくない。本来は問題解決が主で，ビジネスモデリングは従の関係であるべきなのだが，主従を逆転してプロジェクトを実施してしまうのだ。
その背景には，モデルを描きさえすれば自動的に問題が解決されるという錯覚があるように思う。しかし，ビジネスモデリングはあくまでもツールでしかなく，価値の高い要求を簡単に生み出してくれる「銀の弾」にはなりえない。
価値の高い要求を創造するには，問題解決思考を活動のベースにしっかりとすえて，まずは本質的な問題を発見することから始めなければならない。それができてはじめて，要求の発明という次元にも進むことができる。問題解決思考抜きのビジネスモデリングは，絵に描いた餅ほどの価値もないと肝に銘じておいてほしい。
