うまとま君の技術めも

2015年新卒入社した社畜の勉強内容などなど

エンジニアリング組織論への招待 Chapter4 - 読書メモ

エンジニアリング組織論への招待

目次

書籍

Chapter4:学習する組織と不確実性マネジメント

いかにして不確実性を管理するか

  • 不確実性をマネジメントするには、不確実な要素をリストアップして、それらを比較する

スケジュール予測と不確実性

スケジュールマネジメントの基礎

  • スケジュールマネジメントとは次の3つに注目して改善を行うマネジメント
    • 制約スラックを削減する
    • 見積もりの予測可能性を上げる
    • プロジェクトバッファの消費を可視化し改善する
  • 出来る限り早く「いつリリースされるのか」という時間の精度を上げる

制約スラックとクリティカルパス

  • 制約スラック
    • 依存関係を考慮した上で、発生してしまう無駄
  • クリティカルパス
    • 依存関係から導かれるスケジュール遅延の原因となる作業の流れ
  • 成約スラックを削減するには?
    • 「リソース制約」を取り外す
      • 「この作業はXさんにしかできない」といった属人化した作業
    • 「依存制約」を取り外す
      • 「2つの作業を同時に行えない」といった作業の依存関係

悲観的見積りと楽観的見積り

  • プリンシパル・エージェント理論
    • 経済における人間関係を「依頼者」と「代理人」との契約の束として捉える考え方
    • 「依頼者」と「代理人」における情報の非対称性により、「悲観的見積り」や「楽観的見積り」が生じてしまう

スケジュール不安の見える化

  • 「間に合うか、間に合わないか」ではなく「スケジュール予測が収束していくかどうか」を管理する
  • CCPM
    • スケジュール不確実性の削減をプロジェクトバッファの消費という形で「見える化」する
  • 多点見積り
    • 個別のタスクに対して複数パターンの見積りを行い、タスクごとの不安を洗い出す
  • 個別の不安量がわかったら
    • 「不安なタスクの順に問題解決をする」ことで、スケジュールマネジメントを有利に進める
    • 「不安の大きいタスク」と「不安の小さいタスク」にタスク自体を分割する
      • 「不安部分のみを切り出して」実施することが出来る
  • 不安の原因を取り除く相対見積り

計画でなく実績から予測する

  • 小さくスプリントを繰り返す
    • 同じ様なタイムボックスを繰り返すことで、実績から将来の予測を行いやすくする
  • ヴェロシティと生産性
    • ヴェロシティが多い ≠ 生産性が高い
  • ヴェロシティを用いたスケジュールマネジメント
    • ヴェロシティの平均値・偏差 → 最悪値・最高値 → 完了予定を推定

要求粒度と不確実性

  • 作る工程よりも「何を作るか」が決まっていく過程の方が不確実性をもっていてブレ幅が大きい
    • スケジュールマネジメントには要求が詳細化されていく過程もマネジメントする必要がある
  • ボトルネックを探してスループットを上げる
    • 「プロダクト」には完了がない
    • 機能が要求されてから価値が生まれるまでの「川の流れ」を見る必要がある
    • バリューストリーム

スケジュール不安はコントロールできる

  • 不確実性をリリース予測の幅として表現する
    • スケジュール不安が可視化できる

要求の作り方とマーケット不安

スケジュール不安とマーケット不安の対称性

  • スコープバッファの成立条件
    • 優先順位の高い機能ごとに完了する
  • プロダクトに最初に触る顧客
    • プロダクトオーナー
    • プロダクトに触れることで「目的不確実性」を減少させる
  • ユーザーストーリー
    • 各機能を顧客にとっての物語となるよう分解したもの
    • 「XXXは、XXXすることができる、これによってXXXできるからだ。」

マーケット不安はいつ削減できるか

  • 安いコストで仮説を検証していき、不確実性が十分に下がったら大きな予算をかける
    • 「仮説」
      • 直感的に少ない断片情報だけから「このようにしたらビジネスが成立する」というビジネスモデル全体
    • 「検証」
      • 「仮説として成立しているか」を精査し、その後に行うアクションの全て
  • 価値と不確実性
    • 機能の優先順位を考えるときは、価値とリスクのマトリクスに分類する
  • リーンキャンバス
    • 仮説が仮説として成立するためには、ビジネスが成立してできた後のイメージが重要
    • 仮説を明らかにするためのフォーマット
      • 1:顧客の課題「どんな痛み・ニーズを感じているか」
      • 2:顧客セグメント「誰がどの位それを感じているか」
      • 3:独自の価値「他にはない独自の価値はなにか」
      • 4:解決策「どのようにその痛みを解決するか」
      • 5:チャネル「どこから顧客をどのくらいの値段でつれてくるか」
      • 6:収益の流れ「お金はいつどのようにいくら支払ってもらうか」
      • 7:コスト構造「売上に対してどんなコストがどれだけかかるか」
      • 8:測定項目「何がどれくらいなら上手くいっているか」
      • 9:競合優位性「なぜ自分たちがそれをやると上手くいくのか」

スクラムと不安に向き合う振り返り

  • スクラム
    • 「役割の整理」と「いつどんな会議を開くか」をまとめたもの
    • いつどのようにチームが課題と不安に向き合うのかを測定し、改善を行うためのタイミングを矯正するためのフレームワーク
    • 「不安への向き合い方」をチームが学習するための方法論
  • スクラムにおける役割
    • プロダクトオーナー
      • チームのROIを最大化させるため、ビジネス上の要件からプロダクトバックログを作成する
      • プロダクトバックログ
        • ストーリーを優先順位に並べたもの
    • 開発チーム
      • プロダクトバックログに従ってどのように作るべきかの意思決定を行う
    • スクラムマスター
      • プロダクトオーナーと開発チームの間に存在する「ボトルネック」を解消する
  • スクラムにおけるイベント
    • スプリント計画
    • デイリースクラム
      • 前日まで課題やその日やることを簡潔に共有する
    • スプリントレビュー
      • プロダクトオーナーがインクリメントをレビューする
    • レトロスペクティブ
      • 次に向けての改善アクションを決める
Whatの検査 Howの検査 日々の検査
Plan スプリント計画 スプリント計画 デイリースクラム
Do スプリント スプリント その日の作業
See スプリントレビュー レトロスペクティブ デイリースクラム
対象 インクリメント プロセス 前日までの作業

どこに向かって、どのように振り返るか

  • プロダクトチームにとって振り返るべきゴールとは
  • 振り返りの流れ
    • 0:ゴール再認識
    • 1:テーマ設定
    • 2:現状整理
    • 3:よかった探し
    • 4:問題の洗い出し
    • 5:問題の深堀り
    • 6:対策の決定

不安を知りチームマスタリーを得る

  • チームマスタリーを得ている状態
    • チームが自分たち自身の手によって広い視野での問題解決を進めることができる状態
    • 自己組織化された状態

書籍