필사 모드: サイドプロジェクトをキャリア資産に変える方法 — 完成基準、公開時期、振り返り

はじめに — フォルダに残った十二個の始まり

プロジェクトフォルダを開くと、だいたい似たような風景が出てきます。ログイン画面までしか作られていないアプリ、リードミーだけが立派なリポジトリ、初期コミット3つの後ろで8か月間静かなブランチ。十二個ほど始めて、公開できたのは一つか二つ。そしてこの一覧を眺めるときの気持ちは、たいてい自責です。自分には粘りがないという結論に落ち着きます。

ところが粘りというのは、たいてい誤った診断です。死んだプロジェクトを並べてみると、共通点が三つ出てきます。第一に、完成基準がありませんでした。何になったら終わりなのかを定義していない仕事は、終わりようがありません。機能はいつでももう一つ思いつきますし、コードはいつでももう少し磨けます。終わりを定義しなければ、残るのは疲れて止まることだけです。

第二に、公開時期がありませんでした。締め切りのない仕事に優先順位を与える人はいません。会社の仕事には締め切りがあってサイドプロジェクトにはないのですから、衝突するたびに押しのけられる側は最初から決まっています。第三に、振り返りがありませんでした。終わったにせよ死んだにせよ、何を学んだのかを1ページ書き残しておかなければ、半年後に残るのはコードでも経験でもなく、「あれ、途中でやめたな」というぼんやりした記憶だけです。

ここにバイアスが一つ重なります。ダニエル・カーネマンとエイモス・トベルスキーが1979年に名づけた計画錯誤です。ロジャー・ビューラー(Roger Buehler)の研究チームが1994年に行った有名な実験では、卒業論文を書いていた学生たちは平均34日ほどで終わると予測しましたが、実際には平均55日かかりました。最良の場合を仮定するよう求めたときの予測はもっと短く、正確さはもっと悪くなりました。週末で全部作れそうだという感覚は、情報ではなく症状です。

資産になるプロジェクトの三条件

すべてのサイドプロジェクトがキャリア資産になる必要はありません。純粋な楽しみでやるものは、それ自体で十分です。ただし資産として使いたいなら、条件が三つつきます。

第一に、他人が見られなければなりません。ローカルにしかないものは、存在しないのと同じです。公開されたURL、パブリックなリポジトリ、ストアのリンク、少なくともスクリーンショットのついた記事が一本。見られる状態にするコストはプロジェクト全体の5パーセント程度ですが、資産価値の半分以上がそこから出てきます。

第二に、自分の判断が現れていなければなりません。チュートリアルをそのままなぞって作った十番目のToDoアプリには、自分の決定が一つもありません。逆に「リアルタイム同期は要らないと判断してポーリングにして、代わりにこの部分で複雑さを削りました」といった痕跡が一つあるだけで、そのプロジェクトは履歴書で違って読まれます。判断は規模と無関係です。300行のツールにもトレードオフはあります。

第三に、物語として語れなければなりません。90秒で問題、選択、結果を説明できないなら、面接でも会話でも使えません。そしてこの物語は、プロジェクトが終わったあとに作るものではなく、進行中に書き留めておいたメモから出てきます。

スコープを強制的に減らす方法 — 2週間と恥ずかしいv1

スコープは自発的には減りません。構造で強制する必要があります。

最もよく効く装置は順序をひっくり返すことです。ベースキャンプがシェイプアップで整理したやり方が参考になります。普通はやりたいことを決めてそれに合わせて期間を見積もりますが、この方式では逆に使う時間を先に固定し、その中に収まるように機能を削ります。サイドプロジェクトでは2週間で公開できる大きさがよい初期値です。2週間は熱意が保たれる上限に近く、会社の仕事が一度荒れても生き延びられる下限に近い長さです。

2週間に収めようとすると、切り落とすものは明確になります。会員登録と認証(当分は自分一人で使います)、管理画面(データベースを直接見ます)、設定ページ(コードに定数で埋め込みます)、レスポンシブデザイン(v1はデスクトップのみ)、多言語対応。この一覧を先に書いておくと、削る行為が敗北ではなく計画の実行になります。

