ここ数年、私は建設業のエンジニアたちと一緒に仕事をしています。50 代、60 代の方が多く、コンピュータは一番楽な道具じゃない。それでも図面、変更指示、契約書は毎日コンピュータで動かす。共有フォルダが彼らの協業の主戦場：一台の NAS、一群の人、N 個のバージョン、いつでも誰かが編集中。
制御不能な場面を何度も見てきました。設計が新しい版を事務所にメールで送る、受け取った人が NAS に保存する、現場には通知しない。現場監督がその日使っているのは先週の旧版。コンクリートはもう打ってある、寸法が違う、はつって枠を埋め直して、工期は二日延びる。誰も間違いをしていない。でも誰かが代償を払う。
私が選んだ岔路
私自身は git を流暢に使う。ソフトウェアエンジニアは皆使うし、外には有料の講座まである。問題に気づいたら commit、branch、reset、ツールは第二の手のように自然。
でも建設の親方に「git を試してみてください」と言うと、毎回戸惑った顔が返ってくる。git は彼らのために作られていない：黒い画面のターミナル、merge conflict 通知、HEAD ポインタ——どの概念も道を塞ぐ壁です。私は中間で詰まる：自分は流暢に使う、客は使えない、共有フォルダは毎週コンクリートをはつる物語を生み続ける。
彼らに git を教える方が安い。彼らが学ばなくていいツールを作る方が難しい。私は難しい方を選んだ。
私が犯した間違い（の一つ）
第一版の Keeply は機能を詰め込みすぎた。建設業も対応、デザイナーも対応、会計事務所も使うだろう、と全ケースを抱え込もうとした結果、スイスアーミーナイフになった：機能は全部あるけど、誰も気持ちよく使えない。
それから削った、また削った。
今、新機能を Keeply に入れる前に必ず 3 つの質問を通す：建設現場は本当に使うか？60 代の親方たちは開くか？削っても誰か気にするか？どれか「no」= 入れない。機能が少ないのはバグじゃなく、設計の選択です。
なぜこれを書くのか
これは 創業の原点 の話です。
Keeply はバージョン管理ツール界で git・SVN・Mercurial に勝つために作っているんじゃない。その戦いは開発者たちが二十年前に勝った。Keeply は毎日 git を開かない けれど毎日 フォルダを開く 人のためにある：建設の親方、デザイナー、弁護士、会計士、学生、フリーランス。
もしあなたがその一人なら、共有フォルダのファイルバージョン問題を読めば分かるはず：あなたはファイル整理が下手なんじゃない、ツールが整理する責任を全部あなたの記憶に押し付けているだけ。
次のバージョンで会いましょう。
著者について：Ting-Wei Tsao、Keeply 創業者。 LinkedIn
