トラブルの火種は?
ちょっとした事から、少しずつその火種は炎上していきます。
システム案件とは、そういった危険性が多く潜んでいます。
下記は、その一例です。
開発会社が夜逃げ〜あれ?電話出ないぞ〜
ここ数日、結構ツメタからなぁ〜。あっ。そう言えば、タスク管理シートが昨日のMTGの後更新されているはず。
あっ。上がってないや。メールも…来てないな…
電話してみよう。
電話する先が間違っているわけではありません。
居ないのです。夜逃げです。
不景気ですし。案件赤字覚悟なんて出来ないですし。ツメラれすぎて自信もないし。
一度でも電話に出てもらったら、安全のために、データを全部引き上げてください。開発者にしてみれば、「引き上げ」を要求されるとこのような状況になっていると心の重みが減ります。もしかしたら、バックアップ部隊を作ってくれるのかも…とね。
そこからぐっとスムーズに行くこともあり得ます。
期待通りに、バックアップに向かいますので、メールでご相談ください。
担当者のスキル不足〜JS(ジェイエス)ってジャバスクリプト?〜
そうです。JSとはJavaScriptです。
主にウェブブラウザなどのクライアントサイドで実装され、動的なウェブサイトの構築に用います。
えっ?クライアントサイド?お客さんですか?作るのはうちです。
…………
あっ、あのぉ…
仕方ありません。受注してしまっていて、コンテンツの制作はほぼ終わっているんですから…
コンテンツを制作出来るWEB制作会社だからといって、システムが分かるわけではありません。
優秀なディレクターさんだからといって、システム要件に詳しいわけではありません。
早めのバトンタッチをされたほうがよろしいでしょう。
ここまでひどくなくっても、「あれっ?通じていないかも!?」と思われた違和感。
その一瞬があるやいなや、即ご連絡ください。
要件定義の甘さ〜仕様があまくってさぁ〜
仕様書ってありますか?
私たちが真っ先にお伺いする事です。
トラブルになっている案件の多くは仕様書がありません。
仕様書とは、誰に対して、何を実現するシステムの、何に関して記述しているのかを明確にするものです。
必要であれば、お客様のどの要望を、どのように解決するのかも記述する。
またシステム固有の専門用語が出てくる場合はその説明も付け加えることも必要です。
つまり、どう作るのか?どう動かすのか?が関係者にわかるようにするものです。
これがあまい、もしくは、無いとどうなるか。。。
記述をする人(プログラマー)が思ったようにつくってしまいます。
そして、プログラマーはどうしていいか分からなくなった時に「聞く」必要が出てきます。
すると、多くの疑問をその都度解決していくというまるで「ロールプレイングゲーム」になってしまいます。
楽しいのです。。。時間があっという間に経ってしまいます。。。時間が足りなくなります。。。
「仕様があまくってさぁ〜」となります。
一刻も早く、仕様書を確定させてください。仕様書の確定が出来ない、難しい。
そんな時はお問い合わせください。
コミュニケーション不足〜申し訳有りません。コミュニケーションが不足しておりまして〜
どうなってるんだ!全然動かないじゃないか!
クライアントは「要求した機能」が「決められた期日までに」納品されていないことに激怒します。
しかし、制作側はそれをコミュニケーションの不足で申し訳有りませんと言います。
中間での仕様のチェック
中間での検収
この項目をすっとばします。開発に自信のない会社であれば有るほど、途中での検収、検閲を嫌がります。
宿題をやってきたのに、提出しない小学生が居るでしょうか?
やっていないから提出しないのです。正しくは、提出できないのです。
途中でコミュニケーションが不足しがちになる制作会社は要注意です。
開発が必要になるほどのシステム要件がある場合、全てが当初の仕様のとおりにいくことは少ないと言っても過言ではありません。より具体的になるにつれて、また事業の動向の変化によって、また実装可能と予想していた部分が難しくなったなど様々な理由から「仕様の変更」はつきまといます。
これをつぶさに拾い、最終的な要件に合わせた仕様を確定し、可能なかぎり迅速に要求に対して品質をあわせていくことが求められています。
デザインのように提出してから「あっ。ここ。もう少し右」ではすまないのです。




