はじめに

アジャイル開発の主流であるスクラムは非常にシンプルで、やるだけならとても簡単です。
「スクラムガイド」^注1と検索し、20ページ弱の文章を1時間ほどかけて読むだけで、スクラムのルールはすべて覚えられますし、ルールに従って開発することはそれほど難しいことではありません。
しかし、期待する効果を出そうとすると、従来型開発ではまったく気にしなかったところが課題になり、とたんに実践が難しくなります。これまでの連載では、実体験や具体的なシーンをもとに、さまざまな視点でその効果を最大化させるためのノウハウやヒントを紹介してきました。最終回では、よくある課題にフォーカスし、その解決への道筋を紹介します。

スクラムのよくある課題とその解決策

「期待する効果が出ている」スクラムは、継続的に顧客へ価値を届けられています。
スクラムとは、簡単に言えば、顧客の要求を完成の定義を満たすようにチームがインクリメントにして顧客に届ける、という一連の活動です。それぞれの活動が適切に行われている状態を、図1に示します。
逆に言えば、期待する効果が出ていないときは、図1の活動のうちどこかが適切にできていないと考えられます。本節では、スクラムの効果を妨げてしまう課題と、その解決策について解説していきます。

図1　スクラムの期待する効果が出ている状態

プロダクトバックログがうまく作れない

プロダクトバックログ（以下PBL）は、プロダクトの価値と特徴を表したものです。スクラムガイドを読み終えて、さあスクラムを始めようと思ったチームが最初に疑問に感じるのは、PBLはどうやって作ればよいのか、という点です。
スクラムガイドには、PBLの定義や扱い方は書いてあっても、それをどう生み出し、どう作るかは書いていません。見よう見まねで書いてみたとしても、果たしてこれが正しいのか、これでサービスの目的が達成できるのかはわからず、不安を抱えることもあるでしょう。

● 「 顧客がプロダクトに価値を感じている」状態をイメージする

では、どのようにしてPBLを作ればよいのでしょうか。そのヒントが最新版のスクラムガイドにあります。
過去のスクラムガイドでは、PBLの作り方に関係しそうな記載はありませんでしたが、スクラムガイドの2020年版では、この点が少し改善され、「プロダクトゴール」という概念が登場しました。プロダクトは価値を提供する手段であり、そのプロダクトの未来の状態を定義したのがプロダクトゴールであり、プロダクトゴールを達成するための手段がPBL、という関係性です（図2）。
PBLがうまく書けない方は、プロダクトの望ましい状態、つまり、顧客がプロダクトに価値を感じている状態がそもそもイメージできていないのではないでしょうか。
プロダクトの望ましい状態を具体的に考えるために、例として自宅の施錠確認アプリを挙げてみます。施錠を確認するためのアプリを開発してくれと仮に言われたとして、どんな機能を搭載すればよいかを考えがちですが、まずは未来の状態をイメージしてみます。
たとえば、顧客が「利用者が安心して外出できる」という価値を感じている状態を考えてみましょう。すると、必要な機能が自然と頭に浮かんできませんか？

図2　プロダクトゴールとPBL

● プロダクトゴールの例

筆者が頭に浮かんだのは次のような機能です。

このように、まず初めに価値を感じている状態であるプロダクトゴールをイメージすることで、PBLが格段に作りやすくなります。
PBLの詳しい作り方については、本連載の第3回「初めての新規サービス開発（価値創出編）」、第4回「初めての新規サービス開発（実践編）」^注2でも紹介していますので、合わせて読んでみてください。

完成の定義があいまい

