コラム

コンサルや大手SIerに頼んだ開発が進まないのはなぜか。原因と、開発パートナーを見極める3つのポイント

  • 受託開発会社
  • 受託開発
  • 開発パートナー
発注側の担当者が渡した小さな依頼のメモが、4つの机の担当者へ順に手渡され、時計と書類の山の先から点線で発注側へ戻ってくるイラスト

コンサルや大手SIerに頼んだ開発が進まない原因は、担当者の能力ではなく、組織が大きくなるほど細かく分かれていく分業にあります。

この記事では、筆者が発注側と受注側の両方でコンサルティング会社や大手SIerとの開発に関わってきた経験をもとに、開発が止まる原因と、スタートアップに頼み替える前に確かめたいこと、開発パートナーを見極めるポイントを解説します。

コンサルや大手SIerに頼んだ開発は、どこで止まるのか

止まるのは、技術的に難しい箇所ではなく、担当者と担当者のあいだです。判断が返ってくるまでの往復が多いために、作業そのものは遅くなくても、開発が進みません。

大手SIerでは、営業、システム担当、保守担当、サポート担当のように、役割が細かく分かれています。一人ひとりは自分の範囲をきちんと担当しています。それでも発注側から見ると、相談を持ち込んでから答えが返るまでに、何人もの手を経ることになります。

たとえば、画面の項目を1つ増やしたいと営業担当に伝えたとします。営業担当はシステム担当に確認し、システム担当は影響範囲を調べて保守担当と話します。見積もりが社内の承認を通ってから、ようやく営業担当が発注側に返事をします。返事が来るまでに2週間かかり、しかもその返事は「要件を書面でいただけますか」です。

「画面の項目を1つ増やしたい」という発注側の相談が、営業担当、システム担当、保守担当、社内承認の順に手渡しで進み、2週間後に「要件を書面でいただけますか」という返事になって発注側へ点線で戻ってくる図。止まるのは技術的に難しい箇所ではなく担当者と担当者のあいだで、作業そのものは遅くなくても往復の数だけ時間がかかる

なぜ組織が大きくなるほど進まなくなるのか

原因は2つあり、どちらも担当者が怠けているから起きるものではありません。

1. 人が増えるほど、伝える手間がそれ以上に増える

関わる人が増えると、伝える相手の組み合わせが増えます。そのため、コミュニケーションの手間は人数に比例してではなく、それ以上の速さで増えていきます。 10人のチームと30人のチームでは、全員が同じ理解でいる状態を保つための会議・資料・確認の量がまるで違います。

コンサルティング会社が間に入る場合は、ここに層が1つ増えます。コンサルティング会社が要件をまとめ、大手SIerが設計し、その先の開発会社が作る形になると、同じ質問が3社をまたいで往復します。

2. 自分の範囲の外にあることを、決められる人がいない

役割が分かれるほど、自分の範囲の外にあることを決められる人がいなくなります。「それはシステム担当の範囲なので」「保守の契約に含まれていないので」と、話が戻ってきます。担当者の誰にも落ち度がないまま、決まらない状態が続きます。

この2つは、多くの案件を安定して回すための分業が、1つの案件のスピードと引き換えになることで起きています。そのため、担当者の交代だけでは解消しにくく、頼む先の選び方そのものを見直す必要があります。

では、スタートアップに頼めば解決するのか

必ずしもそうとは言えません。スタートアップは往復が少なく判断が速い一方で、大手SIerとは別の理由で開発が止まることがあります。

  • 大手企業の商慣習を知らない。稟議・情報システム部門の審査・セキュリティチェックシート・検収など、発注側の社内で踏むステップを知らないと、開発は終わっているのに手続きで止まります
  • スピードを優先してセキュリティが後回しになる。アクセス権限の設計やログの保存を「あとで」にしたまま公開し、情報システム部門の審査で差し戻されます
  • 「安く早く」を追いすぎて仕事が雑になる。テストが薄い、ドキュメントがない、作った人しか直せない、という状態で納品されると、保守の段階で費用がかさみます

そのため、大手SIerかスタートアップかで選ぶよりも、大手企業の商慣習を知ったうえでスタートアップのスピードで動ける開発パートナーを探すほうが、上の3つを避けやすくなります。商慣習については、大手企業で働いた経験のある人が開発側にいるかどうかで決まります。一方、セキュリティと仕事の丁寧さは経歴では決まらないため、次の節のポイントと、小さく発注して試す段階で確かめます。

