システム開発の受発注企業間で起きる問題点 − 「発注企業」編その1

企業間取引、いま風の言葉で表現すると「 BtoB 」ビジネスで一番気になる問題について、その改善方法の一つを紹介したいと思います。

「 BtoB 」ビジネスの問題と言っても、当然、その業種・業界に特有の問題があると思います。

弊社の場合、システム開発を主業務にしております。このため、「 BtoB 」ビジネスの中でも、システム開発案件に関係する問題点と、その解決方法を取り上げたいと思います。

システム開発における「 BtoB 」ビジネスにおいては、発注企業、システム開発を外注に依頼する側と、受注企業、つまりシステムを開発して納品する側とで、それぞれ次のような点を気にすると思います。

【発注側企業】

・システム開発を発注したのは良いが、本当に期待したものが出来るのか ?
・開発は、納期通りに終わるのか ?
・開発途中で、値上げを切り出されないか ?
・開発途中で、案件を投げ出されないか ?
・納品後の保守はどうなるのか ? ・・・・・

【受注企業側】

・納品後に、約束通りに入金してもらえるのか ?
・途中で、機能を変更しろと言われないか ?
・途中で、契約を解除されないか ?
・瑕疵担保期間が過ぎても、障害対応をしろと言われないか ?
・約束通りのシステムを納品したのに、機能不足を理由に費用を値切られないか ? ・・・・

発注側、受注側とも、心配の種は尽きませんが、ビジネスには、ある程度のリスクは付き物です。心配ばかりでは、ビジネスなど行えません。

しかし、心配な物は、心配です。

発注側企業としては、業務を効率化するために、貴重な時間とお金を掛けたのに、納品されたソフトウェアが、期待する物と異なる物だった場合、どうしようもありません。

受注側でも、貴重なリソース(人材)を注ぎ込んだのに、予定通りにお金が振り込まれなければ、ビジネスが成り立ちません。

双方とも、裁判を起こせば問題を解決できるかもしれませんが、どちらに取っても、さらに余計な時間と費用が掛かってしまいます。

特にソフトウェアの場合、成果物が「目に見えない」し、直接「触れない」物ですから、余計に面倒な事になりがちです。

そこで今回は、まずは、システム開発の依頼を検討中の発注側企業様の心配を払拭するために、発注側企業間でよく起きる、次の様な問題と原因、および対策について、2回に分けて紹介したいと思います。

第1回目
・納期期日が過ぎたのに納品されない
・途中で追加料金を請求された
・納品されたシステムに期待した機能がない

第2回目
・納品されたシステムが動かない
・納品されたシステムの処理の仕方が違う
・納品後、障害が起きたのに対応してくれない
・障害対応を依頼したらお金を要求された

上記問題の中には、実際に弊社のお客様から伺った過去の苦い経験も含まれます。このため、皆様の参考にもなる事例もあると思います。

但し、以降の内容を読んで頂くと解ると思いますが、全てシステム開発を行った企業側が悪いとは限りません。システム開発を発注した企業側に問題があるケースもあります。

システム開発を発注する場合は、発注側企業も、ブラック企業として、インターネットのブログ等に掲載されないように、以降の説明を読んで、システム開発を発注する場合の注意点を理解して下さい。

また、受注企業側にも、システム納品後に起こる問題は、当然存在します。受注企業側で起こる問題に関しては、また別の機会にご紹介したいと思います。

今回も宜しくお願いします。

- - - - -

■納期期日が過ぎたのに納品されない

●現象

俗に言う「納期遅延」という問題で、企業間取引、特にIT業界においては、良く耳にする現象です。
この現象に関しては、特に、この場において、あらためて説明する必要は無いと思いますが、契約書に記載された【納品日】が過ぎても、成果物が納品されない現象です。

●原因
「納期遅延」の原因としては、様々な理由が考えられますが、だいたいは、次の様なものとなります。

