「使われないシステム」はこうして生まれる
業務システムの開発プロジェクトが完了して、現場に引き渡した直後に起きることがある。誰も使わない。あるいは、一部の人だけが限定的に使い、ほとんどの業務は以前のやり方のままになっている。
ある製造業の会社で、受注管理システムを新しく作った事例がある。要件書通りに作った。テストも通った。納品も完了した。でも3ヶ月後に確認に行くと、受注データはExcelで管理されたままで、新システムはほとんど起動されていなかった。
その会社の担当者に理由を聞くと、「操作が面倒で、Excelの方が早い」という答えが返ってきた。画面の構成が、現場の実際の作業の流れと合っていなかったのだ。要件書には「受注情報を入力できること」と書かれていた。開発会社はその通りのものを作った。でも誰も、現場でどんな順番で何を確認しながら受注処理をしているかを、丁寧に聞いていなかった。
「言われた通りに作りました」という言葉は、その場面では完全に正しい。でも、それはプロの仕事の説明にはならない。
発注者が持ってくる要件は「仮説」である
業務システムの発注者は、自社の業務のプロだ。毎日その仕事をしている。誰よりもよく知っている。
ただし、それはシステムの専門家ではないということでもある。「こういうシステムがあれば業務が楽になる」という要件は、業務の専門家が考えた「仮説」だ。正しい可能性が高い仮説だが、それでも仮説にすぎない。
発注者が要件を言語化する時、頭の中には現状の業務フローがある。今の手順、今の役割分担、今のボトルネック。その前提の上でシステムの要件を考えている。だから、「現状の業務フローをシステム化してほしい」という要件が出てくる。
でも本来の問いは別のところにある。「その業務フロー自体が、本当に最適か」という問いだ。毎月3日かかっている請求書処理は、別の方法で1日にできないか。特定の担当者しか判断できない承認フローは、条件を整理すれば自動化できないか。担当者が休むと止まる作業は、そもそもなぜ止まる設計になっているのか。
こうした問いを立てるのは、発注者の仕事ではない。システムの専門家である開発会社の仕事だ。
「プロの仕事」は要件の背後にある目的を掘り下げること
医師に「この薬を処方してください」と患者が言ったとする。医師がそのまま処方するだけでは、医師の仕事をしていない。症状を聞き、診察し、その薬が本当に適切かを判断して、場合によっては別の処方を提案する。それが専門家の仕事だ。
システム開発も同じ構造だ。依頼者が持ってくる要件書は、患者が「この薬をください」と言っている状態に近い。それをそのまま実装するだけでは、専門家としての役割を果たしていない。
依頼者の言葉の奥にある「本当に解決したいこと」を見つけるには、業務の話を深く聞く必要がある。何をどんな順番で、誰がやっているか。どこで時間がかかるか。どこで確認が発生するか。特定の人しか知らない手順はあるか。データはどこから来て、どこへ行くか。
こうした聞き方をしていると、依頼者自身も気づいていなかった問題が出てくることがある。「この確認、実は誰もチェックしていない形だけの手順だった」「このデータ、毎回手で転記していたが、システム連携で自動化できる」。そういう発見を一緒にするプロセスが、プロの仕事のはじまりだ。
扇風機の性能を限界まで上げても、エアコンは生まれない。依頼された解決策を精度高く実装することと、本当に必要なものを作ることは、別の仕事だ。この違いを理解しているかどうかが、開発会社の質を分ける。
「何でも作ります」という提案が危険な理由
システム開発の提案を受ける時、「ご要望を全部お聞きします」「おっしゃる通りに作ります」という姿勢の会社に出会うことがある。これを安心だと感じる発注者も多い。でも、それは危険なサインでもある。
発注者が正しい解決策を完全に把握していれば、外部の専門家は必要ない。外部に頼む理由の一つは、自分たちでは気づかない視点を持ってもらうためだ。「要望通りに全部やります」という開発会社は、その機能を放棄していることになる。
「言われた通りに作ります」と「お客様の本当の課題を一緒に整理します」は、姿勢が違う。前者は受注者として動く。後者はパートナーとして動く。どちらに頼むかによって、完成するものが変わる。
特に中小企業のシステム開発では、要件定義のフェーズに十分な時間と人数をかけられないことが多い。だからこそ、開発会社が業務を深く聞く力を持っているかどうかが重要になる。要件書を受け取って実装するだけでなく、その要件が生まれた背景まで理解しようとする会社かどうか。これは発注前に見極めるべき点だ。
「言われた通り」の罠：発注者はシステムの専門家ではない
業務の担当者は、自分の仕事の「経験者」だ。何年もその業務をやってきた。流れも、落とし穴も、こうすればうまくいくという感覚も持っている。
しかし、その経験は「今の方法でやる場合の知恵」だ。システムを使うとどう変えられるか、どういう設計にすれば現場で定着するか、データをどう構造化すれば将来の改修コストが下がるか——これらは、システムの専門家でなければ考えられない。
だからこそ、発注者が持ってくる要件は、システム設計のスタート地点に過ぎない。それを受け取って、業務の実態と照らし合わせ、本当に機能するものに昇華する作業が、開発会社の本質的な価値だ。
「言われた通りに作ります」という開発会社は、発注者が専門家ではない領域の判断を、発注者に委ねている。それは誠実さではなく、責任の放棄に近い。発注者は「これでいいです」と言ったかもしれないが、本当は「これでいいかどうか」を判断する情報を持っていなかった。
発注前に「提案力」を見抜く方法
開発会社の提案力を見極めるには、商談の場で意識的に観察するポイントがある。
一つは、「なぜその機能が必要か」を聞いてくるかどうかだ。要件書に書かれた機能の目的を掘り下げる質問をしてくる会社は、表面だけでなく背景を理解しようとしている。
もう一つは、「別の解決方法はないか」を提案してくるかどうかだ。「それよりも、こういうアプローチの方が目的を達成しやすい可能性があります」という視点を出してくる会社は、受注した内容を実装することより、依頼者の成果を優先している。
三つ目は、「それをやらない場合はどうなるか」を議論できるかどうかだ。機能の優先順位を一緒に整理できる会社は、発注者の目線でプロジェクトを考えている。
四つ目は、現場の見学や業務の同行を提案してくるかどうかだ。「一度、実際に業務が行われている現場を見させてください」と言える開発会社は、要件書の言葉だけでなく、業務の実態から設計しようとしている。
「言われた通りに作ります」という言葉が出てくる会社は、こういった会話をしない。それは一つの判断材料になる。
完成したシステムが現場で使われ続けるかどうかは、要件定義の段階ですでに決まっている。業務の実態を深く理解した上で設計されたシステムは、現場になじむ。要件書をそのまま実装したシステムは、現場との間にズレが生じやすい。そのズレが積み重なって、「使われないシステム」が生まれる。
最初に払うコストは同じでも、3年後に現場で使い続けられているシステムと、使われなくなったシステムとでは、投資対効果がまったく違う。その差は、発注前に開発会社のどういう問いを聞いてくるかを見ることで、ある程度予測できる。