アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その2
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその2になります。
前回は「文化的なチャレンジ」について書きました。
さて今回は「アジャイルテストの4象限」についてです。
アジャイルテストの4象限
上記の図には様々なテストタイプが記載されています。個々のテストはおなじみのものかと思いますが、アジャイルテストではこれらをQ1～Q4に区切り（Four-quadrant）整理しています。また、これらは開発工程が進むごとにQ1から順繰りに実行するものではなく、現状にて必要なテストを選択するものであるのが特徴かと思います。一つずつみていきましょう。
Q1：チームを支援する技術面のテスト（P107〜より）
- 代表的なテスト：単体テスト、コンポーネントテスト
開発チーム内での開発そのものを支援するテストになります。これらは「自動」と記載されているとおり、自動化が容易でより多くより速くテストの実施が可能であるとしています。
また、「チームは継続的インテグレーションやビルド、テストプロセスをセットアップすべきです。それによってフィードバックをできるだけ早くすることができます。」（P125 7.6 「まとめ」より）
Q2：チームを支援するビジネス面のテスト（P127〜より）
- 代表的なテスト：機能テスト、ストーリーテストなど
開発対象がビジネス面での要求を満たしているかのテストになります。「自動と手動」とあるようにものによって自動化が容易なもの、難しいものがあります。要求は以下のように導き出すとしています。
「ストーリー 」+ 「例」+ 「会話」 = 「要求」
上記は顧客より提示されたストーリーに対して、「こういった場合は？」などと例をだして「会話」し、「要求」を持ち引き出すという意味になります。
本象限でQA担当者が貢献できる重要な部分として、「顧客が、達成の条件を表現すること、各ストーリーの期待される、もしくは期待されない振る舞いの例を作成することを助けること」（P148 8.7 「まとめ」より）としています。
Q3：製品を批評するビジネス面のテスト（P189〜より）
- 代表的なテスト：探索的テスト、シナリオテストなど
開発対象をビジネス面から批評していくテストになります。今風にいうとユーザー体験についてのテストまとめた象限と理解しました。
これらのテストタイプは実際に人の目で見ていく、批評していくことが重要とされており、自動化は適さないと言っています。しかし必ずしも全て手動にて実行する訳ではなく、必要なテストデータの作成といった部分では自動化の余地があります。
顧客へのデモもこの象限に含まれます。
Q4：製品を批評する技術面のテスト（P217〜より）
- 代表的なテスト：パフォーマンステスト、「～性」テスト
非機能要求についてまとめた象限になります。ここでいわれている「〜性」テストとは「保守性」、「可用性」といったISO9126に含まれるものを指しています。
「非機能テストについて考える時間はリリース計画時やテーマ計画時です。必要に応じて小さな反復を繰り返しながら、早めに計画を始めましょう。」（P222 11.3「いつやるのか？」より）とありますが、たとえばストーリーとして「ボタンを押してから最長5秒以内に結果が出力される」といったものがあった場合、実施が検討する価値があると思われます。
まとめ
以上が「アジャイルテストの4象限」になります。
先にも書きましたが、順繰りに実施していくわけではなく、現状に適したテストを各象限から選択して、様々な範囲の観点からインクリメンタルに品質を作り込んでいくということが理解できました。第4象限については実施するタイミングが難しい気がしますが、しっかり見極めてトライしていきたいですね。
次回は・・・
アジャイルテストにおけるテスト自動化について書いていきたいと思います。
ではまた！
アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その1
こんにちは！ 品質マネジメント部の磯です！ 2回目の投稿となる今回からは、弊社内で進めていました「実践アジャイルテスト」勉強会にて学んだことを複数回に分けてご紹介したいと思います。
文化的なチャレンジ
アジャイルに関しての知見というと、よく見られるのはSE/PGよりなものが多いと思いますが、ここではアジャイル体制となった際にQA担当者が陥りやすい状況や、それをどう乗りこなしていくかについてのヒントが書かれています。
危機：品質の番人の考え方（P38 3.1.1 「品質の考え」より）
私たちは、開発リーダーがプログラマにコーディング標準に従うよう強制させることを自慢げに語るテスターと話しました。私たちは、標準に合っていない要求についてのバグを記述することに時間をかけるテスターのことさえも聞きました。これらのことは協力的なアジャイルチームには合いません。これは敵対する振る舞いを育てることになります。
うんうん、過去の経験を思い出すだに、そのようなことはありましたね・・・。これは大きくて厳重なプロセスを一個ずつ踏んでいくウォーターフォール型ではあるあるネタであると思います。技術とは関係ないところではありますが、対立関係が強化されていくとまともな議論すらできなくなるおそれがあります。では品質の番人はいらないの？ 品質は誰が守るの？と思いますが、ここでの答えとしては「チーム全体で品質を作り上げていく」といっています。
一体化したチームの品質のオーナーシップ（P39より）
多くのテスターやQAチームにとって、これは品質を所有することから、品質を定義し維持するという特別な役割へのマインドシフトを意味します。
ここで言われていることは、テスト実施やバグ検出のみに注力するのではなく、品質をチーム全体で考えられるよう導いていく存在へと意識を変えていく必要がある、ということと理解しました。つまりは役割がきっちり分かれていると無用な対立や丸投げが発生してしまい、本来達成するべき価値の創出が行えなくなってしまうよ、 協調していいもの作ろう！と。まさしくその通りですね。
もう一つ典型的な状況として、QA担当者におけるアジャイル実施の阻害要因について考察がなされています。
アイデンティティの喪失（P44 3.2.1より）
テスターはいろいろな理由で独立したQAチームを持つことに固執しますが、その一番の理由は不安です。
いくつか具体的な理由が記載されていますが、チームが一つになることで役割が変化しアイデンティティの喪失が発生する可能性があるとのことです。たしかにこの点については私も不安に思う部分がありますが、本には不安は共有しチームで解決していこうとあります。人間の感情的な部分にも着目しているのがアジャイルの特徴なのかなと思います。
まとめ
今回はアジャイル導入に際してQA担当者が持つべき心構え的なところ、「文化的なチャレンジ」について紹介しました。 変化を恐れず不安は共有してチームの一体感を増し、よりよいものを作っていこう！ということですね。
さて、では具体的に「アジャイルテスト」って何をするの？という部分については次回以降に書いていきたいと思います。 ご期待ください！
見積りのためだけじゃなかった！ プランニングポーカーが開発チームとプロダクトにもたらす8の恩恵
開発部の土岐です。今日が誕生日で割り切れない数の歳になりました。
さて、これまでの幾度か弊社アプレッソで「アジャイルへの取り組みを始めてるよ！」ということを紹介して参りました。
2016年7月現在、DataSpider Servistaの次バージョン、4.1の開発プロジェクトが本格化し、実際にアジャイルな開発に取り組んでおります！ と自信満々に言ってみたものの、本格的なアジャイルに取り組むのは初めての我々。「ヒヨコードでピヨピヨしている」状態ではありますが、日々悩み議論しながらいろいろなことにチャレンジしています。
ということで今後、その取り組みを具体的に紹介していこうと思います。
今回はアジャイル的な見積りの技法、「プランニングポーカー」についてです。
プランニングポーカーとは？
▲使用しているプランニングポーカー
現在のDSS4.1プロジェクトでは、ユーザーストーリーの見積りをすべてプランニングポーカーで行っています。これまでの弊社のプロジェクトでは、一般的な見積りと同様に開発担当者が「人日」などの工数で見積り、それをリーダーがレビューして見積りとする、というのが一般的でした（それがすべてではないですが）。今回はそれを大きく変えたわけです。
プランニングポーカー自体の詳細についてはネット上でいろいろな方の記事があるので、そちらを参照していただくのがオススメです。
ざっくり説明すると、プロジェクトチーム全員（プロダクトオーナー、QAも含めて)がこのプランニングポーカーを持って参加します。全員がそのストーリーの「ポイント」を見積りカードで提示し、話し合いを経て全員の一致でポイントを決定します。この繰り返しによって見積りを行っています。
カードのポイントは「1」「2」「3」「5」「8」「13」・・・・という数値になっています。この数値は皆さんご存じフィボナッチ数列です。この数列は必要以上に細かい数値の違いに議論が集中しないというメリットがあります。
ちなみにここで見積もる「ポイント」は「工数」とは異なり、「ストーリーの相対的な規模」を表したものです。この違いはとても重要です。とても重要です。とても重要です・・・が、今までの感覚とかなり違うのでチーム全員が飲み込めるまで時間がかかりました・・・。イテレーションを進んできて、ようやくその意義がしっくりきているところです。このトピックは面白いのですが詳細に書くと長くなるので、改めて別の記事ででも取り上げたいと思います。
ちなみに↑のプランニングポーカーは、Surviveplus.netさんのPlus Programming .net Planning PokerのPDFを使わせていただき、印刷して作りました。 最初はカードが手元に無かったので付箋でやってたのですが、カードでやるとゲーム感が高まりテンション上がります。
Surviveplus.netさんありがとうございました！
プランニングポーカーで見積ってみる！
▲カードを出し合って見積り！
幾度かこのプランニングポーカーでの見積りをやってきて、新しい技法なので最初は戸惑っていたのですが、徐々に慣れてきて一定の流れが出来てきました。
ざっくりと流れを書くとこういう感じです。
プロジェクトマネージャー(PM)「このストーリーは××を○○するというストーリーです。（ホワイトボードに書いたりしながら）このような機能をイメージしてます。△△の詳細については決っていないので検討が必要です」
メンバー「××については仕様の方針が決まってますか？」
～ いろいろストーリーに関する説明
PM「皆さんイメージは出来ました？」
メンバー「はーい」
PM「いっせーのせ！」
～ 全員カードを提出
PM「えーっと、"5"が一番多くて、"3"の人、"8"の人が居ますね。"8"を出したAさんはどういう理由で"8"ですかね」
Aさん「これはGUIの修正が必要で、その部分は画面仕様も含めて悩みどころが大きくて規模としては大きくなると思います」
Bさん「あーなるほど。そうすると自分も8かな？」
Cさん「自分は3を出したんですけど、他の開発のときに使ったあの機能を取り込めばいいと思うのでそこまで大きくはならないと思うんですよね」
Dさん「QAの立場からみて、経験上このコンポーネントは結構テストが大変で、不具合が出やすいんですよ。なのである程度大きくみておいた方がいいんじゃないかな～」
Eさん「なるほど～じゃあ自分ももう少し大きくしようかな・・・」
～ いろいろ会話
PM「ではこのストーリーはポイント"8"で良いでしょうか？」
メンバー「OKです！」
～ ポイントを記述する
PM「では次のストーリーは～」
というので次々と見積りをやってストーリーにポイントを付けていきます。
なお↑の流れではPMが話の流れを見計らってポイントを提示して、全員の同意を得て決定しています。通常ならポイントを決定するときは、カードを何度も出し直して全員の数値が揃うまで出す、というのが通常のプランニングポーカーのやり方のようです。ただ、それをやると時間がかかりすぎてしまうようだったので、現在はざっくりと議論が終息してきたところで、大きな反論がなければ提示したポイントにするという方法を取っています。この辺は試行錯誤中です。
プランニングポーカー良い！
ということで試行錯誤しながら導入をしてみて、端的に言うと「とても良かった」と私は思ってます。これは他のメンバーに聞いても同じようです。
正直なところ、私はとても疑い深い人間で、人から言われたままやるのを嫌がる天の邪鬼な人間であり、自分には邪気眼とかの秘められた能力があるのではないかと今でもたまに思うという中二病的な人間です（中二病は本旨には関係ないですが）。
「全員一致で決める？ そりゃ理想はそうだろうけど、それをやる意味って本当にあるの？ なんかスピリチュアルでユニティでピースでラブみたいなそういう胡散臭いもんなじゃないの？」
とか失礼なことを思っていましたが・・・違いました！ アジャイルさん、失礼なこと思ってすいません！
プランニングポーカーには、開発チームとプロダクトに確実に恩恵をもたらす現実的で具体的な効果があります。
ということで、その恩恵について1つずつ解説していこうと思います。
1. 「見積り」がゲームになって楽しい！
▲見積りポイントについて喧々諤々の議論を闘わせるチーム
一番分かりやすいのがこのポイントです。「見積り」という"作業“が皆でワイワイ楽しむ”ゲーム“になります。
前述した通り、これまでの弊社での見積りは、開発者が個別に工数を見積もっていくという孤独な作業でした。分からないことがあったら自分でいろいろな人に相談しつつ、PCの前でうんうん唸って悩みながら、でも「決めなきゃいけない・・・」という焦燥感に駆られ、絶望の果て工数を叫ぶ作業・・ってこれは大袈裟過ぎますスイマセン！ しかしここまでネガティブではないですが、「孤独」であり「作業」であったことは確かです。
プランニングポーカーによる見積りでは、関係者もレビュアーも全員その場に居るので、分からないことはその場で解決できます。 さらに「あ、この人はこのポイントを出すんだ」「お、これは皆意見が一致してるね」「そんな視点もあるのか～」など驚きと発見のある楽しいゲームになります。
まあでも正直なところ、「さあ明日見積りだ！ ワクワクして眠れないなぁ」というほどの楽しさではないです。しかし「ちょっとワイワイやってみようか」っていう憂鬱さの無いMTGであることは確かです。
ということで、まずはこの「楽しさ」を前提としつつ、次からが本番です。
2. 全員の「参加感」が凄い！
関係者に仕様を説明するMTGは皆さんやったことがあると思います。
準備した資料を駆使してデモを行い、「質問ありますか？」と聞いたところ
シーン・・・
よく見る光景ですね。自分も説明を受ける立場だったとすると、
- よく分からないところあったけど自分が実装するわけじゃないから
- 他に詳しい人が意見しないから自分が意見するのは恥ずかしくて
- 早くMTG終わらせて昼ご飯食べたいなぁ
こんなことを考えて「ま、いっか」となることがあります。（ありますよね？）
プランニングポーカーの一番重要なところは「必ず全員が自分のポイントを出さなければならず、そのポイントについて理由を説明しなければならない」というところにあると思います。
このことは「“見積り可能である"と判断するまで十分な情報を得る必要がある」ということとイコールになります。
つまり、参加者全員が「見積るにあたって十分な情報がある」と判断するまで、ストーリーに関する議論をする必要があります。
実際にプランニングポーカーをやってみて以下のようなことがありました。
PO「このストーリーは～というものです。質問ありますか？」
メンバー「うーん大丈夫かな・・・」
PO「ではカードを出してください」
メンバー「・・・あ、ちょっとまってください、あそこって仕様決まってますか？」
メンバー「あそこについてはどこまで詳細に落ちてますか？」
などとカードを出す段階になって急激に議論が深まったということがありました。
単なる仕様説明のMTGに「自分でポイントを見積り、そのポイントについて説明する」というフローを設けることによって、全員の「参加感」がまったく変わってくるのです。
これを認知心理学的には「建築中のマンション」理論と言い・・・・ませんし、そんな理論は存在しませんが、何かそんな心理学の理論とかありそうな気がしますね（雑）。
まあとにかく、プランニングポーカーの導入によって、参加者の意識は確実に変わります。これは確かです。
このことは、さまざまなメリットをもたらします。
3 ヒアリングしなくても情報が自然に集まってくる！
前述のメリットによる効果が大きいところがここです。飲み会とかでもそうですが、知らない人と「さあ、話しましょう！」と言ってもなかなか人は口を開けないものです。しかし「共通の話題」があると一気に話は深まります。
ここでの「共通の話題」は「何ポイントと見積るか？」です。具体的な方向に話題をフォーカスすることによって、メンバーから情報が自然に集まってきます。
具体的によくあるのが、ポイント提示後に皆で議論をしているときです。
「同じ仕様で実装した画面があって、あれは凄く大変だった。だからポイントは大きめの方が良いだろう」
「同様の実装があのモジュールにある。なのであそこを共通化すれば実装は楽なはずなのでポイントは少なくなるはず」
「修正自体は簡単そうだけど、影響が大きい機能なので慎重に動作確認が必要。テストのボリュームも大きくなるはず」
「この部分はあの人が実装したのでちょっと聞いてみてからポイントを判断した方がいいかも」
など、さまざまな観点で「そのストーリーの規模」についての有益な証言が多く出てきます。プロジェクトを進めていく上で非常にこのメリットは大きいと思います。
4 全員が手軽に直接情報を「知る」ことができる！
見積りから仕様策定、実装まで1人が担当すると、よくあるのが「あれはあの人の担当だからよく分かりません」という「他人の仕事」状態。これは経験された方は多くあると思います。これにより、誰かが休むとプロジェクトが止まったり、仕様ミスがプロジェクト終盤によって見つかったりという弊害があります。
それを防ぐための仕組みはアジャイル開発の中ではいろいろあるのですが、プランニングポーカーも非常に有益な武器になります。
このプランニングポーカーの段階では「そのストーリーを誰が実装・テストするか」というアサインは決めていません。ここも重要なポイントです。
プランニングポーカーをやっているときは全員が当事者です。全員がストーリーに対して見積りが可能な十分な情報を得ることが求められます。そして、誰でもそのストーリーの実装・テストが担当できるように全員に情報が行き渡ります。
wikiなどでドキュメントを頑張って書いて「情報共有！」って頑張るよりも、当社比で10倍くらい手軽で直接的に情報を共有することができるのであります。（もちろんドキュメントはドキュメントで大切ですよ！）
ちなみにここで議論したことは凄く重要な情報なので、議事録として残すかどうかはちょっと悩みどころです。まあだいたい自分が忘れても誰かに聞くと「あ、あのときはこういう話で～」と意外と覚えているものなのでとりあえず無しでやっています。全員が忘れてしまった場合はその程度の情報だったということで！
5 ストーリー自体が適正かを自然にチェックできる！
実際に議論していくと「まだポイントを決定できない」という結論になることがよくあります。殆どの場合、ポイントが決定できない要因はストーリーが「INVESTの原則」に添っていないことです。
アジャイル開発において、ユーザーストーリーは「INVESTの原則」に添うのが適正である、とされています。
INVESTの原則は以下です。
- Independent(独立している)
- Negotiable(交渉可能である)
- Valuable(ユーザ価値を提供する)
- Estimable(見積り可能である)
- Small(小さい)
- Testable(テスト可能である)
堅苦しくストーリーをこの原則に沿っているかどうかをチェックするのはなかなか骨の折れる作業です。しかし、プランニングポーカーの中でこのチェックを自然に会話の流れの中でやることができます。
例えば以下のような会話が出てきたときは怪しい兆候です。
「このストーリーはややこしいなぁ。複数のストーリーが合わさってない？」
→Independent(独立している) ではない
「このストーリーは詳細機能が決まってるけどもっと良いやり方あるんじゃないかな。ストーリーを一度考え直さない？」
→Negotiable(交渉可能である) ではない
「これって本当にユーザーに価値があるの？ 一度POで再検討した方がいいんじゃないかな？」
→Valuable(ユーザ価値を提供する) ではない
「このストーリーは抽象的過ぎて見積り難しいなぁ。もう少し具体的な仕様にした方がいいんじゃない？」
→Estimable(見積り可能である) ではない
「全員がこの大きいポイントを出すっていうことはストーリーが大きすぎるよね。分割できないかな？」
→Small(小さい) ではない
「このストーリーはテストを作るのが難しいなぁ。こういうストーリーにした方がいいんじゃない？」
→Testable(テスト可能である)ではない
このようなとき、一度見積りを出すのを中断します。そして「プロダクトオーナーに聞く」「別に仕様検討MTGを開く」「ストーリーを分割してから再見積をする」など、より適正なストーリーにするための方策をその場で決めたりします。
6 プロダクトの品質を保つ意識を持って見積りを行える
このMTGは必ず、テストを行うQAも参加します。そのため、開発寄りになることはなく、「品質保証」という観点も必ず見積りの議論の中に入れて行えます。
ただ「簡単な修正だから」という理由でポイントを低く見積もることは必ず異議が唱えられます。「開発」と「テスト」の双方の観点を併せて、見積りのポイントを一致する必要があります。
7 新規参加メンバーの「教育」も行える
プロジェクトに参加するメンバーは、プロダクトに関する知識の多い少ないは関係なく必ずこのプランニングポーカーに参加してもらっています。
そのため新規参加メンバーは、ポイントを選ぶとき凄く悩むようです（当たり前ですが！）。しかし悩んで出したポイントで「この部分が分からなかったので・・・」と説明すると、「それについてはこうこうで」ということで自然にプロダクトに関する知識の共有・教育を行うことができます。
なかなか「ここを教えて欲しいんですけど」と開発中に聞くのは抵抗があるとは思いますが、プランニングポーカーの中で「全員が一致して見積りポイントを出す」という目的のために自然に共有が行えるのは凄く効果的だと思います。
8 チームメンバーの相互理解が深まる！
ということでいろいろな観点で書いてきましたが、やはり一番重要なのは人間同士の関係。なかなか「理解しましょう」と言ってもすんなりできないのが人間であります。
飲み会などでのコミュニケーションも重要ですが、やはり今やっているプロジェクトの中でその人が何をやろうとしているのか、何を大切としているのか、ということを知ることがプロジェクトの成功のための必要な要素です。
プランニングポーカーでは全員に判断と発言の必要があるので、誰かが場を支配することなく、それぞれのメンバーが持っている知識や観点、大切にしている価値観などが分かってきて、チームの相互理解が高まります。
終わりに
「見積り」のための手法として導入した「プランニングポーカー」。一見「見積り」という目的を達成するために面倒くさい作業をしているように見えましたが、実際は
見積り＋ヒアリング＋情報共有＋品質向上＋チーム感向上＋教育＋α=プランニングポーカー
という非常に大きなメリットのあるものでした。開発チームとプロダクトをより改善する方法として、今後も導入して磨き上げてみたいと思います。
この記事を読んで気になった方がいればぜひ試してみてください。「見積り」のイメージが変わることは間違いありません！
ということで、今後もアジャイルの取り組みをいろいろ紹介していきたいと思います。以上、土岐からでした！
アプレッソ品質マネジメント部にだいぶ前にJOINしていました！
お初にお目にかかります。品質マネジメント部の磯と申します。本来はJOINしたタイミングでご挨拶エントリを書くべきでしたが、マゴマゴしているうちにずいぶんと時間が（なんと4ヶ月・・・！）たってしまいました。簡単ではありますが自己紹介させていただきたいと思います。
これまで
主にお客様先にて、デバイス（USBや無線通信）、携帯電話（ガラケー）アプリ、webアプリやスマートフォンアプリなど様々なものを対象とし、テスト/品質管理業務を行ってきました。
10余年お客様の製品をターゲットとして業務を行ってきましたが、より深く製品開発に関わっていきたい、自分の力を試したいと考えていました。そんな折、自社製品を開発しているアプレッソと出会い、入社するに至ります。
JOINしてみて
アプレッソでのQA活動について感心したことは、テストの知見の集積とそれらの選択による実践にあります。いままでの経験からしますとテストは以下のような戦略を持って実行されていました。
- 大中規模のSI系案件
- 固定化された長大なプロセスによる守備的戦略
- スタートアップ系ベンチャー
- 流動的なスピード重視の攻撃的戦略
どちらも一長一短あるかと思いますが、アプレッソにおいてはこれらのいいところを組み合わせQA活動が行われています。
車輪の再開発をしないよう、あらかじめ作成された多様なテストセットの中からを実施すべき内容を選択、制定されたテストルールに乗っ取ることで効率的に対象機能の品質を担保していく。
出来合いのものに沿って実施していくことはテストの目を鈍らせる一面もありますが、ルールは絶対ではなく、自分たちが行っていること自体も検証していくというマインドが徹底されており、常に進化し続けています。
アプレッソでは「多種多様で相互に異なるもの同士をシームレスに、簡単に「つなぐ」ためのソフトウェア」を開発しています。故に自社製品だけでなくその他の様々なシステム/アプリケーションについての知識も必要とされます。直近ではIoTへの連携をうたったDataSpider4.0がリリースされました。習得すべきことは数多くありますが、好奇心をもって日々奮闘しているところであります！
これから
本ブログの他エントリでも紹介していますが、アプレッソではアジャイルでの開発体制へ移行が進められています。
品質マネジメント部としてもこのビッグウェーブを乗りこなせるよう「アジャイルテスティング」の習得を進めています。得られた知見は本ブログ上で公開していきたいと考えていますのでご期待ください！
趣味など
- 音楽 聴いたり作ったりします。（最近は停滞気味）
- ゲーム ほとんどがいわゆる洋ゲーです。
- 散歩 Ingress, ポケモンGOがなくてもいろんなものが見えています。（…AR脳！）
つらつら書き殴ってしまいましたが、読んでいただきありがとうございます。
今後ともAppresso Engineer Blogをよろしくお願いいたします！
Agile Japan 2016、そしてアジャイルについてガヤガヤ話しました！
開発部の土岐です。 今年4月に育休から社会人復帰後3ヶ月経過し、ようやく社会というものに慣れてきた社会人再一年生です。
ということで、弊社アプレッソの開発部10名がワイワイ参加し、先日レポート記事をアップしたAgile Japan 2016。
「あなたと作るアジャイル」というテーマを真摯に受け止め、「参加することはスタート地点。その後にどんなアジャイルを作るのかが問題なのだ！」という気概で、参加者と参加できなかった者も含めて、「我々の開発プロセスをどのように作っていくか？」という主旨の元、ガヤガヤと座談会をしました。 今回は、この座談会で話した内容の概要を紹介しようと思います。 なお、今回の記事は以前の参加感想記事を前提としておりますので、未読の方はご一読いただくことをオススメします。
「スクラム」で何ができるか？ 「スクラムマスター」は何をやるか？
印象深かった講演として真っ先に挙げられたのが、Joe Justice氏による基調講演の「スクラムがイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜」。スクラムと言えばソフトウェア開発プロセスの手法というイメージが強いですが、火星移住計画や農業などさまざまな分野でスクラムの手法を適用し、プロジェクトを成功に納めている事実に驚いた人が多かったようです。
「スクラムの"良いものをより素早く提供しよう"というイノベーションが広がっていっていることを実感して感動した」
という感想がありました。
その中で話題となったのが「スクラムマスター」という役割の重要さです。
「生産性を上げるための障害を取り除くスクラムマスターが居てこそのスクラムだと思った」
「従来の我々のプロジェクトだとマネージャーがチームリーダーをやることが多かったが、まったく違う立ち位置だと思う」
「生産性を上げるためにあらゆることをやるというのがスクラムマスター。開発者のモチベーションを上げることもそれに含まれると思う」
「アプレッソの中で取り入れるためには、これまでに組織や部署に捕われず考える必要がある」
など、「スクラム」・「スクラムマスター」を実際に自分たちでやるためにどのようなことが必要か、ということを具体的に検討しました。
「見える化」によって達成されるものとは何か？
「アジャイルは本当に日本のソフトウェア開発を変えることができるか？」についての感想では、「見える化はどのようにやるべきか？」ということが話題になりました。
「"見える化"の例として野球のスコアボードの例がとても分かりやすかった。現在の状況や全体の流れなど、これに正しい情報が集約されている。見える化の典型的な例だと思う」
「ソフトウェア開発ではカンバン、バーンダウンチャート、ニコニコカレンダーなどが"見える化"のやり方として採用されることが多い」
「見える化」はよく話題になりますが、どのような方法でやるのが良いのか、どこまでやるのが良いのか、ということは悩ましい問題です。
アプレッソのチームでもこれまで取り組んできましたが、ツールやグラフなどデジタルでやることが殆どで、アナログで常に見える場所に置いておく、ということはそれほど積極的ではありませんでした。
そういう中で
「どこまでアナログ化するか？ どこまでデジタルで管理するか？ その線引きはどうするか？」
ということを議論となりました。
「すべてをアナログで書くと管理が大変だし、情報が多すぎる。かといってデジタルだと"ここにあるからね"と言っても見ないことが多い」
という課題があり、そもそも「何のための見える化なのか？」ということについてについて話しました。
具体的な実践として、現在アプレッソではプロジェクトのインセプションデッキを開発部の皆が通る場所の壁に貼っています。
「インセプションデッキを貼ることによって、プロジェクト外の人から"あれはどうなってる？""これは重要だよね"といった会話が発生している。見える化の良いところはそういうところだと思う」
といった具体的な成果についての意見がありました。これから、
「重要なのは"他人事にしない"ということではないか？ プロジェクトの状況を見えるようにすることで、プロジェクト内外の人へ情報が開かれる。それによって"我々のプロジェクト""我々のプロダクト"という意識で関係者全員が取り組むことができる、ということがあると思う。」
「以前だとプロジェクトの中でも各担当者で情報が閉じていた。見える化することによってその連携が自発的にやれるようになると思う」
など議論が行われ、
「どこまでが良いかは恐らく実践しながら考えていくしかないと思う。今回のプロジェクトでは可能な限りアナログで見える化していってみよう」
という結論になりました。
開発とQAの幸せな関係とは？
セッション「新米スクラムマスタとQAおじさんのアジャイル珍道中」についての話では、プロジェクトの中でのQAと開発の関係について議論となりました。
「従来のウォーターフォールを小さいイテレーションで回す、ということとアジャイルなやり方との最大の違いは何か？」
という疑問については、セッションに参加した者から
「大切なのは"フィードバック・ループ"だと思う。設計ありきで開発、テストがあるのではなく、詳細設計・テスト設計が並行で進み常にレビューし合って作っていく。またプロダクトオーナーによる仕様設計にもフィードバックを 返していく」
「このフィードバックのループをプロセスの中で常に繰り返していくことによって、品質を上げていきつつ早いサイクルでプロダクトを作ることが可能になるのではないか」
という意見が出ました。
アプレッソでもかつては「開発→QA」というフェーズを完全に分けてプロジェクトをやっていたのですが、段々と「QAが開発初期から参画する」という方向へシフトしていっています。
しかしそのやり方については悩みどころも多いところです。その中で「QAと開発、そしてプロダクトオーナーのフィードバックのループを作っていく」というのは方向性として大変参考になしました。
結局テスト期間って必要なの？
続いてQAと開発の関係の話は、セッション「まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～」についても議論となりました。
「セッションではQAが居ないチームでどのように品質を高めるか、という話だったが、QAを置いている我々のチームでも真似したいところが多くあった」
「特に開発からテスト期間までが長いプロジェクトでは、テスト期間に問題が発生すると対応が大変になる。ユーザーストーリーの完了をテストも完了した"リリース可能"な状態にする、というのは実践的なプラクティスとして有効だと思った」
それでは結局のところ、我々のプロダクトで「テスト期間は不要！」と言えるか？ という議論になりました。その中では、
「品質を担保するためにテスト期間は必要だと思う。しかし、品質を守りながら素早いリリースを行うために、イテレーションの中でテストを組み込んでいくことはぜひチャレンジしたい」
「そうすることで品質を保ちながらテスト期間を短くすることができるかもしれない」
などの意見が出ました。またQAとは別の視点で、
「バグは"関心の低い"作業から生まれる、という話が印象深かった。プロダクトの品質に関心を高く持つ、ということによってバグを出しにくくすることができるかも」
など品質についてどう取り組むか、という話をしました。
どこまでBe lazyでいける？
セッション「文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！」で話された「Be lazy」という考え方については、賛同と疑問が両方ありました。
「アメリカは仕事に対するの考え方が違う。やらなくていいものはやらない、本質的な問題だけに注力する=Be lazyという意識がある。それによって生産性を上げている」
「日本はやらなくていいことに労力を注力し過ぎだと思う。例えばアメリカの製品について本国にサポート問い合わせをすると、1行"try this!"みたいなメールでモジュールが返ってきて終了、みたいなことがあった」
「Be lazy」で仕事をやっていくのはすごく魅力的な話ですが、実際問題としてそれが可能なのか？ という意見がありました。
「エンドユーザーやパートナー企業に対しては、それが可能な土壌はまだ無いと思う。適用箇所は考えなければいけない」
「アジャイルも含めそれは外国の文化。そのまま取り入れるのではなく"考え方をインストール"していく、取捨選択して取り入れることが大切だという話があった」
などという意見が出ました。我々の仕事という範囲で考えたところ、全部は無理でも「Be lazy」になれるとこはあるのではないか？ という話になりました。
「例えば社内のコミュニケーションでも必要以上に気を使って時間を浪費しているところがあるのかもしれない。もっと端的でもいいのかも」
「開発やQAでもエビデンスを残すために使っている無駄なプロセスがあるのかもしれない。品質は落とさずに省ける無駄を省くという意識は持っていいのかも」
などの議論が行われました。
終わりに
ということでガヤガヤといろんなことを議論しました。（実際はここでは書けないような生々しい話もしながら！）
Agile japan 2016とそれに対する議論を経て、我々で作る「アジャイル」の具体的なイメージがかなり具体的になってきました（なってきたような気がします）。
ということでバトンは受け取った、後は走るのみ！ ということでアジャイルの取り組みがアプレッソでは始まっています。
次回以降の記事では、実際にアジャイルへどのように取り組んでいるか、それに対する良いところ、悪いところなど気づいたことを紹介していきたいと思います。
お楽しみに！
最後に宣伝ですが、ぜひこの取り組みに参画してみたい！ という方、アプレッソではエンジニアを募集しています。ぜひご検討ください！ カモンジョイナス！
行ってきました! JJUG CCC 2016 Spring & Java Day Tokyo 2016
こんにちは。この春にはじめて結婚式に着物で参列した開発部の陳です。
春（4～5月）は日本の結婚シーズンではあるが、実は Java のイベントシーズンでもあることは、ご存知の方結構いますかね？
先月下旬の 5/21（土）と 5/24（火）に開催された日本の Java 二大イベント、 JJUG CCC 2016 Spring と Java Day Tokyo 2016 に、 私は両方とも参加してきました。
若干時間経ってしまいましたが、参加したセッションの簡単な紹介と感想を共有したいと思います。
【目次】
JJUG CCC 2016 Spring
各セッションの資料が、JJUG サイトからダウンロードできるようになっています。
[GH-1] Type Annotation for Static Program Analysis
ITPro 連載でお馴染みの櫻庭さんによるセッションです。
従来のアノテーションの基本用途と使用例を紹介したあとに、 Java 8 でのアノテーションの変更点と、 静的文法チェックでの利用を簡潔に解説しました。
アノテーションは Java 7 まで宣言にしか記述できなかったが、 Java 8 では ElementType に型パラメータ TYPE_PARAMETER と型の使用箇所 TYPE_USE が追加されて、 その結果ツールによる静的文法チェックの制限も少なくなりました。
しかし、現状では言語レベルの標準な型アノテーションが存在しない、関連している JSR-305 も休止状態になっていて、 導入に躊躇する人も多い*1でしょう。
さらに、IDE 独自に定義した静的文法チェック用のアノテーションもあるが、
異なる IDE 間には一貫性がないので、開発環境を変えるとチェックできなくなります。
そこで、Check Framework を使うと、 IDE 間の違いを意識せずにいろんな静的文法チェックができるから、 より快適な開発ライフを送ることができるかもしれません。
[GH-2] Eclipse Collections で学ぶコード品質向上の勘所
ゴールドマンサックスの伊藤さんのセッションです。
Eclipse Collections でのコード品質を向上させる施策と、 俯瞰的な観点から見たソフトウェア開発においてのコード品質の話でした。
コード品質を如何に向上させるか、という話の前に、 ソフトウェア開発においての「コード品質」とは何か、を金融畑の開発者視点から語りました。
一般的に悪者扱いされている技術的負債でも、 捉え方を変えるだけで、ソフトウェアの価値を高める戦略的な手段の一つになるので、 最も大事なポイントは「どのように技術的負債とつきあうか」になります。
技術的負債を抑えるために必要なコストと戦略の妥協点を見極めて、 返済計画を事前に立てたうえで技術的負債を許容することで、 開発スピードとソフトウェアの品質をより容易に両立させることができます。
いつもソースコード中心に考えることが多い私に、技術的負債を見る新しい視点を提示してくれた、とても啓発的なセッションでした。
DRY 原則*2を徹底するための具体的な施策として、 デフォルトメソッドを活用したユニットテスト構成も結構参考になりました。
[GH-3] Jenkins 2.0
Jenkins の産み親である川口さんのセッションで、 内容は主に Jenkins の歴史、現状、と新機能の Pipeline を中心とした説明でした。
最後のユーザをベストプラクティスに誘導するための施策と、 セキュリティに関する取り組みの話以外、 全体的にドキュメントとの重複が多かった印象でした。
[CD-4] ネクスト Struts/Seasar2 としての Java EE アクションベース MVC 入門 ― MVC 1.0、Jersey MVC、RESTEasy HTML
カサレアルの多田さんのセッションです。
掲題通り、Java EE 8 に導入される MVC 1.0 の紹介と、 MVC 1.0 の参照実装である Ozark にテンプレートエンジン Thymeleaf を使う方法を説明しました。
2017 年上半期に Java EE 8 が出るまでのつなぎとして、 Java EE 7 で Jersey MVC か RESTEasy HTML を使う方法も紹介されました。
[M-5] Python + GDB = Javaデバッガ
富士通の数村さんによるセッションです。
最初タイトルを見た時、JJUG CCC に Python の話？と訝っていたが、 どのように GDB を Python スクリプトでカスタマイズして、Java のデバッガを作る内容でした。
JVM の仕様と HotSpot の実装の説明を交えつつ、 デバッガに必要な機能を実現するまでの道筋を立てて話していたので、 Python に詳しくない私でも問題なく理解できました。
ちょうど Java Day Tokyo 2016 にもデバッガ関連の話があったので、実際聞いてみたところ、 Java スタックと native スタックを透過的にデバッグしたい需要は結構あるよね、と自分の中で勝手に納得しました。
[CD-6] SmartNews のニュース配信を支えるサーバ技術
SmartNews の瀬良さんによるセッションです。
ニュース配信のウラで、実装面と運用面においてどのように工夫したかの話でした。 基本的に、実装は既存のライブラリとフレームワークを、運用は既存のツールとサービスを積極的に使うイメージです。
話に出てきた以下のものは個人的に気になるので、機会があったら試してみたいと思います。
完全に余談ですが、発表スライドに前職の先輩の写真が載っていました。
[GH-7] Java Puzzlers
寺田さんと櫻庭さんが送る、Java のパズルをみんなで解いていく楽しいセッションでした。
普段でよく使ってる演算子やメソッドでも、細かい動作を把握していないと、 出来あがったプログラムが意図しない奇妙な動きになるかもしれません。
言語仕様を把握して、Javadoc をちゃんと読むことはとても大事であると、 改めて気づかされました。（前の二問が不正解なので…）
Java Day Tokyo 2016
各セッションの資料が、Oracle Technology Network からダウンロードできるようになっています。
[基調講演] Innovate, Collaborate, with Java
例年通り、基調講演は日本オラクル社長の杉原さんを皮切りに、多くの人が入れ替わり立ち代わり話をしていくスタイルでした。
杉原さんが最初に日本の現状と課題に対して、IT による生産性向上が急務であると話したのはとても印象深いでした。 私が思うには、グローバル化に影響で先進国家のほとんども似ているような課題を抱えていて、 結局のところ、どのように IT 技術を使って人の幸せに促進するかに帰着します。
杉原さんのあとに多くの方が登壇したが、内容をかいつまんでお伝えすると、以下のようなものでした。
- 成長し続けている Java エコシステム
- Java Magazine を購読しよう
- JCP は変わる、もっとオープン、透明、参加しやすように
- Java SE/ME/EE のこれまでの軌跡とこれからの道
- 損保ジャパンの事例：基幹システムを COBOL から Java EE 7 へ
- バイクでのJava Japan Tour
- JJUG の活動
- デモ：Secure IoT Gateway でドローンを飛ばす
- デモ：Pepper + Oracle Cloud Platform
基調講演の動画が公開されているので、もし興味ありましたら是非ご覧ください。
[1-A] Java SE 9 Overview
Oracle の Bernard Traversat さんが Java SE 9 で予定される変更点を説明するセッションでした。
主な変更点は
- Project Jigsaw の導入
- G1 GC がデフォルト
- REPL 環境として JShell が追加される
- 新しいバージョンの付け方
- ライブラリのモジュール化に伴い、sum.misc.* や sum.reflect.* などの内部 API を削除
などがあります。
これらの変更点のうち、 開発者にとってインパクトが最も大きいのは sum.misc.* や sum.reflect.* の削除でしょう。
一部広く使用されている API はモジュール化する際、可視性は public のままにするが、 API 全体の互換性が維持されるかはなんとも言えない状況なので、可能であれば、Java 9 EA リリースを試してフィードバックしましょう。
[2-A] Project Jigsaw ではじめるモジュール開発
櫻庭さんのセッション、（私が受講したこの二日間の）第３弾です。
このセッションは Project Jigsaw が解決しようとする問題と、 Project Jigsaw が Java 9 入り決定までの歴史と、 モジュールの基本的な使い方と注意点を紹介しました。
[3-C] Java Concurrency, A(nother) Peek Under the Hood
イベントでいつも HotSpot の話をしてくれる David Buck さんですが、 今回のセッションは並列プログラミングにまつわる話で、 主にメモリ・モデルと、JITでコンパイルされたコードの分析でした。
6/9現在セッションの資料はまだ公開されていないので、内容を少し詳しく説明したいと思います。
マルチスレッドプログラムは性質上、 スレッドの動作を観察（ログ出力、ブレークポイントによる中断）するだけでも、 全体の振る舞いに影響を与えるので、 バグが織り込まれたら、ほとんどの場合は heisenbug*3 になります。
Java ではマルチスレッド動作の正確性を保証するために、
- synchronized
- メモリ・モデル
- java.util.concurrent（JSR-166）
などの仕組みが用意されました。
メモリ・モデルは書き込まれた値が正しく読み出される条件と、開発者が頼っていい振る舞いを明確にするものですが、言い換えるとスレッドが悪さをする範囲を制限するものです。メモリ・モデルを理解するには happens-before（前に発生）の概念がとても重要です。一つのアクションが別のアクションの「前に発生」なら、前者は後者から見えるほか、順序も後者の先になります。
排他制御を行う synchronized と値の可視性を保証する volatile は、まさに複数スレッド間の「前に発生」の関係を確保するための仕組みです。また、値を変更させない final は読みしか許さないから、実質上の「前に発生」が保証されます。
「前に発生」の関係が保証されていない Java プログラムでは、コンパイラの最適化によるメモリアクセス順序の調整の影響で、予想されない動作になる可能性があります。 もし運が悪くこのような不可解な動作に直面した場合、HotSpot の disassembler である hsdis を使うと、何か役に立つかもしれません。
セッション最後に、 volatile の有無によって HotSpot Client/Server VM の動作が変わるコード例と、hsdis によるコード例の解析結果、が紹介されました。
[4-A] Java 9 で進化する診断ツール
NTTコムウェアの末永さんによるセッションです。
内容はJava 9の診断ツール、jcmd と jhsdb の紹介です。
機能拡張された jcmd の方は開発中によくあるシーンに合わせて、その場合に使えるコマンド例を説明しました。
新しいツール jhsdb は基本な使い方の他、HSDB を中心に説明しました。 ただし、native の C/C++ コードでクラッシュした場合、最後はやはり GDB にたどり着くことになります…
最後の GDB の話を聞いた瞬間、だったら最初から GDB で Java スタックと native スタックを両方扱えれば楽なのになぁー、と思いましたが、 よく考えてみたら、この思いこそPython と GDB で Java デバッガを作るモチベーションでしょうね。
[5-D] オラクルコンサルが語る Java SE 8 新機能の勘所
Oracle のコンサルである伊藤さんによるセッションです。
Java SE 8 の主な変更点である
- Date and Time API
- Lambda 式
- Stream API
を、パフォーマンス分析の観点で旧来のソリューションと比較して、ついでに Java Flight Recorder を紹介する内容でした。
私自身は開発においてこれらの新機能をよく使用していたので、比較結果は大体期待通りでした。 Lambda 式の例外処理の話を少し期待したが、時間の関係か全く触れなかったので、個人的には若干物足りなさを感じます。
まとめ
JJUG CCC も Java Day Tokyo も以前参加したことがあるが、 このような近い時期に開催されたイベントに連続参加するのは今回がはじめてです。
Java のエコシステムはコミュニティによって支えている部分が大きいせいなのか、 イベント講演者の顔ぶれは大体同じです。（そして会う回数が増えるにつれてなぜか親近感がわく…）
講演者の顔ぶれが同じであっても、それぞれのイベントの位置づけがはっきりしているので、 プログラムは相互補完的な構成になっていて、照らし合わせられるような内容もあります。 記憶が新しいうちにさらに刺激を得られるから、結果的に知識も身につきやすくなります。
もし今後このように近い時期に開催されるイベントに参加する機会があったら、是非ふるって参加してみてください。 きっとたくさんの収穫が得られると思います。
Agile Japan 2016 にワイワイ参加してきました！（2/2 : どうやってテストするのさ 編）
開発部の野口です。
アプレッソから 10 名で参加してきた Agile Japan 2016 の感想シリーズ、後編をお届けします！
前編はこちら。
さて、アプレッソには QA チームがあり、開発と QA でどうアジャイルにやっていくかというのが一つの大きなテーマになっています。
この後編では、アジャイルなテストにまつわるセッションの感想をお届けしてまいります。
目次
- 目次
- 特によかったセッション！
- やれる気がします
特によかったセッション！
前編と同様、各参加メンバーに特によかったセッションを選んでもらいました。
セッションの簡単な紹介は私（野口）、感想は参加メンバー各位の文責にてお届けします。
多くの講演資料が、Agile Japan 2016 のプログラムページからダウンロードできるようになっています。
アジャイル開発に適した要件の作り方 ～何をどこまで決めればよいのか～
アジャイルなソフトウェア開発の特徴の一つとして、まとめて開発し、まとめてテストするのではなく、機能を小さな単位で一つひとつ着実に完成させていく（動くソフトウェアに変換していく）、ということがあります。
小さな単位で開発し、テストしていくためには、要求の切り出し方も従来通りにはいかず、工夫が必要となります。
そのための方法を紹介するセッションだったようです。
DEEP 特性と INVEST 特性を意識してユーザーストーリーを作っていく（谷平）
自分はテストエンジニアで、今までアジャイルという概念を本でしか読んだことはなく、実践はこれから始めていくという立場です。
Scrum などでの開発の進め方というのは本を読んである程度こんなものかというのが想像でき、テスターはプロダクトオーナーから要求を引き出すのを手助けできるポジションにある! という話を聞いてなるほどー、と思いはしたのですが、そもそもその要求ってどう決めてプロダクトバックログに落とすんだっけ？ というところがよくわかっていなかったので、このセッションを参考にしようと思い参加をしました。
プロダクトバックログに求められる DEEP 特性や、その特性を満たす目的、手段、使用できるフレームワークが体系的にまとめられていました。
書き留めることができたものを以下に記載しますが、なんの目的を満たすために何を使えばよいのか、という組合せのところがすっきりまとめられていて、わかりやすくてよかったと思います。
- Detailed appropriately : 適切な詳細さ
- 目的 : Sprint 計画に着手したい
- 手段 : 要件記載ルール、画面イメージなど
- フレームワーク : ユーザーストーリー、Storyboard
- Estimated : 見積り済み
- 目的 : 開発する順番を決めたい
- 手段 : 相対的、大まかに見積もる
- フレームワーク : Planning Poker
- Emergent : 創発的（後発的な技術要求をチームが発見した場合にあとから進化させられる）
- 目的 : 開発チームやユーザーとの対話で機能を改善したい
- 手段 : ビジネスモデルやユーザー像を共有して創発を促す
- フレームワーク : Lean Canvas、Pragmatic Persona
- Prioritized : 優先順位づけがなされている
- 目的 : 開発する順番を決めたい
- フレームワーク : User Story Mapping
また、この中でユーザーストーリーが満たすべき特性として INVEST 特性というものがあるそうです。
検索すると以下のページが見つかりました。
このセッションで、どうやるとうまくいきそうか、ということはわかりました。
実際にやってみると最初は大変に苦労しそうですが、それでも何も知らない状態から始めるのに比べると数段楽になりそうというのは確かです。
あとで DEEP 特性について検索してみると『スクラムを活用したアジャイルなプロダクト管理』という本が引っかかってきたので、これも読んでみて次の開発に役立てていこうと思います。
アジャイル開発における品質保証と人材活用
続いては、品質マネジメント部のマネージャーである東と、同じく品質マネジメント部のメンバーである金澤が聞いてきた話です。
かなり毛色の違う業界の話ながらも、期待に沿う内容だったようです。
スピーカーはグリーの村上薫さん、市原楓さん。
エンタープライズでもゲームでも、苦労しているところは同じ（東）
私はエンタープライズパッケージの QA エンジニアですので、コンシューマー向けゲームの QA をどのようにやっているのか、とても興味がありました。
はじめチョロチョロ なかパッパ
開発の状況に応じてテストのやり方を変える（はじめチョロチョロ = 仕様の変化が激しいうちは正常系に注力、なかパッパ = 仕様が落ち着いてきたら網羅的に確認する）という考え方は、我が QA チームも取り入れているので、頷きながら話を聞けました。
一方で、開発・QA フェーズの後にユーザー参加の「ベータテスト」という概念が存在し、「ベータテストで "面白さ" を評価してほしいので、それを阻害するバグはその前までに取り切っておく」という考えは新鮮でした。
これまでは、アジャイルで開発フェーズに QA も入った際に何をしよう……と漠然と考えていましたが、この話を聞いてたとえば「使いやすさ」といったキーワードを立てて、それの評価を阻害するような問題の検出を開発フェーズ内で行う、というようなアプローチを行ってみても面白いな、と思いました。
繁忙期に対応できる柔軟な体制作り
次に、QA は繁忙期に人が足りなくなるということがあり、それを克服するために「社内の手が空いている人に助けてもらう」「特例子会社*1に協力してもらう」という施策を行っているという話がありました。
それを実現するために、（ほとんどが QA 経験なしの方であるため）徹底した作業マニュアル化やコミュニケーション手段の工夫などを行っているとのことです。
確かに、QA フェーズは開発の遅れや想定外の不具合による戻りなど諸問題を吸収しがちになるため、状況に応じて増員が必要になります。
最大人数を常時確保するのはコスト面から承認されにくいため、柔軟に対応ができる体制を整えておくことは、安定して QA を行うためにとても大事なことです。
ただ、単純にマニュアル化すれば誰でも QA ができるのか、というとそれは違うと思いますので、運用できるようになるまでは相当の苦労があったのではないかと想像しました。
また、「誰でもできる」ということになってしまうと、それまでの QA 専任の方のプライドも気になります。
このあたりは、専任の方はより高度で専門的な QA を担当し、本来であれば自動化すべきだがサイクルの早いゲームでは自動化しても使い捨てになってしまう定型的なテストを非専任の方に回して、バランスを取っているのではないかと推測しています。
エンタープライズの対極に位置するように感じていたゲームの QA を通して、結局は自分たちのことのように聞くことができました。
みんな苦労しているところは同じですね！
他部署のメンバーが自社プロダクトを理解する機会にする（金澤）
コンシューマ向けのゲーム開発としての講演なので参考程度の受講でしたが、いくつか面白い取り組みがありました。
- 社員のタスクをすべてカンバン化（可視化）していること
- テストの負荷が高い際には他部署の人にもテスト実施してもらうこと
一点目は、直感的に効果を想像できます。
二点目について、コンシューマ向けプロダクトの品質には暗黙的に「誰でも理解でき、操作できること」が求められると思いますが、それを有効に確認できる面白い取り組みだと思いました。
また、開発部署以外の人は自社プロダクトに触れる機会が少なく、十分に理解できていない場合が少なからずありますが、この取り組みによって自社プロダクトの理解が進むことも期待できると考えます。
アプレッソでいうなら、主にセールス担当やサポート担当の方に触れていただき、フィードバックを得る機会があってもよいのではないでしょうか。
新米スクラムマスタとQAおじさんのアジャイル珍道中
そしてそして、アプレッソ参加者から圧倒的な支持を得たこのセッションです。
私も気になっていたのですが、同時間帯の平鍋さんのセッションが気になって断腸の思いで……。（平鍋さんのセッションもとてもよかったので悔いはありませんが！）
内容はまさに開発と QA でやっていこうとしているアプレッソの先を行くような、期待に応える大充実のものだったようです！
スピーカーはソニーの永田敦さんと、ニッポンダイナミックシステムズの豊田昌幸さん。
開発プロセス全体を通して、「神様」であるテストケースを目指す（陳）
アジャイル開発のプロセスにおいて、開発担当と QA 担当の理想的なつきあい方を提示してくれました。
アジャイルの取り組みを始めて間もないアプレッソにとって、実に学ぶところの多いセッションでした。
私の偏見かも知れませんが、よく見かけるアジャイルの事例の多くでは、要求仕様と開発の間のギャップを埋めることに着目していて、QA 担当がいるような大きなチームでの QA のあり方はもちろん、QA とのつきあい方にもあまり触れていませんでした。
そういう着目点の穴を埋めるように、このセッションでは、一緒に仕様を作るところから始めて、最後の評価まで、開発プロセス全体を通して、「神様」であるテストケースにたどり着くまでに、フィードバックループがどのように広がっていくかを説明しました。
まず、仕様設計段階の開発と QA による仕様レビューは常に違う視点からフィードバックをもらい、仕様が必要以上に複雑にならないよう、盛りすぎないように防ぎます。
そして QA のテスト設計と開発の詳細設計の段階でも、テストの評価内容を共有しておくことで、違う視点からフィードバックをもらい、テストケースの漏れと実装上の穴を防ぎます。
最後に評価とバグ修正の段階でも常にフィードバックすることで、ユーザーストーリーとテストケースの間の溝を埋めていきます。最終的には、「神様」であるテストケースにたどり着きます。
セッション内で提示した理想のアジャイルというゴールまでの道程は遠いですが、他のメンバを巻き込んでフィードバックループを広げるために、今の自分にできることを常に意識して、チームメンバの間に強い信頼関係を築けるように実践していきたいと思います。
テストケースが製品の詳細な振る舞いの仕様書になる（伊藤）
「ペアテスト設計」
ペアプロならぬペアテスト設計というのが面白いと感じました。
テストケースのレビューは行いますが、二人共同でテスト設計していくというのは実践してみたら知識の共有に役立つかなと思いますし、相乗効果でよりよいテスト設計が行えるかもしれないなと。
「フィードバックループの広がり」
最初 PO と QA が行っていた仕様レビューのフィードバックの流れが広がり、開発も巻き込みさらに様々な工程で実施されていったのが興味深いです。
会話しフィードバックしあうという文化（？）のようなものが形成されていったのではと思います。
アプレッソでも積極的に会話を行い、そういった流れや雰囲気を作っていきたいです。
「テストケースは神様」
フレーズも力強くて、一番印象に残りました。
フィードバックループを続けていくことで、最終的にテストケースが製品の詳細な振る舞いの仕様書になったといいます。テストケース = 仕様書という発想はありませんでした。
仕様書と呼べるということは、仕様を相当落とし込んでおり、開発や PO と綿密な連携が必要不可欠であることは想像に難くありません。ですが、そこまで落とし込めたならば、テストケースの不足や誤りを防ぐのに効果を発揮しそうです。
また、テストケースは一覧性があって仕様を読み取りやすいつくりになっているのではと想像します。
現状、我々が作成しているテストケースでは観点毎にシートが分かれており、フリーフォーマットで作るため、仕様を確認するには不向きなつくりになっています。
仕様書としても活用できるようなフォーマットで作成することを検討してもいいかもしれないと考えます。
品質を向上させるフェーズで QA としてどんなフィードバックができるか（金澤）
フィードバックループの成功例として、興味深く聴講しました。
「開発フェーズ (= 作りこむフェーズ)」 で開発・QA とも同時期に、要求仕様を検討することで、より精度の高い成果物になる。
その中で互いにフィードバックしあうことで得られた結果が仕様になり、その結果は「テストケース」としてまとめられ、仕様の神様となっている。
書くと簡単に感じられますが、まず要求仕様からテスト設計することの重要性を深く感じられました。
仕様書なしに「この機能はどうあるべきなのか、どう振る舞うべきなのか」についてのテストを考えることは旧来の QA に求められることが多くなかったからです。
講演では「結果としてテストケースが神様とされている」と刺激的におっしゃられていましたが、これは「仕様書を記載するより先にテストケースを作成」できていることの結果として面白いものと感じました。
また特徴的な表現として「開発プロセスが何であれ、システムテストフェーズでできることは変わらない」との言葉が印象に残りました。
「テストフェーズ (= 確認するフェーズ)」は品質をあくまで確認するフェーズであり、品質を向上させるフェーズで QA としてどんなフィードバックができるか、に注力しなければならないと感じました。
Agile Japan 2016 全体を通しての感想
最後に、Agile Japan 2016 全体を通しての感想を一つご紹介しておしまいにします。
まずは信頼関係を改善していくこと（金）
アプレッソの開発・QA では、現在、アジャイル手法の導入で大変盛り上がっています。
開発フェーズからQAメンバーを投入し、プロジェクト後半に発生するクリティカルな不具合を早期に見つけ、よりよい品質の製品をより早くお客様に提供しようとしています。
しかし、これまでの「開発フェーズの完了後に QA が本格スタートする」というスタイルから、「開発と QA が一緒にスタートする」アジャイル手法への変更で、理想的な製品が期限内にリリースできるか、漠然とした不安を持っていました。
QA はリリースに大きな責任を持っているため慎重に行動しないといけませんが、これまでの経験上、新しいプロセス導入を予行演習なしで本番に導入した場合には、とてもリスクがあると考えています。（もちろん成功するケースもまれにありましたが、ほとんどが失敗しています。）
短いイテレーション期間内に QA がどこまでどんなテストをするのか、具体的な方法を見聞きして、少しでも不安感を解消するために、今回、Agile Japan に参加することにしました。
今回のAgile Japanで最も良かったと感じたのは、信頼関係の改善を優先すべきということです。開発は開発なりのスタイルがあり、QAはQAなりのスタイルがあるのに、急に共同作業することでいろんな摩擦が起こる可能性は非常に高いと思います。どれだけよいプロセスを持っていても、この問題を解決しないと結局プロジェクトは残念な結果に終わるのではないでしょうか。アジャイルも数多いプロセスの中の一つにすぎません。結局、人がやるものです。
チームのメンバー全体が、共通の価値観を持って、楽しく働ける職場を作るのが最も重要だと思いました。
そして、メンバーの平準化も必要です。もちろん経歴が長いほど自己のナレッジも増えるため、経験が足りないメンバーよりはできることは当然ですが、経歴が足りないメンバーがより積極的に動ける雰囲気を作るのも大事です。
楽しく働ける職場を作るための手法として、ほとんどのセッションで話していたのが「情報の可視化」です。直感的に感じることが大切なので、デジタルではなくアナログで情報を可視化した方がよさそうです。
アプレッソ内でも付箋を積極的に活用するようになっていますが、プロジェクトの進捗以外にも個々の趣味趣向などに関する情報なども可視化して、メンバー間の距離感をできるだけなくすに力を注ぎたいと思います。
個人的に今回の Agile Japan で具体的なテスト方法よりは、プロジェクトに対する姿勢について学ぶことができました。（そもそも具体的なテスト方法を求めるのは現実的ではなかった気がします。当然ですが、会社ごと・製品ごとにテストの範囲や手法に差異があるため、何が正しいアジャイルテストの手法であるとは言い切れないと感じました。）
アプレッソにアジャイルのスタイルが定着するまで、色々な試行錯誤があると思いますが、前より品質がよく多様な機能を持つ製品を素早くリリースすることを想像するだけで、ドキドキしています！
やれる気がします
Agile Japan に参加して、それぞれのメンバーがそれぞれに色々なものを持ち帰りました。
新しいやり方を導入していくとき、今までのやり方を変えることは痛みをともなうので、「変えたくない」「なぜ変える必要があるのか」といった抵抗を受けがちです。
それだけをテーマにした本まで出ているくらいです。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (16件) を見る
また、やる気があっても、やり方がわからず、うまくいかないこともあるでしょう。
あまりにもやり方がまずいと、「変えたのがそもそも間違いだった」ということになって、ただ元のやり方に戻ってしまうということも起こりかねません。
しかし、今回多くのメンバーで Agile Japan に参加したことで、「なぜやるのか」についても、「どうやってやるのか」についても、知識や考え方が組織に芽吹き、根付き始めている感じがします。
アジャイルな見積りと計画づくりを始め、フロア内のホワイトボードや壁に付箋が貼りだされ、今までになかったような対話が生まれ始めています。
やっていけそうです！
*1:「障がい者の雇用促進及び安定を図るため、特別な配慮を行っている子会社」のこと（セッション資料より）
