顧客の理解を大事にする

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

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

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

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

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

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

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

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段抽象度を上げてまずは概要を理解してもらえる文書にする必要があります。

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

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

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

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

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

営業の人への説明資料

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

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

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

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

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

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

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

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

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

ソフトウエアの品質を守る最後の砦はテスト

ソフトウエアをリリースして良いかを判断する重要な指標の一つにテストの結果があります。

テストは開発者と別の人が、仕様書と付きあわせて検査項目を作り、一つ一つ検査していきます。

開発者は自分でプログラミングしているので問題ないはずと思っていますし、またある程度の規模以上では複数人で開発することがほとんどなので、個々の部分には問題がなくても全体で動かすとお問題が起きることもあります。

ですので、第三者がソフトウエアの全体をくまなく検査することが求められます。

テストはソフトウエアの品質を決める最後の砦なのですが、問題はきちんと検査項目をしっかり出し、機能のほとんどをカバーできているか、ということがとても重要になります。

テストは期間の定めもあり、人員の制約もありますので、テストの網羅率を高めた上で効率的に進めていくことが求められる、非常に重要な仕事です。

検査項目は正常系と異常系をカバーする

検査項目を作るとき、仕様書の記述に沿って検査項目を作っていきます。

開発者はプログラムのコードのすべてをカバーできるようにプログラムベースのテストしますが、テストで行う工程ではプログラムがどう作られているかではなく、機能が仕様書通りに動くのかで検査します。

機能的には大きく正常系と異常系に分かれ、正常系とは通常の操作で問題なく動作する場合のことを言います。エラー処理も決まっている場合は、これも正常系に含みます。

例えば、入力画面で入力できない文字を入力したときにはじくようにするのは正常系に分類されます。

異常系とは、正常な動作をしたにもかかわらず起きる場合で、入力がサーバーに通知されたのに保存されていないとか、保存できていないことがわかり別の部分がアラートを出したとか、そういったときの処理になります。

正常系、異常系、どちらもシステムの機能として不可欠です。

両方をカバーしてはじめて検査項目としてできたということが言えます。

異常系のテストが難しい

異常系もテストに必要なのはわかっていても、異常系とはそもそも通常の仕組みの中で起きにくいことなので、なかなか現象を起こせないというジレンマがあります。

そのテストのためには、いかにして異常に近い状態を発生させるか、ということがカギになります。

そのためには開発者の協力が不可欠になる場合もあります。

やりたい異常系の状態にもよりますが、例えば内部的に異常な状態を作り出すわけですね。

なかなかこういうテストは難しく、機能の100%をカバーしていくことは至難の業です。

それでもテストが最後の砦である以上、できる限りカバーしていくことが求められます。

どうしてもテストできないものは、開発者がテストしていることでよしとする場合もあります。

網羅性の高い検査項目を作る

検査項目を出すとき、組み合わせとして多くのことをカバーするのが大切です。

やみくもにたくさんやっても、同じことを検証しているだけということになりかねませんし、いかにテストの網羅性を上げるかということに注力しましょう。

網羅性を上げるためには、組み合わせとして違うパターン作ったり、値として意味の違うものを与えることによって、プログラムの違う経路を確認したりします。

そのためにも、機能仕様を理解して、通常はこういう動作をするが、これこれのときは別の処理をしているなということを理解して、通常と別の処理をしているパターンを分けてテストをするということになります。

その辺の検査項目の組み方は少々熟練する必要があるとは思いますが、既存のテスト項目をみながら学んでいくことが大事でしょう。

テストの効率化を目指す

テストは最後の砦ですが、何でもかんでもテストでカバーすることはできません。

時間は限られますし、テストの人員も必要な分だけ提供されるわけでもありません。

そこで効率的なテストの実施が求められます。

検査項目の順序の組み方次第で、1つの手順で2つ以上の検査を実施できる場合もありますし、組み合わせとして減らせる場合もあります。

テストの順番によって同じことを繰り返す手間を減らせることもあります。

テストの進捗やテストの目的にもよりますが、テスト項目に書かれた通りに順にやるのではなく、効率的な実施方法も考えながらやることも大事です。

お客様の言葉を鵜呑みにしてはいけない

お客様の「こんなものを作りたい」という言葉を起点として作るべきシステムを機能分解していきます。

そのとき、目に見える機能の実現だけをゴールにすると、できあがったときに足下をすくわれることがあります。

それは、お客様の言葉や業務からは直接聞こえてこなかった要求が実現できていなかったというようような場合です。

性能が足りないとか、かえって業務が増えてしまったとか、技術レベルが高くて今の人材では対応できないとか、あまり想定していなかったことが起こります。

