木ノ下勝郎『業務設計・RFP・要件定義の“天動説”』同友館〔2005.4
木ノ下勝郎『業務設計・RFP・要件定義の“天動説”』同友館〔2005.4〕を読みました。
【1】一言紹介
著者が引用されている日経コンピュータ2003年11月17日号によれば、世にある情報システム関連のプロジェクトは「成功率は３割」だそうだ。ほとんどが失敗している。著者によれば、その原因は要件が定義できないことにある。それはなぜか、どうすればいいのかということについて、根源的に解き明かして、対策を提言するという書だ。
【2】メッセージ
メッセージは、業務改革プロジェクトにおける要件定義はユーザ主導であるべきだ、という考え方だ。そもそもユーザこそがITを活用する専門家であり、業務改革とは自らが自らの業務を見直すことであると説かれている。
こう書いてしまうとフツーのことのようだが、世の中なかなかフツーでは無い。読者私もサラリーマンであるので体感をしている。
【3】組み立て
分析と対策という組み立てになっている。
まず分析。なぜ、プロジェクトがうまくいかないのか？それはベンダーの言うことを鵜呑みにして丸投げしているユーザ側が悪いと説かれている。しかし、著者によれば、そもそもソリューション提案などをしているベンダも悪い。そして、著者はさらにその根にあるITを導入する側の方法論、ソフトウェア工学にこそ悪の根源がある、ソフトウェア工学は地動説的であり、抽象化偏重思考がある、だからここから絶たなければ駄目だ、というわけだ。業務を抽象化してモデリングしようという料簡が、「要件定義問題の癌」（p.69）と語られている。ソフトウェア工学に汚染されたＳＥの頭の中で「『業務機能』がいつのまにか『データ処理規則』に変わり、そして『プログラムロジック』にシームレスに視点を移していき」（p.108）という思考原理そのものがおかしいと看破されている。
そもそも要件定義はITを導入する側にはできないのだ、とも主張されている。「業務フローを書くには現場体験が必要である」（p.92）からだとしている。なるほど、電子カルテというような領域がうまくいかないのも、こんなあたりに原因の淵源があるだろう。
著者によれば、これまでも方法論と呼ばれるものはたくさんあったが、いずれもソフトウェア工学が根にあった。だが、これまでの方法論はすべて、ITを導入する側の方法論であった、と主張されている。
対策は「使う立場の方法が必要だ」、「対策は天動説」である、とある。それはユーザ主導の要件定義であるというわけだ。読者私は、要件定義とは（１）そもそも自分が自分の業務を反省して、（２）それについて語りだすものであって、（３）それを仲間と話し合って合意してゆくプロセスだ、と理解した。どこかの誰かが他人行儀に観察したりモデリングしたりするようなもんじゃない。
対策として「ライブスペックメソッド」と命名された方法論を掲げている。新業務フローで仕事の環境を具体的に記述せよ、要件定義は合意形成のプロセスであるとされている。そして合意形成の触媒をする役割として、「RFPコンサルタント」という職種を自ら実践されておられるようだ。
【4】熱気
対策としての方法論そのものよりも、要因解析の熱気にひきこまれた。著者の経験に根ざした観点そのものに大変共鳴する。分析のくだりでは切れ味鋭い刃を堪能させてもらった。
本書の中では、ふんだんに、あれは駄目だ、こうすべきだ、という主張が繰り広げられる。これは立ち回りとでもいうべき論考だ。熱気がこもっている。例えば、トップダウンでは駄目だ、擦り合わせこそが重要だ。カタカナ用語は駄目だ、日本語での表記せよ。などとある。ほぼすべてに共感した。
【5】金言
提言としても傾聴に値する言葉がたくさんでてくる。なかでも白眉は「業務」を定義されているくだりだ。素晴らしい。「主体性を持った人間たちの相互関係のシステム」（p.27）であるという定義がされている。
だからIT要件定義というくくり方は駄目なのだ、とある。要件定義なんてものは業務設計の一つの要素にすぎない。「ITは業務活動の一部で利用されているに過ぎない」（p.71）からだ。
【6】バトンを渡された気持ち
本書を読んだ読者私としては、なにかバトンを渡されたような気持ちになる。この先に論考を進めてみなければならないような気持ちにかられる。
そもそも業務改善、業務改革というのはプロジェクトでやるような一過性のものではなく「日常化」されなければならないのではないか？「はれ」の事象ではなく、「け」の事象として。
著者が言われている「仕組みを設計する企画部門の仕事」（p.132）による合意形成のプロセスが、社内で日常として当たり前のようにまわっていればＰＴは不要なのではないか？
著者木ノ下様の論を進めれば、合意形成がルーチンとしてまわっていれば、RFPコンサルタントという触媒も不要になる。
「仕組みを設計する企画部門の仕事」もどんどん人が回転してキャリアパスの一つになっていると良い。
業務シミュレーションについては、あれは画面があれば良い、というわけではないと感じている。例えば新業務劇場というようなところで、本当に新業務を実際にやってみる場が必要ではないか。ビデオの劇にしても良い。
あるいは、目指すべき水準にある企業に出向して、実際に何年か実務をやってみるというのもある。いずれにしてもこれは人事施策であり、ITベンダーのごときなどはまったくおよびでない話だ。
新業務フローは著者が言われるように社会学的な領域であるとも思えるが、さらに読者私は、演劇の領域、ロールプレイングゲームのような領域なのではないかとも思う。
【7】感謝
このような熱気ある書に感謝。
以上
