相手に理解される文書を作るには

エンジニアはいろいろな人に向けて文書を書く必要があります。

ついつい、誰もが同じ理解をしている前提で書き始めることがあります。

そしてその資料で説明し始めて初めて、「それどういう意味？」とか「そもそもどういう目的のものなの？」と聞かれるなど、全く説明が通じないことがあります。

原因は、説明する事柄に対して共通の知識や理解がなくて、話が全くかみ合わないということが起きていることです。

考えていたよりも、もっともっと初歩のことから説明しなければならなかったと気づくことがあります。

同じ組織の人であっても、エンジニアであれば技術用語がそのまま伝わったとしても、部門長のようにマネジメントをしている人にはその理解ができない場合もあります。

ましてや、営業の人に説明するのであれば、技術用語はまず使ってはいけませんし、もっともっとわかりやすい表現をしなければ伝わりません。

どういう知識を持っている人か、その人に自分が伝えるべきことをどうやって伝えるか、それを考えて文書を作る必要があります。

理解のためには共通のスタートに立つ

人に説明をしたとき、ポカンとされるのであれば、それは相手が理解できる共通のスタートラインに立っていません。

そういうことは友達との間でもあるでしょう。

話し始めてしばらくして「それ何の話？」と聞かれて「○○のことだよ」と言って初めて伝わったという経験は誰しもあるでしょう。

友達ならそれでもいいのですが、ビジネスの場でそれをやってしまうと、「最初にそれを説明しろよ」と責められたりするので注意が必要です。

そのためにも「相手はどこまで理解している人か？」をよく考える必要があります。

ところがはじめて会うような人の場合だと、相手がどれだけ理解しているかはわかりません。

そういう場合は、自分が話そうということに対してどのくらい理解している人なのか、相手の人とつながっている人に確認する必要があります。

「このくらいまでは話してあるから大丈夫」とか「何も知らないからその前提で話した方がいいよ」というような情報を得ておくのです。

その上で説明資料や説明内容を考える必要があります。

エンジニア同士であっても前提は重要

同じ組織のエンジニアに説明する場合に、普段から意思の疎通もしているなどの理由もあってついつい最初の説明をはしょりがちですが、それもいけません。

同じ仕事をしている＝説明をはしょっても大丈夫

ということにはなりません。

僕も昔ついつい「わかっているだろう」と思ってディスカッションを始めたことがありましたが、「何の話をしたい」ということきちんと説明することが必要だということが結構ありました。

しばらくしてから、「これってこういうことを話していたんじゃないの？」と想定外のことを言われ時間を無駄にしたことが何度かあったからです。

会議にしろ、ドキュメントにしろ、ある程度進めなければ理解できないようでは、効率が悪い。

最初に「この資料はこういうためのものです」と書いておいたり、「今日はこういう話をしてゴールは何です」と話しておけば、スタート時点でズレを小さくすることができます。

書籍も同じですね。はじめにのところで、「この本は○○な人が、△△できるようにするために書きました」というように、誰にどんなことで役立つかを明確にしてあります。

それと同じです。目的を明確にすることが大事になります。

部門長や企画の人向けの資料

部門長や他部門の人、例えば開発とは異なる企画部門の人などに向けた説明資料では、エンジニア向けのものよりもっともっと概念的な話にする必要があります。

概念的というと語弊があるかもしれませんが、技術的な説明は後に回し、1段2段抽象度を上げてまずは概要を理解してもらえる文書にする必要があります。

詳細を求められたらもっと詳しく説明していくような構成になります。

それでもエンジニアに説明するような詳細説明は不要で、わかりやすい言葉を選ぶ必要があります。

一般的な技術用語や部署内の共通用語を除けば、専門用語を使わない意識は必要です。

※相手が理解している限りは専門用語を使った方が誤解が少ないことはあります。

特に部門長に報告する際などは、いかに短時間で問題点を理解してもらうかが重要になりますから、問題点を的確に説明し、なぜ、どうしてこれで解決するか、という論理的筋道に力を入れる必要があります。

営業の人への説明資料

営業の人への説明資料は本当に難しいです。

僕は営業の人はエンジニアとは別人種と思うくらい違うなと思うのですが、彼らは「技術は知らなくても理解は正確」です。

全く技術的なことはわからない人であっても、商品説明となると間違いません。

それどころか、エンジニアにではできないようなレベルで「上手」に製品の特徴を説明したりします。

「そういう表現があるか！」と感心するくらい上手にまとめます。

いかにお客様に理解しやすいかを突き詰めた説明なんです。

こういう営業の人に説明にするには、細かいことは不要です。

「お客さんにとってはどうなのか？」という目線の説明がとにかく必要です。

うまく伝えれば心強い存在です。

電子メールで気をつけたいこと

電子メールにしろ、チャットにしろ、ビジネスのやりとりにおいて書く文章はビジネスセンスが問われます。

• 返信のスピード
• 件名の付け方
• 依頼事項や質問への回答への的確さ
• 読みやすさ

などなど、たかがメール、されどメール、文章ひとつでうまくいくこともうまくいかなくなります。

要領を得ないメールや回答が不明瞭なメールというのは著しくビジネスセンスが問われます。

下手をすると、「使えない人」という烙印を押されかねません。

気をつけたいメール返信の基本を押さえましょう。

返信のスピード

返信のスピードは速いほどいいのは間違いありません。

速く回答が来た方が相手にとっては待ち時間が減るからです。

例えば、会議の日時を決めたい場合など、早く時間を決められた方が参加者全員にとって都合が良いからです。決定が遅くなるほど都合の悪い人が出てくる可能性もあります。

こういうものは自分の予定だけを確認すれば良いので割と簡単です。即時返信してあげるのが良いでしょう。

ところが、チーム内で検討が必要なもの、資料を作るのに時間が必要なものもあり、すぐに返信ができないことも多くあります。

