実録「ワラ分析」！

スクラムに取り組んでいる方々へ ── ワラって何？と思ったら、是非この記事を読んでいただき、ちょっと使ってみようかとホワイトボードの前に立ってもらえたらハッピーです。

はじめに

2022年11月15日、Agile Japan 2022¹において「トヨタファイナンスにおけるアジャイルビジョンと実践『ワラ分析』！」と題して講演しました。

「実践『ワラ分析』！」では、アジャイル開発において価値を実現するために、要件をどのように素早く分析すればよいのかという趣旨でしたが、具体的事例としてスマホの決済アプリを取り上げました。講演時間の都合上、だいぶん省略した内容でしたので本記事ではもう少し踏み込んで現場のコミュニケーション（セッション）を再現し、ワラ分析のイメージを掴んでいただきたいと思います。

お伝えしたいことは以下の3点です。

• 限られた時間で要求分析の観点を漏らすことなく、検討すべき内容がわかる
• 法令や規制といったビジネス上の制約であったり、ユーザービリティやセキュリティなどの品質特性に注意を向けたりすることができる
• プロダクトオーナーと開発メンバーとのコミュニケーションを促すことができる

さて、次項から始まるセッションですが、以下の方々に登場いただきます。

プロダクトオーナー（PO）：りんごさん
スクラムマスター（SM）：くまさん
スクラムコーチ（コーチ）：ひまわりさん
アーキテクト：つばめさん
スマホアプリエンジニア：もちさん
サーバーエンジニア：もみじさん
セキュリティ担当：ケロちゃん

それでは始めていきましょう！

セッション1 – 新規案件の決定

ここは都内の金融事業会社のオフィスです。この会社では決済アプリを運営しており、今日も新しい案件の企画が決定しました。

くまさんはスクラムマスターを任命されて半年です。UI改善といった小さめの案件をスクラムでこなしてきたのですが、今度の案件はすこし大きいようです。プロダクトオーナーのりんごさんと話をしています。

りんごさん（PO）： くまさん、最近どないや。スクラムマスターとしてもっとはじけたいやろ。決済アプリも今のベースラインをリリースしてから半年や。会員数の目標達成にもう一歩でな。競争が激しいからちょっとした差別化じゃアカンので、いっちょ会員の規模を増やすことにしたんや！

くまさん（SM）： 大々的に何かやるんですか？たしかに、小さな案件だとあんまり成果が出ているかわからないですね。

りんごさん（PO）： そうなんや。会員数が増えんことには収益化への道筋を立てることができんっちゅうことや！テコ入れとしてな、会員の家族や友だちを紹介することでお金がもらえる「家族友人紹介キャンペーン」を企画してな。さっきの経営会議で予算がとれたんや。億円やで、億円。

くまさん（SM）： さすがですね、それだけの予算を通したのですね。で、そのキャンペーンはいつからなんですか？

りんごさん（PO）： 安心しいや、今まで2週間単位のリリースとは違って、2ヶ月後やー！よろしく！！

くまさん（SM）： ・・・（2か月後？招待してお金をもらう仕組みを作るんだよね、むむむ？）

セッション2 – ワラ分析登場

くまさんは億円の予算規模に加えて2か月後のリリースと聞き、果たしてできるのか、何から考えればよいのか、焦り始めました。今のUI改善のスプリントが1週間後に終わるので、もう考え始めないと次のスプリントに間に合わないかもしれません。

青ざめているくまさんのもとへ、ひまわりさんが来ました。ひまわりさんはくまさんにコーチングを施してきたスクラムコーチです。

くまさん（SM）： あわあわ。

ひまわりさん（コーチ）： あ、テンパってますね。聞きましたよ、家族友人紹介キャンペーン。今までの案件と比べて大きいですね。

くまさん（SM）： どうすればよいのやら。そろそろもう少し大きな案件を、とは思っていたのですが。現実となると、できるんだろうかと心配で。

ひまわりさん（コーチ）： 心配ありませんよ。ちょっとしたフレームワークがあるので、それを使っていきましょう。お時間よいかしら？

ひまわりさんはホワイトボードにスクラムの開発の流れを描き、最初の２つの工程を強調しました。

ひまわりさん（コーチ）： もう慣れてきたかと思うけど、スクラム²は短期間でリリースを繰り返し、ユーザーからフィードバックをもらい、ユーザーの価値体験をよりよいものにしていくことが目的でしたよね。