「完成の定義」は言葉どおり、PBLをインクリメントにする際の完成の定義を指します。しかし、プロダクトオーナー（以下PO）にとっては完成の定義よりも、PBLが一番の関心ごとといえます。PBLを見れば、プロダクトバックログアイテム（以下PBI）ごとの費用対効果がわかるため、いわばPOにとってビジネス戦略と同義なのです。
一方、各PBIにおける完成の定義は、コストやプロダクトの品質に大きな影響を与えるにもかかわらず、POから軽視されがちです。その一番の理由は、完成の定義よりもPBLを優先したいからでしょう。PBLで定義されるのは、狩野モデル^注3で言うところの「魅力的な価値」ですが、完成の定義には、プロダクトとして「当たり前品質」^注4と呼ばれるものが定義されるからでしょう。POとしては、「魅力的な価値」を考えることに一番関心を持つのは当然です。
しかし、POが完成の定義に興味を持たず、開発者任せにした場合、どうなるでしょうか。開発者はどう考えますか？　開発者からすれば、完成の定義を厳しくすればするほどコストは上がるので、完成の定義をゆるくしてしまうでしょう。その完成の定義をもとに作られたインクリメントは、POの期待に応えられるでしょうか？
プロダクトのデモはなんとか乗り切れるかもしれませんが、リリース後に問題が出ることは明らかですね。

● 「完成の定義」の共通理解のために対話に時間をかける

まずは、完成の定義の重要性をPOに説明し、時間を割いてもらいましょう。プロダクトの品質は、完成の定義で定義され、PBLにおけるコストは、「PBIの複雑性×完成の定義の要求レベル」で決まるということを理解してもらい、POにとっての関心度を上げましょう。
そして次に、完成の定義で記される、「品質」の共通理解を得ることに時間を割きましょう。品質が良い、悪い、というのはひどく主観的で、かつ、相対的にしかわからないものです。POはよく、「動けばいい」「しっかり作りこんでほしい」など、品質に対してあいまいな表現で要求します。
例として、「動けばいい」を考えてみます。「動けばいい」とは、「ある特定条件で動けばいい」のであり、言い換えれば、「ある特定条件以外では動かなくてよい」という意味です。特定条件については、システムの前提条件や、入力値や操作のパターンをひとつひとつ整理していけばよいので、認識の齟齬は出にくいでしょう。
しかし、動く or 動かないという表現にはさまざまな解釈があります（図3）。開発者にとっての「動かない」は、「動作保証ができない」であることが多く、「システムが異常停止したり、データが破損したりするかもしれないが、動作を保証しているわけではないので許容してほしい」という意味合いです。
一方、POにとっての「動かない」は、致命的な状況を回避するための動作を指していることが多いです。たとえば、操作できないように制御したり、サポートしていない旨のエラーを出したりなどです。
「動かない」の定義を、仮に「特定条件以外は操作できないように制御する」という認識でPOと合意したとすると、制御するための機能設計が必要だとわかり、PBIや完成の定義をしっかりと明文化すべきことがわかります。この作業は、POにとっても開発者にとっても、思った以上にコストがかかると感じるでしょう。あいまいな表現だけで完成の定義を作ることのリスクが理解できたと思います。
完成の定義はPOにとっても重要であり、とくに品質というものはあいまいなものであることを認識し、共通理解のためにPOと開発者は十分な対話をするようにしましょう。その際は、JIS X 25010に定義されている品質モデルを参考にする^注5と、漏れなく観点が洗い出せるので活用してみてください。
品質については、本連載の第11回「アジャイルだとバグだらけ？正しく品質と向き合おう」^注6でも紹介していますので、合わせて読んでみてください。

図3　完成の定義を「動けばいい」としたときの、POと開発チーム間での認識の違い

組織がアジャイルに懐疑的

スクラムを、従来型の開発に慣れ親しんだ組織に導入しようとすると、組織の規約・ルール、人、コミュニケーション、ツール、環境などさまざまな要素を見直す必要があります。これまでうまくいっていた方法を変えるというのは、一から新しいものを作るより難易度は高く、想像するだけで頭が痛くなります。
組織の理解を得ずに、スクラムを強引に始めるとどうなるでしょうか？　何かを変えようとしても、そのたびに組織に対してお伺いを立てることに奔走し、チームが本当に注力すべきことに時間を割けなくなるでしょう。アジャイルの原則やスクラムのルールを守れなくなり、最悪の場合は失敗するかもしれません。組織にスクラムを受け入れてもらえることは、スクラムの成功の大前提です。では、どのようにしたらスクラムを組織に受け入れてもらえるのでしょうか。