もし返信まで半日程度でできる見込みがあれば、できてから送る方法もあるでしょうが、相手にとっては依頼事項が正しく伝わっているか気になる場合もあります。

そうすると、「承知しました。検討して返信します」といった短い返信をするだけでも相手に安心してもらうことができます。

なるべく早めに返信しておく、ということを心がけましょう。

件名で用件がわかるようにする

メールの件名の付け方は非常に大事です。

どんな相手に何の用件でメールを送るのかによって伝え方や表見を変える必要はありますが、メールの用件を明確に伝える必要があります。

送信者と件名を見て、読み手は今開くか後にするか決めますから、確実に開いてほしい、返信して欲しいのなら件名をしっかりと書きましょう。

（例）

• ○○の契約の件
• ××対応について
• ミーティング開催日時のご相談

特にアクションがあるものや、納期が迫っているものであれば、さらに件名を工夫します。

納期が明確なものに「【〆切：○月×日】」や「【要返信】」のような一アクションが一目瞭然の文字列を件名の先頭に入れるようなことは効果的です。

用件を本文の冒頭に書く

メール本文では、挨拶文のあとにまず用件を書き入れます。

件名でちゃんと伝え、メールを開いてもらったのですから、わかりやすく用件を伝えます。

それによって相手にその用件の優先順位を判断できるようにします。

忙しい人であればあるほど、メールにかける時間は短いものです。

そのためにも、用件を早く伝えることが必要になります。

用件を伝えた後で、詳細をその後に書くということです。

もしも、くどくど説明したあげくに、最後にお願い事項が書いてあるメールもあるのですが、そこまで読ませて時間を取ったあげく、たいした用件でなければ、読み手の時間を奪っただけでなくあなたのビジネスマンとしてのセンスが疑われるわけです。

みんな忙しいので、用件を簡潔に伝えて判断しやすいように気配りをします。

読みさすさに気を遣う

メールの読みやすさとは、いくつかの要素があります。

• 適切に改行を入れることで読みやすくする
• 会議などであれば、日時などを行を改めることでわかりやすくする
• 依頼事項、背景、など段落の説明を必要に応じて入れる

まずは適切な長さで改行を入れることが読みやすさには必要です。

スマホで読む人も増えており、画面の幅で自動折り返しもしますが、だからといって1文を長くするよりは改行を入れた方が読みやすいです。

そんな場合に難しいのが、何文字程度で改行するかです。

メルマガなどではPCでもスマホで同じような見栄えになるように割と短い文字数で改行を入れることを推奨している場合もありますが、ビジネスメールでそのルールを使うのはいささか問題はあります。

ビジネスの場合は、PCで見るのが前提で、スマホでも読む人もいると割り切りましょう。

そのため、PCで読みやすいことを心がけましょう。

会議の日時であれば、文中に書くより、

開催日時：○月×日　14時〜

などのように1行別にした方がわかりやすいでしょう。

また、長文になってしまう場合は

■背景：

■依頼事項：

■資料：

などのように段落に見出しを付けることによって、読み手がわかりやすくなるようにすることも良いでしょう。

仮説を立ててスピードアップする

ある商品やサービスの企画をより売れるものにするためにマーケティング調査をするとき、ただ漠然とこの商品を買ってくれるかと人に聞いて回っていたのでは、なかなか正しい答えは得られません。

その商品やサービスが使う対象を明確にして、そのゾーンにいる人に聞いていくことでより速く答えに近づきます。

仮に40代に売りたい商品があったとして、30代の人にどれだけ聞いても「いらないかも」と言われる可能性があります。

働く主婦を対象にしている商品なのに、専業主婦に聞いても答えは違います。

40代の働く主婦という対象ゾーンにいる人に聞いてはじめて、「ここがイマイチなので使いにくそう」とか「こういう人が使うかも」というヒントが得られます。

実際はもっと細かく対象を絞り込むことが多いです。

「子育てしている」こと人を対象にするなら、そういう条件も入れることです。

欲しいと思ってくれるだろう人という仮説を立てて、検証していくということです。

ニーズ調査を聞ける人に聞くという失敗

以前社内でスマホアプリの企画をしていて、こういうニーズは本当にあるかな？？ということを調べようということになりました。

そのときある人が「私の知り合いに聞いてみますよ」と言います。

それはいいね！とは思ったのですが、その人がどういう人か、ということが気になりました。

よくよく聞いてみると、「電車の中で使ってほしい」ニーズなのに、その人は電車に乗らずに通勤している人でした。

つまりその人は企画しているスマホアプリの利用対象者ではない訳です。

そういう人に聞いても、その人は「電車で通勤する人の気持ちになって」答えるわけです。

それだと欲しい答えは得られません。

実際に電車通勤している人から見ると、ぎゅうぎゅう詰めでスマホを開く隙間がないかもしれないし、毎日語学の勉強をしているから他のことはやらないかもしれません。

正しい対象者に聞くことが大事になります。

その人が「知り合いに聞いてみます」と言ったその姿勢は悪いことではないのですが、「知り合い」というお手軽さに惹かれてはいけません。

対象者選びは仮説検証の中では非常に大事なことになります。

自分も大事な対象者である

ニーズの検討をするときに起こりがちなこととして、「対象者は他にいる」と考えることです。

先日、あるチラシを配る際に読みたい内容を考えようというとき、「対象読者にアンケートを採りましょう」という話が出ました。

ところが、僕はすごく違和感を感じました。

なぜなら、そのチラシは自分たちも長年読み手だったからです。

わざわざその読み手を探して聞くのではなく、自分に聞けばわかることもある訳です。

そうすると、まずは自分の気持ちに聞いてみる。「どんな情報だと嬉しいか？」

ニーズに対して最も答えを聞きやすいのは、何より「自分」です。

自分の気持ちに聞いてみることは忘れてはなりません。

何かニーズ調査をする際、誰か他に聞かなければならないと思うことは少なくないと思いますが、まずは自分の心に聞くことが大事です。

