Photo by Amtec Photos
こんにちは。倉内です。
システム開発の上流工程の1つに要件定義という工程があります。
要件定義はプロジェクトの成功・失敗を左右すると言われるほど重要な工程で、炎上したプロジェクトをあとで振り返ってみると「要件定義が甘かった……」と思い当たることが多いです。
要件定義が難しいのは、ユーザーの漠然とした課題や要望を引き出してシステム要件として定義するという性質上、プロジェクトごとの違いが大きく、明確な正解というものが存在しないことにあると思います。
しかし、要件定義をおろそかにするとシステムで何を実現しなければならないかがはっきりしないままプロジェクトを進めることになり、設計・開発・テスト…あとのすべての工程で困ることになります。
そこで今回は、なんとなくでやる要件定義はやめて、プロジェクトを炎上させない要件定義を実施するために気をつけたいことをお伝えしたいと思います。
そもそも「要件定義」とは
要件定義は、下図のとおりエンジニア（SE）が関わるもっとも上流の工程です。
ただし、企業やチームによっては役割が分担されており、開発者が要件定義に関わらない場合があったり、SEが保守・運用を担当する場合もあったりさまざまなので一例だと思ってください。
要件定義の目的を簡単に言うと、ユーザーの要望をシステム要件として整理し、お互いの合意をとるために実施します。受託開発では、この「お互いの合意をとる」ことが非常に重要になってきます。それについてはのちほど説明します。
自社開発の場合、ユーザーから要件が提示されるわけではないので、合意をとるというよりはユーザーニーズを調査し、それに応えるという形になるかと思います。
要件定義のあとは基本設計を実施するため、要件定義での成果物は基本設計のインプットになると考えてください。つまり設計時に「全然情報が足りない…これではシステム設計できない…」となるような要件定義は既に失敗しています。
要件定義の進め方
受託開発を例に要件定義の進め方を簡易的な図に示しました。
図にしてみるととってもあっさりしていますが、「合意して完了」までの道のりは本当に大変です…。
それはユーザーが最初に持っているイメージは多くの場合、「システムで実現したいこと」ではなく「こういうことやりたいなぁ」とか「今のやり方だとこういうことに困ってるからどうにかしたいんだよな～」といった要望や課題だからです。
そのためユーザーの要望をスケジュールと予算を考慮し、現実的なシステム仕様として提示するというのがSEの重要な役割です。何らかの要因で実現が難しいものは代替案と根拠を示す必要があります。それらを提案したり、ユーザーから意見をいただいて再考したり…というのを繰り返して合意を目指します。
「受託開発はお客様から言われたまま作ればいいから楽だよね」と言われて、「は？」と思った方は要件定義におけるSEの役割を分かっている方だと思います。
要件定義で気をつけたいこと
1.ユーザー自身「システムで何を実現したいのか」は分からない
先ほども書きましたが、はっきりと「これこれこういう機能をシステムに実装したい！」と言えるユーザーなんてまずいません。よってユーザーが抱えているぼんやりした要望・課題・問題をいかに多く引き出せるかが重要です。
受託開発では業界特有の常識もあるので、ユーザーは当たり前だと思っているけど一般的には知られてないこと（開発側は知っておかないといけないこと）も要件定義で引き出しておく必要があります。
また、ヒアリングさせていただくユーザー側のメンバーのスケジュールや場所の確保も欠かせません。実際始まってみたら忙しすぎて誰も要件定義のための打ち合わせに出席してくれない…なんてことになったら大変です。契約時に「要件定義にご協力いただけない場合は成果物は保証できない」とはっきり決めておきます。
もう1つよくあるのが、要件定義はIT部門とだけ合意してもうまくいかないということです。実際にシステムを使うユーザーとの食い違いは最後の最後に大幅な手戻りを発生させる危険性があります。
「誰が使うシステムか？」をはじめに確認しておき、できる限り実際の利用ユーザーにも要件定義の内容について合意をとるように（直接打ち合わせの場に出てもらうことが難しくても、利用ユーザーの責任者には随時内容を確認してもらう約束する、など）しましょう。
2.技術を知らないと要件定義の質が落ちる
当たり前ですが、要件定義はシステム開発をするために必要な情報を集めて整理する工程なので、技術的知見がある人とない人では精度がだいぶ変わってきます。
いくら業務知識があって要件定義の経験が豊富でも、開発したことがない人が「いくつかやり方はあるが一番いいのはこの方法だ」とか「これは実装に現実的じゃない工数がかかる」とか見通しを立てることはできません。
また、要件定義のミス（ユーザーとの認識違い、機能の考慮不足や検討漏れなど）はコードの修正はもちろん、テストのやり直し、設計書をはじめ各種ドキュメントの修正など大幅な工数増加・スケジュール遅延を引き起こす原因となってしまいます。
なのでいくら上流工程メインのSEになると言っても、基本設計・詳細設計・開発を見据えた要件定義ができる、機能実装に必要な開発工数を見積もることができる技術力はあったほうがいいと思います。
paizaラーニングでは、プログラミング言語の基礎からLaravelやDjangoといった、人気のフレームワークを使ったWebアプリケーション開発まで動画講座で学ぶことができます。
詳しくはこちら
3.曖昧な部分をできるだけ残さない
100％曖昧さをなくすことが理想であり、それができたら何も言うことはありません。
しかし、特に新規システム（既存システムの改修やパッケージカスタマイズではない）は要件定義段階で完璧に決めることはかなり難しいです。
もしスケジュールの都合などで議論しきれず、曖昧な部分が残りそうなときは「○日までにこちらからA・B案を出して、×日までに回答いただけなければA案でいきます」など対策が必要になってきます。
システムにとってクリティカルな部分じゃなければ（例えば表示色・文言など）後回しにすることもありますが、それも含めて「じゃあ最終確定日はいつにしますか？」というのは決めておく必要があります。期日までに決まらないと、あとの工程に影響が出ることをユーザーにも必ず認識してもらってください。
また、やりがちなのが「○○機能は既存システムと同じ」という要件定義です。既存システムも自分たちが開発したなら（100歩譲って）まだいいのですが、他社システムのリプレースでそれをやると完全に死亡フラグです。
画面1つとっても表示する項目・色・文字サイズ、レイアウト、遷移…などなど要素はたくさんあります。「ボタンをクリックしたら次のページに移るというのは既存システムと一緒だけど、送信するデータ項目は増えていた。でも要件定義で漏れていた…」といった事態を避けるためにも手を抜いてはいけません。
少なくともシステムの必須機能については完璧にユーザーの要求を顕在化できたかをしっかり確認してください。
（参考）準委任契約と請負契約
受託開発では、業務委託契約の形態として、準委任契約と請負契約というものがあります。それぞれの詳細はこちらの記事が分かりやすいのでご参考ください。
準委任契約は作業した期間に対して報酬が支払われ、瑕疵担保責任がありません。あくまで主体はユーザーにあり、開発側はサポートをしますよということで要件定義は準委任契約で実施することが多いです。
とは言え、多くの場合成果物として要件定義書を納品するでしょうし、善管注意義務といって委任された業務をまっとうする義務も発生します。
4.要件定義では「現実的」かどうかを常に考える
システムにはそれがないとユーザーが業務を遂行できない（目的を達成できない）「必須機能」と、あると便利・役立つが「なくても問題ない機能」とがあります。
要件定義でユーザーからヒアリングをすると、「なくても問題ない機能」に分類できる要望がたくさん挙がってきますが、すべて聞き入れていると予算もスケジュールも合わなくなるため、必須かそうでないかを切り分け現実的に実装する・しないを判断することが大切です。
また、性能やセキュリティといった「非機能要件」は定義が難しく、特に性能については「テストデータでは3秒で応答していたが、本番データが膨大すぎて1分経っても処理が終わらず性能要件を満たせない…」などのちのち問題になることがあります。現実的な目標値を慎重に検討しましょう。
大規模プロジェクトで開発SEだけでは検討しきれない場合、インフラ専門のSEに協力してもらうこともあります。
なぜこれほど「現実的」を連呼するのかと言うと、要件定義で理想を語りすぎるとあとで苦しむからです…。要件定義だけしてプロジェクト完了ならいいのですが、実際に開発をして本番稼働・安定運用までを見据える必要があります。
要件定義工程でのアウトプット
実際に要件定義工程では何を決めて、成果物として何をアウトプットすればいいのかについても少し触れておきます。
ここでは「既存のシステムが古くなってサポートが切れるので、新システムの開発・導入をユーザー企業がシステム開発会社に依頼した」という状況で考えてみましょう。
要件定義のためのインプット情報
はじめに前提として知っておかなければならない情報を挙げておきます。
ユーザーから出されたRFP（提案依頼書）、プロジェクト開始時に作成したプロジェクト計画書に記載されている内容もあれば、ヒアリングや資料提供の依頼を必要とする場合もあります。
- システムを導入する背景と目的
- 予算とスケジュール
- システムの全体構成
- 既存システムの情報（仕様書や設計書が望ましい）
- 現行の業務フロー
- 何をもって要件定義完了となるか：要件定義のゴール
これらの情報が不足していると要件定義がスムーズにいかない確率が上がります。
特に既存システムや現行業務の調査が甘いと手戻りが発生する原因になるため、確実に実施したいところです。また、要件定義のゴールはユーザーとよく認識合わせをしておきましょう。完了条件を決めておかないとあとで何度も変更されたり、言った・言わないの泥沼の議論になります。
要件定義で決めるべきもの
システムで何がしたいかにあたる「機能要件」はもちろん、画面の応答時間やデータ処理速度といった性能のこと、将来データが増えた場合の拡張性、セキュリティなど「非機能要件」も定義する必要があります。
機能要件：
- UI（システムに必要な画面（画面遷移・レイアウト）、帳票類）
- 機能（機能一覧表や機能階層図、システム間インタフェース）
- データ（データ項目一覧、データ量一覧）
- システム導入後の業務フロー
- ソフトウェアアーキテクチャと実装技術*1
- パッケージ製品を活用する場合は既存システムとのFit＆Gap
非機能要件：
- システム移行（移行対象システム、手順やスケジュール）
- システム運用・操作（手順、ユーザー教育などスケジュール）
- 性能要件（応答時間など性能目標設定）
- セキュリティ要件
実際の成果物はIPAがサンプルつきでまとめているページが参考になります。
超上流から攻めるIT化の事例集：要件定義：IPA 独立行政法人 情報処理推進機構
また、非機能要件について網羅的に理解するなら同じくIPAの「非機能要求グレード」に目を通すとよいかと思います。
システム構築の上流工程強化（非機能要求グレード）：IPA 独立行政法人 情報処理推進機構
要件定義を学べるオススメ本
- 作者:羽生 章洋
- 発売日: 2015/02/28
- メディア: 単行本（ソフトカバー）
何はともあれこれをまず読みましょう。要件定義の基本から実際どうやって手を動かすかまで、非常にシンプルにまとまっていて分かりやすいです。
- 作者:水田 哲郎
- 発売日: 2017/11/17
- メディア: 単行本
要件定義を訓練するというのは難しいのですが、この本はいい感じに網羅していて実務でも役立ちそうな内容になっています。
2冊ご紹介しましたが、要件定義に関する本はあまり多くないので、研修を受けるのもありかなと思います。SIerなら若手SEは必須研修になっているかもしれませんね。
もしくは要件定義がうまい人というのは社内に必ずいるはずなので、探してみて実務を通して学んでみるというのも一つの方法でしょう。
大変だけど面白いのが「要件定義」
ここまで読んで「要件定義ってこんなに大変なの…」と思った方もいるかもしれません。
確かに冒頭に書いたとおり、プロジェクトの成否に関わってくるので気楽な工程ではありません。ただ、あらかじめ決められた仕様に沿って開発をするより、自分でお客様といろいろ議論しながら仕様を決めるというのはとても楽しいです。
お客様はシステム開発にあたってどうしたらいいか分からない場合が多いと書きましたが、当たり前ですが業務についてはプロフェッショナルです。課題解決のためにこちらから提案した内容についてもたくさん意見や指摘をいただくこともあります。
その後、検討を経て採用していただき、本番稼働後に「あの案にしてよかった！」「業務効率がすごく上がった！」と言われたときは本当にうれしいですし、やりがいがあります。
これは個人的な意見ですが、逆に「要件定義だけ」やるのも少し退屈かもしれません。SEはコンサルタントではないので、やっぱりお客様と要件決めて、実際作って、テストして、納品して…という工程を経たからこそ面白いんだと思います。
お客様の要望をしっかり仕様に落とし込み、あとの工程を燃やさない要件定義を心がけたいですね。
まとめ
「要件定義とは何か？」から始まり、要件定義で気をつけたいこと、アウトプットするものなどをお伝えしてきました。
要件定義は受託開発だけに関係するイメージがあるかもしれませんが、ユーザーがシステムに期待すること、システムに必要な機能や性能、それらをどのような技術で実現するか…などは自社開発・受託開発に関わらず、あらかじめ定めておいたほうがよいと言えます。
エンジニアとして、システム化にあたりユーザーニーズを踏まえた要件整理・定義ができることは1つの強みになるでしょう。
要件定義スキルはプログラミングスキルのように可視化することは難しいですが、紹介した書籍も参考にしながら、炎上せずにプロジェクトを完遂できる要件定義を極めていってください。
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
詳しくはこちら
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら
*1:要件定義前に方針を決めておくべきだという考え方もあります。
