Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば
　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)
をヒントに、開発とマネージメントの共通点として、今回は「Greedy algorith」と「2割8割の法則」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

greedy algorithm

世の中には簡単な問題と難しい問題があり、例えば並べ替えするときに単純に2重ループするとデータ数Nが増えるとその2乗（N^2）ほど時間がかかりますが、処理を工夫して木構造にデータを並べておけばその木の高さ（logN）で処理が済みます（実装者のための計算量のはなし - O(logN)などをわかり易く説明しました -）。

これに対してナップザックにいろいろな大きさの荷物を入れるような問題は、NP困難と呼ばれる難しい問題です。すべての組み合わせを確認しないと隙間を最も少なくできないからです。そこで Greedy algorithmという手法がとられます。これは隙間の少ない（価値のある）大きなものから貪欲に詰めていく方法です。最適ではないですが、ほどほどにうまく詰める方法です。

プロジェクト管理においても最適な計画を立てることは簡単ではありません。そこで、大事な作業や後回しにすると問題になる作業から実行あるいは計画すると、ほどほどに良い計画を作ることができます。アジャイル開発のやり方はまさにこのような方法です。計画駆動な開発ならこの方法でできた計画をたたき台に、より最適な計画を作成することができるでしょう。

＃初期のスクラムガイドは優先順序だけで実行時順序を決めていたので、リスクの考慮が乏しいものでしたが、その後見直されたようですね。

閑話休題。プロジェクトの実行や計画には様々な要素があって簡単ではありません。まずはどの作業が価値があるか、すなわち重要あるいは後回しにできないかをまずは見極めてそれに基づいて計画しましょう。

もちろん、そもそものソフト性能にも利用できます。ソフトウェアの処理データが増えることで処理が遅くなるような場合に、網羅的で単純な繰り返し処理になっていないか、調査してみてください。

2割8割の法則

網羅的に実施しない場合に重要なものから実施するとどのような効果があるのでしょう。2割8割の法則はパレートの法則とも呼ばれ、度数順に要素を並べるパレート図を描くと、一般に上位2割が8割を占めているという法則です。

この法則に基づくと、アプリケーションの価値のある2割の機能を実現するだけで8割の価値があり、残りの8割の機能はあまり価値がないということになります。アジャイル開発では価値のあるものから開発し、随時リリースすることで価値の少ない8割の開発よりもリリース後の外界の変化に対応することを選んでいると考えられます。

2割8割の法則は障害の対応や改善において用いられています。分析して障害の量や質が問題になる上位2割の障害対策を行えば、より効果が得られるでしょう。

プロジェクトを進化させる

プロジェクトは日々変化します。プロジェクトもそのままではうまくいかず、常に変え続けないといけません。ソフトウェア開発ではリソースが潤沢ではない場合が多いので、孫氏の兵法に示されるようにパワーを分散せずにポイントを絞って攻めるとうまくいくでしょう。

グリーディアルゴリズムや2割8割の法則も同じようにポイントを絞る方法で、大事なことを見極め、優先順位をつけるという特徴があります。これらを生かせば、プロジェクトを変え続けてより効果的に進化させることができるでしょう。

参考：
（[#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～）