「書く」から「考える」へ。初めての概要設計で学んだこと

はじめに

こんにちは！　エンジニアのOです。

とあるシステムのリプレースプロジェクトで、初めて概要設計フェーズに携わる機会がありました。今回は、そのプロジェクトでの経験をまとめます。「エンジニアの仕事に興味はあるけれど、実際どんなことをするの？」という方の参考になれば幸いです。

1. プロジェクト概要

クレジットカードの業務システムを刷新するプロジェクトで、要件定義フェーズはすでに完了していました。弊社は概要設計工程の途中から参画し、私は設計担当の一員として参加しました。

2. 概要設計工程では何をするのか

概要設計とは、要件定義フェーズで定めた要件を具体的なシステム構成に落とし込む工程です。

概要設計書の主な役割は、要件定義書の内容をより具体的な形で示し、お客様と開発側の間で仕様に対する認識のずれがないかを確認することにあります。

概要設計書の内容についてお客様から承認をいただいた後、次の工程である基本設計へと進みます。

3. 概要設計書に記載した内容

今回のプロジェクトでは、機能ごとに設計担当者が割り当てられており、私は5つの担当機能について概要設計書を作成しました。

(1) 機能概要

今回のプロジェクトでは概要設計書を機能単位で作成したため、「誰が」「いつ」「どのような状況で」「どのように」この機能を利用するのかを、冒頭に明記しました。

(2) 画面遷移図

画面遷移図とは、どの画面で何をしたら、どの画面に遷移するのかを視覚的に表現したものです。各画面で呼び出すAPIやテーブル、外部インターフェースも合わせて記載しました。

(3) ビジネスルール

ここでのビジネスルールとは、条件によって画面表示や処理を変えることを指します。たとえば「ゴールド会員の場合は変更ボタンを表示するが、一般会員の場合は表示しない」といった内容です。あらゆるパターンを洗い出し、分岐条件を明確に記載しました。

(4) 画面イメージと各表示項目の機能説明

機能内で登場するすべての画面イメージを作成し、各項目の役割やデータ元を明示しました。たとえば以下のように記載しました。

• 会員氏名　：会員テーブル.氏名を表示
• 変更ボタン：変更内容確認画面へ遷移

※概要設計書に必ずしも上記4項目を記載する必要があるわけではありません。今回のプロジェクトでは、上記の項目を含むテンプレートを使用して作成しました。

4. 直面した課題

初めて概要設計を担当した私は、「要件定義に書かれているとおりに設計しなければならない（提案は求められていない）」と考えていました。最初の1機能を書き終え、「よし、要件定義書どおりにできたぞ！」と自信満々でレビューに出すと……まさかのフィードバックの嵐。

理由は、要件定義書は実装や保守まで十分に考慮されていない部分もあるため、そのまま設計書に落とし込むと「処理が煩雑すぎて保守性が低い」といった問題が生じるからです。こうした観点を補い、より現実的な構成に落とし込むのが、まさに概要設計の役割でした。

また、「遷移元の画面によって、ボタン押下後の処理を分岐させる」といった仕様を記載した際には、「それは具体的にどう実現するの？」「値の受け渡しはどうするの？」といった指摘を受けることもありました。そのたびに「セッションIDを使う…？」「Reactの知識が足りないから調べよう…」「知らないことだらけだ…」と、何度も立ち止まりました。

5. 徹底したこと

「自分は技術面でまだまだだ」と痛感したため、せめてドキュメントとしての品質だけは妥協しないと決めました。特に徹底したのは以下の点です。

• 自分の担当範囲に限らず、チーム全体で表記ゆれをなくす
  （例：「ユーザ」「ユーザー」「会員」など同義語を統一）
• 画面遷移図や画面イメージの図形は常に整列・均等配置を意識（「後でやる」と漏れやすいため、その場で修正することを徹底）
• レビュー依頼前に、プロジェクト内専用のAIで誤字脱字チェックを実施
• レビュー依頼前に、チーム共有のチェックリストに従って自己確認を実施

これらを作成時だけでなく、全機能の概要設計書完成後にも再度確認し、最終的な品質向上に努めました。

6. まとめ

概要設計を経験して、「要件定義を正確に写すだけでは不十分」であり、実装・運用・保守までを見据えた設計力が求められることを学びました。また、実装言語やデータベース、ネットワーク、セキュリティなど、非常に幅広い知識が必要であることも実感しました。

今回の経験を通じて、システム開発における“設計”という工程の奥深さと面白さを改めて感じました。