この記事は freee Developers Advent Calendar 2022 の3日目です。
このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます）
前提: アジャイル開発とは
アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でその価値の優先度を示しています。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
また、その価値を実現しようとする上で、アジャイル開発には行動の原則が定められています。
スクラム開発やXPはこれらの価値や原則をより具体的に方式に落としこんだフレームワークで、価値や原則から逸脱せず実装された方式になります。したがって、スクラム開発などを実践するときはこれらの価値や原則を守る必要があります。
アジャイル開発を導入するよくある状況
よくあるアジャイル開発が注目される要因は、価値や原則にも記載がある「変化への適応」というものがあります。具体的に言えば、価値の観点で言えば、
計画に従うことよりも変化への対応を、
であり、原則では、
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
に示されるものです。また、リリースが早いという観点も注目される要因かと思います。具体的には原則でいえば、
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
(snip)
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
というふうに表現されます。
確かに直感的にこの状況は好ましく感じることができ、これを目指してアジャイル開発手法を取り入れることはよくあることです。そのような状況下で、スクラム開発というのはアジャイル開発を実践する上で、シンプル・軽量であり、なおかつ実践例が多いので導入を決めやすいのか採用が多く、人気のフレームワークとなっています。
スクラム開発はスクラムガイドにその内容が全てのっており、そのPDFは日本語版で17ページととても短いです。なので、導入を決めたチームは全員かまたは導入を決めた人がガイドを読み、チームにスクラム開発を説明し、実際にやってみるという流れが多いでしょう。
スクラムガイドはシンプルだが、奥深く、難しい
皆さんはスクラムガイドでどの部分が一番大事でしょうか。経験者がいない、もしくは経験が浅い人が読んで一番学びを得やすいのは「スクラムチーム」と「スクラムイベント」、「スクラムの作成物」の章なのではないでしょうか。もちろん最初の方の「スクラムの定義・理論・価値基準」も読んではいると思いますが、この「チーム・イベント・作成物」の章はより具体的なスクラムの実装に踏み込んだ内容になっているので、これからスクラム開発をやろうという状態ではこの章をよく読むと思います。
しかし実際読んでみると、分量は少なく読みやすいですが、「つまり具体的にはどういうことをすれば良いのか？」というのが説明されていません。これらの多くは「目的」は記載されていますが、「何を」「どうする」という観点の記載はほぼありません。例えば、「デイリースクラム」というイベントには、目的と、費やす時間、参加者、場所は書いてますが、どのようなことを実際行うかというのは一切記載がありません。スクラムの経験者は自然に「昨日やったこと」「今日やること」「困っていること」のような質問を一人ずつ回すというやり方を過去の経験から想像することが多いと思いますが、スクラムガイド自体にはその記載はありません。これは考慮が不足しているのではなく、「スクラムの定義」の章にある以下の言葉を体現しています。
スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。
スクラムガイドはすべてを表現していません。具体的な手法は自ら考える必要があります。そしてその過程で必ず、スクラムの理論に適合しているか、適合するためには何をしなければならないかを検討する必要があります。例えば先程出てきたデイリースクラムにおける「昨日やったこと」「今日やること」「困っていること」が理論と適合するためにやっていることはなにかあるでしょうか？実際に考えてみましょう。
スクラムガイドによれば、その理論は以下のような表現があります。
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採⽤している。
(snip)
スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。
スクラムの三本柱の詳細は実際に読んで確認してみてください。ここでは長いので省略します。スクラムは全てのイベントでこのスクラムの三本柱である「透明性」「検査」「適応」を実現させ、これらを実現することで、予測可能性の最適化とリスク制御を行っています。 そして、「デイリースクラム」は以下の目的で実施されます。
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
デイリースクラムにおける三本柱を整理すると以下のような状態になります。
- 透明性: スプリントバックログが正しく表現され、見ることができる
- 検査: スプリントゴールに対する現在の進捗
- 適応: スプリントゴールを達成させるためにスプリントバックログの調整
これらを実現するために、「昨日やったこと」「今日やること」「困っていること」を聞いているわけです。「昨日やったこと」は検査と透明性のために。「今日やること」「困っていること」は適応と透明性のために。我々が行っているスクラムにおける様々なプラクティス（前述の『「昨日やったこと」「今日やること」「困っていること」をきく』など）はすべてこの三本柱を満たしている必要性があります。その上で実際にやってみた上でより理論を逸脱していないか、理論により寄り添うことができないかを振り返る必要があるのです。
スクラムを始めようとする多くのチームは理論を理解せず、「チーム・イベント・作成物」をシンプルに捉え、実際にやってみたがうまくスクラムが有効化せず、そのとき理論の理解不足による壁に当たることになるでしょう。
スクラム風チャンクウォーターフォール
自分の観測範囲ではありますが、スクラムが有効化出来ていないチームの特徴の一つに、「既存の開発手法を大きく変えることをせず、その流れをスクラムの言葉に置き換え、リズムを作っただけ」というのがあります。
例えば、何かのソフトウェアやモノを作るときはどのような工程を経て行くでしょうか。多くの場合、以下のような順番になります。
- なにを作るのかをきめる（要件定義）
- どう作るかをきめる（設計）
- 実際につくる（実装）
- 期待通りにつくれたか確認する（テスト）
- 使える状態にする（リリース）
この流れ自体は基本的に入れ替えることが出来ません。特定の技術を使いたいみたいなホビープログラミングとかであれば設計から始めて要件定義をやることはあるかもしれないですが、通常はこの流れになります。この不動の依存関係は特に問題ないのですが、問題は、要件定義の粒度がスクラムに適していないパターンです。
とあるスクラムチームでは要件定義の段階では、最初のスプリントで基本的に作るもののスコープを決定し、リリース可能なレベルになるまで機能を構成します。そしてその要件を満たすための設計を行い、実装に着手します、スプリント内で実装が終わらなかったので次のスプリントの前半まで実装を行い、その後テストを実施、バグの改修をおこなって、最後リリースを行うといった方法を取っていました。この場合、最初の要件定義からリリースまでは最短2スプリントが費やされることになります。さて、問題は、その2スプリントの間にやっていた2回あるはずのレビューでは何をやれば良いでしょうか？最後のスプリントではもちろんリリース物が出ているので、そのリリース物をレビューし、フィードバックをもらい、プロダクトバックログを適応することが出来ます。しかし、最初のスプリントでは何もリリース物が出てないので、フィードバックをするところがなく、プロダクトバックログを適応することが出来ません。
このことを私はスクラム風チャンクウォーターフォールと名付けてみました。やっているリズムはスクラムっぽいですが、実のところスクラムで定義されているイベントの検査と適応の実施が難しくなっています。作っているものの途中では、どのようなものが出来上がるかがわからず、透明性も確保出来ていません。そして、リリースの価値は2sprintかからないとユーザーに届くことが出来ません。
では単純に2sprintかかるであろうこのリリース物を半分に分割して見るとどうなるでしょうか。
少なくとも各スプリントのレビューでステークホルダーはリリース物をレビューし、フィードバックをすることで、よりプロダクトの方向性のズレを修正しやすくなります。また、先程の半分の価値ではありますが、素早くユーザーに価値が届くことで、より多くの利益を得ることが出来ます。これをより細かくしてみましょう。
Sprintの中で行う一つのリリースを細かくすればするほどユーザーへ届く価値がより多くなってきているのがわかるかと思います。また、リリース物が小さくなることで、ステークホルダーは大きな価値を見てしまうときに見落としがちな部分もより細かいフィードバックがしやすくなります。検査と適応がより促進されるような状態です。
つまり、スクラム風チャンクウォーターフォールを回避するためには、リリース単位の要件定義でのスコープを小さくする必要があります。しかし実際やるとそのそのスコープの境界の決定はとても難しく感じると思います。経験上よく見てきたのは、小さくするということを念頭に起きすぎて、工程で分割してしまうパターンと、「これ以上小さく出来ない」というパターンがありました。
工程で分割するパターンはチケット駆動で開発しているチームではよく見られます。要件定義と設計のためのチケット、実装のためのチケット、テストのためのチケットのような分割をしてしまっているパターンです。先程の話を踏まえると、ユーザーやステークホルダーがフィードバックを行える単位でリリースを行う必要があります。しかし、工程を分割してしまうパターンは多くの場合レビューでフィードバックをもらうことができなくなり、レビューがただの進捗共有会になってしまう可能性が発生してしまいます。
「これ以上小さくできない」というパターンはさまざまな要因を含んでおり、一概にこれが原因というのはありません。代表的な一つとしてはMVP（Minimum Viable Product: 実用最小限の製品）の捉え方がうまくできていないことに起因するのを見かける時があります。MVPは本来的には「本当に顧客が欲しいもの」がわからない状態において、我々が思う価値が本当にそれで良いのかと言うのをピンポイントで検討するための最小限の製品を目指すものになっています。それはMinimum Releasable Formal Product(最小限のリリース可能な正式な製品: 造語です)ではありません。
考える人・作る人・ほしい人全員が何かを実現しようとしたときどうしても欲張ってしまうことが多いですし、これはプロダクトを構成する上で最低限なければならない機能だという思い込みで作り込みを行いたくなります。もしくは小さい工数であれもこれもできるからついでにやっちゃおうという欲も出てきてしまいます。しかしそのちょっとした機能が将来に渡って多大な保守工数や要件定義工程における調査工数の増大を招くのは経験上よくあることです。作り込んだものを閉じるという判断もとてもむずかしくなります。
誰かから依頼されて作らされている製品ならまだしも、自らの仮説をベースとして製品を「使ってもらう」という立場であるならばこの状況は回避したいところでしょう。本来的なMVPはこのような状況を回避し、学習サイクルを回して必要な機能を小さく実現していくための仮説検証のための概念です。Minimum Releasable Formal Product(最小限のリリース可能な正式な製品: 造語です)にならないように、足りないと思わず、小さく仮説検証をずっと繰り返していく製品を作るというサイクルを構築する必要があります。
なお別の方法として、それまでのリリースのスコープ範囲を変更せず、スプリント期間を延ばして対応するというのがありますが、これはあまりおすすめしません。経験主義とリーン思考をベースとしているスクラムの理論からは逆行した対応になる可能性があります。スクラムにおける経験主義は以下のようにスクラムガイドで説明されています。
経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。
スプリント期間を長くすることで、観察するためのタイミング（代表的なのはレビューやレトロスペクティブ）が少なくなり、意思決定のインターバルが長くなることで変化の追従ができなくなります。前述の通り、スクラムの利点である「変化への適応」が享受しずらくなる可能性があるので、注意が必要です。また、リーン思考に関しては以下のようにスクラムガイドで説明されています。
リーン思考では、ムダを省き、本質に集中する。
スプリント期間を長くすることで、無駄かもしれない機能を入れることができる余地が大きくなる可能性があります。もちろん、リリース物が小さく保っていればその可能性は抑えられますが、時間制約を厳しくすることで、「その時間でできるのだろうか」という思考が自然と出てきやすくなります。
事業目標の表現
会社組織において、その行動は基本的に何かしらの目標や目的があることが多いかと思います。無秩序な拡大は直感的にも危なく、組織のアイデンティティが失われる可能性があるかもしれません。そのような中で組織全体の目標はかなり抽象的か、メンバーレベルで見ればスコープのでかい話で有ることが多く、チームが抱える目標は組織目標を何度か分解するパターンが多くなります。特にエンジニア組織であれば、そのチームレベルの目標は「〇〇をリリースする」などの状態に分解されていることもあるかと思います。
アジャイルソフトウェア開発宣言では
計画に従うことよりも変化への対応を、
と書いてあったり、その原則では
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
といった形で、なにか具体な実現よりも変化への対応を重要視しています。「〇〇をリリースする」という目標の掲げ方は一歩間違えれば、Howが固定化し、変化に対応出来ないばかりか、そのリリースが終わるまでは成果が出てこない可能性があります。アジャイルソフトウェア開発宣言の原則にある
動くソフトウェアこそが進捗の最も重要な尺度です。
を実現出来ない状態です。加えて、多くの目標はHowを決めた段階でその実際の進捗の早い段階で目標達成の期日が決められることが多いです。多くの不確実性をはらんだ状態で決定した期日からは実際にはずれることが多く、その理想的な最初に決めた進捗に合わせようと無理なペースの仕事を行わなければならなくなります。先程の原則には
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
とあるように、その無理は持続可能かというとそうでは無いことが多いです。わかりやすく言えば長時間労働は一生できないという話かもしれません。
もう一つ加えましょう。Howを早期に固定化することはこの原則にも反します。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
自己組織的なチームはスクラムガイド(2017)によれば、
自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。
とあります（2020版では自己組織から自己管理に変わっており、スコープが広がっています）。自己組織的なチームを目指すにあたって目標レベルでHowが早期に決定されていることは大きな制限事項になりえます。
予算と計画の難しさ
組織で何かを成し遂げるときに必ず発生するのがコストです。コストは多くは金銭的なことを指しますが、それに関連して人的リソースの消費や時間もコストとして認識されることもあります（コストと捉えるか投資と捉えるかの議論は別に譲り、ここでは検討しません）。組織はコストを予測し、何に投資していくかというのを予算編成のような形で検討していますが、その予算編成は多くの組織で一定期間ごとに検討していることが多いです。
例えば、一年に一度予算編成を行っているという組織であれば、予算編成の直後に新鮮な需要の高いアイディアがあっても、それに予算がつくのは一年弱後であり、市場に供給できるのはそれよりもっとあとになります。このように未来に実施する施策やアイディアの実現の遅さも問題ですが、今まさに手元で実施しているアイディアも同様の問題を抱えながらやっとことで実施のステージまで来ているのも問題です。つまり1年以上前からある実施しているそのアイディアは、今もその需要が続いているというのが疑わしいのです。じゃあ需要がまだあるか検討してから着手すれば良いのでは、と思うこともありますが、そのアイディアをボツにしたとして、そのあとに積み上がったアイディアはそのボツアイディアに依存していたとしたらどうでしょうか。特に計画をする人々が専任でいる組織は、その計画はHowも含め綿密かつ詳細に組んでしまっている可能性さえあります。一年に一度のようなサイクルで予算編成という形の計画を検討するのは、需要の発生から経過する時間とともに増大する不確実性と相対する必要があります。
そしてこれはチームが向かう方向性にも影響を与えます。組織上位層が決定した目標とそれを実現するための予算と計画はチームの動きを固定化させやすくなります。チームがアジャイルな動きを体現するためには、組織全体の予算編成もアジャイルな変化への適応をすることが望まれます。組織全体のアジャイルさは、チームレベルでアジャイルな動きを実践する上で遅かれ早かれ立ち向かわなければならない大きな壁となるでしょう。
個人の評価とキャリア
ここまでは組織やチームなどのグループの話が多かったですが、最後に一個人の範囲での壁になりうることを検討してみたいと思います。
組織では多くの人が協働して居るのですが、組織と個人の接点の一つに人事評価という成績評価と報酬決定のフローが存在します。それぞれの仕事に関わる人は常にその仕事との関わりが平等というわけではなく、リーダーシップを発揮したなどで仕事に対する関わり合いの濃淡が発生します。そして評価面談のような場では、個人の貢献度を推し量り、それを評し、組織の成長や個人の能力向上を目指すために、目標設定をおこなうというのが成長を目指している企業では多く行われていると思います。個人の能力が高くなることその事自体はとても良いことで、組織の競争力を高めるとても重要な原資になります。
問題はアジャイル開発を行うとき、その価値の源泉は個人というよりチームから出ているという視点がこの個人目標とバッティングする可能性があるところです。スクラムチームを例に取ると、スクラムチームは複数の関心事に特定の誰かをアサインして取り組むというよりは、チーム全体で関心事に取り組むといった動きをすることが多いです。このようなアジャイル開発が目指すチームで成果を出すという思想と、個人が目指す方向性が合わないとしたとき、個人の評価で成績が付けられてしまっている状況下では、個人の目指す方向を優先したほうがその個人が得られる利益（キャリア・経験・報酬）は大きいでしょう。アジャイルチームが目指すチームの在り方と個人の目標のズレは思った以上にアジャイルチームを作る上で大きな壁になります。
別の観点で、組織と合意した個人の目標とは別に、個人がもともと持っているキャリア方向性とのズレも考える必要があるかもしれません。個人の持っているキャリア方向性は明確ではない場合もありますが、明確なキャリア方向性を持っている人はアジャイルチームで働くときに、自分の方向性に合致していないと感じる場面が多いかもしれません。例えば、特定の技術領域の経験を積んでその第一人者に近づく、のようなキャリア方向性をある個人が持っていたとして、アジャイルチームがチーム全体で1つの仕事を進めていくという方針でいれば、たとえその技術に関連している仕事をしていたとしても、すべての工程に関われず、中途半端であるという認識をその個人がしてしまっていることで、今のチームは自分のキャリアにたいして利益（キャリアや経験）をもたらしづらいと判断してしまう可能性があります。
おわりに
アジャイル、スクラム開発を行ったときの壁について、私自身の経験からご紹介させていただきました。まとめると大きく5つです。
- 初めてアジャイル開発やスクラムガイドを読む場合、その人だけでスクラムガイドを読むと難解で、理論や価値基準よりもプロセスとしてのロール・イベント・作成物だけを理解し、不完全に適用してしまう。
- アジャイルの宣言・原則を理解せずスクラムをプロセスとして適用すると、アジャイルなサイクルではなく、それまでのウォーターフォールのような長いプロジェクトを切り刻むまでにとどまってしまうことがある。
- 事業目標でHowを表現してしまうと、変化への対応ができなくなってしまう。
- 計画を予算策定を起点として長いサイクルで回している状態は、変化への対応ができなくなるどころか、ベストなタイミングを逃してから開発をしてしまう可能性がある。
- メンバー個人レベルの目標設定や個人のキャリア方向性によっては、チーム全体で成果を出そうとするアジャイルの方針にブレーキをかけてしまう可能性がある。
このすべてが必ず壁としてあなたの前に立ちはだかるということは無いですが、その壁に当たりそうだなと思ったとき、分析の一助としてこの記事が役立つことを切に願っています。
明日は同じくアジャイル開発で頑張っている id:mattsun0 さんがスクラムの話をかいてくださるようです。しかも明後日は id:lettuce222 さんがアジャイル初心者としてスクラムマスターをやってみた勇気ある話が見れる予定です。今日から3日間に渡ってお贈りするスペシャルアジャイルストーリーズをお楽しみください！
