初めての要件定義で得た気づきと学び
 くまごろー


くまごろー @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