プロが語るIT化の成功条件

当分更新を休みます

おおさこ — 2005-11-21T10:42:34+09:00

当分の間、こちらのブログの更新をお休みします。

Brainproの方のブログ「実践！戦略的IT経営」の方で更新を続けていますので、引き続き、「実践！戦略的IT経営」でお読みください。

実行可能な現実的なスケジュールを作ろう

おおさこ — 2005-10-31T06:00:00+09:00

いよいよ、スケジュールを作成するステップに来ました。この辺になると皆さんも日ごろから行っているので、詳細に説明する必要はないと思います。

スケジュールを作成するには、まず、今から作成するスケジュールの前提条件を明確にします。

既に、何度も前提条件を明確にすることの重要性を書いてきました。

まず大まかなスケジュールを作成し、その後、資源見積、リスク分析などを行なった後で、それをスケジュール反映し、詳細化することになります。

計画作成中に、前提条件が変わることがありますので、初期段階の前提条件を明確にする必要があります。

ここで重要なことは、

実行可能な現実的なスケジュールを作成する

ということです。

そのためには、顧客と成果物について合意を得ていなければなりません。成果物の合意がなければ、スケジュールは、絵に描いた餅です。

あるSIベンダーは、成果物を明確にしないままに、要件定義後、設計フェーズに進みました。ベンダーから提示されたスケジュールは、2ヶ月で設計フェーズを終わらせると言う内容でした。

しかし、顧客から見れば、フェーズが進むに従い、進捗が計画通りなのか、遅れているのか判断が付きません。

顧客のフラストレーションが溜まるばかりで、プロジェクトが良い方向に進むわけがありません。

結局、このプロジェクトでは、成果物を明確に定義せずに進んでしまい、顧客満足とは、程遠い結果となってしまいました。

また、ステークホルダーから承認を得て、投入する資源の確約を貰っておく必要もあります。

よくある例が、予定していたSEを投入できなくなり、スキル不足のSEを投入せざるを得なくなったというようなことが起こります。

このような場合、投入するSEのスキルによっていろいろな方法を考えなければなりません。スケジュールを伸ばす、SEの人数を増やすなど取り得る方法を考慮してスケジュール変更をすることになります。

当然、コストにも跳ね返ります。

実行段階で変更せざるを得なくなるので、変更のために前提条件を明確にしておく必要があるのです。

私がユーザ企業に在職していた時、あるプロジェクトで、新人ばかりを集めた体制を組んだことがあります。SIベンダーのパートナーと合意をし、リーダーとしてシニアSE1名、ジュニアSE1名、新卒SE3名と言う体制です。

このプロジェクトは、そう難しい技術を使うわけでもなく、開発するものも、大半がUIで、力仕事でこなすというものでした。

従って、計画段階から、必要スキルをはかり、新人でできる内容の計画を最初から作成しました。

また、意思決定を伴う事項については、リーダーと私とで即決していく役割分担も明確にしました。

ピーク時には、多少の残業をしましたが、殆どの期間残業もなく、スケジュールどおりにカットオーバーを迎えることができました。

スケジュールを作成する前提となるのは、
・成果物の合意
・投入人的資源
・必要スキル
・リスク分析
・コスト
等ですから、これらがバランスしたものを作成します。そうしないと、プロジェクトが死の行進になってしまいます。

Google AdSenseの秘密

おおさこ — 2005-10-25T12:25:09+09:00

これは、すごいです。ホームページを持っている人は、必見のレポートです。もともとは、英語のレポートですが、私の知り合いが翻訳し、販売を開始しました。

詳細を知りたい方は、Google AdSenseの秘密をクリック！

何がすごいかって？

著者は、1ヶ月にGoogle AdSenseだけで、25,000ドル（120円換算で、3百万円）を稼いでいるのです。3百万円ですよ！

このレポートに書いてあることを実践するだけで、Google AdSenseのクリック率が一挙に跳ね上がります。私も、販売開始を知るや否や即購入し、ブログを変更しました。

変更すると、1日後には、クリック率が数%上昇します。たった数時間の作業だけで、1日の収入が倍になりました。身を持って体験しました。

また、ブログで、クリックされやすいキーワードで記事をどんどん書いていくとさらに効果は抜群です。

ホームページへのアクセス数が増えていけば、笑が止まらなくなると思います。
Google AdSenseを活用してお小遣いを稼ぎたい方は、即購入！著者のような稼ぎになれば、もうお小遣い程度ではすまない。

私も早く、そうなりたいものです。

活用しよう！ネットワーク図

おおさこ — 2005-10-24T06:00:00+09:00

WBSを作成した所まで来ました。WBSのワークパッケージをさらに詳細化し必要なアクティビティを拾い出します。

これを並べてネットワーク図を作成し、アクティビティ間の依存関係や、クリティカルパスを分析する、というのがPMBOKの手順です。

