高単価案件で働くための心構え

2025年11月13日(木) Findy Freelance Meetup in Autumn

1. 高単価案件で働くための 心構え 合同会社N-Works代表 成澤 克麻 2025年11月13日(木) Findy Freelance Meetup in Autumn
2. 自己紹介 成澤克麻 合同会社N-Works代表、SALESCORE株式会社CTO 経歴：東北大学 → DeNA → スタートアップ → フリー ランス → 現在 単価：フリーランスの時は⚪︎⚪︎⚪︎⚪︎⚪︎円〜/時が目安 正社員 → フリーランスになって、単価は⚪︎倍に クライアント：シード〜シリーズCのスタートアップ がメイン（フリーランス時） 2/39
3. 前提 あくまで「自分の心構え」を話します 「世の中のフリーランスWebエンジニアのあるべき姿」 「これをやれば誰でも高単価 を実現できる方法！」etc...ではありません 考えを押し付けようとしているわけではない旨、重々にご承知ください！ …という前置きのもと、自分なりの「当たり前」のスタンスを 「これくらい当たり前だよね〜」というスタンスで話します！ ご了承を！ 3/39
4. イチローの言葉 記者「なぜそこまで自己管理を徹底できるのか？」 4/39
5. イチローの言葉 記者「なぜそこまで自己管理を徹底できるのか？」 イチロー「僕、いくら貰ってると思いますか？」 → 報酬に対する高い責任感 5/39
6. 報酬に対して責任感を持つ 高い報酬をもらっているのであれば、高い次元の仕事をして 「当たり前」 高い報酬をもらっておいて、顧客が満足しないなんてありえない （特に初期の頃は）毎日高すぎる単価に震えながら仕事をしていた 仕事中にスマホ見てダラダラ仕事etc...なんて絶対に考えられない 顧客の不満になりそうなことは全て潰す、満足してもらうのに必死 そういう仕事スタンス/スキルが「当たり前」になった 今日は自分の「当たり前」のスタンスについて話します 6/39
7. 「当たり前」の水準をあげるのは難しい？ 技術スキルをあげるのは、もちろん大変（時間をかける必要がある） スタンス面は、「当たり前」だと思えれば、当たり前にできる （というのは、もちろん言い過ぎではあるものの、まあこういう場なので一旦） 「当たり前」だと思い込むには？ → 周囲の環境が大事 （例）学生時代の部活の朝練は、大変だが「当たり前」だったので実行できてい た（今、自分一人の気力だけでやるのは難しい） 今日の話が「当たり前」の意識を変えることに繋がれば嬉しいです！ 7/39
8. （補足） 今日の話はだいたいこちらのnote記事で書いてる話です！読んでない方ぜひお読みくだ さい！ （読んだ方、重複ですみません！＋αをお伝えしていきます！） 8/39
9. アジェンダ - 高単価案件で働くための心構え 1. 自己紹介 / 前置き 2. コミュニケーション 3. キャッチアップ 4. 開発 5. 契約・勤怠の基本 6. 総論 / まとめ 7. Q&A 9/39
10. コミュニケーション 10/39
11. 即レスは基本 ※1つの案件で、開発者として携わるような文脈を想定 稼働時間中のメンションはだいたい即レス もちろん可能な範囲で。最低限、マークつけるとか 即レスは評判がいいので、自分の中での優先順位は高い。円滑なコミュニケーシ ョンは大事 1つの開発タスクに集中させてもらっているフリーランスなら、メンションに即レ スは普通にできるのでは 稼働時間外でも、可能な限りの返信 「映画見てる最中」 「友人と一緒にいる時」とかは返さなくていいと思う。それ以 外の時間は、自分は返信できる時なら返信する 11/39
12. 情報共有 相手が知りたい情報を、事前にこちらが提供する 相手に質問させている＝相手の思考コストを奪っている 自分についての情報を、積極的に共有する 自分のスキルについて、いま何に困っているか、稼働時間中に何をしたか、何に どれだけ時間がかかったかetc 良い相互理解の第一歩は、お互いの情報の共有から 自分が優秀だなと感じる人は、これが丁寧な人が多い 12/39
13. 出社 基本出社多めにする 出社してコミュニケーションした方が円滑に進めやすい 出社を嫌がる人が多そうだけど、その分良いサービスが作れて、そして高い報酬 をもらえるなら、自分はこれくらいはする そもそも都心アクセス良いところに住んでいる、オフィス遠いところの案件をそ もそも受けない、出社が苦じゃない性格というのはある （2025年のアップデート）アフターコロナの世の中で、リモートが許されやすい環 境にはなっている？ けど、やはり出社した方が、信頼を得やすい気がする 13/39
14. 敬意を払う 既存のソースコード・チーム・組織・仕組みetc…に敬意を払う 残念なソースコードがいっぱいな現場もあるが、それに対してネガティブな意見 を喚き散らかしても、そのコードでやってきた周りのメンバーが嫌な気持ちにな るし、チーム間の信頼がないと結局いいサービスは作れない。ここまで事業を作 ってきた既存の仕組みに敬意を払う 例え正論でも、正論を振りかざすのはダメ まずは郷に入っては郷に従いつつ、周囲の信頼を獲得してから、 「良いサービスを 作るために」という共通認識をもって、現場を変えていけると良い とはいえ、外からやってきたフリーランスには新しい風を期待されることもある ので、合意があれば一刀両断に既存の風土を切り捨てるのもあり。その際は責任 をもって推進 14/39
15. キャッチアップ 15/39
16. 情報は自分から積極的に収集 自分で調べられることは自分で調べる 会社情報とか、サービス情報とか、公開情報は全て眼を通す 社内ドキュメントは、自分に関連しそうな範囲は全て眼を通す 自社サービスを触れる環境があれば、とことん触り倒す 直近のPRレビューに目を通して、開発ルールや直近の開発内容を把握する この辺は初日・初週に済ませる 開発タスクをアサインされたときに、リードエンジニアのブリーフィングなしに 「〜〜が〜〜になってる問題ですね。気になってました。やっときます！」を常 に言えるようになりたい 16/39
17. 開発関連のキャッチアップ コードベースは「テーブル定義」 「ルーティング」 「使ってるライブラリ」 「フォルダ 構造」 「インフラ設計」くらいは一通り最初に見る これ見て理解すれば、サービスの全体像は大体分かるはず （完璧に全部を暗記する必要はないが、ざっくり掴んでおくべき。概要すら理解 できてないと、LEとしては厳しい） 未知のライブラリを使ってたら、自分でキャッチアップしましょう！ 17/39
18. キャッチアップの流儀 不明点は気軽に質問する 不明なことを無理に調べようとして工数を使うのは無駄な時間。調査の時間にも 報酬が発生してしまっていることを意識する 気軽に質問しつつ、どこまで回答してもらうかは相手に委ねる 自分がどういうことに疑問を持っているのか？を相手に共有しておく。相互認識 を作る 自分が担当した範囲について開発ドキュメントがなかったら、自分でドキュメントを 作る 後続のエンジニアの開発効率も考える ドキュメント書いてる間に、自分もドメイン知識が整理される 18/39
19. その他 - Slack #times-<自分> 相当を作って、そこに思考を垂れ流すのが好き 健全な「頑張ってるアピール」にもなる 自分自身の客観視にもなる（この仕事っぷりで、時給N万でいいんだろうか…？） Slackで自分が入ってるチャンネルはだいたい全部目を通しがち。定期的に未読をク リアしがち（これはやりすぎな自覚） 19/39
20. 開発 20/39
21. PRレビューのスタンス PRレビューで、一切指摘されずにマージされる 指摘がある＝レビュワーの工数を奪っている レビューさせている＝レビュワーの工数を奪っている 本来はレビューなしでもOK、くらいなコード品質が理想 自分の契約中は、多分ほぼ指摘はなかったはず PRレビューで、一切質問されずにマージされる 質問がある＝レビュワーに疑問を持たせている＝思考コストをかけさせている 質問になりそうな点を、事前にPRコメントに書いておく 21/39
22. PR 一切不具合を出さないこと 不具合出さないのは当然 レビューしてくれるLEに「この人の書くコードは不具合があるかも……ちゃんと 見なきゃ…」と思わせるのは、だいぶコストかけさせているので避ける 自分の契約中は、多分ほぼ不具合は出さなかったはず？（少なくとも大きな不具 合はゼロ） 仕様を考え抜くこと 「リリースしてから仕様漏れが発覚したけど、自分は言われた通りに作っただけ なので知りません」はNG 実装者が一番仕様に詳しく、またユーザーの気持ちに詳しくなれていると良い。 また、ユーザーの生の声を聞けていると良い（この辺はサービスによりけり） 22/39
23. 短い時間で丁寧に 以上を、高速に行う 「時間をかけて丁寧に」ではなく「短い時間で丁寧に」 自分の力を誇示するのは苦手なので、あんまり大きいこと言いたくはないが、フリー ランスで渡り歩いてみて、平均的なエンジニア(??)の5倍速くらい(???)は出せている かなあ、という自信はついた …というのは実際分からないが、まあまあ実装速度は褒めてもらえている 23/39
24. 特に初期が大事！！ 人間、はじめの第一印象が大事 初日、初週、初月の印象を良くすることを徹底する 最初に「この人すごい！信頼して任せられる！」って思われるか「微妙な人雇っちゃ ったな…。ちゃんとマネジメントしなきゃ」と思われるか。 信頼ができてから小さなミスをしても「Xさんにも珍しいことあるんだな〜」くらい で終わるが、最初にミスが続くと「こいつ大丈夫か…？」ってなりがち 初週は稼働時間外でキャッチアップを進めて「もう開発終わりました〜」 「仕事早す ぎないですか！？？」と印象良くするのとかやりがちだったかも 24/39
25. 他の開発TIPS 普通の開発の話しかなさそう…？聞きたい話あったらぜひお声がけを！以下例 セルフレビューしよう！！！！！！！！ as any やめようね！！！！！（TypeScript） スケジューリング、見積もり、期待値調整は大事 オーナーシップ持ちましょう！！ リーダブルコード、関数型プログラミング、コードリーディングetc…、当たり前に こなしましょう！ AI開発の話とか？ 25/39
26. 契約・勤怠 26/39
27. 契約・勤怠 ※以下「準委任契約で月120時間稼働します」みたいな契約を想定して書く。Webエン ジニアでフリーランスやるならこれが一般的かなという所感 お金・契約内容周りは絶対にルーズにしない 勤怠・稼働時間報告をルーズにしない。むしろ徹底的にアピールする 「実際は稼働してないのに稼働したことにする」みたいやつは絶対NG 自分が採用する側のときに発生したことがある タイムカードや日報を丁寧に書く。稼働開始時に報告する。 雇用側の気持ちになったら、高い金出して雇ってるフリーランスがサボってない か、何に時間がかかってるのかを丁寧に把握したくなるのなんて当たり前 「信頼して欲しい」と思うのは勝手だが、そう思う前にまず信頼させることが大事 27/39
28. 契約・勤怠 - 2 健全な「仕事しているアピール」は大事 これを嫌がるフリーランスは多そう。逆に、だからこそ差別化ポイントになるか も これが嫌ならそもそも稼働時間をコミットしない方が良い。約束したことを破るのを やめようというだけなので、そもそも約束しないのならそれはそれで良い 良い仕事をした分、お金をもらうというスタンスで 良い仕事ができなかったら、極論お金はいりませんくらいの気持ち もちろん、このスタンスで搾取されないような顧客を選ぶ。 良い仕事をしてると、良い顧客が集まる 28/39
29. 総論 29/39
30. 何よりも「信頼感」 お互い仕事をする上で、信頼しあって仕事を進めるのは本当に大事。 あえて自分本位な書き方をすると、仕事を受ける側としても信頼があれば仕事を進めや すい。何か一つ提案をするにしても、 となった方が楽だし、成果を出しやすい。 「XXXをやろうと思うのですが、良いですか？」 「 （この人が言うなら必要なんだろうな…）いいですよ！」 30/39
31. 相手の工数を奪わない 基本的に雇用側は忙しいから人を雇っているのであって、人を雇うことで更に忙しくし てしまったら本末転倒。可能な限り、雇用側の忙しさを軽減してやる。 「契約さえ終わったら、あとは勝手に仕事が進んでいく」と感じてもらう状態がベス ト。 31/39
32. 本質に向き合う 開発業務を任されたとしても、アサインされた開発を言われるがままに進めることが相 手のためになるとは限らない。 「この機能、本当に必要なんですか？」 「こっちの機能の開発を優先するべきではないですか？」 「本質的な課題はこっちじゃないですか？」 「そもそもの開発戦略を考え直しませんか？」 「そもそも、組織的な課題じゃないですか？」 必要に応じてこういう提案をすべきだし、提案だけじゃなくて推進にも関われると良 い。相手よりも、相手のことを考えて動くべき。 32/39
33. 発注者側になってみて 現在はフリーランスをやめてスタートアップCTO、開発会社代表をやっている 発注者目線で、ここに書いてあることをやってくれる人は、本当にありがたいし信頼 できる 弊社だと、契約前後で目線合わせを必ずします 「100%守ってくれ」とは絶対に言わない（言えない） 、求めない 「こんなの絶対に無理だ！！！」と言われると、一緒に働くのは厳しい 結果を出してくれる人に対しては、正直諸々を求めないし、結果が怪しい人には、せ めて信頼関係を求めたい 毎日何やってるか分からない働き方で、アウトプットも微妙だとちょっと… 33/39
34. その他 過去の仕事での信頼が今の仕事に繋がっている件 結局、一緒に働いてみないと、お互いのレベル感は分からない 良いところで働いて、良い評価を受けるのを、いろんな場所で繰り返して、良い 仕事をさらにもらう 短期的に、単価ふっかけて稼ぐような方式は、焼畑農業的 34/39
35. N-Worksの紹介 35/39
36. Q. なぜ起業したか？ A. 個人のフリーランスでは受注しづらい大型案件に参画するため 36/39
37. 創業のストーリー SIer系案件（1億円規模）の開発内容を見せてもらったら、自分一人で1ヶ月で終わり そうな内容だった 諸々の事情は理解しつつも、とはいえ高すぎる、無駄が多いと思った これが日本全国の様々な場所で行われていることを考えれば、社会的な課題 一方で、周りの優秀な仲間が、各種の事情（アピールが苦手、家庭の関係）で、 （自 分から見た時に）妥当な給与・報酬をもらっていなかった 大型案件を優秀な仲間と一緒に手がけ、十分な報酬を得つつ、社会をより良くしてい きたい → 起業 37/39
38. N-Worksについて Mission: 優秀なソフトウェアエンジニアが、大きな社 会課題に取り組み、幸せな社会を実現する 良いメンバーで、みんなで楽しくたくさん稼ぐがコン セプト 楽しく：技術レベル、スタンスともに良いメンバ ーでslackでわいわい 稼ぐ：SIer系案件で開発し、高水準な報酬 38/39
39. Q&Aコーナー なんでも質問受け付けます！ 39/39