AI要約) A frontier without an ecosystem is not stable

※この記事は英語の記事をAIで翻訳・要約したものです。

記事： A frontier without an ecosystem is not stable
著者： Satya Nadella（Microsoft CEO）

---

全体要約

Satya Nadella（Microsoft CEO）が2026年6月14日にXに投稿した論考。「最強のAIモデルを選ぶ競争」は誤りであり、真の競争優位は企業がモデルの上に構築する学習ループ（learning loop）の所有にあると主張する。

企業は「ヒューマンキャピタル（人的資本）」と「トークンキャピタル（AIを動かすトークン処理能力）」を複利的に積み上げる仕組みを持たなければ、一部の巨大AIモデルに知識を吸収・商品化されて競争優位を失うと警告。歴史的にグローバリゼーションが産業空洞化をもたらしたように、AI時代に同じ轍を踏むことは社会的に許容されないとし、「フロンティアモデルではなくフロンティアエコシステム」の構築を訴える。

---

セクション別詳細要約

The 'company veteran' inside the machine — 機械の中の「ベテラン社員」

Nadellaが示すテスト：「ベースモデルを新しいものに差し替えても、蓄積された機関知識（institutional knowledge）が失われないなら、その企業はAIを本当に所有している」。モデルはレンタルできるが、知見は外注できない。

学習ループを構成する3要素：

1. Private evals（独自評価基準）：汎用ベンチマークではなく、自社ビジネスに即した成果を測るスコアカード
2. Private RL環境（強化学習サンドボックス）：社内の実データと意思決定の履歴でモデルを継続的に鍛える場
3. Queryable knowledge base（検索可能な知識ベース）：組織の記憶を検索可能にし、AIのトークン効率も向上させる

この3要素が組み合わさると「ヒルクライミングマシン（hill climbing machine）」になる。改善されたワークフローが学習シグナルを生み、暗黙知が深まり、さらにワークフローが改善するという複利構造。先行者優位は後から模倣困難になる。

読者への示唆：「どのモデルを選ぶか」ではなく「どんな学習ループを構築するか」が経営の本質的な問いになる。

---

A warning dressed as strategy — 戦略に仮装した警告

一部のAIモデルが全ての経済的リターンを吸収するシナリオへの警告。

• 「少数のモデルがあらゆるものを食い尽くす世界は誰も望まない。全ての価値が少数のモデルに集中すれば、政治経済はそれを容認しない」
• 歴史的アナロジー：グローバリゼーション。1990〜2000年代のアウトソーシングは表面上のGDP成長を生んだが、産業空洞化という実被害を招いた。AI時代の繰り返しには「社会的許容性がない（no societal permission）」とNadellaは断言。
• 解決策：フロンティアエコシステム = 価値があらゆる企業・産業・国に広く流れる構造

「プラットフォームは自分が取り込む以上の価値を上位レイヤーに創出させるときに繁栄する」というWindows時代からのMicrosoftの信条を、AI時代向けにアップデートした主張でもある。

読者への示唆：これは企業戦略論であると同時に、政治経済的リスク管理の議論。AI集中化への規制リスクを先回りして論じている点でも注目に値する。

---

Why now — なぜ今か

Microsoft Build 2026カンファレンス直後のタイミングで発表。2026年、世界の大手テック企業が7000億ドル超のAI設備投資を発表しており、過剰投資・リターン集中への投資家不安が高まっている。

この文脈で「エコシステム全体へ価値を分散させる」という主張は、MicrosoftのクラウドプラットフォームビジネスであるAzureの正当化とも一致している。

読者への示唆：Nadellaのメッセージは純粋な利他主義というより、Microsoftの利害と合致した戦略的ポジショニングとして読む必要もある。

---

まとめ

変わること	変わらないこと
競争優位の源泉（モデル選択 → 学習ループの所有）	人的資本の重要性（AIが増えるほど高まる）
資本の種類（ヒューマン資本＋トークン資本の二軸管理）	プラットフォームの本質（上位に自分より多くの価値を創出させること）
企業の「資産」の定義（固定資産 → 複利的な学習システム）	政治経済的持続可能性の条件（価値の広い分配）

AI要約) Nine things a (technical) program manager does

※この記事は英語の記事をAIで翻訳・要約したものです。

  記事： Nine things a (technical) program manager does
  著者： Ben Balter（GitHub, Technical Program Manager）

---

全体要約

GitHubでProduct ManagerからTechnical Program Manager（TPM）に転向した著者Ben Balterが、TPMが日々行う9つの重要な仕事をまとめた記事。TPMの核心は「プログラムの成功実行（execution）に責任を持つ」こと。

成果（outcome）ではなく実行（execution）に責任を持つという点が他のマネージャー役割と根本的に異なり、そのためにコミュニケーション・リスク管理・関係構築・コンフリクト解決など組織横断的な幅広い役割を担う。

---

セクション別詳細要約

1. Communication, coordination, and facilitation（コミュニケーション・調整・ファシリテーション）

TPMの中核スキル。チームが「出荷」に集中できるよう、周辺の「メタワーク」を担う「サーバントリーダーシップ（servant leadership）」が根底にある。

 
• 関係チームへの意思決定・更新情報の共有
 
• チーム間の依存関係の調整
 
• リソース確保や障害除去によるチームのアンブロッキング（unblocking：前進を妨げる問題の除去）

2. Capture and track the work that needs to be done（作業の把握と追跡）

プログラム管理の基本コンピテンシー。「何をやるか・いつまでに・どの順番で・誰が担当するか・外部依存はあるか」をすべて把握し、計画と現実が一致するよう進捗を継続的に追跡・報告する。

3. Identify, analyze, and mitigate program risk（リスクの特定・分析・軽減）

Product/Engineering Managerが「問題と解決策」で考えるのに対し、TPMは「リスクとミティゲーション（mitigation：リスク対策）」で考える。

 
1. リスク特定：各ワークストリームの成功を脅かすリスクを洗い出す
 
2. リスク分析：プログラムへの影響範囲を定義する
 
3. リスク軽減：ミティゲーションを特定・実施し、成功確率を最大化する

4. Reporting up and across（上下横へのレポーティング）

TPMの直接成果物は「サプライズをゼロにすること」。リーダーシップや関係者に対し、現場の真実（良い状況も悪い状況も）を正直に報告する。TPMは実行に責任を持つため問題を隠すインセンティブがなく、BS（誇張や隠蔽）のない報告ができる立場にある。

5. Relationship management（関係管理）

「挨拶だけの会議」は単なる社交ではなく、将来の協力関係への投資。トランザクション（取引的）ではなくリレーショナル（関係的）なやり取りがプログラム成功率を高める。

普段から「社会的資本（social capital）」を積み立てることで、必要な時に頼みやすい「影響力の圏（sphere of influence）」を形成する。これにより曖昧さが自然な会話で解消されやすくなり、役割が孤立しがちなTPMにとって仕事の充実感にもつながる。

6. Resolve conflict（コンフリクト解決）

関係重視の組織では衝突を避けようとする傾向があるが、TPMはあえてその難しい会話を引き出す役割を担う。中立な第三者として、全員が発言できる場を設け、プログラム成功に向けた建設的な解決を促進する。事前の関係構築と、場での冷静な進行管理が前提となる。

7. Drive consensus（合意形成）

TPMは「スクイッシュネス（squishiness）」という造語でプログラムの曖昧さを表現し、それを減らすことを使命とする。すべての決定・計画は明文化・発見可能・共有された状態にする。

 
• 「一部の人には未知」な曖昧さ：計画を明示的な長文で書き出すことで相互依存や未決事項を炙り出す
 
• 「既知の未知」な曖昧さ：リスクレジスター（risk register：リスク管理台帳）に未決の判断事項を記録し、意思決定者が適切にトレードオフを判断できる状態を作る

8. Boundaryless engagement（境界なきエンゲージメント）

TPMのスコープは組織全体。組織の階層や部門をまたいで（SVPからジュニアエンジニアまで、営業・法務・財務・マーケ等）自由に動き回ることができる。この機動力により、「点を繋ぐ（connecting the dots）」役割を果たし、誰のものでもない問題を拾い上げる。

9. Doing what needs to be done（必要なことは何でもやる）

最終的には、プログラム成功のためなら何でもやる。スプレッドシートのコピペでも、異なるフォーマットの報告書作成でも。TPMは「他に論理的なオーナーがいない仕事のキャッチオール（catch all：総受け）」であり、それ自体がTPMがもたらす独自の価値の一部。

---

まとめ

著者はこの記事を「TPMになりたての自分に渡したかったリスト」として締めくくっている。

PM（Product/Engineering Manager）との違い	TPMの特徴
問題と解決策で考える	リスクとミティゲーションで考える
成果（outcome）に責任	実行（execution）に責任
特定チームのスコープ	組織横断・境界なしのスコープ
機能の「何を作るか」を決める	「どう届けるか」のプロセスを支える

AI要約) AI-first program management

※この記事は英語の記事をAIで翻訳・要約したものです。

記事： AI-first program management: amplifying judgment, not replacing it
著者： Ben Balter（元GitHub Director of Hubber Enablement）

---

全体要約

Program Manager（PM）の仕事は「情報処理」と「判断」の組み合わせ。AIが前者を肩代わりすることで、PMは後者に集中できるようになる。著者の主張は「AIはPMを不要にするのではなく、より少ない時間でより多くの価値を生み出せるようにする」というもの。週明け月曜朝の「週末に動いた十数件のスレッド、静かに顕在化したリスク、誰かが変更したスコープをすべて把握してリーダー会議に臨む」というスクランブル状態は今でも変わらないが、AIと一緒なら一人で戦わずに済む。

---

セクション別 詳細要約

1. From async to AI-augmented（非同期からAI拡張へ）

著者はこれまで3つの考え方を提唱してきた。

1. 非同期コミュニケーション優先 — 会議より書き残すことで、時間・場所を超えて情報を共有する
2. エンジニアリング的管理 — Issue・PR・プロジェクトボードなど開発者が使うツールをマネージャーも使う
3. AIエージェントの活用 — オープンソースで培われた透明性・コードレビューのパターンをAIで拡張する

これら3つは「バラバラなトレンド」ではなく、一本の哲学的な線上にある進化。共通する原則は「作業を可視化する・永続化する・アイデアから行動への摩擦を減らす」こと。AIはこの哲学を加速させるツールであり、哲学そのものを変えるものではない。

2. Communication, coordination, and facilitation（コミュニケーション・調整・ファシリテーション）

PMは「プロの文脈切り替え屋」。エンジニアチーム・プロダクトマネージャー・デザイナー・経営幹部それぞれが異なるメンタルモデルと語彙を持っており、PMはその間を翻訳しながら橋渡しする。

問題はこれがO(n²)のコミュニケーション問題であること。チームや関係者が増えるほど、コミュニケーションチャネルの数は2乗で爆発的に増える。

AIはこの「情報のシャトル作業」を圧縮する。具体的には：

• 200件のメッセージスレッドを数段落の要約に変換する
• 「後方互換性のあるロールアウト戦略が必要なスキーママイグレーションでブロックされている」という技術的な説明を、経営幹部が理解できる言葉に翻訳する
• 会議メモの山から「本当に重要な3点」を抽出する

ただし「何を伝えるか・何を強調するか・いつ対面で話すか」という編集的判断はPMが担い続ける。AIはドラフトと整形を担当するに過ぎない。

3. Capture and track work（作業の捕捉と追跡）

PMの最も地味で重要な仕事のひとつは「話し合われたことが必ずどこかに記録される」ようにすること。すべての会話・決定・約束がIssueやプロジェクトボードに着地するようにする役割だ。

AIを活用すると：

