プログラマの思索

「品質・バグ管理はなぜ必要なのか」という質問があって、回答が面白かったのでメモ。
以下は、深く考えずにラフなメモ書き。

【参考】
Redmine - 品質・バグ管理の必要性についてご意見をお聞かせください。(10612)｜teratail

BTSを制する者がソフトウェア開発を制する: プログラマの思索

akipiiさんのツイート: "数人の回答が面白い。僕なら「BTSを制する者がソフトウェア開発を制する」という言葉で回答するかな。「品質・バグ管理の必要性についてご意見をお聞かせください。故障票などに記載（Redmine的なものです）」 https://t.co/L5LKK7hDEd #teratail"

【1】(引用開始)
タイトル通りですが、品質管理・バグ管理の必要性について質問させてください。
個人的には、「100%必要ない！」とは思っていませんが、厳重に管理したバグ票やらを必死に分析して最終的に何に使うのでしょうか？
(中略)

例えば、「あるexceptionによるシステムエラー」が起きたとしたら
１.なぜバグが起きたのか？
→exceptionをキャッチしていない
2.なぜcatch文をいれていないのか？
→設計書から見落とした
3.なぜ見落としたのか？
→凡ミス
4.なぜ凡ミスが起きたか？
→疲れていた、作業効率の低下、特に理由なし

ここで最後の回答をしたところで、管理者は「なるほど、気をつけて」としか言いようが無いし、作業者としても「疲れていた」とは言いにくいものもあります。
バグの内容にもよりますが、明らかに大したバグではない、凡ミスのようなものに追及していく必要はあるのでしょうか？
それより、さっさと改修しても良い気もします。
一つの現場だけでなく、だいたいどの現場も同じ漢字なので不思議です。
(引用終了)

ソフトウェア開発でバグ管理が重要な理由は、障害管理のプロセスがソフトウェア開発の全てのプロセスの根幹をなすからだ。
つまり、BTSを使いこなす者はソフトウェア開発を制する。
以前、Blogにその考えは書いた。

BTSを制する者がソフトウェア開発を制する: プログラマの思索

Bugzilla、MantisからTrac、Redmine、Jiraに至るまでのBTSには、世界中のソフトウェア開発者のベストプラクティスが埋め込まれている。
だから、できるだけ最新のBTSに慣れた方がソフトウェア開発のスキルも向上できるはず。

【2】なお、製造業の品質管理とソフトウェアの品質管理は別物とみなした方がいいと最近は思っている。
製造業の立場から見れば、ソフトウェアの品質管理は、正直笑ってしまうぐらいの低レベルと思えてしまうだろう。

製造業の品質管理が知りたいなら、たぶん、QC検定２級レベルの知識を一度見てみればいいと思う。
彼らは、大量生産される工業製品の品質管理を統計学的手法で、細かな部分までコントロールしようとしている。
統計学における仮説検定、相関・回帰分析などが必要とされるので、相当にレベルは高い。

QC検定とは？ | 一般財団法人　日本規格協会

QC検定2級って奴 受けてみた - Pass Hunter

製造業の品質管理は、管理図を使って、製品の規格のばらつきを抑えるように、工程や作業を改善するのが王道だと思う。
たとえば、ネジを作っていて、そのネジの大きさや長さにバラつきがあれば、どの作業工程でそのバラつきが発生したのか、どの人が担当するとばらつきが大きいのか、などを細かく突き止め、原因を把握して、作業方法を改善していく。

一方、ソフトウェアの品質管理は、製造業の品質管理を真似ようとして色々試されているが、そのレベルまで到達しているようには思えない。

とは言え、ソフトウェア工学では経験則としていくつか知られている知見はある。
たとえば、人月の法則とかコンウェイの法則、リーマンの法則とか。

リーマンの法則～ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

【3】製造業とソフトウェアの品質管理が全く違うように思える理由は、生産プロセスが全く違う観点で存在するからではないかと思う。
製造業は徹頭徹尾、WF型開発のように、生産計画重視で大量生産が王道。

大量に仕入れして原材料費を安く交渉し、大量に販売して売上を大きく稼ぐ。
大量生産するには、見込生産が必要で、そのためには、どの程度の需要があるか、計画段階で決めなければならない。
さらに、大量生産するための土地や工場、機械が必要なので、膨大な額の設備投資という資金も必要。
半導体産業が典型例だろう。

akipiiさんのツイート: "アジャイル開発はソフトウェア開発特有の考え方。製造業とは全く違う。 @koshian: アジャイルもスクラムも日本の製造業から来たものなのになぜ日本始めアジアで普及しないと言われてしまうのか。アジャイルはなぜアジアで普及しないか” https://t.co/2UtpidH2zo"

akipiiさんのツイート: "アジャイル開発が日本で普及しない原因の一つは、予算取りや設備投資の発想にあると思う。製造業は、工場への設備投資で、規模の生産性を生かして、大量に安く作り、市場を独占して先行者利益を得たい。政府も、設備投資は不景気のカンフル剤として有効だから、金利を下げて煽る。"

一方、ソフトウェア開発は、大量生産と言うよりも、個別受注生産して、その製品を長く保守することで売上を確保する。
つまり、ソフトウェア開発プロセスは、ビジネス上も保守プロセスの方が重要なのだ。

そのためには、BTSのように、ソフトウェア保守のために特化したツールが必要で、そんなツールがなければ効率化できない。
ソフトウェアの品質管理が低レベルと言っても、BTSチケットに本番障害を記録していけば、何らかのルールは見出だせる。
また、障害修正のワークフローは、仕様変更や派生開発、新規開発にも拡張できるので、BTSをしっかり運用できる開発チームは、他のプロセスにもすぐに馴染むと思う。
その考えの中に「チケット駆動開発」というアイデアも含まれる。

【４】個人的には、製造業で言われる５S活動(整理・整頓・清掃・清潔・躾)とか、３S（単純化、標準化、 専門化）という概念や活動は、ソフトウェア開発には適さないと思う。

たとえば、製造業の人は「標準化」という言葉が大好きで、確かに、生産プロセスでは標準化活動がすごく効果を持つ。
しかし、ソフトウェア開発に「標準化」という概念を適用しようとすると、すぐに標準化されたプロセスや技術は陳腐化してしまう。
プログラマの創造性を逆に阻害する遠因になりやすい。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

そもそも、メーカーと無関係のソフトウェア企業で、５S活動を社内で推進している所はあるのだろうか？
５Sの順番にも意味がある、とか、３Sの順番にも意味がある、とか、そういうことまで理解して活動しているのだろうか？
少なくとも、日本の製造業の人たちは理解しており、そこまで細かく管理しているが、ソフトウェア企業はそこまでやっているのか？
たぶんやっていないし、創造性が重視される場のソフトウェア開発ではたぶん必要ではないかもしれない。