高校時代、わたしはワシントン州のピュージェット湾に浮かぶ小さな島、バションのガソリンスタンドでアルバイトをした。そこには地元のうるさがたが集まり、いかに世の中がどんどん悪くなっているかを論じ合っていた。わたしはそこでメカについて多くの学習経験（要するに失敗）を積んだが、その1つの後で店長のデール・クイッケンバーナー氏からいつものように説教を受けていたとき、初めてこの賢明なアドバイスを聞いた。「思い込み（ASSUME）はいかんぞ、ジョンソン。ばか（ASS）を見ることになる。君（U）もおれ（ME）もだ」

　最近、われわれのERPプロジェクトの遅れを反省していたときにこの言葉を思い出し、わたしのチームにいかに多くの思い込みがあったかに思い至った。

思い込み1：危ない兆候もあるが、計画どおりに進められる

　われわれのプロジェクト計画は強行軍だった。最初のミーティングで、われわれのベンダー（エクリプスコンピューティング）のプロジェクトマネジャーに目指す稼働時期を伝えた時、彼の右の眉が引きつったのをわたしは見た。だが、われわれは計画を達成しようと突き進んだ。

　わたしの失敗は、遅れているという危険信号を無視してしまったことだ。われわれは前に決着のついた問題を蒸し返して貴重な時間を浪費した。それなのに、わたしは万事順調だと思い込んで、期日どおりの稼働に向けてチームに作業を進めさせた。

思い込み2：期日を守れるかどうかは自分たち次第

　作業完了日がずれ込んでいったため、定例プロジェクトミーティングで進行状況を検討するまでもなく、期日には到底間に合わなくなったことに気付いた。しかも、ベンダーのプロジェクト責任者から電話がかかってきた。彼のチームがバグを発見したとのことだった。われわれは期日を3カ月延期し、プロジェクト計画全体を見直した。

　ベンダーを非難するわけにもいかず、新たに余裕のないスケジュールを組んだ。われわれは4つのフェーズで作業を行う予定だったところを3つのフェーズでこなすことにした。また、最初のフェーズを実施した後で以降のフェーズの業務手順を作成するといったように、順を追って行う予定だったことを、同時並行で進めるようにした。だが、全体をうまく進行させるには、ほかの問題も解決しなければならなかった。

思い込み3：誰もが同じ前提を共有している

　期日の延期を発表した段階で、われわれは品質管理の不備を発見した。標準業務手順書（SOP）の作成担当者の作業成果物であるドラフトに、一貫性がなかったのだ。ある担当者は、熟練ユーザーがSOPを利用すると想定して、基本的なことしか記述しなかった。別の担当者は、この文書がリファレンス資料とトレーニング資料を兼ねると想定して、キー操作の手順まで盛り込んだ。

　そこでわれわれは、SOPの利用者を明確にした。4時間のトレーニングを受講済みだが、仕事をする上でSOPを必要とする初心者ユーザー、というものだ。トレーニング資料はわれわれではなく、ソフトを提供するベンダーが作成することになった。

思い込み4：“誰かほかの人”が検証してくれる

　レビューの過程で、SOP担当チームがソフトを実際に使って内容を検証せずにSOPドラフトを承認していたことが判明した。チームの全員が、これらのドラフトに記載された手順のチェックは誰かほかの人が担当していると思い込み、その結果として書き直しが延々と繰り返されていた。このため、われわれは検証プロセスを設けた。

　米国人は遅れを嫌うし、プロジェクトが成果に結び付かないことについても同様だ。だが、この数カ月に学んだ教訓は、プロジェクトで肝心な、ユーザーが本格的にかかわる段階で役に立つだろう。期日の延期でユーザーにとっては時間の余裕ができたことを生かし、バックオフィス部門のユーザーにミニトレーニング講習で十分な知識を提供することができる。また、フロントオフィス部門のビジネスプロセス設計チームは、明確なSOPドラフトを利用して、われわれが用意した新しい業務手順の案に肉付けしていくことができる。

　こうしてわたしは、こんな仮説に至った――クイッケンバーナー氏の教えをついに身につけたと。

本稿筆者のレス・ジョンソン氏は、電力卸売会社ノースコーストエレクトリックのCIO。

（この記事は2006年1月24日に掲載されたものを翻訳しました。）