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 でどうアジャイルにやっていくかというのも大きなテーマになっています。
次回は感想の後編として、アジャイルなテストにまつわるセッションの感想をお届けしてまいります。
お楽しみに！
