Agile Japan 2016 に参加してきました。
5/31に浅草橋ヒューリックホールで開催された「Agile Japan 2016 あなたとつくるアジャイル」に参加してきました（会社のカネで）。
特に印象に残ったセッションについてレポートします。
スクラムがイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜
Joe Justice 氏 (President Scrum in Hardware, Scrum Inc. )
Awesome! という掛け声とともに登壇したJoeさん。平鍋さんが通訳をしながらのセッションとなりました。
アジャイルがソフトウェア開発以外の分野で取り入れられている事例が紹介されていました。
米国ホワイトハウスや日本の国土地理院、和歌山県といった行政分野でGitHubが取り入れられていることからも伺えるように、プロセスをよりより良くすること、良いものをすばやく提供しようという取り組みは、ソフトウェア分野に限ったことではなく、業界問わずに起こっているムーブメントなのだということに感動しました。
また、「スクラムマスターの１番の仕事はチームをハッピーにすること」という言葉が強く印象に残っています。 スクラムを導入しようとした組織が、最初は失敗したものの、スクラムマスター/アジャイルコーチが突破口となって最終的には成功した、という例はよく耳にします。
この講演を聞いて、スクラムマスター/アジャイルコーチというのは、オーケストラでいう「指揮者」の役割に似ているな、と感じました。
メンバーがそれぞれ高い演奏技術を持ち、「良い音を奏でる」という目的を共有していたとしても、それだけで良い演奏ができるというわけではありませんよね。ひとりひとりが意志も個性もある演奏家です。各パートのテンポや大きさなどを俯瞰し、指揮棒や身振りによって演奏者に伝え、全体としてひとつにまとめ上げる。そんな指揮者の役割もオーケストラの不可欠な要素です。
ましてスキルレベル、得意分野、プロダクトに対する知識、ポジション、など不揃いな要素が多いソフトウェア開発においては尚更その必要性が高いのではないかと思いました。 ミーティングひとつとっても、全員が気兼ねなく思ったことを発言できる会議と、一部の声の大きい人、影響力の強い人、立場の高い人ばかりが発言する会議とは、議事運営のしかたによって大きく左右されます。そもそも前者の空気感を醸成するというのもアジャイルの取り組みではあるのですが、「全員がプレイヤー」という状況で最初からそれができている組織であれば、きっとアジャイルでなくても上手くいくのではないかと思うのです。
人の弱さ、強さを認め、考え方や感性の異なる個性を調和させ、目的を指し示し、文化を根付かせ、エンジニアの集合体を単なる烏合の衆である「グループ」から、同じゴールを目指す「チーム」に昇華させる。そこがアジャイルコーチの活躍どころなのではないかなと。
そんなことを考えさせられるセッションでした。
日本型ハイブリッドアジャイルの導入と実践
長瀬 嘉秀 氏 (株式会社テクノロジックアート)
アジャイルは組織変革にも及ぶ。もともとアジャイルが向いている組織なら導入は容易だけど、大抵の組織はそうではないのでハイブリッド型が必要だよね、というお話。
日立ソリューションズでのウォーターフォール＆アジャイルなハイブリッド型手法について紹介されていました。
見積り
確定している要件については確定的に数字を出し、不確定な要件はバッファとして持っておく形で見積りをしたとのこと。この「不確定な要件」についてはおそらく、過去プロジェクトから似たようなケースを抽出して経験則的に見積もったのではないかと。従来型開発を前提とした見積りと、そうかけ離れた数字にはならなかったのではないかと推測。基本設計、詳細設計、製造、単体試験
ここをイテレーションで回す。
業務フローとユースケース図からユーザーストーリーを抽出して、TDDをやった。 このTDDというのはたぶん、設計手法としてのTDDというよりも、顧客テストの側面が強いテストファーストのことだろう。総合試験
ここもウォーターフォール。
チーム体制としては従来とあまり変わらず、いままでどおりPMもいる。
「生産性の富士通、品質の日立」と言われるくらい品質に力を入れているHISOLであれば、総合試験が従来手法になるのは必然ですよね。 一括請負型の受託開発構造であるSIはアジャイルとの相性が良くないですが、従来型開発で培ってきた品質管理能力を継承した、日立だからこそのハイブリッド型なのだなと感じました。
文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！
牛尾 剛 氏 (マイクロソフトコーポレーション)
野澤 英歩 氏 (株式会社カラダメディカ)
「DevOps! DevOps! DevOps!」こういう湘北高校みたいなノリ、好きですｗ
DevOpsは本番環境へのリリースリードタイムを短くして、早くフィードバックを受け、いかに顧客の望むものをすばやくリリースしていくか、というところに価値がある。
DevOpsはアジャイルの土台の上に成り立ち、アジャイルは文化の上に成り立つ。
しかし伝統的な「日本文化」の上にはアジャイルは適用しにくい。日本文化と DevOps & Agile の文化は相いれない。
ではどうするか。「日本文化」の上に「西洋文化」をインストールすれば良い。
西洋文化では生産性が圧倒的に違う…ように見える。その秘密は、彼らが日本人よりも優れているからというよりも、彼らが本質的に必要なものにだけ取り組むマインドセットを持っているからである。日本では「10」の労力が必要なものが、米国では「1」くらいの労力で行われていたりする。そんなマインドセットの上にアジャイル、DevOpsが成り立っている。
「Be Lazy！」
より少ない時間で成果を最大化する。いかに無駄なことがあるかを考えていく。いわゆるエッセンシャル思考。
チーム全員で西洋文化を共通認識として持っておく。１人でやっていてもつまはじきにあうのが落ち。
西洋文化を学んで実践すれば、アジャイルはうまくいくだろう、というお話。
私もアメリカにいたころ、大量のペニー（1セント硬貨）をドル札に交換しようとして銀行に持って行ったとき、窓口のおばちゃんに「何ドルあるのか自分で数えろ」と言われ、「なんて不親切なんだ」と思った経験がありすが、考えてみればそれは銀行業務の本質ではないのですよね。
「かゆいところに手が届く」が常態化すると、やがてサービスを受ける側はそれが「あって当然のもの」と認識するようになります。それが成熟したのが「日本文化」であって、そういった「おもてなし」な日本文化は仰るとおりアジャイルとの相性が良くないのかもしれませんが、顧客あってこそのビジネスという点を考えると、どちらが良いかは一概には言えないなと感じました。話は自分たちの組織だけでなく、顧客の「文化」まで及ぶ場合がある。そこが難しいところ。 80:20の法則（パレートの法則）は日本でもよく耳にするところですが、「20 or 100」の極端な二社択一ではなく、「まずは70から始めてみる」とか、状況にあった選択をする必要がありそうですね。
さいごに
「アジャイル」というものを知識として持ってはいるものの、実務での経験がない自分としては、生のアジャイルの声が聴けたのは良い機会だったと思います。
また内容もさることながら、このイベントに参加できたということ自体が自分にとってプラスになったと思います。こういった「新たな視点」を吹き込んでくれるイベントは自分に足りないものを気づかせてくれて、自分と向き合う良い機会でもあります。最近は勉強会などにあまり参加できていなくて、人の話を聞く機会が取れていないので、こういった気付きを大事にしていきたいなと思いました。
