『チームトポロジー』で参照されていて関心をもったので読んでみた。

「組織全体やグループとして保持する機能や能力」をケイパビリティと呼ぶそうだ。組織の文化や仕組みなどによって何ができるようになっているか。

本書ではソフトウエアデリバリ（作ったソフトウェアを、使える状態にするまでの流れ）を改善するという視点から、以下の24のケイパビリティをピックアップしている。

1. 継続的デリバリのケイパビリティ（Continuous Delivery Capabilities）

ソフトウェアを迅速かつ信頼性高くデリバリするための技術的基盤。

• 全成果物のバージョン管理: すべての成果物（コード、インフラ設定など）をバージョン管理下に置く。
• デプロイメントプロセスの自動化: デプロイプロセスを完全に自動化し、ワンクリックで実行可能にする。
• 継続的インテグレーション（CI）: 頻繁にコードベースに統合し、ビルドとテストを自動で実行する。
• トランクベース開発: 長期間ブランチを使わず、小さな変更を頻繁にメインライン（トランク）にマージする。
• テスト自動化: すべてのテストレベルで自動化を導入し、高速かつ信頼性の高いフィードバックを得る。
• テストデータ管理のサポート: テストに必要なデータの準備と管理を容易にする。
• セキュリティの左シフト（Shift Left on Security）: 開発ライフサイクルの早い段階でセキュリティを組み込む。
• 継続的デリバリー（CD）: 常にデプロイ可能な状態を維持する。

---

2. アーキテクチャのケイパビリティ（Architecture Capabilities）

デリバリーのスピードと安定性を高めるアーキテクチャ設計に関するもの。

• 疎結合なアーキテクチャの利用: チームが他のチームとの調整なしに、独立してアプリケーションをテスト・デプロイできるアーキテクチャ（マイクロサービスなど）を採用する。
• チームの権限委譲: チームが自分たちで使うツールを選択し、設計上の決定に影響を与えられるようにする。

---

3. プロダクトとプロセスのケイパビリティ（Product and Process Capabilities）

リーンな原則に基づき、市場と顧客への価値提供に焦点を当てる。

• 顧客フィードバックの収集と実装: 顧客からのフィードバックを設計とデリバリープロセスに継続的に組み込む。
• バリュー・ストリームを通じた作業フローの可視化: ワークフローのボトルネックや停滞を把握しやすくする。
• 小バッチでの作業: 作業を小さな単位に分割し、頻繁にリリースすることでリスクを減らし、フィードバックを早める。
• チームによる実験の促進と実現: 製品やプロセスを改善するための実験をチームが自由に行えるようにする。

---

4. リーン管理と監視のケイパビリティ（Lean Management and Monitoring Capabilities）

効率性を高め、継続的な改善を可能にする管理手法とシステム監視に関するものです。

• 軽量な変更承認プロセス: 外部の変更承認委員会（CAB）ではなく、ピアレビュー（相互レビュー）など軽量で迅速な承認プロセスを採用する。
• ビジネス上の意思決定に役立つアプリケーションとインフラの監視: 監視データを利用して、システムの状態だけでなくビジネスへの影響を把握する。
• システム動作状況の積極的なチェック: しきい値や変化率の警告などを用いて、問題が発生する前に兆候を検知する。
• プロセス改善とWIP（仕掛り作業）制限の管理: 仕掛り中の作業量を制限（WIP制限）し、フローを改善することで、効率を高めボトルネックを明らかにする。
• 作業の可視化による品質の監視とチーム間のコミュニケーション改善: ダッシュボードなどで作業の進捗と品質を可視化する。

---

5. 文化のケイパビリティ（Cultural Capabilities）

高いパフォーマンスを実現し、持続させるための組織文化に関するものです。

• 生成的な（高信頼な）文化の醸成: 信頼と協調性が高く、失敗を非難せず、学習を重視する文化を築く。（ウェストラム博士のタイプ論に基づく）
• 学習の奨励と支援: 失敗から学び、知識を共有するための時間とリソースを提供する。
• チーム間コラボレーションのサポートと促進: サイロを解消し、チーム間の協調的な働き方を奨励する。
• 仕事に意味を持たせるリソースとツールの提供: 従業員が自分の仕事の目的を理解し、そのために必要なツールと環境を提供する。
• 変革型リーダーシップのサポートまたは体現: ビジョン、鼓舞、知的な刺激、支援的な姿勢、個人的承認を通じて部下の成長とモチベーションを促すリーダーシップを発揮する。

これらは著者らの調査により統計的に効果があることが分かっている。というより、それらを統計的に示して見せることが本書の目的である。

そして、これらは、開発が円滑に進むだけでなく、組織全体のパフォーマンス（業績）の向上、ビジネスの安定性・レジリエンスの向上に加え、チーム間の協調性と生産的な文化の醸成、学習や成長の促進、燃え尽き症候群の抑制など組織文化の改善との関連も証明されている。

思うに、自分の組織や部署にとって必要なケイパビリティとは何かを明確に定義し、その実現を重要なミッションと位置づけて確実に実装していくことが重要なのだろう。
ぼんやりとこうなるといいなと思っているだけでは、ほとんどそうはならないし、いったんケイパビリティを獲得してしまえば、なんであんなことをやっていたのかと、元には戻れない。（設計事務所にとってのBIM技術獲得もその一つだろう）

うちの部署にも念願だった専門性を持った開発者がジョインし、これまで、直線的に力技で開発していた環境が、一気にモダンな環境へとシフトしていっている。（これは付け焼き刃の知識では何から手を付けてよいかも分からなかった）

まさに今、継続的デリバリに関わるところの改革を行っているわけで、なるほどこれがこうなるのか、というのを目の当たりにできているのはある意味幸運かもしれないな。

技術による基盤環境の構築が、業績や、メンバーのエンゲージメント、組織文化をも改善していく、というのは当たり前のことに思うけれども、実際はそこが軽視されて後回しにされることも少なくない気がする。そこの相関が証明されていることが理解できたのが一番の収穫。そこに手を入れられるかどうかが明暗を分けるのだろう。（といっても、開発の業界ではあたりまえのことをやっているだけだと思う）

まー、一番忙しいタイミングで環境がどんどん変わっていくのでめちゃめちゃ大変なんだけど。

でも、ここで後回しにしたらたぶんアウトなんじゃないかという気がする。上向きになるか下向きになるかの分岐点の改革をしていると思って踏ん張ろう。

もう少し落ち着いたら、生活を整えていろいろバランスを組み直さねば。