仮説を立て自分で検証するコツ

仮説を立てて検証する際に、誰かに聞く前に自分はどうかと考えるようにすれば、人に聞くより格段に早く答えが得られます。

ところが、自分で考えるとどうしても偏りがあります。

そのサービスに対する思いやりが強くなるなど、第三者的な目線で見られない可能性もあります。

そのときは、自分の過去の経験と照らし合わせることがひとつ客観的に見る方法になります。

そのサービスが提供しようとしている価値が起こる場面は、過去に自分はどのように解決してきたかを振り返ります。

サービスがあったら使うか、ではなく、そのサービスがなかったときに自分はどうしていたか？です。

こういうことをしたいけれど、いいサービスがないので「まぁいいか」となってしまったなら不必要なサービスかもしれません。

反対に、いいサービスがないけれど、自分の力で時間をかけて何とか解決したのだとすると、少なくとも自分にはニーズがあったと言えるでしょう。

次の段落の画像を入れる

まとめ

仮説を立てて、対象ユーザーに聞いていくことでより速く答えを得ることができるようになります。

そして、その対象ユーザーに自分が入れば、他人に聞くよりももっと早く答えが得られます。

自分も対象ユーザーとして仮説検証に加わるようにしましょう。

それがニーズ検証ではとても有効になります。

計画の甘さがプロジェクトを遅延させる

プロジェクトマネージャであれ、チームリーダーであれ、担当者であれ、必ず計画を出す必要に迫られます。

計画とは、いつまでにどのようなステップを踏んで目的とする仕事を実現できるのか、ということです。

そのポジションに就いてからの時間が短い場合、経験値がないために見積が甘くなりがちです。

甘くなるとは、できあがりまでの細かいステップを考えずにだいたいの感覚で出してしまうことです。

一人一人の担当者が現実味のある計画を出さなければ、それを積み上げた全体の計画も不確かになります。

そして、実現までの大変さが見極められていないため、仕事の着手が遅めになってしまったり、仕事に着手しても楽に進むと思っていたり、予期せぬ問題に遭遇して立ち往生してしまうことも発生します。

つまり、計画が甘ければ、その後の仕事の進捗にも影響を与え、結果として計画通り進まないことになり、残業でカバーしたり最悪計画変更しなければならない事態に陥ってしまいます。

現実に即した計画を立てるためにはどうしたらいいのでしょうか？

プロジェクト成功のキーポイントを見極める

確かに計画を立てるのは難しい。ついついざっくりと期間だけを考えがちです。

「この仕様なら、○○ヶ月ですかね。」

といった具合です。

この計画の背景に緻密な計算があればいいのですが、そうではなくて感覚的に答えるケースも少なくなく、それが上に書いたような大きな問題になります。

緻密な計算とは何かというと、この仕様を実現するために「何をどのように解決して実現するか？」ということを見通すことです。

こういう技術を使ってこのように実現できそうだ、という仮説を立てたら、本当に実現できるのかを見極めます。

自分がすでに実現性がわかっていることは問題ないですが、そうではない新しい技術やサービスを使うのであれば、本当にやりたいことができるのか？ということを調べることです。

そのひと手間をかけるかどうかが大きな差を生みます。

技術検証も緻密にやる

新しい技術やサービスを使って事前に実現性を検証するとき、機能の一覧で確認するとか、少しサービスをかじってみる程度では不足です。

実際にやりたいことを実現してみる、という姿勢が必要です。

なぜかというと、プロジェクトを進めていって技術的な課題にぶち当たるとき、「事前に調べてできると思ったんだが、実現したい機能には適さなかった」ということが見つかるケースが少なくないからです。

つまり、実現性を検証する場合も、できるだけ現実で必要とされる機能が達成できることを確かめることが必要です。

「いやいや、そこまでやるのは無理でしょう？」

という声も聞こえてきそうですが、そこまでやるかどうかが成否の分かれ目です。

見積で8割の仕事を終わらせる

多くのプロジェクトの成否は、事前に問題箇所を把握して解決策を考えているかどうか、ということに尽きます。

もちろん、新たな技術開発やブレークスルーがないと実現できないプロジェクトがありますので、すべてのプロジェクトとは言いませんが、既存技術の組み合わせでやろうとするほとんどのプロジェクトでは、問題点を事前に解決できているか、で成否が決まります。

このことは、中嶋聡さんが書かれた「なぜ、あなたの仕事は終わらないのか」という著書に書かれていて、僕も非常に共感して読みました。

計画段階で実現すべきことの8割はできあがっている、ということです。

つまり、できない問題はないことがあらかじめ見通せている状態です。

だからこそ「いつまでにできます」と自信を持って言えるようになります。

残りの2割の仕上げを時間をかけてやるということです。

こうなれば失敗はないのです。

ぜひ中島さんの著作を読んでいただけると得られるものは多いと思います。

自分にとっての課題をクリアする

若かりし頃、勘に頼った見積を出し、実際に進めるとさまざまな課題にぶち当たって計画がどんどん遅れていました。

まさに出たとこ勝負の開発をしていました。

そんな開発をしていたのでは計画通りに行くはずもありませんし、自信のある発言もできるはずもないのです。

周りができると言っているからとか、枯れた技術を使うから大丈夫、ということではなく、自分にとっての課題をクリアしておくことが大事です。

他の人はすでにそのスキルをマスターしているかもしれません。

ところが、自分にそのスキルがないなら身につけないといけません。

経験値がないなら、その分事前に経験してみることが必要です。

自分に与えられた仕事に対して、不明な部分があるならなるはや着手して解決しておく、その姿勢が自分を助けることになります。

チャットは楽だが正しく伝わらない

昔から、電子メールは便利でいいけれど、ニュアンスが伝わらないとか、細かい話を伝えることより直接の対話の方が早いというのはよく言われることです。

