クックパッドのモバイルアプリ開発が「機械に人が合わせる」リリースフローに行き着いた理由：＠ITソフトウェア品質向上セミナー2018（1/2 ページ）
クックパッドのモバイルアプリ開発チームは「機械が人に合わせるのではなく、機械“に”人が合わせる」という新しいアプローチを採用した。その理由とは何か。この新しいリリースフローに至るまでの道筋と効果とともに、同社の茂呂智大氏が＠ITソフトウェア品質向上セミナーの基調講演で明かした。
「毎日の料理を楽しみにする」ことを目指し、料理レシピの投稿、検索サービス「クックパッド」を中心にさまざまなビジネスを展開してきたクックパッド。創業20周年を経て、全世界のレシピ数は500万品、月間利用者数は約9200万人に達するほどに成長している。
クックパッドのビジネスの中心はiOSやAndroid向けのアプリだが、他にも料理という切り口から派生したさまざまなアプリやサービスを提供している。これらのリリースを適切に管理し、ニーズに応じて迅速にアップデートしていくため、同社のモバイルアプリ開発では、「機械が人に合わせるのではなく、機械“に”人が合わせる」という新しいアプローチを採用した。
2018年12月14日開催「＠IT ソフトウェア品質向上セミナー AI／機械学習、自動化で開発現場にも訪れるシンギュラリティーにどう備えるか」の基調講演では同社 技術部 モバイル基盤グループ グループ長の茂呂智大氏が、この新しいリリースフローに至るまでの道筋を紹介した。
サービスの拡大に伴って変わった開発体制、その歴史と変わらぬ要求
クックパッドのモバイルアプリ開発の体制は大きく3つのフェーズに分けられる。初回リリースはiOSアプリが2009年11月で、Androidアプリが2012年1月だ。
専門チームがアプリ開発を担当していた時代（2014年前期まで）
1つ目は、黎明（れいめい）期から続いてきた、専門チームがアプリ開発を担当していた時代だ。
1つのクックパッドアプリに対して何人かの開発者がコミットする形で、他部署からの機能追加依頼を受けて修正を行い、そろったら動作確認してリリースする流れだ。
「徐々に開発規模が拡大していくのに合わせて、持ち回りで作業を行えるようにサブミットやリリースの手順を整備したり、コードの品質を担保するためにコードレビューやテスト体制を整えたりと、徐々に整備を進めてきた」
複数のチームで1つのクックパッドアプリを開発する時代（2014年後期〜2017年）
そしてクックパッドのサービス規模拡大に伴って、2つ目のフェーズに突入した。開発規模が拡大し、複数のチームで1つのクックパッドアプリを開発する時代だ。このころから組織体制が大きく変わり、レシピの検索や会員獲得といった注力分野ごとにエンジニアが分散し、特化して動けるようになっていった。
「一方で、コードレビューはチームをまたいで行うようにしていた」
リリースフローの本格的な整備が進んだのも、このころだ。部署は分かれても開発対象のアプリは1つ。「リリース手順を統一する必要がある」ということで、リリースごとに責任者となる「リリースマネジャー」を立て、イテレーション中の変更をまとめたり、部署間の連携を行っていたりした。同時に、リリース時の注意事項をチェックリストとしてまとめ、誰でも同じようにリリースできるような体制を作っていった。
基本的には、2週間ごとにリリースを行う形でイテレーションを回し、10日くらいで開発、実装を進めていた。コードレビューや修正の猶予を見て8日目に締め切りを設け、コードをフリーズしてテストや動作確認をした上で、「よし行ける」となったらリリース、サブミットを行っていた。
一方で、具体的なリリース日は、ビジネス側の都合に応じて柔軟に調整することもたびたび起こるようになる。また、このフローを回していく中で、幾つかの問題点も明らかになってきた。
一つは、特定の施策専用のバージョンが増えたり、「この間は効果検証のため、しばらく他の施策は入れないでほしい」といった要望が増えた結果、他の部署の施策や効果検証をブロックしてしまったりしたのだ。
「思ったように手を打てなくなり、開発速度が低下するケースが生じてきた」
もう一つは、コードレビューに対する疲弊感の顕在化だ。スペルミスなどささいなミスの指摘に時間が取られたり、コードレビューが一部のレビュアーに集中して負担が増えたりする一方で、開発者側にとってはなかなかレビューされず、マージされない時間が長くなるという不満も出てきた。
こうした課題を解決するため、クックパッドではまず、スペルチェックやスタイルのずれといったささいな問題点を機械的に指摘するツールを開発し、導入した。ソースコードにスペルミスがあれば、Slack上でbotが指摘してくれる仕組みだ。「スペルミスのようなささいなミスの指摘は機械に任せ、人間は、実現手段や実装方法に集中すべきではないか」という考えからの取り組みだった。
次に、リリースマネジャーが手作業で取りまとめていたサブミット作業の自動化に取り組んだ。Slack上でサブミットの指令を出すとJenkinsのジョブがキックされ、リリース作業自動化ツール「fastlane」によって一連の作業が実行される仕組みだ。
「人間が持ち回りで作業するのに比べ、手順の抜けや間違いがなくなった他、サブミット作業に必要な証明書やアカウントなどの重要な情報も集約できる効果が得られた」
クックパッドアプリだけではなく複数のアプリやサービスを開発し、リリースする時代（2018年以降）
そして今同社は、クックパッドアプリだけではなく複数のアプリやサービスを開発し、リリースする時代に突入している。これまでクックパッドアプリのために整備してきたリリースの仕組みを活用し、「開発速度、施策の検証速度を上げていきたい」というニーズに応えようとしている。
関連記事
日本企業が「カオスエンジニアリングやっていく宣言」を出せた理由
クックパッドが2018年8月2日に公開したブログエントリ「Chaos Engineering やっていく宣言」に大きな反響があった。米国を中心に多くの企業で実践されているが、疑似的とはいえ本番環境に障害を起こさせるというカオスエンジニアリングを日本で実践するのは、まず不可能という向きが多かったからだ。なぜ、クックパッドでは実践することが可能になったのか。
アプリ開発者とインフラ技術者間のSRE的なコミュニケーション改善に役立つインフラ基盤とは
本連載では、「インフラの、特に基盤寄りの立場からSRE（Site Reliability Engineering）の活動を行い、Webサービスの価値を高めるためにはどうしたらいいか」について、リクルートの新たなインフラ基盤を例に見ていきます。今回は、インフラ基盤の技術的解説とともに、出始めている成果、今後の展望についてお話しします。
開発、リリース、運用のサイクルを回す――アメブロのフロントエンドにおけるモダンなDevOps環境作り
2004年から続くブログサービス「アメブロ」が2016年9月にシステムをリニューアル。本連載では、そこで取り入れた主要な技術や、その効果を紹介していく。今回は、アメブロのフロントエンド開発におけるDevOpsの取り組みについて。
Copyright © ITmedia, Inc. All Rights Reserved.