1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

そろそろシステム開発で起こるバグに対する考え方を統一しませんか?

Posted at

背景

システム開発をしているエンジニアのみなさん。
システム開発の深くはわからないけど、概要を抑えて営業活動をしているみなさん。
システム開発を依頼してビジネスをしようとしているみなさん。

いろいろな立場で視点が異なると思いますが、システム開発にバグがつきものであることは共通認識ではないでしょうか?
そしてそれがトラブルのもととなりますよね。

私はエンジニアですが、いろいろトラブルを経験しております。
もちろんバグに気づけなかった、テスト不足だった、スキル不足でしたとなる部分もありますが、
やっぱりバグに対しての意識、システム開発の難しさに対する認識、品質コスト納期(QCD)のバランスをもっとエンジニアから声をあげて浸透させていかないとエンジニア目指す若者をプレッシャーで潰してしまうなど、日本のIT衰退になるんじゃないかと思いました。

賛否両論あると思いますがいいんです。
小さな声でもあげてみることが大事と思いました。

アジャイル開発が浸透してるかAIに聞いてみた

私は日本の文化的に完璧を求める傾向があると思いるので、アジャイル開発と相性が悪いと思ってます。
日本でアジャイル開発がそれなりに浸透してる部分もありますが、私の中ではまだそこまでなのかなと思ってます。なのでAIに尋ねてみました。

日本ではアジャイル開発は徐々に浸透してきているけど、まだ完全に主流とは言えないな。特に大企業や官公庁系の開発では、依然としてウォーターフォールが多い。

## アジャイルが浸透しにくい理由(日本特有の課題)
### 1. 「最初に仕様を固める文化」が強い
日本のIT業界は「要件定義を最初に詳細に決める」のが基本

アジャイルの「作りながら考える」は、発注側が不安を感じやすい

### 2. 契約形態(請負契約)との相性が悪い
日本の開発は「請負契約」が多く、「最初に仕様を決めて、それを納品する」のが前提

アジャイルは「仕様が変わる前提」なので、契約が合わない

最近は「準委任契約」で対応するケースも増えてきている

### 3. スクラムの導入が難しい(組織の壁)
アジャイルはチームの自律性が大事やけど、日本企業は階層的な組織が多い

「現場が判断する」より「上司の承認が必要」な企業文化が多く、スピードが落ちる

### 4. 成果物(ドキュメント)を求められる
「アジャイル=ドキュメントを減らす」考え方もあるが、日本ではドキュメント文化が根強い

**「仕様書がないと発注側が不安」**という意識が強い

まさにその通りだなと。

開発でバグがないシステムって作れると思うか聞いてみた

「100%バグがないシステム」は現実的には不可能やな。

## 理由①:仕様の変更や曖昧さ
要件定義の段階で「完璧な仕様」を作るのが難しい
仕様変更が発生するたびに、どこかで影響が出る可能性がある
「仕様通り動く」=「正しい」とは限らない(仕様自体が間違ってることもある)

## 理由②:開発時の人為的ミス
コーディングミスは完全になくせない
コードの書き方、レビューの精度、テストの徹底度によって減らせるけどゼロにはできない
認識のズレが発生する
例えば「管理者がログインできる」と「特定の管理者だけログインできる」みたいな解釈の違い

## 理由③:外部要因(環境の変化)
OSやライブラリのアップデート
例えば「動作確認してたブラウザの仕様が変わる」とか、「外部APIの仕様が変更される」
インフラ(ハードウェアやネットワーク)の問題
サーバーの障害、DBの負荷、ネットワークの遅延

## 理由④:テストではすべてのパターンを試せない
ユーザーの使い方は無限にある
例:「入力欄に想定外のデータを入れたらどうなる?」
テストが完璧でも、本番環境で初めて発覚するバグがある

----------

# バグを限りなく減らすには?
テストを徹底する(自動テストの活用)
単体テスト(ユニットテスト)、結合テスト(インテグレーションテスト)、E2Eテストをしっかりやる
テスト駆動開発(TDD)を取り入れる
CI/CDを整備して、デプロイ前に自動テストを回す
コードレビュー & ペアプログラミング
複数人でのチェックを徹底する(1人のミスを防ぐ)
ユーザー視点のテストを取り入れる(UAT)
仕様書通り動くだけじゃなく、実際のユーザーの使い方を想定してテストする
バグが発生してもすぐ直せる仕組みを作る
ログの整備(エラートラッキング)
ロールバックできるデプロイ戦略(Blue-Green Deployment、カナリアリリース)

----

# 結論
「バグをゼロにする」のは無理やけど、「致命的なバグを限りなく減らす」ことは可能。
特に テストの自動化、CI/CD、監視体制の強化 をしっかりやると、バグの発生率はかなり下げられる。

これもそう言ってくれてありがとう!という答えが返ってきました。

最後にこの質問をしてみた