テキスト（文章）で正確に相手に伝えるのは難しいです。

「○○してください」と書いたときに、どんなトーンで言っているのかなかなか伝わりません。

そのために、顔文字を付けたりする努力が必要になることもあります。

書いた方はやさしく言っているつもりでも、聞いた方はそうは捉えられないことも多いのです。

もちろん、口で伝えるのも同じで一度で正しく思いが伝わることはないですが、文章の場合書けば書くほど伝わりにくくなることもあります。

チャットになろうとそれは同じです。

チャットはメールよりも短い言葉で伝える文化になりがちですが、これもまた誤解を生んでしまうことがなくせません。

結局のところ、直接話した方が伝わりやすいということが起こります。

エンジニアだとどうしても電子メールやチャットで終わらせたいと思いがちのところがあるかもしれませんが、直接話し合うことを忘れないようにしましょう。

オンラインは対面より感情の注入が少ない

コロナの頃に、テレビ番組でオンライン会議のデメリットを解説していました。

オンラインでは相手から受け取る緊張感とか感情といったものが対面よりもずいぶん少なくなってしまう、というようなことが数値で示されていました。

対面がなくなってやる気が出ないとか、うつになってしまうなどの問題を起こす人が増えたわけですが、これにはちゃんとした理由があって、オンラインでどれだけ人と対面して話してもリアル感が薄くなってしまうんだそうです。

僕自身、オンラインの仕事が増えた結果、ちょっとした雑談をする機会が少なくなったり全くなくなってしまい、心がウキウキするような場面が激減したと感じていました。

それを裏付けるような調査報道番組だったのです。

ツールで「テキスト」を受け取って相手がこんな感じで言っているんだろうな、と想像できるくらいの近い人ならともかく、そうでない人なら相手が言っている「テキスト」は人間味を感じにくいです。

メールで隣の人とけんかする？？

僕が働いていた会社で、「隣の人とメールでけんかしている」という話題が上がりました。

隣の人と意見を言い合っているのですが、もちろん二人だけでやり合っているのではなく、その他の何人かにccで送られているメールの中でけんかしているのです。

もともと複数人で議論していたのですが、ある問題についての議論がその二人で白熱してしまったことで意見の応酬となってしまったのです。

どちらも「みんなが読んでいる」前提で書いていますから、簡単には引き下がれない気持ちもあるし、納得できない部分もあり延々とやりとりが続くわけです。

しかし、多くの場合主たる議論から外れてしまい、時に揚げ足取りになりかねないみっともないやりとりになることもあります。

こういうとき、介入して解決を試みたことはありますが、なかなかうまくいきません。

本当の意見の食い違いの部分について直接話せたらさっと解決するのに･･･と僕は思います。

メールでの意見の応酬は結構時間を食いますし、無駄にエネルギーを浪費します。

そんなことよりさっさと話して誤解があるなら解く、意見の食い違いを直接話して解決する、相手の意見を受け入れる、という方が早いです。

直接話すことを大事にする

リモートワークが当たり前になって、チャットが当たり前になる中、どうしてもテキストベースのコミュニケーションに頼りがちです。

しかし、残念ながらテキストではちゃんと伝わらないことは多いものです。

しかも、書けば書くほど伝わらない。

なぜかと考えると、書き手がこういうことを知りたいんだろうと思うことと、相手が求めることが必ずしも一致しないことが多いからです。

それなのに、文章でがーっと一気に書くと、相手が求めているものとズレたまま書き続けることになります。

そうすると、読み手としては知りたいことが書いてないのでサーッと読んだり、本来意図しないところが気になって本質とは外れたことの議論に進んでしまうことになりかねません。

書き手からすると「ちゃんと読んでいないだろう？」という気持ちにもなります。

こうやって話が食い違ったままエスカレーションしていきます。

ところが、対面で話をすると「その前に○○のことについて聞きたいんだけど」と、一方が話し続ける前に話のズレを解消することができます。

一方が説明し、他方が質問する、を繰り返すことでズレをどんどん小さくできます。

電子メールやチャットでどうもかみ合わないと思ったら、早々に直接対話に行く、これを大事にしてください。

まとめ

エンジニアの中には、「直接言ってくるんじゃなくてメールでちょうだい」とか、「打ち合わせなんかしないで決定事項を送ってくれたら効率的」という考えをする人もいるでしょう。

ただ、アナログ的とは言え、直接の対話でしか得られないことも多いです。

相手の思いや熱量、こちらに対する配慮や思いやり、深刻さや重大性など、メールやチャットで書いたらなかなか伝わらない感情的なものが多く得られます。

相手に自分の考えを伝えるように文章を打つのはとても考えますし、時間がかかります。

話して済ませられるなら、なるべくそうしましょう。

お客様の困りごとを聞き出す重要性

エンジニアが最終的に実現すべきことは、お客様の困りごとを解決することです。

そのためには、お客様の困りごとをしっかり把握することが非常に重要になります。

これができていないと、作るシステムがお客様の要望に添ったものにならない可能性が高いからです。

ところが意外と、お客様の困りごとは見えていないケースがあります。

お客様からこういうことを実現して欲しという要求は出てくるので、お客様が実現したいことはわかるのですが、その裏にどういう困りごとがあるのか意外と知らないことが多いものです。

どうしたら困りごとを聞き出すことができるのか、いくつも言われることがありますが、ここでは2つのポイントに絞って行きたいと思います。

相づちを打ったり同意して相手に話させる

お客様との会話ですので、片方が一方的に話す状況はよくありません。

困りごとを効く段階では特に、8割方お客様に話をしてもらうくらいのつもりで向き合う必要があります。

そのためには、お客様の困りごとをとことん聞き出す、そういう姿勢で臨みましょう。

お客さんが「こういうことに困っているんだよね」と言い出したとき、それは把握のための第1歩になりますが、そこからいろいろな話しを深掘りして聞いていくことが欠かせません。

