頓挫とは？/ ディック
[ 405] 突然プロジェクトを頓挫させてしまうものは？:コラム（終了） - CNET Japan
[引用サイト] http://japan.cnet.com/column/itm/story/0,2000055912,20054246,00.htm
|
前回の第一弾は「プロジェクト管理上最悪のミスは何なのか?」についてで、主にスポンサーとのコンセンサスを取り続けることの重要性を述べたものであったが、今回はそれを受けての第二弾となっている。 ここでは、スコープの定義の重要性と、スコープ変更についての注意点が述べられているが、規模の小さな開発においては、「スコープ」を「仕様」と読み替えてもよいだろう。 プロジェクトの途中でスコープの変更があるのは誤りではない。完璧な要件定義はありえないと考えておくべき。変更せずに、そのまま役に立たない成果物ができても、誰の得にもならない。途中で変更があっても大丈夫なように、あらかじめスポンサーも交えて明確に変更の手順を定めておくべきである。 ただし、どのように変更があってもよいわけでは勿論なく、その点について次のような注意も述べられている。 このように、今回の記事の趣旨はスコープ変更、あるいは仕様変更を容認すべしという部分が目新しい。通常なら、こうした変更は、悪に近いものと受け取られていることが多い。もしかすると、これは米国と日本での考え方の違いもあるのかもしれない。 ただし、少なくとも私が関わったプロジェクトでは、スコープ変更を容認するようなやり方は、発注側に有利に働きがちで、それがたとえば打ち合わせにば かり時間を取られたり、あるいは外注先に時間およびコスト面での負担を強いるといった好ましくない事態につながることが少なくなかった。 また実際に、開発に入ってから発注側の要求が二転三転し、大幅な仕様変更が必要となる場合もある。もちろん、役に立つ成果物を作ることが目的であるのは言うまでもない。しかし、それで「完成が半年遅れても、予算は決まっているからコストも変わらない」と言われたら、「仕様変更には応じたくない」と感じるのが普通だろう。 ポイントはここである。つまり、「仕様変更はあり得るもの」との前提で、「変更に必要な手順を決めておき、影響されるコストや納期についても、事前に解決可能としておく」ことになっていれば、上記のような被害を最小限に止められるのだ。 最後に、あらためて繰り返すが、はじめに十分な調査をした上できちんと要件定義を行い、それでスコープ変更がないようにしておけば、さまざまな二度手間によるコストや時間もセーブでき、みんなハッピーになれることは間違いない。 プロジェクトの定義を行い計画を立てるのは、プロジェクトマネジメントを成功に導くための第一歩に過ぎない。計画立案の次は「計画通りにプロジェク トを進める」番だ。プロジェクトマネジャーたるもの、決められた時間および予算内で約束した仕事を確実に完了させなくてはならない。しかし、いったんプ ロジェクトが動き出すと、クライアントが当初に取り決めた以上の、あるいは取り決めとは異なる作業をするよう求めてくることがよくある。この避けようの ない現実に備えることも「計画通りにプロジェクトを進める」プロセスの一部だ。プロジェクトマネージャーは、こうしたクライアントの要望にあわせてスコー プ（仕事の範囲）を変更しなければならない。スコープ変更への備えがなければ、当初に取り決めた以上の作業を、元の予算枠のなかで完了させようと、悪戦 プロジェクトのスコープ（仕事の範囲）を定義することは、プロジェクトの定義という準備作業において最も重要な部分だ。このプロジェクトの成果物は何 か、また、プロジェクトでは何をし、何をしないかの境界線をはっきりと知らなければ、そのプロジェクトが成功する見込みはない。スコープ管理はプロジェ クト管理のなかで最も大切な部分といえよう。そして、スコープの「定義」ができなければ、スコープを「管理」することなどできるはずがない。 スコープを「定義」する目的は、これから取り掛かろうとするプロジェクトについて、その論理的な境界線を明確に定め、それについての合意を得ること だ。そして、プロジェクトのカバーする範囲内にある事柄は何か、またこの境界から外れるのは何かを定義する。これには、スコープステートメント（スコー プ定義書）という文書が使われる。この文書にプロジェクトのスコープに関してできるだけ多くの点を盛り込むほど、そのプロジェクトはうまく進むといって プロジェクトの範囲に含まれる成果物と含まれない成果物には、それぞれどのようなものがあるか（例：ビジネス用件定義書、現状評価報告書など） 主要な作業工程のなかで、プロジェクトの範囲に含まれるものと含まれないものは、それぞれどの部分か（例：分析、設計、テスト） プロジェクトの範囲に含まれるデータとそうでないデータには、それぞれどのようなものがあるか（例：財務データ、売上データ、従業員に関するデータ） データソース（データベース）のうち、プロジェクトの範囲に含まれるものと含まれないものは、それぞれどのようなものか（例：請求データ、一般的な帳簿データ、給与データ） プロジェクトの範囲に含まれる組織と含まれない組織は、それぞれ何か（例：人事部門、製造部門、ベンダー部門） 主要な機能のうち、プロジェクトに含まれるものと含まれないものとは、それぞれなにか（例：意思決定支援機能、データ入力機能、管理レポート機能） プロジェクトマネージャーおよびチームのメンバーは、「途中でスコープを変更するのは何ら間違ったことではない」という点をよく理解しておくこと。誰かがスコープ変更を言い出したとしても、それを邪悪な提案だと受け止めなくてもいい。実際のところ、途中で変更を加えたほうがよいことも多い。なぜなら、多くのクライアントは、最終的に納品される成果物に求めるすべての要件や機能を、あらかじめ定義することができないからだ。また、きちんと要件や機能を定義できたとしても、はじめにそれを求めたビジネスが時とともに変化するので、プロジェクトに求められる要件もそれに合わせて変わるのが当然だからだ。 このような変更を受け付けなければ、納品物は当初想定されていたものより価値の低いものになりかねない。あるいは、まったく使い物にならないものとなってしまうこともある。これを避けるために、プロジェクトが進行中であっても、必要に応じてクライアントがスコープを変更をできるようにしておこう。だが、この際にプロジェクトマネージャー側がスコープ変更を管理できる態勢にないと問題が起きる。だから、どのプロジェクトでも効率的にスコープを変更するためのプロセス（手順）を取り決めておこう。このスコープ変更プロセスには、変更箇所の特定、変更のビジネス的価値の算定、変更がプロジェクトに与える影響の算定、そしてその結論をプロジェクトのスポンサー（予算の決裁権を持っている人）に評価してもらう、といった手順を含めるべきだ。こうすれば、スポンサーはスコープ変更を行うべきかどうかを判断することができる。変更を行うときには、それがプロジェクトに与える影響をスポンサーにも理解してもらい、必要な追加の予算と時間を割り当てもらおう。 大きなスコープ変更であれば誰でも気づくが、小さなスコープ変更は気づきにくい。小さな変更だと、あまり深く考えず、ちょっとした追加作業をすれば済むと考えがちである。けれど、そうした細かな変更が積み重なると、結果として大量の追加作業が発生する。そして、予算を超過し、納期が守れない羽目に陥る。 プロジェクトマネジャーはエンドユーザー、利害関係者、クライアント側のマネジャーなどから、数多くのスコープ変更要求を受けることがある。その人たちがみなクライアント企業の人間だからといって、その要求を受け入れなければならないと考えるの間違いだ。エンドユーザーはスコープの変更を言い出すけれど、その変更を承認する権限を持ってはいない。クライアント側のマネジャーでさえ、こうした変更を承認する権限を持っていないことがある。スコープ変更を承認できるのは、プロジェクトのスポンサーだけだ（ただしスポンサーが、別の人間に権限委譲していると場合もある）。クライアントの誰かが言い出した変更要求が、すでに承認を得ているものと思いこんで作業を進め、後になって実は肝心のスポンサーがその変更に同意していなかったとわかり、それでトラブルになることがよくある。 プロジェクトチームのメンバーはクライアントと接する機会が多いので、スコープ変更の要求を聞く機会が多くなる。そのため、プロジェクトチームの全員がスコープ変更管理の大切さについて理解しておかなくてはならない。メンバー全員がスコープ変更に敏感であるべきだ。そして、スコープ変更に気づいたときは、プロジェクトマネジャーに報告する義務がある。プロジェクトマネージャーに報告をせず、メンバーが個々に追加の作業を引き受けてしまうと、彼らの担当分の完了が遅れ、プロジェクト全体が危険にさらされることになる。 もし、あなたが関わっているプロジェクトが予算オーバーし、スケジュールを超過しているようなら、その原因を見つけ出してみよう。単に当初に合意した以上の作業をしているのが原因という場合がほとんどだと思う。そうならないために、スコープ変更プロセスを取り決めておこう。これを定めるベストなタイミングは、実際にプロジェクトが動き出す前だ。なので、プロジェクト開始前に、スコープ変更プロセスについても決めてしまおう。だが、プロジェクト開始前にスコープ変更プロセスを取り決めていなかったという場合には、今からでも遅くない、すぐに「待った」をかけ、スコープ変更要求の必要な箇所を特定し、承認を得るためのプロセス（スコープ変更プロセス）について、クライアントと話し合おう。また、そこで決まったスコープ変更プロセスを、プロジェクトメンバー全員に周知することも大切だ。 こうした努力にも良い面があるとすれば、それはプロジェクトが危機に陥っているため、チームメンバーおよびクライアントが、スコープをきちんと管理しておかない場合に生じる悪影響を、すでに身をもって知っている点だ。彼らもスコープ変更管理の目的をよりよく理解し、その後はもっときちんとプロセスを守るようになってくれるはずだ。 トラックバック一覧からリンクされているウェブページはこの記事にリンクしている第三者が作成したものです。内容や安全性について当社では一切保証できませんのでご注意下さい。 ※サービス名をクリックするとこのページをブックマークできます。また、人数をクリックするとブックマークしている人やコメントを一覧できます。なお、サービスによってはログインが必要な場合があります。 モバイルの世界で近年盛り上がりを見せているのが、広告を主体とした一般サイトだ。エンターモーションはそうした一般サイトのビジネスを支えるソリューションを提供するとともに、起業家の育成にも力を入れている。 ソフトウェアの終焉を予測し、SaaS型サービスをいち早く成功させたセールスフォースのCEOに、マイクロソフト対する見解やサービスとしてのプラットフォームの今後について聞いた。 「ひろゆき」こと西村博之氏へのインタビュー後編。ニコニコ動画の誕生秘話や今後の展開について聞くうちに、話は日本が目指すべき方向へと広がった。 昨年からポーカー熱が高まっている。専門誌が次々に創刊、サロンもできている。ブームの背景には簡単にアクセスできるオンラインポーカーサイトの影響が関係あるようだ。 PCサイトでできることも、モバイルサイトではできない場合がある。また、その使われ方も大きく異なる。モバイルサイトならではの特徴を、技術面、利用面から押さえておこう。 パイオニアは主力商品であるプラズマディスプレイパネルの生産から撤退することを発表した。市場関係者の評価は前向きで、中期的には株価も上昇軌道に乗ることが期待できそうだ。 消費者の趣味嗜好は多角化しており、時代はプロダクトアウトからマーケットインの時代へと変化していると言われています。そんな中で「的確な分析」はさらに重要度を増しています。今回は分析手法の1つとしてアンケートリサーチについて述べていきたいと思います。 インスタントメッセンジャーの認知や利用状況などを調査したところ、認知度、利用意向ともに7割を超えるという結果が出た。しかし一方では、携帯電話メールのほうが便利であるという回答も7割を超えるという結果となった。 シニア層のコミュニティーサイト利用について調査したところ、ブログやQ&Aコミュニティなどシンプルな機能のサービスに人気が集まった。しかし、コミュニティーサイトの利用は全体の約3割に留まっており、若年層の半分以下という状況であることが分かった。 スイスで開催された世界経済フォーラムで、B・ゲイツ氏は「創造的資本主義」を訴えるスピーチを行った。裕福な国々の企業は発展途上国を支援すべきだというものだが、それは世界にとって本当にプラスになるのだろうか？ 米マイクロソフトが、再び米ヤフーに買収を持ちかけている。ヤフーの主事業領域は、マイクロソフトのOSやアプリケーションなどといった主事業領域ではないにもかかわらず、巨額の買収額を提示している。それはなぜなのか。 シャープが今春にも中国市場に携帯電話を投入すると、日本のメディアが報じた。上海や北京、深センなど高所得地域においては、中国でも利用できるように改造したソフトバンクモバイルの携帯電話が販売されていて、特にシャープ製の電話が人気なのである。 インテリジェント ウェイブ、証券市場向け製品強化に向け29West社通信ミドルウェア製品の代理店契約に合意 「画質」でも「記録メディア」でも、さらには「保存方法」でも選べる今シーズンのビデオカメラ。その機能と 機能も画質もデザインも、今年のビデオカメラは例年にないくらいの充実ラインアップを誇っている。SD画質か |
[ 406] ITmedia Biz.ID：プロジェクトが“簡単に頓挫する”3つの要素
[引用サイト] http://www.itmedia.co.jp/bizid/articles/0702/14/news020.html
|
そもそもなぜプロジェクトは失敗するのか――。前回、まずは1人でプロジェクトマネジメントをしてみようという話を書きましたが、プロジェクトを成功させるためのテクニックに入る前に、“失敗”を考えてみたいと思います。 前回も書いたようにプロジェクトマネジメントというと、何だか小難しい印象を受けますが、基本的には複数のメンバーで実行するプロジェクトといえど、個人のタスクリスト管理の延長にあります。 まずは、プロジェクトが失敗する要素を押さえることで、成功のためのポイントを見つめなおしてみましょう。プロジェクトが失敗する要素――というと、いかにもたくさんありそうに思えるかもしれませんが、実はプロジェクトを失敗させる要素は大きく分けると3つしかないのです。 プロジェクトを失敗させる最も簡単な方法は、最初に無茶な計画を立てることです。多くの人が「そんなこと分かっているよ」と思うかもしれませんが、実際に失敗するプロジェクトのほとんどが、最初の計画の失敗から始まります。 「顧客に値切られたために、当初の予定よりも人員を少なくせざるを得なかった」「盛り込む機能が決まっているのに、決算の都合でリリースを1カ月前倒しにせざるを得なくなった」などです。この手の「だから最初から無理だと言ったのに」という計画で実施されているプロジェクトは残念ながらなくなりません。 計画全体から1割程度のぶれであれば、根性論や休日出勤でカバーできる面もあるでしょうが、最初の計画が明らかに無茶な計画である場合、それを成功させるのは至難のワザ。締め切り間際で奇跡がおきて、全てが上手くいくなんて都合の良い話は映画やマンガの中だけなのです。 最初からプロジェクトの計画が無茶なのであれば、プロジェクトを成功させることよりも、まずは失敗をいかに小さくするかに集中したほうが良いというケースもあるでしょう。 もし、計画がある程度妥当なものであるとして、そのプロジェクトを計画通りにメンバーがこなしてくれれば、プロジェクトは成功するはずです。 ただ、話はそんなに簡単ではありません。まず重要なのは、そのプロジェクトを実際に実行するメンバーです。メンバーといっても、メンバーの能力の話ではありません。メンバーの能力が足りないのであれば、事前にそれを見込んで計画を立てる必要があるという話ですから、それはどちらかという計画の話になるわけです。 個々の能力よりも大きな失敗の要素となるのがメンバーの「やる気」。各メンバーの能力を計算に入れて、見積上は実行可能なプロジェクトを計画していたとしても、実際にメンバー見込みどおりに仕事をしてくれなければ簡単にプロジェクトは頓挫します。 他人の話ではなく、自分の話として考えてみてください。作業に集中できて異様なほど仕事が順調に進むときもあれば、ほかのことが気になって仕事に集中できなかったり、理不尽な上司や先輩に腹が立って仕事をやる気にならなかったりすることがあるはず。特に、土木工事のように進捗が見た目にも分かりやすいプロジェクトであれば、やる気がなさそうな人を見つけるのも比較的容易ですが、ホワイトカラーの仕事は進捗が把握しづらい仕事がほとんどです。 やる気があると思っていたメンバーが、何かのきっかけで急速にやる気を失い、気がついたら予定が大幅に遅れていたというのも、意外によくある話です。もちろん、プロジェクトマネージャーが細かくメンバーの進捗を把握するという手もありますが、過度の進捗確認がメンバーのやる気をそぐこともありえるというのが、また悩ましいところでしょう。 プロジェクトの計画も無難、メンバーもやる気があるから一見問題ない――という場合に、失敗の要因となるのが「変化」です。 例えば、予定していたのとは異なる作業が増えた場合です。「メンバーが病気になって数日休んでしまった」「サーバトラブルが発生して復旧作業に人手がとられてしまった」「そもそも見積もりが甘かったために初期作業に予想以上に時間がかかった」など、プロジェクトに途中で変化の要素が加わることは日常茶飯事。にもかかわらず、途中で発生した変化を無視した状態で、締め切り間際までそのままプロジェクトが進行する、というのは実によくある話です。 もちろん、若干の遅れであれば、遅れの原因となった人がカバーするべく努力するなり、最後の最後で他のメンバーがフォローすることで対応できることもあります。 ただ、事前の見積もりが厳密であればあるほど、発生した遅れを取り戻す余裕がどこにも存在しないため、様子を見るつもりがそのまま締め切りに響くことになりかねません。 これは変化を認めないプロジェクトでよく発生するケースです。リリース日は決まっているのだから、途中でプロジェクトに変化が発生しても、プロジェクトのリリース日は死守。そんなプロジェクトに限って、変化が発生した段階では特に対応をせずに、締め切りギリギリまで根性に任せて様子を見るケースが多くあります。 根性で乗り切れないケースは人生にはたくさんあります。結局、奇跡でも起きない限り、最終的には締め切り直前に地獄を見ることになるわけです。 このように失敗の要素を3つに分解すると、プロジェクトの失敗を構成する要素自体は、実は意外にシンプルだということが分かると思います。 計画をしっかり作成し、メンバーにやる気を出してもらい、変化に対応すれば、プロジェクトマネジメントは成功するということですから。 逆にこの「計画」「やる気」「変化」というプロジェクトマネジメントを構成する要素はシンプルでも、それぞれに問題が発生しないようにコントロールするのが至難の業。土木工事のように過去の蓄積があるために「計画」も立てやすく、メンバーの「やる気」もはた目に分かりやすく、予想外の「変化」も比較的発生しにくいプロジェクトであれば、まだ対応の方法はあるかもしれません。 ところが、ホワイトカラーの仕事は、毎回“初体験”のようなプロジェクトで正確な「計画」を立てるのが不可能に近く、「メンバー」の作業効率も把握しにくい上に、プロジェクトに変更や変化が頻繁に発生します。ある意味プロジェクトマネジメントは失敗するのが当たり前と考えたほうがいいかもしれません。 そこで次回はこの前提に立って、変化の激しい仕事では、どのようなプロジェクトマネジメントが最適なのか考えてみたいと思います。 NTT、ITコンサルを経て、現在はアリエル・ネットワーク株式会社プロダクト・マネジメント室マネージャ。ビジネスパーソンの生産性向上のためのソフトウェアの企画・開発やコンサルティング業務に従事するほか、グループウェアやブログ、仕事術などに関する執筆・講演活動を行っている。ブログは「ワークスタイル・メモ」と「tokuriki.com」 チームで働く場合の仕事管理術である「プロジェクトマネジメント」。実は、プロジェクトのリーダーではなくとも“マネジメント”できるのです。自分自身の仕事管理をチーム全体に広げてみませんか。 ITSS判定調査で、何が分かったか。スキルと収入には相関関係はあるのか、資格はあると有利か。それらの疑問に答える 「なぜオフショア？」という疑問をお持ちの皆さんへ。オフショアは目的ではなく手段。選択肢の1つとして力を発揮する状況とは？ インストールパーティを開催してみたが、回を重ねるごとに見えてくる課題と可能性。ユーザーが求めているものは一体何だろうか |
