読書記録 - カイゼン・ジャーニー

読んだメモです

全編通してストーリー仕立てで、スクラム開発とその周辺のフレームワークがガッツリ登場する。合間に入る解説も砕けた文体なのでささっと読めるのが良かった。

反面、軽く触れるだけのモノもあるので詳しくは原典を漁る必要があると思うが、キーワードを知るだけでも価値はある。

チームビルディングだけでなく、SIの現場における提案、製品開発のクオリティ指針に繋がる話など、読む価値のあるターゲット層が幅広い。マネージャや開発者サイドだけでなく、営業やマーケも目を通しておくとタメになりそう。

「第2部 チームで強くなる」以降はロールとしてプロダクトマネージャ、スクラムマスターが登場するが、これらが存在しているチーム構成かつスクラム開発前提でカイゼンの方向で話が進むため、レガシーな環境だとまずこの時点で人材と開発ノウハウが不足する。とはいえ少しずつエッセンスを取り入れて、自分達のチームにフィットする取り組みをどう実践するかの取捨選択をしながら徐々にチャレンジする必要はあると思う。

---

以下は、後で調べる的なメモ。

タスクボード
　計画づくりをした内容を見える化する
　タスクの状態に対応するステージを用意する
　※ツール的にはTrelloがまさにそう

タスクマネジメント
　仕事の背景や目的を理解する
　うまくいかない要素を早めに見つける
　仕事が大きいなら小さな独立タスクに分ける

ふりかえり
　仕事のやり方やその結果を棚卸し、次の計画づくりに活かすことを目的とする

朝会
　タスクボードの変化を反映するタイミング
　決まった時間場所リズムで行うのが原則
　昨日は何をやったか、それを踏まえて今日は何をするか？困っていることはあるか？

スクラム
　スプリントを繰り返し設計・開発・テスト・デリバリーを実施するフレームワーク
　※アジャイル開発の手法の一つ

デイリースクラム
　スプリントのゴール達成のための進捗、優先順位、障害の確認のミーティング（15分以内）

プロダクトバックログ
　顧客要求のひとつひとつ
　優先順位でリスト化し一元管理する
　スプリント開始前あでにプロダクトオーナーが完了させる

ゴールデンサークル
　中心からWhy, How, Whatの円
　Whyから思考を開始する（Whatから始めるほうが楽）
　なぜこのプロダクトづくりなのか？
　なぜこのプロジェクトを始めるのか？

Working Agreement
　チームで仕事をする上で合わせておきたいこと
　スローガンは避け、具体的で誰もが同じ見解で判断できるもの
　動きにくくなるほどの縛るルールにせずチームの生産性を高めるため
　チームのメンバー自分たちで決める（リーダー、マネージャが決めない）
　インセプションデッキ同様、ふりかえりで更新していく

ファイブフィンガー
　問題を抱えている人をチームでサポートする状況をつくるためのコミュニケーション促進。
　テーマは全員に共通するもの
　　プロジェクトの今後、チームの状態など
　全員で一斉に5本の指を使って表現する
　　5本.とてもうまくやれている　

　　4本.うまくやれている感触あり　

　　3本.可不可なし　

　　2本.不安すこしあり　

　　1本.全然だめで絶望的

　ネガティブな本数のメンバーの意見から聞く

狩野モデル
　差別化要素を伸ばすか、当たり前品質のモノにするかプロダクトの戦略に寄る
　品質の定義
　　魅力的品質
　　　満足を与え、不充足でも仕方なし
　　一元的品質
　　　満足を与え、不充足であれば不満
　　当たり前品質
　　　充足されて当然、不充足であれば不満

インセプションデッキ
　外側、プロジェクト関係者における期待のすり合わせ
　やるべきことの目標、目的の共通認識として持つためのドキュメント
　えらい人だけで決めるのではなくて、メンバー全員でやるのが必須
　・われわれはなぜここにいるのか
　　　エレベーターピッチ
　　　パッケージデザイン
　・やらないことリスト
　　　スコープ確認
　　　あとで決めることも時間の経過とともに変化する
　・ご近所さんを探せ
　　　ステークホルダー確認
　・夜も眠れなくなるような問題
　　　解決案を描く
　・トレードオフスライダー
　　　期間の見極め
　　　何を諦めるのか
　　　何がどれだけ必要か（人、時間、お金）

むきなおり
　進むべき先を捉えて現在を正す
　　評価軸を見定め、あるべき姿と現状の課題を洗い出す
　　インセプションデッキの「われわれはなぜここにいるのか」がブレていないこと

合宿
　集中
　　宿のチェックイン・チェックアウトの決められた時間の中で、外部からの割り込みがない
　リードタイム短縮
　　全員でまとまった時間を一気にとる
　高揚感
　　非日常な空間と時間をつくる、お互いの価値観を知る機会
　アンチパターン
　　いつもと同じ場所
　　ゴールがあいまい
　　アジェンダ（やること）の詰め込みすぎ
　　アクションプラン（やること）が未設定
　　必要な人がいない
　　まずい飯

