こんにちは。フリーランスエンジニアのもんしょー（@sima199407）です。
エンジニアの仕事をしてますと、
「四六時中パソコンに向かってプログラミングをしている」
と思われがちなんですが、
意外にコードを書いている時間は少ないです。
どちらかというと、人と話して
・どういう風に作るか
・どんな機能が必要なのか
のようなコミニュケーションの機会が多いです。
以前、ツイッターでも
すごい技術とか高速でコード書くとか全然できる気がしないし、
周りのエンジニアと比べて知識量も未熟だと思いますが、
基本的なやり方がわかれば仕事はできます。
あるに越したことはないですが、必要になれば調べますし
人の話を聞いて理解する技術の方が大事ですね。
— もんしょー?下町の好動派 (@sima199407) 2018年11月15日
すごい技術とか高速でコード書くとか全然できる気がしないし、周りのエンジニアと比べて知識量も未熟だと思いますが、
基本的なやり方がわかれば仕事はできます。
あるに越したことはないですが、必要になれば調べますし
人の話を聞いて理解する技術の方が大事ですね。
ということにツイートしまして反響をいただけたので今回詳しく話していこうと思います。
ポイントとして
・クライアントへの話の聞き方
・定期的に話を聞きに行く
・現場に入らないと分からないことがある
ということです。ここができないと作業の遅れにつながるのでしっかり定義していくことが大事です。
ではみていきましょう。
仕事は「依頼者のほしいもの」作ること
エンジニアの仕事はコードを書くことではありますが、そもそもなんでプログラムを作るのでしょうか。
それは、”作りたいもの”があるからです。
当たり前のことを言っておりますが作りたいものとは誰が作りたいものなのかというと、「依頼者」です。
自作のプロダクトなら自分の作りたいように作れば良いですが、仕事をする場合必ず注文者がいます。
その人の意志をくみ取りプロダクトを納品することが仕事になります。
自分本位に作るのではなく依頼者の問題を解決できるものを作る。
依頼者に質問してみる
依頼者はなぜ依頼するのか。
それは「作りたいものがあるけどプログラミングはよくわからない」という理由がほとんどです(エンジニアからの依頼もあります)。
なので技術的な話をするのではなく「どんな問題があるのか」を聞いてあげることがいいです。
例えば、
という依頼があるとします。
いきなりコーディングから始める人はいないと思いますが、
まず「目的とターゲット」を明確にします。
・何についてのアンケートなのか（商品レビュー系、日常生活系、リクエスト系 など）
・誰を対象にしているのか（２０代、女性限定、結婚している人）
ここまでは依頼者もわかっていると思います。
次の段階がエンジニアの「聞くスキル」が試させれます。
その後に「そのデータを何に使いたいのか」を聞いてあげましょう。
・新商品の開発
・新規の顧客層を獲得
・既存データのアップデート
など
様々な理由が出てきます。
依頼者にはイメージがあるけどエンジニアにそれが伝わってないというケースが多いです。
そこのギャップを埋めることが「聞くスキル」だと思います。
勝手に作ると悲惨な結果に。。。
僕は現場でいろいろ失敗してきました。
今でこそわかることも経験の少ないうちは気づけないことが多いです。
今までで酷かったのは電話注文を受けたときの「顧客情報を登録するフォーム」を作る依頼がありまして、
以前にも同じようなフォームを作っていたのでそれを見本に作って依頼者に確認してもらったところ、
「ここの編集機能がほしい」
「ここを選んだらほかを選べないようにする」
など注文が多く予定工数より大幅に遅れてしまいました。
最初から聞いておけば防げた問題だったかなと思います。
技術的なことは具体例で説明する
作る目的だけを理解しても修正が多く入ってしまうことが多いです。
なので、技術的な面もしっかりおさえる必要があります。
しかし言葉で説明しても理解しづらいですし、前提知識がないところでは会話が成立しないかもしれません。
解決策としては「具体的なものを見せる」ことです。
例えば、
「ラジオボックス」と「セレクトボックス」のどっちを使ったほうがいいかを聞く場合には実際に使用されている部分をみせながら質問するのがいいです。
個人的には選択肢が少ないもの（5つ以内くらい）は「ラジオボックス（性別など）」それ以上は「セレクトボックス（年号など）」
にしてます。
【事例】
僕が以前依頼を受けたフォームのイメージを参考に作成したものです。
このとき、年号の部分が「text」でいく予定でしたが、依頼者と話しているうちにセレクトボックスの方が効率がいいということで変更になりました。
また、こちらからの提案で
①郵便番号を入力時に自動で住所を入る。
②ふりがなにカタカナが入るとひらがなに自動変換する。
という部分を話したところそのように変更になりました。
スキルシートで判断しづらい
話を聞く能力はエンジニアにとって大事な能力なのですが判断がしづらい能力になります。
これはどうしても現場に入ってから分かるものなので「＋α」の部分だと考えてます。
依頼者はどう頼めばいいかわからない
何度も言いますが、依頼をする理由として「作って欲しいものがあるけどプログラミングがよく分からない」ということがあります。
依頼者が持っているふわっとしたイメージを形にするのがエンジニアの仕事でもあります。
その現場での長く仕事をするには技術面の評価より話を聞くスキルが評価を得ることが大事になってきます。
読み取るスキルがあるエンジニアになる
人の話を聞くことは簡単なようで実は複雑だったりします。
・本当はこうしてほしいんじゃないか？
・ここが抜けているのでは？
・欲しい情報はもっと少なくてもいいのでは？
など考える部分はあります。ここは仮設を立てながら相手に提案をしていくことで徐々に見えてくると思います。
話を聞くことを苦手としているエンジニアも多いので、ここで差別化できると貴重な存在になれます。
【おすすめの一冊】
トヨタ出身の著者が会社員時代に学んだ説明術をまとめています。
[box05 title="内容のポイント"]
・「動詞」で説明するのではなく「動作」で表す
・「７つの習慣」を３つにまとめるには？
[/box05]
話を聞く技術だけではなく、質問をする技術も磨くべきです。