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

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

残念ながらうちの二人の息子たちは、早くも高校野球秋季大会予選敗退。山のように積みあがった課題をクリアするために、夏の予選までの限られた時間を有効活用する必要があります。

スケジュール制約のあるシステム開発プロジェクトでも、時間の有効活用は重要なテーマです。今回は、システム開発における「80対20の法則」の活用方法について考察します。

【　80対20の法則　とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
「80対20の法則」をGoogleで検索すると、「パレートの法則 – Wikipedia」という項目が筆頭に表示されます。これをクリックすると以下のように説明されています。（※１）

パレートの法則（パレートのほうそく）とは、経済において、全体の数値の大部分は、全体を構成するうちの一部の要素が生み出しているという説。
80:20の法則、ばらつきの法則などと呼ばれることもあるが、本来は別のものである。

また、世界的ロングセラーであるリチャード・コッチ氏の『人生を変える80対20の法則』によると、「80対20の法則」について、以下のように説明されています。（※２）

80対20の法則とは、投入、原因、努力のわずかな部分が、産出、結果、報酬の大きな部分をもたらすという法則である。たとえば、あなたが成し遂げる仕事の80%は、費やした時間の20%から生まれる。

「パレートの法則」と「80対20の法則」は、本来は別ものとのことですので、本ブログでは「80対20の法則」を使います。簡単に言えば、「世の中のいろいろなことは、全てが平均的にならされているわけではなく、わずかな一部にほとんどが依存していることが多い」っていう感じでしょうか。

８０とか２０という数字にはあまり厳密性はなく、７０対３０でも、９０対１０でも、偏りがあればこの法則に含まれると考えて良いでしょう。まあ、当たり前っていえば当たり前の経験則ですが。。。

やはり言葉の定義だけではピンとこないので、「80対20の法則」をシステム開発プロジェクトのどんな場面で活用できるのかを少し見てみましょう。ここでは、品質管理、問題・課題管理、スケジュール作成における「80対20の法則」の活用方法についてご紹介します。

【　品質管理への活用　～　不具合分析のパレート図　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
まずは、品質管理への活用です。設計工程でのレビュー指摘、テスト工程での不具合分類の傾向分析では、指摘や発生の多い順に次のようなグラフを作ることがあると思います。

これはパレート図と呼ばれるもので、いわゆるＱＣ七つ道具のひとつであり、いまさら説明するまでも無いでしょう。（※３）

工程の初期段階の品質分析において、摘出された不具合の分析を行い、指摘の多い２０％の不具合への予防対策を実施すれば、後続の作業において作りこまれるはずだった８０％の不具合が予防できるという考え方です。作りこみが多い不具合を優先して予防するという考え方は、既にシステム開発の現場にも浸透していることと思います。

【　問題・課題管理への活用　～　優先順位づけ　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
これもシステム開発のプロジェクトにおいては、当たり前に実施していることと思います。問題・課題一覧表には、その問題の緊急度や影響度などにより優先順位をつけていることと思います。問題・課題の発生した順に対策を打つのではなく、優先度の高い順にやっつけていくことが、問題・課題管理のポイントです。

「80対20の法則」との関連で言うと、プロジェクトで発生する問題・課題のうち、優先順位の高い２０％への対応ができれば、問題・課題によるプロジェクトへの影響の８０％を解消できるという感覚を持つと良いと思います。

まだ問題・課題として顕在化していないリスクまで視野に入れると、「とにかく発生した課題は順々に対策していき、まだ発生していないリスクについての対応は後回しにする」という思考だけは、絶対に避ける必要があるということは明白です。

むしろ、既に発生してしまった課題への対応よりも、まだ発生していないがプロジェクト目標に重大な影響を与えるかもしれないリスクへの対応をしっかりと行うことの方が、プロジェクトの成功と失敗を左右するという感覚が必要です。

【　スケジューリングへの活用　～　リスクの分散　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
さて、「80対20の法則」の品質管理や問題・課題管理への活用は、それを意識しているか、意識していないかにかかわらず、システム開発プロジェクトの現場に既に十分浸透しているのではないかと思います。もちろん、「80対20の法則」を十分意識したうえで活用する方が効果的だと思いますが。。。

しかし、実は「80対20の法則」の最も効果的な活用方法は、スケジューリング、すなわち、タスクの組み立てに活用することだと私は考えています。当ブログの前回　【第３７回】９０％シンドロームの賢い撃退法　では、９０％シンドロームを撃退する２つ目のポイントとして、「やっかいな問題を早期にあぶりだすようにタスクを組み立てる（リスク予防策）」ということをあげました。

ある工程のタスクスケジュールを組み立てるときに、「80対20の法則」に基いて、たとえば「その工程で実施すべき全タスクのうち、リスクの高い２０％のタスクを実施するのに、その工程全体の８０％の期間が必要になるかもしれない！」と考えるのです。

この考えに基づいて、単純に、リスクの高い２０％のタスクに８０％の期間を割り当ててしまうと、それは全てのリスクが顕在化したときの最悪のシナリオによるスケジュールとなり、おそらく予定された納期を遵守できるスケジュールを組むことができなくなるでしょう。ここで、もうひとひねり考えてみます。

リスクの高い２０％のタスクへのバッファをどれくらい、どんな感じでスケジュール全体の中に組み込むかにもよりますが、工程単位で見たときの９０％シンドロームに陥らないためには、少なくともリスクの高い２０％のタスクを工程の終盤に固めてしまうことだけは避ける必要があります。

逆にリスクの高い２０％のタスクを全て工程の最初に固めてしまうと、もしリスクが顕在化してしまうと、その工程の進捗が最初からまったく進まないことになってしまいます。それでは関連するステークフォルダーに必要以上に不安をあおることになるし、プロジェクトメンバーたちもこの先どうなってしまうか、不安になりパニックに陥るかもしれません。たとえれば、高校野球予選の初戦で優勝候補と当たって、１勝もできずに敗退してしまうようなものです。

リスクの高くない８０％のタスクについてはすんなり進められるはずであり、それに、プロジェクトメンバーのスキルセットに応じてリスクの高いタスクとリスクの低いタスクを割り振ることも考慮する必要があります。

つまるところ、その工程内でリスクの高い２０％のタスクを洗い出したら、工程終盤は避けつつも、その工程期間全体にリスクの高いタスクを分散するようにスケジュールを組み立てるのが、バランスのとれたスケジュールになると思われます。

まあ、現実のプロジェクトでは、さまざまな制約事項があるでしょうから、そんなにきれいにタスクスケジュールが組み立てられることは無いでしょう。ただ、ここにあげたような「80対20の法則」を意識しながらスケジュールを組み立てることで、プロジェクト成功へのシナリオを作り上げるという思いがプロジェクトマネージャーには必要だと思います。

「80対20の法則を活用して、プロジェクト成功へのシナリオを組み立てよう！」

甲子園への道・プロジェクトでも、システム開発プロジェクトでも、課題やリスクは山積みであり、その課題やリスクに対して、いかに優先順位をつけながら成功へのシナリオを作り上げていくかが、プロジェクトマネージャーの腕の見せ所だと思いませんか？

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

工藤武久

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

※１　「パレートの法則」『フリー百科事典　ウィキペディア日本語版』　http://ja.wikipedia.org/wiki/パレートの法則　2014年9月16日 (火) 04:03 UTC

※２　リチャード・コッチ(2011)『[新版]人生を変える80対20の法則』阪急コミュニケーションズ

※３　「パレート図」『フリー百科事典　ウィキペディア日本語版』　http://ja.wikipedia.org/wiki/パレート図　2013年3月26日 (火) 02:21 UTC