会社の花形部署であるシステム事業部の課長として順調にエリートコースを

歩んでいた。

彼女はプロジェクトマネージャーとして数々の大きなプロジェクトを成功させてきたが、

社内政治の罠にかかり、最悪の状況にあったＳＩ事業部の物流システム開発プロジェクト

のプロマネに任命された。

ＳＩ事業部は恵まれたシステム事業部とは全てが違い、自殺者がでても

体質は改善されず、企業内カウンセラーとして紺野紗枝を迎えたくらいの

対策がとられただけだった。

まさに、「失業か！鬱病か！」の状況の中、失敗の責任だけは負わされるというはめ

に陥った大友は、初めてどうプロジェクトを進めていいかすら分からなくなった。

特に倉庫管理システム（WMS)は大友にとって未経験の業務システムだった。

そんな折、「この会社には悪魔がいる」といった嫌がらせのようなメールまで届く。

大友は初めて味わう無力感と不安、悔しさに、自分の力が全て失われたような感覚

に襲われた。

退職も考えた大友であったが、自分の居場所は自分で見つけると開き直り、

今までのプライドを捨て、サポート要員のアサインを本部長に申し出た。

エリートコースを歩んでいた大友は、人に助けを求めるなど初めてであったし、

社内から中傷を受けるのも初めての経験だった。

大友はこの倉庫管理システム（MWS)プロジェクトの再構築をはじめた。。

なんとか、プロジェクトが回り始めたとき、

プロジェクトメンバーの一人が会社のトイレで首を吊った。

捜査に着手した刑事は「これは自殺ではない」と感じていた。

「プロジェクトのキャッシュフロー」は頭が痛い問題です。

一括請負などでは納入後に一括して代金が支払われますが、長期プロジェクトと

なるとその莫大な手出しのコストが会社のキャッシュフローを圧迫します。

これでスケジュールが遅れでもしたら大変です。プロジェクト途中で経営難に陥る

ＳＩベンダーもあるくらいです。古き良き時代なら受注書をみせれば銀行が融資

してくれることもありました。今は、そうとは限りません。そもそも銀行から借り

るということは、利子を支払うということですので、会社の利益に影響を及ぼしま。

　最低でも、分割検収やフェーズドアプローチなどで工程ごとにキャッシュを受け

取れるようにしておけば手出しが減り、会社のキャッシュフローへの負担を軽減す

ることができます。

　大規模プロジェクトであればあるほどプロジェクトリスクは大きく、リスク回避

の方法を熟考しなければなりません。

　キャッシュフローが悪化する懸念からプロジェクトの要員補充計画に悪影響を与

え、臨機応変の組織編制を阻害する可能性もあります。稟議が通りにくくなるので

す。

　ですので、キャッシュフローに難がある場合は、一括検収ではなく「分割検収」

「フェーズドアプローチ」にするなどして、プロジェクトの完成時だけでなく、

その途中である工程完了時にもユーザーに検収を上げてもらい、ユーザーからキャッ

シュを補給しながら、プロジェクトを進めていけるようにしましょう。

なるべくプロジェクトの途中でキャッシュを補給でき、持ち出しを少なくする方

法を前提に考えてプロジェクト運営方針を立案したほうがいいでしょう。　

この２つはフェーズ（分割）の分け方によっては同じ意味で使われることが

あります。

一つ目の「分割検収」は、基本、システム導入費用の総額は変わらず、

支払うタイミングが工程単位となるやり方です。

以下の例は、総額１億円のシステム導入プロジェクトの検収と代金支払の

タイミングを、０．５（着手金、要件定義）：２．５（設計）：６．０
（プログラム開発）：１（以降の作業工程）という比率で分割し、
各工程完了後に検収、代金を請求するという分割検収の方法です。

例）１０，０００万円の開発であれば、

　５００万円　：　着手金、要件定義
２５００万円　：　設計
６０００万円　：　プログラム開発
１０００万円　：　以降の作業工程

という支払単位になります。

２つ目の「フェーズドアプローチ」とは、

段階的見積方法で、システムの完成までを一気に見積もるのではなく、

要件定義フェーズ、設計フェーズ、プログラム開発フェーズ、

テスト移行フェーズの各フェーズ終了時に次フェーズの再見積りを行います。

このやり方であれば、見積りの精度を上げることもできますし、

フェーズごとに検収を上げてもらうため、分割検収と同じ効果が期待できます。

ただし、フェーズドアプローチはユーザーのシステム導入予算が変動し、

予算が組みにくくなるため、営業段階で難しい状況に陥ることがあります。

競合他社が一括請負で提案してくると、システムの提案内容より予算取りがしやすい

ベンダーが選ばれることになるからです。

日本には「システム化（仕組み化）」という考え方が浸透していないため、

システム化即ちコンピュータシステムの導入となってしまい、

なかなか予算取りの際もシステム化とコンピュータシステムの導入を切り分けること

ができません。

営業としては、売上げが欲しいため、分割検収で話しをつけようとしますが、