• 会議のトランスクリプトを渡せば自動でIssueを生成できる
• 1ヶ月分のSlackログを解析して「Issueになっていないコミットメント」を発見できる
• 何週間も誰も触っていないIssueをフラグ立てできる
• プロジェクトボードが実態から乖離していることを検出できる

著者はこれを「プログラムの状態を継続的に整合させるリンター」と表現している（リンターとはコードのミスを自動検出するツールのこと）。PMの最大のリスクは「何かが壊れること」ではなく「何かが壊れているのに誰も気づかないまま手遅れになること」であり、AIはそのギャップを埋める。

4. Risk identification and mitigation（リスクの特定と軽減）

PMの重要な役割のひとつは「コーナーを先読みする」こと。実際には多くのスレッドを読み、スタンドアップに参加し、「何かがおかしい」という直感を磨くことで実現している。

AIはその直感をスケールを持ったパターン認識で補強する。具体的には：

• 複数リポジトリにわたるベロシティトレンドを分析する
• 長期間オープンのままのPRをフラグ立てする
• 人間が気づいていない依存関係を可視化する
• 複数プロジェクトを横断したリスク（例：2つのプログラムが同じエンジニアの時間を競合して求めているが、どちらのPMも気づいていない）を早期に浮上させる

著者は以前「透明な協働は知識労働のアンドン（異常を知らせる紐）だ」と書いたが、AIは「すべての紐を同時に監視するアンドン」だと表現している。AIは経験豊富なPMの「これは遅れる」という直感を代替しないが、シグナルをより早く表面化させ、対処する時間を増やす。

5. Reporting up and across（上位・横への報告）

週次ステータスレポートを書くのが好きでPMになった人はいない。しかし明確な上方報告は、経営陣が「どこに注目すべきか・どこには介入不要か」を把握するための最高レバレッジな活動のひとつ。

著者はGitHubで SnippetGPT という社内ツールを構築した。チームの1週間の活動（コミット・マージされたPR・クローズしたIssue・コメントスレッド）を読み込み、エンジニアリングリーダー向けのレポート初稿を自動生成するツール。これにより金曜午後を「記憶と半更新のボードからレポートを組み立てる作業」ではなく「AIが生成した実態を反映した初稿に解釈と推奨を加える作業」に変えた。

重要なのは「初稿」に過ぎないという点。AIが提供するのは「何が起きたか（what）」であり、PMが加えるのは「なぜ重要か・何をすべきか（so what / what now）」という戦略的解釈。そして一度初稿ができれば、同じ週の活動を経営幹部向け・パートナーチーム向け・自チーム向けに書き直すのはほぼコストゼロになる。

6. Relationship management（関係管理）

PMの仕事は本質的に関係性のビジネス。著者がTPMロールに移った当初、シニアPMが「ただ挨拶したくて」という理由でミーティングを設定するのを「仕事中の社交」と見ていたが、それこそがポイントだと後に気づいた。「引き出しが必要になる前に、ソーシャルキャピタルを積み立てておく」という行為だ。

信頼はAIで自動化できない。しかしAIは関係維持を「スケールしながら」サポートできる：

• 「この関係者と2週間チェックインしていない」というリマインダー
• 「前回このチームと話したとき、APIマイグレーションのタイムラインへの懸念が挙がっていた」という文脈の事前サーフェス
• 金曜夕方に認知的余力がなくなっているときの、繊細なメッセージへの返信初稿作成

人間の作業として残るのは「ラポール構築・場の空気を読む・誰かが不満を持っているのかどうかを見極める」こと。AIはそこに向かってより「準備できた・反応できた」状態で臨めるよう補助する。

7. Consensus and conflict resolution（合意形成と対立解消）

競合する優先度を持つチーム間で合意を形成することはPMが行う最難関の仕事のひとつ。必要なのは各チームの「立場（position）」だけでなく、その立場を生み出している「利益・背景（interests）」を理解すること。

AIは以下で支援できる：

• 異なる視点を統合してRFC（提案文書）の初稿を生成する（6チームの意見を1人で組み立てるのは不可能だが、AIなら可能）
• 複数の制約条件を加味した妥協案を提案する
• 各チームの意見を公平に反映したドラフトを作る

ただしAIが限界を迎えるのは政治的ダイナミクスの読解。「チームAの反対意見は、前回のローンチで痛い目を見たことが背景にある」「特定の副社長の沈黙はジュニアエンジニアの沈黙と全く異なる意味を持つ」——こうした「組織の影のトポロジー」をプロンプトから学ぶことはどのモデルにもできない。

8. What doesn't change（変わらないもの）

AIによってPMが不要になるという結論は誤り。むしろ逆。

PMの責務は変わっていない。コミュニケーション・リスク管理・関係構築・合意形成——これらは依然としてジョブディスクリプションそのもの。変わったのは1日の中での「情報処理」対「判断」の比率。AIが前者を多く担うことで、PMは後者により多くの時間を使える。

AIにできないことこそ、優れたPMを優れたPMたらしめているもの：

• 場の空気を読む
• 数ヶ月かけて信頼を築く
• いつ押してよくていつ引くべきかを知る
• 組織の政治を航行する
• データが曖昧なときに難しい判断を下す

これらは人間のスキルであり、AIがルーティン作業を担うほどより価値が高まる。全員が同じAIツールにアクセスできるようになったとき、差別化要因は「そのツールを操る人間」になる。

9. What changes for PMs（PMに求められる変化）

AIファーストの時代に求められる新しいスキル4つ：

① プロンプト設計能力
AIが出す成果物の品質は、入力の質に完全に依存する。「ゴミを入れればゴミが出る（Garbage in, garbage out）」の原則がプロンプトに適用される。明確で具体的なプロンプトを書く能力は、本質的に「良い要件定義能力」と同じ。PMが長年磨いてきたIssue記述・受け入れ条件の書き方が、そのままLLM活用能力になる。

② 使わない判断力
AIをいつ使うべきかと同じくらい「いつ使わないか」が重要。繊細な人事会話・政治的に難しいエスカレーション・つらい週を過ごしているステークホルダーへのメッセージ——これらは人間のタッチが必要であり、AIでは代替できない。

③ 検証・編集能力
AIはスレッドを自信を持って要約し、最重要のニュアンスを見落とす。90%正確で10%が危険なほど誤解を招くステータスレポートを作る。PMは「AIの出力の消費者」ではなく「編集長」として機能する必要がある。方向性を決め、初稿をレビューし、公開前に品質を確保する。

④ AIリテラシー
SlackやメールやGitHub Issuesを使いこなすのと同じように、AIアシスタントを日常ワークフローの基盤ツールとして流暢に扱えることが基本スキルになる。これは「できたら面白い」レベルではなく、テーブルステークス（最低限の前提条件）。

10. The PM as orchestra conductor（指揮者としてのPM）

著者が繰り返し使うメンタルモデルは「PMはオーケストラの指揮者」というもの。

指揮者は演奏中、どの楽器も弾かない。しかし指揮者がいなければオーケストラは機能しない。テンポを設定し、各セクションを適切なタイミングで呼び込み、楽譜を解釈し、個々の演奏を「聴衆を動かすひとつの全体」に変える——これが指揮者の仕事。

AIエージェントはオーケストラの新しい楽器。速く・一貫して演奏でき、かつてなら人間奏者が必要だったパートも担える。しかし楽譜を読み、聴衆を理解し、技術的に正確な演奏を「本当に人を動かすもの」に変える百の小さな判断を下すのは、依然として人間のPMの仕事であり、それは常にそうであり続ける。

---

まとめ

変わること	変わらないこと
情報処理の多くをAIが担う	コミュニケーション・リスク管理・関係構築・合意形成の責務
レポートやIssueの初稿作成がAI起点になる	戦略的解釈・「so what」の付加
プロンプト設計・検証・AI判断が新スキルに	信頼構築・場の空気読み・組織政治の航行
同じ時間でより多くの価値が生み出せる	難しい判断を下すのは人間のPM

書評）チームの力で組織を動かす

チームの力で組織を動かす ～ソフトウェア開発を加速するチーム指向の組織設計 [ 松本 成幸 ]

チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計

所感

内製ソフトウェア開発組織の組織設計のバイブル。

すごく新しい手法などはなかったけど、すべての通ってきた道をきれいに言語化してくれている、という感想。全章分かりみが深すぎる。組織設計に携わるマネージャーみんな読んだ方がいい内容でした。

僕は組織のマネージャーたちと輪読会しました。

刺さったポイントサマリ

チーム指向の組織設計

後続の章を理解しやすくするために様々な手法や知識を学ぶ章。

チーム思考とチーム指向。

• チーム思考
  • 自分の担当範囲だけじゃなく、チームや組織全体の目標・利益を優先して行動する
  • その為にメンバーが個々の知識や能力、経験を持ち寄り、それを最大限に活かすことで互いに協力
• チーム指向
  • 組織の最小単位は個人ではなくチームとして組織を設計する

組織の最小単位は個人ではなくチームであるという考え。

個人のパフォーマンスの差は10倍まで広がるのに対し、チームの差は2000倍まで広がる。（そんなに？

優秀な人材を確保できた企業が勝つなら最初から資金力が強いところが勝つことが決まってしまうが現実はそうではないことが物語っている。

組織の優秀な人材だけを集めたドリームチームがうまく機能しないのは「船頭多くして船動かず」に通じますね。必要なのは多様性、公式な役割（テックリード、アーキテクト、スクラムマスターなど）だけでなく、非公式な役割（名ファシリ、ムードメーカー、潤滑油、事前準備がうまい、など）も多様だといい。

企業やマネージャーはどうしても同質性を好む、自分に似た人を揃えようとしてしまう。偏重しすぎると多様性を持ったチームを組成するのが難しく。

アジャイルの中核価値

宣言の中の「個人と対話」は英語では "individuals and interactions", 個人と対話することではなく意味としては「個人 and 相互作用」。個人の能力と共に相互作用でチームのパフォーマンスを高める。HRT大事。

リーンソフトウェア開発の原則

7つの原則と7つのムダ。

原則6は人を尊重する原則。チームの相互作用を活発化させるのは従来のPM管理型プロジェクトのプッシュ型ではなく、メンバーが自律的に仕事を引き受けるプル型。

DevOpsの原則

フィードバックの原則として、その一つの品質の担保。テストコードで作業しながらフィードバックを得て修正することでフロー上の次の作業にまで問題が出ないように食い止めることをトヨタでは「自工程完結」と呼ぶ。チームの作業で考えると自工程でなるべく品質の作り込みを完結させようとすることが全体のフローを改善しそう。

継続的な学習と実験の原則では、組織やチームの心理的安全性が重要。失敗した個人を責める、改善提案を拒否するような環境、つまり「人を信用しない組織」では誰もが口を閉ざすようになり、問題を見ぬふりする文化に。実験は、仮説を立て、検証し、結果を分析するサイクルの繰り返し。得られた知見を組織に広める。

「コンウェイの法則」が示す組織とシステムの関係

組織のコミュニケーション構造が、ソフトウェアの設計上での選択肢を制約し得る。コミュニケーションパスが形成しずらかったチーム間でシステムコンポーネントのインターフェーズが形成しずらいなど。これを解消するために網羅的なコミュニケーションパスを組織内に築こうとするとコミュニケーションコストが組織の処理能力を削り取ってしまう。ここから導き出されたのが「逆コンウェイ戦略」。システムの最適な構造に基づいてチームやコミュニケーションの構成を再編成する。しかしすでにシステムが存在するとその構造が制約に。初期の設計はたいてい正しくないので、ソフトウェアと組織の設計の進化は歩調を合わせる必要がある。

ビジネス機能に基づく組織化 from Microservices

