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

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

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

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

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

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

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

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

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

技術者面談

技術者面談

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

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

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

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


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

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

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

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

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

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

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

IQOS

ブログの趣旨と全然違う投稿ですが・・・

何気に立ち寄ったタバコ屋さん。

何故か人が多く、何事かと思えば、購入が困難と聞いていたIQOSが大量に入荷したとの事。

予約した人で溢れていたんですね。

予約してなくても購入できるとのことなので、衝動的に購入してしまいました。

ちょっとラッキーな日でした。

こちらもご覧ください

最終検収

最終検収

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

現在、受け入れ検収段階にあり、業務シナリオに沿った最終運用テストを実施しております。

当初はバグが結構ありましたが、ベンダーの誠意ある対応で、やっとここまで漕ぎ着けたとの想いです。

ただ、業務を想定しながら運用テストを行っていくと、ユーザ側では　

『あ！　ここはこうしたい』　

などと、この段にきたからこその要望事項が結構でてきます。

このユーザ企業においても、最終検収を行っている段階で、幾つかの要望が挙がってきました。

ベンダーとの痺れる交渉

ベンダーとの痺れる交渉

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

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

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

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

ベンダーの言い分

ベンダーの言い分

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

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

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

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

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

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

早いもので12期目

早いもので12期目

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

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

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


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

困った出来事

困った出来事

知り合いの社長からの一報。

要点を簡単にまとめると、

業務システム用のサーバがクラッシュしてしまったので、新しくサーバを購入。
　☟
　☟
本来であれば、システムを構築してもらった会社に連絡し復旧を依頼するとこだが、
保守契約を結んでいなかったので、ベンダーから納品されていたインストールCDを
使い、自社で新サーバへシステムをインストール。
　☟
　☟
無事インストールが終了。

さあ！復旧と思い、
クライアントPCを立ち上げたところ、まったく駄目。

これ以上、自力で復旧する事は困難と判断し、システムを構築したベンダーに連絡。

ここまでは、そんなに驚く事ではなかったのですが・・・

プロジェクトマネージャって・・・

プロジェクトマネージャって・・・

システム開発プロジェクトがスタートする時、ベンダーからプロジェクト体制が明示されますね。

ベンダーによって違いはあるでしょうが、概ねプロジェクトマネージャを筆頭に、プロジェクトリーダ、サブリーダ、メンバーと階層化されて、それぞれの役割りが示されてます。

でも実際にプロジェクトがスタートすると、

何でこの人がプロジェクトマネージャーなの？

単に、年次が上がったからプロジェクトマネージャとして配置されたの？

と疑問に思うことがあります。

これが業務委託契約書？

これが業務委託契約書？

つい先日、ある方から受けた相談です。

ホームページを立ち上げるため、ある会社にホームページ制作をお願いしようとしたそうです。

早速、その会社より見積書と契約書が送られてきたのですが、記載されている条項や文言が良く分からない。

システムの業務委託に詳しくない方は、良く分からないけど 『プロ』 の言う事だからと、直ぐに契約してしまうところでしょう。

しかし、何かピンと来ることがあったのか、見積書と契約書を精査して欲しいとの依頼でした。

得手分野を持ったベンダー

得手分野を持ったベンダー

あるお客様の話です。

そのお客様は、基幹系システムの全面更改を検討しておりました。

私は、その検討段階からプロジェクトに参画したのですが、提案依頼書（ＲＦＰ）を取りまとめ終わった段階で、どのベンダーに声を掛けるかを協議。

諸般の事情により、それほど期間を掛けられない。

当然ながら、青天井で予算を組むこともできない。

そこで、当該業種向けの実績があり且つ当該業種向けのパッケージシステムを持っているベンダーに絞って提案をお願いいたしました。

ベンダー確定までの経緯は省略しますが、コスト／期間／品質面でお客様の要望を満たしそうなベンダーを選定し、いざプロジェクトがスタート。

ユーザ企業の戸惑い

ユーザ企業の戸惑い

これまでに数社のシステム調達の支援を行ってまいりましたが、各ベンダーより示される見積り費用の 『差』 について、皆さん驚かれるようです。

提示した提案依頼書（RFP）に基づき、各ベンダーより提案書が提示されるのですが、そこに記載されている見積額を比較したとき、

何故こんなにも金額差があるの　？？？？　

その差に驚きを隠せないようです。

ましてや、安い見積りを出してきたベンダーであっても、提案依頼書（RFP）で提示した要件は全て満たしているとなると、もう理解不能のようです。

でも、これがシステム開発の実態ではないでしょうか。

テスト不足が招く不幸

テスト不足が招く不幸

いくつかのプロジェクトで共通的に起こっている現象があります。
端的に言ってしまえば、ベンダーによるテスト／検証不足によるシステム障害。

