私はこの7年間、ソフトウェア開発者をはじめとするフリーランサーの方々にお仕事をお願いしてきました。コードの大部分は自分で書いていますが、他の開発者に依頼することで大きなレバレッジがかかり、ビジネスの他の部分に時間を使えるようになります。

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

以下のドキュメントでは、フリーランスの開発者として私と働くことがどのようなものかを説明しています。私が公開する開発案件の募集には必ずこれを掲載し、稼働開始後には内容をじっくり読んでいただき、その時間もお支払いしています。働き方の相性が合う方からの応募が集まり、採用後の立ち上がりも早くなります。

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

概要

このドキュメントでは、フリーランスの開発者の方と仕事をする際に私が用いているプロセスやルールを説明します。

私と働く前に読んでいる場合は、ざっと目を通して、この働き方がご自身に合うかどうかを確認してください。すでに契約期間中に読んでいる場合は、しっかりと読み込み、その時間は請求してください。

基本原則

自分がされてうれしいように、相手にも接したいと考えています。

コミュニケーション

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

迷ったときは、伝えすぎるくらいがちょうどいいとお考えください。解決策を共有する際は、なぜそれを選んだのか、他にどのような選択肢を検討したのかも合わせて教えてください。

メールは速やかに完結させる

やり取りは主にメールで行います。

私のメールスタイルは、Cal Newportが「プロセス中心」と呼んでいるものです。簡単に言えば、メール1通は1つのタスクや質問を表し、できるだけ少ない往復で解決することを目指します。そのため、お互いに受信箱から消すための最速の返信を打ち返すのではなく、よく考えてメールを書く必要があります。

悪いメールの例

以下は、悪いメールのやり取りの架空の例です。最初に必要な情報を整理する手間を惜しんだ結果、フリーランスの方が質問を小出しにしてしまっています。

良いメールの例

対照的に、こちらは同じ質問を効率よく、計画的にやり取りした例です。

メールの返信時間

メールへの返信は1営業日以内にお願いしています。たとえば火曜日の15時に私がメールを送った場合、水曜日の15時までに返信をいただきたいです。すぐに完全な回答ができない場合でも、まずは受け取った旨を返信し、詳しい回答の目安をお知らせください。

ときどき返信が1日以上かかるのは構いませんが、あくまで例外であって常態ではないようにしてください。私も同じ基準を守ります。

ミーティング

ミーティングは、文章では非効率だったり、そもそも伝えられなかったりすることを扱う場合に有用です。ただしコストは大きく、集中を妨げ、スケジュールも縛られてしまうため、最小限にとどめています。

事実の共有はメールで、双方向の議論が必要なトピックはミーティングで扱うようにしています。たとえば設計書をレビューする場合、内容を一緒に読み合わせる必要はありません。事前にそれぞれで読んだうえで、ミーティングの時間は議論に充てます。

また、月に1〜2回はカジュアルに顔を合わせるためのミーティングも設定します。メールだけのやり取りでは、関係がよそよそしく、ぎすぎすしたものに感じられてしまうことがあるからです。

採用について

採用を決めるために、形式的な面接は一切行いません。

これまでの成果物の例を見せていただいたり、メールでいくつか質問させていただくことはありますが、最も重視するのは一緒にお仕事をしたときの相性です。有力な候補者の方には、通常の報酬をお支払いしたうえで、範囲を絞った小さなお仕事をお願いしています。一般的には「契約から正規採用へ」というスタイルと呼ばれています。

有償のトライアルをお願いした場合、その後に一緒にお仕事をしないことになっても、かかった時間はお支払いします。唯一の例外は、課題に対して誠実な取り組みをいただけなかった場合です（たとえば、プログラミング課題で10時間請求しながら、コードが一行も納品されないといったケースです）。

事前調査

フリーランスの方が最も価値を発揮するのは、私がお仕事を監督する時間を最小限に抑えられたときです。そのため、質問する前にご自身での事前調査をお願いしています。

遠慮なく助けを求めていただいて構いませんが、可能な範囲ではご自身で答えを見つけていただくことを期待しています。どうしても解決できない場合は、どのように調べたり試したりしたのかを教えてください。

稼働時間

週5日を超える稼働は期待していません。別途お知らせがない限り、週末はお休みと想定しています。

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

