こんにちは！「Tekito style」を運営しているやすのり（@98nasi_nori）です。普段は都内でWebディレクター/マーケターなどをしています。

ビジネスサイドやマーケターなどの職につくと、必須でつくるであろう企画書。企画や施策、会社・チームによっても内容が異なることが多く、自己流で作っている方も多いのではないでしょうか。

今回は「企画書ってどう作ればいいの？」という方に向けて、Webサイト・サービスの施策を考えるケースを例に、企画書を書く時に抑えるポイントや構成例をご紹介いたします。

僕も新卒時に入った会社では、企画書のフォーマットなどは当初特になかったので、色々思考錯誤しながら今の形に落ち着きました。今も改善途中ではありますが。

書き方は状況次第で異なると思うので、企画書の一例としてご参考いただけますと幸いです。

企画書の書き方・作り方は？企画の構成例

企画書の全体像を掴むために、まずは構成例をご紹介します。おおよそ下記の要素・ポイントを抑えておけば、最低限運用できるのかなと思います！

基本的には上から考えつつ、各要素を行ったり来たりしながら企画案をブラッシュアップしていくイメージですね。

ちなみに後述しますが、僕は企画書を作る時にいきなりパワポとかは使わず、まずメモ帳やgoogleドキュメントなどテキストでざっと書くことが多いです。

そっちの方が早いですし、修正も効きます。またしっかり言語化する必要があるので、あやふやな部分も少なくできるかと！

企画書・構成の各項目で考えるポイント

企画書の全体像がおおよそ分かってきたところで、構成の各項目についてざっと解説していきます。

1. 企画概要

最初に企画のサマリーをまとめておきましょう。企画目的、施策内容などを一言二言でまとめるイメージです。何をする企画なのか始めにイメージできていると、企画書を共有された人も読み進めやすいです。

2. 企画目的・背景 / 目標値（KPI）

なぜ今回の企画を実施するのか、その目的や背景はしっかり明文化すべきです。

そもそも目的がブレたりズレたりすると、企画内容そのものが的外れなことになってしまいます。また関係者間で認識を揃え、足並みを揃えることも大切です。

企画を進めていくと当初の目的からズレてきたり、「そもそもなんでやるんだっけ？」となることもたまにあったり。そういう時に本来の目的に立ち返る意味でも、企画目的はしっかり詰めて整理しておきましょう！

また企画する場合は「この数字をここまで上げたい」というのが念頭にあるケースが多いので、そうした目標値や達成基準なども明記しておきます。

3. 現状の課題（As Is）

目的を達成するにあたり、現状の課題を定量・定性データの双方から分析し、整理します。

解析ツールなどを使い、どこのページ・機能・コンテンツなどに課題があるのか、データを元に判断します。

またそれだけではなく、実際にユーザーや現場に近いメンバーへもヒアリングするなど、定性的な面についても課題を洗い出しておきましょう。

また企画内容によっては、自社と競合を比較した場合の課題なども前提としてあると良いですね。

※参考：ユーザーヒアリングについて ↓
【THE GUILD勉強会レポ】ユーザーインタビュー設計ノウハウについて@DMM

4. 仮説

次に、なぜその課題が発生しているのか、定量・定性の面から課題の仮説を立てます。

その課題に対し、どういう状態がユーザーにとってベストなのか、理想状態（To Be）およびそれを実現する解決策の方向性についても仮説を立てていきます。

課題仮説と、理想状態（To Be）・解決策の仮説、この2つの仮説の精度・解像度の高さが、企画の成否を分けるので、企画の肝ともいえる重要な部分です！

「頭が禿げそう……」と思えるほど考え抜くつもりで、仮説立てに挑んでみてください。

5. 企画・施策内容

上記で固めた仮説に対し、具体的に企画・施策の内容を固めていきます。

想定される企画・施策内容によってここの内容は変わってくるので、ここでは詳細な解説はしませんが、Webサイト・サービスの場合おおよそ下記のような要素を洗い出しておくと良いです。

