[2023/01/26 開催]”形だけスクラム”からの脱却
2023年1月26日に開催されたCTOmeetupのテーマは、「“形だけスクラム”からの脱却」です。プロダクト開発の手法として多くの企業が導入しているスクラムですが、実際の現場ではなかなか運用が上手くいかない、メリットが享受できないといった課題が生じるケースもあります。
そこで今回は、Chatwork社のだいくしーさんと、グロービス社の大沼さん、久津さんをお招きし、スクラムの課題や工夫のポイントなどについてディスカッションしていただきました。
両社が採用している大規模スクラムのフレームワーク「Scrum@Scale」についても触れていますので、ぜひご覧ください。
目次
真に意味のあるスクラムとは？
スクラムの定義
だいくしー氏：
Chatworkのだいくしーと申します。Chatworkは「働くをもっと楽しく、創造的に」というミッションを掲げ、中小企業向けにビジネスチャットツールを展開しています。よろしくお願いします。
大沼氏：
グロービスの大沼です。私は「GLOBIS 学び放題」や「GLOBIS Unlimited」などのプロダクト開発を手掛けており、現在はエンジニアリングマネージャーとして働いています。認定スクラムマスターを取得した経験もあります。
久津氏：
グロービスの久津です。私は「GLOBIS 学び放題」や「GLOBIS Unlimited」のCPOで、Scrum@Scaleのチーフプロダクトオーナー（以降CPO）のロールを担っています。私は認定プロダクトオーナーの資格を取得しています。
だいくしー氏：
本日のテーマは「“形だけスクラム”からの脱却」ということですね。スクラムはシンプルなフレームワークですが、確かに実際の現場で実行するのは難しい面があります。以下のスライドは、スクラムガイドからの抜粋です。
だいくしー氏：
スクラムは最小限の内容しか定義されていないので、プロダクトやチームによって学習を積み重ねる必要がある点が難しいのだと思います。
今回はスプリントを構成するイベント単位での課題や悩みを4つに分類して、掘り下げていきます。
［スクラムの苦悩1］プロダクトバックログ作成
だいくしー氏：
まずはプロダクトバックログの作成ということで、プロダクトオーナー（以降PO）の久津さんから普段の悩みや工夫について教えてください。
久津氏：
「Why/What/Howをどこまで書くのか」については、コンディションに合わせて泥臭くチューニングをしています。例えばチームが立ち上がったばかりでドメイン知識がメンバーに浸透していないときは、ふわっとした「Why」だけを書いても難しいので、緊急性が高ければある程度ハードに書きます。そればかりではなかなか学習できませんから、状況が変わればある程度ラフに書いて対話の中で理解を深める感じですね。
2つ目の「プロダクトオーナー/デザイナーがボトルネックになる」については、相対的にPOやデザイナーが少ないので、チケット消化のスピードが上がるとボトルネックになってしまうということです。ただ、それに備えてバックログを溜めておくのは、アンチパターンだと言われますね。
だいくしー氏：
3つ目の課題はいかがですか？
久津氏：
リファクタリングや負債解消は、例えばアクティブユーザーを増やす、コンバージョンレートを上げるといった開発に対して得られるベネフィットが全く違います。そのため、エンジニアのバックグラウンドを持つPOでも、優先度を決めるのが難しいですね。
大沼氏：
課題3に対する工夫は、「リファクタリング用に作業時間を20％天引きしておく」のがポイントになります。とはいえ、メンバーは自分のスプリント達成に目が向いているので、なかなか上手くいかないんですよね。その場合はチームを切り出します。
例えば今はDev Experienceという開発体験を高めるチームを作っているのですが、そこにスクラムチームがやりきれない前準備のタスクをどんどん切り出していく予定です。
［スクラムの苦悩2］スプリントプランニング
だいくしー氏：
次の苦悩は、スプリントプランニングについてです。これは私がいくつか書かせていただきました。
だいくしー氏：
よくあるのが、バイネームでタスクをアサインしてしまうケースですね。一見複数の仕事が平行して動いているように見えるのですが、リソース効率を重視するよりフロー効率を重視したいですから、フロー効率的には一つの仕事を確実に終わらせていくほうが効率的な気がします。スウォーミングと言ったりしますね。
あとはタスクのサイズも大きくなりがちです。せっかく毎日デイリースクラムで検査するタイミングがあるのに、3日目にならないと作業が終わらないとなると、残り2日しかありません。できればタスクは小さく作りたいですね。
タスクについては十分に話せていなかったりすると、見切り発車で仕事が進んでしまいます。
大沼氏：
全部あるあるですよね。特にバイネームでのタスクアサインは、スクラムを導入したばかりのチームで起こりやすい気がします。手が空くともったいなくて、不安に感じる感覚はありますね。
だいくしー氏：
最近はモブプロやペアプロが浸透してきてメンバー同士が一緒に仕事をする機会も多いです。こういった工夫を組み合わせると、上手くいくのかなと思います。
大沼氏：
タスクは最初の段階のブレ幅が大きいものなので、例えばクラス単位で合わせておく、スキーマレベルで最初に組んでおくというのはペアプロでよくやります。
［スクラムの苦悩3］スプリントレビュー
だいくしー氏：
スプリントレビューの悩み事のあるあるも書かせていただきました。
大沼氏：
スプリントレビューに必要なステークホルダーが出席していないというのは、よくありますよね。トピックに応じて呼ぶ人と呼ばない人を決めるのはなかなか難しいと思うので、まずは広くアナウンスするのが大事だと感じます。
だいくしー氏：
スプリントレビューの予告を簡単に出しておいて、関係がありそうな人に届くようにする方法もありますね。準備をしっかりした上でステークホルダーを呼ぶ必要があると思います。
久津氏：
2つ目の「声の大きい人のフィードバックを反映してしまう」もあるあるですね。うちの場合スプリントレビューは30分なので、どうしても「本当はこっちの人のレビューを聞きたかった」というシーンが発生します。
これに対しては最初に「こういう観点で意見がほしいから、◯◯さんよろしく」と期待値で伝えておく方法があります。あとはZoomのブレイクアウトルームを3～5人程度に分けて作り、しっかり聞くべき人の意見を聞くといった工夫をしています。
だいくしー氏：
あと、緊急度の高くない細かいフィードバックは、せっかくもらっても忘れてしまいますよね。
久津氏：
ありますね。忘れてしまったとしても貴重なフィードバックです。今はみんなでNotionを眺めながら、ざっと内容を書くようにしています。
また、最近はスプリントレビュー直後にフィードバックの振り返りをしています。その日の午後にスプリントプランニングを行うので、すぐやるときはすぐやる、やらないものはきちんと記入をするという形で、丁寧なプロセスを組んでいます。
［スクラムの苦悩4］その他
だいくしー氏：
次は、ここまでの3つの苦悩以外の内容です。
だいくしー氏：
「新メンバーのオンボーディング」については、私から挙げさせてもらいました。ジュニアのメンバーをどう育てるのかはスクラムに限らずつきまとう問題ですね。
弊社ではよく、組織パターンの「託児所パターン」を使います。チームを「進捗を出す組」と「人を育てる組」に分けて、進捗組みがベロシティを安定させる傍ら、メインとは違う簡単なタスクを切り出して、新メンバーにお願いするような形です。
大沼氏：
弊社の場合は、困ったことがあったらSlackで騒いでもらうよう徹底しています。つまずくポイントがあればすぐにZoomで話すといった経験も何度かしてもらうと、オンボーディングに効きますね。
だいくしー氏：
2つ目の「消費ベロシティ＝個人のパフォーマンス指標になってしまう」問題についてはいかがですか？
大沼氏：
ベロシティはチームのパフォーマンス指標であって個人のものではないという説明は強調していますし、大前提として「個人よりチームメインで考えていく文化」は認識を揃えていきたいところですね。
ベロシティが高いから何の問題もないと思われて、価値が届いていない状態になるのが一番怖いです。そのために健康指標的にデプロイ頻度やリードタイムを組み合わせて、価値提供できている状態に持っていきたいと思っています。
だいくしー氏：
「ビルドトラップ」と言ったりしますよね。
あと、スクラムは経験主義のフレームワークなので、やる必要性が少ない開発を入れ込みづらいのも悩みですよね。
久津氏：
これは私が書かせてもらいました。基本的にアジャイルやスクラムは、変化の激しい世の中で計画主義が通用しづらくなったことから生まれた原理原則だと思っています。
とはいえ、世の中のプロジェクト・プロダクトの全てが経験主義にシフトしたわけではありません。まだまだ制約も多い中では、開発手法をスクラムに統一するデメリットを感じることもあります。
「アジャイルやスクラムではできない」わけではなく、カスタマイズする努力を怠るとハマらない、という感じでしょうか。セールス側でしっかりプレスリリースを出す場合や、外部サービスと連携する場合など、リリースやスケジュールの自由度がないプロジェクトにおいては、特性の違いを認識した上でやり方を決めていく必要があります。だからといって完全に計画主義的に動こうとするとデフォルトからやり方を変えるオーバーヘッドがかかるので、落とし所を見つけるのが大事ですね。
両社が採用する大規模スクラムのフレームワーク「Scrum@Scale」とは
「Scrum@Scale」とは何か
だいくしー氏：
ここからは、当社とグロービスさんが採用している、大規模スクラムのフレームワーク「Scrum@Scale」についてお話ししていこうと思います。
大規模スクラムは非常に難しいので、採用する前に単一の熟練スクラムチームが育っているか、本当にスケーリングさせないと課題解決ができないのか、一度立ち止まって考えてみてほしいと思います。
フレームワークの概要は、以下の通りです。
だいくしー氏：
Scrum@Scaleでは複数のチームが連動して動くことになり、Scrum of Scrums（SoS）という、各チームから代表者が集まって作られるチームが定義されています。このチームが連動してスクラムイベントを実施して、複数のチームが協調していく形です。一番上にはEAT（Executive Action Team）という、スクラムマスターサイクルの最上位決定機関があり、CTOやCEO、CFOを巻き込むのが大事です。
また、各チームにはスクラムマスターとPOが存在します。スクラムマスターサイクルと同時にプロダクトオーナーサイクルもスケールするわけですね。POが複数人いるとどうしても合議的になってしまうので、久津さんのようなCPOがScrum@Scaleの一番上でプロダクトを見ることになります。プロダクトオーナーサイクルの中にもEMS（Executive Meta Scrum）というものが存在し、組織全体に対してエグゼクティブメンバーが意志決定を行います。
「Scrum@Scale」の導入背景と初めのアクション
だいくしー氏：
グロービスさんから、Scrum@Scaleを導入した背景と、初めのアクションについてお話しいただいても良いでしょうか？
大沼氏：
導入背景にあったのは、複数のスクラムチームの存在ですね。スクラムチーム間でタスクの受け渡しをする際に背景情報や目的の伝達が抜けて、上手く課題解決できないことがありました。
チーム間連携を円滑にするためにScrum@Scaleを導入した際、一番意識したのが「良いチームを2つ作る」ということです。「2つ」というのが重要です。2つあればお互いに良い連携の仕方を構築していけますし、「良い状態のデフォルト」がある程度完成されて、3チーム目も良い感じに立ち上がるだろうという感覚がありました。
だいくしー氏：
Chatworkの場合はサービスのローンチから10年経過して技術的負債が深刻になっていたので、マイクロサービス化した新しいアーキテクチャへの移行プロジェクトが立ち上がっていました。それなら組織もアーキテクチャの設計に合わせて柔軟に組み替えられるようにしようと、Scrum@Scaleを導入しています。グロービスさんと同様、熟練した2チームを作ることからスタートしましたね。
「Scrum@Scale」の運用現状と感じたメリット/課題
だいくしー氏：
運用の結果、メリットや課題についてはどのように感じていますか？
大沼氏：
EATにおける課題解決フローがある程度動いているのがメリットですね。これまではどこにエスカレーションしたらいいのかわからない問題がありましたが、今は明確になりました。実際に経営会議にまで持っていくと議事録が取られるので、ある程度情報が見やすくなったと思います。
久津氏：
一方でプロダクトオーナーサイクルにはまだ課題がありますね。組織が柔軟に変更できず、EMSが形骸化しています。
例えば各チームのプロダクトオーナーが集まって議論をしても、担当する範囲に関わるリポジトリやソースコードのエリアがある程度決まっているので、それ以外の部分には触れない状態なんです。結果的に、それぞれやりたいことがあっても、チームの中での優先順位にしか反映できないという現象が起きます。
A、B、Cという3つの領域があったときにAが重要になったとしても、対応できるのが1チームしかないために、横断して優先度を決めることがあまり意味を成さないのです。
だいくしー氏：
Chatworkは「アーキテクチャを刷新する」という特徴的な仕事にScrum@Scaleを適用しているので、アーキテクチャの新しい発見に応じて柔軟に組織を組み替えられるのが逆にメリットだと感じています。ここはグロービスさんと真逆で面白いです。
EATの課題解決機能がワークしているのは共通ですね。全ての課題が明確になるのはメリットである反面、EMSはなかなか難しいです。各チームにPOが必要なので、チームを増やそうとしても人材がいません。採用してすぐにプロダクトを任せるわけにもいきませんから、スケールが課題感です。
久津氏：
今弊社では、業務委託の方にPOとして週3～4日入ってもらっています。POのロールが肥大化しすぎる問題もあるので細分化し、エンジニアが段階的にPOを目指せるようにしていく形も模索中です。
Chatwork、グロービスが伝えたいポイント
だいくしー氏：
今日のディスカッションでお伝えしたい3つのポイントは、以下の通りです。
だいくしー氏：
やはりScrum@Scaleは小さく始めて、徐々に大きくしていくのが大事ですね。
フレームワークを適用しただけでは機能しないため、泥臭い試行錯誤も必要です。
スクラムは検査・適用のフレームワークですから、何が組織の問題なのかを進んでセルフチェックして一歩一歩解決し、スプリントを回していってほしいです。
Q&A
「未来志向に向けさせるためのレビュー」にするためには？
Q.スプリントレビューが開発結果の確認会議になってしまうチームを、プロダクトゴール実現のための未来志向に向けさせるためのレビューに変更するための良い方法はあるでしょうか？
だいくしー氏：
これはステークホルダーと適切にコミュニケーションするのが大事かもしれませんね。
久津氏：
確認会議になりがちな原因は、リリースをこまめに出せないからかもしれません。すぐにリリースされる内容なら、「これはきちんと効果が出るのか」という話になりやすそうです。
そのときやるべきなのは、「誰の何のためにやっているのか」というユーザーストーリーを、スプリントレビューの最初に宣言するなどでしょうか。
負債解消のタスクは何を指標にしている？
Q.「リファクタリングしたいリスト」とか「この負債を解消したいリスト」みたいなのを作るのは多くのチームでやると思うのですが、その中の「どれからやるか」を決めるのが難しいと感じます。プロダクトバックログはPOがユーザーへの価値提供という物差しが機能するかと思うのですが、負債解消のようなタスクは何を指標にされていますか？
大沼氏：
あまり数値化はしませんが、振り返りで辛かったポイントを深掘りすると、最終的に負債に行き当たることが多いですね。
だいくしー氏：
私たちは直近で開発しようと思っているプロダクトバックログアイテムに関わる範囲は、なるべく綺麗にリファクタリングしてから作るようにしています。スプリントバックログを作る段階でリファクタリングをタスクに積む作業計画を練るなどですね。
デプロイ頻度を指標にした場合、タスクが細分化されても問題ない？
Q.ベロシティ至上主義を避けるためにデプロイ頻度を指標に入れると、今度はタスクを必要以上に細分化するようなモチベーションが働きそうですが、それは特に問題ない（タスクがデプロイ可能な状態で細かいことには負の側面は特にない）とお考えでしょうか？それとも、それに対して何らか対策は採られていますでしょうか？
大沼氏：
タスクが細かすぎて困るケースはあまりないのではないでしょうか。タスクが大きいとバッチサイズも寄り戻しも大きくなってしまいますが、小さければフィードバックループが速くなります。
だいくしー氏：
指標を追うことによって、良いふるまいができているんですね。
（番外編）当日取り上げられなかった質問と回答を一挙公開！
スクラム運用において取るべき指標とは？
Q.スクラムでどんなメトリックスを取るといいですか？成熟度合いにより変わると思いますのでその観点でもコメントいただけますと幸いです。
だいくしー氏：
一般的にスクラムをやる場合は
- そもそもスクラムが上手ではないので上手になるように改善する(Howの改善)
- 開発チームが順調に動き始めると、プロダクトオーナーとの関わりを強化する(Whatの改善)
単純なところでは、ベロシティを計測する。それを少しずつあげていく。慣れてきたらFour Keys Metricsなどを計測して開発チームの生産性を測っていく。開発チームがうまく動くようになると同時に、アウトカム（顧客価値）を計測する、という形になるかと思います。アウトカム指標に関しては、プロダクトによってさまざまで一概には言えないのが難しいですね…。
HowからWhatの順に書きましたが、アウトカムはプロダクトにとって重要な指標なので、開発チームの改善を待たずとも最初から計測できるのならしたほうがいいと思います。
大沼氏：
単純ですが、まずはどんな成熟度でもベロシティを計測するのが良いと思います。私の感覚ではHowに課題を抱えているチームほどメトリクスが有効で、
Four Keysはメトリクスとしてはデファクトになっているのでとてもおすすめです。
特にデプロイ頻度の計測が最も効果的であり、始めやすい指標だと思いますね。Howに課題を抱えているチームほど手戻りが多くなりがちです。手戻りをいかに減らすかがとても重要だと考えていて、できるだけ小さいバッチサイズで開発を進めることを目的とするデプロイ頻度がハマります。バッチサイズが小さければ手戻りの量が減り、開発効率が大きく上がりますね。
久津氏：
アウトカムに関するメトリクスも取るべきだと思いますが、適切なメトリクス設計の難易度がかなり高いです。かつ、チームが成熟していないフェーズで早々に設定してしまうと、あれもこれもメトリクスを追わなければならなくなり混乱するリスクがあるので、まずはスループット系のメトリクス運用を適切にこなせるようになってからアウトカム系のメトリクス設計にトライし、いきなり完璧なものを目指しすぎずに少しずつチームや組織の状況に合った運用ができるようになれればいいのかなと思います。
「変革の8段階プロセス」は活用するのか？
Q.Scrum@Scaleで運営されるうえで、コッター教授の８ステップも活用されているでしょうか？
だいくしー氏：
コッター教授の8ステップはお恥ずかしながらそれを知ったのがつい最近であるため、そこまで活用はできていません。もう少し勉強して、活用できるようにしたいと思います。
大沼氏：
僕は特に活用していないですね。
どちらかというと小さく始めて成功事例・成功体験を積み重ねていくやり方が好きなので、小さく成功するにはどうしたらよいかを考えることが多いです！
スクラムが機能するために必要なチーム人数は？
Q.開発者が1名のチームでもスクラムは機能しますか？
だいくしー氏：
検査・適応のループを回すという意味では機能するとは思いますが、スクラムを運用する場合にはチームの継続性というものも気にします。1名の場合は、この人が休んだり退職するとチームとしての活動が止まってしまい、「チーム」とは呼べないため、それは「スクラム」とも呼べないような気がします。
あくまでも、個人が自分の仕事を改善しながらすすめるための「仕事術」としてスクラムを模している、という形になってしまうのではないかなぁ、と思います。
久津氏：
「スクラム」は機能すると思います。コミュニケーションコストが限りなく小さくなるので、運用もしやすいと思います。ですが、エンジニアリングの観点で様々なリスク（品質やチームのケイパビリティが個人に依存しすぎ問題など）が考えられるので、そこへの打ち手も合わせて考える必要があると感じます。
決裁者が重視するポイントが異なる際にどうするか？
Q.リソース効率を重視する決裁者がいる場合、フロー効率性を重視するようにどうマインドチェンジを促せばよいでしょうか。
だいくしー氏：
現場からの働きかけで決裁者のマインドチェンジを促すのは、この件に限らず難しいですね。外部から専門家を招いて社内で講演をしてもらう。フロー効率についての書籍や、資料を使って丁寧に説明する、など根気よくやる方法しか思いつかないです。まずは1on1で「自分はこのように考えているのですが」と対話からはじめるというのも良さそうです。
現場で新しいものを導入したり、変革を促すような場合は、『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』という書籍がおすすめです。変革を促すためのいろいろな手がかりが書いてあります。
久津氏：
個人的な意見ですが、その決裁者の方がソフトウェア開発に直接的に関わっていないのであれば、マインドチェンジをしてもらうことはかなり難しいと思っています。いくら理論を伝えても、フロー効率重視のメリットを享受したことのない人にはなかなか腹落ちしにくいです。
であれば、小さくてもいいので成功体験を積み、それをしっかり結果としてアピールしていくことで、「あ、確かにフロー効率を重視したらパフォーマンスが高まったな」と実感してもらうのがいいのかなと思います。
チーム内の発言を活性化するための工夫とは？
Q.アジャイルの経験が深く、知識のある人が、声が大きい人になるケース（職位的な権限も持っていたりする）があるのですが、発言を躊躇ってしまう人にどう支援したらよい、というアドバイスはないでしょうか？
だいくしー氏：
アジャイルの経験が本当に深いなら、サーバントリーダーシップも身につけているはずなので「声が大きい人」にそもそもなってほしくない！
というのは置いておいて、「この場で発言しても安全である」という雰囲気をつくりたいですね。そういう意味では声の大きい人に、ちょっと控えてもらいつつ、躊躇している人にも発言を促したいです。
こういうちょっといいづらいフィードバックをする手法で、COINの会話モデルというものがあります。
context connection(コンテキストの把握), observation(観察), impact(影響), next(今後) の頭文字です。これにあてはめてみると、次のような感じになりそうです。
①コンテキストの把握
みなさんがこの場をよりよいものにしよう、アジャイルであろうという気持ちでいらっしゃるのはとても理解しています。
②観察
この場を客観的に見てみると、全員が同じように積極的に発言できていないかもしれない、というように見えます。
③影響
発言が少ない人がいると、せっかくの良いアイデアがが表に出ず、意見に偏りが出てしまいそうです。
④今後
自分の発言量が多いな、と思う人はちょっと抑えて、発言できていないな、と思う人はちょっと意識的に発言を増やす、というチャレンジをしてみません？
これはあくまでも一例ですが、このように場の全体に対して働きかけてみてはどうでしょう。
久津氏：
1on1など心理的安全性が担保された場で丁寧に声を拾う…などのやり方も考えられますが、少し大掛かりな対策も紹介させてください。サブプロジェクトとして経験が薄い人だけでチームを組んでみて、そこでしっかりアジャイル開発を行う方法をやったことがあります。
要は失敗しても大きな問題にならない環境を作り、そこで半強制的に自分で考えさせる、そして振り返りをさせ、小さくてもいいので成功体験を積ませることで、発言の機会と自信を持ってもらう、というアプローチです。
熟練されたスクラムチームの判断基準とは？
Q.Scrum@Scaleを始めるにあたり選定したちゃんとしたスクラムチーム2チームは何を基準に判断されましたでしょうか？
だいくしー氏：
定量的な判断基準などはまだ定義するのが難しいので、外部からプロのアジャイルコーチを2名お招きして、その人たちにチームをおまかせすることで「ちゃんとしたチームを立ち上げる」という抽象度の高いミッションを実現しようとしました。
最初からスケールする組織づくりが前提であったので、チーム間の連携が必要な最小単位として2チームからスタート、ということにしました（1チームだけだったらチーム間の連携を整える、という動きができないので）
大沼氏：
この判断は難しいですよね…。
僕はチーム立ち上げを何回かやっていまして、立ち上げ初期と比べてかなり良くなった部分が多く見えているので勝手に判断してしまっています。
スクラムの練度が上がってきた兆候はこちらの記事も参考になります
ベロシティは見るべき指標とすべきか？
Q.ベロシティは指標にしていますか？前のスプリントのベロシティと比較しようとすると、開発メンバーに嫌がれるので。
だいくしー氏：
ベロシティは指標にしています。ベロシティを少しでも増やそう、ということにはあまり使っていなくて、どちらかというと見積もりの予測精度をあげたかいので、ベロシティの安定化、というのを意識しています。ある程度安定してきたら、もう少し仕事量を増やせないか、という議論にシフトしてもよさそうです。
開発メンバーは数字が独り歩きして、納期プレッシャーなどがかかることを気にしてが嫌がっているのでしょうか。だとするとベロシティがきっちり測れている方が、根拠をもって見積もりに対して期限の確かさを主張できるので、楽になるはずなのです
大沼氏：
指標にしています！前スプリントのベロシティ比較がなぜ嫌がられるかは気になりますね。ベロシティが上がった場合はお祝いムードで、下がった場合は葬式のような感じになっているのであれば認識を揃えておきたいところです。
ベロシティはあくまでデータであり、一喜一憂するものではないという認識で、ざっくりですが以下の式に表されるように完成するまであとどれくらいなのかを示すため必要だと思っています。
全体のストーリーポイント / ベロシティ = 完成までの期間の目処
ここの分母がブレるといつ完成するかがブレるので、まずは安定が大事です。 ベロシティが安定しない場合は何かの妨害要因があることが多いので振り返りでアイデアを出して対処し、まず安定を目指してみようという合意形成ができると良さそうです！
PBIにリリース前検証を入れるべきか？
Q.PBIにリリース前検証作業も入れるのでしょうか？もし入れる場合は、開発メンバーはスプリント後半何をしていくのかイメージができません。入れないのであれば、検証せずにリリースするイメージになります。どうするのが理想なのでしょうか
だいくしー氏：
PBIはストーリーの単位で作るのが一般的なので、どちらかというと検証作業はスプリントプランニングで作成される作業計画としてスプリントに入ってくる印象です。
一方で、PBIのサイズが大きいので分割する、という場合に、ひょっとしたら「検証作業」というPBIになるかもしれませんね。着手可能なPBIは、スクラムの原則に従えばリファインメントされ、見積もられているはずですから、検証作業にも見積もりのポイントがついているはずです。
すなわち、ベロシティとつきあわせると、検証作業以外にこのスプリントにはどのくらい追加でPBIを入れられるか、という判断もできると思います。そうやって、「検証作業」以外の別のPBIを入れていけばよいだろうと思います。
久津氏：
（質問者の方の環境と前提が異なるかもしれませんが）リリース前検証が必要なリリースなのであれば、それも含めてスプリントバックログに分解します。その作業の見積りもして、スプリントプランニングしていきます。仮に検証作業が早く終わってしまった場合、残りの期間はリファクタリングなど直接的に依存関係のないタスクを進めていきます。
デザイン思考は備えるべきスキルなのか？
Q.デザイン思考からアジャイルにつながると言うひとがいます。デザイン思考はアジャイルを実践する基礎スキルなのでしょうか？
だいくしー氏：
どの知識を持っていれば「アジャイルである」ということは明確に定義されているわけではありませんから、デザイン思考がアジャイルの基礎スキルかどうか、というのはわかりません。
扱っているプロダクトの性質や、現場のコンテキストにも強く依存します。ただ、アジャイルコーチのスキルセットとしては、できるだけ引き出しが多いほうが有利なことは確かなので、学習して損はないと思います。
久津氏：
「ビジネスの不確実性を経験主義で対処する」という目的でアジャイルを活用し、かつ「ユーザーの課題解決ドリブンなアプローチが有効」という勝ち筋があるなら、デザイン思考ベースのアジャイルがいいと思います。
もしそうではなく、例えば「イノベーター向けにまだ世にないプロダクトを作る」という狙いであればアート思考がいいし、「事業の戦略がクリアで、いかにスピーディにリスクなく前に進めるかが勝負」という状況だったらロジカル思考的にアジャイルを活用するのがいいと思います。
まとめ
改めてスクラムについて、スクラムイベントごとに直面する悩みとその乗り越え方、そして大規模フレームワーク運用のリアルについて語っていただきましたがいかがでしたか。
登壇者お三方の発言にもありましたが、スクラムは検査・適用のフレームワークです。
何が組織の問題なのかをセルフチェックを行い、一歩一歩解決してスクラムを運用していきましょう。
