私はこの7年間、ソフトウェア開発者をはじめとするフリーランサーを雇ってきました。コードの大部分は自分で書いていますが、他の開発者を雇うことで大きなレバレッジがかかり、事業の他の部分に時間を割けるようになります。

フリーランサーとの仕事は、関係性を適切にマネジメントすればうまくいきますが、失敗するパターンは何百通りもあります。うまく始めるための最善の方法は、フリーランスとクライアントの関係について共通認識を持つことです。

以下にまとめたのは、フリーランスの開発者として私と働くことがどういうことかを説明したドキュメントです。私は公開するすべての開発案件の募集要項にこれを添え、契約開始後には内容をじっくり読む時間についても報酬をお支払いしています。相性の合う働き方をする人材を惹きつけ、採用後の立ち上がりを早める効果があります。

このガイドラインはクリエイティブ・コモンズ 表示 4.0 ライセンス（CC BY 4.0）のもとで公開していますので、自由に再利用・改変していただいて構いません。

概要

このドキュメントでは、私がフリーランスの開発者と働く際に用いているプロセスや取り決めについて説明します。

私と働く前にこのドキュメントを読んでいるなら、ざっと目を通して自分の働き方に合うか確認してみてください。すでに契約期間中に読んでいるなら、しっかりと熟読し、その時間は請求してください。

ゴールデンルール

自分が扱われたいように、あなたを扱いたいと思っています。

コミュニケーション

何よりも効果的なコミュニケーションを大切にしています。

多少やり過ぎなくらい、こまめにコミュニケーションをとってください。解決策を共有する際は、なぜそれを選んだのか、他にどのような選択肢を検討したのかも聞けると助かります。

メールは素早く完結させる

主な連絡手段はメールです。

私のメールのスタイルは、カル・ニューポートが「プロセス中心（process-centric）」と呼んでいるものです。要するに、1通のメールは1つのタスクや質問を表しており、できるだけ少ない往復で解決することを目指します。そのため、お互いに受信箱からスレッドを消すためだけの即レスを送るのではなく、よく考えてメールを書く必要があります。

悪いメールの例

以下は、よくないメールのやり取りの架空の例です。フリーランスが必要な情報を最初にしっかり考えず、質問を一つずつ小出しにしています。

良いメールの例

対照的に、こちらのやり取りでは同じ質問を、計画的かつ効率的にまとめています。

メールの返信時間

メールには1営業日以内の返信を期待しています。たとえば火曜日の午後3時に私がメールを送った場合、水曜日の午後3時までに返信が欲しいということです。すぐに完全な回答ができない場合は、まず受領した旨を返信し、いつまでに回答できるか目安を教えてください。

たまに1日以上かかることがあっても構いませんが、それは例外であるべきで、常態化すべきではありません。私にも同じことを期待してください。

ミーティング

ミーティングは、文章では非効率だったり伝えるのが不可能だったりするトピックに有効です。ただ、集中を妨げスケジュールを縛るという大きなコストがかかるため、できるだけ少なくしています。

事実の伝達にはメールを、インタラクティブな議論にはミーティングを使い分けています。たとえば設計書をレビューする場合、リアルタイムで一緒に読み合わせる必要はありません。事前にそれぞれで読んでおき、ミーティングの時間は議論に充てます。

また、月に1〜2回はカジュアルに顔を合わせるためのミーティングも設けます。メールだけのやり取りだと、よそよそしくピリピリした感じになりがちだからです。

面接

採用を決めるために形式的な面接を行うことはありません。

過去の仕事のサンプルを見せてもらったり、メールでいくつか質問したりすることはありますが、何より重視するのは一緒にどれだけうまく働けるかです。有力な候補者には、通常の報酬で範囲を絞った小さな仕事をお願いします。一般的にこれは「トライアル雇用（contract-to-hire）」と呼ばれています。

有償のトライアル課題をお願いした場合、その後一緒に働かないことになっても、かかった時間分の報酬はお支払いします。唯一の例外は、課題に対して誠実に取り組んでいただけなかった場合です（例：プログラミング課題で10時間請求しながら、コードを一切納品しないなど）。

事前の下調べ

フリーランサーが最も価値を発揮するのは、私が監督にかける時間を最小限にしてくれるときです。そのためには、質問する前に自分でしっかり調べることが求められます。

遠慮なく助けを求めて構いませんが、可能な限り自分で答えを見つける努力を期待しています。自分で解決できなかった場合は、どのような方法を試したのかを教えてください。

稼働時間

週5日以上稼働することを誰にも期待していません。特に連絡がなければ、週末は働かないものと想定します。

私自身は週末や米国の主要な祝日には働きません。週末にメールをいただいても構いませんが、返信は翌営業日になります。米国東部時間の正午以前は、なるべくメールをしないようにしています。

どの時間帯に働いても自由ですが、私の稼働時間である米東部時間10時〜18時30分と、ある程度重なる時間帯があると助かります。

毎週決まったスケジュールで働く必要はありませんが、あなたの稼働時間が予測しやすいほど、私もあなたの都合に合わせてタスクやフィードバックを準備しやすくなります。

