締切が絶対と思い込まない
締切は絶対。
何が何でも間に合わせろ。
それがビジネスの掟だー
なんて言う人います。
締切が絶対ではないんです。
絶対なのは約束なんです。
締切は日時と品質で構成されています。
となると、締切に間に合わない場合、
日時を延期してもらうか、
品質を落とさせてもらうか、
このどちらかしかありません。
違います。
その中間の選択肢もあるのです。
締切における相手の状況を把握して
優先度の高い品質ものだけを
元々設定されていた日時に
間に合わせるのです。
ソフトウェアなら頻繁に使う機能だけ、
花見でビアサーバが無理なら缶ビール、
講演で問いかけを増やして持ち時間を埋める、
とか。
当然、相手がそれの条件を
のんでくれるように
交渉することが前提です。
締切には全てはムリと言われても、
相手も手ぶらじゃ帰れないわけで、
何かしら持たせないと話になりません。
そのためには、
相手が重要視していることを
的確に把握しておく、
必要ならば経緯や背景を
聞き出さなければなりません。
2016年度に気付いたこと -2
引き続き2016年度に気付いたこと。
なんかいっぱいで忘れそうだから、
まずリストアップ。
● 不安は不安を産む倍々ゲーム
● 思想が合わない人に近付いてみる価値
● "とりあえず否定"が悪いとは限らない
● "締切"が絶対と思い込まない
● ”キリがない”の基準
● 来たボールはすぐに投げるか打つ
● 決める、宣言する、動かさない
● 子どもの前で親はサトラレとなる
● おじさんリーマンの価値は交渉とまとめ方
● おじさんリーマンは不安を見せないこと
2016年度に気付いたこと - 1
2016年度は個人的にかなり辛かった...。
状況的には落ち着いてきたが、
自分の中では消化しきれていない。
備忘録として書いておく。
●複数のカードが無意味となるケースもある
今まで何かの問題に対して複数の解決策を
用意することをモットーとしてきた。
こっちのカードでもし駄目ならそっちのカードを出せるようにと。
しかし、1つカードを見せた途端、後に引けないケースがある。
例えば、ある解決策を説明したとき、その論理に抜けがあって、その抜けをどうするか追求された場合。
もう問題はその抜けをどう埋めるかとなる。
やっぱり別の解決策にしますとなると、今までの検証が全て無意味となり、最悪は問題の真理が見えていないと相手に信用されなくなる。
問題を解決する場合、論理と同じくらい信用が大切になる。
多少の抜けも、その信用でカバーできるくらいに。
備忘録としてはもっと書きたいが、
今日はここまで。
結論ありきな方法
論理的な説明や方針を求められた時、
要因から結論を導き出すか、
結論から要因を導き出すか
をまず最初に決める。
前者は一般的な説明論法。
後者は答えありきな方法。
演鐸法とか帰納法とかの前の話。
どんな時に後者となるか。
どうしても自分がそうしたいケース。
情報が多すぎて結論が堂々巡りするケース。
結論が直感でしっくりくるケース。
結論がそれなりにどっちも真っ当なケース。
ただ、この場合、
他人から見て前者と感じるように
まとめなければならない。
そのためには、
自分が導き出した要因へのツッコミ対策、
結論を覆す新たな理由へのツッコミ対策、
が重要。
結局は思考にヌケモレがなく、
1つの要因に反論カードを数枚用意
しなければならないから面倒だけど。
うだうだ堂々巡りしてるよりはマシ。
あと、結論が成り立たないと判断したら
すぐに軌道修正すること。
再現できなくなった不具合
組込ソフトウェアを開発していると
どうしても一度は当たる問題。
ハードの問題か、ソフトの問題か。
接触不良や部品の温度素性が
影響しているかもしれない。
ソフトのレジスタ叩くタイミングや
処理シーケンスの不備はないはず。
でもフェイルセーフの甘さや抜けが
あるかもしれない。
切り分けは正直難しい。
同じソフトで
こっちのハードだとたまに起こる。
あっちのハードだと全く起きない。
ソフト屋は出来る限り、
部品の個体差を原因にしたい。
なぜなら論理的に説明できないから。
ハード屋は出来る限り、
ソフトのバグを原因にしたい。
なぜなら歩留まりや信頼性に関わるから。
設計・購買・生産工程まで
すべてを変えなければならないから。
分かる。
分かるんだがもうソフトで説明ができない。
同じROM焼き直したら再現できなくなった。
ケーブル挿し直したら再現できなくなった。
自分所有の電子機器がこれで
故障から復帰したらラッキー
でおしまい。
しかし仕事でこれは冷や汗もの。。
もう後に引けなくなる。
ただ原因の切り分けステップで、
十分有りうるケースではある。
なので、
他人が結構頻繁に再現する
と言っても自分で同じ再現をするまで
次のステップに進まないこと。
あとから切り分けが難しくなるので、
同時に2つの変化を作らず進めること。
この2点が超重要。
あーでもどう説明しよう。
状況証拠しかないよー。
試行回数で確率的に問題なしも
辛いんだよなー。。
選択しない理由
どっちでも良いなーの判断理由を
論理的に説明するのは非常にしんどい。
このようなケースは、たいてい、
こっちの方が単純じゃない？
か、
こっちの方が見通しいいよね？
なんだけど、
もう一方を選択しない理由を
ちゃんと用意しておかないと、
後々面倒くさい。
複雑だからとか見通し悪いから、
とか言うと、
ちゃんと調べたんか!!
って突っ込まれる。
調べた結果、
複雑で見通し悪いから
単純で見通し良い方を
選択したんだが。。。
っていうか、俺なら、
こいつしかいないって
設計時点で責務を意図的に寄せるよ。
無駄にソフトウェア階層を増やすから、
どっちでも良いパターンが出るんだよ。
影響範囲が広いとかテキトーな理由しか
思いつかん。
基盤がガタガタの
派生開発はもう疲れた。
