「マネジメントに悩める全てのエンジニアにささげる」資料が素晴らしいのでメモ

「マネジメントに悩める全てのエンジニアにささげる」資料が素晴らしいのでメモしておく。
以下は、思いついたことをラフに書いたラフな感想。
特に主張はなし。

【参考】
マネジメントに悩める全てのエンジニアにささげる　伊藤直也の１人CTO Night | Kwappa研究開発室

日経電子版　開発内製化の取り組み / nikkei web development 2015 // Speaker Deck

デザイナー横断組織の変遷 - クックパッド開発者ブログ

4ヶ月の間に一休.comで起きた変化 - zimathon blog

モダンな現場にするために実践したこと - SSSSLIDE

【1】自分が最近持つ問題意識として、組織構造はソフトウェア開発プロセスにどのように影響させているか、がある。

第15回RxTstudy 『大規模組織や多様な業務における Redmineの課題』

ベンダーへ開発工程を一括発注とか、製品ファミリーの派生開発、1回限りの受託開発プロジェクトのパターンに、Redmineは大きく影響される。
組織構造の影響は、Redmineの良さを打ち消すぐらいの大きさだ。

組織構造の問題が嫌なのは、開発者がコントロール出来ない問題のレベルだから。
でも、色々探ってみると、開発者がコントロールできる問題もある。
その辺りを切り分けたい、と思っていた。

【2】
【2-1】上記の資料で「日経の場合」のパターンは、今の日本で技術力のないユーザ企業の問題そのものだ。
開発は外注しており、社員は外注ベンダーのプロジェクト管理がお仕事になっている。
すると、その組織構造がそのまま反映されたプロセスになる。

つまり、開発プロセスは社内・社外のベンダーという組織単位に分断されてしまう。

その組織文化のまま、内製化しても上手くいかないのは道理だ。
「内製にしたがチーム構造はそのまま」「内製の経験がないからチーム構造を変えなくてはならない、ということに気づけない」「チームの枠組みがないからラーニングが蓄積されない」という指摘はまさにそう。

そこで、「兼務を解消、1チームに1ミッション」という解決策。
つまり、機能別組織にプロジェクト型チームを持ち込んで、クロスファンクショナルな組織を作った。
このやり方ならば、プロジェクト型チームが有機的なチームになりうる。

【2-2】「Kaizen Platformの事例」の場合は、マイクロマネジメント化してチームが機能しない問題。
SIなら本当によくある。
プロジェクトリーダーが全権を持ち、かき集めた開発者とチームを形成していると、契約上そのような雰囲気になる。
元請けSIにある典型的なアンチパターンだろう。

「PMとエンジニアが1:1で仕事している」「PMがアサイン権限を持っている状態」「エンジニア同士がお互いの仕事を知らない->ラーニング結果が蓄積されない」「コンテキストが分断されスイッチコストが発生する」という指摘はまさにそう。

そこで「PMとチームリーダーが話をする」という解決策。
このやり方は、スクラムチームの構成に似ている。
チームの外側のプロマネとスクラムチームがやり取りする。
そうすれば、チームはチーム自身で問題解決でき、チームに暗黙知が自然に蓄積される。

【2-3】「一休での事例」では、「心理的安全性か責任か」というマトリクスで考えると、チームが置かれている状況が不安定である問題があった。
どの会社でも、事業部の中では、うまくいっているチームもあれば、うまくいっていないチームもある。

「レストラン事業部 : 快適」では、心理的安全が既にあったので「ミッションの明確化、ロードマップの精度向上」を課し、「責任を増やす」。

「宿泊事業部 : 不安」では、開発者が安心して開発できるような環境ではなかったみたい。
おそらく、頻発する障害や数多くのリリースに忙殺されて、メンバーが疲労していた状況ではないか、と勝手に想像する。
そこで、「チームビルディング、技術基盤部の確立」を行い、「心理的安全性を高める」。

デスマーチプロジェクトになれば、「心理的安全性を高める」ことはすごく重要。

【3】そんな話を聞くと、組織構造をいじることで、簡単に問題解決できそうに思ってしまう。
「組織構造で変化を起こす」。
逆コンウェイの戦略みたいに、アーキテクチャ主導でチームを作る。
それである程度解決できる場合も多い。

でも「組織構造はいじりすぎない」。
「組織構造は時間的断片」「フェーズに合わせて横と縦のバランスをうまく組み替えていくことで更に良いサービスづくりが行える」という指摘はなるほどと思った。
組織が成長することで、問題のフェーズ、問題のレベルは変わっていく。
安定した組織を壊す必要はないし、組織に応じた問題ごとに、解決策を変えていく。
その一つに、組織構造をいじる方法があるだけ。

【4】「相談しにくる人たちの共通点」が「技術の問題だと思ったら9割がた組織の問題だった」という指摘は経験上そう感じる時がある。
そして、そのように感じる時は、気分が重たくなる。
開発者が解決できる問題のレベルではないからだ。
やっぱり、CTOクラスのように、経営層と開発者の中間のような立場の人が必要ではないか、と思う。