フィードバック

プロジェクトの途中や終了後に、こちらからフィードバックを求めることがよくあります。フリーランスの方はプロセスや働き方を改善する貴重なアイデアを持っていることが多いのですが、直接聞かれるまではなかなか言い出しづらいものです。

私がよく聞くのは、以下のようなことです。

• 仕事をもっとスムーズに、あるいは楽しくするために変えられることはありますか？
• もっとやりたい仕事、逆に減らしたい仕事はありますか？

納期

急ぎの仕事はめったにないので、基本的にはあなた自身に納期を決めてもらっています。決めた納期は、私からリマインドしなくても守ってください。

納期を何の連絡もなく過ぎさせないでください。火曜日の米東部時間15時までに成果物を期待していると伝えたのに、火曜の夜になっても何の連絡もないと、私はストレスを感じます。タスクをすっかり忘れてゼロからやり直しになるのか、それとももうすぐ終わって数時間以内に納品されるのか、わからなくなってしまうからです。

納期に間に合わない場合は、必ず知らせてください。遅れがわかるのが早ければ早いほど助かります。遅延を伝えるのが最も遅くても、納期そのものを超えてはいけません。

一般的に、事前に計画できれば遅れ自体はそれほど問題ではありません。もし納期が特に重要な場合は、こちらからその旨をお伝えします。

納期を示すときは、正確で曖昧さのない表現を使ってください。

• まあまあ: 金曜日の営業時間終了までに送ります
• 良い: 12月8日 米東部時間17時までに送ります。
• 悪い: 数日以内に用意します。
  • 曖昧すぎます。
• 最悪: できたら連絡します。
  • 極めて曖昧です。

タイムボックス

一緒に働き始めた初期には、1週間あたりやマイルストーンごとの請求時間を制限するようお願いします。あなたの開発スピードや相性を把握するまでの間、請求をコントロールするための措置です。

上限に近づいても終わりそうにない場合は、これまでの作業を整理する時間を確保してください。何が完了し、何が未完で、残りの作業に何時間かかりそうかを説明するメールとともに送ってください。

合意した上限を超えた時間についてはお支払いできません。

一緒に働く期間が長くなるにつれて、上限を引き上げたり撤廃したりして、より自由に進められるようにしていきます。

ドキュメント

ドキュメントを非常に重視しています。

プロジェクトに文書化されたプロセスやGitHubのテンプレートがある場合は、それに従ってください。ドキュメントの指示が間違っているように思えても、勝手に古いとか自分には関係ないと決めつけず、必ず知らせてください。

私とプロジェクトを始めると、その立ち上げドキュメントの新たなオーナーはあなたになります。ドキュメントが不十分だったり、そもそも書かれていなかったりして詰まったときは、不足を補う編集を提案してください。

書いたコードは丁寧にドキュメント化してください。コード自体が説明となるようにすることを目指しつつ、コードだけでは伝えられない情報はコメントで補ってください。新しいコードには、周辺のコードと同程度の丁寧さでコメントを付けてください。

# Number of days per week (seven)   <-- BAD comment
DAYS_PER_WEEK = 7

# This is a workaround for a bug in FooComponent, which crashes the process
# if we call it immediately after writing to disk. <-- GOOD comment
time.sleep(5)

コードの品質

対応の速さよりも、品質と保守性を重視します。

動くコードができたら、ロジックをシンプルにしたりリファクタリングしたりして、より直感的にできないか考えてみてください。コードを30％シンプルにするために2倍の時間がかかっても、私にとってはプラスになります。

コードレビュー

すべてのコード変更を徹底的にレビューし、詳細なフィードバックを返します。

私のコメントはあなたを批判したり、嫌な気持ちにさせたりするためのものではありません。コードを理解し、長期的に自分がメンテナンスできる状態にするために、厳密にレビューしているのです。

私のコードレビューの進め方については、以下の記事で説明しています。

• コードレビューの方法
• レビューに出すコードの書き方

コードスタイル

私のプロジェクトはGoogleのコーディングスタイルガイドに準拠しています。

• Python
• HTML/CSS
• Shell

できる限り、スタイルの規約は自動ツールで強制するようにしています。

Git

ソース管理にはGitを使っています。Gitのエキスパートである必要はありませんが、以下の基本操作は理解してください。

• リポジトリをクローンする
• ブランチを作成する
• コミットを作成する
• 変更をプッシュ・プルする
• コミットをリベースする（まれに）

GitHubの権限

アクセス権は最小権限の原則に基づいて付与します。公開リポジトリで作業する場合は、フォークして追加の権限なしでプルリクエストを作成できます。

私が使っている2つのGitHub連携、CircleCIとReviewableは、厄介なことに非常に広範な権限を要求します。どちらのアプリも、GitHubアカウント内のすべてのリポジトリへの書き込み権限を必要とします。こうした権限に抵抗がある場合は、私との仕事用に専用のGitHubアカウントを作成し、そちらでフルアクセスを許可するようにしてください。

コミット履歴の扱い

すべてのコミットは美しく神聖なものだと考える開発者もいますが、私はそうではありません。

