Agile Do IT で講演しました
去る3/19(月)に DeNA さんからのお誘いで Agile Do IT で講演してきました。既に2週間過ぎてしまっていますが、資料を公開します。
Agile do IT! ヤフー 爆速開発への挑戦!
View more presentations from Kaz Takahashi
とても濃く、熱いイベントにでした。懇親会会場も人があふれ、熱気に満ちていました。主催のDeNAさま、ありがとうございました! 僕たちもタイムテーブルのアイデアやグッズ等で協力できうれしく思います。
パネスディスカッションでのお題についても僕の先日のブログからいくつか出ていたように見えました。ご興味のある方は是非そちらもごらんください。
こちらも拡張していける仕組みをのんびり準備しています。
デブサミ2012で講演してきました。
Developers Summit 2012 で講演してきました。
こういった大きな場で講演する機会を頂いたことに大変感謝しています。
また、同時間帯の強力な講演のなかから、多くのみなさまにご来席いただきました。
本当にありがとうございました！
僕の発表は、アジャイル開発やスクラムのやり方を直接説明するものではなく、新しいやり方を会社に取り入れていく際に、どのような考え方と戦略で組織に浸透させていくのかについて、うまくいったと思える考え方やプロセスを紹介したものです。
アジャイル開発したいけど、「組織環境が整ってない」「チームが言うことを聞いてくれない」「上長が話を聞いてくれない」といったよくあるハードルに対して直接的な答えをお話するのではなく、僕の体験談やアプローチ方法を通じて、「アジャイルやりたい」と思ったときにまわりに働きかけるためのヒントになれたら良いなという思いを込めたつもりです。
アジャイル開発の経験者が居たからできたんじゃ…?と思われる方もいるかと思いますが、全く同じ環境は2つとありません。やりたいと強く願ったなら、一歩踏み出しましょう。
その時はスクラム道(@tao_of_scrum)へ是非!
スクラムマスターとして考えることリスト(ドラフト)
スクラムマスターをする時に考えることって何だろうと思って書きだしてみた。
まだまだ足りない気がするが、とりあえずこんなところ。ササっと書いたのでtypoや重複等あるかと思います。
その人なりのハラオチした答えがあると良いと思う。このなかには僕なりの答えがないものもあるけど。
この中からピックアップしてみんなで議論してみるのも面白そう。スクラム禅問答と名付けようw
追記希望とかあればぜひ〜
- チームのこと
- チームはどこを目指そうとしているのだろう?
- チームは本当はどんな開発がしたいんだろう?
- みんなはどういうチームの状況を働き易いと思うのだろう?
- このチームで何を達成することを「一番」大切だと思うんだろう?
- このチームでまず「一番」最初に直すべきところはどこだろう?
- チームが一番生産性を発揮できるのはどんなときなんだろう?
- チームが一番品質を向上していけるのはどんなときなんだろう?
- 何故やる気が無いことを平然と公言できるんだろう?
- 何故やる気が出てこないんだろう?
- そもそもどんなスタイルで開発がしたいんだっけ?
- 開発全般のこと
- 今作ってる機能って誰のためのどんな目的だっけ?それはきちんと表現されてるっけ?
- そもそも今の管理手法は何を管理しているんだっけ?
- その管理はお客様への価値提供にどう貢献しているんだろう?
- 僕達はどっちを最大化したいんだろう?
- こなすタスクの量
- お客様に提供する価値
- 何故開発には納期が設定されるんだろう?
- 納期の意味は何だろう?
- 何故案件のスケジュールとスコープが両方とも固定になってしまうことが起きるんだろう?
- 開発がうまくいくための前提条件って何だろう? (予算?技術?人?ルール?)
- そもそも「開発がうまくいく」って何だっけ?
- 成果主義的人事評価との兼ね合い
- 目標とプロジェクトの進捗はどちらに合わせるべきだろうか?
- どうやったらプロジェクトの進捗をうまく目標に反映できるだろうか?
- どうやったら目標に引っ張られずに、プロジェクトの進捗を最大化できるだろうか?
- どうやったらスクラムチームの成果を世間に注目してもらえるだろうか?
- スクラムのこと
- 何故透明性(見える化)を大切にするのだろうか?
- 何故開発チームは自分でタスクを取るのだろうか?
- 何故プロダクトオーナーはタスクのアサインができないのだろうか?
- 何故スクラムマスターはプロダクトオーナーや開発チームに命令ができないのだろうか?
- 何故プロダクトオーナーはスプリントで実施するストーリーの量をコントロールできないのだろうか?
- 何故開発チームは実現するストーリーを優先順位順にやらなくてはいけないのだろうか?
- 何故プロダクトバックログを作るんだろう?
- 何故PBLには優先順位をつけるのだろう?
- 何故ユーザーストーリーが良く使われるのだろう?
- 何故見積もりは開発チームが行うんだろう?
- 何故スクラムマスターという役割があるのだろう?
- 何故プロダクトオーナーという役割があるのだろう?
- 何故開発チームという役割があるのだろう?
- 何故3つの役割に別れているのだろう?
- 何故スプリントバックログを作るんだろう?
- 何故スプリントバックログはタスクボードで表現されることをお勧めするんだろう?
- 何故スプリントというタイムボックスを設定するんだろう?
- 何故スプリント計画をするんだろう?
- 何故デイリースクラムをするんだろう?
- 何故スプリントレビューをするんだろう?
- 何故スプリントふりかえりをするんだろう?
- 何故検査と適応を大切にするのだろう?
- スクラムマスターとして
- スクラムチームの中長期的な
- 生産性を保つために何ができるだろう?
- 品質を保つために何ができるだろう?
- チームのどういうところを観察したら良いだろうか?
- 今チームのメンバーに元気がない人はいないだろうか?
- 品質を上げるためにできることは何だろう?
- スクラムマスターに必要なスキルって何だろう? どうやったら伸ばせるだろう?
- プロダクトオーナーに必要なスキルって何だろう? どうやったら伸ばせるだろう?
- 開発チームに必要なスキルって何だろう? どうやったら伸ばせるだろう?
- 何故改善のアイデアを実施するのは、緊張するんだろう?そうしないために何ができるんだろう?
- 何故改善のアイデアを実施するのは、だるいんだろう?そうしないために何ができるんだろう?
- 何故改善のアイデアを実施するのは、後回しになるんだろう?そうしないために何ができるんだろう?
- あいまいな意思決定を防ぐためには何ができるんだろう?
- 課題を言っても動いてくれない上長にどう対処したら良いのだろう?
- メンバーのネガティブな反応をどのような気持と解釈で受け止めたら良いだろう?
- どうやったらスクラムチームが楽しく効果的に働けるんだろう?
- 全てを良くできるわけではないだろうけど、自分たちがやれることがあっとしたら何だろう?
- 自分が燃え尽きないためにできることは何だろうか?あるいは何をしないことにしたら良いだろうか?
- 障害リストは必要だろうか?
- スクラムマスターとして適切な受け答えの仕方ってどんなんだろう?
- スクラムチームの中長期的な
スクラム道.01 行ってきた
もう先週になっちゃったけど、スクラム道.01 に参加してきた。
テーマはふりかえり。
最初の30分 @nawoto さんによる、ふりかえりの概説とKPTのバリエーションについての前説。
そのあと1.5時間みっちりディスカッション。
以下、僕のメモ。
ふりかえりへのインプット
- 場のルール
- スプリントの結果
- スプリント中の出来事
- スプリント中の心理状態の記憶
ふりかえりのアクティビティ(インプットを整理して分析してアイデアを出す)
- KPT,Good/Bad,絵を書く。
ふりかえりのアウトプット
- 改善アクションリスト
-毎回出てくるようなKEEPは工数使って自動化する決定
メンバーとかチームのモチベーションのケアに重心を置くか、スプリント結果と改善に重心を置くかについて、意見がわかれたけど、僕は前者に比重を置くことが多い。ソフトウェア開発は人間系の影響が非常に大きいと思っていて、メンバー・チームの状態によってvelocityとか品質に影響が出るのが避けられないから。でも、後者が間違ってるという話ではなくって、両方大切な事だと思ってる。モチベーションにも、スプリントの結果にも問題があると思ったら、前者のケアを優先したいかな、、、くらいの違い。
総じて新しい視点、バリバリ実践されている方々とのディスカッションを通じて自分では忘れがちな視点を強化できた素敵な場だった。
「チームであることを確認」し、「起きたことを分析し、行動に落とし」て、「プロフェッショナルに前向き」なふりかえりを目指すこと。
KPTをもっと楽しく
みんな大好きKPT。けぷとって読むみたいだね。(僕はケーピーティーって読んでた)
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
僕も好き。でも僕、これ、たまに難しいと思った。だから、僕は次にKPTするときは下のようにしようと思ってる。
- 枠は出さない。ポストイットにどんどん書いてもらう
- ホワイトボードとか壁に、よかったグループと、課題グループに分けて貼り付け、トピックごとにグルーピング
- 特にチームのボトルネックになってる課題を数点だけ選んでもらう
- その課題について次に試すアクションを書く
- 終わったら、必要に応じてKPTのフレームワークにまとめる
どうもね、いきなり
「よかったこと、改善した方がいいと思ったことをどんどん挙げて行こう！」
って、言われてもね、ナニを言ったらいいか戸惑っちゃうんだよね。
だいいち、あれって3つの場所に区切ってあるでしょ？あれがまずいけない。限られたスペースを、ヘッポコな意見で埋めちゃいけないって思っちゃう。
え？思わない？僕は思った。貧乏性かな。
どうも、僕はあの枠が議論の発散→収束のプロセスを曖昧にしているように思った。発散したい場面なのに収束を暗示していて、型にはめてしまうような感覚を覚えたんだ。
あとね、パワポでも何でもいいんだけど、モニターに枠を写して、ファシリテーターが話しながら入力していくのね、あれもミーティングの臨場感って点ではもう一歩だと思うんだ。せっかく貴重な時間を割いて参加してくれたメンバーにもっと参加して欲しいと思ったよ。だから、ポストイットに書いてもらう。壁に貼ってもらって、身体を動かしてもらう。
こういったフレームワークはみんなの意見を構造化してみせたり、それ自体が議論の進め方を示唆したりするけど、フレームワークが意図するところを理解してないと、議論の効果が思ったように出なかったりする。だからこそ、フレームワークが提供する書式(KPTだったら3つの長方形)が効果を妨げそうなら遠慮無くカスタマイズしたらいいと思う。
これってもうKPTじゃないかもしれないけど、きっと同じ効果をだせるよね。だれかやってみたら結果教えて！コメントでもTwitterでもいいからさ！
新しい職場
ヤフーによるシリウステクノロジーズの買収に伴って配置転換が行われ、開発プロセスの標準化を検討・推進するチームに配置となりました。当面はアジャイルプロセス検討・導入を進めるのが僕の仕事です。
今までは１つのチームのスクラムマスターとしてやってきましたが、新しい仕事はさらに広い視野が必要そうです。
大企業での勤務経験がなく、アジャイルの導入に関する経験には乏しい僕ですがこれからさらに学習やコミュニティ活動を活発にして幅広い知識を吸収していきたいと思います。
色々な場でお顔を合わせることがあると思いますが仲良くしてくださいね。
これからもよろしくお願いします。
ところで、導入ご破算とかなったら僕居場所ないんじゃね？w
成長する組織へ導くコミュニケーション変革 - Agile Japan 2010
4/7(土)にAgile Japan 2010 (#aj10) の事例セッションでお話してきました。
ブレインラボさんと共同で、成長する組織へ導くコミュニケーション変革というテーマでした。
Agile Japan は参加者として行く予定だったのですが、申し込み直後に実行委員の江端さんからまさかの講演依頼が。
成長する組織へ導くコミュニケーション変革 - 事例に学ぶコミュニケーション革命 -Agile Japan 2010
View more presentations from Akihito Enomoto.
時間が足りず、用意したことすべてをお話することが出来ませんでしたが、今後また機会があればお話したいと思っています。
セッションではポスト・イットを配布して、質問を集めたのですが、皆様の鋭い質問にドキドキしました。
こんな質問です。(ポスト・イットから書き写しただけなので意味がつかめないものもありますが)
ブレインラボ・弊社両方に向けた質問(セッション内で回答済み)：
- スクラム以前：お客様からクレームが多かったことに対する経営層の態度は？
- プロダクトバックログとは
- (経営者の視点で)チームが成果を上げたときに、どのように誉めたか。
- 導入をしやすいのはどういったプロジェクトがやりやすい？仕事の内容ではなく、規模や受注形態
- 抵抗勢力とはどう対応しましたか？(そもそもいましたか？)
- 外部からはAgile コーチ入れましたか？
- 気持ちの維持や盛り上げるための”技”はありますか？情熱的な回答で…
ブレインラボ・弊社両方に向けた質問(未返答)：
- 変化をきらう人の年齢は？
- メンバーの理解は何%くらいで導入できるか？
- マトリクス型組織や、マルチタスク(複数のPJ)を抱えている場合、スクラムをどのように導入しますか？
- 契約書には「スクラムで開発する」と書いてあるのですか？書いてない場合は、いつ、どのように決めるのですか？
- すくすくスクラムコミュニティは、一体感とあたたかみを感じます。なぜなんでしょうか？
- (経営者の方へ)導入後、そうは言ってもやってられっか！って思ったこと
- 見積り(この粒度は？)以上コストかかる
- スクラムが有効に機能する最小〜最大構成人数は？
- スクラム
- 複数ロールを持つことはあり？
- スクラムに対応した人事評価とは？
- そのピンチ!!をチャンスに変えたキッカケは？
弊社向け質問：
- 採用の際、ロジカルシンキング等のスキルはどのように見極めていますか？
- 紹介あった人員はみんなエンジニア？評価体系の変更ききたい！
- SCRUM 導入にあたって、最初からコーチに依頼することがベストの選択と考えますか？(回答済み)
これからAgileやScrumを意識して開発していきたい方々が典型的に思う質問も混ざっているでしょうね。機を見てこのブログでも取り上げたいと思います。
プレゼン、まだまだ慣れていないこともあり、こうすれば・ああすればという思いはありますが、資料を作る過程で、今までのスクラムへの取り組みを振り返えったり、メンバーへインタビューで意外な考えを知ったり、資料を5人で共同編集したり、準備でも本番でもとても学びの多い体験でした。
参加された方々におかれましては、本当にありがとうございました。参考になることがひとつでも持って帰れていたら、最高に嬉しいです。もし、退屈な時間を過ごされたのでしたら、申し訳ないです。僕の力不足です。またやるときには、もっともっと面白くします！また来てくださいね！(笑)
最後に、お誘い頂いたOdd-eの江端さん、Millsさん、ブレインラボの永井さん、榎本さん、近田さん(資料のデザインをしていただきました。素敵なデザインありがとうございました！)、それから参加を快諾してくれた弊社取締役の安藤、みなさまお世話になりました。すごく楽しかったです。
おまけ：会社紹介で使ったPreziのプレゼンテーションです。
Agile Japan 2010 シリウス紹介 on Prezi
