📖
『はじめよう！プロセス設計』『はじめよう！要件定義』『はじめよう！システム設計』を読み終えたので整理する

2024/09/05に公開
技術書
 はじめに本記事は『はじめよう！プロセス設計』『はじめよう！要件定義』『はじめよう！システム設計』の三冊（以下，はじめよう！シリーズと呼称します）を読み終えたので，要件定義・プロセス設計・システム設計の三要素を図を交えて整理します．特に，はじめよう！シリーズが提示した各要素をつなぐことで，プロセス設計と要件定義，システム設計を俯瞰して確認できるようにすることを目的とします．

 対象読者はじめよう！シリーズの読了者

 はじめよう！シリーズが伝えたいことはじめよう！シリーズは拡張画面遷移図 (Interface, Function and DataStore Application Model: IFDAM)の作成が中心となります．IFDAM図とは，一般的な画面遷移図にUIと機能，データの三要素を加えた図であり，システムで実現すべきことを確認できます．例として物件検索システムにおいて，物件一覧の物件をクリックしてその詳細を表示するIFDAM図を下に示します．IFDAM図は四角の中にその画面のタイトルとUI，表示項目と操作項目をまとめます．その後，操作項目に対応したイベントトリガーと機能を記載して，右側に遷移先のUIを配置します．
はじめよう！シリーズはIFDAM図に関して，それぞれ次の範囲を解説しています．
『はじめよう！プロセス設計』：IFDAM図の前段階に何をすべきか
『はじめよう！要件定義』　　：IFDAM図の作り方
『はじめよう！システム設計』：IFDAM図の作成後に何をすべきか
『はじめよう！プロセス設計』はIFDAM図の前段階として，今ある問題が解決した未来を想像し，その様子をプロセスとして設計する方法を解説します．『はじめよう！要件定義』は設計したプロセスで何が必要になるのかを整理する方法とIFDAM図の作成方法を解説します．『はじめよう！システム設計』は開発者が開発を円滑に進めるために，IFDAM図にさらに何の情報を増やせばいいのかを解説します．

 はじめよう！シリーズの全体像はじめに，プロセス設計と要件定義，システム設計の3つがそもそも何であるかをまとめます．
