システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について

「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。

まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価相当での処理になるので、実態はほぼ一括投資の処理が基本であることは間違いないですね。

んで、ではそもそもシステムの価値はどう認識されているのか？という問題は、一度ゆっくり考えた方がいいと思うので、自分の考えを残しておきます。ここがクリアにならないと、いくらマッチョに「そもそも人月単価という考え方が間違っておる」と主張したところで、なかなか現状は変わらないでしょう。

　来歴的には、システムの資産としての「会計上」の認識の問題は、社内の開発のR&Dの位置づけも含めて、右往左往はありました。（勿論、パッケージ等の販売や構築したシステムのデリバリーを主目的とした、ベンダーサイドの会計処理と、構築や導入を行うことを主とするユーザーサイドでは、処理の内容も基本的に異なります。が、とりあえずここでは、ユーザー・サイドでの通常の処理を前提にします。）
　とはいえ現状では、ユーザーサイドでは、システムの開発のコストの計上は、基本的には固定資産で計上します。途中で仮勘定をつかうとか、段階リリースだけど、途中から本番利用しちゃいますよ、どうします？という諸事はあって、いつから資産化・費用化するかは、微妙な問題はありますが、システム投資をCapitalizeするということについては、一定の合意はとれています。ブックされる価額も基本は投資として支出した金額をベースにします。取得原価の建て付けで処理されますね。
　
んで、問題はその資産性＝価値の妥当性はどの程度あるのか？という議論です。

会計技術的には、単純にクライテリアとして、資産計上の金額の決定と、償却期間の割当、および減損チェックというポイントになるわけで、テクニカルな話としてはそのレベルの話でしかないのが実態でしょう。ただし、建て付けとしては経済実態との乖離は（あまり）ない方が良いという前提は当然あります。本来的にはその実態はどうなのか？という議論は、特にユーザーサイドの情報システム部部長・予算編成担当者・経理・財務・担当役員間では、ある程度やっておかないと、まぁ後々もめるわけです。が、普通はやってないですね。

なぜなら、問題が最後は「システムの資産性＝役に立っておるか？何かに担保されておるのか？」というところに帰着してしまうこと多いからです。勿論表面上は、上記のように会計のテクニカルな要素に還元はされてしまうのですが、現実の泥臭い話になってしまうとなかなかに微妙です。

まともにシステムの資産価額について、そもそも論を議論すると最後は「払ったお金の分の価値はそのシステムには本当にあるのか？」という議論に必ず戻ってしまいます。ここは大抵、議論が収束しません。しかし、ここを考えない限り、システムの価値＝帳簿価額＝払った金額という表面的な話に終始することになり、払った金額＝結局人件費＝人月での評価、という議論に落ちてしまいます。

このあたりの議論の個人的な経験ですが、以下の話が多い。

・建て付けとしての「一般的なシステムの価値」
　まずは、そもそも価値があるのかないのか？という議論については、大人の議論では「システムは動いていれば勝ち」になります。無事これ名馬の理屈も一理あります。実際、中身はともかく、手堅いシステムで継続してかっちり動いていればそれは役には立っている（可能性が高い）と思われるわけです。「使われているのでいいでしょう。普通に動いているので、普通に処理すべきである。なにが悪い？」これは建前としては普通にある話です。
　システムが動いて、サービスを供している以上、企業活動には直接・間接に益しているわけで、その限りにおいて企業活動に有用であるということは説明しやすい。その上で、「価値？よくわからんが作るのにかかった費用でおいておけ。取得原価主義万歳。」とまぁこうなります。これが普通。

・中身はどうなのか？
　その一方で、大抵のSIでできたシステムのほとんどは、中身はボロボロであることが非常に多いという現実もあります。システム構築の現実は「とりあえず動かせ」が主目的になり、後回しにできるところは後に回して機能は制限して、メンテはあとで考える。当初の予定機能は削減して、その分は追加開発で乗り切る予定調和の流れが普通です。さらに、一歩間違うとその追加開発でさらに機能制限ということも多々あります。
　要は、それなりに動いている後ろは、特にソースレベルまで見ると「資産性？なんの話ですか？」という内容が大抵のケースです。勿論例外はありますが、それは本当に例外でしょう。
　また、ユーザーサイドにしても、システムの深いレベルまで確認することは割とレアケースです。実際のシステムの資産性を担保する「品質」ついての確認については、いいところブラックボックステストで精一杯なのが現実です。もっとも、そもそもシステムの品質はトータルなもので、目の前の成果物だけ見て判断できるものでもないですね。要するにユーザーサイドでは、資産性の担保の判定は、実際は中身に依存できていないのが現状です。

