Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
要件定義で得た学び・気づき
Search
kumaGoro95
June 15, 2023
Programming
4
2.4k
要件定義で得た学び・気づき
kumaGoro95
June 15, 2023
Tweet
Share
More Decks by kumaGoro95
See All by kumaGoro95
DDDやってみたら 実装以前の領域での学びが深かった話
kumagoro95
14
8.3k
メンバーのわかりませんはチームが成長するチャンス.pdf
kumagoro95
1
370
ふりかえりでふりかえることしかできなかったジュニアチームが、次の打ち手を出せるチームになるのにやったこと
kumagoro95
3
1.3k
Githubのアクティビティ履歴からチームの健康状態を知る(Findy Teams使ってみた)
kumagoro95
0
510
プログラミングで小数計算すると なんで誤差が発生するのか?
kumagoro95
0
200
導入事例を通じて理解するドメイン駆動設計
kumagoro95
0
310
The Assembly ~ directly controlling CPU ~
kumagoro95
0
360
非エンジニアがドメイン駆動設計(DDD)について説明してみる。
kumagoro95
1
340
カンタン楽しいマイコンの世界
kumagoro95
0
94
Other Decks in Programming
See All in Programming
Androidアプリのモジュール分割における:x:commonを考える
okuzawats
1
280
선언형 UI에서의 상태관리
l2hyunwoo
0
270
20241217 競争力強化とビジネス価値創出への挑戦:モノタロウのシステムモダナイズ、開発組織の進化と今後の展望
monotaro
PRO
0
280
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
1k
PHPで作るWebSocketサーバー ~リアクティブなアプリケーションを知るために~ / WebSocket Server in PHP - To know reactive applications
seike460
PRO
2
770
Swiftコンパイラ超入門+async関数の仕組み
shiz
0
170
ecspresso, ecschedule, lambroll を PipeCDプラグインとして動かしてみた (プロトタイプ) / Running ecspresso, ecschedule, and lambroll as PipeCD Plugins (prototype)
tkikuc
2
1.8k
はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025
cohalz
3
2.7k
Fibonacci Function Gallery - Part 2
philipschwarz
PRO
0
210
Запуск 1С:УХ в крупном энтерпрайзе: мечта и реальность ПМа
lamodatech
0
950
良いユニットテストを書こう
mototakatsu
11
3.6k
ドメインイベント増えすぎ問題
h0r15h0
2
560
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Typedesign – Prime Four
hannesfritz
40
2.5k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Designing for humans not robots
tammielis
250
25k
Designing Experiences People Love
moore
139
23k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
500
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Measuring & Analyzing Core Web Vitals
bluesmoon
5
210
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7k
Into the Great Unknown - MozCon
thekraken
34
1.6k
Transcript
初めての要件定義で得た気づきと学び くまごろー
くまごろー @kumaGoro_95 • 北海道出身 • 2021年5月~ リゾート運営会社でWebエンジニア • 前職は公務員(新卒からずっと務めてました) •
メインはバックエンド(Java) • 最近全然コード書けてないのが悩み ひいじいちゃんは熊 太郎
3 登壇の経緯 • ITエンジニア3年目です • 数か月前に要件定義フェーズに挑戦し始めました • PJは現在進行形ですが、この数か月間だけでも色んな学びがありました • 学びをアウトプットしたかったので今回LTに挑戦しました
• ほんの少しでも皆さんの役に立てれば嬉しいです • エピソードの紹介→学び/気づきの紹介 という流れで話します!
4 遡ること約半年前
5 入社以来所属してたチームを離れた エンジニアなりたての頃からお世話になったスクラ ムチーム 既存システムの保守運用がメイン たまに機能追加したり、改修したり
新しいチームはこんな感じ 6 くまごろ (エンジニア) ステークホルダーたち 現場を知り尽くす ベテラン 既存システムを掌 握するエンジニア PJ統括者
PO UIUX担当 プロダクトチーム 顧客向けの宿泊予約システ ムを新規開発します✋
7 新チームでは要件定義に挑戦することに...
8 最初はこんな気持ちだった ついにこの時が来て しまった... そもそも、要件定義って何や ればいいんだろう?
9 とりあえず、要件定義について調べた。 • 要件定義の他に「要求定義」ていうのもあるんだ • 自分たちの現在地はどこなんだろう? ◦ PJの目的/プロダクトを通じて実現したいことは、既にPJの統括者が割り出して いた
◦ 要求定義は終わってて、要件定義からかな? → 「何を作ればいいか」を決めればいいのか!と思った(安直に) 要件定義は、プロジェクトやシステム開発において、必要な機能や性能・制約条件などを明確に 定める作業を指します。
10 とりあえず走り出した。 • 最初はひたすらインプット。関係者の時間をもらって下記の情報収集 ◦ 業務知識 ◦ 既存の宿泊システムの構造 ◦ プロダクトのシステム要求
11 ユーザーストーリーを作ってみた。 • 得られた知見を参考にしながら、ユーザーストーリーを書き出してみた • オポチュニティ/エピック/ユーザーストーリーの3つの階層で書いた → これで形になってる気がするけど自信ないな...
12 レビューしてもらったけど... • 思ったほどFBが出なかった • 枝葉のような指摘がいくつか来る程度 • ユーザーストーリー完成までに2回見てもらったが同様の状況 → レビュアーにOKもらえたからいいけど(良くない)、なんかちょっと不安...
13 ワイヤーフレームを作り始めた • ユーザーストーリーをワイヤーフレームに盛り込んでいった • 「画面ベースで考えると、細部にこだわり過ぎるので良くない」という話を聞いてたの で、とにかくシンプルに作ることを心掛けた(miroの図形を駆使) 本当にこれくらいシンプル なやつ
14 これがターニングポイントだった
15 レビューに持っていったら... • 打って変わって大量のFB ◦ 「現場的には予約時にこういう情報がほしくて~」 ◦ 「これは既存システムにもあるけど今は必要ないんだよね」 • 芋づる式に新しい情報や観点が出てくる
◦ 「うちはこれでOKだけど、あっちの業務に支障出るかも」 ◦ 「この部分の課題はオペレーション変えることで対応できそうだよ」
16 レビュー/修正を何度か繰り返す内に • ワイヤーフレームは関係者皆の納得のいくものになってきた • チームのプロダクトに対する解像度が上がった • 結果、Whyの理解/意識が足りないことに気づいた ◦ 色んな方面からのFBや課題が集まることで、プロダクトの目的を強く意識せざ
るを得なくなった
17 ワイヤーフレーム→ユーザーストーリー • ユーザーストーリーを改めて確認したら、めちゃくちゃひどかった ◦ 機能の羅列でしかなかった。Whyが全く意識されてなかった。 ◦ 理解度が低いまま、想像で書かれていた • ユーザーストーリー作成時に、こういう課題を抱えていたことがわかった
◦ 業務/既存システムの理解が浅い ◦ 関係者がどのような課題を抱えているかもわかってない ◦ 要求を浅いレイヤーでしか理解してなかった。その裏のビジョンが見えてな かった
18 この出来事をふりかえって 気づいたこと/思ったこと
19 ワイヤーフレームを使った活動は、 プロトタイピング/デザインシンキングの進め方だった • ユーザーストーリーは、プロトタイプとしては微妙だった • ユーザーストーリーではアイデアを評価することができなかった 「デザイン思考とサービスデザインと UXデザインとUIデザインの違い」 https://note.com/kawasagi9/n/n606e1ce1992b
20 何故ワイヤーフレームは良かったんだろう? • ワイヤーフレームは皆が一目見て理解できるものだった! ◦ エンジニア、PdM、マーケ、現場出身スタッフ... • 皆が理解できるので、異なる立場のスタッフが、ワイヤーフレームを足掛かりにして 議論ができる。いわば皆の共通言語 •
Miroを使った ◦ 議論しながら付箋で説明を書き加えることで、全員が話についていける ◦ デザイン性を完全に排したことで、皆が細部を気にせずに済んだ → 皆が評価/テストすることができることで、デザインシンキングによる学習が進んだ
21 学習が進むことで世界の解像度が上がる • デザインシンキングの5ステップループを回せるようになって学習が進み、プロダクト を取り巻く世界の解像度が上がった ◦ 業務/既存システムの理解度 ◦ 関係者がどのような課題を抱えているか ◦
「要求」と言われるものが、その実なにを指しているのか。その裏側にどういう 思いがあるのか
22 解像度が上がることで見えてくるもの • 解像度が上がったことで、当初は気づけなかった課題/解決策/思いが見えるように なる ◦ プロダクトを通して見つけた課題が、実は組織横断的な課題だったり ◦ 「オペレーションを変える」という解決方法に至ったり ◦
単なる1機能だと思ってたものが、プロダクトのビジョンを実現する柱の1つだと 気づいたり → 「自分たちが本当に作りたいもの」に少しずつ近づいていけるようになってきた ユーザーストーリー作成時はこれ が足りてなかった
23 さいごに
24 要件定義フェーズのこと勘違いしてたなあ • 要件定義って「クライアントの話をヒントに、プロダクトの正解を探り出す」活動だ と思ってた... ◦ プロダクトのイデア的なものがあると思い込んでた • ワンチームで、作りたいものの解像度を上げる。プロダクトの姿を形づくっていく ◦
最初から100%見えてる人はいない(クライアントも開発者も皆) ◦ 大事なのは、仮説検証を繰り返すことでチームが学習すること ◦ 学習を積み上げるほど、本当に作りたいものに近づくことができる ◦ そういう意味では、事業会社って要件定義やりやすいな ◦ 初期に学習サイクル構築できるかがPJの命運を握りそう
ご清聴ありがとうございました! 25