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

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第45回】ありのままのプロジェクト実績データ収集


【第45回】ありのままのプロジェクト実績データ収集

Pocket

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

本年もどうぞよろしくお願い致します!

前回はシステム開発の生産性を評価するうえで、瞬間風速とトータル生産性の両面を意識する必要性について考察しました。組織としての見積り精度向上や定量的分析によりプロジェクトの先行きを見通すための基礎データとして、プロジェクト実績データを収集・蓄積することは欠かせないことです。

しかし、プロジェクト実績データを収集して、それをプロジェクトの成功率向上につなげる取り組みは、その目的や意義は十分理解できていても、それを実践することはなかなか難しいことです。

 

【 プロジェクト実績データ収集の目的は? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
昨年、日本でも大ヒットしたディズニー映画『アナと雪の女王』とその主題歌『レット・イット・ゴー~ありのままで~』。(※1)

人は誰しも完璧ではなく、誰しもが持つ欠点を隠して生きていると未来は開けない。「恐れ」を捨てて「ありのまま」の自分をさらけ出し、「愛」する心で自分とは異質な他者を受け入れることで、その結果「世界はひとつ」になる。

というメッセージと私は受け取っています。ディズニー映画も、ディズニーランドも、その主張は明確で、一貫性があり、私も大好きです!

新年早々いきなり話が脱線してしまいましたが、プロジェクト実績データ収集の目的は、「ありのまま」のプロジェクト状況を定量化することで、次のプロジェクトの見積りや計画策定に役立てたり、進行中プロジェクトの今後を正確に予測することで的確なプロジェクト運営を行うことなどです。

したがって、プロジェクト実行中に何か失敗して手戻りがあったり、相応のスキルの技術者が集められなかったことで生産性や品質が落ちたとしても、決して手戻りした分の実績データを除いたり、生産性や品質データをそれなりに見せようと取り繕うことは絶対にしてはいけません。

どんなプロジェクトでも、なんとか成功させようとスタートしているはずです。そんななかで起こった失敗は、必ず次のプロジェクトでもなんらかの形で起こると考えるのが自然です。だから、もし失敗が無かったらこうなるというデータはなんら現実を表したデータでは無く、そんなデータをいくら収集しても生産性や品質の向上にはつながらないでしょう。『アナ雪』から受け取れるメッセージと重ねることができますね。

どんなプロジェクトも完璧ではなく、失敗を隠していると未来は開けない。「恐れ」を捨てて「ありのまま」のプロジェクト実績データをさらけ出し、「愛」する心でどんなプロジェクトでも必ず何か失敗が起きるという事実を受け入れることで、その結果「プロジェクトの成功率」は向上する。

「失敗や手戻りも含めた、ありのままのプロジェクト実績データを収集しよう!」

 

【 プロジェクト実績データとは何か? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
プロジェクト実績データとして収集すべきデータは、主に生産性や品質に関するデータを指していることが多いと思いますが、その組織の成熟度や特性によって、また、その組織が目指している方向性によってもさまざまです。

プロジェクト実績データの収集に関するバイブル的な文献である、CapersJones氏の『ソフトウエア開発の定量化手法~生産性と品質の向上を目指して~第3版』によると、「ソフトウエア定量化、あるいは人間活動を含む複雑なプロジェクトの測定には、ハードデータ、ソフトデータ、正規化データの3種類の情報が欠かせない」としています。(※2)

「ハードデータ」とは、「ほとんど主観を交えることなしに定量化できるデータ」であり、「プロジェクトの文書量、コード量、テストケース数、検出され報告された欠陥数」などが含まれます。

「ソフトデータ」とは、「人間の主観的評価に頼らざるを得ないデータ」であり、「プロジェクトに対する顧客満足度、企業にとってのプロジェクトの価値」などが含まれます。

「正規化データ」とは、「プロジェクトの生産性や品質が平均より上か下かを判断するための標準的な尺度」であり、標準生産性や目標とする欠陥率などが含まれます。

独自性という特徴を持つプロジェクトをなんとか継続的に改善していくために、実にさまざまな切り口で定量化のアプローチが進んでいます。確実に前よりも良くなっていること、そして、どれだけ良くなっているかを経営層にわかりやすく説明するためにも、定量化の手法は欠かせないのです。その改善の方向性をどこに(何に)置くかによって、どのデータを収集すべきかが決まるために、その組織が目指す方向に応じて収集すべきデータは異なってきます。

