アプレッソ品質マネジメント部にだいぶ前に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:「障がい者の雇用促進及び安定を図るため、特別な配慮を行っている子会社」のこと（セッション資料より）
Agile Japan 2016 にワイワイ参加してきました！（1/2 : やっていく気持ち 編）
開発部の野口です。
主に DataSpider Servista を作っています。日々 Java 書いています。
さて、去る 5/31（火）に開催された Agile Japan 2016 に、アプレッソから実に 10 名が参加してきました！
アジャイルとかやっていこうぜ的な気運が高まるなか、多くのメンバーがこのアジャイルの祭典にまる一日浸り、さまざまな刺激を受けて帰ってきたことは、組織の今後にきっと大きな（そしてポジティブな）影響をもたらすだろうな、と思います。
目次
- 目次
- 特によかったセッション！
- つづきます！
特によかったセッション！
それぞれのメンバーがさまざまな刺激を受けて帰ってきたわけですが、その中でも特によかったセッションについて、それぞれ感想を書いてもらいました。
Agile Japan 2016 に参加された方はもちろん、参加されなかった方もぜひ、昨今アジャイルなソフトウェア開発についてどんなことが話題になっているのか、様子を感じてもらえればと思います。
以下、セッションの簡単な紹介は私（野口）、感想は参加メンバー各位の文責にてお届けします。
多くの講演資料が、Agile Japan 2016 のプログラムページからダウンロードできるようになっています。
スクラムがイノベーションを加速する ～ソフトウェア以外にも適用されはじめたアジャイル～
基調講演の一発目は、何でもスクラムでやっていけるぜ的な意気込みを感じる、強烈なセッションでした。
スピーカーは Scrum Inc. の Joe Justice さん。
スクラムマスターは指揮者に似ている（willard379）
Awesome! という掛け声とともに登壇した Joe さん。平鍋さんが通訳をしながらのセッションとなりました。
アジャイルがソフトウェア開発以外の分野で取り入れられている事例が紹介されていました。
- 火星移住計画
- Amazon の物流センターで使われているロボット開発
- 政府機関
- ボーイング
- Volvo
- Bosch
- 農業
- ワイン造り
米国ホワイトハウスや日本の国土地理院、和歌山県といった行政分野で GitHub が取り入れられていることからも伺えるように、プロセスをより良くすること、良いものをすばやく提供しようという取り組みは、ソフトウェア分野に限ったことではなく、業界を問わずに起こっているムーブメントなのだということに感動しました。
また、「スクラムマスターの一番の仕事は、チームをハッピーにすること」という言葉が強く印象に残っています。
スクラムを導入しようとした組織が、最初は失敗したものの、スクラムマスター / アジャイルコーチが突破口となって最終的には成功した、という例はよく耳にします。
この講演を聞いて、スクラムマスター / アジャイルコーチというのは、オーケストラでいう「指揮者」の役割に似ているな、と感じました。
メンバーがそれぞれ高い演奏技術を持ち、「良い音を奏でる」という目的を共有していたとしても、それだけで良い演奏ができるというわけではありませんよね。
ひとりひとりが意志も個性もある演奏家です。各パートのテンポや大きさなどを俯瞰し、指揮棒や身振りによって演奏者に伝え、全体としてひとつにまとめ上げる。そんな指揮者の役割もオーケストラの不可欠な要素です。
ましてスキルレベル、得意分野、プロダクトに対する知識、ポジション、など不揃いな要素が多いソフトウェア開発においては尚更その必要性が高いのではないかと思いました。
ミーティングひとつとっても、全員が気兼ねなく思ったことを発言できる会議となるか、一部の声の大きい人、影響力の強い人、立場の高い人ばかりが発言する会議となるかは、議事運営のしかたによって大きく左右されます。
そもそも前者の空気感を醸成するというのもアジャイルの取り組みではあるのですが、「全員がプレイヤー」という状況で最初からそれができている組織であれば、きっとアジャイルでなくてもうまくいくのではないかと思うのです。
人の弱さ、強さを認め、考え方や感性の異なる個性を調和させ、目的を指し示し、文化を根付かせ、エンジニアの集合体を単なる烏合の衆である「グループ」から、同じゴールを目指す「チーム」に昇華させる。そこがアジャイルコーチの活躍どころなのではないかなと。
そんなことを考えさせられるセッションでした。
まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～
ソフトウェアテスト界隈では有名人である、オンザロードの kyon_mm さんと otf さんによるセッション。
技術的にディープな話かと思いきや、どう考えるか、どう取り組むかといったことを前面に出した内容でした。
理想の開発を貫く（田中）
このセッションを聞いて、本当に理想の開発を貫こうとしたことがあるのか、と自分自身に問いなおすきっかけになりました。
私は現在の開発で、スクラムを理想としたスタイルでパッケージソフトウェアの開発に取り組んでいます。
スプリントやかんばん、プロダクトバックログなどを活用して、素早く高品質なソフトウェアを作ろうと日々試行錯誤しています。
しかし実際にはうまくいかないことだらけで、チームのスクラムマスターが社内資料の作成に追われていたり、ふりかえりでは問題点を洗い出せず、テストは一部後回しになったりしていました。
そして、プロトタイプ開発ベースであったからとか、先行検証向けのリリース作業があったからとかいろいろ言い訳をするうちに、うまくいかないことをむしろ進んで受け入れようとする姿勢が染み付いてしまっているように感じました。
そんな中、このセッションの登壇者がまず言ったのは、「うちには優秀なエンジニアが揃っているので、本気を出せば、スプリント中にテストを終わらせて本当にリリース可能な状態に持っていくことができるのではないか。そしてやってみたらできました」というものでした。
正直力技ではないかと思う部分もありましたが、一番響いたのは、「理想の実現を妨げている要因は何なのか、みんなで話し合ってひとつずつ潰していきました」という言葉です。
私が今いるチームにも優秀なメンバーが揃っています。
そのメンバーを信頼して、理想的な形はなんなのか、どうしてそれを実現できないのか、一つ一つ話しあえば、実はスプリントが終わった時に、リリース可能な状態を作ることができるのではないかと思うことができました。
今まで、理想は無理だからどうやって現実的なところに落とし込もうか、という視点だったのが恥ずかしくなりました。
とはいえ、スプリント中に品質を担保するのに十分なテストを全て終わらせるのは非常に困難だと思います。
いわゆる統合テスト、結合テストなどと呼ばれるテストや、特定のユーザーシナリオを満たしているかを確認するテスト、さらには長期運用テストやパフォーマンステストなど、なすべきテストは数多くあり、多くの時間を必要とします。
これらについてどのようにテストを実践していったかも発表されていましたが、この点については早速チームのメンバーと話し、理想に一歩ずつ近づいていきたいと思います。
組織の壁を乗り越えるアジャイル開発
アプレッソにも当然複数の部署があり、部署間で連携しながらよい製品を作っていく必要があります。
そのために、KDDI では何をしてきたのか、というストーリーを、部長の佐々木が聞いてきてくれました。
スピーカーは和田圭介さん、北条裕樹さん。
がっかり感をなくすこと、バランスをとること、そしてエンジニアが楽しいと思えるチームビルディング（佐々木）
KDDI 株式会社の KCPS の管理コンソールの開発で、アジャイルを導入した経緯と導入当初の失敗談などの話を伺いました。
過去の開発では、仕様書作成→実装→試験→運用というように、「清く正しいウォーターフォール開発」が行われていましたが、プロジェクトを構成する組織（企画、開発、運用）が縦割りで、後工程で重大なバグが見つかったり、リリース後に要求した機能が実装されていないことに気づいたり、周囲の空気が「がっかり感」に包まれる状況になっていたということでした。
顧客ががっかりと感じる理由は、「当たり前のようにできると思っていたことができない」、「簡単なことが簡単にできない」、「（思っていたよりも）遅い」などいろいろ考えられますが、プロダクトを長く愛用してもらう、つまりプロダクトのファンになってもらうためにがっかり感の払拭は継続して取り組む必要がある重要事項であると、あらためて胸に刻むことができました。
このような課題がある状況下で採用されたアジャイルの手法はスクラム色が強かったように見受けられましたが、ウォーターフォール開発で行っていた成果物に対しての承認プロセスや、開発チームから運用チームへの引き継ぎ資料の作成など、ウォーターフォール開発で実施していたいいところもバランスよく残しているという印象を受けました。
ただし、アジャイルを導入した当初はいくつかの失敗があったとのことです。
たとえば、周囲の人間に「アジャイルだから簡単に仕様変更できる」と誤認識されたり、初期のユーザーストーリーマッピングではユーザーの行動（やりたいこと）しか議論できず、個々のアイデアを具体化したときに認識の齟齬が発生してしまったり、また、実装に追われるあまり振り返り会よりも実装を優先してしまった、というような失敗談が挙げられました。
このような失敗にも真摯に向き合い改善を繰り返していくマインドがアジャイルを実践するうえでは大事で、今まさにアジャイルを導入し始めた弊社にはとても参考になりました。
最後に、講師の方がおっしゃっていた「結果は大事だけどプロセスを楽しむ」という言葉が印象的でした。
「楽しさ」ということは製品開発において、また真剣にエンジニアリングに取り組む文化を醸成するうえでも大事な要素だと私は思います。私自身、DataSpider Servista のプロダクトオーナーと開発部のマネージャーという 2 つの立場で仕事をしているので、顧客に届ける価値を高め続けるというミッションを遂行していくとともに、エンジニアが楽しいと思えるチームビルディングを追及していくということを、あらためて強く思いました。
文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！
私が個人的に楽しみにしていた、マイクロソフトの牛尾剛さんとカラダメディカの野澤英歩さんのセッション。
牛尾さんは想像以上に強烈なスピーカーで、期待以上のものを受け取りました。
いらんことをしなければ、がんばらなくてもより多くの成果が出る（野口）
スピーカーの一人である牛尾さんの考えはブログでかねがねうかがっていました。
たとえば、「日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ」での「アメリカのエンジニアの生産性が高いのは能力が高いからではなく、仕事に対する取り組み方が違うから（大意）」という主張をなるほどー！ と思いながら読んでいました。
そうやって一度文字で読んではいた内容ながら、ご本人の言葉で聞くと浸透度が違う！ 「なるほどー」ではなく「本当に、現実にそうなんだ」と感じます。
（私たちは）いらんことをしているから、がんばっているのに思ったほどの成果が出ない。
（私たちは）いらんことをしなければ、がんばらなくてもより多くの成果が出る。
このことはあくまで一例で、他にも多くの示唆がありました。その原因が日本と西洋との文化の違いであること、どうすればその違いを埋められるか。 そうやって、高速なデリバリーを実現していく。
たとえば、現状の DataSpider のリリースサイクルは数ヶ月（パッチの場合）～数年（バージョンアップの場合）におよびます。これを、たとえば毎月リリースにできたら。
カラダメディカさん（リードタイム 13 日→ 3 日）や NEC ソリューションイノベータさん（8.5 ヶ月→ 1 週間）といった会社の事例で、それは可能だ、ということが示されました。
価値観や（全社的な）仕事の進め方のかなり根本的な転換が必要になるので、今すぐやろう、というわけにはいかないかもしれませんが、私はもう、やろうとすればできる、ということを知っています。
まずは 70 から始めてみる（willard379）
「DevOps! DevOps! DevOps!」こういう湘北高校みたいなノリ、好きですｗ
DevOps は本番環境へのリリースのリードタイムを短くして、早くフィードバックを受け、いかに顧客の望むものをすばやくリリースしていくか、というところに価値がある。
DevOps はアジャイルの土台の上に成り立ち、アジャイルは文化の上に成り立つ。
しかし伝統的な「日本文化」の上にはアジャイルは適用しにくい。日本文化と DevOps & Agile の文化は相いれない。
ではどうするか。
「日本文化」の上に「西洋文化」をインストールすればよい。
西洋文化では生産性が圧倒的に違う……ように見える。その秘密は、彼らが日本人よりも優れているからというよりも、彼らが本質的に必要なものにだけ取り組むマインドセットを持っているからである。
日本では「10」の労力が必要なものが、米国では「1」くらいの労力で行われていたりする。そんなマインドセットの上にアジャイル、DevOpsが成り立っている。
「Be Lazy！」
より少ない時間で成果を最大化する。いかに無駄なことがあるかを考えていく。いわゆるエッセンシャル思考。 チーム全員で西洋文化を共通認識として持っておく。一人でやっていてもつまはじきにあうのが落ち。
西洋文化を学んで実践すれば、アジャイルはうまくいくだろう、というお話。
私もアメリカにいたころ、大量のペニー（1 セント硬貨）をドル札に交換しようとして銀行に持って行ったとき、窓口のおばちゃんに「何ドルあるのか自分で数えろ」と言われ、「なんて不親切なんだ」と思った経験がありますが、考えてみればそれは銀行業務の本質ではないのですよね。
「かゆいところに手が届く」が常態化すると、やがてサービスを受ける側はそれが「あって当然のもの」と認識するようになります。
それが成熟したのが「日本文化」であって、そういった「おもてなし」な日本文化はおっしゃるとおりアジャイルとの相性がよくないのかもしれませんが、顧客あってこそのビジネスという点を考えると、どちらがよいかは一概には言えないなと感じました。
話は自分たちの組織だけでなく、顧客の「文化」まで及ぶ場合がある。そこが難しいところ。
80:20 の法則（パレートの法則）は日本でもよく耳にするところですが、「20 or 100」の極端な二者択一ではなく、「まずは 70 から始めてみる」とか、状況にあった選択をする必要がありそうですね。
つづきます！
この記事では、Agile Japan 2016 に参加したアプレッソのメンバーから、「やっていく気持ち」的なセッションにまつわる感想をお届けしました。
ところで、アプレッソには QA チームがあり、開発と QA でどうアジャイルにやっていくかというのも大きなテーマになっています。
次回は感想の後編として、アジャイルなテストにまつわるセッションの感想をお届けしてまいります。
お楽しみに！
アプレッソ開発部にJOINしました！
ブログをご覧のみなさま、はじめまして！5月に入社しました開発部の横山です。
今回は初投稿ということで自己紹介をさせていただきます。よろしければお付き合いください。
これまでのお話
学生時代は文系でしたが、趣味で少しだけプログラミングをかじっていたこともあってこの業界に入りました。 新卒入社した前職では協力会社として、業務系Webアプリケーションの保守開発に携わっていました。
おかげで他の人の書いたコードを読む機会が多く、その点については大変勉強になったと考えています。 一方で場当たり的なバグ修正が中心でクラス設計等を意識して実装する機会が少なく、次第に成長が停滞しているように感じ始めました。 また今までの開発の流れに従うことが求められる立場でもあり、何か新しいことを提案するのは難しい状況でした。
そこで、もっと実際のコードの中身にこだわって仕事がしたい、それが可能な環境で私自身のスキルも高めたいと考えるようになりました。 その折に弊社を知り、このたび縁あって入社する運びとなりました。
入社してからはガイドブックを読んでDataSpiderについて学び、直後にIT Weekに参加して製品説明にもチャレンジしました。 またSDKでアダプタ作成の練習をしたり、社内Slackと連携するbotを作ってみたりして今日に至ります。
入社してみて
「技術に対して真面目なプロフェッショナル集団」という印象を持っています。
dstnサイトや当ブログでご紹介しておりますように、技術を磨くための取り組みは日々実施されており、会議なども少なく開発に集中できる環境になっています。
特に進捗報告だけが目的の集まりはなく、タスク管理は各自で工夫して行っているように見受けられます。 一人ひとりがプロとして信用されているため、仕事の進め方についても裁量が大きいのだろうと想像しています。 自分らしくのびのびと開発ができる一方で、今まで以上に責任感を持たなければと少々緊張している今日この頃です。 そうした雰囲気にうまく溶け込んで、私自身の考え方も変えて（変わって）いこうと思っています。
そして技術力の向上も、間違いなく最優先事項でございます。
Gitによるソース管理やテストコードを書く文化など、初めて触れるあれこれが私を待ち受けています。
とにかく知識も経験も足りないので毎日が勉強ですが、これからは自分からも発信していけるようになりたいですね。
まずは試用期間を乗り切って、次に記事を書くときには少しでも成長した姿をお見せできればと思います！
趣味について
自己紹介は趣味について書くのがお決まりですが、これといったものがないのが悩みです。 強いてあげるならネットサーフィン、アニメでしょうか？インドア人間なもので……ちょっと恥ずかしいので箇条書きでお許しください。
ネットサーフィン
- 実家は常時接続サービスの導入が早い方で、小学生の頃からすでにネット漬けでした。
- ホームページを開設してCGI設置などもやりました。Internet Archiveに残っている当時のサイトは黒歴史です。
- ですがプログラミングを知るきっかけになったため、職業選択には役立ったかもしれません。初めて触れたのはたしかVBScriptでした。
アニメ
- 高校に入ると詳しい友人が一気に増えたこともあって、私も習慣的に観るようになりました。
- 会社員になってからは「アイカツ！」を心の支えとして平日を乗り切っていました。東京では木曜に放送されるため、あと1日頑張ろう！と前向きな気持ちになれます。
- 4月からは新シリーズが始まりましたのでご興味があればぜひ！
思いのほか長くなってしまい恐縮ですが、お読みいただきありがとうございました。
今後ともAppresso Engineer Blogをよろしくお願いいたします！
アジャイルへの挑戦と、アジャイルな挑戦 ～Agile Japan 2016 のロゴスポンサーになりました！
今流行りの男性育児休業から復帰した開発部の土岐です。社会復帰中です。
唐突ですが、今アプレッソ開発部で「アジャイル」が熱い！ 頻繁に開発部の中で「アジャイルとは何か」「どうすればアジャイルにできるのか」という議論が繰り広げられています。2016年5月31日(火)に開催される「Agile Japan 2016」には開発部から十数名が参加し、気になるアレコレの話を聞こうと息巻いています。
さらに鼻息荒く、今回「Agile Japan 2016」のロゴスポンサーとしてご支援もさせていただくことになりました。（上記ページにロゴスポンサーとしてアプレッソロゴが掲載されております)
というわけで、今回はアプレッソ開発部がアジャイル開発に向かおうとした経緯を書きつつ、「Agile Japan 2016」の気になるプログラムをアプレッソ開発部の主観で紹介させていただこうと思っております。
なぜ今アジャイルなのか？
アプレッソ開発部は常々開発プロセスを改善し続けています。2001年6月にDataSpider 1.0がリリースされ、現在最新バージョンは4.0。このDataSpider開発の15年近くの間、アプレッソ開発部は数々の成功と失敗をしながら、改善を続けて成長をしようともがき続けています。例えばこのブログでも、以下のような取り組みが紹介されています。
このような改善を続けていっても、うまくいくこともあり、当然うまくいかないこともあります（ブログには中々うまくいかないことが書かれませんが！）。 そしてまさに最近、とあるプロジェクトで「うまく回らない」状態になったことがありました。それが「アジャイル開発」に向けて舵を切る直接気のきっかけとなったわけであります。 そのプロジェクトはどのようなものだったのか？
プロジェクトの「うまく回らなさ」
それは多くの開発者が関わり、開発範囲も大きいプロジェクトでありました。そのためテスト範囲も膨大。多くのテストを予定通り行うためにも、テストのスタートとなる開発期限日にすべての機能の開発が完了することが必要でした。
しかし実際には、開発期限日までには開発は終わりませんでした。当然のことながら、見積もり段階ではその開発期限日よりも前に開発が終わるはずでした。しかし実際は見積もりよりも開発時間は長く必要であり、それが分かったのが開発終盤の時期。進捗も不明瞭であったため、テストの本格的スタートがなかなかできず、結果としてプロジェクトは大きく混乱しました。プロジェクトが「うまく回っていない」状態となったのであります。
ソフトウェア開発の「不確実性」
プロジェクトの終了後、その原因について多くの検討を行いました。その中で特に大きな原因として挙げられたのは「見積もり」と「進捗管理」のやり方です。
「見積もり」については、プロジェクトの最初に個々の機能の開発担当者が見積もるというものでした。開発者は自分の知識や過去の経験から判断して、だいたいそのくらいに終わりそう、と判断して見積もっていました。しかしこの見積もり通りにプロジェクトが進みませんでした。
また「進捗管理」も基本的に個々の開発者に任せられており、定期的にプロジェクト・マネージャ－が個々の開発者に進捗確認をしていました。しかし実際に開発が進んでいくと報告された進捗と実際の進捗が異なることがあり、見積もりとの整合性が取られないままにプロジェクトは進んでしまい、結果として混乱を招いてしまいました。
では「見積もり」と「進捗管理」を正確にやりましょう、という結論を出すのは簡単です。しかしその「正確さ」を完全に達成するのは非常に困難である、というのが我々の意見でした。なぜなら、ソフトウェア開発にはその途中でさまざまな予見できないことが起こり、多くの「不確実性」が存在するからです。
実際、以下のようなことは非常によくあります。
- 機能実装の難易度が高いところが実装終盤に見つかった
- 修正したモジュールの影響範囲が想定以上に大きかった
- 見積もり時に考慮漏れした要件がプロジェクトを進めていくと判明した
- 他のプロジェクトで人員が必要になりプロジェクトチームを減らさざるをえなくなった
このような「不確実性」はすべてをコントロールすることは不可能です。ソフトウェア開発の「不確実性」を織り込んだ上で、プロジェクトをどのように回していくか。ということで開発部員から、「アジャイル」に真剣に取り組んでみるというのがいいのではないか、という意見が出ました。そこから検討した結果、「アジャイル開発」に本格的に取り組むことにしたのであります
アジャイルへの挑戦＝アジャイルな挑戦
▲開発部に並べられたアジャイル関連の書籍
「銀の弾丸は無い」はフレデリック・ブルックス氏の『人月の神話』で有名な言葉ですが、「アジャイル」が銀の弾丸となることは無いであろう、ということは開発部員の中でしっかりと認識しておこうと話しています。むしろ失敗することは多くあるであろうし、その失敗は恐れない。失敗から多くのことを学び、改善し続けて前に進んでいくことが一番重要であると思います。
「アジャイルに取り組む」＝「失敗し続け、改善し続けよう」ということとして、全員で取り組んでいこうと考えています。
つまり、「アジャイルへの挑戦」そのものも「アジャイルな」挑戦であるということです。
具体的にどのように「アジャイル」に取り組んでいるか、というのは今回の記事では語りません。現在書籍などで勉強しながらさまざまな検討を行っており、今後このブログでアジャイルの取り組みを定期的に報告をしていく予定です。
「Agile Japan 2016 あなたとつくるアジャイル」に期待すること！
ということで、現在アプレッソ開発部でアジャイルへの取り組みを検討しています。さまざまな書籍などから知見を得る一報、具体的な適用方法や開発シチュエーションによる運用の変え方など、気になることも多くある現状です。そこで！ 2016年5月31日(火)の「Agile Japan 2016 あなたとつくるアジャイル」でそのヒントとなるようなことが聴けるのでは、と期待を持って参加する予定です。
ここでは、開発部員の期待するプログラムについてインタビューしてみたので、その中の幾つか紹介してみます。完全に主観の予想なので、実際のプログラムの内容とは異なる可能性がありますがご容赦ください。
「アジャイルなIoTプラットフォーム開発」玉川 憲 氏
http://www.agilejapan.org/program.html#keynote2
「IoTプラットフォームとしてのDataSpiderの機能強化も進む中、今IoT界隈で話題の中心となっている"SORACOM"の開発についての話が聞けるというのがまず楽しみです。新しいサービス・ビジネスを作るというときのスピード感をアジャイルによってどう実現しているのか？ また「"非同期な"ソラコム開発チームの様子と、 "非同期"を実現するための組織、チーム作り」という"非同期"というキーワードがどういう意味なのか？ とても気になります」
(by 開発部 開発チーム 田中)
「自社プロダクト開発現場でのアジャイルなプロジェクト運営記録」 by 大貫 浩氏、長沢 智治氏
http://www.agilejapan.org/program.html#a-2
「アプレッソと同じ自社プロダクト開発の話なので気になります。やはり自社プロダクト開発は受託開発とはさまざまな異なる面があります。特にアジャイルの言う「顧客」が自社プロダクト開発だとどのように捉えて運用していけばいいのか？ など、どのようにアジャイルなプロセスの適用を行ったかの具体的な話が聞けそうで楽しみです。また長沢氏のアトラシアン社のソフトはアプレッソでも大いに活用しているので、実際どのようなプロセスで開発されているのかも気になります」
(by 開発部 開発チーム 佐々木)
「効果的な自働化を目指す！ Value Stream Mapping 実践ワークショップ」 by 牛尾 剛氏、 原田 騎郎氏
http://www.agilejapan.org/program.html#d-5
「最近リーン（『リーン開発の本質』）とかカンバン（『カンバン仕事術』）とかイケてる感じがするし面白いなと思うのですが、「価値の流れにフォーカスする」というのが現実の自分の仕事にとって具体的にいったいどういうことなのか、イマイチ飲み込めないため、このワークショップを通してヒントを掴みたいと思います。」
(by 開発部 開発チーム 野口)
「まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～」 by kyon_mm氏、otf 氏
http://www.agilejapan.org/program.html#d-3
「挑戦的なタイトル！ しかしセッション概要にも書いている通り、確かにアジャイルな開発において"テスト"というのはすごく重要なものにも関わらずあまり大きくは語られてないので、とても興味があります。開発期間からテスト期間へ、という通常の流れではない方法のやり方を知りたいです」
(by 開発部 QAチーム 谷平)
「品質保証部門とアジャイル開発推進部門が一緒に歩んだアジャイル開発導入」 by 新井 和洋氏、石井 裕志氏
http://www.agilejapan.org/program.html#c-3
「品質保証部門に所属する自分としては、まさに今最も聴きたい内容のプログラムです。高い品質を維持しながら、どのようにスピード感のあるリリースをしていくか、というのは常に我々のチームの課題として考え続けていっているところで、アジャイルによってどこまで解決できるのか、という具体的な話を聞きたいです」
(by 開発部 QAチーム 伊藤)
終わりに
というわけで、大きな期待を寄せる「Agile Japan 2016 あなたとつくるアジャイル」は、参加者によるレポートを可能な限り即日掲載します。さらにその後座談会も開催予定。お楽しみに！
またアプレッソのアジャイルの具体的な取り組みも今後このブログで掲載していこうと思います。 我々は何を学び、何を試し、何を失敗し、そしてそこから何をまた学ぶのか・・・その一部始終をお届けしていければ、と思います（可能な限り・・・）。
