【新人教育】ＩＴってなに？ -2-
というわけで、２日目の内容です。
先にお見せしておくと、全体のストーリーはこんな感じをイメージしていました。
この図は新人たちには見せていません。たぶん、ここまでくると新人に伝えるには難易度高いかなと思って。もちろん、この概念図はあくまで私が考えるＩＴ業界のあるべき姿ですし、私の足跡上、エンタープライズ向け、あるいは公共セクター向けにやや偏っているのは否めません。
ですが、それでも「じゃあ、この考え方は他では使えないか？」と言うとそんなことは無いと思っています。言ってみれば、それぞれの業界、企業、現場ごとに比重の差があるだけで、基本の原理原則はどこも似通っていると思っています。
さて、では続きです。
前回は、「ＩＴとは」「情報とは」という点について触れました。ちょいちょい脱線はしましたが、プログラミングすることだけが仕事のすべてだと思ってほしくなかったんです。もっと視座を高く、視野を広く持って、この業界に確固たる足場を作ってほしかったんです。
さらにいえば、転職をするとき、なんなら他業界へと転職するとき、ほんの少しでも己の価値を高めてもらおうと思ったら、具体的過ぎる目先の目標だけを追いかけていても、なかなか難しいと思ったので、俯瞰して考えることができるよう、あえて「広く浅く」ＩＴについて説明しました。
新人がまず修得するべきは、コミュニケーションという名のＩＴ
２日目から、やっと新人向けにぐっと近づく話になります。テーマは「コミュニケーション」。多くの人がコミュニケーションと言うと、「話す」ことをイメージしてしまいます。既にその時点で『情報』を正しく取り扱えていない証拠です。
コミュニケーションはそんなやっすい技術ではありません。
まずは概念ですが、コミュニケーションは大別すると
「情報を伝達する技術」と「情報を共有する技術」
の２つに分かれます。これを理解していない人は、ＩＴのエンジニアとして、あるいは業界人としておそらく１流では無いかもしれません。
そうでないと言う方は、おそらくＩＣＴという言葉をご存じでしょうし、ＩＴとの違いを説明できるでしょうし、そのうえで「Ｃ」が何を意味する言葉なのか、その本質までご存じのはずです。
ＩＣＴとは、Information and Communication Technology（情報通信技術）の略で、海外ではＩＴではなく、ＩＣＴという言葉を使われるのが一般です。日本では、2000年11月にＩＴ基本法(高度情報通信ネットワーク社会形成基本法)が制定され、01年1月に総務省からだったかな？「e-Japan戦略」が策定された頃から広まった言葉です。
しかし、その戦略も含め、ＩＴ業界全体が閉塞的であまり変化を好まなかったのか、結局ＩＣＴという言葉はあまり浸透せず、ＩＴと呼ぶようになっていきました。
ですが、先ほども言ったように海外ではＩＣＴが広く使われています。
なぜなら、今どきスタンドアロンで使われるシステムなんてごくわずかしか需要はなく、どこもかしこもネットワークでつながり、通信…すなわち情報伝達が行われることが前提の技術ばかりになっているからです。
そう「Ｃ」を前提にした技術が世の中の大半を占めているのです。
そのうえで、「Ｃ」を改めて噛み砕いでいくとわかるように、Communication…コミュニケーションのことです。当然、話す技術ではありません。直訳では「通信」と言われていますが、究極的には
情報（Information）を伝達する技術
相互に情報（Information）を共有する技術
の集大成であることがわかります。
Informationの取り扱い方に長けた技術をＩＴと言うのであれば、その長けた技術を用いて、自分の中だけでなく自分以外の誰か、あるいはどこか、何かとの間での情報のやり取りについても長けなければならない…そのためのコミュニケーションなのです。
当然、「話す」⇔「聞く」技術もコミュニケーションの１つです。同時に「書く」⇔「読む」もコミュニケーションの一つでしょう。実現手段などアイコンタクトでも、モールス信号でも、手旗信号でもなんでもいいのです。要するに「情報が正確に伝達されること」「伝達された情報が、劣化・欠損なく相互の共有されること」、この２つの要件さえ満たせれば、なんでもかまいません。
ただし、相手ありきの技術ですので、相手を無視すれば、当然失敗します。
大人がビジネストークを３歳の子供にしても通用しないのと同じことです。相手の受信プロトコル（理解できるレベル…と思ってください）と自分自身の送信プロトコル（理解させられるレベル…みたいな感じ）が一致しなければ、コミュニケーションは成立しません。成立しなければ、波長のあわないラジオを聞くような不快感や不明感を感じることになります。
日常のコミュニケーションもできず、その仕組みもわかろうとせず、だけどソフトウェアや通信の仕組みだけ理解できる…本当にそんなことが可能でしょうか？
私は、ソフトウェアや通信の仕組みを初めて理解した日、「あれ？これって人間の会話とかと同じじゃね？というか、人間が考案したんだから日常の何かをモデリングするよな…あ、そういうことか！？」って思ったものです。
だから、ＩＴを正しく理解しようと思ったら、その中でも特に親和性が高く、今やそれなしではＩＴ業界が成り立たない「コミュニケーション」から理解した方がいいのです。それに、通常のビジネスコミュニケーションができなければ、遅かれ早かれその新人はビジネスパーソンとして詰みます。
先日もお伝えしたように、ＩＴ業界において、プログラミング技術だけでビジネスは成立しません。ビジネスを成立させるためにプログラミング技術は必要条件ではありますが、十分条件にはなりません。
ビジネスとして成立させるためには、絶対にコミュニケーションは欠かせません。これも必要条件の１つです。
５～10%と言うのは、あくまで今いる会社での話ですが、市場全体で見るともっと高いと思います。なにせ、プロジェクトの失敗の原因の大半に、「コミュニケーション」が関与しているのです。
もしも、全てのコミュニケーションにおいて成功を収めていれば、今現在起きている世のなかのトラブルプロジェクトの９割が、失敗を起こさずに済んだかもしれないのです。
この図は10以上前の古い情報を元にしていますが、あえて持ってきたのは「アジャイルによる判断しにくい成功率」分を除いた数字として、今も昔もさほど変わらないと、経験則で感じているからです。
アジャイルの場合、非常に短いサイクルでリリースが行われるため、品質的に仮に問題を発見しても、運用上に支障が無ければ、次のリリースで改修すればよかったりするので、全体的に成功率が高く見えがちです。
また、一つひとつのサイクルを短くするために、イテレーションごとの規模を小さくする（数週間から２～３ヶ月程度）関係上、全体を見渡しやすく、失敗も起こりにくいと言う特性を持ちます。
これに対して、エンタープライズ向けのシステム開発は「億単位」「１年以上」の規模は当たり前で、中には100億を超える開発プロジェクトと言うのも珍しくありません。私自身、最低でも３度は何らかの形で参画し、経験しています。
そういったプロジェクトでは、今も昔も変わっているように見えません。
変わった…とすれば、ほんの少しだけ「論理的」な会話ができるようになったくらいでしょうか。
で、それらの失敗プロジェクトは、その原因の大半が、どこかにコミュニケーションの問題を抱えています。
たとえばこの記事の場合であれば
というように、工程…フェーズごとの分類がなされていますが、
要件定義
・報連相の基礎スキルを駆使したインタビューと情報共有が
しっかりできて、認識齟齬が起きていない
設計
・要件定義で決められた内容が正しく落とし込めていない
・ドキュメントに「書く」と言う作業が十分条件を満たせていない
・ドキュメントを「読む」能力が不足している
製造（…実装？）
・設計で決められたとおりに忠実に翻訳（読むことが）できていない
テスト
・設計内容を正しく理解できていない
・テストケースが「読み手に負担をかける」書き方になっている
と言ったように、コミュニケーションのノウハウさえ十分にあれば解決できたであろうポイントがひしめき合っています。もちろん、うっかりやコミュニケーション要因以外の問題もあるのかもしれませんが、総合的に見れば、おそらくコミュニケーション起因の問題ばかりが目立っていることでしょう。
この記事でも、
・関係者とのコミュニケーション不足：55.9%
・プロジェクトマネージャーの経験不足：32.3%
→…によるコミュニケーション不良
・成功の定義が不明瞭：28.5%
→…によって、大事なコミュニケーションそのものが不成立
・非現実的納期の要求：22.8%
→…に対して、相手を納得させられるコミュニケーションができない
・ＫＫＤ（勘・経験・度胸）だけでの業務遂行：22.1%
→…言語化できないスキルに頼り、コミュニケーションを阻害する
など、多くは必ずコミュニケーションの課題が見え隠れします。
この記事でも、
・不十分な要件定義：50%
・コミュニケーションの問題：15%
だけで、65%がコミュニケーション起因であろうことが予想できます。
私が資料に載せたのは最もシンプルなものですが、それでもまぁ似たような傾向が見て取れます。元々は「人間力の欠如」と書かれていましたが、ヒューマンエラーの大半はコミュニケーションに依存するものなので、あえて「コミュニケーションの欠如」と書き換えています。
また、「マネジメント力の欠如」とありますが、プロジェクトマネジメントの中でも、国際標準であるPMBOK（ISO 21500）に照らし合わせて考えれば、その中の"コミュニケーションマネジメント"にも大きく原因はあったのでしょう。
なにより、どんなにプログラミング技術やエンジニアリング知識を磨き、鍛えたところで、
起きている問題のうち、たった12%しか解決できない
という点に注目しなければなりません。事実から目を背けずに、しっかりと判断するのであれば、むしろヒューマンスキルの方がずっと大事だと言うことがこのことからもわかります。
もしも今起きている失敗やトラブルを無くせたら
もし、もしもですよ？
仮に『これらの失敗をすることがなかったら』この業界はいったいどれだけの市場を改善できたのでしょうか。
たとえば、１億のプロジェクトで、「10%の利益」を目標とした見積りを行ったとしましょう。利益1000万です。ですが、奮戦空しく、-1000万の赤字となってしまいました。
もしも、失敗させなければ、企業としては1000万の黒字経営となっていたはずなのに、-1000万の赤字にしてしまったのです。この時、計画比としては…-2000万の利益となります。言い換えるなら、計画通りにしようと思ったら、別のプロジェクトで余計に+2000万の利益を稼いでこなければならないということです。
しかも、順調に進められていれば+1000万だったところ、その予測よりも2000万つかってしまったわけですが、こんな大金を何に使ったのかと言うと、それはもちろんその多くが人件費になっていることでしょう。そう、予定よりも2000万分多く働かせていると言うことです。
この時考えられるのは、
・人員を増やす
・残業を課す
・スケジュールを延期する
ですが、「人員を増やす」「スケジュールを延期する」場合は、その間のほかに予定していた作業を中断、あるいは破棄せざるを得ないため、その間の売上も減ります。2000万分の作業を課すわけですから、売上が単純に2000万減るということになります。その売上から得られたであろう利益も入ってきません。
もちろん、その対応に当たっている間、参画しているメンバーはほかの仕事をさせられないと言うことなので、受注量にすら影響が出てきます。
利益：計画比-2000万（＋売上が減った際の利益率分の減）
売上：-2000万（2000万規模分の要員が投入されている間の作業減）
受注：-2000万（2000万規模分の要員が投入されている間の受注減）
ちょっとしたトラブル、失敗でこれだけの影響が出るのです。
もしも、コミュニケーションを改善することで、多くの失敗を解決できたとしたら、いったいどれだけの「売上」「利益」に還元できたでしょうか。
今いる会社であれば、およそ利益率が倍になります。失敗が無くなり、スマートに仕事ができて、残業の多くも減れば、もっとコストカットできるでしょう。
そもそも利益が今の状態でも、普通にボーナスが支給されていて、ここ数年が業績もいいからと年３回分相当のボーナスが支給されていました。それが倍になれば、（設備投資や事業投資が無ければ）ボーナス６回分くらい支給されてもおかしくないと言うことになります。
まー、そんな単純計算にはならないでしょうけど、実際問題としてそれが可能な水準になると言うことです。
重要なのは「共有する技術」
先述の通り、コミュニケーションは
「情報を正確に伝達する（される）技術」
「伝達された情報を互いに共有する技術」
に大きく分かれます。どちらか一方が未熟でも、残念ながらコミュニケーションは成立しません。ですが、どちらの方がより大事か？というと、ことに本というお国柄を考えた場合、それは
「共有する技術」
であると言えるかもしれません。
あらためて言いますが、「伝達する技術」が要らないとか、優先度が低いとか、そういうことを言っているわけではありません。
たとえば、このように、どんなに話す技術や書く技術があったとしても、聞く技術や読む技術が同じ水準に無いと、結局コミュニケーションは低い方の割合しか伝わりません。もし、上図のように40もの情報を劣化、あるいは欠損させた状態で、受信側がわかった気になって作業を始めてしまうと、問題だらけ、バグだらけのソフトウェアが出来上がっていることでしょう。
もちろん、放置はしておけませんが、日本の場合、「忖度」や「空気を読む」「行間を読む」と言った受信側に負担を強いる民族文化を持っています（良くも悪くも）。その結果、全員とは言いませんが、多くの人がある程度は脳内補完できるようになっているのです。
そのため、上図のような場合でも、実質40もの開きはなく、10～15は勝手に埋まってしまいます。あとは、ビジネスで慣れてくれば、わからないところは質問等も行うでしょう。完全に一致するレベルまで補完することは難しくても、ある程度のレベルまで引き上げることが可能になります。
それよりも問題は「共有する技術」です。
上記の「忖度」や「空気を読む」「行間を読む」が良い方に傾く限りは問題ありません。ですが、共有という課題に対しては、これが裏目に出やすいのです。
たとえば、設計書に
「〇〇ボタン押下時、正しく動作する」
と書かれていたとしましょう。私の立場上、そんな書き方した奴は一度締めあげなければならないと思ってしまうところですが、それはまぁ置いといて、この文言に対して、プログラマーが勝手に忖度をして設計者の意図を汲み取り、
「あぁ、あぁ…そういうことね」
と言って理解した気になり、作ったプログラムが、設計者のイメージ通りとなっている可能性はいったい何％あるのでしょうか。ゼロではないでしょうが、決して高くも無いと思います。
そして、さらにそれを時間軸で見た場合はどうでしょう。
送信者と受信者、設計者とプログラマー。相互の間で共有した情報は、１ヶ月後、半年後にまで、劣化、欠損することなく、互いに共有されているのでしょうか。
どんなに正確に伝わったとしても、共有されていなければ、イメージとは異なる物しか出来上がりません。特に、複数の答えを解釈できてしまう、あるいは複数の選択肢を与えてしまうようなコミュニケーションでは、想定したものとは違う結果になっていたことが、必ず１度や２度はあることでしょう。
このゆるゆるの蛇口のようなコミュニケーションを何とかしないと、チームワークがうまくいくことはありません。
ここまで言っても、『コミュニケーション＝話すこと』と言うバイアスから逃れられる人は多くありません。だから、教育されたことを意識せず、なんとなく日々仕事をしだすと１週間もしないうちに、コミュニケーションが疎かになると思います。今まで通りの自分に戻るだけです。
運よく、それでうまくいってしまったりすると、その後うまくいった時の何十倍もの失敗をするとしても、忘れるのです。
同じ「情報」が共有できないコミュニケーションはゴミ以下
他人とコミュニケーションをとる以上、「情報が正しく伝達されること」と「伝達された情報が共有されること」のこのセットが成立することは重要です。
少なくともビジネスコミュニケーションであれば、必須です。
伝達齟齬、認識齟齬があって、それでも問題が起きないビジネスなんてものは存在しません。だからこそ、齟齬を起こすようなコミュニケーションには価値がないし、汚物 of 汚物でしかありません。
新人たちには、
「じゃあ、どうすれば自分が伝えた内容が
相手に100%正確に伝わった（共有された）と判断できる？
客観的に『確かに伝わってる』と確認できる方法は？」
というテーマで２人１組で話し合ってもらいました。この具体的方法がわかっていなければ、結局実務では何もできないからです。
一番簡単なのは
「相手に具体的な事例（たとえ話）を説明してもらうこと」
です。オウム返しの返答なんていりません。本当に理解しているのであれば、具体的な事例の１つや２つ出てくるはずです。
以前もお伝えしたように、人の学習定着率…すなわち理解の進行度合いは、上図のようになっています。なかでも定着率90%といわれているのは、「人に教えること」「他人に説明すること」です。
これを実際にやってもらえれば、伝えた情報が共有されているかどうかを確認することが可能です。
ただ、問題は「時間軸上の共有」で、記憶に頼った共有はどうしても信用できません。
エビングハウスの忘却曲線でも言われているように、「人の記憶力」というものはあまり信用に値するものでは無いのです。
ですので、その場で行えるようなものでは無く、ある程度の時間経過を見込んで共有が維持されていなければならないような場合は、「記録化」…すなわち、新人が先輩や上司からよく言われる「メモを取る」ことが重要になってくるわけです。
それさえ行っていれば、いつでも「共有情報」を見直すことが可能になります。
コンピューターの仕組みと同じですよね。
メモリとストレージ(SSD/HDD)があるのは、脳とメモがあるのに似ています。メモリや脳記憶は、処理速度は速いかもしれませんが、シャットダウン（就寝）すれば情報が消し飛びます。ですが、ストレージやメモは、シャットダウン（就寝）しても情報が消えません。
元々、人間が作ったものは、人間が実体験した日々のなにかをモデリングしたものが多いですよね。コンピューターの仕組み自体も、人間そのものを模したものが多いのは自明です。
「情報」を共有する技術にすんごいスキルはいらない
ホント、それだけです。
過剰に努力する必要はありません。相手との水準が合いさえすれば、それ以上である必要性はまったくありません。相手が60なら、同じ60に。相手が30なら、同じ30に合わせる。その必要最低限の努力をするだけです。
たまに、専門用語をまくしたててお客さまを置いてけぼりにするＩＴエンジニアやＩＴ系営業、コンサルなどを見かけますが、これは
相手の受信プロトコルを無視して、送信側の都合を押し付けようとしている行為に他なりません。コミュニケーションとしても３流ですし、インターフェース定義のあり方としても最悪です。
以前お伝えしたと思いますが、インターフェース（接点）の設計でルールを決めることができるのは、受信側、呼び出される側です。
ライブラリやＡＰＩは自分たちが使ってもらう側、呼び出される側だからこそ、「こういうルールを守って呼び出してね」と言うことができます。送信側、呼び出す側に、パラメーターやルールをどうこう言う権限はありません。
WEBでもそうですよね。URLを指定できるのは受信側、呼び出される側であって、呼び出す側に「こういうURLにしろ！」という権限はありません。
電話もそうです。電話番号を指定できるのは、受信側、呼び出される側であって、呼び出す側に「この番号は気に食わん！ほかの番号に変えろ！」という権限はありません。
こういった、ビジネスを含むすべてにおいてのインターフェース定義の常識を知らない、コミュニケーションの３流がたまにやるのが、この「相手を置き去りにする会話」です。
「情報」を共有するための共通点
結果、ＩＴ（情報を取り扱う技術）、そのなかのコミュニケーションにおいて、新人がまず修得すべきは、基本にして究極とも呼べる
この４点ではないかと思うのです。
①「共有できた」と言う確証を互いに得る
先ほども言ったように、相手が正しく共有（理解）したという確証を得ましょう。「相手に具体的事例を説明してもらう」それだけです。自分が共有する側なら、説明するだけです。できるだけ、具体的にイメージできるたとえ話にするのがいいでしょう。２つ３つ用意できれば、なお良しです。
②定期的に「共有できていること」をチェックする
これは「エビングハウスの忘却曲線」における解決法にも出てくるように、反復して脳に刺激を与えることです。
完全に忘れてしまう前に、「忘れそうかも」というタイミングで思い出させるわけです。そうすれば、定着率は徐々に向上します。より長期のあいだ、共有しやすくなります。
③記録化する
記録さえすれば完璧、というわけではありません。記憶と記録は両方必要です。新人の頃を思い出せる人ならなおさらわかると思いますが、「メモを取ったら、取りっぱなしで二度と確認しない」なんてことはよくあることです。
メモは具体的な内容を記載しておき、脳記憶にはその目次（５Ｗ（なぜ、いつ、だれが、なにを、どこに））を紐づけておくのが理想です。どちらが欠けても上手くはいきません。
④２人（当事者間）だけの共有にしない
これは、「脳（記憶）」でも「メモ（記録）」でもなく、「気持ち（心）」の問題に対する解決法です。心は、思考とは別の観点から、物事を軽く見てしまったり、重く見てしまったりしがちです。
それにより、「まーなんとかなるべ」とか「大丈夫、大丈夫」なんて軽く考えてしまうと、その心のせいで、ビジネス的な重要度が下がってしまったりすることも多々あります。
この時、当事者間だけでなく、第三者を巻き込んでおきましょう。
メールにせよ、打ち合わせにせよ、よほど『責任』意識をコントロールできるようにならない限りは、当事者間だけのやり取りにしないことです。
可能であれば、『決裁者』を巻き込んでください。要するに財布を握っている人です。
これは、仕様変更や作業依頼などをいただいたときに、よく起こるコミュニケーショントラブルの１つです。
お客さまの担当者（主任～係長クラス）から、ちょっとした作業や仕様変更などを依頼される…と言うのはよくあることですが、ＩＴ企業側のエンジニアの多くは、これを「お客さまからの正式な依頼」と思って、ﾊｲﾊｲって言いなりになりがちです。
その追加作業で、経費が発生し、後々追加請求したとき、お客さまの決裁者がそのことを知らずに、追加請求されたのを見て、激怒する
…このシチュエーションは、毎年全国で何百件と起きている鉄板トラブルです。そもそも、主任や係長など、管理職未満の役職者には、決裁権そのものが与えられていない企業がほとんどだと思います。にもかかわらず、当人の勝手な都合で、計画に無い作業を依頼し、ＩＴ企業側と最後になってから揉めると言うのは、10のプロジェクトがあれば１つや２つは見かけるんじゃないかってくらいよく起きます。
この手の問題は何か月も引きずるうえに、お客さまを納得させるために記録類を整理したり、証明するための資料を作成したりと、余計な作業が増えて、結局「請求できた」としても、それ以上に無駄な作業が発生して、赤字になった…なんてことも珍しくありません。
そうならないようにするために、本来は
変更管理や変更依頼管理といったマネジメントをするべきなのですが、多くのリーダー、マネージャーはあまりそういった活動を「面倒」としか思わず、しっかりしようとはしないため、いつまで経っても問題が解決されることはありません。
新人たちは、若いうちからこうした問題を起こさない体質を作るため、『第三者（できれば決裁者）を巻き込む』と言う癖をつけておくことをオススメ勧めします。
まとめ
とにもかくにも、色々長々と説明してきましたが、重要な取り組みは最後の４点だけです。
長々と話したのは、「なぜそこに帰結するのか？」を理解してもらうためにすぎません。もっと言うと、別に理解は求めていません。「してくれるといいなー」とは思っていますが、理解しなくても、なんとなく『納得』が引き出せていれば十分です。
もちろん、他にも学ぶべき具体的なことは多々ありますが、それらは所詮「手段」の１つでしかありません。本質的な解決にはなりえません。
１年後の最終的なゴールを見据えた時、どのような業務、どのようなシチュエーションであっても、これら４点が成立するような取り組みができていれば、失敗を起こす確率は少なく、圧倒的なパフォーマンスが出せているのではないでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。