要件定義どうしてる？PMたちがたどり着く最適解を聞いてみた【開発PM勉強会vol.7】

2021年10月から2ヶ月ぶりの開発PM勉強会を開催しました！

今回はPMが切っても切れない「要件定義」をテーマに事業会社のPMさんに登壇いただきました。

普段の受託開発テーマと趣が違うためか定員300名を超える反響の大きさでした。ご参加いただいたみなさんありがとうございます！

今回も共有のご要望が多かったため、こちらで勉強会の内容をシェアいたします！

開催概要

開催日時：2021年12月14日（火）19:00〜20:30
開催場所：Zoom
企画内容：みんな要件定義どうしてる？共有LT【開発PM勉強会vol.7 オンライン】

イベントページはこちら👇
https://peer-quest.connpass.com/event/229463/

各社の要件定義

今回は5名の登壇者に各社の様子をお話ししていただきました。

プロジェクトの形態も様式も各社それぞれで違っていてどのタイトルも気になります！

時間	タイトル	発表者
19:00	オープニングトーク	運営スタッフご挨拶・イベント案内
19:10	レガシー＆機能開発を要件定義で叶えるには？（仮）	鈴木 碩子 さん / 株式会社PR TIMES
19:20	ビジネス部門と連携した要件定義（仮）	御守 一樹 さん / ヘイ株式会社
19:30	「ガチガチ要件定義」をやめるまでの奮闘記	榎本 命 さん / Classi株式会社
19:40	要件定義とアジャイルな開発のバランス	元木 直哉 さん / 株式会社HERP
19:50	3つのシーンから見る失敗の要件定義（仮）	塚本 尚 さん / 株式会社Speee
20:00	ぶっつけパネルディスカッション！	まいどる / PeerQuest Inc.
20:20	みんなのまとめ・総評
20:30	撤収！

レガシー＆機能開発を要件定義で叶えるには？/ 鈴木 碩子さん

事業本体の歴史が長い中で新しいチャレンジをされているPR TIMESの鈴木さんからはレガシーと新規開発の共存関係をPMとしてどうやって調整していったかのお話。

デザインシステム、Jiraの導入をしてスクラム改善やQAの自動化など全社で何が進められているのかを「見える化」することによって共通部分や優先順位を決めていくことによってレガシーを生み出さない、たくさんの協力者を早めに巻き込むなどコミュニケーション能力の問われるPMにはどれも大事なことばかりでした。

その中で「夢は大きく・リリースは小さく」はPMとして柱になる考え方だなと感じました。どうしてもリリース単位が大きくなりがちで遅延とか差し戻ししがちですものね。

ビジネス部門と連携した要件定義 / 御守 一樹さん

御守さんは今回体調不良でお休みでした。
ビジネス部門と開発の連携はPMにとって大事になる部分なのでまたの機会に是非ご登壇いただきたいです。

「ガチガチ要件定義」をやめるまでの奮闘記 / 榎本 命さん

Classiの榎本さんからは事業界隈の激変期に合わせた開発手法としてウォーターフォールからアジャイルに切り替えたことで課題が山のように出てきたところからのお話。「ぶん投げられる」ようになってから解決できることが増えてきたようです。

具体的に「役割」「意識」「話し方」を変えることでエンジニアチームとの対話が生まれアジャイルに即した開発体制が生まれるようになってきたとのことでした。

この体制にユーザーをレビュワーとして巻き込み、より高速で質の高い開発へチャレンジしている部分は受託開発ではなかなか改善点として見れない部分を見える化できるのでとても素敵だなと思いました。

要件定義とアジャイルな開発のバランス / 元木 直哉さん

要件定義というフローも定義書もない！？と衝撃から始まったHERP元木さんのお話。

ヒアリングや議事録などのユーザーからの1次情報が開発チームに伝わる業務フローにすることで共通認知形成できるようにして仮説検証を繰り返せるようになっていることが機能要件・非機能要件のアップデートにつながっているというところが情報の精査がされていてすごいなと思いました。

その一方でメンバーに高いスキルと自立性が求められるので採用のハードルが上がってしまうという問題も抱えている様子。PM界隈でも気になるようになりましたよね。採用についてどのような取り組みをされているのかも気になったので機会があれば是非伺ってみたいです。

3つの決めつけから見る失敗の要件定義 / 塚本 尚さん

決めつけからくる失敗から導き出されたセオリーをお話していただいたのはSpeeeの塚本さん。

実体験のお話はありがたいですし、特に失敗から学んだことは貴重ですよね。

塚本さんがしてしまった３つの決めつけは「エンジニア側」「ビジネス側」「既存のシステム、仕様」についてでした。これはけっこう経験ある方も多いのでは？PMはプロジェクト全体をみる必要があるがゆえだと思うので気をつけないといけないなと痛感しました。

要件定義とはWhy(実現させたい理由)とWhat(実現させたいこと)をしっかり定義することであり、PMはwhatに強く責任を持ち、how(どうやって実現させるか)はチームに属するとおっしゃっていたのが印象的でした。

決めつけずに実現させたいことに漏れがないかをビジネス側と、仕様や現状のシステムについてはエンジニア側とチーム内の会話やディスカッションを大事にしてプロジェクトを成功に導くのがPMの役割だということを再確認できてよかったです！チームビルディングにもなんだか興味が湧いてくるLTでした。

ぶっつけパネルディスカッション！

参加していただいた方をmiroに招待して、リアルタイムにボードで交流をしました！

自己紹介、どんな話を中心に聞きたい？、登壇者に聞いてみよう、感想の４つの島があって皆さんにコメントしていだきました。

今回のテーマ「要件定義」についてお客様をどうやって要件定義に巻き込み、ヒアリング、要望の優先度などの要件定義をいかにより良くするかという質問が多くてその熱量がすごかったです。

登壇者と参加者の双方向のコミュニケーションで要件定義についての考察が深まった時間になりました。

まとめ

今回は登壇していただいた方々の要件定義にまつわるお話、今までの業務での学びを共有していだき有意義な勉強会になりました。

鈴木さんの「夢は大きく、リリースは小さく」、榎本さんの「ウォーターフォールからアジャイルスクラムへ」は変化スピードがどんどん加速している今の時代に即したプロダクト開発の主流になってきているのを感じましたし、元木さんがおっしゃっていた「一次情報を共通認知形成する」ことも重要なポイントではないかと思いました。

塚本さんのお話では「決めつけ」をせずにビジネス側、システム側を横断してプロジェクトをうまくコントロールしていくことが大切だと改めて感じました。

会社ごとの要件定義のとらえ方、作成方法などはさまざまでしたが共通していたのは「コミュニケーションが大事」ということでした。

要件定義でもそうですがPMはチーム、ユーザー含めた人を巻き込む力、会話、ディスカッションしやすい環境を作ること、時に失敗をしながら自分たちの最適解を見つけていく役割なんだなという気づきがありました。業務でもそのことを忘れずに日々がんばっていきたいと思います。

今回の記事担当：なお

※開発PMの採用や育成にお困りの方はdevPM運営チームにお気軽にご相談ください※
メール：contact@peer-quest.jp / DM：@devPM_io