はじめに
この記事では 「現在あなたが担当している開発案件」における「開発チームのパフォーマンスを最大化させること」 を考えます。
この手段のひとつとして「ふりかえり」の活用があります。
この記事では筆者の経験を基にふりかえりの導入例を紹介します。
ふりかえりを通して要件や仕様、コミュニケーションなど開発に関する潜在した課題を検出し、チームのパフォーマンスを向上させることが期待できます。これから開発に取り入れていきたい方への参考になれば幸いです。
前提
- この記事では、プロジェクト毎にチームの立ち上げ～解散が発生する組織運営を例にしています
- この記事では、パフォーマンスを「設計書やコードの作成効率」や「開発課題の解消効率」など、プロジェクトを進捗させる各種活動の効率性を指しています
１．ふりかえりの頻度
１．１．チームが出せるパフォーマンスには上限値がある
スクラムで開発の状況を観る指標の一つにベロシティがあります。このベロシティの定説として「安定させること」が挙げられます。あるチームのベロシティは青天井に伸びていくものではなく、どこかで上限があり、そこで安定させることで見通しが得られる。というものです。
この記事でも、チームが出せるパフォーマンスには上限があるという立場を取っています。そう考えると、関心は
- いかに素早く上限値までパフォーマンスを引き出せるか
- いかに長くパフォーマンスの上限値を維持できるか
という2点に分解できます。
１．２．チームのパフォーマンスは100m走のイメージ
- トップスピードに乗ったら、それ以上は速くならない。
- 多くの選手はトップスピードから更に速くなろうとする。それでは速度にテクニックが追い付かず逆に遅くなってしまう。
- 大事な事はトップスピードに乗ったらフォームを保ち、スピードを維持することだ。
- スタートから３０～４０メートルまではフォームを意識しているけれど、そのあとは自然に大きなストライドになる。
- でもストライドは技術というより自分の体格がそれを可能にしている。意識して大きくすることはなくて、自然にそうなるんだ。
１．３．チームのパフォーマンスとふりかえりの頻度
筆者の経験則ですが、ふりかえりは立ち上げ期に最も効果が高く、チームの成熟と共に効果が限定的になってきます。
①チームの立ち上げ期は毎週ふりかえり会を実施しましょう。各自のタスク進行や相互のコミュニケーションに潜在する課題を早期に検出し解消することでパフォーマンスを素早く押し上げていきます。
②しばらくしてチームメンバの稼働やメンバ間のコミュニケーションが安定する瞬間が訪れます。この状態からは、現在のパフォーマンスが維持出来る様に阻害要因や将来のリスクの検出、良いプラクティスの共有を中心にふりかえりましょう。毎週出るものではない状況であれば、頻度を2週間に1回へ下げることを考えます。
③プロジェクトの収束期はピーク時に比べて課題の検出は少ない筈で、クロージングタスクの確認や情報交換にシフトしていくと良いでしょう。頻度は2週間に1回を基本に、最終盤は1カ月に1回へ下げることを考えます。
図：筆者がよく実践するイメージ
２．ふりかえりの方法
ふりかえりの方法は色々と存在すると思いますが、個人的に意識していることを挙げると以下になります。ご自身の経験と照らしてギャップのある事項があれば参考にしてみてください。
２．１．筆者が意識していること
- 可能な限り多くの人に参加してもらう
- 週次の進捗会の最後の20分など、追加感の無い場所にふりかえり会を入れる
- プロジェクトに全く関係ない雑談コーナーを設ける
- 「前向きな意見」と「耳の痛い意見」の両方を拾得する
- 全ての課題を解決しようとせず、最も重大な1つをチームで選んでタスク化する
- 選ばれなかった課題はストックコーナーに置いて次週以降も拾える様にする
- 古くなった課題は思い切って捨てる
- KPT一辺倒ではなく色々なふりかえり方法をやって顕在化を刺激する
２．２．参考
森一樹さんのふりかえりカタログでは様々なふりかえり方法を目的と共に紹介されています。こちらから任意に選んでやってみる方法もおすすめです。
おわりに
チームのパフォーマンスを向上・維持させる方法論としてふりかえりに着目してみました。
特にチームの立ち上げ期は要件や仕様の検討・メンバ間のコミュニケーションなど課題が多々潜在していることが常であり、この早期検出と解消が重要だと毎回感じます。
ふりかえりの習慣が無い組織で企画するハードルを感じる方もいらっしゃると思います。週次の進捗会など、定例的な会議の最後に差し込むと企画しやすいです。
チームの持てる最速を目指しましょう！
