カイゼン・ジャーニー 第2部 読書メモ
スクラム
- 失敗を恐れず、学びを得てカイゼンする
- Fail Fast
スプリントプランニングとプロダクトバックログ
- スプリント計画
- 何をつくるべきかを決める
- どうやって価値を届けるかを検討する
- プロダクトオーナーが作成する
- プロダクトバックログアイテム
- プロダクトバックログ
- PBLリファインメント
- PBLはチーム全員が見えるようにしておく必要がある
スプリントゴール
- スプリント達成を明文化する
- "課金・決済機能開発スプリント" など
スプリントバックログ
- 開発チームがPBLをもとに作業タスクを作成する
- メンバー全員で見積を行う
- 単位は時間
- 8時間を超えるようならタスクの粒度がでかすぎるので分解を検討
Done の定義と受入条件
Doneの定義
- メンバー全員で完成の共通理解を持つためのもの
- ステージング環境で動作すること
- ユニットテストをパスしていること
- 受入条件を満たしていること などなど
- チームで共通の定義を使う
受入条件
- 顧客の要求を確かに実現していると判断できるリストのこと
- 機能要件
- 非機能要件
- PBIごとに設定される
Doneの定義と受入条件をどちらも満たすことによって初めて完了となる
インセプションデッキ
- スプリント開始前にやるのがよい
- プロジェクトの向かい先や制約をあきらかにする
- 全員で合意
- 透明性をもって運営する
ための道具
- 10の問いでwhyやhowを明確にする
- チーム全員で作る
- 簡単ではないが全員で目的の理解を深めることがチームビルディングや自己組織化につながる
- Start with why.
ゴールデンサークル
- What ではなく Why から考え始める
スクラムマスター
- 外部からひっぱってくるのも検討する
- スクラム導入支援
- スクラムイベントのファシリテーション
- 生産性を高めるための支援役
七里がお調子者である
成功の循環モデル
- 関係の質
- 思考の質
- 行動の質
- 結果の質
Working Agreement
- チームの約束事のこと
- チーム内個人同士の期待のずれを減らせるようにする
- ルールは具体的なものにすること
- 例)
- 欠席のときはデイリースクラムが始まる10時までに全員に連絡する
- ユニットテストのないコードはコミットできない
ルール作りのためのファシリテーションと運用
- 価値観がぶつかる可能性があるがそれを恐れない
- 具体的すぎるルールは抽象度を上げる
- Working Agreement は定期的にふりかえりでアップデートすること
- KPT の Keep で良い習慣となったものをWorking Agreementに加える
- Working Agreement は目に付く場所に貼り出しておくこと
期待のギャップを埋める
- パフォーマンスが高いチームは各人の得意なこと価値観、期待を共有できている
個人個人が完結して仕事をこなし、その総量がチームのアウトプットになっ ているようではまだチームとは呼べへんな。 期待が合ったチームは、お互いに動きやすくて、背中を預けられる感覚が持 てる。お互いの得意技を活かし合えるようになっているはずだ。 個々のメンバー の力を単に足し合わせた以上の、パフォーマンスを発揮できるチームになって いることだろう。
これは新鮮な知見だった。
期待マネジメント
期待はマネジメント対象である
内側の期待 : チームにおける期待
外側の期待 : プロジェクト関係者における期待
どちらの期待も重要である
ドラッカー風エクササイズ
- 自分は何が得意か?
- 自分はどうやって貢献するつもりか?
- 自分が大切に思う価値は?
メンバーは自分にどんな成果を期待していると思うか?
参加者が自分の表明を書き出し、他のメンバーと共有する
- 話をしながら相互理解を深めていく
- 心理的安全性が必要
- その期待が相互にあっているか確認する
- 期待マネジメント
問題ないという問題
だから、チームの一人ひとりが「問題は必ず何かある」 という前提に立ってデイリースクラムに臨んで欲しいんだな。 「問題がない」が問題といっても良いくらい。 だって、みんなが問題に気づけていない、捉えられていない可能性があるってことやからね。
- "障害" や "問題" が人によって異なる
- そのため、問題が表層化しないことがある
- 心理的不安
- 頑張りすぎ問題
- 精神・身体の健康は互いに影響しあっている
- チーム全体で問題を見つけるようにしないといけない
ファイブフィンガー
個人個人が本当はどう思っているかを5本の指で表明するプラクティスのこと。
- 5本: とてもうまくやれている
- 2本: うまくやれている感触有り
- 3本: 可もなく不可もなく
- 2本: 不安が少しある
- 1本: 全然ダメで絶望的
やり方
- 回答するために自分自身と向き合う時間をとる
- 回答が整ったら一斉に指を使って表明する。
- 一番少ない本数を出したメンバーから話を聞いていく
- 否定、吊し上げなどは絶対にしてはだめ
いつやるのか
- デイリースクラムで問いかける
- テーマが大きい場合は絞り込む
- 偉い人は場を和ませるべし
意見を表明しづらい日本人によくマッチしているのでは。
スプリントレビュー
- POと開発チームで行う
- 完成、未完成の確認
- デモ
- デモシナリオは開発チームで事前に組む
- 受入条件、完成の定義を満たしているかチェックする
- デモ結果をPOが受け入れるかどうか判断
- 0-100ルール
- 90%完成している、は完成していないことと同じ
- POはスプリント中止権限を持っている
チームで考える
- 価値を届けられているか
- プロダクトは複雑になっている
- クネビンフレームワーク
- 成功する方法は誰にもわからない
- フィードバックループを構築する
- 考え抜く
- それらをやるためのフレームワークがスクラム
リファインメント
プロダクトバックログをメンテナンスすること
- POだけで考えるのではなくチーム全員で考えて良い
- 開発チームのスプリントの作業量の1割くらいの時間をかけるのが適しているらしい
- 現在走っているスプリントには影響がないようにする
狩野モデル
リファインメント時に有用なPBIの分類方法
https://uxdaystokyo.com/articles/glossary/kano-model/
- 魅力的品質
- 一元的品質
- 当たり前品質
- プロダクトの戦略を練るために使う
- 魅力的品質を上げるためにそれに対応したPBIをこなすようにする。など
むきなおり
ステークホルダーのちゃぶ台返しや長期化したプロジェクトの場合、 今までどおり進めていると周囲との期待が大きくずれる可能性がある。
方向性の変化は、ふりかえりでは検知しづらい。 現状から方向性を定め直し、認識を共通にする機会をつくることをむきなおりと呼ぶ。
- ふりかえりは、過去を顧みて現在を正す
- むきなおりは、進むべき先を捉えて現在を正す
むきなおりの手順
- ミッション、ビジョンを点検
- 評価軸を洗い出し、現状を客観的に見る
- 評価軸ベースであるべき姿と現状の課題を洗い出す
- 課題解決のために必要なステップをバックログにする
- バックログの重要度と、一番効果の高いものを決める
時間軸を明らかにし、期限も明確に決める
神様が解決してくれていたら嬉しいものが一番効果の高いもので最重要なもの
合宿
チームがネガティブな状況に陥っている場合に有用
- メリット
- 集中
- リードタイム短縮
- 高揚感
合宿のアンチパターン
- いつもと同じ場所
- 目的・ゴールが曖昧
- 詰め込みアジェンダ
- アクションプランを設定しない
- 必要な人がいない
- 飯がまずい
気持ち・思考のゆとりが大事である
チームメンバーが増えるときの対処
- 星取表(スキルマップ)
- モブプログラミング
星取表
チームメンバーのスキルを見える化して俯瞰するためのもの
- 項目選びや習熟度はチームで議論しながら作成すること
- 属人的なリスクも可視化できる
- 心理的安全性がなくなるので、人事評価には使ってはいけない
- チームビルディング三種の神器
- インセプションデッキ
- ドラッカー風エクササイズ
- 星取表
- 星取表は定期的にチームで確認すること
まだ星取表がないけど、今更つくったほうが良いかだって? 必要だと気づ いたときが、君やそのチームにとっての最速なんや。遅い速いなんて気にして いないで、さっそく取り組むべきだ。
モブプログラミング
チーム全員で1つの画面を見ながらプログラミングする方法
メリット
- プロセスフロー効率性
- コミュニケーションカイゼン
- 学習効果
- 達成感
複雑な問題を解決する場合、人の稼働率に焦点を当てるのではなく、問題に焦点を当て、いかに早く問題が解決できるかに注力するのがよい。
- 責任は全員にある
問題 vs 私達 の構図をすぐに作ることができる
運営ポイント
- 最低限のグランドルールを作る
- 否定でなく提案する
- 作業の流れを書き出すのもモブでやる
- 止まって考える時間を一定間隔で設ける
- 毎日ふりかえる
TWI (Training Wighin Industry)
職場教育の手法。この中に JI (Job Instruction) というものが紹介されている。
- 習う準備をさせる
- 作業を説明する
- やらせてみる
- 教えた後を見る
人にものを教える場合に使える。
バリューストリームマッピング
プロダクトの価値が顧客の手に渡るまでの仕事の流れを見える化するためのプラクティス
- プロセスタイム
- 事実上そのプロセスを実行している時間
- リードタイム
- プロセスが次のプロセスに移行するまでの時間
これはプラクティス単体で学習し直すのが良さそう。 とりあえず知識インデックスしておく。
開発プロセスだけでなく、業務プロセスカイゼンに使える。
ECRS
業務プロセスカイゼンの方法論
- Eliminate(排除)
- Combine(結合)
- Rearrenge(交換)
- Simplify(簡素化)
バリューストリームマッピングを作成する際に役立つ
カンバン
PBIが生まれてからリリースされるまでの流れを可視化する
- リリースを終え運用と機能開発が同時進行するような状況でカンバンは有用
- 発生してから締め切りが極端に短いPBIの管理ができる
- 発生からリリースまでの期間を計測しスピードを可視化する
ポストモーテム
プロジェクトを振り返って事後検証をすること。 その検証結果から得た学びを他のプロジェクトに活用できるようにするために行う。
- 場の設定に関するポイント
- 時間厳守・タイムボックス厳守
- ゆとりのある開催時間(最低1時間)
- 全員参加
- 時間を割いてくれたことに感謝
- 集まった目的の共有
- ゴールを明確化
- 最後に全員で写真を撮る
- ルールに関するポイント
- 人事評価には関係ないことを宣言
- 気軽に発言できるように
- グランドルールを3つくらい作る
- 議論に関するポイント
- 抽象論の場合、具体的な内容を語る
- 事実を集め、解決すべき課題を見つける
- 事実 or 意見を分ける
- ポジティブな問題解決に導く
- 全員で決めたことに意義がある
- メンバー各自の Try を作る
- ファシリテーターが気をつけること
- 個人攻撃はせず問題を対象に議論するように促す
- 考えを代弁しない。メンバーが発言のために思い出す時間を耐える
タイムラインふりかえり
プロジェクト開始から終了までの出来事を時間軸上に置いていく
- ホワイトボードの上部にスプリント番号や日付をざっくり書く
- それに沿って発生した事件や問題などの事実を付箋に書いて貼っていく
- 個人にとって意味のあるものも貼り出す
- ボードの下部に感情の起伏やモチベーションの起伏をグラフとして書き出す
- それらの関係性からプロジェクトのドライブがかかった瞬間やターニングポイントが見えてくる
- 最後に、次のプロジェクトでこの経験をどう活用するか各メンバーが表明する
自らの考え整理して言語化し、明文化し、表出する ことが重要なんです。これまで見てきた様々なプラクティスと同様に、見える 化がカイゼンへの第一歩となるのですから。
感謝のアクティビティ
メンバー同士で感謝を贈り合う
これめっちゃいい
タックマンモデル
組織作りにおける発展段階のモデル
- 形成期
- 混乱期
- 統一期
- 機能期
所感
2部は読み応えがあった。
物語に出てくる開発チームはスクラムを実践していたが、 ストーリー上のチームの一員となってプラクティスが学習できるので納得感がある。 今まで知らなかったプラクティスもかなりあったので、よい知見が得られたと思う。 特に期待に関するマネジメントは目から鱗であった。
一貫していることは、チーム全員で考えること、可視化して問題を発見すること、にあると感じた。 スクラムはそれをやるためのフレームワーク＆プラクティスを提供してくれるものだと再確認できた。
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- 作者: 市谷聡啓,新井剛
- 出版社/メーカー: 翔泳社
- 発売日: 2018/02/15
- メディア: Kindle版
- この商品を含むブログを見る