納期延期

納期延期

納期に間に合わないシステム開発プロジェクト。結構多いんです。

納期遅延を引き起こす原因は様々ですが、最近、実際のコンサル現場で発生したプロジェクトを例にしてみると、

遅れの原因として、

◆プロジェクトの立ち上げ遅れ

ベンダー側のプロジェクトが発足したのは発注後１ヶ月。元々タイトなスケジュールがより一層タイトに・・・

◆プロジェクト要員の確保遅れ

ベンダーが必要数の要員を確保できず？

ただこれは、このシステム開発規模からすると何人のＳＥが必要かという私の経験からの感覚なので何とも言えませんが・・・

◆要求事項に対する理解度

一般的に考えると特殊な業務であり（但し、その会社では当たり前の業務ですよ）、なかなかユーザ側の意図する事が理解されず・・・

ベンダー選定にあたり当該業界での経験を重視したのですが・・・

◆ドキュメント纏めの遅れ

ベンダー側の要員が揃わず、担当ＳＥが何役もこなさなくてはいけない状況。逆にこちらが心配する有様・・・

でも担当ＳＥは焦りからどんどん先へ進めるが、その内容が設計に反映されない・・・

結局は、仕様が後戻りしてしまう事に。

◆対策の遅れ

経験上、諸々と対策を立てなければならない状況になり、イエローカードを出しました。

早速、ベンダーより体制強化などの対策案が出されましたが、結局は思うように体制強化が出来ず・・・

悩み多きユーザ企業

悩み多きユーザ企業

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

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

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

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

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

などなど。


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

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

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

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

などなど。

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

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

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

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

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

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

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

作業段取り

作業段取り

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

◇◇◇◇◇◇◇◇◇◇

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

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

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


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

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


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

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

ベンダーの能力？

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

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

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

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

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

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

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

◇◇◇◇◇◇◇◇◇◇

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

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

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

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

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

◇◇

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

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

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

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

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

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

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

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

と思いきや、

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

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

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

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

◇◇◇◇◇◇◇◇◇◇

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

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

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

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

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

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

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

◇◇◇◇◇◇◇◇◇◇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

当初の契約額を超過する要因が発生してしまい、ベンダーがユーザへ追加請求する事を指していますが、この追加費用は全てユーザが負担するものなのでしょうか？

追加費用はどの様な場合に発生し、発生した費用はユーザとベンダーのどちらが負担すべきかを、要因ごとに考察してみたいと思います。

今回は、第1回目として、『ユーザ側の検討不足』 を取り上げてみたいと思います。

これは、ユーザ側が何の為に、どの様なシステムが必要なのかなど、システム化を十分に検討せず、要件があやふやな状況でベンダーにシステムを発注してしまうケースです。

ユーザ側としては、システム開発のことは良く分からないのでベンダーに全てを任せてしまえば安心、との裏付けのない根拠？に基づいて、システム開発の全てをベンダーに丸投げしてしまえば楽ですから。

でも、ちょっと待ってください。

技術者面談

技術者面談

システム開発会社の知人より、技術者がいたら紹介して欲しいとの相談が頻繁に舞い込んできます。

最近は、システム開発の案件も増えているようで、どこのシステム開発会社も人手不足状態。

新規の開発案件を積極的に獲得したいとの想いとは裏腹に、技術者がいないので積極的に案件を取りにいけずジレンマに陥っている会社が結構多いようです。

また、新規の案件を獲得したのは良いけれど、社内には対応する技術者がいないため、人手不足で困っている会社も結構多いようです。


そうなると、まずは協力関係にある同業者へ打診し、技術者を調達しようとします。

協力会社でも人手がないと、同様に同業者へ打診し、技術者を調達しようとします。

こうして　『案件情報』　なるものが飛び交う様になります。

そうすると面白い事に、同じ案件で条件（SEなりPGの単価）が違う　『案件情報』　が手元に届くことがしばしばあるのです。

単純に考えれば　『経由した会社数』　によって条件が違うと言う事であり、経由した会社がそれぞれにピン撥ねをするという事です。

ユーザ企業と直接接点を持つより、大手ベンダーとの接点に営業フォーカスを当てている会社の方が圧倒的多数である実情を考えると、仕方のない　『仕組み』　なのでしょうか。

でも、この　『仕組み』　でピン撥ねされるお金は、ユーザ企業が負担しているんですよね。

ベンダーとの痺れる交渉

ベンダーとの痺れる交渉

とある会社の、基幹系システム全面リプレイス・プロジェクトにおいて、プランニング段階より関与しております。

諸々の事情により当初のスケジュールよりも遅れてしまいましたが、何とか総合テストに突入。

しかし、必要機能の不備が発覚・・・・・

対応について、即座にベンダーと協議に入りましたが。。。

ベンダーの言い分

ベンダーの言い分

先日、１０年来付き合いのあるベンダー企業の営業部長を訪問した時の話しです。

打合せ中、携帯電話に頻繁に連絡が入り、その都度打合せは中断。

普段は打ち合わせを中断する事がない方なのですが、相当切羽詰った急用と察し、やっと落ち着いたところで尋ねてみました。

すると、
最近システム開発でのトラブルが頻発し、顧客からのクレーム処理に追われてしまっている　
と嘆いていました。

その営業部長が言うには、
トラブルの大半が開発段階における設計段階への後戻り

で、それが原因で
納期へかなり影響が出るほどのスケジュール遅れ
となってしまっているとの事。

早いもので12期目

早いもので12期目

2006年5月に会社を立ち上げ、あっという間に12期目に突入しました。

ご支援いただける方やお客様に恵まれとこともあり、何とかここまでやってこれ、

感謝の想いでいっぱいです！


私がこの会社を立ち上げた理由、それは・・・・・