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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read more

ユーザサポートの問い合わせを装った攻撃が怖すぎた

ユーザサポートの問い合わせを装った攻撃が怖すぎた

どうもTAKUYAです。個人開発をしていてアプリの知名度が上がってくると、作者個人(あるいはサイト管理人)を狙った攻撃というのをたまに受けます。つい先日も、怖すぎるメールを受け取ったのでシェアします。 件名: Cookie consent prevents platform access Hello, I cannot access use the store. The cookie consent notice keeps appearing and nothing happens once I approve or try to close it, so I’m unable to interact with the website. Please provide guidance on

By Takuya Matsuyama
万年ペーパーの自分が車の運転を楽しめるようになった理由

万年ペーパーの自分が車の運転を楽しめるようになった理由

どうもTAKUYAです。大学の入学前に免許を取って以来ずっとペーパードライバーで、都市生活では出来る限り運転は避ける生活を送っていた。事故を起こせば人を◯してしまう可能性もある代物を日常的に運転するなんて考えられなかった。 そんな自分に転機が訪れたのは、結婚して大阪に戻った事と、子供ができた事、そしてアウトドアに興味を持った事だ。大阪近辺だと箕面とか野勢、神戸、丹波篠山などが日帰りでドライブしやすい距離だ。それで、恐る恐るタイムズのカーシェアで時々ではあるが運転するようになった。 他の車も生きた人間が運転しているという驚き まず運転していて気づいたのは、他の車にも生きた人間が運転していると言う点だ。そんなのは当たり前だろと思うかもしれないが、結構新鮮な発見だった。Grand Theft Autoなどの現代をモチーフにしたゲームをプレイすれば分かるが、NPCの車の動きは鈍臭いのでガンガンぶつかる。プレイヤーの進行を予測した動きなどしないからだ。 しかし現実では相手も事故りたくないので、お互いに動きを読み合い、譲り合って運転する。ルードな運転手もたまにいるものの、どちらかがよっぽ

By Takuya Matsuyama
禅的思考: なぜ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