LASSIC Media らしくメディア
業務委託エンジニアの稼働日数、週2日で任せやすい仕事と連絡
監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)
この記事の結論
- 週2日の業務委託エンジニアには、社内の返事を待たずに2日で区切りがつく作業を任せます。
- 障害対応のようにすぐ動いてほしい仕事や、毎日の打ち合わせで進める仕事は社内に残します。
- IT関連の仕事では48.6%が取引先から進捗報告を求められており、報告の回数は契約の前に決めておきます。
※ 本記事は2026年9月時点の公式情報(省庁・公的機関、および製品やサービスを提供する事業者が公開している資料)に基づきます。
週2日なら開発に加わってもらえる人が見つかったのに、何を頼めば2日で進むのかが決まらない。頼んでみたら、社内の返事が遅れ、相手は次の作業日まで手を止めていた——。業務委託エンジニアに開発へ加わってもらう現場では、頼んだ日数と、作業が実際に進む日数が合わないことが起こりがちです。業務委託エンジニアの稼働日数が週2日とは、契約した人が1週間のうち2日を、自社から頼んだ作業に充てる働き方のことです。
週2日でも、頼む作業を選び、作業日以外の連絡の仕方を決めておけば、社員だけでは進められない開発の一部を任せられます。ただし万能ではなく、すぐに返事が要る仕事や、毎日の打ち合わせで進める仕事は、週2日の人には任せにくくなります。本記事では、開発の現場を回すマネージャーに向けて、週2日で任せやすい仕事と任せにくい仕事、作業の分け方、作業日以外の連絡と進捗報告の決め方、そして外部に頼むときに確認したい点を整理します。
目次
稼働日数が週2日とは
週2日の稼働は、月に直すと8〜9日ほどです。火曜と水曜のように続けて作業する形もあれば、火曜と金曜のように間を空ける形もあります。どちらの形でも変わらないのは、平日5日のうち3日は、相手が自社の作業をしていないという点です。その3日に社内で決まったことや、相手に聞きたいことは、次の作業日まで持ち越されます。
社員どうしであれば、朝に出た質問に昼には答えられます。週2日の人が火曜に出した質問に社内が水曜に答えても、相手がそれを読むのは次の作業日の金曜です。そのあいだ、その作業は止まったままです。週2日で頼むときに考えたいのは、日数そのものよりも、この「相手がいない3日」に作業が止まらない頼み方です。
何日頼めばよいかという日数の決め方は「業務委託エンジニアの稼働日数、作業量と連絡の頻度から決める」で、副業として働く人の週の稼働時間は「副業エンジニアの稼働時間、依頼の前に決める3つのこと」で扱っています。本記事では、週2日と決まったあとに、何を任せ、どう連絡を取り合うかを見ていきます。
週2日で任せやすい仕事
週2日で任せやすいのは、始める前に必要な情報がそろっていて、作業のあいだに社内の返事を待たずに進められる仕事です。加えて、2日の中で区切りがつき、終わったかどうかをあとから確かめられることも大切です。たとえば、次のような仕事が当てはまります。
- 仕様が決まっている小さな機能の追加(画面の項目を1つ増やす、帳票の出力形式を変えるなど)
- すでに動いている機能のテストコード(動作を自動で確かめるプログラム)の作成
- 設計書やソースコードのレビュー(作ったものを別の人が確かめる作業)
- 処理が遅い画面の原因調査と、改善の案をまとめた報告書の作成
- ライブラリ(共通で使う部品のプログラム)を新しい版に上げるときの影響調査
どれも、作業の結果が文書やソースコードとして残ります。相手がいない3日のあいだに、社内の担当者がその結果を読み、次の作業日までに返事を書いておけます。たとえばソースコードのレビューを頼んだ場合、相手が火曜に指摘を書き、社内の担当者が水曜に直し、金曜にもう一度見てもらう、という進め方ができます。
反対に、同じ機能の追加でも、仕様が決まっていないものは任せにくくなります。作業を始めてから「この項目は必須か」「このときは画面に何を出すか」を社内に聞くことになり、そのたびに返事を待つためです。任せる前に仕様を決めきれないときは、仕様を決める打ち合わせを作業日に入れ、社内の担当者と相手でその場で仕様を決め、決まった部分から作ってもらう形にします。
週2日では任せにくい仕事
任せにくい仕事の一つ目は、障害対応(システムが止まったときの復旧作業)や、利用者からの問い合わせへの対応のように、起きたときにすぐ動いてほしい仕事です。作業日ではない日に障害が起きると、次の作業日まで誰も手をつけられません。こうした仕事は、毎日いる社員の担当にしておき、週2日の人には、障害の原因を後から調べて再発を防ぐ作業のほうを頼みます。
二つ目は、毎日の短い打ち合わせで作業を調整しながら進める仕事です。スクラム(開発を短い期間ごとに繰り返す方法)では、1か月以内の決まった長さの開発の期間をスプリントと呼びます。公式ガイドは、その期間の作業を開発者が毎日確かめ合うデイリースクラムを「15分のイベント」とし、「スプリント期間中は毎日、同じ時間・場所で開催する」と定めています。*2 作業日にだけ参加する週2日の人は、5回のうち3回に出られません。毎日の打ち合わせで作業の順番を決めているチームでは、週2日の人に任せる作業を、その打ち合わせで順番が入れ替わらないものにしておくと混乱が減ります。
三つ目は、ほかのメンバーの作業と細かくつながっていて、相手の作業が終わるのを待つことが多い仕事です。たとえば、画面を作る人とデータを扱う処理を作る人が、1日に何度も作りかけのものを見せ合いながら進める作業がこれに当たります。週2日の人がその片方を受け持つと、待つ時間が作業の時間より長くなります。
新しい版を本番環境(利用者が実際に使うシステム)に入れる作業のように、日時が決まっている作業は、その日が作業日に当たるなら頼めます。作業日と合わないときは、社員が立ち会い、週2日の人には手順書の作成と確認を頼むとよいでしょう。
作業の分け方
任せやすい仕事を選んだら、次は作業の大きさをそろえます。スクラムの公式ガイドは、計画を立てる段階で、作業を「1日以内の小さな作業アイテムに分解する」、つまり1日以内で終わる単位に分けることが多いと説明しています。*2 週2日で頼むときも、作業日1日で終わる大きさに分けておくと、作業日の終わりにどこまで進んだかを確かめやすくなります。
社内の勤怠システムに、休暇の申請が承認されたら申請者にメールで知らせる機能を追加する場合を例にします。火曜と金曜のように間を空けた2日で頼み、2週間、4回の作業日に分けると、次のようになります。
| 作業日 | 作業 | 作業日の終わりに残すもの |
|---|---|---|
| 1週目の1日目 | いまのメール送信の処理を読み、追加する処理の設計メモを書く | 設計メモと、社内に確かめたいこと |
| 1週目の2日目 | 送信の処理を作り、単体テスト(部品ごとの動作確認)を書く | 変更したソースコードと、テストの結果 |
| 2週目の1日目 | 週明けに社内の担当者がレビューし、そこで出た指摘を直す | 直した箇所の一覧 |
| 2週目の2日目 | 申請から承認までを通して動かし、確かめる | 確かめた手順と結果、残った課題 |
ポイントは、作業日の終わりに残すものまで決めておくことです。1週目の1日目(火曜)に「社内に確かめたいこと」が出てくれば、社内の担当者は水曜と木曜のうちに答えを書いておけます。相手は2日目(金曜)の朝にそれを読んで作業を始められるので、返事を待つ日がなくなります。
作業が1日で終わらなかったときは、途中までの状態を残してもらいます。どこまで作ったか、次に何をするか、止まっている理由は何かの3つがあれば、次の作業日に本人が続きから始められますし、社内の人が続きを引き取ることもできます。
作業日以外の連絡の決め方
作業日そのものは、相手の予定を聞いて合わせることになります。労働政策研究・研修機構(JILPT)が2017年12月に行った調査では、会社に雇われず一人で仕事を請け負う人に、主な取引先1社との関係を尋ねています(6,329人)。*1 ウェブサイトの作成やソフトウェア開発などの「IT関連」の仕事では、作業を行う日や時間について、取引先から「あまり指示されなかった」「全く指示されなかった」人が合わせて70.3%でした。*1
作業する日を相手が決めることが多いのであれば、自社の側で決めておきたいのは、作業日ではない日の連絡の扱いです。決めておく項目は、次の4つです。
- 質問を書き込む場所(チャットの決まった場所や、課題を管理する表など)
- 作業日ではない日に届いた質問に、社内の誰が、いつまでに答えるか
- 作業日ではない日に、相手が連絡を見るかどうか。見る場合はその時間帯
- 急ぎの連絡があるときの手段と、急ぎに当たる場面
とくに大切なのは二つ目です。社内の答える人が決まっていないと、相手の質問が誰にも拾われないまま次の作業日を迎えます。答える人は1人に決め、その人が休む日の代わりも決めておきます。
三つ目と四つ目は、相手がほかの仕事をしている日に作業を求めないための取り決めでもあります。「作業日以外は連絡を見ない」という人もいます。その場合は、急ぎに当たる場面を障害のときなどに絞り、それ以外は次の作業日の朝に読んでもらう形にします。
進捗報告の回数
同じJILPTの調査で、取引先への進捗報告の頻度を見ると、全体では「逐次進捗報告を求められた」「適時進捗報告を求められた」と答えた人、つまり報告を求められた人は31.9%でした。*1 これに対してIT関連の仕事では48.6%で、ほかの仕事より報告を求められる傾向があります。*1
一方、請け負う仕事を副業としている人では、報告を求められた人は27.4%にとどまり、「一切求められなかった」が42.8%を占めました。*1 この数字はIT関連に限ったものではありませんが、週2日で頼む相手の中には、本業を持ち、報告を求められないことに慣れている人もいると考えておくとよいでしょう。
そのため、報告の回数と中身は、契約の前に自社から示しておきます。週2日であれば、作業日ごとの終わりに短い報告を1回、週に1回は社内の担当者と作業の進み具合を確かめる時間を設ける、という組み合わせが考えやすいでしょう。作業日ごとの報告には、前の節の表で見た「作業日の終わりに残すもの」をそのまま使えます。
報告を増やしすぎないことにも気を配ります。2日しかない作業日のうち、報告を書く時間や打ち合わせの時間が長くなるほど、作業に使える時間は減ります。作業日ごとの報告は、終わったこと、次にやること、社内に確かめたいことの3点を数行で書く程度にとどめます。
外部に委託するときに確認しておきたい点
週2日で開発に加わってもらう業務委託エンジニアを探す段階では、稼働日数のほかに、次の点を候補者に確かめておくと、始めてから連絡がつかないことを防げます。
- 作業日の曜日が決まっているか、週ごとに変わるか
- 作業日ではない日に連絡を見られるか。見られる場合は、返事までの時間の目安
- 作業日の中で、社内の担当者と作業の時間が重なる時間帯があるか
- 作業に使う端末と、ソースコードや資料を置く場所を、初日から使えるか
あわせて、自社の側でも、週2日の人に任せる作業の一覧と、社内で答える担当者を先に決めておきます。任せたい作業が、この記事で見た任せにくい仕事にばかり当たるようなら、週2日ではなく、もっと日数を取れる人を探すか、社員の担当と組み合わせることを考えます。
契約の後に、相手の作業日が変わることもあります。作業日を変えるときは何日前までに知らせてもらうか、その週の作業をどう扱うかも、最初の話し合いで決めておくと進めやすくなります。
まとめ:週2日で頼むときに確かめておきたい3つの点
業務委託エンジニアに週2日で開発を頼むうえで、確かめておきたい点は3つに整理できます。第一に、社内の返事を待たずに進められ、2日の中で区切りがつく作業を選ぶこと。第二に、障害対応や毎日の打ち合わせで進める仕事は社員の側に残し、作業は1日で終わる大きさに分けること。第三に、作業日ではない日の質問に誰が答えるかと、進捗報告の回数を、契約の前に決めておくことです。この3点を踏まえておけば、「週2日で頼んだのに、返事を待つばかりで作業が進まなかった」という事態を避けやすくなります。任せる作業の選び方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
作業日は、続けた2日と間を空けた2日のどちらがよいですか
頼む作業によって変わります。設計のようにまとまった時間を使う作業が多いなら、続けた2日のほうが途中で作業が途切れません。レビューのように社内とのやり取りが多い作業なら、間を空けた2日のほうが、返事を待つ日数が短くなります。
週2日の人に、社内のエンジニアの育成を任せられますか
日々の指導より、レビューを通じて教える形のほうが向いています。社内のエンジニアが毎日質問できるわけではないためです。レビューの指摘に理由も書いてもらうと、相手がいない日にも読み返せる教材になります。
週2日で頼んでいる作業が予定より遅れたら、どうすればよいですか
まず、作業日ごとの報告で、遅れの理由が作業の量なのか、社内の返事待ちなのかを確かめます。返事待ちが理由であれば、日数を変える前に、社内で答える担当者と答える期限を見直します。作業の量が理由であれば、作業を小さく分け直すか、頼む作業を減らすことを相手と話し合います。
週2日で頼む開発の進め方を相談したいとき
任せる作業の選び方や、作業日以外の連絡の決め方からご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考:労働政策研究・研修機構「『独立自営業者』の就業実態」(JILPT調査シリーズ第187号、2019年3月・PDF)(https://www.jil.go.jp/institute/research/2019/documents/187.pdf)。出典:労働政策研究・研修機構「『独立自営業者』の就業実態」。調査概要(2017年12月15日〜26日、ウェブモニター調査)、仕事の分類、第1章第3節の図表1-3-5(進捗報告の頻度・仕事別)、図表1-3-6(進捗報告の頻度・専業/兼業別)、図表1-3-9(作業を行う日・時間に関する取引先からの指示の頻度・仕事別)を参照。いずれも一般消費者のみと取引していた人を除く6,329人の、主要な取引先事業者1社との関係。割合の合計は筆者が計算(2026年9月確認)
- *2 参考:Ken Schwaber & Jeff Sutherland「スクラムガイド スクラム公式ガイド:ゲームのルール」(2020年11月・日本語版PDF)(https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)。出典:スクラムガイド(2020年11月)日本語版。「スプリントプランニング」のトピック3(作業を1日以内の小さな作業アイテムに分解する)と「デイリースクラム」(15分のイベント、スプリント期間中は毎日同じ時間・場所で開催)を参照(2026年9月確認)