フリーランスエンジニアの話

エンジニアとして日々感じてることを綴っています

大規模プロジェクトの進め方

フロントエンドエンジニアとして大規模プロジェクトをいかにスムーズに進めるかについてお話しします。

 

大規模プロジェクトとは

定義は僕の勝手なものですが、開発に2ヶ月以上かかるものは大規模プロジェクトと呼んでます。

プロジェクトというか機能と言ってもいいですね。

一つの機能を実装するのに2ヶ月かかることはよくあります。アプリの中のミニアプリという感じで、結構複雑なものもあります。

これがどういう風に始まるのかというと、まずざっくりした要件がPMから伝えられて、デザイナーにFigmaを共有してもらいます。そこからキックオフのMTGがあったりなかったりしますが、それでよーいどんです。仕様書はないことがほとんどなので、ない前提で考えます。

 

他メンバーとの連携

フロントエンドエンジニアは主にPMとデザイナーとバックエンドエンジニアの3人と連携を取ります。仕様の話はPMに、デザインの話はデザイナーに、APIの話はバックエンドエンジニアとします。

仮に一つのプロジェクトで、3人それぞれに100回質問をしなければいけないとします。プロジェクト成功のコツはこの100回の質問をいかに早くすることです。

というのも、質問するということは、分からないことがあって、その回答が来ないと先に進めないという状況です。特にフロントエンドはデザインとAPI両方に依存してます。デザインとAPIは仕様にしか依存していないのですが、フロントエンドはそれらが完成しないと進めないんです。

内容によってはすぐ返信が返ってきてそこまで大きな変更がないものもありますが、ものによっては大きく仕様の変更が発生しそのデザインを作ったり、APIの場合は開発に数日要したりします。他のメンバーの対応に時間がかかれば、それだけ自分が着手出来るタイミングが遅くなります。

 

不明点の洗い出し

厄介なのは、多くの場合デザインとAPIが未完成の段階でフロントエンドの開発を着手しなければならないことです。デザインが全くない状態でスタートはさすがにないですが、7割くらいしか完成してなかったり、Figma見ただけだと仕様が不明なところが山程あったりするんですよね。

なのでまず僕がやることは、一番最初に着手出来る画面がどこか探します。そしてその画面について質問があればFigmaにバーっとコメントを書きます。その後、他の画面も一通り見て、そこで気づいたことがあれば全部コメントします。多い時だとこの時点で10個以上あります。

質問が返って来なくても着手できるところはコードを書き始めます。

 

全画面をいち早く網羅する

コードを書く時に注意が幾つかあります。一つ一つの画面を完璧に完成させないことです。プロジェクト成功のコツは質問をいかに早くすることですよね。不明点というのは何も最初の方に着手した画面だけに集中してるわけではありません。Figmaを見ただけで全て不明点を洗い出せれば良いですが、実際に手を動かしてみないと気づかないこともあります。

なので、なるべく早く全画面に手をつけることを意識します。デザイナーに確認する必要のないもので後回しに出来るものはどんどん後回しにします。

スタイルは完全に無視するか、そこそこの見栄えまで作って放置します。トンマナは後からいくらでも変わる可能性があるので、初期の段階でピクセルや色を全部合わせても後で水の泡になる可能性があります。仮にデザインがfixされてたとしても、後回しで問題ないです。

他に後回しにするものは例えばページネーション、検索、並び替え、バリデーションなどです。これらは無くても他の画面まで繋げることが出来ます。例えばフォームのバリデーションがなくても何かを新規作成することは出来ます。

新規作成が出来て表示が出来ると今度は編集や削除に進めます。このように他の画面が依存してるクリティカルな画面を最低限完成させて、一刻も早く次のステージを目指します。

 

後回しにしたタスクを待ち時間に消化する

開発していくと、必ずと言っていいほど待ちの時間が発生します。仕様の確認待ち、デザイン修正待ち、API修正待ちなどです。黙ってボーッと待っていたら当然後でツケが回って来ますから、何かしらやることを見るける必要があります。ここで後回しにしていたタスクが登場するわけです。取っておいたおやつみたいな感覚ですね。待ってる間にそういうタスクをやっつけます。

いかに手戻りを少なくし、無駄な待ち時間を減らすかというのを考えるわけです。そうやって自分の稼働時間を最適化していきます。いつでもやれるタスクというのを複数抱えておくと、質問の回答待ちでイライラしたり相手を催促することなく、余裕を持って待てます。

 

なる早地獄

自分の時間を上手くマネジメント出来ない人は、誰かに何かお願いした時に、期限が短いです。「これなる早で!」、「あれ明日まで!」といった感じです。何でなる早になるかというと、ギリギリまでそれを誰かにお願いしないといけないことに気づいてないからですよね。

タスクをお願いされる方もスケジュールがありますから、なる早は困るわけですよ。

同様にSlackの即レスを期待するのも同じです。すぐ返って来ないと仕事に支障が出るのであればその人のセルフマネジメントが出来てない証拠です。勿論障害など緊急の場合は仕方ないですし、何か一つのトピックがあったらある程度テンポよく返信しないといつまでも話が進みませんが。Slackの話はまたどこかでします。

 

最後に

期間が長いとまだ時間があると思ってだらけがちです。デザインとAPIが完成してから動き出した方が楽なので、余計序盤は動きづらいです。しかし開発には予想外の出来事が付き物です。常にまきで進めるくらいの感覚で丁度良いでしょう。