● 小さな成功を積み上げる

組織導入を進めるには、スクラムのように、小さな成功を積み上げるように導入をすすめていくと良いでしょう。その場合、規模が小さく、技術的に難易度が低く、成功の確度が高い案件を見つけ、アジャイルのパイロットプロジェクトとして試行運用するアプローチはよく使われます。
パイロットプロジェクトを成功させ、組織改革を推進する力を持つキーマンにプロジェクトの成果をアピールしましょう。

● アジャイルを組織に受け入れてもらうために交渉する

もし、キーマンに危機感がないのであれば、危機感を持ってもらうところから始めます。この場合、必要性を示す方法と、リスクを示す方法の2通りのやり方があり、交渉相手によってうまく使い分けるとよいでしょう。前者のアプローチであれば、「近年はビジネス環境の変化の速度が速いため、アジャイルが求められている」という切り口で説得しましょう。後者であれば、「競合他社が導入し始めている」「古いやり方では開発者が流出してしまう」などの点を強調すると良いでしょう。
組織の協力を得られることで、アジャイルの効果をより引き出すことができます。組織導入については、本連載の第14回「アジャイルに否定的な組織に対する正しい導入アプローチ」^注7に詳しく記載していますので、参考にしてみてください。

チームのマインドが低い

スクラムチームのマインド^注8が低いとどうなるのでしょうか。もちろんどんな仕事であれ、その担当者や担当チームのマインドは高いに越したことはありません。しかし、スクラムでは、チームのマインドがプロジェクトの成否を決めるといっても過言ではなく、実際にアジャイルの原則には、「意欲に満ちた人々を集めて」「自己組織的なチーム」という表現が使われており、高いマインドが前提になっていることがわかります。マインドが低いチームは、改善ができない、責任を放棄する、目的が一致しない、といったことが起こり、それは継続的な価値提供を阻害するものです。
しかし、チームのマインドを高めることは簡単なことではないでしょう。世の中にあるモノは、直接的もしくは間接的にコントロールできるものと、そうでないものに分類できます。他人の行動をコントロールすることは比較的容易ですが、他人のマインドをコントロールすることは催眠術でも使わない限り難しいと思います。
コントロールしにくい他人のマインドを高めるにはどうすればよいでしょうか？　マインドの低いチームになってしまう大きな原因の1つは、各メンバーの心理的安全性^注9の低さです。心理的安全性が低い状態では、メンバーが「自分の言動が、POや開発チームの他メンバーに受け入れてもらえないのではないか」という対人リスクの不安を抱えてしまっています。

● チームの心理的安全性を高めるためにまずは自分が変わろう

この対人リスクの不安を払拭するにはどうしたらよいのか、有名なビジネス書である『7つの習慣』^注10に、解決のヒントがあります。

まったくコントロールできない問題については、自分の態度を変える必要がある。

これはどういうことかというと、人は他人から何らかの施しを受けた場合に、お返しをしなければならないという感情、いわゆる返報性の原理が働きます。自分自身が他メンバーを受け入れる姿勢を見せることで、ほかのメンバーも返報性の原理で同じ姿勢に変わっていく、ということです。
受け入れる姿勢を見せることは難しくありません。意見を遠慮なく伝え、他人の意見を尊重し、反対されても不機嫌にならず、笑顔を絶やさない。自分自身がこのような取り組みをすることで、メンバーの心理的安全性を高めることにつながるでしょう。また、そのような行動がチーム内で習慣化されるように、デイリースクラムなど日々のコミュニケーションの中で実践することで定着させていくのが良いのではないでしょうか。
チームのマインド向上については、本連載の第13回「なぜマインドが低い『やらされアジャイルチーム』はうまくいかないのか」^注11にも詳しく記載しているので、参考にしてみてください。

プロダクトの変更がしづらい

