DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第25回】プロジェクト初期見積り考古学


【第25回】プロジェクト初期見積り考古学

Pocket

ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

前回は、プロジェクトの初期見積り段階では「明確な部分」「不明確な部分」に加えて、「まだ見えていない部分」までなんらかの形で予算に含めないと、すぐに予算をオーバーしてしまうということを考察しました。では、いったい「まだ見えていない部分」をどうやって見積りや予算に含めるのでしょうか?やっぱり、よく言われるように、見積りはベテランPMのKKD(経験、勘、度胸)に頼らざるをえないのでしょうか?

今回は、この初期見積りの段階で行うべきことについて考察していきたいと思います。

 

【 プロジェクト初期見積りは考古学だ! 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
前回ご紹介した「初期見積りの段階での要件の明確度イメージ」の図を見ると、初期見積り段階では「要件が明確な部分」はごくわずかであり、それだけ限られた情報からプロジェクト全体でかかる費用を見積もる必要があります。このような、ごくわずかな手掛かりから全体像を導き出すという作業について、私はつねづね、まるで考古学のようだと感じています。

考古学というと、たとえば小さな土器のかけらが発掘されたり、過去に住んでいた人たちのごみ箱にあたる貝塚が発掘されることで、その時代のあらたな側面が脚光を浴びることになり、歴史の教科書が書き換わるなんてこともニュースになったりしますよね。そのようなニュースをちょっと聴いただけだと、「そんなに小さな手掛かりから、なぜその時代の全体像を見出すことができるのか?」と、たいへん興味をそそられます。
(と言っても、たいていの場合、深く調べすにスルーしてしまいますが。。。)

では、考古学がどんなものか、ウイキペディアから引用して確認してみます。(※1)

考古学は、遺物の型式的変化と遺構の切り合い関係や前後関係による層位から出土遺物の通時的変化を追う個々の遺跡の編年を縦軸とし、横軸に同時代と推察される遺物の施文技法や製作技法、表面調整技法などの比較を通して構築される編年論を基盤として、遺物や遺構から明らかにできるひとつの社会像、文化像の提示を目指している。

そう、考古学者たちは、「新たに発掘されたもの」だけから時代の全体像を導きだしているわけでは無いのです。過去の発掘史料やそれらを元に「これまで研究を重ねてきた膨大な分析結果」が背景にあり、新発見がこれまでの研究に対してあらたな視点を提供してくれることで、さらに確からしい全体像に近づいているととらえることができます。

そうです。システム開発プロジェクトの初期見積りも、RFP(提案依頼書)などに記載されたわずかな手掛かりだけから、開発予定のシステムとそのシステムを開発するプロジェクト全体像を導き出すわけではありません。これまで見積りを行う組織が蓄積してきた膨大なデータやJUASIPA/SECなどにより公開されている一般的な統計データなども利用しながら、RFPに示されている「ごくわずかな手掛かり」を元に、システムとそのシステムを開発するプロジェクトの全体像を描きだし、その全体像に対して見積りを行うこととなります。(※2)

ベテランPMのKKDは、そのPM個人の経験からだけではなく、これらの膨大なデータをいかに効果的に活用するかということに使われた場合に、効果を発揮するのではないでしょうか?

まさに、プロジェクトの初期見積りは考古学とまるで同じアプローチのように感じられますよね。なので私はこのことを「プロジェクト初期見積り考古学」と呼んでいます。

「わずかな手掛かりから全体像を導く!」なんて刺激的でロマンがあることでしょうか!
プロジェクトの初期見積りは、システム開発の中でも最大のエキサイティング・プロセスです!

「初期見積りは、システム開発の中で最もエキサイティングなプロセスだ!」

 

