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

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回はプロジェクト計画を立てる上で仮置きしたこと、すなわち、プロジェクト前提条件について考察しました。プロジェクトを進めていくうえで、前提条件がくずれた場合のダメージはたいへん大きいものです。そこで、前提条件の確からしさをなるべく早めに検証することを目的に、パイロット開発を行うことがあります。

今回はプロジェクト前提条件の検証目的で行うパイロット開発について考察します。

【　パイロット開発とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
当ブログの　【第３１回】禁断の裏マスタースケジュール　では、プロジェクト・リスクへの対応策として、以下の３つのポイントをマスタースケジュールに組み込むことを推奨しました。

１．スケジュールを１ヶ月前倒しして、リスク発生時対策用のバッファを確保！
２．パイロット開発によるテクノロジー検証で、マイナスの影響を与えるリスクを排除！
３．生産性向上施策により、プラスの影響を与えるリスクを強化！

上記の2番目に「パイロット開発」が登場していますが、このときはどちらかというと、構築するシステムそのもの（ＷＨＡＴ）に関するリスク（たとえば思ったより性能が出ないとか）に主眼を置いたものでした。

システム構築そのもの（ＷＨＡＴ）ではありませんが、新しい開発手法や開発ツール（ＨＯＷ）を導入した場合も、プロジェクトを進める上での大きなリスクになります。新しい手法を導入するのは、生産性や品質の向上が目的であることが多いと思いますが、実際に生産性が向上するかどうかは実証されたわけではありません。そのような場合には、新しい手法の導入による生産性向上効果を実証する目的で、パイロット開発を行うことがあります。（※１）

どちらの場合においても、パイロット開発の目的はプロジェクトの独自性に応じて存在する不確実なこと、つまりプロジェクトに内在するリスクへの対策だと言えます。このようなリスクは、内部設計以降のいわば大量生産に入る前の早い段階でできるだけつぶしておいた方が、プロジェクトがスムーズに運営できるはずです。

【　生産性評価目的のパイロット開発における落とし穴　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
一般的にパイロット開発は、その他大勢のプロジェクトメンバーに先んじて新しいテクノロジーや新しい手法・手順に挑むことになるため、スキルレベルの高いメンバーを選んで実施することが多いと思います。まだ誰も通ったことのない道なき道を進むという意味では、確かに精鋭部隊による実施が望ましいと思われます。

しかし、生産性評価が目的のパイロット開発の場合はどうでしょうか？精鋭部隊が切り開いた道を、その他大勢が通る際にも、精鋭たちと同じペースで進むことができるのでしょうか？これまでの私の経験から、パイロット開発を行う場合に陥りがちな落とし穴をいくつかご紹介します。

＜生産性評価目的のパイロット開発における落とし穴＞
１．精鋭部隊が実施することで、通常よりも高い生産性となる
２．通常より手厚いレビューを繰り返すなど、逆に生産性が低くなる
３．設計・開発課題の解決に多くの時間を費やしてしまい、生産性が測れない

2番目3番目は、パイロット開発の実施者が精鋭であるがゆえに、完全性を求めてしまうことで起こる落とし穴です。腕に自信がある技術者は、品質にもこだわりがあることが想定され、まだプロジェクトの初期段階で検討が深まっていないことがたくさんある中での作業となるために、生産性評価という目的以外のことに、つい力を入れてしまう可能性があるのです。早めにパイロットを始めれば、それだけカットオーバーまでに時間的余裕があるために、逆にそのような過剰作業となるリスクをはらんでいるのです。

このような落とし穴に陥ることを防ぐためには、パイロット開発の目的、ゴールを明確にして、パイロット実施メンバーが十分理解した上で進める必要があります。パイロット開発は、いわばプロジェクト内のプロジェクトとして、その目的に応じた成果がしっかり出せるような計画を組み立てる必要があります。

パイロット開発により生産性を評価する場合は、精鋭部隊が道なき道を切り開いたあとに、平均的なスキルのメンバーがその道を歩いてみることで、プロジェクトとしての標準的な生産性を確認するような２段階パイロットについても検討する必要があるかもしれません。