短期間でリリースをするためにはValue Stream Map³などでどこにボトルネックがあるかを把握する必要があったわけです。決済アプリでもスプリントからリリースまでの期間を短くするためにDevOpsを導入したでしょう？

でも、スプリントが始まる前、つまりエピック⁴が提示されてから要求分析までの期間を短くするための手法はあまり知られてないの。

今回の案件では、家族友人紹介キャンペーンという価値体験をユーザーに届けるために、限られた時間で何をどのように作るのかをスクラムチームで合意していく必要があります。

くまさん（SM）： それはいったい何という手法ですか？

ひまわりさん（コーチ）： それは・・・「ワラ分析」です！

くまさん（SM）： ・・・（ワラ？WARA？）

ひまわりさん（コーチ）： 「藁」ですよ。アジャイル要求分析の手法に”Discover to Deliver”というのがあり、その中の「プロダクトの7つの側面」という分析フレームワークのことを「ワラ分析」と言っています。

くまさん（SM）： なにゆえ「藁」なんですか？

ひまわりさん（コーチ）： ほら、３匹の子豚の寓話があるでしょう？さぼって藁葺きの小屋で済ませちゃった１匹目の子豚がオオカミに食べられちゃう話⁵。藁葺きのままではダメだけど、みんなで検討するたたき台として出発する意味なのです⁶。ここから必要最小限の製品、インクリメントは何かを決めて、煉瓦作りの家を目指すために、検討スピードを上げるのです。

くまさん（SM）： なるほど、MVP⁷を決めるために藁でたたき台を作るわけですね。

ひまわりさん（コーチ）： ユーザーストーリーって最初は内容が荒くて、漠然としているでしょう？２カ月というタイムボックスでは、リファインメントで何時間もかけられないと思うの⁸。ワラ分析は限られた時間の中で、何に注意を払うべきか、何を検討すべきなのかという観点を示してくれます。

ひまわりさんはホワイトボードに向かって、格子状に区切って書き込んでいきました。

ひまわりさん（コーチ）： 後で参考文献を渡すので読んでくださいね⁹。今はごく簡単に説明しますね。プロダクトの設計に必要な観点を７つにまとめたものになります。

わかりやすいもので言うと「ユーザー」ではどんな人が使うのか、「アクション」ではその人は何をきっかけにプロダクトを使うのか、「データ」には扱うデータの論理的な関係はどうなるのか、と言った具合に枠ごとに何を考えるべきかを示しています。

くまさん（SM）： 多岐に渡りますね。これっていつやるんですか？ 1週間後にスプリントが始まるので、もうやらないといけないですよね。

ひまわりさん（コーチ）： そう。もう取り掛からないといけないです。

ひまわりさんはホワイトボードに向かって、３つの線を引きました。

ひまわりさん（コーチ）： ワラ分析をするタイミングは3つあるんです。

1年から2年先のプロダクトのロードマップを考えるのが「全体」ビューです。プロダクトにどんな要望を盛り込むべきか、つまりフィーチャーを考えます。 次に２カ月先のリリースを見据えて、どのユーザーストーリーを対象とするのかが「事前」ビューです。

そして、次のスプリントで開発する必要のあるユーザーストーリーについて詳細化をしていくのが「現在」ビューなんです。

今は事前ビューですが、次のスプリントも考えないといけないので、現在ビューの視点も必要です。

くまさん（SM）： ええっと、２カ月後にリリースするので、家族友人紹介キャンペーンを実施できる状態にならないといけない。そのためのユーザーストーリーは何だろうか、ですよね。

一方、来週からスプリントが始まるので、そのスプリントで開発しなければならないユーザーストーリーを詳細化しないといけない、ということですか？

ひまわりさん（コーチ）： そうです。結構多くの事柄を素早く分析していかないといけないので、ワラ分析の場ではプロダクトオーナーとスクラムマスター、開発エンジニアが参加すべきなのです。みんなが一堂に集まって、その場で検討を進めます。

重要なことですが、技術的な実現性や品質特性もある程度考える必要があるので、アーキテクトやテックリード、QAも参加する必要があります。

くまさん（SM）： なんかカオスなイメージですが、大部屋で議論していく感じですね。まとまるのだろうか・・・。

ひまわりさん（コーチ）： 何を作るかに関してはプロダクトオーナーに任せましょう。どのように作るのかはアーキテクトやテックリードの方々と開発エンジニアが議論して決めましょう。ファシリテートは私が付いていますから大丈夫です！

ひまわりさんはそう言って、ワラ分析の日程調整に乗り出していったのでした。

