顧客の理解を大事にする

システムを作る上では、顧客が望むことを正しく理解することが欠かせません。

「そんなことはわかっているよ」と思っていても、意外にそうでもないことが起きがちです。

まず気をつけたいのが「顧客がわかる言葉」を使うことです。

専門用語を使って説明したりすれば、同じ理解をしていないかもしれませんし、そもそも言葉の意味を正確に知らないけれど、文脈で何とか理解しようとするかもしれません。

言葉の理解の違いによる解釈のズレをなくすことが重要で、そのためには「顧客が使う言葉」で話し合うのが良いです。

顧客の言葉というと、専門家にとっては正しい用語の意味でなかったり、正しい使われ方でない場合もあり、こちら側も使い肉言葉になってしまうこともあります。

それでも、その使い方は間違っているからと専門家の正しい使い方を押しつけると、顧客は間違いを指摘されたようで不愉快に感じたり、素人扱いされて嬉しくはないわけです。

ITの専門家から見れば正しくないと思える使い方でも、顧客が普段使っている言葉で語ってもらうことの方が大事です。

顧客の会社用語を理解する

会話が通常成り立たせるためには、言葉の意味を双方同じ理解をすることが必要なのは上に書いたとおりです。

顧客の会社の中で使われている独自の用語であったり、社内でみんなが使っている言葉の意味も共通理解をしなければなりません。

専門家である以上、知らないとは言わずに進めたいかもしれませんが、知らない言葉をそのままにしておいては会話がすれ違うことも起きてきます。

ですから、はじめて聞いて知らない言葉はその場で確認していくようにしましょう。

なるべく早い段階で言葉の意味を聞いておかないと、ある程度話が進んでから意味を聞くのでは「今さら何を言っているんだ」と思われかねません。

わからない用語については早いうちに確認して、双方の理解のズレをなくしておくことがよりよい理解になります。

もちろん、こういう意味だと理解して聞いていた言葉が、あるときの会話で違う意味だったと理解することもあるので、すべての言葉の意味を同じ理解にすることは難しいですが、なるべく早く同じ理解になるように努めましょう。

意味の伝わりにくい専門用語を使わない

顧客との会話をスムーズに進めていくためには、ある程度専門用語を使っていくことは良いでしょう。

しかし、例えばですが、CRMといった用語を使うことは話を難しくします。

ITの専門家なら、CRMと言われてシステムのイメージをつかむことはできますが、そうでない人にはCRMと言われてピンと来る人はいないでしょう。

言葉としてCRMの意味を知っていたとしても、だからといって同じ理解ができたというのはかなり難しいでしょう。

CRMの代表的なものにSalesforceがありますが、これを使ったことがある人は顧客との関係を管理するシステムのことだなということがなんとなくイメージできますが、CRMを言葉づらしか知らない人はこのイメージがつきません。

同じ会話をしているようでも、イメージしているものが全く違うかもしれないのです。

他にもシステム運用とか冗長性ということなどもなかなか正しく伝わりません。

極力そのような専門用語を使わずに説明すると良いでしょう。

ただし、何度も使わなければならない言葉であれば、一度しっかりと意味を理解してもらうようしましょう。

一旦その言葉を理解してもらえば、その後はその専門用語を使っていくことで会話をスムーズに進めることはできます。

わかりやすく解説することを忘れない

ITを専門にする人は、背景知識が十分にあるので、簡単な言葉で言ってもその背景にこういう意味を含んでいるな、と理解することができます。

何を主に伝えたいかによって変わってきますが、システム運用なら「システムが正常に動くようにすること」とかそのために「人が張り付く必要があってお金がかかる」とか、その用語を使う背景まで正しく理解してもらうことが必要です。

自分が説明したいことが相手にとってちゃんと理解してもらうためにも、顧客にとっての利益不利益がわかるように、「何が起きるか」ということを正しく伝える努力をしましょう。

常にお客様の理解が第一なのです。

（改行）

メールサーバーの容量は無限ではない

クラウド時代なので、サーバーの容量は無限にあると感じている人も少なくないと思います。

僕自身、ほとんどのメールをGmailに転送や受信できるようにして使っているため、ついつい容量が無限ではないかと思いがちになりますが、Gmailでは15GBという上限があります。

Gmailを利用しようが、マイクロソフトを利用しようが上限があることに変わりはありません。

知人某会社社長がやたらめったら巨大なプレゼン資料を作り、1回の送付で何10MBのファイルを添付しては送ります。

