重要なことは全て最新ブランチに反映させて、スタックを残さないようにしたい
タイトル以上のことはあんまりないんですが、プログラミングのバージョン管理とか、書きもののバージョン管理とか、日常のタスク管理とかの話です。思想の話です。
重要なことは全て最新ブランチに反映させる
ブランチというのはバージョン管理システムにおける概念なんですが、出版用語の「版」に近いものです。
僕の書いているnoteは、プログラマーを対象というよりかは、もっと広い読み手を想定しているので、あんまブランチみたいな一般化してない言葉を使うべきじゃないんですが、他に適切な言葉がなかったので、使わせていただきます。
重要なことが全て最新版に反映されている、というのはこれだけ書くと当たり前のことに見えますが、実際仕事してるとそんなに当たり前ではありません。
たとえば「これは大事なことなので、すぐに手をつけずに一度上と相談しましょう」とか、「まだ迷っているので、一旦後回しで。でも大事なので絶対忘れないようにチケットのタグに「重要」をつけました！」とか。
特に完璧主義を患っていると、不十分な状態で最新ブランチの更新をかけるのを躊躇いがちです。
かくして、多数のどうでもいいことの中に一部重大なことがスタックされる状態が発生します。
スタックが残ると何が起こるか
僕がこのスタックされた状態が好きではない一番の理由は、創造性を殺してしまうということにあります。
「さて今日何をやろう」と思ったときに、スタックされた何かが目に入ると、過去の問題に縛られることになって、新しい問題に取り組むときの足枷になります。
常に新しい何かは降ってきます。それはもう永遠に。新しいタスクが降ってくるたびに、スタックしてる何かを重要度を比較して、「よし新しいタスクの方が優先すべきだな！」と判断する。
そうやって何度も劣後されて劣後されて、何年も「課題管理表」というExcelシート上に住み着いたタスクが前職では結構な数ありました。
文章をバージョン管理してたが遡ったときはマジで一度もなかった
話はちょっと変わりますが、僕は去年ぐらいまでEvernoteの有料プランを使ってました。2年プランで支払いを2回したのは記憶しているので、最低でも4年は使っていたはずです。
僕が有料を選択した理由はいくつかありますが、その中の一つに「バージョン管理機能」がありました。
Evernoteで文章を書くと、その文章を編集途中でバージョン管理してくれる機能です。例えば2020/12/28 11:00という版を選ぶと、11:00時点の編集内容を出してくれて、もし「あ、前の内容の方が良かったな」ということがあれば、そちらを採用することもできました。
けど少なくとも僕は4年の中でこのバージョン復元をしたことが遂に一度もありませんでした。
「商業でちゃんと書いてないから」というのは一因かもしれませんが、単純に「前の内容の方が良かったな」というシチュエーションにならなかったんですよね。
なぜなら前に何書いたかなんて忘れてますし。そして、最新版の文章がそっちの表現になってるなら、書きながら、「AとBという選択肢があるけど、Aの方がいいな」と判断して書いたに決まっており、後からそれが覆るケースはそうそうありません。
仮に、推敲段階で、「あのときの判断は間違えで、Bの方が良かった」となりましょう。そのときにとるアクションは前のバージョンに遡って、Bを探すことですか？ 違いますね。Aを消して、新しくBを書きますよね。
自然言語をバージョン管理するメリットはそんなないのでは
これは自然言語（※人間の言葉）とプログラミングの違いなのかもしれません。
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiita タイトルは釣りではありません。 最近、小説の執筆にあたって Git を導入して原稿の進捗履歴を管理しました。めちゃくち qiita.com
小説家・円城塔氏『小説業界にバージョン管理の概念がないのは電子書籍のバージョン管理がなされていないことからも明らか』GitやGitHubによる小説管理が広まらない理由を議論する まとめました。 更新日:11月15日19時44分 togetter.com
たまに小説業界でもバージョン管理は話題になりますが、個人的には一人で書いてる小説ならあんまバージョン管理のメリットがないと感じています。
共同執筆してる実用書なら多少はなんか意味あるかもしれません。
プログラミング言語は書き方間違えると動きませんが、自然言語は別に動かないことはないですし、「正解」が明確に定義できません。
考え方によっては、文章というのは常に最新ブランチに重要なことが反映させている状態になっている、ともいえます。
スタックを残していないとできること
何か重要な課題が残っているシステムや、もしかしたら過去の版の方がいいことが書いてあるかもしれない小説。これはスタックが残っている状態です。
ではそうではない状態だと、どうなるでしょうか？
重要事項が全て反映されているシステム、最新版が常にベストだと言い切れる小説。
この状態にすることで、過去の問題に足を引っ張られることなく、ゼロの状態で新しい課題と向き合うことができます。
これは特に0→1で何かをつくっているときには重要なことだと思います。反対に、すでに規模が十分大きくなって、あとはその規模を維持するだけみたいなフェーズだと、なかなか難しいでしょう。
「そうは言っても過去の判断が間違っていることもあるんじゃない？」
もちろん常に100％正しい判断はできません。でもいいんです。限られた情報の中から決断して、前に進む方が、いつまでも禅問答に時間を費やして行動できないよりも結果的には有益です。
「判断が間違っていた」と気づいた時点で、軌道修正しましょう。
過去に戻って選ばれなかったプランBを選ぶ、というよりかは、今つくっている最新ブランチを新たにつくりなおす、という意識なので、軌道修正はけしてネガティブなものではなく、むしろポジティブなものです。（しなくてすむならしたくないですけどね）
2020/12に会社でやった開発では、僕は2回ほど根本的な設計変更を行いました。それは言うまでもなく最初からそうなっているべきでしたが、開発初期の11月頃だとそっちじゃない方を選択しました。
作業的にはキツかったですが、でもまあ「あのときああしとけばなあ……」みたいな思考にはなりませんでした。
なぜなら11月時点ではチーム全員がプランAの方が良いと思っており、何時間かどっちがいいか調べてからプランBを捨てていたからです。
判断した時点の情報では、プランAの方が正しいという風に見えたというのは、後から振り返っても間違えではありません。
その一ヶ月後にちゃぶ台返しみたいな、根本的な問題が発覚したので、結局はプランBが正解でした、という話なんですが、その根本的な問題は実際にやってみなければわかりませんでした。そしてわかった時点で速やかにプランBに変更しています。
ゆえに最新ブランチには常にその時々で重要なことが反映されていて、その時点での開発チームのベストが反映された状態になっていました。
やるものだけをスタックする
重要なことを全て反映する、と言っても、現実的には「これをやる！」と思ってから「やった！」となる状態までにはタイムラグがあるので、そこはスタックになります。
Githubのissueみたいな感じですね。
ただスタックして許されるのはタイムラグ的な存在だけで、実際やりもしない/やる必要もないタスクがスタックしているのは消しましょう。
いやそうは言ってもスタックした時点ではやる気満々だったのに、状況が変わって着手できなくなって、誰も代わってくれなくてそのまま積まれちゃうことも結構あるあるだと思うんですよ。
最近思うのはそういうタスクチケットの生存期間は長くて一年だなと思います。一年たってもできない/やらないタスクなんて、そもそもやらなくていいタスクなんじゃないですか？
仮にリストからそのタスクを消して、後から「ああやっぱあれ着手しておけばなあ！」となったらその時点で新しくタスク復活させればいいだけですし、そういう状況って思ってる以上に稀だと思うんですよね。
実践編
明文化したのは今回がはじめてですが、僕自身はもともとミニマリスト指向なので、近いことはやっていました。
Gmailの受信トレイは基本的に全メールアーカイブして、何かアクションとらなきゃいけないものだけ残していました。あとiPhoneの赤バッチも全部消します。通知が不要なアプリは設定からNotification切ってました。
とりあえずnoteの下書き一覧にあった昔非公開にした記事を消しました。「いつかまた公開するかも」みたいなこと考えてましたが、そのいつかは永遠に来ないし、そんなタイミングが来るような記事なら公開しとけやですし。
あとはKindleの積読が結構溜まっちゃってるので、それをこの年末年始で消化しきりたい。noteの書くネタも溜まったので、全部書きたい。常に思いつきを全部やり切った状態にしておきたい。それによって次の思いつきが浮かんだときにすぐ動けるようにしておきたい。
（了）