« 2008年2月19日

2008年2月20日の投稿

2008年2月21日 »

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

 

実装者

設計者

発注者

対応

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

×

×

×

設計変更

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

×

テスト

レベル2(仕様相違)

×

レビュー

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

×

×

難しい



レベル0

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

レベル1

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

レベル2

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

レベル3

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

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

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

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

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

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

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

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

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

yohei

« 2008年2月19日

2008年2月20日の投稿

2008年2月21日 »

» このブログのTOP

» オルタナティブ・ブログTOP



プロフィール

山口 陽平

山口 陽平

国内SIerに勤務。現在の担当業務は資金決済法対応を中心とした資金移動業者や前払式支払手段発行者向けの態勢整備コンサルティング。松坂世代。

詳しいプロフィール

Special

- PR -
カレンダー
2013年5月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
yohei
Special オルタナトーク

仕事が嫌になった時、どう立ち直ったのですか?

カテゴリー
エンタープライズ・ピックアップ

news094.gif 顧客に“ワォ!”という体験を提供――ザッポスに学ぶ企業文化の確立
単に商品を届けるだけでなく、サービスを通じて“ワォ!”という驚きの体験を届けることを目指している。ザッポスのWebサイトには、顧客からの感謝と賞賛があふれており、きわめて高い顧客満足を実現している。(12/17)

news094.gif ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
上司や先輩の背中を見て、仕事を学べ――。このように言う人がいるが、実際どのようにして学べばいいのだろうか。よく分からない人に、3つの事例を紹介しよう。(12/11)

news094.gif 悩んだときの、自己啓発書の触れ方
「自己啓発書は説教臭いから嫌い」という人もいるだろう。でも読めば元気になる本もあるので、一方的に否定するのはもったいない。今回は、悩んだときの自己啓発書の読み方を紹介しよう。(12/5)

news094.gif 考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
自社製品と競合製品を比べた場合、自社製品が選ばれるのは価格や機能が主ではない。いかに顧客の価値を向上させることができるかが重要なポイントになる。(11/21)

news094.gif なんて素敵にフェイスブック
夏から秋にかけて行った「誠 ビジネスショートショート大賞」。吉岡編集長賞を受賞した作品が、山口陽平(応募時ペンネーム:修治)さんの「なんて素敵にフェイスブック」です。平安時代、塀に文章を書くことで交流していた貴族。「塀(へい)に嘯(うそぶ)く」ところから、それを「フェイスブック」と呼んだとか。(11/16)

news094.gif 部下を叱る2つのポイント
叱るのは難しい。上司だって人間だ、言いづらいことを言うのには勇気がいるもの。役割だと割り切り、叱ってはみたものの、部下がむっとしたら自分も嫌な気分になる。そんな時に気をつけたいポイントが2つある。(11/14)

news094.gif 第6回 幸せの創造こそ、ビジネスの使命
会社は何のために存在するのでしょうか。私の考えはシンプルです。人間のすべての営みは、幸せになるためのものです――。2012年11月発売予定の斉藤徹氏の新著「BE ソーシャル!」から、「はじめに」および、第1章「そして世界は透明になった」を6回に分けてお送りする。(11/8)

オルタナティブ・ブログは、専門スタッフにより、企画・構成されています。入力頂いた内容は、アイティメディアの他、オルタナティブ・ブログ、及び本記事執筆会社に提供されます。


サイトマップ | 利用規約 | プライバシーポリシー | 広告案内 | お問い合わせ