セッション3 – ユーザーストーリーの作成

ワラ分析を始める前に、くまさんはりんごさんに時間を取ってもらい、ユーザーストーリーを作ってもらうことにしました。

りんごさんが作った家族友人紹介キャンペーンのユーザーストーリーは・・・

決済アプリの会員は、非会員である自分の家族や友人を招待することで、報酬をもらうことができる。それによって、自分のお気に入りのアプリを推し体験ができる。

りんごさん（PO）： 今回のキャンペーンの価値は、「推し」や！紹介したらお金をもらえることがユーザにとって価値のあることかもしれへんけど、自分が推したものを使ってもらえたら、うれしいやろ！！価値にはこだわったんやで。

くまさん（SM）： 「推し」っておもしろい視点ですね。このユーザーストーリー、理解したんですけど、ちょっと大きいですね、もう少し分解できないものですか？

りんごさん（PO）： おっ、大きいか。研修で作り方を習ったけど難しいな！ ユーザーストーリーを小さくする原則ってなんやったか？IMPACTだっけ？

くまさん（SM）： INVESTの原則ですね。

くまさんは研修資料のINVESTの原則のページを見せました。そこにはこう書かれています。

くまさんは3つのユーザーストーリーに分解して付箋に書いてみました。

1. 会員は非会員の家族や友人に招待コードを渡す
2. 家族や友人は招待コードを使って会員になる
3. 報酬として会員の残高に500円が追加される

りんごさん（PO）： へぇ、こう分解するんやな。たしかにINVESTに適っているようや。Negotiableとか、議論に呼んでもらってええで。これで行くで！

セッション4 – アーキテクチャー

ひまわりさんとくまさん、そしてアーキテクトのつばめさんがホワイトボードの前に立って、議論しています。

ひまわりさん（コーチ）： つばめさん、チームのみなさんが家族友人紹介キャンペーンの議論ができるように簡単なアーキテクチャーのモデルを描いてもらってよいですか？

つばめさん： はい。では、こう描くね。

くまさん（SM）： 私はUI改善しかやったことがなくってよくわかっていないんですが、後ろのサーバーって何をしてるんでしょうか？

つばめさん： 決済アプリはスマホだけで動くわけではないんだよね。サーバーと連携するんだけど、サーバーには会員情報の登録や閲覧、チャージ・決済手続きや利用履歴の表示といった基本的な処理とデータを管理するんだ。

もうひとつ、会員がセキュアに利用できるようにする認証基盤と連携して、サーバーはこれらの機能をAPIで提供しているんだ。運営する人が管理目的で使う管理画面も備えているよ。

キャンペーンのユーザーストーリーを聞いてる限りは、このアーキテクチャが大きく変わることはなさそうだね。

くまさん（SM）： ワラ分析の場にはサーバーのエンジニアにも出てもらいましょう。

セッション5 – ワラ分析：ユーザー、アクション、インタフェース

いよいよワラ分析が始まります。

ホワイトボードの前に、りんごさん、くまさん、つばめさん、決済アプリ・エンジニアのもちさん、サーバーエンジニアのもみじさん、そしてひまわりさんが集まりました。

ひまわりさん（コーチ）： みなさんにワラ分析をひと通り説明しましたが、進め方としては、最初にとっつきやすいユーザー・アクション・インタフェースから始めて、データ・コントロール、環境、品質特性の順にやっていくのがやりやすいでしょう。

くまさん（SM）： それでは、ユーザーストーリーを一つずつ見ながらやっていきましょう。まずは、ユーザーストーリー①「会員は非会員の家族や友人に招待コードを渡す」からです。

会員ってどうやって招待コードを家族や友人に渡すんですかね？会員と家族友人とのやりとりを想像してみましょうか。

もちさん： 会員が決済アプリからSNSやメールを起動するとメッセージの本文に会員登録ページのURLを付けるのがよくあるやり方ですね。メッセージを受け取った人がすぐに会員登録できるように。

ひまわりさん（コーチ）： アクションでは今言ってもらったやり取りをユーザーとシステムの応答として表現しますが、このお話をUMLのシーケンス図で書いてみましょう。

りんごさん（PO）： そうやな、SNSやな！招待のしやすさを考えるとメールやないな！

くまさん（SM）： SNSを起動した後の操作は決済アプリではないので、ここはスマホやSNSの役割になるんじゃないかな。

ひまわりさん（コーチ）： そうですね、責務を決めることも重要です。インタフェースにコンテキスト図を描いてみましょう。