1	開発工数の見積りが甘かった
2	開発途中で、仕様変更や機能追加が行われた
3	開発担当者の技術力(スキル)が低かった(いわゆる、アサイン・ミス)
4	当初、簡単に提供できると思った機能が、思いのほか難しかった(※見積りミスの一種)
5	最初に設定した納期に無理があった
6	不可抗力による遅延(天変地異、等の影響)

●対策
最初に、上記に挙げた原因を、発注企業と受注企業、どちらの責任があるのかで分類すると、次の様な結果になります。

【発注企業側の責任】
(2)開発途中で、仕様変更や機能追加が行われた
(5)最初に設定した納期に無理があった

【受注企業側の責任】
(1)開発工数の見積りが甘かった
(3)開発担当者の技術力(スキル)が低かった(いわゆる、アサイン・ミス)
(4)当初、簡単に提供できると思った機能が、思いのほか難しかった(※見積りミスの一種)

【どちらにも責任が無い】
(6)不可抗力による遅延(天変地異、等の影響)

上記結果の内、発注側で対策が取れるのは、【発注企業に責任がある】ケースです。

開発工数の見積りは、通常、受注企業が行います。このため、開発経験が無い発注企業にとっては、受注企業から提出された開発工数を信頼するしかありません。

開発経験がある企業の場合には、過去の経験から、おおよその工数を予測できる場合もありますが、過去経験が無い場合には、もう、どうしようもありません。

また、アサイン・ミスに関しては、言わずもがな、です。開発担当者に、誰をアサインするかは、受注企業内部の問題ですから、発注企業には知る由もありません。

但し、開発工数の見積りミスに対しては、ある程度の対策方法があります。

それは、開発項目単位に、開発担当者と必要工数を、下表の様なスケジュール表として、受注企業に提出させる方法です。(※下表は、土日を考慮しない、1人/月：20営業日の作業工数表となります。)

システム開発の作業項目は、基本的に、上表のようになりますが、開発規模や、受注企業によっては、作業項目が異なります。

例えば、受注企業から、3個の機能から構成されるシステムに対して、技術担当者1名で、1人/月(20営業日)の作業工数で開発を行うと言う見積りが提出された場合、上表のようなスケジュール表になります。

まず受注企業が、このようなスケジュール表の提出を拒むようであれば、その企業への発注は取り止めた方が良いと思います。工数見積がいい加減な可能性が高いと思われます。

上表は、一見、理路整然としたスケジュールのように見受けられますが、私の様な、システム開発経験のある人間が見ると、怪しい点が幾つかあります。

基本設計と詳細設計が同じ工数になるのは疑わしい	通常は詳細設計の方が長期間になる
3個の機能に、工数が均等に割り振られるのは疑わしい	通常は機能の難易度により工数は異なる
結合試験が2日間しかないが、大丈夫なのか ?	3機能を漏れなく試験できるのか ?

疑わしい点、不明点は、契約する前に確認した方が良いと思います。

一方、発注企業に問題がある、次の2点ですが、これには、充分に気を付けて欲しいと思います。

【開発途中で、仕様変更や機能追加が行われた】

開発工数の見積は、提供する機能の仕様(スペック)の難易度と数により決定します。また、受注企業側は、発注企業から提示された要件に合致した見積りを行います。

ところが、開発の途中で、新規に機能を追加したり、既に決定済の仕様(スペック)を変更したりすると、当然工数が増えてしまいます。

このため、納期が遅れるのは、当然の事です。

また、開発工数が増加した場合、追加費用を請求される可能性もあります。注意して下さい。

【最初に設定した納期に無理があった】

これも、言わずもがな、です。最初から、スケジュールに無理がある訳ですから、納期が遅れても当然だと思います。

また、スケジュールに無理がある開発を、請け負う受注企業も、無責任と言えば、無責任だと思います。

弊社にも、機能を沢山盛り込んだ要件で、1ヶ月以内に納品とか、酷いケースだと、1週間で納めてくれ、と言う要求が来ることがあります。弊社においては、当然、そのような案件は、納期に責任が持てないため、お断りします。

また、プログラムを作成した経験もないのに、平気で「もう少し工数は短くできるでしょう」と言われる方もいます。

