NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'12 Kansai

基調講演
「アジャイル開発とスクラム～顧客・技術・経営をつなぐ協調的マネジメント」
平鍋 健児 （チェンジビジョン）

基調講演の平鍋氏のセッションでは、新製品開発(ここではソフトウェア開発)において高品質な製品を作るために考えるべきことが多く含まれている内容であった。

1. なぜアジャイルか？

ウォーターフォールモデルの問題として、ビジネスを行う人とシステムを作る人のゴールが分断されていることや、システム要求ができてシステムを開発している間に市場が変わってしまったことにより、使われない機能ができてしまうことがあげられていた。また、アジャイル開発とウォーターフォール開発の比較を「爆弾をまわす処理」や「ケーキ(ホールとピース)」に例えて説明されていた。
「爆弾をまわす処理」の例は、ソフトウェア開発工程を「爆弾を各工程に渡す処理」に例えたもので工程を期限内に終えれば爆発しない。ウォーターフォールモデルでは、要求定義、基本設計などの各工程を経て爆弾を引き渡していく。問題なく期限通りにテスト工程を終えることができれば問題はないが、多くの場合テスト工程を終えることができず、爆発し、開発プロジェクトに大きな影響を与える。一方、アジャイル開発モデルでは、爆弾が爆発してもその影響が局所的であるために大きな失敗に至らないことが多く、また局所的な失敗を経験することで、開発工程内で反省と改善を行うことができる。また、ケーキの例では、ウォーターフォールモデルはデコレーションケーキをホールで提供すること、アジャイル開発モデルではピース単位に提供することという例えで説明されていた。ウォーターフォールモデルはホール単位に作るため、スポンジ部分、デコレーション部分など層に分けて作られていき、すべての工程が終わらないと提供し、食べることができない。一方、ピース単位では細かい単位で必要な分を顧客に提供し食べてもらうことができる、という内容であった。この例は、分かりやすい例であり、また興味深く思った。

2. 「その設計、テストできますか？」

アジャイル開発を多くの組織で行っている一方で、従来の品質保証組織(ここでは主にシステムテストなどを担当する組織)はどうあるべきか、ということは多くの人が気になり、また悩んでいるところであると筆者は思っている。そうしたなかで平鍋氏は「テストする人がプロジェクトの初めから関わり、開発製品の理解をしながらテストしやすい製品を開発者と一緒につくるべき」ということを主張されていた。テストする側から「その設計でテストできますか？」とテストする人から開発者などに問いかけることで、テストしやすさをテストしやすさを実装やアーキテクチャ設計に組み込むように提案していくことが重要であると主張されていた。

3. 対象に棲み込む

ソフトウェア開発に携わる人(ひいては新製品を開発する人)は、頭だけで考えずに体を動かしユーザになりきって考えることが重要であると言っていた。例えば、医療機器を開発する人なら、実際に入院してみて、患者などの立場になって対象をみてみるといったことである。「自分が作っているものを、五感を使って、ユーザの視点でみていますか？仕様書だけをみて作っていませんか？仕様書には顧客が期待する半分くらいの情報しかありません。」という意見には、普段の自らの仕事のやり方を反省するとともに、印象深く感じた。

テクノロジーセッション

「なんじゃこりゃ！このバグ票なんか腹たつ
～バグ票の失敗から学ぶソフトウェア開発のための幸せなコミュニケーション術～」
近美 克行 （バグ票ワーストプラクティス検討プロジェクト）

本セッションでは、どこのソフトウェア開発組織でも利用されているはずの「バグ票」が、ソフトウェア開発の現場で有効に活用されていないことから発生する悪い現象に対しての改善を考える、という内容であった。
近美氏が参加しているコミュニティによるアンケート調査では「ダメなバグ票」の事例として以下のようなものが紹介された。

1. 開発には関係ない一言からのバグ票炎上
   (「酷いデグレードです。このような開発力では御社の将来が危ぶまれます」というコメントから、バグ票を参照する関係者間で、開発に直接結びつかないコメントの応酬に発展)
2. 「バベルの塔」
   (用語や単位、表記方法などが統一されていないことから、バグ票の起票者により表現が異なり、バグ票の内容を分類することが難しくなってしまい、整理・分類するために余計なコストがかかってしまう。)
3. 「バグピンポン」
   (開発者とテスト担当者の間で、「バグ(不具合)」の認識が統一されてないため、「バグだ！」「バグではなく仕様である。」といったコメントが繰り返される)
4. 「なにかがおかしい」
   (バグ票に「なにかがおかしい」としか書かれていないため、詳細な状況の確認や期待結果などを確認・対応するために余計なコストがかかる。)

「ネタ同然の状況がなぜ発生するか？」に対する近美氏の意見は、「バグ票の目的を考える」「読む人は何を知っていて、何を知らないのか」などを考える必要があると主張していた。
発表の中でも説明があったが、バグ票に限らず、文書すべてにいえることで、文書の改善をするなら同様のことを考える必要があると思った。
自分の起票するバグ票は当然ながら、その他の文書を書くときも、この発表の対策案を取り入れることを考えようと思う。

「テストエンジニアの人材育成と自己開発の秘密のレシピ
～エンジニア能力開発のすすめ～」
佐々木 方規 （ベリサーブ）

