小さく始める時こそ、大規模になった場合を考慮した技術選定を
片山氏は、「小規模なチームで開発を始めると、プロセスをあまり整備しなくてもメンバーが近いので、何となく開発できてしまう」と指摘し、そのままでは人員規模が大きくなっていったときに、「ある人はテストをするが、ある人がテストしないでコードをプッシュしてしまう」など後々のテストが上手くいかなくなる。
「静的解析やコードフォーマットのルールを後から適用しようとすると、すでにあるソースコードへの変更点が多くなりすぎて、結局できないといった例を見てきた（片山氏）」。こうしたことを防ぐために、少人数でスタートするときからプロセスを整備して仕組みにしてしまうことが大切だ。
さらに、サービスが動き始めた後に大規模改修が発生する可能性を潰しておくことも重要だ。よくある例としては、多言語対応が挙げられる。すでにサービスが動いている状態で多言語対応をすることはデータベースの整合性などの問題もあってなかなか難しい。「海外市場を見据えるなら多言語対応は欠かせないが、それができなくなるとプロダクトがスケールしていかない（片山氏）」。
そして、REST APIを開発する際には「APIの定義と実装がずれる」「API定義のフォーマットのあいまいさ、考慮漏れによる実装ミス」「APIごとのバリデーション実装」「APIの定義変更がAPI利用者側に影響」といった問題が発生しやすいと片山氏は指摘する。
この点でスケールした後のことを考えた結果、今回のプロジェクトではOpenAPI仕様を採用し、そのエコシステムを利用することに決めた。「スケールさせていくには自分たち独自の仕組みではなく、既存の優れたエコシステムを利用すべき」という考えからの結論だ。
OpenAPIはYAMLやJSONといった形式で記述できるので、エンジニアには扱いやすい。さらに、関係ツールが豊富にあることも利点だ。例えば「Stoplight Studio」というツールを使えば、GUIでOpenAPI仕様に沿ったYAMLやJSONを作成できる。さらに、「Redoc」というツールを使えば、YAMLやJSONからAPIリファレンスを生成できる。そのほかにも、入出力バリデーションに使える「express-openapi-validator」というツールや、自動テストに利用できる「Jest」というツールもある。今回のプロジェクトでは、以上のツールを採用して、ドキュメント管理とテストに費やす工数を最小化することに努めた。
開発に使用する言語も、プロジェクトが大きくなった後のことを考えて選んだ。候補としてはJavaScriptとTypeScriptがあったが、「新たに参加するメンバーの学習コストが低い点を評価して」JavaScriptを選んだ。「TypeScriptの利点は型がしっかりしていること。ライブラリで型が用意されていれば問題ない。しかし、ない場合は作らなければならない」と片山氏は両言語の得失について語った。
そしてJavaScriptを選んだ理由にはほかにも、「Vue 2.x」でTypeScriptが完全対応していない点や、UIライブラリの「Vuetify」を使いたいといった点がある。
最後に片山氏は現状を振り返って良かったこととして、静的解析を仕組みとして取り入れたことや、OpenAPIのエコシステムを利用できたことを挙げた。反対に良くなかったこととして、ライブラリの依存関係の問題で、最新バージョンを利用できなかったことと、OpenAPIのエコシステムが少々難しく、使いこなすために手間と時間がかかってしまった点を挙げ、セッションを終えた。
