ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

ベストプラクティスもアンチパターンも、それ自体は何も解決しない(かも)

みなさんこんにちは。@ryuzeeです。 2026年3月4日に新刊の訳書『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』がオライリー・ジャパンから発売になりましたのでよろしくお願いします。

本記事は、先日Xに書いた記事の転載です。


勉強会やイベントなんかで色んな人から相談を受けるんですが、そのなかで多いのが「他社の事例ありませんか?」「ベストプラクティスを教えてください」「アンチパターンが知りたいです」みたいなやつです。

その気持ちめっちゃよくわかります。ぼく自身もアジャイル開発を始めたときに、さんざんネットを検索して色々探しました(自戒)。 でも、この時点で罠にハマっているかもしれないんですよね。

事例くれくれ君は他社の正解?をコピペしたい

「エンタープライズでの〇〇の事例ありませんか?」みたいに聞いてくるとき、その質問の裏側にあるのは「他社でうまくいってるやつをパクれば参考にすれば、うちでもうまくいくのではないか」という思考です(上司の許可を取りやすいとか稟議を通しやすいとか、そういうのもあります)。

でも、他社のベストは自分の現場のベストとは限らないんですよねぇ。生成AIでもわかるように、「文脈」が違えば答えは変わります。 業種、組織の規模、組織のルール、プロダクトの性質、ステークホルダーの顔ぶれ、チームのスキルなんて各社バラバラだし、大きな会社になると部門単位でも全然違います。あちこち違うのに表面だけ真似しても意味がありません。

単にコピペするのは、自分の頭で考えることを放棄しているだけだし、うまくいきません。 事例自体は参考になることも多いですが、自分でよく考えましょう。

ベストプラクティス漁りも同じ

「みんなやってるから」「うまくいくらしいから」で何か評判になってるプラクティスを導入したところで、なぜそれが効果を発揮するのかを理解していなければ、形骸化や悪用が起きるだけです。

スクラムの現場で、昔からよく使われてきたプラクティスの1つに「ベロシティ」があります(色んな本に出ているので、ベストプラクティスに近い位置づけなのではないかと思います)。 スクラムでは「知識は経験から生まれ、意思決定は観察に基づく」として経験主義を重視しています。 そして透明性、検査、適応の3本柱をもとにプロダクトやプロセスなどさまざまなことを改善し、大きな効果を得ようとします。

ベロシティはそのための道具の1つで、自分たちの力量を見える化して、今後の改善や将来の予測などに使います。 つまり、スクラムチームが、自分たち自身のためにツールの1つとして使うわけです。

で、こういう原則や背景を理解していないと、ベロシティが報告対象になったり、ベロシティを約束したり、外部からベロシティを上げるように言われたり、他のチームと比べられたりするのを止められなくなってしまいます(数字で見えるものは何でも欲しがるのがステークホルダーw)。

アンチパターンを避ければそれでいい、というわけでもない

プロダクト開発の定番アンチパターンは「兼務」です。よく見ますよね。組織の規模が大きくなるほどよく見るようになります。 「避けろ」と言って避けられるのであればそれはそれでよいのですが、会社には色々な事情があるので「そんなの理想論で無理」みたいになりがちです。で、そこで止まってしまうと何も得るものがありません。

このアンチパターンの背景にはさまざまな要素がありますが、とくに大きいのが「集中の阻害」と、「フローへの悪影響」です。 プロダクト開発のような難しい仕事は細切れの時間ではできません。考える時間や作業する時間をまとめて取って、1つのゴールに集中しなければいけません。また集中せずに複数の仕事を同時に進めれば、仕掛中の時間が単純に伸びます。その間は何の価値も生み出していません。 これを避けるために「兼務は危ない」と言われるわけです。

以上を理解していれば、「うちの会社じゃ無理。以上終了」ではなく、現状の制約のなかでどうすれば集中できるのか、どうすればフローを短く維持できるのか、別の方法を考えられるようになります。たとえば以下のようなものです。

  • 時間で割らずに期間で割る(今週はAプロダクト、来週はBプロダクト)
  • 専任メンバーと、支援や専門職系の限定的関与を区別する(本当に重要な人から専任にする)
  • コアタイム制で集中時間を確保する
  • もちろん並行して、兼務をなくす組織的な努力をする

ちなみに、アンチパターンを避けたところで、プロダクトは失敗することのほうが多いし、アンチパターンを踏みまくってプロダクトが成功することもあります。まぁそんなもんだよ。

根底にある原則を理解しないと意味がない

ここまでの話でわかるとおり、重要なのは背景にある原則を理解することです。 事例やベストプラクティス、アンチパターンっていうのは、原則の表現方法の一形態に過ぎません。

ベロシティの話で出てきたのは、経験主義(透明性・検査・適応)の原則で、兼務の話で出てきたのは、集中とフローという原則でした。 ほかにも、たとえば「ステークホルダーの言いなりになっちゃう」みたいなアンチパターンの裏側には、価値駆動と顧客との協調という原則があります。それぞれのプラクティスやアンチパターンの裏側には、必ず何らかの原則が隠れているわけです。

原則さえ押さえていれば、似たような問題が形を変えて現れても応用が効きます。「集中とフローを大事にしよう」と理解していれば、兼務だけじゃなくて、長すぎる会議とか、割り込みタスクの常態化とかも、ぜんぶ同じ枠で捉えて対処できるようになります。逆に原則を理解せずにプラクティスだけを覚えると、「うちには合わなかった」「あれはうまくいかなかった」で終わってしまいます。それは合う合わないの話じゃなくて、何のためにそれをやるのかを理解していないだけかもしれません。

ということで、他社の事例を漁る前に、ベストプラクティスを集める前に、アンチパターンのリストを眺める前に、どの原則を満たそうとしているのかから考えてみるといいと思います。原則を理解していれば応用が効きます。

ちなみに、プラクティスは「仮説」として扱うのが健全です。導入して、観察して、効果がなければやめる。違和感を覚えたら元に戻すか別のやり方を試す。短いサイクルで検査と適応をしていれば、間違っても取り戻せます。「後戻りできない」と思い込んでズルズル続けるほうがダメージが大きいです。

同じことが最近の生成AI関連のプラクティスにも当てはまるかもねー。

詳しくは登壇したときのスライドにまとめたので、興味があれば以下を参照してください。


それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 「PdM廃止」という言葉に振り回されない

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World