【技術関連】今日からPM（要件定義①）
要件定義を書くのに皆それぞれテンプレ持っていると思うけど、自分理想のテンプレは以下です。（新規事業創出系なので一例です。）毎回これ全てを記述するわけでは無いし、業務コンサルティング後であればイキナリ業務要件定義から入ったりやり方はまちまちですが。
あと、下に記述する内容は私の経験に基づくものなので、他に良い書き方や章立てがあれば教えてくださいww
1.ビジネス要件定義
ここで名の通り「ビジネス」について語ることになります。
事業化している（しようとしている）ビジネスのビジョン、立ち位置やマーケティング、プランニング、スケジュールこれらを明らかにしてサービス一覧を作り上げます。
この一覧には網羅的にBtoB、BtoCそしてBtoE各種アクタ向けのサービスが羅列されます。章立ては以下です。(事業によって異なります。今回はBtoC向けのテンプレートです。)
1.1.ビジョン（理念）
1.2.事業ドメイン
1.3.ビジネスプランニング
1.4.行動計画
1.5.SWOT分析
1.6.VRIO分析
1.7.ペルソナ分析
1.8.３C分析
1.9.ポジショニングマップ
1.10.収支計画・マネタイズ
1.11.事業スケジュール
1.12.サービス一覧
2.業務要件定義
サービス実現に必要な業務を洗い出す工程です。業務とはBtoE以外にも存在します。(例えば、広告掲載等々のフローもです。)業務一覧から各種フローに落とし、フローごとにシステム化範囲を決定します。
先ずは、今回のサービスに係る人物や部署、外部の協力者、システムを洗い出します。これがアクタ一覧です。（利害関係やステークホルダ関係があるのであれば必要に応じ2.1.2.パワーストラクチャ図にまとめます）
そして、各アクタを業務一覧にプロット。詳細を2.2.3.●●業務フローを纏めていき、システム化範囲を明確化します。
2.1.アクタ定義
2.1.1.アクタ一覧
2.1.2.パワーストラクチャ図
2.2.業務定義
2.2.1.業務一覧
2.2.2.スコープ定義
2.2.3.●●業務フロー
3.機能要件定義
業務フローをインプットに機能の前提条件を作成し、機能の一覧を纏めます。機能一覧には業務がプロットされます。
機能毎に機能概要を作成し、機能に対し画面を紐づけ画面一覧、外部インターフェース一覧等の一覧系を作成します。そうすることで業務と機能の紐づけが出来てきます。主な章立ては下記のとおりです。
3.1.機能前提条件
3.2.機能一覧
3.3.機能相関図
3.4.機能概要
3.3.1.●●機能
3.5.画面一覧
3.5.1.ゾーニング
3.5.2.●●画面
3.6.外部接続定義
3.6.1.外部インターフェース一覧
3.6.2.外部インターフェース処理概要
3.7. 帳票・情報・データ要件
3.7.1.帳票一覧
3.7.2.外部ファイル一覧
3.7.3.●●ファイル処理概要
3.7.3.外部データ一覧
ここまでで、「絵に描いた餅」がようやく作れるシステムに落ちてきたはずです。私の経験則ですがステークホルダーが会議体に出席できるってのを条件に1,000マン規模の案件で週2回の定例会を実施した想定で1.5か月くらいの時間を要するかなーと。
ビジネス→業務→機能と連鎖していけばきれいに進むのですが肝心のビジネス要件が固まらない事で遅延が考えられます。
その場合はビジネス分科会と要件定義分科会で分けることをお勧めします。ビジネス系では企画者や経営層、今回のビジネスに参加するステークホルダー（利害関係者）を必ず参加させ、機能定義は別会で粛々と進めて修正修正の手順を踏んでも良いかもしれません。
良く下図を見ますね。
これの「プロジェクトリーダー」の理解をより顧客が説明した要件に近づけつつ、「本当に必要だったもの」を得るにはプロジェクトのリーダーである要件定義作成者のプロの力が必要です。
機能要件は今回定義しているビジネス部門だけではなく、ユーザーの情報システム部門なども交えてより「必要な要件」に決定していくプロセスがビジネス～機能要件定義です。ここで、開発手法や言語、技術論に捕らわれていると「アナリストの設計」に機能要件が陥りがちですので注意を。
ここまで決まってくるといよいよ見積の精緻化を図るため、非機能面での要件定義が始まります。これにはシステムアーキテクトのサポートも必要になるかもしれません。リソースを惜しまず見積の抜け・ブレを全力で減らすためにより具体化していきます。
4.非機能要件定義
ここでようやく「システム屋」としての本領発揮です！
システム化、機能要件の充足に向けて「なるべく具体的に」 徹底的に記述します。ここで考慮漏れや過剰・不足事項があると大きく本見積に影響し上の絵の「営業の表現、約束」に近づいちゃいます。
勘所としては、先ずはここまでで決まった制約やシステム的制約をきちんと前提条件に纏めることです。これ次第でアーキテクトやシステム化設計にも影響大です。また、各種事項においてスペシャリストの参画や援助も必要となってきます。
セキュリティ要件ではセキュリティスペシャリストが、アーキテクチャではアーキテクト、性能や拡張・信頼性（冗長化方針など）にはハードウェア・ネットワークスペシャリストの助言やプロジェクト参画が必要となってきます。
この時点で要員計画も同時に行えると思います。並走させると非常に効率的です。
章立ては以下です。
4.1.非機能要件前提条件
4.2.システム構成概要図
4.3.ハードウェア一覧
4.4.ソフトウェア一覧
4.5.アーキテクチャ
4.6.論理ネットワーク構成図
4.7.物理ネットワーク構成図
4.8.セキュリティ要件
4.9.性能要件
4.10.拡張要件
4.11.信頼性要件
4.12.互換・中立性要件
4.13.環境要件
4.14.品質要件
4.15.移行要件
5.運用要件定義
最後の章では運用・保守に係る要件を書き出します。
実は要件定義書の最後の賞にこれを書くのは意味があります。
ビジネスが決まっていなければ運用は発生しませんし、業務が決まっていなければどう運用をしていくかも決められません。機能・非機能要件がきまってない状態であれば障害ポイントの洗い出しも、障害時の挙動の予測も出来ません。
ここではITELの知識が役に立ちます。運用要件はより具体的に書かれるべきです。システム開発寄りの企業ではこの章を軽視する若しくは記述しない企業もありますが、お客様がシステムを触る段階（案件によって異なりますが）になって非常に困ることになります。
ビジネス部門や運用部門と密にミーティングを繰り返し、前提条件を基に体制やフローを確定していきましょう。
運用要件の正しさを検証するためにも、運用設計を行い更に精緻化し後期工程でコスト面と相談で運用訓練を実施するのも一つの手です。
主な章立ては下記です。
5.1.運用者アクタ定義
5.2.運用前提条件
5.3.運用体制図
5.4.定期運用項目一覧
5.4.1.●●運用フロー
5.5.非定期運用項目一覧
5.5.1.●●運用フロー
5.6.障害時運用
5.6.1.障害発生時体制図
5.6.2.コンテンジェンシープランニング
5.6.3. 障害時対応概要
5.6.3.1.●●障害時対応
5.7.教育要件
5.8.保守要件
6.その他
その他記述すべき勘所ですが、「WBSに影響するか否か」です。私の場合は運用報告書類や、ビジネス観点での書類関連のフォーマットをここで作成してしまいますし、場合によってはモックアップをしてしまったりします。
工数が許す限り開発・運用の具体化をするため労を惜しまず必要書類を作成してください。
今現状、プロジェクトマネージャーをやっている案件が要件定義工程の為、棚卸の意味も含めてこの工程でやるべき事を纏めてみました。
私本人はザッツ器用貧乏なので全工程を1人称でやってしまったりしますが何れにしろお客様の協力が不可欠です。
能書きやノウハウは兎も角、お客様との信頼関係が成功の一番のポイントだと思います。
これから要件定義を実施される方や2次受けでぺらっぺらの要件定義書を渡されて「作ってから考えよう」的な指向でプロジェクトが進んでいる方は上記された内容が要件定義書に盛り込まれているのか、なければ提示いただける、若しくは作成する工数があるか考えてQCD（クオリティ・デリバリー・コスト）のバランスを見て作成した方がその後の設計や実装の約に立つと思います。
ではでは長文失礼しました。