テストエンジニア時代の悲喜こもごもが今のわたしを作った

「ソフトウェア品質シンポジウム2011」に参加しました

»

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

 今月のはじめに、「ソフトウェア品質シンポジウム2011(SQiP2011)」に参加しました。わたしの会社から毎年2名ほどの社員が参加しており、わたしも行ってみたいと上司に伝えたところ、ありがたいことに許可が下りました。

 シンポジウムといえば、これまでソフトウェアテストのシンポジウム「JaSST」には何度か参加したことがありましたが、そちらとはまた違った気付きがありました。

■ソフトウェア品質シンポジウムとは

 「ソフトウェア品質シンポジウム」とは、その名のとおり、ソフトウェア品質に関わるすべての人が、品質についての技術や経験、ノウハウ、研究成果の発表や意見交換を行う場です。ソフトウェア品質に関するイベントとしては日本最大級のものだそうです。

 ソフトウェア品質シンポジウムは、「SQiP(Software Quality Profession 「スキップ」と読みます)」という団体が中心となって開催されています。SQiPはソフトウェア品質の研究・教育を通して、ソフトウェア品質の向上を目指すために構成された団体です。テーマごとに設けられた分科会で研究や勉強を行ったり、「Quality One」というWebマガジンを発行したり、「ソフトウェア品質のホンネ」というコラム風の記事を連載したりしています。

■日時と場所

  • 日時:2011年9月7日~9月9日
  • 場所:早稲田大学 西早稲田キャンパス

 7日はチュートリアルで、8日と9日が本会議というスケジュールでした。わたしは本会議の2日間だけの参加でした。

■基調講演「ソフトウェアにおける作るモノの世界と使うコトの世界」

 SRA 先端技術研究所の中小路 久美代さんのセッションです。

 ソフトウェアを作るときは、使う人の気持ちや使いやすさを考えるのが大切です。しかし中小路さんは最初に「『作るモノの世界』と『使うコトの世界』はまったく別のもの。単純にひとつの世界の表と裏、問題と解答という類のものではない」とおっしゃいました。つまり、作るためのスキルや知識と、使うためのスキルや知識はまったく別物ということです。

 ここで中小路さんは、「インタラクションデザイン」のお話をしました。インタラクションデザインとは、ソフトウェアを使うことでユーザーに何を体験してほしいか? をデザインすることです。インタラクションデザインを担当するデザイナーは、ソフトウェアを使うシナリオやストーリー、画面遷移やフローを作るのですが、このとき重要なのは、「面白いこと」だけでなく「つまらないこと」や「地味なこと」も一緒に考えることだそうです。さらに、UIだけでなく、プログラムの設計や実装レベルのことも同時に考えているそうです。そのため、デザイナーはよくプログラマとユーザーの橋渡しの役割を果たしていると中小路さんはおっしゃいました。

 最後に、中小路さんは「『使うコト』のデザインをする人は、プログラムの道理、プログラムでできることとできないことを知らなくてはいけない。同時に、『作るモノ』を担当する人も、使うコトの世界の事情を知っておく必要がある」と締めくくりました。

 わたしはどちらかというと「作るモノの世界」の人間ですが、自分の担当以外のことだから知らなくていいというわけではない、というお話にはドキッとしました。

■品質ざんまいのセッション

 2日間でわたしは、企業やコミュニティ活動の取り組み、SQiPの分科会の研究発表のセッションに参加しました。JaSSTとは違い、品質教育や開発プロセスの改善、テストも含めたより広い範囲がテーマとなっていました。

 どの発表からも、現場のリアルな声、品質についての熱い思いを感じることができました。全部は紹介しきれませんが、例えば東京証券取引所のシステム開発プロジェクトの発表では、発注者側とベンダ側それぞれのメンバーの取り組みの工夫や、開発秘話を聞くことができました。特に、自分たちプロジェクトチームに合わせるために、既存のプロセスをカスタマイズしたエピソードには感銘を受けました。

 また、ワークショップや勉強会の主催者が、参加者のグループ分けにデータを活用する様子、遠隔地のメンバーとリアルタイムでコミュニケーションを取りながら勉強を進めていく様子を聞いて、普段なにげなく参加しているワークショップにも見えないところにいろいろな工夫があるのだと気がつきました。