くまさん（SM）： コ、コンテキスト図？なんですか、それ。

ひまわりさん（コーチ）： プロダクトと外部の間でやり取りされる情報を表した図です。描いてみますね。

くまさん（SM）： なるほど・・・。SNSから非会員へ招待コードを送る時に決済アプリは関わらないってことがわかりますね。

ひまわりさん（コーチ）： もうちょっとよく見てください。会員は招待コードを知ってますよね。招待コードはどこからやってくるのでしょうか。決済アプリのどこかに表示するのならば、その招待コードは誰が作り出して表示するのでしょうか。

りんごさん（PO）： 招待コードは企画部が用意だな！

ひまわりさん（コーチ）： となると、そのことを示すために、ユーザーのところに、会員と非会員の他に企画担当者と書いておきましょう。企画担当者が登場するユーザーストーリーを考える必要がありますね。

りんごさん（PO）： おぉ、ユーザーストーリーが増えるんか！くまさんが最初に３つに分けてくれたけど、議論したら増えていくもんやな！

ひまわりさん（コーチ）： ワラ分析では、ユーザーストーリーを新たに作ったり、見直したりするんですけど、2カ月後にリリースすることを前提に、チームのベロシティを考えるとすべてのユーザーストーリーをリリースするわけではありません。

ユーザーストーリーが出揃ったら必要最小限の価値を満たすユーザーストーリーをリリース候補とします。ここの判断はりんごさん、お願いしますね。

りんごさん（PO）： わかった！2カ月後にキャンペーンを開始できるように、どのユーザーストーリーで価値を提供できるのか見極めるのが勝負どころやな！

くまさん（SM）： では、次のユーザーストーリー②「家族や友人は招待コードを使って会員になる」を見てみましょう。

家族や友人は送られてきたURLをタップするんですね。アクションにシーケンス図を書くとこうなりますね。もちさん、もみじさん、どうでしょう？

もみじさん： サーバーは基本的にはAPIが呼ばれたら動くので、こうなりますね。招待コードが渡されるので、APIにこの項目を追加することになりますね。

ひまわりさん（コーチ）： シーケンス図にどこまで描くべきかですが、会員登録画面はすでに存在しますので、ここに招待コードも入力できるようにハッキリ書いておきます。会員登録画面はいくつかのページで構成していますが、変更する箇所のみわかればよいです。

会員登録時に求められる本人認証や通知メールといったものは今回影響がなさそうなので、全てのやり取りを書き出す必要はありませんね。

もちさん： 招待コードを入力したときにエラーにすべき条件はなんですかね？正しくないコード？存在しないコード？

ひまわりさん（コーチ）： よい視点ですよ！招待コードについて、会員との関係や多重度といったものを考える必要がありそうです。サーバー側での判断処理も必要でしょう。ひとまず、後で考えましょう。まずはアクション全体を押さえましょう。

ここでは招待コードが正しく入力されたことを前提に会員登録が完了する、としましょう。

もちさん： 一つ質問があります。こういったユーザーストーリーの場合は、決済アプリがインストールされていないことが多いので、そのときはアプリストアページに誘導すればよいと思うのですが、インタフェースにアプリストアとのやりとりを書くべきでしょうか？

ひまわりさん（コーチ）： 気になりますよね。でも、決済アプリができることはストアページに誘導するだけなので、インタフェースには省略してもよいでしょう。

くまさん（SM）： では、ユーザーストーリー③「報酬として会員の残高に500円が追加される」にいきましょう。

家族や友人は会員になることができました。紹介した会員に報酬を付与します。月末に紹介した会員の残高に500円を加算します。複数の招待された会員が登録された場合は、その人数分に500円を掛けた金額を残高に加算します。

残高への付与は月次のサーバー処理となるので、アクションにシーケンス図を描くと・・・。

もみじさん： 月末とは招待された会員が登録された月の月末ですよね。通知の手段としては、チャージや決済が完了した時に決済アプリ上で通知する機能がすでにありますので、今回もこの機能を利用します。

りんごさん（PO）： そうやな、3/31に登録してもらったらその日に残高に付与、っちゅうことやな。ちょっと休憩しよう！

セッション6 – ワラ分析：データ

ひまわりさん（コーチ）： ユーザーストーリーは一通り終わったので、招待コードについて検討を始めましょう。 もみじさん、コード類をデータとして扱う立場から何かご意見ありますか？

もみじさん： えーと、招待コードは今回のキャンペーンで使うものですが、将来、違ったキャンペーンを実施するときにまた招待コードを使うと思うんです。