割と抜けがちなのが、リリース後の運用オペレーション。リリースすることに必死でリリース後のことを考えておらず、オペレーションが回らない…… なんてことにならないように。

実際にリリースされたあとにどう機能やオペレーションを運用していくのか、そのあたりの仕組みや体制は忘れず想定しておくべきです。

6. 企画・プロジェクトの進め方

企画を実行していくにあたり、どうプロジェクトマネジメントしていくのかも企画者次第です。

色々な要素があるかと思いますが、最低限下記は抑えておきましょう。

企画全体のスケジュールはもちろん、デザイナーやエンジニア、決済者など、誰がどのタイミングでどう関わっていくべきかも仕込んでいきます。

企画した内容をどう円滑に進めるか、このあたりの調整は難しいところですが、後々のトラブルやごたごたを防ぐために最初から設計しておくことを推奨します。

7. 企画の振り返り

企画を実施して、そのまま放置されるケースって少なからずありますよね……。そうならないためにも、事前に振り返りの方法やタイミングを定めて、しっかり学びを振り返り次の企画・施策に繋げていきましょう！

企画書を作る時におすすめのツールは？

企画書をどのツールで作るかは、ほんとに人ぞれぞれですし、状況によって切り替えることが多いです。

僕の場合は下記のツールを使っていますね。参考までに！

先に述べた通り、僕は企画をつくる時は基本テキストで資料作成することが多いです。社内外のメンバーにも共有しやすいので、Google Documentがおすすめですね！

テキストだと無駄に装飾する必要もないし、シンプルに、早く、しっかり言語化して企画を考えることができます。

ただテキストドキュメントだと長くなりがちなので、思考整理やブラッシュアップをしたり、社内外のメンバーの企画内容をシェア・プレゼンするときはGoogle SlideやKeynoteを使います。

デザイン案やワイヤーをつくる時は、何だかんだ使い慣れているSketchが多いです。

人によってはAdobe XDで企画書全てを作る人もいるようで、まぁそのあたりはお好みでどうぞ！

【まとめ】企画書の書き方・構成は事前に押さえると楽！

企画書の書き方・作り方を、Webサイト・サービスの施策を考えるケースを例にご紹介してきました。

どの要素も基本的でシンプルな内容ですが、自分なりのフレームワークをもっておくと企画する時に多少楽になります。

企画を考える時はどんな企画内容であったとしても、闇雲に考えず、何を、どの順番で考えるべきか、最初にそこの視点を忘れずに持てると応用が効きますよ。

最後に改めて、企画構成の例のまとめです ↓↓

みなさんもより良い企画書の書き方や構成例があれば、ぜひシェアしてくれると喜びます！
それでは！

本記事とかぶる内容が多いですが、企画を考える際は下記記事も参考に！
【改善施策】企画立案の7ステップと考え方・進め方のコツ｜Webサービス/アプリ

普段は都内のEdtech系ベンチャー企業でWebディレクターなどをしています。学生時代1年間インターンをし、そのまま新卒入社、現在社会人3年目です。これまでWebサービスに関わる、大小様々な企画やディレクション案件に関わってきました。

スタートアップなので社内にノウハウがなかったり、そもそも専任のディレクターポジョンの人もいないような状況で、失敗を繰り返しながら手探りでここまでやってきました。

企画の立案方法や進め方ってなかなか身につけるのが大変だったり、「KPIを○○%上げるように改善して」などいきなり任されて何をどうしたらいいのか分からない…そんな方も多いのかなと思います。

そこで今回は個人、会社員問わず、Webサービスやアプリの企画やディレクションに関わる方に向けて、企画の考え方、特に何かを改善する場合の企画立案ステップや進め方のコツをまとめていこうと思います。

完全に僕個人の進め方かつ試行錯誤中であるので、もっとよい方法もきっとあると思いますが、ひとまず自分なりの考えを備忘録としてまとめてみます。

サービス改善企画における7つの立案ステップと考え方

まずは改善する案を出すまでのステップを、7つに分けてご紹介します。

企画の考え方(1) 改善する目的と目標値を再整理する

