こんにちは、株式会社SCOUTERの石岡 将明( @masaakikunsan )です。
現在、弊社では back check という新規事業の立ち上げを行っています。
この記事では、その新規事業を最速で立ち上げるために僕が行ったフロントエンド開発のノウハウを書いていきたいと思います。 あと、PMとしてどうしたかみたいなことも少し書けたらなと。
新規プロダクトで求められること
具体的なノウハウを話す前に、新規プロダクトで求められることを整理します。
バグが少ないこと
これは、新規プロダクトに限った話しではありませんが、新規プロダクトはまだコアファンもおらず、致命的なバグや小さなバグの積み重ねで顧客が離れていきます。
そして、スピードは保ったまま進めたいのでバグが少ない方が良いでしょう。
少人数で仮設検証を回すこと
まだ儲かるかどうかもわからないので、経営者からしたら新規プロダクトは投資になります。 ですので、ここではなるべく人件費をかけずに少人数で仮説検証をしていきこのプロダクトはいけると判断できるラインにすばやくもっていく必要があります。
少人数で進めるのは人件費の面だけではなく、意思決定フローが楽になるというメリットもあります。
最速でのコア機能の開発
これは、仮設検証にも含まれますが、コア機能を早く作ってユーザーに触ってもらう必要があります。 当たり前ではありますが、コア機能ができあがらないといつまで立ってもリリースはできません。 なにかをリリースするということを当たり前に考えているエンジニアは多いですが、実はリリースは当たり前のことではありません。出戻りなどでいつまで立ってもリリースができなかったり、コア機能が定まらずあれもこれも必要と開発に時間がかかったりなど様々な理由でリリースができなかったということがあります。 なので、新規プロダクトにアサインされたPMは正しくコア機能を定めスケジュールを組む必要があります。
新規プロダクトあるある
次に新規プロダクトあるあるを話します。 これらは最速で進める上で割とある大きな壁にです。これらを認識して進めているかどうかではスピードもメンタル的にも全然違います。
度重なるデザインの変更
これは、経営者次第ではありますが、デザインの変更は割とよくある話しです。 これを仕方ないこととして受け入れるか、いやいやその差し込みはおかしいとデザイン変更を後回しにするかどうかはPM次第ですが、僕は基本的に意味のあるデザインの変更は受け入れるようにしています。(さすがにイケてないとかそういうよくわからないやつは対応しません)
仕様変更の可能性大
仕様変更は開発を進めているとどうしても起こる可能性があります。 画面を触ったらこうした方がいいなど、事前に防げそうな問題から経営上の都合など理由は様々ですが割とあるあるです。
ここまでを踏まえ、爆速で進めないといけないが手が止まる要因があるのはわかっていただけたかなと思います。 新規プロダクトにおいて愚直に作っていたら時間がいくら合っても正直足りません。
では、どうすれば良いのか。 作り直す前提で捨てやすく運用のしやすいコードで開発をする必要があります。
作り直す前提で開発を進めるためのコツ
ディレクトリ構成をしっかりと考える
ディレクトリ構成は開発のキモになってくるのでしっかりと設計しましょう。 ここで事故るとどんどん開発がしづらくコードを読むのも大変になっていきます。
back check では Nuxt.js を使っているので大枠のディレクト構成は Nuxt.js にまかせて、細かいところだけルール化しました。
カラーは変数で定義する
カラーは一箇所で管理したら楽なのと、無駄なカラーが増えることを防げます。 デザイナーには始めにカラースキームを定義してもらい、それを scss ではじめに定義します。
back check では、src/assets/config 配下に colorの変数用のファイルを作成し、nuxt-sass-resources-loader を利用しどこからでも定義した変数を使えるようにしています。
Component はなるべく最小単位で作成する
Component を最小単位で作成すると言うと、すぐ Atomic Design でやるぞってなりがちですが、Atomic Design は気をつけてほしい点がいくつかあります。
- デザイナーがちゃんと Atomic Design を意識してデザインをしている
- Component 設計のレベル感がチームであまり変わらない。
これらの前提がない場合は Atomic Design の導入はやめたほうが良いでしょう。 あと、Atomic Design のルールに沿ってしまうと作り直しがめんどくさくなる背景もあります。 では、どうやって Component の粒度を揃えるのか？幸い、back check チームではあまり Component 設計のレベル感が変わらなかったので気になるところはPRで指摘するぐらいで良かったので個人に任せています。
実装を進め共通処理がでてきたら Mixins 化する
Mixins 化も安易にやっていくと気づいたらカオスになっていたというのがあるので、なるべく Mixins 化をしないようにはしていますが、確実にこの処理は共通で今後も使っていくのが見えたら Mixins 化しています。 back check では form 周りが結構同じような処理だったので抽象化してから Mixins 化しています。
同じ Style はまとめて外に出す
Vue.js / Nuxt.js では Scoped CSS によって CSS を気軽に閉じ込められるので結構 Style がカオスになっている現場が多いです。
同じ Style がでてきたら src/assets/ 配下にscssファイルとして追い出し、必要なところで import するようにし page/component で書く Style をなるべくそこに必要なものだけにするほうが良いでしょう。
再利用性を考えるのは最低限
Component 指向での開発が当たり前になってから、再利用性の高い Component 設計を求められがちです。 もちろん大事なのはそうなのですが、新規プロダクトにおいてここに時間をかけるのはデメリットのほうがでかいです。 理由は単純にどうせ使い回さないからです。他にもあるのですが、とりあえず再利用性を考えるのは最低限にしときましょう。
これらを実行すると割と作り直しがしやすいプロジェクトができます。 back check チームでは、3度のデザインリニューアルと3種類のユーザー画面を二ヶ月でほぼ作りきりました。
最後に、PM として取り組んだことを書いていきます。
チームが開発しやすい環境作り
back check チームでは、週１でMTGを開きそこで歪があがったらその歪を解決するためのルール(仕組み)を作っています。 今後 Join されるメンバーのためのドキュメント作成や、命名のルールなど様々な仕組みを作りました。 なるべくメンバーには自分の思ったことを発散してもらうようにしており、それが必要だと判断したら解決し、なるべくストレスフリーでできるように進めています。
爆速で開発するために作り直しやすいコードで開発するのも大事ですが、そのためにはメンバーがやりやすい環境を作ってあげることが大事なので back check チームでは DX を上げるためにできる限りのことはしてあげようと思っています。
まとめ
- 新規プロダクトはスピード感を求められるが、不確定要素が多い
- 不確定要素に振り回されないために作り直しやすく作っていく必要がある
- 最速でかつ良いものを作るにはチームメンバーが健常がどうかに目を向ける
ここまで色々と紹介しましたが、これはあくまで新規プロダクトにおける話しです。(新機能開発でも割と当てはまる部分はある)
フェーズが変わったらもちろんこの辺も変わるのを忘れないでください。
最後に
現在、株式会社SCOUTERでは、エンジニア、デザイナーの募集をしております。
興味のある方は、是非下記からご応募お願い致します！
