業務システム開発の受ける相手を見きわめる｜断ってよい依頼

業務システム開発の依頼は、始まってしまうと途中で降りにくい仕事です。要件が固まらないまま進む、担当者に決裁権がない、検収の基準が誰にも言えない。こうした状態の案件を受けてしまうと、時間と体力が消えていきます。業務システム開発でクライアントの選び方を身につけるとは、良い相手を探す技術ではなく、危ない依頼を着手前に見分ける技術のことです。この記事では、初回の打ち合わせで確認する項目、危険な兆候、断ってよい依頼の基準、条件を変えて受け直す方法を、受注後の実務として整理します。

見きわめが必要になる理由

業務システムは「決める人」が見えにくい

業務システム開発は、成果物を使う人と、発注を決める人と、日々やり取りする担当者が別々であることが多い仕事です。この三者の意見が揃っていない状態で着手すると、開発の途中で方向が変わります。

Webサイトの制作なら、見た目の合意は画面を見せれば取れます。業務システムの場合、合意すべきものは業務の流れそのものです。誰がどの順番で何を入力し、どういう条件で次に進むのか。この部分は関係者ごとに認識が違っていることが普通で、着手前に揃えておかないと、後から必ず食い違いが出ます。

発注側も探し方に困っている

見きわめが必要なのは受ける側だけではありません。発注する側も、どこに頼めばよいか分からないまま探しています。開発の実務経験を持つ人が、発注先を探した経験をこう記録しています。

以前自分自身も開発会社を探したことがあり、システム開発会社は非常に多く、Google 検索だけですぐに 100 社を超える企業が見つかりました。HP を詳しく見ても実際の技術力は分かりづらく、全ての企業と面談するのも現実的ではありませんでした。 また、「システム開発会社 おすすめ」「SIer 探し方」などで検索しても、比較サイトや受託開発会社の自社ブログが中心で、内容が偏っている印象を持ちました。

発注側が判断材料を持たないまま声をかけてくる、という状況が普通にあります。この場合、依頼者は自分が何を頼んでいるのかを正確に把握していません。悪意があるわけではなく、単に分からないのです。

だから、受ける側が確認の主導権を取る必要があります。相手が整理していないなら、こちらが整理する。整理してみて、それでも進められない案件は断る。この順番になります。

着手後に降りるコストは高い

途中で降りると、それまでの作業が回収できないだけでなく、評判にも影響します。だから、判断は着手前に済ませます。

着手前の確認にかける時間は、無駄になることもあります。確認した結果、受けないと決めることもあるためです。それでも、危ない案件に数ヶ月を溶かすより安く済みます。

業務システム開発の受注環境で起きていること

内製と外注のあいだが増えた

かつては、業務システムを作るなら開発会社に一括で発注する形が主流でした。現在は、社内に担当者を置きつつ、足りない部分を外部の個人に頼む形が増えています。表計算ソフトや業務アプリを作る道具が扱いやすくなり、簡単な部分は社内で作れるようになったためです。

この変化は、フリーランスにとって仕事の入口が増えることを意味します。同時に、依頼の輪郭が曖昧になりやすいという側面も持ちます。社内で作れる部分と外に出す部分の境界が、依頼者自身にも見えていないことがあるためです。

境界が曖昧な依頼は、着手後に範囲が膨らみます。「ついでにこれも」が積み重なり、当初の想定と別の仕事になります。受ける段階で境界を書き出しておくことが、以前にも増して重要になっています。

既存システムとの接続が前提になった

新しく一つだけシステムを作る案件は減っています。多くは、既存の会計システムや顧客管理の仕組みと繋ぐことが前提です。

接続先の仕様が分からないまま着手すると、開発の後半で行き詰まります。接続先が外部のサービスなら、その仕様は公開されていることが多いですが、社内で古くから使われているものだと資料が残っていないことがあります。

だから、既存システムの資料があるかどうかは、着手判断の重要な材料になります。資料がない案件は、調査の工程を別途置く必要があります。

依頼者の期待が短期化した

道具が発達して短期間で形になる例が増えたことで、依頼者の期待する期間も短くなっています。「簡単なものだから」という前置きで、業務の中核を扱うシステムの依頼が来ることがあります。

簡単に見えるかどうかは、画面の数では決まりません。扱うデータの整合性、異常時の処理、権限の管理。表に見えない部分が仕事量の大半を占めます。この説明ができないまま安請け合いすると、期間の見積もりが崩れます。

初回の打ち合わせで確認する項目

誰が決めるのかを聞く

