ソフトウェア技術者へ
IT Pro の記事を読んで、思うところがあるので記事にしておきます。簡単な会員登録が必要なので、すぐに見れないかもしれませんがリンクは下記。メールアドレスの登録が必要ですが、広告メール等の類いは別に届きませんので、エンジニアの方は会員登録をお薦めします。
「日本のソフト産業にもう学ぶものはない」、品質管理の専門家が苦言
日本のソフト産業界が、全体的に品質低下してきていると記事には書かれています。私が生業としている組込みソフトウェアも例外では無い。日本の全てのソフトウェアが品質低下を起こしている可能性がある。
日立製作所などがメインフレーム向けに開発するアプリケーション・ソフトは、1000行あたりのバグ発生件数が、現在のオープン系システムの水準より2ケタ少なかった。 (記事中の斜体部は上記 IT Pro からの引用です)
これは驚異的じゃないですか？今よりもバグが２ケタも少ないなんて。仕事のほぼ全てをバグ修正に追われてはいませんか？それが２ケタも少ないなんて、こんな幸福なことはありません。
マシンの高速化でコンパイル時間が短縮されたこともあり、「とりあえず組んで、バグが出たら直せばいいや」といった安直な考え方が開発現場に染み付いてしまった。
耳が痛いです。正直、(1) 単純で静的な、ほぼテストサンプルに近いコードを最初に作成→ (2) 例外も含めて思いつく動作パターンにおける処理の作り込み → (3) テストを実施し気が付かなかった例外処理に対する処理を作成（バグフィックス）という工程でプログラムを作成してしまいます。プログラムの完成までは、このプロセスを行う事で最短で作成できるものの、品質を向上させる箇所がありません。エンジニアの経験によってバグに気が付く、気が付かないの差が発生しますし、プログラムの質が最初に作成したサンプルコードに依存するので、最後に根本思想の誤りに気が付いた時に後戻り出来ない状態に陥ります。
改善のポイントは三つある。まずは、開発の各段階でシステムの完成度を評価し、確実に不具合を潰す「評価技術」。二つめは、ユーザー企業の意図を汲み取り、用件定義をうまくまとめるための「要求分析」。三つめは短期開発に即した「プロセス・マネジメント」である。
「要求分析」と「プロセス・マネジメント」については、Software People という雑誌の Vol.4、Vol.5 で特集として取り上げられており、大変参考になります。Vol.4 は既に絶版ですが、バックナンバーを抱えている書店はまだあると思います。「要求分析」と「プロセス・マネジメント」について書かれた本は、それなりに販売されていますが、今ひとつ現場の業務に即していない気がして、あまり面白くないのですし、また、インターネットを探しても参考になる様な文献が見つかりませんが、Software People は、内容が現場よりなので、実際に手を動かしている現場の方にはお薦めです。
必要なのは危機感を共有することだろう。
私は開発とバグ修正に追われて、それ以外の事をしている暇なんて殆どなくて、まだまだですが、ちょっとでも空いている時間を見つけて本を読んだりして、品質向上の為に勉強を始めた所です。
後は、体たらくな会社やチームを動かす方法とかを教えてくれる参考書があればいいんですけどね…。
「日本のソフト産業にもう学ぶものはない」、品質管理の専門家が苦言
日本のソフト産業界が、全体的に品質低下してきていると記事には書かれています。私が生業としている組込みソフトウェアも例外では無い。日本の全てのソフトウェアが品質低下を起こしている可能性がある。
日立製作所などがメインフレーム向けに開発するアプリケーション・ソフトは、1000行あたりのバグ発生件数が、現在のオープン系システムの水準より2ケタ少なかった。 (記事中の斜体部は上記 IT Pro からの引用です)
これは驚異的じゃないですか？今よりもバグが２ケタも少ないなんて。仕事のほぼ全てをバグ修正に追われてはいませんか？それが２ケタも少ないなんて、こんな幸福なことはありません。
マシンの高速化でコンパイル時間が短縮されたこともあり、「とりあえず組んで、バグが出たら直せばいいや」といった安直な考え方が開発現場に染み付いてしまった。
耳が痛いです。正直、(1) 単純で静的な、ほぼテストサンプルに近いコードを最初に作成→ (2) 例外も含めて思いつく動作パターンにおける処理の作り込み → (3) テストを実施し気が付かなかった例外処理に対する処理を作成（バグフィックス）という工程でプログラムを作成してしまいます。プログラムの完成までは、このプロセスを行う事で最短で作成できるものの、品質を向上させる箇所がありません。エンジニアの経験によってバグに気が付く、気が付かないの差が発生しますし、プログラムの質が最初に作成したサンプルコードに依存するので、最後に根本思想の誤りに気が付いた時に後戻り出来ない状態に陥ります。
改善のポイントは三つある。まずは、開発の各段階でシステムの完成度を評価し、確実に不具合を潰す「評価技術」。二つめは、ユーザー企業の意図を汲み取り、用件定義をうまくまとめるための「要求分析」。三つめは短期開発に即した「プロセス・マネジメント」である。
「要求分析」と「プロセス・マネジメント」については、Software People という雑誌の Vol.4、Vol.5 で特集として取り上げられており、大変参考になります。Vol.4 は既に絶版ですが、バックナンバーを抱えている書店はまだあると思います。「要求分析」と「プロセス・マネジメント」について書かれた本は、それなりに販売されていますが、今ひとつ現場の業務に即していない気がして、あまり面白くないのですし、また、インターネットを探しても参考になる様な文献が見つかりませんが、Software People は、内容が現場よりなので、実際に手を動かしている現場の方にはお薦めです。
必要なのは危機感を共有することだろう。
私は開発とバグ修正に追われて、それ以外の事をしている暇なんて殆どなくて、まだまだですが、ちょっとでも空いている時間を見つけて本を読んだりして、品質向上の為に勉強を始めた所です。
後は、体たらくな会社やチームを動かす方法とかを教えてくれる参考書があればいいんですけどね…。