エンジニアが‟事業貢献を意識して動く”組織に変えていきたい
映画をつくったり、アイスホッケーの試合で点数を入れたりするためには、異なる業務に携わる人たちが一緒に仕事をしなくてはならない。「調整」が不可欠なのだ。調整は「分業」に次ぐ組織づくりの本質である。
※参考：『ミンツバーグの組織論』（p.65）
ある程度の大きさの組織になると、「プロダクトを作る人」と「プロダクトを売る・提供する人」は分かれて、いわゆる分業をしていることがほとんどでしょう。大きな目標を達成するために一つの組織を分割して、それぞれに細かい役割を持たせることで、より目的がはっきりします。目的が絞りこめているため、繰り返しによる上達が望めることや達成するために要求される知識・能力を集中できている点が利点です。
一方、分割した組織においては、当初の大きな目標と分割した組織の目標の2つを持つことになります。この場合、分割した組織の目標を追っていきながら、他組織との調整を行い、当初の大きな目標への貢献につなげるのが基本的な流れになるでしょう。
ここで大きな目標を「事業貢献」、分割した組織の目標を「良いプロダクトを作り出す」に読みかえてみると、「良いプロダクトを作り、他組織との調整によって事業貢献につなげる」ことになります。良いプロダクトを作ることに集中してもらうのか、プロダクトをうまく届けるために他部署との調整も役割に含めてもらうのかによって、事業貢献を意識する機会は変わりそうです。皆さんの組織でのエンジニアの役割はいかがですか？
さて、この書籍では調整には6種類のやり方「相互の調整」「直接的な監督」「業務の標準化」「成果の標準化」「スキルの標準化」「規範の標準化」が紹介されています。記事の都合上全てを紹介することは難しいので、話に強く関係しそうなものだけ紹介させてください。
まだ事業貢献を意識していない組織において、最も始めるのが簡単なのは、指示を行うことによる調整＝「直接的な監督」です。ただ、この方法は言い続ける必要があり、維持にかける力は大きく必要です。標準化を通じて事業貢献を意識してもらう形へと移行するとより良いでしょう。
例えば、成果に事業貢献の切り口を含める形にすると、その成果を追いかけることを通じて事業貢献を意識することになります。これが「成果の標準化」という調整です。また、事業貢献の信念を各自が持っている状態を普通のこと、つまり企業文化にできれば、自然と事業貢献を意識した考え方や動きを取るようになります。
このアプローチは「規範の標準化」という調整になります。規範の標準化は効果が大きいと思われますが、定着までには時間がかかります。まずは直接的な監督や、成果の標準化の調整を通じて事業貢献を意識して動く組織に変革していき、長期的に企業文化として育てていくのが実用的だと思います。
DIGGLEは「ビジネスサイド」と「プロダクトサイド」という言葉を使わず、それぞれ「サクセスチーム」と「プロダクトチーム」という呼び方をしています。これは開発者もビジネスを担っているという考えのもと、CTOの水上が創業初期からこだわって社内に浸透させてきた言葉です。ビジネスサイドとプロダクトサイドの境界なく、お客さまに価値を届けるという目的に取り組むためには、こうした日々の言葉遣いや意識づくりが大切です。実際に開発チームに属している私もこの考えには馴れ親しんできました。これは規範の標準化が行われて維持されている状態だと認識しています。
終わりに
既存の組織論では、ソフトウェア開発組織が抱えている課題にあてはめることが難しく、居心地の悪さを感じることがありました。これは著者の問題ではなく、私が文脈をソフトウェア開発組織にあてはめる能力の低さというのも大きかったかもしれません。それに比して『ミンツバーグの組織論』は、一般的な組織の話でソフトウェア開発組織のみに向けて書かれた本ではないにもかかわらず、「私たちソフトウェア開発組織の状況をここまで言語化できているとは」「なるほど……たしかにこういったまとめになるか」といった知的興奮がありました。その興奮に駆られて、この前後編の記事を書きました。
もしよければ、書籍の情報と皆さんの組織状況の両方を比較しながら読んでみてはどうでしょうか。私の場合、書籍の情報をDIGGLEにあてはめて考えてみても、構造をうまく説明できることが多く、書籍への信頼が増しました。
前編に書いたように、この書籍をソフトウェア開発組織にあてはめた記事は多くなく、こういった形でソフトウェア開発組織にかかわる方の目にふれることの意義が大きいと考えています。読者の皆さんの興味を引く内容になっていればうれしいです。
ぜひ『ミンツバーグの組織論』を読んだ感想をインターネットに流してください。喜んで読みに行きます。
