日本海側で唯一のソフトウェアテストシンポジウム「JaSST'12 Niigata」開催レポート（その1）――品質と生産性を上げる方法

コミュニティ活動

» 2012/03/23

　こんにちは、第3バイオリンです。

　先日、日本海側で唯一のソフトウェアテストのシンポジウム「JaSST’12 Niigata」を開催いたしました。今年で2回目、今回もわたしが実行委員長を務めさせていただきました。

　おかげさまで今回も参加申し込みは満員御礼となり、当日は大盛況でした。それでは、実行委員長が見た「JaSST’12 Niigata」当日のご様子をお伝えします。

■日時と場所

日時：2012年3月16日（金）
場所：万代島ビル11階　NICO会議室

■今回のテーマ

　今回のテーマは「新潟発！ の品質を考えよう」です。

　去年の「JaSST’11 Niigata」の基調講演で、電気通信大学の西さんが「新潟がレベルアップして、他の地域が新潟を目指すようになってほしい」というお話をされました。今年はそれを踏まえて、他の地域にはない、新潟ならではの品質のあり方とは何かを、参加者の皆さんと一緒に考える場にしたいと思い、このテーマを決めました。

■オープニングセッション

　さっそくオープニングセッションで実行委員長の挨拶です。去年の私は挨拶の内容を事前に考えずに舞台に上がる、という、無謀すぎることをやらかしてしまいました。それで叱られているのでさすがに今年は同じことはしない、と、事前に挨拶を考えてきました。

今回のテーマと、プログラムの概要紹介、それらについてのわたしの考えをまとめて挨拶としました。結局、普通の挨拶となりましたが、それでいいのです。

■基調講演「XDDPによる品質と生産性の同時達成」

　システムクリエイツの清水 吉男さんのセッションです。

　清水さんは「派生開発推進協議会（AFFORDD）」という団体の代表も務めています。その関係で「JaSST’12 Niigata」の前日にも新潟で派生開発のセミナーを開催してくださりました。

　JaSSTの基調講演のほうでは、清水さんは「生産性」をキーワードとして取り上げました。

　さて、今の開発案件は一から作り上げる「新規開発」はかなり少数派だと思います。開発案件の大部分を占めているのは、既存の製品の一部を改良したり、新機能を追加したりする「派生開発」です。

　派生開発は部分理解の世界です。ところが、プロジェクトの反省会ではよく「全体を理解できていなかった。だからうまくいかなかった」という言葉を聞くことがあるのではないでしょうか。

　清水さんは「この『全体』とはどこまででしょうか？ 何がわかれば『理解』できたといえるのでしょうか？ 『全体』『理解』どちらも定義できない言葉です。定義できないことは実現できません。だから結局、同じ失敗を繰り返してしまいます」と語りました。なかなか耳の痛いお話です。

　さらに、清水さんは「拙速なコード変更は人格を壊す」とも語りました。ずいぶん穏やかではないお話ですが、ひとつ例を挙げます。ソースコードを修正したあとで「もっといい修正方法があった」と気付くことがあると思います。しかし、それに気付いたとして、一度修正を加えたコードを再度修正することは、おそらくめったにないと思います。しかし安直なコード修正を繰り返していると、そのうち「動いているし別にいいや」という気持ちになってしまいます。こうして正しいことをできなくなる、顧客に対して後ろめたいことをしていることが、やがて人格をも蝕んでしまう、ということなのです（このあたりは、以前WACATEでお話してくださった「莫作の力（まくさのちから）」にもつながる気がします）。

　さて、ソフトウェア開発で利益を上げたいとき、まっさきに思いつくのがコストを下げることだと思います。とはいえ、人件費が安い国はたくさんあります。単純にコスト競争をしてもそのような国に勝てるわけはありません。かといって、そのような国にオフショアしてしまえばいいというわけでもありません。準備もなくいきなりオフショアしても、現場の混乱を招くだけで、コスト削減どころか品質の低下につながるからです。

　そこで重要になるのが「生産性」です。いくら品質が良くても生産性が悪いと利益は出ません。しかし、品質のデータを収集していても生産性のデータは収集していない、という現場がほとんどです。

　清水さんは、品質と生産性を両立する手段として、自らが提唱している派生開発プロセス「XDDP」を取り上げました。

　XDDPは、もとは海外の顧客の「3ヶ月で40数項目の機能追加と変更をお願いしたい」という要求に応えるために誕生しました。このとき対象となる製品の仕様を知る人は日本国内にはいませんでした。その状態では、今までの保守のやり方は通用しません。

　そこで清水さんは、機能追加と変更を分けて考えることにしました。変更依頼については変更前と変更後のシミュレーションを行い、その結果を顧客に送ってレビューしました。ようはレビューに顧客を巻き込んだわけです。

　ここで「追加要求と変更要求、2つも仕様書を書くの？ 手間じゃない？」と思われる方もいらっしゃると思います。確かに、仕様書を書くことは楽ではないし、工数もかかります。しかし、書き出すことでプロセス全体のどの部分の工数が減るか、わかるようになります。なにより、きちんと書くことで意味がわかるようになり、また、あいまいな点がどこなのか明確になります。プロジェクトの関係者が実現したいものについて認識を特定できているか、関係者全員が同じものをイメージできる状態にあるか、これが大事なのです。

　その後は設計書まで作成してレビューも終わり、必要な工数も確認されたところではじめて、ソースコードを一気に変更します。変更するべきところを一気に変更することが、ソースコードを劣化させずに長持ちさせる秘訣なのです。

　ただし「もとから作りこまれた品質は変わらない」と清水さんは語りました。テストで品質が上がるわけではないのです。

　例を挙げると、品質とは川の水質で、テストは川に流れたゴミを拾うようなものです。ゴミを拾うネットの網目を小さくしたり、ネットを張る位置を工夫したりすればゴミはたくさん取れます。しかし川の水が濁っていたり、有害物質が溶け込んでいたりという水質の問題はネットではどうしようもありません（もちろん、テストだって手当たり次第にネットを張ればいいというものでもありません）。

　ただ、製品の保守性というものは外から見えません。製品の機能は、製品を分解すればわかりますが、保守性は部品を見るだけではわかりません。それだけに保守性は真似をされにくく、製品の競争力に貢献できるのです。

　最後に清水さんは、「今日、製品を差別化するのはソフトウェアです。製造拠点を海外に移転することになっても、ソフトウェアは国内で作ることができて、国内で利益を上げられます。XDDPを使うと一時的に工数は増えるけど、後で劇的に減らせます。日本のエンジニアの皆さんには、国内のソフトウェア産業を盛り返してほしい」と締めくくりました。

　清水さんの講演から、新潟のエンジニア、ひいては日本のエンジニアに生産性を意識した賢い開発と、顧客にまっすぐ向き合う気持ちを心がけてほしい、そうして日本のソフトウェア産業をもっといいものにしてほしい、という熱い想いが伝わってきました。

　「JaSST'12 Niigata」第1回目のレポートはここまでです。次回は、事例発表3件のうちの2件の内容をお届けする予定です。