プロジェクトマネージャーはフェーズドアプローチをとるよう抵抗すべきでしょう。

そしてこの働きかけの結果、要件定義後か外部設計後の再見積りで落ち着くこと

が多いというのが実感です。

私は、最低でも要件定義後か外部設計後に再見積りで交渉します。

本当は、会社の方針として、フェーズドアプローチをとるよう規定しておくのが

一番いいのですが、なかなか難しいようです。

逆に、ＩＴリテラシーが高いユーザーは、最初にＳＩベンダーと要件定義、

外部設計を共に行うことでシステム化の手法（ノウハウ）を吸収し、

その後、新システムの構想を時間をかけて社内で構築し、製造開発以降は

適当な時期に、適当なＳＩベンダーを探して発注するという方策を実施している

ユーザーもいます。

これができるようになると、新サービス、新業務の計画段階からシステム化の方策も

同時進行で策定でき、今後のバージョンアップや新システム導入時のＲＦＰの精度

を上げることもできます。

これは要件定義、外部設計工程の工数低減につながり、割安でのシステム導入が

可能となります。

【引用文献】
ＩＴプロジェクトマネジメントに活かせる孫子の兵法！
詳しくは[URL]⇒【紀伊国屋書店】孫子の計画法



倉庫管理システム（WMS）導入を題材にした小説！
詳しくは[URL]⇒【紀伊国屋書店】窓のないオフィス


⇒闘戦経と孫子の兵法で学ぶ一目置かれる人のメンタルモデルとは

物流システム導入プロジェクトに挑むプロジェクトマネージャー
が主人公の小説です！少なからず似た経験があるのでは。。

[小説！電子書籍]窓のないオフィス
『鬱病か！失業か！イカれたプロジェクトに挑むプロジェクトマネージャー』

＜以下の電子書店で購入できます！＞
⇒ [BinB store]
⇒ [Fijitsu BooksV]
⇒ [楽天Raboo]
⇒ [セブンネットショッピング]
⇒ [紀伊國屋書店 Kinnoppy]
⇒ [東芝BookPlace]
⇒ [GALAPAGOS STORE]



]]> ITシステム導入よもやま話 https://itohanasibkno.side-story.net/it%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E5%B0%8E%E5%85%A5%E3%82%88%E3%82%82%E3%82%84%E3%81%BE%E8%A9%B1/it%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E5%B0%8E%E5%85%A5%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%83%BC%E3%82%B8%E3%83%A3%E3%83%BC%E3%81%8C%E4%B8%BB%E4%BA%BA%E5%85%AC%E3%81%AE%E9%9B%BB%E5%AD%90%E6%9B%B8%E7%B1%8D%E5%B0%8F%E8%AA%AC%EF%BC%81 Tue, 27 Nov 2012 05:31:37 GMT itohanasibkno.side-story.net://entry/22 いろいろコンサルタントとつく仕事がありますが、
システム導入コンサルタントとは何をするのでしょう。。

私は以下のシステム導入コンサルをしています。

・パッケージシステムの開発支援
・パッケージシステムの導入支援
・顧客システムの開発支援
　業務が決定したのち、システム化するため
　にどのような手順を踏めばよいかのサポート
　を行っています。

いざ、システム導入をする場合、
相手のＳＩベンダーとの打ち合わせの中で、
なにを質問したらよいか、なにを要求したらよいか
すら分からない場合があります。

システム導入に詳しい方がおられる会社では
不要かもしれませんが、
私に依頼がある顧客の悩みというと、
「コンピュータの導入は是非ともしたいが、
　進め方が分からない」
「どの程度までシステム化が必要か」
「どのメーカーのシステムを導入すれば一番得か」
「ベンダー提案では、何でもできると言っているが
　ほんとうにできるのか」
「ベンダー提案の見積は中身も金額も妥当かどうか」
「いろいろな企業のシステム導入失敗例をよく聞くが
　大丈夫だろうか」
「システム導入によって本当にメリットはある
　のだろうか」（費用対効果）
「ＳＩベンダーの言っている言葉が分からない。」
「このドキュメントはどう見たらいいのか？」
「どこに気をつけて質問したらよいか分からない。」
「ＳＩベンダーの言っていることがＩＴ業界的に
　正しいのかわからない」
「形式的でなく、もっと腹を割って話しを聞きたい」
などです。

私の場合、
システム導入にあまり詳しくない顧客と
ＩＴベンダーの橋渡し的な作業を行うことも多い
ですね。
　　
また、システム化する場合に必要な情報の準備のサポート、
などもおこなっています。

要するに、電化製品を買いにいくときに、
電化芸人のように詳しい人に付いてきてもらうような
ものです。
 
電化製品なら高くても数十万円ですみますが、
システム導入は数千万円、数億円の買い物ですからね！

ＰＣサイト：『プロマネも人生も段取り八分』もご覧ください！
プロジェクトマネジメント(PMBOK)について書いたり
しています！孫子の兵法も追加！！しました！！

 

「ＳＩベンダーをなぜ使うのか?」

です。