■SIG(Special Interest Group)

 SIGとはテーマ別に参加者がグループになって、悩みや課題について語り合うセッションです。わたしは、「テストの壁をぶち破れ!」というグループに参加しました。

 このグループでは、ラルフチャートというテスト技法についてのワークショップを行いました。銀行のATMシステムについて、入出力、システムの状態遷移、システムの動きを妨害するノイズを書いていきました。

 わたしは普段、状態遷移図を書かないのでそこのところで苦戦してしまいました。どうしてもUIの遷移と、システムの内部状態の遷移がごっちゃになってしまうのです。ラルフチャート作成後のディスカッションで、他の参加者から「いっそのことUIと内部状態は別にして考えてみれば?」という指摘で、その手があったかと気付きました。

 ワークショップのいいところは、自分だけで分からないところについて、他の参加者の意見やアドバイスをすぐに伺えるところですね。

■特別講演「日本の宇宙開発最前線を語る ―日本の基幹ロケットH-IIA/H-IIBについて―」

 有人宇宙システムの前村孝志さんのセッションです。

 前村さんは、最初にロケットの歴史と、ロケットが担う役割について説明しました。日本においてロケットは人工衛星、つまり人々の生活に必要不可欠なものを運びます。さらに、ロケットの製作と打ち上げには莫大なコストがかかります。ロケットの打ち上げは国家プロジェクトであるため、そのコストは税金でまかなわれることになります。おまけに、世間からも注目されます。もし失敗したら、その損害は計り知れません。

 前村さんは「失敗せずにロケットを確実に飛ばす」ための品質管理について語りました。高い品質を維持するためには、まず開発に携わる人が品質について高い意識を持つことが大切です。そのために、作業者に自分で品質維持のためのテーマを宣言させて、それをロケットの脇に貼って毎日見るようにしているそうです。

 前村さんは、ロケット開発は「世界一の仕事」であること、プロフェッショナルであることに誇りと責任を持つこと、そのために妥協と甘えは許さないことを強調しました。

 ロケットとそれ以外のシステムを同じレベルでとらえることは難しいと思います。しかし、まず作業者が品質について高い意識を持つことが、高い品質を作るというお話には納得しました。

■クロージングパネルディスカッション「これからのソフトウェア品質エンジニアリング」

 SQiP2011の最後を締めくくるのはパネルディスカッションでした。

 タイトルの「ソフトウェア品質エンジニアリング」という言葉ですが、実際にこういう言葉が定義されているわけではありません。

 ソフトウェア品質のエンジニアリングとは何をすることか、これからソフトウェア品質はどのような方向に進んでいくか、をパネリストと、会場の参加者みんなで考えました。

 バグを見つけるだけでなく「品質を開発する」という積極的な姿勢、どんなバグがあるか想像力を働かせる、品質を作るための仕掛けや仕組みはどういうものか……etc. テーマが広く、抽象度の高いものだったので、パネリストだけでなく会場の参加者からもいろいろな意見が出ましたが、まとめるのが難しい内容だったと思います。

 ところで、このパネルディスカッションでは、特別講演の講師を務めた前村さんがアドバイザとしてパネリストと一緒に壇上に並んでいました。パネリストの皆さんの議論を聞いていた前村さんの「ソフト屋さんはソフトが新しくなるたびに説明してくれるけど、その説明がいろいろと変わる。こちらは内心『本当に大丈夫?』と不安になることがある。ただ口だけで『大丈夫』と言われてもそれだけでは安心できない、それをきちんと証明してほしい」という言葉に、一瞬パネリストが全員黙り込んでしまうという一幕がありました。

 ソフトウェアの専門家ではない方の率直なご意見というのは、ときに鋭く本質を突いた恐ろしいものであることを実感しました。

