要求はカカシを使って引き出す
要件定義の終わりはお客さまが決めてもいいのですが、たいていは上手くいきません。基本的に開発側が決めるつもりで取り組みましょう。
逆に、それができないようであればそれはエンジニアやプロジェクトマネージャーとして、まだまだ要件定義に関わっていいほどの力量にないことを意味します。
理想は、エンジニアたちが
「お客さまのニーズをすべて吸い上げた」
「お客さまのニーズを実現するイメージができた」
「業務課題の整理ができた」
という納得を得て、その状況を見てプロジェクトマネージャが宣言すればそこで要件定義は終わります。
お客さまが口を挟むことはまずありません。
たとえ要件が漠然としていて仕様を詰め切れていないと感じていたとしてもです。
お客さまは性善説に従い、こう考えます。
「開発側はリリースまでに帳尻を合わせ、
最終的には要求を全て満足してくれる。
高い金を払っているのだから、その責任は自覚しているはずなのだから」
と。その基本的な姿勢は、仮にリリースが１週間後に控えているような状況であっても変わりません。自分たちは金を払う立場であって、その金に見合う「成果」と「期限順守」は開発側の責務であると考えているからです。
しかし、開発側の立場からしてみればたまったものではない…と思うこともしばしばあります。
そもそも、うまく進まない問題はお客さま側にあることも多いからです。
「〇ヶ月前に仕様は確定したはず」
「追加事項は変更管理に載せて採用可否を判断すべき」
といったプロジェクト活動の本質的な進め方を簡単に覆そうとすることも多々あるからです。ですから、開発側にとっては不満もあるかもしれません。私もそう思っていたことはありました。
とはいえ、プロジェクト活動自体は以前から言っているように
となっている以上、杓子定規に考えても問題は解決することはありません。
開発側は、開発をプロジェクトという形でビジネスにする以上、その本質的な基準を理解する必要があります。そして、いかなる契約形態であろうと、オーダーメイドでシステムやサービスを提供するスタイルである以上、お客さまが求めるシステムやサービスでなければそのプロジェクト活動自身に価値はまったくないからです。
完成後にお客さまの不満がでないよう、要求を事細かく合意しておく必要があるという状況自体が変わることは絶対にありません。
そして、要求を精緻に把握するには「発掘活動」が必要となります。
文字通り、開発側がお客さまの中に眠っている要求を掘り起こす作業となります。
「業務のどの範囲をシステム化の対象とするか」
「それが本来のもくろみを満足させられるのか」
「お客様のビジネス上の課題や問題は解決するのか」
「過剰にシステム化をしていないか」
「どのような機能を作るか」
といった観点を確認します。
この時点から全力で責任逃れをするために「スコープ」を定義することばかり注力するプロジェクトマネージャーなんかをたまに見かけますが、最初からお客さまと向き合う気がないプロジェクトマネージャーやエンジニアをみるとイラっとします。
大事なことは「いかに効率的にお客さまから必要な情報を引き出すか」です。
要件定義という工程においてそれ以上に優先していい観点はありません。
ここで
①ニーズをすべて掬い上げ
②それらのニーズをすべて整理し
③お客さまと共有したうえでニーズの実現可否を決定し
④その決定内容に齟齬を生じさせない
という取り組み以外は、ほとんどノイズでしかありません。
たとえば、下図のように請求書をシステムから発行する取り組みがあったとしましょう。
開発側では、いろいろと確認したい事項が出てくるはずです。いえ、出てこなければおかしいはずです。
けれども、これらすべての確認事項について逐一問い合わせて、情報を整理しようとすると相当時間がかかってしまいます。プロジェクトは有期性の活動である以上、無限に満足するまで整理し続ける…というわけではありません。それにすべてが必要な情報とも限らなかったりします。ただでさえ短い要件定義の時間を浪費するのは、プロジェクトマネジメントの本質から考えても絶対に避けたいところです。
また、要求の整理も難しいケースがあります。
ほんの少しでもＩＴに知見のある同じ会社の情報システム部門などが開発してくれるというのであればまだしも、外部のＩＴ企業の場合はお客さまの実業務の全てを知っているわけではありません。
お客さまから「こんなニーズを実現して欲しい」と言われると、エンジニアはお客様の業務や事業にとって本当に必要か否かも判断できず、いわれた通りに受け取ってしまいがちです。
一見、必要なさそうに見える機能でも、業務を知らないためユーザ部門へ論理的に反論することはとても難しいのです。
そう言うときは「カカシ」を使いましょう。
資料が生煮えの状態で「これでどうだろう？」と、あえてお客さまへ聞いてみるのです。
人は白紙から答えを作り出すのは、発言にも一定の責任が伴ってしまうためとても嫌がりがちですが、すでに誰かが用意してあるようなものは平気で批判しがちです。
意見を出すのは苦手なくせに
指摘をする立場になれば饒舌になる人
みなさんの周りにはいませんか？
私の周りはそんな人たちばかりです。
ですから、あえてそういう人の性質を逆手にとって、指摘しやすいように不完全な状態でアイデアを提示するわけです。そうすれば、相手に間違えを指摘してもらいやすくなり、聞いてもいないのに「誰かを指摘する立場にいる」と勘違いして気分よく饒舌に語ってくれるようになります。そう誘導されているとも知らずに。
そして、そうやって相手をコントロールできるようになれば、その分だけ早く正解にたどり着けるようになります。
まさに釈迦の掌の上で踊る孫悟空です。
ポイントは、あえて批判を覚悟で仮説を立ててしまうことです。
ちなみに私は、全修正することを前提にあえて資料を作り、プレゼンなどに挑むことが多々あります。「何かありませんか？」とは聞きません。大筋のシナリオだけをしっかりとつくり、あえて不完全と分かっていながら不完全な状態のままツッコミどころ満載の状態で提案するわけです。
誰かに案を直接求めることはありません。
指摘という形で彼らの頭の中にあるものを聞き出します。
たとえば「請求書の送付形態」を決めるとしましょう。
まず「請求書は送付せず、システムからPDF形式ダウンロードします」と言い切ってしまいます。すると、お客さまは反論します。
「それは困る。FAX送信をする機能が必要なんだ」
と。さらに
「うちは〇〇なんだから」
と背景や根拠まで含めて聞きもしないのに懇切丁寧に説明してくれるわけです。
この理由を説明してもらうところが重要です。
実現すべき要求事項／要件の根拠となる部分だからです。
これを「請求書はどのような形で出力すればよろしいでしょうか？」と聞くと、なかなか説明してくれる人が出てこなかったりします。
「PDFをダウンロードできるようにししたい」
「メールで送付もできるようにしたい」
「紙で郵送もありうるので印刷できるようにしたい」
「ある加盟店へはFAXを送信していたかもしれない......」
「こうしたい」「ああしたい」という意見があふれ出すことにもなりかねません。システムやサービスを利用する以上は、ある程度整理することで冗長業務の低減やコスト低下などに紐づけられなければ意味がないのですが、どうしても既存業務をなぞることしか考えられなくなっていきます。
ですが、人は「これは違う」と感じたときに自分が本当に欲しいものをようやく理解するものです。その習性を利用して、批判という手順をあえて踏ませてから必要な理由を聞き出すようにするのです。
理由…すなわち根拠の背後にはかならず真の要求が隠れています。
わざわざ指摘を受けなくてはならないような完成度の低い資料を作るのも、大舞台で見せるのも、多くの人にとって抵抗があることでしょう。
人は誰しもよく思われたいし、怒られたくもないと考えています。
「クレームが出ないように100点の資料を作りたい」と考えるのは当然です。
それでも、こと要件定義に限って言えば、その発想はリスクにしかなりえません。
最短でミッションを完遂するためには、あえて表向き泥をかぶっているかのように見せて、水面下ではすべてをコントロールしている…そんな緻密なマネジメントも必要になってくるのです。
覚悟を決めてカカシに取り組めば、見合うリターンは得られるはずです。
試しにやってみてください。
面白いようにコントロールされてくれる人が出てきますよ。
いいなと思ったら応援しよう！