が、

私自身、あまりと言うか、殆ど、ネットワーク図を活用したことはありません。
(汗)

私だけかもしれませんが....殆どのITプロジェクトで、ネットワーク図を描いていないんじゃないでしょうか。

なぜ、活用しないのでしょうか。

あまりにも多くのITプロジェクトが、マスタスケジュールレベルの粗さだけでプロジェクトを進めているからではないでしょうか。

例えば、業務要件定義と言うワークパッケージがあったとして、これを構成するアクティビティをあまり考えていない、或いは、メンバー任せにしていると感じています。私自身もそうでした。

しかし、業務要件定義をするには、
・組織構造決定
・業務プロセス数決定
・各業務の詳細化
等があると思います。

当然これらをアクティビティとして定義すれば、業務プロセス間に依存関係がありますから、アクティビティ間の依存関係も自ずと明確になると思います。

ネットワーク図を描くには、
1. WBSで作業を洗い出す
2. 作業の依存関係を決める
3. マイルストーンを特定する
4. 作業とマイルストーンをネットワーク図に表す
5. ネットワーク図を論理的に見直す
というステップを取ります。

唯一、私がネットワーク図を書いた記憶があるのが、R/3の官公庁向けテンプレート開発プロジェクトが大幅にスケジュール遅れを起こし、火を噴いていたのを消火作業に入った時でした。

入った時点で予定より3ヶ月遅れでした。ここまで放っておくなよな....と思いながら、WBSを見てアクティビティを洗い出しました。

すると、案の定、アクティビティの依存関係を無視したスケジュールで、しかも、同一メンバーが同一時期に複数の業務仕様を作るというような超人的なスケジュールになっていました。

これをネットワーク図を使用して修正し、マルチタスクにならないよにスケジュールを組みなおしたのは言うまでもありません。

結局このプロジェクトは、2ヶ月遅れでテンプレート作成を完了することができました。

このようなことが起こらないよう、これからネットワーク図を使用してスケジュールを立てるようにしましょう。MS Projectなどのソフトウェアを使用すると簡単にできますから、それから精査すればよいと思います。

Hot Topics Flashcards for Passing the Pmp Exam

おおさこ — 2005-10-17T06:05:00+09:00

Hot Topics Flashcards for Passing the Pmp Exam: Hot Topics Flashcards 5th Edtion
Rita Mulcahy
Rmc Pubns Inc 2005/09/30
売上順位：271,366
定価：￥ 3,960
アマゾン価格：￥ 3,366

アマゾンで詳細を見る

PMBOK第3版対応のPMP試験対策のモバイル版！とかく忙しい我々には、大変重宝するものです。約300以上の重要で難しい用語の解説がカード形式にまとめられています。

本書は、カード形式版と、オーディオCD版があります。どちらを使用しても、通勤電車の中、オフィスからの移動中、あるいは車の中で聞きながら、学習することができます。

オーディオCD版なら、英語のヒアリングとPMPの両方を勉強できて、一挙両得！
二兎追う者は一兎も得ず、ということわざもありますが...（笑)

私もこれを通勤電車の中で毎日見ていました。

WBSはプロジェクトの要

おおさこ — 2005-10-17T06:00:00+09:00

スコープを定義したら、いよいよWBS作成です。

PMBOKで言うスコープ計画とは、作業を開始する前に、「どの様にやるか｣ということに重点を置いて考えることです。従って、アウトプットは、プロジェクトスコープマネジメント計画書となります。

また、スコープ定義は、何がプロジェクトに「含まれてい｣て、何が「含まれていない｣かに重点を置いて考えることです。アウトプットは、プロジェクトスコープ記述書です。

でも、本当に、WBSって必要？

大工の棟梁は、家を建てるときに、いちいちWBSを作成している？してないよねぇ。というような意見が聞こえてきます。

WBSとは、プロジェクト作業を関連分野ごとの階層構造で示すものです。ということは、プロジェクトを管理しやすい単位に分解することとなります。

プロジェクト全体から、
サブプロジェクト（複雑なプロジェクトの場合)へ、
マイルストンへ、
主要な活動（サマリタスク)へ、
ワークパッケージへ
と分解していきます。

具体的な階層構造の作り方などは、以前に紹介した

実務で役立つWBS入門

という書籍で詳細に解説されています。また、WBSの例も豊富に載っていますので、読まれていない方は、ゲットしてください。

ワークパッケージまで分解できたら、そこから、今後の計画作成に波及していきます。

いわば、WBSはプロジェクト成功への土台である

ということができます。

ワークパッケージをさらに分解して、アクティビティ定義へ、
そこから、ネットワークやスケジュール作成へ、
要員配置も、
さらに、予算の作成へも

と繋がっていきます。

すなわち、WBSを作成するとは、

