Sponsored
システム開発を外注するとき、発注側はどうしても見積金額に目が行きます。
安いところがいいのか。 実績が多いところがいいのか。 営業担当の感じがいいところがいいのか。 提案書がきれいなところがいいのか。
どれも判断材料にはなります。
ただ、個人的には「安いかどうか」だけで選ぶのはかなり危ないと思っています。
システム開発は、見積金額だけで終わるものではありません。 要件定義、設計、実装、テスト、移行、運用、保守、将来の改修、場合によってはベンダー切り替えまで含めて、後から効いてくる要素がたくさんあります。
最初は安く見えても、後で追加費用が膨らむ。 ドキュメントがなくて改修できない。 セキュリティや性能面で問題が出る。 問い合わせのたびに「それは別費用です」と言われる。
こうなると、最初に安く作った意味がかなり薄れます。
良いベンダーは、発注側にとって都合の良いことだけを言う会社ではありません。
むしろ、良いベンダーほど少し面倒です。
「そこは追加費用です」 「そのスケジュールは危ないです」 「その運用だと後で詰みます」 「その機能は初回リリースから外した方がいいです」
こういうことを言ってきます。
発注側からすると、正直ちょっと面倒です。 でも、システム開発で本当に怖いのは、面倒な話を先送りにしたまま開発が進むことです。
この記事では、個人的な経験則として「こういうITベンダーは大事にした方がいい」と思うポイントを整理します。
開発を初めて外注する企業や、ベンダー選定に慣れていない企業にとっては、かなり参考になる判断軸だと思います。
見積書・提案書で開発範囲が分かる
まず、見積書や提案書がちゃんと整理されているベンダーは、それだけでかなり安心材料になります。
例えば、以下のような内容がある程度整理されているか。
- システム全体のアーキテクチャ
- 採用技術
- 想定機能の概要
- インフラ構成
- インフラ選定理由
- 想定する帳票
- 外部システムとのインターフェース
- 前提条件
- 見積範囲
- 対象外の作業
このあたりが最初から整理されている提案書は、単に資料として見やすいだけではありません。
「何を作るのか」「どこまで含めるのか」「何を前提に見積もっているのか」がある程度見えているということです。
これが大事です。
システム開発で揉める原因のかなり多くは、認識のズレです。
発注側は「当然入っていると思っていた」。 ベンダー側は「そこは見積範囲に入っていないと思っていた」。
こういうやつですね。
最初の提案段階で、機能や前提、対象範囲が整理されていると、この手のズレを減らしやすくなります。
提案書がきれいだから必ず開発力が高い、とは言いません。
ただ、少なくとも要件整理や見積のプロセスが一定以上整っている可能性は高いです。
逆に、金額だけがドンと書いてあって、何を前提にした見積なのか分からない場合は注意した方がいいです。
安く見えても、後で「それは別費用です」が積み上がる可能性があります。
セキュリティを最初から見積もっている
提案書や見積の段階で、セキュリティについて触れているベンダーは大事にした方がいいです。
これはかなり重要です。
昨今、Webシステムや業務システムを作るうえで、セキュリティは「余裕があればやるもの」ではありません。
認証、権限管理、通信の暗号化、ログ管理、脆弱性対応、バックアップ、管理画面の保護、パスワードポリシー、外部サービス連携時の認可まわりなど、考えることは普通にあります。
にもかかわらず、最初の提案では一切触れず、発注側から聞かれて初めて「もちろん考慮します」と言うケースもあります。
それだけで悪いベンダーだとは言い切れません。
ただ、最初からセキュリティの観点が出てくるベンダーは、実装時にもそのあたりを意識してくれる可能性が高いです。
そして、セキュリティをちゃんと考えると、当然ながら工数は増えます。
ここを雑にすると安くはできます。 できますが、後で問題が起きたときのダメージが大きい。
なので、単純な金額比較だけで見ると、セキュリティをちゃんと見積もっているベンダーの方が高く見えることがあります。
でも、それは無駄に高いのではなく、必要な作業をちゃんと見込んでいるだけかもしれません。
安い見積の裏側で、何が省略されているのか。
ここは発注側も見た方がいいです。
非機能要件を聞いてくる
要件定義の段階で、非機能要件の話をしてくれるベンダーはかなり良心的です。
非機能要件というと少し堅いですが、要するに「画面や機能そのものではないけど、システムとして大事なこと」です。
例えば、以下のようなものです。
- どのくらいの人数が同時に使うのか
- どのくらいのデータ量を想定するのか
- どの程度のレスポンス速度が必要か
- バックアップはどうするか
- 障害時にどこまで復旧できればよいか
- 権限管理をどこまで細かくするか
- 操作ログを残す必要があるか
- 将来どのくらい拡張する可能性があるか
中小企業向けの小規模開発だと、このあたりはスキップされがちです。
正直、IPAの非機能要求グレードをそのまま持ち込むと、規模によっては too much になることもあります。
ただ、何も考えなくていいわけではありません。
小さなシステムでも、最低限考えるべきことはあります。
例えば、数人で使う前提のシステムと、将来的に全社員が使うかもしれないシステムでは、設計の考え方が変わります。
一時的なツールなのか、数年間使い続ける基幹寄りのシステムなのかでも変わります。
ここを最初に聞いてくれるベンダーは、単に「言われた機能を作る」だけではなく、運用まで見ている可能性が高いです。
リスクや前提条件を先に出してくる
良いベンダーは、「できます」だけではなく、「この前提ならできます」と言います。
ここ、かなり大事です。
発注側からすると、何でも「できます」と言ってくれるベンダーは頼もしく見えるかもしれません。
でも、システム開発において、何の前提もなく断言できることはそんなに多くありません。
- 既存システムの仕様が分からない
- 外部APIの制約が分からない
- 現行業務の例外パターンが多い
- データ移行元の品質が不明
- 関係者の確認工数が読めない
- リリース時期が固定されている
こういう不確定要素があるなら、本来は見積やスケジュールにもブレが出ます。
そのブレを無視して「大丈夫です」と言い切る方が、むしろ危ないこともあります。
良いベンダーは、リスクをちゃんと出してきます。
「この部分は未確定なので、追加調査が必要です」 「この外部連携は相手側の仕様次第で工数が変わります」 「このスケジュールだと、テスト期間がかなりタイトです」 「データ移行は、現行データの状態によって追加対応が発生します」
こういうことを言ってくれるベンダーは、発注側にとって少し耳が痛いかもしれません。
でも、むしろ誠実です。
リスクを隠して受注して、後から燃えるよりずっといいです。
プロジェクト計画書・テスト計画書・移行計画書が出てくる
プロジェクトが始まった後に、適切なドキュメントを提示してくれるベンダーも大事にした方がいいです。
例えば、キックオフ時にプロジェクト計画書が出てくる。
テスト工程に入る前にテスト計画書が出てくる。
本番移行前に移行計画書が出てくる。
こういうベンダーは、かなりちゃんとしています。
大手企業向けのガチガチのウォーターフォール開発であれば、このあたりのドキュメントが出てくるのは珍しくないかもしれません。
ただ、中小企業向けの小規模開発でも、必要な計画書を出して計画的に進めてくれるベンダーは、安心感があります。
ドキュメントを作れば良いという話ではありません。
形だけの分厚い資料を作って、誰も読まないなら意味がないです。
大事なのは、プロジェクトを進めるうえで必要なことが整理されているかです。
- 体制
- 役割分担
- スケジュール
- 課題管理
- 変更管理
- テスト方針
- 移行方針
- リリース判定
このあたりが見えていると、発注側も判断しやすくなります。
逆に、何となく開発が始まって、何となくテストして、何となくリリースするプロジェクトは怖いです。
小規模ならそれで回ることもあります。
でも、少し規模が大きくなると、一気に破綻します。
発注側にも判断を求めてくる
ここは発注側にも少し厳しい話です。
ベンダーが計画書やテスト方針を出してきたときに、「専門的なことは分からないのでお任せします」で全部流すのは危ないです。
細かい技術的な判断まで発注側ができる必要はありません。
ただ、業務上の判断は発注側にしかできません。
例えば、どの業務パターンを優先してテストするのか。 どのデータを移行対象にするのか。 リリース時にどの業務を止められるのか。 不具合が残っていた場合、どのレベルならリリースできるのか。
このあたりは、ベンダーだけでは決められません。
分からないなりにでも、説明を受けて判断する必要があります。
良いベンダーほど、発注側に判断を求めます。
それは責任逃れではなく、プロジェクトを現実的に進めるために必要だからです。
納品物としてドキュメントを残してくれる
設計書やマニュアルなどのドキュメントが納品されるかどうかも大事です。
「そんなの当たり前では？」と思うかもしれません。
でも、意外とそうでもありません。
小規模開発やスピード重視の案件では、ドキュメントがほとんど残らないこともあります。
画面はある。 ソースコードもある。 でも、設計書はない。 仕様の経緯も残っていない。 運用マニュアルもない。
こういう状態になると、リリース直後は問題なくても、後から困ります。
特に困るのは、次の改修やベンダー切り替えのときです。
ドキュメントがないと、新しいベンダーはまず現状調査から始める必要があります。
画面を触り、ソースを読み、DBを見て、動きを確認しながら仕様を推測する。
当然、その調査工数は見積に乗ります。
つまり、最初の開発時にドキュメントを省略して安く済ませたつもりでも、後でそのツケを払うことがあります。
ドキュメントは、納品された瞬間にはありがたみを感じにくいかもしれません。
でも、保守や改修、引き継ぎのときに効いてきます。
設計書、テーブル定義、API仕様、環境構成、運用手順、管理者向けマニュアル。
このあたりを必要な粒度で残してくれるベンダーは、大事にした方がいいです。
工数と契約範囲を曖昧にしない
システム開発は慈善事業ではありません。
これは冷たい話ではなく、プロジェクトを守るために大事な話です。
すべての作業には工数があります。
画面を1つ追加するにも、仕様確認、設計、実装、テスト、レビュー、リリース作業があります。
ちょっとした文言変更でも、確認、修正、検証、反映があります。
問い合わせ対応や調査も同じです。
「ちょっと見てほしい」でも、実際にはログを見たり、データを確認したり、再現確認したり、原因を切り分けたりします。
そこには普通に時間がかかります。
だからこそ、良いベンダーは工数と契約範囲を明確にします。
- どこまでが見積範囲か
- どこからが追加対応か
- 保守費用に何が含まれるか
- 問い合わせ対応はどの範囲までか
- 調査依頼はどのように扱うか
- 仕様変更時の見積方法はどうするか
このあたりをちゃんと言えるベンダーは、かなり誠実です。
何でも無償で受けてくれるベンダーが良いベンダー、というわけではありません。
むしろ、何でも受けすぎると、どこかで無理が出ます。
担当者が疲弊する。 品質が落ちる。 スケジュールが崩れる。 他の作業にしわ寄せがいく。
Sponsored
その結果、プロジェクト全体が悪くなることがあります。
契約範囲を盾にして何も柔軟に対応しないベンダーも困ります。
ただ、工数の範囲内でできるだけ吸収しつつ、超えるものはちゃんと説明してくれる。
このバランスが取れているベンダーは本当に貴重です。
不具合ゼロではなく、不具合後の対応がまとも
システム開発に不具合はつきものです。
不具合は少ない方がいいです。 テストもレビューもちゃんとやるべきです。
ただ、現実問題として、ある程度の規模のシステムで不具合を完全にゼロにするのはかなり難しいです。
大事なのは、不具合が出たときにどう対応するかです。
- 事象を確認する
- 影響範囲を切り分ける
- 原因を調査する
- 暫定対応を出す
- 恒久対応を検討する
- 再発防止を考える
- 発注側に分かる言葉で説明する
ここまでちゃんと動いてくれるベンダーなら、十分信頼できます。
逆に、「不具合は絶対に出ません」と言い切る方が怖いです。
そんなことは普通言えません。
不具合が出たこと自体だけで判断するのではなく、その後の対応を見る方が現実的です。
認識齟齬が起きたときに落としどころを探れる
システム開発では、認識齟齬も起きます。
これもゼロにはなりません。
要件定義で話した内容が、発注側とベンダー側で微妙に違って解釈されていた。 画面を見て初めて「思っていたのと違う」と気づいた。 業務部門に確認したら、例外パターンが後から出てきた。
普通にあります。
ここで大事なのは、誰が悪いかを延々と詰めることではなく、現実的な着地点を探れるかです。
契約や仕様書は大事です。
ただ、実際のプロジェクトでは、仕様書だけでは割り切れないこともあります。
そのときに、発注側とベンダー側が一緒に落としどころを探れるか。
追加費用が必要なら、その理由を説明する。 スケジュール調整が必要なら、影響を整理する。 代替案があるなら、現実的な案を出す。
こういう進め方ができるベンダーは、かなり信頼できます。
逆に、何かあるたびに責任の押し付け合いになる関係だと、プロジェクトはしんどいです。
100点満点ではなく、現実的なリリースラインを提案してくれる
システム開発で100点を目指すと、いつまで経ってもリリースできないことがあります。
品質を下げていいという話ではありません。
ただ、すべての機能を完璧に作り込み、すべての例外パターンを網羅し、すべての要望を初回リリースに入れようとすると、費用も期間も膨らみます。
そして、完成する頃には業務や前提が変わっていることもあります。
良いベンダーは、現実的なリリースラインを提案してくれます。
- 初回リリースで必要なもの
- 後回しにできるもの
- 手作業で一旦運用できるもの
- 将来の改修で入れればよいもの
- 作り込むと費用対効果が悪いもの
このあたりを整理してくれるベンダーは強いです。
発注側が言ったことを全部そのまま積み上げるだけではなく、「それは初回ではなくてもいいのでは」と言ってくれる。
これはかなり価値があります。
耳障りの良いことだけを言うベンダーより、現実的な優先順位を一緒に考えてくれるベンダーの方が、結果的にプロジェクトを前に進めてくれます。
ITベンダー選定で見ておきたいチェックリスト
最後に、ベンダー選定時に見ておきたいポイントを雑に並べておきます。
- 見積範囲と対象外が書かれているか
- 前提条件が書かれているか
- インフラ構成や技術選定の理由があるか
- セキュリティの観点が入っているか
- 非機能要件について質問してくるか
- データ移行や外部連携のリスクに触れているか
- テスト方針があるか
- 本番移行の進め方が見えているか
- 納品されるドキュメントが明確か
- 保守費用に含まれる範囲が分かるか
- 仕様変更時の扱いが明確か
- 「できます」だけでなく「この前提ならできます」と言っているか
- 発注側に必要な判断を求めてくるか
- 不具合発生時の対応フローが見えているか
全部を満たしていないとダメ、という話ではありません。
ただ、安い見積と高い見積を比較するときに、このあたりを見ると「何が含まれていて、何が省かれているのか」が見えやすくなります。
良いベンダーは、たまに耳が痛いことを言う
ここまで書いてきた内容をまとめると、良いITベンダーは「何でも安く、何でも早く、何でも無料でやってくれる会社」ではありません。
むしろ、良いベンダーほど耳が痛いことを言います。
「その機能は追加費用がかかります」 「そのスケジュールだとテスト期間が足りません」 「その要件だとセキュリティ上の考慮が必要です」 「その運用だと将来かなり苦しくなります」 「その仕様は初回リリースから外した方がいいかもしれません」
こういうことをちゃんと言ってくれるベンダーは、発注側からすると少し面倒に感じるかもしれません。
でも、本当に危ないのは、何でも「できます」「大丈夫です」と言って、後から破綻することです。
開発会社も法人です。
社員がいて、給与があり、開発や保守のための時間があります。 その原資は、当然ながら開発費や保守費です。
そこを無視して、無限に無償対応を求めると、どこかで歪みます。
発注側とベンダー側は、敵同士ではありません。
同じシステムを成功させるための関係者です。
だからこそ、費用、範囲、リスク、優先順位をちゃんと話せる関係が大事です。
おわりに
システム開発のベンダー選定では、どうしても金額に目が行きがちです。
予算は大事です。
中小企業であればなおさら、使える予算には限りがあります。
ただ、見積金額だけで判断すると、後からもっと大きなコストを払うことがあります。
提案書が整理されているか。 セキュリティや非機能の観点があるか。 リスクや前提条件を明記しているか。 プロジェクト中に必要なドキュメントが出てくるか。 納品後の保守や引き継ぎまで見据えているか。 工数と契約範囲を誠実に説明してくれるか。
このあたりを見ていくと、単純な金額比較だけでは見えないものが見えてきます。
良いベンダーは、一見すると少し高く見えることがあります。
でも、それは必要な作業やリスク対応をちゃんと見込んでいるからかもしれません。
安い見積には、安い理由があります。 高い見積にも、高い理由があります。
その中身を見ずに金額だけで決めるのは、やはり危ないです。
発注側にとって本当に大事なのは、安く作ってくれるベンダーではなく、プロジェクト全体の失敗リスクを下げてくれるベンダーだと思います。
そういうベンダーに出会えたなら、かなり大事にした方がいいです。
手放した後で、そのありがたみに気づくことも多いので。
