結論ありきな方法
論理的な説明や方針を求められた時、
要因から結論を導き出すか、
結論から要因を導き出すか
をまず最初に決める。
前者は一般的な説明論法。
後者は答えありきな方法。
演鐸法とか帰納法とかの前の話。
どんな時に後者となるか。
どうしても自分がそうしたいケース。
情報が多すぎて結論が堂々巡りするケース。
結論が直感でしっくりくるケース。
結論がそれなりにどっちも真っ当なケース。
ただ、この場合、
他人から見て前者と感じるように
まとめなければならない。
そのためには、
自分が導き出した要因へのツッコミ対策、
結論を覆す新たな理由へのツッコミ対策、
が重要。
結局は思考にヌケモレがなく、
1つの要因に反論カードを数枚用意
しなければならないから面倒だけど。
うだうだ堂々巡りしてるよりはマシ。
あと、結論が成り立たないと判断したら
すぐに軌道修正すること。
再現できなくなった不具合
組込ソフトウェアを開発していると
どうしても一度は当たる問題。
ハードの問題か、ソフトの問題か。
接触不良や部品の温度素性が
影響しているかもしれない。
ソフトのレジスタ叩くタイミングや
処理シーケンスの不備はないはず。
でもフェイルセーフの甘さや抜けが
あるかもしれない。
切り分けは正直難しい。
同じソフトで
こっちのハードだとたまに起こる。
あっちのハードだと全く起きない。
ソフト屋は出来る限り、
部品の個体差を原因にしたい。
なぜなら論理的に説明できないから。
ハード屋は出来る限り、
ソフトのバグを原因にしたい。
なぜなら歩留まりや信頼性に関わるから。
設計・購買・生産工程まで
すべてを変えなければならないから。
分かる。
分かるんだがもうソフトで説明ができない。
同じROM焼き直したら再現できなくなった。
ケーブル挿し直したら再現できなくなった。
自分所有の電子機器がこれで
故障から復帰したらラッキー
でおしまい。
しかし仕事でこれは冷や汗もの。。
もう後に引けなくなる。
ただ原因の切り分けステップで、
十分有りうるケースではある。
なので、
他人が結構頻繁に再現する
と言っても自分で同じ再現をするまで
次のステップに進まないこと。
あとから切り分けが難しくなるので、
同時に2つの変化を作らず進めること。
この2点が超重要。
あーでもどう説明しよう。
状況証拠しかないよー。
試行回数で確率的に問題なしも
辛いんだよなー。。
選択しない理由
どっちでも良いなーの判断理由を
論理的に説明するのは非常にしんどい。
このようなケースは、たいてい、
こっちの方が単純じゃない？
か、
こっちの方が見通しいいよね？
なんだけど、
もう一方を選択しない理由を
ちゃんと用意しておかないと、
後々面倒くさい。
複雑だからとか見通し悪いから、
とか言うと、
ちゃんと調べたんか!!
って突っ込まれる。
調べた結果、
複雑で見通し悪いから
単純で見通し良い方を
選択したんだが。。。
っていうか、俺なら、
こいつしかいないって
設計時点で責務を意図的に寄せるよ。
無駄にソフトウェア階層を増やすから、
どっちでも良いパターンが出るんだよ。
影響範囲が広いとかテキトーな理由しか
思いつかん。
基盤がガタガタの
派生開発はもう疲れた。
ツッコまれ好きになる
自分の成果物をレビューしてもらう
マイルストーンをおくことで
課題に対する自分の理解度と
成果物の品質が
グッと上がる。
1,2時間見てもらうだけで、
丸1日自分だけで考える以上の
効果がある気がする。
そして、
考慮抜け、
分かりやすさ、
理解の足りなさ、
一気に出てくる。
これを続けると、いずれ
自分の感覚が研ぎ澄まされる
自分はまだ十分に理解できていない、
自分は複雑に考え過ぎている、
と自分で自分をレビューできるようになる
結構歳食ってから
気づいてしまった。
どんどんツッコまれましょう
出す でなく 出るように
休日出勤を安易にさせてはいけない。
いや、むしろしてはいけない。
安易にする人、させる人は、
一日の価値を理解できていない。
この価値を理解できている人ほど、
仕事時間を大事に使っている。
どうすれば最大限の成果が出るか。
今やるべきことは何か。
取捨選択をしながら、
周囲の状況を見ながら、
必要なことを必要なタイミングで。
成果を出すようにやる のが仕事ではなく、
成果が出るようにやる のが仕事だと思う。
