【感想】チームの仕事を間に合わせる術：チーム・ジャーニー参考書籍編
チームジャーニーの本読み会第7話で著者からご紹介いただいた書籍を読んでみた。
内容はかなりシンプルで分かりやすい印象を受けた。
読み始める前の書籍に対するモチベーションは「線表」とは何か？
であったが読んでいるうちに「どう使うか」が重要であることが分かった。
線表とは何か
シンプルな進行管理表
「達成状態」とセットで使う
「線表」を使ってメンバー全員が議論することを重視する
ガントチャートほど詳細度が高くない。考え方は同じ。
しかしもっとシンプルで視認性が高い。
A4一枚に収まる
なぜ「達成状態」をつくるのか
チーム全体でプロジェクトの”到達点”を一致させるため
インセプションデッキの中でもエレベーターピッチやパッケージデザインなどプロダクトを言語化するものがあるが、それとも少し異なる。これらは抽象的だ。
気づき：「達成状態」はより具体的な状態を言語化している。
気づき：全てを達成できない場合を想定して、トレードオフ・スライダーのようなものは合ったほうが良さそうだ。
線表は「どう使うか」が肝心
「線表」はチームでつくりあげることが重要
計画をつくり共有し進めていくための道具だけではない。チームビルディングを兼ねている。リーダーは以下が求められる。
サーバント型リーダーシップ
「わたし vs あなた」から「私たち vs 課題」へ
線表を中心に会議を進めることで、出席者間の言い合いへの発展を抑制し、私たちが「その課題」をどう解決するかを一緒に考えられる。
実際にやってみた
Powerpointのサンプルが書籍に添付しているためダウンロードしています。Google Slideにインポートして使ってみた。
1月半程度の環境移行（マイグレーション）プロジェクト。スクラム開発ではない。
私がリーダーシップをとって進行することになっていたちょうどいいプロジェクトのキックオフMTがあったで早速使ってみた。
1ヶ月を前半・後半に分けて2ヶ月分を用意する。カテゴリは事務・環境構築・移行の3種類。マイルストーンを書いて「叩き台」として会議に臨んだ。
作ってみるとわかるがかなりシンプルで分かりやすい。つくるのも難しくない。プロジェクトの全体像がぱっとみで分かる。進捗が出てくると色が変わるため、進捗状況がすぐに分かるだろう。出席者からも「これ分かりやすいね」という声があった。
本当は線表の画像を載せたいが、残念。。。
「移行」のところは敢えて適当に書いた。当事者に主体性を持ってもらうために会議の中で「気になること」「確認したいこと」「これ必要だよね」ある？のような感じで聞き出して整理するスタイルをとってみた。
最初は話にくそうだったが、何周かしたら自然といろいろ出てきていい感じの「線表」と「達成状態」に仕上がった。たった1回の1時間程度の会議であったが効果はあった。出席者はみるみる話すように変わっていった。今後も「線表」使っていくため、気づきがあればまた投稿したい。
気づき：会議中に「線表」をまとめていくため、会議時間は少し長めがいい。
ふだん会話しない関係部署の人たちとの会議はうまくいくか憂鬱だったが、「線表」であればうまくいく確信に変わった。
推測の域を出ないが、話した内容を受け入れそのまま「線表」や「達成状態」に記載していくことで「参加している」感をつくりだし、自分ごとと認識するように変わっていったのでは？と思う。
書籍にも類似の説明があり、読んだときは「本当これでうまくいくのか」と思ったが概ねうまくいった。
よく会社やチームの標語のようなものに以下のようなものがある。
「課題を自分事ととらえて行動すること」
「宿題をやれ」と言われても「やる気がしない」。むしろ「やりたくなくなる」ように「自分事」として捉えて行動するには「仕組み」や「環境」が必要だであることが分かる。意思の力ではうまくいかないのだ。
人間は環境の影響を受け適用しようとする。自分事として捉えなければならない環境だからだ。
スクラムでどう活かすか
スクラム開発では線表などは作らない認識だ。それはスクラムガイド上は合っていると思うが実運用上は異なる。
「線表」は守るべき「計画づくり」としては利用しない。
あくまでもステークホルダーへの意思表示として使う。POや経営層とのコミュニケーションに役立つものという認識だ。
しかし、実際に取り入れてみると分かるが開発チーム内でもスケジュール感の透明性という観点で役に立つ。
「1、2ヶ月後に何をやるのか」は可視化しにくい。
プロダクトバックログは優先度が不安定でスクラムイベントによって変動する。数ヶ月後に何をやるかは約束できないが「こんなことを考えている」をチーム内で共有化することで開発チームとしての情報の透明性を高められる。
注意点は「計画駆動になっていけない。」「守るべき対象になってはいけない」
私はこれで失敗した経験があります。
繰り返し説明をしてチーム内で「線表」の立ち位置について共通理解をつくりだし維持することが必要です。