　さらにいうと、仮に実際に建て付け通りの資産価値がシステムにあるのであれば、システム自体を処分するマーケットの可能性やそもそもの流通性は多少はあるはずです。いろいろ試みはありましたが、残念ながらそのようなマーケットは未だに成立してません。これは本質的には品質担保ができないからでしょう。
　パッケージビジネスをやる側では常識ですが、SIでモノをつくるのと、商品としてモノとつくるのでは品質にかけるコストが3倍違う、というのが相場です。しかも大抵はハイコストのパッケージの方が機能数としては減っていることが普通です。それだけSIのシステムは「動かすこと」にウェイトをおいているというが現状です。とても転売できるほどの品質はなく、したがって市場もできません。すなわち、市場価額なるものがほとんどないですよ、という段階で「資産価値」といわれても普通にかなり怪しい。

・ソフトなのに実際はハード寿命ドリブンでシステムを更新する事が多い現実はどう見る？
　また、構築したシステムの構成原価は大抵の場合人件費です。残念ながら現状では、「人月」でコストが決定され、結果として、そのコストで資産として計上されます。要するにシステムの価値は、利用するハードウェアとはあまり関係ない。
　にもかかわらず、実際のシステムの事実上の耐用年数はハードウェアに依存します。大抵のシステムの更改は、ハードの寿命が来ましたので仕方が無く、というのが実態です。システム自体の価値がどのように劣化するか、という議論は基本的にないわけです。とどのつまりは、システムの資産性は単純な費用のdeferredでしかなく、portabilityやmarketabilityからはほど遠いというのが実態です。

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

つまり、システムの固定資産としての処理は、資産性とかそういう話ではなく、単純に出たお金の償却の繰り延べでしかないわけです。そして、おそらく、人月云々という話の根っこはここにあります。中身を見ないで、かかった金額の多寡という視点のみで見るのであれば、それは当然短絡的なコストの積み上げの議論に終始することになってしまいます。

・この状態で、「だがしかしシステムは投資であり資産性がある」という建前は成立するのか？
資産性は実はまったく評価していないという現実とは別に、しかし、残念ながら大人の事情として、この建前は維持しなければなりません。「資産性とかあんまりないのよね」なんて話が建前になると、んじゃー一気に減損せいや、という話もそれほどでたらめではないわけで。積み上げてきているものは一気の減損とかありえませんから、これはこれで困る。そもそも今までは何だったのか、という議論にしかなりません。そんなそもそも論と始めると、「そもそもシステムの資産性」ってのはなんだ？って話になります。

　実際まったく、そのとおりです。特にユーザーサイドにおけるシステムの資産性とはなんなのか？という点は、実は大抵は看過されています。勿論、それは前述のように「単純に会計上のテクニカルな問題に過ぎない」という言い方も可能ですし、現状では多分もっとも現実的な理由付けでしょう。要は大抵のシステムの資産性の議論は基本的に議論したくないし、仮にしたところで大人の事情が優先するので益がない、やるだけ無駄だ、というのが本音です。

しかし、問題は、「このままで本当にいいのか？」ということです。

・建前は別として、本音は押さえるべき
　ところが、ベテランの情報システム部部長や、ある程度の手練の業務系SI屋さんだと、「このシステムの相場は、こんなものだ」という経験から分かるコスト・適切な価値を基準としてもっています。「投資金額としては、この程度だし、実際その程度の価値はある」こういう言い方は実は普通にあります。
　作ったときはそれなりに最新でしたが、時代の変化や利用することで粗が見えてきて、また新技術との比較劣化もあり、まぁ資産性も下がるわね、ということも普通の感覚としてあります。

つまりですね、「システムの価値」っていうものは、現場感覚的には普通にあるわけです。

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

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

このための価値基準は個々人によって見方は違いますので、諸説様々です。
自分の判断基準は以下です。

1.サポートすべき例外処理の網羅性
システムの「深さ」は一義的に例外処理に依存します。特に、業務系例外はシステム例外ではなく、システム的には正常処理に属します。可能な限り無視することでシステムは軽くなりますが、それでは使いものにならない度合いが増えます。丁寧に業務例外を拾う仕組みほど、人が関わる度合いは減り業務効率性はあがります。適切な業務例外を拾っているほど、システムの価値は高い。

2.処理すべきデータサイズ
処理するデータサイズの規模が大きくなるつれて、システムはそのアーキテクチャを変えていきます。一般には取り扱うデータサイズの桁が変わると仕組みに手を入れる必要がある、といわれていますが、個人的には5倍程度で、もう違う仕組みがいるだろうとは思います（例外はもちろんあります）。また、大きなデータサイズをハンドルするにつれて、できることが増加するのも事実です。その意味ではシステム自体に内在する価値の評価基準として、処理できるデータサイズ、というのは基準としてあるでしょう。

