システム発注者が後悔しない要件定義のための準備とは？

• システムの開発経験が少なく要件定義とは何かがわからない
• 要件定義がシステム開発でどのような位置づけになるのか

システムを発注する側の方は、一般的に開発経験も少ないため、「要件定義」という言葉にも馴染みが薄いのではないでしょうか。

システム開発は、開発者がリードしてくれるだろうと受け身にならないでください。
むしろ、発注者がリーダーシップを取るくらいの姿勢で臨んでください。そうしないと、後から痛い目をみるかもしれません。

この投稿をご覧頂きますと

• 要件定義で行うべき作業内容の概略
• システム開発における重要性

がご理解頂けますのでぜひ最後までご覧ください！

このコラムの内容は動画で公開しています。
「システム発注者が後悔しない要件定義のための準備とは？」Youtube版はこちらをご覧ください。

要件定義とは何か

単純に言うならば、どんなシステムを作るのかということを具体化する工程ですが、理解を深めていただくために、あるサイトに掲載されていたITパスポート試験の問題に対する回答の定義を参考にしながら説明を加えます。
そこでは、次のように定義しています。

これはこれで正しいですが、私はこれにとても大切な点を付け加えたいと思います。
それは何かと言うと

• システム開発の目的を関係者全員が理解する
• 開発者が誤解なく把握できるようにする

以上の2つです。
これを追加すると要件定義とは、

となります。
ここに含まれる7つのキーワードについて、個別に説明をします。

①システム開発の目的を関係者全員が理解

システム開発においては、「何を目的として開発するか」を明確にし、関係者全員が理解する事が大切です。なぜなら、開発工程が進むほど目先のこと、細部ばかりに目がいくようになり、システムの完成が目的化され真の目的から遠ざかることは、よくある事だからです。

一方で、目的は抽象的である事も多く、関係者全員が理解することは困難な事も事実です。
では、抽象的ではなく、具体的に数値で目標設定をすれば理解できるかと言うと必ずしもそうではありません。

例えば、本件システム開発の目的は本事業における利益率を10%向上させる、と言うように数値化したとします。現場の担当者一人一人が経営視点を持てというのも言うは易しですが、「利益率10％向上のために、自分の仕事をどうシステム化すればいいのか？」ということもピンとこないでしょう。開発者側でも、プログラマが自身が開発するプログラムと、真の目的との関連は理解できません。

しかし、だからと言って、目的をおざなりにしてはいけません。システム開発に関わる発注者の関係部署は当事者であるので当然ながら、開発者側のプロジェクトマネージャー、プロジェクトリーダー、そして設計をするSEに最低限の目的意識を持ってもらうため、そして開発中、決断に迷った時の指針にするため、目的を明確にし理解するのです。

②新たに構築する業務

この「業務」という言葉は、単純にひとつの業務と捉えることもできれば、事業という大きな括りで捉えることもできます。いずれにしても、日常的に行う仕事・作業のやり方をどのように変えるのか、あるいは新たにどう作るのかを決めなければなりません。

例えば、既存のシステムを再構築する場合で、昔の汎用機で作られたシステムをクラウドに置き換えるとしたら、全ての機能を単純にそのまま作り変えるというのはいい選択と言えないので、新しい業務フローに置き換わる部分がでてきます。

あるいは、DXを行うにあたって新しい事業を作る。こうした場合でも、そこではどんな仕事・作業をどう行うのかということを決めなければなりません。

このように、システムを構築・導入することによって、業務がどのように変わるのか、どのように行うのかを定義すること、それが「新たに構築する業務」ということです。

③システムの仕様

システムの仕様とは、そのシステムがどのように動作するかを記述したものです。例えば、会員制のECサイトを作るとするならどのような仕様が想像できるでしょうか？

• 買い物をするには会員登録が必要
• 商品の検索は、キーワード、価格帯、商品カテゴリ、色で絞り込むことができる
• 商品をかごに入れたら、「この商品を買った人は、この商品も買っています」とお勧め商品が表示される
• 会員ランクによって、商品の価格が異なる
• 会員ランクは3ランクあり、年間の購入金額で翌年のランクが決まる

などでしょう。

さらに細かく考えるなら、会員は現在までの購入金額が分かるようになっており、後いくらでランクアップできるのか、「この商品を購入すればランクアップ確定」のように購入を促す、といったことが仕様として求めるところになるかもしれません。
また、サイトの主な利用者は40〜50代、パソコン・スマホ両方で利用できる、などユーザの特性を決めておきます。

④システム化の範囲

システム化の範囲をスコープと言う事もありますが、ただですらシステム用語に慣れていないユーザに対して、横文字を使う必要がないので、私はシステム化の範囲で通してます。コンサルタントと称する人はとかく横文字を使って権威を出したがることが多々ありますから。

先述した新たに構築する業務というところで、仕事・作業をどのように行うかを定義すると説明しました。システム化を極論すると、全ての業務をシステムが自動で行えることが理想でしょう。しかし、コスト面、技術面等から、なかなかそうはいきません。

仮に「洗濯」を業務とするならば、洗って乾燥までは全自動洗濯機ができますが、洗う衣類を洗濯機に入れる、乾燥後は洗濯機から出してたたむ、という部分は人手が必要です。

システムも同様、業務全てを全自動でできないとなると、どこを人間が行うか？あるいはシステムでできたとしても、その業務の頻度を考えるとシステム化はせずに、人が対応する。あるいは、そこは必ず人間の目を通す、ということが必要になることもありますし、他のシステムと連携できればミスがなくなる場合も、最初の構築ではあえて外すという判断があり得ます。

