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
昭和の職場からアジャイルの世界へ
kumagoro95
1
530
DDDやってみたら 実装以前の領域での学びが深かった話
kumagoro95
13
8.3k
メンバーのわかりませんはチームが成長するチャンス.pdf
kumagoro95
1
390
ふりかえりでふりかえることしかできなかったジュニアチームが、次の打ち手を出せるチームになるのにやったこと
kumagoro95
3
1.4k
Githubのアクティビティ履歴からチームの健康状態を知る(Findy Teams使ってみた)
kumagoro95
0
530
プログラミングで小数計算すると なんで誤差が発生するのか?
kumagoro95
0
210
導入事例を通じて理解するドメイン駆動設計
kumagoro95
0
340
The Assembly ~ directly controlling CPU ~
kumagoro95
0
370
非エンジニアがドメイン駆動設計(DDD)について説明してみる。
kumagoro95
1
350
Other Decks in Programming
See All in Programming
コンテナでLambdaをデプロイするときに知っておきたかったこと
_takahash
0
140
AtCoder Heuristic First-step Vol.1 講義スライド(山登り法・焼きなまし法編)
takumi152
3
980
令和トラベルにおけるコンテンツ生成AIアプリケーション開発の実践
ippo012
1
260
安全に倒し切るリリースをするために:15年来レガシーシステムのフルリプレイス挑戦記
sakuraikotone
5
2.2k
아직도 SOLID 를 '글'로만 알고 계신가요?
sh1mj1
0
360
PHPでお金を扱う時、終わりのない 謎の1円調査の旅にでなくて済む方法
nakka
3
990
List とは何か? / PHPerKaigi 2025
meihei3
0
550
研究開発と実装OSSと プロダクトの好循環 / A virtuous cycle of research and development implementation OSS and products
linyows
1
190
ローコードサービスの進化のためのモノレポ移行
taro28
1
330
신입 안드로이드 개발자의 AI 스타트업 생존기 (+ Native C++ Code를 Android에서 사용해보기)
dygames
0
500
PHPer's Guide to Daemon Crafting Taming and Summoning
uzulla
2
1k
CQRS+ES勉強会#1
rechellatek
0
390
Featured
See All Featured
A Tale of Four Properties
chriscoyier
158
23k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
490
Building an army of robots
kneath
304
45k
How to train your dragon (web standard)
notwaldorf
91
5.9k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Music & Morning Musume
bryan
46
6.4k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
320
Into the Great Unknown - MozCon
thekraken
36
1.7k
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