フリーランスでリモートワークする際の考え方とコツ

フリーランスでリモートワークする際の考え方とコツ

フリーランスでリモートワークする際の考え方とコツ

IT界隈では日本でもリモートワークする人が増えてきた。働き方が増えてすごい良いと思う。かくいう自分も独立してから6年間、全てリモートワークで仕事をさせてもらっている。通勤が無い幸せ。マイペースに働ける幸せ。これからもこの生活を続けていきたい。

フリーランスだとどんな感じでリモートワークするのか、どうやって先方に理解してもらうのかとか、気になる人は多いと思う。なので自分の例を紹介してみたい。

まず働き方。自分が受けている案件は今のところ全部スタートアップ系で、主に新規サービスの立ち上げをお手伝いさせて頂いている。サービスの要件定義から関わることもあれば、開発の途中で参加することもある。そして担当範囲は全部。もしくは、独立したシステムをまるっと任されるとかが多い。UIもデザインもサーバ側も全部やる。つまり共通しているのは分担しないこと。デザイナーさんとかと一緒に仕事をした事が無い。だから日常的にメンバーとの密なやりとりが必要ない。

コミュニケーションはどうしてるかというと、まず最初の段階で直接会ったりして話を詰める。その後は放任されて、月1〜2回程度のミーティングを設ける。会う必要がなければ出来るだけ音声通話で済ませる。細かな連絡はSlackやメールで。あ、最初の進捗報告はなるべく早めにする。プロトタイプの画面のスクショを送るとか。特に、初めて付き合うクライアントを不安にさせないために早めにする。そのあとはそんなに頻繁に報告しなくても大丈夫っぽい。先方から進捗どうですかと聞かれることはほとんど無いので(信用してもらえてるなぁ・・)

コミュニケーションを減らすためにドキュメントを詳しく書くよう心がけている。どの程度書くかというと、最悪自分が抜けても誰かが引き継げる程度。これを読めば自分ならコードが読み解けるなと思えるぐらいの量と詳しさで書く。Keynoteで2,30ページ前後。ミーティングではその資料を事前に作って数日前に送って読んでもらう。だからミーティングは基本質疑応答だけ。資料に残すことで何度も説明する手間が省ける。

ところで、自分がリモートワークを好む理由はいろいろあるけど、時間で縛られたくないというのが大きい。なぜならオフィスにいる時間はその会社のために作業をするというのが暗黙の了解だから。けど、俺は自分のプロダクトを持っていて、そっちが本業。時間に縛られると本業の時間が割けなくなる。

時間で縛られないために、人月で見積もりをしない。週3日リソースを提供しますというのは、自分の安売りだと思う。自分は人より作業が数倍速い。メンバー同士の連携コストがほとんどかからないから。3人のデザイナ・エンジニアより俺一人でやった方が設計も実装も速いし一貫性が持てる。だから人月見積もりは割にあわない。

依頼内容に基いた報酬額の方が、実は双方にメリットがある。人月見積もりは仕事の遅い人に高いお金を払う計算方法だから。つまり依頼側は安く済む。こちらは早く仕事を終わらせて自分のプロダクト作りに集中できる。リモートワークを取り入れるという事は、この時間の呪縛から開放される意味もある。自分にとって不可欠な働き方。

リモートワークって信用の上で成り立っていると思う。だから、先方に信用してもらうことがとても大事。人月ではなく依頼内容ベースで契約が出来る相手なら、自分の経験上大丈夫。今働いてるかどうかではなく、アウトプット内容で判断できる人だから。そういう人は自分のことを「1人月」として見ない。過去のアウトプット実績でこいつは出来るかどうかを判断してくれる。こういう理解のある人を見つけるのも大事。

逆に言えば、アウトプットに納得してもらえないとリモートワークは成立しない。先方に喜んでもらうことがあくまで前提。納期に遅れたりとか、要件を満たしてないなんて事があると「こいつちゃんと働いてるのか?」と疑われて、信用が失われる。

リモートワークは時間を自由に使える働き方で、それは人月システムからの開放を意味する。アウトプットを重視する評価となって、仕事を速く終わらせられる人が活躍できる働き方。リモートワークのコツは、コミュニケーションコストを下げること。

参考になったらイイネしてね☆

Read more

禅的思考: なぜInkdropはMarkdown独自拡張をしないのか

禅的思考: なぜInkdropはMarkdown独自拡張をしないのか

InkdropはMarkdownのノートアプリですが、Markdownの独自拡張は「絶対にやらない」と決めていて、それがアプリの哲学になっています。 Markdown(厳密にはGitHub-flavored Markdown)の強みは、ソフトウェア業界標準で広く使われてい緩い文書フォーマットという所です。 アプリの独自記法を加えてしまったら、あなたの書いたノートはたちまちそれらと互換性がなくなります。 「独自記法を加えた方が便利な機能が付けられるだろう」と思うかもしれません。もちろん実際Markdownは完璧な書式ではないため、必要な場面はいくつかあります。例えば画像のサイズ指定方法が定まっていない、など。それでも自分は、ノートの可搬性を第一にしてきました。その裏には禅にまつわる哲学があります。 日本の文化は周りの環境と対立するのではなく、溶け込もう、馴染ませよう、共生しようとする傾向があります。窓の借景、枯山水、建築の非対称性、茶室のシンプルさ、侘び寂びなどあらゆるところで見られます。 絵画における「減筆」の手法を例にとって説明します。 これは、描線を最小限に抑えながら絹や紙の

By Takuya Matsuyama
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