2023年11月14日にFindy様の「要件定義 先達に学ぶ今日から使える実践テクニック Lunch LT」で登壇した資料です。
実戦要件定義入門以前石沢 ケント@agnozingdays
View Slide
自己紹介石沢 ケント (@agnozingdays)• 株式会社 電通国際情報サービス (ISID)勤務• 固めのドメイン向けの受託開発PjM、PMO等を経て現在は組織の技術支援等を担当• 技術士 (情報工学部門)• 個人ブログ 「勘と経験と読経」(https://agnozingdays.hatenablog.com/)• 2016年頃まで「要求開発アライアンス」という要件定義工程をテーマにしたオープンコミュニティの幹事を担当(コミュニティは諸事情により解散)• 告知• 所属会社のテックブログ推進しています。ぜひご覧ください! ⇒ISIDテックブログ(https://tech.isid.co.jp/ )• 一緒に働いていただける仲間も募集しています! ⇒ISIDキャリア採用(https://career.isid.co.jp/ )• 今回の発表内容は発表者個人の見解に基づくものであり、発表者が所属する組織の公式見解ではありません2
どうして実戦要件定義入門「以前」なのか要件定義は「作戦負け」することが多い工程安易・無策に突入すると失敗する推奨する打ち手:「回避」または「十分な準備」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