「XPエクストリームプログラミング入門」を読みました

基本的に仕事ではスクラム(or カンバン)をベースに考えてるのですが、スクラムの中でもXPのプラクティスは補完的に使えると思うし、Webで流し読みぐらいしかしたことなかったので、今改めて。

XPエクストリーム・プログラミング入門―変化を受け入れる

XPエクストリーム・プログラミング入門―変化を受け入れる

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/12
  • メディア: 単行本
  • 購入: 3人 クリック: 55回
  • この商品を含むブログ (70件) を見る

第3章 価値、原則、プラクティス

よく出てくる用語だけど、それぞれの意味や関係をちゃんと理解してなかったので。こういうことらしいです。

第9章 応用プラクティス

「チームの継続」と「チームの縮小」。まさに考えてるところなので、参考になりました。

小規模な組織にはこのような問題はない。チームが1つあるだけだ。

...

大規模な組織は、チームの価値を無視し、代わりに「プログラミングリソース」という分子または流動体のメタファを採用する場合が多い。(中略)この戦略では、部分的な効率性は最大限となるが、全体的には組織の効率性が損なわれる。

今僕が見ているチームは、まさにスケールしている最中なので、小規模・大規模のこの辺がよく実感できます。合わせて、うちでは分散拠点なので、ロケーションの問題も考慮しないといけないのが、更にややこしいところなんですよね。もちろん、ロケーションの問題を極力埋めるために、オンラインビデオ会議などシステムで回避できるようなものも積極的に取り入れようと試みてはいますが。

第10章 XPチーム全体

メトリクス(測定値)とは何ぞや?というのを、すごい分かりやすく説明した文章があったので引用。

速度計が速度を指し示すのと同じように、開発後の欠陥と投資から収益までの時間はどちらもチームの有効性を示している。速度計の針をつかんで動かしてみても、車の速度を上げることはできない。速度を上げたければ、アクセルを踏み、その効果を確認するために速度計を見る。同じように、測定値に基づいて目標を設定できるが、チームは根本的な問題に対処する必要がある。数字を直接改善しようとしても、数字が修正されるだけで、プロジェクトに関する透明性の価値が排除されてしまう。

メトリクスはあくまで現状を測るためのものなんですよね。メトリクス自体を補正しようとしても、まったく意味がない、というのが分かりやすい例えでした。

ただ、そもそもメトリクスがないと、実際にいい方向に向かってるのか悪い方向に向かってるのかが分からない(感覚的にはある程度わかっていても)。なので、まずはメトリクスを取ってみるというところは意識付けしていきたいなと思ってます。


その他にも制約理論の話とか、ちょいちょい見たことがある話もありましたが、もろもろ再確認できました。ただ、正直なところ、何か文章が頭に入ってきづらかったんですよね。。寝不足で疲れてたとかもあるのかも。読書も持続可能なペースでいきたいものです。

「コーチングマネジメント」を読みました

テクニックや知識的なところだけでなく、人と対峙する面も求められる今の役割・立場的に必要そうとは思ってた「コーチングスキル」。いくつか推薦してもらった本の中から、まずはこれを読んでみました。

PART1 : 今求められるマネジメント革命

ゴルフを教えないゴルフコーチ

ここで取り上げられてたやり取りが印象的でした。なるほど、こういうのがコーチングの基本形なのかなと感じました。

「目標に対する集中度は1から10で何点?」
「自分の体や動きに対する気づきは1から10で何点?」
「今のショットから学んだレベルは1から10で何点?」

みたいな感じで、コーチが特に技術的なアドバイスをするわけではなく、現状を気づかせる問いかけをするだけ。けれど、それによって、自分自身で考えて行動するようになる、という話。

ミスショットのときも、それを責めるとかではなくあくまで気づきを与えるような問いかけが、例に挙げられていました。

「どうやってあんなふうにボールを曲げたんだね?」
「打つ前から曲がるような気がしたし、・・・頭が混乱していたし、腕も緊張していた」
「そう、それでどんなことを学んだ?」
「混乱しているときは、仕切り直しだな」
「今までだって仕切りなおしのチャンスはあったと思うんだけど、それができなかったのはどうしてなんだろう?」
「一緒にプレーしている人の目を気にしていたのかな?」

PART3 : コーチング・スキル

クローズド・クエスチョンとオープン・クエスチョン

「なぜ?」って言葉は、オープンクエスチョンに見えて、実はクローズドクエスチョンに近いという話。「なぜ」と聞くと相手を萎縮させてしまって、結果的にクローズドクエスチョンになりがちだということです。

