iPhoneアプリ開発の背景

クックパッドは，オリジナル料理レシピの投稿・検索ができる日本最大の料理サイトです。現在の投稿レシピ数は69万品を超え，日々料理する20，30代の女性ユーザーを中心に，月間858万人が利用しています。

弊社ではこれまでiPhoneの対応は行ってこなかったのですが，iPhoneの普及も進み，日常的に料理をしている女性にも受け入れられつつある手ごたえを感じるようになってきました。これはそろそろクックパッドとしても本格的に対応を進めたい，iPhoneでもクックパッドを使って料理を楽しんでいただきたい，ということでアプリの開発に着手しました。

開発プロジェクト始動

ディレクター1人，プログラマー2人，デザイナー1人

本格的に開発することになり，ディレクター1人，プログラマー2人，デザイナー1人から成るプロジェクトチームが結成されました。体制が決まれば次はスケジュールなのですが，このチームは通常業務を一緒に行っているチームではなく，それぞれ別のプロジェクトを進めていた人が招集されたチームだったため，当初開発に使えるとされた時間は1週間しかありませんでした。

まずはAppleへの登録からスタート

この時点では，まだどういうアプリにするかの仕様は決まっておらず，iPhone Developer Programにも登録していないという状態でした。そのため，本当に1週間でプロダクトを完成させてAppleに申請できるのか誰もわからない状況ではあったのですが，とにかく「無料アプリで1位をとれるクックパッドアプリを1週間で開発する！」ということを目標にプロジェクトがスタートしました。

「顔マーケティング」を意識した設計

ミニマムスペックからの設計

アプリの設計では機能と構成の検討のみを行いました。機能検討のフェーズでは，まずアプリにあるべき機能を定義し，その中でもサービスのコアとなる，本当に必要な機能のみをピックアップしました。開発者としては，初めから豊富な機能を実装したものをリリースしたいところなのですが，より少ないコストでより良いものを作るためには，ミニマムスペックで開始して，徐々に改良を進めていくということが重要だと思います。

最終的には，レシピ検索，関連語検索，検索履歴，話題のレシピ，旬のキーワード，ご意見ボックスが実装候補として残りました。今回はWebですでに展開しているサービスから機能を持ってきたので，機能検討についてはスムーズに進行しました。

成功のイメージを強く持つ

この中でも特に重要な機能については，最終的にどのような仕上がりに持って行きたいのか，その成功のイメージも固めました。

たとえば，検索であれば「検索結果を見た際に作りたいものがすぐに見つかる状態⁠」⁠，レシピの閲覧であれば「レシピを見ると 必ず作りたくなる状態」という感じです。感覚的な定義ではありますが，最終的に「料理が楽しくなるアプリ」になっていないとリリースする意味がありませんので，大切なポイントです。

機能検討・要件定義の後は，顔マーケティングによる設計

機能の検討が終了した時点でプログラマーがそれぞれの機能を単体で作り始め，ディレクターがアプリの構成を検討するフェーズに入りました。ここはアプリの印象を決定づける重要なフェーズですので，アプリの起動画面や，起動直後のファーストビューに何を持ってくるかを検討するために，顔マーケティングを重視した設計を行いました。

顔マーケティングとは『⁠“⁠売れ顔⁠”の法則』で紹介されている，ヒット商品を生み出すためのマーケティング手法の一つで，ウリを伝える「顔⁠」⁠，ライバルに勝てるひと言で言える「ウリ⁠」⁠，ウリが実感できる「効き」の3つの原則で構成されています。

今回のアプリでは，顔は「スタート画面のレシピ60万品表示⁠」⁠，ウリは「60万品のレシピから作るものが決まる⁠」⁠，効きは「簡単な操作で作るものがすぐ決ま る」という形に収まりました。最終的に３原則を考慮して，起動画面に全レシピ数を表示することで膨大な数のレシピから探せることを伝え，起動直後に旬の キーワードをタップするだけでレシピがすぐに見れる，という導線に整理されました。

iPhoneでもアジャイル開発

弊社ではアジャイル開発を行っているのですが，今回のアプリも例外ではなく通常の開発サイクルと同様，アジャイルに開発しました。設計のフェーズをご覧いただいたとおり，今回の設計では機能と構成の検討を行ったのみで，その他開発に必要となる情報，たとえば画面には何をどのように表示するのか，などは実際に作ってみて，何度も改良を加えながら固めて行きました。

携帯アプリの特性を把握し，UIを先に，コードを後に

このようなインクリメンタルな開発手法は，開発中にどんどん画面遷移や，画面のレイアウトに変更が入るため，画面構造を容易に変更できない携帯アプリなどでは結構辛い開発手法だと思います。ただ，コードのメンテナンス性を無視すればある程度の速度は出ますので，UI検討中は見た目だけそれっぽく仕上がるように組み上げてしまい，ある程度UIが固まってきた段階で，全コードを見直してリファクタリングするという進め方を採用しました。

UIが固まってきた時点で社長チェックが入るのですが，当時はちょうど社長が出張であまり社内にはいなかった時期だったため，スカイプでiPhoneエミュレーターの画面を共有し，リモートMTGで確認を行っていました。このMTGももちろん開発プロセスに含まれていて，ここで誰かが気づいたこと，指摘されたことは即座に反映してその場で改良を進めます。リモートなので確認しづらいかと思いきや，これが意外と快適で，スムーズに確認を進められたことには驚きました。