それならば、「自分でプログラムを作ってみたら ?!」と言いたくなります。

【不可抗力による納期遅延】

最後に、【不可抗力による納期遅延】ですが、これは、発注側、受注側とも責任はありません。不可抗力による納期遅延に関しては、認めて頂ければだと思います。

弊社も、開発拠点が岩手県盛岡市にある関係で、東日本大震災の時には、2日間、市内が停電しました。

IT企業で停電が起きてしまうと、設計作業以外は、ほとんど何も行えなくなってしまいます。

弊社の場合、緊急の案件が無かったため、東日本大震災による納期遅延はありませんでしたが、それでも、本社側は、何時、停電が復旧するのか、気に病んでいました。

【不可抗力による納期遅延】の場合、作業が遅れても、仕方が無いと思います。開発スケジュールには、ある程度の余裕を持っておいた方が良いと思います。

ちなみに、受注企業でも、単純に「不可抗力」を理由に、納期を遅延させることはありません。弊社でも、停電した2日間分の作業に関しては、社員が努力して遅れを取り戻してくれました。

- - - - -

■途中で追加料金を請求された

●現象

この現象は、滅多に起きない現象だと思いますが、契約終了後、実際の製造作業に入った後で、受注企業から追加費用を請求され、費用を支払わなければ、開発を中止すると言われるケースです。

「滅多に起きない」と記載しましたが、弊社のお客様においては、過去にシステム開発を依頼した企業から、上述のように言われ(脅され?) 、仕方なく追加費用を支払ったと言ってました。このため、それほど現実味が無いとは思えません。

●原因
「追加料金請求」の原因としては、弊社においては、このような対応をしたことがないため、何故、このような対応を取るのか理解に苦しみますが、おそらく次の様な原因があると推測します。

1	開発のために、新たなハードウェア、もしくはソフトウェアが必要になった
2	開発工数が伸びることが明らかになったために、延長分の費用が必要になった
3	最初からの意図的な計画

上記(1)に関しては、確かに「絶対無い」とは言い切れない原因だとは思います。

受託開発でソフトウェアを開発する場合、通常、見積り段階で、システム実現の可否、および実現方法を調査・検討し、ある程度実現可能と言う判断が下された場合のみ、お見積書を提出します。

そして、ソフトウェア開発を受注した後、基本設計の段階で、実際にシステムへの実装方法を検討しますが、見積り段階で実現できそうだ、と判断した機能でも、詳しく調査した結果、システムに実装するためには、別の方法が必要と解るケースがあります。

また、最悪の場合、機能が実現できないことが解るケースもあります。

このような場合、別のプログラミング方法で実装するか、あるいは別のソフトウェアを使用することで対応することになります。

別のプログラミングで対応できるならば、多少の工数のズレは発生しますが、追加費用無しで機能を実現できるため問題ありません。

しかし、当初の想定とは別のソフトウェアを使う必要がある場合で、かつ別のソフトウェアが有償の場合があります。

こうなると、新規ソフトウェアを購入しなければなりません。このため、追加の費用が発生してしまいます。

また、ハードウェアに関しても同様です。調査した結果、機能実現のために、何らかの新規ハードウェアが必要になる場合もあります。

上述の事は、「見積りミス」と言ってしまえば、それまでのことですが、受注側企業にしてみれば、追加の費用は、発注側に負担して頂きたいのが本音です。

しかし、前述の(2)にある「開発工数が伸びることが明らかになったために、延長分の費用が必要になった」に関しては、これは明らかに受注企業の責任範疇です。受注企業側で、何とか対応するのが筋だと思います。

そして、一番怖いのが、(3)の「最初からの意図的な計画」場合です。

当初から追加費用請求を意図した場合、何の理由も無しに費用だけ請求させる訳ですから、発注企業にとっては、驚き以外の何物でもありません。

追加費用を請求された場合、当然、受注企業側と、何らかの擦り合わせを行うと思われます。前述の(1)に関しては、受注企業側としては、発注企業が希望する機能を実現する訳ですから、発注企業側に全額負担して頂きたいところです。