プロダクトの変更容易性（＝プロダクトの変更のしやすさ）は、高ければ高いほど、顧客へすばやくプロダクトの価値を届けられます。しかし、複雑なシステム（≒プロダクト）の変更は容易ではありません。設計やコーディングを行い、テストするという一連のプロセスは、新しくゼロからシステムを構築するときより、すでにあるシステムの機能を追加したり、変更したりするときのほうが困難です。それは、追加・変更する内容がどんなに些細であっても、「すでにあるものは壊さない」という大前提があるからです。
たとえば、ストーリーポイントを高めに見積もったPBIがあったとして、スプリント1で作る場合はそれが20時間で終わったとしても、スプリント10で作る場合は同じ時間で終わるでしょうか。スプリント1～9までに積み上げた機能を壊さないために、設計時に影響範囲の調査をしたり、すでにある機能をあらためてテストしたりする必要があり、これはスプリント1では必要ないものです。

● リファクタリングやテスト自動化に対して目的意識を持つ

読者のみなさんであれば、変更容易性を高めるためのプラクティスはよく知っていると思いますが、代表的なものをいくつか紹介しましょう。
まずは、リファクタリングです。開発初期に将来を予測してシステムの設計をしたとしても、開発が進むにつれ予測のずれが生じ、変更容易性を低下させます。そのずれを修正し、変更容易性を維持するのがリファクタリングの目的です。オブジェクト指向や関数型プログラミングは、近年では特別に意識せず使いこなしている方も多いでしょう。両者の細かい違いは本稿では解説しませんが、考え方の違いはあれど、結局のところは、両者ともほかのソースコードへの影響を少なくするためのアプローチです。
次にテスト自動化です。これは、単純で繰り返し実行するテストの時間を短縮するためのものです。
紹介したプラクティスは効果があると実証されたものばかりですが、大切なのは、プラクティスが目的ではなく、顧客に継続的に価値を提供することが目的であるということです。どんなプラクティスであれ、大小あれど必ずコストはかかり、その時間が直接価値を生み出すわけではありません。
たとえばテスト自動化であれば、自動化するコスト（＝投資）と、自動化によって将来短縮される時間（＝効果）を見積もり、投資対効果が低ければ、自動化しないというのも選択肢の1つです。プラクティスの費用対効果を見極め、本来の目的を見失わないように心がけましょう。
テスト自動化や各種のプラクティスについては、本連載の第7回「手段が目的になっていい？ アジャイルなテスト自動化とは」、第12回「XPは古くなんかない！理解を深めて効果的に取り入れよう」でも紹介しています^注12ので、合わせて読んでみてください。

プロダクトのリリースまでに時間がかかってしまう

プロダクトが変更できたとしても、それを迅速に顧客へ届けられなければ意味はありません。顧客に価値を届ける（＝リリース）までがチームの責務です。
しかし、一般的にリリースの作業は、同じ作業をするとしても、開発作業よりも多くの人数で時間をかける必要があると思われており、実際もそうでしょう。その理由は、開発作業はミスをしても修正するための猶予がありますが、リリース作業は、1つのミスで顧客にプロダクトを届けられなくなる可能性があり、開発作業よりも慎重に進める必要があるためです。さらに、リリース後は、システムを安定的に運用できていることも確認しなくてはいけません。「すでにあるものは壊さない」という前提は開発作業と変わらないのですが、ミスを許容できないのと、その後の安定運用を保証しなければいけない点で、難易度とコストが跳ね上がります。

● トラブルが起きる前提で考える

