XP祭り2012に参加してきた

XP祭り2012に参加してきました。

去年は参加だけだったので、今回はアウトプットをしようということで
LTで登壇してきました。

Xp祭り2012 lt leanstartup from Yasuharu Yanamura

これはUT Startup gymという半年間でアイデアをローンチまでするというプログラムの一プロジェクトとして僕が体験したことを簡単にお話しました。

実際のところ僕らのサービスは、まだローンチまでには至っていないので「やった」とはいいきれないし、
リーンスタートアップを教科書通りにやったわけではなく、考え方などを参考にしてやった程度なので、いろいろつっこみどころはあるとは思いますが、それでも実際にやってみたことで思ったとおりにはいかないことはたくさんあったので、「ひとつの失敗事例」としては他の人にも価値があるのではないかと考え発表させていただきました。

リーンスタートアップもアジャイルもこれといった答えはなく、あくまで「考え方」や「姿勢」のフレームワークだと僕は思っているので、この発表でお話した、「こうすればよかった」や「こうすべき」という意見は、あくまで「この家計簿プロジェクトに限る話」なので、全てに通じるわけでは全くないと思っています。

ソフトウェア開発と同様にスタートアップにも銀の弾丸はないので、試行錯誤してやっていくしかない。なので「超早く回す」ってことが一番重要だと思いますので、実際リーンスタートアップなことをやる場合はそうしたほうがいいのではないかと思います。

アジャイルサムライ横浜道場「ユーザーストーリーを集める」に参加してきた

アジャイルサムライ横浜道場「ユーザーストーリを集める」に参加してきました。

仕事で抜けられなくて約二ヶ月ぶりの参

流れはいつものように５分の音読＋１０分議論の４セット＋まとめ発表５分。
今回？はまとめ発表が各グループ１分＋質疑４分でした。

今回の読書会の内容は第６章「ユーザーストーリーを集める」でした。

文書化は、よく文書化しろとか言われますが、すべて文書で伝えるのは無理で、文書は誤解を与えやすく、コードと同じで完璧な文書というのはありえないです。
網羅しているのか？という質問をされるというお話を聞きましたが、網羅しているかどうかなんて、網羅していることを証明するなんて、スコープをかなり限定しない限り無理ですよね。
ただかと言って、アジャイルでは文書は書かなくていいとかいう勘違いも間違っていて、文書は全く無くてもいいわけでもないです。だったらどれくらい書くのかというと、「場合による」ので自分たちでなにが最適なのか考えないとだめだなわけです。なので思考停止して文書をつくるのが一番やってはいけないことで、何が必要で何が不要なのか考えて書くということが大切だと思います。

今回覚えたのがINVESTという言葉で、
一人で読んでいた時にはあんまり気にしていなかったのですが、
INVESTはソフトウェア開発に似ているという意見にとても同意しました。
独立性、テスタビリティ、見積もれるなど、ソフトウェア開発の手法をユーザーストーリーの抽出に適応させると考えるとけっこうしっくりくるものがありました。

AgileJapan再演に行ってきた

AgileJapan再演　アジャイルな開発からアジャイルな組織へに行って来ました

AgileJapan2012ではものすごい人気で会場から人があふれたほどだったという吉羽さんの講演が横浜で再演してくれるということなので行って来ました。

Agileな開発からAgileな組織へ #aj21 #b2

View more presentations from Ryuzee YOSHIBA

ビジネス環境の変化に対してどう向き合っていくのか。
それに対する銀の弾丸はなく、目的とそれを達成していくための態度が重要というところがポイントだったように思います。

現状に目をつぶらず少しづつでも改善していく態度を意識していきたいと感じました。


以下メモ

ビジネス環境としては、
システムは効率化のためのものから、システム自体が儲かるものとなってきている。（弊社はおもいっきり前者なビジネスモデルだなと感じました・・）

WFとAgileの違いは計画づくりの頻度と計画の粒度。
Agileはリスクマネジメントと言うと上の人に響きやすいかも

プロセスは自分たちで進化させる

ツールやプラクティスは単なる道具にすぎない

WFやったあとに大反省会をしても喉元をすぎているので次にまた同じ失敗をする

Agileは０か１ではなく、度合い。どんだけやっているか。

標準は標準自体が成長するのであればまぁいいけど、標準を守ることが目的となったり、守ってればいいや的になり改善を捨てることにつながりやすい。

技術的負債があるとのちのちコストが大きくなる。同じ投資は同じ対価でないとならない。前半と後半で同じ投資で同じくらいのアウトプットが出せないとお客さんは納得してくれない

高い金を払ってでもやってもらいたいと思えるような成果をあげていないから、今のような価格競争になっている

