要求仕様作業の原点はインタビュー

一般的に、ＩＴを新しく導入しようとされた時、お客さまから提出される要望リストや口頭での要望の連絡は完全なものではなく、断片的であり、矛盾を含んでいたり、欠落もあるのが普通です。

やや古い内容ではありますが、プロジェクトが失敗する要因は、グラフのように大きく偏っています（たしか…日経SYSTEMSか何かだったような？）。別の調査などでは、「要件が詰め切れていなかった」とか「追加の作業が発生した」とかありますが、そんな具体的な一つひとつの問題原因ではなく、もっと本質的な部分まで突き詰めていくと、要するにこの３点に集約されることになるのではないでしょうか。

これは何を言っているかと言うと、

ということです。そして、PMBOK（プロジェクトマネジメントの知識体系）をご存じの方であればわかると思いますが、コミュニケーションに関する課題は、プロジェクトマネジメントの中でチームが混乱しないよう定め、コントロールすることが求められています。つまり、

ということになります。実に、およそ半分がコミュニケーションを主体としたチームメンバー間、あるいはステークホルダー間の「情報共有」に難があると言っているのです。

これには、「品質」の側面においても大いに影響を受けます。

たとえば、あるフェーズの設計書を元にして、次のフェーズが存在していた場合、設計書に記載されている内容がアバウトであればあるほど、次フェーズのエンジニアが保有する読解力依存で品質が決定されてしまうことを示唆しているためです。

そしてこのことは、さらにＩＴに精通していない、お客さま（側の担当者）にも大きくあてはまることとなります。仮に情シスなどを担当されていて、利用しているシステムやサーバーの運用・保守に精通していても、ソフトウェア開発、さらにはその中のプロジェクト活動における『要求定義』『要件定義』『要求分析』などと言ったフェーズが、どのようなもので、どうすることが正解であるかをご存じではありません。

しかし、だからといってエンジニアがお客さまの理想や希望、そして要求を勝手に想像し、忖度し、捏造するわけにはいきません。エンジニアは、お客さまへのインタビューを通じて、お客さまの要求を聞きだす必要があります。

インタビューで、最も重要な能力は、あたりまえですがコミュニケーション能力です。ときに「聞き上手（コーチング）」であり、ときに「話し上手（プレゼンテーション）」でなければいけません。

また、それ以前にもエンジニアがお客さまに向きあう姿勢にもインタビューを成功させる鍵があります。それは、お客さまに敬意をもって接する、お客さまの意見を最大限尊重するということです（我儘をなんでもかんでも聞けばいいと言うことではありません。あくまでビジネスとして成立する範囲内での話です）。

インタビューには、対面でのインタビューの他に、電話や電子メールなどの方法があります。従って、お客さまに対する接し方に気を付けなければいけないのは、対面でのインタビューだけに限るわけでないことは、お分かりいただけると思います。

電話によるインタビューや、メール（最近ではTwitterやLINE、Slackなどの情報伝達媒体）によるインタビューにおいても、相手に対する接し方に気を付けなければいけません。記録に残るのであればなおさらです。

一般的に、相手に対する接し方の難しい順にインタビューの方法を並べると、

　①「メール（等を含む、記録型インタビュー）」
　②「電話」
　③「対面インタビュー」

の順になります。これは、それぞれの連絡方法で伝えられる「言葉」以外の情報量の違いともう一つ、リアルタイム性や感情の伝え方の違いに起因しています。

メール等の記録媒体を用いたインタビュー

友人同士での電子メールの場合には、表現力の豊かなHTMLメールなども使われますが、ウィルスメールと紛らわしいため、ビジネスでは好まれません。ビジネスで使うメールは、基本的に文字によるテキストメールです。

また、あえて文書化するために、お客さまと口語でやり取りすることは少なく、基本的には文語…とりわけビジネスメールの表記に気を遣うようになります。

メールでは、書かれている文章だけで全てを伝える必要があり、文章表現能力、ドキュメンテーション能力が大変重要になります。普段から、あまり文書化する癖をつけていない人にとっては、これがかなり苦痛になるらしく、その苦痛を我慢してまで作成した内容は、添削するととても人様にお出しできるようなものでは無かった…と言うこともよく起こります。