その結果、サーバーの容量を圧迫しており、適時ローカルに移す作業が必要だと説明しています。

昔ならpopで接続してすべてのメールを1つの端末にダウンロードするので問題は起きませんでしたが、スマホの利用が進み、またクラウドサービスが充実したことでimap方式で接続することになり、メールはダウンロードせずにサーバーに残る形式なりました。

その結果サーバーの容量を圧迫する事態になっています。

無駄にメール添付で送らない配慮を

メールサービスはメールを転送するのがメインの役割で、保管機能は送信先のメールをメールクライアントで受信するまでのしばらく保持するのがその機能です。

クラウド時代になって、データの容量を気にする必要がないかもしれませんが、不用意に大きなデータを添付して送ったり、それを不必要な相手にまでccで送ったりと、データ容量を無駄に使用します。

もし、一過性のデータをメールに添付して送ってしまったら、不必要な人は一人ずつそのメールを消す必要に迫られてしまいます。

メールの整理というのもビジネスパーソンの大事な仕事ではありますが、容量不足になって大きな添付ファイルを探して必要可否を判断しながら消す作業はなかなかばかばかしい作業です。

送る方は、一時的なら期間限定でその後勝手に消えるストレージを利用して送るなど、配慮が必要でしょう。

特に大人数に送らなければならないケースなどは注意したいものです。

メールをローカル保存してサーバーから消す

サーバーにメールがたまり続けると、いずれメールが受信できなくなるときが来ます。

そうなると困るのは自分なので、メールサーバーからメールを削除することになります。

大きな添付ファイルが付いたメールを探しては削除していくことで最初は何とかなりますが、メールの件数が増えてくると、いちいちメールを開いて重要かどうかを判断していくのは本当に骨が折れる作業で、すぐにこの方法では立ちゆかなくなります。

そこで、メールアプリを使って、パソコンのローカルファイルとして保存するようにします。

具体的には、メールのアーカイブ用ファイルをローカルPC上に作り、そこにメールを移動させることで、サーバーから消してくれます。

便利な機能ですが、簡単な反面メールの要否を判定せずに丸ごと残すのでこれも無駄と言えば無駄です。

でも落とし穴もあります。僕も今困っていますが、Outlookを使っていてローカルにどんどんメールを移動させていましたが、あるときからサーバーの容量が減らなくなってしまいました。

ローカルには移しているのに、それと同期してサーバーから消されるはずなのに･･･

原因わからず、サーバーの容量が100%に近づくのを恐れてます。

巨大な添付ファイルを付ける人への対策が課題

上に書いたように、やたら巨大なファイルを平気でメールの添付ファイルにする人がいます。

いかに大容量のメールを送れるとは言え、添付ファイルに何10メガものファイルを添付する人は本当に困ったものです。

そういう人に、オンラインストレージにファイルを入れて、リンクを送るといい、と教えてもなかなかやってくれません。

気持ちはわかります。オンラインストレージに格納して、リンクを取得してメールに張り付ける、かつその後パスワードを別メールで送る必要があります。

これはひと手間どころかふた手間ありますから、大容量のメールを送るたびにやるのは骨が折れます。

オンラインストレージの方から格納した後にメールを送る機能があるものもありますが、メアドの登録をしたりグループを作るなど管理をすることが求められるので、それもまた面倒。

このあたりの画期的なサービスはないので、残念ながらいい解決策はないと思います。

社内用のメールサービスが、添付ファイルを自動的にストレージに入れてリンクに変えてくれるようなサービスもあるようですが、導入は簡単ではなさそうです。

チャットサービスが社内ツールとして市民権はあるものの、対外的なやりとりはいまだにメールが主流ですから、メールのマナーというのは心得ておきたいものです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

営業の人への説明資料

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

返信のスピード

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

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

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

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

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

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

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

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

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

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

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

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

（例）

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

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

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

用件を本文の冒頭に書く

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

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

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

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

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

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

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

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

読みさすさに気を遣う

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

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

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

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

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

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

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

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

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

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

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

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

■背景：

■依頼事項：

■資料：

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

（改行）

トラブルはまさかの場面で起こる

不思議なことに、「今日はお客様向けのプレゼンだ」というような大事なときに限って、昨日まで問題なく動いていたシステムが動かない、なんてことが起きます。

神様はどこかで見ていて意地悪をするのか？

と思いたくなるようなタイミングで問題が起こることがあります。