発注企業側からすれば、「そんな話は聞いてない」訳ですから、費用負担には抵抗があると思います。

後は、双方で話し合いを行い、両社納得する形で解決して頂ければと思います。

しかし、(3)に関しては、受注企業側としては、最初から意図した計画ですし、費用を追加する明確な理由も存在しない訳ですから、恐らく、話し合いをしても解決できないと思います。

対応策については、この後説明します。

●対策
上述の3つの原因の内、それぞれ対策を紹介します。

【開発のために新たなハードウェア/ソフトウェアが必要になった】

この現象に対する対策としては、次の3つが考えられます。

1)追加請求を認める

受注側企業としては、この対応が非常に助かります。但し、受注側企業も、追加請求を認めてもらうためには、次の様な項目を説明することで、それなりの誠意を見せる必要があります。

・何故、新規ソフトウェア/ハードウェアが必要になったのか
・回避手段/代替手段はないのか、回避手段/代替手段を採用した場合のリスク・影響
・新規ソフトウェア/ハードウェアを購入しない場合、どのような影響があるのか等

また、発注側企業も、受注側企業が、上記のような明確な説明をしない場合には、安易な費用支出は認めない方が良いと思います。

なお、発注側企業が費用を負担する場合で、かつ購入するのがソフトウェアの場合、ソフトウェアのライセンスは、発注側企業が保持することになります。

2)費用を折半する

費用を両者で折半する方法です。この方法が、一番良さそうに思えますが、実は問題があります。

問題は、ソフトウェア/ハードウェア購入後の、使用権、再販権等の権利、および開発したソフトウェアの著作権の問題です。

ソフトウェアの場合にはライセンスになりますし、ハードウェアの場合は設置場所や使用者を、誰にするのか、と言う問題です。

ハードウェアの場合、将来に渡りハードウェアを使用するのは、恐らく発注企業になります。このために、費用折半には無理があります。

ソフトウェアの場合、まずは購入するソフトウェアの使用権と再販権が問題となります。

購入したソフトウェアを、引き続き受注企業でも使用する場合、費用は折半でも問題ないと思いますが、今後使う予定が無い場合、費用折半は問題です。

またソフトウェアの中には、再販を認めないソフトウェアも存在します。そうなると、ソフトウェアを使う側が再販権を保持する必要があります。これも受注企業としては、費用折半は問題となります。

さらに、開発したソフトウェア自体の著作権を、どちらが保持するのか、と言う点も問題になります。

購入費用を折半する場合には、細かな取り決めが必要になります。

3)追加請求を断る

発注企業としては、想定外の費用です。故に、追加請求は断りたいのが本音だと思います。

しかし、追加請求を断った場合、受注企業から、今後の開発継続を拒否される可能性もあります。

そこで、重要になるのが契約書です。契約書に関して、次の点を明確にしておく必要があります。

・基本契約を締結する
・基本契約書に記載のない詳細項目に関しては個別契約を締結する(以下、両者を契約書とする)
・契約書に、契約締結後の追加費用請求、あるいは費用変更はできない旨を記載する
・契約書に、費用変更等を行う場合の手順を明記する

最低限、上記の内容を含む、基本契約、あるいは個別契約を締結しておけば、開発途中での費用請求はできなくなりますし、費用請求を断った場合に、開発作業を途中で打ち切られる心配も無くなります。

【開発工数が伸びるために延長分の費用が必要になった】

この件に関しては、余程、合理的な理由が無い限り、または、発注企業が、仕様変更や機能追加と言った、工数が増える要求を行っていない場合は、認める必要はないと思います。

また対策としては、上記「追加請求」の対応と同様、きちんとした契約手続きを踏んだ上で、契約書に、次の様な条項を記載する事で防止することができます。

・契約書に、契約締結後の納期延長、および納期延長に伴う費用変更はできない旨を記載する
・契約書に、納期延長等を行う場合の手順を明記する

【最初からの意図的な計画】

この件を防止する方法は、契約書以外存在しません。前述の様に、受注企業は、最初から追加費用を請求する意図を持って業務を請け負う訳ですから、恐らく話し合いを行っても無駄だと思います。

