1. はじめに：企画者は「画面」ではなく「プロセス」を設計する
IT業界では、サービス企画者の役割を「スケッチを描いて画面を作る人」と誤解しがちです。デザインツールを活用してボタンを配置し、ワイヤーフレームを作成する作業が最も目立つためです。
しかし、視覚的な画面は、企画者が定義した数多くの論理やポリシーが最終的に表現された「成果物」にすぎません。本当の企画者の役割は、ビジネス上の曖昧な要件を、開発とデザインが可能な「構造化言語」に翻訳し、サービスの開始からローンチ直前のQAまで、製品のライフサイクル（Product Life Cycle）全体を綿密に管理することです。
船舶の基準情報を管理する新規サービスを自ら構築しながら、企画の3大要素である要件、IA、フローチャートを通じて問題を解決し、成長してきた実務の経験を共有したいと思います。
2. 要件分析および定義：画面を埋めることに追われていた日々から発見したSRSの核心
プロジェクトを進めていると、現場担当者や顧客から「この画面にこの情報も表示してほしい」「あの機能も追加してほしい」といった数多くの要望を受けることになります。企画の初期段階では、私もこれらの要望を画面に手当たり次第詰め込むことに追われていました。まずボタンを作り、入力ボックスを配置し、要望を視覚化することだけに没頭していたのです。しかし、新規プロジェクトを率いながら企画プロセスを深く振り返ってみると、その過程こそが要件定義の核心でした。
2.1 要件分析の4段階プロセス
実務では、この曖昧さを明確さに変えるため、実現可能性調査、要件の抽出および分析、要件定義、要件の検証および管理という4段階のプロセスを経て、骨格を組み立てていきました。
[1. 実現可能性調査] ➔ [2. 要件の抽出/分析] ➔ [3. 要件定義] ➔ [4. 要件の検証/管理]
-
実現可能性調査
-
プロジェクト推進の必要性と、リソースに対する実現可能性（Technical/Business Feasibility）を検討します。
-
要件の抽出および分析
-
現場（ユーザー）から、開発したいシステムの機能要件を聞き取り、整理します。企画者は受動的に書き留めるのではなく、必要な内容を逆に質問し、ユーザー視点のシナリオ形式でユースケース（Use Case）を定義しなければなりません。
-
要件定義
-
分析したシナリオに基づき、システムの動作を説明する機能（Functional）項目と、システムの属性、制約条件、性能を意味する非機能（Non-Functional）項目を区別し、明確な文章で記述します。
-
要件の検証および管理
-
「顧客が望んでいる内容に合っているか」「開発可能か」「テストで検証可能か」について、複数の担当領域（開発/デザイン/ビジネス）の視点を確認し、フィードバックを反映します。その後、変更履歴（変更日、変更項目など）を継続的に追跡します。
要件分析時の注意事項
要件分析の過程で私が感じた、実務上の注意事項があります。
-
内容はできるだけ詳細に分析：「ログイン機能が必要」ではなく、「どの手段を用い、どのような例外処理を含めるのか」まで掘り下げる必要があります。
-
現場担当者の用語をそのまま記録：コミュニケーションミスを減らすため、初期段階ではドメイン専門家や現場が使用する言葉をそのままアーカイブします。
-
書面で共有し、承認を得る：整理した内容は必ずメールや公式のコラボレーションツールで関係者に共有したうえで、最終承認を得ておきます。これは後に発生する可能性のある範囲算定（Scope）をめぐる紛争を防ぐ防衛線になります。
2.2 要件定義書（SRS）の構成項目および作成例
要件定義書（Software Requirement Specification）は、「システムがどのように（How）実行されるか」ではなく、「何を（What）実行するか」について記述する文書です。
-
主要な構成項目：要件ID、分類/項目、詳細内容、依頼者/依頼日、重要度（優先順位）、難易度、受け入れ可否、担当者、担当者の意見、備考
要件定義書の実務ガイド例
|
要件 ID |
分類 |
要件 詳細内容 |
重要度 |
難易度 |
受け入れ可否 |
担当者の意見 |
|---|---|---|---|---|---|---|
|
REQ-001 |
会員登録 |
ユーザーはメールアドレスをIDとして使用し、会員登録を行える必要がある。 |
高 |
中 |
受け入れ |
メールアドレスの重複チェックおよび認証プロセスを必ず含める予定 |
|
REQ-002 |
決済 |
ユーザーはKakao Payおよびクレジットカードで商品を決済できる必要がある。 |
高 |
高 |
受容 |
外部PG会社との連携が必要であり、非機能要件を考慮して決済タイムアウト処理を反映 |
要件定義書レビュー・チェックリスト
以下のチェックリストを通じて、要件を正しく整理できているか確認できます。
-
[ ] すべての要件が曖昧ではなく、明確かつ具体的になっているか？
-
[ ] 正常フロー以外に、例外状況とエラー処理が明示的に含まれているか？
-
[ ] 現在のインフラとリソースで技術的に実装可能なレベルか？
-
[ ] テスト結果を真偽で明確に判定できる、テスト可能な基準が提示されているか？
-
[ ] 1つの要件が他の要件の論理と衝突していないか？
-
[ ] 個人情報保護法など、セキュリティおよびコンプライアンスに関する事項が漏れなく反映されているか？
-
[ ] マイルストーンに合わせて、優先順位（高・中・低）が適切に設定されているか？
3. サービス構造設計（IA、フローチャート）
3.1 情報構造図（IA、Information Architecture）
ここから本格的に、サービス全体の画面とメニュー構造を体系的に設計する情報構造図（IA、Information Architecture）策定の段階へと進みます。白紙の状態で膨大な船舶データに向き合った際、ユーザーがシステム内で迷わないよう、大メニューとサブメニューを分類・グループ化し、緻密なDepth構造を組み立てていく必要がありました。
-
Depth設計ルール：ユーザーの複雑さを軽減し、負担を減らすため、できる限りすべてのメニューを3Depth以下で設計することを原則としました。もちろん、船舶管理システムのように複雑な構造では、段階ごとに表示すべき画面が増える場合もありますが、その場合も明確な論理的根拠に基づき、Depthを最小限に抑える努力を先行させる必要があります。
-
画面IDガイドルール：IAに登録されるすべてのページには、固有の画面IDを付与します。
-
1～2 Depthメニュー名の略称：大メニューの英語名をアルファベット大文字2文字に短縮して使用します。（例：会員管理 ➔ MB）
-
Depth別区分コード：Depthごとに数字で区分し、画面間にルールを付与します。（例：MB_01、MB_01_01）
-
画面形式区分の略称：詳細内容に応じて、形式（List、Detail、Popupなど）を接尾辞として付けて区分することも可能です。
-
絶対ルール：IDは決して重複してはならず、企画変更によって特定のIDが修正または削除された場合でも、そのIDを別の画面に再利用しないことが履歴管理の鉄則です。
-
IAの主要構成要素：分類、サービスDepth（1/2/3）、サービス画面番号、画面ID、ページ定義および要件、詳細事項、進行段階（待機中／企画中／完了）
3.2 フローチャート（Flowchart）
フローチャートは、画面および機能単位で、ユーザーの移動経路とシステムの処理過程を図式化する文書です。ユーザーがどのようなプロセスでサービスを利用し、システムが内部でどのように動作するのかを一目で把握できるようにします。
特に、私が担当した船舶管理サービスでは、企画を進めていると、数多くの画面が有機的に絡み合って動作したり、複雑なデータの例外状況が絶えず発生したりすることがありました。初期には従来の方法どおり、ストーリーボード（画面設計書）のワイヤーフレームの横に、例外ケースをテキストでどれほど長く詳細に記載しても、私の企画意図を100％伝えることは非常に困難でした。
この問題を解決するため、国際標準記号（開始、プロセス、判断分岐など）に準拠したフローチャートを作成し、開発者の方々に併せて共有しました。ユーザーの動線が混乱しないよう、条件分岐（ひし形）に基づくフローを明確に単線化することに注力しました。
フローチャート作成時に遵守すべき国際標準ルール
-
標準記号の活用：開始／終了（角丸長方形）、プロセス（長方形）、比較／判断（ひし形）など、国際標準記号を厳格に遵守します。
代表的な国際フローチャート図形（ISO 5807国際標準）
-
視線の流れ：全体的なユーザー動線が左から右、または上から下へ自然に流れるように構成します。
-
判断の分岐：ひし形（比較／判断）記号を使用する場合、結果値は通常、Yesの場合は下向きの矢印、Noの場合は左または右向きの矢印に分岐させます。
-
入出力の原則：比較および判断に関する入出力線は必ず論理的に明確でなければならず、複雑に交差しないよう、プロセスごとのフローを単線化します。
-
おすすめツール：実務ではDraw.io、Visio、Axure、または近年大きな人気を集めているFigmaやMiroを主に使用します。
4. 結論：堅固な骨格が無欠点のサービスをつくる
船舶基準情報サービスを企画して感じたのは、企画担当者は単に「画面を描く人」ではなく、緻密な「論理」と有機的な「プロセス」を構築するシステムアーキテクトに近いということです。
初期段階で画面デザインだけに注力していたら、この膨大なデータサービスを決してリリースできなかったでしょう。上流で要件を整理し、IAで骨格を築き、フローチャートで導線を整理したからこそ実現できた結果でした。
今回の記事でサービスの上位概念と構造をしっかりと固めたので、次回の投稿では、こうして作成した構造をもとに、デザイナーや開発者とコミュニケーションを取るための最終設計図である「最終画面設計書（ストーリーボード）」を作成した経験を共有したいと思います。さらに、サービスのリリース直前に、製品の品質を最高レベルまで高めるため、実際にテスト（QA）を行いながら経験した実務の話とともに、またお会いしたいと思います。
Ryu