技術（フロントエンド、バックエンド、DB、など）による組織構造は水平統合型。新機能を1つ開発するだけでもすべてのレイヤーで調整が発生する。ビジネス機能はアプリケーションを使う側から見た機能単位、その単位で垂直統合型のチームを構成することで、チームがエンドツーエンドで機能を開発することを可能にする。チーム間のインタラクションはあるが、ソフトウェアモジュールと同じくチームを高凝集とし、他と疎結合となるよう組織を設計する。ただし、不確実性が高いなどの状況によってチーム間の責任境界があいまいなケースなどは、チーム間が密結合の方が好ましいときもある。協会が明確になってきたらコミュニケーションを低帯域モードに。

プロジェクトではなくプロダクト from Microservices

チームはプロジェクト型のように一時的な存在でなくプロダクト共に長く続く。チームに連続性を持たせ、ドメイン知識を蓄積させる。開発と運用を分離せず、運用からフィードバックを開発に反映する。計画したリリースがゴールではなく、フィードバックループの中でプロダクトを高め続ける。フィードフォーワードループにより予測可能な問題やニーズをチームが事前に認識し、表面化する前に手を打つ。

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

1. バリューストリームを単位に構造化されている
   • 組織もシステムも。
   • プロジェクトが終わって解散じゃなくて、プロダクト、それをより具体化したストリームと共に存在する。ビジネスアラインド。
2. チームの独立性が高い（可能な限り）
   • チーム単独でシステムを変更、テスト、デプロイできる。
3. 安定したチームワークを気づいている
4. チームが行動を自己管理している（誰が：アサイン、何を：やるべきこと、いつ：計画、どうやるか：ソリューション）
   
   • 勝手に決めてよいわけじゃなくて、組織やチームの目的・目標を理解したうえで。
5. システムやプロセスを継続的に改善している
6. 素早く積極的に変化を受け入れる（ためにフローを早く、バッチサイズを小さく、イテレーティブなプロセスに）
7. 徹底した経験主義で顧客価値を探索している（仮説検証、失敗のリスクを小さく）

これらの要件は汎用。組織や時代、外部内部環境の変化に組織を呼応させる。

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

バリューストリームはバケツリレーのようなもの。アイディアや顧客からの要求がプロダクトや機能、サービスとして顧客に届けられるフロー。これを改善する思考が優れた組織を実現する。

阻害する要素が3つで互いに影響しあう。

• コミュニケーションコスト：依頼、調整、合意、承認など
• フローの滞留：待ち時間
• ソフトウェアシステムの内部品質悪化：保守性の悪化

組織設計のひずみによって生じた問題は現場だけで解決できない。

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

コミュニケーションは多いほど良いと考えられがち、減らそうと考える人は少ない。非効率なコミュニケーションを改善するためにはバリューストリーム事態を最適化する思考に切り替えなければならない。

コミュニケーションそのものの時間というコスト：

企画と見積りの往復、企画承認会議からの手戻り。スクラムチームは各種スクラムイベントで17.5%をコミュニケーションに費やすが、減らすとプロジェクトがままならなく。コミュニケーションは実務に充てる時間とのトレードオフ。

コミュニケーションの準備に要するコスト：

資料作成に向けた打ち合わせ、資料作り、レビュー、修正、など。

コミュニケーションを待つ時間というコスト：

承認を得るためのミーティング、レビューを受けるためのミーティングには待ち行列が。定例ミーティングまでの待ち時間も。

注視すべきはチーム境界を越えたコミュニケーション：

上記3つのコストが大きくなるのはチーム外とのコミュニケーション。協働は必要だがチーム間のコミュニケーションは基本的に低帯域幅であるとされている。

影響を与えた要素：

• 企画と開発の分業
  • サイロ化されたプロセスはサイロ内外の情報の非対称性を広げる。バトンを受け渡すときにコストが大きく。
  • 先行のプロセスに後続の意見が反映されず、手戻りになりやすい
• 業務機能が低凝集
  • 自チームのプロセスだけで業務が完結しない
  • 外部の決裁を必要とする（企画承認やアーキテクチャレビューなど）
  • 厳密さを求めるために承認やレビューを単体の業務とみなすことが適する場合もある
• アーキテクチャの不整合
  • 機能の一部が他チームのコンポーネントに依存し単独で進められない

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

企画承認会議待ち、レビューミーティング待ち、他チームの開発完了待ち、など。

フローが進行している時間は付加価値時間、停滞している時間は待ち時間、フローが運ぶ対象はフローユニット。

滞留が生じやすいのはプロセス間のフローユニット引き渡し時と、途中で分割したフローの合流時。

引き渡し時は、引き渡される側のプロセスがビジーだと滞留する。優先順位、プロセスごとのスループットの違い。

滞留を緩和すべきためにはバリューストリーム全体の中のボトルネックとなっているプロセスから改善すること。ボトルネックに関係なくプロセスごとに改善が進められがち。個別では全体のスループットが変化しない。

注視すべきはプロセス境界とフロー分割：

フローが滞留しやすい箇所は前述のコミュニケーションコストが高いことが多く、原因も元をたどれば同じ。

プロセス境界へのアプローチと例）

1. ボトルネックを見つける：アーキテクチャレビューに待ち行列
2. ボトルネックプロセスと先行プロセスの間で機能統合できるか検討する：開発チームからアーキテクチャレビューへの境界が適切か、開発チームにその役割を映したら解消するか。
3. 2で統合できたら新たなプロセスに
4. 2で統合できなければボトルネックプロセスを改善する
5. 1に戻り、次のボトルネックを見つける

フロー分割は、1つの機能を開発するのに複数のチームのコンポーネントに手を入れなければならないような場合。

フロー分割へのアプローチと例）

1. コンポーネントの移管：担当を変える
2. コンポーネントの機能移設：凝集度が高まるように一部を移す
3. コンポーネントの共有：担当関係なく変更する

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

品質が悪いとバグ対応に時間取られるし、変更も時間かかるし、見積もりも時間かかるしバッファが多く必要に。

リファクタリングやリアーキテクティングも必要だが、根本原因が組織設計であることも。

悩ましいのは無謀な意思決定による内部品質の悪化

内部品質の悪化：技術的負債の4象限

1. 無謀 x 無自覚：チームがスキル、知見不足
2. 無謀 x 意図的：負債を楽観視しクイック＆ダーティ
3. 慎重 x 意図的：トレードオフと知って意思決定
4. 慎重 x 無自覚：得た学びと現状とのGAPを問題視（おそらくこれが技術的負債の語源）

第1象限の状態のチームで無理やり開発、既存の有識者がいない、教育が無いとか。

スケジュールを重視して第2象限の意思決定、複雑性が高いのにFeasibility studyやPoCへの投資をせずに進める、スピード優先でロジックのコピー、とか。経験から学ぶ機会がない。

必要なのはシステム思考による観察。原因は一つではない。バリューストリームを通して部門やチームがどのように作用し、フローユニットがどのように流れるかを把握。プロセスやコミュニケーションのパターンを観察し、問題を特定。

組織構造は半年や1年で短期的に変わるのに対し、ソフトウェアシステムのアーキテクチャは短期で変えられない、そのためねじれが生じる。そのねじれがチーム境界を超えるコミュニケーションのコストやフロー滞留、ソフトウェアシステムの内部品質に悪影響を与える。システム構造は組織設計を進めるうえでの制約。トレードオフ。

3つの問題を改善しようとする思考が組織設計を進めるうえでの強力なツールに。

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

ユーザから見える振る舞いの品質（外部品質）が重視され、見えない構造の品質（内部品質）が軽視されがち。内部品質が下がると保守性（理解容易性、変更容易性、テスト容易性）が低下。

組織設計者はこの内部品質を悪化させるような構造を埋め込まないように。

アンチパターンは組織の状況によってはうまく機能するケースもあることに注意。

本ケースの前提：

• 内製開発組織
• 既存システムの運用開発保守
• 複数チームで構成

共有リソースプール：プロジェクトごとにチームを編成している

リソース効率を重視している。受託開発のようにプロジェクトの規模や数がコントロールしにくい組織ではこのやり方はメリットが上回るかもしれないが、内製の組織ではデメリットが目立つ。

デメリット：

• 優秀な人は掛け持ちしがち、ベストなチームにならない。
• 信頼関係が無い状態から始まり、チームビルディングに時間がかかる。いつも形成期から。
• 育つのはPM、チームは他己管理型に。
• 内部品質がチームではなく個人任せになり低下。

解決策は、プロジェクトを組織のアトミックな単位であるチームにアサインする。プロジェクトが大きい場合はサブプロジェクトに分割。

不連続なチーム：プロジェクトに専属チームを配備しない

手が空いてるチームを割り当てようとするため、同じ領域に対して配備されるチームがころころ変わる。領域とはプロダクト単体、機能領域、顧客、など。

デメリット：

• チームの知識の喪失、断片化、再学習のムダ
• 不十分な知識、方針による内部品質の低下
• 経験学習からの「次はよりよく」ができない

解決策は安定したチームを対象領域に専属で配備。何を作るべきかの「プロダクトナレッジ」とどう作るべきかの「プロジェクトナレッジ」を得ることで、「目標の不確実性」と「方法の不確実性」を削減する。

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

業務を安定させることを重視し、熟練させることを重視する。リスクに気付いても目の前の仕事を優先してしまうサガ。変化に対する恐怖。

デメリット：

• 属人化、「ここはAさんが詳しい⇒Aさんしかできない」、バス係数の悪化
  • 属人化した業務を他人に共有する労力にモチベーションが沸かない
• コードも属人化、理解・変更容易性の低下
  • 他の人が読むことを前提とせずコメントやドキュメントも不足

解決策は、チームに若干の流動性を低頻度で継続的に注入すること。メンバーローテなどで新人を受け入れる機会を作る。これらを実施するために、チームの目的や価値観、仕事の進め方などが言語化され可視化される必要性が生じる。既存メンバーが抜ける際には引継ぎが必要になる。

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

多くは、コード共有のポリシーを定義するという意識を持っていないことが理由。無制限の参照については共有の設計やナレッジベースとして扱える点ではメリット。

デメリット：

• コンポーネントに対する知見にばらつきのあるコントリビューターが増加
• コンポーネントの設計から一貫性を奪い、複雑なコードを量産
• コードが複雑化すると、コード変更者が消極的な設計を選択するように
  • 安易にテーブルにカラムを追加、テーブルを追加、など最適化されない
  • 割れ窓理論
• 外部品質にも悪影響

解決策はコードのオーナシップ制を導入。チーム外に対しては「弱いコードの所有」。

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

本番システムからのフィードバックを得る機会を開発チームから奪う。無謀で無自覚な負債（保守・運用経験の乏しさ）・意図的な負債（機能開発に追われる）の両方を抱えやすい構造。

開発担当の仕事

• 新機能追加、大きめの変更と改善
• テストが完了するまで

運用担当の仕事

• 本番システムの安定性と信頼性を高め維持する
• システムのモニタリング、問題の対応
• 緊急対応や復旧
• 運用の自動化
• ミドルウェアやプラットフォームのバージョンアップ

保守担当の仕事

• 開発チームから引き継いだバグ修正
• ソフトウェア内部のフレームワークやライブラリなどのバージョンアップ
• 法改正など影響を受ける仕様変更対応
• 本番トラブル時に運用担当と協力して対応、原因の調査と修正

開発チームがSLO、調査しやすいログ設計、継続的なリファクタリング、データ復旧のやりやすさなどの知識経験を持てず、システムへの当事者意識が希薄に。低品質なシステムは顧客体験を下げビジネスに悪影響。

