エンジニアが企画開発をやってみた - ドワンゴ教育サービス開発者ブログ

こんにちは。　N予備校の開発チームではこの4月に企画開発チームが発足しました。

この記事では、N予備校での企画開発の紹介と、でN予備校の企画開発エンジニアって何してるの？　という1つの例として、私自身がN予備校の企画に関わってきた中での気づきなどをお伝えします！

目次
N予備校の企画開発
次世代N予備校の企画の進め方
企画者としてここ1年で発想を変えたこと　「ユーザー目線で考える」
エンジニアが企画をやる中で意識したこと　「簡易なプロトタイプを作って企画に生かす」
エンジニア && 企画者として考える「小さく作ってリリースして、どんどん良くしていく」という開発
企画開発していこう！
We are hiring!

N予備校の企画開発

N予備校は6年前のサービスリリース時からN高等学校/S高等学校を支えるサービスとして展開してきました。リリースしてからはN高等学校の単位認定授業をN予備校に取り込むプロジェクトをはじめとした「学校運営に必要なもの」の機能を明らかにすることを主軸に、機能を拡張し続けてきました。

学校運営を支える部分はもちろん今後もしっかりやっていきます。N高等学校/S高等学校全体の規模も拡大してきた中で、学習方法のトレンドを取り込んだり、私たちから新しい教育への提案をしていく比重をあげていきたいと考えています。

その中で「次世代N予備校プロジェクト」という、学力の向上を目的としたプロジェクトに昨年から取り掛かっています。私たちにとっては新規の挑戦になる企画も含むという性質もあり、今までの開発プロセスではあまり明示的にとられていなかった「企画・技術検証」に取り組んでいます。

では実際にここまで何をしたか、これから何をしていくかを説明します。

次世代N予備校の企画の進め方

まず初めに、簡単に私のバックグラウンドを記載します。私は元々バックエンド開発チームの一員で、過去には N予備校のマイクロサービスについても書かせていただきました。N予備校の開発チームとしては、途中産休・育休で抜けた期間はありますが、5年ほど参加しています。昨年から、バックエンドの業務も行いつつ、メインタスクとしては次世代N予備校の企画・技術検証に関わってきました。

具体的に私がやってきたことはざっくりですが以下のようなことです。

アプリ全体で与えたい体験や企画自体のビジョンをまとめる
新規に導入したい技術(IRTなど)の技術検証
企画に対して本番データを解析して確度を高める

新チームの発足やフェーズが技術検証から開発に動き始めた企画などもあり、私個人の作業は変わりますが、チームとしては上記のことをより深くやっていくことになると考えています。

企画者としてここ1年で発想を変えたこと　「ユーザー目線で考える」

エンジニアだからか…私個人の気質のような気もしますが、企画をやってきて発想を変えたこと（変えなければと思っていること）を記載します。

次世代N予備校の企画はTHE GUILDの深津貴之さんからレビューをいただきながら進めています。その中で何度も指摘していただいていることでもあるのですが、ユーザー目線から考えるという発想を持っていこうということです。

つい「こういう機能」「こういうデータを扱う」から入ってしまうので、一般的な企画のフェーズで用いられているフレームワークを使うことで自分の思考を整理し、ユーザー目線の発想を取り込んでいます。例えば、カスタマージャーニーマップを利用してユーザーの気持ちの上がり下がりから機能の洗い出しや優先度付けを行ったり、サービスブループリントで現状使っているツールとユーザー行動を整理したりしています。

エンジニアが企画をやる中で意識したこと　「簡易なプロトタイプを作って企画に生かす」

逆に、私が企画にコミットしてきた中で、エンジニアの知見を活かそうと意識して行ったことを記載します。

一番大きなものは、簡易なプロトタイプを作ることで、企画・開発両方へのインプットを増やすことを意識しました。

いくつかプロトタイプを作成した中で、1つはRuby on Railsで簡易なWebアプリケーションとして実現しました。規模としては数日で作った壊す前提のプロトタイプです。

