■はじめに
こんにちは。
株式会社iimonでフロントエンドを担当している白水です。
年明けぐらいから、約3ヶ月間に渡って「新規サービス開発」を担当しました。
その中で、個人的に意識したことや、良かったことを振り返る記事を書きましたので、ぜひお読みください。
■実装期間・開発人数・担当領域
- 実装期間：約3ヶ月
- 開発人数：1人
- 担当領域：フロント9割、バックエンド1割
今回、新規に開発したサービスは「約3ヶ月間」で「フロント9割・バックエンド1割」という割合を「1人称」で担当しました。
ほとんどフロント側で完結するサービスでしたので、バックエンドを触ることは少なかったです。
■新規開発する上で心がけたこと（やって良かったこと）
◆見積もりの粒度がちょうどよかった
iimonでは、「新規サービス」に限らず、タスクに着手する前にどれくらいの工数でできそうかエンジニアが「見積もり」をします。
その見積もりに合わせて、ビジネス側が動いていく（いつから動くか？どうやって動くか？を決める）というような構図になっています。
今回の「新規サービス」開発にあたっても見積もりをしましたが、その粒度が小さく分けられていたので助かりました。
1つサービスを開発するにあたって、複数の子タスク（やるべきこと）がありますが、その子タスクを大きくしすぎると「予定工数」と「実際の工数」にズレが生じてくるため、見積もり粒度が小さかったのは良かったです。
◆「サービスの用途」や「ターゲット」を理解する
不動産という領域は、エンジニアが「ドメインエキスパート」ではないです。
しかし、
- 誰がターゲットなのか？
- ターゲットはどんな業務をしているのか？
- ターゲットはどんな問題を抱えているのか？
- ターゲットの何を解決したいのか？
を理解しないと、作業になってしまうなと思いました。
そこで、自分なりに図を作成して、
- 誰がターゲットなのか？
- ターゲットはどんな業務をしているのか？
- どんな問題を抱えているのか？
- このサービスでどうやって解決できるのか？
などを、自分なりにまとめることことをしました。
この図を下にして、ドメインエキスパートである「PM（不動産経験者）」に「サービスのターゲットはあっているか？」「ターゲットはどんな業務をしているのか？」「どんな問題を抱えているのか？」「何を解決したいのか？」を壁打ちすることで、理解が深まり、開発する意味などを見いだせた気がします。
エンジニア側も、ある程度のドメイン理解は大事だと思いますので、開発する前に「ターゲット」や「課題点」などを確認したのは良かったなと思いました。
◆フローチャートを作成して、仕様の認識ズレを減らすように努めた
サービスを開発するにあたって、仕様の認識にずれがあると、手戻りが発生して、全体の工数にズレが生じると考えました。
複数人で見積もりしているといっても、
- 人間なので見逃しもある。
- 文字ベースだと複雑でよくわからない。
- PMとエンジニアの認識は違うけど、見積もりしたエンジニア内での認識は同じ。
ということは、よくあるのかなと思います。
認識がズレている状態で仮に工数内で開発できても、思ったものと違うものが作られるのは、本末転倒だと思います。
そのため、開発前に仕様をフローチャートに落とし込んで、PMと壁打ちをしました。
今回の開発でも、フローチャートに落とした状態でPMと話す中で、認識がズレている事が多々ありました。
そのため、フローチャートに落とし込んで、認識のすり合わせをしておいて良かったと思いました。
ついでに、「ディレクトリ構成」も考えておくと、スムーズに開発できたり、責務を分けた構成に自ずとなるので「ディレクトリ構成」を事前に考えておいて良かったなと思いました。
◆テストを書きながら小さく進められてこと
iimonでは、テストを書くことに力を入れています。
新規開発でもテストを書いていく前提で、小さく「実装＋テスト」の組み合わせてプルリクを出すことで、正しく動くことを担保できたので、「安心感」と「自信」を持って開発を進めることができました！
また、レビュアーも「テスト」があるので、動作に関しては気にしないでよいため、コードの書き方などを重点的に見れるので、レビュアーの負担を減らすことにも繋がったと思います。
◆APIの作成やER図作成など体験できたこと
普段、フロントをメインでやっているので、バックエンド側のAPIを作ったり、テーブル作るなどの経験はあまりなかったです。
今回新規サービスを作るにあたって、テーブルを作る必要があったため、「ER図」を作成したり、「APIの作成」を経験できたのは良い経験になりました。
◆ドキュメントを整備できたこと
「1人称」で開発しているので、サービスへの理解や、ディレクトリの構成などが「属人化してしまう」という懸念点がありました。
サービスは作って終わりになることはないと思いますので、「保守・運用」を将来に渡って誰もができるように「ドキュメント」を整備するのは大事かなと思いました。
そこで、
- サービスのターゲット図
- ER図
- フローチャート
などを、開発前に整備していたので、ドキュメントを整備しやすかったです。
また、サービスの「保守・運用」を他の誰かが担当するときも、ドキュメントを見ればある程度のことはわかるので、持続的なサービスを維持するうえで、作成して良かったなと思いました。
■今後に活かしたいこと
◆見積もりに抜けがあることを前提にする
見積もりは人間がやるので、3人でやっても4人でやっても、ほぼ100％の確率で大小さまざまな抜けがあると思います。
今回の開発でも、実際に見積もりに抜けはありました。
やはり「見積もりに抜けがある」ことを認識しておくことは大事だと思いました。
弊社では、見積もりに対して「バッファ」を設けているので、「抜け」があっても致命傷になることはほとんど無いですが、心の何処かで抜けあるだろうなと思っておくのは大事かなと思いました。
◆簡単そうに見えて、意外と難しいこともある
仕様の文面だけを見ると「削除してください」と書いてあったとします。
普通に見ると、簡単そうに見えますが、コードベースで確認すると、ここを削除するとヤバそうなときもあるなと思いました。
また、「削除してください」という依頼に対して、「削除する場所」を膨大なコードの中から探すのも意外と大変なので、文面だけで簡単そうと判断しないで、疑いを持つことも大事かなと思いました。
PMからの依頼に対しても、その場で即答しないで、「調査して回答します」ぐらいの回答でもいいかなと思いました。
◆追加の要望が来ることも見越しておく
開発していると、途中で
- 〇〇も一緒にやってほしい
- △△仕様も追加したい
など、追加の要望が来ました。
もし、工数に余裕を持たせていないと、「追加の要望」に対応できないので、「追加の要望」が来る前提でいるほうがいいのかなと思いました。
ただ、そもそも追加要望に対しては、純粋に再見積もりするで良いと思います。
◆新規サービス・新機能の説明会を開く
ドキュメントを整備したとはいえ、
- みんながドキュメントに目を通しているとは限らない
- ドキュメントの説明がないと、ドキュメントが理解できない
- ドキュメントの不明点がある
など、あるかなと思います。
また、ビジネス側は知る必要無いけど、エンジニア目線では知っておかないと行けない「ロジック」や「設計」などもあるなと思いました。
そのため、「エンジニアのエンジニアによるエンジニアのためのサービス説明会」みたいなものを「新規開発、新機能開発をしたらやる」という試みもありなのかなと思いました。
説明会を開くとなると、必然的にドキュメントを整備する必要もあるので、1つの試みとしては良いのかなと思いました。
■まとめ
ここまでお読みいただきありがとうございます。
新規開発を通して、
- ドメイン知識を深める
- 普段あまりやらないことができる
- 開発以外での工夫
など、経験できて良かったです。
iimonでは、新規開発が多数あり、そういった環境を求められている方には良い選択肢になるのかなと思います。
もし興味を持って下さった方がいれば、ぜひカジュアル面談でお話しできればと思います！
