「開発会社にお願いしているので、大丈夫です」
そう答えたのは、従業員80名ほどの製造業で基幹システムの刷新を任されていた総務部長だった。プロジェクトが動き出したのは半年前。要件定義のキックオフには経営陣も同席し、開発会社の担当者は熱心にヒアリングをしてくれた。議事録もきちんと送られてきた。だから安心していた。本業の受発注業務や決算対応に追われながらも、月に一度の定例会に顔を出しさえすれば、あとは開発会社が良い形に仕上げてくれるはずだと思っていた。
ところが3ヶ月が経ち、いざ画面のプロトタイプを見せてもらったとき、彼は言葉を失った。現場の作業員が毎日使う在庫入力の画面が、想定していた「タブレットでバーコードをかざすだけ」の運用ではなく、パソコンでの手入力を前提にした複雑な画面になっていたのだ。要件定義の議事録を読み返すと、たしかに「バーコード運用を検討する」という一文はあった。しかし、それが「採用する」なのか「検討したが見送る」なのかは、誰も最終決定をしていなかった。開発会社は、決められないまま宙に浮いた論点を、自分たちの経験則で「妥当」と思う方向に進めていただけだった。悪気はない。ただ、発注側の誰も、その意思決定を引き取っていなかっただけだ。
これは特別に不運な現場の話ではない。中小企業のシステム開発の現場で、驚くほど繰り返されているパターンだ。開発会社は決して手を抜いていない。むしろ真面目に、送られてきた情報の範囲内で最善を尽くしている。壊れているのは、発注側の体制の方なのである。
なぜ「発注したら終わり」ではないのか
契約書にサインをして、要件定義書に承認印を押した瞬間、多くの発注担当者はプロジェクトが自分の手を離れたと感じる。無理もない。忙しい本業を抱えながら、片手間でシステム開発のことまで考え続けるのは現実的ではないし、そもそも専門知識もない。だからこそ、専門家である開発会社にお金を払って任せているのだ、という理屈は一見もっともらしく聞こえる。
しかし、開発という仕事の本質を考えると、この理屈には大きな見落としがある。開発会社ができるのは「指示されたことを、指示された通りに作る」ことだ。優れた開発会社であれば、指示が曖昧な部分について提案をしてくれるし、リスクを指摘してもくれる。それでも最終的な意思決定の主体は、常に発注側でなければならない。なぜなら、そのシステムを使って日々の業務を回すのは発注側の社員であり、そのシステムに投資した費用を回収する責任を負うのも発注側の経営だからだ。
開発が進む中には、必ず「発注側の判断を待っている」瞬間が訪れる。画面のレイアウトをどちらの案にするか。既存の紙の帳票フォーマットをどこまでシステムに合わせて変えるか。他部署からの追加要望をどこまで受け入れるか。こうした判断は、コードを書く技術者には決められない。決めるべき人が決めずに放置すれば、開発は止まるか、あるいは開発会社の推測で勝手に前に進んでしまう。冒頭の在庫画面の例は、まさにこの「止まらずに、間違った方向へ進んでしまった」ケースだった。
発注とは、注文書を出して終わる行為ではない。プロジェクトが完了するまでの間、判断を求められ続ける長い伴走の始まりなのだ。この認識のずれこそが、多くの失敗の出発点になっている。
発注側のプロジェクト管理者が担うべき役割
では、発注側は具体的に何をすればよいのか。ここで言う「発注側PM」とは、必ずしもITの専門家である必要はない。求められているのは技術力ではなく、社内とプロジェクトの間に立ち、物事を前に進める力だ。役割は大きく三つに整理できる。
進捗を「聞く」のではなく「追う」
月次の定例会で「順調です」という報告を聞いて頷くだけでは、進捗管理とは言えない。当初のスケジュールに対して、今どのタスクが、どれだけ遅れているのか、あるいは前倒しで進んでいるのかを、自分の言葉で説明できる状態を保つ必要がある。難しいことをする必要はない。開発会社から共有されるタスク一覧やガントチャートを、月に一度で構わないので自分の目で確認し、「ここが赤信号になっていないか」をチェックするだけでいい。違和感を覚えたら、その場で「なぜ遅れているのか」「取り戻す見込みはあるのか」を率直に尋ねる。この一往復があるかないかで、3ヶ月後の景色はまったく変わる。
社内の声を一本化して届ける
現場の担当者、経理担当、経営者。それぞれが開発会社に個別に要望を伝えてしまうと、開発会社は誰の意見を優先すればよいのか分からなくなる。結果として、矛盾した指示に振り回されるか、あるいは声の大きい人の意見だけが通ってしまう。発注側PMの重要な仕事は、社内の様々な声をいったん自分のところで受け止め、優先順位をつけて整理してから、開発会社に一つの窓口として伝えることだ。これは調整役であると同時に、社内の利害を代表する交渉役でもある。
意思決定の窓口になる
開発会社から「この件、どちらにしますか」という問いが飛んできたとき、誰が答えるべきかが明確でなければならない。担当者が答えられない内容であれば、誰にいつまでに確認して、いつまでに回答するのかを開発会社に伝える。この往復のスピードこそが、プロジェクト全体のスピードを決める。決定が滞留するプロジェクトほど、後になって手戻りが増え、結果的に納期もコストも膨らんでいく。
これらは、華やかな仕事ではない。むしろ地味で、成果が見えにくい。しかし、この地道な役割を誰かが引き受けているプロジェクトと、誰も引き受けていないプロジェクトとでは、成功確率がまるで違う。壁の向こう側にいる開発会社と、壁のこちら側にいる社内。その壁を越えて行き来し続ける人がいるかどうかが、すべてを分けている。
専任のPMを置けない中小企業の現実的な対応策
大企業であれば、情報システム部門にプロジェクトマネジメントの専任者を置くこともできるだろう。しかし、多くの中小企業にはその余裕がない。総務部長や経営企画担当が、本業と兼任でシステム開発の窓口を担うのが現実だ。だからといって、この役割を放棄していい理由にはならない。専任でなくても、最低限やるべきことはある。
- 週に一度、15分だけでも進捗確認の時間を強制的にカレンダーに確保する。忙しさを理由に先延ばしにすると、気づいたときには手遅れになっている。
- 開発会社とのやり取りは、口頭やチャットの雑談で終わらせず、決定事項だけは必ずメールや議事録という形に残す。「言った、言わない」のトラブルは、記録を残す習慣だけでかなり防げる。
- 社内の関係者を巻き込む簡単な仕組みを作る。全員参加の会議は不要だが、決めるべき論点をリスト化し、誰が、いつまでに答えるべきかを一枚のシートで見える化するだけでも効果は大きい。
- 分からないことは分からないと開発会社に伝える。専門用語を知ったかぶりで流すと、後から認識のずれが表面化する。むしろ「非エンジニアなので、噛み砕いて説明してほしい」と最初に宣言してしまう方が、健全な関係を築ける。
- すべてを一人で抱え込まない。経営者の判断が必要な論点は、早めにエスカレーションする勇気を持つ。兼任者の役割は「すべてを決めること」ではなく「決めるべき人に、決めるべきことを、適切なタイミングで届けること」だ。
専任のPMがいないことは、決して言い訳にはならない。むしろ、限られた時間の中でこれだけの役割を果たしている兼任担当者こそ、正当に評価されるべき存在だ。日々の本業をこなしながら、慣れないプロジェクト管理の重責まで背負う。その負担の重さに、まず私たちは敬意を払いたい。
発注側PMがいることで防げる典型的な失敗
発注側にプロジェクト管理者が機能しているだけで、防げる失敗は数多い。いくつか具体的に見てみよう。
ある小売企業では、POSシステムの刷新プロジェクトで、店舗スタッフからの「レジ締め作業を簡略化してほしい」という要望が、本部の担当者を経由せずに直接開発会社へ伝えられていた。開発会社は素直にその要望を反映したが、実は経理部門にとってはレジ締めの詳細な記録こそが月次決算の根拠であり、簡略化は許容できないものだった。もし発注側に窓口が一本化されていれば、この要望は経理部門と店舗運営部門の間で事前にすり合わせが行われ、無駄な手戻りは発生しなかったはずだ。
別の建設会社では、原価管理システムの開発中、進捗確認を怠っていたために、当初合意していた仕様から開発会社が独自の判断で機能を削っていたことに気づかないまま、テスト工程まで進んでしまった。発覚したのは本番稼働の1ヶ月前。慌てて追加開発を依頼した結果、当初の予算を大幅に超過し、稼働時期も延期になった。もし月に一度でも進捗を追っていれば、削られた機能に早い段階で気づき、優先順位を話し合う時間的余裕があっただろう。
発注側PMの存在は、開発会社の仕事を監視するためのものではない。むしろ、開発会社が持っている専門性を最大限に引き出すための、社内側の受け皿なのだ。開発会社が的確な提案をしても、それを受け止めて意思決定する相手がいなければ、その提案は宙に浮いたまま消えていく。発注側PMは、開発会社という壁の向こうのプロフェッショナルたちと、社内の現場という壁のこちら側とを、確かにつなぐ存在なのである。
よくある失敗パターン
最後に、多くの現場で繰り返されている失敗パターンを整理しておきたい。自社のプロジェクトに当てはまるものがないか、確認してみてほしい。
- キックオフだけ経営陣が参加し、その後は現場任せになる。プロジェクトの方向性を最終的に判断できる人が、途中から関与しなくなってしまうパターン。
- 進捗報告を「聞くだけ」で終わらせ、資料の裏にある遅延やリスクの兆候を読み取ろうとしない。
- 社内の複数部署が、それぞれ別々に開発会社へ要望を伝えてしまい、開発会社が板挟みになる。
- 「専門的なことは分からないから」と、判断そのものを開発会社に丸投げしてしまう。技術的な実装方法は開発会社に委ねてよいが、業務上どちらが望ましいかという判断まで委ねてはいけない。
- 仕様変更や追加要望を、口頭やチャットの一言で済ませ、記録に残さない。後になって「そんな話は聞いていない」という食い違いの温床になる。
- テスト工程を「開発会社がやってくれるもの」と誤解し、実際に業務を回す現場の担当者による受け入れテストが不十分なまま本番稼働してしまう。
- 予算超過や納期遅延の兆候が出ても、早期にエスカレーションせず、経営判断が必要なタイミングを逃してしまう。
これらのパターンに共通しているのは、いずれも「誰かがやってくれるはず」という思い込みだ。開発会社は魔法使いではない。発注側から明確な情報と判断が届かない限り、開発会社にできることには限界がある。
まとめ
システム開発は、発注書にサインをした瞬間に始まるのではなく、そこからが本当のスタートだ。開発会社は指示されたことを形にするプロフェッショナルであり、業務を熟知し、意思決定の権限を持つのは、あくまで発注側である。この二つの役割が噛み合って初めて、プロジェクトは正しい方向へ進んでいく。
専任のプロジェクト管理者を置ける余裕がなくても構わない。週に一度の進捗確認、決定事項を記録に残す習慣、社内の声を一本化して届ける窓口。これらを誰か一人が意識的に引き受けるだけで、プロジェクトの成功確率は大きく変わる。それは、忙しい本業の合間を縫って行われる、地味で目立たない仕事かもしれない。しかし、その積み重ねこそが、開発会社と発注側という二つの壁を越えて、確かな成果を築き上げていく力になる。
もし今、自社のプロジェクトで「開発会社に任せているので大丈夫」という言葉だけが独り歩きしているとしたら、それは危険信号かもしれない。今日からできることは小さい。次の定例会で、進捗のガントチャートを自分の目で確認してみること。それだけでも、プロジェクトの景色は変わり始める。