悩み多きユーザ企業

悩み多きユーザ企業

多くのユーザ企業が、システム開発で悩みを抱えているのではないでしょうか。

システム発注の前段階では、

（１）コンピュータの事はよく判らず、システム導入するために何をしたらよいのかわからない。

（２）システムの開発をどの会社に頼んだらよいのかわからない。

（３）契約書にはどのような条項をいれるべきなのか。

などなど。


システム開発段階、導入段階では、

（１）納期通りにシステムが出来上がらず、いつになったら導入されるのかわからない。

（２）当初の予算を大幅にオーバーしてしまい、いったいいくら掛かるのかわからない。

（３）出来上がったシステムを、どの様に受け入れ検収したらよいのかわからない。

などなど。

実際にシステム調達のコンサルをやらせていただく際、ユーザ企業はシステム発注までに何をすべきか、そしてどの様に段取りを立ててベンダーにシステムを発注すべきなのかを明確にします。

そして、システム開発段階、導入段階でのユーザ企業のすべきことも。

それでも、システム開発の様々な工程で問題は発生するものです。

私は、指導者面した表面的なコンサルをするのではなく、ユーザ企業のエージェントとして効率的なシステム調達のお手伝いをすることを目的とし、一緒に作業を進めていく方法をとっているので、ユーザ企業の内実にドンドン突っ込んでいきます。

そのため、一緒に悩みを抱えてしまうことも度々ありますが・・・

その原因がユーザ企業側にあるのか、ベンダー企業側にあるのかによって対処の仕方は変わります。

その都度、問題解決に向けた対策をたてて調整をするのですが、ベンダー側の原因による問題でかなり厄介なものもあります。

作業段取り

作業段取り

システム関連のコンサルをさせていただいているユーザ企業（Ａ）の話です。

システム開発を担当するベンダーが、迷走状態と思える状況です。

ベンダー側の諸般の事情で、システム設計に関するユーザ合意（確認）を得られていない機能が存在するにもかかわらず、ベンダーの思い込みで勝手にプログラム製造を進めてしまい、そのシワ寄せが現れ始めているのです。

更に納期も近づき、本稼働に向けてやらなければならない作業も積み重なり、二進も三進も行かない状況を作り出してしまったのです。

今更ではありますが、作業段取りを立て直すべく、ＷＢＳ（Work Breakdown Structure）などにより作業を洗い出し、現状を正確に把握するようアドバイス。

しかし、そもそも段取りを立てることに不慣れなようで、結局は業務に追われてしまい空回り状態。

そうなると、当然ながらスケジュールは遅れます。

ところが、この状況をベンダーの営業担当や技術部門の責任者は正確に把握しておりませんでした。

プロマネから正確な情報が伝えられていなかったのです。


逆に、スケジュール遅れの原因は、

◇製造したプログラムの仕様変更が発生した

◇ユーザ側の検収が遅れている

などと捉えており、あたかもユーザ側に責任があるような言い様。

追加費用は、どちらが負担すべきか（その５）

追加費用は、どちらが負担すべきか（その５）

システム開発過程におけるシステム開発費の追加。

今回は　『納期遅延』　に係わる追加費用について取り上げてみたいと思います。

◇◇◇◇◇◇◇◇◇◇

システム開発がスケジュール通り進行せず、その結果、納期に間に合わなかった事に付随する費用はどうすべきでしょうか。

ベンダーが納期に間に合わなかったのだから、ベンダーが負担して当たり前であり、それよりも、納期遅延に対するペナルティを科すべきだ！

との声がユーザ企業から聞こえてきそうです。


ベンダーからは、ユーザ企業側は自分の落ち度は棚上げし、全ての責任を押し付けるのか？

と反論の声が聞こえてきそうです。


そもそも、納期遅延を引き起こした原因は何だったんでしょうか？

ユーザが要件を確定しない？

ベンダーの能力？

理由は様々でしょうが、それぞれの立場により主張が異なるのは当たり前です。

どの様な経緯で納期が遅延してしまったのか、事実を明確にしなければ、その責任の所在すら明確になりません。

その為には、納期遅延はシステム開発のリスクの1つと認識し、常に状況を把握できるプロジェクト運営が望まれます。

追加費用は、どちらが負担すべきか（その４）

追加費用は、どちらが負担すべきか（その４）

システム開発過程におけるシステム開発費の追加。

今回は、『システムテスト／検収時に発生する追加費用』 を取り上げてみたいと思います。

