オルタナティブ・ブログ > プロジェクトマジック >

あるいはファシリテーションが得意なコンサルタントによるノウハウとか失敗とか教訓とか

システム構築やっている人のほとんどは品質なんて興味ない件、あるいは良心に頼らないためには

»

★品質なんて知ったこっちゃない?
システムインテグレーター(SIer)の人々と話をしていると、システムの品質に興味がないんだなぁと思うことが多い。
いや、どこの大手SIerにも品質保証部みたいな部門があるし、品質保証のための厳格なプロセスがあって、しっかりした仕事をするようになっている。
でも、実際の所は、彼らが関心があるのは品質よりも「バグが多いか少ないか」だと思う。


色々な定義があると思うが、僕自身は「品質」と「精度」を使い分けている。

精度:システムが正しく動くか?
品質:システムが良いか?

「バグが多い、少ない」は品質というよりも、僕の定義では精度の問題だ。
品質とは、正しいか正しくないかというゼロイチの世界ではなく、良いか悪いかで語るものだ。
例えばソースを読みやすいかどうか。
例えば仕様書がソースを解読する助けになるか。
アーキテクチャがクールで変更に柔軟に対応できるかどうか。
処理件数が増えても簡単にスケールを増やせる作りになっているかどうか。
なるべく少ないロジック量でやりたいことを実現できているか。
などなど。



で、システム構築を請け負っているシステムインテグレーターの人々と話をしていて気になるのは、精度向上には実に熱心なのに、品質に全然関心ない人が多いってことだ。結構ちゃんとした大手の会社でも。


品質が悪いシステムの例を挙げてみよう。
同じロジックを関数にして呼び出すのではなく、幾つものプログラムにコピペしている。その関数を修正したくなったらどんだけ大変になるんですか・・。
そういえば消費税率が上がっただけで、大騒ぎしていたシステムもあったみたいですね。あんなのいつかは絶対上がるのに(昔は3%だったのが、上がったわけだし)。予め可変にしておいてよ、要望書に書かれていなかったとしても。
パッケージを使ったシステムをバージョンアップしようとしたけど、トリッキーな使い方過ぎて、構造を誰も理解していなかったし、解読もできなかったとか。
サーバーでやるべき処理をクライアントでやっていて、クソ遅いとか。
そもそも業務の目的とズレた機能を、猛烈な勢いで作りこんでいるとか。

前に記事にした、「組織コードを追加したいだけなのに、すごく複雑な手続きが必要」というのも品質が悪いことの一例だろう。

今まで見た一番酷いケースでは、非常に複雑な計算をするコアエンジンみたいなものが、1つのシステムに2つ実装されていた。それぞれが出した計算結果が合わなくて大騒ぎになったりしている。最初から1つにまとめておけばいいだけの話なのに・・。


別に1社だけが酷いという話ではない。あんな事例、こんな事例、どの会社も掘れば出てくる気がする。


逆に精度を高めるための努力は、やり過ぎかと思うくらい、やっている。事前にバグの件数を予測し、予測からズレたらなぜズレたかの理由を作文して・・とか。
コボルでひたすらプログラムを作る場合なら、1ステップあたりの想定バグ件数は予想できるのかもしれないし、それが予想とズレたら何か想定外のことが起きているので要調査、という理屈も分かる。でも初めて使うテクノロジー、初めて使うパッケージで同じ事やってもしょうがないでしょ・・。



★どうして精度にばかり熱心なのか?
大きな理由が3つあると思う。

1)測りやすいから
バグの件数は数えられる。週あたりの発生件数をグラフにすることもできるし、なんとなく収束していく様にも表現できる(得てして収束する様に見えるだけなんだけど)。
品質が数値化できないのとは対照的だ。


2)誰でも扱えるから
品質は、工数を突っ込めば上がるというものではない。スキルのある人が作って、スキルのある人がレビューをしなければ上がらない。そして誰がスキルがあるのか、ますます見えにくくなっている。

それに比べて、精度はコツコツとテストをすれば上がる。
特に大手の会社ほど、エンジニアをたくさんかき集めて「誰でもできるシステム開発」を目指さざるを得ない。もうちょっといい言葉を使えば、「能力に依存せず、プロセスで精度を担保する開発スタイル」を目指す。
だからプロセスをガチガチに縛る。テストの実行結果のスクリーンショットをとってエクセルに貼り付けて納品するとか。


3)請負契約と瑕疵担保責任のため
システムインテグレーターが精度に関心が高いのは、バグが出ると無償で直さないといけないからだろう。
バグが判明したら、たいていは責任の所在は明確だ。作った人が悪い。正しく動かないのだから、動くようになるまではいくら工数がかかっても、システムインテグレーター側に直す責任がある。納品出来るようになるまで。
そんなことになったら困るので、作っている最中も精度にはとても気を使う。

それに比べて、品質は高いか低いかが分かりにくい。システムが稼動して何年か経ってから、品質が低いことが分かるケースもある。スキルのある人じゃないのと作れないのと同様、スキルのある人じゃないと品質の良し悪しを判断できないことが多い。

だから多少品質に難があっても、納品できてしまう。つまり、お金がもらえてしまう。ぶっちゃけて言えば、だから品質に気を使わなくなる。買い叩かれて、そうでなくても赤字か黒字かギリギリのところで仕事をしているのだから、無理もない側面もある。品質を上げるなんて金にならない事に、工数を使う余裕が無いのだ。

