新潟初のソフトウェアテストシンポジウム「JaSST'11 Niigata」開催レポート（その2）――品質向上を生み出すのは人の力
こんにちは、第3バイオリンです。
まずは、東北地方太平洋沖地震の被災者の皆様に、心よりお見舞いを申し上げます。
ほぼ同じ時期に、わたしが住んでいる新潟でも大きな地震がありました。幸いにもわたしが住んでいる地域に大きな被害はなかったのですが、同じ新潟の中越、上越地域は大変な被害をこうむったようです。先月開催した「JaSST’11 Niigata」の参加者のなかにも中越、上越の企業の方がいらっしゃいました。その方たちの安否が心配です。
今回は、「JaSST’11 Niigata」レポート第2弾です。地元新潟の企業による、事例発表の様子をお届けします。読んでくださる方が、少しでも楽しんでくださると嬉しいです。
■事例発表1 「組織としての開発力および品質力向上への取り組み」
キヤノンイメージングシステムズの遠藤良夫さんの発表です。
遠藤さんは、まずソフトウェアの管理の難しさについて言及されました。ソフトウェアは目に見えるものではなく、全体像がつかみにくいところがあります。そして、しょっちゅう変更する要求に翻弄されるというのもよくある話です。また、ソフトウェアの開発には、個人の能力に依存する部分がまだまだ存在しています。
そのような状況の中で、遠藤さんはソフトウェア開発のプロセスの改善に着目しました。そこでCMMIをベースとしてプロセス改善のための社内規程を作り、プロセス改善を推進するための事務局を設立しました。
事務局の設立にあたり、遠藤さんは「事務局にテスト担当の社員を入れる」「プロセスの目的、意味を明確にする」ことを心がけました。事務局にテスト担当の社員を入れるということで、開発者だけでなく、テスト担当者の意見も取り入れやすくなるからです。また、プロセスの目的や意味を明確にすることで、現場の社員が「やらされ感」だけでやることを防ぐことができます。
さらに、プロセス改善の規程を作るだけでなく、それがきちんと守られているかどうかを検証する監査グループも設立しました。しかし、ここで思わぬ問題が立ちはだかりました。
監査グループ側は「きちんと監査しなくてはならない」と、開発者に監査用のドキュメント作成を要求しました。ところが、多忙な現場で働く開発者からは「ただでさえ忙しいのに、ドキュメントを作るのは手間がかかる」という反論が多く寄せられ、監査グループと開発者が対立する状態になってしまいました。
監査グループも開発者も「ソフトウェアの品質を向上させたい」という目的は同じはずなのに、対立してしまっては何にもなりません。そこで、監査グループが、プロジェクトの進捗状況に合わせて、ドキュメント作成からレビューまでフォローしながら監査するというスタイルを取るようにしたところ、監査グループと開発者の対立もおさまり、失敗プロジェクト（QCD目標が達成できなかったプロジェクト）が年々減少していったそうです。
監査の成果は見えてきましたが、プロセスを改善しても、下流工程のバグがなかなか減らないという状況が続きました。そこで遠藤さんは、Wモデルを取り入れることにしました。
遠藤さんは、「テスト方針書」というものを導入しました。これは、テストの方針、計画や実施方法、重点的にテストするポイントなどを開発とテスト部門の双方が意識合わせするためのドキュメントです。
テスト方針書の導入前は、開発内テストのやり方はプロジェクトごとにバラつきがありました。しかも開発内テストと、テスト部門で実施するテストの整合性が取れずに双方で同じようなテストをしてしまうといったムラやムダがたくさんありました。
しかしテスト方針書を作ることで、テスト部門が実施するテストだけでなく、開発内テストについても実装前に方針を固めて、それを満たす実装ができるようになります。その結果、バグを作りこむのを防ぐことができるというわけです。
さっそく、いくつかのプロジェクトでテスト方針書を使ったWモデルを試験的に導入しました。すると、導入前は外部設計と内部設計のバグが全体の6割を占めていたのが、4割に減少したそうです。今後もバグ数を減らすとともに、社内のすべてのプロジェクトでWモデルを導入することが目標だそうです。
わたしも、自分の会社で監査と現場の対立のようなことを目の当たりにしたことがあります。それを乗り越えるための知恵と、現場に歩み寄る姿勢が大切であることに、改めて気がつきました。最後に遠藤さんは、「今後もJaSSTという場で情報を発信・共有したい」と締めくくりました。こちらこそ、よろしくお願いします。
■事例発表2 「『おめさん、なじらね？』 - 派生開発でUSDMとDRBFMをミックスして一気通貫で品質確保する - 」
NECソフト新潟支社の酒井賢さんの発表です。
タイトルにある「おめさん、なじらね？」とは、新潟の方言で「お前さん、調子はどうだい？」という意味です。特に、「なじ」とは、相手に対する気遣いを含む言葉だそうです。非新潟県民のわたしにとってもためになる説明でした。
実は事前に酒井さんからタイトルについてご相談があったのですが、最初にこのタイトルを見たときはちょっと驚きました。しかし、酒井さんの「せっかく新潟で開催するのだから、新潟らしさを出したい」という心意気に打たれ、「ぜひそのタイトルで！」とこちらからお願いしました。
酒井さんの業務は、オフィス機器と通信して動作するためのユーティリティソフトの開発です。もともとは、顧客が新規開発したものを保守として引き継ぎ、機種対応やメンテナンス、特定用途向けの開発を行っているそうです。いわゆる「派生開発」です。
引き継いだ当初、提供された成果物はソースコード、実行モジュールとヘルプのみで、仕様書はありませんでした。酒井さんは、成果物をリバースエンジニアしながら仕様書を作成していったそうです。
そんな状態ですから、プロジェクトには問題点が山積みでした。例えば、仕様が作られた経緯がわからずに互換性の維持するための設計が必要になる、ソースコードに手を入れたときの影響範囲がわからない、などなど。
そこで酒井さんは、問題発生を未然に防止するための課題を洗い出し、それを解決するためにUSDM表記法とDRBFMを取り入れることにしました。USDM（Universal Specification Describing Manner）表記法とは、要求の中に含まれる動詞をベースに、要求と仕様を階層構造で表現する手法です。一方、DRBFM（Design Review based on Failure Mode）とは、設計の変更によって引き起こされる不具合を、デザインレビューを通して洗い出すための手法です。
まずは、USDMをベースに「変更要求仕様書」というものを作成しました。これは、システムに対する要求を階層構造で表現することで、仕様の漏れを防ぐためのドキュメントでした。
変更要求仕様書を導入するにあたって酒井さんが心がけたのは「徹底的なレビュー」でした。そのときのポイントは「どこを直すか」ではなく「どのように動作するべきか」を挙げていったことです。出てきた要求はすべてExcelで1つのシートにまとめました。あえてそうすることで、規模の大きさを直感的に分かるようにするためです。
そうして、顧客も交えてメンバー全員でレビューをすることで、要求の真の理由を把握することができました。また、顧客のほうからも変更要求か、仕様かを明確に示してくれるようになったという思わぬ副産物も得ることができたそうです。まさに、顧客も巻き込んだ「高カイゼン戦略」を実現できたわけです。
さらに、酒井さんは「心配点シート」というものを導入しました。これはDRBFMシートをより簡潔にしたもので、要求に対する心配点を挙げることで、それを取り除くためにどのような設計をしたかを明確にするためのシートだそうです。
この心配点シートを活用することで、設計段階で多くの問題を検出できるようになったそうです、さらに、心配点シートを使うことでチームのコミュニケーションが活発になり、ベテランの経験が若手に伝わりやすくなったそうです。チームのコミュニケーションが活発化したことで、自然と「フォロワーシップ」も実現できるようになったそうです。
酒井さん自身も、「このメンバーと規模であれば百戦百勝！ とまではいかないものの、90勝くらいなら勝てる自信が持てる」と思えるほどの手ごたえだったそうです。
最後に酒井さんは、新潟の雪かきの話をしました。新潟に暮らす人にとって、雪かきは冬の大切な仕事です。屋根の上の雪を下ろすときは、危険予知と経験で屋根から落ちるといった危険を未然に防止します。また、雪道では転んだりしないように先を見ながら歩き、状況に合わせてシャベルから除雪車といったさまざまなツールを使い分けています。そして何より大切なのは思いやりと助け合いです。昔から、新潟には「雪かきは、自分の家の前だけでなく、隣の家の半分も一緒にやる」という暗黙のルールがあるそうです。
酒井さんは「品質向上は雪かきのようなもの」と語りました。冬の間、毎日のように雪が降ると、雪かきというのは本当にきりがない作業です。しかし、放置すれば家が潰れたり道路が埋もれたりして大変です。
しかし、それでも春は必ずやってきます。
また、さまざまなツールを使いながらも、品質向上は「人」が主役であること、最終的には、人にしかできない思いやりや助け合いといった「なじらね」の心にあると思うと締めくくりました。
酒井さんの発表を聞いて、今、自分たちに何が必要かを見極め、それに合ったツールを創り出すための知恵と工夫に感銘を受けました。そして、それ以上に、人の力、チームの力をうまく引き出すことの大切さを感じました。
また、最後の雪かきの話も、新潟らしくていいなと思いました。今年は3月の半ばになっても、まだ雪が降るような気候です。今年の冬将軍が手ごわいのか、それとも春がもったいぶっているのかはわかりません。それでも、必ず春が来るとわかっているから、厳しい冬を乗り越えられる、そう思いました。
既存のプロセスを会社やプロジェクトに取り入れるときに、そのまま取り入れると大抵うまくいきません。自分の組織に合う形にカスタマイズする工夫が必要です。遠藤さんの発表でも、酒井さんの発表でも、それぞれの工夫が語られていました。しかも、うまくいったお話だけではなく、苦労したお話と、それを乗り越えていったお話があったことで、リアルで身近な「等身大」の内容だったと思いました。
また、西さんの基調講演で取り上げられた「Wモデル」「高カイゼン戦略」「フォロワーシップ」といったキーワードが、遠藤さんと酒井さんの発表につながっていたような、そんな印象を受けました。
レポート（その2）はここまでです。次回は最終回、クロージングパネルと情報交流会の模様をお送りします。
それから、「JaSST' 11 Niigata」のレポートページがJaSSTのサイトにアップされました。当日の様子を撮影した写真や、発表資料が閲覧できます。こちらも、よろしくお願いします。