自己紹介
大西氏：
本日、モデレーターとして参加させていただく大西です。私は株式会社InnoScouterでCTOを務めております。InnoScouterはエンタープライズ向けのtoB SaaSを提供しています。最近は"「なんちゃってスクラム」に気づくためのコツ"という記事をzsennで公開しました。
私自身、InnoScouterでスクラムマスターとCTOの双方の役割を担っており、スクラムの実践に取り組んでいます。当社は小さな組織なので、スクラムマスターの視点とCTOの視点、どちらで意見を出すべきか、常に悩みながら進めています。今日はそのような背景を持つ私がモデレートしますので、ご理解のほどをお願いします。
次に、今日の登壇者を紹介いたします。多くの企業でスクラムを支援してきたスクラムマスターの藤原さんです。どうぞよろしくお願いいたします。
藤原氏：
藤原と申します。現在は『アジャイルコーチ』と名乗りながら、スタートアップから大手企業にかけて、スクラムやアジャイルの導入、トレーニング、そして組織のスケーリングを手がけています。今日はスクラムのアンチパターンについて、実際の現場の経験を元にお話しします。
大西氏：
ありがとうございます。早速、登壇者LTに進みたいと思います。
なぜ自社ではスクラムがうまくいかないのか、アジャイルコーチと考えるスクラムのアンチパターン
藤原氏：
はい、準備OKです。「なぜ自社ではスクラムがうまくいかないのか、アジャイルコーチと考えるスクラムのアンチパターン」というテーマでお話しします。
藤原氏：
最初に、アジャイル開発やスクラムを通じて実現したい目標についてまとめてみました。スクラムが広く普及している現在、なぜこれが一般的な方法となったのか、という点は非常に重要です。
その実現したい目標を簡潔に言えば、以下のようになります。
まず、顧客満足度の向上を目指しましょう。これを達成するためには、フィードバックを迅速に取得し、速やかに反映させる必要があります。これが、短いサイクル、すなわちスプリントで行う作業の繰り返しにつながります。
次に、柔軟性と適応力の向上も重要です。変化に対して強くなる必要があります。この目標のためには、長期的な計画よりも、短期的で柔軟に変更可能な計画が望ましいという考え方です。
この考え方であれば、バックログやタスクの優先順位は迅速に変更できます。そこから振り返りやレビューを通じて、プロジェクトやプロダクト、チームの改善が進むことも重要になってくるでしょう。スクラムを採用すると、透明性が高まり、「見える化」が進むので検査もしやすくなります。この「見える化」を実現するためのスクラムイベントとして、朝礼、レビュー、振り返りなどが行われます。
アジャイル開発の重要な点は、自己組織化を目指すことです。このように変化することでkとでチームが自立して考え、動くようになる。単に上から指示されたタスクをこなすだけの組織ではなく、自ら考えて目標に対して何を実現すべきかを追求する組織を目指しています。
その結果、リスクを軽減できる可能性があると考えられています。これは、スクラムやアジャイル開発に対する期待値、つまり実現したいことだと思います。
次に、アンチパターンについて触れます。実現したいことがあるものの、うまくいかない現場を多く経験してきました。その原因や詰まるポイントについては、次のスライドで詳しく説明します。
アンチパターンの一つ目を見ていきましょう。アジャイル開発やスクラムは、実は遅いと捉えた方が良い、というのが私の考えです。
従来の方法を採用している人がアジャイル開発を始めようとすると、学習工程があるため、新しい方法を導入しようとする次点で遅れが生じることがあります。多くのお客様がアジャイルを導入することで工数が減ったり、リリース期間が短くなるなどの過度な期待を持っています。しかし、正直に言うと、アジャイル開発は初めは遅く感じることがあると考えた方が良いです。この点は、お客様に説明して理解してもらう必要があります。
もうひとつの遅い例はシチュエーションとして一般的なのは、メンバーが並行作業をしている場面です。12チームで開発者が10人というケースを考えてみましょう。この10人が10のタスクを同時に進めている。この方法は複数のタスクが平行に進むので、効率的に思えます。
しかしこれにはデメリットもあります。タスクがサイロ化しやすく、メンバー間のサポートが難しくなることがある点です。例えば、誰かが困難に直面した時や、レビューが多くなる場面で支障が生じることがあります。また、この並行作業のアプローチはスクラムのイベントの意義を希薄にしてしまい、短期間での成果だけを追求する結果、コミュニケーションの機会が減少するという問題も発生するでしょう。
この効率について、今日覚えて欲しいのは「リソース効率」と「フロー効率」の考え方です。私個人としては、フロー効率を重視して考えるようにしています。アジャイル開発のプラクティスを観察すると、リソース効率よりもフロー効率に焦点を当てているように思います。そして、フロー効率を向上させることで、リソース効率も間接的に上がると感じています。
道と車の比喩を紹介します。左の写真のように、道にたくさんの車が走っている状況を想像してください。この状態は、道路を最大限に活用しているという意味で効率的です。しかし、一つのアクシデントが起きると、すぐに渋滞が生じるリスクがあります。渋滞が起きなければ、多くの車がスムーズに目的地へと進めるので、その状況なら効率が良いと言えますね。
一方で右側の図では「フロー効率」という概念が示されています。これはいわゆる「流れ」や「フロー」を重視する考え方です。この場合、リソース効率は低くなります。というのも、車間距離を確保しているため、使用されていないレーンや空いているスペースが目立つからです。その結果、道路の使用効率は低いと言えます。しかしながら、各車の目的地への到着速度は高い可能性があります。目的が到着の速さを求めるのであればフロー効率が適しているかもしれませんし、車の台数を最大化する目的ならリソース効率が良いと言えるでしょう。
先ほどの並行で作業するという考え方は、リソース効率に基づくものです。それに対して、アジャイル開発が推奨するプラクティス、例えば2人で1つの作業をする「ペアプログラミング」や「モブプログラミング」などは、異なる「フロー効率」という考えに基づいています。
アジャイル開発の特徴は、フロー、すなわち流れや速さ、アジャイルそのものを重視している点にあります。
また、固定の予算や期限がある場合、アジャイルはうまく機能しづらいこともあります。これはよく指摘される点です。
会社員にとって予算や期限は避けられない要素です。予算があることで、何をいつまでに終わらせるかがある程度決まってしまいます。このような予測可能な状態は、従来型のアプローチが得意とする領域です。そういった場面では、従来型が効率的に進められるかもしれません。
一方で、アジャイル開発の強みは、計画を臨機応変に変更する必要がある「適用型」のシチュエーションです。この点で、従来型とは大きく異なります。この違いを理解しておくことが重要です。
具体的な例としては、最近お客様との対話でよく取り上げています。
計画づくりや見積もりについてこの話をする機会がよくあります。左側のアプローチは従来型として捉えられます。この方法では、クライアントが必要とする機能や要求をリストアップし、それを開発組織が受け取り、見積もりを行います。その後、計画を立て、タスクに分けて進行します。これが従来の計画づくりの手法です。
一方、右側のアプローチは、我が家の子供たちが駄菓子屋に行く際の話を例に取り上げます。彼らには限られたお小遣い、例えば100円や200円が与えられています。この金額制限の中で、最も価値あるお菓子を選ぶ必要があります。つまり、予算という制約の中で、最大の価値を追求するのがこのアプローチの特徴です。
この二つの違いは、前者が要求を先に決めてから予算や期間を考えるのに対し、後者は最初から制約がある中で最高の価値を追求する点にあります。
従来の見積もりは機能を基に期間を見積もるアプローチです。しかし、アジャイル開発では、期間を基に機能を見積もる方法を取ります。つまり、設定した期間内で実装できる機能を決めるという考え方です。これは、計画の柔軟性を重視する場面で役立ちます。この使い分けは、スクラムやアジャイル開発において基本的な考え方として必要です。
スクラムを導入するだけでプロジェクトが成功するわけではありません。スクラムはベストプラクティスとまではいかないかもしれませんが、導入によって平均的な成果は期待できます。しかし、その成果れをさらに上げるのは難しいと思います。開発そのものの難しさや、スクラムのシンプルさもあって、簡単に成功するという考えは避けた方が良いでしょう。
従来型のアプローチでは、よくプロジェクトマネージャーが中心的な役割を果たしています。この方法は、リスクをできるだけ管理し、プロジェクトマネージャーを主体としてプロジェクトを完成させるという考え方です。一方、アジャイル開発では、自立性と自己組織化を重視します。チームが自ら管理し、自ら考えてベストな方法を探求するアプローチです。
ですので、アジャイル開発やスクラムを採用する場合、プロジェクトマネージャーの役割は不要になるかもしれません。しかし、プロジェクトマネジメントの要素、例えば予算管理などは、多分継続して必要です。これらの要素を完全に省くことができるのであれば、それは非常に革新的だと思います。このような点をお客様に説明するとき、お伝えすることがあります。
最後に最後です「生産性という言葉が出るとうまくいかない」、これもよくあるケースです。特にアジャイル開発の文脈で「生産性が上がる」と言われることがありますが、アジャイル開発と従来型の開発では、生産性の考え方は異なります。
従来型の開発では、出力の量を中心に測定していました。昔の開発者であれば、ステップ数のような指標を知っているかもしれません。一方、アジャイル開発は成果の質に重点を置きます。少ない出力で大きな成果を得ることを目指します。このため、二つの開発手法を単純に比較するのは難しいのです。
生産性の向上や低下を評価するには、複数の視点を考慮する必要があります。多くの出力があっても、その品質が低ければ意味がありません。生産性を測るのは簡単ではなく、そのための計算にもコストがかかることを理解して、慎重にアプローチする必要があります。
「生産性」という言葉を頻繁に使うと、具体的に「あなたの言う生産性と、アジャイル開発が提供する生産性は何か」という点を比較することが大切だと思います。以上で私の発言を終わります。ありがとうございました。
大西氏：
ありがとうございました。非常にバランスの取れた発表で、納得しました。さて、ディスカッションのテーマに移りたいと思います。
ディスカッション
テーマ①「PdMが忙しそうで巻き込めず、開発チームだけでスクラムをやっているというのはいいのか？」
藤原氏：
POと呼ばれる職種はまだ新しく、人数も少ないため、満たされていない部分が多いです。
そのような現場での課題は必ずといっていいほど出てくるわけですが、PdMなり、POの決定や役割分担、その他のスクラムに必要な条件を欠いて進めるのは難しいと思います。
したがって、できるだけ既定の条件や役割を整えることが重要です。
現場の現実として、人手不足や上手く行かない状況が生じることはあります。そうした中での取り組みとして、例えばPdMがを複数のチームで活用する方法や、スクラムマスターがPOの業務をサポートする方法などが考えられています。
これはベストプラクティスとは言えませんが、実際に試みられている方法です。また、開発チームが主導してPOの役割を取り込むというアプローチもあります。それぞれの方法にはそれなりの結果が得られるでしょう。理想の状態を追い求める際に、現実の制約の中で最善を尽くすことを考えるのも一つの方法ではないでしょうか。
大西氏：
わかりやすい説明ありがとうございます。追加で質問させてください。先ほどスクラムマスターがPdMのサポートをするのは好ましくないとおっしゃいましたが、具体的に、どのような場面で問題が起こるのでしょうか？
藤原氏：
PdMとスクラムマスターは基本的に異なる役割を持っています。PdMはプロダクトの価値の最大化に焦点を当て、スクラムマスターはスクラムの実施の最適化を目指しています。
この二つの役割を一人が兼務することは、特定の状況では可能かもしれませんが、それが難しい場合もあるでしょう。PdMが忙しくて時間が取れない場合、リソースを増やすなどの方法で対応するべきです。そうしないと、理想の状態からは離れ、ただの現状維持になる可能性があります。
大西氏：
スクラムマスターがPdMをサポートする場合でも、PdMがプロダクトに焦点を当て、スクラムマスターがスクラムチームに注目しているため、利益相反の可能性があるということですね。ありがとうございます。
テーマ②「アジャイル開発で開発が遅くなったという意見についてはどうか？また、話し合いに時間がかかったりするが、それは健全な状態なのか？」
藤原氏：
先の発表でもありましたが、まずアジャイル開発を導入すると、初期の頃は開発スピードが遅くなるかもしれません。
しかし、チームの練度が向上こうじょうし、かつプロダクトにアジャイル開発が適しているなら、その遅さは解消され、従来型の開発方法よりも優れたプロダクトを作成できるでしょう。
この初期の遅さは、ある種の「投資」と考えます。将来のリターンを期待しての投資です。すぐに効果を求める場合は、開発方法を変えるのではなく、人員を増やすかスコープを減らすなどの方法を検討するのが良いでしょう。
また、スクラムにはコミュニケーションを取るための「スクラムイベント」が前提として定義されています。朝礼、計画作成、振り返り、スプリントレビューなどがすでに設定されているので、それらの時間を適切に使うことが大切です。
多くの現場で、スクラムイベントに確保された時間が足りていないことがあるようです。スクラムガイドには、例えば1ヶ月のスプリントでは4時間を確保するなどの目安が示されているので、それを参考にすると良いでしょう。
話し合いにかかる時間は、新しい取り組みがある場合や慣れている場合で変わるかもしれません。現在かかっている時間が妥当かどうかを確認するために、計測することが重要です。そうすると、スクラムイベントでどれくらいの時間が必要かの目安がわかり、効率的なリズムで作業を進めることができると思います。
大西氏：
なるほど、ありがとうございます。とても分かりやすいです。
そもそもスクラムを導入するからにはコミュニケーションに重きを置く前提があるということですよね。だから、話し合うこと自体も必要な投資だと捉えるべきだと。
藤原氏：
複雑なシステムやチーム間のコミュニケーションの問題は、スクラムの問題とは別です。必要なコミュニケーション量はチームによって異なりますが、その適切な量を初めに基準として設定してみると良いでしょう。
大西氏：
確かに、妥当な基準があれば、それを超えた場合には問題の原因を特定し、解消するだけですね。
藤原氏：
アジャイル開発では時間に対する考え方が特徴的です。まずは時間を決め、それを基準にどこが問題か、どう改善するかを検討します。一般的には2週間スプリントが多く、振り返りや計画づくりにはそれぞれ1時間、朝礼に15分、レビューに30分が目安として使われています。ただ、今はSlackのようなツールも使われていて、それを非同期のコミュニケーションとして利用してさらに短い時間でのスクラムイベントが行う開発チームもあります。
テーマ③「プロマネが主体となって動かし、プロダクトの納期も決まっている状態の場合、何から改善すべきか？」
藤原氏：
最近、似たような質問を受けたことがあります。その時の答えは「何もしないこと」が最良だと思っています。
「なぜこの状況でスクラムを導入するのか」というのが重要なポイントです。
もし、プロジェクトマネージャー主体ではなく、チーム主体での組織作りを目指しているなら、スクラムを導入するのも一つの方法かもしれません。
しかし、スクラムを導入しても状況がすぐに良くなるわけではありません。方法を変更すると、スピードは一時的に遅くなる可能性が高いです。そのため、効率を最大限に保ちたいのであれば、何も変更しないのがベストだと考えます。
大西氏：
何を目的としてスクラム開発を入れるかってところが一番重要ですね。最高速の開発速度が担保できていて、しかも開発速度に対して重視していきたいと思ったら、もうそのままステイでいい。むしろステイがいい作戦なのかもしれません。
藤原氏：
そうですね。とりあえずこのプロジェクトを終わらせて、次のスクラムを行う時に、そのプロジェクト、そのスクラムでやることを考えた方がいいでしょう。
大西氏：
なるほど。実際に藤原さんは、現場にスクラムを導入しようとされた経験はありますか？
藤原氏：
従来型の組織がアジャイル開発を取り入れるのはよくあることです。その際、スクラムを導入する背景や動機がプロジェクトに適しているかが重要になります。スクラムを導入する動機とプロジェクトの適正が合致していればスクラムが適切でしょうし、逆に、スクラムが適さない場合は従来型で進めても良いでしょう。
すべてをアジャイルにする必要はないと思います。プロジェクトやシステム、チームの特性によって適切な手法を選ぶことが最良だと思います。
大西氏：
単にアジャイルを推進するのではなく、状況に応じてアジャイルを推奨しているということですね。
藤原氏：
実際、すべてのチームがアジャイル開発を採用するケースは少ないです。例えば、カスタマーサポートのチームは日常の運用の問い合わせに柔軟に対応するため、アジャイル開発が向いています。一方で、特定の大きな声を持つお客様を持つSaaSなどでは、期限が厳しいことが多いのでプロジェクトマネジメントの方が効果的です。
すべての部分をアジャイルにするのは理想的ですが、それを実現するには、大きな声を持つお客様もアジャイルの考え方に変わる必要があります。そして、そのためのトレーニングや教育にはコストがかかります。アジャイル開発は即効性を持つものではないので、現在の状態での成功を最優先とし、それからお客様と一緒にアジャイルへの移行を考えるのが良いと考えています。
テーマ④「予算と期限は、顧客と約束したり経営陣に約束する必要があるが、その場合はどうしているのか、どうすべきか？」
藤原氏：
エンジニアリングの仕事には納期や期限があり、それを守ることは最低限の責任だと思います。アジャイル開発であれ、従来型であれ、約束した期限を守らなければ信用が失われ、ビジネスが成り立たなくなります。約束を守らないと、売上が下がり、会社は困難に直面します。だから、約束は絶対に守るべきです。
この事実を前提に、約束を守る意識を持ちましょう。そして、予算や期限が決まっている場合、アジャイルか従来型か、どちらが約束を守れる方法なのかを真剣に考えるべきです。
ソフトウェア開発の難しさは、どのアプローチを選んでも同じで、予期せぬことが起き、残業や徹夜が必要になることもあります。アプローチの選択はチーム次第であり、その中で最適解を選ぶ必要があります。
予算や期限の重要性に応じて作業を進め、その範囲でスプリントの計画を立てるべきです。これが次のスプリントに回せるぐらいの余裕があれば、その前提で計画を立てることができます。そして、顧客もこれらの約束、期限、予算を正確に理解し認識する必要があります。
従来型の開発では、契約が結ばれ、期限が必須です。しかし、アジャイル開発では変更が生じ得ます。顧客や経営陣がこの柔軟性を理解していないと、計画作成段階で認識の齟齬が生まれやすくなります。
顧客が「アジャイル開発は期限を守らない」と誤解しないよう、「要求に柔軟に応えた結果、スケジュールが伸びた」という事実を理解する必要があります。
大西氏：
期限というのは、確かに難しいトピックです。
スクラムの開発を進めていく中で、当初の仕様や機能が次第に拡張されることがあります。初めは計画がきちんとまとまっていても、アジャイルの流れで新しい機能の追加などの話が出てくることは想定内です。その結果、プロジェクトのスコープが広がり、期限がずれることも考えられます。
しかし、特定のスプリントで目指しているゴールに関連するタスクは、しっかりと責任を持って達成しようとする姿勢は変わりません。このような考え方を持つことが重要ということですね。
藤原氏：
仰るとおりです。スプリントレビューや頻繁なリリースによって、外部からのフィードバックが多く寄せられます。これを迅速に反映できることが、アジャイル開発の強みです。しかし、期限を厳守する要求が強まると、全てのフィードバックを次のスプリントに取り入れるのは難しくなるかもしれません。それが続けば、チームは疲弊し、離職率の上昇やトラブルが起きるリスクが増えます。
重要なのは、どのリスクを取るのか、何を得るのかを明確にして、顧客や経営陣に伝え、彼らが意思決定できるようにサポートすることです。これをサポートするのは、スクラムマスターやチームの役割だと考えます。
長時間労働や品質の低下はアジャイルの考えに反するため、スケジュール調整の最善策はスコープの調整かもしれません。この考えを、開発チームだけでなくビジネスサイドにも共有することが大切です。
また、開発チームはふりかえり反省会を欠かさず実施すべきです。どうしたら次回より良くなるかを考えることで、顧客からの信頼を得られるようになります。このサイクルをしっかりと回していかないと、ただの遅延となり信頼を損なう可能性があります。
テーマ⑤「スクラムマスター視点では、メンバーに任せきりにすると少し不安な部分がある。任せられる人が居ない中でどう育っていくのか？どこまでやれば任せていいのか？」
藤原氏：
私はアジャイルコーチでありスクラムマスターではないのですが、自身がいなくてもプロジェクトが回るようにすることがゴールという点はとても似ています。
その際に重要なのは、プロジェクトメンバーへの任せ方です。任せきりにすると不安が生まれるということは、その不安の元があるわけです。チームの構成やシステムの複雑さなど、様々な要因が考えられます。
これらの問題を先に解決することが重要です。ただし、この解決法はスクラムだけでは足りないこともあり、システムや組織の特性に応じてアプローチを変える必要があると考えています。
解決方法として、以下の3つのパターンがあります。
コンサルティング：
この方法では、リーダーがメンバーに具体的なアドバイスを提供し、「こうやったらうまくいく」と指導します。このアプローチはメンバーの自立性を最も高めにくいと思います。メンバーはリーダーに頼りがちになるからです。
トレーニング：
トレーニングは、メンバーに「こうやったらうまくいくからやってみて」と助言し、実践させながらフィードバックを提供するアプローチです。時間と労力がかかりますが、メンバーが将来的に自ら問題を解決できる能力を育むことが期待できます。
コーチング：
最後のコーチングは、メンバーが既にトレーニングやコンサルティングを受け、ある程度の経験と判断力を持っている場合に適用します。リーダーはメンバーの自立した思考を促進し、自分で問題を解決できるようサポートします。メンバーが課題を持ちかけた際には、リーダーは「君はどう思うの？」とオープンに質問し、メンバーに選択肢を自ら考えさせます。そして、その選択肢から最も適切と思われるものを一緒に選び出します。これにより、メンバーは自ら考え、判断する力を培えます。
私自身も、これらのアプローチを段階的に適用し、最終的には私が不在でもメンバーが自立して動ける状態を目指して活動しています。
大西氏：
これはスクラムに限った話ではないと感じますね。
藤原氏：
まさにそうです。伝える技術として使えます。スクラムやアジャイル開発を導入する場合、初めにスクラムマスターの育成が大切です。ジュニアにはコンサルティング、ミドルにはトレーニング、上級者にはコーチングを行い、最終的には全員がコーチングできるように進めていきます。
その次に、スクラムマスター以外の教育が必要です。スクラムマスターだけが知識を持っても、現場とのギャップから認識のズレが生じる恐れがあるので、組織全体の知識の底上げを行います。
メンバーや経営層、マネジメント全体が、スクラムがどのような意味を持ち、現状がどうであるのかを理解することが大切です。教え方も工夫が必要で、すべてをコーチングだけで行うのは現実的ではありません。まずは教え方を見直し、それを組織全体に拡散させていくのが、セオリーとしては正しいと思います。
大西氏：
確かに。スクラムの概念として、ビジネスと歩み寄る動きがすでに組み込まれてるという感じですかね。
藤原氏：
そうですね。「POの意思決定を尊重しましょう」などが、スクラムガイドには書いてあったはずです。つまり、経営層が意思決定の邪魔をしてはいけません。条件や要望を述べるのは構いませんが、最終的な意思決定はPOに任せるという自律した自立文化を求めているので。そのためにビジネス側と開発側が協力体制を築く必要があります。
大西氏：
ありがとうございます。続いては、質疑応答に移りたいと思います。
質疑応答
質問「リソース効率の考え方に支配されていて、フロー効率の考え方にシフトできません。なんとなくサボってる感が出て、居心地悪かったり、メンバーに対しても、どこまでの余裕を許容すればよいかという部分の塩梅がわかりません。フロー効率の考え方が中心になった場合、余裕をどのように使っているのか、具体例があると教えていただきたいです」
藤原氏：
これはとても良い質問ですね。居心地の悪さやその感覚は重要だと思います。
本質的には、アウトプットをしっかり定義することが大切です。フロー効率を追求することのデメリットをアウトプットとして示し、それに基づき行動して結果を評価するのが良いと思います。
例として、ペアプログラミングを挙げると、2人で1つの仕事をするため生産性は半分になりますが、引き継ぎはしっかりとできます。
また、ジュニアに仕事を任せることで、短期的には生産性が下がるかもしれません。しかし、彼の成長により将来的には生産性が2倍になる可能性があります。
ゴールに向けた取り組みをすることで、居心地の悪さは無くなります。もし失敗した場合は、なぜうまくいかなかったのかを振り返ることが大切です。
そして、エンジニアとしてはきれいなコードを書きたいという願望がありますが、それだけでは伝わりません。きれいなコードがビジネスや自分たちにどんなメリットをもたらすのかを明確に伝えられるようなプレゼンテーション能力も大切です。
なぜなら、POはエンジニアの言葉を完全に理解できないこともあるからです。だからこそ、共通の言語でコミュニケーションする能力、例えばユーザーストーリーを使うことも重要だと思います。
大西氏：
なるほど。今、リソース効率とフロー効率が対立構造になっていて、リソース効率の方はリリース数とか目に見えるKPIが建てられてるけど、フロー効率については、将来の投資みたいなところの、言語化しづらいKPIについて考える必要があるということですね。
いかにどう言語化していくか。将来の投資なのか、技術負債がなくなることで、将来の速度が速くなるとか、そこを言語化することが大事だと、今の説明を聞いて思いました。
藤原氏：
最近、お客さんとの会話で、リソース効率とフロー効率について話をしました。あるラーメン店の例を挙げると、お客さんが個室のような座席に座り、他の人との交流が少ない設計になっています。これは、お客の流れとしてリソース効率が非常に高いです。
反対に、フロー効率を考えると、中華街の円卓のような形になります。ここでは、皆が一つの皿を共有し、お互いの食べ物を勧め合うスタイルです。しかし、ラーメン店の場合は他の席のラーメンを取ろうとは思わないですよね。
ラーメン店も円卓も、それぞれに良い点があります。どちらが良いかは、現場や好みによるので、一方が優れているわけではありません。どちらも良さがあると感じています。
質問「スクラムマスターをしています。デイリースクラムなどでチームの発言が少ないなど自主性が低いと常々感じています」
藤原氏：
この問題についてはさまざまなアプローチが存在するので、いくつかの方法を紹介します。
昔の私なら、チームメンバーに「話さないのであれば、会議に参加する必要はない」と伝えていました。Slackなどのツールを使えば直接の対話が不要だからです。そして、会話が必要なポイントを明確にして提供することが大切です。
例えば、「昨日の活動や今日のタスク」ではなく、「スプリントゴールの達成が可能か？」のような具体的な内容に絞ると、効果的なコミュニケーションが可能です。
また、使用するツールの選択も重要で、Slackで十分なコミュニケーションが困難であれば、方法を再検討するなど、柔軟にアプローチを変えることが大切です。恐れずに変更を繰り返し、最適な方法を模索することをおすすめします。
問題として自主性が挙げられていますが、初めから高い自主性を求めるのは難しいかもしれません。そこで、自主性を育むための手法やワークショップを採用することが考えられます。
例として、私が過去に体験したアジャイル開発のワークショップを紹介します。参加者に複数のWikiの画像を見せ、それに関連するページのタイトルを推測させるものです。ただ画像を見て答えを想像するだけでは難しいため、質問を重ねることで答えに近づけます。
自主性が低いチームでは、質問が控えめになることが多いです。しかし、正確な答えやゴールに到達するためには、多くの質問やコミュニケーションが必要です。このワークショップを通じて、スクラムやアジャイル開発の中でのコミュニケーションの重要性を体感することができます。
これは「質問とコミュニケーションがゴールへの近道である」という考えを伝えるトレーニングとして役立つかと思います。
大西氏：
自分の現場で経験上、無言の時間を恐れずに受け入れることも、時には大事だと思うんです。スクラマスターが「このままでは何も進まない」と思わず、一度手を離して任せてみる方法も、効果的なアプローチの一つかもしれませんね。
藤原氏：
まさに、そのとおりです。沈黙の時間は考える時間。それを中断することは避けるべきです。もし考えるのに時間がかかるのであれば、事前に準備をしてもらえば良い。即答を求める場ではないので、良い意見を引き出すための仕組みや方法を取り入れるのも考えられますね。
質問「研究開発に近いタスクの粒度の目安を教えてください。長い時間達成できず、バックログに貯まりがちになってしまいます」
藤原氏：
長い時間かけても達成できない事項、特に新しいチャレンジや新技術に関しては、見積もりに難しさが伴います。
王道的な方法としては、「スパイク」のような形で短い期限を決めて、見積もりのための材料や情報を集めることが考えられます。例えば、半日や1日を設けて具体的な調査や検証を行い、それを基に見積もりを再評価する。このような手法で、実際の作業に必要な時間やリソースの目安を適切に設定していくのです。
実際のスプリントを進めている中で、計画通りに進まないこともあります。その際には、再び短期的なスパイクを実施するなど、適切に再見積もりや調整をする必要があります。
最も避けるべきは、明確な期間を設定しないこと。例えば、スプリント全体をそのまま使用することは適切ではありません。短い期間での評価や検証が望ましいです。
質問: 「スクラムにこだわる必要がないと判断する場面や条件など、判断基準を聞かせてください」
藤原氏：
実際の判断基準は「プロジェクトの見通し」です。もし半年後の目標や成果物が明確に定まっているのであれば、従来型のプロジェクト管理方法で問題ないでしょう。
一方、半年後の具体的な成果がはっきりとしない場合は、スクラムなどのアジャイル手法を用いることで効果的な結果が得られるかもしれません。
質問「おすすめのベロシティ計測方法があれば、教えていただきたいです。また、計測にあたっての注意点があれば教えて欲しいです。」
藤原氏：
もしタスク管理ツールを使用している場合、ストーリーポイントという項目を設け、それを合計するだけで良いと思います。
もし使っていない場合は、スプレッドシートなどに見積もりの合計値を記入すればいいでしょう。重要なのは、見積もりを実施し、その結果を合計して、スプリント内での実績としてのベロシティを求めることです。そして、そのトレンドを追って、必要に応じて調整を行うことがポイントです。
質問「チームが簡単に解散されて、スクラムが継続しない」
藤原氏：
アジャイル開発の基本的な考え方は、1つのチームで継続的に活動し、その練度を高めていくことですね。この考え方をベースにして、プロジェクト型のチームの方法を見直す必要があるかもしれません。何かしらの理由で現在のスタイルを採用していると思いますが、その背景を考慮して、スクラムやアジャイル開発が本当に適しているのかを検討することが重要だと感じます。
私が関わっているスクラムチームは基本的にメンバーが変わらないものが多いです。もちろん、たまにはメンバーの入れ替えも起こりますが、そのような安定した現場をどのように築くか、それが成功への鍵かもしれません。
質問「スクラムマスターの成熟度や信頼度に依存して、スクラムを正しく使えてない」
藤原氏：
初めてのことに取り組む際、皆初心者としてスタートします。その状態から成長を遂げるためには、トレーニングを受ける、専門の本を読むといった方法で学びを積むしかないと思います。
特にスピード感を持ってスキルアップしたい場合は、アジャイルコーチのような専門家と一緒に働くことも選択肢として良いでしょう。人それぞれ進化のペースは異なりますが、おおよそ3ヶ月で基本を掴むことができ、半年や1年の指導を受けることで、もはやアジャイルコーチのサポートなしで活動できるレベルに達することも可能です。
各チームや個人の目指す成長の速度に応じて、最適な方法を選んで進めることをおすすめします。
質問「スプリントゴールが実際のゴールにならない。例）バックエンドチームのAPIは完成してるけど、フロントは完了していない」
藤原氏：
理想としては、一人のエンジニアがゴール全体を担当できる状態、つまりAPIからフロントエンドまでを一手に扱える状態が最適です。これは「フィーチャーチーム」の考え方と一致しますね。松竹梅の中での「松」に該当する解決策状況がこれこかもしれません。
ただ、現実はそう簡単にはいかないことも多いでしょう。できない場合のアプローチとしては、一つの方法として、プロダクトをバックエンドとフロントエンドの2つに分けることですが、これには結合時の課題が出る可能性も考えられます。
もう一つの手法として、一つのストーリーを2人のエンジニアが共同で取り組む、ペアプログラミングのような方法が考えられます。具体的には、APIのインターフェースを最初に2人で定義し、それぞれがそのインターフェースに沿った開発を進め、最後に結合するという流れです。近年のツールや自動化の進化もあり、この方法は現場での実際の取り組みとしても効果的に利用されているようです。
大西氏：
バックエンドチームとフロントエンドチームの間に歩調の違いを感じることからこの質問が生まれていると思います。最適な状態は、フィーチャーチームとして、フロントエンドと関連する実装のメンバーとバックエンドチームが、効果的に連携を取ることではないでしょうか。
もちろん、実際のチームの事情によっては難しいかもしれません。その詳しい状況について深く知る必要があるかと思いますが、上記のような回答が適していると感じます。
質問「POがプロダクトの将来構想を持っていない」
藤原氏：
POの教育は必須で、スクラムマスターがそれを担当しなければならないと思います。チームはPOをサポートし、企業は彼らの業績を適切に評価すべきです。何の構想もなしにプロダクトを作ることはできません。
スクラムマスターは、必要に応じてPOに指導すべきです。外部のトレーニングやコンサルタントを取り入れるのも一つの方法です。また、経験豊富なPOをメンターとして迎え入れる提案も考えられます。
結局、スクラムマスターの役目は「どうしたらうまくいくのか」を探求することです。それをPOのために実践することが、最も有益だと感じます。
質問「POが他部署で連携しづらい」
藤原氏：
多くの企業で開発とPOの部署が分かれているのは実際のところ珍しくありません。その背景には評価基準が異なる、といった理由が挙げられるかと思います。それに対する対策として、会社の全体的な構造を見直す方法や、POと具体的に連携の問題点について話し合い解決策を模索する方法が考えられます。
別部署にPOがいる場合でも、うまく機能するチームの存在は確かにあります。そのため、部署を跨いで連携する方法を模索するのか、それとも同じ部署にまとめる方法を選択するのか、この2つの選択肢から最適なものを選ぶことが大切になります。
大西氏：
フィーチャーチームの考え方を取り入れれば、異なる部署に属していても、例えばPOやフロント・バックエンドのエンジニア、場合によってはSREやQAを含めて、一つの機能を担当する仮想的なチームを形成することができると思います。このようなアプローチで、部署の枠を越えた連携を強化することも可能だと感じますね。
質問「請負契約、住宅契約においてアジャイル開発ができないと認識しているのですが、認識あっていますでしょうか」
藤原氏：
期限やスケジュール、そして予算が設定されている場合、確かに従来型のアプローチが適しているかもしれません。例として、アジャイル開発で始めると、変更に柔軟に対応しながら進行します。しかし、結果として初めに想定していた機能が完成しない可能性も出てきます。そのようなリスクを受け入れるのであれば、アジャイル開発も選択肢として考えられます。
大西氏：
つまり、期限を厳守する必要がどれだけあるのか、また、プロジェクト開始時に決めたスコープを途中で変更しないという前提が保たれるのか、ということがポイントになるわけですね。
藤原氏：
そのとおりです。スコープを変更する余地があれば、アジャイルが適しています。しかし、スコープの変更が許されない場合、リスクは高まりますので、従来型のアプローチの方が適切でしょう。
質問「リファインメントがどこまでやればいいか難しい」
藤原氏：
タスクの内容は各々異なるでしょうが、開発後にテストとリリースがスムーズに進行できる状態であれば良いと思います。
開発が開始できる「Ready」の状態かどうかは、開発者自身が判断するのが最適ではないでしょうか。もし、軽微な疑問点などがあったとしても、それが大きな影響を及ぼさないのであれば、そのまま作業を進めて問題ありません。
しかし、詳細な計画や確認が必要と感じる場面に遭遇した場合は、しっかりとその部分を対処するべきです。
質問「スプリント計画を立てるのが難しい」
藤原氏：
スプリント計画は、実は従来型の計画よりもずっとシンプルです。というのも、理想的な状態や時間の詳細な見積もりをする必要がないからです。スプリントでは、実際にやった作業の量を基に計算するだけです。もしかすると、人々が従来の方法に慣れているせいで、アジャイルの見積もりに戸惑っているのかもしれません。
従来の方法でアジャイルの見積もりが難しいなら、一度スプリントを回してみて、例えば自分たちのベロシティが100と判明したら、次のスプリントではその100を目標としてタスクを入れるだけです。見積もりが合わなかった場合には、見積もりそのものを見直せばよい。これにより、スプリント毎にタスクを完了させることができるチームが形成されると思います。
大西氏：
実務の現場での経験として、あるタスクが1スプリントでは完了しないと予想される時、スプリント計画の立て方が難しく感じました。たとえば、大きな開発タスクがあり、それが2スプリントや3スプリントかかると予測される場合、その間のスプリントで具体的にどんな目標を持つべきなのか、悩むことがあります。1スプリントではタスクが途中までしか進められない時、どのように考えれば良いでしょうか？
藤原氏：
タスクを小さくすることです。MVPのように、小さい単位でも価値を生む形にまとめる必要があります。もしタスクの小分けが難しい場合、それはシステムやフローに何らかの問題があるかもしれません。その際は、タスクを小さくできるようなシステム構築を考慮すると良いでしょう。
大西氏：
私の場合、1つのスプリントの中でスプリントレビューを設けています。そのため、ステージング環境でも良いので、スプリントレビュー時にデモンストレーションできる程度の完成度を目指してプロジェクトを進めています。スプリントの最後にスプリントレビューを持つことで、具体的な目標に向かって作業がやりやすくなったと感じています。
藤原氏：
確かに、大規模なプロジェクトはその扱いが難しく、システム的な制約もあって、例えば3スプリントでの完了ということになることもありますね。その場合、全体として10スプリントで終わるプロジェクトだとすると、1スプリント目で10%を完了するというのは目安として設定するものの、その具体的な10%をどう定めるかは実際には難しい課題です。
このように計画がずれるリスクが増えるアプローチをとるのであれば、その特定の部分はスプリントから切り離して、時間ベースで逆算して取り組む方法を検討する価値があるかもしれません。全てをスプリント方式で強引に進めるよりも、一部を従来の方法で進める方が、リスクを管理しやすくなる可能性があると感じます。
質問「メンバーの個性が強い、コミュニケーションが苦手なメンバーが多いのに、自律的なチームは成立するのか」
藤原氏：
これは特定の開発手法の問題ではなく、むしろ一般的な考え方に近いのですが、アジャイル開発の中では「全員が同じバスに乗る」というフレーズをよく耳にします。つまり、ステークホルダーや関係者全員が同じ目的に向かって一緒に進むということです。
しかし、このチームの中にコミュニケーションを避ける人や、特定の強い個性を持つ人がいる場合、そういったメンバーをどう組み込むかが問題となります。単純に言えば、チームが効果的に機能するための組成を考えるべきです。強い個性を持つ人のために全体を変えるのは適切ではありません。その結果、努力している他のメンバーが不利益を受けることがあり、最終的にはチーム全体が機能しなくなる可能性があります。
高い目標や理想に向かって、全員が一致団結して進むことが大切です。特定のメンバーの個性に合わせて特別な対応をすることは、長期的にはチームのためになりません。
大西氏：
理想や目標を明確に言語化し、基準として設定することで、全員が一つの方向を向いて取り組めるわけですね。
藤原氏：
そのとおりです。共通の理想や目標のもとで集まることで、一致団結して努力できます。もし、個性が強くてその目標に賛同できない人がいるなら、そのチームに参加しない方が良いかもしれません。
一方で、目標に賛同しながらも、個性的なアプローチや考え方を持つ人には、その考えや背景を尊重し、しっかりと耳を傾けることが重要です。
質問「受託開発でスクラムマスターをしていますが、開発の実務を行わず、プロジェクト管理もしないとされるスクラムマスターの存在価値に悩んでいます」
藤原氏：
私も同感です。経験や慣れによるものかもしれませんが、1日をスクラムマスターとして過ごすのはなかなか大変ですね。100人規模で10チームの場合、専任のスクラムマスターがいてもいいかもしれませんが、それより少ない規模の場合、本当に専任のスクラムマスターが必要か、という疑問も感じます。
確かに、理論的には「スクラムマスターは専任であるべき」との意見もありますし、その役割でしっかりと価値を発揮できる場面も確かに存在します。
例えば、10チームがある場合、それぞれのチーム間の障壁を乗り越える役割や、経営層とのコミュニケーション、組織の変更に伴う人事の部分まで関与するなど、スクラムマスターの役割は広がりますね。
このような状況下でのスクラムマスターは、経営やマネージメントの側面とも重なる部分があるかもしれません。そういう役割を担った人たちがスクラムマスターになることで、スクラムマスターの存在価値が本当に発揮されると私は感じています。
質問「いくつかのスクラムやプロジェクトをメンバー全員が兼任している場合の、スプリントのプランニングのコツや、考慮すべき点はありますか？」
藤原氏：
兼務すると、確かにイベントの数が増え、これはアンチパターンに陥りやすくなるかもしれません。例えば、複数のチームをサポートしているPOは、全てのレビューに参加する必要が出てきます。そのような問題を解消するためのアプローチを模索するべきです。集中し、仕事の量を減らし、一つ一つの要点に焦点を当てて取り組む方が効果的だと感じます。
確かに、兼任の際のリスクに関するディスカッションもありました。リスクをどのように取り扱うか、放置するか、またはスピードを落とさずに兼務を進めるのか。これらの認識をチーム内で共有し、整えることによって、多くの悩みや問題は解消できるのではないかと思います。
質問「周りが導入してるからという理由で導入して、魔改造してよくわからないスクラムをやってしまう」
藤原氏：
私は、失敗が成功への一歩だと信じています。多くの場合、一度の失敗の後には成功が訪れることが多いです。したがって、何かがうまくいかなかったと感じることも必要です。
しかし、その後どう対処するか、何を学び取るかが重要です。失敗を経験し、その教訓を活かして前に進めるスクラムマスターは、非常に価値のある存在だと私は考えます。
質問「業務委託の方チームに入れざる入れざるを得ないような時に、チームとしての認識を揃えきれません。自律的に働くという意識を共有しきれないのです」
藤原氏：
確かに、それを求めるのは難しいと思います。契約内容にもスクラムに貢献するといったようなそこまでの記載はないでしょうありません。できる方はできますし、一方で難しい方もいるでしょう。
解決策としては、その業務をこなせる人を探す、社員として採用する、あるいは少し直接的な表現かもしれませんが、その人のスキルや考え方に合ったタスクをアサインする、といった方法が考えられます。
質問「プランニング後のタスク細分化に時間かかるのは普通でしょうか？」
藤原氏：
多くの場合、タスクの細分化はエンジニアのために行われるものです。自分たちが理解しやすい粒度であれば、どのような細分化の方法でも良いと私は考えます。実際、ストーリーから直接作業を始める場合、タスクの分割が不要であることもあるでしょう。
重要なのは、タスクを細分化すること自体を目的としてはいけない、という点です。さらに、ユーザーストーリーを作成する際にも、これに関するディスカッションを早めに始めると良いかもしれません。
質問「職能型で採用している組織で横断型のチームを作りたいと思っていますが、アプリのエンジニアはAndroid、iOSそれぞれ1人ずつしかいないみたいな時に、アプリのメンバーはスクラムから除外した方がやりやすいと思うんですが、そのあたりの過去の経験、このようにしたとかあると聞いてみたいです」
藤原氏：
確かに、一つのアプリをAndroidチームとiOSチームで分けて開発する場面では、このような課題はよく起きます。例えば、Androidで実現可能な機能がiOSでは実現できないこともありますね。理想としては、AndroidもiOSも両方の機能を開発できる万能のチームが存在することがベストでしょう。しかし、現実的にそれは難しいので、チームを分けるのが現実的でしょう。
そうなると、職能も異なるわけですね。その状況で、AndroidとiOSが共通の目標に向かい、効率的に動ける方法を模索することが必要です。そして、それを実現するためにはスクラムから一部を除外することも考慮すべきです。そのような選択も、最終的にはプロジェクトにとって良い結果をもたらすのではないでしょうか。
質問「すでにプロマネがいるチームの場合、プロマネがいらないという思想が受け入れられないんです」
藤原氏：
確かに、プロジェクトマネージャー自体が必須とは限らないかもしれません。しかし、プロジェクトマネジメントという機能は必要です。
プロジェクトマネージャーがそれを主導するのは一つの方法ですし、プロジェクトマネージャーを中心とした管理も全く問題ではありません。
ポイントは、自律性を追求するか、プロジェクトマネージャーを中心とした管理で安定性を確保したいか、という選択ですね。最適な方法は現場の状況や好みに応じて選べば良いと考えます。
大西氏：
スクラムの手法を採用しつつ、プロジェクトマネジメントの役割をプロマネに頼るというケースも考えられるんですね？
藤原氏：
そうです。プロジェクトが存在する限り、プロジェクトマネジメントは避けられません。その役割をどんな形で果たすかは選択の問題です。プロジェクトマネージャーの主導でうまくいけば、それがベストです。一方、チームが自律的に動きたいと考えるのであれば、アジャイルのアプローチが適しているかもしれません。
