- 講演資料：新規事業開発を支える技術
基本指針は「事業成長が第一」「事業と技術のバランスを取る」
冒頭で、木田氏は業務で大事にしている2つの基本指針「事業の成長を第一に考えること」「事業と技術のバランスを取ること」について解説。この指針をもとに、さまざまな方針策定を行ってきたという。
「どんなにこだわってシステムを作っても、ユーザーに使ってもらって事業が成長しなければ意味がありません。『いま事業で求められているものは何か』を考えるように、常に心がけています。とはいえ、開発のスピード『だけ』を優先するのもそれはそれで違います。エンジニアとして、『技術的に譲れない部分』は守りたいのです。たとえ新技術にチャレンジしたとしても、品質や開発速度を守れるならば、将来的にはペイできるだろうとも考えています」
そう語った木田氏は、現在取り組んでいるプロジェクトの全体像について解説した。まずは要件定義の話から。彼がプロジェクトに参画した段階では、要件はまだ曖昧だったという。
そこで、プロダクトオーナーとともに要件の洗い出しを行った。プロダクトバックログを作成し、要件をスプレッドシートに書き出していった。その後、書籍『SCRUM BOOT CAMP THE BOOK』を参考に、大まかな見積もりを実施した。
次に行ったのが、開発プロセスの選定だ。新規事業はその特性上、要件の変更が頻繁に起きる。そのため、仕様の変化に柔軟に対応できるスクラム開発を採用した。
その次はアーキテクチャ設計。「開発するシステムはWebアプリケーションのみで、モバイルアプリは開発しない」「運用負荷をなるべく下げたい」といった方針のもと、アーキテクチャの策定を進めていく。試行錯誤の過程で、アーキテクチャの方向性が当初の予定とは大きく変わっていったという。
最初に検討されていたのはSPA＋Firebaseによる構成だ。Firebase Authenticationで認証を行い、Cloud FirestoreやCloud Storageの書きこみをトリガーにしてCloud Functionsを走らせるアーキテクチャを想定していた。
「ですが、ピタゴラスイッチ的な設計になりそうなことや、状態をどこに持つべきかが難しいこと、Firebase Authenticationで細かいユーザー管理をしたい場合には自前で実装する必要があることなどがわかってきました。『運用負荷を下げたい』前提があったので、別のアーキテクチャの方が良いと判断しました」
最終的に採用されたのは、Microservices Architecture on Google App Engineだ。Google App Engineはリクエストに応じて自動的にスケールし、デプロイも簡単にできる。また、Function単位ではなくサービス単位でデプロイを行うため、FaaSに比べて複雑な処理にも対応しやすいなどのメリットがある。
各サービス間のやり取りはCloud Tasksによって行い、データベースはCloud Firestoreを用いる方針となった。
