要件を削ったら、部長が会議室に乗り込んできた。―「今もやっている」を、なぜ新システムにも残してしまうのか
「現場のことを何も分かっていないじゃないか」
会議室のドアが開き、生産管理部の部長が入ってきました。
少し前まで、私たちは生産管理の現場ヒアリングをしていました。今の業務を一つずつ確認して、新しいシステムに何を引き継ぐのか整理していたのです。
- 帳票
- 入力項目
- 例外処理
- 月末だけの作業
- Excelで補完している処理
当然、すべてをそのまま残すわけではありません。
「この帳票は、新しいシステムでも必要でしょうか」
「この処理は、なくすことはできませんか」
そんな確認を始めた矢先でした。
こちらとしては、新しいシステムに何を残すかを整理しているつもりだった。
部長からすれば、そうではなかったのでしょう。
「それ、なくされたら困るんだけど」
その温度差が、会議室まで部長を連れてきました。
「それ、本当に必要ですか？」は、案外乱暴な質問である
当時はこちらも、「そのためにヒアリングしているんですが」と思っていました。
しかし今振り返ると、こちらの聞き方にも問題がありました。
「この業務は、これからも必要ですか」
こちらは未来のシステムについて聞いているつもりです。
ところが、長年その業務を担ってきた人には、
「あなたたちが今までやってきた仕事は、本当に必要だったんですか」
と聞こえていたのかもしれません。
20年間続けてきた仕事を、数回ヒアリングした外部の人間から「これ、なくせませんか」と言われる。そりゃあ、腹も立つでしょう。
しかも、今ある業務には、それなりの理由があります。
過去にトラブルがあったからチェックが増えた。顧客からクレームがあったから帳票を出すようになった。システムでは対応できなかったからExcelで補完するようになった。
今の業務は、誰かが気まぐれに作ったものばかりではありません。
会社がこれまで経験してきたことの堆積でもあります。
だから簡単には捨てられない。
「無駄な業務を洗い出しましょう」と言うのは簡単ですが、その「無駄」にも歴史があります。
それでも、現場に聞けば要件は増えていく
では、現場の声をできるだけ尊重すればよいのか。ここから別の問題が始まります。
新しいシステムに何が必要かを現場に聞けば、当然、今やっていることが出てきます。
- この帳票は必要
- この入力項目も必要
- この例外処理も残してほしい
- この機能も使っている
どれも嘘ではありません。少なくとも、今の仕事には必要です。
ヒアリングする側にも「漏らしてはいけない」という意識があります。だから記録する。要望一覧に載せる。要件候補にする。
別の部署にも聞く。また増える。
さらに別の部署にも聞く。また増える。
気がつけば、現行システムの機能に現場から出た追加要望まで載った、立派な要件一覧ができあがっています。
丁寧にヒアリングした結果です。
それなのに、何かがおかしい。
「今やっている」と「これからも必要」は違う
たとえば、毎月出力している帳票がある。
誰が見ているのか確認すると、「営業企画だと思う」という。何のために使っているのかまでは分からない。それでも昔から月末に出しているので、今月も出す。
こういうものは、企業の中に案外あります。
ここで確認できた事実は、「現在、この帳票を出している」ということです。
しかし、「新しいシステムでも、この帳票を出せなければならない」とは、まだ決まっていません。
この二つは似ていますが、全く違います。
ところが要件定義では、この間が簡単につながります。
- 現行業務でやっている
- 現場から必要だと言われた
- だから新システムにも実装する
こうして、現在の業務が未来の要件へコピーされていきます。
そもそも「要件をヒアリングする」という言い方自体、少し怪しいのかもしれません。
どこかに正しい要件がすでに存在していて、現場の人がそれを知っている。専門家は上手に聞き出せばいい。
実際には、そんなに簡単ではありません。
現場から出てくるのは、現状であり、要望であり、経験であり、過去の事情です。それらを材料にして、これから何が必要なのかを考える。
要件は、現場から「聞き出す」ものというより、現場と一緒に「作っていく」ものです。
そして、誰も決められない
では、現在の業務の中から、何を残し、何をやめるのか。ここが厄介です。
ある例外処理を新しいシステムにも残すかどうか決まらない。
現場に聞くと、「自分たちでは決められないので、部長に確認してほしい」と言われる。
部長に確認すると、「そこは現場とよく相談して決めてほしい」と返ってくる。
現場に戻れば、「部長は何と言っていました？」となる。
誰もふざけているわけではありません。
- 現場担当者には、長年続いてきた業務を廃止する権限がない
- 部門長には、その機能を残すことでシステムの費用や複雑性がどれだけ増えるのか分からない
- 経営者に聞いても、個々の業務処理までは判断できない
- ベンダーには、顧客企業の業務を廃止する権限などない
つまり、「誰が決めるべきか」は分かっているようで、実際には誰も決められない。
この状態になると、プロジェクトには一つの強力な解決策が残されます。
今まで通りにすることです。
誰かが明確に「やめる」と決めなければ、残る。
残して問題が起きなければ、責任を問われにくい。
なくして問題が起きれば、「なぜなくした」と言われる。
こうして現在の業務は、驚くほど強い生命力で新しいシステムへ引き継がれていきます。
そして「新しい旧システム」が完成する
ここまで来れば、プロジェクトはある意味とても平和です。
- 現場から出た要望は、できるだけ残す
- 既存システムにある機能も残す
- 反対されたものも残す
- 例外処理も念のため残す
- 帳票も、誰かが使っているかもしれないので残す
- 独自ルールも残す
- Excelも残す
丁寧です。現場の声を尊重した、民主的なプロジェクトにも見えます。
そして数年後、新しいシステムが完成します。
- クラウドになった
- 画面もきれいになった
- レスポンスも速くなった
- 新しい技術も使っている
ところが、やっている仕事はほとんど変わっていない。
- 帳票もある
- 例外処理もある
- Excelも残っている
- 承認フローも昔のまま
何年もかけて、何億円も使って、最新技術で「新しい旧システム」を作った。
システム刷新では、案外こんなことが起こります。
もちろん、現行業務を残すこと自体が悪いわけではありません。問題は、
残すと判断したのか。誰もやめると決めなかったから残ったのか。
外から見れば同じ機能でも、この二つは全く違います。
「残しますか？」では、人は決められない
では、どうするのか。
「この機能は必要ですか」
「残しますか、なくしますか」
そう聞くだけでは、なかなか決まりません。判断するための材料が足りないからです。
たとえば、ある例外処理が年間30件、1件20分だったとします。年間の作業時間は10時間です。
一方、この処理を新しいシステムに組み込むために、仮に200万円かかるとする。すると問いは変わります。
「この機能は必要ですか？」ではなく、「年10時間の手作業をなくすために、200万円をかけますか？」になる。
もちろん、答えが「かけない」とは限りません。人が間違えれば重大事故につながる処理なら、年間10時間でも200万円をかける価値があるかもしれない。
つまり重要なのは、200万円が高いか安いかを専門家が決めることではありません。
判断できる形に、問いを変えることです。
- 帳票なら、誰が何の判断に使っているのかを確認する
- 誰も分からないなら、いきなり廃止せず、一定期間止めて影響を見る方法もある
- 例外処理なら、発生頻度、手作業の負荷、システム化のコスト、ミスした場合の影響を並べる
専門家が勝手に「いらない」と決めるのでもない。「現場で決めてください」と丸投げするのでもない。
判断できる材料と、判断できる選択肢を作る。
ここに、要件を整理する側の重要な役割があります。
要件定義は、「意思決定のデザイン」である
あのときの生産管理部長に、今なら少し違う聞き方をすると思います。
「この帳票、本当に必要ですか？」ではなく、
「この帳票が担っている役割を教えてください。その役割を、新しい仕組みではどうするか一緒に考えたいです」と。
その結果、やはり残すかもしれません。別の方法に変えるかもしれません。調べてみたら、もう役割を終えているかもしれません。
大切なのは、専門家が最初から答えを持っていることではありません。
現場から出てきた事実、要望、過去の経緯、例外、制約を整理し、
「何を残し、何を変え、何をやめるのか」を、組織が決められる状態にする。
要件定義には、そんな「意思決定のデザイン」という仕事が含まれています。
だから、「現場から要望が出たので、要件に入れておきました」では足りない。
反対に、「これは無駄なので、なくしましょう」と外から切って回るのも違う。
現場の声を聞かずに、良いシステムはつくれません。しかし、現場の声をすべて要件にしても、良いシステムにはならない。
「今もやっている」は、事実です。
「これからも必要だ」は、判断です。
要件定義で本当に必要なのは、その二つを切り分け、組織が判断できるところまで持っていくことです。
システム刷新で、「何を残すか」が決められずにいませんか？
現場の要望は集まった。ベンダーからも提案は出ている。それでも、「何を残し、何を変え、何をやめるのか」が決まらない。
こうした状態では、要件を増やす前に、判断の軸を整理する必要があります。
オーシャン・アンド・パートナーズでは、特定の製品やベンダーを前提とせず、発注側の立場から、現状業務の整理、要件定義、RFP作成、ベンダー選定、プロジェクト推進まで支援しています。
「このまま要件定義を進めてよいのか」
そんな段階からでも、ご相談いただけます。
▶ ITで何を変えるべきか、相談してみる
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