上司や現場のリーダーは「これからプレゼンだというのにどうなっているんだ！？」と声を荒げます。

だいたい、こういうタイプの人が最も困る人である。

声を荒げて場を凍り付かせる以外何もできないからだ。

それでなくても動かなくて焦っているのはシステムを作っている裏方なのだ。

どうしてこうなったんだと必死に頭を回転させている。

そこに罵声を浴びせる愚、本当にわかってない。

僕はそういう大事な場面で横から出てくる人を極力無視ししている。

怒鳴ることで問題が解決することはないからだ。それより頭を回転させたい。

その声にかえって焦ってしまうとしたら、解決は遅れることはあっても早まらない。

トラブルの原因は過去に戻っていくことで見つける

トラブルが起きたら、その原因を見つけるためには正常に動いていた状態と今は何が違うか？を順を追って、あるいは消去法で問題を絞り込んでいく必要があります。

昨日動いていたのだとすれば、昨日以降今日の間に何を変更しただろうか？を思い出していく。

そうすると、昨日の夜あれを変更したということを思いだし、まずはその変更が悪影響を与えていないか調べる。

それが問題ないなら、他に思い当たることがないか調べていく。

時に、原因となる変更が数日前や数週間前のことで思い当たることがなかなか思いつかない場合もあります。

原因がわかってから、「あの作業が影響したのか！」とようやく気づくこともあり、過去をさかのぼっていけば必ず見つけられる訳でもありません。

それでも、短時間でいかに原因を特定するかということが大事になります。

その場しのぎも大事

トラブルが起きるまでの経緯を過去に戻るだけでは思いつかない場合、今度は症状から原因を推測していくことが必要になります。

しかし、そういう場合のトラブル解析には時間がかかることが少なくありません。

時間がないとき、その場だけでもいいから動かす方法がないかを考えることも重要です。

しっかり原因を追及するのは後に回し、取り急ぎその場をしのぐ方法を探します。

あるべき姿に戻すことに気を取られるあまり、本来やるべきことがまるっきりできなくなることは避けるべき時もあります。

緊急時のトラブル対応は、ある程度経験を積んでいろんな対応方法があり得ることを経験しないと簡単に身につかないかもしれません。

物事にトラブルは付きものだと理解する

上に書いたように、トラブルの際にただ慌て怒鳴るような人と仕事をするのは本当にしんどいものです。

原因を特定するため落ち着いて考えたいにも関わらず、的外れな指示を飛ばしたりすることもあるからです。

それでも一刻も早く問題を解決するのが最も大事なことですから、それぞれの立場で考え対策を出し合いましょう。

それぞれの立場で考えるのは、その場しのぎであってもできる対策が見つかる可能性があるからです。

そのためにも、人任せにしたり慌てふためくのではなく、落ち着いて冷静に判断することが必要です。

もちろん、後で考えてもうちょっといい方法があったと思うこともありますし、他の人が考えた妥協案の方が適切な場合もあります。

それでもその場面を乗り切ることができたら成功としましょう。

そういう経験を積んでいくことで、冷静に短時間で正解にたどり着けるようになっていきます。

（改行）

リスク管理には手順がある

リスク管理とはプロジェクトの成功のめに危険（リスク）を管理（マネジメント）することです。

リスクを管理することなんてできるのか？といわれそうですが、早く見つけて早めに対処していくことがプロジェクトを成功させるためには必要です。

ところが、多くのプロジェクトではそのリスク管理ができていません。

たいがいのプロジェクトマネージャは問題なく進むと信じていますし、リスクを管理するというよりは、問題が表面化してはじめてことの大きさに気づくことも少なくありません。

チーム内やプロジェクトの進捗の報告を読む人にリスクに対する感度の高い人がいればいいのですが、そうでなければ問題が大きくなるまで気づかないという致命的な問題になることもあります。

リスクマネジメントは難しく、結局現場やそれを見守るマネージャの力量に任されるというのが現実です。

リスクは早期発見・早期対策

病気と同じで、プロジェクトのリスクは「早期発見・早期対策」が重要です。

僕が関わっていたプロジェクトでは、その「早期発見・早期対策」ができずに大炎上してしまったことがあります。

新規のプロジェクトを率いていたチームリーダーは、他部門と仕様調整に難航し当初考えていたような計画では進んでいませんでした。

その辺りの問題を含め、「順調ではない」ことをたびたびアラートとして発していました。

