Agile Japan 2014 いってきました（レポートというか個人めも）
Agile Japan 2014 レポートというか個人めも
とりあえず今あがってそうな資料まとめ
アジャイル入門
エンタープライズでもできるアジャイル開発
効果的に試行錯誤を行うための仕組みづくり〜失敗はおはやめに、プロダクトの成長は着実に〜
若干道に迷いながらも静岡から初参戦させていただきました。
一応、うちのプロジェクトではアジャイルな開発をしている。
「アジャイルな開発」っていう言葉
これはどうかなーって思うところはあるけどニュアンスとしてとらえていただければ。
自分が思う今プロジェクトのよくないところ
もちろんいいところだってたくさんある。
でも、あんまりうまく回っていると思っていないのが本音。
うちは複数のプロジェクトがアジャイルな開発をしていて、
自分のチーム・他のチームを見ていてなんかおかしいだろーって思うこと。
本当にエンドユーザに喜ばれるものが作れているのか？
なんでかっていうとフィードバックを全く得られていないから。
あっても要望に答えられていない （本来、ここが一番大事なはずなんだが・・・）
フィードバックを得るための方法もできていない。
プロジェクト内のどれだけの人が本質を理解している・しようとしているか？
わりとトップダウン的にアジャイルに取り組んでいる。
なので本質を理解せずに、ただただ終わりがない苦しい開発って思ったりしている人もいるのかなと思う。
チームが楽しそうに開発してない、悲壮感が漂っている時を見るのはとてもやるせない。
エンドユーザに喜ばれるのも大事だけど、プロジェクトが楽しく仕事できるっていうのも同じくらい大事なはずなんだけどなぁ。
まぁまるで成長しない、しようとしない自分たち自身がよくないが。。
開発・開発・開発・・・
日々の開発に追われてチームの技術向上の取り組みができていない。提案ができていない。
月に数回リリースするのがやっとな状態であったり、環境構築に何日もかかったり。
こんなことを続けていたらあっという間に世の中の技術についていけなくなってしまう。
技術ってアジャイルと密接だと思っていて、いかにコンピューターに任せられるところを任せるかが大事。
確かに初期構築までは時間がかかるけど、それに見合った効果はある。
リリースするのにチャットで「デプロイしてちょ。」っていうだけになれば
プロジェクトはユーザーが心待ちにしている体験を提供することに注力することができる。
最近まであんまり気にしてなかったんだけど、
「チーム開発実践本」やら「github kaigi」やらを見ていて、世間の動向ヤバス。と感じた。
今回期待していったところ
そんなこんなで今回 agile japan 2014 では以下の事柄について勉強させていただきたく参加した訳です
- チームビルディングのコツ、みんなで楽しく開発するために他社ではどんなことしているのか？
- 他社のアジャイルな開発、って実際にはどんなことしているのだろう？
- ・・・うち、技術的に遅れてる？
各セッションのまとめ
チュートリアル アジャイル入門〜オープニング
道に迷ったため、途中からの参加になりました。
内容は入門ーっって感じなので省略して、メモだけ。
- チュートリアル
- まず最初にとりくんでみるなら振り返りがおすすめ
→ その通りだとおも。振り返りの結果をどう積み上げていくかが難しい。。 - 実践して行動でしめす
- 「Social change statrs with you」
- 質問タイム
- 質問タイムの前に手を挙げる練習wこれは取り入れたいw
- (質)アジャイルでやりたいけどどうやって上司に説明したらいいの？
アジャイルという言葉を使わすに説明してみたらどうでしょう。 (質)まわりのひとを取り込んでいくにはどうしたらいいの？←質問させてもらいました
Agile Japanにつれてきたらどうでしょう。
→ 回答をもらった直後は「うーん」って思ったけど、水野さんの基調講演を聞いたら確かにいいかもと思った。
あれはYoutubeで動画を見るんじゃなくて、あの場で聞くことでより一層ココロオドルな。オープニング
- きっとスライドがあがるだろうと思って、数値系の話はメモしていない
- 2013年の禅の話はちょっと面白かった 自分がその場にたったとき、自分が感じるものを大切にする
基調講演：ソフトウェア開発者に問う ～日本人のモノづくりの本質とは～
水野 和敏 氏（元日産GT-R開発の総責任者）の講演。
すみません、車に興味がないので知らなかったです。。。
写真だけみて「ちょっと怖そうな人か？」と思ったけど、すごいめちゃくちゃ優しい物腰のお方でした。
まずメモまとめ
- 基調講演
- GTRという車は「日本のモノづくり」、「日産のモノづくり」ではない
- 権利はいらない、すべての責任をもらった
部門ごと分けるから責任をなすりつけあってしまう - 女子サッカー日本代表の話
個の強さではな到底勝てないが、チームの強さが勝っている
一人一人に役割を与えて、それぞれが海外などでその強さを成長させる - Raceを勝つために考えるとき「How to race」ではなく「What is race」で本質を考える
- BigDataから傾向を見いだして、それぞれのチームに目標を設定する
例えば、前回の大会優勝が６h３２mで、これまでの傾向から０h０２mタイムを減らせれば勝てると判断
そして車チームには1m10sec,ドライバチームには30sec,ピットチームには40sec
それぞれタイムを短くすることを目標にさせる - BigDataの分析結果、可視化したものは裁量や目標をみいだすためのマネジメントツール
- Try and ErrorのErrorはいらない、バカか！
このErrorってのは行き当たりばったりの失敗のことかな？
成功に着実に向かうための失敗を否定している訳ではないと感じた - 技術の進化が価格を下げる
- 会社という枠にはいると「会社が〜」「部長が〜」「他部門が〜」という言い訳を始めてしまうが、バカか！ 本来、社会的使命（What is）から職業を選んでいる。会社は手段(How to)でしかない
- 工程の最上流にあるもの、それは「現場」
現場が作れないものを設計してすごいだろっていっても全く意味がない。
現場の技術力があがらないと設計レベルはあがらない - 未来というものは言葉じゃなくて画像
言葉は過去を共有するためのコミュニケーションツールだ
いきなり討論するな、一人で考えた結果を画像で共有する - 目標を言葉ではなく、シーンで共有することが大事 例えば、「最高時速３００km」というものではなく、「海外の老夫婦が時速３００kmで３時間走りながら会話を楽しむ」みたいな
- 質問タイム
- 趣味で仕事をするから価値観が変になる
仕事は人のため、人の喜びを共有する
自分のために何かをしようと思うとアイデアはでてこないけど、人のためになにかしようと思うとアイデアは無限に出てくる 例えば、休日何しようかなーって思っても「疲れたから寝るかー」とかしか浮かばないけど
恋人のために何しようかって考えると「レストランにつれていうか」「ショッピングにいこうか」などなど、どんどんでてくる - ペルソナの設定論議には時間をかけるべき
- 最後に会場にむけて
会社の組織に埋もれるな、使命を果たせているのかが大事
でも、ダメでもともとと思って気楽に。失敗しても雇用した会社が悪いんだから（笑
もーーーね、これを聞けただけでも今日は agile japan 2014 きてよかったと思えた。
アジャイルの様々なプラクティスに当てはまるモノがある。
ペルソナの設定、個人で様々な案を図にして発表する、個々に役割を与える、ユーザーストーリーとかとか。
プラクティスはこういうモノづくりの本質から生まれているんだな。
だから、ただそれを実践しているだけになっちゃだめだと深く反省させられた。
youtubeの動画で見てるよねっていくつかスキップしてしまった部分があるからそこは動画を見ておこうと思う。
マイクロソフトにおけるアジャイル開発の実践
他社を見るということでセッションを聴講させてもらいました。
メモ
- 講演
- CEOがかわったらしい。
Mobile / Cloud / Usage / Engineer にフォーカス
Usage : いかに多くの人に使ってもらうか - VisualStudioOnlineのデモ
- 2005 → 2008?のとき、過去の負債（５０００件のバグ）を返済するために
４ヶ月間のMQ（マイルストーンクオリティ）を実施した
正直もっとアジャイルのお話をしてほしかった。
ほとんどの時間がVisualStudioOnlineのデモに費やされていて、聞きたいこととはずれていた。
ただうちもこういうリポジトリ、ビルド、テスト、デプロイのフレームというか
テンプレート的なモノをOSS組み合わせておいて、あらかじめ用意しておきたいなと思った。
新規でプロジェクトが発足するたびにやってたらちょっと無駄感。
あと最後の方でモバイルアプリのリリースの質問？みたいなのがあった。
ネイティブなアプリだと修正はいるたびにリリースはあり得ないんだろうな。
１日に何回も細かいバグがなおるたびにアプリアップデートとか使う方からしたら邪魔っちぃきがする。
効果的に試行錯誤を行うための仕組みづくり 〜失敗はおはやめに、プロダクトの成長は着実に〜
つづいてヌーラボさんの公募セッション。
水野さんの基調講演でTry and Errorはだめ！と言われてて、ドキドキしていたらしいw
講演見ていて思い出したけどBacklog作っていることろか。
メモ
* 講演
* パワポが黄色に白文字になっててなんにも見えないとこがちらほらw
* 2011年に３、４つの機能を盛り込んだビッグリリースに失敗。
２時間かけて前のバージョンに切り戻したらしい。
* UI設計にはコストをかけるべき。
UIドリブンな開発、開発者がなるべくそこに関わること。
そうすることで後々にいきてくる。
* UI設計ではモックを利用。
HTMLだけーのから、JavaScriptで動きがあるもの、ChromeExtensionをつかったものなど必要に応じて使い分けている
* 失敗できる環境づくり β環境
STGとは別に本番環境の横にいて本番のデータを使っている。開発者はそこを利用しているらしい。
切り替え方はバーチャルホスト・クッキーディスパッチ・リソーススイッチ・アプリフラグなどなど
* インフラはPacker/Vagrant/Ansible/serverspecを使っていてAWSを利用しているみたい
* アプリで使っているのはGradle
* nubotによる自動デプロイ
* 失敗するためには失敗しても簡単にやり直せることが大事
デプロイ失敗時のロールバックまで自動化
* だれが？どの環境が？デプロイ作業中なのかーっていうところは可視化してわかるようにしている
* フィードバックのためのトピックがあって「ツッコミビリティ」を確保している
情報をオープンに、別プロジェクトのメンバーもはいっていてそこからのツッコミも。
* フィードバックするときの注意
* ポジティブフィードバックを心がける
* 指摘ではなく提案をする
* 人ではなく課題にたいしてツッコム
* フィードバックしてほしいときの注意
* 見てほしいところを明確に、これみといてーはだめよ
* 手軽な場を作ること
* 質問
* データベースの構造変更はどうしている？
→ create table とかalter tableとかSTGで検証して問題ないことを確認したらやっちゃう
* どこまでのフィードバックに対応しているか？
→ 必要があれば利用者と直接会話して内容をきくことも。
自分たちで使い心地を判断しかねるときはβ環境を顧客にも提供する
β環境的なものは私たちも用意できている（キリッ
（最近アプリ適用できてないからいまいち感はんぱないけど）
でもすごいなー、やっぱり進んでるところは進んでるなー。
hubotで自動デプロイやりたいなー。
自動化するってことは試行錯誤を容易にするってことに通じるんだなー。
講演が終わってから、自動化をどうやって進めたかについて聞いてみたところ
一年間にわたって時間かけて徐々にやっていったので、
あんまり焦らず長期的な目で進めていけたらいいんじゃないかとアドバイスをいただけた。
あと誰が進めたかについても聞いてみた。こういうのは誰かがガンガン進めるべし、みたいなのもみたので。
そしたら割とチーム全体で進めていったご様子。素敵。
hubot使ってみたいんですよーと聞いてみたら、楽しいしおすすめですよと。
hubot自身でもいろいろできるけど、あらかじめあったJenkinsのジョブを実行するだけになっているらしい。
既存のリソースを無駄にしないでいけたところがよかったとのこと。
染田さん、貴重なアドバイスありがとうございました。
素敵なチームなんだろうな。
今更ながらどうやってチームビルディングしたか聞いてみたい。
twitterフォローさせてもらったので聞いてみようかしら。
アジャイル経験0から3年で3億以上を稼いだ道のり～とある中小ソフトベンダーの請負アジャイル開発実績～
請負というキーワードで聴講。
どうやってお客さんと調整しているのかしら。
メモ
- 講演
- リスクは承知で準委任ではなく請負
- 見積もりにはJUASの１画面１人月に０．７掛け（なぜかそう思ったらしい、ってのとお得感をだすために）
- どういう業務を実現したいのか→要件
- 要件定義はあくまで最初の指標としての立ち位置
- アジャイル初体験にしてはちょっと多めの１０人で立ち上げ
- メンバが楽しいっていってくれた → 大事
- 顧客も最初は少しずつのリリースに違和感を感じたみたいだけど、慣れてくるとどこまでできているのかが見えてよかったとのこと
- チームビルドは大変
- リリースの次MSを顧客の試用期間にすることでお客様の負担を減らす試み
- MS最終日はリリース、デモ、フィードバックの実施
- タスクは個人がこれやるーっていって選ぶ
- Geekがいてくれたことが大きい
- Geekレビューが必須で、負荷があがってしまっている、平準化が急務
- １つのアジャイルチームを２つに分けて、そこに未経験メンバを投入
- それぞれが気にして朝会やらチケットを見ていたみたいで、佳境時に別チームメンバにすんなり入ってもらえた
- 質問
- 調整系のおはなし
要求を一定に保てるようにしていた。
この機能があればこっちはいらないよね、とか。
顧客との協調が大事で、信頼関係が築けていれば請負でもあとあとで問題にはならない。
チームビルドやらメンバを楽しくさせる工夫とか聞きにいきたかったけど、既に捕まっていて聞けず。
UI/SSは全くやっていなくてコードから保守用のドキュメントを起こしているって聞いて「ほえー」ってなった。
やっぱりお客さんとの信頼関係大事だなぁ。お客さんも含めて１つのチームなんだよなぁ。
Embrace Change for Unchangeability. ～エンタープライズのためのアジャイル～
最後はここ。理由はなんかtwitterで見たことある人だったから。
メモ
- 講演
- 変化の中の不変の価値
- かわらないために動き続ける
- 開拓
- ３ヶ月かけてモノを作ったが、すべて捨てて２ヶ月で作り直したことも
- 一番最初に誰の何のためのITサービスかを書く
- プロダクトビジョンの検証
プレスリリースを書いてみる、壇上で発表もする
amazon?がやっているらしい。ヘビーユーザに見てもらってどう感じるか？など - ユーザエクスペリエンスデザイン
- ユーザにとって効率のいいタスクやナビゲーションフロー
- ユーザーインターフェースの見た目と雰囲気
- アイデアを反映したプロトでテスト
- ユーザがやりたいことが用意に達成できるか判定
- 持続（だっけ？）
この辺りでこれまでの情報量に頭いたくなってきているのでメモが少ないw
でもこの講演をしている人は徹夜あけで発表しているらし。
割とリアルなバーンダウンを見させてもらった。うちと似た感じのw
PullReq開発しているっぽくて、この人のレビューがOKになったらマージされるみたいだけどめちゃくちゃ大変っていってた。
そりゃそうだよな。。。
リリース自動化にも取り組みたいらしいけど顧客を説得させるための資料とかとかで取り組めていないらし。
まとめ
チームビルディングのコツ、みんなで楽しく開発するために他社ではどんなことしているのか？
こういう話はあまりきけなかったな。
でも情報の透明性は大事と結構多くの人が言っていた。その通りだと思う。
実際に別チームの人で「何も聞いてない」って言って怒ってる人もいるし
自分自身も定例会フィードバックでいきなり？？？な話を聞かされると「どうなってんの？」って思う。
tweetとか見てると、やはりコミュニケーションで困ってる人は多そうだ。
なにかできないか、もっと画策してみよう。
他社のアジャイルな開発、って実際にはどんなことしているのだろう？
うちの取り組みもなかなか悪くないではないか、と感じました。
ただマネジメント的な部分がイマイチなんだろう。
ほんとに、こういうセミナーにいってこいっていうのは「あじゃいるっ？」
って人に結構効果的なんじゃないかな。
・・・うち、技術的に遅れてる？
技術的に先をいっている所は先をいっている。
おそらく自社開発だからそういったところに融通がききやすいのかな？
うちもお客さんのメリットをちゃんと伝えたうえで
技術力アップのための検証とかさせてもらいたいから
そのために提案をしなければいけないな。
最後に
次回 agile japan 2015 も参加したい。
agile japanだけじゃなくて、もっといろんな所に参加してみたい。
水野さんの基調講演の動画がアップされたら(されるかな？)、部長に
みんなで見る時間をとれるか、みんなで見て意義があるだろうか
を相談してみよう。