「なぜできなかったんだ?」
「なぜそんなことをやってしまったんだ?」

そのかわり、「HOW」や「WHAT」を使うとのこと。一般的には、HOWがアイディアを発展させて、WHATが問題をはっきりさせると説明されています。

「どうやったら、同じ失敗を繰り返さないですむと思う?」
「次はどういうふうにやる予定?」


「何が足りなかったんだろう?」
「何か気がついたことはなかった?」

効果的な質問のためにすること・実際のコーチングクエスチョン

コーチングの質問に際して考えておくべきことや、質問リストがきれいにまとまってました。ちょくちょく見直すことになりそう。

選択の幅を広げる質問

クローズド・クエスチョンの「Yes / No」「やるか、やらないか」は選択ではなくて脅迫らしい。コーチは、必ず3つ以上の選択肢を見つけ出して、自発的に選択できる状態をセットしなければいけないって。

結構難しい気がするけど、頑張ってみる。

アクナレッジメント

「賞賛」などの評価を含む言葉ではなく、事実を事実として伝える。評価が入ると、意見なので受け取りにくくなるということらしいです。「You」「I」「We」の視点があり、一番効果的なのは「We」のアクナレッジメント。

具体例をあげるのはやめておくかな。意識的か無意識的かにせよ、これと同じ言葉を誰かが聞いたとき、わざとらしく感じるかもなので。

エコロジカルチェック

何か変化があったときに、質問しながらその変化によって生じた歪みを見つけること、らしい。例えば、こんな状態になってるとして、

「頭では分かっているんだけどしっくりしない」
「何か違和感がある」
「最初はいいと思ったけど、今はちょっと」

これらの心理的な違和感や歪みを、こんな質問であらためて確認する感じ。

「今やっていることは、やる前に考えていたことと一致していますか?」
「やり方を変えて、気分はどうですか?」
「思ったような成果が上がっていますか?」
「ストレスはどうですか?」
「何か違和感はありませんか?」
「体の変化どうですか?」
「生活のバランスはとれていますか?」

要はやりっぱなしでなくて、ちゃんとアフターフォロー的なところも意識してってことかな。こういった「継続的な取り組み」ってのは、最近のマイブームというか、自分・組織に対して根付かせていきたいと思ってます。ふりかえりにしろ、例の本で学んだ見積もりと計画づくりにしろ、ここでのエコロジカルチェックにしろ。


一通り書いた後に見返してみると、ちょっとコーチングのスキル的なところばっかり目についちゃったかな。また適当なタイミングで見返してみて、そのときはどう思うかを感じてみたいです。

「アジャイルな見積もりと計画づくり」を読みました

名著と言われながら、今まであまり興味がなくて読んでなかった分野。もっと早く読んでおけばよかったなと思う反面、おそらく以前の自分では消化できなかった&活かせなかっただろうなと思ってはいます。

1章:計画の目的

1. なぜ見積もりや計画づくりが必要なのか?

しょっぱなにあるこの問いかけ、最初からすごいためになる文章です。この本を読むまでは、見積もりや計画って、やりたくないけどやらざるを得ないといった、どちらかというと消極的な理由しか思い浮かびませんでした。でも、それだけでないよという話。具体的には、以下の5つが挙げられています。

  • リスクを軽減する
  • 不確実性を減らす
  • 意思決定を支援する
  • 信頼を確立する
  • 情報を伝達する

この中で太字にしたものが、消極的な理由ではなく、計画作りをしていくことによってもっと前に進めるための理由かなと感じました。開発者・チームにおいても、いやいや計画づくりをやっていくのではなく、チームが計画づくりをやっていくことによって、ビジネス面での意思決定を支援したり他チームとの信頼を確立していくことを意識する。それが結果的に、開発チームだけでなく全体のサービス・プロダクトにいい影響をもたらしていくというのは、自他共に意識づけていきたいなと強く思いました。

あとは、これかな。

3. アジャイルな計画づくりとは?

本書で扱うのはアジャイルな「計画づくり(planning)」だ。アジャイルな「計画(plan)」ではない。
...
アジャイルな計画づくりで重視するのは、計画よりも、計画を作る過程そのものなのだ。

プロジェクト初期のみ「計画」を作成するだけじゃだめで、ちゃんと日々の活動の中で計画を更新していく「計画づくり」が大事だよということ。これって、プロセス改善の文脈でのメトリクスとかでも同様だよなーというのを思い描きながら読んでました。