私にとって重要なのは、mainブランチのコミット履歴が健全であることです。それ以外のブランチでは、好きなようにコミットしてください。コードレビューの指摘1件ごとにコミットしても、すべての指摘を1つのコミットで対応しても構いません。どのようなワークフローでも大丈夫です。GitHubのsquash and merge機能を使っているので、どのプルリクエストも最終的に1つのコミットにまとめられます。

多くのコミットを含むプルリクエストを送っても、私はプルリクエストのタイトル、説明、コメントを読みます。個々のコミットは中間作業だと想定しているので、わざわざ掘り下げて見ません。記事「How to Write a Git Commit Message」で説明されているコントリビューションの記録スタイルを、私は好んでいますが、それを個々のコミットではなくプルリクエストに適用するイメージです。

テスト

プルリクエストを作成する際は、継続的インテグレーションですべてのテストが通ることを確認する責任があります。ビルドが失敗している場合は、レビューに出す前に修正してください。

機能を追加したり、何らかの挙動を変更したりした場合は、新しい挙動を検証するように自動テストを更新してください。

自動テストが難しい機能を変更した場合は、手動でその機能をテストして新しいコードを検証してください。どうしてもテストする方法が見つからない場合は、レビューに出す際にテストできていない旨を知らせてください（これは極めて稀なケースであるべきです）。

請求可能な時間

私との仕事のために行う活動は、ほぼすべて請求可能な作業とみなします。

経費

フリーランスの開発者として活動するために必要な基本的なツール（例：PC、インターネット接続、電気）は、ご自身で用意していただくことを想定しています。

作業をより効率的に、あるいは快適にするためのソフトウェア、サービス、機器の費用は喜んで負担しますので、まずは私に相談してください。

仕事に関連して何かの購入をお願いした場合は、次回の請求書で精算します。

モニタリング

作業時間は正直に申告していただけると信頼しています。時間を「証明」するよう求めたり、監視ソフトをインストールさせたりすることは決してありません。

Upworkのようなモニタリング機能が組み込まれているプラットフォームを利用している場合でも、その機能は常に任意とします。作業時間に甚だしい不一致がない限り、モニタリングデータを確認することはありません。仮にそのような場合でも、データを確認する前に必ずあなたに声をかけます。

進捗報告

どれくらいの頻度で進捗を共有すべきかを厳密に決めるのは難しく、ある程度の判断が求められます。

スコープが明確なタスク、たとえば内容がよくわかっている機能開発であれば、請求時間が8〜10時間ごとに1回報告してください。バグ調査や試行錯誤が必要な機能など、スコープが変動するタスクであれば、2〜4時間ごとに1回を目安にしてください。いずれの場合も、進捗報告なしで空けてよい期間の上限は、稼働日で3日間か、請求時間で10時間のいずれか早い方とします。

進捗を共有する最良の方法は、進捗がわかるプルリクエストを出すことです。理想的には、作業の一部を切り出して完成したプルリクエストとして出せるとよいですが、難しい場合はドラフトとしてマークして共有してください。バグ調査中の進捗を共有する場合は、GitHubのissueを更新し、何を調査して何がわかったかをまとめてください。

GitHubで広く共有したくない、仕事に関するメタ的な議論については、個別にメールで連絡しても構いませんが、できるだけ多くの議論はGitHub上で行うようにしてください。

支払い

請求書は2週間ごとに送ってください。請求書の受領から5営業日以内、通常はもっと早くお支払いします。

ボーナスやチップはお支払いしません。報酬は透明にしたいと考えており、金額が私の裁量に左右されるような曖昧な支払いに悩む必要がないようにしたいからです。

お支払いは、ご希望に応じてPayPal、Payoneer、ACH送金（米国のみ）、または小切手の郵送（米国のみ）で行います。

契約終了後の対応

仕事が終わった後に、成果物についての質問や無償での修正依頼を連絡することは決してありません。契約期間内に依頼したものがすべて納品されたかを判断するのは私の責任です。

支払い後にあなたの仕事に問題が見つかった場合でも、それを自分で修正するか、追加の有償時間として依頼するかは私の責任です。

税務

暦年で600ドル以上お支払いする場合、税務上いくつかの書類が必要になります。

• 米国市民および居住者の方
  • W-9フォームの提出が必要です。年末にはこちらから1099-MISCをお送りします。
• 米国外のフリーランスの方
  • 米国での納税義務がないことを申告するW-8BENフォームが必要です。

知的財産

知的財産権をこちらで保持したいプロジェクトで一緒に働く場合は、契約書を送付し、電子署名をお願いします。そこでは、あなたが私のために書いたコードの著作権を私が買い取ることが明記されています。

この契約は、私が報酬を支払って制作していただいた成果物のみを対象とするもので、報酬が発生していない時間にあなたが作成したものには及びません。

カバーアート: Loraine Yow

あなたはクライアントですか、それともフリーランスですか？ 同様のドキュメントを見たり、他の方がこの問題にどう取り組んでいるかを聞いたりできれば嬉しいので、ぜひコメントで共有してください。