本業の開発で手一杯なとき、社内の管理ツールを外の開発チームに任せる：頼む範囲と、最初に決めること

自社のサービスを作るエンジニアはいる。けれど、そのサービスを運営するための社内の管理ツールまでは、手が回らない。新しい拠点の設定は表計算ソフトで管理し、請求や取引先への支払いの計算は、担当者が手で行っている。事業が小さいうちはそれで回っていたのに、取引が一気に増えると、作業が追いつかなくなり、入力のミスも増えていく。

こうした状況は、自社でサービスを開発している会社が伸びる時期に、よく起きます。エンジニアは、お客様が使うサービスの開発で手一杯です。社内の管理ツールは「いつかちゃんと作りたい」ものの、優先順位で負け続けます。

そこで、社内の管理ツールを、外の開発チームに任せるという選択肢が出てきます。この記事は、そう考え始めた事業の責任者や、開発チームのまとめ役に向けて書いています。次のことを順にまとめます。

• 管理ツールが後回しになりやすい理由
• 株式会社プラゴ様が、管理ツールを外の開発チームに任せた経緯
• 頼む前に決めておく4つのこと（任せる範囲、要件の渡し方、技術、指示の出し方）
• 契約の形（請負と準委任）の違い
• 人を自社で集める場合と、チームごと頼む場合の違い
• 人数の増減の見込み方
• 頼む前のチェックリストと、つまずきやすい所

開発会社の選び方や、受託開発と SES の違いといった一般的な話は、SucSak の「受託開発とSESの違い」などの記事にまとまっています。この記事では、自社に開発チームがある会社が、その横に外のチームを置くときの話に絞ります。

結論：任せるのは「人」ではなく「範囲」。範囲・判断する人・技術を先に決める

先に結論を書きます。社内の管理ツールを外の開発チームに任せるときは、人を何人借りるかより先に、次の3つを決めておくと、立ち上げで迷いにくくなります。

1. 任せる範囲：どの業務の、どの作業を楽にするツールなのか。自社のサービスとの境目はどこか。
2. 判断する人：何を作るか、どの順で作るかを、自社の誰が決めるのか。外のチームへの伝え方をどうするか。
3. 技術：今の自社のサービスと、使う言語やデータベース、置き場所をそろえるのか。

この3つが決まっていないと、外のチームは「頼まれた人数で、言われたことをやる」動き方になりやすくなります。そうなると、自社の側に指示を出す手間が残り、本業の開発の時間はあまり空きません。さらに、自社の担当者が外のチームのメンバーに直接、細かな作業の指示を出し続けると、後で触れるとおり、契約の上でも問題になることがあります。

逆に、範囲と判断する人が決まっていれば、外のチームは自分たちで段取りを組み、自社の側は「何を作るか」と「できたものを確かめる」ことに集中できます。

社内の管理ツールが後回しになりやすい理由

自社でサービスを開発している会社で、社内の管理ツールが後回しになるのには、いくつか理由があります。

• 売上に直接つながって見えにくい：お客様が使う機能は、売上や評判に直結して見えます。社内の作業を楽にするツールは、効果が「作業時間が減る」「ミスが減る」といった形で表れるため、優先順位の議論で負けやすくなります。
• 今のやり方でも、なんとか回っている：表計算ソフトや手作業で回っているうちは、困っているのが担当者だけで、全社の課題として見えにくいものです。
• 作業の量が、ある日一気に増える：大きな取引先が決まる、拠点が一気に増えるといった出来事があると、手作業の量が急に増えます。気づいたときには、作る時間の余裕がなくなっています。
• 本業のエンジニアを動かすと、本業が遅れる：社内ツールのために本業のエンジニアを割けば、お客様向けの開発が止まります。

このうち最後の点が、外の開発チームに任せる理由になります。社内ツールの開発を外に切り出せば、本業のエンジニアはお客様向けの開発を続けられます。

株式会社プラゴ様の場合

株式会社プラゴ様の事例は、ちょうどこの状況に当てはまります。事例のインタビューで話されていることを、順に整理します。

