半年かけて作った完璧な資料がある。承認も通っている。関係者全員の合意も取れている。
しかし、現場では1日も使えない。
これは極端な話ではない。実際に何度も経験してきたことだ。
PMとして多くのプロジェクトに関わる中で、確信したことが1つある。現場に行かなければ、何も始まらない。 これは個人の経験則ではなく、PM手法としての現場主義だ。そして、現場で見つかる答えは、いつもシンプルだ。
物流倉庫で見た「机上の空論」
ある物流倉庫の管理システム（WMS）を開発したときの話だ。
案件の状況
クライアントは、エクセルやメールで運用していた倉庫管理をシステム化したいという依頼だった。運用自体はある程度回っている。それを効率化するためのシステム構築だ。
管理部署の担当者がシステムの要件定義と運用フローを検討していた。
しかし、その担当者は倉庫の現場に一度も行ったことがなかった。
倉庫は業者に丸投げ。管理部署は「なんとなくわかっている」レベルで、現場の実態を知らないまま、机上で完璧なフローを設計していた。
出てきた「完璧なフロー」
管理部署が出してきた運用フローは、一見すると隙がなかった。
しかし、中身を見て愕然とした。
同じ商品に対して10回以上のピッキング作業が設計されていた。
- 注文確認のためのピッキング
- 数量確認のためのピッキング
- 出荷準備のためのピッキング
- 出荷前最終確認のためのピッキング
- ...
さらに、すべての商品に固有のラベルを貼り、数量管理ではなく1つ1つバーコードを読み取るフローになっていた。
数千、数万の商品を扱う倉庫で、1個ずつバーコードを読む。10回以上ピッキングする。
管理者の視点では理解できる。1つの動作レベルで在庫状況をリアルタイムに把握したい。 その気持ちはわかる。
しかし、現場の人間の身にもなれ。
実際の倉庫で、1つの出荷に対して10回以上同じ商品を手に取り、毎回バーコードを読み取る。これを何百回、何千回と繰り返す。人間がやる作業としてありえない。
現場に行った
私は管理部署の会議室を出て、倉庫の現場に行った。
実際の作業を見学し、作業者と話をした。そこで見えたものは、管理部署が想像していたものとは全く違った。
- 作業者は効率的な動線を自然に作っている
- 長年の経験で、どの商品がどこにあるか体が覚えている
- エクセル管理でも、実運用は十分に回っている
- 問題は「管理部署が状況を把握できないこと」であり、「現場の作業が非効率なこと」ではなかった
問題の本質は、現場ではなく管理側にあった。
管理部署が求めていたのは「現場を完璧にコントロールすること」。しかし、現場は既にうまく回っていた。必要だったのは、現場の動きを邪魔せずに、管理側が状況を見えるようにすることだった。
私がやったこと
管理部署のフローを全面的にやり直した。
現場目線と管理目線の中間を狙った機能設計を行った。
- ピッキングは最小限の回数に削減
- バーコード読み取りは要所のみ（入荷時と出荷時）
- 管理側が見たいデータは、システム側で自動集計
- 現場の作業者の動線を変えない設計
結果は、管理部署が半年かけて作ったフローの1/3以下のシンプルな設計になった。
ここで、もう1つの問題がある。
半年の資料作成、3ヶ月の開発
管理部署は半年以上かけて資料を作成していた。 しかし、いざ開発に入ると納期は3ヶ月。
しかも、半年かけた資料にはシステムの具体的なロジックがほとんど書かれていなかった。「この処理はどういうロジックで動くのか」「データの整合性はどう担保するのか」——こうした肝心な部分が曖昧なまま。
半年間、何を話していたのか。
会議の設定に1週間、承認に2週間、次の会議まで1週間——このサイクルで半年が消えていた。プロセスは回っていたが、プロジェクトは1ミリも前に進んでいなかった。
ここからヒアリングをやり直し、現場と管理の中間を狙った設計を短期間で仕上げた。再設計は約2週間、開発は3ヶ月の納期内に収まった。管理部署の当初フローをそのまま実装していたら、開発工数は倍以上に膨らんでいただろう。時間がないからこそ、本当に必要なものだけに絞る。 結果的に、シンプルな設計が最短の開発を可能にした。
5Gネットワーク立ち上げで学んだ行動原則
WMSの経験の前に、もう1つ私の仕事の仕方を決定づけた経験がある。
某通信キャリアの5Gネットワーク立ち上げプロジェクトだ。
ゼロからのスタート
5Gの立ち上げは、文字通りゼロからだった。
- 運用フローがない
- 技術資料がない
- 前例がない
- すべてを作らなければならなかった
しかし、ゼロから作る以上に困難だったのは、誰も決めようとしないことだった。
「決めない人たち」
新しい技術、新しいネットワーク。前例がないから、判断の根拠がない。根拠がないから、誰も決められない。
決めたくない。責任を負いたくない。
この空気がプロジェクト全体を覆っていた。
仕様を決めようとすると「もっとエビデンスが必要」。運用フローを提案すると「関係部署との合意が取れていない」。設計を進めようとすると「まだ早い」。
プロジェクトは完全に膠着していた。
電気をつけるには、スイッチを押すしかない
この状況で辿り着いた行動原則はシンプルだった。「電気をつけるには、スイッチを押すしかない。」 他に方法があるなら教えてほしい。ないなら、押して前に進めるしかない。このスタンスで動き始めた。
窓口を飛ばして直接担当部署に話を持っていった。根回しなしで方針を決めた。上の承認を待たずに設計を進めた。
PM手法としてのリスクと判断
正直に言えば、この判断にはリスクがあった。組織のプロセスを無視することで、関係者の信頼を損なう可能性があった。実際、「勝手に行動するな」「窓口を飛ばすな」とかなり怒られた。
しかし、結果的にプロジェクトは動き始め、最終的に5Gの立ち上げは成功した。
ここから得た教訓は2つある。膠着状態では、誰かが意思決定のリスクを引き受ける必要があるということ。そして、プロセスを飛ばすなら、その分だけ結果で証明する責任を負うということだ。推奨できる方法ではないが、PMとして「決断の引き受け手」になる覚悟は必要だ。
ここで学んだもう1つのこと。物事を観察し、因数分解し、再構築する。 そうすれば、答えはいつもシンプルになる。
「言語化できない」問題の本質
WMSと5G、2つの経験から見えた共通点がある。
クライアントは、自分が何を求めているかを正確に言語化できない。
WMSの管理部署は「完璧な管理」を求めていたが、現場の実態を知らなかった。5Gのプロジェクトメンバーは「正しい仕様」を求めていたが、前例がないから言語化できなかった。
しかし、言語化できないからといって、答えがないわけではない。
現場に行けば答えがある
WMSでは、倉庫に行って作業者と話すことで答えが見つかった。 5Gでは、「スイッチを押すしかない」という発想で前に進めた。
どちらも、会議室の中では見つからなかった答えが、現場にはあった。
要望が曖昧でも、明確な指示がなくても、現場に行く。実際に使う人と話す。実際の作業環境を見る。そうすれば、何が必要かは自ずとわかる。
これはPMの基本動作として、どんなプロジェクトでも再現できる手法だ。机の上で考えるのをやめて、現場に行くだけでいい。
AIでも同じアプローチを使っている
この考え方は、今のAI活用でもそのまま使っている。
クライアントが「AIでこういうことがしたい」と曖昧な要望を出してきたとき。私は聞く。
「今、実際にどうやってその作業をしていますか？」 「一番時間がかかっている工程はどこですか？」 「この作業をするとき、何が一番面倒ですか？」
理想の姿を聞くのではなく、現在の現場を聞く。 そこから因数分解して、AIで解決できる部分を見つける。
答えはいつもシンプルだ。複雑な要件定義書なんて必要ない。現場を見れば、何をシステム化すべきかは明白になる。
現場主義 x AIの実践サイクル
PMBOK-AIでは、この現場主義をAI活用の前提プロセスとして位置づけている。具体的なサイクルはこうだ。
- まず現場を見る。 データ分析をAIに任せる前に、現場で実際の業務を観察する
- 現場で仮説を立てる。 「この工程がボトルネックではないか」「この確認作業は省略できるのではないか」
- 仮説をAIで検証する。 AIにデータを分析させ、仮説の裏付けを取る
- 結果を現場に戻す。 AI分析の結果を現場の作業者にフィードバックし、実運用に落とし込む
AIに丸投げしても、現場の実態を反映しない分析結果が出てくるだけだ。現場で得た仮説をAIで検証し、検証結果を現場に戻す。 このサイクルが、システムの品質と現場の納得感を同時に上げる。
なぜ「完璧な資料」は役に立たないのか
WMSの経験で、もう1つ気づいたことがある。
完璧な資料を作ること自体が、プロジェクトの目的にすり替わる。
半年間、管理部署は資料を作り続けた。会議を重ね、承認を得て、修正して、また承認を得て。資料の体裁は完璧だった。フォーマットも統一されていた。
しかし、肝心のシステムロジックが書かれていなかった。
なぜこうなるか。理由は簡単だ。
資料を作ることには責任が伴わない。 「資料を作りました」「会議で報告しました」——これは仕事をしている「フリ」ができる。
しかし、「この仕様で決定します」「この設計で進めます」——これには責任が伴う。決断した人間が、結果の責任を負う。
だから、決断を避けて資料を作り続ける。 半年経っても何も決まらない。
これが、「請けたら負ける」構図の正体だ。
シンプルの本質
5G、WMS、マレーシアでのクライアントワーク——すべてを通じて辿り着いた結論。
シンプルとは、物事を観察し、因数分解し、再構築すること。
複雑に見える問題も、分解すれば1つ1つはシンプルだ。電気をつけるにはスイッチを押す。商品を出荷するにはピッキングする。データを管理するにはシステムに記録する。
1つ1つの動作はシンプルなのに、人間が「念のため」「万が一」「全員の合意」を重ねることで、10回のピッキングが生まれる。
必要なのは「念のため」を削ることだ。
- 本当に必要な確認だけ残す
- 本当に必要な承認だけ残す
- 本当に必要な工程だけ残す
残ったものが、シンプルな設計だ。 そしてそれは、たいてい現場の人間がすでに無意識にやっていることと一致する。
まとめ：現場の60点は、机上の100点に勝つ
完璧な資料を半年かけて作っても、現場で1日も使えなければ意味がない。
現場で60点の設計を3日で作って、すぐに動かす。 使ってみて問題があれば直す。これを繰り返す方が、結果的に良いシステムができる。
現場に行け。作業者と話せ。実際の動きを見ろ。
そこにある答えは、いつもシンプルだ。
みんなが難しく考えすぎている。電気をつけるには、スイッチを押すだけでいい。
「シンプルにする」という会社のスローガンについてはシンプルにする｜会議1ヶ月の世界で勝機を掴むために選んだ戦い方で詳しく書いています。AI社員との協業がどうプロジェクトを変えたかは1人社長がAIチーム4名を組むまでをご覧ください。
プロジェクトマネジメントやシステム開発についてのご相談はお問い合わせからお気軽にどうぞ。