Unicorn Cloud ID Manager (以下UCIDM) の開発チームのふりかえりについて紹介します。

UCIDM チームのふりかえり

UCIDM の開発は2022年11月から始まり、本稿執筆時点で1年半の間、課題管理を土台にした イテレーション開発 を採用して取り組んでいます。アジャイル開発という用語が生まれる以前からあった手法ですが、昨今の雰囲気ではアジャイル開発の一種とみなしてよいでしょう。イテレーションという2-4週間程度の期間を区切って開発を繰り返す、タイムボックス方式で開発します。スクラム開発に慣れている方向けに言えばスプリントとほぼ同じものと捉えてもらっても構いません。UCIDM 開発では2週間のイテレーション6つ (3ヶ月) を機能開発に、2つ (1ヶ月) を QA テスト期間として合計8イテレーション (4ヶ月) を1回の開発期間としています。補足として、UCIDM の開発チームはほぼフルリモートワークで開発しています。メンバー全員が顔をあわせるのは月に2日あるかないかです。本稿ではイテレーション開発の詳細については踏み込まず、それはまた別の記事で書きます。

ふりかえりなくして成長 (改善)なし

私は何度も機会がある度にチームにこの言葉を啓蒙しています。

昨今さまざまな開発をうまくまわすためのプラクティスが共有されるようになりました。うまく機能している開発チームはふりかえりを当たり前にしていると思います。しかし、私が過去に働いてきた、いくつかの会社／チームの経験則で言えば、日本の会社ではふりかえりをやらない、もしくはやっても形骸化しているところが多かったです。ふりかえりが形骸化している組織でよく起きるのは「みんながんばった」で済ませることです。実際はそんなことはなくて、一部の開発者に大きな負担を強いていたり、組織としての意思決定やプロセスに課題があったとしても、ふりかえりで議論したりはせず、なかったことにするケースがあります。とくに課題の規模が大きかったり煩雑度が高いほど思考停止してスルーされがちです。先送りとも呼びます。これは責任を取りたくないという日本人のメンタリティと相性がよいからではないかと私は考えています。

マネージャーとしてチームビルディングでやることの1つに、このチームの開発プロジェクトで起きるすべての事象に対する責任はマネージャーにあると自他ともに認識して、メンバーにはシンプルに開発に向き合ってもらい、失敗や気付きを共有できる体制づくりをしていく必要があります。これもまた別の話題になっていくので別の機会としましょう。

Fun/Give/Learn を使ったふりかえり

そのふりかえりの手法として Fun/Done/Learn をカスタマイズした Fun/Give/Learn を採用しています。いまチームで行っているのは Fun/Done/Learn の Done を Give に置き換えたものになります。その経緯については後述します。

実際に社内の wiki に書いてある運用ルールが次になります。

ふりかえりの運営

ふりかえり (定例会議) の前にあらかじめメンバーそれぞれが付箋に内容を書き出しておく。

事前作業

• イテレーションでの出来事ややったことを Fun/Give/Learn の文脈で付箋に書き出す
• 付箋を Fun/Give/Learn のどの位置が適切かを考えながら貼り付ける
  • Fun: おもしろかったこと、やっていて楽しかったこと
  • Give: 形式知 (ドキュメントやブログ、資料など) としてメンバーや他者向けに共有できたこと
  • Learn: 学びになったこと、未経験な挑戦をしたこと
• 付箋の「作成者を表示」しておく
• 他メンバーの付箋をみて関心をもったり質問があれば「コメント」を付ける

当日作業

1. ファシリテーターがチームで共有した内容、補足やまとめを「コメント」に書き込む

• 目安時間: 15分
• 長くても20分程度でおさまるようにファシリテーターが調整する
• ここでは概要を共有し、詳細については チーム勉強会 で共有する
  • フィルターしやすいように Postmortem ラベルを使ってもよい

Google Jamboard から Miro への移行

これまで1年半の間、Google Jamboard を用いて Fun/Give(Done)/Learn を実践してきました。これは4ヶ月の開発期間の間にある次開発へ向けての準備期間のイテレーションでのふりかえりです。そのため、UCIDM 開発に関する内容はあまりありません。メンバーが黄色の付箋でふりかえりを書き、ファシリテーターがメンバーからヒアリングした内容や気付き事項などをピンク色の付箋を使ってコメントします。

ここで先日 Google Jamboard のサービスが終了するというアナウンスがありました。

• Google Jamboard の提供終了について

