何でも屋エンジニアのブログ

Rails中級者向け勉強会Step-to-Rails-Expert.rbや出席した勉強会に関するメモが多い

「社内横断の技術組織を終わらせました」を読んで思ったこと

nottegra.hatenablog.com

を読んで、思ったことがはてぶコメントに書ききれなかったから、ブログで書いた。思ったより長くなった。 割りと思ったことベースでそのまま書いているので駄文です。あと、会社の元記事も合わせて読んでいますが、認識に間違いがあったらすみません。

はじめに

まず最初に、筆者の方には辛い話を共有していただけて本当にありがたいです。色々勉強にになりましたし、今後私にもこのような知見が生きるときがあると思うので、参考にさせて頂きます。 以下に書くことは誰への批判でもありません。客観的に聞いて考えたことです。

思ったこと

複数の事業部が荒く速く進めていることで生じる問題を抑制するために横断的な別の組織が責任を持つようになると、インセンティブが異なる組織になってしまうが、そこに歪みが発生してしまったのだと感じた。事業部は速く進めようとする方にインセンティブ向くけど、横断組織は問題を抑える(極端に言えば0にする)方に向き、異なるインセンティブが生じ断裂を生んでしまう。事業部は速く進めれば勝ちだし、横断組織は問題を起こさなければ勝ちという構図に陥っているように見えた。本当は「なるべく」速く「なるべく」問題を起こさないのが目的なのに。 なので、横断組織はレビューを過度(?)に行い、新技術導入も同類のプロダクトを比較するという慎重な姿勢にならざるを得なかったのではないかと推察している。

新規技術の導入に関して、クリティカルに生じている問題に対しての技術導入は(誰が行っても良いが)横断組織としてでなく事業部としての仕事の成果として計上するような方式で進める方が良かったのではないかと考える。そうすれば、必要以上に慎重になる必要がなく、「とりあえず」今の問題を抑える技術導入ができればOKラインだろうし(横断組織の技術導入はこの成果ではOKラインは出ないでしょ)。逆に、ある程度長期的な新規技術導入なら、しっかり調査&比較して決断し、横断組織の成果とすれば良いと思う。 レビューに関しても、横断組織は推進だけ行い、とりあえず粒度は事業部ごとに自由度を持たせ事業部の責任にした方が良かったのかな。

まとめると、やる内容で責任主体を分けるだけでは不十分で

  • インセンティブの向き
  • 施策内容の目的(喫緊の問題に対するパッチなのか長期的な根本解決なのか)
  • 施策内容の緊急度

あたりで責任の主体を分けるのが良いのかなと思った。

会社名出ている元記事のミッションを見ていると組織は割りと中・長期的な方向性が想定されているのに、実態はそうでなかったりしているので、中・長期的なことをやる組織が必要に追われ喫緊の課題を解決するようなミッションに追われてしまったのが不幸だったのだと思う。 横断組織で喫緊の課題を解決する場合は、もっと厳しいトップダウンではないと難しいのかな・・・