最初に確認するのは、意思決定の構造です。目の前の担当者が決められるのか、上長の承認が要るのか、複数部署の合意が必要なのか。

決裁の経路が複雑な案件は、進行が遅くなります。遅くなること自体は問題ではありませんが、遅れの原因が発注側にある場合の扱いを決めておかないと、納期の責任だけがこちらに来ます。

聞き方は率直で構いません。「仕様の変更が出たとき、どなたの承認で確定しますか」と聞けば、経路が見えます。ここで答えが曖昧な場合、着手後も曖昧なままです。

現在の業務をどう回しているか聞く

業務システムは、既存の業務を置き換えるものです。だから、今どうやって回しているかを聞かないと作れません。

表計算ソフトで管理している、紙で回している、既存のシステムがあるが一部だけ手作業。実態を聞くと、要件の輪郭が見えてきます。同時に、依頼者が業務を説明できるかどうかも分かります。説明できない依頼者は、要件を出せません。

この確認には時間をかける価値があります。聞き取った内容は、文章ではなく画面のイメージとデータ項目の一覧に落とせるかどうかで判断します。誰がどの画面で何を入力し、それがどこに保存され、入力を誤ったときにどう振る舞うのか。この三点が具体物として書けるなら、要件は固められます。書けないなら、まだ着手できる状態ではありません。

初回の打ち合わせでここまで作る必要はありませんが、こうした形にできそうかどうかは判断できます。依頼者が業務の流れを具体的に語れるなら、進められます。逆に「だいたいこんな感じで」という言い方が繰り返される場合、着手後に認識のずれが噴出します。

検収の基準を聞く

何をもって完成とするかを、着手前に確認します。ここが決まっていない案件は、終わりません。

「使えるようになったら」という答えが返ってきた場合、それは基準ではありません。誰がどの操作を行い、どういう結果が出れば完了なのかを、具体的に決める必要があります。決められないなら、決められる形に落とす作業自体を最初の工程として提案します。

予算の枠と支払いの条件を聞く

金額の水準そのものより、枠がどう決まっているかを聞きます。すでに承認された予算があるのか、これから申請するのか。後者の場合、着手してから予算が下りないという事態が起き得ます。

支払いの条件も確認します。着手金の有無、分割の区切り、支払いのタイミング。業務委託で仕事を受ける場合、取引条件を書面や電子メールなどで明示することや、受領後の一定期間内に報酬を支払うことは、発注する側の義務として整理されています。この枠組みを知っておくと、条件の確認を切り出しやすくなります。

過去に誰かに頼んだことがあるか聞く

同じ案件を以前に別の相手に頼んでいた場合、その経緯を聞きます。途中で終わったなら、なぜ終わったのか。

依頼者側に原因がある場合、同じことが繰り返される可能性が高いです。開発側に原因があったとしても、その説明の仕方で依頼者の姿勢が分かります。前の相手を一方的に非難する説明が返ってきた場合、次はこちらが同じように語られる立場になります。

危険な兆候の見分け方

要件が「あとで決める」のまま進もうとする

最も分かりやすい兆候が、要件の確定を後回しにしようとする姿勢です。「まず作り始めてもらって、細かいところは進めながら」という進め方は、変更が無限に入る構造になります。

反復して作る進め方自体は有効な手法ですが、それは変更の扱いが決まっている場合の話です。変更のたびに範囲と期間を見直す取り決めがないまま反復すると、単に終わらない案件になります。

決裁者が打ち合わせに出てこない

担当者だけと話が進み、決める立場の人が一度も出てこない案件は注意が必要です。担当者が持ち帰った内容が、上で覆ることがあります。

覆ったときに手戻りの費用を誰が負うかが決まっていないと、こちらが負うことになります。着手前に、決裁者と一度は直接話す機会を求めるのが安全です。求めても実現しない場合、その理由を確認します。

予算の話を避ける

金額の話を先送りにしようとする依頼者は、予算が確保できていないか、値切る前提でいるかのどちらかです。

「まず提案をもらってから」という進め方は一般的ですが、枠の目安すら示されない場合は、こちらの工数が無償で使われる可能性があります。提案の前に枠の目安を確認するのは、失礼な行為ではありません。

外部との連携の役割分担が曖昧

デザイン、インフラ、既存システムの改修など、複数の担い手が関わる案件では、役割の境界が曖昧なまま始まることがあります。これは遅延の典型的な原因です。誰がどこまでを担当し、どこまでできていれば納品として受け入れられるのかが決まっていないと、納品物が想定と食い違って手戻りになります。

自分の担当範囲がどこで終わるのかを、着手前に文章にします。境界が書けない案件は、書ける形に整理してもらってから受けます。