• 事業：電気自動車の充電サービスを展開しています。2018年に設立し、2023年頃から充電ステーションの数を増やしていく時期に入りました。
• 困っていたこと：数百件のステーションを設置していく中で、管理や請求の業務、たとえば設置場所のオーナーへの収益の配分などを、人の手で行っていました。
• きっかけ：2023年8月頃、大型の小売店舗の国内数百か所にステーションを整える話があり、それまでのやり方では追いつかなくなりました。
• 自社の開発の状況：運営のための管理用のシステムは自社で開発していましたが、サービスそのものに人を取られ、運営の改善までは手が回っていませんでした。
• 頼んだこと：管理用のツールを、事実上ゼロから作ること。おおまかな要件はプラゴ様で作り、詳しい要件定義や画面の構成を考えるところから、クリーヴァが入りました。フロントエンドとバックエンドのそれぞれに、クリーヴァがメンバーを付けています。
• 結果：以前は、新しい店舗にステーションを設置するたびに、さまざまな設定や、関連する情報をシートで管理する作業を人の手で行っていました。管理ツールで自動化されたことで、人の手による作業の一部がなくなり、ミスや不具合の件数も減ってきていると話されています。ただし、不具合はほかの要因で起きる場合もある、とも添えられています。

インタビューでは、外の開発チームに頼むときに大事だった点として、次の3つが挙げられています（3つ目は依頼の背景を話す中で、ほかの2つは決め手を話す中で出てきたものです）。

• 人を集めて、チームを組む手間：自社でフリーランスのエンジニアを探すと、多くの候補から選び、チームとして組むところまで自社で行う必要がある。
• 技術が合うか：自社の別のサービスとバックエンドがある程度共通していたため、その技術に合わせてもらえるか。
• 人数を増やしたり減らしたりできるか：中長期で、どのくらいの人数が必要になるか分からなかった。

ここから先は、この3つに「任せる範囲」と「判断する人」を加えて、頼む前に決めることを順に見ていきます。

頼む前に決めること① 任せる範囲

最初に決めるのは、外のチームに任せる範囲です。「管理ツールを作ってほしい」だけでは、範囲が広すぎます。次のように、業務の言葉で書き出してみてください。

とくに大事なのは、最後の「自社のサービスとの境目」です。社内の管理ツールは、多くの場合、自社のサービスが持っているデータ（利用の記録、契約の情報など）を読んだり、書き戻したりします。どのデータを、どの方向で、どのくらいの頻度でやり取りするのか。ここが決まっていないと、外のチームが作業を進めるたびに、本業のエンジニアに確認が飛び、結局、本業の時間が削られます。

業務の流れの書き出し方は、システムを作る前に業務の流れを整理する記事でも詳しくまとめています。

頼む前に決めること② 要件をどこまで自社で書くか

次に決めるのは、要件をどこまで自社で書いてから渡すかです。プラゴ様の場合は、おおまかな要件を自社で作り、詳しい要件定義と画面の構成から、外のチームに任せていました。

渡し方には、大きく分けて次の3つがあります。

本業で手一杯の会社にとって、3つ目は負担が重くなりがちです。一方で、1つ目のように丸ごと任せると、自社の業務に詳しい人が聞き取りに付き合う時間が、それなりに必要になります。どの渡し方でも、自社の業務を知っている人の時間はゼロにはならないと考えておくと、計画が崩れにくくなります。

要件定義で何を決めるのかは、要件定義の進め方の記事に、相談の前に用意しておくものは、開発会社に初めて相談する前の準備の記事にまとめています。

頼む前に決めること③ 技術をそろえるか

3つ目は技術です。社内の管理ツールは、自社のサービスとデータをやり取りすることが多いため、使う言語やデータベース、サーバーの置き場所をそろえるかどうかで、その後の手間が変わります。

