少し前のことだが，あるシステム・インテグレータの社内研修に1日だけ参加させてもらった。研修のテーマは要件定義。ユーザー企業の利用部門からヒアリングした業務上の問題や要望を分析し，解消すべき根本的な課題を見いだす要求分析の進め方を学ぶのが目的である。

　その研修は，講義より演習が主体だった。素人の記者にはハードルが高かったが，無謀にも「ほかの方と同じように受講させてください」と頼み込んだ。要件定義の記事は何度か書いたことがあり，ちょっとした自信を持っていたのである。

　演習の手始めに，架空の利用部門からヒアリングした結果という10数個の業務上の問題が題材として与えられ，他の参加者と同じく記者もその分類を試みた。「すべての問題をカバーする“巧みな分類”を考えなくては」と記者は思った。問題が起こっている場面や原因が共通する問題同士をくくり，「○○系」「××系」という具合に分類名を付けた。「これでなんとか格好が付いたかな」とホッとした。

目的を忘れ「分析のための分析」に

　しかし講評のとき，講師のベテラン・コンサルタントに「利用部門はその分類を見せられても気付きがないでしょうね」とダメ出しをされた。要は，何を意図した分類なのか分からない，というわけだ。

　言われてその通りだと思った。記者は分類を考えているとき，「利用部門との間で重要な課題について合意形成する」という目的をすっかり忘れていた。ひたすら，論理的に矛盾なくすべての問題をカバーできる分類を探した。「分析のための分析」をしていたのだ。

　講師が示した模範解答では，論理性をあえて崩し，明らかに重要な問題が目立つ分類になっていた。利用部門がこの分類を見れば，「やはりそこが問題だな」と思うだろう。

壁一面の模造紙はエンジニアの自己満足

　研修のあと，講師のベテラン・コンサルタントに対して，「素人の記者がITエンジニアに交じって受講するのは，やはり無謀だった」と謝った。ベテラン・コンサルタントによると，記者がはまった「分析のための分析」は，要件定義における失敗パターンの一つだという。論理性にとらわれすぎて分析の目的を忘れると，ITエンジニアは暴走を始める。

　典型的なのが，問題とその原因という因果関係の分析に凝ることだ。利用部門からヒアリングした数多くの問題やその原因を一つひとつ付せん紙に書き出し，模造紙に貼り出すというのは，よく使われる方法である。この因果関係図を作ることで，複数の問題に共通する根本的な原因（課題）を見いだすことができる。

　このとき，ヒアリングした問題やその原因をすべて付せん紙に書き出し貼り付けていくと，あっという間に会議室の壁一面を埋め尽くす大きさになる。利用部門は数多くの問題を抱えているからだ。

　巨大な因果関係図を作ったことで，ITエンジニアはある種の満足感を得られるかもしれない。しかし模造紙が巨大になるほど，重要な課題は見つかりにくくなる。

　この場合でも，分析の目的を意識することが重要だという。大半のケースでは，利用部門は自分たちが抱えている根本的な課題をある程度認識している。分析の結果，「やはりそこが問題だな」という共通認識を持つことができればいいのだ。

　そのため，枝葉となる問題や原因はあえてカットし，根本的な課題が浮かび上がるように分析を進めるのがポイントだという。教科書にない実践的ノウハウとはこのことか，と感じ入ったのを覚えている。

　こうした実践的なノウハウは，日々の仕事のなかで少しずつ身に付いていくものだろう。お手本となる上司や先輩がいれば，そのワザを盗むことで学習のスピードを高められる。

　セミナーを活用するのも，実践的ノウハウを習得する一つの手である。日経SYSTEMSは7月3日に東京・表参道で，「すぐに現場で使える 手戻りなしの要件定義テクニック」と題したセミナーを開催する。教科書にない実践的なノウハウを身に付けたい方は，ぜひ参加していただきたい。