なぜ、ＳＩベンダーを使うのか。
なぜ、自社に情報システム部があるのに外の会社を
わざわざ使うのか。
自社のＳＥはスキルが低いからか・・。

基本、自社のＳＥはスキルが低いと囁かれることが多いですが、
そうではないですね。
　
理由としは、以下の場合が多いでしょう。

１．ＩＴ技術者自体がいないため
２．プロジェクトという会社組織と違う組織を作る必要があるため
３．自社と違う技術（言語、ＯＳなど）を使用するため
４．業務に特化したシステム開発を行うため
　　　（またはパッケージを導入するため）
５．ＩＴ技術者不足を補うため

全ての理由に、共通するのは、自社に足りないものを補うために
使うということ。

ＳＩベンダー側もシーズ（自分たちの持っている知恵や技術）
で、顧客のニーズを埋めようと考えていますし、
顧客も埋めてもらおうと考えているということです。

注意しなければならないのは、何を埋めて欲しいかを明確に
することです。

それ以上に頼ろうとすると、絶対に歪が生じます。
　
この歪はシステムテストぐらいから表れ始め、運用時に障害
となって表面化します。

ＳＩ業者は開発が終れば去るということは、頭の隅において
置かなければなりません。

頼り切ってはだめなのです。

 ＰＣサイト：
『プロマネも人生も段取り八分』もご覧ください！
プロジェクトマネジメント(PMBOK)について書いたり
しています！
⇒ http://www.fieldsmobile.net/
 

「システム導入前のＥＣＲＳ！」

です。

さて、あなたの会社で業務システムを導入する
こととなりました。

ここで一番大切なことは、自分の会社の業務を
ちゃんと理解できているかということ。

これ、なかなか難しい。。。

分かってるつもりでも。。。

実際、ＳＩ業者と打ち合わせに入ると、
漏れが生じたりしてしまいます。

日本のシステム導入の場合、
システム化とＩＴコンピュータ導入がイコール
となってしまっているため、

システム化のところでつまずき、
要件定義が混迷します。

システム導入をする前に、まず、自社の
業務を整理、できれば、非効率な業務は改善
しておきます。

すると、ＩＴシステム導入がシンプルになり、
システム導入に成功する可能性が高くなります。

余計なものを作らなくて済むし、そもそも話し合う
ことすら必要ありません。

数日、深夜まで検討してようやく固まった要件が、
他の業務の打ち合わせをしている最中、余計な作業
であることに気づき、その要件自体が不要になる
ようなことを避けることができます。

これ、結構、要件定義の段階では起こります。

そこで、まず、「業務プロセスの改善」を
試みましょう。

方法としては、業務プロセスを『可視化』して、
どう短縮できるかを分析していきます。
　
IE(Industrial Engineering=インダストリアル・エンジニアリング）
という作業改善の考え方で

「ＥＣＲＳ」
（Ｅ：Eliminate=なくせないか）
（Ｃ：Combine=同時にできないか）
（Ｒ：Re-Order=順番をかえられないか）
（Ｓ：Simplify=単純化できないか）

この言葉を、
机の前に貼っておられる責任者の方は結構いらっしゃいます。

また、システムを導入するＳＩ企業側は、
顧客の業務がどのレベルで整理されているかを
早めに察知することが重要です。

要件定義に業務コンサルタントの分野や業務の整理に
とまどる場合、見積りにはかなりのリスクを乗せておか
なければなりませんし、
乗せることが出来ない場合も、見積り会議の議題に
しておかなければなりません。

「PMが倒れた！君やって」

です。

ホラー映画より怖いと思います！

どうでしょうか？

突然、ある悪名が轟いている、プロジェクトの
ＰＭが長期入院することとなりました。

病名は・・・。

部長に呼ばれたあなたは、

そのプロジェクトのＰＭをやるよう指示された

とします。

どうしましょう。。。

もちろん断りますよね。

最初は。。

でも部長の強い一押しがあったとします。

はあ～、ある年齢になるとありうる話しです。
（嫌ですね～）

まだ、上司が頼りがいのある方であれば、

まだOKですが、

でも、もしそうなら、そもそもPMがこうなった
のか？

まず最初の難関は
　１．現状がちゃんと把握できるか
　２．前PMのイメージを消し去ることができるか
　　　（顧客、メンバー）
　３．もう一度、メンバーのテンションを上げれるか

かと思います。

できれば、PMを受諾する前にできるだけ情報を集めて、

「条件をつける」ことを考えましょう。

ある意味、プロジェクトの再構築をするのは、
この時しかありません。

これ！重要ですよ！

プロジェクトはそもそもプロマネ一人でどうこう
できるものではありません！

上司が気にしてくれるのも、最悪この、

プロマネ交代の時しかない！！

場合が多いです。

（頼むときだけは、会話の時間がとれたりします！）

最低でも、

「現状把握後に、再検討しますという宣言は
　しておくべきです。」

ズルズルと引き受けることだけは避けましょう！

>>プロマネも人生も段取り八分サイトもご覧ください！