• そろえる場合：自社のエンジニアが、後から管理ツールの中身を読んだり直したりしやすくなります。データのやり取りの仕組みも作りやすくなります。その代わり、外のチームがその技術に慣れているかを、頼む前に確かめる必要があります。
• そろえない場合：外のチームが得意な技術で、早く作れることがあります。その代わり、将来、自社で引き取るときや、別の会社に引き継ぐときの手間が増えることがあります。

プラゴ様のインタビューでは、開発会社によっては標準で使う技術が決まっている場合も多い中で、自社のバックエンドに合わせて対応できたことが、決め手の一つとして挙げられていました。

技術とあわせて、次のことも頼む前に決めておきます。

• ソースコードの置き場所：自社のリポジトリ（ソースコードの保管場所）に置いてもらうのか。外のチームの側に置くのか。
• サーバーやクラウドの契約の名義：自社の名義にするのか。
• できたものの権利：契約が終わったあと、自社で直したり、別の会社に頼んだりしてよいか。

あとから開発会社を変えるときに困らないための確かめ方は、開発会社を途中で変えるときの記事で詳しく扱っています。

頼む前に決めること④ 判断する人と、伝え方

4つ目は、自社の側で「何を作るか」「どの順で作るか」を決める人と、その人から外のチームへの伝え方です。ここは、契約の上でも大事な点があります。

厚生労働省は、システム開発を外に頼むときの考え方を「労働者派遣事業と請負により行われる事業との区分に関する基準」（37号告示）に関する疑義応答集（第3集）にまとめています。要点は次のとおりです。

• 請負や準委任の契約でも、発注した側が、受けた側のメンバーに直接、業務の進め方や働く時間などを指示している実態があれば、いわゆる偽装請負になり、労働者派遣法に違反する。
• 一方で、発注した側と受けた側が対等な立場で一緒に開発し、受けた側のメンバーが自分たちで判断して作業を進めているなら、密に連絡を取り合ったり、技術の話し合いや提案をしたりしても、それだけで偽装請負とはされない。
• 作りたい機能の一覧や優先順位を発注した側が決め、その中身を受けた側のメンバーに直接説明することも、それだけで偽装請負とはされない。
• 受けた側のメンバーに、仕事の割り振りや順番、急ぎかどうかを指示する必要があるときは、受けた側の管理責任者などを通して、受けた側が自ら指示する。
• 発注した側が、特定の人を指名して作業させたり、特定の人を外すよう求めたりすると、適正な請負等とは認められない。

この疑義応答集はアジャイル開発を題材にしていますが、同じ考え方は、アジャイル開発以外のシステム開発を請負業務とする場合にも当てはまる、と書かれています（Q8）。

これを、社内ツールを外に頼む場面に置き換えると、次のようになります。

疑義応答集では、こうした事態を避けるために、発注した側と受けた側の役割や権限、チームの中での進め方を、あらかじめはっきりさせて合意しておくことが大事だとしています。頼む前に「自社の側で判断する人は誰か」「外のチームのまとめ役は誰か」「急ぎの依頼は誰から誰に伝えるか」を決めておけば、契約の上でも、日々の進め方の上でも、迷いが減ります。

契約の形：請負と準委任

外の開発チームと結ぶ契約は、多くの場合、請負か準委任のどちらかです。民法では、それぞれ次のように定められています。

• 請負（民法 第632条）：一方が仕事を完成させることを約束し、もう一方がその結果に対して報酬を払うことを約束する契約。
• 準委任（民法 第656条）：法律行為でない事務を任せる契約。委任の決まりが準用されます。仕事の完成ではなく、任せた事務を行うこと自体が対象です。

2020年4月に施行された改正民法では、準委任の中にも、成果に対して報酬を払う形があることが条文で定められました（民法 第648条の2）。成果の引き渡しが必要な場合は、報酬は引き渡しと同時に払う、という決まりです。

社内の管理ツールの開発に当てはめると、次のように考えられます。

IPA が公開している情報システム・モデル取引・契約書（アジャイル開発版）は、作りながら機能を足したり、優先順位を変えたりする開発を外に頼むためのひな形で、準委任契約を前提にしています。このひな形には、契約の前に両方の会社で確かめる「契約前チェックリスト」も付いています。目的やゴールがはっきりしているか、発注する側で判断する人（プロダクトオーナー）を選び、権限を任せられるか、といった項目です。社内ツールの開発でも、そのまま使える観点が多くあります。

