色々な経験をさせてやりたい

若手エンジニアに

色々な経験をさせてやりたい。

と育成を考えて上層部が若手の

異動や担当を変えるケースがあります。

気持ちはわかります。

が、その前に彼ら彼女らに

仕事の終わりを経験させましたか？

良くも悪くも結果を出させましたか？

それなりに大きな企業で

エンジニアをしていると

たまに正常終了も異常終了も

未経験な中堅エンジニアがいます。

知識や技術として色々経験させたい

気持ちも希望も分かりますが、

残念ながら終わり方を知っている人と

知らない人の差は結構ある。

仕事に対する精度や緻密さ

担当範囲への腹のくくり方が

違うんですよ。

簡単に言えば

感じている責任のレベル

が違う。

色々経験させたいのも分かりますが、

まず先に彼ら彼女らの業務レベルにおける

始まりと終わりをしっかり経験させる方が

良いかと。

一回怒られた方が早い

異動や転職で

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

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

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

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

怒られても嫌われても、

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

腹を決めて。

お仕事ですし。

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

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

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

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

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

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

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

挙句に絶賛炎上中。

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

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

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

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

でも設計思想も、

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

grepだけでは迷子状態。

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

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

そして聞いたけど、

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

説明が理解出来ない。

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

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

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

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

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

その繰り返し。

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

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

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

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

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

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

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

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

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

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

あのー。。。

。。。

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

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

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

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

メンタル潰れちゃうよ。

あと次異動して来る人に

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

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

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

締切は絶対。

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

それがビジネスの掟だー

なんて言う人います。

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

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

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

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

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

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

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

違います。

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

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

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

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

間に合わせるのです。

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

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

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

とか。

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

のんでくれるように

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

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

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

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

そのためには、

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

的確に把握しておく、

必要ならば経緯や背景を

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

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

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

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

まずリストアップ。

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

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

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

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

● ”キリがない”の基準

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今日はここまで。

結論ありきな方法

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

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

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

をまず最初に決める。

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

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

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

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

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

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

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

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

ただ、この場合、

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

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

そのためには、

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

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

が重要。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

あるかもしれない。

切り分けは正直難しい。

同じソフトで

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

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

ソフト屋は出来る限り、

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

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

ハード屋は出来る限り、

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

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

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

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

分かる。

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

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

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

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

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

でおしまい。

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

もう後に引けなくなる。

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

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

なので、

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

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

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

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

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

この2点が超重要。

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

状況証拠しかないよー。

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

辛いんだよなー。。