解決策は、開発・運用・保守を1つのチームで、DevOpsを実践。

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

外部品質の検証と問題の修正がデプロイ直前だけで実施されており（いわゆるQAフェーズ）、テストコードの無い機能コードが量産され、無謀で意図的な負債を抱える。

代表的なテストレベル分類

• ユニットテスト（UT）
• インテグレーションテスト（IT）
• システムテスト（ST）
• ユーザー受入テスト（UAT）

UTやITのスコープもSTで吸収されるケース。機能テストや回帰テストに時間が割かれ、ユーザー体験に関するテストが十分に実施できない。

設計と開発を終わらせてからテストをするというミニウォーターフォールのメンタルモデルが影響。詰め込みすぎた計画、スコープは削れない状況でテストが犠牲に。最後の砦としての頼もしいテストプロセスの存在を、セーフティネットのように感じてしまう。品質基準が定義されていなく、時間が圧迫されると品質機銃を下げてしまう。

こうして出来上がったテストコードの無い機能コードは「レガシーコード」に。

• 既存コードに変更を加えたときに正しく変更できたか判断できない
• 古いコードを後からきれいにするのに時間がかかる
• コード品質を高めるフィードバックループが存在しない

解決策は、品質に対する責務を各プロセスに分担させ、プロセスそれぞれで実施すべきテストの目的を明確化する。開発プロセス内にテストを書く時間の見積りを含める。

アジャイルテストの4象限を組織としてのテストの定義のツールに。

• ビジネス面：ユーザー視点
• 技術面：エンジニアや専門家視点
• チームを支援：テストファースト。満たすべき仕様をテストとして定義し、テストが開発を導く
• プロダクトを批評：仕様と実装、仕様と期待のギャップを見つける

アジャイルでは、品質保証はチーム全体の仕事。

ドメイン知識の過疎地：ユーザーや顧客と開発者の距離が遠い

上流と下流の分業が進みすぎ、ドメイン知識が開発者に蓄積されず、最適なアーキテクチャや設計の選択を困難にし、無謀で無自覚な負債を抱える。

企画・分析と開発を分ける組織構造の狙いの一つは人的リソースは一の最適化。もう一つは同じ職能でチームを編成し専門性を高める。ドメイン知識がそれぞれにサイロ化、受発注構造になり互いの不満が蓄積。

依頼の関係を通してコンテキストは抜け落ちる。

• 何故作るか（Why）が抜け落ち、何を作るか（What）だけ伝えられる→開発チームは知識が不足したまま言われたとおりに作る→「言ったことしかやらない」「ユーザーやビジネスのことを考えていない」ように見える
• 開発チームには統一されたユーザー像がなく、なぜこれが必要なんだという疑問

ドメイン知識が不足した状態ではソフトウェアの内部設計が最適なものにならない。特にデータモデリング。どこに拡張性を持たせるか、どこは不要かの判断を誤り、保守性が低下。

解決策はプロセスのオーバーラップ。スプリントレビューへの企画や顧客の参加、要件定義やUSMへの開発チームの参加。

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

やることは外から主にビジネス視点に基づく意思決定で決められ、技術面での意見が取り入れられず、無謀で意図的な負債を抱える。権限を持つのはライン上のマネージャーのほかにPdMやPjMのケースも。

マネージャー自身の上司や利害関係者からの圧力が大きい場合に、現場に任せることを不安に感じ、自らの制御下において成功確率を上げようとする、など。ビジネス視点と技術視点の問題や課題の目線合わせができない。

継続すると学習性無力感を感じ、チームは「上が」と言い、上は「自分たちで考えない」となる。結果、内部品質が低下。

解決策は、相互理解と信頼関係の構築。対等に意見を出し合って「誰が、何を、いつ、どのように」を共同で決める。ユーザーとビジネスと開発のトライアングルの中でやるべきことを決める。裁量には責任も伴う。RACIマトリクスなど使って権限と役割を明確に。

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

開発フローのクリティカルパスを悪化させる、チーム境界を越えたコミュニケーションの頻度をどれだけ減らせるかが、組織・チーム設計で最も注力すべき観点の一つ。仕事の縦割りを推奨しているわけではなく、フローを早くするコミュニケーションや協力体制、情報や知識の流通、イノベーションを生み出すようなコラボレーションは必要。

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

概要：

自社プロダクトの機能開発業務が、複数の小さなプロジェクトでまわされていて、ほとんどのプロジェクトは1～2名で担当、で並行して進行している状態。プロマネ権限が開発チーム外（企画など）にある場合にしばしば見られる。企画部門のメンバーごとに案件が動く状況など。

症状1：高頻度の見積もり依頼対応

• 企画と開発チームがサイロ化、開発のリソースを無駄にしたくないと企画だけで詳細化して見積もりを依頼、出てきた見積もりが大きいとか仕様変更で再見積もり依頼

症状2：常態的な開発リソース不足

• それぞれの企画リードが自分の企画を最優先、プロジェクトは並列化
• 開発メンバーはプロジェクトの兼任が増えマルチタスク状態、参加するMTGも増える
• 1プロジェクトがより少人数のアサインに
• マネージャーは各プロジェクトの状況把握困難になりメンバーの評価も難しく、メンバーは評価に不満

問題点：プロジェクト間で頻発する調整

• アサインパズル発生。差し込みで頻発する再調整。
• 企画が終わってもすぐ着手できない「未完成の作業のムダ」
• 使われない機能をリリースする「余分な機能のムダ」「作りすぎのムダ」

解決策：サービスインターフェースとしてのプロダクトバックログの配置

• 企画と開発の間のIFとしてプロダクトバックログを配置し、優先順位をつけ、上から2-3か月で着手できる範囲で見積る
• PBIの数に上限を設ければ企画の厳選や見積もり作業のムダの削減に
• PM主体が開発に移り、開発はチームのキャパシティに基づいて計画される

（キューシステムのような）プロデューサー／コンシューマーパターンとなり、開発チームが企画の活動ペースの影響を受けにくくなる。

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

概要：

よくあるフロントエンド、バックエンド、DBAとチームが別れてるようなケース。技術スタックの違い、特定技術領域への集中による専門化などが理由。新しい、専門性を有していない技術領域を強化する場合は役に立つ（例えばAndorid、Next.js、など）。

症状1：プロジェクトは全チームの参加が基本

• チーム単独で機能開発を完結できない

症状2：本番トラブル発生時も全チームでの対応が基本

• システムをエンドツーエンドで理解するメンバーが育ちにくい
• どの領域が問題かも最初は切り分けが難しい

問題点：チーム間で頻発する調整

• APIのIF仕様がいつ決定するか、IT/STの期間、リリースと日程を調整
• チームごとに優先とする仕事が異なり、決定する日程はそれぞれのチームが提示する最も遅い日に調整される

解決策：垂直統合型チームへの移行

• どんな時でも垂直統合が優れているわけではない
• 水平統合が良い場合もあればハイブリッドが適している場合も

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

概要：

開発プロジェクトの実行責任（出すこと）にばかり集中し、それを実行するプロセスの品質に意識が向けられない。プロセスの品質と、人やITの処理能力がパフォーマンスを左右する。

症状1：何をするのか、何ができていなければならないかがあいまい

• PBIがReadyじゃないまま積まれる、来た企画全部見積もる、大きすぎるタスク、割り込みが発生、ブランチ戦略が無い、コーディングスタイルがばらばら、完成の定義がない、コードレビュー基準がない、メンテされないドキュメント、メンテされないCI、テストのスコープがあいまい、リリース基準があいまい

症状2：プロジェクトへの割り込みや変更に対する柔軟すぎる対応

• 知らない間に個人へタスク依頼、頻繁な仕様変更や割り込み、追加見積依頼に即興で対応
• 遅れた分は残業でカバー、コミットメントで疲弊

問題点：プロジェクトの計画と実行が複雑

• 設計、実装など各ステージのアウトプットの品質が安定しないまま次のステージのインプットに（欠陥のムダ）
• 変化への適応ではなくただの無秩序に

解決策1：プロセスの標準化

• 得られる効果はアウトプット品質の安定、言語化による知識のグローバル化、再現性の獲得
• 標準化されたプロセスはチーム間での共有ができ、改善のサイクルが機能する

解決策2：プロセスのカプセル化

• プロダクトバックログなどをインターフェースとし、チーム内部のあらゆるステージへの介入を防ぎ、チーム内部のプロセスの変更を外部影響なく可能にする
• アウトプットのインターフェースとしては受入テストやスプリントレビュー

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

概要：

チームに分掌された業務機能に、一部の要素がパッケージされていない状態。アーキテクチャ決定権を別のアーキテクトチームが保有するなど。これをやる主な動機は専門化による効率化や品質向上など。承認のGateを設け、リスクを回避しようとする。欠けた要素を補うチーム間が強く結合し、チーム単独で業務を完遂できない。

症状1：専門家による行き過ぎた分業

• 代表的なのは設計と実装の分業
• 前工程から後工程への引継ぎコストが伴い、その過程で情報も劣化し、手戻りコストも発生する
• フェーズ完了まで引き渡されないことによるフロー滞留
• 設計上の欠陥を実装でカバーしてしまう、責任を前工程に押し付けてさらに後工程に欠陥が送られる
• 後工程の学びが前工程にフィードバックされない

症状2：過剰なリスク回避思考による承認プロセス

• 承認権限は、チームの外のセントラル部門や役職者が保持、セキュリティ部門や法務部門などはその代表例。妥当なものと行き過ぎたものを見極める必要がある。
• 無駄な承認プロセスは説明資料の準備、審査とのコミュニケーション、審査待ち行列などでチームのフローの弊害に
• リリースを承認するマネージャーはプロジェクトのコンテキストが共有されておらず承認が形骸化

症状3：優秀な人材に頼り切った品質向上

• 独立したアーキテクトチームによる承認プロセスは症状2と同じ問題に

問題点：チーム単独でのプロセス実行が不可能

• 欠けた業務要素がそれ単体で1つの業務機能やサービスとみなせるほど、組織にとって重要なプロセスとして価値を生み出している時は妥当な場合も。

解決策：業務機能の高凝集化、あるいは結合度の調整

• しかし、分割された業務機能の見直しや結合、承認プロセスの廃止などは組織改革に近いレベルの高難易度
• そういうケースでは体制を維持したまま協働の方向に手を加えるのが第一歩
• 工程の分業では作業粒度を小さくして一度の引き渡しコストを下げ、前後をフィードバックループでつなぐ、または前後の工程のメンバーが相互に参加しあうなど
• 承認が必要な個所ではチームが自己判断できるガイドラインを作り、承認が必要な場合も非同期に
• ガイドラインは定期的に見直し
• 優秀な人材によるレビューは、対象をクリティカルなところだけなどに限定

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

概要：

機能追加を繰り返す中で、ソフトウエアシステムの規模もそれなりに大きく。開発体制が強化され、単一チームでさばききれない数の開発要求に応えるために複数チームを配備する中で以下の問題が発生。

• コンポーネントの機能的凝集性の低下
  • 原因はコンウェイの法則。他チームのコンポーネントに変更加えるべきところを自チームのコンポーネントで手っ取り早く済ませる。複雑化したシステムは高い機能的凝集性を実現する設計が難しく。
• 企画体制と機能領域の不一致
  • 機能領域ではなく戦略に基づいて組まれた企画体制により機能領域に囚われない要求が多く出される。組織のコミュニケーション構造とシステム構造にねじれが発生。

症状：所有権をまたいだコード変更が頻発

問題点：コード変更で生じるチーム間での調整

誰が開発するのか、いつデプロイするのかなどの調整がチーム間に生じる。

取り得る手段は3つあるが、いずれも理想的ではない。