まずいきなり施策を考え始めるのは止めましょう。今回改善する目的・意図は何か、また数値として何をどれくらい改善するのかを具体的に定めいったん整理します。

そこの軸がブレていると、これから考える打ち手も全てブレてしまう上に、企画の振り返りの際に良し悪しが判断できなくなり、もし失敗し撤退する場合の基準なども曖昧になってしまいます。目的を改めて再整理し、社内やチームでの認識を揃えておくべきでしょう。

またこれは根性論とかになってしまうのですが、「絶対にこのKPIを達成する」という強い意思がなければ、なかなか良い施策は出ない気がします。企画者の本気度や熱意は企画の成功に大きく直結するので、その点でもここで改めて目的を自分なりに定めることは重要かなと思います。

企画の考え方(2) 現状分析：課題点の仮説を立てる

次に現状の数値を達成できていない課題点、その理由の仮説をいったん自分なりに考えてみます。ペルソナとなるユーザーはどんなことに困っていたり詰まったりしているのか、何が行動の阻害要因になっているのか。

課題点をいったん全て洗い出し整理、それが本当に課題なのか、突き詰めて考えてみるべしです。ここでの仮説の精度が荒ければ、その分解決策の精度が下がり、つまり企画の不成功に繋がります。

仮説の精度はかなり重要で、出来る限り小手先ではなく、本質的な課題にアプローチすべきです。表面上の課題をいくら解決しても、結局大きく課題を解決することはできず、また違う問題が表面化するだけです。課題のボトルネックになっている、真の課題を捉えるべきです。

企画の考え方(3) 現状分析：データを見る、有識者＆ユーザーにヒアリング

ここでようやく過去のデータや数値を見ます。課題として置いた要素が、本当に課題になっているのか客観的な指標から判断します。上記で出した課題は、どんな数値を見ればそれが課題だと証明できるのか？その当てをつけながら数値を深掘りしていきましょう。

施策を出す時にいきなり数値を見るのは止めておくべきです。もちろん数値を見て新たな課題に気付くことも多いので、ケースバイケースな部分もあるのですが、数字の海に溺れて収拾がつかなくなったり、本質的な課題を掴み取りづらくなる場合があります。個人的にはまず課題の仮説を立てた上でデータを見る方が良いかなと思います。

仮説を裏付ける数値が出ないのであれば、その仮説は間違っているのかもしれません。いったん課題をもう一度考え直すというのも手です。また数値化できない領域であれば、社内のナレッジがある人（ユーザーと直接関わる人や業界知識がある人など）に意見を聴くのもよいです。

またプロジェクトに時間や予算的余裕があるのであれば、社外の有識者やユーザーにもヒアリングした方が課題の精度が上がります。特に重要なKPIに直結するような企画の場合は、数人でもユーザーへのヒアリングはしておくべきでしょう。

企画の考え方(4) TO BE（理想の状態）を定義する

(2)のステップでまとめた課題に対し、もっともベスト・理想的な状態を描きます。その課題が解決された状態は、つまりどのような状態なのか、言語化し定義しましょう。

また同時になぜそれが理想の状態であるのか、どのようなメリットがあるのか、ユーザー視点で整理します。理想の状態の候補が複数ある場合は、どちらの選択肢がユーザーにとってベストか、再度課題の本質に立ち返り考えてみましょう。

企画の考え方(5) 施策の洗い出し

下準備が整ってきたところで、いよいよ具体的な施策を考えていきます。

現状課題がある状態を、いかにして解決するのか、どのような施策が打てるか、全て洗い出します。その際は先ほど考えた理想の状態・あるべき状態にどう近づけるか、ということを念頭に置きましょう。理想から逆算し、現実とのギャップを埋める工程ですね。

この段階で競合サービスや提供しているUXが類似する別業界での他社サービスなども色々見てみて、施策として取り込めそうな機能やデザインの参考にしましょう。また改修する機能を軸に（検索機能、一覧ページなど）、色々なサービスを横串で見ると施策アイディアのヒントになることもあります。同じような課題を抱えたサービスがどのようにそれを解決したのか、その背景がちらっと垣間見えたり。

