00:03
はい、9月7日、金曜日ですね。はい、時刻は朝9時を回りました。
えーっと、今日の僕はですね、若干の2日酔いでですね、昨日ちょっと楽しい飲み会があったので、そこで美味しいお酒いっぱい飲めたのでよかったんですけど、飲みすぎました。
で、今ちょっと頭痛い中やるので、いつも以上にちょっとグダグダ、ダラダラだかもしれないですけどお願いします。
はい、夢見のけーすかの桑原です。では、本日も朝活を始めていきたいかなと思います。
で、えーっと今日はですね、まあタイトルがありますけれど、「Why we transitioned from Sprints to Basecamp’s “Shape Up”methodology 」ですね、っていう記事を読んでいこうと思います。
はい、まあまあいわゆるなんかチームビルディングとか、まあスクラム的な確か文脈のお話だったと記憶してますけど、はい。
まあ気になったというか、タイトル的にも気になったし、内容的にも、多分おそらく面白いだろうというのを期待ができそうだったので、読んでいこうかなと思った次第になります。
はい、では早速入っていきましょう。今日の、えーっと、筆者の方ですね、この記事の筆者の方は、VP of Product at SafeSiteっていう会社のVP of Productの方だそうですね。
VP of Productっていうポジションがあるっていうのが、なかなか面白いなと思いました。はい。
じゃあ早速入っていきましょう。
えー、ちょっと外音がうるさいですね。
えー、2週間のスプリントがうまくいかなかったらしいですね、この方としては。はい。
Let's Keep Itって書いてますけど。
えー、2週間のスプリントがうまくいかなかったとにかく、つまりそれなりの速度で製品を出荷していたのですけど、プロセスに亀裂が入ってしまったのです。
で、特に、えー、超成長期か、はい。3900万ドルのシリーズBを調達してしたときには、ユーザーとビジネスにとって最もインパクトのある機能を出荷するためのより良い方法があるはずだというふうに考えていたよっていうお話です。
まあ、これが冒頭のお話ですね、背景がそうなったというのです。
まあ、ちなみにシリーズBの資金調達をしたときの記事とかのリンクも貼られてますので、まあ興味ある人は見てみてくださいということでした。
はい。で、えーと、今この冒頭の、あのー、概要と言うか、挨拶のところで、えー、下にちょっと画像というか、まあ動画が貼られてるんですけど、これは多分アメフトかな?のフィールドで、なんか2人の男がずーっと走って、で、片方の人がずっこけるみたいな動画がありますね。
なかなか見てて面白いんですけど。
はい。で、まあそれ、まあ多分その動画が意味してるのは本当に僕らとしては上手くいくだろうと思ってて、あのー、走り始めたんですけど、その失敗したっていうところですね。
というところだと思います。
はい。ではなぜ2週間スプリントが上手くいかなかったのでしょうかと、いうところに入りますが、これまでのスプリントプロセスを見直すことにした理由はいくつかありますが、主なものは以下の通りです。
で、合計4つぐらいありますね。
えー、いきますけど、1つ目が、まあ大きなプロジェクトは常に追加スプリントと、まあ重なっていたと。
03:01
はい。別の追加になってしまったスプリントと、まあ重なってしまったと。
が1つ目。で、2点目は、スプリントが連続するため、プロセスそのものを一時停止して見直し、えー、改善する時間というのがほとんどなかったと。
あー、なるほど。まあありがちというか。
よく見るケースな気もしますけどね、これはね。
はい。で、3つ目ですね。
3つ目は、プロダクトチームはお客様を理解し、次に何を作るべきなのかを検証する代わりに、今作られているもの、まあチケットモンキーですね。
と言ったりしますけどね。
多くの時間を費やしてしまいましたと。はい。
まあまあ、これも仕方ない面はありますね。
なんだかその辺はちゃんとスクラムマスターが、とか、まあプロダクトオーナーでもいいですけど。
えー、その辺をうまいことコントロールできればよかったんでしょうけど。
まあ現場の開発チームとしてはやっぱりチケットモンキーになりがちなのでね、仕方ない面はあると思います。
とにかく今やるべきことなんだろうというところで、実際手を浮かすのはやっぱり開発チームにはなるので、
開発チームがその今の目の前にあるものを、えー、何とかこなす、こな、えー、終わらせていくっていうところに注力するのは仕方なくて、
まあその辺のコントロールを、スクラムマスターかプロダクトオーナーがやるのが本当はいいと思いましたけど。
まあそれができなかったってことらしいですね。
まあやってるつもりだったけど、結果的に言うとそのチケットモンキーに多くの時間を費やしてしまったという結果で、
2週間スプリントを受けたんだろうなっていうところはあると思いますね。
はい。で、ラスト4つ目ですね。4つ目は、私たちは急速に成長しており、スケーラビリがすごく重要だったっていうところですね。
はい。っていうのがまあ、2週間スプリントがうまくいかなかったっていう大きな4つの理由だったそうですね。
まあまあまあ難しいところですね。スプリントを2週間って、僕あんまりうまくいくようなイメージが実はないんですよね。
まあなんか1週間で細かく区切るのが僕は好きなんですけど、細かすぎたり確認だったりミーティングの数が増えたりするのは果たしてどうなのっていうのもあるので、
まあ2週間にするっていうのもよくある話だと思いますけど。
えてして2週間って大きくすると、2週間もあるといろんな物事が変化したりとか、いろんなイベントが発生するので、僕としてはあまりよくない気はしてますけどね。
まあ感覚違いで喋ってます、これは。はい。
じゃあすいません。余談から戻りまして。
なぜスプリントを長くしないのかというところですね。
はい。あ、逆なんだ。もっと長くすればよかったってことですか。2週間だと短かったのかな。
私たちはスプリントを4週間に延長することでいくつかの問題は解決すると考えていましたが、思うようにはいきませんでした。
なるほど、逆ですね。長くしたら失敗してしまったと。
特に開発チームやプロダクトチームが今だけに集中することで、そのポテンシャルを十分に発揮できていないことが分かっていました。
今だけでなく、次やその先に何があるのかっていうのも考えて、顧客やビジネスニーズにこだわり、その学びを検証した上で構築するチームが必要だという風に考えていましたと。
後半の方はその通りだと思いますけどもね。
だと考えていましたという過去形なので、何か違うのかもしれないですね。
06:04
スプリント4週間はもう何か意味わかんないですよね。4週間ってほぼ丸々1ヶ月なんで、それもスプリントじゃなくない感はあります。
いわゆるマイルストーンという言葉に切り替えて区切っていくっていうのは別にいいと思いますけど、
スプリントでやる意味で言えば、4週間は僕の中ではもう完全に機能しなさそうな印象しかないですね。
あんまりそんな事例を聞いたことはないです。4週間スプリントなんていうのは。
なのでスプリントを長くするのは悪臭な気はしました。
で、続いて。
How did we end up with ShapeUp?
ShapeUpを導入することになった経緯は?というところですね、次は。
シェイプアップっていうのはなんだっけ。タイトルがありますけど、ベースキャンプのシェイプアップメソドロジーっていうのがあるらしくて、
それを使ったっていうのがこの記事のタイトルなんで、その理由がここから出てくるんでしょうね。
シェイプアップを導入するに至った経緯ですけども、これを導入するのは簡単なことではありませんでしたと。
私たちは何がうまくいき、何がうまくいかなかった、何を学んだか、何が私たちのチームにとって理想的かについて率直な話し合いを重ねましたと。
どのプロセスも全てのチームのためにあるわけではないということを忘れないでください。
あなたのチームの罪は何でしょうか。もっとうまくやる必要があるのはどんなことですか。
数週間ごとに振り返りを行うことが成長の鍵となりますと。
私たちの場合、ストーリーポイントやスループットメトリクスのようなフレームワークによる小森を必要としない強力でモチベーションの高い開発チームが強みの一つであるということが分かっていましたと。
プロダクトチームの強みは問題を発見して深く掘り下げること、目標に対して超優先順位をつけること。
なぜか超がつきますね。
あ、でも原文がhyperpriorizingって書いてあるから。
プライオライジング?プリオリティシングか。はい、すみません。
ハイパーがついているので超がつくんでしょうね。
超優先順位をつけること、ユーザーやステックホルダーを完全に理解するための徹底的なリサーチというのがこのプロダクトチームの強みだったということですね。
で、プロセスレビューのミーティングをしているときに、新入社員、現エンジニアリングの部門長だそうですね、今は。
その当時新入社員だった方が、シェイプアップ、いわゆるサークルで走るのをやめて重要な仕事をしようというふうに提案をしたそうですね。
シェイプアップってそういうものなんですね。サークルで走るんじゃなくて重要な仕事をするというような話なんですね。
これの記事がリンクを貼られていまして、さらにこれは無料で読めるので皆さんも興味ある人は読んでみてくださいということでした。
これを読み、さらに詳しく議論したところ、グループとして巧妙を見出すことができましたと。
シェイプアップでは私たちが抱えていた問題の多くが浮き彫りにされ、その大半について私たちの強みに沿った解決策というのが結構提示されていましたよということですね。
09:05
ちょっと、僕はシェイプアップっていうのは実はこの記事見て初めて知ったので、なんか気になりますね。読んでみたくなりましたけど。
リンク先は記事のリンクではなくて、これは完全に書籍っぽいかな。
バイザープリントエディションって書いてあったりするんですけど、ダウンロードPDFもあるのでそこから読むこともできるようですね。
ちゃんと書籍でPDFで今僕ダウンロードしてみたんですけど、大体ページ数にして176ページあるんですけど、後半の方はアペンディックスなので、ちゃんとした内容としては153ページありますね。
いやーボリューミーだな。しかし、かなり良さそうに見えますね。
まあ、目次だけバーッと見てるんですけど、目次の内容だけでも割とチームとかスプリントだったりとか、開発工程だったりとかっていうのをこと細かにカテゴライズされて語られているので、これは素晴らしいな、多分。
ちょっとこれ読みたいです。しかもこれ無料で読めるので、朝勝内で読んでも全然問題なさそうですね。ただ、150何ページもあるので朝勝で読むには何日分読むんやねんって感じがするので、ちょっと用を検討します。
一旦本部に戻ります。
これを読んで、いわゆる我々のチームの課題点というのがバンバン浮き彫りになったようなところでした。
これは良い話ですね。
続いてのセクションで、形状は6週間周期で構成されている。形状って言うとあれですけど、いわゆるシェイプですね。シェイプは6週間の周期で構成されていることでした。
仕事っていうのは6週間をワンサイクルとして行うようにします。これがそのシェイプアップのやり方だそうですね。
6週間という期間は最初から最後まで有意義なものを作り上げるには十分な長さですけれども、全員が最初から締め切りが迫っていることを感じ、賢く時間を使うには十分な短さだとします。
はいはい、なるほどね。
深い、深いじゃないですね。俯瞰視点で物事を考えるんだったら6週間という期間は最初から最後まで有意義なもので行くと十分な長さというふうに感じますけど、
実際に具体的に開発を行うメンバーですかね、現場の人たちからすると6週間というのは意外と短く迫っているというような感覚になるんでしょうね。
これはその通りだともちろん思いますけど。
もっともっとより良くしたりとか、より良い設計開発がするためには十分には短いだろうなという感じはしますけどね。
目標は6週間のサイクルの中でビルド、QA、リリースというのを行うことがやっぱり目標になります。
私たちの決断は時間を細かく管理するのではなく、6週間後に製品を前進させることだけに基づくべきですと、私たちは自分自身にこう言い聞かせます。
このプロジェクトが6週間後に出荷されれば本当に幸せだと、このプロジェクトが6週間後に出荷されれば本当に嬉しいというふうに自分自身に言い聞かせたということですね。
12:09
そして6週間をコミットし、チームには邪魔が入らないように独占的に仕事をさせるんですねということですね。
これも結構重要ですよね。外部要員がバンバンバンバン入ってくると、スプリントとか自分の目の前のタスクに集中できなかったりするんで、
そこをしっかり遮断して僕らは僕らだけでしっかりやっていくというところの環境を作るのは大事なことだと思いました。
続いて、シェイプアップと構築というデュアルトラックの話が続いてきます。
アジャイルプロセスでは大規模な作業をスプリントサイズの小さな塊に分解して構築を開始しますが、
シェイプアップでは作業の塊を顧客にリリースする時期を固定し、その時期に作業をシェイプアップすることに焦点を当てます。
チームは複数の仕事を同時にこなすことを求められず、代わりに一つのプロジェクトに群がり完成まで全力尽くすことが求められます。
これは本来のアジャイル的な進め方というか、プロセスだというふうに感じますけどね。
6週間のサイクルの間、チームは既にシェイピングされた作品を作り、
シェイパー、私たちの場合はプロダクトマネージャーとデザイナーというふうに言ってますね。
チームが将来のサイクルで作る可能性のある作品に取り組みをします。
なるほどね。
シェイピングというところが結構ポイントになりそうですね。
名前にもシェイプアップってありますからね。
それについては具体的に仲の人たちでサイクルを回しながらやっていくということですね。
僕はシェイプアップをどんなことをやるのかわかってないので、ここがやっぱりその味噌であるんですけど、
ここがわかるともうちょっとこの記事もイメージしやすいんでしょうね。
本当はさっき言ったシェイプアップの書籍を読んでからこの記事を読むといいんだろうなと思いましたけど、
今回はこのまま入ります。
2トラックスのところですね。
もう少し具体的に説明しますけど、
2トラックスウェンインサイクル6ウィークですね。
6週間のインサイクル中は2トラックでありますよということで、
1つはビルディング、1つはシェイピングということですね。
ビルディングの方は承認されたピッチでの作業を中断することなどをやることです。
シェイピングの方は次のサイクルのための要件を収集することですというところですね。
一応図があってですね、
簡単な2つのサイクルがあるんですけど、
アウトオブサイクルとインサイクルという2つの軸があってですね、
アウトオブサイクルの方でいろんなものをシェイプして、
そしたらインサイクルの方でビルドをしますと。
それから6週間続いたら、
6週間中にビルドもするんですけど、
次のシェイプをまたしますと。
で、次2週間でベッドをしますということですね。
で、インサイクルの方はクールダウン中ですということです。
で、そのベッドしたものがまた次のビルドにつながっていく。
で、そのビルドを6週間中にシェイプも行っていって、
シェイプが終わったらまた2週間ベッドをしていって、
そのベッドするものをまたビルドをしていくということですね。
15:03
いわゆるチケットをまた起こし直したりとか見直しをして、
そこから次の6週スプリントの段階で何をやるかっていうのをベッドして、
それから実際に実行をビルドしていくということでしょうね。
で、ビルドする中でもまた月のサイクルのためにシェイプをするということで、
そのシェイプでチケット化をするということでしょうね。
こういうサイクルを回していくよってことでした。
これは今音読はしてますけどイメージしづらいので、
多分見てもらうのがいいと思います。
100分は1件にしかあると思うので。
もちろん後ほどこの記事のリンクをツイートします。
と言っておいても、俺昨日朝勝のツイートしましたっけ?
覚えてないですけど。やってなかったらごめんなさい。
ちょっと後で確認しますけど。
ではそのまま記事続きますね。
続いてピッチのシェイピングっていうセクションに入ります。
シェイピングのニュアンスについては記事全体を費やすことは容易ですけど、
基本的にはチームが将来のサイクルで構築する可能性のあるものについて、
ピッチと呼ばれる文書で製品要求を収集することです。
よくやるチケットというものではなくて、
まずピッチと呼ばれるもので収集するんですね。
ここでのキーワードは、
かもしれないですっていうところが重要らしいですね。
英語単語的にはmightって書いてますね。
なんとかかもしれないっていうところで一回収集をしようと。
ビジネスと製品の優先順位が変われば、
何を作るかっていうのの決定も変わります。
シェイピングトラックでの作業は非公開とされ、
それにかける、ベッドすることが決定されるまで、
より広い組織で共有されることはまずないと言ってました。
ちなみに資水ベッディングっていうのがあるので、
ベッディングの章を参照してくださいということですね。
この章はおそらくさっきのドキュメントというか、
書籍の中のベッディングっていう章を見てくださいということだと思います。
シェイピングチームの構成はあなた次第ではなりますけど、
一般的にはプロダクトマネージャーが率いて、
関連するステークホルダー、デザインだったり、
カスタマーエクスペリエンスだったり、エンジニアリングなどなど、
ステークホルダーがピッチに関する知識を持つ可能性がある場合は、
それに加わっていくと。
基本的にはそういう感じですね。
シェイピングチームは一般的にはプロダクトマネージャーが率いて、
関連するステークホルダーがそのピッチに関する知識を持つ可能性がある場合は、
それに加わります。
シェイピングの主な目的は、ソリューションを起草する前に、
問題を深く理解することだと言っています。
オーディエンス、ユーザーとかステークホルダーを理解し、
問題やユーザーをより理解するために役立つあらゆるインサイト、
訂正的または定量的なインサイトを把握することになります。
えー、なるほどね。
認識とか理解というところに重きを置いたフレームワークかな、これは。
ピッチの材料というのは以下の通りです。
いっぱいあるんですけど、ざっといきますと、
プログラムステートメントとオーディエンス、インサイト、アペタイト、
あとは解決策ですかね。
18:01
ラビットホール、アウトオブスコープ、禁止事項ですね。
あとは成功のというところです。
それぞれの項目については、そのシェイプアップ、
ピッチの書き方というものですね。
の第6章を読むことを強くお勧めします。
これはさっきのドキュメントのチャプター6ですね。
に、ライティング・ザ・ピッチという項目があるので、
そこも見てみてくださいということでした。
これを読まないと、
ピッチの材料は以下の通りですと言われています。
しかわからなかったですね。
今回の記事はそれが前提な記事だなというのがあるので、
ざっくりとしか理解できない気がしますが、
このまま走り続けていきましょうかね。
続いてビルディング・ピッチですね。
さっきシェイピング・ピッチをしたので、次はビルディング・ピッチですね。
ピッチが別途されたら、
次の最後の6週間のビルドサイクルの中で、
ビルドしてリリースすることをコミットします。
PMの仕事というのは、ただタスクを割り当てることじゃないよと。
そういうPMさんいらっしゃいますよね。
プロジェクトマネージャーさん。
なんですかね。名前出てこない。
プロ岸おじさんになってしまうPMの方とかいらっしゃいますけど、
本来のPMの仕事はプロ岸ではないですからね。
プロ岸はあくまで仕事の一部でしかないので、
そういう人もいらっしゃいますよね。
ただただタスクを割り当てることではなくて、
タスクマスターだったり、プロダクトオーナーのように、
プロジェクトを分割して他の人に実行させるような役割を担う人もいません。
そして開発者というのは、もはやチケットテイカーやコードモンキーとして扱われることはありません。
プロジェクトをタスクに分割することは、
ピッチをシュレッダーにかけるようなものになります。
すべてのピースがどのように組み合わせるかを判断する責任を負うことなく、
誰もがバラバラのピースを手にするだけだと言っていますね。
シェイクアップの基本方針というのは、
プロジェクトが全家庭において全体であることを望むことで、
全体像を見失うことは決してありません。
プロジェクト全体を引き受け、ピッチの境界の中で作業するようチームを信頼してください。
境界の設定とかアペタイターというのがあるので、その辺を参照してください。
チームは自分たちのタスクと仕事へのアプローチを定義することになります。
彼らは完全な自立性を持ち、自分たちの判断でできる限りピッチを実行します。
プロジェクトは通常チームに全体の面倒を見える責任を持たせることで、
より良い結果を得ることができます。
うーん、なるほどですね。
ちょっとやっぱり読んでないから、コンテキストもわからんまま読んだ感想を述べると、
各それぞれにしっかり責務と権限を渡しつつ、
ジョブディスクリプションをチームごとにしっかり分割をして、
それぞれ独自に動けるようにするとはいえ、
みんなにちゃんと全体感を持たせていて、
相互作用というところも考えながら物事を進めていくというところが重要なんだろうなと思いました。
21:01
プロジェクトの開始時には、すべてのピースが適切に組み合わされるために、
何が必要なのか誰も予測することはできません。
最初の数日の仕事は仕事らしくないかもしれません。
誰もタスクのチェックをしなかったり、成果物を見ることもなかったり、
最初の数日間はチーム間のコミュニケーションがあまりないことが多いでしょうと言っています。
なぜなら、各自が既存のシステムがどのように機能するのか、
またどの指定に立つのがベストなのかを理解しようと頭を抱えるからです。
誰もが土地観を身につけ方向性を定めるのに精一杯になるから、
そういうチーム間相互作用や成果物の話はなかなかできないと言っています。
これも仕方ないですよね。スタートというときはそういうものだと思います。
マネージャーはこの段階を尊重することが重要です。
これは必要なフェーズなんですね。
チームはこのコードベースに飛び込んで、すぐに新しい機能を構築し始めることはできません。
関連するコードに精通し、ピッチを考え、質問を投げかけ、
出発点を見つけるためにいくつかの行き止まりを経験する必要があります。
これいいですね。この観点はすごく重要だと思いました。
あまりに早い段階で鑑賞したりとか状況を聞いたりすると、プロジェクトに支障をきたしたりします。
チームが最適なアプローチを見つけるために必要な時間を奪ってしまうからです。
目に見える進捗を求めると、それが地下に潜るだけになってしまいます。
それよりもどうすればいいかまだ考えるところですと、
はっきり言えるような権限をチームに与える方が、
まだこの正当な仕事を隠したり、起訴したりする必要がなくなるので、
お勧めですよというふうに言っていますね。
なかなかいい話だな本当に。
シェイプアップのもう一つの優れたコンセプトは、
仕事を坂道に見立てて考えることです。
まずどんなアプローチで何をするのかを考える上り坂の段階があります。
そしてやるべきことが見えてきたら、次は実行するための下り坂です。
みたいな考え方もありますね。
実際今の言葉が図示されていますので、後ほどこの記事を見てもらえればと思います。
長いが、これ。
残り時間、30分きてしまったんですけど、
あともうちょいなんで、すみませんが走り切っていこうと思います。
金曜日なので皆さんお仕事も大変かもしれないので、
もちろんお時間なくなった方は全然抜けていただいて大丈夫です。
続いていきます。ベッティングテーブルですね。
テーブルにベッドするという話です。
続いてバックログではなくベッツというふうに書いてあって、
別の記事のリンクが貼られているので、
これも先ほどのベースキャンプのドキュメントですね。
のチャプター7に、
ノットバックログスベッツという章があるので、
そういうところを見てください。
もしあなたがガイルから移行するのであれば、
この言葉を飲み込むのは難しいかもしれませんが、
バックログはしばしば大きな時間の浪費と不安の種になります。
バックログは変化に対して柔軟ではありません。
24:01
例えば5ヶ月前のアイディアはもう関係ないかもしれないのに、
なぜそのアイディアの追跡に多くの時間を費やすのでしょうか。
バックログを手放すのに役立つもう一つの考え方というのは、
重要なアイディアは特に顧客や社内チームの動向を
しっかり把握していればまた戻ってくるということです。
ああいいですね。なるほど。
必要性とか重要なものは一回手放したとしてもどうせ帰ってくるということですね。
なので手放しても別にいいんじゃないのということですね。
あるアイディアを一度聞いたり二度と聞かないのであれば、
そのアイディアは実は問題ではなかったのかもしれません。
またそのアイディアを聞き続けていれば次のサイクルで解決策を練り、
そのアイディアに時間をかける気になるでしょうと言っています。
この考え方は結構大事ですよね。
僕は結構この考え方を他のものに転用していて、
いわゆるこうやって朝風だったりとか、
後で読もうみたいな記事のリンクがあるじゃないですか。
後まとめてたんですけど、
本当に必要だったり自分にとって読むべきものっていうのは、
もう一回どっかでツイッターだったりどっかからで流れてくるので、
ToDoに入れないように僕はしました。
結果的に確かにもう一回戻ってきたという記事ってあるので、
その時に読めばいいんじゃないかというのはありますけどね。
こういう応用を僕はしました。
余談ですね。戻ります。
そのコンセプトが終わって続いて、
So what's the betting table?
そのベッティングテーブルはつまり何なんですかというところですけど、
クールダウンと次のサイクルが始まる前に、
次のサイクルで何を作るかを決めるためにベッティングテーブルを開催すると。
このミーティングでは、
以前に作成したものを見直すことに非常に集中し、
次のサイクルで作成することを決定したいくつかのピッチを成果物として提示します。
ベッドしないものはとりあえず出放しますが、
次のクールダウンで再びベッドすることももちろん可能ですよ。
このベッドの意味もシェイプアップの重要なポイントです。
シェイプアップの本によると、
プランニングの代わりにベッドという用語を使うのは、
異なる期待を持たせるためだそうです。
異なる期待なんだ。
ベッドには配当があります。
賭けですからね。
賭けには代償があるのです。
1つの機能に対して2週間を費やし、
意図的な進展を期待するのではありません。
6週間という枠の中で意図的に仕事を組み立て、
最後には意味のあるものを完成させるのです。
ピッチは賭けに見合うだけの具体的な配当を定義しています。
ベッドはコミットメントです。
6週間を賭けるのであれば、
その6週の間中断することなく、
その仕事だけに専念してもらうことを約束するのです。
プログラマーの時間を1時間単位で最適化しようというものではないですよ。
6週間後の製品全体の進捗という大きなムーブメントを見ているのです。
賢いベッドというのは、
ダウンサイドに条件があります。
6週間を賭けるのであれば、
失うのはせいぜい6週間。
最初の見積もりの何倍ものお金をかけて、
その値段に見合わないものを作るような事態は避けたいのです。
27:02
なるほどね。
ただまあ、今更だけど、
6週間ってスプリント的に結構長い気がしているのですが、
6週間サイクルなんだというところが、
まあ気にはなりますので、
なんだかんだシェイプアップのスマッキーの書籍ですね。
ちょっと読んでみたくなりましたね。
続いていきましょう。
Who takes part in the betting table?
サイクルを正しく回すには、
上層部の賛同と連携が不可欠ですから、
一般的には社内の一番偉い人たちが
そのベッティングテーブルに参加する人たちだと言っています。
まあステークホルダーと言ってもいいかもしれませんが。
ピッチが事前にきちんとレビューされていれば、
ミーティングは効率的で選択肢はよく形作られて、
ヘッドカウントも少なくて済むはずですと言っています。
現在私たちのベッティングテーブルでは、
製品担当副社長、
そして最近製品エンジニアリングの
責任者を加えることにしました。
今後自分たちのプロセスを改善しながら、
さらに変化していこうでしょうと。
冒頭で述べたように、これは全てあなたの組織とチーム構造に基づいて
決定がされますよと言っています。
ベッティングテーブルという最終的な意思決定のところです。
誰がやるかというと、
会社のトップの人たちが参加するのは当然だと思います。
最後に、
現在の状況について語っていきます。
移行期間について少し触れましたが、
プロセスの変更を急がないことが重要です。
全ての選択肢を徹底的に吟味し、
トレードオフを文書化し、
綿密な移行計画を立て、全員から賛同を得るようにしましょう。
また私たちはシェイプアップを忠実に実行したわけでもありません。
しかし、他の方法論と同様に、
チームや組織に最適になるように微調整することがもちろん重要です。
これ大事ですよね。
スクラムやる時も一緒だと思うんですけど、
スクラムやることが目的ではなくて、スクラムの要素だったり、
メソッドだったり、フレームワークそのものを
自分たちのチームにどうなじませるというか、
咀嚼させて取り入れるかというところが重要なので、
スクラム自体をやることは別に目的ではないというところが重要ですね。
今週私たちは5つのサイクルを終えましたが、
これはシェイプアップを始めてから4分の3余りに担当します。
1年の中の4分の3に相当します。
もちろんこの間、様々な学びや調整もありましたが、
全体として私たちはこれが
私たちに必要な変化であったというふうに確信ができています。
製品戦略はこれまで以上に集中し、
ピッチを戦略的目標で分割することで、今何が重要で、
何が遅れているのかというのをより明確にすることができます。
またこの変更によりチームの自立性と集中力が高まり、
必要に応じてコラボレーションやコミュニケーションの枠組みを
提供することができるようになりました。
チームがこのプロセスに満足し、改善策を模索し続けるためには、
レトロスペクティブを実施し、
30:00
どうすればより良くなるのか、
自分自身に正直になることが不可欠です。
ほとんどのことがそうであるように、時間とユーザーが
これがあなたやあなたのチームにとってうまくいっているのかどうかというのを
正直に話してくれるでしょう。
ここで記事としては終了です。
最後にサンクス的なところが書いてあって、終了です。
詳しくはいくつでもお話ししますので、
直接連絡を入れたら回答しますよというところでした。
というわけで、
すみません、長くなってしまいましたけど、以上で終わりましたが、
繰り返しになりますが、
冒頭の方で貼ってあった、
この書籍が無料で読めますので、
皆さんの方でも読んでみていただければと思います。
大体150ページくらいの書籍です。
PDFでもダウンロードできますので、見てみてください。
これがないと、今回のシェイプアップの話を
理解するのは結構大変だったなというのがあるので、
だいぶ僕は不完全燃焼というか、
全然咀嚼できないまま終わってしまったのがあって、
今日の朝活はグダグダひどかったなという感じはありますが、
とは一方でコンセプトだったりとか考え方とか思想というのが
かなり書かれていて、そこに関しては具体的な事例でもあったので、
イメージは結構できたなと思います。
あとは具体的なノウハウとかやり方とか、
いろんな言葉の定義というのを改めて書籍から確認して、
この記事を読み直したくなりましたね。
もしスクラムやってたりとか、
スプリントで結構苦労している方がいたら、
改めてこのシェイプアップの記事を読んで、
そこから必要な要素を取り入れるのもいいですし、
ガツンとシェイプアップのやり方に
乗り換えるのも全然いいなと思いますので。
チームビルディングとかその辺に興味ある方は、
この辺読んでみるといろいろ学びかえるんじゃないかなと思いました。
というところで、今日の朝活は以上にしたいかなと思います。
明日からまた何を読むかは
別途検討します。
というところで、今日の朝活は以上ですね。
金曜日1週間の終わりですが、
今日も頑張ってきて、
週末もゆっくり休んでいただければなと思います。
今日もご参加いただきありがとうございました。
終了します。お疲れ様です。