動くものを作ることや技術検証した結果を見られることで企画イメージを固めるためのインプットになることを狙って作ったものでした。しかし実際には、簡易すぎてイメージが固まりづらく、企画に直結という成果は得られませんでした。

Ruby on Railsのscaffoldほぼそのまま、テキストベースの画面遷移レベルであればいくらデータが揃っていてもユーザー体験へのインプットにはなりづらかったです。このケースであればデザイナーメンバーがFigmaで作ったデザインプロトの方が適していました。もしくはフロントエンドの技術を磨いてガッツリ作っていく方法もありですね…！

別のプロトタイプですが、データからという意味ではWebアプリケーション化せずともGoogle Data Portalで現状のデータからユーザーに出せる表示を簡易的に作ったものもあります。こちらの方が企画のインプットに繋がるケースもありました。

とはいえミニWebアプリプロトの方も、形にすることで技術検証の引き継ぎには役に立ちました。技術検証したデータ自体がプロトタイプ上に残ることで、技術検証メンバーが増えたときにプロトタイプをベースに次の検証に取り掛かることができ、その後の議論のしやすさ繋がりました。

開発へのインプットとしては、データ構造やテーブル設計を本番に向けて意識して試行しました。例えば学習をする上での「問題」の性質を洗い出しそれをどう持つかなど、プロトタイプではカラム定義やそもそもの持ち方から試行錯誤しながら定義しています。

エンジニア && 企画者として考える「小さく作ってリリースして、どんどん良くしていく」という開発

最後に、エンジニアと企画者という両方の目線から大事にしたい考えを記載します。

先に述べましたが、今までN予備校の開発というのは「学校運営に必要なもの」を作っていくのが主でした。リリース時期は必達、欲しいものも明確で基本的に1つの案件はウォーターフォールのように行われていました。

しかし、私たちから新しい教育を提案していく中で今までと大きく違うのが、誰も仕様を知らないものを作っていきたいと考えているということです。

そこで必要なのが 「ユーザーに価値あるものを小さく作ってリリースして、どんどん良くしていく」という開発です。これはMinimum Value Product (Earliest Testable Product) と呼ばれている発想です。小さくてもユーザーに価値のあるものを出し、ユーザーの声を聞いて次の企画に反映していくことで、私たちがこのサービスを通じて提供したいと思っているものに近づけていくことができるのではという考えです。

企画中はどうしても理想の形を追求しがちです。ですが、「小さく作って小さく出す」ことの重要性は、企画検討で頭を悩ませ…結局答えが出ず…その中で出したことも周囲の納得感は得られず…また戻り…というプロセスの中でも痛感しています。

ユーザーが真に欲しいものはわかりません。「初手は小さいけれどユーザーに価値あるものを出す」「データから得られることを整理し、次の企画に活かす」という循環を作っていくことで、プロダクトに関わる人たちの納得感も作っていけるのではと考えています。

そしてこの考えの実現において、エンジニアが企画をやっていることで、企画と開発両方の観点からの「小さく作る」ために必要なことが短いサイクルで回るのではと考えています。というのも開発目線の「裏側はこういう要素なら作りやすそうとかあたりをつけられる」ことと企画目線の「企画はここまでなら小さくできるというあたりをつけられる」ということを合流させやすいためです。

ただし、この「小さく作って小さく出す、それをどんどん改善していく」ことは開発体制として非常に難しいというのも痛感しています。開発の人員計画を立てる上で、「この企画の改善に1人」と考えたとき、そのメンバーがプロダクトの多機能（バックエンドで言えば、多くのマイクロサービス）に熟知していなければ開発が成り立ちません。そういうメンバーは少なく、かつ他の大きな案件も動いている中でこういう「遊撃隊」に当てられる体制はまだできていません。これには、開発チーム内で育てていく体制づくりが必要だと考えています。