こんにちは、最近プロダクトオーナーにジョブチェンジしてコードを書く機会が減ってきたyo-iidaです。
クラウドワークスでは、開発チームをプロダクトオーナーと数人のエンジニアで構成し、スクラムをベースにしつつ細かいプロセスは各チームでカスタマイズしながら開発を進めています。
今回はそのカスタマイズの事例の1つとして、困難な目標や高い目標を追うため、既存の開発スタイルにとらわれないプロセス改善にチャレンジした話をお送りします。
目次
プロセス改善で新しく試したプラクティス
今回チームで新しく試したプラクティスは、
- AAR
- SMART Goals
- Mob Programming
の3つです。
AARとは
「AAR」とは「After Action Review」の略称で簡単に言うとふりかえりのフォーマットです。やることは次の4つです。
- われわれは何をやろうとしたのか？
- 実際に行動しようとした結果、どんなことが起きたのか？
- なぜそうなったのか？
- この失敗を踏まえ、次に何をするべきか？
これをミーティングが終わった後や、その日の開発が終わった後にチームメンバーで話し合います。
ポイントはできるだけ事実を多く書き出すことと、それを解決するアクションがその課題を解決できるアクションになっているかにフォーカスして考えることです。あいまいさが入り込みにくいフォーマットなのでしっかりやるとかなり疲れますが、従来やっていたKPTに比べて少ない準備と短い時間で実施でき具体的な改善案が出やすいメリットがあると考えています。
SMART Goalsとは
「SMART Goals」とは達成できる可能性が高い目標を立てるためのフォーマットです。
SMARTはそれぞれ以下の頭文字となっています。
- Specific(明確で)
- Measurable(計測可能で)
- Attainable(達成可能で)
- Relevant(適切で)
- Time-bound (期限がある)
前述のAARと組み合わせて次のアクションを決めるときにこの観点を満たしているかチェックすることで質の高いアクションを設定することができます。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
- 作者: Esther Derby,Diana Larsen,角征典
- 出版社/メーカー: オーム社
- 発売日: 2007/09/01
- メディア: 単行本
- 購入: 10人 クリック: 1,282回
- この商品を含むブログ (117件) を見る
Mob Programmingとは
「Mob Programming（略してモブプロ）」とは、複数人で一つの開発をすすめる手法で、一人がドライバーとなりコードを書き、その他はナビゲーターとしてドライバーをサポートします。これを一定の間隔でローテーションし、開発をすすめていきます。
モブプロは、メンバー全員が一つのことに集中して開発を進めるためプルリクエストによるレビューが不要になり手戻りがなくなることや、メンバーのスキルや知見を共有しながら進められることが大きなメリットです。
そしてなによりやっていて楽しさを実感できる開発の進め方です。
現状クラウドワークスでは複数のチームで実践しており、徐々に広がってきている状況です。
ちなみに本記事の執筆もモブで進めています。
プロセス改善の歴史
次に、AAR、SMART Goals、モブプロという3つのプラクティスを実際に普段の開発で運用した時に、どんな課題があり、それをどのように解決してきたかを時系列で振り返ってみたいと思います。
モブプロ導入期
課題: チームメンバーの知識がばらばらでチーム感がない
解決: モブプロで知識のフラット化
当初、我々のチームは組織改編により2チームが合流しお互いの知識や経験がバラバラの状態から始まりました。 一方のチームはペアプロを日常的に行なっているチームで、もう一方のチームは各個人が個別に開発を進めお互いにレビューし合う進め方をしていました。
今後新しいチームでの開発をどう進めていくか検討していく中で、一番最初はペアプロを採用する話がありましたが、全員の知識や経験をフラットにできるモブプロが良さそうと判断して、試験的に採用することにしました。 世間的にもアジャイル開発手法の中にモブプロの話が浮上していたことも、後押ししました。
ある日のオフィスでのモブプロ
7/24のテレワーク・デイではコーワキングスペースを借りてモブプロをしました。
バーンダウンできない期
課題: 実装中に手戻りが発生してバーンダウンしない
解決: 実装前に技術的なリスクを細かく洗い出し、日々振り返ることで改善フィードバックを生む
クラウドワークスでは基本の開発スタイルはスクラムでスプリント単位で開発しています。 開発のメトリクスとしてはバーンダウンチャートを採用していましたが、モブプロにする前からなかなかフルバーンダウンできないという課題は抱えており、モブプロにしても特に大きな改善傾向はなく、バーンダウンの乖離が大きいスプリントが増えてしまうという課題に直面していました。
原因を考えた所、
- プランニングで技術的課題が全然見えておらず、実装時に手戻りが発生ケースが多い
- バーンダウンしていなくてもそれを開発プロセスの改善にフィードバックできていない
という原因があることがわかってきました。 モブプロでは実装に入ってからの細かい設計などはみんなで考えることができるので確かに手戻りは少ないですが、実装に入る前に見抜けていなかった技術的課題はモブプロではどうすることもできず、当初見積もりをオーバーして作業が発生することが多々ありました。
これを解決するために、
- プランニングで施策に関連するコードをフロントエンドからバックエンドまで追いながらタスクを洗い出し、1デプロイごとにバーンダウンチャートを作りデプロイ日をカレンダーに登録する
- 夕会でバーンダウンチャートを確認し、遅れている場合はバーンダウンさせるためのSMARTなアクションを夕会が終わるまでに決める
というアクションを出しました。
「1デプロイごとにバーンダウンチャートを作りデプロイ日をカレンダーに登録する」というのは一見やりすぎのように見えますが、一度コストがかかっても細部までしっかり把握しにいきどれだけ見積もり精度をあげられるのかを試すという方針をとりました。
プランニングボリュームアップ期
課題: 技術的なリスクの見積もりに時間がかかる
解決: 空のテストやインターフェースを先に定義しタスクを網羅的にコメントで残す
もともとプランニングではストーリーごとにプランニングポーカーでポイント見積もりをしていました。
前述のアクションを反映した結果、ポイント見積もりをやめて、プランニングでコードを追いながらタスクの洗い出し、デプロイ日を設定するようにしました。
タスクをコメントで実際のコードに残していき、必要な箇所にはクラスやインターフェースを書いていく方針にしていました。
しかし、精度を上げようとするあまり、プランニングに掛ける時間が増大し、ひどいときは、「ここまで書いたらもう実装もかけるでしょ」という勢いでプランニングが終わったら実装がほぼ終わっているということもありました…。
これでは何をやっているのかわからない、、ということで、落とし所として、チーム独自のTODOコメントを用意し、プランニング時にブランチを切ったのち、実装が必要な箇所にTODOコメントを残し、それをコミットするまでをプランニングとしました。この作業もモブプロで行い、全員の認識を一致させます。このときにホワイトボードにも全体像を書いていき、リリースまで残しておくようにしました。
その結果、実装に入ってからはそのTODOをすべて潰せばリリースできるという状態を作ることができました。
夕会地獄期
課題: 日々のふりかえりが機能していない
解決: AARとSMART Goalsでその日のうちに具体的で明確なアクションを起こす
これまで夕会はバーンダウンチャートと残タスクを確認し、共有事項や翌日の予定の確認を行う内容となっていました。
バーンダウンチャートを確認といいつつ、見るだけで終わっていたので遅れている場合のアクションが何も出ない状態でした。
これを前述のアクションを反映するために、AARというふりかえりフォーマットで1日をふりかえることにしました。ふりかえりといえばスプリントの終わりにKPTなどでふりかえることが多いと思いますが、1日単位で記憶がフレッシュなうちに具体的なアクションが出るやり方に変えました。
その結果、1日の開発内容や課題点をすべてふりかえったためそれまで5分で終わっていた夕会が1時間かかるようになりました。
これもやりすぎ感がありますしタイムボックスを守っていないのですが、対応があいまいになっている課題を完全に消化しにいくという方針で試してみた形です。
初期段階は課題が非常に多かったので時間もかなりかかることがありましたが、回数をこなすにつれてあいまいになっていた大きな課題は徐々に解消され、コンパクトに終わるようになりました。
AARで出た改善アクションで事前に検討しておいたほうがよいものはプランニングチートシートに反映するなど、継続的な改善が機能するようになりました。
AAR祭り期
課題: なんでもAARで時間がとられる
解決: 改善点はチートシートに落とし込み
AARのふりかえりフォーマットに慣れてくると、今度はチームのミーティングが終わった後にはなんでもかんでもAARをやる癖がついてしまい、
「我々は何をやろうとしたのか？」
「どうしてそうなったのか？」
ということを常にチームメンバーが意識するようになりました。
しかし、AARはそれなりに時間がとられるので主要なミーティングではすべてチートシートを用意することで同じAARを繰り返さないようにしました。
プランニングでは技術的な観点でタスクを洗い出しますが、実装に入ってから施策のKPIの測定方法が明確に定まっていないことが発覚するといった問題が起きたこともあり、プランニングの前にプレ・プランニングを行い施策のあいまいなところを洗い出すチートシートなどもできました。
こういった取り組みの結果ミーティングの質が大幅に向上しました。
ミーティングダイエット期
課題: ミーティングにかける時間が長い
解決: 改善が定着したミーティングは時間の削減
ミーティングの質は改善してきましたがまだ掛けている時間が長いということで、改善サイクルが定着したミーティングを減らす検討を行いました。
プランニングやグルーミングはチートシートの充実によりフィードバック自体が少なくなったので、それらのミーティングごとにAARを行うことはなくなりました。
また、夕会後のAARでは、一度にその日の開発内容をたくさんふりかえるのが大変だったため、開発の区切りがついたタイミングで都度ふりかえるようにしました。
そうすると記憶が新鮮な状態で改善アクションがだせるのでAARの質も上がり、開発の進め方がさらに改善されました。
開発チームとプロダクトオーナーのコミュニケーション改善期
課題: ミーティングごとのコンテキストスイッチつらい
解決: チームは一つのことに集中し別の話題のミーティングをいれない
開発チームとしてはミーティングに掛ける時間は減り、開発に集中できるようになりましたが、ここで新たな問題に気が付きました。
開発中にプロダクトオーナーから次の施策のミーティングを挟み込むと、集中している分コンテキストスイッチの負担が大きいことがわかってきました。
この問題に対しては、思い切って開発チームには今やっている開発に集中してもらい、終盤になるまで次の施策について開発チームとの検討を進めることはしないようにしました。
いいかんじに施策リリースできるようになった期
ここまでの改善を経て、一度にやる開発は1施策という単位に変えたため、スプリントやバーンダウンチャートという概念もなくすことにしました。
もともとスクラムの見積もりというのは、プロダクトバックログのユーザーストーリーに対して相対的なポイントを見積もることでそのスプリントで実施する対象を決める というやり方です。しかし、我々の場合プロダクトバックログにいくつもストーリーが積んであるわけではなく、都度都度実施する施策をユーザーの反応をみて練りながら進めるスタイルだったので、 その施策がいつリリースできてどれくらいの数字の伸びを見込んでいるかの精度を高める ことが重要でした。
そのため、プロダクトオーナーとして施策がいかに詰められているかを追求することと、開発チームとしていかに技術的リスクを排除して手戻りを少なくすることに注力した結果、「教科書通りの進め方から外れてみる」という選択をしました。
安易に自分たちのやり方で進めるのにはリスクがありますが、ふりかえりが機能していたので失敗で終わってしまうことはありませんでした。
結果的に、以前のような技術的課題の見落としによる手戻りに悩まされることがなくなり、自分たちの改善によって施策が予定通りリリースできるようになり、施策としても効果が見え始めたのでチーム全体としてパフォーマンスが上がっている手応えを感じることができました。
まとめ
長々とプロセス改善でやってきたことを振り返ってみましたが、何が一番重要だったのか一言でいえば、
「ふりかえりを機能させること」
に尽きると思います。
初歩的なことに聞こえますが、質の高いふりかえりを実現するのは気力と胆力を伴う作業であり、継続してしっかりふりかえっていくことは非常に難しいことだと改めて思います。
今回モブプロという新しい手法を試しましたが、これを上手く定着させることができたのは短いサイクルでのふりかえりをきちんと実施できたことが大きいです。 ふりかえりの重要性はモブプロに限らず通常のスクラム開発でも同じなので、個人的にはこれまでやっていた開発もわりといい加減だったんだなぁという反省がありました。
ということでモブプロを導入する過程と、その中で気づいたふりかえりの重要性について気付かされたというお話でした。
改善プラクティス集
最後にモブプロやAAR等を効率よく実施するために役に立ったプラクティスを紹介します。
全体の流れ
プレ・プランニング
施策内容をチームに共有し以下の点をチェックします。
- [ ] その施策、目的と手段合ってる？ - [ ] 受け入れ基準を明確にする（絶対実装するライン、プランニング結果や実装途中でやらない判断ができるライン） - [ ] KPIの計測方法が明確になっている - [ ] 技術検証が必要か？（パフォーマンス懸念、新技術利用、構造的なリファクタリングなど） - [ ] UIデザインをレビューは必要か？ - [ ] ユビキタス言語を決める（日本語） - [ ] そのストーリー、見積り可能になってる？ - [ ] プランニング前までにやっておくことのSMARTなアクションを決める（必要か？で必要なとき） - [ ] 検証で明らかにするべきことをリスト化し各検証にかける時間を決めてカレンダー登録する
プランニング
モブプロで以下の点をチェックします。（カードと呼んでいるものはTrelloのカードです）
- [ ] カードのタイトルに関連する施策がわかるユビキタス言語を含める (2分) - [ ] 少なくとも「モデル / UI / ユーザー導線」の3フェーズにリリースをわけている (それぞれdevelopブランチから派生可能であること) (15分) - [ ] 大まかな流れ、関連するモデルをホワイトボードに書いて全体像を見えるようにする(15分) - [ ] Pull Requestを作ってカードにアタッチする (1分) - [ ] プランニング時に確認した項目があればQiita:Teamに記録する - [ ] 実装すべきインターフェース(クラス・メソッド)のYARDと実装の補助となるチーム名_TODOコメントを記載する (コードの追加・削除をしない) / 併せて RSpecの1行contextと空のitを書いておく 。テストがない場合、空ファイルを必ず作る。 (1時間15分) - [ ] Elasticsearchのフィールド追加を伴う場合はそのフィールドへの同期がいつ行われるかを確認する - [ ] チーム名_TODO をもとに全体の流れがあってるか図を使って確認(10分) - [ ] 施策をやる前にリファクタが必要か(リファクタは別ぷるりにする) - [ ] チーム名_TODOのコミットをまとめる - [ ] チーム名_TODOをTrelloへタスク化する git grep --line-number チーム名_TODO | pbcopy (15分)
HackMD
リアルタイム共同編集できるMarkdownノート
モブプロでその日の開発内容をナビゲーターが記録していくという使い方をしています。朝会アジェンダなどもここに記載していて、1日が終わるとQiita:Teamのほうに転記してチーム開発日報として残しています。
AARの記録。楽しく開発するには遊び心も大事。
キッチンタイマー
モブプロ関連の記事ではMobsterがオススメされていることが多いですが、我々は物理的なキッチンタイマーを使っています。 Mobsterは一つのマシンを使い回す前提のツールになっていますが、我々の場合はマシンは各自のマシンを使い、ディスプレイだけつなぎ変えるやり方にしているためキッチンタイマーが使いやすいです。
git-now
モブプロやペアプロでは交代の際にcommit & pushが必要になるため、開発がある程度まとまるまではgit-nowを使って即座に交代ができるようにしています。
ひと段落したところでgit nowで積んだコミットをrebase等でまとめる方針としています。
参考: Git nowではじめるCommit駆動開発 - Qiita
割り込みタスクで離脱
開発をしているとアラートが飛んだり、サポートから問い合わせがあったりどうしても開発を中断して対応しないといけない割り込みタスクが発生します。
このような場合でも開発をストップさせないために、依頼がきた場合はその場でランダムでモブプロから抜けて対応する人を決め、最低限ペアプロで開発を進められる状態を保つということをしていました。
※割り込みタスク自体もモブプロでやるという選択肢もありますが、事業観点では開発を止めないことを優先しています。
ホワイトボード
ディスプレイの後ろにホワイトボードを用意して開発中は開発しているものの全体像を可視化するようにしています。
これをやることで実装で迷わなくなり、議論の効率化もできます。
太陽フレアが話題になったときに生まれた謎キャラクター。楽しく開発するには（ry
最後に
クラウドソーシングのクラウドワークス では、モブプロなど新しいプロセス改善に積極的にチャレンジできるエンジニアを募集しています。
