高単価のフリーランス案件で仕事するときに意識していたこと
フリーランスのWebエンジニアとして仕事をする上で、いつも気をつけていたことをつらつらと書いてみます。
フリーランスやっている人、興味ある人の参考になれば。
自分についての情報
フリーランスのWebエンジニアを2年半
当時はRails, Vue.js, Reactがメイン(2018-2020)
情報系の大学院 → メガベンチャー2年 → スタートアップ2年からの独立
単価は相場の最高額くらい
お金の話あんまりしたくないが、みんな興味あると思うので一応
一度お世話になったFindy Freelanceさんの募集を数年ウォッチして、自分がFindyさんで受けた案件が頭を抜けて最高額だった
ややボカすため最低限の目安だけ書くと、時給1万円〜（人月160万円〜）以上
技術顧問業を上手くやると、もっともらえると思う
準委任契約、月N時間稼働って感じで契約
シードA〜シリーズCのWebスタートアップ企業の案件が多め
前置き
あくまで「自分が気を付けていたこと」です。
「世の中のフリーランスWebエンジニアのあるべき姿」「自分がフリーランスに求めること」ではありません。
誰かの参考になれば幸いです。
コミュニケーション
稼働時間中のメンションはだいたい即レス
もちろん可能な範囲で。
最低限、 👀 マークつけるとか
もちろん、コーディング中で集中切らしたくないときとかは遅れても良い。しかし即レスは評判がいいので、自分の中での優先順位は高い。円滑なコミュニケーションは大事
1つの開発タスクに集中させてもらっているフリーランスなら、メンションに即レスは普通にできるのではという考え
稼働時間外でも、可能な限りの返信
ワーカホリックっぽい。でも顧客からすると嬉しい
「映画見てる最中」「友人と一緒にいる時」とかは返さなくていいと思う。それ以外の時間は、自分は返信できる時なら返信する
相手が知りたい情報を、事前にこちらが提供する
相手に質問させている＝相手の思考コストを奪っている
自分についての情報を、積極的に共有する
自分のスキルについて、いま何に困っているか、稼働時間中に何をしたか、何にどれだけ時間がかかったかetc
良い相互理解の第一歩は、お互いの情報の共有から
自分が優秀だなと感じる人は、これが丁寧な人が多い
基本出社多めにする
出社してコミュニケーションした方が円滑に進めやすい
出社を嫌がる人が多そうだけど、その分良いサービスが作れて、そして高い報酬をもらえるなら、自分はこれくらいはする
そもそも都心アクセス良いところに住んでいる、オフィス遠いところの案件をそもそも受けない、出社が苦じゃない性格というのはある
既存のソースコード・チーム・組織・仕組みetc…に敬意を払う
残念なソースコードがいっぱいな現場もあるが、それに対してネガティブな意見を喚き散らかしても、そのコードでやってきた周りのメンバーが嫌な気持ちになるし、チーム間の信頼がないと結局いいサービスは作れない。ここまで事業を作ってきた既存の仕組みに敬意を払う
例え正論でも、正論を振りかざすのはダメ
まずは郷に入っては郷に従いつつ、周囲の信頼を獲得してから、「良いサービスを作るために」という共通認識をもって、現場を変えていけると良い
とはいえ、外からやってきたフリーランスには新しい風を期待されることもあるので、合意があれば一刀両断に既存の風土を切り捨てるのもあり。その際は責任をもって推進
キャッチアップ
情報は自分から積極的に収集する
自分で調べられることは自分で調べる
会社情報とか、サービス情報とか、公開情報は全て眼を通す
社内ドキュメントは、自分に関連しそうな範囲は全て眼を通す
自社サービスを触れる環境があれば、とことん触り倒す
直近のPRレビューに目を通して、開発ルールや直近の開発内容を把握する
この辺は初日・初週に済ませる
開発タスクをアサインされたときに、リードエンジニアのブリーフィングなしに「あ〜、xxxがxxxになってる問題ですね。気になってました。やっときます！」を常に言えるようになりたい
コードベースは「テーブル定義」「ルーティング」「使ってるライブラリ」「フォルダ構造」「インフラ設計」くらいは一通り最初に見る
これ見て理解すれば、サービスの全体像は大体分かるはず
不明点は気軽に質問する
不明なことを無理に調べようとして工数を使うのは無駄な時間。調査の時間にも報酬が発生してしまっていることを意識する
気軽に質問しつつ、どこまで回答してもらうかは相手に委ねる
自分がどういうことに疑問を持っているのか？を相手に共有しておく。相互認識を作る
#times-<自分> 相当を作って、そこに思考を垂れ流すのが好き
自分が担当した範囲について開発ドキュメントがなかったら、自分でドキュメントを作る
後続のエンジニアの開発効率も考える
ドキュメント書いてる間に、自分もドメイン知識が整理される
slackで自分が入ってるチャンネルはだいたい全部目を通しがち。定期的に未読をクリアしがち（これはやりすぎな自覚）
開発面
PRレビューで、一切指摘されずにマージされる
指摘がある＝レビュワーの工数を奪っている
レビューさせている＝レビュワーの工数を奪っている
本来はレビューなしでもOK、くらいなコード品質が理想
自分の契約中は、多分ほぼ指摘はなかったはず
PRレビューで、一切質問されずにマージされる
質問がある＝レビュワーに疑問を持たせている＝思考コストをかけさせている
質問になりそうな点を、事前にPRコメントに書いておく
一切不具合を出さないこと
不具合出さないのは当然
レビューしてくれるLEに「この人の書くコードは不具合があるかも……ちゃんと見なきゃ…」と思わせるのは、だいぶコストかけさせているので避ける
自分の契約中は、多分ほぼ不具合は出さなかったはず？（少なくとも大きな不具合はゼロ）
手元でのQA、ちゃんとやろうね
仕様を考え抜くこと
「リリースしてから仕様漏れが発覚したけど、自分は言われた通りに作っただけなので知りません」はNG
実装者が一番仕様に詳しく、またユーザーの気持ちに詳しくなれていると良い。
自分がサービスのヘビーユーザーになれていると良い。また、ユーザーの生の声を聞けていると良い（この辺はサービスによりけり）
以上を、高速に行う
「時間をかけて丁寧に」ではなく「短い時間で丁寧に」
自分の力を誇示するのは苦手なので、あんまり大きいこと言いたくはないが、フリーランスで渡り歩いてみて、平均的なエンジニア(??)の5倍速くらい(???)は出せているかなあ、という自信はついた
…というのは実際分からないが、まあまあ実装速度は褒めてもらえている
特に初期にこれらをやる
人間、はじめの第一印象が大事
初日、初週、初月の印象を良くすることを徹底する
最初に「この人すごい！信頼して任せられる！」って思われるか「微妙な人雇っちゃったな…。ちゃんとマネジメントしなきゃ」と思われるか。
信頼ができてから小さなミスをしても「Xさんにも珍しいことあるんだな〜」くらいで終わるが、最初にミスが続くと「こいつ大丈夫か…？」ってなりがち
初週は稼働時間外でキャッチアップを進めて「もう開発終わりました〜」「仕事早すぎないですか！？？」と印象良くするのとかやりがちだったかも
いい意味でのハッタリも大事
契約、勤怠周り
※以下「準委任契約で月120時間稼働します」みたいな契約を想定して書く。Webエンジニアでフリーランスやるならこれが一般的かなという所感
お金・契約内容周りは絶対にルーズにしない
勤怠・稼働時間報告をルーズにしない。むしろ徹底的にアピールする
ここがルーズだと、本当に一気に信頼が地に落ちる
「実際は稼働してないのに稼働したことにする」みたいやつは絶対NG
自分が採用する側のときに発生したことがある（信頼が地に落ちた）
タイムカードや日報を丁寧に書く。稼働開始時に報告する。
面倒だろうけど、信頼を得られるほうが圧倒的にメリットがあると考えている
雇用側の気持ちになったら、高い金出して雇ってるフリーランスがサボってないか、何に時間がかかってるのかを丁寧に把握したくなるのなんて当たり前
「信頼して欲しい」と思うのは勝手だが、そう思う前にまず信頼させることが大事
健全な「仕事しているアピール」は大事
これを嫌がるフリーランスは多そう。逆に、だからこそ差別化ポイントになるかも
これが嫌ならそもそも稼働時間をコミットしない方が良い。約束したことを破るのをやめようというだけなので、そもそも約束しないのならそれはそれで良い
良い仕事をした分、お金をもらうというスタンスで
良い仕事ができなかったら、極論お金はいりませんくらいの気持ち
もちろん、このスタンスで搾取されないような顧客を選ぶ。
良い仕事をしてると、良い顧客が集まる
総論（雑多に色々）
何よりも信頼感
お互い仕事をする上で、信頼しあって仕事を進めるのは本当に大事。
あえて自分本位な書き方をすると、仕事を受ける側としても信頼があれば仕事を進めやすい。何か一つ提案をするにしても、
「XXXをやろうと思うのですが、良いですか？」
「本当に必要なんですか？それの費用対効果は？客観的な指標で示してくれますか？………」
となるよりも
「XXXをやろうと思うのですが、良いですか？」
「（この人が言うなら必要なんだろうな…）いいですよ！」
となった方が楽だし、成果を出しやすい。
そして、信頼というのは細かいアクションの積み重ねなので、積み重ねを意識すると良い。
※もちろん、本当に必要なときは客観的資料をこちらから提出する前提
相手の工数を奪わない
基本的に雇用側は「忙しいから人を雇っている」のであって、人を雇うことで更に忙しくしてしまったら本末転倒。可能な限り、雇用側の忙しさを軽減してやる。
「契約さえ終わったら、あとは勝手に仕事が進んでいく」と感じてもらう状態がベスト。
相手にとって本当に必要なことをやる
開発業務を任されたとしても、アサインされた開発を言われるがままに進めることが相手のためになるとは限らない。
「この機能、本当に必要なんですか？」
「こっちの機能の開発を優先するべきではないですか？」
「本質的な課題はこっちじゃないですか？」
「そもそもの開発戦略を考え直しませんか？」
「そもそも、組織的な課題じゃないですか？」
必要に応じてこういう提案をすべきだし、提案だけじゃなくて推進にも関われると良い。相手よりも、相手のことを考えて動くべき。
とはいえ、もちろんこの実現は難しい（そもそも、上の例だと経営レイヤでの知見が必要）。
一応書いておくと、任されたタスクをやろうとせずに、口だけで批判するようなフリーランスに価値はないので注意。
フリーランスがこれをやるのは難しくもありつつも、例えば組織の中で往々にして起きがちな「現場（開発者）」vs「マネージャー」みたいな対立を、良くも悪くも外部の人間であるフリーランスという立場を生かして、両者からの信頼を得つつ、仲介をする立ち回りができるととても良い。
おわりに
ざっと書いてみた。誰かのお役に立ててれば幸いです。
この記事が気に入ったらサポートをしてみませんか？