施策のアウトプットの質と量は日々のインプットに比例するので、常日頃いろいろなサービスをウォッチしておきましょう。

企画の考え方(6) 施策の優先度を精査

施策を洗い出したら、複数の項目別（コンテンツ、UIなどの大カテゴリ、またPC・SPなどデバイス別、ページや機能別など）にグルーピングするなど、整理整頓・精査していきます。

恐らく1つの課題に対して複数の解決策が出ることが通常だと思いますので、実行する優先度も決めましょう。KPIへのインパクト（課題解決度）、工数（開発が関わる場合は開発・デザイン工数をざっくり見積もってもらう）、実行コストなど複数の軸で精査します。

できればKPIへのインパクトが大きく、工数が最小の施策から実行するのが常套手段です。手間がかかるものはいったん後で回しでOKですが、時としてコスパのいいものは本質的な解決策でない場合も多く、ある程度そのサービスに携わった上での知見や経験則で判断する必要があります。

また個人的にはコストがかかってでも、本質的な打ち手をいかにしっかりやり切るかだとは思います。しかし資金的に余裕のある大企業ではなくスタートアップや中小企業などの場合、まずはいったん目先の数字を上げてから、本質的なことをやるなど、事業や企業の状況を見ての判断が必要なケースも多々あるかなとは思います。

企画の考え方(7) おおよその実行スケジュールを切る

施策の整理と優先順位付けが完了したら、全体のスケジュールを設計します。

個々の施策別に、企画、デザイン、開発の工数を見積もり、デバックや調整踏まえたバッファー期間を含め、いつまでにリリースするのか定めていきます。まだそれぞれの担当者も定めて置きましょう。

複数の施策が同時平行する場合は、いつもスプレッドシートでガントチャートをつくり進行管理していますね。

企画・施策の進行ディレクションで心がけておきたいこと

ここでは僕の過去の教訓を踏まえ、企画を実行・ディレクションしていく上で心がけておきたいことをさくっとまとめました。何か参考になれば幸いです。

企画進行のコツ(1) CVに直結するページの改修は最大限に慎重をきすべき

CVつまり売上に直結する重大なページや機能を改善していく場合は、最大限慎重に企画の実行を進めましょう。

大変でも抜本的な施策を打たなければ、大きく数値を改善することは難しい場合もあります。しかし大きく改修する場合は、逆に大きくマイナスにも左右する可能性もあります。スタートアップなどの場合、CVRが少し変動しただけで大ゴケする場合も。

どんなに考え抜いた自信のある企画でも、フタを空けてみたら想像と大きく乖離する可能性もあります。実際にリリースするまで分からないことも多々あるのです。

構想は大胆に、しかし実行は慎重に移しましょう。

企画進行のコツ(2) 改修は必ずリーンに実行すべき

基本的に既存のサービスを改善する場合は、施策を更に細かく分割して、ステップごとにリリースしていくべきです。

その方が開発工数を抑えることができるケースも多く、小刻みにリリースすることで早い段階でユーザーの反応を確かめながら企画を進めていくことができます。もしKPIや予想していなかった部分でマイナスに左右する場合、その時点で企画を再考することも可能で、リスクを最小限に抑えることができます。

例えばPC版で反応が良ければスマートフォン版で、一部のページで反応が良ければ別のページにも施策を適応する、まずはデザインを改修してから機能改修をするなど。

改善を焦り一気に大きく改修するような企画はせず、必ずステップを刻み、ユーザーの反応を見ながら実行すべきです。

特に先ほど紹介したCVに直結するページの改修は、必ずリーンに実行すべし！（経験者は語る……）

企画進行のコツ(3) 企画進行では関係者をかならず巻き込む

企画を進める際は、社内メンバーの巻き込み方も工夫すべしです。必要であれば個別に、またはミーティングを開き、企画、デザイン、ステージングとリリースまでのそれぞれの段階で小刻みに進捗を共有し、さまざまな意見を聞き、ブラッシュアップをより重ねるべきです。

