仕事してて思ったので書いてみる。
自分も昔はこうだったなぁとか思いつつ。
ある物事について、
知ってるとか分かってるとかいろいろ理解度を示す言葉はあるんだけど、
あ、それ知ってるとか分かってるというので任せてみたら失敗するケースがやっぱりある。
まぁ相手の言葉だけを鵜呑みにしてたらこうなるので、「コイツ本当に分かってんだろうか」と確認の意味を込めて、
理解度を3段階くらいに分けて仕事するようにしたらまぁマシになった。
相手がどういう認識なのかをしっかり確認したほうが仕事も手戻りなく、変なミスも減るのでいったん整理。
で、相手の理解度に合わせてどういう対応が必要かも合わせて整理してみた。
【Lv1】聞いたことがある
理解度Lv1。
とある物事について、言葉としては聞いたことがあるレベル。
内容についてもなんとなーくは頭の中に入っているって状態。
ただこのレベルだと会議に同席させて議事録書かせたりすると支離滅裂な文章が出て来たり、何故こういう経緯になったのかまではやっぱり説明できない。
まずその言葉が何を指しているものなのか、関連する用語は何があるのか等、資料を読ませて疑問が無くなるレベルまで教育してあげるがよろし。
そしたら後述の「知っている」レベルに上がるはずだ。
【Lv2】知っている
理解度Lv2。
とある物事について、言葉としては知っていて、かつそれが何を指しているのか、どういうものなのかはなんとなく言える。
資料用意してあげればプレゼンだけはできるけど、質問対応等で、応用ケースというか前提条件等を少し変えた場合には回答が怪しくなるレベル。
このレベルだと周りの人間と一応会話が成り立ってることが多い。
けど、具体的に物事を考えられていなかったり、表面的な理解に終わっているケースもある。
（例：〇〇ボタン押したらクライアント内の動画データを送るっていう仕様は理解してるけど、どうやって送るのか？とかその技術、仕様で本当に送れるの？とかは理解してないとか）
やっぱり不安は残るので、関連用語も含めて知っている状態まで理解度を上げるとか、例えば技術用語であれば、何故こうなっているのか？
といった理屈含めて分かる状態に仕立て上げないといけない。
何故？それはどういう意味？具体的に言うとどうなるのか？と、面倒くさいけどひたすら問うていくつらいフェーズになるけど。
【Lv3】理解している
理解度Lv3。
とある物事について、関連用語含め知っており、多少前提条件が変わったり応用的な使い方をした時にどうなりますか？
という質問をしたら、すぐ返ってくる。
または分からないにしろ、仮の前提条件を置いて、〇〇なのでこうなると思います。
といった回答ができる。
ここまできたら担当として安心して任せられるかなーって感じです。
知ったかぶりが一番やばい
で、稀に知ったかしてるケースがある。
仕様書とか書かせて内容確認してて、あれ？と思った部分について説明を求めると
いやそれ全然違うし・・・
とか、〇〇APIを使えばできる！とか言うので、前提条件とかないの？と聞くと
「それは知りません」と・・
情報システムのプロジェクトマネジメント的にはこういうのが一番やばい。
システム開発って端的に言えばルールや論理の集合体を矛盾なく創り上げることなので（予算と工期の範囲内でね）、
不確かな理屈に基づいて仕事をすると高く積み上げた塔の土台から崩れてしまうことにも繋がりかねない。
知らないことは別に悪いことじゃないので、嘘はつかないでほしい。
おわりに
とか書きながら自分も知らないことなんてまだまだあるし、何もコンサルの領域から技術的な深いところまで理解するというつもりもない。
ただ、仕事に応じた物事の理解度というものが求められていて、
- 今どういう知識が必要か？
- 仮にそれを後で学習したとしたらどういうリスクがあるか？先に一人学習させておいたほうが学習効率は高いのでは？
- このAPI採用してできますって言ってる部分、実は無理でした とかならないよね？
っていうリスク管理の感度や生産性をどう上げていくか、いい意味でのさぼり癖といったパーソナリティー的なところがしっかりしてるかどうかって部分は、
物事の理解度以前にさらに大事なことなんだろうなと思った。
いやいるんだよ言わないと勉強しないし実際やり出してから
「分からないので時間がかかります」とか平気で言う人。
先に言えって話だよ。
余談だけどこういう部分の出来不出来はマジで学歴に比例してるんじゃないかと最近思えてきた。
そんな感じ。
