新人OJTネタです。
最近、開発項目の検討を部下の研修員に割り振って、その結果のレビューを行なっていますが、その際に起きたのが『物事を極端に解釈してしまう』ということ。
■ 一つの指摘ですべて破棄
どういう対策案があるかの案レビューをしている時のこと。
この案では、メリットはあってもデメリットが大きいよね？という指摘が上がりました。
結局、どの案もそのままではダメだということになり、打ち合わせは終わりました。
そして、次の打ち合わせの時に、上がってきた資料を見ると、前の打ち合わせで出していた案がすべて消えていて、別の案が思いつきませんでした…という状態に陥っているようでした。
前の案は？と聞いてみると、
指摘があったので、その案はダメだということで、廃案にした
ということでした。
いやいや…
「案に対して指摘は出ましたが、１つ指摘されたからといって、その案をいきなり廃案にする必要なんてないじゃないんですか？」
というと、「そうなんですか？」という応答。
指摘された箇所に対してブラッシュアップとかではなく、１件でも指摘されたらもうダメだという解釈をしたのか…まではわかりませんでしたが、そこまで極端な判断はしなくてもよさそうなものですが…。
■ 必ず最初から最後まで順番に全て見る
他にも、そもそもの背景や仕様について理解しているかが疑問だったので、色々と質問してみました。
結果、う〜ん・・・という感じ。
こういう時の定石としては、やはり動かしてみたり、その動きがどういう実装になっているかをソースを見て調べてみるといいんですが、全然やれていないようなので、やってみようというように提案しました。
そこで嫌な予感がしたので、一つ質問を…。
「ソースを見るのにどれくらいかかりそう？」と聞いてみると、全体規模がわからないですが、多分１〜２週間かかりそうです・・・のような返事。
これには流石にびっくりです。
なんでそんなにかかるの？どうやってやるつもりなの？と聞いてみると、
「ソースを最初から最後まで見ていくつもりです」
という回答が…。
いやいやいやいや…調べるのに１step１step最初から最後まで見ていたら、何日かかるかわからないでしょと。
そもそも全stepの実装を理解したところで、今回の問題に関係ある部分はどれだけあるんだと。
アプローチとして、こういう問題があるから、その部分はどういう実装になっているか？を調べて、そこの実装を見たときにその前後の処理を見ないとダメだったら広げていく…という感じにするべきですね。
こういった最初のとっかかりからいきなり100点を取るのは正直言って難しいです。
もちろん、最終的に100点を取ることはできないこともあります。
それなのに、最初の手探りの段階で、
- １つでも指摘されたから諦める
- 全てを理解しないといけないと思い込む
と極端に考えるのはやめるようにしたほうがいいですね。
前者は、アイデアが広がったり、ブラッシュアップするチャンスを失いますし、
後者は、別の案になったときに、そこに全力をかけた時間が全てパーになってしまいますので…。
