昨日に引き続き、スクラムフェスニセコ2024に参加しているので、会の様子を書いていこうと思います。
スポンサーセッション
Day2はスポンサーセッションからスタートしました。
シンプルな会社紹介というセッションももちろんありましたが、会場にいる参加者の方とコミュニケーションを取るようなセッションがあったり、スクラムフェスニセコの場を盛り上げるようなセッションがあったりと、毎度のことながら素敵なスポンサーセッションばかりでした。(なお、スポンサーセッションというコンテキストで自分はそんなに喋ることもないなあと思って辞退しました)
根本さんとお話する
根本さんとお話をしました。
神崎さんが道民というのはすごいよね、という話になり、島田さんにしても札幌在住の方でこれだけ現場で実績を重ねられている方がいるというのはすごいことなんじゃないかという話をしました。
また、神崎さんは今回のkeynoteをお願いするにあたって、嫌な顔をしたりすることはまったくなく、コミュニティへの利益や貢献ということを最優先にして色々と話をしてくれたということで、そういった方がIT界隈では溢れているというのは本当に尊いことだということを話しました。
また、神崎さんの講演もすごく楽しみだというお話をして、生成AIという観点でのアップデートが気になるということや、ただRDRAを説明するというよりも実際にやってみた結果の話が聞けるのがすごく尊いという会話をしていきました。
神崎さんのkeynoteを聞く
神崎さんから、実際にツールの説明をしてもらいながらRDRAの全体像や考え方に関してのkeynoteがありました。
要件定義で起きていること
要件定義が終わったにも関わらず、システム全体を説明することができなかったり、簡単なポンチ絵くらいしかアウトプットできないみたいなことが起こるという話がありました。
どう作るかわからないということは、より良くするということができないということにもつながるため、非常に危険な状態だということです。
要件定義の問題
神崎さんが一番要件定義でまずいと思っているのはガントチャートベースで要件定義を進めることで、これは一人で考えて一人で作成するという進め方を促進することにつながるため、危険だと思っているそうです。
また、ビジネスサイドの関係者が共通に話ができる土台がないというのも問題だと思っているそうで、チームごとに関心の押し付け合いが発生するという話が挙がっていました。
次に、要求同士はどんどん重なって見直しが必要になっていくものですが、それが手戻りとして捉えられて新規開発に手が回らなくなってしまうという話がありました。(全体を俯瞰する仕組みがないがゆえに個別詳細である暫定仕様を最初に決めて、その後に正式仕様にするステップがうまく踏めないということにも起因している)
最後に、様々な資料が乱立してしまっているがゆえに、何が要件なのかという評価が難しくなり、一向に要件が決まらないという問題が挙がっていました。
RDRAで解決すること
RDRAでは上記の課題を解決するもので、
- 関係性ベースの情報整理
- みんなで作成
- ざっくり作って徐々に洗練化
- 詳細化するのではなく関係者の粒度を揃えることを目指し、次の工程で使いやすいような仕様を作る
- ビジュアライゼーションを駆使し、意思を伝える
- 要件定義書を埋めることが完了基準になってしまう状態から、全体を俯瞰して要件を決める仕組みを作る状態にする
RDRAの概要
システム価値/システム外部環境/システム境界/システム(依存関係は後ろから前に順に進んでいる)という4つのレイヤーでシステムが組み立てられているという考え方がRDRAの基本だという話がありました。
このレイヤーでいうと、ユーザーが興味を持っているのはシステム境界になりますが*1、もしシステム境界に関して意見が合わないのであればレイヤーを一個移動して、システム外部環境の話をし、それでも合わなければシステム価値の話をするようにしているということです。
以下、各レイヤーに関しても簡単に説明をしていきます。
システム価値...基本的にアクターや外部システムがある。誰にとって価値があるのか？という視点はもちろん、どういうシステムに繋げることで価値になるのか？というを考える必要がある
システム外部環境...ビジネスユースケースがあり、業務(「販売」くらいの1-10個くらいのもの)、業務フローやアクティブティといったものを仕事の単位で表現する
システム境界...ユースケース(一度作業に取り組んだらスタバにいかないくらいの単位であり、状態を変えるもの)やユーザーが使う画面、外部システムがユースケースとつながるためのイベントがある
システム...コンテキストという漠然とした概念の中に情報や状態モデル、条件(ビジネス上認識しているルールであり実装上認識しているルールではない)、バリエーションがある。
要求抽出
もし50個の要求があったとき、本当に重要な要求はなにか？というのを問いかけ、重要なステークホルダーが重要度が高いと思っている要求を数個だけ抽出したうえで、後は捨てるくらいの覚悟が必要だという話がありました。
RDRAの表現
上述した説明は、表形式で書くことが多いという話がありました。
上述したアクター、外部システム、情報、状態...といった要素ごとに、要素の洗い出しや関係性の表現をしていくということです。
ただし、表だけ見ても作っている人以外は何をしているのかがさっぱりわからないので、RDRAGraphというものを用意しているということでした。
RDRA分析
人が何をするのかを考えることに集中できるように(アクターとの紐づけが正しいのか？というのを考えなくてよいように)分析シートをRDRAでは用意しているという話がありました。
RDRAとスクラム
神崎さんはそこまでスクラムに詳しくないという前提で、プロダクトバックログのような大きな単位に関してはコンテキストやビジネスユースケースが対応しているという話がありました。
また、スプリントバックログに関しては画面やイベント、情報、状態管理みたいな粒度が(正しいバックログになるかはさておき)適切だということです。
また、ユーザーストーリーマッピングで洗い出した機能をRDRAでチェックし、こういうところが足りていなさそうだ、というのを洗い出すのにも使えるということでした。
要件定義の進め方
要件定義のスタート時は、同じ語彙であってもAさんが言っている内容とBさんが言っている内容がまるで違うという話はあるので、ざくっと議論のベースをまずは作るという話がありました。
そのうえで、RDRAのシート(表)にあるようなつながりを見つけ、要素からボトムアップで構成要素を網羅するような形になるように要件を組み立てるということです。
最後に、要件と仕様を分けて考えられるようにする*2ために、ユースケースにつながるような条件であったりバリデーションといったものを洗い出し、要件の精度を上げながら仕様化を進めていくということでした。
RDRAではある程度の粒度感が大切になってくるので、細かく書きすぎないようにするというのも重要なポイントだということです。
LLMとRDRA
エンタープライズ系の要件定義をターゲットに考えたとき、どうやってRDRAでLLMを活用するのか？という話がありました。ただし、LLMはプロジェクトの課題や状況は何も知らないので、どこまで正確に自分のプロジェクトの状況を教えることができるのか？というのがポイントになるということです。
また、LLMは素早く要件定義のアウトプットを出しくれますが、それを理解する速度が遅ければLLMを使う必要がなくなってしまうので、その点も注意が必要だというお話がありました。
そのため、LLMの理解をするときも上述した要件定義の進め方で理解を進めていくことが大切だということです。
LLMは壁打ち相手に使うくらいであんまり厳密なアウトプットを出すために頑張りすぎないのがコツだということでした。
ランチ
佐野さん稲野さん川口さんとランチをしました。
すごく楽しくてめちゃくちゃ話も盛り上がってあっという間に時間が過ぎ去っていったのですがブログに書けることはほぼ0で、唯一スクラムフェス沖縄を楽しみにしているという話だけはかけそうかなという感じでしたw
OST
OSTが開催されたのですが、特になにかのセッションに参加したりすることはなく、頭取とえんどうさん(途中からみほらぶさんとばっさーさん)と話をしました。
- セッションのメモの取り方を話しました。えんどうさんは印象に残った文字をとりあえず書いてみて、そこに近そうな単語をメモしたりちょっと遠そうなところは外に入れたりしてみたりしながら、時々絵を挟んだりしているということでした。これは、耳で聞くほうが圧倒的に優位なのでそういった方法を取っているそうです。また、グラレコはやりたいと思ったことはあるけれどイラストを書く速度が全然追いつかないということでした。頭取は、話を聞いているだけだと眠くなってしまうので、ひたすらメモを取るようにして、気になった部分に関しては感想と一緒に別途切り出しを行うということで、自分とかなり近しい方法だなあというのを話していました
- みほらぶさんのkeynoteで、自己評価が低いから他者評価も低いという話があったのですが、自己評価も他者評価も低い人はいるけれど、自己評価が低いから他者評価が低いというわけではないよね、という話をしました
- 評価制度で、自己評価が低いがゆえに評価がしにくくなるという現象があるよね、という話をしました。評価を得ることに関してはそんなに興味がないという話はありつつも、とはいえ自分がやったことは上司のためにも正確に表現する必要があり、そのあたりはなかなかやっていくモチベーション的な面で難しいという話がでていました。また、スクラムマスターやアジャイルコーチという立場で動いている場合、クライアントやチームが成功しているかどうかが大切なので自分がいくら教科書的に完璧な仕事をしていてもクライアントやチームの成果が出ていなければ問題が大きいため、その人の行動などで評価とかをすることはほとんど意味がないよね、という話をしました
- 珍しい苗字として船迫や上戸鎖があるという話から、自分がこれまで出逢ってきた人の名字の中で一番珍しい苗字は前表(日本で10人くらい)だという話をしました
- みほらぶさんのkeynoteにあった、ユーザー体験をインクリメンタルにすることが大切という話はすごくそのとおりだと思った一方で、ユーザー体験をスプリントごとに変えるというのははたして現実的なんだろうか？という話がありました。みほらぶさん的には全然普通にできるということで、ユーザーというのは前のスプリントと今のスプリントで違う状況に置かれている人なので、極端な話、前のスプリントと同じものをデモとして見せるというのも全然ありだということです。ただ、社内業務アプリケーションなどはスプリントごとにそんなにユーザーが違う状況に置かれているという風には考えづらく、それはユーザー体験をインクリメンタルにする是非というよりも、社内業務アプリケーションをアジャイルで作る意味があるのか？という議論に発展する可能性はありそうだという話をしました。
- コミットメントが示す内容の難しさの話をしました。「死ぬ気でやります」は死ぬことはないのだろうからコミットメントというのはあんまりふさわしくないというのは間違いないということでした。ただ、それくらい強いニュアンスが入る場面として海外では神に誓うという文化があるため、そのレベルと比べると日本でいうコミットメントというニュアンス(結果に向けて頑張りますみたいなニュアンス)にはかなり温度感の差があり、人によってコミットメントが示す内容がぜんぜん違うみたいなところは問題としてあり得るし、どのレベルがコミットメントなのか？というのはあくまでもその人個人の基準であるがゆえに議論が必要だという話をしました。
- コミットメントさせる、というのがおかしいというのは間違いがないのだけれど、特に受託開発のようなコンテキストでは、相手に働いてもらわないと困る、みたいな話は間違いなくあって、それは契約などで取り決めをするしかないという話をしました。一方で、内製開発でもそういう構図を持ってきたりすることはあるので、そういった場合は早いうちにコミットメントをする人が手を動かせる権利を得られるように調整したり、相手の目標に対してコミットメントをするのではなくて相手の目標から考えて自分がコミットメントできるような目標に対してコミットメントをするのが重要だという話がありました。
- teyamaguさんがくれたという北海道のクラフトビールがまとめられている本を喜んで読んでいるみほらぶさんの様子を見ていきました。みほらぶさんはBrasserie Knotというお店にぜひとも行きたいそうです(ここはクラフトビール業界で有名な植竹さんがやっているだけに外れないだろうという期待感があるそうです)
- こういったアジャイル系のカンファレンスだと、どうしてもプロセスの話が注目されがちで、「新しいこういうプロセスがいい...」「コミットメントとは...」みたいな話が繰り広げられがちではあるのですが、自分の手を汚して実際に仕事を進めている人がどう考えても偉いので、「これはコミットメントというのか？」みたいなことを考えている暇があるならば実際にその人が手を動かして少しでも状況を好転させる努力をしたほうがいいという話が出ていました。
- 今回のkeynoteをみほらぶさんが受けた際の話として、「元気が出るような話をしてほしい」というオーダーに対して「気っ風がいい話ならできる」とみほらぶさんが返したという話を聞きました。言葉の真意として、初心者にもアジャイルを実践している人にもはっと刺さって何か動きたくなるようなテーマで話をすることならみほらぶさんはできると思ったそうです。
- 今回のkeynoteでコミットメントというテーマを話そうと思ったのは、「コミットメントさせたい」と思うスクラムマスターの人たちがここ最近増えてきているようにみほらぶさんが感じる状況が前提にあって、そこに辟易としてきたがゆえにこれはどこかで一度話をしないといけないと思ったというのがきっかけだったということでした。ただ、今回のミームになったハリソニズムに関しては、二日前くらいに思いついた言葉だったということです。
- コミュニティの良さとして、決して無理をせずに持続可能な形で参加し続けられることが挙げられるという話をしました。無理をしなくていいし、ただ話を聞いているだけでも全然構わないし、最初は会話とかはせずにじっと耳だけで聞いているような状態でも全然構わないという話が出ていました。そのうえで参加したいと思ったところで参加をすればいいということで、その人の今の状況にあった形での参加方法を守ることが大切だという話をしました。
- スクラムフェス金沢をやってみて、最初はなんでスクラムフェス金沢をやる必要があるんだろう？他のスクラムフェスと何が違うんだろう？ということがすごく気になっていたんだけれども、実際まずはやってみることで、場が作られていくし、その地域の色というのも出てくるんだろうという話をしました。ただ、そうしたことが実現できているのは、スクラムフェスが各地で開かれるようになって、やりたいとさえ思えればスクラムフェスをやれるからというのがありそうだという話をしました。
クロージング
最後にクロージングがありました。
簡単にふりかえりをしながら、今回の参加者層の内訳に関する話があってついに北海道内の人が60%以上を占めるようになったという話を聞いたり、集合写真をとったりしました。
