こんにちは、フリーランス個人アプリ作家のTAKUYAと申します。 現在僕は独りで作ったノートアプリ「Inkdrop」で生計を立てています。 しかしその生活は、リモートワークという働き方がなければ実現しえませんでした。 リモートワークがあったおかげで面白い企業さんと一緒に働くことができたし、個人開発で得た知見を彼らに提供できました。さらに、個人開発にも充分な時間を割けるようになり、そこで得た知見を受託案件に還元することで、さまざまなお仕事の依頼をいただけるように。こうした仕事の好循環を経て、最終的には自分で開発したアプリ一本で生計が立てられるようになりました。
このように個人開発と受託案件の間で相乗効果が得られたのは、リモートワークの存在が大きいです。 本稿では、リモートワークがもたらしたこの好循環の仕組みと、その効果をより高めるための戦略についてお話したいと思います。
まず最初に個人開発に取り組んだ理由とその効用について説明します。
自分の開発したアプリでマネタイズに成功するまでは、フリーランスとして受託案件をこなして生活費を稼いでいました。自分のプロジェクトである個人開発に打ち込んでいる時間は当然報酬が出ません。 それは受託専業でやられている方からすれば損失でしかなく、大きなリスクを取っていることになるでしょう。 そこまでして個人開発に打ち込むのは、単に「好き」では収まらない情熱やこだわりがあるからです。情熱やこだわりを持って自分自身で何かを発起し、形にして提供するまでの過程で得られる知見は山ほどあります。
僕の場合は、アプリの企画からデザイン、開発、集客やユーザサポートまですべて自分でやります。 そうすると、さまざまな観点を持ってプロダクトに取り組む力が身に付きます。 また、個人開発では誰も止める人がいませんから、思う存分にこだわりを注ぎ込めますし、新しい技術や手法にも遠慮なくチャレンジできます。すると思いもよらぬ発見があったり、自分の適性や才能に気付いたりします。
個人開発者を人材として見たとき、一緒に働きたいと思う企業の方も多くいらっしゃるのではないでしょうか。 彼らは単に言われたことをやるのではなく、自分で立案して物事を推し進めていく力があります。 ただ自発性があるだけでなく、「もっとこうすればいいのに」という思いを個人プロジェクトにぶつけて、失敗と成功を積み上げています。 言い換えると、企業の担当者の代わりに先に冒険して経験を積み重ねている訳です。 その知見は、場合によってはとても貴重なものです。
制作したMarkdownノートアプリ「Inkdrop」。英語で公開し、国外の人からも使われている
僕はフリーランスとして独立する前から個人でアプリを作っていました。 独立して最初にいただいた受託の仕事は、そのアプリの出来栄えを認めてくださった方からの依頼でした。 それ以降も全てのお仕事は、僕の作品がきっかけで頂きました。 しかも、どれも僕の興味と合致しているお仕事でした。
企業は個人開発者の制作物を見ることによって、欲しい能力とそれを裏付ける実績が確認できます。 アプリ制作は写真や音楽のそれと同じで、作者の内面や嗜好・メッセージ性が強く反映されるものです。 僕に声をかけてくださった方々は、そこに何らかのシンパシーを感じてくださったのだと思います。 例えばiOSアプリでアニメーションに凝っていたら、「このアニメーションすごいね。ウチでもやりたいんだよ」と声をかけられたことがあります。またある時は、音楽推薦アプリを作ったところ、推薦アルゴリズムに着目した企業さんからお誘いを受けました。 すなわち、個人開発の成果物は最高の営業材料という訳です。
これは個人開発がもたらす素晴らしい恩恵です。 成果物が、自分と相性の良い企業さんを引き寄せてきてくれます。 興味を持って取り組めるのでよりよい成果物をアウトプットでき、なおかつ先方にも満足していただけます。win-winですね。
以上のように、個人開発のプロジェクトを持ちながら受託案件もこなすことは本人と雇い手の双方にメリットがあります。 しかし、個人開発には多大な時間と労力が求められるので、なかなか両方をこなすのは基本的に難しいでしょう。「個人開発」と「受託案件」にかけられる時間は明確に切り分けできず、いつでも臨機応変に対応できるような働き方が不可欠だからです。 もし会社に常駐する契約しか許されない場合、受託案件をしている間は強制的に個人プロジェクトから引き離されることになってしまいます。
例えばアプリを作り、ひとたび一定の認知を得てユーザを抱えると、簡単には手が放せなくなります。 iOSに新バージョンが出たら、それにいち早くキャッチアップする必要もあります。 サーバで問題が起きたら早急に対応したり、ユーザへのサポートも怠ってはなりません。 新機能の追加など、やりたいことは常に山積みです。 僕の場合、通勤している暇があったらコードを一行でも多く書きたいと思っているぐらいです。
作業環境へのこだわりも影響します。 僕は家で歌いながらコードを書くのが好きです。 人の目を気にして黙々と作業するように強いられると、パフォーマンスがうまく発揮できません。 しかも根っからの神経質で、すべてを遮断して誰もいない空間を好みます。
でもリモートワークなら、個人開発を継続しつつ、いつもの環境で仕事ができます。 「ワガママなやつだな」と思われたかもしれません。 でもせっかく僕の成果物を見込んで依頼してくださったのに、働き方の制約のせいでそのパフォーマンスが存分に発揮できないのは本末転倒ですよね。 リモートワークはよく子育てなどの家庭の事情や地方居住の支援として提供されています。 それなら、個人開発の支援やパフォーマンス向上のためにリモートワークが検討されてもいいはずです。
言ってみれば、僕のような社会不適合性を持ち合わせる人間でも、その能力を活かせるのがリモートワークという働き方です。では、そのリモートワークの受託案件を、具体的にどのように獲得してこなせばよいでしょうか。以降では、僕が実践した戦略についてご紹介します。
ありがたいことに、僕の取引先はどの会社もリモートワークを全面的に受け入れてくれました。 なぜ彼らはそんなにも僕に寛容的だったのでしょうか。 企業側からすれば、初めての取引にもかかわらずいきなりリモートで仕事をしようなんて、結構勇気がいる事だと思います。 そこには、やはり実績ベースでの信用が前もってあったから認めてもらえたのでしょう。
そしてもう1つ重要なのは、依頼主が自分に何を期待しているのかを明確に意識して相談に乗ることです。
例えば、自分の受ける案件は新規開発が多いのですが、依頼主の作りたい完成イメージは基本的に曖昧です。 やってみなければ分からない要素が入っているからです。 そして彼らが僕に期待しているのは、その曖昧だったイメージをいい感じに具現化することです。 そのために、実際に動くものをサッと作って見せたり 、場合によっては契約前の相談の段階で軽いモックアップを実装したりします。 実際に見て触れられるモノがあると、相手のイメージが広がると同時に、仕事に対する信用の裏付けにもなり説得力が格段に上がります。 こうやって、自分がいかに相手のイメージを具体化できるかをアピールしています。
契約前に手を動かして具体的なイメージを提示するのは、あまり一般的ではないかもしれません。 契約に至らなければ、作ったものがムダになる可能性もあります。 でもリフォームや戸建ての業界では、契約前に模型作成して具体化しお客さんとイメージを共有する、と聞きます。彼らは一つひとつの取引額が大きいので、契約前の提案にコストをかけます。 ちゃんとした設計図や完成イメージを描くことで、結果的に成約率が上がるのでしょう。
つまり、「リモートワークでもちゃんとやってくれそうだな」と思ってもらうために、相談の段階から無駄骨になってしまうリスクを許容してアプローチしています。
個人開発者の方々は「JavaScriptだけ書ける」といった人よりも、マルチスキルで何でもこなす人が多いように思います。 もとい、そうしなければ1人でサービスは作れません。 例えば、僕はバックエンドからフロントエンド、デザインまで一貫して担当できます。 そうすると、デザインはAさん、フロントエンドはBさん、バックエンドはCさんと別々に雇った場合よりも遥かに効率よく開発できます。 なぜなら担当者間のコミュニケーションコストがゼロになるからです。
このようなスキルセットを持っている場合、人月や工数ベースの時給制は向きません。 時給制は仕事の速い人が損をする可能性がある制度です。 なので必ず成果物ベースで見積もりを行い契約しています。
また、成果物ベースの契約はリモートワークと相性が良いです。 リモートワークは場所の制約から開放してくれます。 成果物ベースなら、更に時間の制約からも開放されます。 この組み合わせは、個人開発と受託開発を両立する最高の働き方だと思います。
リモートワーク＋成果物ベースの契約で作業を進めるにあたっては、依頼主の以下の不安を取り除くことが重要です。
この2点の不安を取り除くには、できるだけこまめな進捗報告とフィードバックのサイクルを回すのが効果的です。 自分の場合は、常に相手の手元で動く形でモノを確認できるようにします。 例えばサーバを用意してデプロイしたり、iOSならTestFlight（iOSアプリのテスト配信をサポートしてくれるサービス）で配信したり。 何か変更を加えたら、できるだけこまめにアップデートして確認してもらいます。
すると、依頼主は常にモノを見ながら状況を把握できる上に、気になる点をすぐフィードバックできます。 僕は契約前に作ったモックアップを土台にして作ることが多いので、初期の段階からすぐにこのサイクルを回せます。 スクリーンショットを見せたりソースコードを共有するのも良いですが、やはり動くモノが最も効果的です。 なぜなら、とりわけ新規開発では依頼主と開発者との完成イメージの齟齬を防ぐ必要があるからです。 実際に実装してみて出てきた課題やアイデアも、その都度相談しながら進めていけます。
2016年にかかわったインバウンド向けモード雑誌のアプリ版。この案件は契約前にモックアップを作り、デモを見せてから進めていった
上記のように小まめなフィードバックのサイクルを回していれば、基本的なコミュニケーションは事足ります。 それでも伝えきれない部分については、ミーティングを設けて説明します。 ミーティングは時間を無駄にしないためにも、回数は月1ぐらいで必要最低限にしています。 また、資料を1週間前にアップして事前に目を通してもらい（見てもらえないこともありますが……）、実際の対話では資料の疑問点を潰すだけにしています。
このように、ミーティングは資料を中心に行います。 その利点はミーティングの時間を短縮するだけではありません。 よく書けたドキュメントは、無駄な質疑応答や引き継ぎ作業を軽減してくれます。 更に、もし自分が担当を離れた後でも読み返して活用できます。 ドキュメントをしっかり書ける人は意外と少ないので、後になって「この人に依頼して良かったな」と思ってもらえることも期待できます。 それが次の仕事の契約や紹介につながる確率を高めてくれます。
親しい知人に「お前はエンジニアではない。アーティストだ」と言われたことがあります。 確かに一理あると思います。 アーティストを人材として見たときの最も大きな問題点は、彼らを単純に規格化できないことです。会社（特に大企業）は、組織を効率的に回すために社員を規格化する必要があります。すると、逆にその規格に当てはまらない人材は雇用しづらくなってしまいます。
個人開発でユニークな能力や知見を備えた人材は、単に「エンジニア」や「デザイナー」という技能規格には収まりません。 僕はそれを誇りに思うと同時に、会社が求める規定された社員像に適応できず苦しんでいました。しかしフリーランスになり、リモートワークで企業とコラボレーションすることで、自分に合った働き方の道が開かれました。 会社組織は人材を規格化することで効率化していますが、逆に新しい技能や特殊な領域をカバーするのが難しい仕組みでもあります。 どうやら、それは一部のIT企業の経営者も認識している問題のようです。 変化の激しいIT業界の中で、企業がカバーしきれない新しい領域に、個人開発で率先してチャレンジして知見を積んでおく。そうすることで、企業の人材ニーズに運良くハマり、なおかつリモートワークをうまく活用することで満足する働き方ができたのかな、と思っています。
この記事が独立して自分のプロダクトで生計を立てたいと考えている方、もしくはそういった個人開発者と働きたいと考えている企業の方に、参考になればうれしいです。
編集：はてな編集部