More Effective Agileを読みました
Twitter で書評をまとめてたのを、集約するために転記。
More Effective Agile “ソフトウェアリーダー”になるための28の道標
- 作者:Steve McConnell
- 発売日: 2020/06/11
- メディア: Kindle版
次は #萌えアジャ本 を読みます https://t.co/jYOaQOMYfY
— ikikko (@ikikko) 2020年8月11日
『「検査と適応」はOODAの省略表現としてうってつけである』OODAがなにものかいまいち分かってなかったんだけど、この表現はわりとしっくりきました
— ikikko (@ikikko) 2020年8月31日
「オープンフロアオフィスにさまざまな問題があることが判明している」「生産性が最も高まるのは個室か2人部屋である」完全オープンフロアはともかく、チームがまとまって好きに使えるブースは欲しい派。ホワイトボードや共有ディスプレイ付きで。
— ikikko (@ikikko) 2020年8月31日
『開発者とユーザーとの触れ合いと、「自律、熟達、目的」の「目的」部分との間には、強い相互作用がある。このプラクティスはプロダクトの品質という恩恵とモチベーションという恩恵の療法をもたらす』やっぱユーザーと触れ合うのは大事ですよねー
— ikikko (@ikikko) 2020年8月31日
「対面でのコミュニケーションを定期的にスケジュールする」「信頼の半減期は6週間だ」わかりやすい目安。今の状況下ではなかなか難しいかもだけど、コロナが落ち着いたらこれぐらいを目安に考えたい。一方、単に対面にしただけだとあまり効果なかったこともあるので、その辺はもうちょい仕込まないと
— ikikko (@ikikko) 2020年8月31日
「短いスプリントは実験を短期化する」「作業量は与えられた時間をすべて使い切るまで膨張するというパーキンソンの法則」短いスプリントの利点を、パーキンソンの法則に絡めると、一言で説明できてわかりやすいですね
— ikikko (@ikikko) 2020年8月31日
「スプリントのリズムに変化を持たせることは、アジャイルの持続可能なペースというスローガンを後押しする」今までは、ペースを崩さないことが持続可能であると思ってた。けど、同じペースを続けると単調になって、逆に持続可能じゃなくなる懸念があるというのは、なるほど。この辺は気付かされた
— ikikko (@ikikko) 2020年8月31日
「チーム間でのベロシテの比較はたいてい無意味なものに終わるが、意味のある比較が一つある。チーム間の生産性の向上率である」これはそうですね。絶対視するものではないけど、一つの参考情報にはなるかも。
— ikikko (@ikikko) 2020年8月31日
わかりやすいので、画像をはらせてもらう。不確実性コーンの前半は、アジャイル的な見積りは使えないというか同じになるので、ちゃんとシーケンシャル開発での見積り手法もおさえておく pic.twitter.com/ztMHAQ1A47
— ikikko (@ikikko) 2020年8月31日
「予測可能性が必要なときにエピックを予算として扱う」例では、あるエピックに55ptを割り当てたら、その後分解するときは55を超えないように分解していく。これはスコープと期日をいい感じに扱うための、よさげな手法っぽい
— ikikko (@ikikko) 2020年8月31日
この本でも出てきた、遅延コスト。よさげだとは思うんだけど、うまく扱えてない。正確な値を出すより、まずはTシャツサイズ的なのでざっくり出して、考えるほうがわかりやすいかなあ
— ikikko (@ikikko) 2020年8月31日
アオアシから学ぶ、ふりかえりに大切な行動特性やマインドセット
みなさん、アオアシというサッカー漫画はご存知でしょうか?純粋に漫画としても面白いのですが、漫画の中のセリフや考え方がいちいち自分にいい意味で刺さってくるので、私が特に心に残った場面をふりかえりと絡めて紹介したいと思います。
言語化
alu.jp最初は言語化について。この場面は、それまで感覚でプレーしていた主人公が、おぼろげながらもプレー時に考えてたこと・感じたことを言語化しようとしている場面です。「いいぞ、言語化できてる」
ここで取り上げられているように、言語化することによって、自分の考えをふりかえって整理できるようになります。いいことは、再現性を高く / 改善の余地あることは、同じ失敗を繰り返さないように。逆に言うと、言語化できないうちは何でうまくいったか・いかなかったかを意識しないので、同じところから成長できない。
また、いい言語化ができるようになると、他人に考えを分かってもらう・動いてもらうのがスムーズになります。
大事なのは、だからどうするか、だ / 厳しい意見をもらいにいく
alu.jp自分的ナンバーワンワード。主人公に差をつけられたサブキャラが、差をつけられたということを認めた上で、じゃあどうするか?というのを宣言する場面です。
自分も他人と比べて凹んだり、やろうとしたことが全然できなくてで凹んだりで、よくボコボコになっています。ただ、そこで凹んだままだと成長がない。「自分はできない」を自覚した、その上で「だからどうするか」に意識を切り替えるようにしています。
で、どうするか?に対しては、厳しい意見でも率直にくれる信頼できるメンターがいると、より効果的です。メンターと話す際には、↑の言語化もセットで活きてくるでしょう。
いろんなことがいずれ考えなくてもできるようになる。そうしたら、ようやくそれが自分のものになる / 人間は考える葦である
alu.jpalu.jp
「真摯に考え続けていたら、だんだんそれが染み付いて、考えなくても自然とできるようになる。だからガンバレ」というのを、ヒロインが応援してくれる場面。なお、主人公の名前は「青井葦人」で、「人間は考える葦である」や漫画タイトルの「アオアシ」は、そこにかけているものと思われます。
サッカーに限らず、個人やチームに染み込んだ理念や行動は、いずれ考えなくてもできるようになるでしょう。KPTで言うと、最初はKeepに掲げていちいち意識しないと続けられなかったことが、だんだん当たり前になってくるイメージ。
なお、このブログは以下の記事にインスパイアされています。漫画好きなんですよね。
dev.confengine.com
next.rikunabi.com
あと、著作権を配慮した漫画のコマ引用ができるとのことだったので、一度試してみたかったのもあったのでした。
alu.jp
以上、みなさんのおすすめの漫画・セリフもぜひ聞かせてください!
フェニックスプロジェクトワークショップを体験してきました
今日、クリエーションラインさんのフェニックスプロジェクトワークショップというのがありました。それに参加してきたので、忘れないうちにメモっておこうと思います。
目的
今日の参加者は、普段とは違ってアジャイルコーチの人たちばかりで構成されてました*1。
めんどくさいアジャイルコーチな人たちはよく「自律的なチームがー」みたいに言ってるけど、その人たちが集まったときにほんとにそういう風に振る舞えるの?というのが気になってたので、この機会にいっちょ確かめてみようかというのが目的。
感想
あー、ただただ、多人数での作業の進め方に熟練した人たちばかりでやると、ここまで物事が早く進むんだなあというのを実感した場でした。いくつか例をあげると、こちら。こういうのって、別に今回のワークショップに限定した話ではないんですよね。
- 話しやすいように、ワークショップ始まって最初の第1声で「はいまずテーブル寄せようー」と会場のレイアウト変更
- 一人で抱え込んでたら情報量過多でどうにもならなくなるってのが直感的にわかってるので、まず全部共有
- ちょっとあちらこちらでわーわーいってても、「大事なことなんで聞いてくださいー」って手あげたらみんなそっちを聞く
- なんか不安要素があったら、協調作業する / 並列で進めるより一個一個確実に終わらせていく方向に自然となる
- バリューストリームに並べたほうがプロセス見えやすいよね、じゃあそう並べようと自然に
- 何か問題が起きて詰まってたら、周りの人にすぐ相談・周りもすぐに集まって助けに入る
- タイムキーパーも誰か特定の人がするのではなく、空いた人が自発的に確認して「あと〇〇分だよー」って知らせてくれる
- 会話だけで空中戦になって何を話しているかの認識が合わなくなってきたら、一回立ち止まろうと誰かが言い出して書いて見える化
- 何らかの決定時にちょっと意見がわかれても、長々と話し込まずに親指サイン*2で3秒で決を採る
- 改善のやり方がこなれている:まず現場や起こったことをふりかえって、課題をリストアップして、改善アクションを決めて、アクションを実際にシミュレーションして、その結果をフィードバックしてまた調整するループを回していって・・・
- 既存の発想にとらわれない:持ち歩いてたドットシールをカードに貼って分類の手助けにしたり、必要な紙が1枚しかないのであれば会場飛び出してコンビニにコピー取りにいくし、挙句の果てにはテーブル狭いよねじゃあ床使おうとなるし
問題もなかったわけじゃなくて、「ちょっと目の前の作業や割り込みに注力し過ぎて、大局的に見てROIが高い施策を進められてるか?」といったところは、改善の余地はありそうではありました。
ちな、自分の中での今日1のパワーワードがこちら。床は最強ですね。
壁にはりものしにくい現場はあるけど、床がない現場はない(ので、壁がなければ、床を使えばいいじゃなーい)
というわけで、開始1分でレイアウトがこうなって・・・
お昼過ぎたころにはこうじゃ
自社(自分もメンバーの一員)の中で活かすには
よくあるトラップであろう、役割のサイロ化は、文化的に多分避けられそう。
ただ、作業のやり方をこうまでうまくできる自信はない。その中でも、積極的に上であげたような振る舞いを自分で実演して、いい意味で周りをその雰囲気にのませて当たり前に思ってもらい、みんなが実践しだすように持っていくのがポイントかなと感じました。
どこかの現場を支援する立場のときに活かすには
今回僕たちがやった体験と照らし合わせて、その現場はどこがひっかかるのかを比較するのがおもしろそう。録画とってないから、完全に比較するのは難しいけど。
あとは、実際の組織構造をそのまま連れてたときに、どう変わるかは観察してみたい。今回の僕たちは、みんなロールをガン無視して進められました。けど、実際の組織に当てはめたときは、普段のロールにとらわれてて不要にサイロ化しちゃわないか、など。
ということで、クリエーションラインさんありがとうございました。みなさんも興味があったらぜひ参加してみてください!
(※:写真はフェニックスのポーズ)
*1:ぼくは別にアジャイルコーチとして動いてるわけじゃないけど、主催者にお声掛けしたときに、ちょうどアジャイルコーチで集まってやる機会があるよーとのことだったので、そのタイミングで混ぜてもらいました。
*2:親指サインはじめ、決定を早くする手法は以前まとめたので、https://backlog.com/ja/blog/3-ways-of-effective-meeting/も参照。
「リーンエンタープライズ」を読みました
Switchを買っちゃって、プライベートの時間がどんどんなくなっちゃって、ヤヴァイってなってます。この本も、もう1年以上前に読んでたのに、いまさらの感想ブログになってますし。
リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)
- 作者: ジェズ・ハンブル,ジョアンヌ・モレスキー,バリー・オライリー,角征典,エリック・リース,笹井崇司
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/10/15
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
確か、この本読もうとしたときに、ちょうど↓のスライド見た記憶があります。幅広くカバーしてるってので、もれなく吸収したいなと思ったのでした。
2章 企業ポートフォリオのダイナミクスを管理する
この章では、やっぱり3つのホライゾンですよね。
ホライゾン1 | ホライゾン2 | ホライゾン3 | |
---|---|---|---|
概要 | 既存のビジネス:今日のキャッシュフローを生み出す | 高成長ビジネス:今日の収益成長と明日のキャッシュフローを生み出す | 成長のオプション:将来の高成長ビジネスのオプション。キーワードは、リーンスタートアップや製品/市場フィット(Product / Marget Fit) |
目標 | 経済的リターンの最大化 | キャズムを超える、収益に貢献し始める | 新しいビジネスを作る |
主要指標 | 計画に対する収益、市場シェア、利益率 | 売上高利益率、ターゲット顧客数 | クチコミ(消費者)、有名顧客(法人) |
自分の性質がホライゾン1,2に向いてるのもあって、ホライゾン3はちょっとおろそかになりがち。なので、そうなりがちというのを意識しておかないとなと、再確認しました。合わせて、自分が今手がけてる事業は、ホライゾンのどこに当たるのかな、それにふさわしい指標やら施策になってるんだっけ?というのを踏まえながら。
5章 製品/市場フィットを評価する
海賊指標:AARRRと、課題/解決フィット・製品/市場フィットの関係について、再確認。それぞれ単語は頭に入ってたのですが、それらの関連などを確認・考えるきっかけになりました。
名前 | 目的 | Votizenでの例 | 気にかけるべきフィット |
---|---|---|---|
Acquisition:獲得 | サービスを訪れた人の数 | アカウントを作成した | |
Activation:アクティベーション | はじめてなんらかの体験をした人の数 | 信頼性を確証した | 課題/解決フィット |
Retention:定着 | 何度も戻ってくる人の数 | 少なくとも3回システムを使用した | 課題/解決フィット・製品/市場フィット |
Revenue:収益 | 収益を生む活動にかかわる人の数 | 活動を支援した | 製品/市場フィット |
Referral:紹介 | 他のユーザーを紹介する人の数 | 友人に転送した | 製品/市場フィット |
フィット関連について思い出したのは、下記の記事。製品の時間軸の流れを考えて、AARRR -> ARRRAというようにAcquisitionを最後に持ってきたのと同じことかなと思いました。自分の中の知識がチョットつながってきた。
あとは、ソフトウェア開発には外せない、エンジニアリングプラクティスについて。「あとで技術的負債を支払うために、最初から従っておくべき2つのプラクティス」はこちら。ホライゾン3では製品レベルだけど、ホライゾン2でも機能レベルで技術的負債を扱うことになるので、どのみち避けては通れない。
- 継続的インテグレーション
- 基本的なユニットテストおよびユーザージャーニーテスト
前者は、エンジニアとしての自分が価値を出せる&自分もやってて楽しい領域。他は多少優先度下げてでも、ここはちゃんと第一線はれるように腕を磨いておきたい。
後者は、ユーザージャーニーテストって知らなかったんだけど、Fowlerの定義や下記の図いわく、一番下(ユニットテスト)と一番上(ユーザージャーニーテスト)を抑えておくべしということかな?
( by You cannot Automate a User Journey Test – Toby The Testers Blog )
6章 継続的改善をデプロイする
ソフトウェアに依存している会社がハイパフォーマンスを達成するには、何よりもまず、実行する能力、信頼できるシステムを構築する能力、複雑さを継続的に軽減していく能力にフォーカスすべきです。ビジネスの優先度と連携するのは、それができてからでいいでしょう。
よく「どこから改善していくべきですか?」という質問を受けたり見たりしたとき、雑な手書きだけどこういう風に認識している。いつまでもビジネスの優先度を考えないのも困りものだけど、まずは先立ってIT部門にある程度の実行能力がないと、ビジネスがうまく回っていかないので。
他には、活動会計。最終的には時間ではなくて、成果 = アウトカムに結びついてるかを考えたいけど、その手前としてどういう活動にどれぐらいの時間を使ってるかというのは、自分たちでコントロールしやすくてとりかかりやすそう。下記は、本書で取り上げられてた活動会計の表。
コストの割合 | 活動 | 以前 |
---|---|---|
2% | 継続的インテグレーション | 10% |
5% | アジャイルな計画 | 20% |
15% | ひとつのメインブランチ | 25% |
10% | 製品サポート | 25% |
5% | 手動テスト | 15% |
23% | 自動テストスイートの作成と保守 | 0% |
~40 | イノベーション | ~5% |
自分でもちょっとお試しとして、自分でも各人の月次稼働実績をまとめて集計して、何か見えないかを試してみました。もう1,2ヶ月分出してみて、ちょっとふりかえってみよう。
最後に、改善のカタ。これ、フォーマットとしていいんじゃないかと思いつつ、以前やったけどうまく実践できなかった。改めてもう一回トライしてみようかしら。
www.slideshare.net
7章 価値を明らかにしてフローを増やす
バリューストリームマッピング、カンバン、遅延コストの章。これだけでご飯が3杯ぐらい食べられそう。
それぞれ、以前読んだ本にも取り上げられてるぐらい。けど、バリューストリームマッピングは結局素振りもちゃんとできてないので、やらんといけんってのを改めて思い出せました。やるぞー。
第IV部 変革
- 文化
- GRC:ガバナンス / リスク / コンプライアンス
- 財務管理
- IT部門
にまつわる話。ですが、まだまだピンとこなかったところが多いです。少しずつ関わるようにもなってきたのですが、まだまだ経験不足ですね。後日もう一回読み直してみましょうかしら。
最後のIT部門に関しては、おそらく今後レビュー書くであろう「LeanとDevOpsの科学」で触れるはず。もう読んだけど、感想文書くときにあらためて考えることにします。
LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)
- 作者: Nicole Forsgren Ph.D.,Jez Humble,Gene Kim,武舎広幸,武舎るみ
- 出版社/メーカー: インプレス
- 発売日: 2018/11/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
1回目に読んだときは全然ささらなかった探索のところが、2回目読み直すとチョット分かるようになってきたのは面白い変化。前向きに捉えると、以前よりは成長してるということなんでしょうかね。
RSGT2019の当日ボランティアスタッフをやってきました
応募したきっかけ
去年もボランティアスタッフに応募していたのですが、家族がインフルっちゃったので、(自分はかかってなかったけど)念のために直前キャンセルをさせてもらいました。なので、今年が初めて。
スタッフに応募した目的としては、よりRSGTを味わいたかったから。スピーカー枠でいけたら一番よかったんだけど、残念ながらプロポーザル落ちたので、ならばとスタッフで応募したのでした。スタッフ業が少し慌ただしい時間もあったのですが、とは言ってもフル稼働しておかないと追いつかないような体制では全然なかったので、適度にセッション見学や参加者と交流しつつができました。
スタッフみんな自律的!
スタッフ業やってて一番ほーとなったのは、スタッフみんなが自律的に動いてるというところ。ほとんどのスタッフが2回目以上だったり、会場が前年と一緒で慣れていたりというのもあるのでしょうが、各々が判断して作業を進めていました。
理由の一つに、トランシーバーが効果的なのかなと思いました。「ヘルプお願いー」とか声掛けあると、すぐにみんな反応するとかはわかりやすい話。あとは、判断に迷ったときでも「トランシーバー上で共有しておけば、ダメだった場合誰か止めてくれるか」と思って、自分の判断で動きやすいという心理的な安心感はありました。トランシーバーがないと、やっていいか分からないのでちょっと置いておくか、みたいな状況も多分多かっただろうなーとも。
細かいところを見れば、自律的に動いた結果、作業がかぶる(誰かがやったことを、よかれと思って戻す)こともちょいちょい見受けられたのですが、概ね問題なく進められて、全体としてはもろもろかなり早く進められたんじゃないかなと思ってます。自律的な組織・チームをトランシーバーという仕組みで作る、いい体験をできました。
スマホアプリもあるようなので、小規模のイベントではこっち使えるかもですね。
「デザインスプリント」を読みました
基本、読んでる本はWIP 1で進める派(今読んでる本を読み終わる or 諦めるまで、次の本に手を出さない)なのですが、割り込みでデザインスプリントの本を読みました。
背景としては、業務でプロダクトデザインフェーズでのアイデア出しワークショップを開いたことのふりかえりから。ワークショップ内で発散まではまあどうとでもなるとして、収束させることがそのときの自分の引き出しではできなくて、結局ワークショップ内では発散しっぱなしで諦めました。で、そのことを某関西弁のパイセンコーチに壁打ちしたら、「デザインスプリントにアイデアがあるかもね」というありがたい言葉をいただいたので。
というわけで、今回はDay 3の「決定」を一番中心に読みました。言い換えると、「この本を読んだ後に、例のワークショップを開催するとしたら、どこをどう改善するだろうか?」というのを考えながら。
デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド
- 作者: Richard Banfield,C. Todd Lombardo,Trace Wax,安藤幸央,佐藤伸哉,牧野聡
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/11/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
ちな、以前下記のスライドは目を通してました。なので、デザインスプリントとは何?ってのをざっくり知ってるけど、実体験として理解はできていないレベルです。
www.slideshare.net
www.slideshare.net
決定に関わること
Day 3 決定:チームでのスケッチ作成
この作業のサイクルを複数回繰り返す時間はないことが多いでしょう。したがって、ユーザージャーニーマップを分割してチームごとにそれぞれ異なる部分を作業してもらいましょう。そして、最後にそれぞれのチームからフィードバックをまとめることで時間短縮が可能です。
ここが一番知りたかったところ。一気に全員で全範囲を収束の議論するのではなくて、分割した上でそれぞれを3~5名程度のグループ単位に割り当てていくわけね。その切り口の一つとして、ユーザージャーニーマップごとに分割するとか。
なるほどー。時間の問題もあったんだけど、一番のネックって思ってたのは、人数が多い状態(6名以上を想定)で収束の議論が難しいそうだなと感じてたんでした。それは、分割して議論の人数を絞った上でそれぞれで議論すればいいのか。もちろん、一人が全部をがっつり見ることはできなくはなるけど、それは各グループの結論を信頼して任せる感じ。
Day 2:発散でも似たように、分割してやってるところがあった。発散を複数回繰り返すときに、一気に全部を考えると、2回目以降同じ範囲を考えても同じアイデアしか出てこないんじゃないかなーと思ってました。けどこれも一緒で、1回目はジャーニーマップの前半で、2回目はジャーニーマップの後半とかやると、考える範囲が違うので、複数回してもよさげ。
Day 3 決定:最終スケッチの作成
「選択肢を2つか3つにまで収束できたなら」的な説明がありました。収束となると、この辺が現実的かなとは感じてます。
10も20もアイデア出てきても、全部を実装できるほど僕らの人生は長くないし、ましてや作りっぱなしではなく検証まで含めるのならばなおさら。なので、もう数個に絞る。どれぐらいに絞るかは、プロジェクトの予算やスケジュール感にもよるかな。
決定に関わらないけど、心に残ったもの
Day 1 理解:アイスブレイク
- ここだけの話ですが、実は…
- 自己紹介に続けて、参加している他の参加者が誰も知らないと思われるちょっとした秘密を話してもらう。
- 希望と心配
- 2色のポストイットに、それぞれ希望・心配事を書いてもらう。で、それを匿名状態で集めて、任意に一枚ずつ選んで書いた人以外がその意味を推測しながら説明していく。このことによって、他の参加者の共感を持てるようになる。
前者の「ここだけの話ですが、実は…」の派生として、ワークショップで取り上げようとしてる内容に関してのことだと、より味わい出そう。あとは、少人数(1~3名)のみ知ってるとかだと、あまりにもニッチな領域じゃないところを狙いに行きたくなって少しゲーム要素も出そうでよさげ。
後者の「希望と心配」は、単に自己紹介で終わるのではなく、自分以外の誰かのことを考えるってのがよさそうと感じました。ドラッカー風エクササイズの「期待されてると思うこと」と派生の「相手に期待すること」でもそうだけど、他の人の立場で考える機会ってなかなかないけどチーム力を高める上で大事なことだと思ってるので。
Day 1 理解:課題の定義
また、モバイルデジタルプロダクトの1つだったAndroid携帯をFacebook携帯に帰るFacebook Homeを使ったことがある人もいるでしょう。結局我々はFacebook Homeを使いませんでした。このアプリにはまったく使う意義を感じられません。「ユーザーを自社アプリに囲い込む」というFacebookにとっての課題は解決されたのかもしれませんが、ユーザーにとっての本当の課題やニーズにはまったく考慮されていません。
Facebookのとあるプロダクトを例にあげられてて、ぐさっときました。あまり聞いたことないプロダクトの失敗事例を聞いてもぴんとこないところもあったけど、Facebookでさえもそういうことあるという(実際にFacebook Homeなんて知らなかった)。
自分たちに都合のいい解釈で、「自分たちのビジネス的にこうなるといいな」からの「これ作れば使ってくれるだろう」っていう流れに陥らないように、↑の説明文に続いて述べられてた↓の文も合わせて。
ユーザーや顧客のためではなく、自社にとっての課題を解決するためにデザインスプリントを行おうとしている企業は今も多数見受けられます。
Day 1 理解:HEART Framework & Goals-Signals-Metrics
「UX のゴールやメトリクスを設定するときには HEART Framework と Goals-Signals-Metrics プロセスが使いやすい」という触れ込み。ちらっと見ただけだけど、確かによさげ。頭の片隅に入れておこう。
Day 2 発散:ストーリーボード
絵コンテとも。テキストだけより絵も含めて書いた方がより記憶に定着するだろうし、複数のコマで表現されてるとインタラクションがイメージしやすい。これも、アイデアを表現するフォーマットの一つとして、引き出しに入れておこう。
ストーリーボードの説明は、よさげなサイトがあったので、そちらにおまかせ。
Day 5 テスト:プロトタイプの評価 - よく起こること:辞退者が出た
我々は辞退者の発生を見込んで、7,8 人にインタビューを行うようにしています。そうすれば、辞退者がいても最低でも5,6人からフィードバックを得られます。
いい目安。とりあえずメモだけ。
やっぱり、実際にやること・やったことと照らし合わせて読むと、理解度とかも違いますね。自分が知りたかったことが知れた(収束に至るまでのやり方)のもよかったし、それ以外でもいくつか引き出しができた。今後デザインスプリント自体をがっつりやるかはさておき、一つレベルアップできたんじゃないかな。
「エッセンシャルスクラム」を読みました
だいぶぶりの読書感想ブログ。ノルマ的にこなしていかんと、なかなか進まないなあ。いつも言ってる気がするけど。
ということで、これも今更ながらの名著です。実際には、スクラムガイド2017での変更点の紹介 | Ryuzee.comやスクラムで削除された5つのトピック | Ryuzee.comのように、スクラムガイドも細かく更新されています。が、本質的なところはそう変わってないはずなので、ちゃんと読んでおくべきだと判断しました。
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
- 作者: Kenneth Rubin,岡澤裕二,角征典,高木正弘,和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2014/07/08
- メディア: 大型本
- この商品を含むブログ (7件) を見る
第1章 イントロダクション
クネビンフレームワーク。開発プロセスの提案をすることもときどき出てきた立場として、アジャイルプロセスを適用するかどうかの最初の指針になるもので、盲目的にアジャイルでいくんだーとなる前に考えていいところ。まあ、最近のソフトウェア開発は、大体は複雑な領域に相当するので、それをうまくやっていくためのアジャイルな開発プロセスがマッチするというのはそうなんでしょうけど。
ちなみに、クネビンフレームワークを改めて調べ直して、カオスな領域での適切なふるまいを勘違いしてたことに気づきました。カオスな領域だと、まずはカオスを脱出するために、強力なリーダーシップのもとにコマンド&コントロールで進めるべきみたいですね。例として挙げられてたのは、9.11 のテロ事件とか。確かに、テロ真っ最中のときに悠長に検査・適応してから進もうってのは苦しい。
と考えると、ソフトウェア開発でカオスな状況って、よっぽどのことですね。本の中では、自分たちのサービスのバグによって不利益をこうむった顧客から、今まさに巨額な訴訟を受けよう最中というのが挙げられてました。
第3章 アジャイルの原則
ここではやっぱり「3.5 仕掛中の作業(WIP)」ですよね。
- 作業は経済的に妥当なサイズにまとめよ
- 在庫を認識し、適切な流れで管理せよ
- 作業者の手待ちではなく、作業の手待ちに着目せよ
- 遅延コストを考慮せよ
この辺は、カンバンの原則にもまんま通じるところがあると思ってます。詳しくは、以前発表した資料を。
第5章 要件とユーザーストーリー
ここは目新しい項目はなかったのだけど、今まで学んできたことを再度確認した章。そうだよね〜とか、あーこれはどうだったっけ?って調べながら、読み進めていきました。キーワード的にはこの辺。
- ユーザーストーリー・エピック・テーマ
- INVEST
- 非機能要件
- 学習のためのストーリー(スパイク)
- ユーザーストーリーマッピング
第7章 見積もりとベロシティ
すでに本書の時点で、ストーリーのサイズ見積もりをしない話がでてました*1。
スクラムを実践している人たちの中には、PBIのサイズ見積もりを必須ではないと考えている人もいる。経験上、成熟したスクラムチームなら、すべてのPBIを同程度のサイズにまとめられると知っているからだ。彼らは、同程度の小さいサイズにまとめられたPBIを前にして見積もりをするのは、時間のムダだと考えている。そんなことをしなくても、単にPBIの和を数えれば、それで十分だというわけだ。
ケースバイケースとは思いつつも、↓の理由から作者はPBIを見積もりたい派で、自分も同じだなー。少なくとも今は。
- 第5章で説明したとおり、すべてのPBIが同時に同じサイズになるわけではない。たとえすべてのPBIのサイズを小さめに揃えることを目指していても、バックログの中には大きめのPBIがいくつか残る。
- チームのメンバーがPBIのサイズを同程度にまとめられるようになるには、それなりに時間がかかる。
- 同じサイズにすることが目的になってしまい、不自然なところでストーリーを分割せざるを得なくなるかもしれない。
- いちばん大切なことだが、見積もりの最大の目的は、話し合う家庭でいろいろな気付きが得られるということだ。何かに対して数字を付けてくれと頼んだりするだけでは、健全な議論が生まれない。意見の相違は見えなくなるだろうし、思い込みがあったとしても表には出てこなくなる。見積もりをやめてしまうのなら、健全な議論をうながすための何らかの手を他に探す必要がある。
この辺も思い出したので、参考がてらはっておこう。
第8章 技術的負債
今自分の中でホットな話題w どういうものかはある程度感覚としてあるので、主にどういう風に解決していくべきか?という視点で読んでました。その中であがったのが、以下の2節。
- 技術的負債の可視化
- 技術的負債の返済
技術的負債の可視化
可視化については、ビジネスレベル / 技術者レベルでの可視化があるとのこと。ビジネスレベルではベロシティへの影響を与えるかどうかで考えるのが分かりやすそう。ベロシティが半分になれば、倍の作業コストなり遅延コストがかかるよねという感じで。
技術者レベルでの可視化については、障害管理システム / プロダクトバックログで障害を扱う / 技術的負債バックログの3つがあげられてました。それぞれ、負債の量が少ない順という感じかな。負債がすくなければ、不具合と同じレベルで障害管理システムに突っ込んでおくぐらいでいいし、もうちょい大きいものならばPBIとしてプロダクトバックログにつっこむ。負債が多い場合は、それ専用のバックログを用いて、かつそれをちゃんとスプリントプランニングで考える必要がある(けど、管理だけして忘れがち。。。)
技術的負債の返済
返済の手法で気になったのは、以下の3つかな。
- ボーイスカウトルールに従う(負債を見つけたらその場で返済する)
- 技術的負債の返済はインクリメンタルに
- 技術的負債を返済しながら顧客に価値をもたらす作業も行う
ボーイスカウトルールは好きなんだけど、無制限にその場で返済し続けるわけにもいかないですよね。一定の割合に収めるというのが大事そう。
残り2つは、一括返済じゃなくて徐々に返済していこうという話。一括は考えやすいんだけど、それは問題を先送りにして楽な方に逃げてたつけなのかもですね。ご利用は計画的に。
「技術的負債返済スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。(中略)私に言わせればそれは大量の負債を一気に支払うということだ。実際のところ、そんなコメントが出てくるというのは、技術的負債がそんなにふくれあがるまで負債の削減など気にしていなかった証に他ならない。
↑の「技術的負債バックログ」と合わせた手法も紹介されてました。こういうのもよさそう。
第9章 プロダクトオーナー
だんだん疲れてきたのでw、後から参考にできるように、ここでは最低限の表だけで。
開発の種類 | プロダクトオーナーの候補 |
---|---|
社内開発 | そのソリューションによって恩恵を受けるビジネスエリアの代表や顧客 |
商用開発 | 実際の顧客やユーザーの組織内プロキシ(プロダクトマネージャー、プロダクトマーケッター、プロジェクトマネージャーなど) |
外部委託開発 | そのソリューションに支払い、恩恵を受ける会社の代表や顧客 |
コンポーネントチーム | 技術的なバックログの優先順位をうまく受けられる技術者 |
最後のコンポーネントチームだけは、ちょっと疑問に思った。コンポーネントチームを作るのは、悪手だと思ってるので。コンポーネントチームはそれ単体ではユーザーに価値を出さないし、コンポーネントを利用するフィーチャーチームからすると外部のコンポーネントチームに依存するので、クロスファンクショナルにならなさそう。
というのを、第12章の「12.2 フィーチャーチームかコンポーネントチームか」に書いてあった。
第10章 スクラムマスター
「1日の様子」が面白かった。スクラムマスターのやることとして、下記のようなアクティビティがある。
- インペディメントの除去
- コミュニケーション
- チェンジエージェント
- プロダクトオーナーの支援
- チームのコーチ
- スクラムのアクティビティ
スプリントの最初と最後はスクラムのアクティビティ(スプリントプランニングやレビューなど)が占めるのはそのとおりだけど、それ以外の日は5割ぐらいインペディメントの除去に費やされてた。まあそうだよね。
第11章 開発チーム
ここでは、開発チームの特性かな。「よりいいチームになるために、どこを頑張っていけばいいと思う?」みたいな問いかけのときに、こういうのを思い返してもよさそう。
- 自己組織化
- 機能横断的な多様性と十分な能力
- T型スキル
- 銃士の姿勢
- 広帯域のコミュニケーション
- 透明なコミュニケーション
- 適切な規模
- 集中とコミットメント
- 持続可能なペースで仕事する
- 長寿
第12章 スクラムチームの構成
「12.3 複数チーム間での調整」で、スクラムオブスクラム・リリーストレインという2つの手法が紹介されてましたが、後者の方に興味をひかれました。ちょいちょい見たことはあったのですが、SAFeでも定義されてたんですね。SAFeはほとんど知らないのですが、いつかちゃんと見ておきたい。今の自分の立ち位置だと直接関わることはほぼなさそうですが。
第13章 マネージャー
マネージャーの責務として、一番根幹だと思うものを一つだけ取り上げておこう。
境界を定める
- マネージャーが、プロダクトやプロジェクト(砂場)を定める
- マネージャーが、チームの構成を決める(誰をどの砂場で遊ばせるかを決める)
- チームは、それぞれの砂場の中で自己管理する
第15章 さまざまなレベルでのプランニング
プランニングのレベル。スクラムで主に意識するのは、リリース・スプリント・デイリーぐらいまでだろうけど、プロダクトやポートフォリオ*2もあるよと共通言語を持っていると、話が早いだろうなとは思った。例えば、いまのうちの会社に照らし合わせると、ポートフォリオプランニングはあれで、プロダクトプランニングはロードマップ含めたあの辺かなという感じ。
レベル | 範囲 | 誰が作るか | 何を対象にするか | 成果物 |
---|---|---|---|---|
ポートフォリオ | おそらく年単位 | ステークホルダーとプロダクトオーナー | プロダクトのポートフォリオの管理 | ポートフォリオバックログ、そして仕掛中のプロダクト群 |
プロダクト | 数ヶ月単位か、あるいはもっと長期 | プロダクトオーナー、ステークホルダー | ビジョン、そしてプロダクトの成長 | プロダクトのビジョン、ロードマップ、そして概要レベルのフィーチャー群 |
リリース | 3ヶ月から9ヶ月程度 | スクラムチーム全体、ステークホルダー | 顧客に届ける価値と全体的な品質について、スコープやスケジュールそして予算などの制約の範囲で継続的にバランスを取る | リリースプラン |
スプリント | イテレーションごと(1週間から1ヶ月) | スクラムチーム全体 | 次のスプリントでどのフィーチャーを出荷するか | スプリントゴール、そしてスプリントバックログ |
デイリー | 毎日 | スクラムマスター、開発チーム | コミットしたフィーチャーをいかに完成させるか | 進捗確認、そしてその日の作業をうまく進めていくための調整 |
第16章 ポートフォリオプランニング
この章からは、やっぱ遅延コストかな。よさげな概念だとは思うんだけど、まだ理解しきれていない。次かその次に感想ブログあげる予定のリーンエンタープライズでも出てきてるので、そっちも合わせて考えてみよう。
なお、ポートフォリオレベルでのプランニングとは言ってるけど、別にポートフォリオに限らずプロダクトレベルやリリースレベル以下でも十分に適用できる内容も多かったです。上記の遅延コストもそうですし、小さなリリースとか、WIPの制限、作業者の手待ちじゃなくて作業の手待ちとかとか。
第23章 未来へ
「23.4 スクラムを使って、進むべき道を探し出せ」がよかった。スクラムを広げる際、まずは少数のチームから始めて次に組織全体に広げていくことになったお話。全体に広げるときにやるべきことをバックログとして管理して、3週間のスプリントで見直しながら取り組んでいったというお話。開発じゃなくても物事を進めるときのフレームワークとしてスクラム(のエッセンス)を使うのもよさそうです。
最後に小ネタですが、高校の合唱コンクールでキロロの「未来へ」をピアノ伴奏しました。男の人がピアノ弾くと、映えるのでオススメです♪
スクラム自体というより、スクラムをうまくやるための周辺の考え方やツールなどが役に立ちました。スクラムのルール自体は、スクラムガイドで分かるしね。
ちなみに、ブログ書くときは再度読み直すのでこれも2周目なのですが、今回はいつにもまして以前読んだことをまったく覚えていない。。。まあ、だからこそ改めて読み直す意義があるのでしょうが。