先日(2014/06/06)は、SEA関西プロセス分科会に参加してきた。今回は、JAXA(宇宙航空研究開発機構) 情報・計算工学センター宮本祐子氏による講演だった。 このような状況の中、ソフトウェアの品質を確保するために、私たちは、米国航空宇宙局（NASA）や欧州宇…

一昨日(2013/4/19)はSEA関西プロセス分科会に参加してきた。講演は、オムロンソーシアルソリューションズ(株)幡山五郎氏による、自動改札機のテストの話だ。既に昨年の講演を取り上げた記事も出まわっており概要は知っていたが、今回は直接話しを聞くことが…

2012年もお終い。1年の終わりには、その年に作ったバグをふり返ってみることにしている。各マイルストーン毎にふり返りを行なっているとは言え、1年のまとめとして改めて総括してみると自分なりに反省点が多い。クローズしたチケットを遡りつつ、昨年の反省…

経験則に基づく話。ソフトウェアの品質評価を行う際には、全く未知の障害を見つけ出そうとはかない努力をするよりも、既知の障害に基づく評価を行う方が、費用対効果が高くて効果的ではないかと思う。新規の開発対象や言語、開発環境、ドメインを対象にした…

開発現場で問題の再発防止策を検討すると、その結論として出てくるものの一つにチェックリストが有る。曰く、このチェックリストに従って確認を行えば、同じような問題の発生を防ぐことができるし、誰でも同じレベルで作業を行うことが出来る。チェックリス…

日経ビジネスの2011年7月25日号に楽天ブックスでのシステムトラブル事例が載っていた。「単行本やDVD、CDなど200万点を扱う。現在1日約1億円を売り上げ、楽天にとって最大の店舗」（記事より）ということなので影響が大きく、アフターサービスランキングの「…

ある人から開発現場におけるプロセス改善活動の目的は何か？と聞かれたことがある。きれい事を言えば、成果物の品質向上であり、手戻り作業の削減や、前回の開発経験をフィードバックした効率的な作業ということになるだろう。もちろん、それはそれで間違っ…

ソフトウェアの開発プロジェクトが終わると、Tracには大量のチケットが生み出される。やれやれ、一件落着、こんな障害情報なんて見たくもないという人が多いかも知れないけれど、実はこの情報は次の開発に生かすべきヒントを含む重要な情報だと思っている。…

2010年度上半期の開発まとめを読み返しつつ考えたこと。 以前に行ったふり返りでの反省事項をきれいサッパリ忘れている。 何を作るべきか最終形が明確になっていないのにコードを書き進めている。 障害を発生させないための未然予防策を取っていない。 正常…

日経エレクトロニクス2010年9月20日号に、日本のソフトウェア品質に関するCusumano氏の寄稿記事が載っていた。Cusumano氏の著書は「ソフトウェア企業の競争戦略」しか読んだことが無いけれど、長年に渡ってビジネスの観点でソフトウェア業界をウォッチしてい…

GUIが絡むアプリケーションを作っていて困るのは、テストを意識せずにマニュアル通りの手順で作ってしまうと単体テストが容易に実行出来ない点だ。入力がGUI依存ではテストコードから上手く呼び出せないし、また処理結果をGUIに表示するような構成では人間が…

あるソフトウェア開発関係のイベントに参加した同僚に感想を聞いてみた。 特に目新しい情報は無かった。発表されている事例は当たり前のこと。やっていることは自社と変わらない。 それはその通りかも知れない。品質改善に関して全く新しいアイデアはなかな…

ソフトウェア開発の現場では、QCD（品質、コスト、納期）のバランスが重要と言われることがある。バランスと言っても、実際問題としてどれかを後回しにすることはあり得ないので、各項目について「それなりのレベル」を確保することが求められるが、コスト（…

あるiPhoneのアプリを見せながら年配の方に説明。「こんな機能があって、あんな事も出来て...」と自慢気に解説していたら、ソフトが異常終了してしまった。特に珍しいことではないし、目くじらを立てるほどの事でもないのだが、それを目撃した相手は嬉しそう…

ソフトウェア開発において、ありがちな品質対策の例。 テスト作業への人員追加 テスト期間の延長 テスト体制の見直し 経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローし…

上手くソフトウェア開発が出来るチームは、開発プロセスも良好だし、技術・スキルもそれなりに高いようだ。細かく見ていけば問題が無いわけではないけれど、それらは許容範囲内に収まっているし、絶えず改善活動を行っているせいか昨年の状態より良くなって…

終了した開発プロジェクトの問題分析を行っている。「バグの源流をたどれ」の如く、なぜなぜ分析で問題の根本原因を探り、抜本対策案をまとめるのが目的だ。さすがに限られた時間内で全障害を検証するのは不可能なので、優先度の高い問題のみをピックアップ…

「バグの無いソフトを作るためには、そもそもバグを発生させなければ良い」というのはid:rabbit2goの名言だけど、モグラ叩きの如くバグを潰していくだけの開発では、一向に品質は向上しない。そもそも、障害が発生するのは開発プロセスやエンジニアリングに…

かなり昔の記事だが、印象に残っているので取り上げる。ソフトウェア開発のバグに関して、記者はソースコードの記述を例にバグを減らすためには地道な努力と工夫が必要と訴える。 一つひとつは些細なものでも，習慣として実行することでバグは確実に減るはず…