要件定義というものは、しっかり定義するのにスキルが必要だ。
そして、スキルの前に間違いなく、
・運用開発だったらそのシステムの知識
・システムを新たに作る場合は対するビジネスの業務知識
これらが必須となる。
しかし、要件定義を上げる部署が必ずしもこれらに詳しいというわけではない、という状況にぶつかる。
・社内での受注だったら、営業部署や企画部署が自社プロダクトのシステムに詳しくないままお客様の要望を聞いてきてまとめているケース
・社外からの受注だったら、その発注元の担当者が自社のビジネスの全容を知らずに右往左往しているケース
等々に出くわす。
特に後者の場合は、要件が固まらないまま開発部にパスされることもままある。
自社の営業としてはとりあえず案件を取ってきて社内にパス、売上の数字は管理するが中身はノータッチ・ソフトタッチ、という場合等。
さらには、どの現場も担当者は多重タスクでアップアップということがほとんどだ。
要件定義の詰めまで手が回らない。
要件定義とは、シンプルに言うと「何がしたいか？」ということだ。
何がしたいか？がわからないと、開発としては作れない。
例えば「飲みものを買ってきて」と言われただけでは受けた側としては行動を起こせないだろう。
「炭酸？コーヒー？お茶？」「どのくらいまでに買ってきて欲しいか」「予算はいくらか」「いくつぐらい欲しいか」あたりがあって始めて行動を起こせる。
飲み物を買う例で例えるとわかりやすいが、ことシステムになると、目に見えないものであり状況も混み合っているということもあり、途端に「何がしたいか？」をまとめることができなくなる。
ここに対して、業務知識があるPM/PL/SEリーダーあたりが立ち向かわないといけない。
PM/PL/SEリーダーの誰が立ち向かうかは、誰が一番業務知識を持っていて対抗できる弁を立てられるかというそのときの現場の状況によって変わってくる。
要件定義というのは開発に必ずついて回るものであり、大きな悩みの種になる部分でもある。
開発者だったら要件定義に対して相対できるように心がけておきたい。
長く開発者を続けるほど、要件定義に近い部分に携わるようになるからだ。
間違いなく、避けては通れない部分なのだ。
入会申込
ログイン