そのためには、「そうですか」「なるほど」、時に「おっしゃるとおりですね」というようなフィードバックを返しながら、相手に「うちはこんなことに困っているだよね」と話しさせることが大事です。

人は自分の悩みを理解してくれない人にはあまり話しをしません。

皆さんもそうですよね？「野球のあのチームを応援しているんだ」などとうれしそうに話されても、自分が興味なければそれは相手にも伝わり相手はその話をしなくなります。

それと同じで、自分の困りごとを「ふんふん」と興味を持って聞いてくれる人にはいろいろと話しをしてくれます。

相手が気持ちよく話せるようにする、そういう風に話をしていきましょう。

質問を混ぜる

聞くことはとても大事ですが、ある程度話しが見えてくると、今度は疑問も沸いてきます。

これってどうなっているのかな？

どうしてこういうことをしないのかな？

などなどもっと深く知るための疑問が出てきたらそれを少しずつぶつけていきます。

そうすると、より一層詳しく説明してくれるきっかけになります。

例えば趣味の話しでも「そのテクニックってかなり難しいですよね？どうやって習得したんですか？」などと聞けば、「それはな･･･」と得意満面で話してくれることになります。

困りごとも同じで、相手が「よくぞ聞いてくれた！」と身を乗り出すような質問ができると、話しはさらに深まって行きます。

そうやって、少しずつ核心に迫っていきます。

もちろん、その中には取り組もうとしていることと直接関係のない話題も出てくるかもしれませんが、そういった話題もどこかでつながる可能性が出てきますから不思議です。

そんな一見関係なさそうな話しも聞いておいて損はないのです。

解決方法を話すな

僕たちエンジニアは困りごとを解決するのが仕事なので、お客様の困りごとを聞きながらも解決策まで考えてしまっていることが少なくありません。

ついつい「その課題にはこういう方法があります」などと言いたくなる気持ちはあるのですが、それをグッと抑える必要があります。

ある程度話しが進んでくると、解決方法の提案も入れてどういう対策がいいのかを絞り込んでいく必要はあるのですが、あまり早い段階での解決方法を例示していくのはうまくありません。

なぜなら、解決策の話しをすると、困りごとの話しが中断してしまって、最後まで聞けていないこともあるからです。

お客様も話したいことがあるのに中断された印象を受けることもあります。

また、困りごとの全容を理解しないうちに解決策を考えると、解決方法が適切ではない可能性がありますし、その考え方に引っ張られてしまう懸念もあります。

この段階はお客様の困りごとをしっかり聞き取る、それに集中しましょう。

困りごとを整理する

そうやって困りごとの話しを聞いていくのですが、すべての話しが一気に出てくることはありません。

聞いた話を整理しながら、新しい質問を出していく、そしてまた情報をアップデートして整理していく、その繰り返しです。

最終的にはお客様の困りごとが解決しているということが実現したいことですから、解決したい困りごとを明確にすることは欠かせません。

困りごとが明確になるとそれでいいかと言えば、そこから今回解決したい「要求」にまとめていく必要があります。

困りごとが多く多岐に渡れば、それをすべて一度に解決することはできないかもしれません。

そこで、今回実現する要求を明確にするというステップに進みます。

聞き方のまとめ

困りごとを聞き出す段階での聞き方をまとめると、

1. 同意や質問など適度なフィードバックを返す
2. 自分の判断を加えない

ということが大事になります。

相手に気持ちよく「困りごと」を話してもらう、それに徹して聞き役に回るということですね。

家族や知人の困りごとは学びのチャンス

家族がスマホのことで困っている、あるいは知人がネットのことで悩んでいる、などのことを聞きつけたら、なるべく問題を解決できるように協力しましょう。

協力するといっても、そういった問題に対処する中で、自分の知見にプラスになることが多いので、やって損することはありません。その上、解決すれば感謝もされます。

人が抱える問題は、自分が知っている環境とは条件が同じではないので、簡単に解決することばかりではありません。

ネットワークの問題だとしても、使っているプロバイダが違う、Wi-Fiルーターが違う、部屋の構造が違う、ルーターを置ける場所が限定される、使っている人数が違うなどなど、条件はさまざまです。

僕が体験した一例などを参考に、どうして人の手伝いが役人立つのか参考にしてください。

!

Netflixのアカウント共有に制限ができた

今ちまたで話題になっている問題（？）として、Netflixがアカウントの共有は同居の人のみ、という制限を全面的に導入したということがあります。

これまでは、家族間や友人間でアカウントを共有し、契約しているプランで認められている上限数の範囲内なら、違う場所にいながらそれぞれNetflixを見ることができました。

ところが、そういったアカウント共有は認められないとなった訳です。

そうするとNetflixが見られなくなってがっかりしていると知人から聞いたので、何とか方法はないのか？と調べることにしました。あくまで合法的なものです。

その結果、テレビやFireTVのようにテレビに接続して使うものは同じ家の中で同じWi-Fiにつながるなどしていないと使えないようになる制限がかかり、スマホのように持ち出すものが前提のものは制限はかけないとわかりました。

これらはNetflixのサイトに説明があります。

なるほどそういう制限があるのなら、同じ家にいない人はスマホで見るしかないね、ということになりますが、大画面のテレビで見たい！という欲求は消せません（笑）

スマホで見られるならスマホからテレビに出力する方法はないか？などと調べていきます。

そうすると、スマホからHDMIケーブルで接続してテレビに映すことやクロームキャストを使って投影するなど、Netflixの制限の中で許容されている方法が見つかりました。

それを知人に伝えたところ、とても喜ばれました。

YouTubeが見られなくなったと泣きつかれた

僕の義母はテレビでYouTubeを毎日見ているのですが、あるときYouTubeが見られないと電話で相談されました。

まず疑うのはネットに接続できているのか？ということになります。

