はじめに
こんにちは、食べログWEBエンジニアの@k-sekidoです。
本記事では振り返りによってチーム作りを実践する中で感じたことや学びを得られたことをまとめてみました。
システム開発にあたって、いいチームを作りたい、チームの状態をもっとよくしたい、ひいては、より早くユーザーに価値を感じてもらえる成果を出したいという課題について、アジャイルやスクラム、振り返り、KPT、YWTなどいろいろな考え方や手法が語られてきました。
それら考え方や手法について理解を深めたからといって、実際に課題が解決できるとは限りません。振り返りの手法をいろいろ工夫して振り返りをしてみたものの、 実際のところ思った結果にならなかったり、心の底からよいと思える行動するための知見を得られてなかった という経験は多くの人にあるのではないかと思います。
より当初の課題を意識して、実際的な行動を重視して考えたときに、 まずは地道に振り返りを積み重ねてみる ことをしてみるのがよいと考えました。
その結果として、少しだけよいチームの状態に近づけた気がするので、考え方や手法というよりも具体的に何を考えて、どういう行動をしたかをまとめたいと思います。
いいチームとは
振り返り自体についてよりもまずは先に課題についてもう少し具体的に考えてみます。
いいチームを作りたいとなったときに、いいチームとは何かは人によっていろいろな考え方があり、自分なりのイメージをつけておく必要がありそうなので、下記の通り定義してみました。
ユーザーに価値を感じてもらえる成果を上げるために、実際に手を動かしている人々の間で、
よりよくする改善をしていく方向性について 共通認識 があり、 次につながる行動 ができている状態
ポイントは下記になります。
- まわりのステークホルダーよりも、まずは実際に手を動かしている人々の内々の状態をよくする
- 継続的によいチームでありたいため、改善と行動の要素は必須になる
上記のようないいチームのイメージを前提として、その実現を考えていきます。
より具体的な課題
いいチームを目指すにあたって、具体的にどういうところが課題になってくるのでしょうか。
実際に手を動かしている人々とは、具体的にはユーザーに価値を感じてもらうための成果につながるプロジェクトに関わる企画やデザイナー、エンジニアといったイメージになります。
また具体的な課題としては下記が出てきます。
- 異なる職種ないし立場の人々が集まったときの コミュニケーション課題
- スケジュールの遅延や工数の膨らみなど プロジェクト進行上の課題
- 手を動かしたことが成果につながっている実感を得られるかという モチベーション課題
それら課題を踏まえつつ、下記の課題についての解消を重視しました。
(1) ミスコミュニケーションをなくす（あの人はこう思ってると思ってたなど）
(2) 独断をなくす（個人の作業遅延をチームへ共有せずに自分だけの課題のままにするなど）
(3) なんとなくをなくす（このプロジェクトを進めれば、なんとなく成果につながるはずなど）
実際のところ、(1), (2)までは解消できたと思っていますが、(3)についてはこれからのチャレンジになります。
課題解消の目論見
具体的な課題の解消を目指して、振り返りを実施していきました。
振り返りにした理由は下記が挙げられます。
- トップダウンで指導する形よりも、 当事者の気づき ベースの方がより実現可能性が高いと考えた
- 職種の異なるメンバーが思ってることを話せる機会は振り返りくらいしかなさそう
- プロジェクトを進める中でのコミュニケーションは業務的な話が優先になりがち
振り返りをしようという話自体は、世間的にもふつうのことという感覚はあり、すんなりと機会を設けることができました。また、振り返りを通して、どのようにいいチームを作っていくかについて、下記の目論見がありました。
＜振り返りでコミュニケーションの機会を作る＞
プロジェクトに関わる企画、デザイナー、エンジニアのコミュニケーションを活発にして、
ミスコミュニケーションをなくす
↓
＜振り返りを次の行動につなげる＞
プロジェクトの課題について、個々のメンバーで判断せずにプロジェクトに関わるメンバーで判断する
まずは振り返りの場でプロジェクトに関わるメンバーみんなの判断で課題解決の行動を決める
振り返り以外でも継続的に課題についてプロジェクトに関わる メンバーみんなで判断し、行動していく
↓
＜成果につなげる＞
プロジェクトの成果について、事業や数値へのコミットに対する成功と失敗の基準を明確にして、
まずは 成功のために必要十分なこと を進める
実際にやってみての結果を受けて、成功や失敗の要因を分析し、成果を出すための行動につなげる
何のために振り返るか
目論見については、メンバーには説明はしたものの、実際にすぐ理解して行動できるわけではないので、まずは振り返りを実施してみました。
当初の振り返り
さあ振り返りをしてみてくださいといわれたところで、目論見通りになるはずもなく、下記の状態になりました。
- 個人の振り返り に近い内容が多く出てきた
- 自分のスケジュール通りに進められた、テストで考慮漏れがあったなど
- 次のプロジェクトでは振り返りで決めた行動が考慮されずに進む
- 振り返りをして形式上、次の行動を決めたはずだが 実践できない
もちろん、はじめから目論見通りに行くとは思っておらず、まずは内容というよりも振り返りによってコミュニケーションをとること自体ができればよいと考えていました。
振り返りの振り返り
なぜ次の行動につながらないのか、下記の通り考えました。
- 振り返りで決めた次の行動が心の底からよいと思えない
- 行動してみようという気持ちになれない
対応については下記の通り考えました。
- 振り返り内容の 深掘り が足りていないのではないか
- 当事者たちの 核心をついた内容 になっていないのではないか
- ただ深掘りをして詰めてるだけの状態にはならないようにしたい
やみくもに深掘りをするのではなく、ある程度の着地点は見越して深掘りしていくのがよいと考えました。その着地点こそ「(2) 独断をなくす」という課題を意識したもので、何のために振り返るかの共通認識の構築を目指しました。
どのように深掘りをするか
振り返りでは多くのテーマが挙げられるため、どのテーマについて深掘りをしていけばよいか迷うことになりますが、下記の考え方で深掘りをしました。
- よりメンバーが興味のあるテーマがよい
- どんなテーマでも深掘りをすること自体が重要で、 根本的には同じ ところに行き着くだろう
- 上記以外の観点では特にテーマは選ばなくてもよさそう
よかった点/継続したい点
よかった点や継続したい点はどのように深掘りをしていけばいいか難しいところがあると思います。下記の観点で考えてみました。
- 次のプロジェクトで同じことが 再現 できるとも限らない
- 状況が異なれば継続できるとも限らない
- 再現性の観点で、成功要因について取り巻く状況や当事者が考えたことについて深掘りする
例）「Aさんの活躍でBがスムーズに進んだ」
「Aさんのどのような活躍があったか？」
「Aさんはどのような考えでBを進めたか？」
「AさんがいなくてもBはスムーズに進むか？」
問題点/改善したい点
問題点や改善したい点は一見すると深掘りは簡単そうに思えますが、下記の観点を重視しました。
- どのような 文脈 でそのテーマを問題として捉えるか
- 個人レベルの問題ではなく、チームレベルの問題として捉えるとテーマに対する見方が変わる
- 捉え方を変えることによって、テーマを深掘りしていく
例）「AさんとBさんの間でCについての認識相違があった」
「どのような場で認識相違に気づけたか？」
「Cの中でも具体的に何について認識相違があったか？」
「AさんとBさんの認識にはそれぞれどのような前提があったか？」
深掘りの方向性
いずれにしても深掘りの方向性としては、時間軸としてはその当時だけでなく、次のプロジェクトも含めて考えたり、個人だけでなくチームとして捉えたり、視野を広げていくことにしています。そうすることで、プロジェクト全体としての共通認識を持つことにつなげられると考えました。
次の行動につなげる
何度か振り返りを行い、その都度振り返りをしていく中で、下記の変化が起きてきました。
振り返りの内容としては、 個人レベル のテーマが多く、
次の行動としても個人としてどうするという話になり、結局それが実現されることはまれな状態
↓
深掘りを行うことで、チームの 共通認識 ができて、振り返りの内容もチーム全体を見据えたものとなる
みんなで次の行動をする ことになり、みんなの納得感を得るためにより具体的な行動のイメージができる
↓
次のプロジェクトで行動をしてみて、その振り返りでみんなで行動したことについて 深掘り ができる
振り返りの回数を重ねるごとに観点は必然的に揃ってくる
何より振り返りで挙がるテーマのどれもが 自分ごとのように感じてくる
同じメンバーが次のプロジェクトでも一緒になることが多くなり、みんなで行動していける状況もあり、
メンバーたちだけで次々と行動していけるサイクルに乗ることができました。
次のチャレンジ
今までの振り返りでは、プロジェクトの進め方が主なテーマでした。ただ、プロジェクトの目的は成果を上げることなので、成果に対する振り返りにもチャレンジしたいと考えています。
下記の観点で考えていきたいです
- なんとなく取り組んでいるだけでは ムダ が多くていつまでも成果にたどりつけない
- プロジェクトの成果に対する成功と失敗の基準を事前に決めて、その基準に対して 必要十分 なことをする
- 成果に対するプロジェクトの取り組みを振り返る観点も、成功と失敗の 基準に照らし合わせて明確にする
他の考え方との比較
成功か失敗かを検証するという点で、仮説検証型の進め方が思い浮かびます。仮説検証型で進めていても、仮説のボリュームが大きくて工数が膨らむことはあり得えます。また、ムダをなくすという点でリーンの考え方に近いところはあるかもしれません。下記の観点をより重視したい考えです。
- 仮説を検証する進め方にしても仮説を検証するために必要十分なことを考えたい
- 何がムダである/ないの客観的な基準はなく、そこを曖昧にせずに自分たちなりの基準を明確にする
- 結果として、ムダがなくなり、仮説検証をするために必要十分なことが明確になる
まとめ
次のチャレンジについてはまだ実践はできていないので、今のところの考えにとどまってしまいます。
@sudomeg さんの「作る人にも使う人にも嬉しいMVPをやってみた 〜実用最小限の見つけ方〜」にも近い考え方が書かれていたので、実践の参考にできそうです。
より早くユーザーに価値を感じてもらえる成果を出せるチーム作りを目指してがんばっていきます。
明日は、@e-ronny さんの「情報処理安全確保支援士試験の問題を解いて、セキュリティインシデントの事例を他山の石として学ぼう」です。お楽しみに！！