精神と時のblog

明日が来年ならデーモン閣下と同い年になれると思っているおじさんの駄ブログ

一回怒られた方が早い

異動や転職で

右も左も分からないけどのに

成果物を期限までに求められた時。

 

もう怒られても嫌がられても、

周りに聞きまくりましょう。

 

怒られても嫌われても、

期限に成果物を出せないよりマシと

腹を決めて。

 

お仕事ですし。

本当に嫌われたら辞めればいいし。

 

異動直後に全然知らないシステムの

不具合修正を来週まで完了せよと

ミッションがくだされた時、

とにかく周囲に聞きまくりました。

 

部署のメンバーはほとんどが初対面。

ドキュメントは整備されていない。

挙句に絶賛炎上中。

 

顧客に多々の不具合の説明を求められ、

部署全体がピリピリを超えてビリビリ。

 

でも腹を決めて聞きまくりました。

こちとて理解する努力はしたさ。

 

でも設計思想も、

何がどこで処理しているのか、

grepだけでは迷子状態。

 

ミッションを達成するには、

周囲に聞かないと進まない。

 

そして聞いたけど、

背景が理解出来ていないから、

説明が理解出来ない。

 

だからその背景の話を聞く。

 

でもそれを説明されても分からないから、

自席に戻ってさっきの情報をもとにコードを見る。

 

ちょっと理解は進んだけど、

謎の処理や定義があるからまた聞く。

 

その繰り返し。

 

聞く人を変えるとか努力はしてみたものの、

最終的に同じ人に行き着く。

 

ドキュメントが整備されていない組織は

だいたい暗黙で担当分野が出来ている。

 

そしてとうとうキレられる。

ここにシーケンス図のdocがあると。

 

何このサーバ? 初耳です。

でも情報あるならいいや。

 

コードと照らし合わせると、

書いてないメッセージが飛んでるよ。

 

あのー。。。

 

。。。

 

でも情報取れただけマシ。

そしてキレられたのは自分のせいではない。

 

この感情を洗脳するかのように

無理矢理にでも持ってないと

メンタル潰れちゃうよ。

 

あと次異動して来る人に

こんな想いは絶対にさせない

という決意と行動は忘れないこと。

 

 

 

締切が絶対と思い込まない

締切は絶対。

何が何でも間に合わせろ。

それがビジネスの掟だー

なんて言う人います。

 

締切が絶対ではないんです。

絶対なのは約束なんです。

 

締切は日時と品質で構成されています。

 

となると、締切に間に合わない場合、

日時を延期してもらうか、

品質を落とさせてもらうか、

このどちらかしかありません。

 

違います。

 

その中間の選択肢もあるのです。

 

締切における相手の状況を把握して

優先度の高い品質ものだけを

元々設定されていた日時に

間に合わせるのです。

 

ソフトウェアなら頻繁に使う機能だけ、

花見でビアサーバが無理なら缶ビール、

講演で問いかけを増やして持ち時間を埋める、

とか。

 

当然、相手がそれの条件を

のんでくれるように

交渉することが前提です。

 

締切には全てはムリと言われても、

相手も手ぶらじゃ帰れないわけで、

何かしら持たせないと話になりません。

 

そのためには、

相手が重要視していることを

的確に把握しておく、

必要ならば経緯や背景を

聞き出さなければなりません。

 

 

 

2016年度に気付いたこと -2

引き続き2016年度に気付いたこと。

 

なんかいっぱいで忘れそうだから、

まずリストアップ。

 

● 不安は不安を産む倍々ゲーム

● 思想が合わない人に近付いてみる価値

● "とりあえず否定"が悪いとは限らない

● "締切"が絶対と思い込まない

● ”キリがない”の基準

● 来たボールはすぐに投げるか打つ

● 決める、宣言する、動かさない

● 子どもの前で親はサトラレとなる

● おじさんリーマンの価値は交渉とまとめ方

● おじさんリーマンは不安を見せないこと

 

2016年度に気付いたこと - 1

2016年度は個人的にかなり辛かった...。

 

状況的には落ち着いてきたが、

自分の中では消化しきれていない。

 

備忘録として書いておく。

 

●複数のカードが無意味となるケースもある

 

今まで何かの問題に対して複数の解決策を

用意することをモットーとしてきた。

 

