フロントエンドエンジニアが体験した新規プロダクト開発の難しさと面白さ
こんにちは、フロントエンドエンジニアの金城です。ウェルスナビに入社して半年が過ぎました。
新規プロジェクトに参加した私は、開発に必要な情報がほぼ整っていない状態からのスタートに直面しました。前職までは受託開発で基本設計以降の開発経験をしてきた自分にとってまさにゼロからの挑戦。
本記事では、この状況からどのように整理し開発を進めていったのかをお話します。
プロジェクト初期フェーズのため仕様書なし、画面一覧なしからの開発スタート
アサインされた新規プロジェクトに気合を入れてキックオフミーティングに参加する私。そして知った現状が見出しの通りです。
私がメインとして行うのはフロントエンド開発であるのは間違いないのですが、そもそも開発に取り掛かれる材料が何もないという状況でした。
これは新規事業を立ち上げるのである意味当たり前かもしれないのですが、これまで実装フェーズの開発経験しかなかった自分にとってはかなり戸惑いがある状態からのスタートでした。
ある材料からやることを整理していく
どんな画面か、作る画面数も分からないのでスケジュールも立てられず、何人のエンジニアをアサインすれば良いかもわからない、という状態でしたのでフロントエンド開発に入るためにはまず何が必要か、ということの整理から着手しました。
フロントエンド開発を始めるのに必要なのは
- 画面一覧(サイトマップ)
- フロントエンド開発のスケジュール
- 画面仕様書
- 技術選定
となります。
そして今ある材料は
- ワイヤーフレーム
- プロジェクト全体のスケジュール
- フロントエンド側でもつ機能
です。
これらの材料を元にして以下の筋書きで進めていくこととしました。
- 画面一覧を作る
- 画面ごとに係る工数を割り出す
- 工数をもとにスケジュールを引く
- 技術選定を行う
- 環境構築&開発開始
画面一覧の作成
まず着手したのが画面一覧を作成することでした。
起こされているワイヤーフレームをもとに画面をスプレッドシートに一覧化し、各画面ごとにかかりそうな工数を割り出します。
細かい仕様が決まっていない状態なのでここでの精度は求めず、まずは出すことを目標で進めます。
スケジュールの作成
作る画面と工数さえわかればそれを元にスケジュールを引けます。
ここでは画面数に換算できない不確定要素、例えば環境構築や設計、認証まわりなどもスケジュールに入れ、さらにバッファも積みます。
画面仕様書の作成
画面仕様書については以下のことを念頭に作成しました。
- 作成時の仕様の抜け漏れは許容し最低限の開発が行える精度とし、後から決まった仕様は随時更新していく
- 仕様書を作成することにより仕様の把握が進むため、作成はメンバー間で分担する
- 最終的には数年後の誰かが運用した時に画面の仕様で迷わないことを目指す
技術選定
技術選定についてはエンジニアに裁量があるので、個人的にはこれが一番楽しいところです。
とはいえプロダクト全体のことを考えて決める必要があるため以下のことに念頭に選定しました。
- 他プロジェクトとの兼ね合い
- メンバーの技術スタックにフィットしているか
- ライブラリの開発体制・成熟度
- プロダクトの求める要件にフィットしているか
具体的に選定した技術についても書きたいのですが、それだけで一記事書けてしまいそうなのでそれはまた別の機会にしようと思います。
コミュニケーションの壁
さて、画面一覧を作るにもワイヤーフレームを読み解いたり、スケジュールを引くにも優先度を決めたりしなくてはなりません。
いずれも自分一人で解決できるものではなく、不明点などはプロジェクトメンバーに確認する必要があります。ここで問題となるのがコミュニケーションの壁です。
部署を跨いだ横断チームということもあり、まともに話したことがないメンバーばかりで正直なところかなり不安でしたが、以下の2点でかなり解消されたと感じています。
- 担当領域に絞ったSlackチャンネルが立ち上がり、必要最小限のメンバー間でやり取りが可能
プロジェクト全体のチャンネルでやり取りするのはかなりハードルが高いと感じているのでこれは良かった - 上記のSlackチャンネルメンバーで週2回の定例MTGがある
ウェルスナビは週3出社のため、Slack上のやり取りだけではなく直接話す機会があるというのもメンバー間のコミュニケーションがしやすくなって心理的なハードルを下げることができていると感じています。
余談ですが、親睦を深めようと思い切ってランチ会を主催したのですが当日主催者の自分が体調不良で欠席する羽目になってしまいました。。参加メンバーの交流は深められたので良かったのですがいずれリベンジしたいです。
終わりに
ここまでやって見えてきたことは、
- スケジュールや工数は、精度は粗くても無いよりはあったほうが話が先に進む
- 話が進むと周りが少しずつ動いて少しずつ輪郭が見えてくる
プロジェクト参加当初は戸惑いの連続でしたが、この繰り返しで少しずつ形になっていってると感じています。
開発はまだ始まったばかりですが、自社プロダクトの仕様を固めるフェーズからプロジェクトに関われたことは、私が事業会社に入った目的の一つでもあるので良い経験を積ませてもらってます。今後は、よりスムーズに開発を進めるための仕組み作りや、より良いプロダクトになるためのユーザー体験を高めることにも挑戦していきたいと考えています。
Discussion