発注側と受注側の両方を経験した立場から、選定の観点を整理している解説もあります。

そこで、システム開発会社での勤務経験と PM・エンジニアとしての経験を活かし、なるべくフラットに良いシステム開発会社の探し方や見極め方について記載します。 出典: qiita.com

見きわめの観点は、発注側と受注側で表裏の関係にあります。発注側が良い相手を見分けるために見ている項目は、そのまま受注側が自分の準備状況を点検する材料にもなります。相手を選ぶ立場で確認項目を持つと同時に、選ばれる立場としてその項目に答えられる状態にしておくと、話が早く進みます。

連絡の速度と質が最初から悪い

打ち合わせの日程調整に時間がかかる、質問への返答が来ない、返ってきても答えになっていない。契約前の段階でこの状態なら、着手後はさらに悪化します。

業務システム開発は、依頼者からの情報提供が滞ると進みません。連絡の質は、そのまま進行の質になります。

断ってよい依頼の基準

判断の軸を三つ持つ

すべての兆候を覚えておくのは大変なので、判断の軸を三つに絞ります。

第一に、決める人がいるか。第二に、終わりが定義できるか。第三に、支払いの条件が明確か。この三つのうち二つが欠けている案件は、着手しないほうが安全です。

一つだけ欠けている場合は、その一つを整える作業を提案します。整えられるなら受け、整えられないなら見送ります。

断ってよい典型的な依頼

具体的には、次のような依頼は断ってよいものです。

要件が固まっていないのに納期と金額だけが決まっている案件。作った後の運用を誰が担うかが決まっていない案件。既存システムの資料が一切なく、しかも改修が前提の案件。決裁者が最後まで出てこない案件。前の開発者との経緯を説明したがらない案件。

これらは、受ける側の技術力で解決できる問題ではありません。発注側の準備の問題なので、準備が整うまで着手しないのが正しい判断です。

断り方の実務

断るときは、理由を相手の人格や組織に向けないことが基本です。「現状の情報では、責任を持って進められる状態ではありません」という、条件の話にとどめます。

そのうえで、何が揃えば受けられるかを示します。要件を整理する工程を先に置く、決裁者を含めた打ち合わせを設定する、既存システムの資料を用意する。示された条件を相手が整えてくれば、良い案件に変わることもあります。

断りが関係の終わりになるとは限りません。着手前に問題を指摘してくれた相手として記憶され、後日別の案件で声がかかることがあります。

条件を変えて受け直す

断るか受けるかの二択にしなくてよい場面もあります。範囲を絞る、工程を分割する、調査だけを先に受ける。

特に有効なのが、要件を整理する工程を独立した仕事として受ける形です。この工程を終えた時点で、案件の実態が正確に分かります。分かったうえで、本体の開発を受けるかどうかを改めて判断できます。依頼者にとっても、整理された要件は他の相手に頼むときにも使える成果物になるため、断られたとしても損になりません。

うまく回った案件と、こじれた案件の比較

うまく回った案件に共通するもの

進行が安定した案件には、着手前の段階で共通する特徴があります。

依頼者が現在の業務を具体的に説明できた。決める人が打ち合わせに出てきた。完成の基準が文章になっていた。予算の枠が承認済みだった。既存システムの資料が揃っていた。連絡の返答が速かった。

これらはいずれも、開発が始まる前に確認できるものです。技術的な難易度とは関係がありません。難しい機能を含む案件でも、これらが揃っていれば進みます。

こじれた案件に共通するもの

対して、途中で行き詰まった案件にも共通点があります。

要件の確定を後回しにしたまま着手した。担当者と決裁者の意見が違っていた。完成の基準が「使えるようになったら」のままだった。予算がこれから申請という状態だった。既存システムの資料がなく、動作から推測する必要があった。質問への返答が数日おきだった。

こちらも、技術の問題ではありません。着手前に確認していれば見えていたものばかりです。だから、見きわめは技術の話ではなく手順の話になります。

途中で兆候に気づいたとき

着手後に危険な兆候が出てくることもあります。この場合、放置せずにその時点で扱います。

有効なのは、進行の記録を残し、遅れの原因を明示することです。こちらの作業が遅れているのか、依頼者からの情報提供が滞っているのか。記録があれば、後で責任の所在を話すときに事実で説明できます。

記録がないまま進むと、納期の遅れがすべてこちらの責任として扱われます。業務システム開発は関係者が多いぶん、この構図になりやすい仕事です。

費用の見せ方と見積もりの出し方

工程ごとに分けて出す

