プログラミングとパレートの法則 80:20

「80:20の法則」などとも言われ、全体の数値の大部分は一部分が生み出しているものである。といった法則です。
今回はこれをプログラミングのコーディング時間の観点で見ていきたいと思います。

結論を書いてしまうと、80%程度の出来で素早く作ることを意識していきましょう。ということです。

Wikiを参照すると次の通り。

パレートの法則（パレートのほうそく）は、イタリアの経済学者ヴィルフレド・パレートが発見した冪乗則。経済において、全体の数値の大部分は、全体を構成するうちの一部の要素が生み出しているとした。80:20の法則、ばらつきの法則とも呼ばれる。

https://ja.wikipedia.org/wiki/パレートの法則

では、このパレートの法則を見ていきましょう。

プログラムを完璧にする

プログラムで不具合もなく、完璧なソースコードを書くには時間がかかります。
全てのパターンを洗い出すといった作業が必要になるためです。

パターンの洗い出しは人の手で完璧に行うことはソースコードの量が多くなればなるほど難しくなってくると思います。人の手で完璧を目指すのは無理がある。そんなプログラムもあるかもしれません。

正直、プログラムを完璧に近づけていく作業というのは、コスパが悪いんですよね。
多少の不確実性については目をつぶったほうが良いでしょう。

コスパが良いプログラムとは

段階を踏むようにして探すが良いでしょう。

例えば、以下のような形に段階を分けて開発を進めていくことで、どこまでであればすぐに終わるのかわかるようになると思います。

分け方やどこまでがコスパが良いのかは開発内容にもよるかと思いますので、ここまでにしたほうが良いとは言えませんが、どこまでがコスパが良くてどこまでがコスパが悪いのかがわかるようになるのが良いですね。

順正常や異常系対応を削るという考え方はあまりせず、どこに時間がかかっているのかを見るために分けておくイメージですね。

80:20 の法則

さて、コスパが良いプログラムは各々で探すと書いてしまいましたが、
恐らく段階を設けてみると、殆どの作業が準正常や異常系といったプログラムの詰めを行う部分になるのではないかと思います。

80:20という具体的な分け方にはならないかと思いますが、最初の正常系動作部分を作るのみであればすぐに出来上がってしまうということが多くありました。

この詰めの部分については、異常系のパターンなど悩む時間が増えてしまうんですよね。

イメージとしては、

のようなイメージだったりします。

解消するには？

正常系実装時点でチームメンバーに共有することです。悩む時間は、一人で悩む時間が多くなり、人に聞けないせいでさらに時間がかかってしまうということが多くなります。

完璧に実装するにはどうすればよいか悩むようであれば、誰かと相談して結論を早めに出してしまう。そんなことをすれば、悩む時間の削減を行うことができるでしょう。

まとめ

パレートの法則が関係なくなりつつありましたが、結論はこの2つです。

皆様も悩むようであれば、早めに相談してしまいましょう。