テレビはネットにつながっていなくても見られるので、スマホでWi-Fiに接続してもらい、ネット接続が必要な画面を開いてもらいます。

使っているのはiPhoneだったので、AppStoreを開いてもらいました。

ブラウザで画面を開く方法もありますし、設定を開いてWi-Fiの接続状況を見る手もあるのですが、僕はAppStoreは誰でも最も簡単にネット接続しているかを知る手段と考えています。

そしたらAppStoreが開けません。

それならインターネットにつながっていないということなので、Wi-Fiルーターかそもそもインターネット接続ができなくなっている可能性があります。

Wi-Fiルーターの再起動などを試しましたが、一向に効果がありません。

そうなるともしかすると、宅内ではなくマンション内、もしくはプロバイダの問題では？？と疑われます。

それでプロバイダに障害が起きているか調べてみるとそんな情報はないし、マンションに同様の問題がある家は報告されていないとのこと。

であれば、宅内しかない。

Wi-Fiルーターは僕が設置して昨日まで何年も問題なく動いていたわけですから、それを疑う余地はなかったのですが、ここまで調べるとWi-Fiルーターが最も疑わしくなります。

まさかと思いながらも、プロバイダの端末とWi-Fiルーターの写真を撮って送ってもらいました。

そしたら、ビンゴ！

プロバイダの端末からWi-Fiルーターに入れるLANケーブルの挿入口が間違っているじゃありませんか。

僕が設置してこの前まで動いていたのにどうして？？と思ったら、義母曰く

「掃除したときに外して、適当に戻した。どこでもいいんじゃないの？」だと。

LANの挿入口を修正して、無事ネットに接続できましたが、自分のせいでこうなったとわかり義母は納得していました。

iPhoneの電話が鳴らない

ある人からiPhoneのLINE電話で、相手の声が聞こえないと連絡あり。

自分がしゃべっている声は相手に聞こえるのに、相手の声が聞こえないとのこと。

なかなか珍しいこともあるもんだと思って、音量とかの問題じゃないかと調べていたが問題はない。

僕がLINEで電話しても確かに聞こえていなさそうだった。

他に音楽もかけてもらったが、音楽も聞こえなかった。

電話を切って、一旦頭を冷やすことにした。

どんなことが考えられるか考えていたが、iPhoneの音が鳴らないって「ヘッドフォンなどに音が飛んでいるのではないか？」とひらめいた。

改めて聞いてみると、最近補聴器を付けて、iPhoneの音を聴いているとのこと。

「それだ！」

iPhoneの音が補聴器に飛んでいるんだ。

通常なら補聴器をオフにした段階でiPhoneとの接続は切れてiPhoneの音が鳴るはずだが、補聴器の電源を確実に切れていなかったので、接続状態が維持されたままだったのだ。

iPhoneの上部には外部のヘッドフォンなどに接続するとそれを示すアイコンが表示されるのだが、よく見ていないとそういうことに気づかないんですね。

こちらも電話だけで解決！

人のIT課題を解決することで学びは多い

こんなバカみたいな事例ですが、こういうことを経験すると、どういう順番で何を調べて問題の原因を絞り込んでいくか、ということを考える訓練になります。

加えて、原因を突き止める想像力が働くようになります。

自分がIT専門家として当たり前にわかっていることなど、意外と人は知らないものです。

こういうトラブル対応を繰り返す中で、自分で試して確認することで確実な知識が身についていきます。

小さな経験値の積み重ねは、仕事でも役に立つことは多いものです。

身近な困りごにぜひ首を突っ込んでみましょう。

技術ばかりに注力すると失敗する

エンジニアとして技術を磨くことは不可欠ですので、ついつい技術ばかりに目が向けがちです。

しかし、本当に技術者として成功したいなら、経営やマーケティングなどの知識を持つことが不可欠です。

なぜかといえば、お客様の課題を理解しないでお客様の望むようなものは作れないからです。経営やマーケティングの素養がないと、お客様の課題を正しく理解できないことが多いです。

お客様の困りごとの理解が足りないと、「要求仕様」だけ見てを作ることになり、結果的にお客様の困りごとを解決できないシステムを作ることがあります。

そこで経営の本を読む、マーケティングについて学ぶことで、お客様の困りごとにまで目配りしたり、お客様の課題をより現実的に理解できるようになります。

これがあってはじめて、お客様の望むシステムを作れるようになります。

言われたように作って失敗した日々

僕がプログラマとしてシステム開発に携わっていた頃、こんなことがよくありました。

見積もりしたら納期に間に合わない、納期短縮は難しく、納期の延期も了承されない。

何とか、目標の納期に間に合うようにしなければならない、という状況に追い込まれたとき、開発チームは納期に間に合うように機能を削減して納期に間に合うように調整を始めました。

各機能の見積が出ていますので、どの機能を減らすとどのくらい工数が削減できて納期に間に合うかをシミュレーションしていきます。

そして数字上ちょうど良くなる機能の削減を提案していきました。

その結果、目標の納期に提供することはできましたが、使うお客さんからは期待通りのものではないと苦情が来ました。

問題は現場での使われ方を考えずに、納期に間に合うような機能を削ったことでした。

こういうプロジェクトを数個経験し、お客様の事情を理解しないシステムの提供に無理があると悟りました。

人を仲介すると知りたいことが聞けない

エンジニアといえば、開発拠点にこもって毎日パソコンに向かって仕事をしている人は多いと思います。

営業の人や企画の人と打ち合わせをするのは一部の限られた上層部の人であり、ましてやお客様のところに顔を出す機会が少ない人も多いでしょう。

僕はまさにそのタイプでした。

営業の人とディスカッションするとか、お客様に出向くのは自分の仕事じゃないと思ってました。

ところがそうなると、営業や企画の人が聞いた要望を「間接的に」聞くことになります。

仕様を決めるに当たって

僕：「こういう使い方になると思うので、このような仕様でいいでしょうか？」

営業：「顧客に確認します。」

