ランチェスターの法則にシステム開発の仕事を当てはめてみる

ランチェスターの法則というものがあります。人数と戦力の関係を表した法則です。

一方でシステム開発は地道な作業が非常に多くてマンパワーを必要としますが、人数を増やしても思うように成果が上がりません。

今回はシステム開発を効率化するために、ランチェスターの法則を活用できないかと考えてみました。

ランチェスターの第一法則

第一法則は、近代より前の装備（剣や槍など）では戦力は人数に比例するというものです。

基本的に一度に一人の敵しか攻撃できないので、人数に比例すると考えられます。

システム開発では戦力というか生産性は、人数からコミュニケーションコストを引いた値になると人月の神話に書かれています。

よってシステム開発も第一法則に近いと考えられます。そもそも人間は基本的にシングルタスクなので（マルチタスクは非効率であると研究結果から解っています）、仕事は第一法則に近いと考えられます。

ランチェスターの第二法則

第二法則は、近代以降の装備（重火器や装甲兵器）では戦力は人数の二乗に比例するというものです。

近代以降の兵器では、複数の敵を同時に攻撃できるため、単純に人数比例にはなりません。また兵器の性能によって戦闘力が大きく異なります。

システム開発における人数と生産性の関係

システム開発の世界には人月の神話という古典的名著がありまして、これによると、システム開発の生産性は、一人当たりの生産性をP、コミュニケーションコストの係数をC、人数をnとして次の式で表せます。

システム開発の生産性 = Pn - Cn ( n - 1 ) / 2

Cn ( n - 1 ) / 2 の部分がコミュニケーションコストです。

人数が増えると、こなせる作業量も増えます。しかし人月の神話では、それ以上にコミュニケーションコストが増えると指摘しています。

ITエンジニアの方は人数によるコミュニケーションコストを日頃から実感されていると思います。システム開発以外でも、メンバーが多い管理職の方や、大規模プロジェクトのマネジメントを担当している方は、人数によるコミュニケーションコストを実感しているかと思います。

作業を特徴で分類してみる

システム開発には地道で細かい単純作業が沢山あります。ITとは華やかそうに見えて泥臭い仕事です。

一方で企画や要件定義、設計、難解な技術的な事象の解決など、単純に時間をかければ解決できるわけではないことも少なくありません。システム開発の見積もりはこのような不確定要素に悩まされることが多く、具体的な数値を出すことが簡単ではありません。

では地道で細かい作業と不確定な作業に分類して考えてみましょう。

単純な作業はランチェスターの第一法則で考える

単純な作業はランチェスターの第一法則で考えます。これらの作業は単純に人数比例だからです。コミュニケーションコストはありますが。

しかしここで単純にランチェスターの第一法則に従ってはいけません。あくまでもこの手の作業はランチェスターの第一法則に近いというだけです。人月の神話の式で書いたように、コミュニケーションコストが人数比例以上に大きくなります。

ここでやることは、適度に人数を確保するけど、過剰に人数を確保しないことです。人数が多すぎるとコミュニケーションコストが高くなり、人数が増えたのに生産性が上がらないということになります。

対策としてはこんなところでしょう。

・プログラムやExcelテクなどによる効率化を図る。
・顧客が自前でできる作業は、顧客に自前でやってもらう。
・顧客のIT部門に人員が多い場合は、顧客のIT部門にやってもらう。
・あまり効果が高くない作業を交渉によって見送りにする。
・プロセスを整備することで、作業方法に関する質問などを削減する。

不確定な作業はランチェスターの第二法則で考える

企画や要件定義、設計、難解な技術的な事象の解決など、作業時間が見えにくい作業においては、ランチェスターの第二法則で考えてみます。

この手の作業は、一人で散々悩んだけど、相談したらいい案をもらえてすぐに解決できたということがあります。一人で悩まず、知っている人に聞いたり、解りそうな人に相談したりすることが重要です。

そうなると相談相手がいる場合は、一人と比べて圧倒的に解決時間が短くなります。1時間悩んだのに聞いたら10分で解決したなんてよくあります。つまり効率は圧倒的に高いのです。

これなら戦力は人数の二乗に比例するといえるかもしれません。しかしプロジェクトメンバー全員に相談できるとは限りません。

ということは、プロジェクトの人数に比例するのではなく、相談できる人数（＝ヒントをくれそうな人数）のk乗に比例するのです（二乗かどうかわからないので、k乗としています）。

対策としてはこんなところでしょう。

・一人で悩まず解りそうな人に相談する。
・相談相手は上司や社内の有識者も含める。
・相談相手に顧客の担当者も含める。
・作業範囲や体制などが絡むなら、相談相手に営業も含める。
・解決方法は作業完了だけでなく、作業範囲の変更もときにはある。

相談できる人数によるということは、ここでもやはり人が多ければいいわけではないということになりますね。適度な人数がよいのです。

終わりに

ただ闇雲に突っ走っても仕事は上手くいきません。そこで仕事を上手く回すにはどうしたらいいかを考えてみました。今回はたまたまシステム開発でしたが、他の仕事でもランチェスターの法則を応用できると思います。

知と知の組み合わせによって気付きが得られたり、解決方法を発展させたりできますね。こういうことは積極的にやっていきたいものです。