組織構造が顧客への価値を届けるための分割になっていない。

規則ばかりになると思考停止が起こり、規則の意図が理解されず規則はただの制約になってしまう。

ピーターの法則・・・上の方は使えないやつばかりになる

チームの解体は阻止すべき。一回つくったチームの仕事は早いから。

仕事のかけもちは非効率だしストレスがたまる

結果に対して全力でやることをコミットし、見積にコミットするのではない

常に改善する責任、チームメンバーを育てる責任を持つ。プラクティスを採用するのであれば採用理由をチームに説明する責任がある

育てるインセンティブが必要

外部からのマイクロマネジメントは止める。言われてやるようではだめ。

個人の評価ではなく、チームで評価すべき

会社に目をつけられて一人前。

小規模でうまくいかないものを大規模でいきなりやっても失敗するだけ

抵抗勢力になるような人をいれるくらいなら入れないほうがいい

リファクタリングも全部が全部やるのではなく見極めが必要。投資対効果を考える

品質にはビジネス品質と内部品質がある。

Agile do ITに参加してきた

Agile do IT! に参加してきました

Agile Japanには残念ながら業務優先で行けなかったので、こちらに参加。

Agile in a Nutshell
アジャイルサムライの筆者のジョナサンの講演。
タイトルの通りアジャイルの概要でアジャイルサムライの第一章の内容ほぼそのまんまだったので正直読んだ人にとってはあんまり役にはたたなかったんですが（失礼）、本人のお話聞けてよかったです！

ジョナサンのおすすめなアジャイル開発の進め方としては
まずXPのエンジニアリングプロセスを導入してみて、次にScrumとXPを組み合わせたものをやってみて、最終的にLeanの考え方を導入して改善していく方法がいいんでない？と言ってました。

また3つの重要なこととして

1. 価値を毎週届けること
2. UnitTest、Refactoring、TDD、CI　は少なくともやる
3. ３つの真実
1. 全ての要求をかなえるのは不可能
2. 要求は必ず変化する
3. 時間と金は必ず予定を超過する

というところを最後にあげていました。

質問では、マネージャを説得するにはどうしたらいいんだという質問があり、回答としてはロジカルに説明するという方法と、顧客にどっちのやり方がいいか聞いたら顧客は毎週価値を届けてくれる方を選ぶと思うよといってました。

もう一つの質問では、チームがアジャイルを抵抗したらどうするんだという質問で、ジョナサンはアジャイル開発を強いるのは好きではなく、自分からはじめていくのがいいと思うと言っていました。

スクエニのプロジェクトマネジメント事例
スクエニのCTOの橋本さんの講演。
とてもよくアジャイルを理解しておられて、それをうまく工夫して自社開発に落とし込まれているなと思いました。（今回の中で一番参考になりました）

プロジェクトの予想はできないが制御は可能、予測できないことを受け止めなければならない。
事前対策と事後対策のバランスが重要。WFでは事前対策を重視しすぎて、なんちゃってアジャイルでは事後対策しかしていなかったりするから失敗するみたいです。

スクエニでは2点見積もりをしている。最小見積もりと最大見積もり（最小見積もり＋バッファ）で見積もって、さらに見積もり精度を指標として用いるなど、かなり厳密な測り方をしていて、納期に対する姿勢がとても感じられました。それぞれの見積もりにはプランニングポーカー的なやり方を導入しているそうです。

だいたい比率は　準備：実装：仕上げ＝１：１：１　になることが経験上得られているそうです。

橋本さんが強調しておられたのは、そのやり方をなぜ行うのか？ということを常に考え改善し続けることが最も重要であり、思考停止してはいけないというところでした。このあたりはまさにアジャイルの精神だなと感じます。

Yahooの事例
Yahooでは「標準」としてアジャイル（Scrum）が取り入れられているというのが驚きでした。どんな内容なのか詳細にはわからなかったのですが、狙いとしては、アジャイル開発を導入する際の導入コストの低減だそうです。「標準」とアジャイルというのはかなり相反する存在だと思っているのですが、そのあたりのバランスをどうコントロールしているのか今回は聞けなかったですが、今度是非聞いてみたいところです。

Scrumやってよかったことはコミュニケーションが円滑になったこと。
Scrumの準備としては、チームメンバーにスクラムガイドは読んでもらうことと、インセプションデッキはやったほうがいい。効果の定量的な評価は難しいが、導入前後の定性的な評価は行なっているそうです。

DeNAの事例
DeNAではプラットフォームのところでScrumを導入しているそうです。
40人くらいの人数なのでScrum of Scrumといった構成になっていました。
プロダクトオーナーは各チームにサブプロダクトオーナーを置いていました。
管理はJIRAを使ってプロダクトバックログ、スプリントバックログバーンダウンチャートなどを出しているそうです。

