事の起こり
以前いた現場で、「JavaのSimleDataFormatって、この仕様の場合どう使えばいいんですかね？」という質問というか雑談をされた。
ほんなら別クラスで試してみたら？
使ったことのある人ならばわかると思うんですけど、あれの使い方、ソラで出てきます？
「これで合ってるだろ」でいきなり実装に入れて、本当にそれ思った通りの動きします？
テストする段階で、うわーもっとちゃんと調べとけばよかった！ってなるより、個人的には「別クラスでmain作って、そこでサンドボックス的に試す」ほうがいいんじゃないかと思います。
だって、そこコケたり想定外の動きしたら、後続のテスト止まるじゃないですか。
テスト担当者が自分ではない場合、そういう細々したバグ挙がって対応で手が止まるぐらいなら、サンドボックスで試してから実装に入れるほうが堅実（という言葉が適切かはわからない）じゃないかなと思います。
すごく難色を示された
「まぁあなたはそういうやり方なのかもしれないですけどね」的なことを言われた。
うーん、それってバッチリな答えを他人から引き出したかっただけなのかな。
自分で試してみて、「こうしてみたけど、こんな結果になって思い通りにならなかった」っていう証跡を他人に見せないと、答えも引き出せないと思うんだけどなぁ・・・。
試してもないけど、答え教えて！って、傲慢というかテキトー過ぎない？
でもこれって、他人に仕事のスタイルを強制する手段なのかなあ。
とりあえずやってみて、ダメなら聞いてみるスタイル
最近の社員さんはわからないけど、私が新入社員だったとき（遠い目）に上司からよく言われたことは
- そのわからないって言ってること、どこまで調べた？
- 調べてどこまで自分でやってみて、どこがわからなかった？
- どっちもやってない？じゃあ○ね（一応伏せ字にしておくよ！）
でした。
当たり前ですよね。調べてもない、やってもないのに「わからないよぅ」って聞いてたんですから（恥ずかしい・・・）。
でもこの当たり前が意外と出来てなかったりする。
調べて・やってみて自分の寿命が縮む呪いをかけられてるならしょうがないですけど、そうでもないなら命までは取られないんだし、とりあえずやってみよう。それでダメなら聞いてみよう。
聞いてみるステップの前に「今自分は何がわかってないんだ」という整理が出来るので、私はそういうスタンスで仕事をしてます。
他人に聞く前に要点を整理するって大事じゃないかな。
私がよくやりがちなんですけど、要点が整理出来てないせいで、言ってることが支離滅裂になって相手に伝わらないんですよね・・・これは気をつけたい。ほんとに。
わからないところは紙に書いてはいけない
やりがち。紙に残すだけまだいいんですけど、「ここわからないんですよね」って見せられた自筆の字が汚すぎて読めない・・・
と、「あー、そういうことですね。わかりました！」ってその紙に追記しているようなのだけど、所詮裏紙だったりするので扱いをテキトーにしちゃうんですよね。挙げ句
「あれってどうやったっけ・・・確か質問して答えも書いといたけどあの紙どこ行ったっけ・・・まぁええわもう１回聞いたろ！」
という、聞く人・聞かれる人どちらにも幸せではない結果が生まれます。かなしい。
せめてテキストファイルに残すとか、メールやExcel等眼の前の箱にいくらでも残す手段はありますやんか。
「おれのさいきょうのずのうにのこってるからへいき」
という人はすみません、一緒に仕事したくないです・・・自分ではその頭脳信用出来るのか知らんけど、私はその頭脳見られないからわかんないから信用出来ない。
人の記憶力って大したことないですよ。私昨日飲んだ酒の種類も忘れてるし。
あと、そういう人って周りが優秀だから助かってるだけ、ってこと多い気がします。
まとめ
- Utilの使い方がわからない？じゃあ目の前の箱でそのUtil切り出して試してみればいいじゃない。
- 調べてもない・やってみてもない？ちょっと会議室行こうか（ﾆｯｺﾘ）。
- 調べて・やってみたけどわからない。人に聞く前に「わかっていないこと」をまず整理する。
- わからないこと・わかったことは紙に書くべきでない。頭の中にあるとか論外。
- 昨日飲んだ酒、9999や（今思い出した）。