ＩＴ業界の進歩はめまぐるしく、次々と新しいテクノロジーや開発ツールが登場してきます。競合他社に対する優位性を保つためには、技術革新に遅れをとることは許されません。したがって、リスクが高いと知りながらも、多くのプロジェクトで新しい技術や新しい手法を導入することになります。

常にそのようなリスクを抱えながらプロジェクトを実行することの良し悪しについては、議論の余地があるかもしれませんが、現実問題として多くの場合そのような状況下でプロジェクトを推進していく必要があるので、パイロット開発などを効果的に活用して、リスクへの対応をしっかりマネジメントしていく必要があります。

【　「瞬間風速」と「トータル生産性」　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
パイロット開発などにより、システム開発の生産性を評価する場合には、担当する要員のスキルレベルなど評価対象の置かれている環境や条件によって、測定値に大きなブレが生じる可能性があることをしっかりと意識する必要があります。

たとえば、外部設計書などのドキュメント作成タスクについて、作成するペースが１時間に1枚くらいだった場合、単純に1日８時間として、ひとりが一日に８枚できるから10人で一週間（５営業日）かければ、４００枚が出来上がるなんて計算をするかもしれません。

外部設計の生産性　＝　８枚／人日　×　１０人　×　5日　＝　４００枚／週　？？

ところが、実際にはレビューによる手戻りやプロジェクトメンバーのうち二人がインフルエンザにかかって休んでしまったなど、現実の世界ではそんなに計算通りの生産性実績があがるとは限りません。

つまり、システム開発の生産性評価を行う場合には、単純に最小単位のタスクの生産性を測るだけでは不十分で、厳密に言えば、そのタスクの含まれる工程内で想定される全てのタスク（レビューや進捗報告資料の作成など）やプロジェクトメンバーの個別事情による非稼働時間なども考慮しておかないと正確には算出できません。

生産性評価に関するこのような二面性について、私は「瞬間風速」と「トータル生産性」という言葉を用いて表現しています。

「瞬間風速」　⇒　ドキュメント作成、個々のプログラムのコーディング作業や単体テスト実施・・・など、小さい単位での「成果物量÷所要時間」で示すことのできる生産性

「トータル生産性」　⇒　外部設計、内部設計、コーディング～単体テスト・・・など、システム開発プロジェクトの工程単位のような大きな期間の中で、その中で行われる管理タスクや一定の非稼働時間などを加味した生産性

「生産性を評価するときは、瞬間風速とトータル生産性の両方を意識しよう！」

パイロット開発では「瞬間風速」については比較的測定しやすいが、「トータル生産性」については測定が難しいのです。生産性を評価する対象の工程内で行われるであろうレビューや進捗報告資料作成などの全てのタスクを含めてパイロット開発を行ったとしても、測定期間におけるさまざまな固有の事情により、生産性にブレが生じる可能性が高く、正確性に欠けるはずです。

「トータル生産性」については、組織として実施されるいくつものプロジェクト実績データを地道に何年もかけて積み上げることで測定していくしか無いと思いますが、新しい手法を導入した場合は過去の積み上げデータをそのまま使うこともできません。

なので、パイロット開発などにより前提条件の検証を行うことは大事なことですが、パイロット開発で検証した生産性を全面的に信用するのはまだ危険であり、パイロット開発で実証した生産性が本体開発ではその通りにならない可能性があることを、引き続きリスクとして認識しておく必要があります。

ふー。かえすがえすも、独自性という特徴を持つプロジェクトを成功に導くことって、難しいことだと感じます。ここはやはり、リスク対策の万能薬ともいえる十分なバッファの確保が大事だということでしょうか。。。

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

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

※１　新しい手法を検証するためのパイロット開発は、プロジェクトの一部として行う場合や、特定のプロジェクトとは切り離して検証だけが目的のパイロット・プロジェクトとして実施する場合など、組織やプロジェクトのおかれた状況の中で、さまざまな取り組み方が考えられます。