オルタナティブ・ブログ > 一般システムエンジニアの刻苦勉励 >

身の周りのおもしろおかしい事を探す日々。ITを中心に。

わかりませんと言うには勇気が必要

»

わかりませんということを言うには勇気が必要です。

馬鹿にされないか
質問相手に手間・時間をかけてしまわないか
評価が下がらないか

そういった心配をしてしまうこともあるかもしれません。

わからないという状態も本当にわからないと
わかっていないという事実を自分自身で認識できません。
そういうのってなんとかって言うよね?と奥さんに聞いたところ
「無知の知でしょ。今のあなたみたいな知ったかぶりな様子。」
という厳しいひと言をもらいました。
さすが文学部の前に第一とかつく人は違いますね。
失礼しました。商学部でごめんなさい。

私は無知の知の詳しい意味を知りませんので、脇に置いときます。
これから先の人生で脇から取り出してくることは無いでしょう。

さて、わからないという状態には3つくらいの段階があるように思います。

  1. わからないことを本人も理解していない
  2. わからないことは認識しているが、どこがわかっていないか理解していない
  3. わからないポイントを自分で把握しているので、的確に質問できる

冒頭にあるように、「わかりません」という質問を躊躇してしまうのは
2の状態、「自分はわかってないなぁ。でも何がわからないかもわからんなぁ。」
という気分の時かと思います。

昨日もこの2つのリンクを紹介させていただきました。
2日連続でリンクを貼って恐縮なのですが、

教育と訓練は違う・・・【人的資源管理入門】

Whatを教える訓練、Whyを教える教育

の2エントリはこのあたりのところを解決するものであると思います。
何をすればうまくできるか、は訓練で解決できます。
なぜそのようになるのか、は教育で解決できます。

それを踏まえて、上で取り上げた3つ目の点
「わからないポイントを自分で把握しているので、的確に質問できる」
に関しては少し違った捉え方ができそうです。

自分でどのへんがわかっていないかを認識しているため、
「そこには手を出さないでおこう」と注意することができます。
そのおかげで「よくわかっていない」事も習得する事ができます。
上のリンクに例えると訓練だけを受けて教育を受けていない状態です。
ブラックボックスをブラックボックスのまま飲み込んで消化した、とも言えます。

たとえば設計がよくわかるSEさんが設計書を作りました。
実装のところはSEさんがやるとNullPointerException(ぬるぽ)
が出たりしてボロボロですが、PGさんに任せるとスムースに行きます。

一方PGさんは設計書を作るには色々と足りない知識があります。
しかし設計書に基づいて美しいソースを書くことができます。

どのようにソースコードに落ちるか見届けないと不安で仕方ない人は
設計だけやるタイプのSEには向かないですし、
設計段階でどのようにしてその設計になったのかということが
気になって仕方ない人はコーディングだけやるタイプのPGには向かないです。

高校生がやるような数学だと、教科書を見ながら自分で一度証明してみたけど
自力では到達不可能な公式などがあります。でも使ってしまいます。
そのように割り切った処理は人間が備えるコンピュータよりも優れた機能の1つと言えるでしょう

そう考えると、わからないポイントさえ把握できているようであれば、
わからないところを無理に解決することも無いように思います。
ただしそのことで危険が起きそうだと感じる部分については
調べるなりわかっている人に聞くなりして学習を深めます。

この「危険そうだと感じる部分」を見抜く力と言うのは
SEにとってかなり重要な能力です。
SEにはレビューと言う大切な工程がありまして、
自分の力では見つけることができない欠陥を他人に見つけてもらうものです。

無限の人員と無限の時間があればどんな欠陥も見つかると思いますが、
現実には有限の人員と有限の時間で実施して最大の効果をあげなくてはなりません。
そこで自分が前もって「このへんは危なそうだ」というポイントをピックアップして
「特にこのへんを注意してレビューに参加願います」ということを周知しておきます。

その事に関してはオルタナティブ・ブログの森崎修司の「どうやってはかるの?」に、
設計レビューをどうはかるかという素晴らしいエントリが掲載されています。
いつもだらだらと写経のように長いエントリを作る私にとっては
到底到達不可能な美しいエントリです。初めて見たとき感激しました。
(こういう文を挟むからいつまでたっても文章が終わらないのでしょう。)

このようにレビューをする人(レビューア)にレビューしてもらう人(レビューイ)が
「このへんが怪しいと思います」ということは勇気が必要です。
自分の弱点と向かい合う形になりますし、突っ込みが集中して精神的につらいかもしれません。
「自分で怪しいって思ってるならてめぇで直してもう1回持ってこい」という方もおられるでしょう。

それでも効率良くレビューをするには、自分が技術的に不安があるポイントや、
システム全体の急所になるような重要なポイントを把握しておいて
レビューアの皆さんに集中的に確認していただくことが必要だと思います。
そうすることで、レビュー対象の全体を漫然と見る場合よりも効率的なレビューができます。

視点を新入社員の教育の場面に移してみますと、
自分がわかっていないということを悟られないように
「わかったふり」をしてしまったりしていないでしょうか。
聞くは一時の恥、聞かぬは一生の恥と言う言葉があります。
わからないところがあったら恥ずかしがらず、迷わず聞いてください。
そのときに「自分はこのへんがやばい」と申告してもらえれば満点です。
そのことで効率的に弱点を克服できれば、他のもっとおもしろいことや
もっとためになることを教えてあげられる時間ができるかもしれません。
そのような関係を築く事ができたらお互いに良い経験になると思います。

私もさきほど無知の知って何?と聞いてぼろかす言われましたが、
おかげでこのブログに「無知の恥」と書いてしまわずに済みました。
冗談抜きで無知の恥なんだと思ってました。本当によかった。
でも面と向かって言われると私もつらいのでgoogle先生に聞けば良かったと思います。

Comment(2)

コメント

はじめまして。

ご紹介いただいたことに(かなり遅ればせながら)気づきました。ありがとうございます。いつもタイムリーかつ趣向が凝らされた(奥様ご執筆のエントリ等)エントリを拝見して勉強になるなぁと思いつつ、全てのエントリに追いついておりませんでした。ご紹介いただいた文脈に恥じぬよう精進いたします。今後ともよろしくお願いします。

森崎さん、コメントありがとうございます。
今日もちょうど設計レビューを行いました。私のところではISO9001ベースで品質管理を行っており、レビュー指摘件数の目標や、その記録などを残しております。スケジュールがタイトだと品質記録をつけることも「やらなきゃいけないから」というマイナス思考になってしまいがちなのですが、森崎さんのブログを見ると開発しながら記録を残していくことの大切さを実感することが多いです。
ちなみにうちの奥さん(SEを育児休業中)も睡眠時間やミルクの回数などの育児記録を精密につけています(笑)
こちらこそ今後ともよろしくお願いいたします。

コメントを投稿する