契約書に、これまでに説明した様な条項を加えることで、受注企業側の悪意ある行為を防止することができます。

受注企業が、契約書の記載内容に対して修正依頼をしてきた場合は、最初から、追加費用請求の意図が感じられます。その様な企業には、システム開発を依頼しない方が賢明です。

これは、受注側が企業でも個人でも対応は同様です。システム開発先が個人だからと言う理由で、契約書を交わさない理由は存在しません。

- - - - -

■納品されたシステムに期待した機能がない

●現象

この現象は、原則論から言えば、本来起きてはいけない現象ですが、ソフトウェア開発の現場においては、よく起こる事象です。(他の業界でも、よくある話だと思います。)

一般的には、「言った/言わない」、もしくは「言った/聞いてない」と言う、「水掛け論」的な事象として現れます。

例えば、発注企業が納品物の検査を行った時に、次の様な現象として現れます。

発注企業：「納品物をチェックしたら印刷ボタンない。印刷ボタンと印刷機能を付けてくれ。」
受注企業：「そのような要求は聞いておりません。」
発注企業：「いや、確かに指示したはずだ。無いと困るから付けてくれ。」
受注企業：「いいえ、そんな要求は聞いておりません。聞いてない事には対応できません。」
発注企業：「言った」
受注企業：「聞いてない

●原因

これは、発注側、受注側の双方に原因があります。どちらが一方的に悪いと言う事はないと思います。

発注企業として、本当に必要で、かつ欲しい機能ならば、その機能を、契約書に明記すべきです。また、契約後に行われる打合せで必要性が認識されたならば、自ら議事録を作成し、議事録を受注企業に提出すべきです。

受注企業としても、自分達が、これから作成するシステムに実装する機能を明確にするためにも、実装する機能を設計書等のドキュメントに記載し、作成したドキュメントを発注企業に提出して、承認を得る努力をすべきです。

この問題は、商習慣、および人間の特性に原因があると思います。

営業系の人間は、普段から仕事が忙しいために、文章を書くのが苦手で、面倒臭がる方が多いように見受けられます。逆に技術系の人間でも、指示された事を、平気で忘れる人間も存在します。(弊社社内にも存在します。)

また、営業以外の職種の方でも、役職が上位の方に成れば成るほど、文章以外、口頭で指示される方が多くなります。このため、相手に何かを依頼する際も、口頭だけで依頼するケースが多いように思われます。

これが、社内だけなら影響範囲も限られますが、社外に対しても口頭で指示・依頼する事が問題です。

指示・依頼を受けた側の人間も、きちんと指示内容や依頼内容を、メモに記録したり、再確認したりすれば問題は起きないと思いますが、忙しさにかまけて、そのままにしておくと、指示・依頼内容を忘れてしまいます。

また、普段は、指示/依頼内容を忘れない人でも、割り込み作業等があれば、忘れてしまう可能があります。つまり、人間は、相手から言われたことを忘れてしまう物だと考えられます。

普段から指示・依頼をドキュメントで行えば、このような現象も防ぐことが可能だと思います。

本現象は、発注企業、および受注企業が、本来自分が行うべき作業を、放棄した結果発生する事象だと思います。

●対策

受注企業としては、システム納品後、つまり開発作業が終了した後で「必要機能不足」と指摘される訳ですから、再度、担当者をアサインして開発作業を再開しなければなりません。余計なコストが掛かってしまう上に、担当者のアサインと調整することになります。

発注企業としては、出来上がったと思ったシステムに、必要機能が無い訳ですから、本番業務を開始できません。受注企業が、再度作り直しを行ってくれても、再び受入試験を行わなければなりません。余計な手間ひまが掛かってしまいます。

また、最悪の場合、受注企業に、追加発注と受け取られてしまい、追加費用が必要になってしまう可能性もあります。

つまり、発注側、受注側の双方とも困ってしまいます。どちらも、「相手がやってくれない」と文句を言うばかりでなく、自ら、本現象が起きない様に、何らかの対応を取るべきだと思います。

