NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'12 Kansai
HOME > 活動報告 > イベント報告 > JaSST'18 Kansai
2018年6月15日（金） 於 東リ いたみホール（伊丹市立文化会館）
JaSST'18 Kansaiが、2018年6月15日(金)に開催された。開催場所は昨年に続き、いたみホール（兵庫県 伊丹市）である。会場は参加者で満席となり、開催テーマに大きな関心を寄せている様子が伺えた。プログラムの最後には、実行委員による各講演のふりかえりが行われ、開催者・参加者ともに「納得してワンステップアップする」ことへの強い熱意を感じる1日となった。
JaSST'18 Kansaiは、実行委員長である野中氏の挨拶で始まった。若手のエンジニアが自分の仕事に納得感を得られていないという現状に触れ、納得してワンステップアップするためにはどうすれば良いか、本日の講演をきっかけに活発な意見交換をしてほしいと述べた。次に、若手代表として、実行委員の鍋島氏から挨拶があった。自分が納得し、相手も納得するテストとは何か。今日一日は、納得についてじっくりと考えてほしい、という内容であった。
本講演では、いわゆるFizz Buzz問題を例として、ライブコーディングが行われた。テスト駆動開発とは、「Red」「Green」「Refactoring」のサイクルを繰り返す開発スタイルである。
設計には、箇条書きのToDoリストを用いる。近いもの(最も変更の規模が小さいもの)から詳細に、ジャストインタイムで一つずつ納得をして作業を進めていく。ToDoリストの1行が、テスト駆動開発1サイクル分の設計になる。設計が完了したら、テストコードを書き始める。コードを書き進める都度、「今の時点でテストコードを実行すると、この理由でこの結果となる」という予想を立て、その通り動作することを確認する。予想通りの動作をすれば、それは状況をコントロールできているということである。
まず最初にテスト用のクラスを自動生成し、そのままの状態でコードを実行する。failメソッドによりRedバーが表示されると予想し、その通り動作することを確認したら、failメソッドを削除してテストコードを書く。
テスト用のクラスにアサーションを書く際は、まだ存在していないプロダクトコードのクラス名やメソッド名を予想しながら書く。当然、コンパイルエラーとなるので、これを解消するようにプロダクトコードを書く。コンパイルエラーが解消されたら、テストコードを実行する。まだプロダクトには何も記述していないので、テストコードを実行すると、プロダクトコードはNullを返す。「プロダクトコードがNullを返すことでエラーとなる(Redバーが表示される)」という予想を立て、テストコードが予想通り失敗すれば、状態が「Red」となる。
次に、テストコードが成功するようにプロダクトコードを変更する。ここで状態が「Green」になる。この時点では、テストコードが成功することが最も重要になるので、プロダクトコード側には「"1"を返す」のように、期待する結果を具体的に記述することも許される。仮にこのタイミングでテストが失敗したのであれば、失敗はテストコード側にあることが明確になる。最後に、テストコードが成功する状態を保ちながら、「Refactoring」としてプロダクトコードに修正を加え、ただ動作するだけのコードから、より綺麗なコードへと洗練する。「Refactoring」が完了したらToDoリストを更新し、また次のサイクルを始める。
コードを書き始めた段階では、見通せない部分が多い。そのためテスト駆動開発では、最初はいわゆる「歩幅」を小さくして作業を進めることを推奨する。見通せる部分が増えてくると、不安がなくなる。不安が取り除かれるに従って、「歩幅」も徐々に大きくする。テスト駆動開発では、1つ1つの作業に納得をしながらコードを書き残すとともに、仕様レベルの言葉を残しておくことも推奨される。例えば、メソッド名に意図を含めてしまう。また、「歩幅」を小さくしていた初期のテストコードを適切に減らしておくことが重要である。ただ書くだけがテストではない。情報を適切に整理することで、他者が意図を読み取ることが可能となる。開発者は、テスト技法を知らない場合も多い。例えば、ペアプログラミングで、同値分割や境界値分析の技法を、テスト技法に精通したメンバーがアドバイスする。このようにして、テストコードをより良いものにブラッシュアップできる。
プロダクトコードが目の前で作り上げられていく過程を、ライブコーディングという形で拝見した。1つ1つの作業が丁寧に言語化され、緻密に納得感を積み重ねながら、プロダクトコードおよびテストコードが組み立てられていった。「百聞は一見に如かず」の言葉通り、書籍を読んだだけでは得られない、強い納得感を感じるセッションであった。一朝一夕に身に付く技術ではないが、テスト駆動開発をよく学び、開発者と共にテストコードを作り込むスタイルを目指したい、と感じた。
S3セッションの時間帯は、A会場とB会場で3セッションずつ、合計6セッションが開催された。A会場は「テスト管理セッション」、B会場は「テスト設計セッション」という形で分けられていた。筆者は、いずれもA会場を選択した。
新規サービスを開発するにあたり、迅速に仮説検証を行うため、アジャイル型要求開発を導入した。老舗メーカーで、既存の文化や組織構造を変えるために行った取り組みの紹介があった。
既存の組織構造では、役割によって目指すゴール(=その役割にとって大切なこと)が異なっていた。また、組織ごとに仕事の範囲が定められているため、各組織の間(グレーゾーン)を巡って対立が発生してしまいがちであった。そこで、スクラムの手法を参考に、各部門からメンバーを選出し、全員でゴールを共にするチームを新設した。また、言われるままに開発を行う、いわゆる「御用聞き」のマインドを変えるため、開発者も含めたチーム全員で要求を開発する進め方に変更した。
「誰の、どんな課題を、どのように解決し、どんな効果を狙っているのか」「そのために、何を、どこまで作るか」というフォーマットを用いた。「ペルソナ」を作成して「誰」を仮定し、「カスタマージャーニーマップ」を用いて「課題、解決方法、効果」を仮定した。最後に、「ユーザーストーリーマッピング」を用いて「何をどこまで作るか」を合意した。また、これらの手法だけでは非機能要求が漏れるため、運用体制/コスト面も含めたサービスレベルを検討し、サービスレベルを満たすための非機能要求を作成した。
開発した要求はあくまでも仮説であり、その妥当性を判断(検証)するためには、「一般的にはどうか、他の製品と比べてどうか」を把握している必要がある。そのため、QA(品証部門)もスクラムチームに参画してもらった。要求を作成すると同時に受け入れテストを作成し、自動化した。受け入れテストを作成する際の品質レベルはチームで合意した。要求も品質レベルも、チームで合意することによって、特定の誰かの責任ではなく、チームの責任となる(筆者解釈：チームの責任にすることで、品質保証部門以外から参画したメンバーも、品質について考えざるを得ない)。品質も、チームで担保することが肝要である。
組織の壁が存在することで自分の仕事に納得感が得られない、という悩みは、多くのエンジニアが抱えている悩みであると想像する。具体的なプロセスを交えて事例の紹介があったことで、自分の携わる仕事に対してのヒントが得られた。
現在、テスト設計エンジニアの需要が高まっている。積極的に採用を行なっているが、いわゆるキャリア採用(IT業界経験者の採用)だけでは、需要に追いつくことができない。そのため、未経験者でもポテンシャルのある人材を採用し、研修による教育に取り組んでいる。
通常のテストプロセスでは、まず大まかな内容を固め、段階的に細かな内容を固める。これに対して、研修ではまずテスト実行を習得し、次にテストケース作成、最後にテスト設計という順序で、プロセスを逆に進めている。まず具体的で細かい内容を把握して納得し、その後徐々に広い範囲を把握できるよう工夫している。また、実務で用いるための様々な中間成果物を定義(フォーマット化)し、それらの成果物を実際に作成してもらう。これらの成果物はすべて細かくレビューする。ここで手を抜かないことが、受講者の納得につながる。研修の成果として、研修修了者を、実際に現場にアサインしている(もちろん、熟練者がフォローする体制を敷いている)。すでにプロジェクトリーダーとして従事している社員もいる。
江添氏の考えるテスト設計エンジニアの素養と適性として、以下の項目が挙げられた。
未経験者でも「テスト設計エンジニア」になれる研修は整ってきたが、今後は「テスト設計」に止まらない「テストエンジニア」を育てる研修を構築していきたい。
受講者が、納得して研修を先に進められるようにするための工夫が、研修プログラムの随所に散りばめられていたと感じた。自分自身が教育を行う場合も、受講者の納得感を細かく確認しながら進めることが大事だと再認識した。
本セッションでは、杉本氏の経験をもとに、ステークホルダーと良い関係性を構築できる「理想のテストエンジニア像」および、「理想のテストエンジニアを育成するための取組み」について紹介があった。杉本氏は、理想のテストエンジニア像とはどのようなものか？ どのようなポイントを押さえていると、納得感や自信に繋がるか？ という点に着目して、社内で情報を集めた。具体的な声としては、「客観的事実を積み上げて安心を提供してくれる」「設計者と独立した観点を持っている」などがあった。また、「メーカー社員/請負・業務委託」といった区分けによっても期待される資質が異なるという結果が得られた。例えば、メーカー社員には社風への適合性や、社内向けに合理化されたルールを用いてのコミュニケーションスキルが求められる一方で、請負・業務委託には専門家としての高い技術力や多様な現場経験が求められる。
人と人がお互いを気にすることが大事である。ある人が「大切にしていること」に蓋をしに行かない。また、失敗に学ぶことが大事である。失敗は栄養価の高い「野菜」である。また、マクロな視点で、隠れた因子を導出することが大事である。例えば、テストとは全く関係ない部署に運用してもらうことで、「先入観のない運用で作られるデータ」を得ることができる。
現場の「生の声」が多数盛り込まれたセッションであった。人と人が仕事をする以上、期待のずれや、人同士のぶつかり合いは避けられない。お互いがお互いの期待を丁寧に汲み取り、コミュニケーションを密に取ることが大切であると感じたセッションであった。
現代は、以前は考えられなかったようなことが当たり前の状態になる」時代である。ソフトウェア開発技術においても、ニューノーマルは起きている。例として、チームで開発を進めることや、自動化の拡大、本番稼働中にテストを行うことなどが挙げられる。
開発技術や実行環境のニューノーマルに呼応する形で、プロダクトライフサイクルのより早い段階で、自動的かつ継続的にテストを実行することが重要となった。また、異なるバージョンを並行稼動させながら段階的にリリースを行う「カナリア・リリース」や、本番障害を意図的に発生させてシステムの耐久性を確認する「カオスエンジニアリング」といった手法を使って、本番稼働に対するテストも行われるようになってきている。
「Internet Trend」によると、デジタルメディアの利用時間は、その半数以上がモバイル端末によるものである。また、「State of Testing Survey」によると、開発モデルとしてはアジャイルがほぼ一般的になっていることに加え、手動テストにおいては探索的テストが最も多く採用されている。このように、テストを取り巻く環境は激しく変化している。これらの変化を情報源から的確に読み取ることが重要となる。テストは知恵の総合格闘技である。歴史も発想のヒントになる。
現代が変化の時代であることを再認識したセッションであった。特に、海外の動向を知ることの重要性を痛感した。変化を敏感に察知し対応することで、世界に取り残されないよう務めたい。
最後に、 実行委員の一人ひとりが各セッションをふりかえる時間が設けられた。ふりかえりとして、各セッションに対して実行委員が一人ずつ感想を述べた。同時刻の別セッションの感想を伺うことができ、有り難かった。
大いに納得したという感想もあれば、すぐに答えが出るものではないが、理解がひとつ深まったという感想もあった。実行委員長である野中氏からは、セッションの内容がいずれも濃密であったとの感想が述べられ、熱気に包まれたJaSST'18 Kansaiを締め括った。
現代は、よりスピードが求められる時代である。スピードを大事にするからこそ、個々の作業とよく向き合い、納得のいく説明ができる状態を自ら作り上げること、および、それを維持することが重要であると感じた。また、情報をただ集めるだけではなく、自分にとってどの情報が重要かを判断する力が必要であると感じた。目まぐるしく変化する環境に流されないよう、日頃から足元を固め、納得感をもって過ごすことを心がけたいと感じた。
記：原 考功