2024-12-31 以降は Google Jamboard ファイルにアクセス不可となるそうなので過去のファイルも移行しないといけません。知人の所感で FigJam よりは Miro の方がよいというアドバイスをいただきました。私も Miro は過去に少し触ったことがあったので、まず Miro を評価して、機能の豊富さ、操作性の良さ、チームのふりかえりで必要な機能があることを確認できたので Miro へ移行することにしました。

次の Fun/Give/Learn の図を Miro のボードへアップロードします。

ふりかえりを行う日付のタイトルを付け、Fun/Give/Learn の図と一緒に「ロック」します。こうすることでスライドマスターのような、別レイヤーで固定しているかのような振る舞いになります。この上に付箋をぺたぺた貼り付けるには都合がよいです。

実際に Miro バージョンで作ってみた Fun/Give/Learn の図は次のようなイメージです。付箋の作成者を表示できたり、付箋にコメントを付けられることで Jamboard では出来なかった運用も可能になります。Miro のボードは無限にスケールするため、境界という概念もありません。例えば、簡単なデモを表示する gif アニメを端っこに貼り付けてもスペースが足りなくなることはありません。

Fun/Done/Learn から Fun/Give/Learn へ

UCIDM はインターネット上にデプロイする Web アプリケーションではありません。顧客へソフトウェアパッケージという形態で提供するプロダクトです。開発するプロダクトの違いからオリジナルの手法にある Done (Delivery) は UCIDM の開発にとって意味をなさないことに気付きました。UCIDM のチームでは fix した issue はすべて Done とみなしています。Done ではないことは issue に残っている状態になっています。そのため、チームのふりかえりで共有していることはほぼすべてが Done であり、事実上 Fun/Learn の2つをカテゴライズするふりかえりになってしまいました。そこで Done に変わる、UCIDM チームならではのカテゴリを探そうとメンバーと話し合った結果、新たなカテゴリとして採用されたものが Give です。来週にある次回のふりかえりのときに私が付箋に書く本稿がまさに Give の1つです。

Give: 形式知 (ドキュメントやブログ、資料など) としてメンバーや他者向けに共有できたこと

ドキュメントを書いたり、ブログ記事を書いたり、開発や保守のコストを下げるための取り組みをしたり、UCIDM チームではそういった他者向けの取り組みを評価しようと考えました。

過去の開発フェーズのふりかえりのふりかえり

UCIDM はソフトウェアパッケージなので4ヶ月という単位を機能開発の区切りとしています。これまでに3回の開発フェーズの区切りがありました。隔週で行う定例会議のふりかえりとは別に、これを「大きい単位でのふりかえり」と呼び、開発フェーズが完了すると必ず4ヶ月間の開発を俯瞰するふりかえりを行っています。

そのときに「ふりかえりのふりかえり」も行っています。チームで行っている現行のふりかえりは適切なのかどうか？をふりかえりするわけです。このケースでは、具体的に言うと、Fun/Give/Learn はこのまま継続してよいのか、なにか改善することはないか、他の手法に置き換える候補はあるのかといったことを話し合います。前節の Fun/Done/Learn から Fun/Give/Learn へ移行したのも、ふりかえりのふりかえりのタイミングで UCIDM 開発においてほぼすべてが Done の付箋になるために Done に付箋を貼り付けることに意味がないという意見がメンバーから出ました。

次のスライドは直近の大きい単位でのふりかえりの内容です。

3つのカテゴリのうち Give を付けるのがもっとも難しいという意見が出ました。付箋の作成者ごとの統計をとってみるとなにかみえてこないか？という意見もありました。これは Jamboard から Miro へ移行したことで実現できるようになりました。このように開発の区切りにおけるふりかえりで出た内容からさらに改善して、次の開発フェーズではよりよいふりかえりに改善していきます。いま3回の区切りを経たふりかえりになっているため、いくらか改善が施されています。

チーム勉強会の運営に悩んだふりかえりとの融合

よいプロダクトはよい開発文化から生まれる。

私が好んで周りによく言っている言葉です。マネージャーとしてやることの1つに、チームによい開発文化を作っていくことがあげられます。その一環としてチーム勉強会を運営することはよい開発文化の醸成に役立つと私は考えています。