■2日間を通して

 この2日間で、テストだけでなく、品質や開発プロセスといった、もっと広い範囲からソフトウェアの品質を向上させていくという視点を持つことができました。

 以前、ある方から「テストだけでなく、品質全般にまで自分の守備範囲を広げたほうがいい」という言葉をいただいたことがあるのですが、いつかテストだけでなく、もっと大きい部分の品質改善に取り組みたいと改めて思いました。

 2日間、とても楽しかったです。会場でお会いしたすべての皆様に感謝します。

Comment(4)

コメント

ohym

品質に関するシンポジウムとは、なかなか興味深いですね。
テストの目的のひとつであると思いますので、先に品質について考える方が正道かもしれないと思いました。
インタラクションデザインは所見ですが、広義の要件定義でそうとは意識せずに行っていることとは違うのでしょうかね。

第3バイオリン

ohymさん

コメントありがとうございます。

>テストの目的のひとつであると思いますので、先に品質について考える方が正道かもしれないと思いました。

そうですね。
私も、テストは品質の一部分であり、品質を実現する手段のひとつだと思います。
どのような品質を実現するかはプロダクトの特性によるところもありますし、(あと、コストや政治的判断なども)
そのあたりも含めて先に品質を考えて、それを保証できるテストや開発プロセスを考えることが大事になると思います。

今回のSQiP2011のセッションでは、まさにいろいろな種類のプロダクトの品質と、それに関わる人たちの努力や工夫のお話を聞くことができました。
意外と、自分が普段扱っているプロダクト以外のことってこういう機会でもないと聞くことないんですよね。

>インタラクションデザインは所見ですが、広義の要件定義でそうとは意識せずに行っていることとは違うのでしょうかね。

ペルソナを使ったシナリオテストなどが、これに近いものがあるかもしれません。
単にプロダクトをどう使いこなすか、使い心地はどうかということだけでなく、
プロダクトを使うことでユーザーがどうなるか、どう感じるか、をデザインするのがインタラクションデザインというようなお話でした。

すと

当日の様子はtwitterで見ていました。
コラムからも当日の充実ぶりがうかがえます。

前村さんの質問に対して、TLではユーザーが求める品質に対する回答が議論されていましたが…第3バイオリンさんはどう思われましたか?

もし品質をどこで担保しているかの具体性を説明する場面に遭遇したら…

明日は我が身、これは自分自身に対する質問でもあります。

第3バイオリン

すとさん

コメントありがとうございます。

>当日の様子はtwitterで見ていました。
>コラムからも当日の充実ぶりがうかがえます。

ありがとうございます。とても充実した2日間でした。
私も後からTwitterでハッシュタグを追ってみましたが、
参加者それぞれにとって密度の濃い時間だったことがわかりました。

>前村さんの質問に対して、TLではユーザーが求める品質に対する回答が議論されていましたが…第3バイオリンさんはどう思われましたか?
>もし品質をどこで担保しているかの具体性を説明する場面に遭遇したら…

前村さんのコメントは、ユーザーとしてもっともなご意見だと思います。
「このソフトウェア製品は安全です」「十分テストしました」ということを
ソフトウェア専門外の方に納得していただけるように説明するにはどうすればいいか、
ある意味ではエンジニアの永遠のテーマだと思います。

そのための方法としては、月並みな意見ですがテストについてエビデンスを取り、わかりやすい形で説明できるようにすることでしょうか。
あとは会場でも挙がっていたことですが、日ごろから顧客との信頼関係を結ぶ努力をすることでしょうか。
「○○さんがそう言うなら」みたいな話がソフトウェア業界において、どこまで通用するのかは正直なところわかりませんが。

コメントを投稿する