佐藤 三智子
「計画段階は足し算，開発段階は引き算」が開発プロジェクトを成功に導くカギである。計画段階では，関連部門からもれなく要望を集め，システムの目標を「足し算」で設定する。計画が了承されて，構築段階に入ってからは，常にシステムの開発目標と予想される効果を評価。開発が遅れたりした場合は，「引き算」をして大胆に開発範囲を縮小するべきだ。ただし，必ず達成すべき最重要の目標を変えてはならない。
新システムの構築について社長の了解は得た。予算も付いた。リーダーシップがある推進役も決まった。いよいよ開発プロジェクトに入るにあたって，注意すべきことは表1の3点に集約できる。しかし，この3点を守ることはそう簡単ではない。
(1) 利用部門の協力 |
業務仕様の絞込みや総合テストへ積極的に参画してもらう。自分たちが今回のシステム構築の当事者である，という意識を醸成してもらう |
|---|---|
(2) 仕様変更の最小化 |
開発工数の増加抑制，開発日程の確保，品質保持，予算額の維持のために，仕様変更は必ず抑えるべきである |
(3) 枯れた技術の採用 |
新技術をむやみに持ち込まない。未経験の技術には信頼性の確保や見積もり通りの生産性を達成するためのリスクが付きまとう |
プロジェクト管理の壁 (1)
利用部門の要望をまとめられない
組立部品メーカーA社は現在，新しい生産管理システムの構築に取りかかっているところだ。生産管理課長が情報システム担当者を兼任し，システムの設計から構築に至る作業はソフト会社に全面委託している。
開発にあたっては，「プロトタイピング手法」を採用。設計段階でシステムを利用部門に見せて，利用部門とソフト会社で意見交換をしながら使いやすいシステムを構築することにした。現行の生産管理システムを構築した時には，利用部門の意見をほとんど取り入れなかったため，「使いにくい」という指摘が現場から出ていた。
ところが，実際に利用部門の意見を聞いてみると，たびたび要望が変わる上，まったく新しい要望が発生し，なかなか設計仕様がまとまらない。しかも一部の利用部門は勝手にソフト会社と連絡をとり，仕様変更を直接依頼し始めた。設計の日程が大幅に遅れる危険が出てきたほか，仕様変更に伴い開発費が予想より増加するという難関にぶつかってしまった。
生産管理課長が「これ以上の仕様変更は認められない」と利用部門を説得しても，「要望が認められないなら，新システムに変える意味がない。わが部門は現行システムのままでもかまわない」と開き直る部門まで出てきた。最終的な仕様を固められず，生産管理課長は弱り果てている。
プロジェクト管理の壁 (2)
本番直前に設計ミスが判明
「オンラインが止まった」。総合テストをしていた営業部で，営業部係長の大声が響いている。衣料品製造のB社は，新しい販売管理システムを構築中である。新システムの構想は意欲的だった。受注・出荷情報をリアルタイムに反映でき，最新の在庫情報に基づいて受注処理や出荷手配を進められるようにする計画だった。
システムの開発は順調に進み，本番運用直前の総合テストに入った。営業部・工場・物流部に設置した端末から，本番と同様のデータを入力していった。総合テストも順調に推移していたが，「朝一番」を想定したテストで問題が発生した。
プログラムに不備がありオンラインの処理が停止してしまった。そこでシステムを再度立ち上げて，データ入力を続けようとしたが，新システムは入力中に処理が中断すると，それまで入力していたデータが消滅する設計になっていることが分かった。
朝一番の段階では，前日の業務が終了した後に発生した受注・出荷データをまとめて一気に入力しなければならない。その数は30～40件と多い。もしシステムに障害が起こると，これだけのデータを最初から入力し直さなければならない。B社は開発を委託したソフト会社に改善を申し入れた。
ベンダーはシステム仕様の不備は認めたものの，「基本設計まで戻って改善する必要があるので，期間として半年間いただきたい」と返答してきた。半年間も本番時期を遅らせてこの課題を解消するか，あるいは問題は残っているものの予定通りカットオーバーしてしまうか。B社は難しい判断を迫られている。