・プロジェクトの主要部分を明確にし、プロジェクトで何をするべきかを明らかにする
・プロジェクト作業の実施順序を論理的に決定する
・チームメンバーが担当すべきワークパッケージを明らかにする
・各ワークパッケージに必要な資源を明らかにし、予算作成の基礎とする
・各人が行なうべき作業とプロジェクト全体での位置づけについてチームメンバーに周知する
・関連するワークパッケージを、マイルストンを活用して結びつける

ということになります。

第30号メルマガで書いたRFPでは成果物WBSを要求しようを、実際に行なった時の話です。

ベンダーからの提案書に、詳細なWBSの記述がありました。

でも、分析すると、スケジュールと連動していないもの、必要要員数と連動していないものなどが見られました。

極めつけは、費用と全く連動していないものまでありました。費用見積は、開発一式xxxx万円としか、かかれてありません。（汗)

おいおい、成果物WBSを要求した狙いを考えて提案してくれよな！

こう叫びたくなりました。

ベンダーの策略かもしれませんが、それにしても...情けない。どのように見積を行なっているのか疑問です。

この業界、人月単価しか持っていないのでこうなるのかなと考え込んでしまいました。シビアに考えるなら、人月単価ではなく、人日単価を使うべきなのですが。

ちなみに、海外から、プロジェクトに参加の打診があったときは、必ず、man day rateはいくらかとたずねられます。この問題は、後日、取り上げたいと思っています。

PMP Exam Prep 第5版

おおさこ — 2005-10-10T06:05:00+09:00

PMP Exam Prep Rita's Course in a Book for Passing the PMP Exam: PMP Exam Prep
Rita Mulcahy
Rmc Pubns Inc 2005/09/30
売上順位：36,954
定価：￥ 10,366

アマゾンで詳細を見る

ついに出ました！世界で最も売れているPMP受験対策本のPMBOK第3版対応版です。私もPMPを受験した時にバイブルのように重宝しました。

私が勉強した第4版の内容を大幅に書き換えての登場です。

PMBOK解説だけではなく、ゲーム、演習、支援で陥りやすい間違いなどあらゆる角度からプロジェクトマネジメントを学習することができます。さらに、PMP試験問題が約400問程度網羅されています。

私は、これを3回学習しなおしました。最後は、試験問題の最初を読むとその答えが分かるほど。

本書は、英語ですが、PMPを受験する方には、最高の試験対策本です。

受験される方は、今すぐゲット！

スコープは、プロジェクトの基盤

おおさこ — 2005-10-10T06:00:00+09:00

プロジェクトを無事に立ち上げ、計画を策定するフェーズに入りました。

皆さんはプロジェクトで、何回程度スコープを変更していますか？

顧客の要求を満たすため、何度、機能を追加していますか？

スコープをどの様に定義するかをまず最初に計画しなければなりません。

PMBOK第3版では、スコープ計画、スコープ定義、WBS作成と3つのプロセスが計画プロセス群に定義されています。このうち、WBS作成は、第3版から新たに追加されたプロセスです。

でも、スコープって一体何でしょうか。分かりやすそうで、なかなか定義できない言葉です。日本語に直せば、文字通り「範囲｣のことですが、何の範囲を定義するのでしょうか。

スコープといっても2種類あります。

プロダクトスコープ（成果物スコープ)と
プロジェクトスコープ
です。

プロダクトスコープとは、

「プロジェクトの成果物に関連する要求事項｣を言い換えたものです。

プロダクトスコープは、前フェーズ、或いは前プロジェクトの結果からもたらされるかもしれませんし、新たにプロジェクトで定義しなければならないものです。

では、プロジェクトスコープとは？

プロジェクトの成果物を作成するために必要な作業を意味します。
会議、報告書、分析など、プロジェクトマネジメントに関する作業を含みます。

ちなみに、PMBOKで出てくるスコープベースラインとは、

「プロジェクトが顧客の要求を満たしているか｣

というプロジェクトの成功を評価するための指標となるものであり、
プロジェクトスコープ記述書、WBS、WBS辞書などが該当します。

言葉の定義はこれくらいにしておいて、これから始まるプロジェクトの枠組みを決定するプロセスが、スコープマネジメントだと覚えておいてください。

これが、変更されると、スケジュール、コスト、品質に大きな影響を与えることになります。

顧客側の皆さんは、何でもかんでもプロジェクトで実現して欲しいと要求を出してきますが、ここがぶれるとプロジェクトもぶれることになります。中には、スコープを変更しても、軽微な影響しかない場合もありますが。

当然、プロジェクト側と顧客側で、スコープの合意を得ておく必要がるのは言うまでもありません。

では、プロジェクト実行中にスコープを変更することはダメなのか？

そうではありません。