したがって、組織が目指す方向と収集しているデータの整合がとれていなければ、いくらプロジェクトデータを収集しても、改善は進みようがありません。

 

【 プロジェクト実績データ収集の阻害要因 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
これだけ定量化の意義や大切さが叫ばれているのに、なんでシステム開発の現場ではプロジェクト実績データの収集・活用が進まないのでしょうか?私の経験から、実績収集がなかなか進まないことのいくつかの阻害要因をご紹介します。

1.プロジェクト実績データをプロジェクトの通信簿と勘違いしている!

プロジェクト実績データの収集に際し、最も心理的なハードルとなるのがこれです。学校の成績に自信の無い生徒は通信簿をなかなか親に見せたがらないでしょう。そりゃそうですよね。成績が悪ければ親に怒られます。親に怒られなかったとしても、自分が他人より劣るのではないかと疑心暗鬼になってしまいます。

成績が悪くても「恐れ」を捨てて、「ありのまま」の数字をさらけだす勇気が必要です。それを受け取る側はその数字を査定評価に使うのではなく、「愛」を持って受け入れて、組織の改善に結びつけるような行動をとる必要があります。CapersJones氏も明確に、「成果目標は社会学的およびビジネス上の理由から、技術者ではなく部長や副社長レベルの上級管理職に対して設定すべきである。」と明言しています。

2.プロジェクト実績データがステークフォルダー間の駆け引きの材料にされる!

たとえば生産性や品質のデータは発注側と受注側の間で、発注金額や作業条件にダイレクトに影響するため、お互いに明確な数値を出したがらない傾向があります。ソフトウエア開発の世界では、未だに成果物の価値に対する報酬ということよりも、成果物作成に投じた工数に応じた清算的な商習慣が根強く残っています。いわゆる人月清算です。

受注側が努力して生産性を高くしても、逆に受注額が減るというパラドックスが存在するために、「ありのまま」のプロジェクト実績データが発注側には提供されないことになります。それでは発注側としてはプロジェクト実績データを収集する術が無くなるので、結果として定量化が進まないということになります。

ここはお金がからむだけあって、なかなか難しい問題ではありますが、現実的には発注側としては、無理なく取得可能な情報だけを収集するしかないと私は思います。無理に受注側の内部データを深く追求しようとすると、さまざまな力学によって無用な負荷を受注側に与えることとなり、受注側が意図的であろうがなかろうが、良い結果は生まれるとは思えません。発注側は「愛」をもって、自分たちが選んだベンダーが提示する数字を「ありのまま」に受け止めるべきではないでしょうか?

3.そもそも測定対象プロセスの標準化が不十分である!

おそらくこれが最も致命的で、最も多くみられる定量化の阻害要因ではないかと思います。システム開発の進め方が個々のプロジェクトによって、または、それぞれのプロジェクトマネージャによってまちまちであれば、それを横並びにしてデータ分析を行う意味はそれほどありません。

プロセスの標準化が不十分な状態でプロジェクト実績データを収集することもできないことは無いですが、その場合は、やり方の違うプロジェクト間での定量化データの比較により、どっちのやり方の方が良いかということを定量的に示すことで、組織としての標準化の方向性を決定するといったアプローチぐらいにしか使えないと思います。

ものごとを定量的にとらえるという習慣を組織内に根付かせるという目的のために、標準化が進んでいなくても、定量化を進めるという考え方もあるかもしれませんが。。。

いろいろと阻害要因を並べてみましたが、プロジェクト実績データを収集して、実効性のある定量化を推進するためには、トップダウンにより定量化の目的を明確に打ち出して、強力に推進していく必要があります。さきほど示したような阻害要因への対応策も盛り込んだ「定量化計画」を十分検討したうえで、CapersJones氏が言うように「測定コストを正しく評価」して、定量化の仕組みを作り上げるために必要十分なリソースの手当ても欠かせません。システム開発実務を進めている現場に丸投げするだけでは、絶対に進みようがありません!

うーむ。定量化の道のりは本当に険しいですねえ!

皆様のプロジェジェクトが定量化に成功することで、『アナ雪』のようなHappyEndを迎えられることをお祈りしています!

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

工藤武久

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

※1 「アナと雪の女王」『フリー百科事典 ウィキペディア日本語版』
2015年1月9日 (金) 16:52 utc http://ja.wikipedia.org/wiki/アナと雪の女王

※2 CapersJones(2010)『ソフトウエア開発の定量化手法-生産性と品質の向上を目指して-第3版』共立出版

| 目次
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最近の記事