SI業界のコードが洗練されない経済学的理由
ペアプログラミングや勉強会など、洗練された綺麗なコードを目指すための取り組みはWeb系業界から多く聞くように感じます。
一方でSI業界はマネジメント関係への取り組みが多く、コーディング技術の向上にはあまり興味が無いようにも感じます。
SI業界はコードを洗練させる必要がないのでしょうか。
最近そういったことをよく考えるのですが、その中で以下の考えが芽生えてきました。
多くのSIにおいては、開発と保守が分かれている。
それゆえコードの品質が"外部化"され、"外部不経済"に陥る。
これについてまとめてみます。
"外部不経済"とは何か
例としてよく「公害」のケースが挙げられます。
例えば、工場の汚水排出問題を考えましょう。
工場が取れる選択肢は以下の２つであるとします。
1. 何も考えず汚水を垂れ流す
この場合、周辺住民が健康を害し、全部で1億円分の経済学的損失に繋がるとします。
「周辺住民の不幸分を金額で表すと1億円ぐらい」って感じですね。
「損害賠償として1億円貰わないと納得しない」と考えてもいいと思います。
2. 汚水浄化マシーンを買う
これで無事公害を防げます。
その代わり汚水浄化マシーンは1000万円します。
周辺に工場関係者しか住んでいなかったとしたら
つまり、公害の被害を全て工場が食らうとしたらです。
この場合、工場の損失は
1. （浄化しない場合）1億円
2. （浄化する場合） 1000万円
です。
当然工場は2を選びますよね。
周辺に工場関係者が住んでなかったとしたら
経済学ではこの場合、「公害のコストが外部化されている」と表現します。
つまり、公害の損害なんて工場にとっては関係ないということですね。
兵藤会長の言葉を借りれば、「彼は痛いが…わしは痛まない…！」です。
なので、工場の損失は
1. （浄化しない場合）0円
2. （浄化する場合） 1000万円
と考えます。
何も罰がないのなら、工場は1を選ぶというものです。
（実際には「信用を失う」などの損失もありそうですが。）
問題点
さて、ここまでの問題を国の立場で考え直してみましょう。
国は基本的に、「皆の幸せ値の合計が一番高ければいいな（不幸値の合計が一番低ければいいな）」と思っています。
皆の不幸値の合計はこうなります。
1. （浄化しない場合）地域住民 1億円 ＋ 工場 0円 ＝ 1億円
2. （浄化する場合） 地域住民 0円 ＋ 工場 1000万円 ＝ 1000万円
つまり2の方が望ましいわけです。
しかし、先ほどの後者のケースでは1になってしまいました。
この状況が「不経済」です。
つまり、皆の不幸値がより高くなってしまった状況です。
不経済の原因は「コストが外部化されている」ことでした。
なのでこの状況を「外部不経済」と呼ぶわけです。
解決法
実際には外部に損害をもたらした人には罰が与えられます。
国は「汚水を流したら1億円罰金！」と規制をかけておけばいいのです。
そうすれば、工場の損失は
1. （浄化しない場合）1億円
2. （浄化する場合） 1000万円
となり、工場は2を選びます。
これを「公害のコストを内部化した」と表現します。
1億円の損失を、罰金という形で工場も計算しなければいけなくなったということですね。
SI業界の"外部不経済"
前置きが長くなりましたが、本題です。
簡単に言ってしまえば、「コードの洗練」が先程の例で言う「汚水浄化」にあたると思っています。
「開発」が「工場」、「保守」が「周辺住民」です。
具体例で行ってみましょう。
SI会社は以下の内どちらかの選択肢を選べるものとします。
1. 汚いコードでさっさと納品する
初期開発費用として1000万円の人件費がかかります。
年に1回の機能追加／改修の際には毎回500万円かかります。
2. 綺麗なコードで丁寧に作り込んで納品する
初期開発費用として1500万円の人件費がかかります。
年に1回の機能追加／改修の際には毎回200万円かかります。
システムを5年は使い続けるものだとします。
前提として、汚いコードでもテストはちゃんとやっており、バグは直してるものとして下さい。
あくまでもコードの綺麗さはメンテナンス性のために目指すものとしています。
開発と保守をセットで行える場合
1. （汚いコード） 5年で総費用3500万円
2. （綺麗なコード）5年で総費用2500万円
当然2を選びます。
保守は他がやってくれる場合
1. （汚いコード） 初期開発費用1000万
2. （綺麗なコード）初期開発費用1500万
これは1を選びますよね。
企業は基本的に自分のビジネスが最優先です。
保守が苦しむことになろうと、自分たちに関係が無いのならばお金を出して助けようとは思いません。
結果としてこれは、周辺住民と工場の関係と同じになります。
実際には、開発が保守を完全にやらないというケースは稀だと思います。
しかし、「次の機能追加を自分たちがやるとは限らない」という雰囲気が強まるほど、この問題は立ち現れるでしょう。
「このシステムは自分たちが長く作っていくものだ」という認識がなければ、綺麗なコードを目指そうという動機が生まれない。
ここがWeb系業界との差だと考えています。
エンドユーザーの視点
エンドユーザーとしては、トータルで安く買いたいはずです。
しかし今回の例のように「次の機能追加が200万円で済む」などと事前に分かることは、実際はほとんど無さそうです。
そうするとエンドユーザーができることは結局、初期開発の見積が一番安いところを選ぶことだけではないでしょうか。
こうなると勝つのは汚いコードを書く会社ですよね。
これもSI業界が綺麗なコードをなかなか目指すことが出来ない理由だと思います。
そもそもの問題は、エンドユーザーがコードの汚さを測れないところにあります。
公害の例で言えば、国は川の汚染状況を測ることができるため、対策を打つことができました。
エンドユーザーはこれができません。
コードの海は知らない内にどんどん汚染されていくのです。
保守費用がいくら膨れ上がっても、「機能追加ってやけにお金がかかるものなんだなぁ」と感じるだけではないでしょうか。
解決法１
エンドユーザーが打てる手としては、まずはSI会社にとっての保守費用を内部化させることです。
つまり、「このシステムはずっと御社に任せたい。」と表明するような体制です。
１エンジニアとして思うのですが、自分たちで作ったシステムを他社にメンテナンスされたり、他社が作ったシステムを自分たちで弄ったりすることは苦労が多いです。
どこの会社が作ったかも分からない汚染物質だらけのコードの海を任されて、一から洗浄する時間も与えられず、せめて海からなるべく早く帰ってくることを目指すしかない。
そのためには、自分たちも海を汚していくしかない。
というかこんだけ汚れてたら今更どれだけ汚しても変わらないよね……。
こうしてエンジニアとしての清らかな精神も、汚染物質にすっかりやられてしまいます。
こんな悲劇を避けて、お互い幸せになりたいところです。
しかし、これはエンドユーザーとSI会社の間に深い信頼がないとできないかもしれませんね。
初期開発に時間をかけるのは後の保守効率のためであること。そのためトータルでは安く済むこと。
このへんを話し合って認識を共有しておく必要があります。
また、この体制では保守時の見積額に競争原理が働かなくなってしまいます。
つまりSI会社は保守金額を無駄に釣り上げることもできるということです。
そこに関しても信頼関係や、事前の深い話し合いが必要かと思います。
解決法２
もう一つの作戦として、エンドユーザーがコードの汚さを測ればいいんじゃないかと私は考えています。
実際にはエンドユーザー自身が測るのではなく、第三者によるコード品質監査サービスを利用する形で考えています。
（そういうサービス、あるんでしょうかね？
もしも無いとしたら、これはビジネスチャンスなんじゃないかとも思います。）
コードの汚さが数値化できれば話は早いです。
コードの汚さが一定以下であることを要件に入れてもいいですし、コードの汚さに応じて払う金額が変わるような契約を結んでもいいんじゃないかと思います。
いずれにせよ、これでSI会社側には時間とお金をかけてでもコードを洗練させる理由が生まれます。
まとめ
というわけで、「SI業界はコードを洗練させる必要がないのか」という問いに対しては、「現状ではそうなってしまう」というのが私の考えです。
もちろんバグの発生を抑えるようなコードの洗練は必要だと思いますが、一定レベル以上の洗練はメンテナンス性の向上が主目的だと思っているので、そこから必要なくなってくると考えています。
エンドユーザーからの打開策も考えてみましたが、いずれも「エンドユーザーがコードの汚さを後の損害（いわゆる"技術的負債"）と認識できること」が前提です。
エンドユーザーとSIが今よりもっと深く話し合わないと難しそうな気がします。
何より、今のSI業界はコードを洗練させない方向でそのまま戦略を最適化しようとしてるように思えます。
綺麗なコードを書ける高い人より、汚いコードしか書けない安い人を使う。
優秀な人は下流ではなく上流で使う。
オフショア開発の流れなどはその典型的な表れですね。
ここまで自分の考えをまとめてみましたが、推測が多分に含まれています（特にエンドユーザーとSI会社がどういった契約の結び方をしているのかとか）。
何か認識に誤りがあればコメントで指摘して頂けると幸いです。
おまけ：レモン市場
今回は「外部不経済」というキーワードで分析してみましたが、「質の悪いものを納品されてもエンドユーザーは分からない」という点で言えば、経済学で言う"レモン市場"の状況にも当てはまりそうです。
前述の解決法２はこれへの対処法とも言えそうです。
では、このへんで。
