目次
Contents
要件定義とは
要件定義と混同されがちな言葉として「要求定義」があります。
要求定義、要件定義はどちらもシステム構築における上流工程となりますが、それぞれの定義としては以下のとおりです。
・要求定義：システムに求めるものを書き出したもので「～したい」と記述されます。
・要件定義：システムの機能や非機能要件、運用要件、保守要件を取り決めたもので「～すること、～が必要」と記述されます。
簡単に要約すると、要求定義はお客様の「システム化の目的を明確化」し、目的達成のために必要な要求を書き出していく工程であり、要件定義はその目的や要求を実現していくために必要なシステムの機能や、動作のスピード、稼働時間やその担保の方法を具体化して取り決める工程となります。
これまでの慣例として、要求定義や要件提示の実施主体は発注者（すなわち顧客）であり、それを基にRFIやRFPを行い、構築業者を選定。サービス利用前提のプロジェクトであれば、業者ごとのパッケージシステムと、顧客の求める要件とのFit＆Gapを実施し、最終的な「業務要件」「機能要件」「非機能要件」を決めていくのが一般的ではないでしょうか。
この他、特定のパッケージを持たずにフルスクラッチで顧客要望の全てに答えたシステムを作るという手法もあります。
私自身の経験としては、基幹システムの改修、刷新の経験が多いため、
今回のブログでは基幹システムの改修、刷新に焦点を当てて書きたいと思います。
基幹システムの改修、刷新の要件定義はおおまかに以下の流れで行います。
◇ユーザーに要求をヒアリングする、要求定義書を読み解く
・どういう業務運用をおこなっているのか
・どんなことに困っているのか
◇ユーザーの要求を要件定義書に落としこむ
・業務要件、システム要件を定義する
・要件から機能分解を行い、機能一覧、業務フロー、システムフローにする
◇落とし込んだ一覧、フローを元にユーザーと意識を合わせる
・要求が網羅されているか
・業務運用した際に適切な流れとなっているか
要件定義の工程はユーザー側、開発側共に不明点、違和感等クリアにし、業務上発生していた問題点を解決するための方法を明確にしていく必要があります。この時点ではユーザー側も「要求定義」があやふやな認識である事が多く、不明確な点が残ったままだと、後の工程や実際の運用時にトラブルが発生しかねません。
トラブルが起きないよう、ユーザーのイメージと開発していくシステムに認識のずれがないかをすり合わせる重要な工程です。
要件定義の心がけ
今までに私が携わってきたプロジェクトで、要件定義に取り組んだ際に
どのような事を意識してきたかを簡単にまとめました。
◇要件をシステム化すると業務効率が向上するのか
注意点は必ずしも「ユーザーの要求を全て網羅し、ユーザーのイメージ通りのシステムにすること」＝「正解」ということではありません。
もちろん、「開発者側のイメージ」＝「正解」ということでもありません。
どのような部分をシステム化すると実際の業務効率があがるかどうかを
ユーザーと協力して検討し議論を重ねる必要があります。
時には現場で実際にシステムを使用する人たちに直接ヒアリングを行う場合もあります。
◇色々な運用場面を想定できているか
通常業務の場合はもちろんのこと、緊急事態が発生した際にも運用を継続できるのか、
対応(リカバリ)できるシステムとなっているかを考える必要があります。
また、業務は必ずしも全てがルーティン化されているわけではありません。
イレギュラーな対応をせざるを得ないケースは必ずあります。
ユーザーの要求には目に見えて現れない事もありますので、
どこまで業務をリアルに理解し、想像できるかが重要になります。
◇できる限りシンプルに
色々な要求を盛り込んだ機能はあたかも便利に見えますが、複雑な仕組み、操作だと「使いづらい」と思われ、
結局使われない事があります。また、後々機能の拡張がしづらい、制約がかかる、メンテナンスで苦しむことになってしまいます。
そのため、出来る限りシンプルな機能、且つ機能毎に分離されている方が良いです。
◇期間、予算内におさまるか
当たり前のことですが、システムを開発するには期間、予算が必要です。
要件をすべて取り込めるのが一番ですが、要件定義が膨れ上がった場合は
要件に優先度をつける、機能を縮小する、段階的なリリースにするなど
場面、場面に応じて臨機応変な提案を行い、期間、予算内に収めるよう
行動する必要があります。
要件定義あるある
過去に私が要件定義の際に実際に体験したあるあるをまとめてみました。
◇要件定義が言葉の羅列になってしまい、ユーザーとイメージを共有出来ていなかった
言語化することは重要ですが、言葉だけの要件定義だとイメージを共有しづらい部分もあります。後々の工程でイメージと異なるということになり、戻り作業を経験したことがあります。文字ベースで合意していても、画面を目の前にすると細々とした気になる箇所が多々発生してきます。想定内の内容で機能に落とし込んでいれば良いのですが、全てを網羅することはやはり難しく、それ以降は簡単な画面設計でも早い段階でイメージを作成する事にしています。
◇ユーザーと盛り上がり過ぎて、膨大な開発計画となってしまった。
ユーザーと打ち合わせした際に話が弾んで色々なアイデアが生まれることがあります。
ユーザー側のご担当者とも意気投合！はりきってＷＢＳに落とし、工数算出。。。と、調子よく進めたものの、最終的にはSTOPがかかり、要件定義のやり直しになったことがあります。
この時は、ユーザー側のご担当者、チームで大いに反省し、落としどころを見つけるのに苦労しました。
◇既存機能の有識者が少ない
歴史のあるシステムだと、開発者側、ユーザー側どちらも機能の詳細な動きを
把握しきれていない事が多々あります。よくいわれる「ブラックボックス」です。
後々の工程を進めていくと想定していた流れ、処理と異なる事が発覚し
一から要件定義をやり直すということがありました。古いシステムはドキュメントが残っていないことも多く、特に注意が必要です。このような時、やはり重要なのはお客様の業務を知っていること、システム稼働後の運用をよく定義し具体的にイメージすることです。ユーザーは既存システムの動きや現行の運用方法を基準に考えている事も多く、それを尊重しつつ引っ張られ過ぎないことが肝要だと思っています。
おわりに
今回は、要件定義について紹介しました。
要件定義に関する情報はインターネット上、書籍などで豊富に公開されていますが
実際に要件定義を行うと山あり谷ありで非常に大変な工程です。
その分非常にやりがいのある工程で、実際に改修したシステムが実運用された際にユーザーからお褒めの言葉を頂いた際には感極まるものがあります。
弊社はこれまでに様々なユーザー様のシステム開発を要件定義から携わらせて頂きました。
「業務をシステム化して効率化したいけど何から始めたらいいかわからない」などで
お困りの際は弊社にぜひご相談ください。
次回は要件定義あるあるで失敗してしまった際に私がどのように考え、どう行動して
解決に進んだかをご紹介致します。
記事 ： K.M
