ひとことでいえば要件定義です。
ただ、要件定義とひとことで名詞でいってしまうと、なぜそれが必要なのかが見えなくなります。機械的に要件定義と呼ばれているものを満たそうとする。要件定義をするにはそれなりに理由があるのですが、その理由のことなどは頭の片隅でも考えないまま、ただ要件定義と呼ばれる作業を機械的にこなすだけになったりします。それではダメです。
では、要件定義をする理由とはなんなのか？
1つには、多くの仕事がほかの大きな仕事の一部だったりするからです。
B2Bの業務委託型のビジネスから消費財の製造・販売まで。自分のやった仕事がほかの誰かの仕事のインプット・素材として使われることは多いはずです。自分の仕事が相手の仕事の出来を左右することもある。だから、相手はあなたの仕事の出来／不出来に文句もいえば賛辞を呈することもあるのです。
そうであるからこそ、自分の仕事に何が求められるかは、相手がそれを受けてどんな仕事をしようとしているかでほとんど決まってきます。何を自分の仕事のアウトプットとして最終的に提示するのかを最初に相手と握れていなければ、あとで双方とも困ることになる場合もあるでしょう。
自分の仕事が階層化された構造のなかにあると意識すること
自分の仕事はほかの誰かが仕事をするためのインプットです。その誰かの仕事もおなじように、また別の誰かの仕事のインプットになるものです。多くの仕事はこのような大きな階層構造の全体のなかにあると捉えたほうがよいでしょう。にもかかわらず、クライアントと最初に仕事の仕様を決める際に、この仕事の階層構造をイメージできない人は少なくありません。相手の要求、置かれた状況をろくに確認せずに一方的に「自分たちにできること」を一般論的に並べてみせるだけで仕様を確定しようとする人が案外多かったりします。
既製品を販売する仕事なら、売れるものの種類は最初から決まっているのですから、そうするほかないのでしょうけど、受注生産の仕事やコンサルティングのような依頼を受けてからアウトプットの制作がはじまる仕事においては、客の要求にどれだけ仕様をフィットさせられるかはひとつの肝であるはずです。
ここが最初に固められていないと、あとでクレームになる可能性があったり、満足度が低くなってしまうことがあるのは、皆さん、ご存知のとおりです。
そうならないためにも、自分の仕事は階層化された大きな仕事全体の構造のなかにあると意識することは大切だと思います。
要件定義作業にも情報デザイン能力が必要
でも、それがわかっていたとしても、実際に、その仕事に何が求められているかをきちんと明示したうえで、それに対応した仕様を確定するというのはなかなかむずかしいことです。まぁ、簡単ではありませんが、基本的なスキルとそのための方法がわかっていればできないことではないし、何度かやっていればコツはつかめてきます。ただ、そうはいっても要件定義のための基本的なスキル、方法というものをわかっていない人も案外多いようです。これも「判断力は情報デザイン力、物語化の能力」で判断力を、「自分の視野を広げるためにも他人の意見には耳を傾けなきゃ」では視野の広さを、それぞれ情報デザインの問題と考えたように、根本的には情報デザイン力の問題です。
- 相手が何を必要としているかを理解するために適切な情報を入手する
- 相手から情報を入手するために、相手と話をするなかで適切な質問を投げかけ、情報を引き出す
- 入手した情報を整理しながら、相手のおかれた状況を把握すると同時に、相手が何を求めているのかに関する仮説を組み立てる
- 組み立てた仮説を相手に提示して、相手が求めていると自分が思っているものに間違いはないかを確認する
この組み合わせで、自分の仕事の目的や具体的なゴールとして何をアウトプットすればよいかを明確にしていくのです。
結局、ユーザー中心のデザインで、ユーザーの利用状況を把握し、ペルソナ／シナリオ法を使って要求分析～要件定義をするのとおなじことです。
いや、受注生産であれば、顧客が特定されているのですから、むしろ、その作業は楽なはずです。その意味では受注生産でクライアントの要件も理解できないようでは、目の前につねに存在するわけではないユーザーの利用シーンやニーズを把握しながらデザインを行うユーザー中心のデザインなんてできないんじゃないかと思ったりもしますね。目の前の客と仕事の要件定義に関する話もできないユーザビリティ・エンジニアなんてありえないでしょうね。
5W1Hで相手の仕事の依頼背景・ニーズを把握する
では、相手の状況を把握し、相手が求めているものがどういうものかを理解するには、具体的にはどんな情報を入手し、状況およびそれを背景としたニーズを明確にすればよいのでしょうか。Contextual Designで用いられる5つのワークモデル（「ユーザー行動を構造的に分析するための5つのワークモデル」参照）をフレームワークとして使って、相手の状況を構造的に理解する方法もとれますが、ここでは別の方法として5W1Hをフレームワークとして、どんな情報を相手から引き出し、状況を明確にしたほうがよいかを示しておくことにします。
- WHY：背景・目的を明確にする
まずは相手の口から今回の仕事の背景、目的を語ってもらうことです。もちろん、相手が自分自身の状況をすべて把握できているなんてことはありません。だから、最初に語られたことをそのまま受け取ってしまっては必ず抜けがでます。とはいえ、抜けはあっても最初に相手が語ることが問題の核心であることも多いですし、要件定義を進めるにあたってはやはりきっかけとなるものが必要ですので、最初はここからスタートするのがよいでしょう。 - WHERE：全体の仕事のなかでの位置づけを明確にする
次に、仕事の依頼の背景となる情報をより明確にするために、今回の仕事が相手がやる必要がある仕事のうち、どのような位置づけにあり、前の段階でどんなことが行われ、今回の仕事のアウトプットが何に役立てられるのか、そして、最終的に先方は何を実現しようとしているのかを明確にする必要があるでしょう。とうぜん、そのためには相手のビジネスを理解しなくてはいけないでしょうし、相手のビジネス環境（市場動向、競合他社の動向など）についても知っておく必要があるでしょう。 - WHO：ステークホルダーを明確にする
結構、大事なのが、今回の仕事にかかわるメンバーだけではなく、仕事を進めるうえでは直接かかわることがなくても、実際の仕事のアウトプットを利用する、または影響を受けるステークホルダーについて把握しておくことです。今回のアウトプットを具体的に使う人は誰で、その人は全体の仕事のなかでどんな役割を担っているのか。また、その人の知識や専門分野はどういうもので、今回アウトプットしようとしているものに対する理解度はどのくらいあるのか、など。目の前で要件定義をしている相手には理解できるものでも、実際にそれを用いるユーザーには納品したアウトプットが使えずに、結局、仕事が役に立たなかったなんてことがないためにも。 - WHEN&WHAT：いつまでに何が必要かを明確にする
納期と納品物を明確にするのはとうぜんですが、最終的なアウトプットのみならず、中間成果物やマイルストーンとなるレビューの日付などはきちんと明確にしておくことが必要です。 - HOW：制約条件、前提条件になりそうなリソース(ヒト・モノ・カネ・情報)に関して確認を行う
どのように仕事を進めるかを決めるにあたり、相手から提供されるリソースあるいは先にも書いたようなアウトプットの実際の利用者やその人がそれに費やすことができるリソースの量などを把握しておきます。アウトプットの途中の成果物をその人にもレビューしてもらうにも、その人がもしすごく忙しい人だったりすればなかなかレビューの時間がとれないかもしれませんのですから。
このあたりを意識しながら、クライアントの打ち合わせを重ね、自分の仕事に相手が何を期待しているのかを明確にしていくわけです。相手の期待がわかれば、それを実現するのにどんな手法が適切なのがみえてくるでしょう。
何を実現したいかがあってはじめて、どの手法が適切かが判断できるのです。それをやらないまま、自分たちが使える手法、技術の側から、無理やり仕事の要件を定義しようとしても無理があるに決まっています。
自分たちの論理に無理やり相手をおさめこもうとするのではなく、まずは相手からできるだけ多くの情報を引き出したうえで、それにカウンターをあてる形で自分たちの考えを述べればいいのだと思います。
要件定義をすこしラクに進めるために
まぁ、だいたい、このような情報が入手できれば、あとはどれだけ情報をうまく整理して、相手の状況なり要求なりを具体的にイメージし、それに適した提案をできるかということになってきます。とはいえ、なかなかこれらの情報を相手から引き出すのにもそれなりにテクニックは必要になるでしょう。
残念ながら、このあたりの情報をうまく相手から引き出せる力がある人にはあまりお目にかかったことがありません。
ですから、これをやらないとダメなのは明らかでも、ただ、ダメといってるだけでは誰もがこれをやれるようにはならないでしょう。ここですこし工夫が必要になってきます。
工夫できる点としては、こんなものがあります。
- ヒアリングシートをつくる
- 話し合いの素材になりそうなものはあらかじめその場に用意する
- ホワイトボードやプロジェクターを使って話した内容を見えるようにする
- 議事録を作成する
まず、「ヒアリングシート」について。これはなかなか相手の話を聞きながら情報を整理しつつ、全体像を考えながら抜けがないかを考えながら質問を行える人というのは稀少ですので、そのへんを少しでも軽減するためには最初に質問内容を構造化したヒアリングシートを用意しておくのは適切な工夫だと思います。あまり構造化した質問に頼りすぎてしまうと、顧客固有の状況を見逃してしまう危険もあるので、ヒアリングシートを軸にしつつ、相手の話に応じて臨機応変に内容を深掘りしていく力も必要ですが、まぁ、話のガイドラインの役割としてヒアリングシートは用意しておいたほうがよいでしょう。
次に「話し合いの素材になりそうなものはあらかじめその場に用意する」ということですが、これは話す側も話を聞く側も、目の前にないものについて説明したり、理解したりするよりも、百聞は一見にしかずの状況をつくったほうがいいということです。ユーザー中心のデザインでユーザーの利用状況を把握するために、ユーザーに意見を聞くのではなく実際にモノを使っているところを見せてもらいながらそれを観察するコンテクスチュアル・インクワイアリーを行うのとおなじです。目の前でみせてもらえば理解もしやすいし、相手が肝心なところを話さなかったために、それが情報として抜け落ちてしまったということも減ります。
「ホワイトボードやプロジェクターを使って話した内容を見えるようにする」ことや「議事録を作成する」ことは、相手の話した内容を自分がどう理解したかを相手に示し、理解の間違いがないかを確認するための工夫です。これをやるのとやらないのとでは、話し合いの生産性に大きな違いが出ます。
という感じで、ほかにもいろんな工夫ができるはずですが、いま思いつくのはこのくらいでしょうか。
いずれにせよ、お互い気持よく仕事をしていくためには、「その仕事には何が求められているかを明確にする」ための要件定義は大事なことです。これを大事にせず、ただ機械的に仕事を進めてしまう現場は進行の途中においてもその結果においてもなんとも寒々しいものが漂っているのを感じますよね。
関連エントリー
- 判断力は情報デザイン力、物語化の能力
- 何が起こっているのかわからない状態を脱するための9つの工程
- 自分の視野を広げるためにも他人の意見には耳を傾けなきゃ
- 他人の話を聞く技術：べからず集とうまい聞き方のコツ
- 情報設計の重要性、わかってますか？
- ペルソナとISO13407：人間中心設計プロセスの関係に関するまとめ
- ユーザー行動を構造的に分析するための5つのワークモデル
この記事へのコメント
bon qu ra
どうやってこれをうまく伝えられるか模索してたら近いところに答えが＾＾
さすがだなっ