契約の種類ごとの違いは、SucSak の受託開発の契約の記事でも詳しく解説しています。

人を自社で集める場合と、チームごと頼む場合

外の力を借りる方法は、開発会社にチームごと頼むだけではありません。フリーランスのエンジニアと個別に契約し、自社でチームを組む方法もあります。どちらがよいかは、自社に何があるかで変わります。

プラゴ様は、社内にもフリーランスのエンジニアがいる会社です。それでも、インタビューでは、人を選んで加わってもらうまでの手間が大きいことを挙げています。たとえば、仲介の会社5社から10人ずつ、合わせて50人ほどの候補を紹介されたとすると、その中から書類で選び、場合によっては面談もして、ようやく1人か2人を選ぶ。さらに、そこからチームを組むのも自社で行う、という流れです。

どちらの方法にも、それぞれの良さがあります。自社でチームを組めば、メンバーを自社の考えで選べます。チームごと頼めば、選ぶ手間とまとめる手間を、相手に任せられます。本業で手一杯の会社にとっては、自社に残る作業がどれだけあるかで比べてみると、判断しやすくなります。

自社で開発するか、外に頼むかの考え方そのものは、SucSak の受託開発と内製の比較の記事にまとまっています。

人数の増減を見込んでおく

社内の管理ツールは、作り始めてから「あれも必要だった」と範囲が広がることがよくあります。反対に、最初の機能ができたあとは、直す量が減り、人数を減らしたくなることもあります。プラゴ様も、中長期でどのくらいの人数が必要になるか分からなかったと話しています。

人数の増減が見込まれるときは、頼む前に次のことを確かめておきます。

• 人数を変えるときの連絡の時期：何か月前に伝えれば、増やしたり減らしたりできるか。
• メンバーが入れ替わるときの引き継ぎ：誰が、どのように引き継ぐのか。引き継ぎの期間の費用はどうなるか。
• 資料の残し方：メンバーが入れ替わっても困らないように、設計の考え方や決めたことを、どこに残すか。
• 区切りの見直しの時期：1か月ごと、3か月ごとなど、範囲と人数を見直す時期を決めておく。

ここで気をつけたいのは、先ほどの疑義応答集との関係です。発注した側が特定の人を指名したり、外したりすると、適正な請負等とは認められません。人数やメンバーの入れ替えは、「何人で、どの範囲を担ってほしいか」を伝え、誰を充てるかは受けた側が決める、という形にしておくのが安全です。疑義応答集では、個人を特定できない形で技術の水準や経験年数を書いた「スキルシート」を求めることは、それだけで偽装請負とはされない、とも書かれています。

なお、IPA のアジャイル開発版の契約前チェックリストには、「開発チームを固定できるか」という項目もあります。人数を柔軟に変えたい気持ちと、チームを固定したほうが進めやすい面の両方があるので、どの時期にどのくらい変える可能性があるかを、頼む前に率直に伝えておくのがよいでしょう。

立ち上げの最初の1か月で、やっておくこと

外のチームが加わってからの最初の1か月で、次のことを済ませておくと、その後が進めやすくなります。

1. 任せる範囲と、最初に作るものの確認：書き出した範囲を外のチームと読み合わせ、最初に作る機能を一つか二つに絞る。
2. 判断する人と、連絡の道筋の確認：自社の判断する人、外のチームのまとめ役、急ぎのときの連絡の流れを決める。
3. 開発の環境とデータの準備：ソースコードの置き場所、試すための環境、自社のサービスのデータの読み方を整える。本物の個人情報を使わずに試せるデータも用意する。
4. 今の作業の現物の共有：表計算ソフトのシート、手順のメモ、よくある間違いの例を見てもらう。
5. 最初の機能を触って確かめる：できた画面を、実際に作業する担当者に触ってもらい、意見を集める。