助詞を間違ったり、誤変換で間違った漢字を使ったために、文章の意味が変わり、相手に誤解や不快感を与えてしまうことは少なくありません。ましてや、文章能力が低い人からのメールの場合、不快感を与えるだけではなく、メールの内容や意味がわからないこと、あるいは誤って伝わってしまうことも少なくありません。

メールを使ってインタビューする場合、言語化、および文章表現に十分な注意を払わなければ、正しいインタビューができることはありません。

また、メールは基本的に一方通行の連絡です。従って、メールの返信のタイミングを間違えると、相手に不安や誤解を与えることにもなりかねないので、この点についても注意が必要となります。

電話によるインタビュー

電話は、音声による双方向のコミュニケーションツールですので、文章だけの電子メールよりも、声の抑揚や言い回しなどで相手により多くの情報量を与えることができます。また、双方向コミュニケーションですので、相手の理解や誤解を会話の中で知ることができます。その場での補足や、確認なども取りやすいでしょう。

そのような場合、違った言い方で説明し直したり、たとえ話等で具体化したり、補足説明をすることも可能で、インタビュアーの意図に合ったコミュニケーションを行えます。

しかし、電話によるインタビューは、聴覚だけによるコミュニケーションであり、図解しなければならないような複雑な説明が難しく、正確に伝えられなかったり、誤解が生じることもあるので、注意が必要です。

昨今では「Web会議」「テレビ会議」などもあるので、直接会わなくても対面化することは可能です。あえて電話に固執する必要もありませんが、Web会議やテレビ会議などは、

　1. セキュリティの観点
　2. 施設/設備の台数

などの制約事項によって、必ずしも使いたい時に使えるとは限りませんので、いざという時には電話でもコミュニケーションに齟齬が起きないよう、日頃から注意しておく必要があります。

数年前までだと、セキュリティと言えば『ファイル共有』機能による機密情報の漏洩が主でしたが、最近では『盗聴』あるいはそれに類する問題がささやかれています。特に、お客さまのシステムを刷新するような場合は、その情報自体がインサイダーなどにつながることもあるため、オフィス内だからと言っても安易に誰もが聞こえるようなところで使っていいものでは無かったりします。

まぁ、大抵はお客さま側の方がピリピリしていることが多いので、エンジニア側も空気が読めればすぐにわかると思いますが、Web会議等の利便性のみを追求すると痛い目に逢うことがあります。

特に昨今は、リモートオフィスなどの普及によって、否応なく利用する機会が増えていますが、カフェ等で作業される方もいらっしゃったりしますので、気を付けなければなりません。

対面インタビュー

対面インタビューは、視覚や聴覚などの五感をフル活用できる双方向コミュニケーションです。

そのため、ノートやホワイトボードなどがあれば、説明内容を言葉だけでなく、文章や図を用いて説明することができ、相手に与える情報量が格段に多くなるという利点があります。また、対面でのコミュニケーションですので、相手の反応を見ることで、お客さまの理解度を判定し、補足説明も容易になります。

ただし、対面インタビューは、その場で合意や理解を得られやすくなる半面、『記録化』が杜撰になりやすいと言う問題も起きやすくなります。議事録等を残すことは、会議における基本中の基本ではあるのですが、その場で理解できたと思うと、しっかりと記録化しないエンジニアは多く、後になってから

　「いった／いわない」

の水掛け論となってしまうのは、永遠の課題なのかもしれません。

また、ＴＰＯ（Time（時間）、Place（場所）、Occasion（場合））のすべてを満たさないまま、自己都合だけで行おうとすると、相手にとって非常に迷惑となることがあります。Web会議等でもそうですが、リアルタイムコミュニケーションは、相手の時間を固定化してしまうと言う側面があります。有意義なインタビューとなった場合は良いのですが、インタビューと言う目的そのものがお客さまにとってはメリットの感じにくいものですので、できるだけ負担をかけなくていいように、様々な準備をしっかりとしておく配慮が必要になってきます。

なんでもかんでも「どうすればいいですか？」みたいに、図々しくもお客さまにカンペまで用意させようとする姿勢では、お叱りを受けることもあるかも知れません。

とはいえ、相手の顔色をうかがって、いつまで経っても進められなくなると、時間だけがどんどん過ぎ去ってしまって、逆にプロジェクトスケジュールのピンチを招きかねません。使いどころを誤らないようにしましょう。

最後に

インタビューとは、相手から情報を引き出す作業です。

