見出し画像

アプリ改善のプロジェクトの始まりから終わりまで

はつゆき

こんにちは、くふうAIスタジオ買い物事業サービス開発部副部長を務めさせていただいているhatuyuki4です。自分は今までモバイルアプリエンジニアとしてiOSアプリ開発を主に行っていたのですが、今年になってからコーディングの比率を下げて、プロダクトマネジメントの仕事の割合を増やしています。今回は自分がアプリ改善のプロジェクトを企画してリリースが終わるまでの流れの中で、どのようなことを行なっているのかをまとめたいと思います。

プロジェクトの始まる前

何を行うか決める

プロジェクトが始まる前に、まず何を開発していくのか決めていく必要があります。一度開発が始まってしまうと多くの人員と時間がかかってくるので、効果の薄い無駄な開発を行わないために事前の調査は念入りに行います。調査に当たっては、以下のようなことを実施します。

  1. チームの今期の目標を達成するためにどのような課題があるか検討、調査をする

    • 定量的調査(利用状況などの数値分析をして改善点を洗い出す)

    • 定性的調査(ご意見・レビュー・ユーザインタビューなどを通じて改善点を洗い出す)

    • チーム内から改善意見を募る

  2. 集まった課題に対してさらに定量的調査を行なって、課題の重要性を決定する

    • ex: 画面の読み込み時間が遅いという課題

      • 対象となる画面のそれぞれの表示時間を調べる

      •  対象となる画面の各画面の表示頻度を調べる

      • 表示時間と表示頻度の掛け合わせで、画面ごとに重要度を決める

  3. 改善方針と優先度を決定する

    • 調査した結果から重要度の高いものから着手する

    • 重要度が高いが開発リソースが不足している、もしくは現時点では解決できないという場合は後回しにする場合もある

自分の場合は課題の発見に関しては定性的な調査を重視して、着手する課題の決定というところでは定量的な調査を重視しています。定量的なデータのみからユーザの課題を想起するのは難しいですし、数値の変動が起きやすい場所ばかりに着目してしまいがちです。実際のユーザインタビューなどでの意見を参考に改善の方向性を見つけ、それの重要性を定量的なデータで補完していくということを行なっています。

また、このフェーズでは1週間に2回ほど、企画壁打ちという定例MTGを実施して、企画の方向性を調整していきます。企画壁打ちでは上司やデザインリーダーと改善の方向性を擦り合わせたり、マイルストーンや開発リソースの調整、ステークホルダーコミュニケーションをどうやって進めるかなどの認識をそろえます。この段階で細かくコミュニケーションをとっておくと、後々方針が大きく変わって手戻りが発生することが少なくなるので、重要な場としてMTGを設定しています。

プロジェクト発足

企画書作成

方向性が決まったら、それを企画書に落としていきます。この企画書は企画意図の共有とデザインドラフト・技術設計を円滑に進めることが目的です。なのでこの時点では細かい仕様までは固まってなくて大丈夫ですが、企画として実行したい方向性は固めておく必要があります。

  1. 企画概要・コンセプト

    • 2行以内でその企画でやりたいことを記載する

    • 企画の骨格となるコンセプトがあれば記載する

    • コンセプトがあると他の人に伝えやすくなるし、仕様を決める際の判断軸になるのでなるべく考える

  2. 背景・仮説

    • なぜその企画を行うのか記載する

    • 課題検討の際に調べた定性的なご意見をまとめたり、定量的なデータをまとめて、読んだ人に企画の意図が伝わるようにする

  3. 仕様案

    • 目的はデザイナーがデザインを作成でき、エンジニアが技術設計を進められるようにすること

    • この段階で仕様はフィックスしていない

    • この段階ではデザインや技術的な制約が詳細には考慮されていないので、最終的な仕様はデザインドラフトと技術設計が終わってから固める

  4. 画面仕様案作成

    • 画面のアウトプット

      • その画面でどのような情報を表示するのか

      •  表示するのに必要なデータはどのようなものか

      •  表示条件はどのようなものか

    •  画面のインプット

    • どのようなUIコンポーネントが必要でどのようなアクションが発生するのか記載する

    • インプットの結果どのような処理が行われるのか

  5. デザインラフ

    • 自分の中でどのような画面になるのかイメージしておく

    • ただし、デザイナーがイメージする方向性を限定的にしすぎてしまう可能性があるので、デザインラフを書かない場合もある

    • デザイナーの経験をみて、キャリアが浅そうだったら具体的にした方がいい

    • ラフに落とさない場合でも、頭の中ではイメージは明確にしておく

  6. 数値的指標

    • この企画の効果を測定するために、どのような数値を指標とするのかまとめる

    • 数値を計測するために新しくログを仕込む場合は、どのような形式のデータが必要なのか記載する

技術設計、デザイン作成

企画書をもとにデザイナーとエンジニアに、デザインドラフト作成と技術設計を依頼します。デザインドラフトは実装開始の2~3週間前くらいに依頼して進めます。デザインドラフトが上がってきたらフィードバックを行います。デザインが自分のイメージと異なる場合は、以下のような分岐を頭の中で作ってフィードバックを行います。

