[音楽]成功するアジャイル開発今日は要求定義について説明したいと思います阿闍梨改悪ては要求定義をユーザーストーリーという形で
定義指摘そしてそれを元にバッグを積み上げるそしてスプリントの中でそのバックログの優先度の高いものから順番に作っていくというスタイルでそれを何度も何度も頒布して作っていくっていうのが基本タイルになります
でそれを辛い厳密にいろいろ定義してあるのがスクラムの中では言葉をメーカーとして役割をつけてやっていきますけれどもシステムをシステムがどのような価値を出すかというものを把握するというのがとても大事になってきます
でユーザーストーリーユーザーストーリーマップそしてそれらを暴露に積み上げるといったようなプロセスというのは者医療へ進めていく上でスクラムをやる上でどのチームでも取り組んでいるとは思いますただよくありがちなのはユーザーストーリーの中に要求を表現はしているもののそれを
実際に開発チームが作ろうと思ったときあるいは開発チームが要件を盗んどのような作り方でシステムとして表設計していかなければいけないのが実装していかなければいけないのかというより具体的なフェーズに入ってきた時に様々な
考慮漏れがあったりとかあるいは要求自体に重複したに矛盾があったりそういったことがおごってしまうことがありますそれらの問題のひとつはユーザーストーリーをマップとして作るその初期段階において
とりあえず思いついた要求をどんどんと突っ込んでいってそしてそれらのつながりだとか守らせ全体性というのはあまり考えずにとりあえず思いつくままにどんどん列挙して言ってバックログに積み上げてそしてそれぞれのユーザーストーリーを
優先順位に応じて言ったんに入れ替えるだけそういった作り方をしてしまった結果それぞれのユーザーストーリーがユーザーストーリー同士の関係だとかユーザーストーリー絶対でどのようなシステムを求めているのかそういった事が考えきれてないということが問題にあります
そこで要求定義の中ではユーザーストーリーという表現方法でプロダクトバックログに積み上げていくという基本的なスタンスはスクラムのセオリーどおりにやればいいんですけれどもそもそものをそのユーザーストーリーごーっ作る時ユーザーストーリーを
書き上げるときに何を考慮ししてすればいいのかそしてユーザーストーリーは単体で見るのではなくてそれではユーザーストーリーを繋げてみたときにシステムとして求めるものになるのかどうかといったものも考えながら作っていくとより開発するとに作りやすくなりますで考えないといけない側面というのは本当たくさんあるんですけれども
agile スクラムの中では要求定義に関してもできる限りこうアジェルミ早くやっていこうという基本スタンスがありますのでこの要求を定義する段階であまりにも詳細に設計しようとかシステムの中のすべてを詳細なレベルにまで網羅しようとかってやりすぎますと時間がかかりすぎたりあるいはそれでギア月ドキュメントが後からメンテナンスができない
ほど重厚なものになってしまってメンテナンスコストがかかりすぎて草開発スピードに追いつかないみたいなことが起こると本末転倒ですのである程度を乾燥に開きながらも重点的に抑えるカ所これらをうまく見つけ出すそして表現するというのが重要になってきますなのであくまでもこの要件定義は
このシステムというのを詳細に設計仕様としてはいけませんこれは私の以前の動画でも説明しましたがモデリングというテクニックを使ってこのシステム全体をどう表現するか
できる限り抽象的に絶対が把握しやすい状態でええうまく表現するというのが大事になってきます人間の認知できる能力というのは限りがありますからあまりにも詳細に書こうとかあるいは詳細に表現した
グラフトがマップ見たとしてもまったく理解できないあるいは詳細に理解するロールがが高すぎて認知負荷がかかりすぎていてそして aある特定の部分の把握認識が落ちてしまうみたいなことが起こってしまうようなことがあってはならないということですね
なんでできる限り簡素に書きつつも全体性を維持するなどで重要なのはこの全体とつながり今回のユーザーこのユーザーストーリーは絶対の中のどこに当たるのかそしてこのユーザーストーリーで求めている要求がどの要求のに対して影響を与えるのか依存があるのか
そういった繋がりをですねがにうまく把握するかというのがこの要求定義た重要になってきますで役割スクラブの中の役割スクレも中でどのロールがいるかですけれども基本的にはですねねえこれらはチームでうまく
メンテナンスして管理するのがいいとは思うんですけれどもこの一番外側の価値の部分これはプロジェクトオーナーが見て判断できるようにしておいてくださいでビジネス要求の部分システムの外部環境ですからこれはユーザーにヒアリングをしたりプロダクトオーナー
これらを把握するというのが望ましいと思いますシステムも協会とか足システムの中にこの辺りになってくると開発者も含めてお互いに意見を出してそしてこれらのすべてのモデルをブロジェクトオーナーを
開発者も認識が合うようにしていってくださいあくまでもこれこれも出来上がったず出来上がったモデルが重要なのではなくてこのモデルを作ろうとするプロセスに意味がありますモデルを作ろうとするプロセスの中でお互いの解釈の違いがわかったり
あるいは抜け漏れがわかったり開発者サイドからの技術的な制約だとかあるいは技術館の繋がりそういったものもお互いに把握し合うことができますですので誰か一人が作り上げてそれを一方的に渡してお願いしますって言ったようなえっそういったシーケンシャルなぁ
業務の仕方は開発の仕方ではなくてあくまでおいてれるというふうにありますから要求定義本当の一番初めのスプリント1をスタートするタイミングではあるという広く開業いたほうがいいですけれどもこれらもう一度海峡ありではなくて毎度毎度スプリントを回していく中でより詳細にしたり変更したり修正したりというのをやっていってください
そして変更が入りやすい度合いですけれどもこの一番外側が変更のが一番入りにくいですそこから内側に行けば行くほど実際のスプリントの中で変更が入る可能性が高いです
システムとして機能とか処理あるいは er 図とかを作っている中でですねこの部分の頃分のデータは実はもともと当社高価なと思ったけど作り始めてだいぶデータベースを見てみたりするとちょっと違ったかもみたいな事が起こったりしますのでこの辺何処の何方かと詳細な具体的な方に行けば
行くほど変更が入りやすいと思ってくださいそれはの環境変わったとかではなくて実際に作ってみないとわからないとかあるいは作業をし始めるとより詳細になって分かってくるみたいな領域はこの内側の方が多いということですね外側どっちがどちらかというと外部環境とか顧客が求めるものコトぺ顧客の顧客増とかですね
ペルソナとかあそういったところの定義になりますので一番初めにこういうお客こういう顧客が使うであろうという関わってくるであろうというシステム自体のフェイスの対象ペルソナが域内大幅に変わるみたいなことはあまりないと思いますただまビジネス上の外部環境は変わったとかただ
へ競合他社がこういったビジネス仕掛けてきたとかですね仕組みを変えてきたとかでビジネスのあり方自体を少し軌道修正しますといったような変化が入ることもありますのでこれが一番外側の価値自体も全く変わらないというわけではありませんがスプリントを
回していく中での変更される頻度ですねはこの内側の方がより頻度が高く変更修正がされる外側に行けば行くほどそれほど頻繁には変更修正はされないというと特性がありますのでこの外側から順に作っていくというのがいいと思いますまず勝ちを決めて社会環境や顧客を定義してそしてどのような制御をこれはの法律とか
ルールとかですねそういったものがどんなものなのかというのを先に定義してしまってそこからいいユーザーストーリーをつくってでそれをモデルとして表現しておくこれはのユーザー層リーってこの呼ぶ不全とかですねあるいは
をないんだとマージらとかでですねそういったカードでデッキをバラバラにして管理できますけれどもできる限りこのモデル上ではそれらの要求ばユーザーストーリーの繋がりですねこれらを表現しておくものを用意しておくといいと思いますそこから一つ中に入ってシステムの外部環境としてのビジネス要求
これらは業務フローだったりあるいはアクションによって変化するものこういったものを書いておきますこれにはシステム以外の領域が多忙にたくさん含まれなのでここには実際のこの業務に関わるステークホルダー業務に関わってくるものでるを入れ込んでおいて料理自体が同様な流れになっているのか
といったようなモデルを表現しておきますそしてこのシステム協会はシステムを使うユーザーとシステムの二枚とか使い方ですね利用シーンこういったものを表現しますここにはユーザーだけではなくて外部システム
からの連携だとかあとは必須ですねこういったものも含まれますのでこのシステム協会は湿地ステムの外部と内部これらをまたがったものこれらをで出し入れする際に必要になってくる情報をこれらを含めたものをモデルとして表現しておきます
システム自体はこのな仲になってくるとどんなデータを保持するのかどのようなデータを管理するのかでどういう機能が必要かどういう処理をするかこういったものをはまあ er 図とかデータプロ第ダイヤグラムなどで表現をするというのが光システムに完成
モデルになりますこれらをこれはですねこういう形してますけれどもこのモデルをたくさんいくつか作ってですねそのモデルをつなげてば個々の業務フローのこれはシステムでこの機能の部分です
でシステム協会の姉とインターフェイスの部分であればこの部分のこのインターフェースに関わるところはここですといったようにごつなげてしまってモデル自体もそれぞれ配置してそのモデルの中のあるエレメントを別のモデルもエレメントのつなげてこれとこれはモデル所は別ですけれども同じものを表しています
絶対につなげておくと後から一覧で見るときですねあここでのこの要求はこの業務フローの頃流れのことで実現しようとしていてそしてしてもデータで行くところ下たところデートとこのデータとこのデータを使うのがここの部分なんだらそしてここにインターフェイスが入ってくるので画面の
レイアウトとかあるいは出力する帳票とかというものはこういうものを出すというのを想定してるんだなといったようなことがこれらのモデルを見でつながりがわかりますんでそれとそのつながりをさかのぼって要求まで戻ってさらに本級同士が
繋がってたりモデルの中ではつながっているはずですからその中の要求からまたつなげたものを見て全体を把握するみたいなことができるわけですねするとその要求自体が具体的に何を意味を何を意味するのかというのがメンバー名はメンバーですね全ても頭の中で一致するよう
に心がけるそういった使い方をしますですのでこれはユーザーストーリーという本当にシンプルな
そして価値を中心にして考えるいうユーザーの体験ユーザーの世界観これらを中心にして考えるというのはアジャイルスクラムの中では特に強調されますけれどもメンバー全員が
それを具体的にそれらを実現するために具体的にじゃあ何を得ればいいんだという部分を共通認識させてそして絶対性を損なわないというためにこのモデリングというのをうまく使っていくといいと思いますなので要求定義となるとオーダーボールモデルですと幼犬猟犬定義という形で本当に
一番初めのフェーズで一気に落とし込んでいくと思いますけれどもagile スクラムの場合ですと全体を粗くやりながらそしてその中の床が一部をより深く減っていくといったような提示のような最後の進め方をするのクロエするといいと思います
すべてを詳細に全部やろうとするとそれはもうも8 c 傾斜なウォーターフォールモデル開発のような形になりますのでまずはサーク広くやっておいてそこからどうかこれかなという当たりを決めたら一気に深くやっていくそしてまたその中の次のプライオリティが高そうだなと思う所になったらまた深く
ホットいくみたいな感じでやっていくといいと思いますその前の床を掘るんだとかどこより深くやればいいんだという当たりを決めるためにもこのユーザーストール要求を決めてからこのように少しモデルを書き進めていくとそのあたりが見つけやすくなり具体的に技術的にどうやるんだとか要求が本当にそのは日帰った要求なのかどうか合理的な要求になるかどうか
やばユーザ特定のユーザーが何が大きな声を上げてあれが欲しいんだと化すいます今すぐ作れとかって言われたものを優先してしまうみたいなことに陥らないようにシステム全体として本当に最も roi が高い少ない労力で最も大きなメリットを享受できる価値を提供できる機能というものがどこにあるのか
それがその後のイテレーションの中でもコアになってそれがが元になってより後半どんどん機能が追加されて全体の子システム全体がより健康になっている有機的に結合してシステムとしての振る舞いが大きくなってきたときにより価値を
ますようなシステムの構造になるのかどうかというか場合をある程度把握しておく比しておいたほうがいいんですけれどもそれをする場合にはやはり v のように初めの段階で要求をつなげてそこから具体的なね要求の別の側面よりより技術的な側面にフォーカスをしていくということをやりながら
もそして実質をしてリリースしたレビューの段階でですねリリースする機能リースした機能こういったものをまたこのを練るの中で適合させて前体制が維持できているかどうかそういったものを把握するために使うと良いと思います
前の動画ではそのアジャイルモデリングをこれをさらにもっとシンプルにして少なくともいい要求そしてシステムこの2つの切り口でモデリングを行うだけでもずっと全体性を把握しやすくなりますという風に説明をしました土井らもうこの萌えリングもですねいろんなテクニックがあってベースとなるが uml
のようなモデリングテクニックをベースにしていろんなパターンのモデルを書くというのがあっ2それで確かにいいんですけれどもこのモデリングはモデリングで覚えないといけないといったような学習コストがかかったりドキュメントそのものがあまりにも増えすぎてメンテナスができないといったことが起こる場合も
あると思いますそれはそのチームの能力スキルあるいは慣れ親しんだえ状態に対して持ってもいいものを使えばいいと思うんですけれどもすべてを
このモデルの中で表現し切ろうとしてしまうとこのモデル時代が重くなってしまいますメンテナンスしにくくなりますなので何を優先するかと考えるとこのユーザーストーリーと諸要求都そしてシステムとしての振る舞い構造
この3種類をモデルとしてまずはシンプルに書いてみてそこからさらにこのようにしてエリアを分けてより詳細に踏み込んでいくというステップでやればいいと思いますこれはですねあのck 者のに開発をするウォーターフォールモデルとは違って手順が先にあるわけではなくて開発メンバー含めたチームメンバーの能力
capacity ですねこれらに対してどういうアプローチを取るかの方が重要ですなのでこれらのモデルのかけたと詳細にまだ理解していないあるいは自分たちの手にまだなじんでいないというツールをとりあえず今からモデル10個あるのでこの10種類のモデルをプレイ柄くださいみたいに行ってしまうといいですねてい
きちんとその他インボックスの中に収まらなくなりますなのでどちらかというとそのメンバーが最も慣れ親しんだであろうと思うものいい絞った方が本当はいいんですけれどもagile モデリングの動画で言いましたが少なくとも3種類のモデリング歳できればもう
開発の方に行きましょうと割り切って開発が始められるぐらいシンプルなものから取り組んでそしてより詳細なものをそれ以外のモデルも
習得しながら表現して作っていくというやり方で良いと思います私今こういう人ってオチこのようにして紹介しましたのはこのようなて国がありますよと言うこういうことですのでこのようなテクニックを使わないといい物を作れないというわけではないです
なので全くモデリングを行っていないと言ういうチームマットモデリングを行わなくても上手く今うまくいっているというチームもあると思いますのでその場合は無理ですねこのモデリングをしましょうとを押し付ける必要ないとは思いますがただ習得できてそしてチーム全体でこれらがシェアできる状態をつくってしまえばそう
ではとてもチームにとって見てですね有益な状態になると思いますのでぜひトライしてみてください