りんごさん（PO）： 将来のキャンペーンな・・・。ありえるな！

もみじさん： ということは、今回の招待コードと将来とでは違うものになります。なので、招待コードをキャンペーンコードと言い換えて、キャンペーンの種類や用途によって使い分けることにすればよいのでは？

ひまわりさん（コーチ）： もみじさん、データのところに、キャンペーンコードと会員と用途の関係を示してもらえますか？

もみじさん： こうですかね。会員ごとに異なるキャンペーンコードを付ける前提です。

りんごさん（PO）： ええな！まだ家族友人紹介キャンペーンしか考えてないけど、将来のキャンペーンでも使えることが分かったで！

ひまわりさん（コーチ）： もみじさんが描いてくれた論理モデルはスプリント中にサーバー側のチームで論理ER図に加えられ、必要な属性を検討することになります。

もみじさん： 一般論ですが、このようなコードにはコード自体に意味やcheck-digitが付与されることが多いです。コードの体系として全8桁とし、頭2桁は目的に応じたコードにし、残りはランダムに付与するとしましょう。

会員Aさんに家族友人紹介というキャンペーンの場合は“FFnnnnnn"という感じです。

くまさん（SM）： ここまでの話をユーザーストーリーとしてまとめると、ユーザーストーリー④「企画担当者は会員に家族友人紹介キャンペーン用の招待コードを付与する。」となりますね。

アクションとしては、サーバーに備わっている管理画面で登録するのかなと思います。

もみじさん： そうですね、管理画面に会員の属性を管理する画面があるので、そこで登録できるようにしましょう。

ひまわりさん（コーチ）： 招待コードの体系が決まったので、会員登録時のシーケンス図にエラーチェックを入れましょう。

セッション7 – ワラ分析：コントロール

ひまわりさん（コーチ）： ここまではユーザーを中心に分析してきましたが、キャンペーンに応募した人が報酬を受けることについて、法規制に準じた設計が必要になります。

りんごさん（PO）： 以前にも違うアプリで会員になってくれた人にポイント付与しよう、って決めたときに、法務からチェックがあったんや。景品表示法や。消費者庁の。

ひまわりさん（コーチ）： そうですね、決済アプリではいろんな還元・キャッシュバック策やキャンペーンを展開するので、法規制に従っているかは法務部門と連携が必要ですね。

このワラ分析では皆さんに集まってもらって活動しますが、法規制については専門家である法務部門の方に問い合わせるか、ワラ分析の場に来てもらって確認してもらうのがよいでしょう。いずれにせよ、法規制に違反していないか、決済アプリの利用規約を変えなくてよいか、という観点に気づくきっかけになります。

りんごさん（PO）： 了解！法務に確認して、利用規約は企画部にチェックしてもらうわ！

（ワラ分析後・・・）

報酬に上限を設ける必要があることがわかり、会員は一定期間に10件まで紹介できる、としました。際限なく紹介すると、報酬の上限を超えてしまうからです。

セッション8 – ワラ分析：品質特性

セキュリティ担当のケロちゃんが来ました。

ひまわりさん（コーチ）： 品質特性と言われると何それ？と思われるかもしれませんが、非機能要求とも呼ばれますね。定められた時間内にレスポンスが返ってくるのかや、負荷をかけても大丈夫か、大量データでも正常に処理できるか、といった観点ですね。品質特性はこれらに加えて、機能や使いやすさといったユーザービリティも含む、より広範囲に品質を捉えます。

りんごさん（PO）： 経営会議でもセキュリティや個人情報の取り扱いにかなり敏感になってるな！プロダクトの存亡の危機やで！前にもあったけど、仕様の穴を突かれてポイント稼ぎに使われたわ！

ケロちゃん： そーなんすよ。アレをやられたらたまりませんで。このキャンペーンでは不正利用の可能性あり、っつーことで事後的に不正利用を確認できるように、紹介した会員と紹介を受けた会員とを紐付けるリストをダンプする機能が欲しいっす。使うのは俺っす。

くまさん（SM）： では、ユーザーストーリー⑤「セキュリティ担当者は不正利用を検知するために紹介者と非紹介者の紐付きリストを出力する。」を加えますか。

ケロちゃん： ありがとうございやす。これ、キャンペーンが始まると同時に使いたいっす。キャンペーン開始と同時に不正利用も始まる可能性があるわけで！

りんごさん（PO）： そうやな、MVPやな！

もみじさん： アクションとしてはこうですね。

