要求定義とはやりたいことを言う場。 現場では「やりたいこと」は積極的に言っていい空気になっていることが多い。
しかし全部はできないので、やることを決める。
それが要件定義。
やることを決めたら今度は、それを実現するための
- 機能要件
- 非機能要件
を決める。 これはエンジニアの仕事(開発経験のある人がやる。一通りやったバックエンド寄りのエンジニアが好ましい)
お金と期間の問題もあるので、最低限のゴールを決めるのが大事。 エンジニアは意見を言い、納得させないと地獄を見る(非エンジニアは大変さを知らないので、目的が達成されるためにリッチなことを要求してくる)
エンジニアは既存のシステムの中でビジネス要望を叶えるので、既存の作りを見ながら開発を行う必要がある。
既存の作りによって工数がかかる事が多い。
また、運用してユーザーはどう受け取る & 新たな問題が発生しないか考慮しないといけない。 変更によって新たな問題が発生したり、想像してないような使い方や質問、トラブルが発生する。
なので最初の段階で
- それを実現すると起きるメリット
- それを実現する上でのデメリット(めっちゃ大事)
を考えなくてはならない。 エンジニア以外は自分達で作らないし責任を負わないので好き放題言ってくる。
なのでデメリットを言ってこないので、エンジニアが察しないと地獄を見る(自分の身を守るために受け身ではいけない)
運用やステークホルダーと良い関係を作り、問題点を早めに炙り出さないといけない
彼らとの情報交換はとっても大事。 しかし彼らに判断を任せてはいけない。 自分自身でもドメインを理解して、 - これはいる - いらない
を知っておかなければならない。 知らないと要らない機能を作るハメになる
その後感謝されなかったり低評価をもらうハメになったりする
