私たちのフロントプロジェクトの進めかた

ユーザー課題からプロトタイプのテストまで

たとえば、あるオンラインスクールのWEBアプリを改善したいというプロジェクトが走っているとします。

プロジェクトにアサインされたら、まずはステークホルダーやプロジェクトに関わるみなさんと、このアプリのユーザーにとって、いま「課題」なっているものはなんだっけ？という会話をします。いわゆるユーザー調査ですね。

一般的には、ここで時間をかけて、ペルソナやカスタマージャーニーマップを、きれいなドキュメントとしてまとめることもあるのですが、わたしたちはこれはやりません。

かわりに、wikiなど、プロジェクトメンバーみんなが見られる場所へ、箇条書きで「こんな人が、ここで困っているよね？」「こういうタイプのユーザーだと、ムービーのところで離脱するんじゃない？」という「考察」を書き込みます。

さらに、この考察をある程度分類化します。そのうえで、分類をもとにユーザーの課題を解消するアイデアはなになのか？をシャープにしていきます。ちなみに「それってそもそもマーケット課題だからこのプロジェクトでどうこうできるはないでないよね？」みたいな、高コスト＆影響の薄い課題はこの時点で削ぎ落として、無駄なことに時間をつかわないことを徹底して進めます（とはいえ、、、こういう課題にハマってしまって、時間を無駄にしたねー、ってことは、多々あるのですが、そのときは素直に反省）。

シャープなアイデアがある程度出揃ったら、ここからは、プロトタイプの作成です。
プロトタイプと言ってもそんなにカッチリしたものではなく、スピーディに出来上がりが想像できるくらいのものを作って、社内のユーザーとなりそうそうな人に見てもう（評価してもらう）。このときAdobeXD、figmaなどのデザインツールを使うことが多いですが、時間のないときは、それこそスケッチブックに手書き、みたいな場合もあります。

ここでのフィードバックをもとに、さらにアイデアを磨いて、本当に受け入れられる確率の高いUIと機能の実装に進む。まず、デザインフェーズは、そんな進め方になります。

さて、実装だ！

こんな進めかたで、ユーザーの本当にほしかった機能／UIがみえてきたら、すかさず実装です。
とはいっても、デザインチームがプロトタイプを作っているタイミングから、エンジニアチームは技術選定や環境構築などは進めています。なので、機能が絞れたり、優先順位がついたころにはNuxtでいくか？Nextでいくか？ 環境はどうする？？みたいな話は、SRE（Site Reliability Engineering）さんや、BFF（Backends For Frontends）の担当者の方とは会話済みになることが多いです。

私たちは、多くの案件でバックエンドを担当するSIerさんと協業しているのですが、プロトタイプのタイミングから「フロントではどんな仕様のAPIがあるとスムーズに実装できるか？」などを提案させてもらうことがほとんどです。こうすることによって、バックエンドの構築も比較的スピーディーにできるので、両者にとって嬉しい進め方になります。

たまには、大規模にバックエンドを用意するのではなく、CaaS（CMS as a Service）や、PaaS（Platform as a Service）型のHeadlessCMSを利用して、フロントチーム自らAPIを用意。さらに安価にスピーディにプロジェクトを進めることもあります。

つまり、いずれの場合のAPIファースト。プロトタイプからAPIの項目を想像して、バックエンドから切り離された、つまり柔軟に変更できるフロントエンドを構築していきます。

開発段階に入ると、プロジェクトの管理は「カンバン方式」。基本的にはgithubを使い、課題をつくって、それを実装、プルリクエストを投げてレビュー、マージして検証環境で動作確認して、課題をクローズ。こんなプロジェクトの進め方になります。

リリース、QA、保守対応まで、カンバン方式でヤー。

実装がスムーズに進むと、リリース直前のフェーズに入りますね。大規模な新規サービスとなると、各社のQAエンジニアさんとも協力します。QAエンジニアさんが、リリース前の動作確認をしてくれて、そこでバグが出れば、原因を切り分けて課題として登録。開発時と同じようにカンバン方式で、ひとつずつ、バグ、考慮漏れ、仕様漏れをツブしていきます。

このスタイルはリリース後の保守フェーズでも継続します。バグがあれば、それをカンバン方式で素早く潰していく。機能追加の要望があれば、その機能が本当にユーザーに受け入れられるのかを、検証して素早く実装しています

つまり、ここまで説明してきたスタイルを、リリース後もグルグルとまわすことによって、よりユーザーに受け入れられるWEBサービスをを作り続けていくとに貢献していけるのです

ちょっと話は変わります。こういったスタイルなので、基本的には準委任契約で仕事をさせてもらっています。請負契約で仕事をしないこともないのですが。。。あらかじめシッカリ仕様が決まっていて、そのとおりに作ればうまくいく、というようなプロジェクトはあまりなく。。。

もちろん、ある程度のスケジュール、予算は意識した上で仕事はすすめるものの、クライアントと一緒になって、課題を発見、解消していくということになると、人月単価を頂いた上で柔軟にアイデア出し、実装チャレンジのできる「準委任契約」でプロジェクトに並走していくほうが、うまくいく確率が非常にたかいなーと思っています。
少人数でクライアントである企画の人も、パートナーであるバックエンドのエンジニアの人も、みんなで「スクワッド」をつくって進めていきたいのです。

ということで、こういった進め方に興味のあるかたは、ぜひ、お声がけください。