弊社の場合、弊社は受注企業側になりますが、本現象を避けるために、次の様な施策を取っております。

1)提案書に、実装する全ての機能を明記し、発注企業の承認を得る
2)見積り時点で、提案書に記載された全機能に対する見積りを行い、可能な限り詳細な作業項目を提示する
3)契約書には、別紙として上記「見積書」、あるいは「提案書」記載内容のみを対応する旨を記載する
4)契約後に、打ち合わせの中で明らかになった仕様・機能については、議事録を作成して発注企業に提出し、記載内容に関して承認を得る
5)契約後に、質疑応答の中で明らかになった仕様・機能については、質問管理表を作成して発注企業に提出し、記載内容に関して承認を得る
6)当初の予定にない機能が必要になった場合、予算と工数の関係を調整しながら、今回の開発に含めるのか、それとも次回の開発に回すのかを検討し、発注企業に提案を行う

発注企業としても、次の様な対応を取るべきだと思います。

1)契約前に、実装機能に漏れが無いように、開発内容を詳しく把握する
2)自分達が指示・依頼した項目が、受注企業に正しく伝わり、かつ正確に認識されたのかをドキュメントで管理する(メールでも可)
3)仕様変更や機能追加に関しては、開発工数が増えることで、開発費用が増加することを覚悟した上で依頼・指示を行う
4)契約後、開発作業が始まった後も、開発内容に漏れが無い事を常に確認し、漏れがある場合には、速やかに受注企業に伝える

発注企業の姿勢として、特に重要なのは、上記3)です。発注企業には、「言えば、何でもやってくれる」と勝手に思い込んでいる企業が沢山いますが、それは間違いです。

ソフトウェア開発は、ビジネスです。

ビジネスの世界で、仕様変更や機能追加を行えば、仕様変更や機能追加に伴い費用も増加するのは当たり前です。

それに、仕様変更や機能追加に対する指示も、「こういう指示をしたから、後は受注企業が対応してくれる。」と言う思い込みも危ない考えです。

また、「言ったから」と言う理由だけで、受注企業が無償で何でも行ってくれるとは限りません。ビジネスの世界においては、発企業も受注企業も、契約締結後は、立場は平等です。

立場が平等であれば、行うべき作業も平等です。

それに、前述の様に、人間は、基本的に、物事を忘れる物です。特に、自分にとって都合の悪い事は忘れがちになります。

「伝えたから安心」でなく、「伝えた事を確認したから安心」と言う姿勢に変え、かつ何らかの手段で、記録を残し、何時でも開示できるようにして下さい。

- - - - -

今回は、以下の問題点について、現象の説明、原因の説明、および解決策の案を紹介しました。

・納期期日が過ぎたのに納品されない
・途中で追加料金を請求された
・納品されたシステムに期待した機能がない

如何でしたか ?

「そんな事、言われなくても解っている」、「そこまでしなければならないの」・・・等、多くのご意見があるとは思います。

しかし、これまで説明してきたことを理解し、かつ実践していれば、問題の発生を、ある程度は防止できると考えています。

次回は、引き続き、次の問題点について説明しようと思っております。

・納品されたシステムが動かない
・納品されたシステムの処理の仕方が違う
・納品後、障害が起きたのに対応してくれない
・障害対応を依頼したらお金を要求された

ご精読、ありがとうございました。次回も宜しくお願いします。

以上

【株式会社 エム・システム】
本      社　 ：〒124-0023 東京都葛飾区東新小岩8-5-5 5F
 　 　 　 　 　 TEL : 03-5671-2360 / FAX : 03-5671-2361
盛岡事業所　 ：〒020-0022 岩手県盛岡市大通3-2-8 3F
 　 　 　 　 　 TEL : 019-656-1530 / FAX : 019-656-1531
E-mail　 　　： info@msystm.co.jp 
URL　　　　　： http://msystm.co.jp/
ブログ       ： http://d.hatena.ne.jp/msystem/ 
Facebook　 　： http://www.facebook.com/msysteminc