3.関わる人間への影響の度合い
所詮、どう頑張ろうと一人用の専用の仕組みは価値が低い（これは個人の意見です）。もちろん少数のトップ向けの仕組みとして非常に重要である、というシステムもあります。またその特定個人のミッションの企業に与える影響度が大きい場合は、そのサポートシステムは非常に重要な、したがって価値ある仕組みになりえます。ただし、これらはあくまで例外で、一般には企業組織の業務全体への影響度が深い仕組みほど、その企業の企業活動に必要不可欠なものになります。もちろん、たとえ関わる人間が多数でも、影響度合いが低いのであればその仕組みには、高い価値はおけないでしょう。むしろ、深いレベルで多くの人間に結果として影響が出てしまう仕組みは、企業のコアコンピタンスを支えるインフラとして、高い価値を置くべきです。

4.システムのポータビリティ
ポータビリティの高いシステムほど、資産性は高いです。つまり、コードベースは少ないほど価値が高い。（コードベースの大きさと機能の充実度は比例しません。）やたらめったら、コード量がおおいデスマ的なSIのアウトプットは、移植性が低く、メンテナンスコストがやたら高いですね。その意味で価値は低い。率直に言ってもはや減損検討対象でしょう。ここはつまり、人月がかかれば、かかるほど価値が下がる傾向になる、ということです。逆に、少ないコードや小さなシステムサイズで、相当の機能をこなすシステムは価値が高い。

5.ユーザーから見たときに代替できるリソースの多寡
現実論として、システムを導入したからといって人員を削減できるわけではないですし、往々にしてむしろ人件費が増えることすらあります。しかし、システムが動かなくなると確実に代替するリソースとして、人員が必要になることが多いのが現実です。仮にシステムが落ちたときに、一時的に人手やそのほかの資源で、システムの代替をする必要が発生する場合、その費消されるリソースの多寡は、システムの価値の判断材料としては有用だと思います。

ほかにもいろいろありますが、個人的にはこの辺はいつも頭に置いています。念のためですが、以上は個人の意見です。とはいえ、要は「作った人間の単純な多寡」は価値とは関係ないないないない、というのが、自分の意見です。

これらの価値基準をユーザーやベンダーはそれぞれ各自に持つべきです。このようなクライテリアは基本的に主観的なもので、それぞれの各自のキャリア・経験・実務に依存します。たしかに定量化はしにくいものですが、それなりに根拠があるものが多いと思います。逆に言うと、このような経験的な知識がない人間ほど、人月のような「いかにも客観的に見える基準」に頼る傾向があります。本来的にはそのような人はシステムの価額・価値判断を下すべき立場にいるべきではないですね。

むろん、人月工数も基準に一つにはなるでしょう。ただしそれは本筋ではありません。より様々なロジックで積み上げられた判断基準に勝る価値判断は、システムにおいては存在しません。これは、システムとはそもそもどうあるべきか、ということが根っこにあり、そのような議論が具体的に必要だ、ということです。

残念ながら、現実が事ここに至らない理由の一つは、ベンダー・ユーザー両者の業務・システムに対する理解度、率直に申し上げれば、「基本的知識」の度合いが足らなさすぎることもあります。
　ベンダー様においては、そもそも業務知識以前に、まず社会的な一般常識もないことがおおい。世の中の発注処理・受注処理・在庫処理・人事給与処理・会計処理・などなどなど、「普通に考えると世の中こうですね」という知識がない上に、加えてユーザーさんのドメインの知識がどうしても不十分になってしまっています。人力商売になっているので、効率よりも稼働率優先で人のアサインとかやるので、やる人の業務知識が少ない上に、そもそも技術習得が放置プレイで、これで「適切なシステムの価値」なんて考えろ、という方が無理。
　ユーザー様におかれましても、少なくとも多少はシステムの中身をわかろうとする人間を優先して、しかるべき役職にあてるか、ちゃんと人員を調達すべきだと思います。さすがに、商品調達部門の部長が横滑りで情報システム部に来た上に、「ウチの方針は、「同じ品質なら、安い方！同じ値段なら、品質のよい方！」であーる」というRFPなんかどーんと出ると、これは厳しい。

とはいえ、クラウド化はこのような見直しには良い契機

特にクラウド時代になってくると、「システム」とハードウェアの分離が進みます。確実にポータビリティはあがりますからね。そうなってきたときのシステムの投資可搬性に値する、「システムの価値」はそもそも、どういうものか？という議論は避けられないでしょう。「そもそも、そのシステムは、どれだけの意味があるのか？」これはユーザーさんもベンダーさんも、胸襟を開いて話し合うべきことだと思います。

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

・・・と言いつつも、システムの見積もりを見るたび、ユーザーサイドから見るとこれは高いよね、と同時に、作る側から見るとこれは安いよね、とか思ったりして、自分自身で格闘しているのが毎日ではありますが。そんな感じでごわす。とほほほほほほ。