セカイノカタチ

世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。最近はカメラの話題も多め

「価値創造契約」と企業のシステム開発を覆う暗黒ロジック

永和さんの「価値創造契約」が大苦戦を強いられている件

この件ですが。

新しい契約形態での受託開発サービス「価値創造契約」 | 永和システムマネジメント

最初に、このニュースを見た時には、「これは凄いことだ」と思いました。

こんな事がうまくいくのであれば、まさに業界の価値観がひっくり返る出来事だと。

しかし、今のところひっくり返っては居ないようで、悲しいですが、まあ順当かなという感想です。

ユーザーは自分の欲しいシステムを知らない

ていうか、これ、ガチでシステム開発含めて初期費用0円なの?

そうすると、自分で思いついたシステムを作ってもらって、即解約→自分で作り直す。とかできちゃうけどいいの?

僕が好きな格言に「ユーザーは自分の欲しいシステムを知らない」という物があります。

これは、自分でシステムを作ってみるとわかるんだけど、「こういうシステムがあったら便利そうだな」っていう予想のもと作り始めたシステムが、当初の仕様で使えるものになる可能性って凄く低くて、そこから約9倍(経験則)ぐらいの手間をかけてやっと、使える感じのシステムになるという。

自分で使うシステムを自分で作る。つまり「ユーザー=開発者=自分」なわけで、コミュニケーションロス=ゼロです。理想の開発環境に置かれたとしても、要件を最初から完璧に定義するのは難しいということです。ましてや、他人が作ろうとしているシステムなんて、解かろうはずがありません。

これを前提に置くと、初期費用0円というのは、線引が難しいですね。システム屋として勿論「最初の要件」なんでしょうけど、なんせアジャイルなので、「作ってみないとわからない」という核心的な部分で矛盾します。

百歩後退して「約9倍」のところが線だとして、さらに大きな問題があります。

例えば、スタートアップでのビジネス目的にシステムを作るとして、そのスタートアップは、99%失敗します。つまり、そのシステムは「残念システム」となるわけです。そうすると、折角手弁当で作ったシステムがレンタル費用を発生させた瞬間にお払い箱となる危険性が非常に高いという事です。

実際、システム開発プロジェクト的には大成功でも、ビジネス的には失敗というシステムは大量に発生していると思います。

今回の件は、そこまで行く前の状態のようですので、ビジネス的には99%側に入っているようです。

企業のシステム開発を覆う暗黒ロジック

ちょっと脱線しますが、そもそも企業のシステム開発ってどんなのなの?っていう話題です。

システム開発を行うというのは、人と時間を使って、プログラムを書き、サーバーを設定したりネットワーク機器を設定したりして、システムを使えるようにすることです。

企業にとってシステム開発とは、設備投資となります。

机や、ビル、車やコピー機と同じ扱いです。

投資というのは、リターン目的に行うものですが、システム開発においては、ハイリスク・ハイリターンとなります。

額も大きくなるので失敗すると一発で会社が傾いてしまうようなものも少なくありません。

反面、システム開発はプロフェッショナルの立場からしても難しく、誰もが簡単にできるという代物では決して無いのです。

システム開発を委託する側の企業にとってもこれは頭の痛い問題ですが、何度かの痛い経験から、ある程度の方法論を確立していることが多いです。これは、規模が大きくなればなるほど、言えることですが、大概は、最大限に官僚化し、ガチガチの仕様と予算を事前に用意することによって、なるべく失敗を回避しようとしていることが多いと思います。

対して、アジャイルですが、ソフトウェア開発の立場に身を置く自分の価値判断では、100%正しい(少なくともウォーターフォールよりは)ことが断言できます。しかし、大半の人の直感に反することを行う必要があります。(というか、ソフトウェア開発における"正しいこと"とは、常に人の直感の逆を行くような気がします)

これは、システム開発において非常に厄介な問題です。ウォーターフォールが、なんだかんだ今でも多くの企業にとってスタンダードとなっているのは、それは理屈上、直感に反しない素直なアプローチだからでしょう。

「事前に決めたことを計画通りに実行する」

なんの不自然さもありません。企業が、投資行動を行うのにこれほど相応しいものは無いように思えます。

そして、情シスの担当者が、システムを発注するにあたっても、最も責任が掛かりにくいやり方になります。事前に計画を立て、ユーザー部門とプロジェクトオーナーの承認を貰ってからスタートするのです。もし、計画が上手く行かず、プロジェクトが遅滞するようなことがあっても、それはSIが責務をまっとうしなかったことが原因なので、情シスの預かるところではありません。また、プロジェクトが計画通りに遂行されたとして、それが上手くビジネスに反映できず、思った通りの利益を生まなかったとしても、要求を上げたユーザー部門とプロジェクトオーナーの承認を受けてスタートしたことですので、自分たちに非がないことは明確です。

このロジックを突き崩す必要があります。

本来であれば、投資価値を最大限に高めるためには、責任の所在をはっきりさせることよりも、より成功しやすい手法を取るべきです。

しかし、アジャイルの持つ先進性は、万人に受け入れやすいとはとても言えないシロモノです。システム開発に身を置く人達の間でも、疑問に思う人が少なく無いと思います。ましてや、門外漢の経営陣に真に価値を理解させて、支持を取り付けると言うのは、絶望的でしょう。

中には先進的な経営者も居ますので、奇跡的に支持を受けることができたとします。そうなった場合でも、それを全社の共通認識として意識改革を行うのは、大規模な転換が必要になります。いくら社長がわーわー言ったところで、場合によっては数十年にわたって積み重ねてきたロジックの積層を破壊し、新たなる価値観を再構築するというのは、カルロス・ゴーン並みの経営改革手腕が必要となるわけです。

今の時代、先のような価値観では、その企業の存続自体危ぶまれますので、傍目にはドンドン革新していって欲しいと思いますが、実際問題は厳しいでしょう。