システム構築の現場では，ユーザーと開発者による何回もの打ち合わせを経てシステムを実装しているはず。しかしながら，設計書の段階では目に見えなかったシステムが，工程が進むにつれて形になってくると，ユーザー側で「これは言っていた仕様と違うのでは？」という認識のギャップがよく発生する。
|
設計書は膨大な量になることが多い。開発者は仕様を凍結する際に，仕様全体を説明しなければならないが，「残された時間が少ないときなどは，設計書をすみずみまで説明するのは難しい。ユーザーにとって業務上インパクトの大きい部分だけを説明することがどうしてもある」（あるベンダーの開発者）。しかも，仕様凍結時に説明していない部分は，それまでの話し合いで合意しているから大丈夫だろうと考える。こうして開発工程が進んでいくと，「言った，言わない」というトラブルが発生しやすい。
小刻みにレビューを受ける
こうした問題を完全に防ぐのは難しい。人と人が会話を通じて仕様を詰めていく以上，どうしても解釈に食い違いが生じてしまう。ただし，工夫を凝らせば，ある程度はトラブルの種を減らせる（図5）。
| |
|
図5●「言った，言わない」のトラブルを防ぐ現場の工夫 |
その工夫の一つは，こまめにユーザーの同意を得ることだ。日立システムアンドサービスの上野氏は，「議論の内容をその場で議事録にとり，内容の確認をユーザーに求めている」という。こうすれば議事録を作成することを忘れてしまうという初歩的なミスを防げる。さらに，会社に持ち帰ってから議事録を書く場合には，「『ここはこういう意味だったはず』という勝手な解釈が入り込んでしまう。それを防ぐ効果もある」（上野氏）という。
別の工夫として，小刻みにレビューを受けるという方法もある。打ち合わせから日が経ってしまうと，会話した内容をどうしても忘れてしまう。そこで，システムインテグレータの松田氏は，「時間さえ許せば，1週間間隔など，小刻みに設計書のレビューをユーザーに求める」ことを実践している。こうすることで，ユーザーと開発者の両者が，議論したことを覚えているうちに設計書の内容を確認できる。
さらにこの方法を使うと，仕様を凍結する際に，ユーザーのレビューにかかる負担を緩和できる可能性がある。分厚い設計書を目の前にすると，「すべてを読んで理解するのは無理」とたじろいでしまい，理解するのを最初から諦めてしまうこともあるからだ。
|
仕様変更が生じることをあらかじめ想定していれば，実際に起きた際に慌てずに済む。仕様を変更する際にユーザーと開発者の間で一番もめるのは，「お金と納期」なので，ここに余裕率を盛り込んでおきたい。
実際，「開発費の数％を，リスク分として別に予算化しておいてほしいと，以前から取引のあるユーザーには伝えている」と富士通の福冨秀則氏（共通技術本部 SDAS推進統括部 統括部長）は話す。さらに，「その予算をお互いに“見える化”しておく。仕様変更の会議のたびに，予備の予算の減り具合がお互いに分かるので，腹の探り合いにならない。結果としてプロジェクトが成功することが多い」（同氏）と説明する。
ただし，ユーザーと開発者がお互いに腹を割って話せるケースばかりとは限らない。「確かにうまくいくプロジェクトでは，ユーザー側が，ある程度余裕を持ってプロジェクトに臨んでいることはある。しかし，中小規模の企業の場合はシステム化の予算取りが厳しく，ほとんど余裕がない」（日立システムアンドサービス 執行役 石井清氏）。しかも，「数社のベンダーがコンペで提案するような場合，ぎりぎりの線で見積もりを提案する。余裕率を盛り込むのはなかなか難しい」（同氏）というのが実情だろう。こうしたプロジェクトでは，仕様変更そのものが発生しにくいように，上流工程での対策を強化する必要がある。
