Warning: include(/home/users/2/lolipop.jp-a-virtual/web/dhmo/dhmo/wp-content/advanced-cache.php): failed to open stream: No such file or directory in /home/users/2/lolipop.jp-a-virtual/web/dhmo/dhmo/wp-settings.php on line 74

Warning: include(/home/users/2/lolipop.jp-a-virtual/web/dhmo/dhmo/wp-content/advanced-cache.php): failed to open stream: No such file or directory in /home/users/2/lolipop.jp-a-virtual/web/dhmo/dhmo/wp-settings.php on line 74

Warning: include(): Failed opening '/home/users/2/lolipop.jp-a-virtual/web/dhmo/dhmo/wp-content/advanced-cache.php' for inclusion (include_path='.:/usr/local/php/5.4/lib/php') in /home/users/2/lolipop.jp-a-virtual/web/dhmo/dhmo/wp-settings.php on line 74
【Web製作】要件定義書の前にやるべきこと|プロジェクトに爆弾を抱えないためにできること – Androidアプリつくったった

【Web製作】要件定義書の前にやるべきこと|プロジェクトに爆弾を抱えないためにできること

CakePHP手順

要件定義をいきなり行うのはNG?!要件定義の前にやるべき事とは?

要件定義書と要求定義書

Web製作は『ドキュメント』ありきで進んでいきます。

ドキュメントは電車でいえばレールです。
脱線すれば当然『事故』になる意味でもそっくりです。

プロジェクトの脱線

今もWeb製作・システム製作案件の失敗の主な要因は
『仕様決定』のプロセスにあるといわれています。

『仕様書』とは、原則『要件定義書』に基づいてシステムが
どういう稼動環境下でどのような機能を具備するかをまとめ、
『定義』したドキュメントの事です。
 
 
仕様と言えば、この『要件定義書』か『仕様書』のどちらかではないか。
と思われる方も少なくないかと思われますが、
 
では、『クライアント』の要求はどこに書かれているのでしょうか?
 
仕様にあっているか否かではなく
そもそも、こんな要望を出したつもりじゃなかったと
言われたとき何を根拠するのでしょうか?
 
その橋渡しこそ『要求定義書』であり
これは『クライアント』に書いてもらうものです
 
本来、プロジェクトが合意のもとスタートされている限り
クライアントの要求は『要求仕様書』にありますし
受託側としてやるべき仕事は『仕様書』状態となっていれば
要望に関する水掛け論はそもそも起こり得ません。

パートナーの協力

要求定義書は『顧客』に書かせる

パートナー
一方的に任せることが成立するのは士業ぐらいです。
Web製作はあくまでも双方の合意点がゴールとなります。

 
契約はWeb製作というあいまいなものではなく
契約は『プロジェクト』として結びます。
いかに『Web製作』と結びつこうとも『プロジェクト』の
契約書面に含まれていない内容は仕事として行いません。
 
したがって『何が行われて、何が行われないか』
大変重要になるわけです。
 
Web製作・システム製作では、経営環境に影響を与えるものも
多く、大半の場合その後の運用は顧客側で行われます。
 
要求仕様を確認しないで、いきなり要件定義を確認し仕様として
確定すると思い込みで『妥当性』を判断することになります。
 
『妥当性』の宛てが外れることで、
言った言わないの水掛け論へと発展していくわけです。

 
いかにこちらが熱心に耳を傾けて仕様にまとめたところで
まず、相手が確かに書いた要求に基づいていない限り
要求とのズレの危険性は不可避だということです。
 

クライアントに書かせるのは難しいと思うのですが・・

実際のクライアントはWebに関して当然のように知らないという
言う方がほとんどです。
さらに、クライアントに要求はおかしい
プロであるあなた方が提案するべきと
言われることもあります。
 
私の場合、これを簡易的に『プロジェクト定義書』として
クライアントに書いて頂いてます。
 
なぜ書けるか』は項目を見ればわかります。
 
そこには、まず3点の確認を行います。

1 現状の問題点       ・・・解消すべき要求事項
2 達成したい目標      ・・・プロジェクトの着地点
3 システム化に期待することを・・・システムの位置づけ

 
続いて、最も大事な確認事項を記載してもらいます。
 
『このプロジェクトが成功したかどうかは、
何をもって判断されるか。』

 
もうお分かりかと思いますがこの部分の記載に
WebやITに関する知識は一切不要です。

 
乱暴な言い方をすれば、
これを相手に書いてもらった上で達成されていれば
プロジェクトとして成功している事になります。
 
後は、この要求を整理し確かにこの要求で間違いない事を
確認後、要求仕様書として双方もっておきます。
 
後は相手がその解決策に『妥当』と納得してもらえるように
ITの知識をフル動員して小さな仕事単位である要件とし
要件定義、見積もりの提示とスムーズに移ることができるでしょう。
 
それと要求定義書を作るときのポイントは
はじめに話を聞くときに質問のフォーマットを
見せたり、渡したりしないことです。
 
本音を引き出すためにもあくまでも
『関心』をもって聞き最後にまとめる際に
お客様に見える形で確認しつつ記載しましょう。
 
そして、まとめた内容をメールとして送り
必ず確認を取ってから進めましょう。
 
以上です。
 
参考になれ幸いです。

About the Author

dhmo
Author:DHMO(ディベロッパー名) 仕事では自社サービス・メディアの開発を行ってます。 趣味でAndroidアプリ製作を行っています。 カラオケではランキングバトルにはまっております。 Mail: dihydromooxide7@gmail.com 

Be the first to comment on "【Web製作】要件定義書の前にやるべきこと|プロジェクトに爆弾を抱えないためにできること"

Leave a comment

Your email address will not be published.


*