全体設計の記載

今回はLichtwork（リヒトワーク）で書く設計書のコンテンツの一つである全体設計について紹介します。開発についての全体感を記載する設計書で、これをベースに細かい部分は「機能設計書（共通設計と画面設計を記載）」、「非機能設計書（可用性や性能、セキュリティ等について記載）」、「運用設計」といった各設計書に詳細を書いていきます。

Lichtwork（リヒトワーク）の場合、前回でも書きましたがサービスを開発メンバーにどう創って欲しいかを伝えるために設計書を書きます。昨今はコロナの影響もあり、チャットなど非同期にコミュニケーションを取るケースも多いと思いますが、設計書をかくことも、エンジニアとプロジェクトマネージャーのコミュニケーションの一つと考えています。近くにいれば口頭や伝わってくるカルチャーで自ら開発メンバーも判断することができるかと思いますが、リモートである場合は難しいと感じています。そのためにもどう創るかであったり、どのように進めていくか、何を求められていくかは可視化していく必要があると思っています。

記載する内容

今回モデルケースとしてLichtwork（リヒトワーク）で開発したIntrappsというアプリ配布基盤をベースとした設計書となっています。受託で開発する時に画面（デザイン含む）と機能は大体決まってるけど、開発する人がいないというケースを想定しています。

受託である場合、何にも決まってないけど企画だけあるとか、一旦プロトタイプで検証してみた結果から本番サービスを作るなどケースによって様々です。そのため画面や機能が決まってなかったら、画面にどういう機能があるなどもっと書く必要があるなどシーンによって内容やボリュームが変わります。

また誰が開発するか、どういう技術を持っているか、メンバーとの距離感などによっても書く内容自体は変わってきます。テクノロジー面に不安があるのであればそれを補助する内容を書かないといけないですし、技術はあるが業務内容がニッチすぎてピンと来ないのであれば、業界や業務についてや、システムを利用するときの体験、提供する機能といったを厚めに書かないといけないかなと思います。

故に内容によるのですが、概ね下記のような項目を書いていきます。

プロジェクト概要

• 提供したい体験、利用するユーザー、プロジェクトの目的、プロジェクトのゴールのスコープといった開発を行う中で認識しておいて欲しいことについて書く。
• 提供したい体験、利用するユーザーについては開発するサービスをどういう人に対してどういう体験をしてもらうかということを知ってもらうことを目的する。
• 目的とする人々が提供したい体験を得ることができるようにプロジェクトの目的を設定する。プロジェクトのスコープとゴールについては、開発するだけなのか、導入支援を行うのか、運用フェーズも含むのかといったどこまでの範囲かということを定める。

サービスの概要、ユーザー利用シーン

• サービスを中心に利用するユーザーを図解する。どういう人がどのように使う想定かについて記載する。

運用イメージ

• どのようにサービスが使われ、提供したい体験が体験できるかを図解する。その際に必要な手順や情報について整理する。（細かい運用の流れや、レポートラインといった詳細は運用設計書にて記載する。）

画面イメージ

• 画面実装する画面のイメージについて概要を記載する。（細かい画面の仕様についてはデザインやプロトタイプにて記載する。）

機能一覧

• 画面実装する機能の一覧について概要を記載する。（画面ごとの動作やサービス全体にまつわる仕様については機能設計書、非機能設計に記載する。）

インフライメージ

• 構成するインフライメージの概要を記載する。（可用性、性能、移行性、セキュリティといった細かい仕様については非機能設計に記載する。）

開発の進め方

• 開発期間、スプリント、フェーズで何を創るかについて概要を記載する。（成果物、プロジェクト運営ルール等はプロジェクト計画書にて記載する。）

品質について

• どういうタイミングでどういうテストを行うかを概要を記載する。

上記が全体設計の概要です。先述の通り記載する内容は状況により変化しますが、サービスの仕様や開発進め方、品質について全体的にまとめいるようなものになることが多いです。各詳細な情報については全体設計に記載した内容をベースとして、情報を追記したり、詳細に説明していく形としています。

参考にしていただけますと幸いです。