システム開発プログラミング

障害（バグ）の直接原因にはどのようなものがあるのかを紹介していくシリーズ。

 

直接原因を知り、その根本原因を知ることは、自身の設計やプログラミングの質を高めます。

 

第二弾は、「条件文（判断文）の漏れや誤り」です。

 

初期化漏れと同様に、条件の漏れや誤りによる障害（バグ）によって、プログラム動作にどのような影響が生じるのかを学んでください。

スポンサーリンク

 

条件文（判断文）の漏れや誤りとはどのようなバグなのか？

条件文または判断文の漏れや誤りとはどのような障害（バグ）なのでしょうか？

 

その名のとおり、IF文などの条件文を構成する条件が不足している状態を、条件文の「漏れ」と呼び、条件が誤っている状態を条件文の「誤り」と呼びます。

 

まず、条件文の「漏れ」についてですが、そもそも条件が足りていない訳ですから、ある条件の場合、必ず障害が起こります。

 

例えば、期末テストの成績が６０点～６９点までで、かつ、教科が国語であれば「可」とする。という条件があったとします。

 

このとき、「教科が国語の場合」という条件が抜けていた場合、全ての教科で６０点～６９点までは「可」と評価されてしまいます。

 

数学は、「再試験」という条件だったかもしれません。

 

このように、条件が一部抜けていることで、評価が正しく行われなくなります。つまり、国語以外の教科では必ず障害が発生してしまうということです。

 

 

一方、条件文の「誤り」ですが、そもそもの条件が仕様と異なっている状態になります。

 

上記の例でいえば、教科が国語で、６０点～６９点までは「再試験」とするのが、誤りになります。

 

上記の条件とは食い違っているのが分かると思います。

 

 

 

条件文（判断文）の漏れや誤りによるプログラム動作の影響とは？

条件文または判断文の漏れや誤りにより、プログラムにどのような影響がでるのでしょうか？障害（バグ）とはどのようなものでしょうか？

 

一番多いのは、期待する処理が行われないという事象です。

 

条件文とは、次の処理にはどういう処理を行わせるのかを決定するための重要な論理です。

 

ですので、条件自体に不備があれば、当然、正しい動作にはならないことが理解できると思います。

 

条件を構成するものとして、比較演算子と論理演算子があります。まとめると以下のようなイメージです。

 

比較演算子での条件文は、単純な条件ですが、比較する値を含めるのかどうかを判断する条件に誤りが多く見受けられます。

 

含めない場合は、「＞」「＜」、含む場合は「≧」「≦」を使用するという算数や数学でやってきているはずですが、実際プログラムを作成する段階では、これらの演算子を取り違えてコーディングしてしまうケースもよくありますので、注意が必要です。

 

 

論理演算子は、複合的な条件の場合に使用されます。

 

例えば、先の点数の評価のような条件の場合が該当します。

 

点数が６０点～６９点　かつ　教科が国語　の場合、評価は「可」とする。

 

左側の条件が「点数が６０点～６９点」、右側の条件が「教科が国語」となります。

双方の条件をともに満たす場合に、真となり評価が「可」となるのです。

 

プログラミング的にいえば、厳密には、「点数が６０点～６９点」の条件は、「点数が６０点以上　かつ　点数が６９点以下」となり、複合条件になりますので、AND条件が２つあることになります。

 

AND条件、OR条件、そして、NOTをさらに複合的に使用した条件になると、条件が複雑になり、障害が発生しやすくなります。

 

その際は、条件を見やすいように書く工夫が必要です。

 

例えば、以下のようなイメージです。

 

見づらい条件文の例）

条件を全て横並びに羅列していて、どこが区切りなのか分かりづらいです。

 

見やすい条件文の例）

ひとつの複合条件を１行に示しているので、どこが区切りなのかわかりやすい。

また、桁合せをしているため、見やすくなっているのが分かると思います。

 

このように、条件文が複雑になればなるほど、漏れがあるのか誤っているのか解析が困難になる場合があります。その際には、コーディング自体を工夫するだけでも、障害を防ぐことも可能なのです。

 

スポンサーリンク

 

条件文（判断文）の漏れや誤りの根本原因とは？

条件文または判断文が重要であることは、誰もが知っているはずです。

 

ですが、障害（バグ）の原因として多数発生しているのです。

 

そもそも、条件を詰める作業が足りなかった、条件が必要であることに気付かなかった、あるいは、条件を誤認識していた、などなど。その要因となるものはたくさんあります。

 

そのほとんどが、「考慮不足」あるいは「考慮漏れ」というものです。

 

では、なぜ、こうした考慮不足や考慮漏れが発生してしまうのでしょうか？

 

それは、仕様を把握していない、または、仕様が定まっていないかのどちらかに集約されると思います。

 

では、なぜ、把握できていないのでしょうか？仕様が定まっていないのでしょうか？

 

これは、２通り考えられます。

 

一つ目は、設計やプログラミングを担当するSE・プログラマーが注意力散漫、怠け者、うっかりものである場合です。

 

二つ目は、そもそも、レビューが機能していないとうことです。

 

システム開発の現場の七不思議に、レビューしているにもかかわらず、障害（バグ）が発生した場合の犯人は、９９％、その担当者になります。

 

レビューをしてくれたレビューアではありません。レビューアには、何の責任も及びません。

 

おかしいと思いませんか？

 

でも、９９％の現場ではそれが当たり前になっています。

 

ですが、ここで声を大にして、言わせていただくなら、

 

レビューアが無能だったからです。

 

これが、本当の根本原因です。

 

ですが、誰もそれを認めません。当たり前です。プライドが高い人がレビューアをしているからです。

 

ですが、そもそもの仕様の理解不足や認識誤りは、レビューの際に、指摘できるはずなのです。ですが、実際のレビューでは、誤字脱字のチェックだけとか、表組にしなさいとか、どうでもいいようなことで何時間も無駄にします。その修正にどれほど無駄な時間・工数が費やされていることか。

 

さらに、レビューア自身もよく仕様を把握していないことも多々あります。ここに、プロジェクトが失敗する要因があります。

 

これでは誰も、仕様を把握できていない状態です。上辺だけの仕様書に書いてあるからというようなレベルのものではなく、ユーザーが要望するイメージするシステムそのものを把握している人がいない状態なのです。

 

これこそが、システム開発が失敗するたったひとつの理由とは？でも書きましたが、失敗が待っている結末になるのです。

 

ですので、この障害に対する、再発防止策は、明白なのです。

 

レビューを機能させる。ということです。これができないプロジェクトは破綻します。どこかで必ず歪がでます。このことは、よくよく肝に銘じておいてください。

 

あなたが、レビューアであるならば、条件のチェックは、時間をかけて、ヌケがないか正しいかをチェックすることです。

 

また、あなたがレビューイであるならば、精一杯、仕様を理解する努力をすることは言うまでもありません。

 

 

 

関連記事）こちらも参考にしてみてください。

障害（バグ）の直接原因・根本原因（１）初期化漏れを知る！

障害（バグ）の２つの原因「直接原因」と「根本原因」を知る

 

スポンサーリンク