「システムの価値」とは「そのシステムで何人食えるか」である

タイトルは釣りですと言いたいけど微妙に現実な話。

システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
Asakusaの中の人のこの手の話はいつも考えさせられます。僕は作る側の人ですから、「システムを作ることが会社に利益をもたらす」ことを意識しなければなりません。ここで言う会社はクライアントではなく自社ですね。
当然ですが、クライアントが満足しないと長い目で見て利益につながりません。ではクライアントは何を求めているか。ここが難しいところです。
なんどか述べたように、システム化の目的はいくつかあります。しかしシステム開発案件の目的は更にたくさんあります。

  • 人間がやると非効率な業務の電算化(本来のシステム化その1)…全口座の利率計算など
  • 人間の手では難しい処理の実現(本来のシステム化その2)…顧客の動向分析など
  • システム運用自体の効率化
  • 古くなったシステムのメンテナンス
  • 古くなったシステムの更改(廃棄)

等々。業務インパクトのある(=費用対効果が図りやすい)開発は1番めですが、よっぽどのことがない限りすでに何らかの手段で実現済なものです。なので、話としてはリプレイス案件になってしまい、効果が見極めにくいことが多いです。2番めにしても同様で、元々無かったものを作ったことによって期待される効果が事前に見極められることはめったにありません。
実際のところ3番めが一番なんとかできそうな気がするんですが、これが一番難しかったりします。というのも、システム運用・メンテナンスはシステムが巨大になればなるほど削減を図った時の効果が大きい=リストラ必至という問題があるからです。大企業になると、メンテナンスをアウトソースするのが子会社であることによって、連結ベースで業績が落ちたりしますwもちろん、トータルコストとして下がったほうが全体としてはよろしいのですが、往々にしてシステム運用会社は元々は母体の偉い人で「俺の目の黒いうちはやり方を変えさせねえ」とギラギラしていたりしますので、なかなかうまく行かなかったりしますw

そんな話は特殊なケースであるとして。

・でも一応、ROIが向上したとか、実際にシステム投資で効果が目に見えて上がったという話もある?
ま、それはあると思いますが、現実的には例外です。大抵のシステム投資の効果は計測できないのが実態です。システムを導入したからといって、そのまま人件費の削減になることもないですし、またシステムを構築・更新したからといって、自動的に売上があがるわけではありません。システムは使い手により、アウトプットがいくらでも変わります。仮になんらかの業務効率があがったとして、その収益ドライバーのほとんどは業務に携わる人の努力の賜であり、それをもってシステム投資のリターンと見なすことは、荒唐無稽というよりも一種の確信犯的な自己欺瞞でしかないです。

システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

まあこれはちょっと悲観的かなーと思ったりはします。
巨大な企業になると、例えば申込の打ち込み業務で1000人パートのおばちゃんがいるとかいう世界もあります。1枚あたり100打鍵かかるものが新システムで80打鍵で済むようになると、200人の人員が削減できるという目に見える成果が出る場合もあるんですよね。そういう意味で、フロントエンドのシステムはかなり詰められます。
バックエンドはどうか。バッチ処理が2時間から10分になった!早い!…でもどうせ朝までシステムは稼働しません、という場合はあるでしょう。でも、1日が2時間になったらデータ提供が1日早まってそれによって顧客を獲得できた、という話はあります。むしろ客に「あっちの会社なら1日かからないんだけど、移っちゃおうかな〜」って脅されてシステムが出来たりもしますw
目的・目標が明確なら、システムの投資効果は計測可能です。投資効果が評価できないことが多いのは、当初に目標がきちんと設定されていないということもありますが、設計完了時に目標が再評価されていないのが最大の要因じゃないかなーと思います。大抵の場合、「意外と費用がかさむ」ことから多分に当初は(経営にハンコを押させるための)建前として設定された目標がそのままでは達成困難であることから目を背けたいというのが理由なんじゃないでしょうか。
で、後から必死に効果をひねり出すわけですね。そうすると「満足度」などの非常に抽象的な目標にすり替わります。そりゃ計測できるものにはなりませんよ。

とはいえ、システム化による効果ってのはそんなに一義的なものだけではありませんから、なかなか難しいですね。

この感覚はシステム携わっている、それなりのユーザーであれば、確実にあります。また同時に、経験の豊富なしっかりしたプロのSI屋さんには、同じく確実にあります。本来であれば、この感覚をベースにして資産として評価・計上・管理して行くの方法が筋でしょう。ただし、この感覚的なものは、どこまで行っても主観的なものでしかないですし、100歩譲って間主観性はあるとしても、客観性はゼロです。ということで、なかなかまともな議論にならないのが普通です。

システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

