聞き取りのプロセスについて

何かの情報システムを作りたいんだ、という相談があると、何はともあれ、それを言い出した方にインタビューに行きます。何か解決したい問題があるんですね、何か仕組みをこしらえることで解決できそうだと考えているんですね、それは面白そうですね、くらいの気軽さで。仕事の意識というよりは、好奇心に駆られて首を突っ込みにいく、くらいの意識のときも割とあります。

そこで、何か決まったパターンの作業を延々と繰り返しているのが不合理な気がする、とか、いろんな情報を参照しながら作業をしなくちゃいけなくて間違えやすいのが悩みだ、とか、そんな感じの具体的な悩みを聞き出すところから始めます。問題があると思うからシステム化したいんだ、というのがそりゃあ普通なわけですし。自分の実感として「ああ、そりゃあ大変ですよねえ」と思えるまで詳しく聞くことにしています。自分自身がその仕事をかわりにやる羽目になったとしたら、さぞかし面倒でかなわないだろうな、と想像したりもします。

この時点で、なにか既存の仕組みを使うだけで問題が解消するかもしれない、と感じることがあります。それってExcelをちょっとうまく使えばできそうだよ、とか、完全にぴったり使い道があてはまる既存のソフトウェアがあるよ、とか。システムをこしらえること自体が目的なわけではないので、こういう提案で話がうまく収まったなら、これはこれで大成功です。

そうでない場合は、いよいよ、なんらかのシステム化によって、やりたい仕事を人間にとって合理的なものにすることを考える段階です。さっきまでの「大変ですねー」的な話によって、どんな登場人物がどんなデータを扱って、最終的にどういう成果物をつくりたいのかが大体見えていますから、それを分かりやすく即興の図に描いて（適当な白紙にエンピツ描きで充分！）、「これが普段やっていることの全体で、この中でもここらへんが面倒な部分ですね」といった具合に、問題点を「見える」ようにしていきます。現場の人も、この時点で「そう、ここが解決したいんだ、その通りだ」と同意できるくらい、話に着いてきてくれていることが必要です。まだ「システム屋さん」としての技術的な用語を持ち出してくる必要はなくて、素朴な言葉で構わないので、「これが解決したいんだ」という共通の意識をこの場のみんなが持てるのが大事な目標地点です。

こういう場で、的確に問題点を汲み取ってそれを示した図が描けるか、その核心部分について「その通りだ」と思ってもらえるか、というのが、けっこうな経験を必要とする、システム屋さんの備えるべき必須スキルだと思っています。ここまでやれてはじめて、「じゃあどんなデータをどこに入力しましょうか、それを誰がどういう操作で処理しましょうか」なんて段階の話を進めることができるわけですが（そしてこれも結構なスキルを要するところですが）、一番大事な「解決したい問題はこれなんだ」というのは、今後の色々な議論にあたっても、不動の中心点としてドッシリ決まっていないといけないです。