エンジニアリング組織論への招待を読んで考えていること(第1章)

はじめに

ちまたで話題のエンジニアリング組織論への招待を読んで、感じたこと、考えたことをまとめていきたい。
何度も読み直すし、それに対する自分のactionも都度updateされていくものだと思う。
にしても、ここまで体型的にまとめられているのは本当にすごい。
これを書けるようになるような人になる方法も知りたい笑

エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング [ 広木大地 ] 価格：2570円（税込、送料無料) (2018/12/3時点) 楽天で購入

わたしは

とある企業のマネージャー
UIエンジニア
メンバーは20人弱

ここ最近は

システムのリニューアルに従事。
このリニューアルは、アーキテクチャ、仕様含めてのフルリニューアルであった為、非常に不確実性の高いプロジェクトでした。

Chapter1 : 思考のリファクタリングを読んで考えていること(WIP)

三次元の「U」(2018/12/05)

これを読んで、思い浮かぶのは、PDM, DEV, QAの関わり方。

• 参考

www.atmarkit.co.jp

会社では、よくこの3つの立場でバランスをとることを意識しようとしていた。
(実際には、特にPDMはビジネス側との関わりも強いので、4つで考えないといけない場面も多かったとは思うが)

例えばQAとは、QAに出すタイミングでqualityの共通認識がとれだけとれるかが大切。

• スピードを重視したい時
• 品質を重視したい時

でQAに渡すプロダクトの品質に多かれ少なかればらつきは発生すると思っている。
その時に、その目的を共有できていないと、お互いが問題を感じることが多い。
特に、スピードを重視する時。

極端に書くならば、
DEV - この期間でこれだけの機能を実装したから、このくらいのバグは出る
QA - なんでこんなに品質が悪いのか
みたいな感じ。

いいプロダクトを出来るだけ早く良い品質で世の中に出したい

というのが全体像かつ共通の目標で、そこに対して、どのタイミングでの品質を大事にしたりとか、
どこにテストの負担をかけるとか、そういうことが事前に共通認識がとれていれば、
そこまで問題にはならない。

マネージャとして、メンバーが全体像を見えていないと感じたら、三次元の「U」を描いて見せてあげることが大切

情報の非対称性(2018/12/05)

ハンロンの剃刀 - Wikipedia

カレー作りの寓話(2018/12/03)

組織が大きくなるにつれて、役割は分担されていきます。
役割を分担すると、まずはその役割の責任範囲を明確にしようとしていました。
明確にすることは大切でしたが、それだけだと、役割分担的に宙に浮く仕事や、
その役割の人がすぐに作業できる状態に無いと

※実際にはそこまで食い合ってないです

• 宙に浮いた仕事の反応が悪くなってしまうことがある
• (特に)Leaderの仕事が不在時にボトルネックになりがち(自分かなw)
  • MgrやMemberのこともある

今までは、個人個人の判断で巻き取ってくれたりくれなかったりという状況でした。
※くれないことが悪いと思っているという意図はありません

そもそも、宙に浮いてしまう仕事があることは、そもそもの役割分担がいけてないこともあります。
ただ、それも踏まえた上で、今はこういう状況で、ここはいけてないしベストではないと思うんだけど、
必要に応じて、こういう部分の仕事を巻き取ってほしい
ということを明文化することにしました。
なるべく良くない所は良くないと明記することを意識しました。
※良く無い所をどういう風に無くしていきたいか、というのも別途用意しています

e.g)

• 問い合わせの対応
• 緊急対応
• 複数チームのドメインを跨ぐタスクのハンドリング
• 必要な承認など

(を具体的に書いた感じです)