例えば、性能の面でいうと、1年に数回しかないけれどもとても注文が多くなる日があって、その日に処理するには性能が足りなかったというような場合。

「そんなこと聞いてないよ」

といいたいところでしょうが、求められる処理性能について質問していなかったから、最も処理が多くなる日について考え及ばなかったとも言えます。

こういう機能要件でないものを「非機能要件」と呼びます。

非機能要件を満たしていない場合、顧客満足が下がることもあるので結構重要です。

どんな業務にも見えない要件がある

業務をシステム化するときに、今の業務がどのように流れているか、ということを把握する必要があります。

そのために、現場がどんな手順でやっているのかをヒアリングしながら理解し、どういうシステムにすればいいかを考えています。

業務をやっている人はシステム構築のプロではありませんから、システムの要件として話ができる人はおらず、「こういうことをやっています」という説明を聞くことになります。

なるほどやっていることはわかるのですが、そこにはあまり出てこない話もあります。

どんな頻度でやるのか、どのくらいのスピードでやるのか、どのくらいのスキルがあるのか、など意識して聞いておかないと把握が難しいことも少なくありません。

例えば、「システム化するので私は別の作業をする予定になってます」となれば、人が全く不要になる仕組みを作らなければなりません。

そうすると、その会社ではなくリモートで保守できるような仕組みが必要になるかもしれません。

そうするとずいぶんと新しいものが必要になりそうです。

そういうことを引き出していくことが求められます。

今までの業務を変えていいところ、いけないところ

非機能要件の難しさは、現場で行われる業務を知ってはじめて出てくるものも少なくないことが理由としてあります。

今まで、エラーが起きるとすぐにお客様に連絡して確認していたとすると、システム化してそのエラーを即座に通知して、従来と同じようにお客様に聞いてもらえるような仕掛けが必要です。

また、お客様に聞いて間違いの箇所がわかったら、すぐに修正できるようなUIも必要になります。

「1日分まとめてエラーファイルを作り、修正した内容翌日一括して読み込むつもりでいたので、1つずつ変更するUIを用意していなかった」

ということになれば、お客様も会社も困るわけです。

システム化によって便利になる反面、従来できていたことができなくなってしまっては元も子もありません。

同じことをより効率的にやれるようにするのがシステム化です。

新しい業務には何らかの業務支援機能が必要になる

新しい業務を設計してシステム化すると、そのシステムに満足しがちですが、何か穴がないかをよく考えることが必要です。

頭で考えると非の打ち所のないシステムに見えても、実際に使うとボロボロだったり、ぼろくそに言われたりということも決して少なくありません。

人は新しいものを使うのにどうしても抵抗感がありますし、慣れるにも時間がかかります。

これまでならコピペできていたのに、コピペできなくなったらとても効率が下がります。

画面を開くと戻らないといけない分だけ面倒だと言われるかもしれません。

それを回避するため、一括でCSVでダウンロードやアップロードする機能が必要かもしれませんし、一覧性の良い画面レイアウトが解決策かもしれません。

システム化は一つ一つの現場の要求を拾い上げながら、業務上の最適化も実現しなければなりません。

それ以外にも、納期や予算もありますから、非機能要件を拾い上げて、そこも含めた機能を実現することがなかなか大変なことであります。

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

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

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

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

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

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

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

返信のスピード

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

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

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

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

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

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

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

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

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

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

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

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

（例）

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

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

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

用件を本文の冒頭に書く

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

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

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

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

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

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

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

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

読みさすさに気を遣う

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

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

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

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

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

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

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

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

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

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

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

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

■背景：

■依頼事項：

■資料：

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

（改行）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

その場しのぎも大事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

情報セキュリティの実務上の注意点

情報セキュリティを語るには僕はそれにふさわしい専門家ではありませんが、それでも今の時代最低限の心得を知っておき自衛する必要があります。

体系的ではないですが、日々の業務を進める上で気をつけたい事例について取り上げようと思います。

• BCCの使い方
• 社外秘の情報をやりとりする場合の添付ファイルの取り扱い
• パスワードの管理
• フィッシング等のメールを見極め方

ひとつずつ説明しますね。

BCCの使い方

BCCとは、メール送信の際に「受信者に誰に送ったかメールアドレスがわからないように送信する」際に利用するものです。

主には、一斉送信をする際に利用します。

社内や社外の人に一斉に同じ内容を送るけれど、誰に送っているかわからないようにする意図があります。

多くの人に一斉に同一のメールを送る場合に、本来知るはずのない人のメールアドレスをメールの送信先として見えるようにしてしまったら、個人情報の漏洩と責められかねないので非常に気をつけたいことです。