とくに5つ目は、本業で忙しい会社ほど後回しにしがちです。ただ、社内の管理ツールは、実際に作業する人が使って初めて効果が出るものです。作業する担当者に早めに触ってもらうことで、「思っていたものと違う」を早く見つけられます。

頼む前のチェックリスト

社内の管理ツールを外の開発チームに任せる前に、次の項目を確かめてください。

任せる範囲

• 楽にしたい作業と、今のやり方を書き出した
• 作業する人、回数、困っていることを書き出した
• 自社のサービスとの境目（やり取りするデータと方向）を決めた

要件

• 要件をどこまで自社で書いて渡すかを決めた
• 自社の業務を知っている人が、聞き取りに付き合う時間を確保した

技術と権利

• 自社のサービスと技術をそろえるかを決めた
• ソースコードの置き場所と、サーバーやクラウドの名義を決めた
• 契約が終わったあと、自社で直したり別の会社に頼んだりしてよいかを確かめた

判断と伝え方

• 自社の側で、何を作るか・どの順で作るかを決める人を決めた
• 外のチームのまとめ役と、急ぎの依頼の伝え方を決めた
• 外のチームのメンバーに直接、作業の手順や時間を指示しない進め方を共有した

契約と人数

• 請負か準委任か、準委任なら何に対して払うかを決めた
• 人数を変えるときの連絡の時期と、引き継ぎの方法を確かめた
• 範囲と人数を見直す時期を決めた

つまずきやすい所

最後に、社内の管理ツールを外に任せるときに、つまずきやすい所をまとめます。

自社の判断する人が、本業と兼ねていて時間が取れない 自社の側で「何を作るか」を決める人が、本業の開発の責任者と同じ人だと、外のチームからの確認が後回しになり、作業が止まります。本業とは別に、運営の業務に詳しい人を判断する人に立てるか、週に決まった時間を確保しておくと、止まりにくくなります。

本業のエンジニアへの確認が、毎日のように飛ぶ 自社のサービスとの境目が決まっていないと、外のチームはデータの持ち方を本業のエンジニアに聞くしかありません。データの読み方や、聞いてよい相手と時間を、最初に決めておきます。

「ついでにこれも」で範囲が広がり続ける 管理ツールは、使い始めると要望が次々に出てきます。要望は一度一覧にまとめ、判断する人が優先順位を付けてから、外のチームに伝えるようにします。

外のチームのメンバーに、直接細かく指示してしまう 急いでいるときほど、自社の担当者が外のチームのメンバーに直接、作業を頼みたくなります。先に書いたとおり、これが続くと契約の上でも問題になることがあります。急ぎの依頼も、外のチームのまとめ役を通します。

作業する担当者が、できあがるまで画面を見ていない 管理ツールを実際に使うのは、運営の担当者です。できあがってから初めて見せると、作業の流れに合わない所が多く見つかります。最初の機能ができた時点で、触ってもらいます。

クリーヴァに相談するとき

クリーヴァには、社内の管理ツールの開発を、おおまかな要件だけがある段階からご相談いただけます。詳しい要件の整理と画面の構成を一緒に考えるところから、開発のチームを組んで作るところまで、お話をうかがいながら進め方をご提案します。

ご相談のときは、楽にしたい作業と、今のやり方（表計算ソフトのシートや手順のメモ）が分かるものをお持ちいただけると、話が早く進みます。今の自社のサービスで使っている技術も、分かる範囲で教えてください。

おわりに

社内の管理ツールは、本業のサービスに比べて後回しにされがちですが、事業が伸びる時期ほど、その遅れが運営の負担として表れます。外の開発チームに任せるのは、本業のエンジニアの時間を守るための一つの方法です。

そのときに大事なのは、人数より先に、任せる範囲、判断する人、技術の3つを決めることです。範囲が決まっていれば外のチームは自分たちで段取りを組めますし、判断する人と伝え方が決まっていれば、自社の側の手間も、契約の上の心配も減ります。まずは、楽にしたい作業と今のやり方を、表に書き出すところから始めてみてください。