かっぱっぱ

2012-04-02 Agile Do IT で講演しました

去る3/19(月)に DeNA さんからのお誘いで Agile Do IT で講演してきました。既に2週間過ぎてしまっていますが、資料を公開します。

とても濃く、熱いイベントにでした。懇親会会場も人があふれ、熱気に満ちていました。主催のDeNAさま、ありがとうございました! 僕たちもタイムテーブルのアイデアやグッズ等で協力できうれしく思います。

パネスディスカッションでのお題についても僕の先日のブログからいくつか出ていたように見えました。ご興味のある方は是非そちらもごらんください。

スクラムマスターとして考えることリスト(ドラフト)

こちらも拡張していける仕組みをのんびり準備しています。

2012-02-21 デブサミ2012で講演してきました。

Developers Summit 2012 で講演してきました。

こういった大きな場で講演する機会を頂いたことに大変感謝しています。

また、同時間帯の強力な講演のなかから、多くのみなさまにご来席いただきました。

本当にありがとうございました!

僕の発表は、アジャイル開発やスクラムのやり方を直接説明するものではなく、新しいやり方を会社に取り入れていく際に、どのような考え方と戦略で組織に浸透させていくのかについて、うまくいったと思える考え方やプロセスを紹介したものです。

アジャイル開発したいけど、「組織環境が整ってない」「チームが言うことを聞いてくれない」「上長が話を聞いてくれない」といったよくあるハードルに対して直接的な答えをお話するのではなく、僕の体験談やアプローチ方法を通じて、「アジャイルやりたい」と思ったときにまわりに働きかけるためのヒントになれたら良いなという思いを込めたつもりです。

アジャイル開発の経験者が居たからできたんじゃ…?と思われる方もいるかと思いますが、全く同じ環境は2つとありません。やりたいと強く願ったなら、一歩踏み出しましょう。

その時はスクラム道(@tao_of_scrum)へ是非!

2012-01-19 スクラムマスターとして考えることリスト(ドラフト)

スクラムマスターをする時に考えることって何だろうと思って書きだしてみた。

まだまだ足りない気がするが、とりあえずこんなところ。ササっと書いたのでtypoや重複等あるかと思います。


その人なりのハラオチした答えがあると良いと思う。このなかには僕なりの答えがないものもあるけど。

この中からピックアップしてみんなで議論してみるのも面白そう。スクラム禅問答と名付けようw

追記希望とかあればぜひ〜

  • チームのこと
    • チームはどこを目指そうとしているのだろう?
    • チームは本当はどんな開発がしたいんだろう?
    • みんなはどういうチームの状況を働き易いと思うのだろう?
    • このチームで何を達成することを「一番」大切だと思うんだろう?
    • このチームでまず「一番」最初に直すべきところはどこだろう?
    • チームが一番生産性を発揮できるのはどんなときなんだろう?
    • チームが一番品質を向上していけるのはどんなときなんだろう?
    • 何故やる気が無いことを平然と公言できるんだろう?
    • 何故やる気が出てこないんだろう?
    • そもそもどんなスタイルで開発がしたいんだっけ?
  • 開発全般のこと
    • 今作ってる機能って誰のためのどんな目的だっけ?それはきちんと表現されてるっけ?
    • そもそも今の管理手法は何を管理しているんだっけ?
    • その管理はお客様への価値提供にどう貢献しているんだろう?
    • 僕達はどっちを最大化したいんだろう?
      • こなすタスクの量
      • お客様に提供する価値
    • 何故開発には納期が設定されるんだろう?
    • 納期の意味は何だろう?
    • 何故案件のスケジュールとスコープが両方とも固定になってしまうことが起きるんだろう?
    • 開発がうまくいくための前提条件って何だろう? (予算?技術?人?ルール?)
    • そもそも「開発がうまくいく」って何だっけ?
  • 成果主義的人事評価との兼ね合い
    • 目標とプロジェクトの進捗はどちらに合わせるべきだろうか?
    • どうやったらプロジェクトの進捗をうまく目標に反映できるだろうか?
    • どうやったら目標に引っ張られずに、プロジェクトの進捗を最大化できるだろうか?
    • どうやったらスクラムチームの成果を世間に注目してもらえるだろうか?
  • スクラムのこと
    • 何故透明性(見える化)を大切にするのだろうか?
    • 何故開発チームは自分でタスクを取るのだろうか?
    • 何故プロダクトオーナーはタスクのアサインができないのだろうか?
    • 何故スクラムマスターはプロダクトオーナーや開発チームに命令ができないのだろうか?
    • 何故プロダクトオーナーはスプリントで実施するストーリーの量をコントロールできないのだろうか?
    • 何故開発チームは実現するストーリーを優先順位順にやらなくてはいけないのだろうか?
    • 何故プロダクトバックログを作るんだろう?
    • 何故PBLには優先順位をつけるのだろう?
    • 何故ユーザーストーリーが良く使われるのだろう?
    • 何故見積もりは開発チームが行うんだろう?
    • 何故スクラムマスターという役割があるのだろう?
    • 何故プロダクトオーナーという役割があるのだろう?
    • 何故開発チームという役割があるのだろう?
    • 何故3つの役割に別れているのだろう?
    • 何故スプリントバックログを作るんだろう?
    • 何故スプリントバックログタスクボードで表現されることをお勧めするんだろう?
    • 何故スプリントというタイムボックスを設定するんだろう?
    • 何故スプリント計画をするんだろう?
    • 何故デイリースクラムをするんだろう?
    • 何故スプリントレビューをするんだろう?
    • 何故スプリントふりかえりをするんだろう?
    • 何故検査と適応を大切にするのだろう?
  • スクラムマスターとして
    • スクラムチームの中長期的な
      • 生産性を保つために何ができるだろう?
      • 品質を保つために何ができるだろう?
    • チームのどういうところを観察したら良いだろうか?
    • 今チームのメンバーに元気がない人はいないだろうか?
    • 品質を上げるためにできることは何だろう?
    • スクラムマスターに必要なスキルって何だろう? どうやったら伸ばせるだろう?
    • プロダクトオーナーに必要なスキルって何だろう? どうやったら伸ばせるだろう?
    • 開発チームに必要なスキルって何だろう? どうやったら伸ばせるだろう?
    • 何故改善のアイデアを実施するのは、緊張するんだろう?そうしないために何ができるんだろう?
    • 何故改善のアイデアを実施するのは、だるいんだろう?そうしないために何ができるんだろう?
    • 何故改善のアイデアを実施するのは、後回しになるんだろう?そうしないために何ができるんだろう?
    • あいまいな意思決定を防ぐためには何ができるんだろう?
    • 課題を言っても動いてくれない上長にどう対処したら良いのだろう?
    • メンバーのネガティブな反応をどのような気持と解釈で受け止めたら良いだろう?
    • どうやったらスクラムチームが楽しく効果的に働けるんだろう?
    • 全てを良くできるわけではないだろうけど、自分たちがやれることがあっとしたら何だろう?
    • 自分が燃え尽きないためにできることは何だろうか?あるいは何をしないことにしたら良いだろうか?
    • 障害リストは必要だろうか?
    • スクラムマスターとして適切な受け答えの仕方ってどんなんだろう?