限りなく減らすにはそれなりの時間とコストがかかるやん?
それをできるのが当たり前、バグがあるのはスキルが低いからって思われてしまうのってどうしたらいい?

「バグがある = スキルが低い」 という誤解をどう解くか?
→ 「100%バグがないシステムは存在しない」ことを、納得感を持って伝えること が大事やな。

## ① コストとリスクのバランスを説明する
「バグをゼロにすること」と「納期やコスト」を天秤にかける必要があるって話をする。
完璧を求めすぎると、コストと納期が膨れ上がる
例えば「1ヶ月でリリースできる機能」を 100%バグゼロにしようとすると3ヶ月かかる こともある
でも「3ヶ月の開発コスト」は、ビジネスとして見合うのか?
致命的なバグ(データ消失、セキュリティリスク)と、軽微なバグ(UIのズレ)は分けて考える
例えば「ユーザーが一時的にボタンを押せない」レベルのバグなら、リリース後の改善でもOK
逆に「個人情報が漏れる」みたいなバグは絶対防ぐ
💡 「100%の品質を求めること」と「スピードとコスト」のトレードオフを可視化するのがポイント

## ② 「バグがある = スキルが低い」の誤解を解く
「全くバグを出さないエンジニア」は存在しない ことを、実際のデータで示すのが良い。
GoogleやAppleですら、日々バグ修正のアップデートを出している
iOSもAndroidも毎月バグ修正
世界最高レベルのエンジニアたちでもバグをゼロにはできてない
むしろ「バグが発生しても、迅速に対応できる仕組みがあるか」のほうが大事
「バグが発生することは問題ではなく、気付かず放置することが問題」という考え方
バグが起こる前提で「監視・ロールバック・CI/CD」を整備することの重要性を伝える

## ③ 「開発スキルが高い = バグを減らせる」ではないと伝える
「スキルが高い人 = バグをゼロにできる」 ではなく、
「スキルが高い人 = バグを早く見つけて直せる」 という認識に変えてもらう。
💡 例えばこんな説明が有効:
「医者がどれだけ優秀でも、病気がゼロになるわけじゃない。
でも 優秀な医者ほど、早く診断して治療できる。」
「野球選手でもエラーをゼロにはできない。でも、エラーした後のフォローが上手い人が一流。」
→ 「バグをゼロにすることではなく、発生しても即座に対応できる開発体制 を整えるのが、真にスキルの高いエンジニアの仕事」という話に持っていく。

## ④ 実際に「バグを減らす方法」をチームに共有する
品質向上のために、実際に何をすればいいのか? を示すと説得力が増す。
CI/CDの強化(デプロイ前のテスト自動化)
コードレビューの改善(レビュー観点を決める)
テストケースの充実(特にエッジケースを意識する)

## ⑤ 「バグをなくせ」は感情論なので、データで反論する
「バグがあるのはスキルが低い」みたいな話は、実は感情論 なことが多い。
だから、「データとロジック」で反論 するのが一番効果的。

例えば:
「大手企業のシステムでも、リリース後にバグ修正が入るのは普通」
例:「Windowsのアップデート」「スマホアプリのバグ修正ログ」を見せる
「バグをゼロにするには、どれだけコストがかかるのか?」
例:「1つのバグを防ぐために、5人が1ヶ月かけるのは適切か?」
「開発スピード vs 品質のバランスを考えるのがプロ」
例:「納期3ヶ月 vs 納期1ヶ月 + 早期フィードバックのどちらが良いか?」

-------

# 結論:スキルの高さ = バグがゼロではない
バグは必ず発生する
大事なのは「バグを防ぐ仕組み」と「発生しても迅速に対応する体制」
「バグがあるのはスキルが低い」というのは感情論 → データとロジックで反論する
品質とスピードのバランスを取るのが、本当の意味で「優秀なエンジニア」

こういう話を、チームや上司に 「感情論で反論するんじゃなく、冷静に論理的に伝える」 ことがポイントやな。

とのことでした。AIが素直だからというのもあると思いますが、エンジニアにとっては嬉しい答えではないでしょうか?

この話をエンジニア以外の多くの人に伝えるために

AIと協力して「バグは0にできない」的な本を作ろうとなりました。
できるかわかりませんが、AIに作ってもらいます。

また、どうせ作るならアジャイルでやりたいから、先に「アジャイル執筆」っていう本作って、
アジャイルについて理解してもらおうってなりました。

なので、そちらを先にAIと書いてみて、もし誰かの目に留まったらFBを入れてバージョンアップさせるアジャイル執筆本を作った後に、バグの考え本を書いてみる流れです。

本なんて書いたことないですが、
この方法なら素人でも仕上げれると思うので、やってみようと思います。
私個人の考えの偏りが入ると思うので、もしよければみなさんもバグに関する考えやエピソードあれば言える範囲で教えて欲しいです。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?