11章:「望ましさ」による優先順位づけ

狩野モデルについての説明。このモデルについてはどっかで見たことがある気がするけど、本の中で出たので改めて見なおしてみました。守備範囲的にはプロダクトオーナーの領域っぽいけど、スクラムマスターとしてもさらっとでも知っておいて損はない領域だし、参考になりました。

モデルの説明については、先人のブログを参考に。
d.hatena.ne.jp

16章:ベロシティの見積もり

ベロシティは常に固定になるわけではなく当然幅があるけど、その幅をどう扱うかの話。3イテレーション(スプリント)以上取れる場合、以下の方法が挙げられていました。

  • イテレーション毎のベロシティをそのまま幅として扱う
  • 不確実性コーンを活用する

前者は単純。3回のイテレーションのベロシティが (12, 15, 16) ポイントだった場合、見積もり幅は 12~16 ポイントと扱います。

後者は、不確実性コーンと呼ばれる、プロジェクトの状況に応じて不確実性の幅が変わる図を流用しています。ここで、3回イテレーションこなした後の平均ベロシティが20ならば、下限が20*0.85=17, 上限が20*1.15=23 で、17~23 の幅に収まるだろうと推測する感じ。

f:id:ikikko:20160813102519p:plain

実施したイテレーション 下限の係数 上限の係数
1 0.60 1.60
2 0.80 1.25
3 0.85 1.15
4以上 0.90 1.10

ちょっと計算式は複雑になるけど、不確実性コーンをもとにした方が、今のうちのチームにとってはいいかなと思いました。理由としては、ベロシティの平均が基準となってるから。

うちのやり方として、1イテレーション内できれいに終わりきらないことがあるのですが、その場合各イテレーションのベロシティは変動しやすくなるんですよね。ただ、各イテレーション毎の変動はともかく、移動平均をとっていくと中長期的には問題とならないことが多い*1。なので、平均を考慮した方がより精度が高いものが出せるかなと思っています。

22章:なぜアジャイルな計画づくりがうまくいくのか

11. ゆとりを残す

チームメンバー全員の時間を100%使い切るような計画を立てないこと。特にイテレーション計画では気をつけること。高速道路の限界100%まで車を詰め込むと、誰も身動きの取れない渋滞になってしまう。開発チームもこれと同じだ。メンバー個々の時間を限界まで使ってしまうと、プロジェクトの進みは遅くなってしまう。

はい、やってしまってました。イテレーション計画ミーティング時は作業時間見積もりをしてるのですが、このとき全時間を詰め込もうとして結局計画したものが全部終わりきらない。終わらないものを計画時に話すのムダだし、終わらなかったという事実はチームメンバーのモチベーション的にもいい影響を与えない。

なので、最近ではベロシティ(実績)ベースで考えるようにしようとしてます。普段大体これぐらいポイント消化できてるのだから、(作業時間はもうちょい余裕あるけど)計画するのはここまでにしておこう。で、おかわりできるならばそのとき考えよう、という方針にしてます。

チームがもっと成熟して毎回安定して計画したものを終わらせられるようになってきたならば、その次はいかにベロシティを上げていくかを考えていく感じ。もしかしたらその中で、作業時間のムダに着目していって、より効率的にタスクに取り掛かれるようになるかもしれないなーとは考えています。


いつもより長くなった。それだけためになる内容が多かったです。特に1章の「1. なぜ見積もりや計画づくりが必要なのか?」は常に意識しておきたいです。

あと、タイムリーなことに、先月の WEB+DB PRESS でちょうど見積もりの話がでてました。こちらも参考に。

WEB+DB PRESS Vol.93

WEB+DB PRESS Vol.93

*1:この辺は「7章:再見積もり」の「4. 部分的に完了したストーリーの再見積もり」も参考に。

「ピープルウエア」を読みました

事務所にあったやつをひっぱってきたので、最新でないちょっと古いやつ。名著と言われてたけど読んだことなかったし、今の立ち位置的に読んでおいて損はないと思って。

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

第 II 部:オフィス環境と生産性

騒音、特に電話の話。電話という点では、うちにはそこまで影響がないとは思ってます。が、(別チームの)ミーティングがうるさい問題は以前ちょっと感じてたので、その辺を頭に思い浮かべながら読んでました。

なお、つい先日事務所引っ越しして、ミーティングルームが増えたので、今はかなり改善されてるのかなと思ってます。

第 III 部:人材を揃える

採用における「能力テスト」についての説明が気になりました。

