前回のコラムで、なぜアジャイル開発なのか？というWhyを問い直しました。いかがでしたでしょうか。十分にアジャイルに取り組む理由があると判断できたでしょうか。では、さっそく来週からスクラムを始めましょう！…と言うには早計かもしれませんよ。「え、アジャイル開発って、失敗から学べというスタンスで臨むのではなかったっけ？」と思われるかもしれません。今回は、勢いで進めた際に起きがちな問題を捉えることから始めましょう。
いきなりアジャイルの問題
問題は3つあります。
1. 自分たちの組織、現場との適合性の問題
来週であろうと、来月であろうといきなりスクラムを始めようとした場合、どうしても教科書に従った実践にならざるを得ません。スプリントの長さはどのくらいにするべきか？スプリントプランニングは何時間くらいで、スプリントレビューを仕切るのは誰がやるべきか。こうした課題に数多く直面することになります。
実践にあたっては一つ一つ、これらの課題について方向性を決める必要があり、その決定根拠のために世の中にある教科書や事例を引いてくることになります。幸いにして？経験者がいたりするとその人物の経験を適用しようということになるかもしれませんが、外から持ってきた知識をそのまま適用としているならば、教科書や事例に倣うのとあまり差はありません。なぜでしょうか？
皆さんの現場の外側にある知識には何らかの前提としている背景、文脈が存在します。これらが、皆さん自身とあっているとは限らないためです。
・組織やチームのあり方
どこを目指していて、何を大切にしているのか、そのためにどういう体制や働き方を取っているのか。
・プロダクトの性質
どのような戦略の下で開発していくのか（例えば、不確実性の高い領域なので価値の探索が必要であるとか。市場の2番手なので王者にぴったり追随していくが必要であるとか）
今何を狙っているのか（例えば、価値検証が終わっていないため、まずはMVPを提供して検証を行う段階であるとか。既に何が価値かは分かっているので機能の作り込みを進め、安定的に稼働させる必要があるとか）
こうした内容は、背景、文脈の一端です。自分たちが向かっている何らかのミッションの実現、そのためのあり方ややり方、優先する基準。これらが外から仕入れてきた知識が前提としていることと一致しているのかどうか、丁寧に見極める必要があります。
2.影響範囲の問題
スクラムを実施しようとすると、当然プロダクトオーナーという役割があり、ステークホルダーと呼ばれる関係者の巻き込みを考慮する必要があります。プロダクトオーナーは、プロダクトの企画者であったり、事業責任者であったり、ステークホルダーは組織マネージャーであったり、営業・マーケティングなどの他部署、場合によって経営陣であったりするでしょう。
このように、小さく始めようとするものの、関係者の巻き込みがある程度広範囲に及ぶことになります。たとえ、チームがアジャイルへの取り組みに意欲的だったとしても、他の関係者、部署の人たちが必ずしも同じ考え方にあるとは限りません。アジャイル開発とそこに宿る価値観を知らない人たちとの取り組みになるわけです。「やってみての失敗」への見方が異なっても然りです。
取り組んでみて、思ったような成果があがらないとき、「アジャイルはやめたほうがよい」という判断がなんとなく大勢を占めてしまったとき、「失敗から学びを得てアジャイルに取り組みなおす」という主張を通すのは、最初の頃よりも格段にハードルが上がっている可能性があります。関係者が多いほど、その調整先も広くなります。ですから、「失敗から学ぶ」という精神は宿しつつも、推進者以外は必ずしもそういう考えではないという点を踏まえて、取り組みへの段取りを丁寧に行うことが求められるのです。
3.取り組みにあたって、そもそも相応のレベルを求められる
スクラムガイドには「軽量、理解が容易、習得は困難」と説明されています。そう、理解は容易だが、習得は難しいと言っているのです。アジャイル開発とは、エッジの効いた先達者たちが学びの上に学びを積み上げてきた実践知のかたまりなのです。難しい、失敗する可能性が高い、だからこそ、適用局面を選ぶ必要があるのです。ひとまず反復的な開発スタイルだけを適用しようとしたところで、それが事業の根幹にあたるプロダクト開発の場合、気軽に失敗するというノリではあたれないのではないでしょうか。
今回のコラムでは、1つ目の適合性の問題にどのように臨むのかについて扱いたいと思います（2つ目の問題は「段階の設計」が必要で、今後このコラムシリーズの中で扱う予定です）。
自分たちで考える
アジャイル開発にまつわる数々のプラクティス（習慣）は、基本的にアジャイル開発宣言および、その宣言の背後にある原則に立脚しています。
アジャイルソフトウェア開発宣言
https://agilemanifesto.org/iso/ja/manifesto.html
アジャイル宣言の背後にある原則
https://agilemanifesto.org/iso/ja/principles.html
この宣言と原則を知っている方も多いと思います。ですが、これらの宣言と原則を自分たちの組織、現場を前提に置いて捉え直したことはあるでしょうか。例えば、数学の問題を解くのに、定理や原則は必要不可欠です。ですが、原則がどうして成り立っているのかを理解していなければ、ただルールを覚えているだけで、暗記の問題になってしまいます。それでは、分かりやすい問題は解くことができても、応用が効きません。
プラクティスの背景にある原則がどのようなもので、その原則はそもそも自分たちの現場ではどう捉えられるのか考えることで、どういう手段を選択すればよいか見えてくることになります。
例えば、原則に「動くソフトウェアこそが進捗の最も重要な尺度です。」というものがあります。では、この動くソフトウェアを確認するのはどのくらいの間隔であるべきなのでしょうか。「状態が捉えられていない間隔=作っているものや、作り方が間違っている可能性がある期間」と捉えると、間違いを許容できる期間と言い換えることができます。それは、1ヶ月でしょうか？それとも1週間でしょうか？その回答は私にはではなく、現場にあります。これが背景や文脈を踏まえて、考えるということです。
さて、では具体的にどのように原則を捉え直していきましょうか（アジャイルの価値観からより遠いと感じる現場の場合は、宣言から捉え直しましょう）。
まず、12の原則を疑問形で読み替えてください。つまり、
- 「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く必要があるか？」
- 「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることですか？」
- 「シンプルさ（ムダなく作れる量を最大限にすること）が本質ですか？」
といった具合にです。そして、それらをまず自分一人で答えてみてください。あなた一人です。チームではありません。もちろん単なるYes、Noで終わりではなく、その理由を言語化するのが大事です。あなたの現場での理由を答えてください。
自分なりの言語化したら、次はチームで向き合います。先に一人で向き合う理由は、同調圧力（なんとなく大勢に従ってしまう傾向）を避けるためです。チームで向き合う際は時間の制約があったり、発言力の強いメンバーがいたりと、本質とは別のことでミスリードされてしまう可能性があります。当然、先に自分が考えているからといって今度はあなたがミスリードする役割に回らないように気をつけてください。向き合いの場で必要なのは、解ではなく、問いです。
こうした場に、専門家は必要でしょうか。アジャイルの経験豊富な専門家やメンバーがいると心強い気がしますね。確かにそうなのですが、専門家の役割は「書いている内容を理解できるようにするため（例えば「自己組織的なチーム」とは何なのかなど）」と、目線の上げ下げです。自分たちだけだと、経験が限られます。自分たちが知っていることの中で判断をしてしまおうとして、目線が低くく成果の上がらない方向性や、逆に高すぎて土台無理な取り組みを行おうとする方向性に振れてしまう可能性があります。こうしたときに専門家に目線の状態がいまどうなっているか示唆してもらうと良いでしょう。
自分たちで考える。まずここから出発することです。
