システム構築やっている人のほとんどは品質なんて興味ない件、あるいは良心に頼らないためには
★品質なんて知ったこっちゃない？
システムインテグレーター（SIer）の人々と話をしていると、システムの品質に興味がないんだなぁと思うことが多い。
いや、どこの大手SIerにも品質保証部みたいな部門があるし、品質保証のための厳格なプロセスがあって、しっかりした仕事をするようになっている。
でも、実際の所は、彼らが関心があるのは品質よりも「バグが多いか少ないか」だと思う。
色々な定義があると思うが、僕自身は「品質」と「精度」を使い分けている。
精度：システムが正しく動くか？
品質：システムが良いか？
「バグが多い、少ない」は品質というよりも、僕の定義では精度の問題だ。
品質とは、正しいか正しくないかというゼロイチの世界ではなく、良いか悪いかで語るものだ。
例えばソースを読みやすいかどうか。
例えば仕様書がソースを解読する助けになるか。
アーキテクチャがクールで変更に柔軟に対応できるかどうか。
処理件数が増えても簡単にスケールを増やせる作りになっているかどうか。
なるべく少ないロジック量でやりたいことを実現できているか。
などなど。
で、システム構築を請け負っているシステムインテグレーターの人々と話をしていて気になるのは、精度向上には実に熱心なのに、品質に全然関心ない人が多いってことだ。結構ちゃんとした大手の会社でも。
品質が悪いシステムの例を挙げてみよう。
同じロジックを関数にして呼び出すのではなく、幾つものプログラムにコピペしている。その関数を修正したくなったらどんだけ大変になるんですか・・。
そういえば消費税率が上がっただけで、大騒ぎしていたシステムもあったみたいですね。あんなのいつかは絶対上がるのに（昔は3%だったのが、上がったわけだし）。予め可変にしておいてよ、要望書に書かれていなかったとしても。
パッケージを使ったシステムをバージョンアップしようとしたけど、トリッキーな使い方過ぎて、構造を誰も理解していなかったし、解読もできなかったとか。
サーバーでやるべき処理をクライアントでやっていて、クソ遅いとか。
そもそも業務の目的とズレた機能を、猛烈な勢いで作りこんでいるとか。
前に記事にした、「組織コードを追加したいだけなのに、すごく複雑な手続きが必要」というのも品質が悪いことの一例だろう。
今まで見た一番酷いケースでは、非常に複雑な計算をするコアエンジンみたいなものが、1つのシステムに2つ実装されていた。それぞれが出した計算結果が合わなくて大騒ぎになったりしている。最初から1つにまとめておけばいいだけの話なのに・・。
別に1社だけが酷いという話ではない。あんな事例、こんな事例、どの会社も掘れば出てくる気がする。
逆に精度を高めるための努力は、やり過ぎかと思うくらい、やっている。事前にバグの件数を予測し、予測からズレたらなぜズレたかの理由を作文して・・とか。
コボルでひたすらプログラムを作る場合なら、1ステップあたりの想定バグ件数は予想できるのかもしれないし、それが予想とズレたら何か想定外のことが起きているので要調査、という理屈も分かる。でも初めて使うテクノロジー、初めて使うパッケージで同じ事やってもしょうがないでしょ・・。
★どうして精度にばかり熱心なのか？
大きな理由が3つあると思う。
1）測りやすいから
バグの件数は数えられる。週あたりの発生件数をグラフにすることもできるし、なんとなく収束していく様にも表現できる（得てして収束する様に見えるだけなんだけど）。
品質が数値化できないのとは対照的だ。
2）誰でも扱えるから
品質は、工数を突っ込めば上がるというものではない。スキルのある人が作って、スキルのある人がレビューをしなければ上がらない。そして誰がスキルがあるのか、ますます見えにくくなっている。
それに比べて、精度はコツコツとテストをすれば上がる。
特に大手の会社ほど、エンジニアをたくさんかき集めて「誰でもできるシステム開発」を目指さざるを得ない。もうちょっといい言葉を使えば、「能力に依存せず、プロセスで精度を担保する開発スタイル」を目指す。
だからプロセスをガチガチに縛る。テストの実行結果のスクリーンショットをとってエクセルに貼り付けて納品するとか。
3）請負契約と瑕疵担保責任のため
システムインテグレーターが精度に関心が高いのは、バグが出ると無償で直さないといけないからだろう。
バグが判明したら、たいていは責任の所在は明確だ。作った人が悪い。正しく動かないのだから、動くようになるまではいくら工数がかかっても、システムインテグレーター側に直す責任がある。納品出来るようになるまで。
そんなことになったら困るので、作っている最中も精度にはとても気を使う。
それに比べて、品質は高いか低いかが分かりにくい。システムが稼動して何年か経ってから、品質が低いことが分かるケースもある。スキルのある人じゃないのと作れないのと同様、スキルのある人じゃないと品質の良し悪しを判断できないことが多い。
だから多少品質に難があっても、納品できてしまう。つまり、お金がもらえてしまう。ぶっちゃけて言えば、だから品質に気を使わなくなる。買い叩かれて、そうでなくても赤字か黒字かギリギリのところで仕事をしているのだから、無理もない側面もある。品質を上げるなんて金にならない事に、工数を使う余裕が無いのだ。
もちろん、品質に大変気を使うシステムインテグレーターもあるだろう。会社と言うより、個々のエンジニアがちゃんとした人だった場合だと思うけど。
でも、それってあくまで、その人の良心とかスキル次第なんだよね。「商売としては品質に気を使う余裕はないけれど、エンジニアの矜持（プライド）として、良い品質のモノを作る」という。
あー、書いててブルーになってきた。
★システムの買手はどう自衛すべきか
言うまでもないことだが、システムの品質は大事だ。
バグだらけで動かないとか、間違った金額を出されても困るけれども、品質が低いのも相当こまる。本当は10年、20年と使っていくつもりで作ったシステムが、保守性が低くてすぐに使えなくなったら、経営へのインパクトは非常に大きい。
そこまでいかなくても、「システムが複雑になりすぎていて、ちょっとした改修でも影響調査のために何ヶ月もかかる」という状況はよく見る。
なのに、作り手であるシステムインテグレーターは品質への興味が低い。正確に言うと、請負契約の性質上、興味が低くならざるを得ない。本当に困ったものだ。
これという特効薬はないと思うが、一応対策を書いてみる。
どれも大前提は、性善説ではなく、「構造的にシステムの品質はないがしろにされがちなものである」と思って臨むことだ。
a)品質の良し悪しが分かる人が関与する
売り手であるシステムインテグレーターに品質の良し悪しの判断を丸投げするのは、前述の構造上、危険だ。なので、ソフトウェアの品質を語り、判断出来る第三者をプロジェクトに関与させた方がいい。
社内の情報システム部の様なところにそういうスキルを持った人がいるのが理想だが、いなければ連れてきた方がいい。
b)保守まで含めて依頼する
「納品をなくせばうまくいく ソフトウェア業界の常識を変えるビジネスモデル」という本で、顧問契約的に開発から保守までまるっと委託するモデルが紹介されている。「自分たちが保守をするので、ソフトウェアの品質にはこだわり、徹底的に社内レビューする。品質が低くて泣くのは自分たちだから」という理屈で、品質を下げないビジネスモデルだという。
僕はこのモデルの実例を見たことはないけれども、理屈は通っていると思う。「とりあえず検収印もらっちゃえば、あとは知ったこっちゃない」という既存のモデルよりも、ずっといい。
全ての案件で適用できないことや、品質が低くい場合でも最終的には顧客が負担すること、その会社への依存度が高くなりすぎるなど、完璧じゃないと思うけれども。
c)事前に、品質について議論する
最低限やっておきたいのは、発注前に品質についての考え方と取り組みを議論することだ。品質について聞いているのに、「バグの件数をどうやってトラッキングするか」みたいは話しか聞けなかったら、要注意。
「請負契約では、本質的に品質に目が行きにくい」という前提を共有した上で、それでも品質を高めるために何をしているか？を腹を割って話してくれるかどうか。
信頼できるシステムインテグレーターを探すのは、本当に大変だと思う。
※品質の構成要素に「信頼性」や「正確性」があり、これはこの記事における精度と近い。なので、その定義によれば精度は品質の一部となる。
そうだとしても、「品質の中で、信頼性や正確性にばかりに関心が高い」という意味で、ここで論じたことは問題だと思う。
定義がややこしくなるので、ここでは精度は品質の一部ではなく、別の概念という書き方をした。
※この手の話は「過去に品質の悪い仕事をしたことのない者だけが石を投げなさい」ということなので、自分を振り返るとブーメランになるわけだが。でも品質の良いモノを作ろう、というプライドは持ち続けたいし、構造的にそれを目指せる契約の仕方や発注者受注者の関係づくりも模索し続けたい。そう思って書きました。