その人物は、能力テストで測られた作業を2年間で終え、他の作業を20年間やることになるかもしれない。

採用の際には、今できることという短期的な視点だけではなく、長期的にどうなりそうかを重視するのがよさそうだというのを、改めて考える機会となりました(もちろん、今までも無意識的にそういう風に考えていたとは思いますが、改めてということで)。

第 IV 部:生産性の高いチームを育てる

組織のビジネス的な目標、例えば「今期の利益を2倍にする」といったものが、ダイレクトに個人やチームの目標と結びつくかは分からないという話。この点も、うちではある程度解消されているのかなと感じています。というのは、自分たちが作ってるサービスを自分たち自身でも使ってるので、「サービスをよりよくすること=自分たちも楽になる」というのが分かりやすく実感できる目標なためです。

とは言っても、「自分たちのサービスをよりよくする」だけじゃ足りないところももちろんあるので、やっぱりその他やれることはやっておく必要があります。という点では、この辺かな。

チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。

このチームの目的は満たされたとき、チームのメンバーはずっと効率よく働く。一体になったことでベクトルが合ったからだ。

これを達成するためにも、チームの目標が何なのかと、それを各チームメンバーにも意識付ける取り組みに注力しようとしてるところです。


全般的に、名著と言われるほどには自分が読み解けない点が多かった気がしました。もっと経験を積んだ後に読み直すと、また違ったものが見えてくるのかなあ。

「リーン開発の現場」を読みました

前回のカンバン仕事術でカンバンが気になってきたので、もう一冊カンバン系の本を読んでみました。少し昔の本ですが、カンバン仕事術が最近の本だったので、敢えて古めの本を手にとってみることに。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

第3章:デイリーカクテルパーティーに参加しよう

30人から60人の大規模チームにおける、デイリースタンドアップミーティングの効率的なやり方について。

こんな感じで、3段階に分かれてそれぞれデイリーミーティングを行ってるようです。

  • 第1段階:機能開発チームのスタンドアップミーティング
  • 第2段階:スペシャリティ同期ミーティング(テスター同士のミーティングや、開発リーダーミーティングなど)
  • 第3段階:プロジェクト同期ミーティング(プロジェクト全体に関連するミーティング)

今の自分のチームの状況と照らし合わせると。規模がここまではないので3段階はやり過ぎ感があるけど、2段階で各チーム + 開発リーダーミーティング的なのはありかなと思いました。というのも、今は自分がハブになる感じで各チームとのミーティングを個別にやってるけど、それだとどうしても自分がボトルネックになりがちなんですよね。持続可能じゃない気がするので何とかしたいところ。

第16章:僕たちが学んだこと

「実験しよう」「失敗を抱擁しよう」とか、色々いい言葉が書いてます。時々、この辺の言葉を思い出したいです。

いくつか気に入った言葉をピックアップしておこう。

完璧な解決策を探そうとしてはダメだ。そんなものを期待して待ってもたぶん仕方がないだろう。
...
その代わりに、小さく少しずつできる改善点を探して、改善を実験だと考えてみよう。

失敗への恐怖が、改善の最大の敵だ。「なぜ俺達は失敗したんだ?誰がやらかしたんだ?」と問いただす代わりに、「僕たちは何を学んだんだろう?そして、次に何を試そう?」と聞いてみよう。

本当の失敗はひとつしかない。それは、失敗から何も学ばないという失敗だ。

たいていの人は変化を好む。でも、他の誰かに変えられるのは好まない。だから変化を起こすときは、影響を受ける人々をまず主体に巻き込まなければならない。

第20章:因果関係図

カンバン仕事術でも紹介されてたし、「なぜ5回」とかも呼ばれてるよくあるやり方だと思うけど、この本は説明が多く例が分かりやすかったです。これやらないと、何か気持ちモヤモヤしたままになったり、ひとまず一番最初に思いついた問題に対して(結果として表層的な)解決策を実施しようとかなったりするので、大事なことかなと思ってます。結構時間使うのでいつでもできることじゃないとは思いますが、ふりかえりと合わせて、自分も取り入れ始めてみました。

翻訳者の一人の@papandaさんのスライドも合わせて。

www.slideshare.net

おまけ:5分で理解するリーンな「かんばん」

本書でもとりあげられてますが、このサイトのマンガ、カンバンやWIPの制限の紹介に便利なのでよく引用させてもらってます。

lean-trenches.com

「カンバン仕事術」を読みました

