「具体例を挙げてほしいって、いつも同じ質問をしますね」---。

 何度か取材でお世話になったエンジニアから、こう言われたことがある。自分では意識していなかったが、いつも同じ質問をしているらしい。「例えば、どういうことですか?」「具体例を挙げてもらえませんか?」といった例示を求める質問である。

 例示が必要なのは、記事に載せる材料にするからだが、最大の目的は、その場で記者が話の内容をしっかりと理解することにある。だから、さらに突っ込んでこんな質問の仕方もする。

 「なるほど、プロジェクトの目的を明確化するには、対象範囲や現状の課題が分かっていないとダメなんですね。じゃあ、私がITエンジニアだとして、A社の顧客管理システムを題材に、今うかがった二つの項目をどのようにして取りまとめていくのか教えてもらえませんか?」。

 相手が乗ってくれると、二人で手順書を作っていくような感じで取材が進む。

「まずどうしたらいいですか?」
「そうだなあ、最初にA社について念入りに調べるかなあ」
「念入りってどういうことですか?何を見るのですか?」
「ホームページとか、会社案内とか、商品カタログも見るかな」
「はい、目を通しました。それで何かアウトプットを作りませんか?」
「経営方針や事業内容、組織体制、業績はメモしておくね」
「どのくらいの分量ですか?A4用紙1枚くらい?」
「だいたいそのくらいですよ」
とまあこんな具合だ。

 「そんな質問をされたら、うっとおしいな」と思ったかもしれない。確かに我ながら「しつこい質問」だと思う。取材中に嫌な顔をされることもたまにある。

 しかし、それをするのが記者の役割だと考えている。記者の後ろには大勢の読者がいて、その代表として質問している。だから遠慮はしない。

コツは業務担当者になり切ること

 しつこい質問を取り上げたのは、要件定義の工程で、ITエンジニアが利用部門にヒアリングするときに使えるのではないかと考えたからだ。要件定義の取材では、「利用部門の業務を理解するのは難しい」という悩みをよく聞く。利用部門の業務をしっかりと理解するには、手順書を作るぐらいのしつこい質問が必要なはずだ。実際、この主張に賛同してくれたエンジニアがいた。ヒアリング時間の制約はあるが、ぜひ部分的にでも試してほしい。

 そこで改めて、要件定義のヒアリング向けに、しつこい質問の仕方を考えてみた。

 そのコツは、自分が主人公、つまり業務担当者になり切ることである。一種のロールプレイだ。

 現行システムの画面、伝票、帳票、商品など具体的なモノを用意した上で、業務担当者の視点に立ち、具体的な情景を思い浮かべる。情報が足りなければ、「今はオフィスですか、倉庫の中ですか?」などと質問してヒアリングの相手に補完してもらう。そして「次は何をしますか?」と質問し、相手から指示を受けながら、頭の中で業務を進める。

 全体の流れを理解したら、最初に戻って例外処理を探す。「電話で注文を受けたとき、個数を打ち間違えたら大変なことになりませんか?」「配送手配が終わってから注文のキャンセルがきたらどうするんですか?」「さっきの注文と一緒に配送してほしいと言われたらどうします?」---。目指すは、自分で迷わずに業務をやれる感覚である。これをつかめれば、ヒアリングは終了だ。

 実は、このしつこい質問は、記者のライフワークである「属人的スキルの手順化」を通じて培ったものだ。要件定義、モデリング、設計レビューなど、ITの現場には属人的なスキルが多々ある。それらを、多くのITエンジニアが実践できる手順に落とし込む。いわゆる、暗黙知の形式知化である。

 要件定義については、日立コンサルティングの水田哲郎氏(シニアディレクター)や富士通の森田功氏(SI技術本部 システム技術統括部 シニアマネージャー 上流工程技術担当)らに数年にわたってしつこい質問を続けた。両氏は大変な忍耐力で、記者の質問に答えてくれた。それが形になったのが『手戻りなしの要件定義 実践マニュアル』(日経BP社)という書籍であり、「手戻りなしの要件定義テクニック エキスパート編」というセミナーである。ご興味のある方は、参考にしていただきたい。