今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。開発体制クックパッドにはモバイルアプリを専門で開発するようなチームはありません。必要に応じて、誰でもモバイルアプリ開発に取り組みます。機能追加・修正を行ったらリポジトリにプルリクエストを送ります。プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。リリースマネージャーバージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。進捗確認、リリース作業、リリース後の監視を行います。リリースマネージャーがリリースに関する作業を受け持つことで、他の開発者が自分の開発に集中できるようになりました。チェックリストにすることで、何をすべきか、何がまだ終わっていないかがわかるようになり、開発フローをうまく回すことができるようになりました。リリースマネージャーはアプリ開発者の中から持ち回りで選んでいますが、通常の業務に加えて担当するとなると負担が大きいので、作業の自動化を少しずつ進めようと考えているところです。自動的にリリースビルドを作成したりアップロードしたりする仕組みやリリース後監視を楽にするダッシュボードを作ろうとしています。開発イテレーション開発では、以下の様な項目を1イテレーションとして回しています。どのバージョンにどのような変更をいれるか管理するようにしています。開発期間10営業日のうち8日目をプルリクエスト受付最終日としています。これは、開発期間最終日に駆け込みでプルリクエストが大量にやってきてコードレビューが終わらないという事態になるのを防ぐためです。機能追加が間に合わないとわかった時点で、修正を次のバージョンに回すなどの調整を行います。開発期間が終わればコードフリーズとし、以降の修正はこのバージョンの修正によっておきた不具合修正など最低限にとどめます。テスト期間の3営業日では、不具合の洗い出しとその改修を行います。事業として優先度の高い内容を除くと、多くは前回リリースからの実装差分に焦点を充てて確認を行います。基本的に、不具合の改修もこの期間内に行います。ここで行うのは主にリリース前の手動テストです。この期間でなくとも、自動テストや手動テストを必要に応じて回し、不具合があれば修正します。基本的には決まったペースでイテレーションを回していきたいのですが、必ず守っているわけでもありません。場合は審査の都合で計画通りにリリースすることができない場合があります。期日の決まった機能追加があっても、他の修正が原因でリジェクトされてしまったり不具合が起きたりしてリリースできない恐れがあります。そのため、スケジュールだけでなくバージョンに含める機能の調整を行うことがあります。全体に影響をあたえるような大きな変更がある場合は、他の修正を次にまわしてもらうなどの調整をしています。場合は段階的リリース、iOSの場合はサブミットして審査が通り次第リリースします。対象ユーザを広げてリリースします。10%リリースを行います。段階的リリースを行うのは、不具合によって迷惑をかけてしまうユーザをなるべく少なくするためです。不具合による被害の拡大を防ぐためでもあります。リリースにあたったユーザにも不具合を出さないことなのでテスト期間を十分に設けていますが、起きるときは起きてしまいます。ユーザが増えることで見えてくる不具合もあるので、慎重にリリースを進めています。リリース可能な状態になったら翌日の午前中にリリース準備・公開作業を行うようにしています。休前日にはリリースを行いません。休日中に不具合が見つかったとしても、きちんと対応することができないためです。リリース後監視アプリをリリースした後は以下の項目を確認しています。アクティブユーザ数の伸びAPIのエラーレスポンス数APIのエラークラッシュ数アプリが利用しているAPIでエラーが増えていれば、なにか不具合につながるような予期せぬことが起きている可能性があります。アプリのクラッシュ数が増えていたら最悪です。リリースした日の夕方や翌日の朝など時間を決めて、アプリに異常がないか確認しています。アプリエンジニア間の連携の取り方あちこちの事業部にアプリエンジニアがいる状況は、事業部内での意思疎通が図りやすいメリットはありつつも、アプリ開発の足並みを揃えるのが難しいデメリットがあります。そのため、毎日アプリエンジニアが集まる朝会を開いています。朝会ではアプリに関する全体連絡やスケジュールの確認、各自の進捗報告などを行っています。10分程度の軽いものです。朝会によって、アプリに今何が起きているのかがみんなに伝わります。開発期間の開始やリリース後には社内ブログで周知しています。これによってエンジニア以外にもアプリのリリーススケジュールを意識してもらったり、アプリのどこが変わったのか伝わりやすくしています。ふりかえり少し前の記事「KPTで粘り強く品質改善に取り組んだ話」にもありますが、イテレーションが終わるごとに、そのバージョンの開発期間中に起きたことを少しでもコミットしたメンバーを集めて振り返っています。開発を進めたり、良いアプリを作るために少しずつ改善を続けていきます。おわりにクックパッドでのモバイルアプリ開発の流れを説明しました。モバイルアプリの品質を損なわずにどう開発を続けていくのがよいか、アプリエンジニア達で試行錯誤し、今はこの形に落ち着いています。このやり方が必ずしも正解というわけでもないし、まだまだ困っていることもたくさんありますがより良い方法を考えていきたいと思っています。09:30クックパッドモバイルアプリの開発体制とリリースフローTweet関連記事2018-12-12毎週リリースを実現するテスト活動こんにちは。技術部の松尾(@Kazu_cocoa)です。クックパッドでは、2年程前か...2016-03-11デザイン品質を高めるための仕組みづくり安定したデザイン品質のモバイルアプリをユーザーさんに届ける...2016-02-26アプリの動作確認をする時に心がけていることこんにちは。投稿推進部ディレクターの新里です。使ったセキュリティログ検索基盤の構築サービス特性にあった検索システムの設計戦略クックパッド採用説明会「クックパッドはサービスの作り手を採用したいんです。/*}*/スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。