【 「まだ見えていない部分」を見積りに含めるにはどうすればよいか? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
とはいえ、「まだ見えていない部分」を見積りに含めるには具体的にどうしたらよいでしょうか?
前回のブログで、私は「C(要件が見えていない部分)の面積が、プロジェクトの初期段階ではこれだけあると覚悟してくださいね!」ということを主張しました。そう、まず見積り作業に入る前に、この「まだ見えていない部分」が少なからずあるはずだ、という認識を持って欲しいのです。

たとえば、車を運転しているとき、暗いトンネルに入って10メートル先が見えなくなったらあなたならどうしますか?すぐにヘッドライトをつけて前が見えるようにしますよね。車の運転の場合は、10メートル先が見えないということは、誰しもすぐに気づく(認識する)ことなので、ヘッドライトをつけるという行為を必ず行います。見積りも同じです。「まだ見えていない部分」があると認識しさえすれば、まずは「まだ見えていない部分」を見えるようにするための行為を必ずするはずです。先が見えないまま車を運転し続けたら、ほぼ100%事故ります!

プロジェクトも同じで、先が見えないまま(「まだ見えていない部分」が少なからずあるまま)、プロジェクトを進めた場合、間違いなく失敗するはずです!

話をわかりやすくするために、RFP(提案依頼書)をもとにシステム開発にかかる費用全体の見積りを行うというシチュエーションを考えてみます。最初にRFPを読み込んで、「まだ見えていない部分」を抽出して、まずはQ&Aで不明点を確認しますよね。これが第一歩です。しかし、簡単なようで、最も重要な第一歩だと認識してください。この段階で「まだ要件が見えていない部分」があると認識しているか、認識していないかで対応が大きく変わってきます。もし、それを認識していないとしたら、おそらく「要件が不明確な部分」に関する質問をたくさんすることになるでしょう。

しかし、この段階で最も重要なのは、「要件が不明確な部分」に対する質問よりも、「まだ要件が見えていない部分」がどれくらいあるかを探るための質問の方なのです。出来るPMは、この段階から過去の膨大なデータを活用するはずです。RFPから読み取れる(または読み取れない)情報に対して、過去のプロジェクトの全体像から推察して、この辺に何か隠れているかもしれないというポイントに対して質問を投げかけるのです。

たとえば、RFPの中に移行に関する要件が全く書かれていなかった場合に、「システムの移行は一括切替を前提と考えて問題無いですか?」とか、「新システム稼働後に旧システムは稼働可能な状態として残すことで、リリース直後の切戻しが出来る前提でよろしいでしょうか?」などの質問を投げかけることで、移行要件をあぶりだそうとします。ここで、RFP発行側としても移行は未検討というケースもあるでしょうが、質問の回答を読み解くことで、RFP発行側の検討状態もある程度類推することが可能となり、移行に関する見積りに対して、どの程度のリスクを考慮しておくべきかという根拠が積みあがっていくのです。

ここにあげたRFPに対する質問はあくまでも第一歩です。現実のプロジェクトの見積りでは、数週間という短期間でプロジェクト全体像に対する見積りを求められることもあるでしょう。たとえ、まだ要件は固まっていない段階での超概算であっても、ひとたび見積りが数値化されると、その数字が独り歩きすることを何度も目にしてきました。それだけ、この初期見積りはセンシティブに行う必要があります。「まだ見えていない部分」を見積りに含めるという作業は、RFPに対する質問だけで完結するはずは無く、まだまだ始まったばかりです。次回以降も初期見積りに関する考察を続けたいと思います。

それでは、次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

※1「考古学」『フリー百科事典 ウィキペディア日本語版』
http://ja.wikipedia.org/wiki/考古学 2014年2月7日 (金) 13:38 UTC

※2 主な公開データ提供組織と成果物
・一般社団法人日本情報システム・ユーザー協会(JUAS)
『ソフトウェアメトリックス調査』
・独立行政法人情報処理推進機構(IPA)
技術本部ソフトウエア・エンジニアリング・センター(SEC)
『ソフトウェア開発データ白書』

| 目次
Pocket

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事