開発生産性10倍だが、開発費が1/10にならないのは、なぜか

当社が提供している超高速開発ツールWagbyは「開発生産性10倍」とうたっています。
しかし、これをもって「開発費が10分の1」とは、言っていません。営業ベースでは、他社様による受託開発の半額程度というのが一つの指標です。

なぜ開発生産性10倍なのに、開発費は10分の1ではなく、半額相当なのか。よくいただくご質問ですので、私の考え方を明記します。なお、この考え方はあくまでもWagbyに立脚したものであり、同業他社様の開発ツールには適用できない(ツールごとに異なる考え方・ポリシーがある)ということをご理解の上、お読みください。

システム開発にパレートの法則を適用してみた

あくまでも経験則ですが、開発すべき要件(機能)の80%を開発するのは労働集約的で、残り20%を開発するのは高度なプログラミングが必要、と切り分けます。

高度、というのはあいまいですが、Wagby的には「複雑な業務処理・バッチ処理」「複雑なユーザーインタフェース」など、自動生成できない部分を指します。

そしてWagbyが対応するのは前者の80%の実装部分です。これを10分の1で開発することを目指しています。(残り20%は、もともと自動化にそぐわない領域なので、人間による開発が必要です。)

次にコスト視点です。前者の80%と後者の20%のコスト費は8:2 ではなく、ざっくり7:3と捉えます。
この「7」の部分を「1」にするのがWagbyです。ただしWagby本体のライセンス費や、Wagbyの学習コストを加味して、「1」ではなく「2」とみなすと、後者の人間による開発とあわせて「5」になります。これがコスト半額のおおざっぱな根拠です。

これがわかれば、Wagby採用の分岐点も明確になります。労働集約的な部分(自動化できる部分)が多いプロジェクトには向いていますが、そうでなければ効果は限られそうです。

しかし、ここで発注側であるユーザー企業に、ある視点を加えていただくことで、さらにプロジェクト成功率が高まるようになります。

業務要件にもパレートの法則を適用してみる

ユーザー企業が「必要」と感じられている機能のうち、本当に必須なのは20%で、残り80%は「あると便利」という例外対応・ユーザー操作に関するものである、という視点で切り分けてみます。*1

ここでいう残り80%の開発部分こそ、前節でいう「高度のプログラミング」が求められるところでもあります。

そこで例えば、この80%のうちの半分は対応し、残り半分は運用しながら再検討するとします。運用中、ストレスがたまって業務に支障が生じるのか、馴れてしまうとどうということはなかったのか、やってみながら考えると割り切るのです。それだけで初期開発費をさらに減じることができます。やはり開発しようとなった場合でも、当初よりも軽い実装に落ち着き、結果としてコスト削減につながった例を私自身、何度も経験しました。「5」を「4」や「3」にするというのは、そういう視点が必要です。

Wagbyの使い方を学ぶ、ということの先へ

Wagbyという自動生成ツールを使いこなすというのは、複雑な定義のテクニックを学ぶことと同義ではありません。
ツールがカバーしない領域に対して、どのような方針で臨むのかという思想のようなものが問われます。
それはいわゆる技術面からのアーキテクチャ設計とも異なります。ツールの成長と、自社業務の高度化をリンクさせるという共存共栄が、もっともコストがかからないという意識を持ち、ベンダーとユーザーがタッグを組むという考え方に同意できるか、という説明がわかりやすいかも知れません。

これを「ベンダ依存の、囲い込み戦略」とみなすところもあるでしょう。しかしこの言葉が悪い意味で捉えられた原因は、ベンダの要求する金額を呑まざるをえないというユーザー企業の悔しさにあります。私が意図しているのは、「ユーザー企業が積極的に開発ツールの発展を支援する関係」であり、多くのユーザー企業が少しずつお金を出し合うことで、結果として「安価に、質のいい業務アプリケーションを入手しやすくなる」公共財的な環境を構築することです。そしてユーザー企業のノウハウである仕様書そのものはツールとは無関係に再利用できます。これは従来型の(ブラックボックスによる)囲い込みとは異なる発想です。

もう一つ。もっとも著名な開発ツールベンダーはマイクロソフト社ですが、同社の戦略は自社OSのバージョンアップと開発ツールをリンクさせるというものです。WagbyはOSを問いません。そして基盤技術はWeb標準(JavaやHTML5)に合わせるようにしています。基盤技術はできるだけ、その時代の標準技術に合わせるというポリシーです。

開発ツールは一度選定すると長いお付き合いになります。しかし選定基準が「機能の多さ」「価格の安さ」だけですと表面的なことしか見えません。ツールをつかったトータルの開発費削減と高速開発の体制について、ベンダがどのように考えているのか。過去の資産の継承や、未来への保守費の削減といった軸も含めて総合的に判断することが結果としてユーザー企業の安心につながる、と考えています。

*1:そんなことはできない、と最初から反対する方は、システム開発が一種のプロジェクトであり、ヒト・モノ・カネの制約の範囲内で関係者間の最適な合意を引き出すという性格を有しているという基本を今一度、思い出してください。そしてコスト重視の経営環境では、災害医療におけるトリアージという考え方と同様、(涙をのんで)線を引くという覚悟もまた、必要なのです。