不況時のプロセス改善 - 脱ノルマ -

少し前になりますが、TV東京系の経済番組(WBS)で「脱ノルマ」という特集をしていました。不況が迫る中、ノルマを課して売り上げアップを狙っても限界があるので、ノルマをやめて利用者に好まれる販売に徹する様にしてリピータを増やしたというお話でした。これまでならノルマを考えて、推奨品や高額品を進めていたが、お客様に最も喜ばれる商品を勧めることができるようになったというお話でした。

さて、これをソフトウェア開発に当てはめるとどうなるでしょうか？ノルマと言うのはやはり生産性や経済性になるでしょう。そしてその延長の品質向上だと、手戻りが少なくなるような信頼性の向上と言うことになるでしょう。

そして、脱ノルマプロセス改善に当てはめるなら、顧客重視と言うことでしょう。品質＝信頼性ではなく、品質＝顧客満足となるような品質向上が必要なのでしょうね。そこでの問題をなぜなぜ分析してフロントローディングすると、結局は要求を如何に引き出すか、如何に顧客との信頼関係を築いて協力してもらうか、と言うところが改善のポイントになるような気がします。キーワードとしては、プロトタイピング、アジャイルのほか、狩野モデルあたりでしょうか。

Ideapad S9e で Windows 7 のチェック

知り合いがDell mini9にWindows 7を入れたそうで、S9eでもWindows 7が動くのか、ちょっと気になっていました。すると、Windows 7が動作するかをチェックしてくれる
Windows 7 Upgrade Advisor Betaなるものが出たとの記事(リンク先はINTERNET Watch)を発見。私のS9eで動かしてみました。

バックアップしろとか動かないプログラムがあるとかは言われますが、システムもデバイスも問題なｼでした。

システムはメモリーも2GBに増設しており、最低限の1GBをクリアしていました。

デバイスは以下のものが確認されました(複数続くときはx2などで表しています)。

Realtek High Definition Audio
Broadcom NetLink (TM) Fast Ethernet
Broadcom 802.11g ネットワーク アダプタ
Mobile Intel(R) 945 Express Chipset Family (x2)
Intel(R) 82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller
Intel(R) 82801G (ICH7 Family) USB Universal Host Controller (x4)
Intel(R) 82801G (ICH7 Family) USB2 Enhanced Host Controller
Intel(R) 82801G (ICH7 Family) Ultra ATA Storage Controllers
USB ルート ハブ(x2)
USB 複合デバイス
Broadcom 2046 Bluetooth 2.1 USB Dongle
Realtek Card Reader(0158)

プログラムでは、EMONSTER用に導入したActive Syncがだめで、他はアップデートしろとのこと。Windows 7とWindows Mobileの接続が気になるところです。

外部接続機器も繋げてチェックしたほうが良かったのでしょうけど、まあ、何とかなりそうなのでひとまず安心しました。

さて、S9eのその後ですが、最近はファンの音が気になる時があります。常時動いてくれればなれるのですが、状態によっては2-3秒ごとにファンがON/OFFするときがあって、静かに作業しているときは、妙に気になります。

BIOSアップデートで改善されたとの書き込みもあるのですが、今は公開されておらず、しばらく我慢するしかないようです。orz

不具合摘出工数 - SEA関西プロセス分科会 -

ソフトウェア工学やプロセス改善に大きくかかわるのが、不具合摘出工数です。先日のSEA関西プロセス分科会の秋山先生のTSP/PSPの講演でも話題になりました。

コードレビューなら1欠陥を修正するのに2分ですむが、単体テストなら32分、システムテストなら1405分かかると言うものです。これは、バグを修正する時間だけでなく摘出する、つまりテストの時間を含めてバグ数で割ったものだそうです。

メアリー・ポッメンディーク他,リーンソフトウェア開発,p.82-84, 日経BP社, 2004.のよると、スパイラルモデルやアジャイルと規律で有名なベーム先生が言いだしっぺのようで、リリース後は開発中の100倍だとか5倍だとかの工数がかかると言われているようです。

秋山先生によれば、バグを見つける工数も含むと言われるのですから、テストが進むにつれて、すなわち品質が向上するにつれてバグが見つかる確率が下がる、見つける工数が増えるのは当たり前ですよね。しかも、一度に結合してしまう(ことが多い)ウォータフォール開発では、バグを見つけてから除去するために、問題箇所を突き止めるのも難しくなるのは当然です。

アジャイル開発は、段階的に開発・テストをしますから、バグの入っていそうなところを中心(というか古いところは自動テストされるので発見工数が不要)にテストされるので、常にほぼ同じ確率で発見できるでしょうし、バグが見つかっても追加したコードがおそらく原因でしょうから、バグの除去にかかる時間も安定しているのでしょうね(まあ、アジャイル開発でも、規模が大きくなればそれなりに工数は増えますし、品質保証部門のテストがあれば工数もかかり、デバッグも難しいでしょうけど)。

さて、この後の工程ほどバグの修正にコストがかかるというのは、プロセス改善の基礎になっています。「フロントローディング」などと言う言葉がありますが、後の工程で発覚しないように、前の工程でバグをつぶすような活動です。後工程ほど工数がかかるのだから、早めに見つけるのは当然だし、途中の作業を飛ばすなんて言語道断と言うわけです。実際にテスト工程のどれかを飛ばしてみると、その意味が良くわかります(良い子はまねをしないでね)。

リリース後の品質が悪くて工数がかかって仕方がないなら、プロセス改善のチャンスです。改善結果が利益に直結するので、きっと楽しい活動になると思います。