くまさん（SM）： ユーザーにセキュリティ担当者を加えましょう。

ひまわりさん（コーチ）： もう一点、非機能の観点から今回のキャンペーンのアクションやインタフェース、データを見て、アーキテクチャー上でボトルネックになりそうなところはありますか？

一同： うーん

もみじさん： 残高加算を月次処理ですかね。処理の量が多くなる可能性があるので、サーバー負荷を見積もりたいですね。りんごさん、今回のキャンペーンで紹介する人、紹介される人の試算ってありますか？

りんごさん（PO）： おぅ、企画書に書いたので。はいっ、コレ！

セッション10 – ワラ分析：環境

ひまわりさん（コーチ）： 最後の環境です。ここはそれほど特別なものではありません。例えば、開発環境ではサーバーのAPIと接続できるのか、その時のテストデータはどのようなものなのかを確認します。

ここは完成の定義に関わるところで、スプリントの完了の定義では何を検証できれば完了とするかが書かれているはずです。完成の定義に従って、環境とテストデータをいつまでに用意すればよいかをインフラエンジニアとQAにも入ってもらって確認しましょう。

りんごさん（PO）： どんなものを作ろうとしているのかよーくわかった。やっぱり検討していくと、考えんとあかんことが多いな！ 後からこのユーザーストーリーが必要なんですって言われると優先順位は考えるけど、最初からわかってたほうがやりやすいわ。 それに、みんながあつまって議論しているので、決まるのが早いわ！

くまさん、みなさん、よろしく！！

セッション11 – ワラ分析を終えて

くまさん（SM）： ワラ分析って今回だけでいいですか？2カ月先のリリースを見据えた事前ビューはできたかなと思うんですが。

ひまわりさん（コーチ）： 事前ビューは十分だと思います。後は、各スプリントのリファインメントで見積もれるまで検討してみるのがいいでしょう。

最初はワラ分析が終わったらユーザーストーリーマッピングへ、と直線的に進んでよいと思います。これに慣れれば、ワラ分析をやりつつ、都度ユーザーストーリーマッピングをやったり、同時並行していくのがよいでしょう。

MVPはユーザーストーリーマッピングで考えるのですが、提供する価値と実装の難易度のバランスを見極めるために、どれぐらいの労力が必要なのかを掴むためにもワラ分析に戻って確認するのが良いでしょう。

また、スプリント中やリリースした後もワラ分析に戻ってくるべきだと思います。スプリントレビューやリリースした後は、ユーザーやステークホルダーからフィードバックがあると思います。何らかの改善を考えるので、導線を変えるならばアクションで手順を考えたり、画面に表示する内容を変えるならばデータの論理モデルで会員情報の属性を加えてみることを検討したり、スクラムチームが議論できる土台として活用できるはずです。

くまさん（SM）： いつでもこのワラ分析に戻って、どんなことを検討していたのかを確認するのは大事ですね。

最後に

ワラ分析のイメージを掴んでいただけたでしょうか？お伝えしたかったことは以下の3点でした。

• 限られた時間で要求分析の観点を漏らすことなく、検討すべき内容がわかる
• 法令や規制といったビジネス上の制約であったり、ユーザービリティやセキュリティなどの品質特性に注意を向けることができる
• プロダクトオーナーと開発メンバーとのコミュニケーションを促すことができる

ワラ分析という聞きなれないフレームワークでしたがこれに近いことは皆さんが既にやられていると思います。

しかし、昨今は機能面以外にもセキュリティや品質問題に関してますます世間の眼が厳しくなってきており、発覚したらすぐ直します、では手遅れでしょう。また、問題を完璧に押さえるために時間をかけるのもアジャイルの思想から逸脱すると思います。

時間をかけたり、深堀するためのほどよいバランスを見極めるには、ワラ分析を一人で行わずにプロダクトオーナーとスクラムチーム、アーキテクト・テックリードが一堂に会して議論することが必要でしょう。この意味で、会話を促進するツールになると思います。

今ではオンラインのホワイドボードツールがありますので、デジタルでワラ分析をすることもできます。敷居は高くありません。必要なのはアジャイルで成果を出すことが求められているリーダーの意思です。

プロダクトのグロース（成長）に貢献できたという実感はなかなか経験できないことではありますが、ワラ分析がその助けとなれば幸いです。

謝辞

ワラ分析を実践する機会と、この事例を提供いただいたトヨタファイナンス株式会社様に感謝します。

改定履歴：レイアウトを一部修正しました。(2023.04)