特にKPIへの寄与が大きい企画は、かならずCS（カスタマーサポート）のメンバーなど、ユーザー知見のある社内メンバーにまずは意見を聞いてみましょう。

またその改修するページや機能変更の影響を受ける関係者や部署の意見も事前に聞いておくと、企画のブラッシュアップはもちろん、改修に伴う混乱を最小限に抑えることも可能です。

企画者・ディレクターは独りよがりにならず、いろいろな人と積極的に関わるスタンスをまずは持つべきです。

企画進行のコツ(4) 有識者やユーザーへのヒアリングも

大規模な機能改修やCVに直結するページ改修の際は、社内メンバーだけでなく、できれば外部の有識者やユーザーへのヒアリングも実施すべき。

当初想定していた仮説と、ユーザーのニーズにすれ違いが生じる可能性を少しでも減らすために、ユーザーへのヒアリングをしていくと良いです（プロジェクトに当てられた時間や予算にもよりますが）。

また外部の知見ある有識者や、自社サービスより一歩先を行くサービスの運営者（別業界で……！）の意見も聞く機会を設け、企画のブラッシュアップをしましょう。

企画進行のコツ(5) 企画段階で細部の仕様を詰めるべし

企画する際は、大きな改修の方向性などに目を奪われがちですが、企画の細部についても必ず事前に考え抜き、デザイナーやエンジニアとすり合わせをしておきましょう。

例えば以下のような項目です。

開発している段階や、リリース直前のタイミングで、この仕様だと実現できないなどなると、関係者がみんな不幸なことになります。またデザインや仕様を途中で調整しまくると、デザイナーや開発陣にも不満が溜まり、チーム全体のモチベーションが低下してしまうことも。

事前に全ての要素を企画段階でヌケモレなく考え抜くのは、知見と経験がものをいうので難しいとことですが、出来る限りここもしっかり考え抜いておくべきです。

企画進行のコツ(6) 振り返るタイミング、撤退基準を持つ

時に施策で想定通りの数値にいかない、もしくは大きく下回る場合もあります。冷静に状況を分析・把握し、企画や開発の工数に関わらず差し戻すという選択肢も常に持つべきです。

そのためにも事前に施策を振り返るタイミングや、撤退する基準、また撤退した後別の企画を追加で打つ場合はその進め方も事前に考え、関係者と意思共有しておくと色々とスムーズに物事が進みます。

引くことも選択肢の1つとして、手札に持っておきましょう。

企画は一筋縄ではいかない…

ここまでWebサービスやアプリの改善施策を企画する際に、抑えておくべき立案ステップや、企画を進行する際の心構えを、個人の見解を交えてまとめてみました。

企画と一言で言っても考える領域はかなり広い上に、企画する対象や、企画者によっても方法は異なるでしょう。なかなか方法論を確立するのは難しいところです。ですがベースとなる要素などはだいたい同じような気もします。

よりよい企画・ディレクション方法について日々経験を重ねながら試行錯誤しているので、また随時ブラッシュアップしていければと思っています。

最後までお読みいただきありがとうございました。

UXを踏まえた企画やユーザーインタビューについては、下記記事も参考にしてみてください↓↓

関連記事【THE GUILD勉強会レポ】ユーザーインタビュー設計ノウハウについて@DMM

2019.03.31

こんにちはやすのり（@98nasi_nori）です。現在都内で留学系ベンチャー企業にて、ディレクターとして働いている社会人2年目です。

先日診断系（マッチング）コンテンツを企画、ディレクションする機会がありました。企画からデザイン、開発、デバックや改修など含め、リリースまでトータル3ヶ月ほどかかりました。

この様な機能を企画・ディレクションするのは今回が初めてで、自分の企画の詰めの甘さが如実に現れた苦い経験となりました。特に企画段階での挙動の仕様の詰めが甘く、開発の部分で想定した以上に工数がかかってしまいました。

