システム設計の登竜門！要件定義入門#１#2では要件定義の基本や概念をご紹介いたしました。今回はその定義をした成果、つまりは要件定義の目指すものをお伝えしたいと思います。システム設計の登竜門！要件定義入門#1#2　で説明したとおり、①要求のあるべき姿が明確である(ToBe モデルが存在する)場合と、②要求が愛味(具体的でない。ToBe モデルは存在しない)、いずれの場合にも対応可能なように、「要件定義」はどうあるべきか、どうするべきかを明確にしていきます。

上流工程とは?

要件定義を含む、システム開発の上流工程について考えてみます。一般的には、上流工程はシステム開発の初期工程を指し、「企画」「分析」「要件定義/機能定義」といった工程で構成されます。反対に下流工程とは、構築·実装·テストの工程を指します。では、上流工程は、どうあるべきでしょうか。何事も最初が肝心です。ユーザが本当にやりたい、やらねばならないことを川の源流とみなせば、そこから流れ出す思いをくみとり、整理した上で、枠組みと方向性、範囲を定めるのが上流工程の役割だと、筆者は考えています。上流工程は源流に極めて近いところから始めるべきでしょう。源流から滴り落ちる“思い”を汲み損ねて、下流へ向かう流れをうまく作ることができなくなってしまいます。水の一滴が川のうねりを経て、大海に注ぐイメージです。そんな上流工程を巧く行うためには、何が必要でしょうか。筆者は、とにもかくにも「コミュニケーションである」と確信しています。そして、「コミュニケーションの価値は受け手が決める!」という当たり前のことを、肝に銘じる必要があります。送り手の独りよがりでは、コミュニケーションは成立しないのです。そしてコミュニケーションを通じて要件を整理し、システムの全体像を構想し、要求に沿ったシステム要件を作り上げていくのです。

筆者は上流工程を以下のとおり定義しています。「“上流工程”を一言で表現すれば、システムのプロと業務のプロとの間で相互翻訳作業を行い開発対象のシステム構想を作り上げる工程である」。言い換えれば、「システム屋と業務屋とのコミュニケーションを円滑にするために、お互いの言語を翻訳し、整理した上で、システム構想を固めていく段階」ということかもしれません。
ここで気を付けなくてはならないのは、あくまでも「相互理解」「相互翻訳」が必須であるという点です。システム屋(開発者)が一方的に業務屋(ユーザ)を理解するだけではダメです。業務屋には、開発されたシステムをツールとして活用し、ビジネスの価値を生み出すことが求められます。システムに対する自主的な理解が求められるのです。その上で各々の立場と役割を明確にし、共同でシステム要件を作りあげていくのです。両者がお互いの立場から必要なアーキテクチャを考え抜き、要求と要件の橋渡しを行い、要件を明確化していく必要があります。その際にシステム屋にとって、「ユーザが要件を提示してくれないから要件定義ができない」といった泣き言は禁句です。いくら「主体的にシステムに関わる」といっても、業務屋は、システムで何ができるか、わかっていない場合がほとんどです。システム屋から積極的に働きかける姿勢が必要です。「思いを言わなかったユーザが原因で要件定義が失敗した」といった言い訳は許されないのです。

思いを汲み取った上で、システムで実現できることをきちんと提示する必要があるのです。さらに要件定義では、「どこまでシステム化するか」といった範囲と制約を明確にしなければなりません。夢ばかり語ってよいのは要求の段階までです。業務屋も後々「こんなシステムだとは思わなかった」といった泣き言は禁句です。出来上がったシステムは自分たちのものであり、それを有効送用してビジネスの成果をあげることが使命だと認識しなければいけません。お互いの役割を認め、積極的に関与しあって共同で作り上げていくという共通認識に立ち、相互理解、相互翻訳を可能としてこそ、システム開発における上流工程が意義あるものになるのです。その上で
・安易に作りに走らない。
・常に目的を念頭において立ち帰る。
・自ら動く。
といった三カ条のセオリーを意識して、要件定義を行うことにより、システム開発を成功に導くことが可能になります。

必要なもの

要求分析、要件定義という工程では、何が必要でしょうか。所謂上流工程でまず認識すべきことは、様々な立場の人間、しかも互いに異なる立場の人間たちが関わり合うということです。そこで必要になるのは、立場の違う者同士が共通認識を持てる仕組み、その仕組みを可能とするツールです。ここで言うツールとは、モデリングツールなどの狭義の開発支援ツールだけではありません。仕事のルールや作業を支援し、開発プロジェクトに有用と思われるツール全般を指します。「ツールなんか要らない。自然言語だけで十分可能である」という考えの人もいるでしょう。果たして言葉だけで、様々な立場の人間同士のコミュニケーションは可能でしょうか。システム開発は共同作業です。立場の違う、時には利害の対立する人々が、当たり前のごとく参画して成り立つものです。自然言語だけでコミュニケーションをとろうとした場合、お互いが架空のイメージを思い浮かべて共同していくことになります。皆が本当に同じひとつのイメージを共有しているのか、誰にもわかりません。そして何の根拠もないまま、だんだんと共有しているものと思い込み始めます。実際にはずれていることの方が多いのに…。こうなるとまさに嘱し絵の世界です。

残念ながら、「自然言語だけでは難しい」と言わざるをえません。特に暖味さを許す日本語の表現は、ディティールを描ける美しさの半面、システムの要件を整理するうえではリスクを孕んでしまいます。では、どうすればよいでしょうか。それは、言葉だけに頼らないことです。架空のイメージではなく、実際に目に見えるように描かれた図版、つまりイメージを可視化したモデルを共有することです。誰が見ても同じ理解を得るように、抽象的なチャート図やフロー図、ダイヤグラム、表の形などにわかりやすくモデル化することが肝要です。開発にもビジネスの現場にも役立つ、強靭かつシンプルな「図式」をモデル可視化ツールとして徹底的に活用するのです。システムは使われなければ「作る人」と「使う人」を繋ぐのが「要件」です。ですから、「作る人」と「使う人」の間で合意がなければなりません。両者の相互理解を可能とするコミュニケーションツールとして、図表が必要となるのです。使うツールは、表現がシンプルでなければなりません。立場の違う者同士の共通言語となって、「何を作るのか」を明確に表わすのです。要件定義が目指すもの#2は今回の記事内容の続きと結論を記載した記事になります、続けてご覧ください。

 

【広告】Librus Tech Communityのお知らせ
Librus株式会社が運営する、システムエンジニアやプロジェクトマネージャーの方向けに展開するコミュニティにぜひご参加ください。「互いに助け合い、学び合う空間」をコンセプトに、システム開発に関するセミナーや勉強会をはじめ、案件や転職先のご紹介、相談対応も行います。エンジニア初心者の方や起業、現在フリーランスをされている方、フリーランスを目指している方も大歓迎です。

▼Slackコミュニティ入会フォーム
https://forms.gle/1D5duKwVJhm1vFb18