もちろん、品質に大変気を使うシステムインテグレーターもあるだろう。会社と言うより、個々のエンジニアがちゃんとした人だった場合だと思うけど。
でも、それってあくまで、その人の良心とかスキル次第なんだよね。「商売としては品質に気を使う余裕はないけれど、エンジニアの矜持(プライド)として、良い品質のモノを作る」という。

あー、書いててブルーになってきた。



★システムの買手はどう自衛すべきか

言うまでもないことだが、システムの品質は大事だ。
バグだらけで動かないとか、間違った金額を出されても困るけれども、品質が低いのも相当こまる。本当は10年、20年と使っていくつもりで作ったシステムが、保守性が低くてすぐに使えなくなったら、経営へのインパクトは非常に大きい。
そこまでいかなくても、「システムが複雑になりすぎていて、ちょっとした改修でも影響調査のために何ヶ月もかかる」という状況はよく見る。


なのに、作り手であるシステムインテグレーターは品質への興味が低い。正確に言うと、請負契約の性質上、興味が低くならざるを得ない。本当に困ったものだ。
これという特効薬はないと思うが、一応対策を書いてみる。
どれも大前提は、性善説ではなく、「構造的にシステムの品質はないがしろにされがちなものである」と思って臨むことだ。


a)品質の良し悪しが分かる人が関与する
売り手であるシステムインテグレーターに品質の良し悪しの判断を丸投げするのは、前述の構造上、危険だ。なので、ソフトウェアの品質を語り、判断出来る第三者をプロジェクトに関与させた方がいい。
社内の情報システム部の様なところにそういうスキルを持った人がいるのが理想だが、いなければ連れてきた方がいい。


b)保守まで含めて依頼する
「納品をなくせばうまくいく ソフトウェア業界の常識を変えるビジネスモデル」という本で、顧問契約的に開発から保守までまるっと委託するモデルが紹介されている。「自分たちが保守をするので、ソフトウェアの品質にはこだわり、徹底的に社内レビューする。品質が低くて泣くのは自分たちだから」という理屈で、品質を下げないビジネスモデルだという。

僕はこのモデルの実例を見たことはないけれども、理屈は通っていると思う。「とりあえず検収印もらっちゃえば、あとは知ったこっちゃない」という既存のモデルよりも、ずっといい。
全ての案件で適用できないことや、品質が低くい場合でも最終的には顧客が負担すること、その会社への依存度が高くなりすぎるなど、完璧じゃないと思うけれども。


c)事前に、品質について議論する
最低限やっておきたいのは、発注前に品質についての考え方と取り組みを議論することだ。品質について聞いているのに、「バグの件数をどうやってトラッキングするか」みたいは話しか聞けなかったら、要注意。

「請負契約では、本質的に品質に目が行きにくい」という前提を共有した上で、それでも品質を高めるために何をしているか?を腹を割って話してくれるかどうか。


信頼できるシステムインテグレーターを探すのは、本当に大変だと思う。




※品質の構成要素に「信頼性」や「正確性」があり、これはこの記事における精度と近い。なので、その定義によれば精度は品質の一部となる。
そうだとしても、「品質の中で、信頼性や正確性にばかりに関心が高い」という意味で、ここで論じたことは問題だと思う。
定義がややこしくなるので、ここでは精度は品質の一部ではなく、別の概念という書き方をした。

※この手の話は「過去に品質の悪い仕事をしたことのない者だけが石を投げなさい」ということなので、自分を振り返るとブーメランになるわけだが。でも品質の良いモノを作ろう、というプライドは持ち続けたいし、構造的にそれを目指せる契約の仕方や発注者受注者の関係づくりも模索し続けたい。そう思って書きました。

Comment(2)

コメント

ardbeg32

えーっと・・・・
1)社内の情報システム部の様なところは品質の取りまとめで社内を敵に大立ち回りしてるか白でも黒と言わされてしょんぼりしてるかの2択なので、PMOみたく丸っきりPJとは関係ない所の人に品質の査定をしてもらうべきかと
2)保守まで含めて依頼して欲しいのはむしろベンダー側で、保守はタダと思ってる依頼主に対して社内情シスがどこまで抵抗できるか?の問題かと。まあ年間保守費を払わないでスポット保守でソースや仕様書を何年も管理しろってのがどれだけ無茶ぶりかってのは依頼主には100万年たっても理解できないことだとは思いますが
3)せっかくパッケージを買っても、使う側があちこちでローカルルールで勝手な使い方したりデータをエクスポートしてアクセスで加工したりそのアクセス作った人が退職したらもう何が何やらわからなくなったりとにっちもさっちも行かなくするのはむしろ依頼側のような。

結局のところ、情シスが絶大な権力を持ってばしっとシンプルにクールに運用≒品質を取り纏められるかが一番大事と思うのは、ベンダー側の肩を持ちすぎでしょうか。
とは言え、白川様のような依頼主側をバシッと取り纏められるようなコンサルが入るとクールになるわけですから、あながち間違いではないと自負しとります。

PS. セミナー参加できませんで申し訳ございませんでした。

きむらよしひさ

品質を良くしようとするとコストがかかるから、どこかで妥協しないといけない。品質に見合った報酬を顧客からもらえればハッピーなんだけど、現実はそうもいかない。だからSIerで出世する優秀な人材は品質で妥協するんだ。つまりSIerの経営陣、上級管理職、マネージャークラスはこのような考え方が基本となっているんじゃないかと思う。
それを変えるには顧客とSIerが同じテーブルに座って、ビジネスの利益を分配する仕組みから作らないといけないのかなって思います。

コメントを投稿する