• 対象コンポーネントのオーナーチームに変更を依頼
  • 「強いコードの所有」
  • スケジュールや仕様の調整が発生
• 対象コンポーネントの変更やデプロイなどすべてをプロジェクト側のチームが実行
  • 「コードの共同所有」
  • 内部品質が悪化
• 対象コンポーネントの変更のみをプロジェクト側のチームが実行
  • 「弱いコードの所有」
  • オーナーチームがレビューするが、仕様や設計について調整が必要
  • 3つの中では推奨

解決策：チーム間での3種類のコード所有権の使い分け

• 強いコードの所有
  • 開発期間に余裕がある場合や内部品質が求められるプロジェクト
• コードの共同所有
  • スピードが求められるプロジェクトでオーナーチームのスケジュールを合わせられないプロジェクト
  • 但し、変更されたコードをオーナーチームがあとで確認し、必要であれば修正する計画も
• いずれのケースでもないなら「弱いコードの所有」

状況を正しく判断して使い分けることが必要だが、スピード優先になりがちで内部品質が悪化するため、関係者間でよく話し合う。忘れてはならないのが、少しずつでも時間を取って組織とシステム構造を一致させていくこと。

乖離が広がる一方なら、新しいアーキテクチャに少しずつ切り出す。企画体制と機能領域の不一致なら、企画領域ごとに関連性の強いコンポーネントをグルーピングし開発チームの担当領域を見直す。さらに踏み込むならコンポーネント境界を見直しリアーキテクティング。

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

概要：

組織が複数のプロジェクトを常に抱え、並走するプロジェクトの数は一定ではないことから、組織全体で必要となる人的リソース量が一定になることはなく、組織のキャパシティをしばしば超える。こうした人手不足の状況を、マネージャーは兼務ながらもメンバー数を揃えることでチームを機能させようとする。

兼務は1つのプロジェクトで100%の稼働に満たないエンジニアのリソース効率を高めるために利用されることもある。

希少エキスパートをできるだけ活用しようとすることも。属人化によって、エキスパートが抜けると担当業務の効率や継続が困難になっているケースも。

兼務には代表的な兼務比率、日付指定、期間指定、制約なし、の4つの種類がある。

症状1：マルチタスク

兼務をするいずれのプロジェクトも「最優先」と言ってくるのが常。マルチタスクはタスクの終了日を遅らせる要因に（3日で終わる2つのタスクを並行で進めるとどちらも終了に6日かかる）。それぞれのプロセスやルールの違いでスイッチングコストも生じる。

症状2：ミーティングの増加

プロジェクトそれぞれのミーティングに召集される。

症状3：知識の偏りと負荷の偏り

エキスパートに頼り切ったフォーメーションは属人化を深刻にし、エキスパートの負荷が高い状況が続く。

問題点1：フロー効率の低下による市場投入までの時間の悪化

一方のタスクを進めている時、もう一方のタスクは待ち時間。さらにそのタスクに依存する他のタスクも待ち時間に。さらにプロジェクト間の調整でも時間を消費。

問題点2：プロジェクトをまたいだ遅延の連鎖

兼務者が先行タスクの遅延の影響を受けるパターンと、兼務者自身がタスクを遅延させるパターン。

問題点3：コミュニケーションコストの増大による実務時間減少

ミーティング時間により実務時間に充てられる時間を奪われ、差し込みにより集中がそがれる。ミーティングへの参加を控えるとコミュニケーション不足に。

問題4：高負荷とオーナーシップ欠如による内部品質への悪影響

内部品質に向き合う余裕などなく、各プロジェクトに対してオーナーシップも持ちづらく。

解決策：兼務からの脱却

兼務が多発する原因は、プロジェクトチーム制。必要な人員が一定にならず、複数プロジェクトが並走し、組織のリソース管理が複雑に。プロトタイプ開発のような一時的なプロジェクトではうまくいくが、内製の日常的な開発には向かない。

兼務が必要になる状況を減らしていくには以下の3点。

• チームを安定させる
  • プロジェクトではなくプロダクトを担当する
• チームの担当領域を決める
• 企画と開発を一体化する
  • 実現難易度が比較的低いのは、企画体制の「顧客／プロダクトオーナー分離」。開発メンバー主体の安定したチームに企画メンバーをPOとして加入させ、顧客たる企画チームからの要求をPBLで管理。

将来的にチームが担うことになるシステムを先行して開発するプロジェクトなどは、兼務がうまく機能する代表例。兼務者がそこで得たドメイン知識をチームに持ち帰ることができる。

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

概要：

頻繁にアップデートされる共有コンポーネントの専任チーム。ポリシーは強いコードの所有で、コンポーネントに対する変更はこのチームのみが行う。

症状1：コンポーネントに対するマルチバリューストリーム

複数バリューストリームからの要望が絶えない。いずれの仕事を優先すべきか、その調整にいつも悩まされる。

症状2：高コストな仕様決定

既存に対する変更の影響を常にすべてのクライアントに確認する必要がある。

症状3：膨らんでいく機能領域

要求に応えていくことで責務とする機能領域が徐々に広がる。要求の中には特定のクライアントでしか使わない機能があるが、その判断は難しい。クライアントへの貢献が目標に含まれていることも。

症状4：仕事に対するモチベーションの低下

要求に応える性質上、受け身な仕事、保守運用といった仕事をこなすことになる。バリューストリーム全体から正式メンバーとして扱われず外部委託先のような扱いを受ける。

問題点：複数のバリューストリームをまたいだボトルネック化

いずれの要求を優先させるかを各クライアントの間で調整することがクライアントのフローを停滞させやすい要因に。クライアントも共通仕様に合わせるために余計なコストが発生。共通化により無駄をなくし組織全体の開発パフォーマンスを上げる目的のはずがボトルネックに。

解決策：専任チームの解散と弱いコードの所有

社外提供するコンポーネントなら主体的な開発プロジェクトを担えるが。専任チームを残すのであれば負荷の軽減策の1つとしてコンシューマー駆動契約テストが使える。

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

概要：

企画ラインの並列化に伴い1つの開発チームを2つ以上のバリューストリームに配備。

症状：チームに対するマルチバリューストリーム

人気者チームと似た症状。バリューストリームの数だけPOが存在し、優先順位の折り合いがつかない。

問題点：バリューストリーム間での開発リソースの競合

チームレベルでの兼務状態に。

解決策：バリューストリームと開発チーム配備の整理

企画ラインと開発チームの数を合わせる。企画ラインの統廃合、開発チームの分割（リーダー育成が必要）、バリューストリームの流量に着目する（流量が多いもの少ないもので組み合わせる）、（コアプロダクトやコア技術でないものについて）社外サービスや社外リソースを頼る。

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

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

プロジェクトチーム体制はメンバー構成が一時的、エンジニアリング部門として「共有リソースプール」としてプロジェクトに人をアサインする。固定化しすぎると「行き過ぎた固定化」アンチパターンとなり業務が属人化。「流動性原則」が組み込まれ、チームの長いライフタイムの中で意図的にメンバー構成を少しずつ変化させる状態が安定。

責務が一時的なチームは「不連続なチーム」のアンチパターン、プロジェクトのたびに責務が決定される。

安定に固執しすぎると組織レベルでの「変化の適応」への阻害要因に。

チームの再編5つのパターン

• メンバーを一人ずつ参加、離脱
• 大きくなったら分ける
• 統合する
• 各チームから人を集めて特定のプロジェクトに集中するチームを作る
• 学びや刺激を得るためにチーム間でメンバーを入れ替える

不確実性が非常に高いプロジェクトを進めるときなどはチームを安定させないことが有利に働くこともある。臨機応変に。組織で対応する「共有リソースプール」パターンか、自己組織化してチームを組成するFASTか。

「安定」原則はあくまでもメンバー構成や責務が一時的であることや固定化することで生じる問題を避けようとする考え方であり、それ自体を目的にすべきではない。

安定したチームは形成期、統一期を得て機能期を持続させられる。

• 形成期：チームが集まり目標や役割を確立する段階
• 統一期：ルールや手順を確立し協力関係を築く段階
• 機能期：チームワークを発揮し目標を達成する段階

安定したチームはプロジェクトやイテレーションを得るたびに学びを得て、「目標の不確実性」に対するプロダクトナレッジと「方法の不確実性」に対するプロジェクトナレッジを蓄積する。それらは不確実性を削減し、継続的な改善を可能にする。

安定したチームはベロシティに代表されるようなプロジェクトの予測可能性を高めることができる。

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

アトミック性が高い組織では、「チームとして仕事を引き受ける」。人手が足りない他チームを支援するときでさえチームで引き受け、支援元先どちらのチームもメンバー構成が変わらずチームの安定につながる。

この原則を適用した「アトミックチーム」の実現ことが本書の組織設計の中核。

アトミックチームはオーケストレーション型のプロジェクトマネジメント（PMが管理する方式）に比べ、引き受けた仕事をどうやって進めるかをチームが決めていくことで自己管理型に近づいていく。

自己管理型に近づいていく過程で、メンバーそれぞれがチーム思考で動けるようになることが期待できる。メンバーの部分最適な行動を全体最適に引き上げる。

アトミック性に対する理解が進めば、組織をスケールする考え方が「チーム指向」となり、単なる増員ではなくチームの追加という観点に変わる。どんなスペックのエンジニアが何人必要か、ではなく、どんなチームが必要か、チーム構成を変える必要はないのか、といったことを念頭に組織設計を進める。とはいえいきなりチームは増やせないので、加入メンバーを既存チームに追加しつつ、必要数に達したらチームの分割やマージで再編する。そのためにはリーダーの数が必要になるため、意図的・計画的にそういう層を育てる必要がある。

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

兼務メンバーの存在は組織設計を複雑にする。

専属メンバーはチームに対する帰属意識を高め、オーナーシップが醸成され、仕事に対する品質も高まる。チーム内のコミュニケーション機会を通して、チームの共通の目的や目標の理解を深め、協働する意欲を高めることでコミットメントも高まる。

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

コミュニケーションコスト

• 1人の人が双方向で定常的にコミュニケーションできるネットワークの大きさの限界
• 人数が増えるとコミュニケーションパスが増大し、生産力よりもコミュニケーションコストのオーバーヘッドが増大
• 組織のスケールは少人数チームを増やす

主体性

• 不確実性の高い仕事では主体性が推進力
• 多人数チームではどうしても少数一部の人に残りの人が従う形に

バッチサイズ

• バッチサイズを小さく保つことは経験主義的なアプローチでは必須の要素
• 少人数チームであれば必然的にバッチサイズは小さく

アジリティの獲得

• 前述の要素により変化への適応能力に優れたチームが育つ

マネジメントコスト

• 人数が多ければマネジメントが行き届かなく

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

小規模で低頻度に、半年から1年の周期で組織内それぞれのチームの1名程度を別チームに移動させるスイッチングで充分。

属人化の緩和

• 知識経験豊富なメンバーを異動させることで、引継ぎプロセスの中で属人化した仕事が言語化・可視化される
  • 新しいチームメンバーのオンボーディングでも
• 退職で去ってしまう前にこの手が打てればリスクも低く、社内にいるため相談もできる

マンネリの解消と人材の育成

• 特定の人が得意な仕事を毎回担う構造は、他の人の成長機会を奪い、当人の新しいチャレンジの機会を奪う
• 属人化による個人のパフォーマンスの獲得ではなく、チームとしてのパフォーマンスの向上が目指す姿
• チームや組織への流動性の注入は、日ごろの1on1などを通じメンバーそれぞれのキャリアについて話しておくことが欠かせない

ラーニングゾーンへの移行

