システム開発はなぜうまくいかないのか？（ベンダー編）
システム開発はなぜうまくいかないのか？（ベンダー編）
さて、前回の記事では外注編として主に発注者の方の視点で解説をしましたが、今回は、ベンダー編として受託開発を受けるベンダー側の視点から、彼らにもそれなりの理屈があることや、悪質なお客様からの圧に屈して仕様変更や追加要望を全部聞いた結果赤字プロジェクトになり、休日も深夜も返上してデスマーチをしている可哀想な会社も沢山あります。また、それとは逆のケースでベンダーが悪質な場合に、よく使ってくる手法についても解説したいと思います。
前回の記事はこちら
ベンダーが直面する一般的な課題
システム開発においてベンダーが直面する一般的な課題について詳述します。基本的にはコミュニケーションの問題と見積もりの難しさです。具体的には、要件の不明瞭さ、コミュニケーションの障壁、技術的制約などが含まれます。
最初に、クライアントからの要件が不明確であることが挙げられます。要件が明確でないと、プロジェクトのスコープが曖昧になり、予期せぬ工数増加を招くことがあります。また、プロジェクトの途中で要件が変更されることも少なくありません。しかし、一般的にスケジュールや予算の見直しに応じてくれるクライアントは居ません。特に日本の場合は契約の問題と労働基準法の問題が余計に事態をややこしくしています。
請負契約の限界
みなさんが、もし初めてシステム開発をしようと思いついた際には何から着手しますか？多分多くの人が、比較サイトなどを使ってアイミツを取り、その中の会社から発注先を決めると思います。その際の契約形態は「請負契約」になることが多いです。そしてこの請負契約に問題があります。請負契約は、ある特定の仕事の完成を約束し、その成果に対して報酬を受け取る契約のことです。発注者が指定した仕事を請負者が引き受け、その仕事を完成させた結果に対して報酬が支払われます。この契約では、作業過程ではなく、成果物の提供が重視される点が特徴です。つまり、システム開発が終わって納品するまでお金が貰えません。
これはベンダー側にとってはかなりのリスクです。相手が求めているものがどこまでのクオリティのものなのか、どんなシステムなのかもわからずに見積もりして契約をしないといけず、更に完成までの人件費はすべてベンダーが持つ事になります。なので、必然的にかなりのバッファを積んだ金額と納期を提示してきます。最近では交渉をして、半金を先にもらう、もしくは毎月分割で支払い、納品が済んでから残りの50%を貰うような契約にしている会社も多いとは聞きますが、納期に間に合わないと減額交渉をされたり、追加要望で追加費用が取れないなどの問題が発生します。トラブルに発展するケースだと納品後に、使い勝手が悪いと難癖を付けられ、支払いを拒否されたりし、最後は裁判になるケースが多いです。
それから、契約が請負契約の場合アジャイル開発が出来ません。なぜなら請負契約は納期と金額を決める必要があるからです。アジャイル開発については別の記事で詳しく解説する予定なので、一旦端折りますが、契約が請負契約の場合は基本的にウォーターフォールという開発手法で開発することになります。
ウォーターフォールという開発手法の限界
ウォーターフォールとは、システム開発手法の一つで、プロジェクトを段階的に進めていく方法です。プロセスは上流から下流へ一方向に進み、一つのフェーズが完了して初めて次のフェーズへと進むことが特徴です。滝のように上から下へしか流れることが出来ず、完了したフェーズに手戻りすることが出来ないことから名付けられました。主なフェーズには要件定義、設計、実装、テスト、運用・保守があります。この手法は明確な目標と要件がある場合に適していますが、変更が発生した場合に全て最初から作り直しになるという欠点があります。
要件定義の罠
こんなケースに備えてベンダーでは最初に要件定義書というものを作成します。そこには、今回開発するシステムの要件が詳細に記述されており、具体的に何が出来て、何が出来ない。といった機能要件から、非機能要件など全てを定義します。非機能要件とは、システムやソフトウェアがどのように動作するかに関する要件で、性能、セキュリティ、利便性、信頼性など、システムの「機能」以外の特性を指します。たとえば、処理速度、対応する同時ユーザー数、データの安全性、使いやすいUIなどが含まれます。
これは一見すると正しいアプローチの様に感じられるかもしれませんが、実はこのアプローチは間違っています。そもそも、未来を予知できる人間なんて居ません。そして、今の世の中は、世界は、ものすごいスピードで変化していっています。例えば、5年前にコロナを予測出来ましたか？20年前にiPhoneの登場を予測出来ましたか？もちろん不可能ですよね？iPhoneやコロナは我々の生活様式を一変させました。iPhoneの登場で地球上ほぼ全ての人が手のひらにコンピュータを持っている。そして、誰とでも簡単にコミュニケーションが取れる世界になりました。コロナで、リモートワークが一気に普及しZoomやGooge meetなどでのオンライン会議も当たり前になりました。
その前提を踏まえつつ先程の要件定義の話に戻ると、未来を予知出来る人にしか完璧な要件定義は出来ません。また、実装中にエンジニアが設計の間違いに気がつくことが良くあります。しかし、請負契約のウォーターフォール式開発の場合だと、上司に報告しても、それをやり直して納期が延びたり、入金トラブルに発展するのを防ぐ為、だいたいお客様に報告されずに握りつぶされます。セブンペイの炎上事件などはまさにこれだと思います。
ラボ契約（準委任契約）
一方、日本でも一部のオフショア開発会社などがやっているラボ契約というものがあります。これは、正確には準委任契約と言います。準委任契約は、一方の当事者（委任者）が他方の当事者（受任者）に対してある業務の遂行を依頼し、受任者がこれを引き受ける契約です。この契約では、具体的な成果物の提供ではなく、業務遂行そのものが契約の目的となります。受任者は、委任された業務を自己の責任で行うことが求められますが、その成果に対する責任を負うわけではありません。
つまりベンダー側に納品責任がなく、あくまでもリソースが足りない時に労働力だけ「時間貸し」しているということになります。請負契約に慣れている方が発注企業内にいると、ラボ契約はリスクが高い契約の様に思えるかもしれませんが、請負契約よりもリスクは低いです。特に技術開発やリサーチ、特定分野の専門知識が必要なプロジェクトにおいて、柔軟かつ効率的な作業体制を築くために有効な手法とされています。この契約形態の特徴は、受任者に対して、業務遂行のプロセスや方法について広範な裁量を認めている点にあります。受任者は、契約に基づく業務を自らの専門知識と技術を用いて適切に管理し、遂行することが期待されます。
ラボ契約のもう一つの重要な側面は、受任者が委任者に対して定期的に進捗状況を報告することが求められる点です。これにより、委任者はプロジェクトの進行状況を随時把握し、必要に応じて指示を出したり、方向性を修正したりすることが可能になります。このようなコミュニケーションの流れは、プロジェクトが予定通りに進行し、期待される結果を得るために不可欠です。アジャイル開発という開発手法で外注を利用して開発をしたい場合はラボ契約一択になります。
しかし、ラボ契約には注意が必要な点もあります。特に、受任者が独立して業務を遂行するため、委任者は業務の質や進捗に対する直接的なコントロールが限られることになります。また、受任者が業務遂行の過程で発生した問題や遅延に対して法的な責任を負わないため、委任者はリスク管理に特に注意を払う必要があります。このような状況に対処するために、契約書には業務の範囲、期間、報告の頻度や形式、コミュニケーションの方法など、プロジェクト管理に関する詳細な条項を含めることが推奨されます。
アメリカの様に企業都合で正社員を簡単にレイオフ出来ない悪法 -労働基準法の問題-
日本における正社員の解雇が困難な法的・文化的背景は、多くのビジネス環境において大きな議論の的となっています。アメリカのように企業が比較的容易に正社員をレイオフできるシステムとは異なり、日本の労働基準法は従業員を解雇する際に厳格な基準を設けています。これは、日本の終身雇用の考え方がベースにありますが、既に終身雇用は破綻しており、この法律自体を変更するのが望ましいと考えています。
これから社会人になる方は、一つの会社で勤め上げよう、一生潰れなさそうな大手に就職しようという考え方は危険なので辞めたほうが良いと思います。それよりも、いつクビになってもすぐに次の勤め先が見つかる人材が本当に優秀な人材だと思います。自分の人材としての価値やスキル、経験値を高める事に全力を注いでください。1つの会社の経験しかないのは、今後の社会を生き抜くうえでものすごいハンデになると思います。それよりは、小さくて先は見えないけど、社会に貢献出来そうな事業を行っているベンチャーに行くことをオススメします。
さて、本題に戻りましょう。まず、企業が正社員を解雇することが事実上難しいため、不況や業績不振の際に人件費を削減することができません。これにより、企業は経済的な困難に直面したときに柔軟に対応する能力が制限され、場合によっては企業全体の存続が危ぶまれることもあります。
さらに、正社員を解雇するハードルの高さは、人材の流動性を低下させる一因にもなっています。企業は採用に際して極めて慎重になり、新たな人材を採用することに消極的になる傾向があります。これは特に、革新や新しいアイデアが重要となるスタートアップ企業や技術分野において、人材の流動性が低いことが成長の妨げになっています。日本の自動車産業がなぜここまで技術力が高いかと言うと、戦後GHQにより戦闘機の製造を禁止されたからです。それによって職を失った飛行機製造のエンジニアが皆自動車産業に行ったからだと僕は思っています。
加えて、このような環境は、若手や新規参入者が正社員としての地位を得る機会を限定的にしています。多くの場合、非正規雇用者（派遣とフリーランス）が増加し、彼らはしばしば不安定な雇用条件や劣る福利厚生に直面します。
やることがなくて暇を持て余している無能なおじさんを揶揄して窓際族と良いますが、その無能なおじさんのクビが切れず、現役世代である若い人たちにお金が行き渡らない事には、社会保険料問題と同じような憤りを感じます。
ITゼネコン（Sier）の問題点
ITゼネコンの解説はWikipediaに正しい記載があったので、こちらを転載します。ITゼネコンとは、建設業界のゼネコンと同じように、情報処理産業において官公需を寡占する大手のシステムインテグレーター（SIer）のこと。またはそれらが形成する多重の下請け構造のことである。
ゼネコンとは、元請負者として工事を一式で発注者から直接請負い、工事全体のとりまとめを行う建設業者を指す。現在の日本では、建設業界と同様に、IT業界においても元請け、下請け、孫受けの多重構造が形成されている。
NTT系列や国内大手ITベンダー（日立、NEC、富士通）の三社、外資系ITベンダー（IBM、HP、Oracleなど）系列のSIerが大手の顧客を囲い込み、インフラ構築からコンピュータ機器の設置、納入後の運用メンテナンスに至るまでを一括受注して利益を得ており、実際のプログラミングやテスト作業を中小のSIerに丸投げしている状態となっている。このようなIT業界の構造を揶揄して、「ITゼネコン」という用語が批判的文脈で使用されるケースが近年多くなってきている（なお、下請けのプログラマは「デジタル土方」という言葉で揶揄されている）。また、システムの規模の計算は、人数と日数の掛け算の「人月計算」という単純な方法で金額が決められて発注が行われるため、この点においても建設業界のゼネコンの構造と類似している。
そして何より、官公需の独占がある。経済産業研究所の報告書によると、平成13年度の政府調達において、NTTグループで全体のシェアの4割、ITゼネコン大手4グループ（NTTグループ、日立グループ、NECグループ、富士通グループのいわゆる「旧電電ファミリー企業」）で6割、ITゼネコン大手10グループで8割を受注している。政府調達は巨額であり、市場規模は中央官庁と地方自治体を合わせて約2.2兆円にのぼる。これは日本のIT産業の約2割のシェアを占める。
私は、このITゼネコンと呼ばれる大手Sierが全ての癌だと思っており、ITゼネコンを全てぶっ壊したいと思っています。そもそも彼らは客の方ではなく、政府の顔色を伺いながら仕事をしています。要は官僚の天下り先確保の為に蜜月な関係を築き上げ、公金をチューチュー吸っている寄生虫です。
独自フレームワークに注意
悪質なベンダーが取りがちな手口に、独自フレームワークを使っているベンダーが居ました。これは、どうゆう事かと言うと、わざと手離れを悪くさせるために独自フレームワークを採用しているのですが、お客さんにはこっちのほうがセキュリティが担保出来るとか、早く実装出来るから納期短縮出来ると真っ赤な嘘を言っておりました。もし、クライアントが開発ベンダーの乗り換えを検討した際に、現行システムを他のベンダーに見せてもそこはその独自フレームワークの内容はわからないので、あんまりやりたくない仕事になるんです。なので、だいたいは作り直しを提案されます。フレームワークを利用するのならば、多くの人が使っているLaravelやReact、Vue.jsなどを利用すれば良いのに、わざわざ独自フレームワークを使っていると謳うベンダーが居たら注意してください。
無知に漬け込む
とあるベンダーに居た頃も本当にひどい会社だなと痛感し、こんな会社が世の中にあるのは社会的に損失が大きいとまで感じました。しかし、大手ということで何故か無知な人からは安心感を獲得しているようです。まず、そのベンダーにはエンジニアがおりません。そして開発をすることもありません。コードも書けません。ただ受注したら一部をピンハネして、子会社に丸投げするだけです。その子会社もまた孫会社に丸投げするんですが、、、。そんな姿勢で本当に良いシステムが作れると思いますか？私は、無理だと思います。
また、客が無知なのを良いことに、無茶苦茶な提案をしてくる開発会社がありました。それは私がシステム開発のコンサルティングサービスを営業して新規顧客の開拓をしたく、アイミツサービスに登録していた時の事でした。お客さんは運送会社で、彼らの要望は「東京と埼玉の2拠点でExcelやパワポ、ワードなどをオンラインで同時編集出来るようにしたい」でした。私は話を聞いていて、M365でもクラウドストレージに入れれば既に共同編集は出来るので、クラウドストレージサービスの契約を提案しました。料金は毎月1000円/1ユーザーです。私の仕事はコンサルティングですので、クラウドストレージの使い方をレクチャーするサービスメニューを考え、2拠点への訪問とレクチャーのコストや大変さを鑑み、50万円で提案をしました。すると、他社と比べて安すぎて怖いと言われました。よくよく話を聞いてみると、他社はなんと5000万〜1億の見積もりを出していたそうです。呆れ果てて内容を聞いてみると、なんと使い勝手の良いクラウドストレージをその金額で作りましょう。という提案をしていました。最終的に決めるのはお客様ですが、IT業界には「車輪の再発明をしない」という文化があります。既に世の中にあるのであればそれを再発明する必要はなく、利用させてもらえば良いだけです。
システムを人質に取る
ベンダー側が困った時の最終手段はシステムを人質に取る事です。具体的には、既に運用が始まっているシステムや自社が以前に開発したシステムが対象となります。しかし、この手段は非常にリスキーであるため、最後の手段としてやってくることが多いです。
自社サービスのご案内
私の会社では、自社でのシステム開発や内製化を目指す企業向けに、コンサルティングサービスを提供しています。初めてのご相談は無料で承っておりますので、ぜひ気軽にお問い合わせください。アジャイル開発のプロフェッショナルが、あなたの事業の成長とイノベーションをサポートします。日本には良いところが沢山あります。しかし、既得権益を守るだけの悪法（放送法、旅館業法、道路運送法などなど）がなかなか改正されないなど、課題は山積みです。しかし、このシステム開発に関する課題だけは、発注者であるユーザーの皆さん、事業会社側の人間が正しい知識を身につければ解決出来ます。外注と比べて自社開発は「費用」「納期」「UI」「拡張性」の全てにおいて勝っています。この記事が外注している方や、外注を検討している方に、少しでもお役に立てたら幸いです。
まとめ
システム開発はとにかくコミュニケーションコストが掛かります。同じネイティブな日本人同士が日本語でやり取りをしても認識齟齬が多発します。これを解決するには、7-9人の自律性を持たせた少人数のチームを作り、Face to Faceのコミュニケーションを重視するアジャイル開発しかありません。
私たちアジャイルテクノロジーは、内製化に挑戦する全ての企業様を応援致します。最終的なゴールは、全ての企業様が、持続可能な開発・運用プロセス（DevOps）を実践し、高品質な製品を通じて、企業の競争力を高め、顧客満足を実現することです。この道のりは決して容易ではありませんが、御社の未来を素晴らしいものにするお手伝いが出来ることを楽しみにしております。 最後までお読み頂きありがとうございました。
この記事が気に入ったらサポートをしてみませんか？