要件定義の概念共有 - エンジニアのひとり言

プロジェクトが立ちゆかない、所謂炎上状態になるには、主に以下の領分での失敗が主ではないだろうか

その中でも確率として数値化するのであればこれぐらいか。

基本的に、それ以外の実作業で起こる失敗や異変は、根本的な原因は上記の3つのどれかに当てはまるはずだ。

例えば、プログラマの技量が低く、納期が遅れるということは、プロジェクトマネージャの采配ミスだ。

ビジュアルデザインの作り直しというプチ炎上状態も、要件定義が甘かったことに落ち着く。

要件定義、設計、プロマネは、プロジェクトを円滑に進行するために重大な役割をもっているはず。

ただ、うちの会社のような少人数で経験も少ない世の中の「Web制作」会社、もしくはフリーの方にとって、比較的疎かになっている工程ではないだろうか。

少人数で小規模なプロジェクトを進める場合、逆に経験則で進めた方がコストをかからないし、円滑に終わるパターンもあるかもしれない。

しかし、それはクライアントにとって最適な解ではないと思う。制作側が「なんとなく」で制作した場合、クライアントも「なんとなく」しか評価しないはずだ。

できましたの報告を受け、確認はしてみるが結局、なんとなくで許可してしまう。

小規模のプロジェクトになると、依頼内容自体もふわっとしていることが多い。

明確なゴールを数値で目標立て、クライアントに意識づけるということは、こちらから提案しなければまず伝わらないし、そもそもクライアントは要望しか持っていないのだから、こちらが要件を定義してあげなければわからない。

ここら辺はきっとどんな仕事でも共通であり、依頼側が無知なことは普通のことだ。

だからこそ、経験則でデザイン、コーディング、納品まで進めてしまうと、それはなんの役にも立たないことが多い。もしくは「Webサイトを作る」ということを勝手にこちらで要件定義しているだけ。テンプレで作るのと何も変わらない。

ここら辺の話というのは、やはりある程度経験が必要で、会社全体で共有するのが難しい。

そもそも、要件定義や設計がどんな作業をするのかということが分からないので、自分の領分内を中心に考えてしまう。

設計については経験や知識に対する依存度が高いと考えているので中々難しいが、要件定義であらば、概念を共有できるのではないかと思った。

そんな中で見つけたこの本。

読んでみて、本当にわかりやすかった。僕自身はもちろん勉強してきたつもりだったが、こんな表現で説明できることに驚いた。

次の社内勉強会で、この辺のことをやろう。