• 固定化しすぎるとコンフォートゾーンに
• コンフォートゾーン化したチームが新しいメンバーを受け入れると、外部の分かや新しい価値観がチームに混ざり、停滞した空気に刺激が加わり再びラーニングゾーンへ

知識とネットワークの組織的拡大

• 流動性のないチームの特徴の一つとして、コミュニケーションがハイコンテキストになり、チーム内のコミュニケーション効率が高まる
• が、馴染みすぎるとそれが当たり前になり、相手とのコンテキスト差を意識せず、他チームメンバーとローコンテキストで話そうという気遣いがなくなる
• この状況では、チームの知識が組織内で流通せずローカル化
• 流動性によりハイコンテキストなコミュニケーションは軽減し、異動したメンバーは異動前後のチームで情報流通網として機能
• 知識を流通させるのではなく、知識を持つ人を流通させる

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

フィードバックループは様々なレベルで生じる。

プロジェクト > リリース > イテレーションのフィードバックループ

• プロジェクトのループでは、組織の目標に対するフィードバックが得られる
  • KGIやそれに連なるKPIとして計測された実績値
• リリースのループではユーザからのフィードバックが得られる
  • リリースによる「機能」はユーザ価値に関する仮説を検証するために作られたもの
  • リリースによる本番稼働は、プロダクトの保守や運用を改善するためのフィードバックも得られる
• イテレーションのループでは顧客や関係者からフィードバックを得られる
  • スクラムチームが最も注力すべきはスプリントレビュー
  • イテレーションからの振り返りを得てチームは継続的に成長し、プロダクトとプロセスの質を高めていく

日次的なフィードバックループ

• デイリースクラムで、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させる
• 開発を終えたアイテムが「完成の定義」を満たしているかを検査することでアウトプットの品質に対するフィードバックになるとともに、イテレーションの正確な進捗を知る手段になる

継続的なフィードバックループ

• CI/CDで早期に実装されたコードへのフィードバックを得る
• TDDで、テストを書くことで設計に対するフィードバックを早期に得て、テストの実行で機能コードのテスト結果としてフィードバックを得る

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

組織設計者は、チームの責務をミッションや業務分掌、業務機能、プロセスに分けて認識し、それらを構造化してとらえることが重要

• ミッション：組織やチームが「なぜ存在するのか」「何を達成したいのか」
• 業務分掌：業務機能のセット
  • 開発、保守、運用などの業務機能と、プロダクトAや機能Xといった担当領域
  • フロントエンドやバックエンドなどの技術領域
  • 戦略的な担当領域
• プロセス：業務機能の具体的な進め方について設計・実装したもの
  • 業務プロセスや運用フロー、「スクラム」など
  • プロセスの設計・実装はチーム自身が担う

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

企画ラインに沿って形成されるバリューストリームにチームを専属配備し、その体制を安定させる。

企画ラインとは、なんらかの業界づけられた領域ごとに組成され、その領域の成長に責任を持ち、それぞれが担当する領域の成長を描いたろおーどマップを持つ、「プロダクト企画」機能を担うチーム。

ストリームアラインドなチームは安定原則による効果、特に「知識の蓄積による継続的な改善」が狙い。

1つのチームは1つのバリューストリームに配備することが望ましいが、企画ラインの数の方が多い場合は「バリューストリームの合流点」アンチパターンを元に解決策を検討する。

結合度の低い複数のチームが1つのバリューストリームに配備されることもある。iOSチームとAndroidチームなど、バリエーション分割した場合。フロントエンドとバックエンドのように結合度の高いチームの場合、チーム間の調整が頻発しフローを停滞させる原因となる。

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

健康管理サービスの例：バリューストリームは健康に興味のあるコンシューマー、医療機関、保険会社の3つ。それぞれに開発チームが配備され、それぞれに昨日を提供するコンポーネントの所有権を持ち、外部・内部品質に責任を持つ。

コンポーネントのコードはチーム内では共同所有し、チーム外からの変更が必要なニーズに対してはバランスの良い「弱いコードの共有」とする。

チームによる技術スタックの選定を適度に制限することで、弱いコードの所有を機能しやすくさせ、技術知識をグローバルしやすく、メンバーの流動性の敷居を下げる。

コードは組織内に仕様と共に公開し、チーム境界を超えるコミュニケーションのコストを下げる。

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

同じプロダクトでWeb、iOS, Androidなど対応プラットフォームが分かれている場合。コードが分かれ、技術スタックが異なる。バリエーションごとに設計・実装するので、1つのチームで複数バリエーションを開発するメリットはない。

企画ライン1つに対し複数バリエーションに分かれても、バリエーション間の結合もなく干渉しあわない。

バリエーションごとの位置づけが大きく異なる場合は、企画ラインと共にバリューストリームを分けることも。

それぞれのバリエーションで異なる開発をすることで、並行して複数の仮説を検証することもできる。成功であれば他のバリエーションに移植したり、洗練してから移植したり。

遅延コストが高いと判断するときは全バリエーションで同時開発。

特定のバリエーションにばかり開発が集中する場合は2つ以上のバリエーションをまとめて担当するチームを作り負荷を分散、マルチスキル化。

人員数が少ない時はチームを1つにまとめてマルチスキル化を進める。小分けにして1～2名のチームを作るとバス係数が悪化。

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

ストリームアラインドを前提としてチームがエンドツーエンドの全ての技術領域で機能を担当できるようにするのが垂直統合。調整コストを少なくし、デリバリーを短縮する。

今や、技術スタックの発展でそれぞれの学習コストが高くなったことで水平統合型の編成が自然な流れに。しかし、そうすると1つの機能開発で複数チームが絡み合うことになり非効率に。

垂直統合の前提として、コードやコンポーネントが機能領域ごとに凝集され、他の領域と疎結合であることが望ましいが、そうではなくても大部分はチーム単独で進められる。

iOSとAndroidが共有するようなバックエンドはどちらかのチームに担当させ、コードの所有ポリシーを「弱いコードの所有」とし変更を加えられるようにする。新機能を優先的に開発するバリエーションがあるならそのチームをオーナーとする。バックエンドを専任チームとした場合は、「人気者チーム」のアンチパターンに注意する。

組織として十分な技術力を有していない技術領域は水平統合チームとして切り出し、短期間で技術力を高める。同じ技術領域を扱うチームであれば知見の共有を促進できる。

アーキテクチャ量子に着目してチームが引き受ける範囲を決める：

機能的凝集性、独立してデプロイ可能かどうか、同期的なコナーセンス（接続、同期的に呼び出しの依存があるAPIなど）、この3つの特徴で定義づけられるアーキテクチャ量子を1つのチームで引き受けるのが基本。

但し、アーキテクチャ量子のサイズによっては3つを段階に分けて1つのチームが引き受ける範囲を削減する妥協も必要。例えば3段階目の同期的なコナーセンスの範囲を外す。ただし、外した機能を担当するチームと結合度が高くなることに注意。同期的なコナーセンスを担当に含めるかどうかを検討する際、それが複数のバリューストリームを持っている場合は「バリューストリームの合流点」のアンチパターンになるため、担当に含めない方がよい。

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

分離するとチームミッションの分離によってコンフリクトを生じさせやすい。開発チームは「優れた機能をユーザーに届ける」、保守・運用チームは「安定性・信頼性の高いサービスを提供する」こと。例えば高頻度のリリースという手段を挟んで対立する。

DevとOpsが統合されたチームは、開発と保守・運用業務にそれぞれ何割を割り当てるのかの基準値を決め、業務のバランスを取る。大きなイシューはPBIへ、緊急の割り込みに備えたバッファなどで計画を調整。それぞれの業務の時間を記録しモニタリングして、乖離は振り返りなどで議論。緊急対応に追われ続けていたら品質が下がっているサイン、など。

オンコールローテーション、デプロイパイプラインの整備、自動化、といったプラクティス。

運用業務の増加傾向、未解決のバグチケット数などについてステークホルダーと少しずつ話し合い、課題意識を合わせ、必要ならプロジェクト化。

保守・運用業務の負荷が高い状態では、チーム統合の前に運用チーム主導で保守・運用業務の改善を。改善がシステムのモダナイズといった大規模なものであれば開発チームも合流してプロジェクト化。場合によってはアイソレーションパターンでそれぞれのチームから人を集めてチーム編成。

統合できない組織では保守のみ統合、運用のたすき掛けなどの選択肢も。

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

クロスファンクショナルなチーム組成。

企画機能の一部と開発を統合する：

アイディアの創出や大まかな企画をまとめることは企画チーム、それをPBLで管理、詳細化、開発するところは企画機能の一部を移管した機能横断型チームで。最大の難関は企画プロセスと開発プロセスのサイクルの融合。「デュアルトラックアジャイル」はその解決策として注目されている。

品質保証と開発を統合する：

いわゆるシフトレフト。アジャイルテストの4象限のQ1～Q3をQAメンバーと一緒に。

無理しない：

機能横断型チームを作るのは難しいので、まずはスプリントレビューなどのイベントから機能横断型に。

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

垂直統合、DevOps、機能横断型チームを少人数で機能させるためにメンバーのマルチスキル化が必要。マルチスキル化で多人数化と内部分業というもんだいをかいけつする。

人員不足はマルチスキル化で解消できることもある：

シングルスキルばかりだと、例えばフロントエンドは人手不足、バックエンドは余裕がある状態などが生まれる。こういったケースにおいては、フロントエンドの人材を追加するのではなく、バックエンドエンジニアがフロントエンド技術を身に着ける。

T型やπ型人材を推奨する：

マルチスキルといっても、自分の専門分野を1つ、2つ以上深堀しつつ、専門分野以外のスキルも浅く広く身に着けていく。

但し、1つをとことんというキャリア志向もあるので無理に押し付けない。

組織のリファクタリング・リアーキテリング

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

マネージャーが組織アーキテクトとなってアーキテクチャを示し、現場のチームがそれに沿ってチームやプロセスを設計・実装する。ITアーキテクトが将来的な変更や成長性の対応を見据えてアーキテクチャを設計し、具体的な設計や実装をエンジニアに任せる点と共通する。

マネージャーは必要に応じて組織設計をリアーキテクティングし、チームはプロセスの設計・実装をリファクタリングし続ける。このため、マネージャーは組織設計の方針や意図を明確に言語化すべき。

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

組織の問題を見つけ出し、適切な組織設計を導き出すために組織の現状を正しく理解する必要がある。

Satisfaction and well-being 満足度と幸福度：

これらはベロシティとの相関関係があり、幸福度がベロシティの先行指標となった事例が確認されている。

Performance パフォーマンス：

アウトプットではなくアウトカム観点で評価。信頼性やバグの少なさ、サービスの健全性、顧客満足度、顧客獲得やリテンション、機能の利用状況、コスト削減、など。リリース後の指標だけでなく、設計・実装したコードの品質評価なども。

Activity 活動：

アクションやアウトプットの数を計測する指標。設計書、仕様書、作業項目、プルリクエスト、コミット、コードレビューなどの量や数。

例えばバグの数はアウトプットではなく、アウトプットされたコードの質を評価するものなのでパフォーマンスに該当する。ストーリーポイントにおいては、完了したポイント数は活動指標、リリースしたポイント数はパフォーマンス指標、後者はユーザーに提供された機能の大きさをはかる代替指標として（必ずしも価値の大きさとは限らないが）。

Communication and collaboration コミュニケーションとコラボレーション：

個人間やチーム内、チーム間の協力関係や情報連携の質を評価するディメンジョン。ただ定量的な計測が難しいので、コストをかけ過ぎずアンケートなどを活用したほうが良いかもしれない。

Efficiency and flow 効率とフロー：

フローの滞留や手戻りを押さえ、どれだけ効率的にフローを進められているか。