こっちのカードでもし駄目ならそっちのカードを出せるようにと。

 

しかし、1つカードを見せた途端、後に引けないケースがある。

 

例えば、ある解決策を説明したとき、その論理に抜けがあって、その抜けをどうするか追求された場合。

 

もう問題はその抜けをどう埋めるかとなる。

やっぱり別の解決策にしますとなると、今までの検証が全て無意味となり、最悪は問題の真理が見えていないと相手に信用されなくなる。

 

問題を解決する場合、論理と同じくらい信用が大切になる。

 

多少の抜けも、その信用でカバーできるくらいに。

 

 

備忘録としてはもっと書きたいが、

今日はここまで。

 

結論ありきな方法

論理的な説明や方針を求められた時、

 

要因から結論を導き出すか、

結論から要因を導き出すか

 

をまず最初に決める。

 

前者は一般的な説明論法。

後者は答えありきな方法。

 

演鐸法とか帰納法とかの前の話。

 

どんな時に後者となるか。

 

どうしても自分がそうしたいケース。

情報が多すぎて結論が堂々巡りするケース。

結論が直感でしっくりくるケース。

結論がそれなりにどっちも真っ当なケース。

 

ただ、この場合、

他人から見て前者と感じるように

まとめなければならない。

 

そのためには、

自分が導き出した要因へのツッコミ対策、

結論を覆す新たな理由へのツッコミ対策、

が重要。

 

結局は思考にヌケモレがなく、

1つの要因に反論カードを数枚用意

しなければならないから面倒だけど。

 

うだうだ堂々巡りしてるよりはマシ。

 

あと、結論が成り立たないと判断したら

すぐに軌道修正すること。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

再現できなくなった不具合

組込ソフトウェアを開発していると

どうしても一度は当たる問題。

 

ハードの問題か、ソフトの問題か。

 

接触不良や部品の温度素性が

影響しているかもしれない。

 

ソフトのレジスタ叩くタイミングや

処理シーケンスの不備はないはず。

 

でもフェイルセーフの甘さや抜けが

あるかもしれない。

 

切り分けは正直難しい。

 

同じソフトで

こっちのハードだとたまに起こる。

あっちのハードだと全く起きない。

 

ソフト屋は出来る限り、

部品の個体差を原因にしたい。

なぜなら論理的に説明できないから。

 

ハード屋は出来る限り、

ソフトのバグを原因にしたい。

なぜなら歩留まりや信頼性に関わるから。

設計・購買・生産工程まで

すべてを変えなければならないから。

 

分かる。

分かるんだがもうソフトで説明ができない。

 

同じROM焼き直したら再現できなくなった。

ケーブル挿し直したら再現できなくなった。

 

自分所有の電子機器がこれで

故障から復帰したらラッキー

でおしまい。

 

しかし仕事でこれは冷や汗もの。。

もう後に引けなくなる。

 

ただ原因の切り分けステップで、

十分有りうるケースではある。

 

なので、

 

他人が結構頻繁に再現する

と言っても自分で同じ再現をするまで

次のステップに進まないこと。

 

あとから切り分けが難しくなるので、

同時に2つの変化を作らず進めること。

 

この2点が超重要。

 

 

 

あーでもどう説明しよう。

状況証拠しかないよー。

 

試行回数で確率的に問題なしも

辛いんだよなー。。

 

 

選択しない理由

どっちでも良いなーの判断理由を

論理的に説明するのは非常にしんどい。

 

このようなケースは、たいてい、

こっちの方が単純じゃない?

か、

こっちの方が見通しいいよね?

なんだけど、

 

もう一方を選択しない理由を

ちゃんと用意しておかないと、

後々面倒くさい。

 

複雑だからとか見通し悪いから、

とか言うと、

ちゃんと調べたんか!!

って突っ込まれる。

 

調べた結果、

複雑で見通し悪いから

単純で見通し良い方を

選択したんだが。。。

 

っていうか、俺なら、

こいつしかいないって

設計時点で責務を意図的に寄せるよ。

 

無駄にソフトウェア階層を増やすから、

どっちでも良いパターンが出るんだよ。

 

影響範囲が広いとかテキトーな理由しか

思いつかん。

 

基盤がガタガタの

派生開発はもう疲れた。