ソフトウェアの開発依頼のマナー

質問

最近法人ではなく個人的に
パールのプログラマにその人
の作ったスクリプトのカスタマイズを
お願いしようとうことを思っています。

しかし、ソフトの開発を頼んだこととなどないので
いったいどのようなことをそのプログラマーに伝えればいいのかわかりません。

どのような製作依頼の仕方がいいのでしょうか？
最低限のマナーは何でしょうか？

回答No.2

Solitivs · ベストアンサー

ご質問からは，恐らく「法人発注者が法人開発者に対して開発を依頼するのではなく，法人発注者が個人開発者に対して依頼する」ケースだと読み取れたのですが，それでよろしいでしょうか。
とりあえず，そうだと仮定して，わたくしの経験から注意すべき事項を思いつくままに挙げていきます。ちなみにわたくし自身は発注する立場に立ったこともありますし，開発する立場に立ったこともあります。

■カスタマイズの結果として，どのようになればいいのかをきちんと提示する（発注者）。
現在の処理結果と希望する処理結果との違いを，画面やデータなどで具体的に示すとよいと思います。往々にして，何が目的なのかが開発者に伝わっていないことがあります。

■カスタマイズの結果，他の処理や処理結果に影響が及ぶかもしれない点を洗い出してもらう（開発者に依頼）。
希望する処理結果を得るためにカスタマイズした結果，一見なんの関係もない部分に影響が出ることがあります。これは開発者のほうが見つけやすいので，「この部分を希望通りに変えると，別の部分の入力フォーマットを変えねばならない」といった点が出てくるかどうかを，開発者に十分検討してもらいます。これについては，カスタマイズ前後の異同を仕様書の形で開発者から提出してもらうことが多いと思います。
この時点で，作業量と費用がある程度出てくると思います。

■既存のシステムが開発された時期と発注時点での処理環境の違いについて，認識を合わせる（双方）。
既存のシステムが初めて開発されてからある程度の時間が経っている場合，問題が生じることがあります。たとえば処理結果の印刷について，初めて開発したときにはNetscape Navigator 4.78で印刷することを想定していたとします。しかしその後，パソコンの機種が変わり，現用のパソコンにはInternet Explorer 6しか入っておらず，希望した印刷結果が得られない，といったことがあり得ます。現在の利用環境について，認識を合わせておく必要があります。

■仕様が確定して，実作業にかかってから納品するまでの期間を決めておく（主に開発者）。
「何月何日までに，ここまでやりましょう」というスケジュールをきちんと立てないと，ズルズル引きずることになりがちです。もちろんスケジュール通り行かないことも多いのですが，「ここが後ろにずれたら，次の段階はこれだけずれ，最終納品日時がこれだけずれる」という計算をするためにも，仮でもいいですから開発の日程計画を話し合って作っておくことをおすすめします。

■仕様確定後の仕様変更についての取り扱いを明確にしておく（主に発注者）。
何回か話し合って，「これでいきましょう」となったあとに，「やっぱりこうしたい」という意見が出てくるのはよくあることです。一般的に，開発者は立場として弱いですから（何しろお金をもらう立場なので），「いったん確定したのに……」と思いながらも，依頼者の言うことを聞かざるを得ません。ところがそういった仕様変更が，システム全体に影響を及ぼし，開発期間の大幅な遅延を招いたりすることが多いのです。
「開発者から提出された仕様書と見積書を，発注者がチェックして認印を押した段階で仕様と開発費用は確定，それ以後の変更は別料金」などときっちり決めておいたほうがよいでしょう。

■検収テストの手順を考え，テスト期間の終了時期と保守期間を明示する（主に発注者）。
開発後には検証を行う必要がありますが，実際にそのシステムがどのように使われるのかは，開発者よりも発注者のほうが当然よく知っています。発注者は，それを踏まえてテストの方法を考えておく必要があります。「このようなテストをクリアしたら検収済みとし，納品完了とする」というラインを発注者が決めておかねばなりません。
納品完了後に瑕疵担保期間を設け，「瑕疵担保期間が終了するまでは初期不良の修正扱いで無償対応だが，それ以降は機能変更扱いで有償対応」といった契約をすることもあります。また，保守契約も考えておくべきでしょう。年間保守料金を決め，実作業がなくとも保守料を支払うか，スポット保守で実作業ごとに保守料を支払うか，などなど。

■操作マニュアルがある場合，改訂する（開発者）。
「カスタマイズ前のシステムからどのように変わったか」という視点，そして「システム全体としてはこのような操作である」という視点，双方のマニュアル作成を開発依頼に含めておくことをおすすめします。

以上あれこれと長々書きましたが，もしかしたら求めておられるアドバイスとは食い違っているかもしれません。何かのご参考になれば幸いです。

回答No.1

w210

こんにちは。
私は仕事でよく外部の人にプログラム開発を依頼していました。そこでの経験をもとに書きます。
まず次の項目を伝えることが必要です。
１．何をどうするのか？（変更点）
２．いつまでに（納期）
３．金額（予算）
４．テストデータ
一方受け取るものは次のような物になります。
１．改定された仕様書または変更仕様書
２．プログラム（スクリプト）そのもの
３．テスト結果
４．請求書と領収書
そのあと、受け取ったものの検査をして検収書を返す。その検収書をもとに支払いをする。これで手続きは終わりです。
今回の質問者さんの疑問は依頼の仕方、マナーなんですよね。とすると、ビジネスライクだけではないようですね。
１．具体的にこのように困っている
２．ここをこうすればこのように助かる
現状のスクリプトを否定することだけはしてはいけません。そうではなくて良い悪いではなく、合わない、ここをこうすることがどうしても必要なんだってことを伝えるべきです。誠意をもって接すれば分かってもらえると思いますが。
プログラム作る人はそれなりにプライド持ってますからそれを否定することなく、新たな課題をぶつけると制作意欲が沸いてくるはずです。変更の内容によっては説明が必要でしょうし、あまり文書にこだわらずに内容をきっちりと伝えることが重要です。もちろんビジネスですから納期や金額はきっちりとしましょう。