プロセス設計：問題が解決した未来を想像してプロセスを設計すること
要件定義　　：発注者と受注者の間で双方が納得する要件を定義すること
システム設計：要件を開発が円滑に進められる設計書に変換すること
1つ目のプロセス設計は今ある問題が解決した未来を想像し，その様子をプロセスを設計します．問題がある状態をスタート地点，解決された状態をゴール地点として，その間にあるあらすじを想像しながらプロセスを書きます．これにより，問題に対する目標を設定し解決までのプロセスを設計することができます．2つ目の要件定義は発注者と受注者の合意形成トラブルやすれ違いを防ぐために，予め双方が納得する要件を定義します．受注者の要求を受けて発注者が提案して，再び受注者が要求するという流れを繰り返すことで，受注者の要求を満たしつつ受注者が実現可能な要件を定義します．3つ目のシステム設計は要件を分かりやすく設計書に変換して，開発者に何を作ればいいのかを伝えます．小規模なシステムならこの作業がなくても要件だけ見て開発を進めることが可能です．しかし，大規模なシステムの場合は要件も大規模かつ開発者も大勢いるため，要件を設計書に変換して開発者同士の合意形成を取れるようにする必要があります．
『はじめよう！プロセス設計』はプロセス設計としてカスタマーエクスペリエンス（Customer Experience: CX）とサービスシナリオ，ユーザシナリオの三つを解説しています．
カスタマーエクスペリエンス：顧客が問題解決に至るまでのプロセスのこと
サービスシナリオ　　　　　：CXをスムーズに進めるためのシナリオのこと
ユーザーシナリオ　　　　　：ユーザーが一つの仕事をする際のシステムの利用手順のこと
1つ目のCXは顧客の目線に立ち，顧客が問題を抱えている状態をスタートとして，問題解決というゴールに至るまでのあらすじを決めます．これにより，顧客がどのようにシステムを利用してほしいのかという方針を定めることができます．2つ目のサービスシナリオは，設計したCXを達成するためにはシステムにどのような支援が必要なのかを考えてシナリオにまとめます．このシナリオとは，スタートからゴール地点までにどのようなことが必要なのかをフローとして書きます．3つ目のユーザーシナリオは，設計したCXとサービスシナリオに基づいて，ユーザーが各機能を利用する際の手順を定めます．サービスシナリオだけでなくユーザーシナリオも設計することで，システム目線とユーザー目線の両面から考えることができます．
『はじめよう！要件定義』は要件定義として準備と行動シナリオ，拡張画面遷移図 (Interface, Function and DataStore Application Model: IFDAM)の三つを解説しています．
準備：企画書，全体像，サブブロック図，ソフトウェアアーキテクチャ，要求一覧の5つ
行動シナリオ：利用者がシステム上でどのように行動するのかをまとめたもの
IFDAM：UIと機能，データの三要素を定めた画面遷移図であり要件定義そのもの
1つ目の準備では，要件定義ではいきなり要件を定めるのではなく，その前段階として画書，全体像，サブブロック図，ソフトウェアアーキテクチャ，要求一覧の5つを作成します．これらを用意することでプロジェクトの概要紹介や，プロジェクトメンバーへの情報共有を行えます．2つ目の行動シナリオはシステムが実現したときに，実際に利用者がどのようにして仕事を進めるのかを表したシナリオです．ここで，行動シナリオにおける利用者はシステムを利用する人全体を指しています．そのため，単にシステムを利用する顧客だけでなく，システムを活用する社員や管理者，システム自体も対象となります．3つ目のIFDAM図ははじめよう！シリーズの中核であり，要件定義のメインとなるUIと機能，データの三要素を定めます．このIFDAM図は行動シナリオに従って作成します．
『はじめよう！システム設計』はシステム設計としてフロントエンド層，バックエンド層，DB層の三つを解説しています．
フロントエンド層：IFDAM図に基づいたUIレイアウト作成とそれに伴うIFDAM図の修正，フロントエンド層の機能に関するモジュール定義
バックエンド層　：フロントエンド層から呼び出される機能のモジュール定義
DB層　　　　　 ：バックエンド層から呼び出される機能のモジュールのモジュール定義
前提として，『はじめよう！システム設計』は要件定義で得られた要件をフロントエンド層とバックエンド層，DB層の3つのアーキテクチャに落とし込むとして解説しています．ほかのアーキテクチャを使用する場合はまた別の考え方となります．そして，落とし込む際に要件をモジュール化して一つの部品としたうえで各層にマッピングすることになります．1つ目のフロントエンド層は，UIレイアウトの作成と一つのレイアウトに入りきらず画面分割が発生する場合のIFDAM図の修正，IFDAM図におけるモジュール定義としてインターフェース（モジュールの機能名と入力，出力）と実装定義（モジュールの処理の流れ）を行います．ここで，実装定義においてバックエンド層を呼び出す処理を定義しておきます．2つ目のバックエンド層はフロントエンド層で呼び出す機能のモジュール定義として，インターフェースと実装定義を行います．ここで，実装定義においてDB層を呼び出す処理を定義しておきます．3つ目のDB層はバックエンド層で呼び出す機能のモジュール定義としてインターフェースを決めた後，インターフェースと接続するデータを定義して，それらをまとめてERD図を作成します．
はじめよう！シリーズで解説する要素を図にまとめると次のようになります．
はじめに，プロセス設計のサービスシナリオやユーザーシナリオを一つ選択して行動シナリオを作成します．つぎに，行動シナリオの一つを選択してIFDAM図を作成します．これを繰り返した後，最後に各IFDAM図のフロントエンド層，バックエンド層，DB層を考慮してUI，機能，データの詳細を詰めていく流れとなります．

 プロセス設計『はじめよう！プロセス設計』で解説しているカスタマーエクスペリエンスとサービスシナリオ，ユーザーシナリオの三要素を整理します．

 カスタマーエクスペリエンスCXは顧客の目線に立って，顧客が抱える問題からその問題解決までの一連の流れをプロセスとして設計します．CXは企業目線で考えるのではなく顧客目線で考えます．そのため，顧客がどのような問題を抱えているのか想定して，それが解決するまでの道筋を立てていきます．