というやりとりをします。

もちろん、営業だからといっていつでもお客様に会いに行けるわけではなく、数週間後、時に1，2ヶ月後に答えが返ってきます。

営業：「お客様は、それで大丈夫だと言っています」

僕：「それは良かった。その仕様で進めます。」

とまぁ、こんな感じで作るんですが、できあがって使ってもらうと想定していたお客様の使い方が全然違ったりします。

質問した仕様の部分はもちろん、それ以外もダメだったりします。

要は、人を仲介して質問に行ってもらっても子供の使いのようになり、本来知りたいことを持って帰ってくれていないということです。

お客様に向き合えるようになる

こんなことを繰り返していてもなかなか本当のお客様の困りごとを聞くことはできません。

お客様との窓口になっている人にはもう少しこちらの聞きたいことを理解してほしいと思うものの、彼らはシステム構築のプロではなく、あくまで営業パーソン。

どうがんばっても、技術者が求めることを正確に伝えることなどできません。

そうなると、自分で言って聞いた方が早くて確実！という気持ちになります。

そう思って、自分でお客様のところに出向くようになりました。

ところが、そうやってお客様に話しを聞きに行くと、僕が聞きたいこととは全く別の課題をあれこれ言われて、「ええ？今まで聞いていることと違う！」ということにちょくちょく遭遇します。

実際問題、お客様の課題を正しく拾うのは難しいんですね。

対応するお客様も、営業の人が対面していた人と、僕が話を聞くような現場の人では、そもそも困りごとのレベルが違う、という問題もあります。

とにかく、自分で聞くと情報の正確さが違うことを実感します。

お客様のところに行くには準備が必要

直接お客様のところで話を聞くようになるには、それなりに準備が必要です。

準備というのは、何を聞くかとかそういうことの他に、お客様との話し方や、質問の仕方などのビジネス的な基本スキルに加え、担当者がやっている業務への理解する力や、困りごとを把握する力などが求められます。

こういったものは一朝一夕には身につきませんので、時間をかけて少しずつ身につけておくことが必要です。

僕自身エンジニアとしてやっていたので、最初はお客様のところに行っても必要な質問ができずに戻ってから再度聞かなければならないこともしばしばでした。

あとで聞くというのはお客様にとっても面倒ですしすぐに答えが返ってきません。質問内容を上手に伝えることも難しいです。

その点で、どれだけ現場できちんと情報を把握しておくかが大事になります。

その力を身につけるためにも、技術以外の本を読んだりセミナーに参加して知見を広げておくと良いです。

機械翻訳が高度化しても英語力は必要

DeepLやGoogle翻訳がどんどん賢くなって、翻訳の精度が上がってくると、自分の下手な英語力より格段に速く正確に翻訳してくれます。

僕は英語の素養はそこそこあるとは言え、得意言語の訳でもなく、読むのがまどろっこしいような複雑な文章の時は翻訳ツールに頼ります。

ビジネスの場面や苦情を伝えたいときなど、相手に正しく伝えたい場合の英語も翻訳ツールを使います。

海外旅行でもポケトークなどの翻訳機が活躍しているようです。

だからといって、英語（だけでなく第2、第3の外国語）を学ぶ必要がないのか？というとそうではないと考えています。

母国語が日本語じゃない人との会話においていちいち翻訳機などを使っていたのでは会話は弾みません。

ソフトウエアエンジニアの場合、海外のサービスが多いですから英語のドキュメントを読む必要があり、大量の文書をいちいち翻訳していたら手間がかかります。

技術的なドキュメントの場合に、必ずしも正しく翻訳されないという問題もあります。

せめて英語くらいはやはりマスターしておくべきと考えています。

機械翻訳にかけるより手間なく読める

どの程度の英語力が欲しいかは、どんな仕事に就くかやどんな目的に利用したいかによるでしょう。

僕は会話がペラペラできるような英語力を持っているわけではないですが、技術的な文書は割と読めます。

翻訳ツールにかけるなくても十分理解できます。

そのくらいの能力があると、あまりツールに頼らなくてすみます。

僕は、機械翻訳にかけた結果、日本語の意味がよく理解できず原文（英語）を見直すことも少なくないため、ちゃんと理解しようとすると翻訳されたものより原文をそのまま読むことが多いです。

これは人によりけりでしょうけど、エンジニアを目指すなら原文のまま読めるようにしましょう。

自分の言いたい表現は人工知能が教えてくれる

僕は過去何度か海外に出張していますし、アジアやヨーロッパのエンジニアと日本で一緒に仕事をした経験があります。

そのたびごとに、思ったようにしゃべれなくて残念に思ったことは数知れません。

AIを使った翻訳が登場するまでは、「こういうことを話したい」と思っても、適切な英語を調べることが至難の業でした。

日常あるいはビジネスのいろんなシーンで使える文例がたくさん載っている参考書を買ってきても、自分が言いたいことが載っているとは言えません。

どちらかというと自分が話したいことを見つけることがほぼ困難です。

だから、どうしても知りたいときは、親しくなった英語を母国語とする友人に尋ねて表現を聞いていました。

今はそういう英語を知りたければ、DeepLでもChatGPTでも聞くことができます。

そういう意味でとても便利になったと感動します。

会話は日常会話会話以上が話せるといい

基本的な日常会話などを勉強したら、その先いろいろなシーンでどう言えばいいか人工知能との学習で学べばより効率的だろうと思います。

最近では英語学習のアプリも優秀になってきてチャットで会話ができたり、アレクサに英語で指示することでちゃんと理解されるか判断するのにも使えます。

こういうツールを利用することで英語学習のハードルは以前よりグッと下がっている気がします。

何とか日常の会話程度話せるといいですし、できればもう少し複雑な会話もできるようになると、話していてうまく表現できずにまどろっこしい感じは少し減らせるでしょう。

翻訳の正しさを見るためにも英語力が必要

