完璧なシステム

Pocket

森林公園

長年SEをやっていると、システムに対していろいろな経験ができます。

絶対に発生しないと思われたエラーが発生した、とか、ほんの小さなミスがこんなに大事に至るんだ、とか。

そんな経験値がたまると、SEとしては成長したことになるのかもしれないけど、どんどん慎重になっていくような気がしています。

コーダーとか自分で手を動かせる人については自分でなんとか出来るだろうと、逆に豪胆になっていく人ももちろんいますが、上流工程(特に発注側)の人については「あれは大丈夫?」「そっちは検討した?」「過去のバグを踏まえた形になっている?」など石橋を叩きまくっている人が多いような気がします。

それ自体、悪いことではありません。石橋を叩くことによって防げたシステムトラブルだってあったはずです。しかしその行為がコストに跳ね返ってきていることも認識すべきです。

システムの品質は、いかにバグを出さないか、で評価されます。

バグは人為的ミスであったり、コミュニケーション不足による勘違いだったり、選定した製品によるものだったり、相性の問題だったり、、と原因をあげればたくさんあるのですが、その全ての原因を事前に潰すのは数が多すぎるので現実的ではありません。なので、品質を上げるには、大抵は試験(テスト)に頼ることになります。事前に全てのバグになりえる原因を潰すことができたのなら試験を行ってもバグは発見されないことになります。もちろん試験以外にもシステムを開発する各工程ごとにもある程度のルールを作ってバグを混入されない仕組みは用意しておくのですが、時間もお金も有限であるためある程度で切り上げる必要があります。

でも試験については、比較的簡単に、今までの経験を追加できます。「過去のバグの傾向からこのテストは行うべきだ」「このケースは念のため試しておいたほうがいいよね」と言った感じで試験工数はどんどん膨れ上がってきます。試験の場合は、試験に合格した根拠はともかく、必要な試験に合格したという実績が全てなので必要最低限の工数で済むのが良いところなのですが、いろいろなケースを追加することにより結局試験計画の見直しが必要だったり、試験専用の環境を追加したり、試験用データの生成をしたり、そして余計な残業が発生したりとコストが上がっていくのです。

つまり品質を上げるには、コストがかかるのです。

では、バグとは不具合のことですが、そもそも不具合ってなんでしょうか。システムの利用に困らなければ、潜在的なシステムバグがあっても良いのではないでしょうか。

例えば、サッカーの点数を表示するシステムがあったとしましょう。スコア部分に3-2とか入力するのですが、1000-2とか数字の桁数が4桁に達すると表示できないというバグがあったとしても、1試合で1000回もゴールすることがないので利用には困らないでしょう。※これは本当はあまりいい例ではなくて、基本的にSEは値(表示する点数)の範囲を決めておいて、その値を元に境界値(限界値)テストを行います。

もちろん、ほとんどの仕組みがIT化されたこの社会で、完璧じゃないとダメなシステムも存在するのでしょう。あまり想像できませんがバグを出すことで死人を出すようなシステムもあるのかもしれません。しかし、今までの経験上、バグが発生して誰かが死んでしまうようなシステムに関わったことはありません。なので品質を考える際には、必要最低限の仕組みのみを試験し、コストを削減するような選択肢もあってしかるべきだと思います。感覚的な話で申し訳ないのですが、80%の品質を求めるには比較的簡単に試験ができると思っています。しかしそれを90%にするには結構コストがかかります。さらに100%に近づけるためにはとんでもないコストがかかります。システムにある程度以上の品質を求めるのは相当なコストがかかるし、完璧を求めるのは不可能なのです。

システム開発におけるコストと品質のバランスを考えた松竹梅という選択肢を提示して、その中でも梅でもいいじゃん、と思っているわけではありますが、単純に品質強化を捨てて開発コストを下げれば良いと言っているわけでもありません。

重要なのは、バグが出た後の話。バグを出したとしてもその影響を抑え込める仕組みを作ること、もしくはバグが出たとしてもその影響を見切っているため大事に至らないと判断できること。どちらも非常に高度な話ですが、本当はこちらにコストをかけるべきなんだと思います。

石橋を叩きまくる人は、思いつく全てに保証を、強いてはコストをかけようとする。まずは試験工数を増やしておきながら生産性が上がらない、という矛盾には気づくべきです。そして簡単に生産性を上げたいのであれば、何かをやめなきゃいけないことにも気づくべきです。

と、偉そうに言っていますが、じゃあ自分が責任取れるのかと言われちゃうと、やっぱ石橋叩きましょうかとなってしまいます。とはいえ、完璧なシステムなんて存在しないので、コストかけるところを間違えないようにしなきゃね、というお話でした。※本当は石橋を叩く人がよくいう「実績はありますか」という言葉が嫌いというエントリーを書こうと思っていたら、指が違うストーリーに変えてしまいました。

[amazonjs asin=”4774131989″ locale=”JP”]

Pocket

コメント


  • arkstrong

    システムの品質というのは凄まじく難しい課題ですよね。
    私はSEから事務屋へ転職をしたのですが、SEだったころはatsuronさんと同じような考え方が基本であり前提だと考えていました。
    しかし、それは真実であると同時にシステム屋の考え方に過ぎないらしいのです。
    システムを知らない事務サイドの責任者は、バグって都合のいい言葉だよね。と言います。
    問題が起きたときに、バグでした。って言えば許してもらえると思ってるんじゃないの?と。
    もう一人の責任者はこう言います。不具合がある状態でリリースするなんてシステム屋としてのプライドはないのか?と。
    元SEの私から見たらそんなのはぶっちゃけ暴論で、SIerを擁護したくなるのですが、モノの製品の場合、不具合があるものは保証期間とか関係なく無償でリコールされるわけですから、システムをそれと同じように見る感覚というのはある意味で正しいのかもしれないとも思うのです。

    ブログのタイトルの、「完璧なシステム」が当然と考える顧客と、そんなのは論理的にあり得ないと知っているSE側の溝は深いです。
    (私は両サイドを知っているつもりなので、システム全体と各所のデータの動きを把握しておいて、潜在バグとかを見つけても内々でオペレーションを精査して埋めたりにするんですが、大抵必死です(笑))


    • atsuron

      システムを知らない人とのコミュ二ケーションも難しいですね。
      完璧を求めること自体は間違いではないけど、それなりのコストがかかるって事を理解いただきたいですねー。
      簡単な改修でしょ、とかいう中途半端に知識がある人でも、それを変更するプロセス全体までは頭には入ってなかったりするので。

コメント投稿

* は必須項目です。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください