「行動観察とIT～後篇：事実の現場力をどう仕組みにつなげるか～」

　前回、業務効率化のためのIT施策導出を例に、行動観察から新価値を含むIT施策につなげる流れのうち、顧客の現場で必要としていることや困りごとなど"現場がやりたいこと"に関する様々な情報を得る（気づく）ための観点について話をした。今回は、後編として、事実や気づいたこと（要望）から要求へつなぐ際に、どのようなプロセスで明文化・表現し、その内容を関連するステークホルダーと合意をとっていくかについて記載する。

要求定義の課題については一定の品質の確保が難しい、ということが言われている。古いデータではあるが、情報サービス産業における技術動向調査（2009）^＊１によれば、「品質は改善されているが、ベンダー側の要求の整理の仕方や可視化の仕方、合意の取り方などは約6割が未だ改善されていない」ということが言われている。それは手法が確立されていない、ということだけではなく、現場・現物・現実をありのままに生々しく捉えたとしても（要望）、そこから具体的に"要求"としてきちんと明文化し、現場部門から価値を感じていただけるようなシステムや仕組みを施策として提案につなげていないことが考えられる。つまり、顧客の現状（要望）から、問題、ニーズを整理し、要求の本質までを要求として定義できていない、ということが考えられる。また、要望／要求／要件など言葉の意味すらそれぞれの部門でバラバラということが多い。要望→要求→要件と素直に落ちていくわけではなく、要望＜=＞要求＜=＞要件＜=＞要望・・と常に回していくことで、顧客部門の「やりたい、こうしたい」を実現すること、すなわち人を中心にしたシステムを現場部門や経営部門、そしてシステム部門に価値を提供することが求められている。

以下は、システム開発の工程での行動観察からの基本的な流れである^＊２。
(1)は、顧客の要望や利用状況など、現状の顧客のやりたいことを把握するフェーズである。顧客側からは、業務効率化／新事業形態構築／中期経営計画の実現にむけた共創／新商品開発コンセプト構築、部門イノベーションなど、様々な相談事が来る。その部分を明文化し、続く要求につながるようにするフェーズである。
(2)は、(1)の要望を具体的な"要求"として言語化し、関連するステークホルダーと合意ができた状態である。
(3)は、(1)、(2)をシステム開発者にわかるようい伝えるために言語化し、要件に『翻訳』し、システム開発につなげられるようにするフェーズである。

ここでは、行動観察×ITとしての要望・要求・要件に関する言葉の整理を行う。表１は、行動観察リフレーム本部としての言葉の定義と意味を記載した。定義と意味は以下のとおりである。
１）要望：顧客が作ってほしいこと（もの）の抽象的な表現。本当に顧客がやってほしいのか、は顧客間でも未合意。顧客・ユーザー観点での希望、理想に留まっている場合が多い。「●●だったらいいなあ」というレベル。
２）要求：顧客が作ってほしいこと（もの）の条件。顧客がやりたいこと、として明確になっているが、どのレベルまでやりたいか、という詳細までは顧客間では合意されている。構造的に「●●●●●にしたい」というレベル。
３）要件：こと（もの）自体が満たすべき条件。やりたいことをどう実現するか、ということや、一方でできないこと、効果がないことなども明文化されている。「Aは、Bごとの帳票で整理する。BはAに対して、設定している手数料を円未満切捨てとする・・」と表現できるレベル。
上記の説明を考えると、１）２）は主に現状を把握し、顧客起点で明文化する必要がある。１）２）→３）と、要件として理解・合意するためには、翻訳する必要があることがわかる。要求から要件への翻訳、というのは、要求を明らかにしてシステム部門へわかるように伝える、ということだけではなく、「明文化した要求を顧客部門に対して解決してあげるにはどうしたらいいか、を考えること」といえる。

　今回業務効率化と働き方改革にむけた施策の方向性を出すため、以下の可視化を行った

実際の見た業務を行っている人を中心とした人間・部署・情報の流れのリレーション図や観察対象者の一日の行っている業務の流れを最初にまとめる。続いて、課題と気づきの一覧表を出し、それぞれに対しての施策案を記載する（図３－(1)）。

要望の中でも、あるタスクを行う際に、「具体的に行っている」、「個人に留まっているが、ルールとしてやっている」、「本当はこうしたいのに、現状がこうだからこうやっている」という作業フローを作成する。観察を実施した業務を行っている人の一人ひとりがどのように行っているか、だけではなく、複数の関連部署とどうやりとりがあるのか、その中で情報や紙資料がどう流れているのかなどを明文化したものである。「このような行動をとっているのは、こういう理由だからだ」と要望の中でも、あるタスクを行う際に、「具体的に行っている」、「個人に留まっているが、ルールとしてやっている」、「本当はこうしたいのに、現状がこうだからこうやっている」という作業フローを作成する。観察を実施した業務を行っている個人がどのように行っているか、だけではなく、その人、部署・部門を中心に複数の関連部署とどうやりとりがあるのか、その中で情報や紙資料がどう流れているのかを可視化したものである。「これらの行動は、・・・理由だからだ」というところがわかるように補足シナリオを追記して、行動のステップを可視化するいうところがわかるように補足シナリオを追記して、行動のステップを明文化する（図３－(2)）。

要望→要求への明文化したものを、どういう方向性で仕組みやシステムを更改、改革していくかという点について、調査者が考える施策の方向性のコンセプトとしてまとめ、それらを実現にむけてどういうことをしていくか、ということがわかるように明文化する。具体的には、始めに、人（現場）、組織（システム）、経営（あるべき姿）の観点で、解決したらよい問題（課題）を整理し、それらから、施策のコンセプトを明文化する。例えば、人（現場）では、一人ひとりのやる気や真面目さで今の煩雑な仕組みを乗り越えながら時間短縮にむけて努力をしている、組織（システム）では、組織のノウハウや個人の工夫で回してしまって、パワーを最大限活かしきれていないシステム、など、"解決してあげるポイント"がわかるように文言を記述する（図３－(3)、(4)）。

今まで私たちは、行動観察やインタビューで得た知見から現状を把握し、ありたい姿を共創・具現化に向けた取り組みを行ってきた。それらを可視化したのが、図３－(1)～(4)であるが、これらは結果をまとめ分析結果を整理する、という意味を持つだけではなく、これらをもとに、それぞれの部門（特に現場、ユーザー部門）と認識に相違がないかを確認するために行っている、といっても過言ではない。特に、根本的な解決・支援できることとして、調査者側の施策のためのコンセプトとそれに沿った施策実現の方向性を出して、初めて仕様のフェーズに進めることになる。なお、我々行動観察からの施策のためのコンセプトや方向性は、必ずしもITだけとは限らない。その部分を要求から要件にする際に伝えることができるような表現で明文化する。

2回にわたって、行動観察がどのようにシステム開発工程の上流工程で活用できるか、を念頭に、やり方やアウトプットの例をお話した。しかしながら、システム開発への仕様へつなげるには、要望、要求、要件、どの表現レベルにおいても、"あいまい"さが少しでも残ることは設計工程で苦労が重なる。現場・現物・現実を見ながら変化を早急に察して、小さく文書化しながら、顧客部門と対話を行い、具体的な解決策を"考え続けて表現する"ということが必要である。