お好きな時間に働いていただいて構いませんが、私の稼働時間である米国東部時間10時〜18時半と、一部重なる時間帯があると助かります。

毎週決まったスケジュールで働く必要はありませんが、稼働時間をある程度予測できると、あなたのご予定に合わせてタスクやフィードバックを準備しやすくなります。

フィードバック

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

よくお聞きするのは次のようなことです。

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

締め切り

急ぎの仕事はめったにありませんので、締め切りは基本的にご自身で決めていただいています。決めた締め切りは、私から催促がなくても守っていただくようお願いします。

締め切りを何の連絡もなく過ぎてしまうことがないようにしてください。たとえば「火曜日の東部時間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倍の時間がかかっても、私にとってはプラスです。

コードレビュー

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

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

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

• How I review code
• How you should submit code for review

コーディングスタイル

私のプロジェクトでは、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」で推奨されている書き方は、個々のコミットではなくプルリクエストに適用する形で、私の好みと一致します。

テスト

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

機能を追加したり、挙動を変更した場合は、自動テストを更新して新しい挙動をカバーしてください。

自動テストが難しい機能を変更した場合は、手動で動作確認を行い、新しいコードが正しく動くことを確かめてください。どうしても確認する手段がない場合は、レビュー依頼の際に未テストである旨を教えてください（これは極めて稀であるべきです）。

請求時間

私とのお仕事のために行うほぼすべてのことを、請求対象と考えています。

経費

フリーランスの開発者として活動するための基本的な道具（パソコン、インターネット接続、電気代など）はご自身でご用意いただくことを想定しています。

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

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

モニタリング

あなたが時間を正直に申告してくださることを信頼しています。時間を「証明」するよう求めたり、監視ソフトウェアのインストールをお願いすることは決してありません。

Upworkのようなモニタリング機能が組み込まれているプラットフォームを利用している場合でも、モニタリング機能は常に任意とします。請求時間に著しい乖離がある場合を除き、モニタリングデータを確認することはありません。その場合でも、データを見る前に必ずお声がけします。

進捗共有

どのくらいの頻度で進捗を共有すべきかを一律に決めるのは難しく、ある程度の判断が必要です。

範囲が明確なタスク、たとえば内容がはっきりしている機能開発であれば、請求時間が8〜10時間ごとに一度共有してください。バグ調査や試行錯誤が必要な機能のように範囲が変動するタスクでは、2〜4時間ごとに一度を目安にしてください。いずれの場合も、進捗共有がない期間は、稼働日で3日間または請求時間で10時間のいずれか早い方を上限としてください。

進捗共有の最良の方法は、進捗を反映したプルリクエストです。可能であれば、作業の一部を切り出して完成したプルリクエストとしてください。難しい場合は、ドラフトとしてマークしたプルリクエストを共有してください。バグ調査の途中経過を共有する場合は、GitHubのissueを更新し、何を調べて何がわかったかをまとめてください。

GitHubで広く共有したくない、仕事に関するメタな議論は個別にメールしていただいても構いませんが、できる限り議論はGitHubに残すようにしてください。

お支払い

請求書は2週間ごとにお送りください。請求書から5営業日以内、通常はそれよりも早くお支払いします。

ボーナスやチップはお支払いしていません。報酬を透明にし、裁量に左右される不確かな支払いについて悩む必要がないようにしたいからです。

お支払い方法は、ご希望に応じてPayPal、Payoneer、ACH送金（米国のみ）、小切手の郵送（米国のみ）からお選びいただけます。

契約終了後の対応

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

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

税務

暦年で600ドルを超えるお支払いをする場合、税務上いくつかの書類が必要です。

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

知的財産

知的財産権をこちらで保持したいプロジェクトで一緒にお仕事をする場合は、契約書を電子署名のためにお送りします。私にお支払いいただいたコードの著作権を譲渡いただく内容です。

この契約は、私がお支払いするお仕事として生み出された成果物のみを対象とし、あなたの有償時間以外に作成されたものには適用されません。

カバーアート：Loraine Yow

クライアントの方ですか？ それともフリーランスの方ですか？ 同様のドキュメントをお持ちでしたら、あるいは他の方がこの問題にどう取り組んでいるかご存知でしたら、ぜひコメントで教えてください。