ちょっと読むのに時間かかってしまった、カンバン仕事術。最初読んでるときは、カンバンもよさげな開発手法だなとは思いつつ、実業務の中で活かしどころがイメージできてなかったのですが、読んでるうちにちょっと霧が晴れてきた気がしたので、2周読んだ感じ。

カンバン仕事術

カンバン仕事術

カンバン3原則

カンバンって何となく、最初の「見える化」したものって思ってたのですが、それだけでなく「WIPの制限」とそれによる「流れの管理」も必須なんだなと理解できました。見える化だけでもある程度は解決するものもあるでしょうが、カンバンから継続的な改善を引き出すには後ろ二つが重要になってくると。

「流れ」対「リソースの稼働率

WIPとリードタイムについて疑似体験するゲーム、コイン渡しゲームの結果を受けての一言。

逆に、最後のイテレーションでは、リードタイムは短くなりましたが、それぞれの作業者の作業時間は長くなりました。効率が落ちたのです。ですが、チーム全体としては一番でした。

「WIPを小さくして流れを早くすると、個々のリソース(開発者)の効率は落ちる」ってのは、目からうろこでした。ついリソースの稼働率を気にしちゃうけど、稼働率が max なのがそのままユーザにとっての価値につながるわけじゃないですもんね。ならば、稼働率にとらわれ過ぎるのではなく、リードタイムを短くして流れを早くし、より早くユーザに届けることを意識するのは理にかなってると思いました。

そのままキャプチャで抜粋させてもらいますが、同様のことを言ってるやりとりがこちら。これはがつーんときましたね。意識改革が必要なんじゃないかと思ったところ。個人個人がそれぞれで動くのではなく、チームとして動くべき一つの理由になると思いました。


デイリースタンドアップ

他の手法でのスタンドアップミーティングとは違って、「個人の作業ではなくてチーム全体の作業・流れについて着目する」ってのはなるほどなと思いました。

多分、この辺のことを意識せずに普通にスタンドアップを開くと、「昨日やったこと」「今日やること」「困ってること」をそれぞれ個人に聞く形式をしそうだなと思ってました。だけど、カンバンでは「ボードを右から左に歩く」つまり完了に近い方から見ていって話し合うというやり方がいいようです。

f:id:ikikko:20160605021748p:plain


ほかにも色々実運用を考える際に参考になるところはあったのですが、大きく揺さぶられたのはこの辺ということで。カンバン使えそうな気がするので、もうちょい追ってみようかと思ってます。

「アジャイルコーチの道具箱-見える化実例集」を読みました

カンバン仕事術を先に買ってたのですが、京都遠征したときに@yohhatu, @posauneと話した際、まずはこっちを読んだほうがいいとアドバイスもらったので。

leanpub.com

いつでもさくっと確認できるように、iPhoneにPDFを入れておいた上で、気になるやつをブックマーク付けしておきました。ブックマークしたやつはいくつかに分類分けできそうなので、記憶の定着がてら、簡単に紹介します。

モチベーション上げる系

ちょっと反省点なのですが、ふりかえりなどでどうしても悪い点ばかり目について指摘しがちになってしまってます。言うべきところでは言わないといけないと思いますが、そればかりだとモチベーション的にもあーあーってなっちゃうので、悪い点を指摘するのではなくいい点を取り上げてうまくモチベーションを向上できるような仕掛けもやっていかないとなと、改めて思いました。

f:id:ikikko:20160508173203p:plain

  • 成果ポスター
  • 時間通りのスタンドアップ + ハイスコア
  • 遅刻はケーキ
  • ごほうびビン
  • 失敗ボード
  • レース場

なお、偉そうなこと言ってる割に自宅でのモチベーション管理がまったくできていないので、家でも導入しようかしら・・・


チームのコンディション確認系

↑のモチベーション上げる系にも関連しますが、チームのコンディションを手軽に見える化できると面白そうかなと思いました。口で「ツライわー」とはなかなか言いにくい人もいるけど、こんな感じでアイコンちょっこっと動かすぐらいなら朝会の前にでもぱっとできそうなので。

f:id:ikikko:20160508173253p:plain

  • 自信のニコニコマーク
  • ストレスレベルのメーター
  • チームのムードメーター

情報共有系

うちは拠点が分散してるのもあるので、通常以上に情報共有を意識しておかないといけないんですよね。その辺を見える化するためのやつもいくつか気にかかりました。

f:id:ikikko:20160508173307p:plain

  • サーバンドマネージャーのドア
  • 私の学びたいこと