開発工程の中の要件定義の説明です。
１．要求定義との違い
要件定義のINPUTは要求定義書です。要件定義書は、要求定義に記載された「やりたいこと」に対して、「やること」を決める工程です。
夢を見ていた人たちを現実に戻す作業が要件定義です。
要求定義と要件定義の違いって、実は難しいです。両者の間のグレーゾーンは非常に広大です。でも実際のプロジェクトでは、この違いはほとんど気になりません。
何故か？
要求定義と要件定義の違いは、現実のプロジェクトでは、単に作った人の立場の違いだからです。事業会社のシステム部門やシステム子会社が作れば要求定義書で、受託したベンダーが作れば要件定義書です。もっと言えば、要件定義工程で作ったドキュメントが要件定義書で、それより前の工程で作ったドキュメントが要求定義書なのです。中身には関係なく・・・。
要求定義は「やりたいこと」、要件定義は「やること」をどちらも「ユーザー」と決めていくので、実際のところたいした違いはありません。
スキルの高いシステム部門やシステム子会社が作った要求定義書は、ほとんど要件定義書とイコールなので、その場合のベンダーの要件定義は「お勉強」のような感じになります。もっと言えば、システム部門やシステム子会社が内製で開発するのであれば、要求定義をやる必要はありません。
要求定義が不十分であれば、要件定義の受託者であるベンダーはリスクを大きく乗せますし、要求定義がきちんとしていれば要件定義のコストを抑えられます。要求定義＋要件定義のトータルのコストは、実はあまり変わりません。強いて言えば、要求定義をきっちりやればキャッシュアウトを減らせますが、そのためには、それなりに強いシステム部門あるいはシステム子会社が必要です。ベンダー丸投げがいいのか、内製強化がいいのか、正解は無いので、システム部門やシステム子会社は、振り子のように外注と内製の間を行ったり来たりします。
２．要件定義でやること
要件定義で作成する成果物は、基本的には「要件定義書」と呼ばれる「要求定義書」と似たようなフリーフォーマットのドキュメントです。
非機能の要件定義を実施する場合には、以下のような標準化されている非機能要件の項目があり、機能の要件定義よりも定型化されています。
・可用性
・性能、拡張性
・運用、保守性
・移行性
・セキュリティー
・環境
一般的に多くのプロジェクトでは、要件定義は準委任でベンダーと契約をして、要件定義が終わった後、基本設計以降の工程を請負で契約をします。そのためユーザー部門としっかり要件の合意をして、基本設計以降に仕様変更が発生しないようにすることが重要です。
３．スクラッチ開発とパッケージ利用の違い
スクラッチ開発とパッケージ利用では、要件定義の進め方が異なります。
スクラッチ開発の場合には、ストレートにユーザー部門と要件を決めていけばいいのですが、パッケージ利用の場合には、パッケージと要求内容とのFit&Gapを実施します。
パッケージの機能をユーザー部門に紹介しながら、「パッケージの標準機能で実現できる要求」と「実現できない要求」を整理していきます。実現できない要求に対しては、
・要求を少し変更して実現するもの
・パッケージをカスタマイズして実現するもの
・パッケージとは別でアドオンで開発をして実現するもの
・要求を取り下げるもの
といった整理をします。
パッケージによってはカスタマイズが一切できないものもありますし、方針として極力、カスタマイズをしないプロジェクトもあります。一般的にはパッケージのカスタマイズをすると、パッケージのバージョンアップ時に費用が増えると言われていますが、カスタマイズ可能なパッケージの場合には、カスタマイズの有無でバージョンアップの費用に差が出ることは少ないです。
またパッケージ利用の場合、企画や要求定義の段階で複数のパッケージとFit&Gapを実施して、パッケージを選定済みの場合が多いです。この時のFit&Gapが中途半端だと、要件定義のFit&Gapで致命的なGapが出て、ユーザー部門の不満が高まることもあります。
４．要件定義の例
紙で回付している稟議書のワークフロー化の要求をもとに要件定義を考えてみます。
要求①
「社外秘は、同じ部署の人は全員が参照、ダウンロード、印刷が可能」
ここでのキモは、「同じ部署」です。会社の組織体系は複雑です。「部、課、係」「部、担当、チーム」といった呼び方があったり、部と室の関係も複雑です。
経営企画室の下にシステム企画部がある会社もあれば、システム企画部と経営企画室が同列にある会社もあれば、システム企画部の下に調達室がある会社もあります。
要件定義では、人事システムで管理している組織の階層が、要求を満たす階層構造になっているかを確認します。例えば「部、課、係」という組織階層の会社で、例外的に「室」があって、この「室」は「部」と同列で、「室」の下には組織が無い場合があったとします。このときの「同じ部署」が「部」や「室」であればいいのですが、「課」や「室」だと、「課」は第二階層、「室」は第一階層なので、権限を与える際に工夫が必要になります。
要求②
「厳秘は、稟議を回付した人だけが参照のみ可能で、ダウンロードや印刷は不可」
この要求は厄介です。ダウンロードや印刷の制御はアプリケーションでは不可能です。パソコンでの制御も全社的な影響が出てしまうため、一つのアプリケーションの要求で対応するには現実的ではありません。
そのため要件定義では、システム対応はせず運用ルールでの対応で合意形成を図ります。単に「運用で対応して下さい」だけだと難色を示されることもあるので、利用者への牽制や事後での追跡が可能なように、稟議書へのアクセスの記録を保存するシステム対応の提案をします。
要求③
「稟議を起案したタイミングで稟議番号を発番する」
ここでは稟議番号の体系を確認します。総務部の稟議番号であれば、「総務-2020-001」とか「総-2020-厳-001」とか。稟議番号に厳秘等の機密区分が含まれる場合には、機密区分ごとに連番を振るのか、機密区分は関係なく連番を振るのか等も確認します。
この稟議番号の体系などは、業務ルールなのでスキルの高いシステム部門やシステム子会社であれば、要求定義書に予め記載しているので、要件定義を省略することができます。このような感じで、要求定義書と要件定義書は境界が曖昧で、要求定義書に記載されていないことを要件定義で補ったりします。
要求④
「起案した稟議は稟議整理簿で、年度ごとに管理できる」
ここでは、稟議整理簿の出力方法や保存期間を確認します。画面での表示以外にCSVでのダウンロード機能があると便利です。ダウンロードができれば、保存期間は長くなくても問題ありません。３年度分はシステムで参照できるようにするけど、それ以降は自分でCSVダウンロードして保存して下さい、といった提案をします。
要求⑤
「回付ルートは、起案者の所属と決裁者によって自動で決まる」
ここで重要なのは、組織改正や異動時のメンテナンスです。人事システムから異動の情報が連携されれば、回付ルートにいた人を自動で除外することはできます。でも誰が代わりの人なのかはシステムでは判断がつきません。
メンテナンスは人手でやってもらう必要があること、予約機能が必要か、回付ルートに設定された人が異動した場合にお知らせ通知が必要か、仕掛かり中（回付中）の稟議の扱い等を決めていきます。
【振り返り】
今回は要件定義の説明でした。次回は基本設計の説明をしていきたいと思います。