見積もりを一つの金額でまとめて出すと、依頼者は中身を判断できません。判断できない相手は、金額の大小だけを見ます。

工程ごとに分けて出すと、何にどれだけかかるかが見えます。要件の整理、設計、実装、試験、導入の支援。分けて出すことで、削れる部分と削れない部分の話ができるようになります。

依頼者が予算を超えていると感じたとき、分かれていれば範囲を減らす相談ができます。まとまった一つの数字だと、値引きの交渉にしかなりません。

見えない作業を書き出す

業務システム開発では、画面に現れない作業が仕事量の大半を占めます。データの整合性を保つ処理、権限の管理、異常時の扱い、動作の確認。

これらを見積もりに書かずに総額だけ出すと、依頼者は画面の数で高いか安いかを判断します。書き出しておけば、金額の理由が伝わります。この書き出しは、着手後に範囲が膨らんだときの根拠にもなります。

変更が入ったときの扱いを先に決める

業務システム開発では、途中で変更が入るのが普通です。問題は変更そのものではなく、変更の扱いが決まっていないことです。

着手前に、変更が発生したときの手順を決めます。変更の内容を書面で受け取り、影響する範囲と期間を見積もり、双方が合意してから着手する。この手順があれば、変更が積み重なっても収拾がつきます。

受ける相手を見きわめるときの費用と手間

確認にかける時間をどう扱うか

着手前の確認には時間がかかります。この時間を無償の営業活動と考えるか、有償の工程と考えるかで、進め方が変わります。

初回の打ち合わせ程度なら無償で構いませんが、業務の調査や要件の整理まで踏み込むなら、有償の工程として提示します。ここを無償で引き受けると、確認が深くなるほど自分が損をする構造になり、結果として確認が甘くなります。

資料を作る手間を減らす

確認の項目は毎回ほぼ同じです。だから、確認シートを一つ作っておきます。決裁の経路、現在の業務、検収の基準、予算の枠、支払いの条件、過去の経緯、外部との役割分担。この七項目を並べた一枚で足ります。

シートがあると、聞き漏らしが減り、打ち合わせの時間も短くなります。相手にとっても、何を準備すればよいかが分かりやすくなります。こうした資料を整った形で作れると、確認の場そのものの印象が変わります。文書の型を確認したい場合はビジネス文書検定の出題範囲が実務の目安になります。

技術面の前提を確認する

業務システムは、既存のネットワークや社内の環境の上で動きます。社内からしか接続できない、特定の端末しか使えない、既存の認証の仕組みに合わせる必要がある。こうした前提は、着手後に判明すると設計に影響します。

ネットワークまわりの前提を聞ける状態にしておくと、確認の精度が上がります。基礎的な範囲を体系的に押さえる目安としてはCCNA（シスコ技術者認定）の出題範囲が参考になります。資格を取る必要はありませんが、扱う語彙を知っておくと、相手の情報システム部門との会話が成立します。

メリットとデメリットを踏まえた選び方

選ぶことのメリット

依頼を選ぶようになると、稼働の予測が立ちます。危ない案件に時間を奪われないぶん、他の仕事に回せる時間が確保できます。

さらに、進行が安定した案件は継続に繋がりやすいです。一度うまく回った依頼者は、次も同じ相手に頼みます。選ぶことは、結果として関係の質を上げます。

選ぶことのデメリット

一方で、選べば当然、受ける件数は減ります。稼働が埋まらない時期が生まれる可能性があります。

だから、選ぶ前提として、依頼が入ってくる経路を複数持っておく必要があります。一つの経路に依存していると、断る判断が経済的に難しくなります。業務システムの分野で仕事を探す入口としてはWeb・業務システム開発のお仕事で扱われている領域の広さが参考になります。隣接する分野としてAI・マーケティング・セキュリティのお仕事のような領域を併せて持っておくと、時期による波を吸収しやすくなります。

判断を鈍らせる要因に注意する

稼働が空いている時期は、判断が甘くなります。危ない兆候が見えていても、「今回は大丈夫かもしれない」と考えてしまいます。

この状態を避けるには、判断の基準を文章にしておくことです。文章になっていれば、気分に左右されにくくなります。前述の三つの軸を書いた紙を、確認シートと一緒に置いておくだけでも効きます。

受けたあとに関係を保つための運用

進捗の共有を定期的に行う

見きわめて受けた案件でも、進行中の運用が悪ければ関係は悪化します。最も効くのは、決まった間隔で進捗を共有することです。