CXはバックキャスティングに従って設計します．バックキャスティングとはゴールを最初に定めて，そこからスタートに向けて逆算しながらあらすじを決める方法です．先のゴールを定めることで結果を明確にした後，そのために必要なステップを順々に考えながらスタートとつなげます．その後，各ステップを詳細に考えることでCXの完成度を向上させます．
CXでゴールを決定するためには対象範囲を考えます．対象範囲を決めることでゴールやスタートが分かります．例えば，ログイン画面に遷移してからログインが完了するまでや，開発したシステムを周知してからフィードバックをもらうことなど，対象範囲の規模は自由です．対象範囲が決まった後は，バックキャスティングに従って設計します．

 要件定義『はじめよう！要件定義』の準備と行動シナリオ，IFDAMの三要素を整理します．

 準備要件定義に入る準備段階として，プロジェクトの概要紹介およびプロジェクトメンバーへの情報共有を目的とした以下の5つを作成します．
企画書：企画のゴールおよび目的が分かる資料
全体像：企画によって出来上がるシステムの紹介
サブブロック図：システム内のの各機能の連携を示したもの
ソフトウェアアーキテクチャ：技術選定および使用する方式の方針決定
要求一覧：システムで実現したいことを文書化したもの
1つ目の企画書はその企画によって何を実現することがゴールなのかを記載する必要があります．これがなければプロジェクトがどの方向を目指して進めばよいのかが分からなくなってしまいます．さらに，企画書は単なる提案書ではなく報告書の役割も担います．そのため，企画を手短に説明できて，聞き手が簡単に理解できるよう要点をまとめます．
2つ目の全体像は企画によって実現するシステムを説明します．企画書は企画の方向性を定めるものでしたが，全体像はシステムが俯瞰してシステムをどのように利用できるようにするのかを図としてまとめます．全体像は真ん中にシステムを表す四角いの箱を設置して，その周りに利用者を配置して何ができるのかを箇条書きにします．この時の利用者は，顧客だけでなく社員や管理者なども含まれます．
3つ目のサブブロック図は企画で実現予定のシステムが大規模な場合に必要となります．システムに機能が互いにどこと関係しているのかを決めてフロー図にまとめます．並行して実行される機能はさらに別のラインに配置されます．
4つ目のソフトウェアアーキテクチャはシステムをどのようなアーキテクチャに実装するのかを定めます．一見すると要件を定めてから考えればよさそうですが，実装の都合が分からないと適切な要件を定めることはできません．さらに，アーキテクチャにできないことは実装できないため，システムはアーキテクチャに依存します．そのため，事前に実装の見通しを立てる必要があります．ソフトウェアアーキテクチャはこの段階で完璧に決める必要はなく，利用者とシステムとのインタアクション方法や機能同士がどのような通信プロトコルやデータフォーマットを使うのかを定めます．
5つ目の要求一覧は，心の中で考えている実現したいことを文書化することそのものが目的となります．心中にある要望を共有することで本当に実現すべきものは何かを整理できます．さらに，要件定義に入る前に共有しておくことで，システムが完成間近の最後の最後で実はこういう機能が欲しかったんだというちゃぶ台返しを防ぐことができます．

 行動シナリオ行動シナリオは利用者がシステム上でどのように行動するのかをまとめたものです．これはサービスシナリオやユーザーシナリオの一つの部分が対象として作成します．行動シナリオは左側に利用者やシステムを配置して，右側に利用者が仕事を始めてからどのようなやり取りを経て完了するのかの一連の流れを示します．
