はじめに
ポケットサイン株式会社でエンジニアをしている大森です。
皆さんはソフトウェア開発の設計において何をどこまで決めるべきか悩んだ経験はないでしょうか？
本記事では当社のミニアプリ開発において導入している開発プロセスのうち「設計」に焦点を当て、小規模な開発チームでの実際の運用方法や現場での工夫を紹介します。
前提：開発プロセス
本記事における開発プロセスとは、ソフトウェア開発プロジェクトの立ち上げからリリースまでの工程を区分けし標準化したものを指します。
開発プロセスは工程順に「要件定義」「設計」「実装」「テスト」「リリース」と区分けしています。
要件定義は「何を作るか」を決めるプロセスで、主にPjMやPdMが実施します。設計は「どう作るか」を決めるプロセスで、要件定義の内容に従ってエンジニアが実装方針を決定します。実装は要件定義や設計の内容に従い、実際にソフトウェア開発を行うプロセスです。この後、実装内容の正しさを確かめる「テスト」と、それをユーザーの手元に届ける「リリース」が続きます。
実際に設計でやること
設計を行い設計書に実装方針を明文化することで実装を行う前に整合性を検証したり、開発チーム内で認識を揃えたりすることに役立ちます。ソフトウェア開発における設計手法については既に様々な方法が提示されている一方で細かな粒度まで設計を行うには労力や時間の観点から高いコストがかかります。そこで当社のミニアプリ開発チームのエンジニアは2,3人程度と小規模であることも踏まえ、設計のメリットを享受しつつスピード感をもった開発を行うため設計プロセスで決めるべき内容や粒度を以下のように策定しました。
システムアーキテクチャ
開発するソフトウェアのアーキテクチャおよび他システムとの連携方法を設計します。
決定すべき内容には、フロントエンドとバックエンドの対応関係、マルチテナント構成、インフラ構成などがあります。特にインフラ構成については、どのクラウドサービスをどの要件の実現のために利用するかを定義します。
例えば、Google Cloud Scheduler をジョブの定期実行に用いたり、Cloudflare Workers をリクエストルーティングや軽量な処理に用い、静的ファイル配信には Cloudflare Pages を組み合わせるといった構成を採用しています。
他システムとの連携では、他ミニアプリや外部サービスと通信する際の具体的な方法を設計します。
例えば、子育て支援ミニアプリには地域ポイントミニアプリに対してユーザーにポイントを発行するAPIリクエストを叩く実装があります。これを下記のような図で表現します。
サンプルミニアプリのシステムアーキテクチャ図の例
利用技術選定
開発するソフトウェアで使用する技術スタックを決定します。
例えばバックエンドには Go 言語を採用し、クリーンアーキテクチャ に基づいて Domain層・UseCase層・Interface層・Repository層の責務を明確にした構成を取ることを決めます。
また、利用するライブラリやフレームワークも決定します。例えばバックエンドとフロントエンドとの通信には Buf 社製の Connect RPC（gRPC互換のRPCフレームワーク）を用いることを決めます。
画面設計
フロントエンドの画面単位で、画面のパスや表示内容、操作内容を設計します。
要件定義で決定したワイヤーフレームと、設計時に並行して作成されるUIデザインをベースに、実際の実現方法に落とし込みます。
例えばおしらせミニアプリでは、記事の内容を閲覧する際に画面パスから取得した記事IDをもとに記事内容を取得するRPCを呼び出し、タイトル・内容・サムネイルなどを表示します。
DB設計
ソフトウェアでデータをどのように保持するかを決定します。
基本的にはリレーショナルデータベース（RDB）に永続的なデータを保持するため、必要なデータの洗い出しからテーブル設計を行い、アウトプットとしてER図を作成します。
サンプルミニアプリのER図の例
機能仕様
要件定義では機能要件を定めますが、その具体的な実現方法が複雑な場合は「機能仕様」として以下のように設計段階で策定します。
例えばポケットサインおしらせミニアプリでは、記事をブックマークする機能があります。
ブックマーク状況は記事一覧および詳細画面に反映されるため、記事の取得RPCのレスポンスにブックマーク状態を含める必要があります。
バックエンド側では、記事テーブルとブックマークテーブルを突合する処理を定義することで実現します。
実際にはこれより複雑な処理を必要とするケースも多く、それらはシーケンス図や状態遷移図なども使いながら慎重に仕様を決定していきます。
逆にこれよりシンプルな例、例えばブックマークの登録や解除はDBの特定のテーブルにレコードを挿入・削除するだけで良いので込み入った機能仕様の検討を不要としています。このようにして必要以上のコストをかけないようにしています。
設計レビュー
上記の通り設計を行い、アウトプットを Notion のページにまとめたら、技術責任者によるレビューをミーティング形式で実施します。
このレビューでは、各設計内容が要件に即しているか、抜け漏れがないか、技術的に妥当かといった観点を確認します。
レビューの結果、承認となれば実装に移ります。差し戻しとなれば修正後に再レビューを行いますが、一部指摘事項は非同期で対応するなど、柔軟に対応できる体制を取っています。
実際に運用した所感
これまでは設計内容が甘かった結果実装中に大幅な手戻りが発生してしまったり、逆に設計粒度を細かくしすぎて設計書の作成に数週間かかってしまうこともありました。
しかし上記の方針に従って実際にいくつかのプロジェクトにおいて運用し改善を繰り返すことで、1週間程度で設計書の作成からレビューまで完了し、手戻りもほとんどなく実装を進めることができるようになりました。
さいごに
本記事では、当社の開発プロセスのうち設計についてその内容と運用の工夫を紹介しました。
比較的小規模な組織において効率よく開発を進めるうえで参考になれば幸いです。
