1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

要件定義で学んだこと

Posted at

はじめに

開発もしたことない新卒webエンジニアが、研修明けから要件定義に放り投げられて学んだことの備忘録。

大事だと思ったこと

認識の齟齬がないように気を付ける

私が参画した案件はモバイルアプリを作成する案件で、案件内でいくつかのチームに分かれていました。
アプリ側のチーム、管理画面を作るチーム、インフラのチームなどなど...

そのチーム間で認識の齟齬が起こってしまうことが何回かありました。
具体的には、

  • 名称が同じだけど指示している対象が違う
  • チーム間で仕様が異なる
  • 片方のチームでしか把握していない要求が存在する

などです。
またチーム間だけでなく、お客さんとの認識にも齟齬が生まれてしまうこともありました。

疑問点を感じたらすぐに聞く(聞ける環境を作る)

当たり前のことかもしれませんが、疑問点を感じたらすぐに聞くことが大事です。
要件定義フェーズでは基本的にネットで調べて解決するようなことがないので、聞くしかありません。
疑問点を放置してしまうと、修正範囲がどんどん広がってしまいとても大変です。

また、疑問点を聞けるするような環境を作ることも大事です。
私の案件では毎日2回30分程チーム内でのミーティング、週4回30分程チーム間でのミーティングがありました。
疑問点や聞きたいことがある場合、これらのミーティングのGoogleカレンダーのメモに議題を追加するというルールになっています。
slackで直接聞くよりも気楽であるため、新参者の自分にとってはとてもありがたかったです。

チーム間で統一する

チーム間で同じ単語だけど、違う対象を指しているということがありました。
これを解決する方法としては、単語の定義をはっきりと明確化させることが大事です。

案件の用語集のようなものを作ることも一つの手だと思います。

また、チーム間で異なるドキュメントに同じものを重複して記載していることもありました。
ドキュメントをまとめて管理するなど対策する必要があります。

議事録を残す

ミーティングでの決定事項やTODOを共有できるように議事録を残す。
以前決まったことを再度話すと時間の無駄となってしまうので、それを防ぐために議事録を作成することが大事です。

社内の議事録は基本的に決定事項やTODOを残すもの、社外(お客さん)との議事録は言ったことの証拠とするもの。
議事録の目的が少し異なるので意識して議事録をとるようにしていました。

目的を意識する

作成するドキュメントや、要件の目的が大事です。
これらは手段の一つであり、目的を達成するために作るものであるため、目的から外れたものを作成してしまうと手戻りが発生してしまいます。

ドキュメントには複数の目的がある場合がある

業務フロー図の作成時、これがお客さんにシステムを理解してもらうために作っているものだと思っていました。
その目的自体は間違っていなかったのですが、それに加えてシナリオテストの設計をする際にインプットとして使うドキュメントでもあるという指摘を頂きました。

全体のドキュメント関連図があればそれを基に、自分が作成しているドキュメントが何に使われるのか意識して作成することが大事だと思います。

「何をやりたいか」ではなく「なぜやりたいか」を意識する

これは様々な場所で言われ続けていることだとは思いますが、whyから要件を詰めることが大事だと思います。
提示される要件によっては、具体的に「これがやりたい!」というものがありますが、よくよくなぜやりたいのか理由を聞くと、他の手段で実現するほうがよいということがありました。
システムは悩みや要望を解決するために作ることを忘れちゃいけないなと思いました。

逆に誰かに説明する時も、なぜやりたいかを最初に説明し、それを実現するためにこういう手段をとりたい、という説明をすると聞き手が受け取りやすくなります。

要件を絞ることも大事

要件定義のフェーズが進むにつれ、どんどん要件が増え収拾がつかなくなってしまいます。
要件定義の終盤で見積もり立てたら、当初の予算に収まりきらないなんてことも...

フェーズの初期段階では要件を増やしていくことは大事だと思いますが、ある程度期間がたってからは減らしていくような作業も必要なのではないかと思います。

運用を意識する

受託開発の場合、運用を行う人物が誰なのか意識することも大切です。
業務を行う頻度や難易度、誰がそれを行うのか考えると、現実問題としてその業務を遂行できないということも考えられます。

そのような業務、要件は思い切って切ってしまう。もし今後必要であるならば追加開発を行うといった考えをすることが大事だと思います。

後続に響く

ウォーターフォールで開発を行っている場合、数か月後、数年後の自分が泣くことになります。画面数を増やしてしまったばかりにテスト項目が増えてしまうなど、ちゃんと後のことも考えて計画をすることが大事です。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?