業務委託エンジニアとして持ちたいスタンス
ターゲット読者層にこのタイトルの方が届きやすいと思って業務委託エンジニアと書きましたが、正確にいうとフリーランスではなく1人システム請負開発会社向けの記事です。現代はこれらがごっちゃになっていると思います。
フリーランスと業務委託・個人事業主・1人開発会社との違いはこのあたりの note なども書いてますので見てもらえればと。
上記の記事で言ってるのは、フリーランスは契約上同じ業務委託という形式を使っていて、指揮命令のなしとか非拘束みたいな自由が強調されがちだが、プロジェクト単位であってもあくまで雇われる立場なので、指揮命令なしや非拘束が標準パックで付いてるとする前提は変だよねってことです。
この記事では、フリーランス（無所属でもプロジェクト単位で雇われる人）ではなく、あくまで業務を委託される独立した事業主として確立しておきたいスタンスを、ご紹介・ご提案したいと思います。
前提
日本の場合、そもそも雇用や働き方について以下のような問題や疑問が前提としてあると思っていて、長いのでここでは列挙だけしておきます。
- まず正社員、というか無期雇用者の解雇規制が厳しすぎる問題
- それによる人材の流動性不足を補うために派遣やフリーランス、業務委託などが増え、本来の役割や定義を超えて「正社員より切りやすい人材」みたいになってること
- 業務委託というと偽装請負や指揮命令や非拘束の視点がよく語られるが、じゃあ正社員や派遣された労働者は指揮命令をされたり時間や場所を拘束される奴隷なの？
結論、理想の働き方という意味ではフルフレックス・フリーアドレス・週4日稼働・1日4〜6h稼働の時短正社員なのではないかと思います（そりゃそうだ）。
被雇用者と業務委託パートナーとの違い
いわゆる正社員と本来の業務委託（≠フリーランス）では主に以下のポイントで違いがあると思います。SESの社員やフリーランスエンジニアでこの辺の立ち位置が正社員とほぼ変わらないような人は多い認識で、それゆえに“本来の”業務委託もごっちゃになって扱われるイメージがあります。
- 所属（雇用なのか外注先なのか）
- 指揮命令と非拘束の有無
- 報酬の対価（労働 or 成果）
- フルタイム or パートタイム（タイムチャージ式の場合）
- チームメンバーなのか？パートナーなのか？
つまり業務委託とは「所属先はもちろん別で、指揮命令や必要性のない拘束は受けず、基本的には労働でなく業務の代行や成果を対価として提供している。納品のある請負契約なら当然期限までに納品さえすれば極論月1h稼働でもいいだろうが、フルタイムかパートタイムかは請け負う業務の内容や成果の期待値による。あくまでパートナーである」といったところだろう。
基本的なスタンス
抽象的に言うと「準委任契約のタイムチャージ制であっても、あくまで真の意味での業務委託として、役割、評価、成果物や提供価値、コミュニケーションなどで振る舞いを変えましょう」ということなのですが、以降具体的に見ていきます。
フェーズごとの成果物を握る
昨今はアジャイル開発的に（受託開発だろうと）MVPをスピーディーに作って、ユーザー（顧客の現場社員たち）からのフィードバックを受けて欲しいものを明確にして開発していくスタイルしか良いものはできないんじゃないかと思っているので、そうなると「じゃあ合計でいくらで、3ヶ月でできると思います」とか言えないため、準委任契約のタイムチャージ精算方式（時間 or 月間）とならざるを得ない。
しかしあくまで「1ヶ月間常駐して働きますよ」じゃなくて、報酬の対価として成果物を納品するという意識を持ち、まずクライアントとMVP, 機能A追加、機能B追加..のようなフェーズを握り → そのフェーズごとに握った大まかなスケジュールと品質イメージのものを都度納品していくイメージを持つことが、業務を委託されているプロとして適切なスタンスかと思う。
フェーズ1：9月
例）MVPとして1人の社員がローカル実行して業務効率化できるツールを作る
例）まず Google スプレッドシートとGASで業務効率化ができるツールを作る
フェーズ2：10月
例）ログイン機能をつけて、全社員が利用できるようにする
例）Webシステムとして管理画面作成
フェーズ3：11月
例）操作ログ機能の追加
このくらいざっとではあるが、フェーズとスケジュール感を事前にクライアントと握っておくことで、何でもやる社内情シスではなく「フェーズごとの成果であるシステムを納品してくれる業者さん」というスタンスが明確になりやすい。
具体的な現場でのケーススタディ
名刺とメールアドレス
あくまで会社は別なので名刺はやっぱり本来の所属先のものを持たないとダメだよね。派遣とかSESで10社くらいの人が入っているプロジェクトとかも多いんだろうけど、所属とは教育の有無だと思っているので「任天堂の人」と「任天堂から業務委託を受けた人」だとスキルとか役割が同じでもやっぱり錯覚資産的な期待値や評価は異なるよねと。
単にコードがかけるとかシステムを組める人が優秀なわけではないから、コミュニケーションや一般常識や「任天堂の入社試験を通過した人材が持っているもの」みたいな、数字にに現れにくい価値があると思うので、所属していない業務委託の人に名刺を発行するのはやや詐欺っぽさがあると思う。
メールアドレスなどの各種アカウントも、Google Workspace や Slack 招待まわりで業務委託の方にも発行した方が色々楽だったり、課金しなくて済むとかもありそうだが、基本的には自社のもの（個人ならGmailでもいいが）を使ってやりとりすることを勧めたい。
SaaSのアカウント関係
上記の通り Slack もあくまで外部の人間として Slackコネクトで繋いでもらう。今は Slack Connect で繋がっている人も問題なくチャンネルに招待などできる（ただし1個ずつなど手間はあるが）ので、基本はその対応でお願いする。
同様に Notion や GoogleDrive のファイルもゲストで招待してもらって、自社（自分）のメールアドレスに紐づくアカウントで閲覧や操作をさせてもらうようにする。
全社MTGや社内イベント
基本的に会社全体の方針や社員同士の交流などが目的の行事には出席しない。が、取引先としてイベントやパーティーに招待されるケースは多いと思うのであくまでパートナーという立場で出席するはいいことだと思う。
チーム内での言葉遣い？
顧客には当然敬語を使うとして、業務委託であってもプロジェクトチームに組み込まれて作業することもあるだろう。これ自体が良いことなのか悪いことなのか一般解はわからないが、個人的には“業務委託パートナー”という立ち位置でチームと言われるとやはり違和感がある。
（例えば「琵琶湖の水、全部抜こうプロジェクト」みたいな社会的というか、あまり会社会社してない精鋭チームを集めるプロジェクトみたいな感じだと、どこの所属から集まってようがこれはチームとして一丸とならなければならないし、一丸となれるのなら契約形態や報酬形態がどうであれ上手くいきそうだが。）
で話を戻すと、そういうクライアントの社員と同じチームで働くとなった場合、つい「会社は違っても同じチームなんだから」とか「PMやTechLeadとして参画して年下の新人さんのPRをレビューする」といった関係性の中で、慣れてくると部活のようにタメ口になったりもするかもしれない。
が、基本的にはあくまで発注元と発注先の関係というスタンスを守って、年下だろうとペーペーの新人だろうとお客さんとして敬語というか丁寧語や謙譲語で話すように心がけたい。まぁ口頭だと流石に硬すぎるが、Slackなどの文面では「です」「ます」だけじゃなく「〇〇された時に..」「前に仰られたXXは〜」みたいな表現を私は使います。
と言いつつも、コミュニケーションにおいてタメ敬語のようなバランスも大事だと思っているし（敬語でツッコミとか冷めるし、お客さんだからボケれないという関係も悲しいし）、そもそも敬語やタメ口という年齢や肩書きなどで言葉遣いを変えたり上下関係の線引きをするのも気持ち悪さを感じる派ではあります。
ただ結局、言葉遣いに迷うみたいな状況が「それって業務委託として向いてない仕事（切り出されてない仕事）ですよ」ってサインなのかもしれない。
プルリクエストのレビューを依頼？
同様にチーム開発だと GitHub でプルリクエストをすることも多いだろう。
プルリクエストというものが納品物の検収ではなく、コードの良し悪しをチェックしてもらうような側面もあるため、「プロに業務を委託しているのに、なんで客の立場のウチが教育やミス探しみたいなことをしてるんだ」みたいになってる現場も多いと思う。
そのため「とりあえずできたんで先輩にコード見てもらおう」といったスタンスよりは、業務委託されているプロのエンジニアとして、納品的に品質を高いコードを Pull Request したい。まぁ正社員だろうと当たり前だろうとも思うが、実態として「契約の通りに見るなら、お客さんが発注先の社員の教育をしている」みたいな状況は多いのではないだろうか。
クライアントに相談？
同様に「技術的にわからないところが出たらクライアントのエンジニアに相談するのか？」という疑問もでる。システムの連携部分など協業する上で合意や議論が必要な部分は当然するものの、「これってどういう設計にしたらいいんだろう？このバグの原因がわからない..」みたいなことは、あくまでプロとして自己解決する前提でいたい。まぁ正社員でも当たり前か..
ただ時間チャージにしている以上、相談すればわかることに何時間も使うのはクライアントにとっても損なのでやはりそこは立場をわきまえ相談するしかない。
ただあくまでプロとして「お客さんに教育をしてもらう」ということがないようにしたい。
メンバーのマネジメントや教育はこちらの責務？
本来は業務を委託される事業主なのであれば、その業務遂行に必要なメンバーは自社で集めるのが筋に思う。当然自社のメンバーのマネジメントや教育は自社の責任である。一方、クライアント所属のエンジニアたちとチームを組むプロジェクトの場合、そのピープルマネジメントや教育は自社の責務だろうか？
業務委託は社員と疎外感があって寂しい？
そこを気にするなら正規雇用のメンバーになろう。フルタイム勤務や縛りがいやならフルフレックス、フリーアドレスの条件を頑張って交渉できるくらいハイスキルやハイバリューになるしかない。
正社員登用のお誘い？
フリーランスだと正社員化をするというのはアリだと思う。実際、冒頭のnoteの通りフリーランスが得られる自由とは「どのプロジェクトをやるか」という選択の自由であり、本来は時間的自由や働く場所の自由は標準で付いてないものと思っている。なので「40歳超えても人生ずっと会社を跨ぐプロジェクトを転々とする」というのは結構キツイ人が多いと思う。その意味で正社員を勧めるのはお互いにメリットのある話で筋が通っていると思う。
一方、真の意味で業務委託の場合、これは引き抜きであるのでちょっとそこの分別はクライアントにもわきまえてほしい気持ちがあるが、AIが発達してるとは言え1人で受託できる範囲は依然限界があるためそうなってしまうのも仕方ないか。
ただ会社のミッションが個人のミッションに共感することは非常に重要だと思うので（お金以外のその仕事に感じる意義）、中小企業の業務効率化支援をミッションとしている会社の社員が、クライアントである全く別のミッションを持っている企業にジョインする、というのは例え仲が良いとかスキルがあるとか関係なく、ミスマッチでないかお互いによく検討しないといけないと思う。
まぁ本来はそこが合う人にだけ正社員オファーが来るのが綺麗だが、世の中、会社ミッションと個人ミッションを紐づけられて生きがいを持って仕事できてる人ってどれくらいいるんだろう。
このスタンスを取りにくいケース
一部機能の開発だけを委託したい
システムの設計なり使用するフレームワークやライブラリの選定なり、アーキテクチャやコード規約の選定を自身（自社）でコントロールできないとかなりつらい。そういう意味で、既存のコードベースがあるプロジェクトに自己の裁量で業務を遂行したい独立志向が高い人が入るのはやはり難しいのではないか。
2次請け
多重下請けの問題はよく言われるが、シンプルな2次請けだとしてもその業務の80%以上を再委託するようなのは禁止にした方がいいと思う。コミュニケーションが直だろうとお金の流れとして、間にほぼプロジェクトや業務の実行に関与してない人が入るとやはりおかしくなる。
100%再委託となるとそれはつまり紹介であり、本来は紹介してくれたお礼に請け負う側が紹介料を払う（＝客であり）強い立場であるはずが、紹介者がお金の流れを握っている構造になっていて力関係がおかしくなる。
お金を払う人とユーザーが一致しないシステム
これは個人的な好みもあるかもですが、業務委託やシステム開発の外注であっても、お金を払う人とそのシステムのユーザーが一致していないと色々やりにくい。代表例はC向けアプリの開発を全て委託とか（ソフトウェアの使い易さや機能が事業価値に直結するようなものなら自社で作るのがおすすめ。それができないなら Why you? に答えられていない事業だと思う）。
ただポケモンを開発した Game Freak のように開発パートナーとして会社は違っても一般消費者が使うプロダクトを開発してうまくいくケースもある（任天堂はIPを貸し出している立場）。
契約書や注文書で定める交渉条件
最後に業務委託にあたり準委任契約書や、それを元に個別で期間や報酬金額などを柔軟に変更して発注できる注文書に明記しておく方がいいことをあげておく。
- 仕事の進め方（働く場所、働く時間帯）
- 連絡方法（Slack）
- 進捗共有方法
- 最低稼働時間
- 営業日、特に祝日の扱い
働く時間帯については、タイムチャージとは言えあくまで雇用されてるわけではなく、フェーズごとの成果を売っているので 9:00~17:00 出勤してくださいのような条件は「業務委託とは？」と思わざるを得ない。
弁護士や税理士などと同じく、社会的に平日日中に連絡つく状態である、ということで十分と思うが、チームで動くとなるとより密なコミュニケーションが必要になるため、（そもそもそれは業務委託に適してない仕事なのではないかと思うが）、コアタイムのような条件は事前に交渉や明記をしておかないと、正社員と同じような出退勤なりを求められてしまうなど困ってしまう。
逆に最低稼働時間については、タイムチャージであったり毎日何かしらのコミュニケーションが必要な業務の場合はクライアントのために定めておいた方が良いと思う。
営業日（稼働曜日）について、特に祝日やGW、年末年始などは事前に擦り合わせとかないとクライアントに合わせたりしがちと思うが、ソフトウェア開発なんか炎上やデスマーチになりやすい（無理ゲーなウォーターフォールだったから？）ため、しっかり休息や、会社や個人の方向性などを考える時間を確保してないと「ずっと働いてたら契約切られちゃって来月からどうしよう..」みたいなことになりかねない。まぁこれも正社員にも言えることだよね。
AIの発展が凄まじいとはいえ、まだまだ売り手市場のエンジニアならフリーランスとしてエージェントに紹介してもらえばすぐ次の案件決まるかもだけど、そもそもその働き方でずっといいのか、今後の人生設計など考える時間は大事だと思うから、営業日や祝日の稼働可否は事前に合意できてるのが理想かなと。
まとめ
色々書いてきましたが、文中でも見られるように結局自分も真の意味での業務委託エンジニアなのか、フリーランスなのかよくわからなくなって来ました。そもそもこの大量生産・大量消費、終わりなき競争の資本主義社会の限界が来ていると感じる身ですが、魚を釣って野菜を育てていた時代と比べて、お金や金融というものが生まれた現代は複雑だなぁと思います。
Discussion