Agile Japan 2015に参加してきました！
目次
L小川です。
先月の話になりますが、4/16（木）に開催された「Agile Japan 2015」に参加してきました。
恥かしながら…「 アジャイルって何？」という状態で当日を迎えてしまったのですが、そんな私でも得るものが多く大変勉強になりました。
今回のタイトルは”失敗から学ぶアジャイル、成功につなげるアジャイル”ということで、アジャイルを導入した際に現場で起きたことやその対処方法等、生々しい話を聴くことができました。
得られた知見をこのまま溜め込んでしまうのももったいないので、自分が聴いた講演についていくつか内容をまとめました。
…とその前に。
アジャイルって何？
開発対象を機能単位で分けて、短い期間で要求決定・実装・テスト・リリースし、そのサイクルを繰り返す開発手法です。早い段階でフィードバックが得られ、仕様ミスや漏れに気づくことができるなどのメリットがあります。
ウォーターフォール型開発では「前工程が正しい」という前提で進んでいくのに対し、アジャイルではリリースごとにフィードバック・修正が行われます。
基調講演1：アジャイル・テスティング 〜 チーム全体のためにテストとテスターができることを学ぶ旅（Janet Gregory氏）
【概要】
アジャイルはチームが一つの場所で働く場合にもっともうまく機能するが、企業間の合併・大規模な組織・離れた地域に住む人を雇う場合等、様々な理由によって分散した環境で仕事を進めないといけない状況が発生する。
・分散環境で仕事をする時の問題
カナダ〜インド間でフォロー・ザ・サンの24h体制を採っていた。これにはメリットもあるが、デメリットがその恩恵を超えてしまう場合もある。何か疑問がある場合、リアルタイムなコミュニケーションが出来ない。また、12時間の時差がある状況では2hで終わる仕事が4日かかってしまった。
分散チームではしばしばダイバーシティ（民族・文化・考え方の違い）に遭遇する。どうやってお互いから学び、どうやってお互いを知るかが重要である。
分散した環境にはたくさんの課題がある。他の国へのテストのアウトソース、大規模組織で別のチームがテストするケース、チーム間の依存関係（Aチームが終わらないとBチームの作業が始まらない）等。
・課題解決のための経験
co-workerのもとに訪問してみて、その人について初めて知る事があった。co-workerの状況について言葉の上では理解していたが、実際のフィーリングとして理解することが出来た。他人がどういう問題を抱えているか理解することが始まりになる。
・「砂場では仲良く」
「砂場では仲良く」というキーワードをよくチームに話している。皆が気持ち良く仕事できる職場環境を心がけるということ。そのための信頼関係を築く（お互いを理解する）事が重要。
・伝える事の難しさ
ある一枚の写真を見て、その内容を言葉で他人に伝えても完全に伝えきる事は難しい。
言葉だけでは全てを伝えることが出来ない。絵を併用するなどの工夫が必要。
・実務においてのコミュニケーション
（会議に参加しないとしても）全てのチームメンバーが全ての情報（決定事項／決定経緯）にアクセスできるようにする。
分散環境では顔を見ながらの対話が難しくなる。常に人の顔の高さにモニターを置いて分散環境にいる人を映し出し、会議の際はモニターごと移動させる。
巨大なモニターに分散環境全体を映し出し、朝会を行う。
これらは小さいことだがお互いを理解するには大事な事である。本当は現地を訪問するのがベストだが、そうしなくても各種ツールを使うことでも出来る事はある。
ゲームを使って打ち解ける方法もある。パーソナルな情報（家族構成や飼っているペット等）を使うバーチャルビンゴというものがある。このゲームでは人に聞いて回る状況を作り出すことで、人と人との会話のきっかけとなりお互いを知る事につながる。
分散チームではDONEの定義が問題となる。こちらのOKと別チームのOKでは意味が異なるかもしれない。クオリティの善し悪しではなく、何を持ってOKするのかという共通理解が大事。
定義を明確に書き出してそれを話すということが大事。書き出すだけでなく、その前後に確認することも大事。
基調講演2：デジタル革命には アジャイルがよく似合う（横塚 裕志氏 東京海上日動システムズ株式会社 顧問）
【概要】
今、第４次産業革命（製造業のデジタル革命）が起きている。
例として、富士フィルムがカメラフィルムから化粧品・医薬品の製造へシフトし、Googleが自動走行可能な車を造っている。巨大な3Dプリンタで車・家を作れば、ハウスメーカー・大工は危機に曝されることになる。
今後、人工知能の発展によって危機に曝される産業も多くあるだろう。これは創造的破壊である。
こういった状況では競争優位は続かない。
ひとつイノベーションが起こせてもすぐ他メーカーに追いつかれてしまう。継続してイノベーションを起こせる組織能力を持つ事が必要になってくる。そうでない企業は淘汰されていく。
勝ち残るためには新しい価値づくりが必要で、お客様の潜在的なニーズに気づいてサービス・製品を作る事が唯一の活路となる。
そのために重要な視点が４つある。
・カスタマーセンス（customer sense）
カスタマーセンス（お客様の感覚）から製品を作るにはデザインシンキングというメソッドが必要になってくる。
シンガポールでは国家戦略としてデザインシンキングが推し進められている。
・コラボレーション（collaboration）
チーム＋お客様、エンジニア＋ビジネス等、様々なコラボレーションが考えられるが、「議論」ではなくたくさんの人との「対話」からいろいろな知見が得られる。いろいろな立場の人と対話していくことはダイバーシティという観点からも重要になる。
・ビジブル（visible）
3Dプリンタでのプロトタイプ作成でもわかるように、見えるようになれば工夫のしどころが見えてくる。
・イタラティブ（iterative）
改善の繰り返し。お客様に見せてフィードバック、改善していく。
誰もやっていない新しいサービスを作る場合には必須になる。
ビジネスそのものが完成するなんてありえない。ビジネスは常にconstant betaであるという視点が大事。
毎日のようにお客様からフィードバックをもらって改善していく。そういうソフトウェア・ビジネスでないと勝てない。
ソフトウェアだけでなく、アジャイルをビジネスに浸透させたい。
アジャイルはある意味マインドセットの問題だと考えている。組織の中でアジャイルチームでひとつ成功させる。失敗しながらジワジワ良いものを作っていき、従来の組織をアジャイル型に変えていく。
三年計画というものがあるが、三年後のテクノロジがどうなっているか、商品・サービスがどうなっているかが読めない。三年計画でも負けてしまうと考えている。そこで、アジャイルな経営で、企業そのものをアジャイル型に持って行く必要がある。
今後の日本の企業が生き残るためには、アジャイルでいい事例を作り、アジャイルで開発（ビジネス）を提案していく必要がある。
[アジャイルな現場になっていく時の超えなければいけない3つのハードル / 中村 洋氏 ギルドワークス株式会社]
【概要】
アジャイルを導入する際に遭遇する「壁」について実例を挙げて説明。
第一の壁：理由なき導入
アジャイル導入自体が目的になってしまっている。
現場は何故アジャイルを入れるのか、何をしたらいいのかわからずやらされ感が発生する。デイリースクラムやふりかえりはやるが、何故やっているのかがわからず、後々儀式としての残骸だけが残る。
期待マネジメント（自分の期待と相手が受け取る期待を合わせること）というものがある。例として、息子に部屋の片付けをするように言う状況を考える。息子はおもちゃを部屋の隅に置いたが、こちらの要望はお客さんが来るからおもちゃを箱にしまって片付けることを期待していた。双方での「片付ける」の意味合いが異なっていた。
これは日常の開発でも起きている事である。
なんのためにアジャイルを導入するかが大事である。そもそも課題は何か。見つけた課題がスクラムに合っていれば導入すれば良いし、もしかしたらドキュメントの整備・会議スタイルの変更だけで済む話かもしれない。
まずは課題をはっきりさせた上で、スクラムを「軽くやってみる」ということを推奨している。
第二の壁：定着の壁
教科書どおりのやりかたでなくても良い。whatにこだわりwhyを忘れることがある。
なんとなく楽しくやれているが、成果を見える化することを忘れてしまう。
現状のやり方でいいのか？という疑問から不安定（変化）を安定的に作り出すことが大事。
第三の壁：拡大の壁（ボトルネックが移動する）
開発チームが一定のスピードで安定した品質を出せるようになったが、事業を考える（企画）側がボトルネックになってしまった。プロダクトオーナーにどう企画を練ればいいのか、どうやってユーザストーリーを書けば良いのか、どう開発チームと接すればうまく自分たちのビジネスをやれるのかという方向に軸を変えていった。
第四の壁：組織の壁（それってもうかってるの？）
開発チームはうまく回るようになり、プロダクトも速く出せるようになったが、経営側からは売り上げにつながっていないと見えていた。確かにプロダクトがまずいせいもあり、売り上げにはつながっていなかった。しかし、組織の変化についてうまく伝えられれば結果は変わったと思う。（そのチームは解散し、トップダウンに戻った。）
これらの壁を超えるにあたって：
不確実性の高い世界ではちょっとずつ確認して改善していかないといけない。
自立的に考え、動き、やり方を変えていく組織である事が必要。
現場と寄り添いながらもビジネスに踏み込む事が大事だと考えている。
開発現場がアジャイルで良くなるとボトルネックがプロダクトや事業に移動する。
そうなった場合、ビジネス側にも踏み込む必要があり、開発現場だけでなく組織全体として良くなっていかないといけない。プロダクトをうまく売って行くために開発・マーケ等の境界線を越境し、組織全体を変えていくことが大事である。
[大規模スクラムの失敗から学んだこと〜急成長をとげるAirレジの組織拡大の取り組み〜 / 塚越 啓介氏/佐橋 一旗氏（リクルートライフスタイル）]
【概要】
経験者ゼロからスクラムを導入し、一年が経過した。
そもそもなぜスクラムに取り組んだのか？
Airレジが未経験の事業領域だったため、できるだけ速いサイクルで開発をして試行錯誤をする必要があった。
従来の方法（WF）での問題点として、組織が大きくなるに従って生じるボトルネックがある。マネージャーが足りない、要件定義をする人が足りないという理由から要件定義が終わってないから次に進めない等。
■スクラムを現場に導入
１チームのみスクラムを導入。（まずは本を読みながら形から入った。）
それまではエクセルで管理していたが、カンバンでホワイトボード上に張り出したことで
他の人の作業が可視化され、上手く進んだ。
■他のチームにも全面適用
要件定義をしていた人をProduct Owner（以下PO）に、プロマネをScrum Manager（以下SM）に置き換えてチームを作成。しかし、思ったように上手く回らなかった。
トップダウンの導入で、なぜやらないといけないのか？という疑問がメンバーに発生し、上手く回らず、やらされスクラムとなっていた。初期で上手くいっていたのはメンバー一人一人が課題感を持って、ボトムアップで進めていたため。
また、スクラムだからうまくいかないのではという流れになってしまった。
何故スクラムでやるのか？を理解できているかどうかでその効果が変わってくる。
発生した事態：スクラムのバズワード化
スクラムをやる事が目的になってしまった。
対策：なぜスクラムなのかを話しあうワークショップを開催。
発生した事態：POのコミット力低下
ユーザストーリを書けば良いということで、それ以降の作業をチームに任せるようになった。他の業務と兼務することが多くなり、現場から離れて行った。計画ミーティングの時だけPOが登場するような状況で、ディスコミュニケーションが発生し、お互いに責任をなすり付け合うようになっていた。
対策：物理的にPOを近くに持ってくる事で解決できた。（相手についての文句を陰で言わず、その場で問題を解決できるようになった。）
発生した事態：メンバーの自発性がなかなか育たない
もともとプロマネだったSMが仕切ってしまうことでメンバーの自発性が育たなくなっていた。
対策：SMに対してアセスメントを実施。チームをサポートするリーダーにならないといけない。行動を客観的に可視化するためのチェックシートを導入。自身で気がつく事でサーバントリーダーシップに意識を持って行く。
スクラムをやってみて学んだ事：
「whyの理解・共有」「メンバーの物理的な距離」「プロマネをそのままSMにせず、マインドセットの支援をしていく」事が重要である。
さいごに
アジャイルは開発手法としてだけではなく、組織のあり方にも大きな影響を与える可能性があるという内容がとても新鮮でした。
アトラスも新しい開発スタイルに挑戦し、より良いシステムを世に出せるよう取り組んでいきます。