しかし、なぜかプロジェクトマネージャはその問題を「そんなに大きな問題じゃない」と高をくくっていたせいで、何の対処も行われないまま数ヶ月が過ぎてしまいました。

僕は周りから見ていて新規のプロジェクトにしては人の割り当ても少ないので、「大丈夫ですか？手伝いますよ」とそのプロマネに進言していたものの、「大丈夫だ」ということで済まされていました。

しかし、数ヶ月経ってテストを開始する頃、問題は発覚します。

仕様通りに作られていない箇所がどんどん発見され、バグとして登録されたのですが、まさにバグの山。

しかも一つ一つは他部門との仕様調整が必要なものが多く、修正にはとても時間がかかります。

そして、とてもテスト期間内には修正できないような量になり、その後大量の人を投入して仕様の調整やバグ潰しをしました。

結果的に、半年以上の大幅遅れで導入となりました。

この問題は「早期発見・早期対策」で完全に解決できる規模のものではなかったかもしれませんが、早く着手すればもっと小規模な炎上で済んだかもしれません。

プロジェクトマネージャの判断ひとつがプロジェクトを大炎上させることもあります。

リスクはあらかじめ出しておく

リスクは何かその後のプロジェクトの進捗に影響を与えそうだとかなえたとき、早めにアラートを出す、ということがとても重要になります。

ところが、それぞれ経験によって同じことに直面しても大きな問題と感じなかったり、そもそも問題と感じなかったり、自分の中で何とか片付けたいという気持ちが起きてしまいます。

そうならないように、まずはこういうことが大きな問題につながる可能性がある、ということをチームメンバーで共有しておく必要があります。

そうすることで「これってリスクに関係するかな？」というような考えが出ることで、早めにアラートが出ることにつながる期待があります。

リスクに関しては具体的なもので、かつそれが起きたときにどういう対処があり得るか、誰に相談すべきか、といったことを決めます。

まずはリスクを見える化しておくということが有効でしょう。

とはいえ、それがうまく機能するかはそれをうまく活用できるか、ということに関係します。

リスク管理を機能させる

リスク管理をしている会社であっても、そのリスクとして挙げるものがあまり起こりえないものだったり、簡単に思いつくものであることも少なくありません。

確かに、「リスクを挙げよう」と検討を始めても、なかなか適切なものが挙げられないことも多いのが現実です。

リスク何がリスクなのかをわかっていなければ、問題が発生しても担当者が解決すべきことと思うかもしれません。

出てきたリスクは、まずは優先順位を決めて管理していくことです。

管理するためには、継続的にレビューをしていくことが欠かせません。

一定の間隔で見ていくことで、リスクマネジメントしていないことに気づくことがあります。

プロジェクトの進行中は、ついついプロジェクトを進めることばかりに目が行き、リスク管理を忘れがちになります。

また、プロジェクトが進行することで、初期の頃にはぼやっとしていたリスクがもっと具体的に見えてきたり優先順位が変わったり、あるいは別のリスクが浮上していることに気づくこともあります。

プロジェクトの実情に合わせて、リスクの優先順位を変えたり、リスクをより具体的なものに絞り込んだり、あるいは新たなものを追加して改めて見直すことが有効でしょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次の段落の画像を入れる

まとめ

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

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

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

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

社外の交流を増やす

30代ともなると、会社の中でもある程度ポジションができ、仕事の進め方もだんだんと確立してきて、仕事がやりやすくなっていると思います。

それだけ、仕事のやり方をマスターし、自分のスキルも高め、会社が求める仕事ができるようになったということでとてもいいことです。

社内でどうやって自分の立ち位置を高めて行こうかと考える時期でもあります。

確かにそれはそれで素晴らしいことなのですが、自分が働く会社という小さな社会におけるルールや価値観の中で仕事ができるようになった、ということに過ぎません。

テレビのCMで「転職サイトへの登録はキャリアの健康診断みたいなもの」というキャッチコピーを使ったものがありますが、転職サイトを使うかどうかはともかく、自分のキャリアを見直す時期でもあります。

ここでオススメしたいのが、社外に出てみるということです。

社外に出るとは、社外のコミュニティに入って自分は何ができるか試してみるということです。

全く違う職種や価値観を持った人たちとの交流は、会社にいるのとは別世界です。

自分が持つ能力を知ったり、逆に井の中の蛙であることを知らされたり、大きな刺激を受けられます。

エンジニアから離れようと思ったあの頃

僕はアラフォーになろうかとしていたころ、このままでいいか？ということを思いました。