テストと言っても色々なレベルがありますが、

まずは単体テスト

作成したプログラムが所定の機能を満たしているか、または、誤動作をしないかなど、作成したプログラム単位で行うテストです。

システム開発 失敗しないために

システム開発　失敗しないために

（１）社内にプロジェクト体制を組む
（２）何をやりたいのかを明確にする
（３）適切なベンダーを選定する
（４）システム化の意向をベンダーへハッキリと伝える
（５）ベンダーと協力しながらシステム化を進める
ユーザ企業がやるべきことを簡単に言ってしまえば以上です。

プロジェクトメンバーは、コンピュータに詳しくなくても良いのです。
まずは、意思決定権限を有する責任者です。
社長が最適。無理ならば、役員以上の方が適任です。

何故なら、本来システム化には基本的に業務改善が伴うからです。
意思決定できる方のいないプロジェクトは、本来のシステム化の目的を達成できない傾向にあります。

システム開発 失敗が多いのは何故（４）

システム開発　失敗が多いのは何故（４）

ユーザ企業側の問題として触れた点を、掘り下げて考えてみたいと思います。

『システム化の知識に乏しく、ベンダーへ丸投げしてしまう　(依存型）』
『システムを導入すれば、漠然と経営強化や効率化が図れると思っている　（幻想型）』
『経営面から、システム化の目的や目標が十分に検討されていない　（無目的型）』


上記のような問題を整理すると『システム開発の本質とその進め方の問題』と言えるのではないでしょうか。

システム開発とは単にコンピュータシステムの開発に留まらず、事業活動の目的を達成するために、如何に有効且つ効果的にコンピュータを利活用するかが本質と考えております。即ち、『コンピュータ化する部分』と『コンピュータ化しない部分』を見極めると共に、全体を上手く融合し、如何に経営／業務に寄与する『仕組み』を作り上げるかが大切なのではないでしょうか。

システム開発 失敗が多いのは何故（３）

システム開発　失敗が多いのは何故（３）

ベンダー側の問題として触れた点を、掘り下げて考えてみたいと思います。

『ユーザ企業の経営や業務に関する知識が不足している』

『ユーザ企業との要件調整が不足している』

『システム化をすることが目的となってしまう』

『ユーザ企業のシステム化の目的や目標が理解されていない』


まずは、ベンダーの業務知識不足ということがあります。

システム開発 失敗が多いのは何故（２）

システム開発　失敗が多いのは何故（２）

システム開発の失敗は、『ユーザ企業側』と『ベンダー側』の双方に問題があるとしましたが、そもそも『システム』とは何なのでしょうか？

私は『システム』とは、

（１）広義の意味として、事業活動全般の構造（経営資源の活用方法）であり、即ち
　　　経営そのものを指すと定義。

（２）狭義の意味として、ずばり『コンピュータシステム』を指すと定義。

しております。

この定義を前提に、システム開発とは単にコンピュータシステムの開発に留まらず、事業活動の目的を達成するために、如何に有効且つ効果的にコンピュータを利活用するかが本質と考えております。

即ち、『コンピュータ化する部分』と『コンピュータ化しない部分』を見極めると共に、全体を上手く融合し、如何に経営／業務に寄与する『仕組み』を作り上げるかが大切なのではないでしょうか。

システム開発 失敗が多いのは何故（１）

システム開発　失敗が多いのは何故（１）

システム導入に関する『失敗』について考えてみたいと思います。
ここで言う『失敗』とは、

●予算（予め決めた金額で）

●納期（予め決めた期限に）

●品質（予め決めた業務範囲を網羅し、安定的に運用できる）

の評価３点セットを守れなかった事を意味しています。

いくら品質の素晴らしいシステムが導入できたとしても、予算が倍に膨れてしまったり、納期が半年も遅れてしまったりでは、明らかに失敗に分類されると思います。

ＰＭの苦悩

ＰＭの苦悩

プロジェクトにおいて、ＰＭに悩みは尽きないものです。
その悩みも多種多様でしょうが、あるプロジェクトにおけるＰＭの悩み話です。
簡潔に言ってしまえば、プロジェクト・メンバーを信頼出来なくなってしまったということです。
ここに至るまでに様々な経緯があるのですが、その主だった理由として、
◇期限を守れない（意識していない？）
◇遅れても言い訳ばかり（自分の非を正当化？）
◇勝手なことをする（本来の目的・役割が解っていない？）
◇適時報告がされない
などなど、メンバーの責任感の欠如を挙げております。

メンバーの言い分としては、
◇無理な計画を押しつける
◇指示があいまい
などなど、ＰＭとしての力量に対する不満を挙げております。