共有の内容は、完了した作業、着手中の作業、依頼者側に依頼している事項の三つです。三つ目が重要です。依頼者からの回答待ちで止まっている部分を明示しておくと、遅れの原因が記録として残ります。

共有の頻度は、案件の長さに応じて決めます。数週間で終わる案件なら週に一度、数ヶ月に及ぶ案件なら区切りごと。頻度そのものより、決めた頻度を守ることが効きます。

想定と違ったときは早く言う

着手後に、聞いていた前提と実態が違うことが判明する場合があります。既存システムの仕様が資料と違う、データの量が想定を超えている、業務の流れに例外が多い。

このとき、抱え込んで自力で吸収しようとするのが最も悪い選択です。吸収しきれなくなった時点で発覚すると、納期の直前に問題が表面化します。判明した時点で伝え、範囲と期間を見直します。

早く伝えることは、能力が足りないという表明ではありません。前提が違っていた事実の共有です。この区別を自分の中で付けておくと、伝えることへの抵抗が減ります。

引き渡しまでを範囲に入れる

業務システムは、作って終わりではありません。使う人が使えるようになるまでが、実務上の完成です。

操作の説明、初期データの投入、運用の手順書。これらを誰が担うかを着手前に決めておかないと、完成後に無償の作業として降りかかります。範囲に入れるなら見積もりに入れ、入れないなら誰が担うかを明示します。

選ぶ側に回れる受け手の条件をどう見るか

在宅・業務委託の市場を長く見てきた立場から言えば、安定して仕事が続いている受け手ほど、依頼を選んでいます。選べるのは技術が高いからというより、断っても困らない状態を作ってあるからです。

運営者として見てきた限りでは、依頼を選べない受け手は、経路が一つに絞られていることが多いです。一つの取引先、一つの紹介元、一つのサービス。そこからの依頼を断ると次がないため、条件が悪くても受けます。経路を複数持つことは、収入の安定だけでなく、判断の自由をもたらします。

もう一つ、発注側と受け手のあいだに立つ相手がいないと、確認の会話が直接できます。仲介を経ると、要件の細部が伝言のあいだで丸くなり、着手後に食い違いが出ます。手数料0%の直接取引が効いてくるのは、金額の面だけでなく、こうした情報の精度の面でもあります。同じ予算で依頼者はより多くを頼め、受け手の手取りも厚くなるうえ、確認の往復が速くなります。

専門性の高さが条件にどう反映されるかを見る材料としてはソフトウェア作成者の年収・単価相場が参考になります。また、働き方全体をどう組むかという観点では定年後のフリーランス独立｜退職金を活かした起業プランと注意点が、収入の柱を複数持つ考え方を扱っています。

業務システム開発で受ける相手を見きわめるために必要なのは、相手を疑う姿勢ではありません。決める人がいるか、終わりが定義できるか、支払いの条件が明確か。この三つを着手前に確認する運用を持つだけで、抱え込む案件の質は変わります。

よくある質問

Q. 業務システム開発の依頼を受ける前に、最低限どこを確認すべきですか？

決める人がいるか、終わりが定義できるか、支払いの条件が明確かの三点です。このうち二つが欠けている案件は着手しないほうが安全です。一つだけ欠けている場合は、その部分を整える作業を提案し、整えられるなら受け、整えられないなら見送るという判断になります。

Q. 要件が固まっていない案件は必ず断るべきですか？

断る以外の選択肢もあります。要件を整理する工程を独立した仕事として先に受ける形が有効です。この工程を終えた時点で案件の実態が正確に分かるため、本体の開発を受けるかどうかを改めて判断できます。依頼者にとっても整理された要件は資産になります。

Q. 決裁者が打ち合わせに出てこない場合はどうすべきですか？

担当者が持ち帰った内容が上で覆り、その手戻りをこちらが負う構図になりやすいため、着手前に決裁者と一度は直接話す機会を求めてください。求めても実現しない場合は理由を確認し、仕様の変更が誰の承認で確定するのかを文章で明確にしてから進めます。

Q. 断ると次の依頼が来なくなりませんか？

着手前に問題を指摘した相手として記憶され、後日別の案件で声がかかることがあります。断る際は相手の人格や組織を否定せず、現状の情報では責任を持って進められないという条件の話にとどめ、何が揃えば受けられるかを示すと関係が残ります。

Q. 確認のための打ち合わせや調査は無償でやるべきですか？

初回の打ち合わせ程度なら無償で構いませんが、業務の調査や要件の整理まで踏み込むなら有償の工程として提示してください。ここを無償で引き受けると、確認を深めるほど自分が損をする構造になり、結果として確認が甘くなって危ない案件を受けてしまいます。