この話はよくわかります。厳密に見積もらなくてもこのくらいのシステムだったら「こんなものだよな」という感覚はあります。難しいのは、その「こんなもの」というのが手法によって大きく変わることについて、明確な説明をつけることが難しかったりすることです。ホストの感覚で金額提示され、え、こんなに貰っていいの?と思うこともあれば、それオープンでやるとかえって大変ですよということに予算がつかなかったりします。ええ。そういった細かいズレが最終的にはでかい亀裂になってきたりもするのでシステム開発の感覚ってのは難しいものです。
新技術を導入するとどうしても「劇的に変わる何か」が求められちゃったりもします。そういう意味では「新しくこれができるようになります」というのは常に厳しいです。システム屋の最後のフロンティアはウェブ対応だったんだろうなあと思うとこれから先の付加価値創出には苦労しそうです(なのでみんなビッグデータだなんだと言っているわけで)。
話がだいぶずれました。

本来的には、ユーザーとベンダーの価格交渉は、この感覚のすりあわせであるべきです。それぞれのユーザー毎に、適切な必要かつ十分な規模と機能を備えたシステムで、身の丈にあった仕組み、またそれを適切な原価・人員・納期・間接コストで作り上げたとした時の金額は、実現可能性はともかくとして、あるべき原価または価額としてはあるはずです。これを丁寧に議論して、評価されるべき資産としてシステムを管理・維持していくのはユーザーの責務ですし、また適切なコストで構築を行うことが本来のSI屋のロールでしょう。

システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

この先に書かれているシステムの「レベル」を決めるであろう様々な要素の部分も含め「適切なコスト」というのが大変重要なんですけど、「適切」を突き詰めていくと、最後は結局人月に帰結する、というのがこのSIという仕事の面倒なところです。
提案の時に「松・竹・梅」で提案したりもするんだけど、それぞれに違いがわかってもらえなくて安いのを選ばれた挙句、あとからなんでできないの的な話をされたりします。

とは言え、適切(安すぎないのも大事)な価格を提示することは重要です。提案で選ばれなかったときに後から「やっぱりおたくの言っていたことは正しかった。安かったから他社にしたけど本当にやりたいことが上手く行かなかった」と言われることもあったりします。

ベンダー様においては、そもそも業務知識以前に、まず社会的な一般常識もないことがおおい。世の中の発注処理・受注処理・在庫処理・人事給与処理・会計処理・などなどなど、「普通に考えると世の中こうですね」という知識がない上に、加えてユーザーさんのドメインの知識がどうしても不十分になってしまっています。人力商売になっているので、効率よりも稼働率優先で人のアサインとかやるので、やる人の業務知識が少ない上に、そもそも技術習得が放置プレイで、これで「適切なシステムの価値」なんて考えろ、という方が無理。

システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

これは厳しい話です。開発側にいていつも思うのは、「普通に考えると世の中こうですね」ということについてあまりに無頓着な人が多いってこと。一般的な開発であれば、基本設計レベルの間違いはSTで、詳細設計レベルの間違いはITで検出されたりしますけれども、それ以前の問題として「どうしてそんな設計ミスをするの?」というレベルの間違いがあって、それは「世の中こう」というところから考えないのが原因だったりします。日本式の開発であれば、ローレベルの開発者であってもこれを意識しないとどうにもならないと個人的には思っていますが、それが本当にいいことなのかな。このことは常に考えています。

ユーザー様におかれましても、少なくとも多少はシステムの中身をわかろうとする人間を優先して、しかるべき役職にあてるか、ちゃんと人員を調達すべきだと思います。さすがに、商品調達部門の部長が横滑りで情報システム部に来た上に、「ウチの方針は、「同じ品質なら、安い方!同じ値段なら、品質のよい方!」であーる」というRFPなんかどーんと出ると、これは厳しい。

システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

こちらも厳しい。ぶっちゃけ偉い人は「結果的に同じ物ができるならどこでも一緒」と思っている場合が多いと思います。実際には付け焼刃でない技術、業務知識を持っているということを判断するのは難しいです。RFPに対する提案なんてRFPがよくできていればいるほど横並びに近くなるわけですから、単純に数字で判断すると大変なことになりかねません。一見同じような提案でもその数字の拠り所が違うから違う数字が出てくるわけで、その拠り所の適切さこそが評価すべき点なんですよね。しかし、それなりにきちんとしたシステム部があってなんとか、という話でもあります。

その意味では、今のシステムのクラウド化という機会は、システムの価値とは本来何によって測定・評価・メンテナンスするべきか?という考え方を整理するよい契機だと思います。ユーザーさんにおいても、ベンダーさんにおいても、どれだけの価値をそのシステムにおくべきか?ということは、そもそも大本になるはずです。そのあたりからエンジニアリングの価値といったものへの新しい見方が生まれる気もします。

システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

そうですね。今はシステムが次第に「カスタマイズ済パッケージ」に近づいていっている過程なのかな、とも思います。機能性に対する単価がシステムの価格に繋がってくる世界では、それを何人で作ったかは関係ないということになるでしょう。ていうかなってほしい。世の中の効率化をはかるための仕事が非効率であればあるほど利益になるようないびつな構造は早く終わりになってほしいものです。