佐々木氏の発表したこのセッションでは、教育における目的はどこにあるのかを考えることが効果につながる、というお話から開始された。
セッションを聞いていて重要だと思ったことは「スキルの可視化」である。自分の持っているスキルの棚卸しを行い、スキルマップやスキルツリーにより表現してみることは、教育を行う側にとっても、教育を受ける側にとっても重要であることを感じた。また、教育というと集合教育で知識を教える、ということがイメージされるが、佐々木氏は、それでは不十分と説明していた。例えば、技法の種類などの知識は集合教育などで行うことができるが、その技法などを理解し自分の業務などに適用して効果を出せるようになるためには、OJT(On-the-Job Training)でスキルを体得していく必要があると言っていた。そのとき重要なのは、指導者(≠熟練者)の存在であり、指導者がスキルの分析を行い、ポテンシャルを見極めてスキルを習得させていくことである、と述べていた。
教育を、個人が組織に依存することなく、同時に、組織が個人のみに丸投げするのではなく、今できることと、今できることから次にどのようなスキルを習得するかをお互いに納得しながら進めることが重要なのだと思った。スキルの可視化は、佐々木氏の説明にあったETSS（*1）ほか、Test.SSF（*2）、ITSS（*3）など公開されているため、これらを参考にしながら自分でも試みてみようと思う。

*1）ETSS ： 組込みスキル標準
http://sec.ipa.go.jp/ETSS/
*2）Test.SS ： SSFに基づくテスト技術スキルフレームワーク
https://aster.or.jp/business/testssf.html
*3）ITSS ： ITスキル標準
http://www.ipa.go.jp/jinzai/itss/

「チームで成功させるシステムテスト自動化 by Friendly.」
石川 達也 （Codeer）

石川氏のセッションは、Windowsにおけるテストフレームワーク(Friendly)についての発表であった。Friendlyを利用したデモをセッション中に行い、テストコードを書く様子や実行の様子をライブでみることにより非常に興味深く聴くことができた。
セッションでは、テスト自動化について、よくある誤解を説明するところから開始された。「テスト作業のすべてを自動化するのではなく、何割かを自動化する」「自動化は人間が考えたことを自動化するだけ」などである。また「そのテスト対象を自動化することで、どのような品質が担保されるのか」を考えることが重要であるとも主張されていた。
テスト自動化にあたり、テストチームと開発チームが協力して対応することが重要であると思った。

招待講演

「フィリピンでのテストチーム立上げとマネジメントの秘訣!!」
田中 学二 （Klab Cyscorpions Inc）

本セッションでは、日本とは異なる文化などの違いの中でフィリピンの企業においてテストチームの立ち上げ時に行ったことや考えた内容についての紹介であった。
フィリピンについての紹介がはじめにあった。平均年齢が想像より若かったことは衝撃であった(日本は42歳に対して、フィリピンは23.5歳という紹介があった)。また、紹介にあったスライド中の海の写真がきれいで、いずれ行ってみたいと思わせる紹介内容だった。
チームの立ち上げに関しては、計画を立てて、その内容をチームメンバーに納得してもらい実行に移す、というプロセスであり、進め方自体は日本と特に大きく異なるところはないというお話であった。ただし、文化の異なるチームメンバーの扱いは注意が必要であることも説明があった。例えば、仕事(会社)優先でないことや、会話で通じていると思っても文書で説明して納得しているか確認する必要があることなどである。
ソフトウェア開発にかかわる作業は人が中心であり、その人と取り巻く環境を理解することが重要であると感じた。同時にグローバル化が言われるようになって久しいが、ビジネスにおいて海外が近くなっていることから、一部の人だけでなく、多くの人が、相手を理解し、人を取り巻く文化の違いを意識しなければならない、とも思った。

「Being as a test engineer in the past and in the future
(フィリピンのテストエンジニアの想い～これまでとこれから!!)」
GERANGCO Angeli Marie （Klab Cyscorpions Inc）

フィリピン企業のテストチームのマネジャーの立場にあるGERANGCO氏が発表者であった。発表では、テストチームの立ち上げから今までにやってきたこと、国民性とテストエンジニアの関係、テストエンジニアという職種の意識や、やりがいなどについて語られた。
「フィリピンではテストエンジニアという職種については、現在では、あまり広くは知られていないけれど、数年たてば多くの人が知るようになる。そうした中で、テストについてのコミュニティが作られ、いろいろな技術や知識の共有をしていきたい。」という熱意あふれる内容が非常に印象的であった。

まとめ

今回のJaSST'15 Kansaiは、オープニングセッションで実行委員長より話があったように参加者それぞれが、なにかしら現場で困っていることに対して参考になる内容であったと思っている。すべての講演セッションで活発に質疑が行われており、さらに情報交換会では、講演者を囲み、発表内容などについて、講演者や他参加者間において活発に意見交換されていた。また、招待講演での内容は、海外においてテストエンジニアはどのような考えで業務や研鑽を行っているかを現場マネジャーの視点から話していただいたアツい内容は今回独特のものであったと筆者は思っており、情報交換会でも田中氏・GERANGCO氏の周りでは多くの方が意見交換されていた。
基調講演にあった「共感で人を動かす」、テクニカルセッションにあった「(文書を読む相手が)何を知っていて、何を知らないのかを理解する」「(教育における)教える側と教えられる側の関係」「(テスト自動化における)テストチームと開発チームとの協同」などから、技術だけでなく、人を大切に思うことが、よい品質を生むことにつながり、それが「いたみのないテスト」から私たちの幸せにつながるのではないかと思った。今回のJaSST'15 Kansaiに参加した多くの方々が、今回の内容をもとに、自らの開発現場での改善に取り組み、その改善が成功することで自分たちの幸せにつながることを切に願う。