へんな思い込み

無くすと仕事は早く終わるようになる。

プログラム作成中に手が止る。
(´-`).。oO(あれ？これってどっから取得すりゃいいのだ？)
(´-`).。oO(この処理の前にこんな判定してるけどなんだったっけ？)
(´-`).。oO(いままではこの方法だったけど、ここで使っちゃだめなんだったっけか？)
等々。
仕様がらみ、制約がらみで悩める材料はいっぱいある。

そこで。
解決方法模索のための第一歩。
例題。

例えば、仕様でわけのわかりにくいところがでたとする。
どういう選択をするのが早く終わりそうか？
　(1) がんばって自分で考える
　(2) わかりそうな人に聞きに行く
　(3) 放置する
　(4) 仕様を知っている人に確認しに行く

いうまでもなく4番である。
(1)はどれだけ自分が正確なことを知っていると思ってみても、
最終的に確認を取らなければ、それは推測憶測の域をでない。
万が一うまくいくかもしれないが、我々の仕事に求められるのは
万が一の成功ではなく、安全確実なそれである。
無駄を作成する可能性は高いのだ。
(2)はほぼ正解である。
ただ、何の用意もなしに聞きにこられても、
その人がこまる。
何を聞かれているのか？何を求められているのか？が
見えにくい場合があるからだ。
それよりも安易に聞きにこられすぎると、
その人の手が止まることが多くなり、
決して歓迎されることではなくなるのは注意するところだ。
(3)。最悪の選択肢であることだけは間違いない。
で、最後に(4)。
ポイントは「確認する」っというところ。
何を確認するかというと、自分のわからないところである。
そのわからないところが確認できるということは、
その聞くべきポイントと前後が確認できそうな資料は用意している
というところに妙がある。
用意してあれば

　　( ´Д｀)/先生！　これこれはこんなんでいいでつか？

と聞ける。
yes/noで答えられるなら即座に終わるし、
補足ポイントがあればより深く情報が得られるかもしれない。
両者に勘違いの要素がどの選択肢よりも少なくなるので、
確認ポイントのズレや、両者の認識のズレも少なくなるって寸法である。

資料整理の回でもふれたけど、
自分のわからないようなわかりにくいようなポイントをまとめる作業。
これは多少時間を割いてもやっておくほうがいい作業なのだ。
単純に回答をもらえるからだけじゃない。
自分の中での再整理ができるし、
なにより質問するときのポイントが明確になる。
自分が混乱している状態で( ・ω・)∩シツモ-ンを投げても
相手がわかってくれることはない。
(,,゜Д゜)＜何を聞きたいのかがわからんぞ
っと言われるのがオチなのだ。
そうならないためのちょっとした時間。
これは無駄ではない。
それに、この作業を繰返しているうちに慣れてくる。
初めてやってみたときにはえらい時間がかかったかもしれないが、
何度もやっているうちに、手を抜けるところがわかってくる。
相手にわかりやすく、自分も楽に質問用資料集める。

これになれてくると、
もはや自分ひとりで考え込む時間が無駄に思えてくる。
ちょっと悩ましかったらちょちょいと資料作って聞きに行く。
これが手っ取り早くなってくる。
作業がさくさく進むし、同じようなところで悩む同僚がいた場合には、
その資料を元に自分が説明してあげることもできる。
こうしてコミュニケーションの機会がプロジェクトの中で増えていくと、
情報が集まってくるようになる。
そうすると、知らないから悩むなんてことも無くなって来る。
解決策は誰かが知っているって状態になってくる。
お互いがお互いをフォローできるような関係になっていく。
良循環がここに完成するのである。
( ・ω・)bグッ

でもひとつだけ問題がある。
自分自身が頭を使わなくなってくることだ。
なんだか自分がだんだんアホになってきているように感じている。
深く物事を考えられなくなってきたかもしれない。
やばいやばい。(;´Д｀)