「システムを入れたけれど、思っていたものと違った」。中小企業のご相談を受けていると、この言葉を本当によく聞きます。
私は中小企業診断士として、また公的支援機関で経営相談を受ける立場から、日々システム導入やDXのご相談に関わっています。その前は、ITベンダー側で20年以上、基幹業務システムの開発・導入に携わってきました。
システム導入がうまくいかなかったとき、よく「要件定義(システムに何をさせるかを決める工程)が甘かった」と言われます。ただ、ベンダー側にいた実感は少し違います。うまくいかない案件の多くは、要件定義が始まる前に、もう勝負がついていました。
この記事では、ベンダーの内側から見えていた景色をもとにお話しします。要件定義の前に決まってしまう3つのことと、その防ぎ方です。
「要件定義が悪かった」は、半分しか正しくない
要件定義は、システム導入でいちばん揉めやすい工程です。「その機能は聞いていない」「今のやり方と違う」といった食い違いは、たいていここで表に出ます。
そのため、失敗の原因も要件定義にあるように見えます。しかし実際には、要件定義は問題が「見つかる」場所であって、問題が「生まれる」場所ではないことが多いのです。
要件定義の場で揉めるとき、その原因をたどると、たいてい3つのどれかに行き着きます。何のために入れるのかが決まっていない。今の業務が見えていない。誰が決めるのかが決まっていない。どれも、ベンダーが来る前に会社の中で決めておくべきことです。
ベンダー側から見えていた風景
私がIT業界に入ったのは2004年ごろです。当時は、こんな進め方が珍しくありませんでした。
営業担当がお客様の業務を深く知らないまま、システムの機能名を並べて「これもできます、あれもできます」と説明する。お客様は機能名から「それがあれば解決しそうだ」と想像をふくらませる。そのまま受注に至る。いわゆる「風呂敷を広げる」営業です。
受注のあとは開発部門に引き継がれます。現場に入った技術者が、そこで初めてお客様に会い、「さて、何をどう作りましょうか」と話し始める。そんな案件が実際にありました。
このとき、お客様の頭の中にある完成形と、ベンダーが作れるものとの間には、すでに大きなずれがあります。同じ「販売管理」という機能名でも、食品を扱う会社と建築資材を扱う会社では、求められることがまったく違うからです。取引先との商習慣、値引きや納品のルール、請求のタイミング。業界ごとに細部が大きく異なります。
私の仕事の多くは、こうして広がった風呂敷を、要件定義の場で一枚ずつたたんでいくことでした。今はこうした売り方をする会社は減りました。それでも、「中身がすり合っていないまま、選定と契約が先に進む」という構造は、形を変えて残っています。
この風呂敷営業の話は、noteの記事でも詳しく書いています。
要件定義の前に決まっている3つのこと
では、要件定義の前に何が決まっていればよいのか。ベンダー側から見て、うまくいく案件とそうでない案件を分けていたのは、次の3つでした。
① 導入の目的が「入れ替えること」そのものになっていないか
「今のシステムの保守が切れるから」「古くなったから」。入れ替えのきっかけとしては、どれも正当な理由です。ただ、それだけでは新しいシステムで何が良くなれば成功なのかが決まりません。
目的がないと、要件を判断する物差しがありません。物差しがないと、現場から出てくる要望はすべて「今と同じようにしてほしい」になります。今のやり方をそのまま再現しようとして、追加の開発(カスタマイズ)がふくらんでいく。よくある失敗の入口です。カスタマイズの膨らみ方は、ERP選びの記事でも詳しく書いています。
「月末の請求作業を3日から1日にしたい」「在庫の数を、毎朝見に行かなくても分かるようにしたい」。この程度の具体さで十分です。目的が1行あるだけで、「その要望は目的に効くか」という問いが立てられるようになります。
② 今の業務が見えているか
「今と同じでいい」と言うためには、本来「今」が説明できなければなりません。ところが、誰が・何を使って・どの順番で仕事をしているのかが、社内でも共有されていないことがよくあります。
そうなると、要件定義の打ち合わせが、そのまま業務整理の場になります。ベンダーの担当者が質問を重ね、そのたびに社内に持ち帰って確認する。時間がかかるだけでなく、ベンダーの質問の範囲でしか業務が整理されないことが問題です。システムの機能に引っぱられた整理になり、本当の困りごとが抜け落ちます。
今の業務の流れ(As-Is)が見えていて初めて、次の判断ができます。「パッケージの型に業務を合わせるのか」「自社に合わせて作り込むのか」です。この順番が逆になると、どんなに良いシステムでも現場に定着しません。
③ 誰が決めるのかが決まっているか
3つめは見落とされがちですが、影響がとても大きいものです。要件定義は、要望を集める場であると同時に、「やらないこと」を決める場でもあります。予算にも期間にも限りがあるからです。
ところが、部門ごとに要望は出てくるのに、どれを優先してどれを諦めるかを決める人がいない。決裁する人が打ち合わせに出てこない。そうした体制のまま進むと、最後の承認の段階で「やっぱりこれも必要だ」とひっくり返ります。決める人が決まっていない案件ほど、こうした手戻りは大きくなりがちです。
最終的に決める人、優先順位をつける人、現場の窓口になる人。この3つの役割に名前が入っているかどうかで、要件定義の進み方はまったく変わります。
キックオフの時点で出ている「危ない兆候」
3つがそろっていない案件には、最初の打ち合わせの時点で兆候が出ます。もし自社に当てはまるものがあれば、要件定義に入る前に立ち止まるサインです。
- 「今と同じでいい」以外の要望が出てこない……目的が決まっていない
- 業務を説明できる人が1人しかいない……今の業務が社内で共有されていない
- 打ち合わせに、決める立場の人がいない……決める体制ができていない
- 「詳しいことはお任せします」という言葉が出る……3つすべてをベンダーに預けてしまっている
最後の「お任せします」は、悪気のない言葉です。しかし、ベンダーは御社の業務の当事者ではありません。任された範囲を、自分たちの作りやすい形で埋めるしかないのです。この点は「ITベンダーに丸投げしていませんか?」でも詳しく書いています。
明日からやれること:ベンダーに声をかける前に、A4一枚
立派な資料は要りません。ベンダーに相談する前に、次の3つをA4一枚にまとめてみてください。
- 目的……新しいシステムで「何が、どのくらい良くなれば成功か」を1〜3行で書く
- 今の業務の流れ……いちばん困っている業務を1つ選び、「誰が・何を使って・何をするか」を順番に書き出す
- 決める人と決め方……最終的に決める人、優先順位をつける人、現場の窓口になる人の名前を書く
この一枚があるだけで、ベンダーとの最初の打ち合わせの中身が変わります。機能の説明を聞く場から、「この目的に、この業務で、どう応えるか」を話し合う場になるからです。
この一枚を育てたものが、RFP(提案依頼書。ベンダーに提案を依頼するための資料)です。RFPの基本は「RFPって何?」の記事で紹介しています。
生成AIの時代でも、この順番は変わらない
最近は、生成AIの力でシステム開発が速く、安くなってきました。ただ、速くなるのは主に「作る」工程です。何のために作るのか、今の業務はどうなっているのか、誰が決めるのか。要件定義の前にある3つは、AIが代わりに決めてくれるものではありません。
むしろ、作るのが速くなったぶん、前提がずれたまま進むと、間違った方向にも速く進んでしまいます。前工程の大切さは、これからさらに増していくと考えています。
私が担当した自治体主催の個社別DX研修でも、同じ順番を大切にしました。最初の回は、ツールを選ぶ前に、参加者の皆さんに業務フロー図と業務一覧表を書いてもらうところから始めています。その様子は研修レポートの第1回で紹介しています。
まとめ
システム導入の失敗は、要件定義の場で見つかります。しかし、その原因の多くは、要件定義の前にあります。
- 目的……「入れ替えること」ではなく、何が良くなれば成功かを決めておく
- 今の業務……誰が・何を・どの順番でやっているかを見えるようにしておく
- 決める人……優先順位をつけ、「やらないこと」を決める人を決めておく
この3つは、ベンダーではなく、御社にしか決められないことです。「自社だけでまとめるのは難しい」という場合は、ベンダーを選ぶ前の段階から、中立の立場でお手伝いします。