内容紹介

※この商品はリフロー型で作成されており、ハイライトや検索、文字の大きさの変更などの機能がご利用可能です。

◆200枚超の図でわかる、疲弊する現場・歪んだ組織の立て直し方◆

「チーム」という単位をないがしろにする組織は、うまく機能しません。日々の業務フローが複雑で入り組み、非効率になりがちになります。たとえプロジェクトが成功したとしても、再現性がありません。現場はいつも手一杯で、余裕のない状態が続きます。

　本書では、そんな“うまくいかない組織”で生じる問題を、組織設計の視点から解決に導きます。チームを最小単位とする「チーム指向」に基づく組織設計によって、組織を侵す問題を解消することを目指します。

　組織設計として避けるべき16のアンチパターンや、チーム中心の組織作りのための6つの原則、チームの機能と配置を考えるための7つのガイドラインを収録。「アジャイル」「リーン」「DevOps」「コンウェイの法則」「チームトポロジー」、そして組織論としての「Microservices」といった考え方に基づいて解説します。

　対象読者は、組織設計を担うエンジニアリングマネージャーを想定していますが、現場で働くメンバーにとっても、日々感じる問題把握に役立つでしょう。さらに、エンジニアリング経験のないビジネスリーダーやプロダクトマネージャーにとっても、エンジニアリング組織をより深く知るための有益な情報源となるはずです。

■こんな方におすすめ

・エンジニアリング組織を預かるマネージャー

・ソフトウェアの内部品質の低さに苦しむエンジニア

・ソフトウェアプロダクト事業に携わるビジネスリーダーやプロダクトマネージャー。

■目次

第1章　チーム指向の組織設計

　　1-1　チーム指向の組織設計が目指す組織のビジョン

　　1-2　チームが組織を駆動する

　　1-3　チームレベルの設計のための学びを得る

　　1-4　組織レベルの設計のための学びを得る

　　1-5　チーム指向の組織設計に求められる要件を定義する

　　1-6　戦略や時代の変化に組織を呼応させる

　　1-7　まとめとこれから

第2章　組織のパフォーマンスを蝕む問題から捉える組織設計

　　2-1　問題1：非効率なチーム間コミュニケーションが組織の生産性を削り取る

　　2-2　問題2：非効率なフローが無価値な待ち時間を生じさせる

　　2-3　問題3：粗悪な内部品質がビジネスに悪影響を及ぼす

　　2-4　3つの問題は相互に影響し合う

　　2-5　まとめ

第3章　内部品質を悪化させる組織設計アンチパターン

　　3-1　共有リソースプール：プロジェクトの度にチームを編成している

　　3-2　不連続なチーム：プロダクトに専属チームを配備しない

　　3-3　行き過ぎた固定化：チーム編成を長期に渡り変更していない

　　3-4　無制限のコード共有：どの領域のコードでも制限なく誰もが変更できる

　　3-5　保守・運用の分離：開発チームが保守・運用業務を知らない

　　3-6　品質保証の一極集中：品質をテストフェーズに頼り過ぎてい

　　3-7　ドメイン知識の過疎地：顧客と開発メンバーの距離が遠い

　　3-8　無力な他己管理型チーム：チームに決定権がない

第4章　コミュニケーションコストとフロー効率を悪化させる組織設計アンチパターン

　　4-1　スパゲッティ組織：プロジェクト体制が組織内で複雑に絡まっている

　　4-2　水平統合：組織を技術観点でチーム分けしている

　　4-3　即興的な開発プロセス：開発プロセスがあいまいで過度に柔軟性を重視している

　　4-4　低凝集な業務機能：業務機能の一部がチームに欠けている

　　4-5　ねじれコンウェイ：コミュニケーション構造とシステム構造に乖離がある

　　4-6　メンバー共有：兼務メンバーがチームに存在する

　　4-7　人気者チーム：コンポーネントを共有化し専任の開発チームをつけている

　　4-8　バリューストリームの合流点：1つのチームが複数のバリューストリームに配備されている

第5章　チーム中心の組織作りのためのチーム設計の原則

　　5-1　安定：チームのメンバー構成と担当責務をほぼ一定に保つ

　　5-2　アトミック：組織内でチームを「個」として扱う

　　5-3　専属：メンバーを兼務させない

　　5-4　少人数：チームメンバー数を制限する

　　5-5　流動性：少しずつチーム編成を変えていく

　　5-6　イテレーティブ：フィードバックループをプロセスに組み込む

第6章　チームの機能と配備を考えるためのチーム責務定義ガイドライン

　　6-1　ストリームアラインド：チームをバリューストリームに対して配備する

　　6-2　コードのオーナーシップ制：コードごとの所有権を各チームに持たせる

　　6-3　バリエーション分割：対応プラットフォームごとにチームを分ける

　　6-4　垂直統合：エンドツーエンドの開発チームを作る

　　6-5　DevOps：開発と保守・運用を1つのチームに統合する

　　6-6　機能横断：より多くの業務機能を1つのチームに統合する

　　6-7　マルチスキル：専門分野を越えて協力し合うチームを作る

第7章　組織のリファクタリング・リアーキテクティング

　　7-1　組織設計をアーキテクティングと設計で責務分けする

　　7-2　SPACEフレームワークで組織の開発生産性をモニタリングする

　　7-3　指標を正しく活用する

　　7-4　まとめ：組織にもリファクタリング・リアーキテクティングを！

■著者プロフィール

松本成幸：大学卒業後、ソフトウェアエンジニアとしてさまざまなプロジェクトに従事し、開発・保守・運用を幅広く経験。2008年にシナジーマーケティング株式会社に入社。開発部長やプロダクト開発本部長として、組織改革や主力プロダクトのアーキテクチャ刷新、クラウド移行などを主導し、2020年に退社。現在は、LINEヤフー株式会社で開発本部長として、複数のコンシューマ向けサービスの開発業務全般に携わっている。