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 チームメンバーの相互理解が深まる！
ということでいろいろな観点で書いてきましたが、やはり一番重要なのは人間同士の関係。なかなか「理解しましょう」と言ってもすんなりできないのが人間であります。
飲み会などでのコミュニケーションも重要ですが、やはり今やっているプロジェクトの中でその人が何をやろうとしているのか、何を大切としているのか、ということを知ることがプロジェクトの成功のための必要な要素です。
プランニングポーカーでは全員に判断と発言の必要があるので、誰かが場を支配することなく、それぞれのメンバーが持っている知識や観点、大切にしている価値観などが分かってきて、チームの相互理解が高まります。
終わりに
「見積り」のための手法として導入した「プランニングポーカー」。一見「見積り」という目的を達成するために面倒くさい作業をしているように見えましたが、実際は
見積り＋ヒアリング＋情報共有＋品質向上＋チーム感向上＋教育＋α=プランニングポーカー
という非常に大きなメリットのあるものでした。開発チームとプロダクトをより改善する方法として、今後も導入して磨き上げてみたいと思います。
この記事を読んで気になった方がいればぜひ試してみてください。「見積り」のイメージが変わることは間違いありません！
ということで、今後もアジャイルの取り組みをいろいろ紹介していきたいと思います。以上、土岐からでした！
アプレッソ品質マネジメント部にだいぶ前に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とそれに対する議論を経て、我々で作る「アジャイル」の具体的なイメージがかなり具体的になってきました（なってきたような気がします）。
ということでバトンは受け取った、後は走るのみ！ ということでアジャイルの取り組みがアプレッソでは始まっています。
次回以降の記事では、実際にアジャイルへどのように取り組んでいるか、それに対する良いところ、悪いところなど気づいたことを紹介していきたいと思います。
お楽しみに！
最後に宣伝ですが、ぜひこの取り組みに参画してみたい！ という方、アプレッソではエンジニアを募集しています。ぜひご検討ください！ カモンジョイナス！