色々と苦労の連続でしたが、学ぶことはとても多かったので、実際の企画・制作のフローや考えたこと、企画時の注意点などをざっくり備忘録としてまとめてみました。あくまでのメモ程度ですが、参考にしていただけますと幸いです。

どんな診断系コンテンツを企画したのか？

Photo by : https://schoolwith.me/matchings

今回僕が企画したのは、ユーザーが留学先として自分にピッタリな国や都市を診断できるというコンテンツです。

URL : オススメの国・都市診断

本機能では、留学主要8ヵ国（アメリカ、カナダ、フィリピンなど）の中から、ユーザーの志向にマッチする国を診断できる機能と、各国ごとにマッチする都市を診断できる2つの機能に分かれています。

Photo by : https://schoolwith.me/matchings

AとBの2択問題を「国診断」は計20問、「都市診断」では最大15問解答していくことで、マッチング結果を集計。結果画面では、マッチ度の高い上位3つの国や都市を確認することができます。

Photo by : https://schoolwith.me/matchings

またどれくらいユーザーとマッチしているかは、パーセント表示で確認できるほか、オススメされる理由なども合わせてコメントで表示されます。

サービス本体の拡大に伴い、掲載する留学先の国や都市の選択肢を拡大してきた一方で、どこの国や都市が自分自身に合っているのかわからないという悩みを抱えるユーザーが多くいました。そうしたユーザーの声を受けて、今回の機能の企画に踏み切りました。

診断機能の企画までのステップ

今回の診断機能を企画するに辺り、どのようなステップを踏んでいったのか、簡単に振り返ってみたいと思います。

(1) 企画の方向性を整理

今回の診断機能をリリースするに辺り、企画の背景や意図、ターゲット、目標とKPIの設定、対象国と都市、機能の導線、ユーザーのフロー、プロジェクト全体の工数など、企画の方向性をさくっと整理していきました。

(2) 類似サービスのリサーチ

他社の診断系コンテンツを、ジャンル問わずとにかく使ってみました。留学関係はもちろん、性格診断から恋愛、転職、またスマフォアプリやSNS、Webなど、様々な診断コンテンツを使ってみて、機能や診断の流れ、UIイメージを膨らませていきました。

参考にですが、こちらのサイトが色々な診断コンテンツの事例をまとめていて面白かったです。
VONVON

(3) 機能・仕様を具体的に固めていく

リサーチ結果をもとに、企画内容をより具体的にしていきます。診断コンテンツによるゴールの実現や今後の拡張性などを踏まえて、マッチング機能の仕様や方向性を具体的に詰めていきました。例えば以下のような項目です。

またマッチングの結果が特定のものに偏らないようするにはどうするか、結果が同列の場合はどうするか、などの想定される懸念点やその対処法などもイメージしておきました。

ある程度僕の中で機能が固まった段階で、エンジニアやデザイナーの方も交え、実装における実現の可否や、ユーザビリティにおける懸念点など、様々なアイディアを出し合い、機能を更にブラッシュアップしていきました。

(4) プロトタイピングの作成

上記の仕様を元に、PhotoshopとInvisionを用いて簡単なプロトタイプを作成し、実際に社内のメンバーの方に使ってもらいました。そこからのフィードバックを踏まえて更に機能をブラッシュアップしていきます。

(5) 仕様書の作成とスケジュールの策定

機能が固まった段階で、仕様書を作成していきます。マッチング全体の分岐フローを、遷移図を作成しディレクトリごとにまとめていきました。

診断TOP画面、質問画面、回答結果画面などのページごと、またPCとSPなどデバイスごとの仕様も詳細にまとめていきます。

また再度サイト内における診断コンテンツの導線位置や、バナーの訴求文言、リリース後の計測も考慮して導線ごとのパラメータ、診断結果のシェア機能の仕様も合わせて整理していきます。

これらの仕様を踏まえ、再度デザイナー、エンジニアの方を交えてデザインや開発工数を算出、リリースまでの全体スケジュールを詳細に洗い出し整理しました。

(6) 点数調整