行動シナリオを作成する理由は，システムの利用者全員の仕事の連鎖をまとめるためです．仕事の連鎖とは，Aさんが仕事Aして成果A'を出した後，その成果A'を使ってBさんは別の仕事をするといった流れで，人から人へ仕事が連鎖する様子を指しています．これにより，スタートからゴールまでの時系列を示すだけでなく複数の利用者との仕事の連鎖を示すことができます．この仕事の連鎖を示すことで必要な機能を漏らすことなく明確化することができます．プロセス設計で作ったユーザーシナリオやサービスシナリオはシステムに依存しておらず，あくまでゴールを達成するまでの道のりをプロセスとして定めただけです．そこで，行動シナリオを使ってシステムが実現した際の行動の流れを考える必要があります．
行動シナリオはプロセス設計と作成の仕方自体は同じです．はじめにゴール地点とスタート地点を定めてから，その間のあらすじを決めます．ただし，プロセス設計にはなかった仕事の連鎖や成果の受け渡し，データの保存，データの取り出しについても考える必要があります．また，行動シナリオから利用者だけでなくシステムも登場するため，どこでどのUIが必要になるのかも示す必要があります．

 IFDAM拡張画面遷移図 (Interface, Function and DataStore Application Model: IFDAM) はUIと機能，データの三要素を定めるものであり要件定義そのものです．なぜなら，要件定義とは開発者がシステムを完成させるために必要なUIと機能，データの3つの要件を定めることが目的だからです．IFDAM図の対象は行動シナリオの一つの仕事です．一つの仕事とは，「〇〇が××する」という主語と述語のみで構成される仕事を指しています．
IFDAM図は手書きのラフイメージを作成した後，ラフイメージに基づいてUIと機能，データを設計します．はじめにUIはタイトルと表示項目，入力項目と操作項目の4つに分けて配置することで作成します．つぎにイベントトリガーと機能を作成します．イベントトリガーとはUIの操作項目を使用したことを表すトリガーであり，これに対応して機能が呼び出されます．さいごに機能が使用するデータを作成します．機能がデータを保存する場合や取得する場合に記載します．画面間の機能やデータに関する詳細な定義はのちほどシステム設計で行います．

 システム設計『はじめよう！システム設計』のフロントエンド層とバックエンド層，DB層の三要素を整理します．

 フロントエンド層フロントエンド層はIFDAM図に基づいてUIレイアウトの作成とIFDAM図の修正，ロントエンド層の機能に関するモジュール定義の3つを行います．
一つ目はIFDAM図に基づくUIレイアウトの作成です．要件定義で作成したIFDAM図から一つピックアップして，デザインガイドラインとデザインの4原則に従ってUIレイアウトを作成して項目を配置します．
二つ目はUIレイアウトの作成に伴うIFDAM図の修正です．UIレイアウトの作成において，一つのUIに項目が入りきらない場合，画面を分割して二つに分ける必要があります．すると画面遷移が発生するため，IFDAM図と操作手順も修正する必要が出てきます．また，この分割作業を機能についても考え，一つの機能が一つの仕事だけをこなすようにします．そのため，IFDAM図は機能と機能同士が矢印でつながっていても大丈夫です．
三つ目はフロントエンド層の機能に関するモジュール定義であり，インターフェースと実装定義の2種類を行います．インターフェースでは機能名と入力，出力の3つを定義します．実装定義は機能のモジュールの詳細をプロセスとして定義します．基本的に，イベントトリガーを入力として，次の画面に遷移するまでの処理の流れを記載して，さらに各機能を階層構造で小分けしていきます．このとき，バックエンド層で呼び出す機能を明確にしておきます．

 バックエンド層バックエンド層はフロントエンド層が呼び出すモジュールのインターフェースと実装定義を行います．以降はフロントエンド層と同様であり，インターフェースは機能名と入力，出力を定義します．実装定義はその機能名がどのような処理を行うのかをまとめます．このとき，データの保存や取得する場合はDB層を呼び出すことを明確に示しておきます．

 DB層DB層はバックエンド層が呼び出すモジュールのインターフェースの定義とERD図を作成します．インターフェースは今までと同じで機能名と入力と出力を定義します．データのやりとりのため，出力は処理ステータスやnull の場合もあります．DB層はさらにこの入出力にの下側に，対応するテーブルを定義します．最後にこれらのテーブルの各要素を書き出してそれらをグループ分けして各テーブルにまとめます．最後にテーブル間をリレーションさせることでERD図が完成します

 まとめはじめよう！シリーズの3冊で述べられていたことについて，その定義と関係性をまとめました．以降は実践を通して身に着けていきます．