ソフトの開発を委託する時の注意点
ソフトウエアの開発業務を委託する時の注意点
ソフトウエアの開発を他社にソフトウエアの 開発業務の委託 をする時に注意する必要がある項目は色々とありますが、どんな事に注意すれば良いのでしょうか。良い委託先を選ぶ、委託する業務を明確にする、管理の仕方を決めておく、検収条件を決めておく、リリース後の保守をどうするか考えておくなど、色々な注意点があります。ここでは、ソフトウエア開発を委託する時にグータラ親父がどんな点に注意してきたのかを紹介していきます。
ソフトウエア開発と開発業務の委託
ソフトウエアの開発の業務は、企画、設計、実装、テスト、保守と大きく分ける事ができます。 これらの業務の全部や一部を他社に業務委託する事も、ソフトウエア開発の現場では良くあります。業務委託した部分が、当初考えていた機能や品質を満たして納期どおりに納品されれば良いのですが、なかなか思い通りに行かない場合が多いのが世の中の常です。では、業務を委託する時にどんな事に注意すればいいのでしょうか？ここでは、グータラ親父が業務委託の時に注意してきた事について、紹介してきいきます。
請負契約と準委任契約と派遣契約
業務委託をする時には委託先の会社と契約を結びますが、ソフトウエア開発の業務委託で使われるのは、請負契約か準委任契約か派遣契約のどれかになります。ここでは、ソフトウエア開発の現場でよく使われている請負契約による業務委託に限定しては話しをします。業務委託には他にも準委任契約と派遣契約がありますが、これらはまた別の機会に紹介します
請負契約は仕事の完成を目的とした契約で、仕事の進め方や誰が作業をするのか等は請負先に権限があります。また、委託元には請負先の作業員に対する指揮命令権はありません。 要するに、仕事の仕方も含めて全部任すので、出来上がった成果に対しては責任を持ってね、という契約ですね。ですので、委託した業務が例えば設計と実装だとして、ソフトウエアの設計と実装のプロセスについては、委託先のルールに従って作業が進められます。その様な契約では、何に注意すれば良いでしょうか。
信頼できる委託先を選びましょう
まずは良い委託先を選ぶのが最も重要です。ソフトウエア開発は量産品の製造と違って特別な設備や環境（綺麗な水とか）が要るわけではなく、良いエンジニアさえ居れば大丈夫です。逆の見方をすれば、良いエンジニアが居なければ、どんなに立派な事務所に入っていても、そこに業務を委託するとえらい事になります。
と言うのは簡単なのですが、ではどうすれば良い委託先かそうでないかを見分けられるのか、というとこれは実はとっても難しいです。もちろん、ネットに公開されている情報から、会社の規模や得意とする技術分野やこれまでの開発実績等、ある程度の情報を得る事はできます。
しかし、残念ながらソフトウエアの開発は担当するエンジニアの力量に全てが掛かっています。いくらその会社がこれまでに良いソフトウエアを作ってきた実績があったとしても、それらの実績を作ってきたエンジニアではなく、経験も技量も薄いエンジニアが委託した業務を担当したら、同じような素晴らしい成果は望めないでしょう。
ではどうするかというと、、、経験と勘ですね！！ まあ、要するにソフトウエアの開発を委託する先を選ぶ時には、委託する業務を担当してくれる予定のソフトウエアのリーダさんに合わせて貰い、これまでの開発経験や開発管理や技術について、いろいろと話しを聞かせて貰います。で、その解答がしっかりしているようなら、その人がリーダを務める開発チームに開発業務を委託してもたぶん大丈夫でしょう。 もちろん、相手の技術力や開発管理職を短い時間で正しく判断する事はなかなか難しいのですが、直接会って１時間～２時間程度会話をすれば、何となくその人の力量が判ってきます。
もう少し詳しく委託先の選定をしたい場合には、ソフトウエア開発監査という手段もありますので、興味のある方はそちらの分類もご覧ください。
業務範囲と責任分解点
ソフトウエアの開発業務は上流から企画、ソフトウエア設計、ソフトウエア実装、テスト設計、テスト実施、保守と流れていきます。この業務の中でどの部分の業務を委託するのか、を明確にする必要があります。同時に、委託した業務と委託していない業務つまりは自社で行うか他社に委託するか業務との責任分解点を明確にしておく必要があります。言い方を変えると、業務委託の入口と出口を明確にするとも言えます。
例えば企画は自社で行い、ソフトウエア設計からテスト実施までの業務を委託するとします。この場合業務委託の入り口は設計業務で、責任分界点は設計業務へのインプットになる要求仕様書です。この要求仕様書に書かれている内容が、請負契約で業務を受託した相手先の会社が責任を持つ業務の入り口の責任分解点です。
もう一方の出口の責任分界点はテスト結果の報告書です。できあがったソフトウエアが要求仕様書に書かれている内容を満たしている事をテストで確認したその結果が、今回の委託業務の出口側の責任分解点です。
このように、委託する業務の範囲とその入り口と出口の責任分界点を明確にして、業務の委託を進める事が大切です。ここが明確になっていないと、開発業務の一部分がダブったり抜けたりして、最終的なソフトウエアが完成しないような事態も起こり得ます。
要求仕様書をしっかり書きましょう
ソフトウエアの機能の一部や全部の開発業務を委託する場合、多くは設計からテストの実施までを同じ会社に委託する事が多いです。そのような場合に重要になる入り口側の責任分解点となるのが要求仕様書なので、これをしっかりと書く事が大切なのですが、要求仕様書をしっかりと書くのは実はなかなか難しいのです。
ソフトウエアの開発なので、実現すべき機能や性能は割と簡単に思い付きますし要求事項を具体的に書く事も、わりとやり易いです。 こんな機能が必要で、それはこんな操作によって起動されて、これくらいの応答時間で処理が終わって、というような事を漏れなくでいるだけ具体的に書きだしていけば要求仕様書の章が埋まっていきます。
書くのが難しいのが、非機能要件と呼ばれる物です。長く使っていても安定して動作し続けるという安定性、何ま間違った操作や入力を入れてしまってもちゃんとエラーとして処理して動き続ける堅牢性、半年経って新しい機能を付け加える時にスムーズに機能を追加できる拡張性、何か問題が起きた時にその対策をしたり原因調査のための情報を集めたりする保守性、ハードウエアが陳腐化して性能が不足してきた時に新しいハードウエアに簡単に乗り換えられるような移植性、などなどです。
一旦リリースした後も長い期間に渡ってユーザに使ってもらえる良いソフトウエアにするには、機能や性能以外にもソフトウエアに作り込んでおく必要のある非機能要件が、実はいろいろとあるのです。そして、これらの非機能要件を思いつくには、ソフトウエアが完成した後の市場での使われ方を想像できるようにならないと、気づけない事が多いです。 そのような観点で要求仕様書が書かれているか、皆さんも一度注意してみてはどうでしょうか。