スムーズな納品をあまり経験したことが無い、ユゲタです。
漏れのない要件定義をして、
機能詳細をきちんと設計した上で、
スケジュールを守って納品して、
作業を終える。
という、ごく当たり前に聞こえるけど、そんなキレイな、受託開発をした記憶が全く無いのは、
クライアントが、ほぼ見切り発車的な依頼のために、様々な当初予定していなかったトラブルや、問題点が発生することを
数多く経験してきたので、
そうした受託開発を効率的に行えるために、どうすればいいかを考えてみました。
ちなみに、これまで、どんな無茶なスケジュールにも、遅れたことが無いというのが、当方の強みにはなっています。
基本的にシステムは不具合が無いと思われがち
システムを開発した場合に、開発者は、何かしらの不具合が無いかという心配はつきものですが、納品されたクライアントでは、お願いしたとおりのシステムになっているかという視点でのみ持っており、不具合は想定されていません。
世の中のシステムの多くが、不具合が無くて当たり前の状態なのは、実際に自分がスマホアプリなどを使っているとわかると思います。
少しでも、表示がおかしい箇所があれば、不具合ではないかと、疑われ、不具合があるとなると、非常に粗悪なシステムであるので、使い物にならないというレッテルを貼られることもあります。
どんな簡易な開発依頼でも、ベストエフォートでの納品は考えず、常に完璧にする必要があるということですね。
クライアントからの無茶振り依頼の場合は、不具合があることを納得させる努力も必要なのかもしれませんね。
一般論が通じないクライアントに、求めてはいけない事
スピード納品と、安価な開発を求めて来るクライアントには、納品後の確認と、デバッグ作業をお願いすることは多いのですが、じつはそれを求めてしまうと、クライアント側から、仕様変更が多くなるという事態が発生します。
不具合と、一言で言っても、クライアントから提供されるデータや素材によって発生する場合もあるし、もともとのオーダーがシステム化することで、問題が発生する事による、システム不具合ではなく、仕様の整合性の無さも含まれます。
こうした場合、クライアントは、基本仕様を簡単に「変更したい」と言い始めます。
こうした仕様変更は、ヘタしたら、基本機能であった場合、大幅に作り直さなければいけないという事になる可能性も低くはないので、できればさけたいのですが、どれだけ事前に仕様を確認していても、こうした事態は発生してしまいます。
こうした、仕様変更による工数のかさ増しは、事前に見積書などで、きちんと明記しておかなければいけません。
できるだけ効率的な開発をしたいと考えて、スピード優先で、依頼をしてくるクライアントほど、こうした仕様変更によって振り回される確率が高いというのも、多くの経験をした事で、学ぶことができました。
納品後に仕様変更をしてくるクライアントには、注意しなければいけませんが、事前にそうしたクライアントかどうかを、初見で見分ける方法は、曖昧さを判定するのがいいかもしれませんね。
納品後に受け入れ検証をしてくれないクライアント
基本的に、開発を依頼する側には、開発終了後に納品検証を行う義務が発生します。
もちろん、クライアントがITシステムの納品になれていないという人も数多くいるので、こうした点は、細かな指示をしてあげるケースも多いですが、瑕疵担保責任という事で、完了したあとでも、不具合は修正してもらえると考えて、納品時にまともな検証作業をしないクライアントも数多くいます。
こうした粗悪なクライアントであると分かった時には、時すでに遅し・・・
こうしたクライアントは、デバッグ作業を、利用ユーザーにさせるという事になるので、結果的にサービス品質を落とすことになりますが、それを開発責任にしてくる可能性も高いので、事前の開発依頼の規約や覚書で対応する必要があります。
こうした、法務知識は、開発者としては、必須のスキルと言えます。
そもそも、コーディング開発を依頼してきて、デバッグまでの責務を請け負っていない場合、基本動作確認さえすればいいし、他システムとの結合などは、できるはずもないので、そうした切り分けは開発側でしっかりと付ける必要はありますね。
結局、テストコードは大事
「赤色は赤い」的な事を言いますが、不具合検知を、IT素人に任せてはいけません。
開発者であれば、自分のプログラミングで発生する不具合を見つける機能を、自らプログラミングするという事は、重要です。
そんな悠長な開発はできないと考えがちですが、簡単な、テストコードを書いておくだけで、最終的にラクができるのは、自分自身であるとも考えてみましょう。
こうしたテストコードこそ、ルールもなければ、納品義務もないし、表に出なくてもいいので、自分への保険という意味で、作っておくといいでしょう。
また、テストコードって、自分にとっての非常に大きなスキル資産にもなるので、時間が許される限り作り続けたほうがオススメです。
ツールなどを利用して、一般的なテスト環境を構築するのもいいですが、そんな中でも自分ライブラリを持っているエンジニアは、メチャクチャ強いスキルを持っている事になるので、マリオのスターを取った状態（無敵）です。
テストは、テスターが行うと考えている開発者がいたとしたら、とんでもない勘違い開発員の可能性も高いので、その思考も見直したほうがいいですね。
基本的にも全体的にも、プログラミングのバグは、それを開発した人の責任です。
こんな内容を書いていて、非常に耳が痛い、下駄でした・・・
0 件のコメント:
コメントを投稿