JavaOne 2016 3日目 & 4日目 - Message in the (Panama) Canal
こんにちは、開発部の野口です。
案の定 3日目のレポートは飛ばしてしまいましたが……巻き返していきます。 例によって、特に印象に残ったものをピックアップしてお伝えします！
Connecting Oceans with Project Panama: A Journey into Native
JNI の置き換えや Vector API の追加を目指す Project Panama についてのセッション。
Project Panama という名前は（ご想像の通り）北アメリカと南アメリカの境にあるパナマ運河からきていて、”connecting the gap” をコンセプトとするプロジェクトです。つなぐのは、Java と Native との間の gap、ですね。
Project Panama は JDK 9 には入りません。
JDK 10 以降でのリリースを目指して、鋭意研究開発中です。
野心的な機能が色々と含まれますが、すべてを実装し尽くしてから出すというよりは、部分的に使えるようにして、早くリリースすることを目指しているそうです。
Java と Native とをつなぐ、安全で、簡単に使える、高速なインタフェースを構築することが大きな目標です。
Java がネイティブコードと連携するための方法としては JNI があり、また JNA をはじめとする、JNI の使用を容易にするためのライブラリも広く使われています。
Project Panama は、それらを「安全性、使用の容易さ、速さ」の 3 つの面で超えることを目指します。
よくばりですね！
簡単なデモもありました。
jextract というツールで C のヘッダを読み込んで自動生成されたクラス群を使って、OpenGL のライブラリを呼び出します。
▲ネイティブっぽい雰囲気の Java コード
実際のコードを見ると、想像以上にネイティブコードっぽい Java コード、つまりネイティブとの一対一対応に近いラッパーを Java のクライアントコードから触ることができていて、これらのクラス／インタフェース群がすべてコマンド一発で生成されるのだとしたら、かなりナイスです。
安全性についても色々と考慮されており、さらにこれでパフォーマンスも JNI を上回るとしたら……。
AutoCloseable や 関数型インタフェースといった近年 Java に入った機能も大いに活用して設計されており、たしかにこれならやれるのかも、と期待が持てます。
ただし、あくまで研究開発段階ということで、今後仕様や設計が変わる可能性は大いにあるとのことです。
実際、セッション終わりの質問タイムも紛糾しました。
まだまだ課題は山積みのようですが、業務上 JNI のつらさを味わうことがちょいちょいあるので、期待したいところです。
Thinking in Parallel
Stuart Marks と Brian Goetz というグルーヴィーな登壇者による、並列処理についてのセッション。
今後入る予定の新機能についての議論があるかなとも思っていましたが、案外そういうのはなくて、基礎的な内容でした。
にも関わらずここに書いているのは、とても面白かったから！
大まかに言って、前半は Stuart が Stream API の価値について説き、後半は Brian が並列処理についての議論をするという段取りでした。
ごく簡潔にまとめてしまうと、Stuart の主張は、従来の for ループを使うよりも、Stream API を使用するほうが常によい。
理由は、新しいから、カッコいいから、関数型だから……ではなく、「抽象性のレベルが（for ループよりも）上だから」。
ごもっともです。
たとえば C を使わずに Java を使うのと（細部にこそ違いはあれ）同じなのかなと思います。一方で、「それでも Java でなく C を使うケース」というのもあることを考えると、完全な論理ではないとも思いますが、少なくとも、（C 言語を使うのに十分な正当性が必要であるように）for ループを使うのには十分な正当性、たとえばパフォーマンスのボトルネックであることが特定されているとか、が必要と言えそうです。
一見 Stream で処理するのが難しそうな「値のリストをチャンクに分割する処理」も、「インデックスのストリーム」という考え方を導入することで Stream で処理できるよ、という例には目を開かされました。*1
それから、後半の Brian の主張はというと、こちらは「並列化するほうが常によい」……ではもちろんなく、必要なときにだけすべし、でした。
理由は、「並列化は最適化だから」。はい。
並列化はたいてい、メモリ空間と効率（省エネ）を犠牲にして、スループットを向上させるために行います。よって、その費用対効果が十分だと判断できる場合以外には、すべきではありません。
Stream API は並列処理をサポートしています。
ここで、Stream API で並列処理によってスループットが上がる可能性があるための条件として、
- データの数が多く、一件あたりの処理コストも高いこと
- データの（メモリ上での）局所性が高いこと
- 処理の分割コストが低いこと
- 最終的な処理結果の統合コストが低いこと
- 順序に依存しないこと
が挙げられていました。
美しいリストです……。
もちろん、これらの要素を感覚で判断して決めてしまうのではなく、実データ（少なくとも、それに近いデータ）による実測が必要です。（最適化ですから最適になっていることを確認しないと！）
なお、上の議論は値の計算処理を前提としていて、I/O が絡む場合は少し変わってきます。
Let’s Get Lazy: Explore the Real Power of Streams
『アジャイルプラクティス』や『Java による関数型プログラミング』などの著書を持ち、JavaOneでも例年数多くのセッションを担当している Venkat Subramaniam による遅延処理についてのセッション。
去年は縁がなく、今年初めて彼のセッションを取ったのですが、さすが期待通りの内容でした。
まず Haskell の動作や Scala の lazy キーワードによる遅延評価を紹介したのち、Javaでは Supplier のラムダ式で同じようなことができるよね……、といった具合に、一歩一歩下地を作ります。
個人的には、評価した値を再利用するパターンも何か紹介してくれるかなと期待していた（結局なかった）ので、そこにはやや不満もありましたが、全体としての構成と運びが見事すぎて、帳消しになりました。
後半は、Stream API がいかに lazy であるかの紹介。
Stream は終端処理が呼ばれるまではあくまでパイプラインを組むにすぎず、各種の条件（filter）や変換（map）は終端処理を呼んだ時点でまとめて処理されます。
そのため、個々の処理が行われる回数は、従来の for ループで効率的にロジックを組んだ場合とまったく変わらない。ということを、実際の動くコードで、デバッグプリントも使いながら巧みに説明します。
▲なんかペンみたいなやつでパイプラインを示す
▲デバッグプリントでどのロジックが何度呼ばれたかを示す
どれも既に知っていることなのですが、よく整理された説得力のある説明で、知識が更新され、定着していきます。
終盤には無限ストリームを説明し、またリストを返すメソッドをストリームを返すメソッドにリファクタリングすることで、行われる処理の量（実行時間）を大きく削減するというデモも行いました。
この辺のコンセプトは彼の著書である『Java による関数型プログラミング』でも説明されている（されていた……はず）のですが、こうして説明を受けることで本当に明日から使える知識になります。
こういうところ（すぐれた教師の教えを直接受けられること）にも、JavaOne のような技術カンファレンスの価値はあります。
Ask the JDK Architects
去年も色々な面白トークを聴くことができたこのセッション。
今年は Mark Reinhold、John Rose、Brian Goetz の 3 名が登壇して、参加者からの数多くの質問に答えました。
▲The JDK Architects
今年のキーノートでまさに Brian が発表していたローカル変数の型推論について、去年も話題に上がっていた（気がする）「Java で一番後悔していること」、果ては彼らが好きな IDE まで……。
いくつかピックアップして紹介したいのですが、いまいち聞き取れなかったところの補完をするのに手持ちの iPhone *2 だけでは心許ないので、日本に帰ってから補足します！！
Oracle Appreciation Event
そして……会社から JavaOne 行かせてもらってる組として役得としか言いようのないこのイベント……！
▲今年は AT&T パークで行われました
Sting のステージ開始から 2 曲目で早々に Gwen Stefani が（再）登場し、一緒に「Message in a Bottle」を歌うなどしていました。
別々のスターが同時に二人ステージ上にいる状況に混乱して、少し泣きそうになりました。
▲Sting & Gwen Stefani!!
JavaOne 2016 も残すところあと一日。
最後（蟹 One）まで気を抜かず、励みます。
JavaOne 2016 2日目 （その2）
こんにちは、開発部の陳です。
同行している野口とは選んでいるセッション構成が少し違うので、 そのうちに印象の深いものを、2日目レポートの裏番組でお送りします。
Pick Diamonds from Garbage
セッション名の通り、ゴミ（GC ログ）からダイアモンド（有益な情報）をあさる方法を紹介するチュートリアルでした。
構成は順に、 KPI の説明、GC ログの読み方、ツールの紹介、Q&A になっています。
GC の KPI を説明するのに、 バカンスでサンフランシスコからハワイに行くのに、 戦闘機と旅客機どっちが適切かという面白い比較をしました。
- Latency = 一人の乗客を運ぶのにかかる時間 / GC pause time
- Throughput = すべての影響を考慮した上で、24時間で運べる乗客数 / useful works
- Footprint = 一人の乗客を運ぶのにかかるコスト / CPU, memory
この例えは一見奇抜ですが、GC を広い意味でオブジェクトの移動として捉えれば、納得できます。
そのあと GC ログの読み方を紹介したが、
- Java の実装ベンダー
- JVM バージョン
- GC アルゴリズム
- 起動時引数
によって、形式だけでなく含まれている情報もかなり違うという無情な現実を突きつけられました。
さらにその現実の残酷さを実感するため、ここでこの曲を流しました…
最後に現実との戦いに生き残るため、いいツールを紹介してくれました。
GC ログをアップロードすると、人が読みやすい形式テーブルやチャートに変換してくれるほか、 さらに統計情報や、GC の動きを分析して、可能な問題点を洗い出すという便利なツールです。 REST API も提供しているので、パフォーマンステストを含む CI に組み込むと幸せになるかもしれません。
Functional Data Structures With Java 8
Zeroturnaround の Oleg Šelajev さんが、Java 8 ベースの「関数型データ構造」を紹介するセッションでした。
コレクションを関数型の手法で実装するという素敵な試みで、 個人的（主に情報学的な観点）にはとても面白い内容だと思いますが、 普通の Java 開発者が普段の仕事でプロダクションコードで使う場面はあまりないでしょう…
セッションのスライドはこちらで公開されています。
Disciplined Locking: No More Concurrency Errors
Checker Framework の中の人、Werner Dietl 先生と Michael Ernst 先生によるセッションで、
主に @GuardedByアノテーションの使い方とコード検証にまつわる話でした。
@GuardedByは 2006 年に Java Concurrency in Practice の作者、Brian Goetz さんが提案したもので、
データ競合を防ぐためのロックを文書化するためのアノテーションで、いまやデファクトスタンダードになっています。
しかし、このアノテーションには正式な定義がないため、解釈によって意図した使い方と異なる実装になる可能性があるので、
このセッションで、@GuardedBy の定義を厳密化したうえで、Checker Framework によるソースコード検証方法を説明しました。
ちなみに、このセッションの元ネタとなる論文はこちらです。興味のある方はぜひご一読を。
裏番組も（たぶん）つづきます
初日の会場の寒さに負けて、風邪気味になってきましたが、体力がある限り更新続けて多くの情報をお届けしたいと思います。 もし体力が尽きてダウンになったという事態になったら…まあ、その時にまた考えます。
JavaOne 2016 2日目 - JDK 9 がくるよ（7 月に）
こんにちは、開発部の野口です。
今年も JavaOne にきています。（二年連続二回目）
というわけで 2 日目のレポートをお送りします！！
と、バシッといきたいところなのですが、不覚にも PC の AC アダプタをうちに忘れてしまい、iPhone で書いています……。
ので、特に印象に残ったものをダイジェストでお伝えしてまいります。
JDK 9 Language, Tooling, and Library Features.
JDK 9 の最新状況もろもろをダイジェストで伝えるセッション。
さすがに人気でした。
1 年前にはちょうどこの JavaOne 2016 の期間中にリリースされる予定だった JDK 9 は、その後リリース計画が半年ずれ込んでいましたが、最近さらに延期の提案がされ、現在は 2017 年 7月の見込みのようです。
気を取り直して、内容はというと、まず Modularity（Project Jigsaw）の話、それから JShell や 新しい Javadoc などツールの話、言語への変更について、ライブラリについてのアップデート、そして最後に Q&A という構成でした。
私は、リリースがまだ先ということもあって、JDK 9 のことは今まであまりちゃんと追っていなかったのですが、今こうしてキャッチアップしてみて、やはり JDK 8 ほどのインパクトのあるアップデートではないのかな……というのが正直なところです。
とはいえ、大きなものでは Jigsaw による依存性管理の改善をはじめ、Java がより使いやすくなる地味ながら着実な変更が色々と入ってくる印象です。
個人的には、Java で REPL が使えるようになる JShell がなんとなく想像していたよりも便利そうで、ワクワクしています。
コマンドライン上で評価した値に（自動的に割り振られる）「$1」のようなシンボルを通して簡単にアクセスできたり、メソッド名を途中まで入れてからタブで候補の一覧が表示されたりと、軽快なデモを見ていると、触ってみたくなる感じでした。
動画が上がっています。
JShell のデモがこの動画の 12:40 からなので、ぜひ見てみてください。（もちろん JDK 9 の Early Access を入れて触ってみるのもよいです！）
また、Javadoc でインクリメンタルサーチが使えるようになるのも地味に嬉しいですね。裏で Java が……ということはさすがになく、JavaScript で実装されているそうです。
スライドも上がっています。
色々と詳細な情報が記載されているので、気になる方はぜひチェックしてみてください。
The Diabolical Developer’s Guide to Performance Tuning.
「Diabolical Developer（悪魔の開発者）」というやばそうな肩書を持つ人によるやばそうなセッション……のはすだったのですが、Java Champion の Kirk Pepperdine が登壇していました。
といっても、もともと予告されていたこのセッションの内容が Kirk Pepperdine のパフォーマンスチューニング手法を紹介するものだったので問題なし。
結果として、とても充実した内容でした。
パフォーマンスチューニングの王道に沿って（測る、仮説を立てる、少しだけ変える、測る、仮説を立てる……）問題を絞り込み、JVisualVM をはじめとした定番のツールを使って探り当てるという、言葉で説明してしまうとなんてことない内容なのですが、目の当たりにすると実に鮮やかです。「こうやってやればいいんだ！」という感動があります。
その考え方や手法自体は、今回のものではないですが、以下のスライドに紹介されています。
また、やはり今回のものではないのですが、今回のセッションに似た構成のセッションのビデオも見つけました。
解像度が低くて画面がよく見えないので少し辛いかもしれませんが……雰囲気は伝わるかなと思います。
Learn About DI and Web Frameworks Through Implementation
最後に紹介するのは、日本ではおなじみの、きしだなおきさんのセッション。
BOF（Birds of a Feather）というユーザセッションの枠で、入場チェックも特にないなどざっくりした運用の中、始まる少し前までは人もまばらだったのですが、始まる頃にはそこそこの人が集まっていました。
内容は、ドンズバでこれです。
私もこの記事は一度ざっと読んではいたのですが、改めて一歩一歩着実な説明を直接聞くことで、理解が浸透しました。
きしださんは（アメリカでセッションを担当できるからといって）特別に英語が得意というわけではなさそうで、セッション中少し言葉に詰まる場面もあったのですが、参加者は終始興味深く聞いていたように思います。実際、とても面白い内容でした。
しっかりした内実があれば多少言葉が苦手でもやれる国（アメリカ）、あるいは業界（IT）なのだよな……という思いを少しだけ強くしました。
つづきます
JavaOne はまだまだ続きます。
時差ボケもあり、私も同行している陳もへたり気味なので更新を続けられるかはなはだ不安ですが……！
そのへんのチャレンジも一種のエンターテインメントとしてお楽しみいただけると幸いです。
JavaOne 2016 1日目
こんにちは、開発部の陳です。
サンフランシスコで開催される JavaOne 2016 に来ています。
初アメリカで若干心細いですが、去年参加した野口も同行しているので、 いざとなれば経験者の知識に頼れば問題ないでしょうという気持ちだから、割りと気楽にやっています。
世間話はここまでにして、初日の状況を簡単にレポートします。
午前中のセッション
去年の教訓を活かして、ちゃんと事前に登録して、参加してきました。 ただ、時差ボケが心配なので、午前中は11時開始のセッション一つだけにしました。
参加したのはユーザグループフォーラムセッションの Coding with the Best: Learn How Great Developers Code Their Lives [UGF7870] です。
主な講演者の Bruno Souza さんは JUG の活動以外に、 Code 4 Life というサイトを運営していて、成功した開発者たちの経験をもとに、 開発者を志業とする人々がより簡単になりたい理想な自分になれるよう、 アドバイスなどを発信しています。
このセッションはまさに Code 4 Life の元ネタとなる開発者たちが経験を共有してくれるという内容でした。
似ているような経験を持つ開発者なら共感できるでしょうけど、 自分的には一人ひとりの話が早すぎて、内容も発散しているようで、 結論が見えていないうちにに終わってしまいました。
文章として書かれているものがあれば、もう少し追えたかもしれないが、 ここらへんはディスカッションという形式の制限かもしれません。
セッションの最後に出てきたチェックリストはいくつ具体的な建言が書かれていて、 以前読んだアプレンティスシップ・パターンを思い出させてくれました。
この本が未読の方は、Code 4 Life に登録してみるのもいいでしょう。
- 教訓：スライドのないセッションはつらいです。何も把握していないうちに終わってしまうかもしれません。リスニングによほどの自信がなければ、スライドのあるセッションに行きましょう。
昼休み
日曜日に JavaOne 弁当がないのは知ってましたが、朝来る途中にお昼買っておくのを忘れました。 午前中のセッションと Key Note の間に 30分しかなくて、会場の近くも店が少なかったので、 結局ちゃんとしたお昼を食べられませんでした。
- 教訓：日曜日（初日）は午前中のセッションに行く前に、お昼買っておきましょう。
Key Note
一言でまとめると、「火星探査は熱い！会場は寒い！」に尽きます。
開幕：Java の３つのＥ
最初は Java の３つのＥ ― Easy, Efficient, Expansive ― を軸に、 CERN、gatk、Twitter、Databricks などの企業や組織の事例を交えつつ順調に説明をこなしてきました。
しかし、Anita Sengupta 博士が登壇してから、 完全に NASA のイベントになったかのように、火星探査機にまつわる話しか出てこなくて、 火星の話は面白いけど、肝心な Java はいつの間にか完全に地球の重力圏から去ってゆきました。 そして Java が遠くに離れていくにつれて、会場の温度（物理的に）もどんどん下がって行きました…
寒すぎて生きていくのがつらいと感じた頃、やっと Java の話が再開しました。
火星のあとは引き続き Wavefront の事例があって、説明自体はかなり短いけど、 技術的に面白いことをやっている雰囲気が結構出ていました。
本番： Java SE 9
３つのＥの話が終わったあと、 Mark Reinhold さんが登壇して、Java 9を簡単に紹介しました。
JShell のデモには少しトラブルがあったけど、見せてくれた * タブ補完 * import によるパッケージ追加 は便利で使いやすようです。（JShell を使う場面自体は少ない気がするが）
JShell のデモにつづいて、Jigsaw の話に入って、jlink で小さめの JRE を自作する実演をしました。
そのあとは Brian Goetz さんが登壇して、少し Valhalla と Panama を紹介したあとに、短い本番が終わりました。
終局： Java EE 8
Anil Guar さんが Java EE 8 の進展と Java EE 9 のロードマップを説明したあとに、 パートナーが登壇して事例や意見を共有する形で終わりました。
ちなみに登壇したパートナーにはいつも Java Day Tokyo / JJUG でおなじみの富士通の数村さんと、 今年の Java Day Tokyo で事例紹介で登壇した興和損保の浦川さんの姿がありました。
感想
連続何回か Java Day Tokyo に参加してきたせいか、 現場で聞くキーノートのワクワク感がだいぶ薄れてきました。 そして、楽しい火星探査のおかげで、クダクダです。 さらに、会場が寒すぎて、途中で頭が痛くなってきて、話があまり頭に入りませんでした…
- 教訓：会場内でも防寒対策をしっかりしましょう。
追伸
JavaOne 2016 のサイトのオンデマンドビデオは火星探査の部分を切り出して別ビデオとして編集したものになります。 キーノートの内容を把握したいなら、こちらのほうがおすすめです。
アジャイル開発になったら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 チームメンバーの相互理解が深まる！
ということでいろいろな観点で書いてきましたが、やはり一番重要なのは人間同士の関係。なかなか「理解しましょう」と言ってもすんなりできないのが人間であります。
飲み会などでのコミュニケーションも重要ですが、やはり今やっているプロジェクトの中でその人が何をやろうとしているのか、何を大切としているのか、ということを知ることがプロジェクトの成功のための必要な要素です。
プランニングポーカーでは全員に判断と発言の必要があるので、誰かが場を支配することなく、それぞれのメンバーが持っている知識や観点、大切にしている価値観などが分かってきて、チームの相互理解が高まります。
終わりに
「見積り」のための手法として導入した「プランニングポーカー」。一見「見積り」という目的を達成するために面倒くさい作業をしているように見えましたが、実際は
見積り＋ヒアリング＋情報共有＋品質向上＋チーム感向上＋教育＋α=プランニングポーカー
という非常に大きなメリットのあるものでした。開発チームとプロダクトをより改善する方法として、今後も導入して磨き上げてみたいと思います。
この記事を読んで気になった方がいればぜひ試してみてください。「見積り」のイメージが変わることは間違いありません！
ということで、今後もアジャイルの取り組みをいろいろ紹介していきたいと思います。以上、土岐からでした！