英語の表現はいろいろ学習しないと自分が表現できる範囲が広がりません。

ビジネス文書やビジネスメールではやはりAIの力は絶大です。

自分では思いつくことができなかったような表現が可能になります。

そうやって翻訳させた結果を自分が学んでいくといいです。

こういう場面でこう言えばいいんだなとわかります。

また、翻訳させたい日本語の書き方によって答えは変わってきます。

自分が英語を書きたいとき、それが自分でうまく表現できなければ、何とか表現可能な日本語に変えていくことはよくやる方法でしょう。

同様に、機械翻訳においても日本語を少し変えることによってより言いたいことに近づいていくようになります。

翻訳された英語を読んで足りない部分を感じたら日本語を変えて翻訳し直してみる、そういうことは必要ですね。

そのためにも英語の正しさをある程度判断できる語学力も必要です。

人工知能が賢くなれば、そのうち自分が言いたいことをくみ取って考えて翻訳してくれるようになるときも来ると思います。

（改行）

成長は仕事の中でしか得られない

リスキリングがとかく言われています。

リスキリングとは新しい技術を身につけ新しい業務や仕事に就くことですが、残念ながら仕事に使えるスキルは一朝一夕には身につかないです。

仕事に使えるレベルのスキルにするには何千時間とそのことに費やす必要があります。

ですので、それを仕事とは別に時間を割いて個人的な時間でやるには相当の時間が必要になります。

それと個人で技術習得しているときは、うまくいかないときも「まぁいいか」と諦めてしまえる環境にあります。

ところが仕事でやっているなら、「まぁいいか」で終わらすことはできず、是が非でも仕上げる必要があります。納期があるなら、徹夜してでもやり遂げる必要があります。

この「是が非でも仕上げる」ところに本当のスキルアップがあります。

妥協など許さず自分で自分を追い込める人はともかく、そうでない大多数の人は仕事でスキルアップするのが時間も確保でき、レベルも上がります。

同じ仕事では成長がない

仕事で成長すればいいとは言え、同じ仕事をしているだけでは下手をするとルーティンワークになる恐れもあります。

単純な繰り返しという仕事ではなくても、経験を積み上げてくるとその仕事のコツがわかってきますし、失敗しないための勘所も得られるようになってきます。

そうすると、効率的になりミスも少なくなるため、必然的に成功率も上がってきます。

仕事はあまりがんばらなくてもうまくいくし、上司や他部門の人からの信頼も上がり、仕事が楽しくなります。

こうなると、職場でも一家言のある人となり自然と重要な役割を担ったり、役職も上に上がったりしていきます。

それはある程度まではいいことなのですが、こういう繰り返しの場合、成長は少しずつ頭打ちになってきます。

成長しなくたって仕事はうまくいくのですから。

ひとつ上の仕事を目指す

そこで、成長のためにも自分が今できることのひとつ上のレベルの人がやっている仕事をできるように目指しましょう。

これは簡単なようで実際にはなかなかできないかもしれません。

なぜかというと、組織には役割に順列がありますし、上司がひとつ上の仕事を認めてくれないと実際には担当が難しいからです。

だからといって準備しておかないと、いざというときに問題なくやっていくだけのスキルがないということになります。

そういう場合でも、ひとつ上の仕事をやるつもりで取り組んでみましょう。

• プログラミングをやっているなら、少し上の設計や仕様書を書いてみる
• 自分の作業計画を立てるだけでなく、チームの計画をとりまとめる
• ある機能の一部の担当をしているなら、より大きなモジュールを担当する
• 機能設計をやっているなら、ひとつ上流の要件定義をしてみる

などなど、1つ上のレベルを目指す方法があります。

ひとつ上の仕事をやろうとすると、カバーしなければならない範囲がかなり大きくなり、やるべきことが大きく変わります。

これこそがまさに成長につながることになります。

目線が大きく変わる

ひとつ上の仕事をしようとしたとき、最も変わるのは「目線」だと思います。

1階にいると目の前のことだけしか見えませんけれども、2階に上がるともっと後ろや横との関係、あるいはもう少し向こうまで見渡せるようになります。

これによって周りを見る意識が生まれ、その中で仕事をうまくやるために新たなスキル習得が必要になります。

上に挙げた例で、どんなスキルアップが起きるか説明します。

• プログラミングから設計に上がると、全体の構成などを把握したり、将来の改修計画などを把握することが求められます。
• チームの計画をまとめるためには、各人の役割、スキル、スキルレベルなどを考慮して、どういう仕事の割り振りをして、どう開発を進めたらよいかを決めていく必要があります。
• より大きなモジュールを担当すると、関係するモジュールが増え、外部システムとの連携なども考慮しなければいけなくなり、他の機能についての把握が不可欠になります。
• 機能設計から要件定義に仕事をアップグレードするには、顧客の要求を聞くという新たな仕事が必要になります。言われて作る状態から、顧客の要望に合わせて作ることに考え方を変換する必要があります。

このように、1段階上に上がるだけでもぐっと広い視野を持つことが必要になり、スキルを上げないとやっていけません。

転職よりまずは社内でスキルを磨く

スキルを上げるというと転職を考える人も少なくないと思います。

確かに、転職でなければ得ることができないスキルアップもあります。

今の会社ではやっていないような事業領域や、会社には存在しない職種などもあります。

そういう人は転職も視野に入るでしょう。

ただ、どんな会社も「外から見える会社の姿」と「中に入ってわかる会社の実情」はだいぶ違うのが現実です。

仮に「こういうことをしたい」と望んで入ったものの、採用の際に聞いていた話とずれがあるのは避けられないと思います。

誰も嘘を言ってないとしても、表現された内容とそれをどう受け止めどう理解するかには常にギャップがあります。

ですので、転職を考える前に、まずは今の会社内でステップアップできる道を探しましょう。

会社でしっかり成長した方がより転職もうまくいくと思います。