恥ずかしさについても一言必要です。リンクトインを作ったリード・ホフマン(Reid Hoffman)は、製品の最初のバージョンが恥ずかしくないなら出すのが遅すぎたのだと言いました。この言葉は品質を捨てろという意味ではなく、完成度の判断を自分の部屋でせず外でやれという意味に近いものです。一人で磨く2週間と、ユーザー3人に見せたあとの2週間は、まったく違う方向に流れていきます。

ただしこの助言にも限界はあります。決済、医療、セキュリティのように初期のミスのコストが非対称に大きい領域では、そのまま適用してはいけません。恥ずかしいv1が許されるのは、取り返しのつく決定の領域でのことです。

完成した小さいもの一つが未完成の大きいもの五つに勝つ理由

履歴書に未完成のプロジェクトを五つ書くより、完成した小さいものを一つ書くほうが強いです。理由は謙虚さや正直さといった美徳ではなく、面接で実際に交わされる質問の性格にあります。

プロジェクトについての質問は、ほぼいつもこの四つの周りを回ります。なぜこれを作ったのですか。この部分はなぜこう決めたのですか。何が予想と違いましたか。もう一度やるなら何を変えますか。四つとも、最後まで行った人にしか答えられません。未完成のプロジェクトには公開がないので、予想と違った瞬間も、振り返る結果もありません。残るのは意図だけですが、意図は検証できません。

特に三つ目の質問が分かれ道です。実際に公開した人には答える材料が余っています。ローカルでは100ミリ秒だった応答が実環境で3秒になった話、誰も使わないと思っていた機能が唯一使われた話、エラーログを残していなくて最初の障害のときに何も見えなかった話。こうした話の一つが、完璧に設計された未完成アーキテクチャの説明より信頼をつくります。

規模についての誤解も指摘しておきます。面接官が感銘を受ける地点はプロジェクトの大きさではなく、意思決定の密度です。ユーザー40人が使うツールを作りながらぶつかった本物の問題一つが、誰も使わないマイクロサービス六つより会話をはるかに遠くまで連れていきます。この観点からプロジェクトを履歴書の文に移す方法は、読まれる履歴書の回でより具体的に扱いました。

コードよりレバレッジが大きいもの — 文章と発表

同じ4時間をコードに使うこともできますし、文章に使うこともできます。驚くことに、キャリアの観点では後者の収益率のほうが高い場合がよくあります。

理由は単純です。コードは読まれるために来てもらう必要がありますが、文章は検索で発見されリンクで広がります。リポジトリ一つは訪問者が自分で判断しなければならない素材である一方、「この問題をこう解いて、これは失敗しました」と整理された文章は判断まで一緒に届けます。資産になるのは成果物ではなく、成果物についた解釈です。

学習効率の面でも根拠があります。ジョン・ネストイコ(John Nestojko)の研究チームが2014年に発表した実験では、あとで他人に教えなければならないと言われた参加者のほうが、試験を受けると言われた参加者より資料をよく覚えていました。教える前提に立つと、情報の整理の仕方そのものが変わるということです。プロジェクトをやりながら文章に整理するのは、時間を奪う副業ではなく学習の一部です。

実務的には三つの形が費用対効果に優れます。第一に、プロジェクトの振り返り記事を一本。問題、選択、失敗、もう一度やるなら。第二に、プロジェクトから切り離された狭い技術記事を一本。「ウェブソケットの再接続をこう処理しました」のようなもので、検索流入はたいていここから来ます。第三に、社内発表か小規模な勉強会で15分。発表は聴衆の規模より準備の過程が残り、スライドはそのまま次の記事の骨格になります。

そしてこの三つは互いを養います。発表が文章になり、文章が次のプロジェクトの読者を連れてきて、読者の質問が次のプロジェクトの題材になります。サイドプロジェクトが複利になる地点は、コードではなくこの循環にあります。

会社との境界線 — 契約書をまず読んでください