デザインの制作を進めつつ、同時に各項目ごとに、選択肢が選ばれた場合の点数をどの様に付与するのか、国ごと、都市ごとに専門の留学カウンセラーのアドバイスを元に調整していきました。

また算出した点数に基づき、実際に診断してみて点数に偏りがないか、想定される結果になっているのか検証していきます。

かなりの数の項目があったことに加え、項目ごとの部分の最適化と、診断結果全体の最適化を同時に達成する必要があり、想像以上に難航、時間を要しました。ずっと数値とにらめっこすることになり、正直かなり辛かったですね・・。

この点数次第で診断コンテンツの結果が大きく変動し、ユーザーの満足度・納得度に直結する部分ですので、かなり気合を入れて検証すべしです。

またある程度僕の方で点数の調整を終えた後に、エンジニアの方に質問文と回答結果を算出できるデザイン抜きのプロトタイプを実装してもらいました。それを社内のメンバーにも使ってもらい、ある程度の回答パターンを算出、さらに精度を高めるべくブラッシュアップしてきました。

(7) テキストの精査

点数調整と同時に、タイトルやディスクリプション、質問文やヒント文、結果時の文言など、テキストを具体的に精査していきました。

(8) 実装へ

点数や文言などの調整が完了した時点で、デザインも完了。ついにフロント・バックエンドの実装へ踏み切りました。

企画時の注意点や反省点

今回診断機能を実装するに当たって悩んだ点、反省点を簡単にまとめます。

どこまで点数算出のロジックを調整するか

これはなかなか難しかったのですが、点数算出ロジックの調整をどこまでするのか、と言う線引もなかなか難しかったです。

今回は質問ごとにカテゴリを設け、結果画面ではカテゴリごとのマッチ度も算出する仕様なのですが、そのカテゴリごとの％に偏りがでる場合がありました（マッチ度100%や10%など極端に低いもの）。そうした場合、極端な数値が出ないようにロジックの微調整していきましたが、あまりにやりすぎると本来の点数から離れ、実態を歪めてしまうことがありました。

変数の多い回答次第ではどうしても点数調整をしていく必要が出てくるかと思いますが、そのロジックで本来の目的をユーザーが達成できるのか、改めて立ち帰り、ロジックを組み直すことを忘れないでいるべきです。

リリース後のバグチェックは必ず抜けもれなく、確認すべし

これは本当に当たり前なのですが、機能のリリース後は必ずバグがないか入念に全てチェックしましょう！

今回はリリース時に、SP版の特定の国を選択した場合に結果が表示されていなかったり、ログインした上で結果ページから選択肢のページに戻った場合、回答結果が表示されなくなるエラーなどが発生したり、諸々の対応に追われました。

またOGイメージがリリース直後設定していなかったという確認漏れもあり、自分の詰めの甘さに気付かされました。サービスのリリース時には、バグのチェックリストを事前に作成し確認を怠らないこと、また必ずリリース直後だけではなく定期的に確認していくことも重要です。

新規の機能だけでなく、影響がありそうな機能や、サービスの重要な機能も含めて、周辺の領域にバグが発生していないかも徹底的に確認しましょう。

企画の段階で、ありとあらゆるユーザーの行動を想定しておくべし

またそもそもですが、企画の段階でありとあらゆるユーザーの行動を想定し、その時の挙動などの仕様も細かく固めておきましょう。ユーザー行動パターンを洗い出しておくことで、ある程度バグやミスなどの発生を最小限に抑えることができ、かつバグの発生時にも迅速に気づき対処できるはずです。今回はこのあたりの洗い出しの詰めが甘かったこともかなりの反省点です。

いかがでしたか。このような診断系の機能・コンテンツを企画するのは今回が初めてで、全くノウハウがない中で自分なりに試行錯誤しながら進めていきました。思った以上に全体の設計をすることが難しく、また失敗も重ねながらなんとか企画をカタチにし、リリースをすることができました。本当に多くの学びがありました。今後は診断対象の範囲を広げるとともに、より精度を高め、また導線の最適化を進めていきたいと思っています。

最後までご覧いただきありがとうございました！