オルタナティブ・ブログ > 一般システムエンジニアの刻苦勉励 >

身の周りのおもしろおかしい事を探す日々。ITを中心に。

バグを見つけても自分を疑えないケース

»

ソフトウェアのバグは大きく4種類に分類できると思います。

 

実装者

設計者

発注者

対応

レベル0(SW/HWの仕様・不具合)

×

×

×

設計変更

レベル1(プログラムミス・性能不良)

×

テスト

レベル2(仕様相違)

×

レビュー

レベル3(プログラムの存在自体がバグ)

×

×

難しい



レベル0

ソフトウェアやハードウェアの仕様であったり、それらに潜むバグにより引き起こされるものです。実装者(プログラムの担当)や設計者では回避できません。メーカーのパッチの提供を受けるか、設計の変更による対応が可能です。予防を行うには枯れた技術を用いることが効果的です。

レベル1

プログラムのバグです。文法の間違いや、論理的な間違い(ゼロ以上なら処理するところをゼロ以下なのに処理してしまうようなケース)により引き起こされます。性能が悪く発注者の要望を見たさないような場合もこちらに分類しました。十分な環境で必要な工数を投入してテストを行い、ある程度の長さの試験運用期間を設ければバグ発生を抑制できます。

レベル2

プログラムは設計通りに作成されています。しかしながら設計が発注者の要望と一致していないために、発注者から見たときにバグに見える状態です。敏腕の実装者が「これは本当にこれで良いのか?」と疑問を呈して検出する事もありますが、基本形は発注者と設計者で十分な確認を行うに尽きます。

レベル3

実はこれが一番数が多く、そして引き起こす問題も大きいと思います。システムは必要なかったり、システム化する元となった業務の遂行形態が不合理なものです。発注者が強い意志で開発を進めることを決定した場合、存在しなくても誰も困らないシステムが出来上がってしまうことは回避することが非常に難しいです。信頼できる経営コンサルタントやITコンサルタントを身近に置き、開発の正当性の根拠を外部に求めるようにすればある程度は回避できるように思います。私が勝手にバグの一種と定義しましたが、普通これをバグと言うことはないでしょう。

ではこの中で私が苦手なものはどれでしょうか。

まずレベル3のものですが、これは開発サイドの手に負えないものであることは間違いありません。コンサルタントの方やCIO、CTO、株主などに頑張っていただくしかありません。ですので苦手も何もありません。ただし「これはおかしい」と感じるようなシステムの開発を命じられたならばモチベーションも下がって辛い思いをすることでしょう。これまで感じた事はありません。

次にレベル1のものですが、テストをしっかりと行うことと、ツールにやってもらえることはツール任せにすることでバグを確実に減らしていくことができます。知識と資源(人・モノ・金・時間)さえあれば成功させることができるプロセスです。反対に、時間やモノ(テスト環境)が欠けると24時間3交代でテストを実施するなどの悲惨な経験も積むことができます。そういうのは苦手ですが、延々とマーカーでテスト結果をチェックし続ける作業は時間に追われていなければ嫌いじゃありません。

そしてレベル2のものですが、情報システム開発の世界で長らく難しいポイントであると言われ続けているところです。発注者の思い描くイメージは大きく膨らんでいますので、発注者が許せる範囲でスリム化して設計する事になります。ウォーターフォール型の開発を行うのであれば、ISO9000シリーズに代表される品質管理の考え方を用いることで回避の助けとすることができます。もしくは、お客様の参加のもとで動くシステムを、グリグリといじりながら見て触って開発していけば相違を減らす事ができます。どちらも言うのは簡単で、実践するのは難しいものです。

では一番苦手なものはと言うとダントツでレベル0のものです。自分で回避できないのですから当然なのですが、開発を担当する人間からするとこれほど嫌なものはありません。OSや開発環境に潜んだこの種のバグの発生は、自分が作ったプログラムに潜むレベル1のバグと見分けがつきません。しかしどれだけかの体力を費やした後に異常に気付き、技術文献などを頼りにしてようやく「仕様」であることが判明します。とても時間がかかります。

これでも十分に嫌なのですが、もっと嫌な点があります。この類のバグは一度発生するとシステムに対する疑心暗鬼を生むということです。自分で発生させたレベル1のバグでも「これはひょっとして基盤のバグではないか」と考えてしまうようになります。その結果、デバッグ作業時に心の迷いが生じ「自分のプログラムは正しい。値が書き換わる様なバグがブラウザ自身にあるに違いない」というように、ありもしないバグを探してしまうということもあります。

プログラミングというのは何もないところからソースを紡ぎ出す作業ですので、自分に対する自信、自分の技術や知識に対する自負がなくてはうまくいかないものなのかもしれません。例えばプログラムの教本で勉強をしている際、最初のほうではエラーが起きると自分を疑うのに対して、知識がついてくるとエラーが起きた時に自分ではなくて教本の誤植を疑ってしまうという覚えのある方もおられることでしょう。

不安定なハードウェアやソフトウェアを使用していると、疑心暗鬼が生じてありもしないバグを探してしまうことになりかねません。何が不具合が起きたら真っ先に自分を疑えるような環境で心を落ち着ちつけて開発をしたいものです。

Comment(0)