ここからは楽しい話ではありませんが、必ず確認すべき部分です。先に断っておくと、以下は実務上の注意点であって法律アドバイスではありません。実際に紛争の可能性があるなら、必ず専門家の助言を受けることをおすすめします。

争点はたいてい三つの軸で分かれます。勤務時間に作ったのか、会社の機材や資源を使ったのか、会社の業務と関連する内容なのか。韓国著作権法第9条は、法人等の企画のもとで業務上作成され法人名義で公表される著作物の著作者を、原則として法人と規定しています。特許の側では発明振興法上の職務発明という概念があり、会社の業務範囲に属し従業員の職務に属する発明であれば、会社に一定の権利が認められます。三つの軸すべてから遠いほど安全で、近いほどグレーゾーンが広がります。

最もよくある失敗は、法律の条文ではなく契約書から出ます。労働契約書や入社時に署名した別紙の誓約書に、知的財産の帰属、兼業禁止、競業禁止の条項が入っている場合が多く、条項の範囲が法の定めより広く書かれている場合もあります。入社時に読まずに署名した文書が何だったのかを今すぐ確認することが、この節の唯一の実行項目です。写しがなければ人事に依頼すれば済みます。依頼すること自体はまったくおかしなことではありません。

実務的な安全装置は単純です。個人のノートパソコンと個人アカウントだけで作業すること。コミット時刻が勤務時間に偏らないようにすること。会社のコードや内部データは一行も持ち出さないこと。会社の製品と競合したり代替したりする性格なら、始める前に聞くこと。そして曖昧だと思ったら、メールで短く確認を取っておくのが最も安い保険です。口頭の承認は担当者が変わると消えます。

収益化が絡むと基準がもう一段上がります。無料のオープンソースのときは問題にしなかった会社も、有料製品になると態度が変わる場合があります。兼業関連の社内規程が別に適用されることもあります。お金を受け取り始める時点は、もう一度確認すべき時点です。

持続可能なリズム — 週4時間

最後は速度ではなく持続の話です。

週4時間をおすすめします。少なく見えますが1年なら200時間で、2週間規模のプロジェクトを何度も完走するには十分です。何より、この程度なら残業のある週にも、風邪をひいた週にも生き延びます。サイドプロジェクトを殺すのは怠惰ではなく、3週間にわたって週15時間を注いだあとにやってくる反動です。詰め込みは進捗を出しますがリズムを壊し、壊れたリズムは回復に数か月かかります。

4時間の使い方も重要です。30分を八回より、2時間を二回のほうがはるかに良いです。コード作業は文脈を組み立て直すだけで20分かかるので、短い断片はほとんど準備運動で消えてしまいます。曜日と時間を固定するのも助けになります。毎回いつやるかを決める意思決定コストをなくしてくれるからです。目標ではなくシステムを設計するという原理は、目標よりシステムの回で扱ったそのままです。

そして休む区間を計画にあらかじめ入れてください。プロジェクトを一つ公開したあとの2週間は何も始めないこと。この空白は怠惰のように感じられますが、振り返りを書いて次の題材を選ぶ時間はここからしか出てきません。公開の翌日に新しいリポジトリを作る人は、たいてい三つ目のプロジェクトで止まります。

最後に、何もしたくない時期が来たなら、それはプロジェクトの問題ではないかもしれません。サイドプロジェクトは余ったエネルギーでやるものであって、ないエネルギーを絞り出してやるものではありません。会社の仕事だけですでに赤字なら、その時期に必要なのは新しいリポジトリではなく回復です。

おわりに — 2週間後にリンク1本

いまフォルダにある未完成のプロジェクトを蘇らせる必要はありません。そのうち一つを選んで、今日やることはこれだけです。v1の定義を三行で書き、公開日をカレンダーに入れ、切り落とす機能の一覧を作ること。2週間後に残るのは完璧な製品ではなく、リンク1本と振り返り1枚です。

そのリンク1本が、次のプロジェクトの読者を、次の会話の話題を、次の面接の最初の5分をつくります。複利は大きな収益から始まりません。最後まで行った小さなもの一つから始まります。