リードタイムや、そこに含まれる待ち時間と付加価値時間は代表的な指標。

フェーズによってリードタイムの特性が異なる。

開発プロセスを開始し、設計と実装からコードレビュー完了までのフェーズでは、待ち時間を縮めることに集中したほうがリードタイム短縮に効果的。

デリバリーフェーズでは、自動化率と効率性を高めることがリードタイム短縮に効果的。

指標の選択：

SPACEを使った開発生産性の計測は、1．テーマを決める、2．そのテーマを計測する代表的な指標を1つか2つほど選ぶ、3．その指標に加え、1のテーマに沿って各ディメンジョンの指標をさらに追加する、という3つのステップで進めるのが良い。

例えばバリューストリームを通るフローを増やすことを考える場合、デプロイの頻度を指標として選択できる。バッチサイズを小さくし、仮説検証のフィードバックループを素早くする。デプロイ頻度を高めるとリリースに伴うオーバーヘッドが伴うため、効率性を高める活動となる。

デプロイの頻度を中核にして指標を選ぶなら、次のようなラインナップが考えられる。

• S:
  •  チームの幸福度
    • フローを増やすために無理させてないか
    • ツール：アンケート
• P:
  •  ユーザの満足度
    • 高速なフィードバックループが機能しているか
    • ツール：NPS
  • 変更失敗率
    • スピードと引き換えに品質が犠牲になっていないか
• A:
  • プルリクエストのサイズ
    • 大きなPRは待ち時間を長くする
  • 勤務時間の長さ
    • メンバーの健康面やプロジェクトの健全性を観る
  • チームの稼働率（リソース効率）
    • プロジェクトに75~80%以上稼働するあたりから疲労や不満が顕在化し、他のメンバーのレビューを放置したり、チーム思考を失い問題に気付いても対処しなくなる
• C: プロセス間の手戻り率
  • 本来はEに位置づけられるが、コミュニケーションの質や量を計測するための代替指標として
• E: デプロイの頻度、コードレビューの待ち時間、継続的デリバリーの自動化率とリードタイム

ソフトウェアの内部品質について指標を選ぶ場合の例として、注目するのは「コード・テストカバレッジ（定量指標）」と「チームによる保守性の評価（定性指標）」。後者は、理解容易性と変更容易性を定量化しないことに対する補完。それらを中核にして指標を選ぶ場合は次のようなラインナップが考えられる。

• S:
  • チームやプロダクトに対する誇り
    • ツール：eNPS
• P:
  • コードカバレッジ、チームによる保守性の評価、欠陥の数、変更失敗率、計画予実
    • リリース前と後の欠陥数を計測
    • コードの品質が低いほど計画通り進まない
• A:
  • プルリクエストのサイズ
    • サイズが大きいとレビューの精度を下げ、コンフリクトの修正が多くなる
    • 内部設計がまとまっていないことでサイズが大きくなることも
  • コントリビューター数
    • 多くの人が変更を加えると一貫性を失う可能性がある
    • 他チームからのコントリビュートは境界が正しくない可能性
  • マイナーコントリビューター数
    • commitの少ないコントリビューター、つまり経験が乏しく、設計が適切でない可能性
• C:
  • 他チームからのプルリクエスト受入数
    • Aのコントリビューター数と同じ目的、絞ってもよい
• E:
  • 開発と保守・運用の投下工数比率
    • 保守・運用の比率が高くなっていることは、内部品質を改善する時間を確保する交渉材料となる

指標を正しく活用する

情報と知識に変換したうえでの組織全体への共有：

各チームが独自に発見した改善点や成功事例を組織全体に。

チームの活動や状況・状態は基本的にブラックボックス。内部に抱える問題や課題も外から見えない。チーム内で解決できない問題や課題を解決するにあたり、関係者に相談したり、進めることへの承認を得るうえで、チームの状態を指標で可視化することはメリット。

急に「コード品質を高める活動が必要」と唐突に関係者に相談が持ち込まれると、なぜ今になってと不信感につながる。常日頃から状態を可視化しておくことで、深刻化する前に話し合われることが期待できる。

データだけを伝えると、他のチームと比較して低い場合などにチームの評価を下げられかねない。それを恐れて開発生産性の可視化にチームが否定的になるかもしれない。そのため、データだけでなく情報と知識も併せて伝える。指標にはそれぞれ、計測する目的やコンテキストがあり、それに基づいてデータを読み解いたり、組み合わせることで情報になる。その情報を蓄積し、経験や学習を通じて理解・解釈されたものが知識。チーム外にデータを提供するのは、あくまで情報や知識のエビデンスとして。

システムレベルのアウトカムレベルであれば関係者に関心をもってもらいやすいが、遅行指標であることが多いため、チームが関連性を感じられる指標を選ぶ。例えば「コード品質」の場合、MAUは遠すぎるので、変更失敗率や計画予実にするなど。

組織として重要視することの明示：

組織として何かを指標化したり、そこに目標を設定する行為は、重要視すべきものがなんであるかを組織全体に示すことにつながる。例えば品質向上を重要視する組織なら、それを宣言し、バグの数やテストカバレッジなどの品質指標を設定し、それによってパフォーマンスを評価することを説明する。

指標の数字をハックしても、現在のステータスを知ることも将来を予測することもできないので、悪意のあるハック行為はまれ。

但し、指標に集中するがあまり、目的を見失わないように。意味のないテストコードを充実させても、意味のあるテストかどうかは別。目標に対するこのような自己目的化は、目的やコンテキストの意識付けができていないことと、計測指標が限定的であることが原因。前者は言語化してしっかり伝え、後者はSPACEなどを用いて複数の観点から指標を選択。

アウトカムが最優先：

• エフォート、我々はどれだけ一生懸命働いているのか？
• アウトプット、我々は顧客にどれだけのものを提供しているか？
• アウトカム、顧客はどれだけの価値を実現しているのか？
• インパクト、どれだけの価値が私たちに戻ってくるのか？

開発生産性を高める活動は、アウトプットを増やしたり、そのリードタイムを短くすることに注意が向けられがち。それは仮説検証のサイクルを回し続けるための手段。

SPACEでのシステムレベルのパフォーマンスは、アウトカムやインパクト、活動はエフォートやアウトプットに位置づけられる指標。コミュニケーションとコラボレーションや効率とフローは、アウトプットに至るフローを観察する。適切な指標をパフォーマンスにも配置しておくことができれば、アウトカムを最優先にして取り組める。多次元的な観点で開発生産性を計測する利点はここにある。

• 指標選びは、網羅しようとせず、チームや組織の関心事に基づいて関連性と一貫性を持たせ、絞り込むようにする
• アウトカムをシステムレベルのパフォーマンス指標として設定し、それを意思決定のためのガイドとする

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

不確実性が高く予測可能性の低い環境の中、私たちが使える道具は、探索的アプローチと変化への適応に基づくいくつもの意思決定。

ソフトウェア組織のマネージャーが担う組織設計とは、組織規模のフィードバックループを繋ぐアーキテクチャを築く活動。

マネージャーは組織をエンジニアリングする。

AIエージェント MCPメモ

How to configure MCP servers using "npx" on Windows and Mac

Windowsでnpxを使ったMCPの設定にはまったのでメモ

Mac

"slack": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-slack"
  ],
  "env": {
    "SLACK_BOT_TOKEN": "{token}",
    "SLACK_TEAM_ID": "{team id}",
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}

Windows

