クックパッドのモバイルアプリ開発が「機械に人が合わせる」リリースフローに行き着いた理由：＠ITソフトウェア品質向上セミナー2018（2/2 ページ）

「機械が人に合わせる」から「機械に人が合わせる」へコペルニクス的転回

　このように大きく3つのフェーズに分かれるクックパッドのモバイルアプリの開発体制だが、根底には常に共通するニーズがあった。「可能な限り開発や施策の検証を素早く回したい。ただ、開発速度を上げるからといって、品質を下げたいわけではない。そして、アプリというものは一度出して終わりではなく、頻繁に更新するものであり、持続的な開発環境を維持してコードの品質を保っていきたい」ということだ。

問題点の可視化

　こうした要望を満たす前に、茂呂氏らは「開発作業のどこで、どのように時間がかかっているのか」「ビルドに時間がかかるのか、レビュー作業か、あるいはレビュー待ちの時間か」といった事柄を調査し、可視化した。

ビルド時間を可視化した例

　ここから導き出されたのは、「ビルドの待ち時間は無視できない」というものだった。「中には1日のうち1時間もビルドを待っている人もいた。残念ながらここは自動化が有効な部分ではないので、モジュールの分割やハイスペックPCの導入といった対応策を講じた」

　もう一つ分かってきたことは、やはり「コミュニケーションコストが高い」ということ。「部署をまたいだスケジュール調整や各チームにヒアリングしてイシューを整理するといったコミュニケーションは必要不可欠な事柄だが、リリースマネジャーに少なからぬ負担がかかっていることも明らかになった」

毎週金曜日の早朝にコードが自動的にビルドされ、成果物としてアップロードされるフローに人が合わせる

　こうした実情を踏まえ、茂呂氏らは、「自動化すべきところは一体どこか」を考えた。

　「人は単純な作業を何回も繰り返すのは苦手だけれど、機械は得意。繰り返し行う決まった作業、人が間違えやすいところは機械に任せていくのがよいのではないか」ということで新たに取り組み始めたのが「機械に人間が合わせる新しいリリースフロー」だ。

　「コンセプトは、機械に人間が合わせること。人がやっていたことをbotのような機械にやらせるのではなく、人間が機械のペースに合わせた方が、実は効率的なのではないか。今までは人間中心で、人間の都合に合わせてやってきた。そのため、休暇や、そのときのチームの都合でリリースのタイミングが変わっていたが、そのやり方を止め、機械を中心とする考え方にシフトした」

　機械に合わせる新しいリリースフローでは、毎週金曜日の早朝にコードが自動的にビルドされ、成果物としてアップロードされる。「次のリリースに何らかの修正を含めたい」と考える開発者は、このタイミングに間に合うように動作確認を行った上でマージしなければならない。一方、以前はサブミット前に実施していたシナリオテストや全体の動作確認は、リリース候補のアップロードが済んだ後に行う形とし、万一致命的な不具合が見つかった場合はすぐに戻せる形にした。

毎週金曜日の早朝にコードが自動的にビルドされ、成果物としてアップロードされるリリースフロー

新しいリリースフローの構成

できるところを自動化し、機械に合わせることで得られたメリットと、新たな課題

　新しいリリースフローになったメリットは、幾つかある。

• リリースサイクルが速くなり、各開発チームがスケジュールを意識して行動するように

　まずは、リリースサイクルが速くなり、リリース回数が増えたことだ。そして、各開発チームがスケジュールを意識して行動するようになったという。

• リリースマネジャーの役割も不要に

　毎週自動的にリリースされるため、リリースマネジャーの役割も不要になった。

　「これまでのフローでは、時に次のリリースが2〜3週間後になることもあった。そうなると開発側もそこまで間隔が空くのは許容できず、リリースマネジャーが『何とかこのリリースにねじ込ませてくれ』と依頼されることもたびたびあったが、毎週確実にリリースが出る安心感から『修正を次に回す』という選択肢を容易に採れるようになった」

　一方で、すぐにチーム全体が「この時期に入るはずだったもの」という意識から逃がれられるようになったわけではなく、修正を積んで手動再サブミットを行うことがあるという。

　「再サブミットするとしても、新しく致命的な不具合が入ることのないように慎重に進めている」

• 開発チームが品質をコントロールできるように

　新しいリリースフロー導入のもう一つの狙いとして「開発チームが品質をコントロールできるようにしたい」という思いがあった。「発生した不具合にどう対応するかを考えるのは、開発チームであるのが健全ではないか」

　以前から品質には気を配ってきたし、QIT（Quality Improvement Team）を設けて不具合の指摘も行ってきたが、新しいリリースフローでは、開発チームが動作確認を行い、必要な修正を加えた上でマージする形になった。

　リリース直前の全体確認で重大な問題に気付き、あちこちで手戻りが発生するという従来のやり方に代わり、開発チームごとにマージ前に問題に気付き、食い止められるようになったこともメリットだ。

　「『リリース前に発覚した不具合をつぶす』という思い込みを排除しないといけない。『不具合をつぶす』よりも、『不具合を素早く検知し、どう対応するか』を考え、開発チームでノウハウを蓄積し、同じ間違いを次の開発で繰り返さないようにしたい。その意味から、不具合を一律に扱うのではなく、内容や影響範囲に応じてレベル分けしたり、テストや動作確認を効率化し、ある程度の期間でテストパターンを網羅したりするようなやり方も必要だろう」

まだまだ人の意識を変えていく取り組みが必要だ

　このようにクックパッドでは、長年にわたって開発体制とリリースフローの改善に取り組み、「より素早く品質の高いコードをリリースする」という要求を満たすため、機械に単純作業をやらせる「自動化」を進めてきた。そしてさらに一歩進んで機械を中心とする考え方にシフトすることで、いっそうの効率化、省力化が可能になることに気付いたという。

　茂呂氏は「このやり方が全てに当てはまるとは思えないし、組織やサービス、アプリを取り巻く状況に合わせて変えていく必要はあるが、自動化を進め、機械に合わせることで効率化した今、人間は人間にしかできないところに注力すべきだ。そのために、まだまだ人の意識を変えていく取り組みが必要だ」と述べ、講演を終えた。