思ったことは、こういったソーシャルゲームといった業界ではかなりアジャイル開発をしているのかと思っていましたが意外とまだそこまで浸透していないということと、最初はスクラムのチームをエンジニア、デザイナーなどそれぞれで分けていたなどと、まぁどこでも組織というか職種の壁は存在するのだな・・と思いました。

パネルディスカッション

• チームにはスペシャリスト（CIなど）を置かないほうが、各自が勉強するのでよい
• ユーザーストーリーについて
• だれが作ってもいいけど優先度はPOがつけて責任をとる
• 割り込みタスク用に１０％〜２０％ほど余分にアロケートしておく手もある
• 非機能はどうしてる？
• スプリントの完了の定義に入れる
• 非機能対応用のタイムボックスを作ってそこでやる
• プロダクトバックログの大事なところ
• 優先度、背景はなにか、数が多くなりすぎないようにメンテすること
• 技術的なリスクを考慮する
• 納期に対してどれだけリソースをさけるか
• 準備できているか
• スクラムマスターとして意思決定に関わるときのコツ
• 振り返りの時に話題を投げかける
• 最初にガイドなどをつかって手本を示す
• 一人一人話しを聞いて人によってアプローチを変える
• BootCampをする。アジャイルはこういうものというのを紹介する
• メンバーのもつ不安を解消する。反論するチャンスを与える
• どのテクノロジー(TDD,CI)をやるかではなく、将来的にどの方向に向かいたいのかを決めておくのが必要。
• スクラムマスターに必要なスキル
• 空気を読まない事、忍耐力
• 最終的にチームから必要なくなる人になること

雑感
タイトルが"Agile do IT!"ですが、"Be Agile!"のほうがいいというか正しい気がしています。
というのもアジャイルは”する”ものではないというところがアジャイル開発において難しいところなのではないかと思っています。
確かに導入としてはTDDやCI、朝会、振り返りなどを”する”というのは大いにありですが、それによって万事解決するわけではなく、それをベースとして”自分たちにあった形に改善し続けていく”というところがアジャイルの本質的な部分ではないかと個人的には思っています。
そこをどう全体に広めていくかといったところにみなさん苦労なさっているという印象を受けました。むろん私もですが・・・

結構以外だったのが、DeNAなどのWeb系やソーシャル系のところではかなりTDD,CI,自動化などが進んでいて当たり前のようにやられているのかと思っていましたが、実際にはそういうところもあるが、テストの全くないレガシーコードも大量にあるのが実情ということで、まだそれほど差はないなということがわかった点でした。

アジャイルサムライ読書会 横浜道場 第三回に参加してきた

アジャイルサムライ読書会　横浜道場　第三回に参加してきました。

私としては第一回、第二回と連続参加になります。

今回は前回と引き続き、5分の輪読＋10分のディスカッションを何セットか行い、最後に書くテーブルでまとめを言うという形式でした。

各テーブルはスタッフ＋４〜５名で構成され、4テーブルにて行いました。

今回は第二章の始めから開始しました。


第二章は個人的にはアジャイルサムライの中でも最も重要なところの一つと思っている「自己組織化」について触れている章であります。

ここではアジャイルチームとしては職能横断であることや同じ職場で働くことなどが必要であるとあげられていますが、なぜそういったことが必要なのかといったことを議論していくうちに少しわかってきました。

チーム内でお互いをよく知るには同じ職場にいることが近道だし、職能横断であることでお互いに助けあったり、更に深く知ることもでき、それらの積み重ねによりチーム内での信頼が生まれ自己組織化に繋がるのではないかと感じました。
アジャイルなチームの構築には地味ですけどこうした継続的な努力が必要ですね、アジャイル全般に言えることでもあるかもしれませんが。


横浜道場は今回も初参加というかたもたくさんおられましたし、
だれでもウェルカムな雰囲気なので是非興味のあるかたは一度来られてみるといいと思います。

第三回では2章は終わらなかったので次回は2章の途中からになると思われます。

アジャイルサムライ読書会 横浜道場 第二回に参加してきた

アジャイルサムライ読書会　横浜道場　第二回に参加してきました。

前回にひきつづき参戦。

前回はワールドカフェ方式でしたが、今回は輪読方式でした。
１章の始めから５分ほど輪読したあと１５分ワールドカフェ方式でディスカッションするというのを何セットかやる　というやり方でした。

５分でかつ声に出して読むということでそれほどたくさん読めないので、ディスカッションするところがかなり絞られて、ディスカッションとしてはやりやすかったように思えました。

また、私のテーブルではSIerの方が比較的多く、業界によっての悩みどころの違いなんかもわかってきました。特にSIerだとやはりお客さんとの関係が問題で、最初に仕様、予算、納期を求められるところが悩みどころのようです。
個人的にはアジャイルと日本のSIerのようなビジネスモデルは相性が悪いというか、真っ向から否定しているような関係にあるように思っていたのですが、結構SIerさんの参加も多いのでみなさん現状に危機感を持っている方が多いのかなとも思いました。

こういった読書会は本の理解を深めるだけでなく、他の業界や会社での悩み事なども共有できたりするよい機会でもあるので今後も参加していきたいです。

また、今回の読書会のやり方は結構よかった気がするので今後自分がやることがあれば参考にしたいと思いました。

アジャイルサムライ読書会 横浜道場 第一回に参加してきた

アジャイルサムライ読書会　横浜道場　第一回に参加してきました。

アジャイルサムライ読書会他流試合以来二度目の読書会の参加です。

方式は同じでワールドカフェ方式で、お題に対してディスカッションを行いました。
投票で３つのお題を決め、２０分×３回のディスカッションを行いました。

お題は、アジャイルの導入、自己組織化、アジャイル導入時の問題　でした。

業界とか違う人達が集まっていたのでいろんな話が聞けて参考になったし面白かったです。
社外の勉強会はこういう点がいいですよね。

次回はワークショップのようなのでどんなことをするのか楽しみ。

Scrum Gathering Tokyo2011に参加してきた

Scrum Gathering Tokyo2011(Day2)に参加してきました。

といっても丸一日ScrumBootCampに参加したので他のセッションは全然見れませんでしたが。

Scrum Boot Camp

丸一日かけてScrumとはなんぞやという座学と実際にワークショップを体験して学ぶといったものでした。
４人〜５人のチームにわかれてワークショップは行いました。

・スプリント体験（チーム）
 まず午前の部では トランプを使ったもので、ものすごく短いスプリントを繰り返してゴールを達成する過程を体験するといったもので、これをやることにより気づいたことは非常に多く、今回やった中で一番よかったです。
会社でもすぐにできそうなので是非やってみたいエクササイズでした。

・プロダクトバックログの作成（個人）
家の掃除を題材にプロダクトバックログをつくるエクササイズ。
順序付けとどこまで必須なのかよく理解できました。

・見積もり（個人）
紙飛行機の作成、こよりの作成、トランプの並び替えの時間を見積もって、そして実際やってみるというエクササイズ。
全然見積とはあいません。

・見積もり（チーム）
今度は似たようなことをチームで見積もり。
個人でやるよりも安心感や確かさがあがる気がしました。

・見積もり（チーム）
今度はポイントを使って相対的な見積もりをするといったエクササイズ。
こちらは実際にせーのでポイントを各自がカードで出すことで楽しく見積もりができるだけでなく、ポイントが違った場合に、なぜそう見積もったのかということをチーム全体で共有することができ、これまでの見積もりよりも、より全員がゴールのための品質や手順などの共通認識がとれたように思えました。これもかなりよかった。

・スプリントの過ごし方（チーム）
ひらがなの表を手書きでメンバーの数×２個作成するという協業作業のエクササイズで、数名利き手と逆の手で書くという制約があり、余裕のあるメンバーが手助けしてこなすといった内容でした。

どれも座学だけでなく、実際にやってみることで気づいたり、納得したりすることが多く、やっぱり何事もやってみることが重要だと感じました。
アジャイルで開発を始める前に是非やっておくべき内容だと思います。

以下当日のスライド
Summary of Scrum Guide

View more presentations from Nishimura Naoto

Agile Estimating and Planning in your drawing paper

View more presentations from Nishimura Naoto

Ways and Means of Spending Your Sprints

View more presentations from Nishimura Naoto

XP祭りに参加してきた

XP祭りに初参加してきました。
http://xpjug.com/xpx/

いろいろと参加型のワークショップがあり、当日に紙に名前を書いて参加というかたちでした。
午後からなので余裕だと思っていたら遅刻してしまい、ワークショップはひとつだけ参加でしたorz

scrumはじめの一歩というワークショップに参加しました。

折り紙を使って紙ヒコーキをできるだけ多くつくるという作業を
10分×4回のスプリントでやるといったものでした。
scrumの講義だけでなく、実際に短い時間で体感できてとても面白かったです。
会社とかでもすぐにできそうなものなので、試してみたいなーと思います。

資料は以下です。

2011年 XP祭り Scrumはじめの一歩 #xpjug

View more presentations from Ryuzee YOSHIBA

講師の@ryuzeeさんのブログ
http://www.ryuzee.com/contents/blog/4225

よく見たら自分もちらっと写ってた！