このままでいいか？とは、エンジニアの中にいて仕事することだけで良いかと不安になったのです。

エンジニアの仕事として僕が気に入っていたことは、いくつかをひもとくと次のようなことです。

• スーツなど着る必要はなく、服装が自由でいい。
• 面倒だと思うことはあったけれど、基本的にはメールや文書ベースで仕事が進んでいく。
• 顧客と直接会う必要はなく、営業や企画の人から聞いた要求に基づいてサービスを開発したり改善すればいい。

もちろん、納期が迫って死ぬほど忙しいときもあるし、営業の人のように大きな商談をまとめ大きく利益を出せば、後はそこそこ楽に過ごしているのをうらやましく思ったことも事実。

エンジニアとして、人ではなくシステムを相手にしていると、仕事の多くがシステムという仕様という厳格なものに従った完全なものを作り上げることになります。

そのプロセスはというと開発工程にしたがって進め、工数や進捗の管理・バグ数など品質を測るなど数値的なもので管理することがほとんどの毎日です。

その仕事に、人の温かみは感じず、僕には血の通ったものとは思えない状況が毎日続いていました。

このままエンジニアの世界にいたのでは僕の考え方は血が通わなくなる！

という不安にさらされました。

そう思ったときから、どうやってその世界に出ようかと考え始めました

エンジニアの力を生かせる道を見つけた

外部に出るといっても、どういう世界に行けばいいのかなかなか見当が付きませんでした。

そんな時に目にしたのがファイナンシャルプランナーという資格。

ファイナンシャルプランナーは、相続や保険・年金といった知識が必要になりますが、ライフプランを作成する際には毎年の収支などを積み上げて将来予測をする必要があります。

「ライフプランを作る」、ここにはエンジニアの技量が使えるのではないか？

なんとなくそう思ってファイナンシャルプランナーの道を選ぶことにしました。

それから一念発起、ファイナンシャルプランナーの資格を目指して勉強する日々となりました。

どのくらいの時間をかけたか今となっては記憶がありませんが、無事AFPの資格を取得するに至りました。

それからはその資格を生かせるようになるにはどこに行けばいいかを模索し、身近なところにあったスタディグループに参加することにしました。

これが自分にとっては大きな転機となりました。

FPのスタディグループで自分の役割を発見！

ファイナンシャプランナーの集まりであるスタディグループに行ってみると、僕とは違う経歴の人ばかり。

保険業界の人や社労士・司法書士として働いている人、税理士などその道のプロばかり。

エンジニアは影も形も見つけられません。

その中で一体僕はどんな役割を果たせるのだろう？

しばらく悶々とした時間でしたが、しばらくしてその会で無料の相談会をやろうということになり、そのためにライフプランを作成するためのツールが必要ということになりました。

そのときエクセルのスキルがあった僕に白羽の矢が立ちました。

それまでの間に、社労士や税理士といってもほとんどITスキルがないことは十分把握していましたし、僕以外にできる人はいないことはほぼ自明でした。

よし、これは俺の出番だ！と張り切りました。

エンジニアのITスキルは世の中がうらやむくらい高い

エクセルでライフプランを作ったことは成功しましたが、こういうことを通じて感じていることは、エンジニアが持っているITスキルは世の中から見れば驚くほど高いということです。

世の中を見渡せばメール送受信の設定すら四苦八苦する人がたくさんいます。

もちろん会社の中にもたくさんいますが、運営チームから自社の環境に準拠した懇切丁寧なマニュアルが配布されたり、必要なら人的支援も得られるので多くの人はすぐにメールの送受信ができます。

ところが、一般の人たちとなるとメールサービスはそれぞれ違うし、使うPCもメールクライアントも異なるのでなかなかできないわけです。

そんなこんなでエクセルでいろんなことを実現していくと、人はとても驚きます。

ですので、エンジニアが持つIT力には自信を持った方がいいです。

ただし、気をつけないといけないのは「生半可な理解ではダメ」ということです。

会社で使っているPCやメールソフトならわかるけど、そうじゃないPCだとわからないとかでは役に立てません。

また、専門用語を使わないわかりやすい説明が求められます。

そういった点は注意する必要がありますが、エンジニアのITスキルの高さは世の中から見れば驚きものです。

そういった自信を持って外に出てみましょう。

一人で解決しようとするな

ついつい人は自分で解決しなければ、と思います。

人に手伝ってもらうのは「恥」