"slack": {
  "command": "cmd",
  "args": [
    "/c",
    "npx",
    "-y",
    "@modelcontextprotocol/server-slack"
  ],
  "env": {
    "SLACK_BOT_TOKEN": "{token}",
    "SLACK_TEAM_ID": "{team id}",
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}

書評） アジャイルチームによる目標づくりガイドブック

アジャイルチームによる目標づくりガイドブック OKRを機能させ成果に繋げるためのアプローチ [ 小田中 育生 ]

アジャイルチームによる目標づくりガイドブック OKRを機能させ成果に繋げるためのアプローチ【電子書籍】[ 小田中 育生 ]

うちの会社でもいわゆる「MBO」式の目標設定と評価制度を運用しているが、まぁこれが義務的で面白くないわけで、でもなかなか時間使う業務なので、せっかくならもっと前向きに有用に取り組むヒントはないかと思い読んでみました。

対話、リズム、集中、アウトカム、などアジャイルのエッセンスが目標づくりとその運用に応用されるイメージが沸いたので、義務的じゃなく成長と成果に結びつく目標づくりのヒントになりました。

内容粒度については、目標づくりに役立つ幅広いプラクティスが簡潔に紹介されていて、例えば「インセプションデッキ」と言うプラクティスがてでくるが具体的な実践の仕方については触れられない。

なので、

• これまでいろんなアジャイル関連の本を読んできた人にとっては「あーあれをここで使うのか」と知識の応用のきっかけになる
• まだそんなに事前知識がない人にとっては「これ気になるから深掘りしてみよう」と、いろんなプラクティスへの入り口になる

という感じかなと受け取りました。

また、読み進めていくと人としてうまく行くための心や姿勢のあり方の話も多くて、目標設定の枠を超えて、人やチームや組織の中でうまく仕事をするヒントも得られました。

刺さったポイントサマリ

お互いをしろう

インセプションデッキ

• インセプションデッキはそれを作り上げていく過程にも大きな意味がある
• まずはチームの前提を揃えることにフォーカス
• 誰かが残念な思いをしてしまうかもしれない、ということに気を配り対話を避けてしまうと、チームの焦点がぼやけることに

ドラッカー風エクササイズ

• 互いの強みを知る

Disagree and Commit 

• チームとして最終的に決定した方針には全員でコミットする

ワーキングアグリーメント

• チームが仕事を進める上で守るべきルールや基準
• チームにとっての当たり前が新しいメンバーにとって当たり前じゃない可能性がある
• 定期的に見直す

わくわくする目標をつくろう

SMART

OKR

• 昨対比はなぜその目標を目指すのかを明確に
• 要求の不確実性、そのKRを達成したらOを達成するのか
• 技術の不確実性、そのKRを達成する方法は道筋が立っているか
• CFR、対話、フィードバック、承認
• OKRをツリーにすることに無理があるならツリーにこだわらない
• Google Re:WorkのOKRスコアカードがおすすめ
• 目標は絞る、どれも大事、はどれも大事じゃないように扱うのと同じ

チームのリズムをつくろう

• チャレンジングな目標を立て、達成しやすい小さな中間目標を設定する

開発サイクル中の成果

• 開発サイクルのゴールとしてクイックウィン、目標とのギャップを埋める小さな成果を明らかにする

• レビューは褒める会じゃなくて生み出した成果から学びを得る場

ふりかえり

• 新しいアクションを生むKPT
• Small starfish ある程度チームが成熟してきたら、新しいアクションよりも既存のアクションの更新を

マインド面での変化をもたらす

• Fun Done LearnのLearnが少ないのはチャレンジか足りてないのかもしれない

チームで余白を持つ

• 木こりのジレンマ
• 業務時間内の自己研鑽をしつこいくらいに奨励する、ためらいを持つ人は多い

チームのマインドを育てよう

• 責務とは行為にある。その結果にあらず。行動には全力を尽くすが、その行為の結果には執着しない
• とはいえ失敗は怖いので、小さく失敗する
• 失敗は、この方法はうまく行かないということの発見
• 経験→省察→概念化→実践 ＝ 結果→分析→仮説→アクション
• 成功体験と同じように失敗体験とその学びを共有する
• 意見が対立した時は認知の4点セットで掘り下げる
• 一見ネガティヴな行動の、その人の肯定的意図を捉えてその目線で話す、リフレーミングでポジティブに見方を変える、ただしわかった風に考えない
• 善意からの行動で情報対称性や主体性を毀損することがある（忙しいだろうからやっとこうとか）
• 心理的安全性が低い状況ではまず匿名でフィードバックを集める

目標の共同所有

• 全員で達成すれば良いいうマインドの醸成
• 個人の評価はピアフィードバックやこまめな擦り合わせなど対策

ウィンセッション

• どうしてうまくいかなかったのか、ではなくどうやったらもっと上手く行くか

戦略とは今やるべき3つの優先度リスト

• 迷った時に立ち返れる優先度リスト、なぜその順位なのか徹底的に考え抜く
• 曖昧な部分があれば、より良い目標を作る良い機会となる

助け合えるチームになろう

• 関係の質が低いまま成果にこだわるサイクルにはいると、成果の圧により対立や無関心といった歪みを産む
• 好き嫌い表でチームメンバーの得意不得意、興味関心、成長機会を知る
• 費用対効果の大きなアクションをほぼほぼやってしまった時にチームは停滞感を感じる。勇気を持って労力の大きなタスクに向き合うときかもしれない

チームの開発生産性を測ろう

• Four Keys とDevOps Capability とSPACE
• VSMは暗黙知や特定の人しか知らない情報を引き出すことも目的
• 測定、数値達成を目的化すると本来の目的が歪む
• OKRでOを達成した時に、結果としてどのような変化が生まれているか、という問いへの答えとしてKRを設定する
• 開発生産性の向上を独立した目標とするか、既存の目標に関連する成果指標とするか

チームの外と向き合おう

• 解空間内の探索、あらゆる可能性を検証する
• 解空間を狭める、Oに対する相対的な立ち位置を明らかにするメトリクスを定め、計測結果から注力ポイントを探る
• 最初は注力ポイントを探ることがKRとなり得る
• ビルドトラップ、顧客のニーズではなく、自分たちの都合を優先し不要な機能をリリースする行為
• スコープの調整では「why now」で今やることで得られるもの、今やらないとどういう問題があるのかを明らかにする

ゴールにたどり着いたその先に

• 自分たちが大切にしている要素をインセプションデッキやOKRから洗い出し評価し、次のアクションについて話す
• 結果から行動を変化させていくシングルループ学習、行動の背景にある前提やメンタルモデルまで変えていくダブルループ学習、インセプションデッキの更新はダブルループ学習を活用する良い機会

書評）リモートワーク・マネジメント

リモートワーク・マネジメント 距離と孤独を乗り越える強いチームづくり【電子書籍】[ セダール・ニーリー ]

リモートワーク・マネジメント [ セダール・ニーリー ]

感想

リモートワーク関係なく普通にいいマネジメントの本だった。

ポイントサマリ

ローンチ（リローンチ）・ミーティング

• チームの成果の60％はプリワーク（事前準備・チームの設計）、30％はローンチ・ミーティング、10%は日々の実際のチームワークによって決まる
• プリワーク
  • どういう形のチームにするか、果たすべき機能やメンバー構成や設計などを決めるチームの誕生前に行うもの
• ローンチ・ミーティング
  • チームとしてどのように業務を進めていけば最大限の成果を上げられるかを全員が理解し合意する
• リローンチ・ミーティング
  • 過去現在未来を点検し、状況変化に応じて方向付けや方向修正
• 見解の不一致は必要
  • どういう方法で目的地に到達するかの対立は構わないが、目的地の認識は合わせる必要がある
  • 目標・役割・リソース・規範の認識を一致させる
• チームメンバーは自分や他人がチーム内でどのようなポジションにあるかを正確に把握していない
  • どの業務やチームにどのくらいの時間を割くべきかの認識に違いがある
• コミュニケーション規範を設定する
  • リモートコミュニケーションのルール、チャットツールの使い方などについて全員がストレスを感じず孤独にならないように基本原則を定める
  • ざっくばらんな交流チャンスがない分、それを埋める規範が必要
  • 会議のアイディアはデジタルに書き出しておく、業務連絡のタイミングを決めておく、仕事と家庭の境界線の守り方、など

信頼関係

• 信頼とは相手の発言や行動や判断に従っても大丈夫そうだと安心でき進んで従おうと思えること
• リモートでは信頼関係構築の基盤となる毎日の自然発生的なインフォーマルな交流がない
• 認知的信頼と感情的信頼
  • 認知的信頼の基盤となるのは「この人ならあてにできる、頼れる」という確信、頭で判断する
  • 感情的信頼の基盤となるのはお互いに対する思いやりや気遣い、友情と似ている
  • リモート環境下では認知的信頼は早々にピークに、感情的信頼がピークに達するには時間がかかる
• 信頼関係を後押しする直接情報・反映情報
  • 直接情報、リモートにいる同寮の個性や生活ぶり、仕事の状況を知ることで相手の仕事を信頼しやすくなる
    • MTG冒頭や1on1での雑談などで情報を知る
  • 反映情報は相手の目に映る自分の姿への認識、同僚が自分を理解してくれていると思えれば相手を信頼しやすくなる
    • リモート環境でも相手を注意深く観察することで収集できる
    • メールやチャットのレスをいつくれるか、同意してくれることが多いか不満そうなことが多いかなど、規範が人によって違うことに気づければ、気づきを元に自分の行動を修正できる
• 感情的信頼
  • 確実な方法の一つが自己開示、コミュニケーションの中で自分の情報を小出しにする、プライベートな話を織り交ぜる（節度は守る）
• リモートワークにおける信頼構築
  • 完璧な信頼ではなく、まずは情報収集や業務遂行にとって必要十分な「適度な信頼」を確保する
  • まずは「必要十分なだけ」メンバーを信頼する。メンバーの能力の判断材料をチェックし限定付きで相手を信頼する。その一方で今後も信頼し続けられるか否かの判断材料を積み重ねていけばいい

生産性

• 監視ツールの導入は「お前を信用していない」というメッセージとなり、チームワーク成功の土台が崩れる
• チームパフォーマンスの3つの評価基準（ハックマン）
  • 結果
  • 個の成長
    • 自分はこのチームに所属することで充実しているか、成長を実現できているか、チームはそこを気にかけてくれていると実感できるか
    • 成果にダイレクトに影響しなくても、仕事満足度の上昇につながり、ひいてはチーム全体の生産性強化につながることが多い
  • チームの結束
    • チームワークのスキルを身に着ける必要がある
    • 人間的なつながりがその学習プロセスに欠かせない
• 自律性
  • 自分で自分をコントロールできる環境にあることが自律性であり、自分が信頼されている証拠であり、それが主体性を生み、個人の都合に合わせたスケジュール設定が可能になることで効率改善を促す
  • リーダーは監視をやめ、必要なツールやリソースを提供するにとどめ、各人の業務目標を達成する方法は本人が一番理解していると考える
• 仕事がしやすい環境
  • リモートで自律性が増し仕事と家庭のバランスがとりやすくなり幸福感が増す一方で、自宅環境次第では持続的作業に必要な集中力が欠け葛藤や不安を感じることがある
  • リーダーは仕事環境の最適化を目指してサポートする
• チームの結束
  • 結束は物理的距離は関係なく、他のメンバーとのやり取りの頻度と、メンバー間のやりとりから形成される人間関係の質の2つの要因できまる
  • オフィスビルに掲げてある社名やブランド名に変わるアイデンティティ、チーム目標を思い出させるシンボルを示すのはリーダーの役割

デジタルツールの活用、解決すべき課題

• テクノロジー疲れ
  • 連続したビデオ会議は疲れを引き起こす
    • 移行時間、後処理の時間を確保できない
  • ビデオ会議だけでなく多様なツールをTPOに合わせて選択する
  • リーダーはこのチームにどういうコミュニケーションカルチャーを形成したいかを決める
• 相互知識
  • 有効なコミュニケーションが成り立つ条件の一つが「共通の前提や理解の存在」
    • それが無いとリモートワークを阻害する
  • 例
    •  自分の背景情報を相手に伝えないことで理解されない
      • 別のPrjで忙しい状況、など
    • メールチェックの頻度の習慣を伝えないことで共有速度に差が出る
      • なかなか返信をくれない人だと思われたり
  • トラブル時に情報が少ないと、原因を人間関係や個人的問題に帰する傾向がある
  • 相互知識の上でデジタルツールを利用する
• 社会的存在感
  • リモートワークの課題の一つに対面の機会が無いこと
  • この問題を考えるときの一つの視点が「社会的視点」
  • 親密性：対人距離感
    • リアルタイムで相手の顔が見えるデジタルメディアのほうが親密性は高くなる
  • 即時性：心理的距離
    • メッセージの送り手が受け手との間に感じている心理的、感情的つながり
    • 言葉を通しても伝わるし、服装や表情などでも伝わる
    • これらをどの程度見たり感じたりできる課は利用するテクノロジーに左右される
  • 効率性
    • メッセージを伝えるうえでどのメディアが最も有効か
  • 非言語コミュニケーション
    • デジタルメディアがどの程度対面と同じようなディティールが伝えられるか
  • どういうデジタルツールを使うかは「何を伝えたいか」に加え「どの程度の社会的存在感を達成したいか」も含まれる
• リッチメディアとリーンメディア
  • リッチ＝伝達情報量が社会的存在感も含め多い、シンクロ
    • 対面＞ビデオ＞ソーシャルツール
    • 曖昧で多義的で不明瞭な状況ではこちらが効果的
  • リーン＝伝達情報量が少ない、非シンクロ
    • 文書＜メール＜チャット
    • 単純明快な状況ではこちらが効果的
  • 人間関係な良好なチームではリッチメディアからさほど恩恵をうけないこともあり、逆に多用することでテクノロジー疲れが起きる恐れも
  • 逆にまだ人間関係が構築できていないチームではリッチメディアでコミュニケーションするほうが明らかにチームワークが良くなる
  • 人間関係が悪化したチームでリッチメディアを使うとチーム環境がこれまで以上に悪化する
• 繰り返しコミュニケーション
  • チームメンバーを動かすために複数の種類で繰り返しコミュニケーションする
  • ラインの権限を持つマネージャの例
    • まずは非シンクロなコミュニケーションで「このままではまずい」と伝える（メールなど）
    • それでも部下の行動がすぐに変わらないとシンクロなコミュニケーションを通じて本当にまずい事態であることを伝える（チャット、ビデオ会議など）
    • ここで始めて温度感が伝わることも
  • ラインの権限を持たないプロジェクトマネージャーの例
    • 最初にシンクロなコミュニケーションで伝える
    • 後で非シンクロなコミュニケーションで補強する
    • 非シンクロメディアなら受け手が時間をかけてメッセージを処理・消化できる
• 文化の違い
  • 多様な文化を受け入れ、自分の信念や認識を押し付けない
    • 対面を重んじる文化ではリッチメディアが好まれる
    • まずは雑談から入る文化の人にはチャットのほうが適している
    • 欧米文化では悪い知らせはリアルタイムで伝えるものとされるが、グローバルチームではまずメールで知らせて受け手が非シンクロに情報を処理してからのほうが良いことが分かった
  • 業務にどういうメディアを使いたいかに関しては、必ずコミュニケーションの相手に意見を聞く
• ソーシャルツールの活用
  • 地理的距離がある中、相手が何をしているのかが見えることでつながっている実感が生まれる
    • 業務外コンテンツや雑談も適度に存在したほうがよい
  • ツールを導入するだけでは不足、ツールを利用することで社員に、組織全体にどういうメリットがあるのか、リーダーが方向性を示す必要がある
    • リーダーもツールに参加し規範を見せる
    • 公式発表限定の利用だと社員はしょせん管理職の情報周知手段でしかないと受け止める