筆者が，要求開発ファシリテータとして生きがいを感じるのは，参加者の意識が変わりつつあることを実感したときだ。以前，要求開発プロジェクトで，こんなことがあった。私がコンサルタントとして入った会社で業務を束ねるリーダーから「萩本さんはITコンサルなんでしょう。業務改善なんて考えていただく必要はありませんよ！」と言われたのである。
私はこの業務リーダーの一言で，やる気120倍となった。まずは何としてもこの人をくどき落とそうと考えたのだ。そして，この業務リーダーに，「そうではありませんよ。ITは業務をつかさどる手足なのです。手足だけ改善してどうするんですか。第一，手足は皆さん自身の持ち物なのですよ。」と言った。
私がこのような発言をするときに，一つ子供のころから実践してきたことがある。それは，その人に対して好意を示す表情で，目をそらさず，強い口調で話すことだ。そうすると，相手はこの人は真剣に取り組んでいるという印象を持ってくれるものである。その際，目は怒った目ではなく，信頼していることを感じさせる目をするのが重要だ。要は，相手に信頼してもらいたいなら，相手を先に信頼すればよい。
この業務リーダーは，1カ月間ほどは私に反抗していた。ただ，子供が興味を持った大人にイタズラするような，そんな刃向い方だったので，私もその人の主張を真剣に聞くことに徹した。そのうち彼は，私の強力な味方になり，プロジェクトが進むにつれて，彼なしでは要求開発プロジェクトが前に進まないほどになった。
相手と信頼関係を結ぶためには，こちらが分かってほしいと主張ばかりしても効果がない。相手の主張を100％聞き，自分なりに理解して，その意見に真剣に答える姿勢，それが必要なのだ。
教訓：
初めに反抗する人を避けるのは二流の戦略。まず，最初のターゲットとしてその人を落とせ。なぜなら，その人々にこちらを向かせることができたなら，強力な味方になってくれるからだ。もし駄目でも，真剣に接しているうちにこちらの主張を理解してくれるようになり，最大の敵はいなくなる。
反応がない人には要注意
要求開発プロジェクトの内外で私が最も気を付けているのは，反応なき人，反応なき組織である。こちらのアプローチに何の反応を示さないような人や組織は，ある日突然反抗してきたり，こちらの主張を全く理解していなかったことが判明したりすることが多いからだ。私はファシリテータとして，人の気付きをできるだけ与えるように工夫を重ねる。しかし，反応がない人は，そのような工夫に対しても，あまり反応を示さない。そこで，私が考えたのは「すぐやる改善」である。
要求開発の成果は，必ずしもIT化して初めて得られるというわけではない。ビジネスを可視化している最中に何か気が付いたら，システム開発とは無関係な個所ですぐに改善を実施すればいいのである。これは，要求開発の要素技術の一つである「プロセス・セル」において，PDCA（Plan，Do，Check，Act）のActに含まれている。
要求開発の日々の活動の中で業務改善個所を見つけたら，すぐ改善計画を立てて改善行動を実施し，それを会社でリアルタイムに情報開示する仕組みを作るのだ。そうすることで，要求開発プロジェクトの活動は，社内のほかの組織から徐々に認められていくのである。その過程で，無反応な外の組織も少しずつこちらを振り向いてくれるようになる。
また，無反応な要求開発メンバーに対しては，次のように語りかけるのが効果的だ。
---「要求開発プロジェクトを成功に導く秘訣は，業務改善を目に見える形で行うことです。そのために皆さんが，何か一つでも身近な改善をしてみてください。それができたら，ここに15人いますので，15個の小さな改善ができるはずです。そうすると，もっともっとこの活動を認める味方が増えますよ。それに，実は皆さんが工夫した小さな改善作業そのものが，大きな改善を行う際に必要とされる改善プロセスを，リアルかつシンプルに体感していることになるのです。」---
このように，一人ひとりに業務改善課題を考えさせ，ミッションとして与えることで，無反応な人々の意識を改革していくのである。
教訓：
無反応な人には気を付けよう。無反応な人には，自分でできる業務改善課題を与え，改善活動を体感させるとよい。そうすることで意識改革ができる。
業務の本質的な面を抽象化する
私はビジネス・モデリングの効果について非常に厳しくとらえている。ビジネス・モデリングさえ行えば，すぐに多大なる効果がある，などというのは幻想だ。その一方で，すぐには目につかないものの，非常に基本的な部分で絶大な効果が得られることがあるのも経験している。とあるプロジェクトでこんなことがあった。業務の標準化，効率化を目標に，標準業務モデルを業務フローと概念モデル（クラス図）を使って確立しようとしていたときのことである。業務フローがだんだん複雑になり，収拾がつかなくなってきた。
すると，ある業務担当者がこう提案した。「今議論している業務は例外的なものに過ぎません。もう少し標準業務フローの本質に立ち返って，その業務の重要性を考えてみませんか？」この発言に参加者全員が納得し，議論が収束に向かった。
私は正直驚いた。まさにこれが業務の本質的な面の抽象化による効果なのだ。この要求開発チームは，ビジネスの重要な本質が何であり，その部分をモデル化する価値がどれだけあるかを理解してしまったのである。そのおかげで，その後システム開発へと進んだときにも，この標準モデルをベースに必要な要求だけを抽出することができたのだ。
この要求開発チームでは，業務メンバーと開発メンバーの意識が，普通の開発プロジェクトとちょうど逆になる現象が発生していた。要求開発チーム内の業務メンバーは，「この要求は，どの程度の工数で作れますか？ 無駄なものは作りたくないので投資効果を考えたい」と言う。開発メンバーが，「業務に必要なものならとにかく試作してみませんか？」と言うのにである。
通常は，要求分析フェーズの中で，決められた開発費内に収まるよう，できるだけ早く要求を確定しようとする。しかし筆者からすると，そんなやり方で出た要求の中でまともなものは3割程度しかないことが多い。残りの7割は，ろくでもない要求なのである。開発者は，要件定義として確定された7割のろくでもない要求に疑問を感じつつ，（泣きながら）開発しなければならない。
一方，開発を終えた後でその不良財産の面倒を見るのはユーザーだ。また開発途中でより重要な要求に気付いた場合も，仕様変更としてお金を取られることになる。なんという不幸なユーザーと開発会社の関係なのだろうか？
それに比べると，要求開発プロジェクトのこの逆転現象は，システム開発を始める前に「無駄なものは作らない」とい意識が働くことになる。当初は5つのシステムを作ろうとしていたのが，3つで済んだといった具合だ。そのほうがユーザーにとって幸せなのは言うまでもない。
ではシステム・インテグレータ（SIer）にとってはどうだろうか？ 一見，ビジネスを阻害するように思えるかもしれない。でもそれは間違いだ。ユーザーは既にSIerの姿勢を疑いつつある。本来ユーザーのビジネス価値を高めるためのIT化なのである。今後は，それに気が付いたSIerだけが価値あるSIerとして勝ち残るのだ。つまり，要求開発は価値あるSIerの姿をも提案しているのである。
教訓：
シンプルかつ最大のモデリング効果は，要求開発メンバーが，業務の本質的な面の抽象化を実感できたときに得られる。
要求開発におけるコタツモデルは，トップと業務とITという3つの役割を持つ人々がコミュニケーションによって学びながら育つ場である。学びながら育つという意識がない要求開発活動では，ビジネス改革・改善において最も重要とされる創造・創作活動は生まれてこない。
| （萩本 順三＝要求開発アライアンス理事） |
