要件定義のアクティビティ
案外、何も考えずになんとなく進めているエンジニアの方も多いと思いますが、要件定義と呼ばれる工程あるいはプロセスの中では大きく３つの課題が存在します。それが
要求をいかに引き出すか（=抽出）
要求をいかに可視化するか（=整理）
要求をいかに管理するか（=管理）
です。
この３つを満たす作業を適切に構築できなければ、次工程に進んでも満足のいく設計作業ができず、確実に手戻りが発生する時が来かねません。仮に手戻り作業が発生しなかったとしても、それは問題や課題に気付かずに作業が進んでいるだけであり、システムテスト以降やリリース後に必ず大きな問題となって襲い掛かることでしょう。
これはシステム開発プロジェクトにおいて、マネジメントが不得意なプロジェクトマネージャーやエンジニアがよく経験するトラブルです。そもそもＩＴ企業のなかで「設計」や「実装」、「テスト」についてはある程度定型化されているものの、要件定義となった瞬間ものすごく
ふわっと
した内容しか教えてくれないところは多いものです。少なくとも私がこれまで渡り歩いてきた企業では１社もありませんでしたし、プロジェクトの中でかかわった他ベンダーでもほとんど見たことがありません。現場のリーダーやプロジェクトマネージャーにしても、ググってわかる程度の概要は説明できても具体的な道筋までは決して教えてくれません。そのためなんとなくプロジェクトに参加して、なんとなく経験し、言語化されないままなんとなく経験則だけで「こんな感じ」としか説明できない組織ができあがってしまっているところが多いのではないでしょうか。
仕様変更、あるいは"仕様通りでない"と言う問題でお客さまと揉めるケースの多いプロジェクトではしばしばこういった事例が見受けられます。
ではこの３つの課題を実際に達成するための作業とは、どのように構成されるのでしょうか。またその作業プロセスごとにどのようなアウトプットを残し、どのような情報が次の工程に引き継がれていくべきなのか考えてみましょう。
必ずしもすべてのシステム開発で一律同じというわけではありませんが、一般的な業務システムであれば極々最低限のものとなると次のようなものがあります。
個人的にはもう少し足したいところですが「最低限」といえばこのくらいでしょうか。
要求をいかに引き出すか
この工程を担当するエンジニアやプロジェクトマネージャーにとって必要な資質の１つに「コミュニケーション力の高さ」が挙げられます。残念ながら技術力だけが高くてもこの工程では不足です。
すべての工程／プロセスを俯瞰してみたとき、この能力が如何なく発揮されるのはまさにこの「要求管理」分野においてではないでしょうか。裏を返せば、この分野においては確実に成功率に影響を与える能力といっても過言ではありません。
こうしたヒューマンスキルは本人の性質に依存することが大きいのですが、コツさえつかめば得意／苦手に関わらず要件定義において必要とされるコミュニケーション力を高めることは十分可能です。なぜならコミュニケーション能力とは「話す/聞く」や「書く/読む」といった手段のことを指すものではないからです。
コミュニケーションの本質は、相互に
認識した情報が伝わる（共有する）
共有された情報が必要なあいだ維持される
ことです。言ってみれば、この本質的な目的が達成できるのであれば手段は問わないということです。
そして、この要求管理分野において「引き出す（=抽出）」過程で手段を問わず重要となるのは質問の仕方です。具体的には
開く質問 と 閉じた質問
の使い分け方となります。これらの質問方式を有効に活用することで、お客さまから要求を引き出し、重要度や決断を促すことが可能になるのです。
開く質問とは文字通りユーザの口を開かせる質問で、 Yes／Noで回答できない種類の問いを指します。一般に「5W／3H」（何、どこ、誰、いつ、なぜ、どのように、どれくらい、いくらくらい）といった問い掛けです。
これに対し、閉じた質問とは基本的に 「Yes／No」「はい／いいえ」 形式で答えることができる質問のことを意味します。お客さまから要求を引き出すには開く質問を使い、決断を求めたり事実を確認するときには閉じた質問を使う…というように、２つの質問スキルを適切に使い分けることで、スムーズに要求を引き出せるようになります。
そしてこれらの要求がどのような特性を持つのか分析し、システム領域に最も最適な形で反映させていくことになります。
お客さまの要求事項は、そのタイプと構造として「機能要求」と「非機能要求」という２つの軸に分け、それぞれ
ビジネス
ユーザー
システム
という３つの視座で区分けします。
ビジネスレベルとは主に経営層によるビジネス戦略上の成果や要望になります。そもそもお客さまは自社のビジネス課題を解決し、収益を改善・向上するためにＩＴ投資をしています。この目的が果たせなければＩＴ投資する意味がないといっても過言ではありません。
エンジニアはただ「言われたものを作ればいい」と思っているかもしれませんが、その通りに作ったからと言って必ずしもお客さまのビジネス課題を解決できるとは限りません。
それはこの有名な風刺画が物語っています。
私たちは少なくともＳＩ（System Integration）領域においてはお客さまと比較になるべくもないプロフェッショナルなわけですから、その大前提を無視した対応をとるべきではありません。
このことを念頭にビジネスレベルの視座に立って、課題解決できるようにしましょう。それができなければ「Solution」なんて言葉、恥ずかしくて使えません。
ユーザーレベルとは業務現場からの機能要望や使い勝手にかかわる要望となります。対して非機能要求とは一般に「非機能要件」といわれているものとほぼイコールであり、システムインフラに関与することも多くなりがちです。こうした非機能要求をミドルウェアやアプリケーションフレームワークなどに組み込むことで、再利用を促進できるというメリットも生まれます。
要求をいかに可視化するか
言い換えるなら
「抽出された要求をいかにモデル化するか」
ということでもあります。モデル化することで洗い出された要求の内容と実現可能性を確認するというメリットが生まれます。また各ステークホルダー間において情報共有や管理・統制がしやすくなるという側面も出てきます。
要求管理のフェイズにおいて、最大の肝となるのがこの"モデル化”です。
モデル化の目的は、エンジニアたち開発側の認識を可視化するということもありますが、本当に重要視すべきは
お客さまとエンジニアのイメージを共有しやすくする
点です。
日頃、お互いに全く異なる領域でビジネスを行っていますので、用語１つとっても同じ解釈となっているとは限りません。そのようななかで「仕様書」と称して文章をだらだら書いたようなドキュメントを作成しても、お互いがお互いの解釈によって理解した気になっているだけで、認識は全く異なっていた…ということは往々にして起こりえます。
その認識祖語のハードルを限界まで引き下げることで、初期工程におけるコミュニケーション不良を低減させることが「モデル化」の真の目的です。
要求を可視化する手段として、ビジネスモデルやビジネスプロセスモデル、DFD（Data Flow Diagram）、状態モデル、イベントシーケンス図、概念クラス図、概念オペレーショナルモデルなど多くのモデル表記法が有効です。
これまでトラブルプロジェクトだけで50以上、全プロジェクトというと70～80件ほど関わってきましたが、ＵＭＬやＳｙｓＭＬのような図表化したモデル表記法を活用しているプロジェクトというのはあまり見たことがありません。
組み込み系の一部などでは率先して用いられている分野もあるようですが、少なくとも業務システム系、技術要素でいえばWeb系の開発現場ではあまり見かけません。そのため書き方どころか読み方すら知らないエンジニアも非常に多いのです。そういう現場ではお客さまのＩＴリテラシー云々以前にいろいろ心配になってくることも出てきます。
モデル化の中でも案外重要となってくるのは、アーキテクチャ構築のための
メタモデル
の重要性です。アーキテクチャも様々ですが、そのメタモデルとは機能と非機能２つのモデルで構成されます。お客さまからの機能／非機能の要望をモデル化して、
仕様
詳細
物理
の３つの側面から分析し、融合させていくことが重要になってきます。データベース設計の場合であれば「概念→論理→物理」と設計段階を踏んでいきますよね。アレと同じようなものだと考えてください。物事にはなにごとも段階というものがあるのです。
しかし、このことを理解していないプロジェクト現場も多く見かけます。
特に非機能に関しては設計作業や設計書のようなものさえ存在しないことも多々あります。
たとえば、トランザクション設計や排他設計などは機能単位で行いません。システム全体の包括的なアーキテクチャに関わってくる部分です。しかし要件定義工程においても「何を作るか」「どう作るか」にばかりかまけて機能設計さえ済めば早々に見積りをしようとするプロジェクトマネージャーも出てきます。
少なくとも私はその結果、ある公共系プロジェクトにおいて排他設計をロクに検討しておらず、データの不備によって国際問題となりかねないようなシステム障害を目の当たりにしたことがありますし、たった１ヶ月で400kstep以上の規模もあるシステムの解決に従事したことがあります。ほぼ１人で。
実際には解決プロジェクトに割り当てられたメンバーは４人いたのですが、２名はもう１つの課題解決に従事しており、１名は別件で精神的に病んでしまって来なくなってしまったので、たった１人で全調査、全解析、解決策提示、その証明、改修、検証、etc.…実施することになりました。んなアホな。やり遂げましたけども。
要求をいかに管理するか
最後の課題は「要求の管理」です。
ここでいう"管理”とは、物理的な文書管理はもちろん、変更が生じた場合のトレースやインパクト分析も含めています。ただ情報を把握するだけの簡単なお仕事ではありません。
さらにもう１つ、要求管理の実践において必要なのが
「ベースライン管理」
です。
一般に、ベースライン管理というとPMBOKなどに挙げられるようにプロジェクトマネジメントの領域と思われがちですが、それは違います。プロジェクトマネジメントにおいて必要なのは
「どのようにベースラインを定義し
そのベースラインに変更が生じたときにどのようにコントロールするか」
を計画管理することを言います。
ここでいうベースライン管理とは、あいまいな要求の"ベース”となる起点を暫定でもいいのでまずは決定し、そのベースに対してどれだけ変更が加えられたか、その内容や遍歴を把握・理解することです。
しかし、変更やその履歴を管理することは非常に大変な労力を伴います。単純なEXCELやWORDなどの履歴管理だけでは、記録としての管理はできても、おそらくプロジェクトの全体最適という観点では破綻してしまっていることでしょう。
結果、プロジェクトマネージャやエンジニアの多くは"記憶"と言う曖昧な媒体をもとに仕様を取り決めていくか、あるいは冗長的な記録を大量に作成し、後で見直すこともできない資料の山を築いていくかを実施することになります。
知恵よりも根性や体力でどうにかしようという発想に行き着いてしまうのです。
そしてその先にはほぼ確実に情報の管理ができず、どんどんと後手に回り、悪いときにはトラブルとなって大炎上を起こしてしまうという状態を招きかねません。
よって、必要とわかったそのうえで変更が頻繁に発生する要求管理を効率的に行うには、市販のツールを含めた何らかの『仕組み』が必要となります。こうしたところに投資できないプロジェクトは正直近寄りたくありません。だって、不毛で冗長的な業務を大量に生み出し、残業や休日出勤を強制するようなプロジェクトに成り下がっていることでしょうから。
しかもそうした冗長的なコストはスケジュール的にもコスト的にも一切考慮されていないのが通例です。確実に負け戦が待っているわけです。
「要求は開発するシステムの制約にかかわるうえ、頻繁に変更や手戻りが発生する」
「トレーサビリティを確保するには、手作業ではなくツールの仕組みが必要になる」
この２つの認識は必ず要件定義の時点で持つようにしましょう。ベースラインは要件定義工程で設定するものですから、設計工程以降になってからでは確実に後手に回ってしまうことになります。
ツールを導入するメリットは２つあります。
１つはステークホルダー間の情報共有がよりスムーズになること。
もう１つは、変更履歴のトレースやインパクト分析がしやすくなることです。
コミュニケーションツールとしても一役買いますので、余計なもめごとも減ることになります。マネジメントプロセスでいうところの『変更依頼管理』は基本的に見積りの工数やコストにも計上されていないことが多いため、ここで無駄に工数を費やすとそれだけでマネジメントを圧迫しかねません。
一方、デメリットとしてはツールの導入により発生するオーバーヘッドの存在です。
たとえば変更履歴のトレースやインパクト分析を実行するには、事前のデータ入力やメンテナンスが欠かせません。何事もそうですが適切に管理するためには、インプットの時点で統制がとれている必要があります。
日頃からそうした文化や風土に慣れていない組織では、どうしてもオーバーヘッドがかかってしまうことでしょう。
こうしたイニシャルコスト（=初期投資）と呼ばれるオーバーヘッドを吸収する１つの目安が開発期間となります。3～4カ月未満のプロジェクト程度の場合はメンテナンスと開発スピードのバランスが取りづらくなりますので、あえて不慣れなツールを利用することは控えた方が良いかもしれません。
また、一般に要求管理に対しては何らかのツールは必要となるものですが，メリット／デメリットをしっかり考慮すると必ずしも高機能なツールでなくても構わないという実情もあります。
プロジェクトの要求特性の中で「要求を可視化し」「管理する体制を作り上げる」ことが最優先と位置付けられるような特性がなければ、無計画・無思慮にツールに依存してしまっていては逆に効率を阻害することにもなりかねないという点は覚えておいたほうがいいでしょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。