SAPプロジェクトの場合、コンサルタントの方からスコープ変更を申し出る場合があります。私もよく、スコープ変更を言い出しました。（笑)

顧客の要求をよく聞くと、実現しようとする機能を実装するには、標準機能だけではできない場合があります。

しかし、詳細に聞いていくと、スコープに入っていないモジュールを追加することで、標準機能を組み合わせるて実現できる場合があります。

「そういうことを実現したいなら、xxxモジュールを追加すれば、アドオンを開発することなしに、実現できますよ。ただし、新たにコンサルタントを入れる必要があるので、コストは膨らみますが。でもアドオンを開発するよりはましでしょ。」

と定番のように言っていました。

Project Management Professional 試験対策講座 1 基礎編

おおさこ — 2005-10-03T06:05:00+09:00

Project Management Professional 試験対策講座 1 基礎編 PMBOK (R) 第3版概要 CD-ROM(6枚組)
青柳次男
翔泳社 2005/10/07
定価：￥ 48,300

アマゾンで詳細を見る

待望のPMBOK第3版に対応した試験対策講１が出ました！

PMP受験に私も購入しました。専任の講師による映像と、PMBOK第3版に準拠のテキストで、基礎から体系的に学ぶことのできる学習教材です。PMBOK2000版から2倍のページ数になったPMBOK第3版の概要をPCで手軽に学習することがきます。

受験を申請するには、公式なプロジェクトマネジメントの研修を35時間受講していることが条件となります。本製品は、ソフトを実習いただいた方に14時間分の受講証明書を発行します。

また、特典として、メールでの質問サポート（5回まで）と模擬テストの実施と解説が付いています。

複数案がある時は、必ずフィージビリティスタディを行なおう

おおさこ — 2005-10-03T06:00:00+09:00

プロジェクトを開始する前の立ち上げフェーズで、
ステークホルダーを特定し、
プロジェクトの目標を合意して、
核となるメンバーを選定し、
プロジェクトの前提条件、制約条件、リスクを分析しました。

PMBOKでは、これらがインプットとなり、プロジェクト憲章の作成と、スコープ記述書暫定版の作成が、立ち上げフェーズのプロセスであると定義されています。

何度も言いますが、プロジェクトは最初が肝心です。ここで誤った定義をすると、プロジェクトは迷走します。そういうプロジェクトを何度も見てきました。

そういう意味で、プロジェクトの立ち上げフェーズは、プロジェクトの定義フェーズであると言い換えることができます。

もし、この時期に、取り得るソリューションが複数あって、そのどちらを取ればよいかわからなかったら、どうしますか？

資源調達にも関係しますが、提案されたソリューションが複数あって、優劣付け難い場合などは、どのようにして最適案を決定しますか？

その時は、フィージビリティスタディを行なうことになります。大きいプロジェクトだと、フィージビリティスタディそのものを別プロジェクトとして実施する場合もあります。

皆さんも良くやると思いますが、複数の案のメリット、ディメリットを列挙して、比較検討することで、最適案を採用する。簡単なフィージビリティスタディは、このようなものです。

開発期間中にある課題を解消するための方法を検討する時、よく行ないますよね。

フィージビリティスタディの結果が、将来を左右することになりますから、慎重に行なわなければなりません。

ある医薬会社で行なわれていたBI導入のプロジェクトで、フロントとしてレポートを見せるためのOLAPを何にするかを決めなければならない局面になりました。

開発ベンダーがフィージビリティスタディを実施し、その報告書を顧客に提出しました。その報告書を顧客と一緒に評価したわけですが、非常に良くまとめられたものでした。

評価ポイントを決め、代替案ごとにそのメリット、ディメリットを列挙し、その詳細内容の分析手法と分析結果を比較できるような形で、50ページにもおよぶ報告書でした。その中には、当然、代替案ごとの制約条件、リスクも含まれており、顧客側としては、決定をしやすい内容となっていました。

方や、ある製造業のBI導入プロジェクトで、同じ局面で、ベンダーから提出されたフィージビリティスタディ報告書は、惨憺たる内容でした。

評価ポイントは決めていましたが、メリット、ディメリットも列挙されず、評価ポイントごとに○×△を付けているだけのわずか1ページの内容でした。

おまけに、評価ポイントに、機能、汎用性、開発リスク、コストと言うような言葉で書いてあり、その内容が全く分からないものでした。

フィージビリティスタディを行なうには、その評価ポイントの定義と、分析方法を決めなければなりません。そして代替案の相違点を分かりやすく報告しなければ、意思決定者が決定することができないのは、言うまでもありません。

おいおい、お前ら本当に分析したのか？とプロジェクトスポンサーが怒り出し、この報告書は、没になってしまいました。

フィージビリティスタディのやり方とその報告書の書き方を実践！戦略的IT経営で公開しています。

興味のある方は、是非ご覧ください。