自分のイメージと異なる場合

  1. 企画のコンセプトに対して自分のイメージより良い体験を提供している場合

    • 自分のイメージを捨てて、デザイナーの案を採用する

  2. 企画のコンセプトに対して自分のイメージと体験が変わらないと思われる場合

    • 自分のイメージを捨てて、デザイナーの案を採用する

  3. 企画のコンセプトに対して望む体験を提供できていない場合

    • どうしてこのデザインではダメなのかを言語化して説明する

    • その際に企画意図と背景を事前に整理しておくと、どの箇所は良くてどの箇所は修正が必要なのか話しやすい

デザインドラフトと技術設計が完了したら仕様をフィックスします。ただ、仕様がフィックスしたとしても、すべてのパターンを網羅しているわけではありません。異常系やマイナーなデバイスでの処理をすべて網羅するのはかなり難しいので、不確定なことが発覚したら発覚した時点で都度判断して仕様を決めていきます。すべてのパターンを網羅した正確なドキュメントを作成しようとするとそれだけで時間がかかりすぎ、開発のボトルネックになってしまうので、開発スピードとドキュメントの正確性のバランスをとりつつ問題が起きたらその場で会話して解消できる状態にしておきます。

実装開始

キックオフ

実装開始日が決まったら、開発メンバーを集めてキックオフを行います。キックオフでは企画の目的と仕様の認識をそろえることを目的としています。ここでも、プロジェクト開始前に調査した定量的データを活用します。

  1. 参加者

    • 企画担当者

    • エンジニア

    • デザイナー

    • QA担当者

  2. プロジェクトの目的となぜそのプロジェクトを行うのか共有する

  3. プロジェクトの仕様を共有する

  4. メンバーから質問があったら個別に解決していく

  5. 開発スケジュールを具体化する

    • ○○日までにAPIをステージングに公開する

    • ○○日までに実装を完了してQAを開始する

    • ○○日にリリースを行う

定例

プロジェクトごとの定例は、主に1週間に2回程度の頻度で行っています。これはチームごとに開催するデイリーの朝会とは別に設けて、プロジェクトの開発を進める上での課題や疑問を吸い上げます。毎日だと進捗が特にあがらないことが多いので、プロジェクトの定例は週2回にすることが多いです。この時点で企画書時点で決められていなかった細かなパターンの仕様をどうすれば良いかという話になることが多いですが、それはその場で都度決定していきます。

仕様を決める際は、以下のような優先順位をもって判断していきます。

  1. 達成したい要件を満たしているか？

  2.  ユーザの体験に悪影響を及ぼさないか？

  3. 自社のデザインシステムガイドラインに準拠しているか？

  4. OSのデザインガイドラインに準拠しているか？

  5. 実装、運用保守上のコストは問題ないか？

リリース

実装が完了したら問題がないかQAと実際の動作確認を行い、リリースを行います。リリースにあたって必要な場合はステークホルダーにリリース日と内容を周知します。

振り返り

ダッシュボード作成

リリースが終わったら、そのプロジェクトの効果が測定できるダッシュボードを作成します。確認する項目は利用数や利用率(CTR)、ネットワークパフォーマンスなどプロジェクトによって異なります。リリース後の1か月くらいは毎日観察し、異常な動きを見せていないかチェックします。

まとめ作成

リリースから2週間ほどたったら、そのプロジェクトの結果をまとめます。基本的にはダッシュボードの数値を貼りつつ、仮説に対してどのような結果が生じたのかを記載し、どうしてそのような結果になったのか考察も加えます。

新機能などを開発してご意見やレビューでの反応が来た場合は、それらをポジティブな反応もネガティブな反応も記載します。

またまとめにはプロジェクトの背景から記載し、そのプロジェクトの概要を知らない人が読んでもどのような施策が行われ、どのような結果が得られたのかまとめるようにします。

買い物メモリリース後のダッシュボード

Next Action

まとめをもとに、NextActionを決めていきます。追加の開発が必要になった場合は再度企画を検討し、開発計画をたてて改善に取り組んでいきます。

おわりに

プロジェクトが始まり、完了するまでを一通り書いてみました。色々書いてきましたが、自分が重視しているところは以下のような点になります。

  • 企画意図と背景は関わるメンバー全員に伝える

  • 企画意図が伝わるように定量的な根拠を用意する

  • はじめに詳細まで詰めすぎずに、コミュニケーションの頻度を上げて細かく調整する

特に企画意図は開発メンバーだけではなく、他の部署の人にとっても開発が何をやっているのかクリアにすることができるので、わかりやすく明確にしていくことを心がけていきたいですね。

くふうAIスタジオでは、採用活動を行っています。

当社は「AX で 暮らしに ひらめきを」をビジョンに、2023年7月に設立されました。

（AX＝AI eXperience（UI/UX における AI/AX）とAI Transformation（DX におけるAX）の意味を持つ当社が唱えた造語）

くふうカンパニーグループのサービスの企画開発運用を主な事業とし、非エンジニアさえも当たり前にAIを使いこなせるよう、積極的なAI利活用を推進しています。

（サービスの一例：累計DL数1,000万以上の家計簿アプリ「Zaim」、月間利用者数1,600万人のチラシアプリ「トクバイ」等）

AXを活用した未来を一緒に作っていく仲間を募集中です。

ご興味がございましたら、以下からカジュアル面談のお申込みやご応募等お気軽にお問合せください。

https://open.talentio.com/r/1/c/kufu-ai-studio/homes/3849

ハッシュタグ

#中途採用 #エンジニア採用 #採用広報 #株式会社くふうAIスタジオ #テックブログ

この記事が気に入ったらサポートをしてみませんか？