デジタル化推進マネージャーの長田です。
前回記事では「デジタルガバメント・ジャーニー (4)」では、

• 要件トレース実践方法

として、期待値通りの成果を得るために、要件トレースのスタートライン（明確な受入テスト仕様書を作成）とトレーサビリティチェックのやり方（評価コストを効率的にかける）を独自の視点で書かせていただきました。

今回は第５弾として、受入テスト仕様書作成の対となる「最小の要件定義書」について、触れていきたいと思います！

1. IceBreak：ローコード開発システムの紹介

まずは当方が担当している行政手続オンライン化プラットフォーム：gBizFORM（以下、Gビズフォーム）についてご紹介させていただきます。
Gビズフォームは年間1000件以下の中小規模の行政手続をターゲットに、オンライン化を推進するプラットフォームとして稼働しています。

GビズフォームはPower Apps（Microsoft社製ローコード開発ツール）が用いられていますが、いかにローコード開発とは言えNo Documentでのシステム開発はタブーでしょう。
これは保守性の低下だけではなく、前回記事で示した品質を確保するための要件トレースにおいても必要だからです。

しかし、システム開発の高速化を達成するためには、やはりドキュメンテーションの無駄はなるべく省きたいところです。
そのため、今回はGビズフォームの視点で我々がこの1年間で行ってきた小さく始める手法についてご紹介させていただきます。

2. 必要なもの：たった2つ！

今回の記事タイトル「最小の要件定義書」で求めているものは「業務フロー図」と「ER図」のたった2つだけです。
具体的には下図のようなものを想定してください。

次に、これらの作成方法についてまとめていきたいと思います。

3. 業務フロー図

業務フロー図には様々な粒度があります。下図を参考に、このうち最低でもFL4程度、できればFL5のレベル感で現在の業務の流れを記載するのが好ましいです。

レーン（アクター）については、FL4の場合は組織レベルに、FL5の場合は担当レベルに置き換えていただくとわかりやすいかもしれません。
具体的な粒度は、ハンドオフの単位でインプット・処理・アウトプットを記載すると丁度良い業務フロー図を作成することができます。

4. ER図

業務フロー図でインプット・アウトプットが明確になった場合、それらで用いられる項目がデータとして蓄積するものの大部分になり、これがエンティティ（Entity：ER図のE）となります。

システムとして管理するために必要となる項目は設計段階で付け加えれば十分なので、まずはインプット・アウトプットのキー項目を特定し、次にキー項目に従属する代表的な項目を書き出します。そして、キー項目間の関連性（リレーション（Relation：ER図のR））を明らかにし、エンティティ間を線でつなぎます。
（この段階で数量関係（1対1や1対n）を明示できたらなお良いですが、頑張り過ぎるところではありません。）

5. まとめ

要件定義書の最小構成として業務フロー図とER図の作成方法をまとめてきました。これらをドキュメンテーションすることは、慣習に埋もれた暗黙のルールを明確化することにも役立ちますし、ボトルネックの可視化によりシステム化により改善すべきポイントを明らかにすることもできます。

不慣れなものを作ることは気後れしがちですが、60点くらいを目指してまずは作ることが重要です。

開発ベンダーや内部のテクニカル・アドバイザーを駆使し、効率よく作成していけると良いかと思います。

補足

Gビズフォームはローコード開発ツールなので、スクラッチ開発をする場合や外部連携を行う場合においてはさらにいくつかの追加ドキュメントが必要となります。（下記は一例です）

• 外部システム関連図

• 外部インターフェイス一覧（連携方向、連携方式、処理量を整理）

• ファイル要件

• 非機能要件（信頼性、稼働率、性能、セキュリティなど）