精神と時のblog

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

やっぱりプレイングマネージャーなんて無理

たぶんメンバーと上司は呆れていると思う。

 

システム全体に及ぶ不具合の計画進めて、

担当ブロックの不具合コード直しながら、

上司と客先用の不具合報告資料書いて、

メンバーに別案件の指示する。

 

まだ自分が作ったコードならまだしも、

他人から引き継いだコードを、

技術負債が詰まったシステムを治すなんて、

組織的に動かないと無理だったんだろう。

 

引き継ぎ時にはそんなの分からない。

やれと言われたからやるだけ。。

 

結局自分の見積が甘かっただけなのか。

ヤバめの案件だから積極的に

みんな係わってくれないのか。

 

いや自分が回せていないからでしょう。

 

たぶん始まる時に、自分の守備範囲を

限定しなかったのが悪いのだろう。

 

数年走ったシステムを突然引き継ぐのは

断りましょう。

 

というか、

設計資料云々よりも

論理的に成立してないじゃないか。

このシステムは。

人日とか見る人で変わる謎単位

この作業は何人日で終わります.

 

エンジニアには親しみのある文章です.

 

単位って絶対なんですよ.

誰から見ても同じ尺度なのが

単位と呼ばれるもの.

誰が測っても10g.

誰が払っても1980円.

 

しかしこの人日とか人月とか.

誰が測っても違う単位なんです.

 

作業の担当者によって違う.

見積立てる人によって違う.

 

人の能力·体力に差がある以上,

これは仕方がないと思ってます.

 

問題は、1人日を1日で換算する人.

 

というか....

 

だいたいこういう人はメンバー5人で

10人日だから2日で終わると思ってる.

 

メンバーが他に何を抱えているか考えずに。

そもそもそれお前が頼んで来たし。

 

 

 

雰囲気が悪い

特に組み込みなんかだと

開発・製品リリースが終われば

保守フェーズに入ります。

 

となると、上層部は

他の火事場にメンバーを

回せって話になります。

 

当然外注さんもお金かかるから

契約終了って話になります。

 

そこから第2の炎上モードに入ります。

 

止まない不具合報告と説明資料作成、

何を意図するか分からない設計思想、

元メンバーの問い合わせ拒絶。

(元メンバーは回された案件で即炎上だから仕方ない)

 

チームの雰囲気も悪くなります。

俺はやりたくないオーラ全開。

でも残ってしまった運命。

 

開発フェーズで炎上したら、

保守フェーズでも炎上します。

必ず。

 

毎年繰り返しても気づかない上層部。

そして上層部の面子もやり方も変わらない。

 

何故なら会社的には収入をあげているから。

 

んーなんだかなぁ。

 

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

若手エンジニアに

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

 

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

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

 

気持ちはわかります。

 

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

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

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

 

それなりに大きな企業で

エンジニアをしていると

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

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

 

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

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

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

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

 

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

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

違うんですよ。

 

簡単に言えば

感じている責任のレベル

が違う。

 

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

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

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

良いかと。

 

 

 

 

一回怒られた方が早い

異動や転職で

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

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

 

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

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

 

怒られても嫌われても、

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

腹を決めて。

 

お仕事ですし。

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

 

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

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

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

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

 

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

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

挙句に絶賛炎上中。

 

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

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

 

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

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

 

でも設計思想も、

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

grepだけでは迷子状態。

 

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

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

 

そして聞いたけど、

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

説明が理解出来ない。

 

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

 

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

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

 

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

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

 

その繰り返し。

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

あのー。。。

 

。。。

 

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

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

 

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

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

メンタル潰れちゃうよ。

 

あと次異動して来る人に

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

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

 

 

 

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

締切は絶対。

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

それがビジネスの掟だー

なんて言う人います。

 

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

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

 

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

 

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

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

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

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

 

違います。

 

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

 

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

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

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

間に合わせるのです。

 

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

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

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

とか。

 

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

のんでくれるように

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

 

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

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

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

 

そのためには、

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

的確に把握しておく、

必要ならば経緯や背景を

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

 

 

 

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

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

 

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

まずリストアップ。

 

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

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

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

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

● ”キリがない”の基準

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

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

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

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

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