チームやタスクを改善してみんなで幸せになろうよ『カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』を読んだ
定期的に巡回している技術系のサイトが結構この本を推しているのを目にしており、たまたま年末にKindle版が半額だったので読んでみた。
紹介している人たちの傾向から、この本はどちらかというとアジャイルやスクラムみたいな開発文化・開発手法に近い書籍だというのは知っていて、俺はその辺の手法はからっきしだったのでそれも含め読んでみたという感じ。
内容としては、今やっている仕事に対して何か変えたいというモチベーションから、
①自分ひとりだけで、タスクの見える化をして改善活動をする。
→本当に改善されているの？
↓
②ふたりでやってみて、改善しているかチェック
↓
③プロジェクトチームでやる。
→最初はスクラムを習う立場、次に教える立場
と同じようなことをやるんだけど、少しずつ領域が広くなっていく最中でのトラブルとかがストーリ仕立てで示されている。
今までのウォータフォール型ではないということへの懐疑をどう払拭するか、非協力的な人をどう巻き込むか、イテレーションを回している際で詰まった際にどうアプローチするか、みたいな。
アジャイルマニフェストや、『アジャイルサムライ』は読んでいたけど経験がないので、このストーリー仕立ての内容が現実的なのかどうかは判断できなかった。
詳しい人教えてほしいです。
- 作者:Jonathan Rasmusson
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
ただアジャイルという考えでなくても、どのように見える化するのかとか学びは結構あったなという印象。
これは一回実践してから読むともうちょっと違うのかなーと思った。
目次
●第1部 一人から始める・第1話 会社を出ていく前にやっておくべきこと
・第2話 自分から始める
・第3話 一人で始めるふりかえり
・第4話 一人で始めるタスクの見える化
・第5話 明日を味方につける
・第6話 境目を行き来する
・第7話 二人ならもっと変えられる
・第8話 二人から越境する
●第2部 チームで強くなる
・第9話 一人からチームへ
・第10話 完成の基準をチームで合わせる
・第11話 チームの向かうべき先を見据える
・第12話 僕たちの仕事の流儀
・第13話 お互いの期待を明らかにする
・第14話 問題はありませんという問題
・第15話 チームとプロダクトオーナーの境界
・第16話 チームとリーダーの境界
・第17話 チームと新しいメンバーの境界
・第18話 チームのやり方を変える
・第19話 チームの解散
●第3部 みんなを巻き込む
・第20話 新しいリーダーと、期待マネジメント
・第21話 外からきたメンバーと、計画づくり
・第22話 外部チームと、やり方をむきなおる
・第23話 デザイナーと、共通の目標に向かう
・第24話 視座を変えて、突破するための見方を得る
・第25話 広さと深さで、プロダクトを見立てる
・第26話 チームで共に越える
・第27話 越境する開発
どのように見える化をするか
上手く仕事を行うには、以下の4つを行い状態の見える化を行う。
1.タスクマネジメント
2.タスクボード
3.朝会
4.ふりかえり
市谷 聡啓; 新井 剛. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで （株式会社翔泳社）より引用
タスクマネジメント
何か仕事をするときに、いきなり作業を開始するのではなく、その仕事の背景や目的を理解することから取り組みたい。
俺が仕事をしていてよく遭遇するケースは、資料作成をお願いした時に説明した内容とoutputが全然違うという状況だったりする。
このケース、そもそも技術力が不足しているという場合もあるんだけど、それよりも大体その仕事の背景や目的を理解していないからっていうのが多分にあって、話聞くとそうじゃないみたいな話に絶対になる。
そんなこと言ってる俺も大体こんなことばかり言われていたし、言われている。
じゃあどうするのかって、背景を想像するというか、誰に何をしなきゃいけないんだっけ？みたいな感じなんじゃないかと。
そういう時は、俺はこう思っているけど認識あっているか、とoutputイメージ大体こんな感じだけどあってる？って大体の構成だけを書いて認識をそろえて、いくとoutputがずれない。
タスクボード
タスクボードは、計画づくりをした内容を見える化するためのものだ。ボード上で、タスクの状態に対応するステージを用意し、状態を見えるようにする。
やるべきことを正しく管理しないと状態も何も見えない。
まずはタスクを小さく区切るのが必要。書籍上も作業の最小単位と記載しているので極力小さく。
敵も大きいと強大に見えるけど、小さくつぶしていけるのであればそのひとつひとつは大したことがないことが多く、認識齟齬も減る。
半年後の話するよりも明日の話をしたほうが齟齬が起きにくいということか（たとえが微妙）
タスクマネジメントで気にしないといけないポイントは
〇タスクがどれくらいあるのか
〇そのタスクのそれぞれのゴールは何か
〇タスクのゴールにたどり着くために気をつけることは何か
〇で、今の状況はどうなっているのか
この4つが挙げられるらしい。
全体量、ゴール、ゴールまでに考えなければならないこと、現在の進捗、このうちゴールまでに考えなければならないことは分からないこともあるけど、その他3点は割と出せることが多いし、これを進捗で言えないとダラダラと長い説明をすることになるのでちゃんと考えたい。
これができていないと「で？間に合ってるの間に合ってないの？」って返されて返事に窮することがあるから。
朝会
そのボードの変化を反映するタイミングが朝会だ。さらに、日々の朝会による確認で、計画とのズレを検出し、再計画するきっかけをつくることができる。朝会は毎日決まった時間、場所、リズムで行うことが原則だ。条件を揃えると、何か異変が起きたときに察知しやすいからだ。
ふりかえり
最後はふりかえりだ。仕事のやり方やその結果を棚卸して、次の計画づくりや日々の仕事に活かすことを目的とした活動である。
個人的にふりかえりが興味深かった。
というのも自分自身でもプロジェクトでも実施したことがなかった要素だったから。
なんとなく面倒くさいとか、顧みるの嫌だなーとかそういう気持ちがあったかも。
ふりかえりは、過去を省みて、今やるべきことを決める。タスクマネジメントは、未来を見渡し、やはり今やるべきことを捉え直す。
ふりかえりについて見ていくことにしよう。ふりかえりとは、これまで行ってきたことから「気づき」を得て、学び、これからどう進んでいくかを決める活動のことだ。
たいていの現場はやることがあふれていて忙しい。毎日が忙しすぎると、自分たちの手元、すぐ近くしか見えなくなってしまう。結果、客観的に自分たちのやり方を捉え直す機会が少なくなってしまう。あえて立ち止まるという考えも、必要なことなのだ。ふりかえりは、「立ち止まって考える」ための機会といえる。
俺は自身の作業でふりかえりをしたことがないし、プロジェクトでもふりかえりはやったことがなかった。
どのようにふりかえりを行うのか
KPT（ケプト）と呼ばれる「Keep、Problem、Try」のフレームワークが有名とのこと。
市谷 聡啓; 新井 剛. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで （株式会社翔泳社）より引用
まずはKeep。
この「Keep」では続けたいこと、つまりやってみて良かったことを挙げる。良かった（「Good」）から挙げてみたものの、続けていくかどうかは別の判断になることもある。
このKeepが挙がっていること自体を見るのも重要な観点だ。得てして、立ち上がったばかりのチーム、分の悪いプロジェクトだとKeepが一つもないということがある。
臆してはいけない。何もないことはない。なぜなら、ふりかえり自体は始められているのだから:)。ふりかえりすらできていなかったら、カイゼンの芽は小さくなってしまう。まずは、ふりかえりができたこと、そしてそれをKeepすることを挙げよう。次に、「Problem」では問題点を挙げるようにする。ただし、問題になる前の兆候や気づきを見逃さないようにするため「モヤモヤしていること」「気にかかっていること」も挙げるようにしよう。
なんでもいいからよかったことを書くところからスタートして、継続しようということだと思う。
以下サイトだとお気持ち表明は書くなって書いてあるけど、どうしてもお気持ち表明になりがちだからそこから、もう一歩具体的なところに落とせればOKなのかな？
つぎにProblemとTry。
Problemではできるだけ具体的なことを挙げるようにしたい。断片的な感情（例えば「しんどかった」とかね）を挙げることは、状態の可視化にはつながるのでダメではないが、そのままでは手が打ちにくい。そのメンバーには何が起きているのかを説明してもらうようにしよう。その問題によってどんな不都合や不利益が出ているのかという問いかけをしてみると、より深い洞察が得られるはずだ。
まずは、KeepとProblemを洗い出すことに専念しよう。それらを踏まえて「Try」、次に試したいことを挙げるようにする。
状況によってはたくさんのProblemが挙げられて、対応するTryの量も多くなるかもしれない。でも、それらを全部やろうとするのは待ったほうが良い。Tryを全部やろうとして、どれも中途半端になってしまっては、効果的とはいえない。取り組むTryについては、緊急度や重要度を見定めて、順番をつけるようにしよう。次のふりかえりまでの期間と、チームの練度によって、取り組めるTryの量は変わる。5つかもしれないし、3つかもしれない。たった一つでも良い、どこまでやれそうかチームで話し合って決めるようにしたい。
Problemを残してしまって良いのかだって？いったん置いてみて、本当に問題の度合いが大きいなら、やっぱりProblemとしてまた挙がってくるだろう。そのときには取り組む順番を上げるほうが良い、という判断ができる。
Problemは改善事項ということもあって、日本人的に出しやすい要素かなと思う。
そのため逆にある程度色付けしないとあれもこれもできないので、Tryで優先度付けしていく感じなのか。
どのように自身を成長させるか
重要なことでも手がつけられないと思ったら、今度は先送りせず、スケジュール表にあらかじめ時間を確保してしまいましょう。自ら実行せざるを得ない状況をつくり出してしまうのです。また、同じ領域で同じくらいの緊急・重要度のものが出てきた場合は、簡単に実施できて効果が出やすいほうを優先させます。自らの成長のためにも時間を管理するテクニックを身につけましょう。
市谷 聡啓; 新井 剛. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで （株式会社翔泳社）より引用
この歳になって②の要素がとても重要だなというのを肌で感じていて、正直①ってプロジェクトに閉じる要素（相手の会社のお作法に近い・既存のソースのコピペメインの改修作業）が多いので、あまり自分の成長に直結しない。
あんまり意味ないなーというのを強く感じていて②にスライドすべきだとは思うけど一歩が難しい。（その一歩踏み出しましょうというのがこの本で、第1～2章はその話なんだけども）
Start with why（目的から始めよ）
市谷 聡啓; 新井 剛. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで （株式会社翔泳社）より引用
この考え方はまず「なぜ」からはじめて「どのように」実現するのか「なにを」やるのかを示す。
何を、whatから始めると必ず最後に「なぜこれやるんだったけ？」と迷子になるので道筋を照らすためになぜやるのかを意識したほうが良い。
なぜが決まらないと、やるタスクの色々な折衷案を提示できなくなってしまうというのも要素のひとつか。
組織の成功循環モデル
期待マネジメント
さっき説明した「期待」も実はマネジメント対象の一つなのだ。プロジェクトの目的や目標を達成するために必要な「期待」がどうなっているかを捉え、期待をすり合わせるような手を、機を逃さず打っていく。
期待にはふたつある。
①内側の期待：チーム内での期待
②外側の期待：プロジェクト関係者における期待
①については、単純にチームが俺に何を求めているのかということになる。
②については、お客さんや自分の会社が俺に何を求めているのかということになる。
じゃあその期待をどうすり合わせるのかという観点として
①自分が何が得意なのか
②自分はどうやって貢献するつもりか
③自分が大切に思う価値は何か
④チームメンバーは自分にどんな成果を期待していると思うか
この4つを挙げて話し合うことで相互理解をする。
タックマンモデル
toyokeizai.netチームは「形成期」、「混乱期」、「統一期」、「機能期」という4段階で定義している。
①形成期（Forming）：組織としてメンバーが集められ、目標などを模索しながら関係性を築いていく
②混乱期（Storming）：組織の目標やあり方で、メンバーの考え方の枠組みや感情がぶつかり合う
③統一期（Norming）：目的や期待が合い、共通の規範や役割分担ができあがり協調が生まれる
④機能期（Performing）：チームとして成熟して一体感が生まれ、機能し、成果を出していく
CCPM（Critical Chain Project）
プロジェクトの遅延への対策として「各タスクのバッファは置かない（つまり何かあった場合は遅延）」がプロジェクト全体としてバッファを持つことで、タスク遅延をプロジェクトバッファから消費するという考え方。
市谷 聡啓; 新井 剛. カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで （株式会社翔泳社）より引用
顧客の潜在課題に気付く
顧客の目的にフォーカスして問題解決をする。ソリューション等は結局目的にあわせたものを選定するだけ。