ミスが許容できないこと、安定運用を保証しなければいけないこと、この2点の課題をどう解決すればよいでしょうか。
ミスが許容できない点については、説明不要だと思いますが、リリースの自動化が最善のアプローチでしょう。いわゆるオペミスは、人間が起こすものです。リリース作業を自動化し短時間でリリースできるようにしましょう。
リリース後の安定運用を保証するためには、可用性、信頼性、スケーラビリティを高めることが重要です。これから開発するシステムはほとんどクラウドを利用すると思うので、安定運用のハードルはそこまで高くないでしょう。ただ、クラウドの特徴を最大限活かすために、クラウドデザインパターンなど先人のノウハウを活用すると良いでしょう。また、最近では可観測性というキーワードが注目されています。システムが複雑になればなるほど、何か問題があったときの原因特定に時間がかかります。可観測性を高めておくことで、早急に復旧措置を取ることができ、それは継続的な価値提供につながるでしょう。
大事なのは、リリースは一度では終わらない、リリース作業や運用時には絶対に何らかのトラブルが起こる、という前提でプロセスやアーキテクチャを設計することです。
可観測性や、リリース自動化については、本連載の第6回「アジャイル開発のマイクロサービス化に欠かせない可観測性」、第16 回「SREで実践する、インフラを巻き込んだDevOps」でも詳しく解説しています^注13。

一番の問題は問題に気づかないこと

今回は、アジャイル開発でつまずきやすいポイントとその解決策を紹介してきました。ただ、今回紹介した問題は、最初からすべてが解決できている必要はありませんし、解決できていなくてもアジャイルはできます。本当に問題なのは、問題を問題と思わないことです。アジャイルは手段であり、目的ではありません。手段を目的と考えてしまうと、効果の有無は二の次になり、問題に気づきにくくなります。アジャイルの目的はあくまで、「継続的に顧客へ価値を届けること」です。このように大規模化したシステムに対応するアーキテクチャでも正しく設計されていないと、結合試験どころか単体試験ですら大変になる可能性があります。また、正しく設計されていたとしても、下記のような理由から結合試験の難易度は高いと言えます。

より優れたアジャイルの実践者になるために

アジャイル開発の需要は、近年、急激に高まり続けています。それは、デジタルトランスフォーメーションの必要性が増してきたことや、新型コロナウイルス感染症が広がりライフスタイルが変化したことで、ビジネスモデル変革が急務であることが背景にあり、この傾向はしばらく続くでしょう。
ひと昔前まで、アジャイル開発は、技術力が高く改革マインドがあるエンジニアを中心に実践されてきましたが、近年はコモディティ化してきており、多くのエンジニアが一度はアジャイル開発を経験しているのではないでしょうか。アジャイル開発は、プロダクトライフサイクル^注14のうえでは導入期、成長期を過ぎ、成熟期に至っていると思います（図4）。そうなると、「アジャイル開発ができること」だけでは、IT市場において優位性が保てません。
そこで思い出してほしいのが、アジャイル開発の界隈ではよく耳にする、「Don't just Do Agile, Be Agile」という言葉です。優れたアジャイルチームは、改善を止めません。改善し続けている状態がアジャイルであり、これからの強みになるでしょう。

◆　◆　◆

本稿では、アジャイル開発の導入や継続を妨げるポイントについて解説しました。しかし、これらの課題を乗り越えたとしても、継続的な価値提供を目指す限り、次の課題がやってきます。「アジャイルの道には終わりがない」ということを心に刻んでほしいと思います。

図4　アジャイルのプロダクトライフサイクル

連載のおわりに

筆者が本稿のテーマを選定したのは、アジャイルに興味を持つエンジニアが、アジャイルを間違って解釈してしまい、期待外れの結果に終わってしまうことを防ぎたいと思ったからです。
アジャイル開発宣言やスクラムガイドは、基本に立ち戻るための「バイブル」と呼ばれることが多いですが、解釈が難しいとも言われています。かといって、ある1人の解釈で、詳細なやり方まで指定し、いわば“宗派”として普及させてしまうと、アジャイルの根幹の価値である柔軟性が失われてしまうと思いました。そのため、執筆や監修の際は正しい解釈を伝えることと、詳細なやり方はあくまで提案に留めておくことに注意を払いました。まだまだ書き足りないことはたくさんありますが、読者のみなさんにアジャイルやスクラムのすばらしさが少しでも伝われば幸いです。お読みいただきありがとうございました。

アジャイルコラム記事一覧

https://www.intellilink.co.jp/column/agile-devops.aspx