2010-11-08 スクラム道.01 行ってきた

f:id:kappa4:20101108170408j:image:right:w400

もう先週になっちゃったけど、スクラム道.01 に参加してきた。

テーマはふりかえり。

最初の30分 @nawoto さんによる、ふりかえりの概説とKPTのバリエーションについての前説。

そのあと1.5時間みっちりディスカッション

以下、僕のメモ。

ふりかえりへのインプット

ふりかえりのアクティビティ(インプットを整理して分析してアイデアを出す)

  • KPT,Good/Bad,絵を書く。

ふりかえりのアウトプット

  • 改善アクションリスト

-毎回出てくるようなKEEPは工数使って自動化する決定


メンバーとかチームのモチベーションのケアに重心を置くか、スプリント結果と改善に重心を置くかについて、意見がわかれたけど、僕は前者に比重を置くことが多い。ソフトウェア開発は人間系の影響が非常に大きいと思っていて、メンバー・チームの状態によってvelocityとか品質に影響が出るのが避けられないから。でも、後者が間違ってるという話ではなくって、両方大切な事だと思ってる。モチベーションにも、スプリントの結果にも問題があると思ったら、前者のケアを優先したいかな、、、くらいの違い。


総じて新しい視点、バリバリ実践されている方々とのディスカッションを通じて自分では忘れがちな視点を強化できた素敵な場だった。


「チームであることを確認」し、「起きたことを分析し、行動に落とし」て、「プロフェッショナルに前向き」なふりかえりを目指すこと。

2010-10-21 KPTをもっと楽しく

みんな大好きKPT。けぷとって読むみたいだね。(僕はケーピーティーって読んでた)

KPTを使ったプロセス改善:An Agile Way:オルタナティブ・ブログ

f:id:kappa4:20101022020610j:image:w240

僕も好き。でも僕、これ、たまに難しいと思った。だから、僕は次にKPTするときは下のようにしようと思ってる。

  1. 枠は出さない。ポストイットにどんどん書いてもらう
  2. ホワイトボードとか壁に、よかったグループと、課題グループに分けて貼り付け、トピックごとにグルーピング
  3. 特にチームのボトルネックになってる課題を数点だけ選んでもらう
  4. その課題について次に試すアクションを書く
  5. 終わったら、必要に応じてKPTフレームワークにまとめる

どうもね、いきなり

「よかったこと、改善した方がいいと思ったことをどんどん挙げて行こう!」

って、言われてもね、ナニを言ったらいいか戸惑っちゃうんだよね。


だいいち、あれって3つの場所に区切ってあるでしょ?あれがまずいけない。限られたスペースを、ヘッポコな意見で埋めちゃいけないって思っちゃう。

え?思わない?僕は思った。貧乏性かな。

どうも、僕はあの枠が議論の発散→収束プロセスを曖昧にしているように思った。発散したい場面なのに収束を暗示していて、型にはめてしまうような感覚を覚えたんだ。

あとね、パワポでも何でもいいんだけど、モニターに枠を写して、ファシリテーターが話しながら入力していくのね、あれもミーティングの臨場感って点ではもう一歩だと思うんだ。せっかく貴重な時間を割いて参加してくれたメンバーにもっと参加して欲しいと思ったよ。だから、ポストイットに書いてもらう。壁に貼ってもらって、身体を動かしてもらう。

こういったフレームワークはみんなの意見を構造化してみせたり、それ自体が議論の進め方を示唆したりするけど、フレームワークが意図するところを理解してないと、議論の効果が思ったように出なかったりする。だからこそ、フレームワークが提供する書式(KPTだったら3つの長方形)が効果を妨げそうなら遠慮無くカスタマイズしたらいいと思う。


これってもうKPTじゃないかもしれないけど、きっと同じ効果をだせるよね。だれかやってみたら結果教えて!コメントでもTwitterでもいいからさ!