◇◇◇◇◇◇◇◇◇◇

システムテスト／検収工程。

この段階で追加費用が出てくるというのは、明らかに　『要件漏れ』　『考慮漏れ』　『設計ミス』　が原因の大半を占めることでしょう。

基本的には、ユーザ企業またはベンダー企業のどちらの　『落ち度』　で発生したかによって、追加費用の負担先が決ることでしょう。

ただ、どの様な経緯でこの工程まで進んできたのか、その間にどの様な合意がなされたのかなど、設計書や議事録などに証拠を残しておかなければ　『落ち度』　を判定することは非常に難しいでしょう。

ただ、判定する材料がないとベンダー企業が圧倒的に不利になるでしょうが、ユーザ企業もその事を逆手に取らず、真摯に協議する姿勢が望まれます。

◇◇

まずは、起こさないようにするにはどうしたら良いかを考えたほうが建設的ですね。

ちょっと一息。 と思いきや・・・

ちょっと一息。　と思いきや・・・

先週、システム調達の支援をしているユーザ企業（A社)での提案依頼書（RFP)作成も終わり、無事にベンダー数社に対して提案依頼を行いました。

ここに至るまで、責任者である常務と新システム企画および導入推進役である事業部長は、通常の業務をこなすなかで社内調整に奔走。

傍ら私は、提案依頼書（RFP）を作成。

二人三脚ならず、三人四脚で喧々諤々とプロジェクトを推進してきたため、提案依頼説明会終了後、やっとここまで漕ぎ着けたとの安堵感。

ベンダー各社から提案書が出てくるまでの間、A社のプロジェクトはちょっと一息。

と思いきや、

追加費用は、どちらが負担すべきか（その３）

追加費用は、どちらが負担すべきか（その３）

システム開発過程におけるシステム開発費の追加。

今回は、『システム設計の考慮漏れ』 を発生要因として取り上げてみたいと思います。

◇◇◇◇◇◇◇◇◇◇

要件定義も終わり、システム設計工程へ。

ここで、『要件確定』　と　『仕様確定』　とは違うと言う事を認識しておいたほうが良いでしょう。

『何をしたいのか』　と　『どの様に実現するのか』　と言葉を置き換えれば一目瞭然です。

また、システム設計も、基本設計（外部設計） と詳細設計（内部設計） がありますが、この違いも認識しておいたほうが良いでしょう。

基本設計（外部設計）は、要件定義をもとに、システム全体をどの様に組み立てるのかを明確にするもの。

詳細設計（内部設計）は、基本設計（外部設計）をもとに、システムを組み立てる部品をどの様に作るのかを明確にするもの。

とは言っても、開発方法論 （ウォーターフォールやプロトタイピングなど） によって違いがあるので一括りにはできませんが、どんな開発方法論であっても、全体のコンセプトを明確にせずに部分（部品）を作ると、後戻りが増えるという事は明白でしょう。

◇◇◇◇◇◇◇◇◇◇

システム設計を進めると、大体システム規模が膨れ上がるものです。

追加費用は、どちらが負担すべきか（その２）

追加費用は、どちらが負担すべきか（その２）

システム開発過程におけるシステム開発費の追加。

今回は、『業務要件漏れ』 を発生要因として取り上げてみたいと思います。

業務要件漏れは、主に、要件定義工程でおきやすいと思います。

どういう形式（例えば、提案依頼書（RFP））であれ、ユーザ企業はシステム化の要件をベンダーに伝えてあるはずです。

ベンダーは、そのシステム化要件を元に見積りを提示していることでしょう。

ただ、その見積書が 『正式見積り』 なのか 『概算見積り』 なのかにより、システム開発費に与えるインパクトは変わってくるはずです。

何故なら、システム開発費が確定してスタートしたのか、それとも確定していないでスタートしたのか、と言葉を変えれば一目瞭然です。

システム規模が大きくなればなるほど不確定要素が多くなり、ベンダーもリスクを回避するために 『概算見積り』 として提示せざるを得ません。

そして、要件定義を終えた後に正式見積りを出すので、当初概算見積りより大幅に費用が膨れる事がありえます。

『正式』 『概算』 どちらの見積りであっても、要はユーザ企業が提示するシステム化要件と、要件定義工程との結果に差が出なければ、この段階でシステム開発費が追加される事はないでしょう。

結局は、ユーザ企業が発注前にどれだけシッカリと検討を重ね、ベンダーに十分な情報を提供したかに依るのです。