Pareto Principle
結果の80%は全体の20%の要素に依存する
「80:20の法則」とも言われます。得られる結果の大部分は、それを構成する要素の一部分で決まってしまう、という法則です。
経済学で使われる法則ですが、システム開発の世界でも不思議に当てはまります。
システム開発における、パレートの法則
システム開発においてパレートの法則を使うと、すばやく改善ポイントを見極めるために役立ちます。
システム開発では様々な問題が発生します。効率よくこなすためには、優先度をつけて問題をさばく必要があります。この優先度をつけるために役立ちます。
システム開発への活用方法を紹介します。
- プログラムバグの80%は、コードの20%に存在する
- プログラム実行時間の80%は、コードの20%の部分が費やしている
- プログラムテスト工程の80%の時間は、テスト項目の20%の実施時間が占めている
- システム開発成果物の80%は、開発者の20%の人が作っている
プログラムバグの80%は、コードの20%に存在する
たくさんのモジュールをコーディングしてテストします。テストすると、いろいろなバグが発生します。
不思議なことに、バグは、各モジュールに万遍なく発生するのでなく、特定のモジュールに集中して発生します。
そういうモジュールはたいてい、いろいろ処理がごった煮状態の、神クラスとなっています。
まずは、バグが多い問題モジュールを特定し、それを真っ先にデバッグしましょう。デバッグ作業全体の効率が上がります。
プログラム実行時間の80%は、コードの20%の部分が費やしている
プログラムを動かすと、処理完了までに非常に時間がかかる。このような場合、高速化のためにプログラムを見直します。
このとき、気になったところからやみくもに直してはいけません。プログラム実行時間の大半は、コードの一部分が費やしている場合が多いです。
まず、コードの中で実行時間を費やしている箇所を特定しましょう。そのような問題箇所を、ボトルネックといいます。
ボトルネックを特定するためには、プロファイルツールを活用します。たいていのプログラミング言語で、プロファイルを計測するためのツールが使えます。
そして、そのボトルネック箇所を集中的に対策するわけです。
プログラムテスト工程の80%の時間は、テスト項目の20%の実施時間が占めている
プログラミング後にテストを行います。このときにテスト項目を設定してテストします。
このテスト、「1日〇件」のように一定数こなしていくことには、まずなりません。テスト項目のうち難易度が高い20%に、大多数の時間がかかる、というパターンが多いです。
テスト項目から難易度が高い20%を振り分け、その項目にはリスクマージンを持った工程を割り当てておくことが大事です。
システム開発成果物の80%は、開発者の20%の人が作っている
大規模なシステム開発を、複数の開発者で分担するときの話です。
その生産性は、担当者の能力で違いがでますが。ことシステム開発においては、初心者と熟練者で生産性の違いが相当大きいです。10%や20%程度でなく、何倍、くらいのオーダーで違います。
担当を決めるときは、担当者による生産性の違いを考えて割り振る必要があります。
まとめ
パレートの法則は、システム開発に携わったことがある人なら、体感として理解していることも多いはず。
問題が多いところを優先的に対処すれば、その他の問題がおのずと解決してくるときもあります。改善どころを見極めましょう。
コメント