要件定義の極意は「急がば回れ」①
要件定義は開発するシステムの仕様を決める重要なステップです。
開発側のＩＴベンダーから見れば多くの場合、プロジェクトの最初の工程となっているのではないでしょうか。
「ソフトウェア品質」という観点から見るといかんせん要件定義は諸々表現しづらい工程ではあるのですが、「プロジェクトの成功率」と言う観点から見るとこの工程は非常に大きなウェイトを占めているため、なんとも複雑な気持ちになります。
いわば、「ソフトウェア品質とプロジェクトの成功は強い結びつきが無い」と言われているような感じがしますから。まぁそんなことは決して無いんですけど。
要件定義は「プロジェクトが終了するまでの質」に大きな影響を与え、ソフトウェア品質は「プロジェクトが終了してからの質」に大きな影響を与える…と言えばいいでしょうか。これが何のことを言っているかはいずれまた機会があれば触れていきたいと思います。
さて、そんな要件定義ですが先述の通り、出だしでつまずくと以後のプロジェクト運営にも様々な面で支障をきたします。
そんな責任重大な要件定義をスムーズにこなし、以降の開発に禍根を残さないようにするためには作業に着手する前に綿密な計画を立て、準備を整えておく必要があります。
「要件定義の準備」
と聞いて首をかしげた方もいるかもしれません。「受注し、プロジェクトのスタートが要件定義であり、プロジェクトのスタートとともに要件定義に着手している」という現場は少なくないはずですから。
特に2000年以降、ビジネスの変化の速さや顧客側の都合もあって開発期間が短縮傾向にあります。
「設計や製造の期間を確保するため、早めに要件定義に着手したい」
「なにを作ればいいかわかれば先に進めるからそれだけ確認しておきたい」
と考える開発現場の気持ちは分からなくありません。しかし、見切り発車で要件定義を始めると泥沼に陥る可能性が高いのは先のグラフの通りです。
たとえば、次のような感じのプロジェクト…エンジニアのみなさんの中には経験したことがある人も多いのではないでしょうか。
プロジェクト開始後、なんとなく要件定義…という名の機能に対する設計が始まり、打ち合わせを重ねる。開発側にとっては「なにを作りたいか」を早々に決めたいと思い、顧客にとっては「なにを実現したいか／解決したいか」を明確にしたいと願っている。しかし、ＩＴリテラシーが伴わない顧客としてはなかなか要件定義の主導権を握ることは難しく、開発側がコントロールしようとするものだから業務や運用などを強くイメージするような検討範囲が明確でないため本当に必要な仕様を決められず、役割分担も明確にできない。そうこうしているうちに進捗が思わしくないことに気付き、契約やスケジュールの都合から課題の多くを後工程に先送りする。そして期日までに何とか中身の伴わない「要件定義書」と言う名の成果物を作り上げる
（後工程以降ではほぼ使われることがない）。
実際、こうしたプロジェクトを目にしたことは一度や二度ではありません。
そういうプロジェクトは非常にわかりやすく
要件定義成果物と設計成果物のトレーサビリティが切れている
要件定義成果物とシステムテストのトレーサビリティが切れている
となっているはずです。また、要件定義成果物がただの設計書になっていて「そうすることで顧客の抱える課題や問題が解決できるのか」「そうすることで解決できた効果はどの程度なのか」などが検討されることが無いまま進んで、後々要望の変更や誤りに気づいてひっくり返される…ということが起きる…というケースもたくさん見てきました。
もし、本気で「要件定義を成功させたい」と考えるのであれば、作業を開始する前に一息ついて綿密な計画を立て、しっかりと準備しておいた方がいいでしょう。
インプット評価
業務改革やＩＴコスト削減などプロジェクトとして発起する目的はさまざまですが、そうした目的が何もないところにゼロからシステムを導入するなんてことはまずありません。
大半のプロジェクトではすでにシステムが稼働していて、それを利用した業務フローが回っているケースがほとんどではないでしょうか。そしてそこにある何らかの課題や問題をシステムの改修や刷新によって解決したいというのが一般的なＩＴ投資です。
システムを構築するエンジニアやマネージャーがこの現状を正しく理解しなければプロジェクトの目標達成はおぼつきません。
そしてそのことを正しく理解し、要件定義を進行しようとするのであれば、その際に最も重要なインプットとなるのが
「既存の業務フロー」と「既存システムの設計書」
となります。開発側はまずこの２つのドキュメントから過去の経緯を理解することから始めましょう。要件定義がスムーズに進められるかどうかの鍵を握る重要な存在です。
そしてそんな重要なインプットとなるものだからこそ、エンジニアは「ドキュメンテーション」のスキルを最大限磨いておく必要があるわけです。要件定義で作成する成果物…たとえば要件定義書などと呼ばれるものは、次の改修や刷新プロジェクトでは間違いなくインプットとして用いられるもので、その存在や内容、可読性などがそのまま次プロジェクトの成否を決定する可能性があるからです。
そして残念ながら、これらのドキュメントがあてにならない…というケースは珍しくありません。みなさんもご経験はないでしょうか。
RFPもなく、当時の仕様を確認する術がないプロジェクト
要件定義書が存在しないプロジェクト
「要件定義書」と言う名のただの設計書しかないプロジェクト
機能要件だけはあるけど、業務要件は存在しないプロジェクト
要件定義以降、最新化されないまま進行したプロジェクト
業務フローなどの要件定義成果物だけでなく、設計工程以降の成果物にしてもシステム開発時に担当者が作成したきりでメンテナンスされていないようなケースは頻繁に目にします（だから「ソースが正」みたいな悪習が根付くわけですが）。また、「よくこんな情報だけで実装できるな…」と思わせるような最初から情報が不足しているお粗末なドキュメントもよく見掛けます。
結果、既存システムの業務フローや既存システムの設計書の品質が低いと、次プロジェクトにおける要件定義は非常に難航します。もちろん既存情報や過去経緯をいったん白紙にもどして
「現状の運用を踏まえてもう一度１から検討しましょう」
と言えれば問題はないのかもしれませんが、それでは顧客の求める「短納期」「低コスト」は実現できません。
プロジェクトを成功させるという前提のもとに要件定義の見通しを立てるためにも、これらのドキュメントには事前に必ず目を通したいところです。
そして「記載されている情報が実態と合っているか」関係者にヒアリングして確認しましょう。差異がある場合は、関係者にアップデートを依頼するのです。
「更新の時間が取れない」
「どう整理すればよいか分からない」
と言われた場合は、（役割定義や責任スコープを明確にしたうえで）開発側で担当してもかまいません。その際には業務とシステムの現状をきちんと説明してもらう必要があります。とにかく、業務とシステムの実態を整理する場を設ける必要があるのです。
ただし、こうした作業はとにかく時間がかかります。
中規模以上のシステムであればスムーズに進んだとしても最低１～２週間、基幹システムにもなると数ヵ月は要するかもしれません。要件定義の工程内に持ち込むとスケジュール遅延の原因にもなりかねない点は注意が必要です。
そうした場合は要件定義の期間外で現状把握の作業をこなせるよう調整するというのも１つの手です。
たとえば「インプット情報の品質が悪い」と判断した時点で関係者に説明会を開催してもらい、業務の実態について口頭で説明してもらう…といった手段です。
顧客側にしても、管理職ならば自社の主要なシステムの業務フローやシステム設計書がどこに保存されているのかを棚卸ししておいた方がいいでしょう。いざとなってから「見つからない」「最新化されていない」状態では、様々な責任を問われることになりかねません。
ここまで説明してきたように、この手の問題を解決するためにどうしてもプロジェクトの中で対応しようとすると「再整理に時間がかかる（=短納期化が困難になる）」「開発側から追加請求される（=低コスト化が困難になる）」ため、結局自身の社内評価を落とすことになってしまいます。評価を落とすだけならまだしも、責任を問われることにもつながりかねません。
「各ドキュメントが最新の状態にメンテナンスされているか」
「情報の精度が十分に記載されているか」
などは都度評価するようにしておきましょう。一般的にＩＴシステムのライフサイクルは５～10年と言われています。ですからシステムはいつか刷新するものとして身構えてかなくてはなりません。こうした既存の情報整理を軽視していると、次の改修や刷新で失敗することになるのは歴史が語っています。
ミーティングの頻度
要件定義では、現在の市場の変化に対応すべく業務やシステムのあるべき姿を定め、そこに介在するニーズを整理して具体的な実現の方法を検討するものです。そのための場として、業務や機能、非機能、移行、運用/保守といった単位でミーティングを設けることになります。
ここで悩みの種となるのが「ミーティングの頻度／回数」です。
何回開催すれば要件が確定するのか正確に見積もるのは非常に難しいものです。しかし、実際のプロジェクトでは具体的な根拠がないままミーティング回数が決まることも多いのではないでしょうか。
たとえば「業務部門の都合で週に2時間2回しかできない」とか、「過去の経験から見積書と受注処理は4回、出荷は3回でいい」といった具合です。私が見てきたこれまでのプロジェクトでも提案書や見積書を見る限りでは、一律「１回/週」とか「月曜/水曜」とかだいたい固定化されていました。
ただ、こうした思考停止した固定見積りは後々の苦労を生むことになりかねません。
「週に１度では回数が足りず、要件を決めきれなかった」
であったり、
「途中で回数を増やしたが、出席できずキャッチアップできなかった」
という話はよく聞きます。もちろん簡単なことではありませんが、顧客の抱えている課題の難易度や検討対象となっているシステム規模を前提に何らかの根拠を持ってミーティング回数を算出することが必要ではないでしょうか。
こうした見積りについては、実はコツがないわけではないんです。
ポイントは業務や機能で分解し、一つひとつのミーティングで検討する範囲を狭くすることです。通常、逆を想定しますよね。「毎度毎度関係者の日程を調整するのが大変だからまとめてやってしまおう」とすると思います。
発想を逆転させてください。
１度にまとめてやろうとするから多くの関係者を巻き込まなければならず、だから日程調整が難しくなって、ミーティング頻度を落とすしかなくなるんです。
業務や受注処理といった粒度で考えると、対象が広過ぎて検討事項の量がイメージできません。
「業務を構成しているモノ」
「業務で必要とされている考え」
といった単位で分解すると、どれぐらいの議題があるのか目処を付けやすくなります。分解すればするほど、そこに関わる関係者は少なくなっていきます。そうすれば日程の調整は格段に容易になっているはずです。あとはそうしたやりとりをナレッジ化する仕組みさえ整えておけば、圧倒的に齟齬が起きるリスクを低減することが可能です。
また、業務や機能を分析する上で気になったポイントについても打ち合わせの場を設けておくといいでしょう。
たとえば見積書発行の業務であれば、「入力内容を簡素化すると業務効率化できそうだ」「発行から承認までのワークフローが形骸化しているので、廃止や一括承認を検討できないか」「全てを見積書形式で発行する必要はないのでは」といったポイントを発見するかもしれません。
このような"気になるポイント"についても、それぞれ検討の場を設定するわけです。ここでもあまり１度にやろうとしないことです。そうして関係者を長時間拘束しようとするとまた日程の調整が困難になるだけです。１時間のミーティングを設けるのではなく、30分や10分で済むような形にすることで日程調整難度をグッと低下させることを検討しましょう。
また、全体最適化の観点から影響度や実現性や優先度、手間を考えて、各業務での要件を取捨選択する場というのも検討したいところです。「全体共通」のミーティングと「個別の業務や機能」のミーティングとは分けて考えた方が良いことも多々あります。
たとえばこのような内容であった場合、
まず、業務部門から要件定義チームに対して、既存業務の全体像と既存システムの課題を説明してもらうといいでしょう。業務とシステムの規模によりますが、まとまった時間を設けて多くても２回の開催で全体感を把握したいところです。
そして利用者の作業環境や業務内容、システムの課題といった個別のテーマを掘り下げていきます。こちらの回数は内容次第、規模次第となっていくでしょう。初回は、業務部門に議題について説明してもらう場とし、その後具体的な検討に入っていく…というながれでしょうか。各テーマごとに２回ぐらいレビューの場を設定、ミーティングの予備日も１回は組み込んでおきたいところです。
業務の機能を整理した後、マスター関連の設定項目や画面遷移、画面イメージ、権限管理などいわゆる『機能仕様』を検討することになると思います。
マスター関連の検討回数は、単純参照であれば1回、ロジックが関連する場合は２～３回が妥当ではないでしょうか。
画面遷移と画面イメージは、既存システムの画面数を参考にしましょう。おおよその感覚ですが、２画面で１回の開催と考えてみるといいかもしれません（帳票の検討も同様）。それ以上多くするとまとまった時間の確保に難航するかもしれません。また権限の整理は10画面で１回くらいを目安にして、業務単位で複数回に分けるなどあまりまとめすぎないような開催を目安にすると整理しやすいのではないでしょうか。
そして最後に個別の機能を検討した後、機能間の影響と採用可否を整理していきます。複数の機能にまたがる要件は、個別の機能を検討している際に処遇を定めていることでしょう。しかし、全体を整理するために最低でも２回はミーティングを開催する必要があります。１度目は共有と課題の洗い出しを行って課題解決の役割や期日を設定。２度目にそれらの解決案を持ち寄り採否を確定します。当然２回目で確定しなければずるずるとミーティング回数を増やさざるを得なくなりますので、それまでに根回し…と言う名の各関係者との情報共有なども必要になってくるでしょう。
「どんなミーティングを開催したいか」を定義すれば、後は「誰が参加すべきか」「いつ開催すべきか」を計画するだけです。議題が決まっているので業務部門に参加要請しやすい点も利点となります。
サンプルとして業務について例に挙げてみましたが、非機能やインフラを含むアーキテクチャや運用についても考え方や段取りは同様です。「全体」と「個別」で分けて、個別の中を具体的に考えるアプローチが有効となってきます。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。