ここんとこ、
市販のCPU評価ボードを使わない、お客さんの試作ボードを使った仕事をやってまして。
となると、ソフトがうまく動かないとき、
「もしかしてハード（がわるいの）かな？」というのも思いながら仕事するわけなのですが、
まずはソフトが絶対わるくないと思えるまで、とことん追っかけてみるわけです。
その「とことん追っかけてみる」がクセモノでして。
何日もかけてデバッグしてみて結局ボードがわるかった、なんてこともあるわけです。
どこでやめとけばよかったんだろう、
どこかで「やめどき」「あきらめどき」があったんだろうな、と思うわけです。
チームでやっていますから、
自分がやっていない部分に関しては、担当者の報告が頼りです。
どうなっているのか聞きながら、コードも見ながら、
今度はこんなことやってみて、とお願いしながら、試行錯誤してみるわけです。
今まで使ったことのないCPUの機能だと、正解がよくわかっていないわけで、
「サンプルプログラムはこうだけど、
データシートのこの説明だと、こうするのがよさそうだ」とか、
まぁいろいろやってみたりするわけです。
ロジアナ当てて出力が出てるかどうかくらいは見ますが、
CPU（の該当機能）がぜんぜん動いてなかったりすると、
もう何がわるいんだかよくわからんわけです。
そんなもんだからなのか、
担当者の報告も今ひとつ的を射てないというか、はっきりしないというか。
何をやったらどうなって、
ここまでは動いてるけど、ここがダメそうだ、みたいな
論理的な説明がうまくできなかったりします。
で、聞いているほうは、
そういうのがじれったかったりしてイライラしたりもするわけです。イカンなぁ。
担当者さんは、ほっておくと作業に没頭していたりします。
聞かないと状況を教えてもらえない。聞けば教えてくれるけど。
どう報告すればいいのかわからないのかもしれないし、
自分の責任だから自分で解決しないといけないと思っているのかもしれないし、
結果、ズルズルと、トラブルが解決せず、時間ばかりがかかってしまう。。。
どうやって現象をとらえるのか。
どうやって問題点を切り分けるのか。
得た情報から何がわかるのか、どんな仮説が成り立つのか。
それを元に次は何をするのか。
そのへんの観点やノウハウもそれぞれの経験値に大きく依存するし
また人によって得手不得手もあるし。
ただ、今回思ったのは、
引きとって自分で見てみたら、割とあっさり「ダメだこりゃ」と思えたこと。
だからきっと、あきらめられる観点やポイントがあるのだろう、と思うのです。
人から得た情報だと半信半疑に聞いてるところもあるのだと思います。
だから思い切って判断できなかった、というのもありそうです。
（人から聞いたことをどうやって信じるか、どう精度を上げるのか（裏を取るのか）、は
チームをまとめる人間にとってすごく大事なスキルだと思う。
が、私はそれがまだうまくないと思う。）
私は立場的にも「あきらめられやすい」わけですし。
「できる」ことよりも「進める」ことを優先して考えているから。
まずは周りに頼ればいいじゃん、と思えるから。
だから最後は私が引きとるべきだったのでしょう。
もう少し早くそうすべきだったのだろうと思います。
....いや、どうなんでしょう？ それでやる気や自信を失うひともいるかもしれない...。
こういう局面では、結局は、
プロジェクトの舵取りをする人が「判断すべき」。
「現場が迷っているとき」にそうするのが私の役割なのですから。
チームで解決してほしい、とも思っていますが、なかなか難しいですね。
P.S.
こういうことが最近何度も続いています。
こんなことでは、ただファーム屋の「見切り」に依存してては、
製品開発は思うように進みません。
だから、お客様にも素直にご相談して
「何かあったときは、すぐにハード側も見てほしいです」と
お願いすることにしました。
ファーム屋のマインドだけに頼らず、
お客様との協調関係で、対策・解決しなければ。
私の仕事はそういうところだと思います。