しかし、実はこの勉強会運営が当初うまくいきませんでした。当社は小さい組織なので初期のうちはチーム勉強会ではなく、他部署にも開かれた全社勉強会を運営していました。チーム内に閉じた勉強会と他部署にも開かれた勉強会はなにが違うのでしょうか？実際に1年ほど運営してみて、それはチームのコンテキストが異なるということに気付きました。他部署の人たちにも通じる内容を勉強会で共有しようと考えた場合、なにも知らない人向けの説明を追加したり、個別ケースを抽象化して一般化して話したりといったことを自然と要求されます。そして、それは発表者の準備コストに転嫁されます。

当初、他部署にも開かれた勉強会をするためにスライド資料を作り、発表者をチーム外からも募るように呼びかけながら運営していました。しかし、ほとんどの勉強会で UCIDM チームのメンバーが輪番で発表するようになってしまいました。参加者の大半は UCIDM チームのメンバーであるにも関わらず、チーム外の人が聞いてもわかるような発表にする準備コストが高くなってしまいました。

あるときチームに閉じた勉強会に変更すると私は決めました。課題管理システムの issue は他部署にもオープンなのでそのコンテキストを把握して参加する分には他部署の人が参加してもらっても構わないが、基本的にチームメンバーのみを対象とした勉強会を開くようにしました。そして、それは毎週やっていることや開発した機能の詳細を「ふりかえる」ことも考慮して取り組むことにしました。これは準備のコストをほぼゼロにしました。資料は issue のみです。その週に対応した課題に関してその issue の担当者がふりかえりながらチームのメンバー向けに話すようにしました。

その結果、発表者が issue をふりかえっている際に他メンバーから質問が出て、作業の抜け・漏れに気付いたり、開発中の機能を他のメンバーに共有して懸念事項を相談する機会にもなりました。単純にチームのコミュニケーションや情報共有を増やす機会にもなっています。

実際に社内の wiki に書いてある運用ルールが次になります。

チーム勉強会の運営

よいプロダクトはよい開発文化から生まれる。

よい開発文化を作るための施策の1つとしてチーム勉強会がある。経験則からよい開発チームは当たり前のように毎週勉強会を継続していた。

目的

• 個人がもっているスキルや知識をメンバーに共有する
• 他人に説明するスキルを習得する

運用

• UCIDM システム全体の機能が増えてきて、メンバーそれぞれがやっていることもバラバラになりつつある
  • 普段やっていることを他メンバーへ情報共有する機会とする
  • そのときのマイルストーンでやっていることをふりかえりする機会とする
• UCIDM のシステムについて知りたいところや設計の議論などをしてもよい
  • メンバーが全員揃っていれば、どんな質問をしても誰かが知っているはず
• そのマイルストーンでやったことを基本として他メンバーへ共有する
  • 内容は基本的になんでもよい、あまり準備せずに話せる内容でよい
    • 特定の issue の内容でも、マージリクエストの解説でも、機能や振る舞いの考察など
  • 知識やノウハウを他メンバーに共用する上で wiki やブログの記事などにしてもよい
    • 書くところがなかったら OSSTech Blog に書けばよい
• 勉強会のために調査する時間が必要であれば、その調査時間も仕事の一環とする
  • 勉強会の準備も考慮して開発のスケジュールを各自で調整する
  • 業務で実装したことや調査したことを共有する機会にもなる

チーム勉強会が与えた開発プロジェクトへの影響

次の図は4ヶ月の開発期間で fix した issue 数を、直近のそれとその前のそれで比較しています。明らかに Refactoring/Bug の種別がついた issue 数が増えています。この背景の1つにチーム勉強会で実装途中の機能をメンバーにみてもらって、メンバーから早期にフィードバックを受けてリファクタリングする issue を作る機会が増えたことを表しています。ちょっとしたデザインレビューのような役割も果たすようになりました。

まとめ

ふりかえりなくして成長 (改善)なし

大事なことなので2回言いました。

本稿では UCIDM チームのふりかえりのやり方、ならびにこれまでの開発を通して、ふりかえりのふりかえりを行いながら改善してきたことについてまとめました。開発は生きものです。以前うまくいった手法やプラクティスがその後もずっとうまくとは限りません。それは世の中の変化に応じて、環境が変わったり、求められる期待値やアウトプットも変わっていくからです。UCIDM の開発の歴史はまだ浅いため、うまくいかないものを少しずつ改善してよりよくしていくような段階です。いずれ過去に成功を収めた手法を置き換える時期もくるでしょう。

ふりかえりを継続して現状の課題に対して向き合い続けることが重要です。今後もまたそういった気付きがあったときに紹介したいと思います。