はじめての要件定義
今回は仕事日記です。
仕事で初めてシステムの1機能の要件定義をやることになりました。しかし私は今まで要件はまとまっていて細部や非機能要件を詰めてシステム設計するフェーズからしかやったことがありませんでした。
そこで今回ははじめて要件定義をするにあたって考えたこととして、PM経験が豊富な上司に聞いてみたことと、今回の要件定義のどう進めることにしたかという事を書きます。絶賛進行中なので良い悪いの話はまた別の機会に。
上司に聞いたことから見出したこと
要件定義のゴール
自分たちは何を作るか、依頼側と合意すること。
最終成果物
合意するためのアウトプットを提示する。
eg. 画面定義所(誰が何のために使うのか、権限、ボタンを押すとどうなるのか)
(IPAのドキュメントがありました。今回はここまで厳密にやるつもりはないのですが、何かの参考になるかもしれないのでメモ)
そしてこのアウトプットを作るために、目的の再確認をしたり、現状を把握したり、やりたいことを整理していく必要がある。そういった考えを詰めるのにUMLが使える。とりわけ上司の場合、ユースケース図でシステムがやるところとやらないところを明確にしたりすることをよく行うとのことだった。
注意事項
要件をまとめていざ作ろうとすると割りに合わないくらい工数がかかってしまうこともあるので、システム設計のこともある程度一緒に考えていくのが良い。
今回の要件定義の進め方
前提
登場人物に関しては、関係者は社内の人間のみになります。
- PDM: システムの企画をする人。カレンダーを見ると想像を絶する多忙さ
- 先輩エンジニア: 同じチームの先輩。今回は私のサポートしてくれるポジションにある
- 自分: この機能の開発を主体的に進めていく立場にある。今回触ることになるコンポーネントは携わったことがないので中身のことも調べつつやっていくことになりそう
機能に関しては、以下のような状態でした。
- 以前からやりたいこととしてマイルストーンにあったもの
- ざっくりとした要望があり、どう形に落とし込んでいくか(要件定義)はシステム側と相談しないと詰められない状態
- この企画が作られた背景や、あるとどうユーザーにとってメリットになるのか断片的なドキュメントしかないので、チーム移動で途中参戦した自分の場合そこから把握する必要もあった
- (余談だが、業界柄人の移り変わりも激しいのでこういった長期目線で何をやっていくべきなのかという思想が失われがち)
立てた計画
方針を立てる
ひとまず「要件定義のたたきを作ってPDMに共有。それを元に要件を固めていけるようにする」という方針を立てました。最初の共有までの期限は1週間です。今の段階ではあまり長くやっても正解にたどり着けるものではないのと、システムや機能を考えるにあたって調査の時間が欲しかったので1週間後に設定しました。そしてPDMに共有する前段階として、前日に先輩に共有して意見をもらいます。
共有用のアウトプットのフォーマットを作る
無限に時間を掛けられてしまう領域なので、とりあえずアウトプットのフォーマットを作ることにしました。今回は以下です。
- この機能の目的
- 想定ユースケース
- 最終成果物(画面)のイメージ
機能の目的に関しては、mtgが途中参戦だったので丁寧に説明してもらう機会がありませんでした。過去ドキュメントを漁った断片情報からこうなのだろうなと思うものはあったのですが、それが合っているか確認するのも兼ねて冒頭に据えます。
想定ユースケースに関しては、とりわけ私の理解が及んでいない部分でした。実は打ち合わせした時に全然話についていけなくて内心軽くパニクってたのですが、この部分を理解していないからだったんだということにフォーマットを作っていて気づきました。 ユーザーの気持ちを考えることはできても、層が自分から離れていることもあり短い時間では浅い理解しかおそらくできないだろうなと思っています。とはいえ考えるうちに少しずつ近づけるようにもなりたいので、まずは自分で考えてそれから「こんなふうに考えてみたんですが、実際はどうなのでしょう」といった形で聞いてみようと思いました。とりわけこの部分を確認するために3日目に先輩に時間をもらうことにしました。 これも無限に悩めてしまうのでアウトプットベースで、3つのペルソナを作ってそれぞれに対して3パターンユースケースを挙げてみました。
最終成果物(画面)のイメージに関しては、今はたたきの時点なので丁寧には作りません。何かしらベースがあった方が話が進むと思うので、ipadでjamboardに絵を描いてリンクを共有する形にしました。jamboardを使うことで、修正をすぐにブラウザに反映させることができるのが良さそうでした。(実際のmtgではまだ試していない)
Google Jamboard: 共同作業に適したデジタル ホワイトボード | G Suite for Education | Google for Education
こんな感じで進めています。
おわりに
要件定義は大事で、ここをしっかりできなければ後々取り返しのつかないことになることはよく耳にしますが、実際どうやっていくのがいいのか、何に気をつけたらいいのかなど、体系的にまとまっていて初心者の手引きになるドキュメントを知りませんでした。各々の地頭を駆使して行われているようなイメージでした(そして実際そうみたいだった)。我流でやるのもいいけど、せっかく先駆者がいるのであればその人たちの学びを参考にして避けられる失敗は避けて進めたいと思っていました。
今後も要件定義をやる機会はあると思うので、なんとなくでやるよりも自分なりに要件定義との付き合い方を掴められるようになりたいものです。
