KPTで粘り強く品質改善に取り組んだ話 - クックパッド開発者ブログ

KPTで粘り強く品質改善に取り組んだ話

f:id:y_310:20141030163053j:plain

はじめに

こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。

実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。

そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。

そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。

課題

取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると、

  • リリース毎にリリース日を調整していたため、多部署が関わるようになった結果調整コストが増大した
  • テスト期間が明示的に取られていなかったため、開発者の意識による品質のばらつきが大きく単純な問題が見逃されがちだった
  • リリース作業の担当者が決まっていなかったためリリース直前の作業漏れが頻発していた
  • リリース直前の駆け込みコミットによりテストされていない変更がリリースされていた

他にも大小様々な問題が山積している状態で、それが結果としてアプリの品質を落とすことにもつながってしまっていました。

この状況を打開するために最初に実践したことがKPTによる振り返りです。

KPT

KPTとはKeep、Problem、Tryの略で振り返りのためのフォーマットの一つです。リリース後の振り返りで、続けたいこと、問題と感じたこと、次の開発期間で改善に取り組むことを上げることで課題の整理と継続的な改善を実践するために採用しました。 採用当初は単に問題を整理するツール程度の感覚がありましたが、半年たった今ではこの枠組みを維持することが一番本質的なことだったと感じています。

モバイルファースト室ではAndroid、iOS各チームでリリースごとに約2週間に1回程度の頻度でKPTを用いた振り返りを実施しています。

最初のステップはルール作り

1回目の振り返りはProblemが大量にありKeepは見つからないという傾向になりがちなので、ちょっとしたことでもKeepに挙げたり、Problemで人を責めないようにすることなどを注意しながら始めました。

またこの段階での一番の課題は無法地帯だった開発プロセスをコントロールできるルールを作ることでした。

そこで最初のTryでは開発開始からリリースまでのルールを決定しました。

具体的には

  • 約2週間に1回のリリースサイクルを決め、開発チームはリリース希望日に一番近いリリース日を選択してもらう方式に
  • コードフリーズ日を決め、それ以降の機能追加を禁止
  • リリースバージョンごとにGitHubのMilestoneを作成し、そのバージョンに含める開発項目をissueにして管理
  • テスト期間を定めissueに含まれる開発項目を漏れ無くテスト

といったルールを決めました。 これにより、部署間でのスケジュール調整が不要になる、直前の駆け込みコミットを禁止できるようになるなど、開発上のリスク要因を理論上大幅に削減することができるようになりました。

次はルールを徹底する負担の削減

ルールを決めて何度かイテレーションを繰り返しルールの精度を上げていくと、次はそのルールを維持するコストが問題になりました。忙しい日々の中で常に様々なルールを意識して行動するのは意外に難しいものです。そのため気づくとコードフリーズに間に合わない状況が発生していたり、リリース準備のための細々とした準備作業のタスク漏れによる作業遅延などの問題が起きていました。

そこで次の振り返りではルールの運用コストを下げる施策をTryしました。

具体的には開発開始からリリースまでに必要な作業をチェックリストにして1つのissueにまとめるというものです。

f:id:y_310:20141029224237p:plain

これによって作業を記憶しておく必要がなくなり負担が大きく減りました。 このチェックリストを使う試みはシンプルながら思いの外うまくいったので、以前こちらのブログで紹介した アプリ開発の品質底上げ施策をWebhooksでBotが支援する世界 においても、Pull Requestマージ前の確認項目として使っています。

誰がルールを運用するのか

チェックリストを作って運用を始めたところ、誰がこの作業をするのかというのが次の問題になりました。手が空いた人が率先してやるという形でやっていましたが、自分のタスクに集中しているうちに気づくと誰もやっていないという状況が起きていました。

そこで次の振り返りではリリースマネージャーというそのバージョンのリリースに責任を持って取り組む役割を設定しました。 リリースマネージャーはそのバージョンに含める開発項目の決定や、開発途中でのタスクの進捗確認、コードフリーズやリリース作業などリリースを成功させるための作業全体に責任を持ちます。 バージョンごとにリリースマネージャーの担当者を変更することで特定の人に負荷が偏らないようにしながら運用しています。

そしてその先へ

この他にも細かい改善を沢山積み上げていますが、ここまでの取り組みで開発プロセスをほぼコントロールできるようになりました。 結果として深刻なバグや大幅なスケジュール遅延を起こすことなく、半年間でAndroid、iOSそれぞれ10回ずつリリースすることができました。

ただ今までの取り組みはほぼ問題を起こさないための仕組みづくりでした。 ここで一定の成果が出たため、今後はユーザ価値の観点で見た品質向上にシフトしていこうとしています。 これについてはいつか良い成果が出てきたらまたご紹介したいと思います。

KPTの重要性

今回の取り組みにおいて、KPTによって着実な一歩を積み重ねていく仕組みを作ることは個々の施策以上に重要なことだと考えています。

プロセス改善はそれ自体が目的ではないため、散発的に改善のアイディアを出しても継続できず自然消滅してしまうことがよく起こります。 そこにKPTを導入することで、失敗した施策から目を背けず、成功するまでTryを繰り返す仕組みづくりができるようになります。

KPTのコツ

KPTを実践する中で見えてきたコツを箇条書きですがいくつかご紹介します。

  • 前回のTが実践できていたかどうか必ず最初に確認する
    • やらないと改善策を出しただけで実践されないままになる
  • Kは少しでも良いと感じたら躊躇わずに挙げて改善の取り組みがうまく行っているという雰囲気を出す
    • 最初のうちは「振り返りを実施できた」というレベルでも重要なKになる
  • Tが浮かばない場合Pが抽象的過ぎる可能性が高いので、問題を一般化せず具体的に捉えなおす
    • 「バグが多い」というPならどういうケースのバグが多いのか、開発のどの段階で見つけられるのかといった詳細を分析してTを出す
  • Pが多い場合はすべてを一度に解決しようとはせず、着実に現状より改善出来る範囲のTを実践する
    • 一回のイテレーションでできることは限られていると自覚して確実にできる施策だけをTに含める
  • Tは「気をつける」「注意する」といった心がけではなく、チェックリストを作れるような具体的な行動にする
    • 次回の振り返りで出来たかどうか明確に判定できないものはTではない

最後に

今回ご紹介した取り組みは目の醒めるようなアイディアや先進的な技術といったものは全く登場しない地道なものです。

もちろん技術で解決できることはどんどん取り組んでいきますが、それだけに固執せずに小さい問題解決を積み重ねることにも価値があるということがお伝えできればと思います。