従って、相手が自ら情報を提供するような場を用意できれば、それが最も良いインタビューになります。その時に必要とされる能力が「聞き上手」という能力です。「聞き上手」とは、インタビューする側が多くを語るのではなく、相手が自発的に自分の考えを話すようにするコミュニケーション能力です。

聞き上手の要素として「自らの望む形に話を誘導しない」ことも含まれます。話の流れで、思ってもいないことを話したり、知らないことを知っているように話したり、また不確定なことも確定しているように話すこともあります。話を誘導することばかり考えてしてしまうと、その傾向が強くなってしまいます。

アナリスト（分析者）などが行うようなインタビューは、お客さまの本当の要求を引き出すことであり、アナリストが期待している答えをお客さまに言わせることではありません。

たとえば、

お客さま　「〇〇という問題が現状ありまして…」
エンジニア「つまり、〇〇が起きないシステムを作ればいいんですね」
お客さま　「え、えぇ…まぁ…」

ではなく、

お客さま　「〇〇という問題が現状ありまして…」
エンジニア「それが経営上のボトルネックとなっているわけですね」
お客さま　「えぇ、この問題を解決したいと思っておりまして…」

といったようにするわけです。
この違いがわかりますか？

前者は、エンジニアの主観的な目線から、自分たちのすること、したいことに無理やり紐づけて、さっさと仕事を先に進めようとしているのが見て取れます。特に要件定義や要求定義と呼ばれるフェーズは、

　現状課題の洗い出し

がまず先にありきとなるべきフェーズです。
その課題を中途半端に理解した気になって、さっさと開発を前に進めたいと言う姿勢を前面に出してしまうと、どうしても強めの誘導尋問のようになってしまうわけです。

もし、ソフトウェアを無理に開発しなくても、業務の見直しだけで不要になったり、解決してしまうことだって往々にして存在します。

あまりに、話を誘導することは、当初のお客さまの要望とは異なった回答を引き出しかねず、結果としてインタビューを不成功にするという危険性を持っていることを忘れてはいけません。

そして、相手の話を的確に聞き取ることも、聞き手の能力のひとつです。

忖度であれなんであれ、エンジニアが自分の気持ちや解釈を先行させてしまうと、その時点で相手の話を正確に理解できず、歪曲して理解してしまうことがあるので注意が必要です。

　

また「話し上手」とは、一般的に、

　「自分の話に耳を傾かせ、共感を得てもらうことのできる能力」

を指しますが、インタビューで期待される話し上手とは、相手に共感を持ってもらう能力ではなく、相手に正確に情報を伝える能力のことを言います。認識齟齬が起きない話し方をすると言うことです。

これは、インタビューの目的や前提条件を説明する時に、お客さまに正しく理解していただくと言う意味で、非常に重要となります。

たとえば、会話の中で助詞（てにをは）ひとつが間違っているだけで、意味が変わってしまうこともあります。

　「○○でお願いします。」
　「○○をお願いします。」

たった一文字違うだけで、言いたいことが丸っきり変わってくるのがわかるでしょうか。もし、「○○になさいますか？△△になさいますか？」と聞かれていたとしたら、「で」を用いて答えた場合、相手に「あれ…？ひょっとして、他の方がよかったのかな？」と思わせてしまうかもしれません。

また、語尾が聞き取りにくい話し方の場合、肯定や否定が逆転する場合もありますね。会話をしているときに、自分が思っていることと話していることの間にずれが生じることがあるでしょう。自分が違ったことをしゃべったことに気付かないことさえもあります。

インタビューを行う側が問違った報告や説明を行い、それに気付かなかったら、お客さまは間違った情報や説明を元にインタビューを受けることになってしまう…と言う点については、慎重に慎重を重ね、コミュニケーション上の齟齬が「絶対に起きない（と思う）」と言える状況を作り出すことが肝要となります。

要件定義と呼ばれるフェーズで問題が起きやすいのは、仕様が詰められないと言うことでも、お客さまがＩＴをあまり理解されていないということでもなく、

　一人ひとりのコミュニケーション能力に差があり、
　その差を埋めることなく、双方の思い込みが認識齟齬を生んだり、
　あるいはそのために確定すべき事項がいつまで経っても決められない

ために起きているにすぎません。最もロジカルな思考が求められる業界の１つであるにもかかわらず、最もアナログな能力に頼らなければならないために、優秀なエンジニアであればあるほど、この落とし穴にハマりやすいのかもしれません。