大きな組織では、異なるタスクを遂行するチームが発生し分業が必須になる。分業は調整と統合を必要とする。調整は連絡や仲介を行い複数のチームを協働させる。統合はプロセスと成果を統合する。
チームあるところにステイクホルダーあり。ステイクホルダーと関係を築き、期待や関心を管理することをステイクホルダー・マネジメントという。ステイクホルダーを特定し、その考えや情報を把握する。チームにとって重要なステイクホルダーを特定し、要求や期待を引き出す。
ステイクホルダー・マネジメントには交渉が不可欠になる。交渉はゼロサムではない。自分と相手のBANTA（Best Alternative To Negotiated Agreement：次善の策）とRV（Reservation Value：次善の策のメリット）を考えて、落とし所を探る。

第5章　戦略実現のためのマネジメント

この章では以下の内容が取り上げられている。

戦略について
内部環境と外部環境の分析について
戦略の実行方法としての予算と目標
組織デザインの考え方
意思決定とは何か

ただ、自分の中で戦略の実行について整理ができず、自分なりに以下の図のように整理してみた。
戦略実行のイメージ

組織デザイン

ケイパビリティ

近年はVUCAの時代とも呼ばれ、不確実な物事に対して柔軟に対応できる組織であることが重要になっている。変化に対して柔軟なことを示す「リソースを適宜組み直して活用する組織の能力」をケイパビリティという。エンジニアリングにおけるケイパビリティについては、DevOps Research and Assesmentが実施した研究があるという。この研究では、ケイパビリティの指標として5つのカテゴリーからなる計24個の指標が挙げられている。

継続的デリバリ
- 本番環境のすべての成果物をバージョン管理システムで管理
- デプロイメントプロセスの自動化
- 継続的インテグレーションの実装
- トランクベース開発の実践
- テストの自動化
- テストデータの管理
- 情報セキュリティのシフトレフト
- 継続的デリバリの実施
アーキテクチャ
- 疎結合
- チームへのツール選択権限を付与
製品とプロセス
- 顧客フィードバックの収集と活用
- 全業務プロセスの作業フローの可視化
- 作業の細分化
- チームによる実験の奨励と実現
リーン思考に基づく管理と監視
- 負担の軽い変更承認プロセス
- 事実上の意思決定におけるアプリケーションとインフラの監視結果の活用
- システムの健全性のプロアクティブチェック
- WIP制限によるプロセス改善と作業管理
- 作業の可視化による、品質の監視とチーム内コミュニケーションの促進
組織文化
- 創造的な組織文化の育成
- 学びの奨励と支援
- チーム間の協働の支援と促進
- 有意義な仕事を可能にするツールなどの資源の提供
- 改善を推進するリーダーシップの実現や支援

ケイパビリティの可視化として、Four Keysというメトリクスがある。メトリクスを活用することで、日々の開発が数値として可視化され具体的な議論に繋げることができる。

デプロイ頻度：本番環境へのリリース頻度。
変更のリードタイム：コードの変更がコミットされてから本番環境稼働までの所要時間。
変更障害率：デプロイが原因となり本番環境で障害が発生する割合。
サービス復元時間：本番環境での障害から復旧までにかかる時間。

チーム立ち上げ

チームの立ち上げには2通りある。

新規のチームを立ち上げる
- 一からメンバーを集めるため目標達成に最適なチームを組める可能性があるが、人間関係も一からの構築となるため立ち上げに時間がかかる。
既存のチームの目標を変更する
- 既存チームの流用となるためすぐに機能するが、目標に対して最適にならない可能性がある。

チームの人数

チームの人数も目標によって異なる。専門性の高低が判断基準となる。

専門性が高く複雑な業務が要求される場合
- 情報共有や議論が適宜必要になり、コミュニケーションが必要になる。チームのメンバーが多いほどコミュニケーションのチャネルは指数関数的に増加し、コントロールが難しくなる。このことから少人数が適しており、多くても10名ほどである。
専門性が低く単純な業務が要求される場合
- マニュアル化でき、業務知識の情報共有がしやすいため人数を増やしやすい。