とまではいかないにしても、簡単に人に頼れない気持ちもあると思います。

ところが、リーダーともなれば人を活用することがとても大事になります。

人を活用することで、自分でできる範囲を大きく超えることができます。

三人寄れば文殊の知恵といいますが、人が集まることで知恵どころではなく労力が生まれ、スキルが集まり、その結果高速なスピードで、質の良い仕事ができるようになります。

しかし、うまくやらないと労力やスキルがうまく活用できず、質やスピードが高まりません。

その辺りがどんな仕事をどういう風に任せるか、リーダーに求められる力量と言えるでしょう。

Aさんにあなたの考えを文書化するスキルがあり、Bさんは顧客への提案力があるなら、AさんとBさんであなたの代わりができるかもしれません。

いきなり満足できる結果は出ませんが、まずは任せて自分の仕事の一部ができるような部下を育てましょう。

大変な仕事ではないよ、ハードルを下げる上司

かつての上司にとても人当たりのいい人がいました。

やさしい話しぶりだし、いろいろ話も聞いてくれて共感もしてくれる、部下から見れば理想的な上司の一人でした。

ところが、仕事の経験も増えその人といろいろな仕事を繰り返していくうちに見えてきたものがありました。

それは、「仕事を任せるときに、どこまでやってほしいという期待値をちゃんと言わない」といくことです。

例えば、炎上するプロジェクトの支援を求められたとき、彼が言ったことは

「1〜2週間手伝ってくれ！」

でした。

聞いた瞬間、炎上プロジェクトの支援が1〜2週間で終わるわけがない、少なくとも2〜3ヶ月は必要だろう、プロジェクトの経験があればそんな短期で終わるわけがないことは明らかです。

案の定、そのプロジェクトは半年以上かかり、かつその間毎夜深夜まで働かざるを得ませんでした。

他にも「外部との協議会に参加してほしい。行くだけだから」

というような話もありました。

ところが、いくだけの仕事なんてあるはずはなく、毎週宿題を抱える状態。

そんないくつかを経験するとその上司がやりたいことは、何とか担当を任命することであって、負荷とかその仕事の目指す成果が見えていないことでした。

言葉の響きよく気楽に参加したものの、評価のされない仕事が多く、この人との仕事は後悔することが多かったです。

マネージャたるもの、仕事をどこまでやってほしいか、それを見極めて依頼してほしいものです。

期待値を明確に伝える

このマネージャの問題点は、やってほしいことを明確に伝えてないことです。

炎上を何とかしたいのであれば、「今このような状態で、ある程度落ち着くまでPM補佐として専任でやってくれ！」というような、役割とゴールを明確にすべきだったと思います。

同じ仕事でも、「とりあえず作業を手伝ってやってくれ」というのと、「PM補佐で」というのでは役割が違いますし、1〜2週間の腰掛けとするのか、落ち着くまでと明確にゴールを設定するかによっても気持ちの入り方が違います。

実際、プロジェクトに関われば関わるほど炎上具合が見えてきて、これはにっちもさっちもいかないということが見えてきました。

要するに、仕事を頼むときは、「ここまでやってね、それを期待して人選したんだからね」というようなことを伝えてほしいと思います。

もちろん炎上したプロジェクトの現状を把握もせずに、とにかく人の投入ということも少なくないのですが、そんなことでは人的資本の無駄遣いですね

適材適所がチーム力を高める

新しい仕事を立ち上げる必要があるとき、いつもなら自分の役割だから、いつものように自分でやろうとせずに、一度考えてみる必要があります。

ぜひ誰か別の人に任せてみるということを考えてみてください。

会社の仕事は複数のことが並行して走るので、新しい仕事を始めたいときにいつも最適な人材が待機していて充てられるわけではありません。

「自分でやるしかない」と考えるのではなく、今までやっていない役割を経験させることでスキルアップの機会を与える、という考え方が必要です。

そうすることで、自分の分身とまではいかなくても、似たようなことができる人を育てることができ、自分だけなら1しかない仕事量が、1.5倍や1.8倍に増えるのです。

また、部下って自分がどんな仕事に割り当てられるかで「自分が組織内でどのくらいの立ち位置にいるか」を判断するものです。

「私にこんな仕事が回ってきた」

と期待されることがわかればやる気もアップします。

ぜひ自分の分身を作るつもりで、一段上の役割の仕事を与えて欲しいと思います

それがゆくゆく自分を救うことにつながります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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