プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる！」って感じで読んでてワクワクした。良かった。
ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。
立ち止まる時間
やることが多すぎてチームが疲れている。
その状況において
少しでもタスクを早く終わらせてチームに余裕を作りたい！と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。
そこで
5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り返る。
その結果
それまでは、終わりのないずっと続く作業に思えていたものが、この振り返りの単位で「終わり」が認識できるようになる。それによって、メンバーは自分たちが期間内に終わらせたタスクを確認することができ、チームとして一歩ずつ前進していることを実感できるため、達成感と自信を得ることができる。また、期間内でのアウトプットが見えるようになるため、効率良く作業を進めることを受け入れることができるようになる。
称え合い
メンバーにスキルアップして欲しいと思っている。
その状況において
リーダーは、メンバーの足りていない部分を見つけると、その場で伝えてあげないとまた繰り返すと考え、指摘する。その一方で、良いと感じた部分に関しては伝えるタイミングがなく、またそれを伝えないことによるプロジェクトへの実害もないため、伝えずに済ましてしまう。そして、リーダーから指摘を受けてばかりいるメンバーは自信ややる気をなくしてしまう。
そこで
《立ち止まる時間》にチームのメンバー同士で良かった点を伝え合うようにする。そこで、特にリーダーはメンバーの良かった部分について伝えるようにする。また、指摘に関しても、開発中にどうしても伝えなければならないこと以外は《立ち止まる時間》に共有する。その際には個人に対する指摘ではなくチームの課題として取り上げ、チームの仕組みとして改善していくようにする。
その結果
メンバーは、自分の良い部分を認識し自信を持つことができる。そして、相手がどのように思ってくれているかを知ることができるため、お互いを助け合いやすくなる。それぞれが自分の強みを活かしてお互いにサポートし合うことで、チームとして弱みを補って成長していくことができるようになる。
誰の幸せ
メンバーに自主的に仕事を進めて欲しいと思っている。
その状況において
メンバーはアサインされたタスクを指示通りにこなすだけで、自分から意見を出してくれない。だから、リーダーは自分が指示を出さざるを得ないと感じている。
そこで
アサインするタスクだけではなく、プロジェクトで何を作るかだけでもなく、それを開発することによって誰に対してどのような幸せを届けたいのか、を伝える。
その結果
一連のタスクがどのようにビジネスや社会に貢献できるのかを知ることができる。そのため、次に何をするべきか、少しでもその幸せを大きくするにはどうすれば良いか、を考えることができるようになり自主的に動けるようになる。
昨日の天気
タスクを無理なく期間内に終わらせて欲しい。
その状況において
メンバーは《誰の幸せ》かを考えているため、できるだけ早く進めたいと考えている。そのため、実現可能なスケジュールではなく「こうありたい」というスケジュールを立ててしまい、予定した期間内で終わらずに無理をしてしまっている。
そこで
実際にその前の期間で終わらせることができたタスクを数える。期間の開始時に100時間で見積もっていたものが、期間の終了時に40時間分残っていたら、チームには見積もりの時点で60時間分のタスクを終わらせることができる力があるということになる。実績を元にしているので、そこには、差し込みタスクや病欠、プロジェクト外の仕事に取られる時間なども含まれていることになる。
その結果
チームは、自分たちの感覚や希望・逆引きではなく、実績を元にスケジュールを立てることができるようになる。それによって、差し込みタスクや、レビュー後の差し戻しなども含めて、無理のないスケジュールで開発を進めることができるようになる。
ケーキの切りわけ
できるだけ管理することなく、進捗状況をより正確に把握したい。
その状況において
毎回、開発の中盤までは進捗状況が悪くなく見えているが、終盤になってレビューによる差し戻しが発生したり、仕様の認識違いが発覚したりしてしまい、予定通りに進まないことが多い。
そこで
開発の各工程（設計・実装・テスト）で切り分けるのではなく、スコープを小さく切り分ける。それによって、短い期間でリリースまで持っていけるようにする。
その結果
工程がxx％終わっている、という内容ではなく、動くものがxx個中yy個開発完了している、という内容の進捗把握をすることができる。完了しているものはエンジニアの感覚ではなく実際に動くものなので曖昧さがなく手戻りもない（手戻りを含めて、既に終わっている）。開発が全て完了しない場合も、そこまでの部分でリリースをすることができるのでリリースできないというリスクを軽減することにもなる。
生き残る方法
プランニングを行っている。
その状況において
《昨日の天気》で現実的なスケジュールを出したが、それではリリースに間に合わないことが分かった。
そこで
「一致団結してがんばりましょう！」というような精神論でその場を乗り切るのではなく、現実を見て計画を立てる。そのために、プロダクトオーナーに状況を説明し、調整可能なスコープがないかを一緒に考える。《ケーキの切りわけ》で、なんとか生き残れる方法がないかを話し合う。
その結果
ビジネス視点、開発視点の両方の視点からの議論をすることができ、段階リリースなどでなんとか安全に生き残ることができるパスを探すことができる。チームは、そのおかげで現実的なスケジュールでクオリティを落とすことなく、予想外の事態にも対応できる体力を持ったまま開発を進めることができる。
そんな感じ
で、上から順番にやっていくと「指示を受けて動くチーム」から「ビジネス視点を持って自走できるチーム」になっていく感じあるかなー。知らんけど！
