あのお客さん、苦手なんだよな。システムに疎いから話が全然進まないし…
クライアントと要件が詰められず困ってませんか？
- 打ち合わせのたびに前回の話を蒸し返される
- 「はぁ…」とか「はい…」などの生返事が多く、要件が詰まっていく実感がない
- なぜかケンカ腰で、打ち合わせ中イライラ
クライアントとのやりとりがこんな状態の場合、もしかしたら要件定義の進め方に問題があるかもしれません。
今回ご紹介する点を意識することで、お客様との関係が改善し、要件定義がスムーズに進められるようになるかもしれませんよ。
クライアントも「エンジニアが苦手」と思っている
IT関係の会社や部署にいると実感しづらいですが、エンジニア以外の人は「エンジニアが苦手」という先入観を持っている人が意外と多いです。
人によっては、エンジニアは怖いと思っていることも…。
エンジニアが苦手という人は、大きく次のように感じているようです。
- 話が専門的すぎて良く分からない
- 理詰めで畳みかけるように話すからイヤ
- 気難しそう
私が経験した話ですが、お客様と一度もお会いしたことがない状態にも関わらず、「男性のエンジニアは見下されているみたいでイヤなので、女性の方（できればエンジニアでない人）を窓口にしてほしい」と言われたことがあります。
過去に何があったのかは分かりませんが、こんなこと言われたら引くしかないですよね…。
あなたが「あのクライアントは苦手」と思っているようであれば、先方も「エンジニアであるあなたが苦手」と思っている可能性があります。
つまり、お客様が持つこのようなエンジニア像を払拭して上げれば、関係が改善する可能性があるわけです。
イメージ改善ポイントは３つ
イメージ改善のポイントは次の３つです。
- 最初から完成形の絵を示す
- 横文字は出来る限り和訳する。無理なら別の例えを用意する
- 笑顔でハキハキ話す
最初から完成形の絵を示す
通常、要件定義は要件を仕様化した文章で作成していきます。それももちろん必要ですが、まずは、クライアントが実際に使う画面を中心に画像やモックアップで示すように心がけましょう。
細かい説明や注意事項は、画面に吹き出しでも入れて説明すればOKです。
エンジニアでない人に、言葉だけで説明したところで残念ながら理解してもらうことは難しいです。
画面を見せることで、実際の利用シーンをイメージすることができ、要件の充足度を判断しやすくなります。
具体例
車のカタログをイメージしてもらえると分かりやすいと思います。
カタログでは、まず颯爽と走る車の表紙が目に入ります。ページをめくると内装とシートアレンジなどの情報がやはり写真付きで紹介されています。
最後の方には、エンジン容量やホイールベースなどの細かいスペック表（仕様）が細かい文字や注釈付きで記載されています。
みなさんが車を買おうとした時、まずカタログのどこを見るでしょうか？
普通の方であれば、まず写真を見て、普段の乗り方や旅先での使い方などイメージされるのではないでしょうか。
いきなり最終ページのスペック表に目が行く人は、よほどマニアックな人でしょう。
要件定義もこれと同じで、多くの人はまずイメージから入ってもらわないと、システムの全体像を伝えることができません。
「システムと買い物は一緒じゃない！」と思われるかもしれません。しかし、クライアントから見たシステムとは、『手間のかかる高い買い物』なのです！
そのため、機能要件、非機能要件、制限事項など、細かく決めるべきことはいろいろありますが、とにかく絵を交えて説明しないと伝わらないのです。
特に、最終的にどんな動きや画面になるかというイメージが重要です。「この要望を実現するとこういう見た目と動きになります」という感じで、絵を用意していきましょう。
文章レベルでの合意は、それまでに作ってきた絵と要件定義書を見比べながら要件定義の最終段階で行えばOKです。
そうは言ってもきれいな絵なんて描けないし、時間もないし…。何より、ころころ変わる仕様のために、モックアップなんて作りたくないよ！
そういう方もいらっしゃると思います。というか、ほとんどのエンジニアは忙しくてそう思いますよね…。
そこで役に立つのがペーパープロトタイピングという手法です。
この手法は、手書きで紙のモックアップ画面を作成し、それをユーザーと共有しながら仕様を詰めていきます。
要はお互いのイメージを共有できれば良いのですから、体裁にこだわる必要はないのです。
また、紙なので打ち合わせ中に動きを変えて、即座に新しい動きを作り出すことができるのも魅力の一つです。
ペーパープロトタイピングを学ぶなら、こちらの本がオススメです。スマホアプリ向けに書かれていますが、手法自体は他でも使えます。
カタカナ語は出来る限り和訳する。無理なら別の例えを用意する
クライアントと話すときは、可能な限りカタカナ語を避け、日本語に変換して話しましょう。
具体例
- プロパティ → 細かい設定（または詳細設定）
- ソート → 並び替え
- データをフィルタする → データを抽出する
こんな感じです。
ただ、何がなんでも和訳するのは無理がありますし、逆に意味不明になってしまいます。
基本ルールは、お客様の資料や口から出てきた言葉はそのまま使う、それ以外のカタカナ語は言い換える、としましょう。
自分が知らない用語というのは、「知らない」というだけでストレスを感じますし、特にコンピューター用語は日本語との対比が瞬時にできないことが多いため、専門知識がないと脳内変換が困難です。
例えば「スレッド処理」と言った場合は説明が必要ですが、「並列処理」と言えば、その言葉の意味から「同時になんかやるんだな」くらいのことは察してもらえます。
コンピュータ用語に慣れていない人にとって、知らない単語が「日本語でない」というのは、想像以上のストレスです。
似たようなことは医療現場でも起きやすいですね。お医者様が懇切丁寧に「この薬の成分がー」とか「これは〇〇という症状でー」と説明されても、言葉だけではピンとこないと思います。
これがクライアントが話を理解してくれないとか、イライラされる、といった結果につながる要因になってしまうのです。
しかしながら、どうやってもうまく和訳できない言葉というのは存在します。
例えば「IPアドレス」とか「ルーター」。どうしても和訳できない場合は、別のものに例えて理解してもらうのが手っ取り早いです。
具体例
- IPアドレス → ネットワーク上の住所のようなもの。番地情報。
- ルーター → データを住所別に振り分ける装置。宛先別にハガキを振り分ける郵便局のような機械。
こんな感じで、できる限り相手のボキャブラリーにある用語を使って説明するようにします。
エンジニアは、職業柄、正確にものごとを話そうとする傾向があります。もちろん、それが重要なのは分かりますが、クライアントとの会話も同じである必要があるかは考えた方が良いです。
システムの根幹に関わるところは正確に仕組みを共有しておく必要がありますが、そうでなければ、「～のようなもの」という説明で、だいたいの要素だけ把握しておいてもらえれば十分なんじゃないかと思います。
「相手のボキャブラリーにある言葉で話す」という点を心がければ、少なくとも、クライアントが思考停止なって話を聞いてくれなくなるということはなくなるはずです。
うまい言い回しが思いつかないとか、なんて言ったらいいか分からないというときは、e-WordsのようなIT用語辞典を活用するのがオススメです。
笑顔でハキハキとしゃべる
根性論のようになってしまって申し訳ないのですが…、意外と重要です。
特にエンジニアは「オタク」「コミュニケーション下手」「自己中」のようなイメージを持たれがちです。（自分のことのようで耳が痛い…笑）
そのため、笑顔ではっきりしゃべるだけで「お、こいつは話が通じるな」と思われやすいのです。
たったこれだけのことで、相手の方から勝手に一歩寄ってきてくれますので、利用しない手はありません。
「いや、そういうキャラじゃないし…」という方もいると思いますが、別にキャラを変える必要はありません。
「自分としてはがんばっている」というレベルでOKです。多少ぎこちなくても、歩み寄る姿勢が見えれば、向こうから近づいて来てくれます。
よほどひねくれた人でない限り、頑張っている人を無下にすることはないと思いますので…。
はっきりと、あまり早口にならないように話すことがポイントです。
良い提案でもボソボソ声では自信なさげに聞こえ、その不安はクライアントに伝わります。
また「笑顔で」と書きましたが、これはハキハキ話していれば、自然と出てくると思います。
普通の笑顔でなくとも、照れ笑い、自虐笑い…、笑顔にはいろんなパターンがあります。「笑顔は人間関係の潤滑油」とも言われてますので、とにかく何でも良いのです。
まずは「はっきり、ゆっくり話す」を心掛けましょう。
私はその人が持つ自然な笑顔だけで十分だと思いますが…、笑うこと自体が苦手という方もいらっしゃると思います。
そんな方は、こちらの本で笑顔の練習をしてみてはいかがでしょうか。表情筋の動かし方について、詳しく解説されています。
まとめ：要件定義は「日本語」で絵を交えて分かりやすく説明しよう
以上、ITが苦手なクライアントと要件をサクサク進める方法についてご紹介しました。
ポイントは次の３つです。
- 最初から完成形の絵を示す
- カタカナ語は出来る限り和訳する。無理なら別の例えを用意する
- 笑顔でハキハキ話す
中でも特に重要なのが「最初から完成形の絵を示す」です。
最終形が分かれば、利用イメージが湧きますので、課題や要望も明確になってきやすいです。
ペーパープロトタイピングなどの手法を使い、手書きでもなんでも良いので、どんどんクライアントに絵を見せて、イメージを膨らませる手助けをしてあげましょう。