システム開発の価値生産性を高めるためには
この手の話、生産性ってよくIT業界なんかでも話題になる話なので、ちょっと考えてみます。
開発生産性と保守生産性と価値生産性
IT業界、特にソフトウェア開発の現場では、開発生産性、保守生産性、労働生産性それぞれ語られることが多いです。
開発生産性は、主にソフトウェアを作成するのにかかる生産性。プログラミングスキルが高いと生産性が高いとか、記述力のある言語を使うと生産性が高いとかってやつです。
保守生産性は、維持保守に必要となる生産性で、運用を自動化して少人数で保守できるとか、トラブルが起きてもハードランディングしないので復旧に手間がかからないとかってやつです。
労働生産性は、元記事でも言われるように最小の投入工数で最大限の収益を得るってやつです。労働生産性＝価値生産性ですね。
IT業界、特にソフトウェア開発等の生産性を語られる場合、大体の場合開発生産性化保守生産性が語られることが多いかと思うんですけど、あまり価値生産性って語られないことが多いんですよね。。
SIerのシステム開発でよく使われる開発形態として、スクラッチ、パッケージ、SaaSを題材に語ってみようかと思います。
価値生産性あれこれ
価値生産性を語る際に欠かせないのが、価値の売り方です。
ここでは、SIerの観点から、「スクラッチ」「パッケージ」「SaaS(ASP)」の3種でウリ方を考えてみようかと思います。
まず、スクラッチですが、基本的には開発したソリューションの価値が提供価値と等しく、また、それにかかる労力は開発工数に等しいです。
この場合は、開発工数を最小とし、提供するソリューションの価格を最大にすることで価値生産性が最大となります。
つまり、開発生産性を高めることとほぼ同意です。
同一機能のシステムを３回開発しようとする場合は以下の様な形となります。
| 提供価値 | 工数 | |
| 1回めのシステム開発 | スクラッチ開発の価値 | 開発工数 |
| 2回めのシステム開発 | スクラッチ開発の価値 | 開発工数 |
| 3回めのシステム開発 | スクラッチ開発の価値 | 開発工数 |
毎度毎度、同一の開発工数を使い、同一価値のシステムを提供する様な形となります。
※本当は、こなれた開発ができるので２回目以降は生産性向上するのですけど、面倒なので除外。
次にパッケージですが、標準化ソフトとカスタマイズから成り立つパッケージの場合、カスタマイズ部分ではスクラッチと同じ価値生産性の考え方となる反面、標準化ソフトは、一度開発して以降は完全に使い回しとなりますので、2回目以降の適応では開発工数はほぼ0です。標準ソフトはスクラッチ開発でいうところの内部設計以降の開発工程を対象にすることが多く、毎度の開発は外部設計部分までの設計＋カスタマイズソフトの作成となります。つまり、以下の様な関係となります。
| 提供価値 | 工数 | |
| 1回めのシステム開発 | カスタマイズ開発の価値＋標準ソフトの価値 | カスタマイズ開発の工数＋標準ソフトの工数 |
| 2回めのシステム開発 | カスタマイズ開発の価値＋標準ソフトの価値 | カスタマイズ開発の工数 |
| 3回めのシステム開発 | カスタマイズ開発の価値＋標準ソフトの価値 | カスタマイズ開発の工数 |
スクラッチ開発と比較すれば、１回めのシステム開発では通例標準化開発部分では開発生産性が高くない（スクラッチに比べれば面倒な設計となる）ため、スクラッチ開発より開発ボリュームが増加するため、価値生産性が低いのですけど、２回目以降のシステム開発ではスクラッチ開発よりも、標準ソフトを利用している分開発工数が少なくなります。
同一の標準ソフトの提供回数が多ければ多いほど、スクラッチ開発より価値生産性が高いこととなります。
ただし、保守生産性はスクラッチよりも低いです。システムが１つの標準ソフトに対して複数のカスタマイズソフトが存在することから、レグレッションテスト等の負担が非常に高まります。標準ソフトは開発会社資産となるため、メンテナンス費用は自社持ち出しが多いです。そこら辺の負担は無視できない場合も多いです。
次にSaaS(ASP)ですが、標準システムとデータパラメータシートの入れ替えによりシステムを提供するため、標準システムの初回開発以降はほぼ開発工数は０となります。パッケージよりも標準化領域が多く、外部設計（外部仕様）も統一化されます。導入要件である概要設計以降のすべての部位が再利用されるわけです。つまり、以下の様な関係となります。
| 提供価値 | 工数 | |
| 1回めのシステム開発 | SaaSの価値 | 標準ソフトの工数 |
| 2回めのシステム開発 | SaaSの価値 | パラメータ入れ替え |
| 3回めのシステム開発 | SaaSの価値 | パラメータ入れ替え |
パッケージ開発と比べれば、１回めの標準システムの開発はパッケージ以上に開発生産性が高くないです。パッケージは比較的ステートレスな設計ができるのですけど、SaaSでは利用する複数のユーザデータが共通の領域にであるため、セキュリティや権限管理などに多数の開発が必要となるからです。
反面、２回目以降はパラメータの入れ替えだけでユーザ導入が対応できるため、工数はほぼ０みたいなもんです。
つまり、パッケージと同様に影響回数が多ければ多いほど、価値生産性が高くなることとなります。
ただし、保守生産性はトコトン低いです。維持にかかるコストはスクラッチやパッケージ以上です。パッケージと同様、標準ソフトは開発会社資産となるため、メンテナンス費用は自社持ち出しが多いです。そこら辺の負担は無視できない場合も多いです。
価値生産性を高めるには
スクラッチ、パッケージ、SaaSの各種生産性についてまとめると以下のようになります
| 価値生産性（１回売り切り） | 価値生産性（複数） | 開発生産性 | 保守生産性 | |
| 高い | スクラッチ | SaaS | スクラッチ | スクラッチ |
| ↓ | パッケージ | パッケージ | パッケージ | パッケージ |
| 低い | SaaS | スクラッチ | SaaS | SaaS |
※ざっくりなので、必ずしも成り立つわけではないのでご注意。
１回だけのシステム開発に限定すれば、スクラッチ開発が最も価値生産性が高く、開発生産性や保守生産性の高いソフトウェア開発ができます。
コレに対し、複数回のシステム提供を念頭にするのであればSaaS形式が最も価値生産性が高いこととなります。
となれば、理屈上は非スクラッチ開発の方が良いって結論になりそうですが。。。
非スクラッチ開発はときとして開発生産性の低い開発手法を選ばなければならない場合があります。前述した通り、開発物も多く複雑です。
また、パッケージもSaaSもソフトウェア資産の扱いで、契約締結方法の見直し（顧客資産から自社資産への変換、運用費の自社持ち出しなど）が必要となるので、基本的には開発の現場だけでは対応は厳しいかなと思います。
複数の売り先も無いのに非スクラッチ開発を行ったら、開発・運用コストだけでエライことになりますしね。
したがって、非スクラッチ開発の適応可否について、現場の立場導入するインセンティブは働きづらいので、ときには個別プロジェクトや開発現場の枠を超えた戦略的な開発計画が必要になるかと思います。
また、ユーザの要求を達成しようとした場合、SaaSはあまりにも固定的で、業務要件を達成できないこともしばしばです。
となると、カスタマイズやその他パッケージ適応なんてのも必要になるわけで、そういった複雑なシステムをきちんと開発、運用できるようマネジメント能力が問われる形になるかと思います。
そういった製品戦略に対して適切な能力開発についてもきちんと計画を立てなければ、価値生産性の向上は絵に描いた餅でしょう。
資本集約と労働集約という言葉がありますが、SIの世界はよく労働集約と言われます。
であれば、労働資本をいかに高めるか、適切な投資計画がカギを握るかと。
まとめ
上記の様に、システム開発の価値生産性を高めるためには、キーワードとして「再利用」「標準化」そして「戦略的投資」なんて言葉で表せます。
上記例はSIの話ですが、一般論でも通じるところはあるかと思います。
価値生産性を上げるためには、現場の努力で開発生産性を高めることももちろん必要ですが、何より経営方針といった戦略レベルで立案することが必要かなと。
というわけで、結論としては元記事の話と同じ。労働生産性あげたきゃ
なにい？労働生産性が低いい？なんということだ、もっとビシバシ低賃金で死ぬ寸前まで働かせて、生産性を無理にでも引き上げろ！！！
ではなく、そうやって文句を言っている経営者や役員が、きちんと知恵絞って戦略練らなきゃ労働生産性をあげようなんか無いですよってことで。
以上