星取表（スキルマップ）
　プロジェクトで必要なスキル、メンバーの表
　スキルの習熟度合いを5段階で描く
　　☆：エース級、○：一人前、△：ヘルプが必要、↑：習得希望、ー：できない
　インセプションデッキのAチームが項目づくりの参考になる
　項目づくり、スキル埋めはチームメンバー自身で議論しながら作成する
　チームビルディング初期に役立つ
　詳しい人に聞く、依頼するなどにも使える
　定期的に確認して、チームの成長度合いを測る
チームビルディング三種の神器
　インセプションデッキ：
　　プロジェクトの目的や方法論
　ドラッカー風エクササイズ：
　　チームメンバーの価値観
　星取表：
　　目的を達成するために必要なスキル

モブプログラミング
　みんなで一つの画面を見ながらコードを書く
　ドライバーは１人、他はナビゲータ（指示をする）
　全員が交代でドライバーをする
　時間交代（１０分程度）
　５人くらいまでが望ましい
　メリット
　　プロセスフロー改善
　　　同期、承認、手戻り、レビューが一切いらない。
　　　その場で解決。プルリクもマージもその場でやっているイメージ
　　コミュニケーションカイゼン
　　　ワイワイガヤガヤやることで思考を共有する
　　　向く先は画面と課題であり、ボスでもリーダーでも実装者でもない
　　学習効果
　　　建設的相互作用
　　達成感
　　　全員で解決していく
　否定ではなく提案をする
　プログラミング以外でも使える（その日の作業の流れの書き出しもモブでやる）
　止まって考える時間を設ける

TWI
　Training Within Industryの略、職場教育手法

バリューストリームマッピング
　プロセスの見える化とカイゼンするためのコミュニケーションツール
　リードタイムとプロセスタイムを意識し、局所最適化にならないようにする。全体最適化が大事。
　“遅い“のカイゼンのための可視化

カンバン
　自分たちの仕事の流れに着目した可視化
　開発だけでなく開発と運用が同時進行するような状況で力を発揮する
　ステージ(列)はバリューストリームマップの、マッププロセスが利用できる
　計測するのは2つ
　　1. 着手ready状態のプロダクトバックログアイテムが完了するまでの期間の記録
　　2. 定期的に、完成したプロダクトバックログアイテムの数を数える
　　スピード、どこで滞るかが把握できる

ポストモーテム
　プロジェクト終了後の事後検証
　場の設定ポイント
　　時間厳守
　　全員参加
　　目的の共有
　　ゴールの明確化
　　記念写真
　ルールのポイント
　　人事評価には関係ない
　　気軽で自由な発言
　　グランドルールを３つくらいつくる
　議論のポイント
　　具体的な内容を語る
　　事実を集めて課題を見つける
　　事実と意見/解釈を分ける
　　ポジティブな問題解決
　　次のプロジェクトの糧にする、メンバー各自のTry事項をつくる
　ファシリテーターのポイント
　　個人攻撃になりそうになったら対象を問題に対するよう促す
　　考えを代弁しない、メンバーが発言のために思い出さす時間を耐える

タイムラインふりかえり
　メンバー全員で年表をつくる
　時系列に事実（チーム単位、個人単位どっちも）を記載する
　感情やモチベーションをグラフ化
　今後どう活かすかを考える

ドラッカー風エクササイズ
　　内側、チーム関係者における期待のすり合わせ
　　人と質問のマトリクスをつくり、他のメンバーと共有する
　　　・自分は何が得意なのか
　　　・自分はどうやって貢献するつもりか
　　　・自分が大切に思う価値は何か
　　　・チームメンバーは自分にどんな効果を期待していると思うか
　　　・その期待はあっているか？他のチームメンバーが5段階で回答する
　　　　　1.完全に合っていない

　　　　　2.あまりあっていない

　　　　　3.ふつう

　　　　　4.だいたいあっている

　　　　　5.完全にあっている

モダンアジャイル
　4原則
　・人々を最高に輝かせる
　・安全を必須条件にする
　　　プロジェクト（CIでのテスト）やチーム（人を非難しないメンバー関係性）など
　・高速に実験＆学習する
　・継続的に価値を届ける

プランニングポーカー
　開発メンバーである自分たちで見積もる。上司、コンサル、上流工程のSEではない。
　相対的な見積値
　全員に1組のフィボナッチカード
　プロダクトオーナーがユーザーストーリー読み上げ
　開発チームメンバーが各自カードを選び一斉オープン
　一番高い、低い人の意見を聞き、根拠や懸念点を話し合う
　再度全員でカードを選び直す

リリースプランニング
　プロダクトバックログにリリースの目安（マイルストン）を引く
　１つのリリースは複数のスプリントで構成されるのが一般
　遠い先まで詳細にした緻密な計画ではなく、妥当なレベルの正確性を重視
　スプリント毎の検証を活用し、情報を反映させていくので、目安の線は上下する

パーキンソンの法則
　仕事の量は完成のために与えられた時間を満たすまで膨張する
　計画はたいてい上振れし、バッファは消費されていく