開発パートナーを見極める3つのポイント

商談の段階で、次の3つを確かめます。どれも会社のWebサイトには書かれていないため、実際に話して見分けることになります。

発注側の担当者が、ノートPCでシステムの構成図を説明するエンジニアと向き合い、横に3つのチェックが付いたチェックリストと、すぐに返ってくる返信の吹き出しが並ぶイラスト

1. 営業担当やディレクターが、開発の中身を理解しているか

窓口になる人が、開発や細かい仕様を(完璧でなくとも)自分の言葉で話せるかを見ます。

確かめ方は簡単で、商談の場で仕様に踏み込んだ質問をしてみることです。「既存の基幹システムとどうつなぎますか」「ログインは社内のアカウントを使えますか」と聞いてみます。その場で見通しを答えられる人と、「持ち帰って確認します」としか言えない人に分かれます。窓口が中身を理解していれば、開発中の相談の多くがその場で片づき、往復の回数が減ります。

2. 質問への返事が速いか

商談中のやり取りで、質問を送ってから返事が来るまでの時間を見ておきます。

契約前は、会社が最も丁寧に対応する時期です。この段階で返事に数日かかる会社は、開発が始まるとさらに遅くなると考えたほうが安全です。返事の速さは担当者の性格ではなく、その人が社内で判断できる範囲の広さを映しています。決められる範囲が広いほど、返事は速くなります。

3. 大手企業向けの開発実績と、スピードのある開発の両方を持っているか

実績の一覧ではなく、「大手企業の案件で、どの手続きを踏んだか」を聞きます。

セキュリティチェックシートへの回答、情報システム部門との調整、検収の進め方を具体的に話せる会社なら、発注側の社内で止まる箇所を先回りして動けます。あわせて、「直近の案件で、最初の動くものを何週間で見せましたか」と聞くと、スピードのほうも確かめられます。

大きな開発でも、まず小さく発注して試す

3つのポイントを商談で確かめても、実際の仕事ぶりは発注してみるまでわかりません。そのため、大きな開発を予定している場合でも、いきなり全体を発注しないことをおすすめします。まず小さな範囲で見積もりを取り、実際に発注してみます。

小さな範囲とは、たとえば全体の中の1画面、1つの連携処理、あるいは要件を整理する最初の1か月です。この発注で見るのは、成果物の出来だけではありません。

  • 見積もりの範囲と前提が、質問しなくても読める形で書かれていたか
  • 進め方の相談に、窓口の人がその場で答えたか
  • 約束した日程で、動くものが出てきたか
  • 納品物に、次の人が直せるだけのドキュメントとテストが付いていたか

上の4点がそろっていれば残りの範囲を任せ、欠けていれば、損失が小さいうちに別の会社を探します。

まとめ

  1. 開発が進まない原因を、担当者ではなく組織の分業に求めましょう。
    担当者や同じ規模の会社に替えても、往復の多さは変わりません。
  2. スタートアップに頼み替える前に、商慣習・セキュリティ・仕事の丁寧さを確かめましょう。
    大手SIerとは別の理由で止まることがあります。
  3. 商談で3つのポイントを見ましょう。
    窓口が開発の中身を話せるか、返事が速いか、大手企業向けの手続きとスピードの両方の実績があるかです。
  4. まず小さな範囲で発注して、仕事ぶりを確かめましょう。
    見積もりの書き方・その場の返答・日程・納品物の4点がそろってから、残りを任せます。

弊社には、大手企業出身者とスタートアップ経験者の双方が在籍しており、スピードとクオリティの両方を求める企業様に合う体制があります。まずは小さな範囲からでも、お気軽にご相談ください。

ライター

feeed編集部 / フィード株式会社

フィード株式会社のコラム編集部です。PoC開発・新規事業開発・受託開発の現場で得たことを、発注する側の判断に役立つ形で書いています。

大手企業の商慣習と、スタートアップのスピード。両方を知っている体制で開発しませんか?

弊社には、大手企業出身者とスタートアップ経験者の双方が在籍しています。まずは小さな範囲の見積もりからでも、お気軽にご相談ください。

関連記事