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
Preparation for actual requirement definition
Search
Kent Ishizawa
November 13, 2023
Technology
1
1.3k
Preparation for actual requirement definition
2023年11月14日にFindy様の「要件定義 先達に学ぶ今日から使える実践テクニック Lunch LT」で登壇した資料です。
Kent Ishizawa
November 13, 2023
Tweet
Share
More Decks by Kent Ishizawa
See All by Kent Ishizawa
SIer Who Leapt Through Time
kent4989
1
850
Other Decks in Technology
See All in Technology
アカデミーキャンプ 2025 SuuuuuuMMeR「燃えろ!!ロボコン」 / Academy Camp 2025 SuuuuuuMMeR "Burn the Spirit, Robocon!!" DAY 1
ks91
PRO
0
150
Amazon Q と『音楽』-ゲーム音楽もAmazonQで作成してみた感想-
senseofunity129
0
140
LTに影響を受けてテンプレリポジトリを作った話
hol1kgmg
0
370
o11yツールを乗り換えた話
tak0x00
2
1.4k
AIに目を奪われすぎて、周りの困っている人間が見えなくなっていませんか?
cap120
1
640
形式手法特論:位相空間としての並行プログラミング #kernelvm / Kernel VM Study Tokyo 18th
ytaka23
3
1.3k
風が吹けばWHOISが使えなくなる~なぜWHOIS・RDAPはサーバー証明書のメール認証に使えなくなったのか~
orangemorishita
15
5.8k
ユーザー課題を愛し抜く――AI時代のPdM価値
kakehashi
PRO
1
120
Amazon Inspector コードセキュリティで手軽に実現するシフトレフト
maimyyym
0
110
ファッションコーディネートアプリ「WEAR」における、Vertex AI Vector Searchを利用したレコメンド機能の開発・運用で得られたノウハウの紹介
zozotech
PRO
0
320
Intro to Software Startups: Spring 2025
arnabdotorg
0
260
結局QUICで通信は速くなるの?
kota_yata
5
5.4k
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
GitHub's CSS Performance
jonrohan
1031
460k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
[RailsConf 2023] Rails as a piece of cake
palkan
56
5.8k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Documentation Writing (for coders)
carmenintech
73
5k
Building Applications with DynamoDB
mza
96
6.5k
Practical Orchestrator
shlominoach
190
11k
The Invisible Side of Design
smashingmag
301
51k
We Have a Design System, Now What?
morganepeng
53
7.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
Transcript
実戦要件定義入門以前 石沢 ケント @agnozingdays
自己紹介 石沢 ケント (@agnozingdays) • 株式会社 電通国際情報サービス (ISID)勤務 • 固めのドメイン向けの受託開発PjM、PMO等を経て現在は組織の技術支援等を担当
• 技術士 (情報工学部門) • 個人ブログ 「勘と経験と読経」(https://agnozingdays.hatenablog.com/) • 2016年頃まで「要求開発アライアンス」という要件定義工程をテーマにした オープンコミュニティの幹事を担当(コミュニティは諸事情により解散) • 告知 • 所属会社のテックブログ推進しています。ぜひご覧ください! ⇒ISIDテックブログ(https://tech.isid.co.jp/ ) • 一緒に働いていただける仲間も募集しています! ⇒ISIDキャリア採用(https://career.isid.co.jp/ ) • 今回の発表内容は発表者個人の見解に基づくものであり、発表者が所属する組織の公式見解ではありません 2
実戦要件定義入門以前 石沢 ケント @agnozingdays
どうして実戦要件定義入門「以前」なのか 要件定義は「作戦負け」することが多い工程 安易・無策に突入すると失敗する 推奨する打ち手:「回避」または「十分な準備」 4
どうして実戦要件定義入門「以前」なのか 要件定義は「作戦負け」することが多い工程 安易・無策に突入すると失敗する 推奨する打ち手:「回避」または「十分な準備」 5 …という話の詳細は ブログ記事「実践要件定義入門以前」に書いています。 (https://agnozingdays.hatenablog.com/entry/2023/09/20/080000 ) 今回は文書化が難しくて掲載を見送った
実戦向けのポイントについてお話します。
要件定義の難しさは、ライブパフォーマンスの難しさに似ている 要件定義は スポンサーは、 ビジネスオーナー パフォーマーは、 コンサル or ベンダー担当者 観客はユーザー、 で実施する一発限りの
ライブパフォーマンス のようなもの 6
7 スポンサー(ビジネスオーナー) 「時間は2時間、予算は〇〇円、 テーマは〇〇で、 あとはよろしく。 最終評価は最後に私がするね」
8 観客(ユーザー) 「私たちは素人なんで、 プロとして 楽しませてくださいね」
9 パフォーマー (コンサル or ベンダー) 「・・・・・・・・」
10 結果 「・・・・・・・・」
要件定義の難しさは、ライブパフォーマンスの難しさに似ている 要件定義は スポンサーは、 ビジネスオーナー パフォーマーは、 コンサル or ベンダー担当者 観客はユーザー、 で実施する一発限りの
ライブパフォーマンス のようなもの 11
12 「作戦負け」を避ける前に必要なもの 手数、場数、あとは作戦
手数と場数 手数=テクニックの数 • 要件定義はユーザーとのコラボレーション作業 • 相手の状況やレベルに合わせて、手法や表現を変えたほうが良い • いろいろな手法を学び、手に馴染ませておく • 書籍等で紹介されないオススメのテクニックは「ライブ文字起こし」
(ニュース等を聞きながらその場でテキストやダイアグラムにする練習が有効) 場数=経験数 • 簡単には増やせないので、疑似体験で補充するのがオススメ • 手近な要件定義書(実物がよい)を批評的な立場で精読する (自分だったらどうやるかを考えながらよむ。書き直しても良い) 13
余談:要件定義におけるテクニックは(残念ながら)あまり変化していないようだ • 『ソフトウェア要求 第3版』(2014)を書いたカール・ウィーガーズが新しい本を出していた。 『Software Requirements Essentials』(2023) で、斜め読みをしているが、残念ながら真新しさはなさそう。 (そのうちちゃんと読んでブログに感想を書く予定) •
最近新しいと思った手法はヴォーン・ヴァーノン 『要件最適アーキテクチャ戦略』(2022) で紹介されている イベントストーミングという (私の理解では)ユーザーストーリーマッピングの拡張手法。 • 何がいいたいかというと、 実装技術に比べると発展や進歩がゆっくりなので、 要件定義に関する手数の習得はそんなに大変ではないのでは…… (まずは、IPAの要件定義ガイドを読みましょう) 14
あとは作戦 どのように要件定義という山を登るのか、 ビジネスオーナー、ユーザーの代表 ベンダーで事前に話し合い、 青写真を描いておくことをオススメする • 要件定義の章立ではなく、中身の話 • 青写真は正しくなくて良いし、 そもそもラフなもので良い
• ざっくりモデリング(ざくモデ) 15 ビジネスオーナー ベンダー ユーザーの代表 計画は3カ月だが、 2カ月目で状況を 知りたい 通常はこういう 進め方なんですが どうですかね 不慣れなので 前半は詰め すぎないで 欲しいです 〇〇には こだわりたい この図は 読めますか 現行の業務規程は 変えられるので とらわれないで良いです 〇〇さんの 話をよく 聞いて 〇〇が いちばん 難しい
もうひとつの作戦 要件は基本的には不安定なもの 単に聞き出して 整理・文書化するだけでは 不安定さは変わらない。 不安定な要件を「立たせる」ために 構造を持たせることを事前に考えたい。 (その方法はケースバイケース) 個人的な好みは ユースケース×フロー×データモデル
16
まとめ 要件定義は「作戦負け」しやすい 要件定義はライブパフォーマンスのようなもの 失敗を避けるために、手数、場数、作戦を準備しよう 17