ソフトウェア開発でバグ管理はなぜ必要なのか
「品質・バグ管理はなぜ必要なのか」という質問があって、回答が面白かったのでメモ。
以下は、深く考えずにラフなメモ書き。
【参考】
Redmine - 品質・バグ管理の必要性についてご意見をお聞かせください。(10612)|teratail
BTSを制する者がソフトウェア開発を制する: プログラマの思索
【1】(引用開始)
タイトル通りですが、品質管理・バグ管理の必要性について質問させてください。
個人的には、「100%必要ない!」とは思っていませんが、厳重に管理したバグ票やらを必死に分析して最終的に何に使うのでしょうか?
(中略)
例えば、「あるexceptionによるシステムエラー」が起きたとしたら
1.なぜバグが起きたのか?
→exceptionをキャッチしていない
2.なぜcatch文をいれていないのか?
→設計書から見落とした
3.なぜ見落としたのか?
→凡ミス
4.なぜ凡ミスが起きたか?
→疲れていた、作業効率の低下、特に理由なし
ここで最後の回答をしたところで、管理者は「なるほど、気をつけて」としか言いようが無いし、作業者としても「疲れていた」とは言いにくいものもあります。
バグの内容にもよりますが、明らかに大したバグではない、凡ミスのようなものに追及していく必要はあるのでしょうか?
それより、さっさと改修しても良い気もします。
一つの現場だけでなく、だいたいどの現場も同じ漢字なので不思議です。
(引用終了)
ソフトウェア開発でバグ管理が重要な理由は、障害管理のプロセスがソフトウェア開発の全てのプロセスの根幹をなすからだ。
つまり、BTSを使いこなす者はソフトウェア開発を制する。
以前、Blogにその考えは書いた。
BTSを制する者がソフトウェア開発を制する: プログラマの思索
Bugzilla、MantisからTrac、Redmine、Jiraに至るまでのBTSには、世界中のソフトウェア開発者のベストプラクティスが埋め込まれている。
だから、できるだけ最新のBTSに慣れた方がソフトウェア開発のスキルも向上できるはず。
【2】なお、製造業の品質管理とソフトウェアの品質管理は別物とみなした方がいいと最近は思っている。
製造業の立場から見れば、ソフトウェアの品質管理は、正直笑ってしまうぐらいの低レベルと思えてしまうだろう。
製造業の品質管理が知りたいなら、たぶん、QC検定2級レベルの知識を一度見てみればいいと思う。
彼らは、大量生産される工業製品の品質管理を統計学的手法で、細かな部分までコントロールしようとしている。
統計学における仮説検定、相関・回帰分析などが必要とされるので、相当にレベルは高い。
製造業の品質管理は、管理図を使って、製品の規格のばらつきを抑えるように、工程や作業を改善するのが王道だと思う。
たとえば、ネジを作っていて、そのネジの大きさや長さにバラつきがあれば、どの作業工程でそのバラつきが発生したのか、どの人が担当するとばらつきが大きいのか、などを細かく突き止め、原因を把握して、作業方法を改善していく。
一方、ソフトウェアの品質管理は、製造業の品質管理を真似ようとして色々試されているが、そのレベルまで到達しているようには思えない。
とは言え、ソフトウェア工学では経験則としていくつか知られている知見はある。
たとえば、人月の法則とかコンウェイの法則、リーマンの法則とか。
リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索
【3】製造業とソフトウェアの品質管理が全く違うように思える理由は、生産プロセスが全く違う観点で存在するからではないかと思う。
製造業は徹頭徹尾、WF型開発のように、生産計画重視で大量生産が王道。
大量に仕入れして原材料費を安く交渉し、大量に販売して売上を大きく稼ぐ。
大量生産するには、見込生産が必要で、そのためには、どの程度の需要があるか、計画段階で決めなければならない。
さらに、大量生産するための土地や工場、機械が必要なので、膨大な額の設備投資という資金も必要。
半導体産業が典型例だろう。
一方、ソフトウェア開発は、大量生産と言うよりも、個別受注生産して、その製品を長く保守することで売上を確保する。
つまり、ソフトウェア開発プロセスは、ビジネス上も保守プロセスの方が重要なのだ。
そのためには、BTSのように、ソフトウェア保守のために特化したツールが必要で、そんなツールがなければ効率化できない。
ソフトウェアの品質管理が低レベルと言っても、BTSチケットに本番障害を記録していけば、何らかのルールは見出だせる。
また、障害修正のワークフローは、仕様変更や派生開発、新規開発にも拡張できるので、BTSをしっかり運用できる開発チームは、他のプロセスにもすぐに馴染むと思う。
その考えの中に「チケット駆動開発」というアイデアも含まれる。
【4】個人的には、製造業で言われる5S活動(整理・整頓・清掃・清潔・躾)とか、3S(単純化、標準化、 専門化)という概念や活動は、ソフトウェア開発には適さないと思う。
たとえば、製造業の人は「標準化」という言葉が大好きで、確かに、生産プロセスでは標準化活動がすごく効果を持つ。
しかし、ソフトウェア開発に「標準化」という概念を適用しようとすると、すぐに標準化されたプロセスや技術は陳腐化してしまう。
プログラマの創造性を逆に阻害する遠因になりやすい。
製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索
そもそも、メーカーと無関係のソフトウェア企業で、5S活動を社内で推進している所はあるのだろうか?
5Sの順番にも意味がある、とか、3Sの順番にも意味がある、とか、そういうことまで理解して活動しているのだろうか?
少なくとも、日本の製造業の人たちは理解しており、そこまで細かく管理しているが、ソフトウェア企業はそこまでやっているのか?
たぶんやっていないし、創造性が重視される場のソフトウェア開発ではたぶん必要ではないかもしれない。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 掃き溜めの鶴を活かすマネジメント、それは強みSと環境Oを組み合わせたクロスSWOT分析と同じだ(2026.10.01)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
「Redmine」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
「ソフトウェア工学」カテゴリの記事
- AIが思考を代行する時代に人間が「知識を繋ぐ」固有の価値とは何なのか?(2026.10.12)
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代のソフトウェア開発者とはアーキテクトの役割として再定義される(2026.08.30)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
「チケット駆動開発」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)


コメント