SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

直近開催のイベントはこちら!

EnterpriseZine編集部ではイベントを随時開催しております

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

開発担当者必携!トラブル削減のための原則拾七ヶ条

【八】期限が迫っているからといって、テスト、レビューを省略しない。

第8回


 システムは納期との戦いです。急がされることがほとんどではないでしょうか? しかし、頑張った結果が大失敗では浮かばれません。どのような局面でも、テスト、レビューは省略しないことが大事です。

100点以外は0点

 「上手の手から水が漏れる」という言葉があります。上手な人でも時には失敗することがある、ということですが、この言葉、システム開発では特に肝に銘じておかなければなりませんね。

 システム開発の仕事は、その過程で誤りを作り込むという宿命を負っています。作り込まれているはずの誤りを発見して直していくのがテストですし、行った作業や、検証している内容が的外れでないことを押さえるためにもレビューは必要です。

 ところが、特に急いでいる時などは、急いでいることを理由にして、テスト、レビューを省略することが行われます。

 急がなければならない時、急いでいることが全てに優先する…という気持ちになりやすいのはよく理解できるのですが、急いでいる時の方が誤りの発生や、勘違いが起こりやすいのもまた事実です。何とかしなければいけないという気持ちが先走って、品質と期限をバーターにするのは悪魔のささやきです。

 システム開発は「100点以外は0点」という宿命を負っています。皆さん、口では80%主義などといいますが、それが実現機能80%のことなら良いのですが、品質80%でしたらシステムは使い物になりません。また、作りこんだ誤りの大きさと、その誤りが起こす事件の大きさは無関係です。些細な誤りが…大事件となります。

 頑張って、徹夜で、何とか間に合わせようと一所懸命働いて、しかし、その結果が大トラブルでは浮かばれません。「何とか間に合わせてくれ」と言った相手も、「トラブルを起こしてくれとは言わなかった」と冷たい態度になります。こういった頑張り方に価値は無いのです。

 開発依頼者と期限優先の合意が出来ている場合、またトラブルに寛容なお客様、一定程度の誤りは本番をやりながらなおしていく…ということが許される業務なら話は別ですが、その場合でも、どんなトラブルが起こるかわからないのですから慎重にはなりますね、大きなトラブルになると、よいとは言ったがこんなトラブルは想定していないよ…、と言われる羽目になりそうです。

テスト、レビューは省略しない

 結局、原則はどのような局面でも、テスト、レビューは省略しないことです。もちろん、要領よく行うよう頭を使う必要はあります。押さえなければいけないところをきちんと押さえ、最低限、そこは譲らないのがプロです。その押さえが正しいかについてレビューをしっかり行うのもプロです。万が一!万が一!省略せざるを得ない時も、リスクを評価し、省略の判断についての責任を明確化しておくことです。

 誰がやっても、システム開発に伴う誤りの作り込みが発生するのは事実です。テストやレビューをしないことに伴うリスクを主張するのは恥ずかしいことではありません、責任あるプロの仕事です。そして、こうした原則、基本動作は、結局は開発依頼者、そしてお客様のためだということを忘れてはなりません。

やったことのチェックだけにならないようにする

 トラブル発生時のプログラム緊急修正、緊急作業。もっとも期限が厳しい状態になります。テストが出来ない環境、条件の時もあります。どうしても人間系でのチェックだけで作業を進めなくてはならない場合が出てきます。

 このような時は、是非、チェックに際して、作業をやったことのチェックだけにならないようにお願いします。チェックする人は、作業する人に、なぜ、この作業でよいのか、どこがどうなればよいのか、その根拠は、という点を説明させてその内容を吟味、判断してください。完全ではありませんが、担当者に根拠を説明させることで人間の犯しやすいミスを防止できます。経験的にはテストが出来ない時の、2重遭難を防ぐ数少ない有効策といえると思います。

この記事は参考になりましたか?

  • Facebook
  • Twitter
  • Pocket
  • note
開発担当者必携!トラブル削減のための原則拾七ヶ条連載記事一覧

もっと読む

この記事の著者

菊島 靖弘(キクシマ ヤスヒロ)

独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター(SEC) リサーチフェロー。1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管理の向上を実...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/190 2007/10/25 12:42

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング