フリーランスの報酬額の見積もり方と考え方

フリーランスの報酬額の見積もり方と考え方

フリーランスの報酬額の見積もり方と考え方

フリーランスになってかれこれ6年目。それでも毎回悩むのが仕事の報酬の見積もり。永遠のテーマ。たぶん人それぞれ考え方は違うかもしれない。あれこれ悩みたくないし交渉が苦手だからと、人月単位で単価を固定してる人とかもいると思う。以前書いた通り、自分は人月単価で仕事を受けていない。全て案件の内容に応じて報酬額を提示させていただいている。その理由も必要なら納得してもらえるまで先方に説明する。ちなみに自分の場合、最初から報酬額が決まっている案件はあんまりない。

この6年で仕事を見積もる際の考え方はだいたい出揃ってきたので、紹介してみたい。

依頼内容を詳しく聞いたら、軽く設計して実際のタスクがどのようになるか検討する。それを元に効率性・緊急性・専門性・有効性の4軸で仕事を評価する。詳しくは後で説明するとして、まずは希望的価額を自分の中にイメージするのが大切。つまり、「この仕事を自分ならいくらで引き受けたいか」をざっくり決める。

で、その希望的価額ってのは自己評価に大きく影響を受ける。その仕事をやり切る自信が全然なければ、プレッシャーや責任を避けるために低めに提示しようとしてしまう。だから成功体験を積み上げて自分に自信を付けておく必要がある。そうしなければ、勇気を出して正当と思える額を提案できない。誰よりもまず自分がその提示額に納得できる必要がある。

希望的価額が主観によるものなら、相場勘は客観的な評価額。あくまで参考程度にする。一番やってはいけないのは、会社員時代の給料を基準にすること。給料には福利厚生やオフィスの地代、仕事道具代が数字として現れていない。フリーランスはこれらを全部自分で賄う必要があるので、勘案することを忘れないようにする。

有効なのは他のフリーランスの知り合いを参考にすること。例えばとあるエキスパートなRuby on RailsエンジニアのAさんの一人月は80万円だった。でもこの数字を鵜呑みにしないで欲しい。この人はRubyだけの人じゃないから。仕事も早かった。マネージメントもできた。あくまでAさんのケースってこと。Aさんを詳しく知っている俺だけが参考にできる。

だから「相場を教えて下さい」と言われても、正直俺も知りませんとしか言いようがない。自分なりの客観的な基準があればそれでいい。正しさは問題じゃない。相場「勘」だから。

主観的・客観的な価額の基準をイメージできたら、次の4つの評価軸で提示額を検討する。

まず客観的に開発工数を見積もる。自分なら何日かかるかではなく、一般的にどれぐらいかかりそうかを想像する。例えば今まで一緒に仕事をした人たちのスピードなどを参考にする。普通は3人月かかるところを1人月で終わらせられるのなら、それは価値だ。1ヶ月で終わらせられるからといって1人月分相当しか貰わないというのはおかしい。

自分の場合はフルスタックなので、UIも担当することが多い。担当範囲は広いほど効率がいい。なぜならコミュニケーションコストがかからないから。この節約できたコストは同様に価値として考慮する。

先方から期限があらかじめ与えられたら、その緊急性を加味する。いわゆる特急料金というもの。一週間でサーバサイドを含めたAndroidアプリを作る話などが過去にあった。この場合は割増で提示する。

緊急性の高い仕事はお得感がある代わりにリスクが高い。使ったことのない技術が必要な案件は危ないので避けるべき。絶対に自分なら確実に仕留められるという確信がある時だけ受ける。

例えばWordPressのサイトコーディングなどは出来る人が沢山いるので、専門性が低いと言える。対して、推薦システムを組むとか画像認識させるとかは専門性が高い。ようは出来る人が少ない領域ほど専門的になる。自分にとってそれが簡単に出来るかどうかは関係ない。その技術を会得するために払った労力には価値があることを意識する。

この仕事は同じ要件で別々の人に作らせると、全く異なるものが出てくるから面白い。つまり人によってクオリティに違いが出る。だから要件を満たして「ただ動くモノ」は最低ラインとして考える。そこから更に「ユーザが満足するモノ」とか「話題になるモノ」とか、リリースした後に分かる効果は付加価値として評価できる。そういう力量の違いが大きく現れる案件では、自分の持つ付加価値を加味する。

自分の場合は主に「使いやすいモノ」を作るのが得意。その付加価値の裏付けは実績が全て。例えば13万人のユーザを集めたとか、お金を払ってもらえるプロダクトを作ったとか。口だけでは誰も信じない。だから日頃から実績を残すことを意識して働く。

希望的価額と相場を起点に、以上の評価軸を使って折り合いの付く額を見つける。つまり葛藤する。これぐらいは欲しい、これぐらいは貰うべき、いや取り過ぎか・・と。

検討の結果、自分は三人力だから三倍の額を提示する、というのは若干ぼったくり感がある。そこから幾分か安くしてお得感を出して、それを自分に依頼するメリットの一つとして提案すると納得してもらいやすい。大事なのはお互いが納得できる事。

ただし、相手の懐に一方的に合わせるのは良くない。取引相手だって出来れば安く抑えたいに決まってる。でも相手の顔色をうかがって安売りすると結果的にお互い不幸になる。報酬が安いとやる気が起きないし仕事も粗くなる。粗悪品を受け取って喜ぶ人はいない。予算が足りなければ、要件を削るなどして妥当な内容に修正してもらう。

この4つの評価軸は、報酬を上げていくための成長指針としても使える。もっと効率化して、臨機応変になり、スペシャリストになり、実績を積み上げる。どれかに的を絞るのも手。

あと報酬を上げる方法の飛び道具としては、カリフォルニアに行くとかもアリ。自分は物価の高いロンドンの仕事を今狙ってて、7月に営業に行く予定。英語がんばろ。

以上、参考になったらイイネしてね☺️

作ってます:

Read more

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6.0.0 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山 こんにちはTAKUYAです。 v6.0.0 の最初の Canary バージョンをリリースしました 😆✨ v6では、アプリのコア機能の改善がたくさん盛り込まれています! * リリースノート(英語): https://forum.inkdrop.app/t/inkdrop-desktop-v6-0-0-canary-1/5339 CodeMirror 6 ベースの新しいエディタ フローティングツールバー v5ではツールバーがエディタの上部に固定されており、使っていないときもスペースを占有していました。 v6では、テキストを選択したときだけ表示されるフローティングツールバーに変わりました。 GitHub Alerts 構文のサポート Alerts の構文が正しい色と左ボーダーでハイライトされるようになりました。 ネストされたアラートや引用にも対応しています。 また、アラートタイプの入力を支援する補完機能も追加されました。 スラッシュコマンド 空行で /

By Takuya Matsuyama
AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった こんにちは、TAKUYAです。日本語ではお久しぶりです。僕はInkdropというプレーンテキストのMarkdownノートアプリを、デスクトップとモバイル向けにマルチプラットフォームで提供するSaaSとして、かれこれ9年にわたり開発運営しています。 最近、その開発にClaude Codeを導入しました。エージェンティックコーディングを可能にするCLIのAIツールです。 最初の試行は失敗に終わったものの、徐々に自分のワークフローに馴染ませることができました。そして先日、アプリ開発がまた「楽しい」と感じられるようになったのです。これは予想外でした。 本稿では、自分がエージェンティック・コーディングをワークフローに取り入れた方法と、それが個人開発への視点をどう変えたかを共有します。 * 翻訳元記事(英語): Agentic coding made programming fun again 自分のアプリに技術的負債が山ほどあった ご想像のとおり、9年も続くサービスをメンテするのは本当に大変です。 初期の頃は新機能の追加も簡単で

By Takuya Matsuyama
個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ InkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR * 最初はとにかく最速でリリースする事を最優先する * 迷ったら「ときめく方」を選べ * 程よいところで切り上げて開発を進める * 使っているモジュールがdeprecatedされるなんてザラだと覚悟する * 古いから悪いとは限らない * シンプルにしていく * 老舗から継続の秘訣を学ぶ * 運ゲー要素は排除しきれない 最初はとにかく最速でリリースする事を目標に技術選定する 開発計画とビジネス計画は切っても切り離せない。 コーディングに傾倒するあまり完璧主義に陥って結局リリース出来ないまま頓挫してしまう個人開発者は多い

By Takuya Matsuyama
子育て中の個人開発者の一日

子育て中の個人開発者の一日

子育て中の個人開発者の一日 どうもTAKUYAです。 久しぶりに生活まわりの事を書きたい。自分はInkdropというMarkdownノートアプリを売って生きている。 子供も無事順調に成長しており、あと数ヶ月で3歳になるというところで、イヤイヤ期もやっと終わりが見えてきた。 生活パターンもなんとなく定着しつつあるので、ここで一旦どんなルーティンなのか書き出してみる。ちなみに当方今年で40歳。 平日の1日の流れ * 06:30 妻と子供起床、朝食 * 07:10–30 俺起床、朝食 * 07:40 布団を畳んで子供を着替えさせる。妻はその間に化粧や通勤の準備 * 08:00 ストレッチと軽い筋トレ(腕立て50回、スクワット100回) * 08:10 妻と子供を見送る。15分前後瞑想 * 08:30 散歩 * 09:00 作業開始(カフェまたは家) * 11:00 昼飯 * 12:00 ダラダラする * 12:30 作業再開(だいたい家)

By Takuya Matsuyama