概要
IT資源調達で実施するシステム要件定義は、これから導入するシステムがどんなものであるべきかを決めることである。的確な要件定義は経済的で信頼性の高いシステムを構築するには欠かせないが、ソフトウェアというものの特性をおさえて進めないとうまくいかないことも多い。
システム開発プロジェクトの主体はソフトウェア作成
情報システムはハードウェアとソフトウェアから出来上がっている。ハードウェアは余程のことが無い限り注文製作をすることはないが、ソフトウェアは独自開発やパッケージソフトウェアのアドオン開発により注文製作をすることは多い。一般に「システム開発」と呼ばれるプロジェクトは、ソフトウェアの作成が主体である。
発注者の検収段階で生じやすい問題
注文製作のソフトウェアは、設計、製作、テストの工程を経て、動作する品質、つまり発注者が検査できる出来映えとなる。この段階で、発注者が発注した（と想像していた）ものとは違う物が出来上がってくることがある。「項目の並び順は50音順ではなく地域順でなければならない」とか、「マウスでカーソルを移動していたのでは遅くてダメだ」などだ。しかし、ソフトウェア製作の受託者としては、注文内容、これを要件というが、要件を受けて設計書を作り承認してもらっているのだ。
ソフトウェアの特性は「あらかじめ想像しづらいこと」
独自開発のソフトウェアというのは、あらかじめ見て、触って確認ができないため、このようなことが起こりやすい。発注者が要件を出す段階、設計を確認する段階での考慮漏れも多い。倉庫担当者の入出庫入力機能と営業員が検索する在庫情報など、別な部門がデータで連携する機能は、機能そのものを見落としていたなど、大きなレベルでの漏れが生じることもある。
ソフトウェアの特性を踏まえた「要件定義」をつくる
細かなレベルでの仕様の考慮漏れまで完璧にはなくせないのがシステム開発の特性である。細かなレベルであれば、発注者の検査の際に発見されれば改修ができる。しかし、大きな見落としや、根本的な相違のレベルとなると、追加開発や作り直しになってしまう。これは、日程や費用が大きく狂ってしまうことになるため、極力避けたい事態である。これを避けるためには、システムのあるべき姿に関する明細書である「要件定義書」を的確に作るというのが基本だ。
要件定義は、これからシステムを導入しようという企業が、「何が欲しいか」（What)を明確にするものであり、それを根拠に見積り、契約がなされる。これがスッキリと良い物ならば、システム開発プロジェクトは成功の第一歩を踏み出したといえる。
システムの要件だけでなく業務の要件を決める
的確なシステム要件定義をまとめるには、業務の要件が十分に定義されていることが前提となる。業務の流れ、ルール、データ、処理方法が整理されて初めて、その中での情報システムの役割が明確になる。システム開発のテストの段階で漏れが発覚するのは、このあたりの検討が不十分なことによるケースが多い。
業務の要件定義ができていれば、ここからシステムに期待する内容も導きやすい。ITの知識が不足していて、システムに何が期待できるか分らない場合も、業務の要件がハッキリしていればITベンダーからの提案を引き出すこともできる。
さらに、発注後、設計をする段階でも、システム機能の詳細を決めていく際に、何のためにその機能があるかの業務要件が定義されていれば、エンジニアはそれを参考にするので的外れな設計にはなりにくい。
業務の要件定義内容
業務の要件を定義する標準的な内容は以下のようなものである。
１．この業務改革の目的と目標
２．前提とする組織体制
３．業務の流れと各処理手順の処理内容、処理ルール
・業務フロー、業務記述書、付属資料などを作る
４．業務の実績、成果をモニタリングする指標
５．処理ボリューム
・対象データ件数、1日の処理件数など
システム要件定義の内容
システムの実装形態が独自開発かパッケージかSaaSかにより、定義しても意味が無いものものあるが、独自開発で必要な下記内容が最大のものと考えてよいだろう。
１．業務フロー上、システムで処理する部分
・業務要件と併せて見てもらう
２．システムの入出力一覧
３．システムの入出力レイアウトのイメージ
４．非機能要件
・応答時間、運用時間、セキュリティ、システム構成など
５．既存システムの資料、または既存業務のフローやデータ保管方法
・新たなシステムの要件を補完したり、新システムの稼働前に行なうデータ移行設計の参考とする
要件定義作業の留意事項
このように要件定義は重要な工程であるが、次の留意事項は心に留めておいていただきたい。
一つめは、用語と図式化である。要件定義をITベンダーなど社外の人に見てもらうためには誤解が無いようにしなくてはならない。そのためには社内用語は極力避けるか、避けられない場合は用語集を用意する。また、要件定義は図式化を心がけ理解度を高めるようにしたい。
二つ目は、いかにしてこれらを適確に、負担が少なく、短い日程で行なうかである。現在と変わらなくていいものは、現存の資料の流用を考えること、適材適所で役割分担をして担当者にかかる負担を軽減する、などが考えられる。
（執筆：山田一彦）
ブログに関する関するご意見・ご感想はお問合せフォームよりお知らせください。
デジ☆ブログへのご意見・ご感想
ITマネジメント・サポート協同組合では、DXの活用・推進にお悩みの中小企業に向け、DX計画向け解決策提示・スコアリングサービス『デジ☆レシピ』をリリースしました。こちらもご覧ください。
『デジ☆レシピ』サービスご紹介