CCPM(Critical Chain Project Management)
　各タスクに個別バッファを持たず、プロジェクト全体としてのバッファを持って管理する
　プロジェクトバッファの求め方
　　例）五分五分の確率で達成でき見積の合計値の半分の値をプロジェクトバッファにする
　プロジェクトバッファだと各タスクの作業を期限ギリギリまで消費する現象が回避できる
　プロジェクトバッファを使っても責められない場づくりが必要

SoE(Systems of Engagement)
　顧客との絆を築く
　利用主体は顧客
　迅速なリリース、顧客体験
　フロントエンド
　スマホアプリ、Webサービス
　開放的
　サービスレベルを決めにくい
　仮説検証
SoR(Systems of Record)
　事実を記録する
　利用主体は社員
　安定性、信頼性
　バックエンド
　基幹業務システム
　社内・公開限定的
　サービスレベルの保証
　業務検証

YWT
　むきなおりフレームワーク
　　Y：やったこと
　　W：わかったこと
　　T：次にやること
　定期的に実施し、T→Yとなるようにループする

スクラムオブスクラム
　スクラムチームの代表者同士が話をする
　　・チーム内作業の情報
　　・チームで解決できない障害

コンウェイの法則
　アーキテクチャは組織に従う。組織はアーキテクチャに従う。
　組織の分割が進むとオペレーションの幅が狭まり、組織の壁ができる。コミュニケーションが減る。

デイリーカクテルパーティー
　ミーティングに構造をもたせる
　＋プロジェクト全体ミーティング：プロジェクトマネージャ, 各専門担当者
　　＋専門担当者ミーティング：各機能開発チームリーダー(テスト, バックエンド, フロントエンド, インフラなど)
　　　＋スタンドアップミーティング(朝会)：各機能開発チーム

仮説キャンバス
　目的：なぜこの事業をやるのか
　　ソリューション：提案価値の実現手段
　　優位性：自社がやるべき具体的なリソース・状況
　　評価指標
　　提案価値：顧客にもたらす価値
　　意味：顧客にとっての意味
　ビジョン：顧客にどうなってもらいたいか
　　顕在課題：顧客が気づいている課題
　　潜在課題：顧客が気づいていない課題
　　代替手段：課題解決の現状手段と不満
　　チャネル：顧客に出会うための手段
　　状況：対象顧客の状況
　　傾向：状況に基づく顧客の傾向
　収益モデル：ビジネスモデル

ユーザーストーリーマッピング
　時間の流れに沿ってユーザの行動の変遷を可視化する
　人物像を描き、場面と行動を書き出す
　各行動に対するストーリーを書き出す
　ストーリーの優先順位をつける
　各行動の最優先のストーリーをMVP（Minimum Visable Product）とし、リリースロードマップとする

MVP
　ユーザーにとって価値があり、かつ最小限の機能性を持った製品
　価値検証
　　プロトタイプ型
　　　DIYなどの図工の青果物、試験やデモ用
　　ハリボテ型
　　　プレゼンやPhotoshopのような画面イメージと画面遷移を体験する
　　　ボタンやリンクは動かず、プログラムコードは存在しない
　　動画型
　　　ストーリーベースの動画作成
　　コンシェルジュ型
　　　システム化はなく、人が中に入って検証する（有人自動販売機）
　再利用を考えず、捨てる前提。

ユーザーインタビュー
　ユーザーが何を求めているか、お金を払ってでも解決したい悩みを思い込みだけで進めないため。
　ユーザーが本当のことを話していない可能性がある。
　　無意識のうちに意味のあることを話すために事実を変えて答える
　　主語が自分でなく推測になる
　どう思う・考えたかではなく、どんな行動を取る、取ったのかを掘り下げ推測と事実を切り分ける
　準備
　　仮設を立て、その仮設が本当に存在するかユーザの考えとの合致、解決ができるかをインタビュースクリプトにまとめる
　実施
　　テクニック
　　　ペーシング、ミラーリング、ラポール空間
　　貴重な時間を割いている相手に敬意を払う
　　分析、解釈、判断は後で行う。事実や話題をメモする。
　検証
　　無加工のインタビューログの共有
　　考察や分析は解釈が偏らないようにする。
　　　声の大きい人の意見に寄る、根拠の無い見立てで判断するなど。

SL理論（Situational Leadership）
　チームやメンバーの成長に合わせてスタイルを変える
　S1~S4の段階を経てメンバーが成長していく。
　　S1　教示的リーダーシップ：具体的に指示し、事細かに監督する
　　S2　説得的リーダーシップ：こちらの考えを説明して、疑問に応える
　　S3　参加的リーダーシップ：考えを合わせて決められるよう仕向ける
　　S4　委任的リーダーシップ：仕事の遂行の責任を委ねる

ハンガーフライト
　経験の共有。
　経験や勘にもとづく知識が蓄積され、血肉となる
　社内ハンガーフライト（勉強会の実施）
　　日程と場所
　　参加者の熱量が上がるテーマ
　　コアメンバーと登壇者
　　業務時間外
　　理解ある経営陣や管理職からの応援の承諾
　　軽食、ビールなど
　　運営はボランティア

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで