1

@daipresents藤原 大•楽天株式会社 開発ユニット •アジャイルグループ マネージャ•好きなヒーロー： ウルトラマンゾフィー ダイナマン、スーパーワン キョウダイン、ZZガンダム

http://daipresents.com/

上記以外にもサービスはあります。これだけいろいろなサービスがあると開発方法も様々です。

•PO、DEVのチーム•スキルがまだ弱い若手•一体感のなさ現場

今日お話することアジャイルコーチとして活動を始め2年。リーダー・マネージャーとして、チームに繰り返し伝えてきたマインドセットと、現場を救う未来のヒーローについてお話したいと思っています。よろしくお願いします。

http://www.flickr.com/photos/31029865@N06/5845786904/

アジャイルマネジメントとマインドセット

Agile 2012in Dallas

アジャイル開発の本質とスケ-ルアップ - ソフトウェア開発の実践 - http://goo.gl/vIsk9

8つの変革

レガシーマインドセットたくさんのプロジェクト詳細なプロジェクト計画年間予算エライ人が作る年間計画WBSプロジェクトPMBOKWFのマイルストン

リーンアジャイルWIPを使ったかんばん軽量なビジネス案徐々に追加投資チームによる計画サイクル見積りと計画づくりリリーストレインアジャイルプロマネ現実に即したマネジメント

http://www.flickr.com/photos/31029865@N06/5845786904/

1. たくさんのプロジェクトから WIPを使ったかんばん

たくさんのプロジェクト

•非効率な並行作業•横やり作業•忙しいは生産的か？

•かんばんを用意•朝礼で確認・共有•使いながら改善WIP制限した”かんばん”

作業中ゾーン

MAX2枚

•WIP制限で安定化•見える化による発信•コミットメント宣言WIP制限した”かんばん”

朝礼の風景

PRO

ENG

ENG

ENG

問題がよく起きる場所

Before After

開発時間

x6

作った時間の有効活用

•価値のある手作業へ•サービスの触り心地確認•気づきをつなげる

http://www.flickr.com/photos/31029865@N06/5845786904/

2. 詳細なプロジェクト計画 から軽量なビジネス案

詳細なプロジェクト計画

•ヘビーなドキュメント•机上の空論スケジュール•守ることが目的に

•仕様書は正しくない•仕様はゴールではない•仕様は仮説でしかない軽量なビジネス案

小さいサイズ

軽量なビジネス案•要求をカードに書く•デモ・リリース可能なサイズ•大事なら時間をかける

photo - http://www.flickr.com/photos/nknh/2447013697/

•”汎用的に”•”スケールを考えて”•”キャッシュを入れて”軽量なビジネス案？

photo - http://www.flickr.com/photos/brucehh/7627194894/

小さくリリース

http://www.flickr.com/photos/31029865@N06/5845786904/

3. 年間予算から 徐々に追加投資

年間予算•年末の道路工事現象•使い方を決めて守る•1年先見越してる

徐々に追加投資

パス普通の予算型運営でやってるので経験者募集中。

http://www.flickr.com/photos/31029865@N06/5845786904/

4. エライ人が作る 年間計画から チームによる 計画サイクル

エライ人が作る年間計画

•1年を見越した計画•綿密な計画•変更コストがでかい

チームによる計画サイクル

•短期計画と長期計画•変更可能な開発計画•柔軟なリリース計画

ちゃんと計画する計画は変更する

計画 1～2週間のタイムボックス 比較的柔軟なリリース日 リズムを作る

計画は道路標識レベル

http://www.flickr.com/photos/31029865@N06/5845786904/

5. WBSからアジャイルな 見積りと計画づくり

WBS•部品を組み立てても欲しい物ができない謎•項目の漏れによる打撃•管理作業の圧迫

アジャイルな見積りと計画づくり

•優先順位付けと見積り•タイムボックスで計画•頻繁な見直し

やることリスト

見積もりで会話

こういう意見が“間に合うようにがんばってて欲しい”

楽天ブックス: アジャイルな見積りと計画づくり - マイク・コーン http://bit.ly/RhGkCO

“見積りは確率だがコミットメントは確率ではない”

http://www.flickr.com/photos/31029865@N06/5845786904/

6. プロジェクトから リリーストレイン

プロジェクト•リリースでDONE•チーム解散、運用チームへ•人が集められる

リリーストレイン•継続的にリリース•職能横断的なチーム•チームに対しての仕事

レーンが計画

2Wごとのリリース

リリース計画

http://www.flickr.com/photos/31029865@N06/5845786904/

7. PMBOKから アジャイル プロジェクト マネジメント

PMBOK•WBS•ガントチャート•進捗報告

アジャイルプロジェクトマネジメント

•新たな指標の設定•タイムボックスの活用•ゴールの確認

Velocity予定多すぎない？

リリース後下がってない？

当初は上がったり下がったり安定していない

急激に落ち込んでない？

かんばんの状態

TODOが増えてない Doingが増加していないか？

順調にDONEしているか？

ゴール•仕様どおり•ビジネス価値が正しかった•これを安定して継続的に繰り返すこと

“Quality is value to some person”

by Gerald Weinberg

品質

価値ユーザビジネス エンジニア

http://www.flickr.com/photos/31029865@N06/5845786904/

8. WFのマイルストン 現実に即した マネジメント

WFのマイルストン•計画に事実を合わせちゃう•机上の空論化

現実に即したマネジメント

•プロダクトの計測•効果測定を強化•現実に合わせて舵を切る

”なぜ全部計測しない？”

効果測定•20％ KPI上昇した！•想定以下の効果だった…•しかし何も起きなかった！

レガシー リーンアジャイルたくさんのプロジェクト WIPを使ったかんばん詳細なプロジェクト計画 軽量なビジネス案年間予算 徐々に追加投資エライ人が作る年間計画 分散回転式計画WBS 見積りと計画づくりプロジェクト リリーストレインPMBOK アジャイルプロマネ

WFのマイルストン 現実に即したマネジメント

http://www.flickr.com/photos/31029865@N06/5845786904/

ヒーローは誰だ？

90 ICQでギリシャ人に話しかけられびっくりして電源を抜いてしまうMacに出会う、Windows95を使う

Javaエンジニアとして働き出すSIerに就職し横浜に引っ越す

00

高校を卒業してフリーターになる

03

日記を書きだすビリヤードサークルを作る

好き勝手やっていながら親に頭を下げて専門学校に行かせてもらう

サークルにエンジニアが多いことに気がつく

0809数日後、標準化を撲滅しようと決意する現職に転職。標準化チームに配属される

10チームリーダーになるアジャイル開発に取り組みはじめる

Agile2010に参加はじめて勉強会で参加・発表

11イベント開催に加わるアジャイルコーチ開始

アジャイルマニフェスト10周年 12

マネージャになるAgile Japanで発表デブサミ2012で発表

今

”職業エンジニアどうすればいいですか？”

”アジャイルやってみたいんですけど”

”アジャイルはバズワードだ” ”会社が○○

だから”

”誰かなんとかしてくれただし、私の希望のとおりに”

楽天ブックス: ヒーローを待っていても世界は変わらない - 湯浅誠（社会運動家） 本 http://goo.gl/HBZfh

トレインスポッティング　ポスターフレームセット：セレッサ http://goo.gl/oVDtW

96

“人生を選べ。仕事を選べ。キャリア、家族、大きなテレビ、洗濯機、車、CDプレーヤーや電気オープナー、固定金利、マイホーム、友達、レジャーウェアとそれにあった旅行かばん、こじゃれたスーツ、日曜大工や休日の午前に自分探しすること、お菓子を食べながらソファでクイズ番組を見ること、よぼよぼになって古くなった自宅で老いて行く事を選べ。未来を選べ。人生を選べ。・・・でも、それがいったい何なんだ？”

Trainspotting (film) - Wikiquote : http://en.wikiquote.org/wiki/Trainspotting_(film)

“エンジニアの人生を選べ。未来を選べ。自分戦略を選べ。技術のトレンド、ビジネスを加速する、グローバル化、時代の変化、これからは英語がいる、生産性の向上、SIerはオワコン、ブラック企業、会社を変えると替える、社畜、業界構造、キャリアアップ、スキルセット、答えはあなたの中にあるとか、リーダーシップ、マネジメント、組織改革を選べ。未来を選べ。人生を選べ。・・・でも、それがいったい何なんだ？”

今

ふりかえりで成長を見える化する

話し合いに入れなかった。 報告のレベルがわかりにくい。全体のスケジュールが見えない。 タスクDONEを共有できていない。タスクがなくなった。 人に任せっきりになっていた。 利用者と相談ができていなかった。 タスクが多かった。 仕様の理解不足。 横槍り作業を考えるのが大変。 メンバーに頼りすぎた。 レビューが完了できなかった。 DONEの定義が曖昧。 口頭のほうが早いことがあった。 デザイン当てに時間がかかる。 レビュー反映に時間がかかる。 テストの時間が足りていない。 誰が何をやっているかわからない。 確認ポイントがばらばら。 見積より時間がかかっている。 TODOが減ってきた。 これまでのレビューが怪しい。 コミット漏れがあった。 タスク洗い出しがうまくなかった。 自動化に時間をつかえなかった。 デモを完全な状態で見せたかった。 開発環境が整っていない。 メインタスク以外のタスクが影響。 体調があまりよくなかった。 タスクを拾うのが消極的。 影響範囲把握ができなかった。 ドキュメントが古い。 作業遅延の報告が遅い。 デモが意味なかった。 データが壊れて開発に影響した。ファイルのリリース漏れがあった。コードが汚くなってきた。 目的を理解せず作業してしまった。 空き時間ができてしまった。 再設計引き継ぎがうまくいってない。 タスクに入るためのタスクがあった。 寂しい。 リリース自動化に失敗してしまった。 開発開始まで時間がかかった。 テスト不足があった。 寂しい。 タスクが大きすぎた。 メンバーに頼りすぎた。 うっかり仕様抜けが発生した。 目に見える成果がなかった。 マージ漏れがあった。 処理内容の理解不足があった。 デバッグが遅い。 チャレンジが足りなかった。 勉強会に参加できなかった。 バグがバグを生み出した。 実機を使ったテストが少ない。 英語に困っている。 優先順位がわからなくなった。 コミット漏れがあった。 完成するまで先が見えない。 スケジュール通りは厳しくなった。 ゴールが不明確な部分がある。 見積り忘れがあった。 チームとマネージャで認識ずれ。 JSではまって時間を消費。 汎用的に作ると時間がかかる。 仕様を確認せず実装してしまった。 メンバーのフォローが遅れた。 担当していない機能の理解不足…

144の『いまいち』

まず、見える化をしよう。 準備をしよう。 リーダにDONEを確認してもらう。 アジェンダを準備しよう。外部のタスクを把握しよう。チェックポイントを作ろう。技術MTGをはじめよう。 口頭で話そう。 ゴールの共有をしよう。確認者をちゃんと決めよう。 もうちょっと様子を見よう。明日計画MTGをしよう。レビュー時間をとろう。コミット前に差分確認しよう。 いないときは置き手紙をしよう。 自動化するレベルを考えよう。全員集合して分担をはじめよう。開発環境も並行してつくっていこう。タスクボードを朝礼後把握しよう。2週間分はかならずみつもろう。 腹巻きをしよう。 運用を考慮しよう。資料を残すようにしよう。環境構築も自動化していこう。レビューをもっとしよう。データを壊さないようにしよう。 勉強会しよう。 デザイナーと話してみよう。見積りを出そう。朝礼でカバーしていこう。チェックリストを作ろう。状況を整理してから共有しよう。 勉強会をしよう。 ENG MTGを活用しよう。最終確認までしたらリリースしよう。作業が止まらないように動こう。伝える時間を作ろう。 なぜから考えてみよう。 レビューを忘れずにしよう。ゴールを再定義してみよう。朝礼を有効活用しよう。遅いと思ったら改善しよう。再計画に時間をかけよう。 なぜから考えてみよう。 ソースレビューで検知しよう。ブラウザテストに時間をかけよう。確認手順を統一していこう。1日1タスクを考えていこう。付箋にして見える化していこう。 隣の人がを気にかけよう。 朝礼で共有していこう。付箋にして見える化していこう。残ったTODOに名前を書こう。テストを充実させていこう。 勉強会でナレッジ共有しよう。 朝礼で空き予定も共有していこう。はやめにアラートを出していこう。CIサーバを活用しよう。手でしかできないテストを洗い出せ。 アイデアを出しあっていこう。 ストーリの裏にゴールを書こう。実装の流れを書いてみよう。システムの理解を深めよう。テスト計画を張り出そう。 小さく作っていこう。 STGなどの環境で確認を強化しよう。タスク洗い出しでDONEの定義。タスクの移動は朝礼でやろう。 積極的に学んでいこう。 確認のルールを決めよう・・・

100の『チャレンジ』

スタンドアップMTGがよかった。タスクボードができた。 メンバーから意見が出た。 ゴールが明確だった。決定がスムーズだった。3キロ痩せた。 DONEの定義がよかった。ファシリテーションが良かった。誰が何しているかわかりやすい。 スキルの無さに気がついた。 問題解決の時間が短くなった。進んでタスクを取りに行けた。メンバーがサポートしてくれた。 サービスを全員で考えれた。 台風で早く帰ることができた。機能のブレストがうまくいった。メンバーのことがよくわかってきた。 要件以外の提案が出てきた。 コミュニケーションがとれている。ペアワークがうまくいっている。データ構造が理解できてきた。Rubyを勉強できた。 タスクをプル型でとれた。 リリースが成功した。既存ユーザの評価が良かった。トラブルのリカバリがスムーズ。 メンバーに元気をもらった。 周りがよく見えた。処理性能が高くなる実装ができた。デモの自動化が早くてよかった。自動リリースの範囲が増えた。 集中して開発できる。 開発～テストの流れを理解できた。TODOを増やすことができた。インタフェースの検討ができた。免許をとれた。 改善活動を皆でやることができた。 メンバーが増えた。開発環境が使いやすい。前よりすぐに人に聞くようになった。設計～リリースまで作業ができた。 チームのスピードが速い。 チーム感があった。座席変更がよかった。 全タスクをDONEできた。 アイスが美味しかった。 朝礼の遅延報告が良かった。勉強会がとてもよかった。リリースに自信をもつことができた。声かけしながらリリースできた。 新しいことにチャレンジできた。 メンバーとのペアオペがよかった。情報共有が良かった。 要件からENGが入ってきている。 メンバーの目標を聞くことができた。設計を経験できている。リリースまでの流れを理解した。 コードが綺麗とほめられた。 機能のデモが良かった。考えてソースを書くことができた。リリースまでの時間が短縮できた。リリースとテストの効率が上がった。 自分のコードがひどいことに気がつくことができた。 新機能開発の立ち上がりが速い。ペアプロが良かった。皆で仕様を考えた。設計が良かった。 何をやればいいかわかった・・・

142の『よかった』

世界は変わらないかもしれないけど

誰でもヒーローになれる

人生を選べ。未来を選べ。

未来は今だ。未来を選べ。