システム化の範囲では、システム開発の目的に照らし合わせて、業務のどの範囲をシステム化をすることが最適か考えて、その範囲を定義します。

⑤機能

これは画面だと分かりやすいです。ECサイトのシステムだと、会員登録、商品検索、カートなどが一つ一つの機能であり、これらの機能はどんな項目で構成され、どのように画面が遷移する、など具体的な動作内容を定義します。例えば、会員登録で登録する項目は、名前、住所、電話番号は必須、生年月日、家族構成を任意とするなどです。

また画面の遷移は図式化した方がいいですが、「登録画面、確認画面、登録完了画面へ進み、完了後はログイン状態のままトップ画面を表示する」と言ったように定義します。

⑥利害関係者間で合意

利害関係者はシステムを直接利用する人だけには限りません。システムの開発・運用に関わる人はもとより、経営層、マーケティング部門、製造部門、経理部門、カスタマーサービス部門など、そのシステムの内容次第ではあるものの、複数の利害関係者が存在するはずです。優先順位はあれど、利用の中心となる人だけが満足するのではなく、システムで登録されたデータを使って別の業務を行う人、データを分析する人、導入効果測定をする人などそれぞれにとって、必要なデータや機能が満たされているのかなどの合意を取っておかなければなりません。

⑦関係者が誤解なく内容を把握できる

まず、申し上げたいのは、発注者の常識はシステムの開発者には通じないものだと思ってください。同じ会社の人間であっても、入社一年目の新人にベテランが行っている業務が直ぐに理解できるでしょうか？慣れてしまえば普通に使っている業務の専門用語も新人さんには通じませんよね？その感覚を忘れないで頂きたいのです。

システムの開発者は、システムの開発に対しては専門家ですが、発注者であるあなたの業務については、素人だと考えてください。入社一年目の新人さんに等しいと思ってください。

一般的な経理業務、人事業務で、開発者がその業務に精通していることもあるでしょう。その場合は対等に会話できるかもしれませんが、自社独自の業務の処理の仕方があることもありますから、「これは常識だろう」と思い込み説明を省略することなく、開発者が独自の解釈をしないよう誤解なく内容を把握できるようにする必要があるということです。

要件定義の重要性

要件定義とは何かを解説してきましたが、既に「何やら重要そうな作業だ」ということは感じていらっしゃるのではないでしょうか。私としては、「要件定義を制するものは開発プロジェクトを制す」と言っていいくらい、システム開発では、要件定義が最も重要であると申し上げたいのです。

開発経験がない方であっても、「システム開発が失敗して訴訟になった」「何百億のシステムを中止せざるを得なかった」そんなニュースを耳にした事があるのではないでしょうか？システム開発の失敗の原因のほとんどは要件定義という統計もあります。裏を返せば、要件定義がきっちりとできていれば、システム開発の成功が近づくのです。

開発失敗の一つに、予算オーバーがありますが、これも要件定義の出来不出来に直結します。要件定義の後工程となる、設計・開発は全て要件定義の成果物である要件定義書を元に進められます。

要件定義で、抜け漏れがあれば、当然漏れた機能は開発されません。「とても大切な業務の一部が要件から漏れており、設計途中で発覚した。そのために設計変更が生じ、その影響範囲が広く、追加見積もりが発生した。」ということは珍しくありません。

設計時に分かればまだしも、プログラム開発を終えてから要件の漏れが発覚したなら、設計に遡って追加・修正し、かつプログラムも追加・修正となりますから、工程が進めば進むほど、影響度合いが大きくなるのです。

プログラムはソースコードはあるものの、発注者は目に見えないものなので「これだけの変更なのになぜそんなにコストがかかるのか。」と思われます。これが建物だとしたなら「外観が出来上がっているのに、やっぱり間取りを変えてほしい。2部屋を1部屋にするだけだから」と言っても、強度の設計を見直し、壁を壊して、という手戻りの作業が発生することに等しいものだと理解してください。

要件定義はユーザがリーダーシップを持とう

繰り返しになりますが、システム開発は発注者側は経験が少ないのが一般的。「それなのに、よくわからない要件定義のリーダーシップを持てと言われたところで、無理。」と思われることでしょう。その通りだと思います。

実際の作業が始まったら、開発側が計画を立て、ヒアリングが始まるので、それに対して回答し、時には資料を作成して提示してと、進んでいきます。慣れない作業ですから、その進行を開発側に委ねるのは構いません。

しかし、事前に要件定義に対する知識を持ち、準備をしておくことで、作業は円滑に進み、抜け漏れも抑える事ができるようになります。なにより、業務をよく知っているのは発注者側であり、作りたいものは発注者が1番よく分かっているはずです。

システム開発は、システムの専門家に任せるのではなく、専門家の持つ知識を利用しながら自分が作りたい、作らなければならないシステムのイメージを固めていく。発注者と開発者、どちらが真の主役か。主役は発注者である自分自身という意識を持てるかどうか。
その意識を持つという事が、ユーザ側がリーダシップを持つという事なのです。

まとめ

システム開発の経験が少ないと、要件定義は必要なのだろうか？と思うこともあるかもしれません。

そもそも要件定義とは、システム開発の工程の1つ。「要件定義を制するものは開発プロジェクトを制す」と言えるほど重要な工程です。その気持ちを持って要件定義に入り、不備のないよう的確に、ユーザがリーダーシップを持って、開発に臨みましょう。