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