チーム編成

エンジニアリングのチームには2つのパターンがある。

コンポーネントチーム
- フロントエンドやバックエンドなどのコンポーネント単位で分割されたチーム。メンバーが特定の領域にアサインされるため開発効率が良くなり、必要なタイミングでのアサインもしやすく稼働率が調整しやすい。一方で、コンポーネントでチームが分断されているため、コミュニケーションコストが増大するタイミングが発生しリードタイムは長くなる。
フィーチャーチーム
- フロントエンドエンジニアやバックエンドエンジニアなどをひとまとめでチームを編成し、機能を開発する。コミュニケーションコストも低く、リードタイムも少なくなりやすい。しかし、メンバーが他領域にも踏み込まなければならないケースも多くリソース効率が悪くなりやすい。

4章ではシステムと組織の関係性について記載があったように、システムのアーキテクチャを元に組織を編成する逆コンウェイの法則というアプローチもある。

第6章　人材の成功にコミットする

採用面接

面接では、担当者が応募者にさまざまな質問を投げかけ、思考やスキルが採用基準を満たしているか確認する。行動面接は応募者の具体的な行動とその結果を確認する面接手法。例えば大きな成果や困難だった課題について聴き、具体的なストーリーが浮かび上がるよう質問を重ねる。構造化面接は応募者全員に対して同じ質問内容で、同じ基準で評価する面接手法。評価にはルーブリック（評価基準表）を用いることがある。例えば、解決が困難だったインシデントのエピソードについて聴く場合、以下のようなルーブリックとなる。
インシデント対応のルーブリック

人材評価

人材評価には、人事制度の3本柱とよばれる評価制度、等級制度、報酬制度の3つがある。評価基準は成果評価、能力評価、情意評価があり多面的に評価することを目指す。以下は一般的な評価プロセスの図である。

　評価には納得性が重要であり、納得性が低い場合は離職にもつながってしまう。納得性の高い評価には以下の5つが挙げられている。

公正な評価
評価制度が正しく運用され、悪意のある利用から守られていること。
評価基準の明確化
評価対象や評価尺度が具体的であること。
評価基準の理解
評価基準が皆に伝わっていること。
評価基準の厳守
評価基準が守られていること。
評価責任の自覚
評価者が、被評価者の成長に責任があることを自覚して評価すること。

また、評価するにあたり認知バイアスや評価エラーにも注意する必要がある。

認知バイアス

ハロー効果
確証バイアス
後知恵バイアス
結果バイアス
選択支持バイアス
フレーミング効果

評価エラー

印象評価
中心化傾向
寛大化/厳格化傾向
論理的誤謬
対比誤差
期末効果
逆算化傾向

第7章　技術とわたしのマネジメント

セルフマネジメント

瞬間のマネジメント

セルフマネジメントにおける最小単位は瞬間のマネジメントとなる。自身の感覚、感情、思考を認識し、これらの事実を客観的に分析する。分析することで自分の認知フレームを発見し、事象に対してこれまで取れなかった選択肢を取ることが可能になる。

感想

本来は毎月1章の投稿予定でしたが、都合により今回で残分を一つに凝縮してまとめることになりました。各章の内容は薄くなってしまいましたが、気になったものに絞ったことで取り組みやすかった気がします。
4章では組織構造について触れましたが、SESをやっていると自社組織と現場業務のマトリクス組織のようだなと感じることがありました。この辺りを深く考えていくと、SES業界の各社のカラーが見えてきそうです。
7章は特に薄くなってしまいましたが、主に技術戦略とセルフマネジメントの章を扱っていて、技術戦略はDesign Itやアーキテクチャの基礎の方が詳しいため今回は触れませんでした。セルフマネジメントについては、日頃リーダー業務を務めるなかで仕事を止めないように即断即決を意識することもありましたが、半ば瞬発的な反応のまま考えてしまうなと振り返れるところがありました。瞬間のマネジメントを取り入れて判断の精度を上げていきたいと思います。

はじめに

第4章 組織のマネジメント

組織構造

組織とシステム

組織は人から成る

第5章 戦略実現のためのマネジメント