Untitled

失敗しないシステム構築プロジェクト

*****

◎従来の手法は通用しない、成功に導く「新常識」を探る

納期、コスト、品質を守るだけでは成功とは言えない
システム構築に使う道具や、システム構築に求められるスピードも変化している。

★従来の常識
1)一括請負契約をする
2)下流工程になるほど人を増やす
3)設計と開発の分業体制
4)工程単位の計画

★新常識
1)できるだけ小さい単位で契約する。
・プロジェクトの期間はできるだけ短い方がよい。
・「まだまだ時間がある」という安易な気持ち。
・仕様変更、追加がずるずると出てくる。
・コアの部分を先行開発し、様子を見ながら必要な機能を盛り込んでいく。
・例えば、情報系ならば、プロジェクトを細かく分けて対応する。
・基幹系ならば、工程単位で契約を分ける。
・前工程の成果物をベースに見積もることができるため、リスクがヘッジされ結果的に安価。
2)上流工程からリソースを投入する
・上流工程（業務分析とか要件定義）さえしっかりしていれば、プロジェクトが失敗する危険性は低くなる。
・上流工程にたくさんの人材を投入すると、いろいろな意見が出てまとまりにくくなる。→プロジェクトマネージャの力量発揮の場。
・上流と下流の担当者を同じとする。
・コミュニケーションギャップを防止できる。
・ピーク時の要員が少ないため、管理コストが減る。
・「させる／やらされる」という意識がなくなり、高いモチベーションが維持できる。
3)要素技術ごとの分業体制
・設計と開発の分業はロスが多い。
・設計と開発の分業ではなく、要素技術や製品ごとの分業とする。
4)工程を細分化した作業単位の計画
・「工程」よりも小さな「作業」単位の計画を立てる。
・作業単位の計画によって、手戻りの発生を少なくできる。
・計画は変わる。でも作らなければならない。
・進捗管理がうまくいくコツは、情報をオープンにすること。

◎工数ベースの見積は矛盾が多い。
・工数ベースの見積は、生産性が低いほど価格が高くなる。
・ベンダとユーザの両者が納得のできる価格を探す。
　→FP（ファンクションポイント）法が一つの解決策。
　　FP法は機能が明確になったシステム開発に適している。
　→導入効果をベースに価格を決めるのが一つの解決策。
　　何も決まっていない段階での見積に有効。
・機能優先度を検討する。その時の判断基準は以下の通り。
　　1)ビジネス上の効果
　　2)技術上の実現可能性
　　3)ユーザ側の受入体制
・適性コストが先に決まっていれば、余計な投資を抑えることができる。

[所感］
何か、最近日経BP系の雑誌は、「旧常識を捨てる」というようなトーンが多いです。気のせいかもしれませんが。
ここで言っている「新常識」は、それぞれもっともだなあと思うし、特に目新しいものでないものもあるんですが、ではなぜそうなっていないのでしょう？
一つは、こういったやり方だと、ベンダにとって非常にシビアになると思います。特に小さい単位での契約や工程を細分化した作業計画などはかなりの負担になると思います。でも、それで成功するならばそんな苦労も厭うべきではないのでしょうが。
次、スキルの問題。上流工程を任せられる人材、分業できるだけの要素技術や製品知識を持った人材がどれくらいいるかということです。結局こういう人材が現実に居なければ絵に描いた餅でしかないわけですね。
最後、ユーザ側（発注側）の意識。ここで言っている新常識は、従来の文化を変えていかなければ実現できないと思います。で、ベンダ側がいくら頑張ったところでユーザ側が旧態依然としていのでは駄目ということでしょう。

見積の件ですが、FP法と導入効果の反映を挙げています。
FP法については、過去の実績が結構ものをいうため、ノウハウの蓄積が必要です。また、FP法をツールとして使えるスキルもそれなりに求められます。すぐに導入というわけにはいきませんが、長い目で徐々に導入していけば、いずれ効果がでてくる方法だと思います。
導入効果をベースに価格根拠を決める方法は、斬新だと思いました。ただ、よく考えると、ビジネスとしては当たり前のように思います。経営者が自社のシステム投資を考える際には、こういう発想は必ずあるはずです。
ベンダ側が対処できるかというのが一番気になる点です。

以上

（日経オープンシステム1999年10月号より）

情報技術スキルアップの種のページへ

GLORY's OFFICEへ