一方で、BCCで送ったメールは、送り手にはBCCに記載したメールアドレス宛に送っていますが、受信者は自分のメールアドレスが宛先のどこにも書いてないのに届いた不思議なメールに見えます。

そのため、仮にその人が返信しても送信者だけに届き、全員に届くことはありません。

それを同じ情報が皆に届いているものと誤解してはいけません。

そのためにも、誰に送られているかということに日頃から注意する必要があります。

また、メールソフトはCCとBCCを間違えて指定しても注意機能などはないため、うっかり間違えてBCCの代わりにCCに記載すれば、メールアドレスが全員に見える形となり、いわゆる誤送信問題となります。

BCCは相手にメールを見せずに大勢に一斉に送れる点で便利ですが、一歩間違えるとメール誤送信問題になりかねませんので、慎重に利用しましょう。

社外秘の情報をやりとりする場合の添付ファイルの扱い

社内利用に限定された情報やプロジェクトの関係者だけにファイルを送りたい場合など、よくある方法としてzipファイルにして暗証番号を付ける方法です。

メールに添付ファイルを付けて送り、それとは別にパスワードを相手に連絡するという方法を採ります。

その際できるだけ別の手段でパスワードを送りたいものです。

ファイルを送ったメールへの返信でパスワードを送るのはセキュリティ的には感心しません。

また、別途新たに新規メールを作って送ることはよくやられています。

返信メールよりは良いかもしれませんが、可能であれば別の方法（電話やチャットツールなど）で送るのが良いでしょう。

また、その際使うパスワードは割と簡単なものを使う傾向が強いです。

それは、そのパスワードが一時的なものではなく、その後のやりとりでも使われる可能性があるので、なるべく思い出しやすいものにするという意図があるからです。

電話で伝える場合は割と簡単にしないとそれこそパスワードを伝えることも難しくなります。

悩ましい問題ですが、共有のパスワードは事前に決めておいて、ファイルを送信するときにパスワードをやりとりしなくてすむようにできればいいですね。

パスワードの管理

パスワードをあちこちのサイトで共通に使うなというのはセキュリティ上の基本ですので、必ず守った方がいいでしょう。

そうなると、パスワードを覚えておくことなどすぐに不可能になりますから、パスワードをどうやって安全に管理するか、ということが課題になります。

個人で利用しているなら、PCとスマホで共通に使えるようなアプリを利用するのがひとつの方法です。

BitwardenはPCでもスマホでも使えて非常に便利です。

無料でも使えますし、ファイルを保管できるようにしても年10ドルと非常に安価です。

それ以外にも、OSが標準で持っているメモ帳に記載する方法もあるでしょう。

ただ、パスワード管理ツールはパスワードを生成する機能を持っているものも多いので、重複しないパスワードを生成するには便利です。

パスワードを入力する場合、ほとんどコピペでできることが多いので、複雑なパスワードでも困ることはありません。

※まれにコピペできずに手打ちしなければならない場合があって、困ることはあります。

会社で使う場合は、スマホと同期する必要性がなかったり、したくてもセキュリティ上許されていない場合も多いので、基本的にはPC上だけで管理するものになると思います。

フィッシング等のメールを見極める

「ログインに失敗しました」「サービスが停止します。今すぐ更新を」などというメールを見て、ついリンクをクリックしてログインをしてしまうことがあるかもしれません。

メールでそういった連絡が来る場合、多くはフィッシングメールだったりするので気をつける必要があります。

フィッシングメールは実在するサービスに似せていますが、全くの別物でログインIDとパスワードが取得されてしまいます。

フィッシングメールの見分け方は、よく言われているものですが次のことが有効です。

• 送信者を確認する

ドメインなどがその企業のものかどうかを見ることが基本になります。

• リンク先を確認する

「ここをクリック」などのボタンやリンクがどこに飛んでいるかを確認します。

飛び先がやはり企業のドメインでは内などが見分けるポイントです。

• 言葉遣いの不自然さ

幸い日本語は難しく、翻訳ツールなどを利用して書いたメールでは所々おかしな文章になっていることがあります。

最近は翻訳の精度も上がっていますが、それでもおかしな箇所は見つけられますのでちょっとおかしいと思ったら疑うことが大事です。

一旦パスワードを取られると、その後の対応は面倒くさいの一言です。

あちこちのパスワードを変えないといけないし、その前にログインされて変更されてしまったら、目も当てられなくなります。

メール上の煽る言葉にだまされないようにしたいものです。

（改行）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

リスク管理を機能させる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次の段落の画像を入れる

まとめ

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

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

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

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