プログラム開発の終わりはどこか？

プログラム開発の終わりはどこか？

プログラム開発をする上で開発の終わりはどこだかご存知ですか？この記事ではプログラム開発の終わりについて考えてみました。 前回の記事で書いた通り、フリーランスには決めることが沢山あると書きましたが、プログラム開発の終わりも決める事のひとつです。

会社の場合は？

最初に考えるのは会社でプログラム開発をする場合を考えてみます。 もちろん、会社にもよりますが、会社の場合は、プログラム開発の終わりを会社が決めています。 従って、普通は会社の従業員で給料をもらってプログラム開発をしている場合は、開発の終わりは自分で決める必要がありません。

開発を終わりにする「基準」を作って開発の終わりを判断しているという場合が多くなっています。 決め方にはいろいろありますが、基本的には以下のような項目です。

＊　プログラムのドキュメントが完成している

＊　プログラムが求められている動作をする

＊　プログラムのテスト（検証）が終了している

他にも細かい事が決められているかと思いますが、簡単に言うならば上の３つの項目を満たしているのを確認した上で終了になります。 その後は、別のプロジェクトを始めるという感じで仕事が続いていきます。

会社の場合は、ドキュメントやプログラムの作成、テストを別の人が行う場合も多く、それぞれで更に「終わり」の条件を決めています。基本的に条件を満たせば終わりで、割り当てられた仕事が終わるというイメージです。

フリーランスの場合は？

ではフリーランスの場合はどうでしょうか？

基本的に必要な事は同じなので、同じような基準を作って決めれば良いだけの話です。 例えば、プログラム（アプリ）を作成して販売するようなビジネスモデルを実践する場合は、会社と同じような形で決めると大抵は問題ありません。

では、お客様からの依頼を受けてプログラムを開発する場合はどうでしょうか？ 実は、この場合は少し話が変わってきます。

お客様からの依頼を受けてプログラムを開発する場合は、お客様がどんなプログラムが欲しいかと言うアイディアを持っている場合が殆どです。そうすると、ドキュメントは既にお客様が作っているかもしれません。

しかし、お客様がドキュメントを持っていても、そのドキュメントがどの程度詳しく書かれているかはケースバイケースです。 あるお客様は、アイディアで実際にどのようにプログラムを作るかまでは考慮されていない場合もありますし、殆どどのようにプログラムを作るかまで考えられたドキュメントの場合もあります。

殆どの場合、プログラミングのコーディングは任される場合が多いと思いますが、基本的な動作を確認したら、最終的な試験はお客様自身で行う場合もありますし、詳細の試験を依頼される場合もあります。

そう考えると、案件毎に「終わり」も変わってくる場合が実に多くなります。

つまり、案件毎に「何が終わりか」決める必要があると言う事です。

プログラム納品をしたら終わりか？

かなりの方が作成したプログラムを納品したら終わりと考えていらっしゃると思います。 確かに、依頼されたプログラムを開発して、それを納品すれば終わりのような気がします。

プログラムの納品を持って「終わり」にするには、実は「そのように決める」必要があります。 「そのように決める」というのはどういうことかと言うと、相手にしっかり合意を取ると言うことです。 要するにこの取り決めは「契約の一部」にすると言う事です。

実は、これをきちんと決めないとトラブルの原因になる場合が非常に多いからです。

「終わり」の定義が、プログラムの開発者とプログラムの発注元では違う場合が多いからです。

よくもめる例を挙げると、プログラムに「バグ」は付き物です。 どの程度詳細なテストをするかにもよりますが、テストでは全てのケースをテストしきれない場合がどうしてもあります。 納品した後に、プログラムを本格的に使い始めると、予期しない不具合が出たりします。

例えば、納品後にこの不具合が発生した場合はどうなると思いますか？

開発者は、納品をした時点で終了と思っていても、発注元は問題があるので修正して欲しいと思う事はあるものです。 このようなケースには、「終わり」をきちんと決めておかないとトラブルの原因になります。

決めていないと、どちらの言い分も間違いではないので、決着をつけるのは難しくなります。 多くの場合は、受注側の方が弱い立場の場合が多いのでトラブルになった場合は、開発者側は対応しなければいけない場合の方が多いのではないでしょうか？

しかし、事前に決めて同じ「終わり」の認識がある場合には話は違ってきます。 例えば納品を持って、その開発は「終わり」と決めておけば、トラブル対応の修正は別の仕事として交渉するのが普通です。

大切な「役割」と「責任」

プログラムの開発者も、プログラムの発注者もお互いビジネスで行っている以上は、無限の責任を追うことは難しくなります。 従って、責任範囲を明確にするために、仕事を始める前に、お互いの「役割」と「責任」をきちんと決めて合意して置くことがとても大切です。

プログラムにバグがあると行っても、開発したプログラムに無期限の責任を追っていては殆どの場合はビジネスになりません。 一方で、プログラムの発注元の方も、プログラムを納品したら後は知らないと言われても困ります。発注元がある程度大きな会社で、プログラムがわかる人がいる場合でも、他人が書いたプログラムを理解して修正するのは簡単ではないからです。

そこで、納品後、例えば 1 ヶ月間に発生した不具合は開発者が修正をすると言うような合意にすると双方に都合の良い合意になります。 ただし、1 ヶ月を超えた場合には、別の案件として交渉するようにすれば、フリーランスのような開発者でも、無期限に責任を追う必要はなくなります。

テストの範囲についても、同じような事が言えます。フリーランスの開発者の場合、詳細のテストまでは手が回らないことも沢山あります。従って、最終的なテストは発注元がカバーするケースも沢山あります。この場合は、どのテストを開発者が行うかをハッキリ決めておくと、トラブルを最小限にすることができます。要はテストの「役割」をきちんと分担して決めると言う事です。

このように、プログラミングなどの開発の仕事は、「役割」と「責任」を仕事を始める前にきちんと決めて合意しておくことが大切です。プログラム開発の「終わり」のように、人によって解釈が違うのはよくある事です。

トラブルを減らすためにも、事前に話し合ってきちんと決めることが大切です。

まとめ

プログラム開発の終わりは一見シンプルに見えますが、人や立場が違うと「終わり」の条件は違ってくるのが普通です。 開発の終わりだけではなく、いろいろな細かいところもきちんと確認をしないと、お互い違うことを仮定している場合が実に沢山あります。会社の場合は、間に会社が介入することで、こうした事が問題になるケースは少ないですが、フリーランスとして仕事を受ける場合には、事前に確認して合意しておく事が大事です。

会社などと取引をする場合には、こうした点をきちんと示して提案するだけでも、信頼度が大きく変わってくるものです。

「役割」と「責任」を意識して、取り組む癖をつけると、開発だけではなく、いろいろな場面でトラブルを未然に防いでプロフェッショナルの仕事ができるようになります！