「ルーチンワーク」を創造する

最近 Backlog をよく利用するようになりました。 無料プランならプロジェクトをひとつだけ作れるので，これを使ってタスク管理をしています。 どうも私は Ticket 型のタスク管理が性に合ってるようです。

結城浩さんの「色つき星取表」もよさげですが，私の場合，「やりたい」と思ってから実際に「やる！」ってなるまで時間がかかるタイプなので，最初はやりたいことを自身に（適当に期限を付けて）投げておいて寝かせます（具体的には忘れます）。 期限が近づいたらメールが来るようにしておけば，その度に思い出すわけです。 で，その時点で先延ばしにするなら期限を延ばせばいいし，「もういいや」ってなればチケットを破棄すればOK。 本当にやらなきゃいけないものは優先順位を上げればいいし，意外にラフに使えたりします。

でも Backlog の場合，全部の機能が欲しかったらプレミアム・プランにしなきゃいけない。 他の人との協働（collaboration）でやるにしてもこの値段はキツいので，それなら 7 USD/M 払って GitHub にするか，いっそのことクラウドでサーバを立てて Redmine＋git でよくね？ ってことになると思うのですが，どうなんですかねぇ。

って，今回はそういう話じゃなくて，そうやって git 絡みのサービスで遊んでると，この記事を思い出すのです。

• ルーチンワークを創造して、一冊の本を書き上げる（本を書く心がけ）｜結城浩｜note

これは文字通り「本を書く心がけ」の記事ですが，「工程」を組むタイプの作業では一様に言えるんじゃないでしょうか。

「つまり、こういうことです。
「あれをああして、これをこうして…よし、ここまでくれば、後はいつものルーチンワークだ！」
このように「いつものルーチンワークに落とすところ」に創造性が必要になるんです。たとえは少し変ですが、大きな魚をさばいて定型のパックを作るみたい。」
（「ルーチンワークを創造して、一冊の本を書き上げる」より）

git にもルーチンワークの工程があります。 repository の生成からはじまって，clone/fork，checkout brunch，commit/push，pull request，pull/marge って感じでしょうか。 作業をこれらの工程に落としこむには各工程を貫く「プロセス」が非常に重要になってきます。 実は昔，このネタで記事を書いたことがあります。

「「逸脱がない」ことは「バグがない」こととは違います。 ソフトウェアの性質上「バグがない」プログラムを作ることは（それが大規模であればあるほど）至難の業です。 しかし「逸脱がない」プログラムを作ることは「バグがない」プログラムを作るよりもはるかに楽です。 何故なら「逸脱がない」プログラムを目指すことでエンジニアの責任範囲が有限になるからです。 顧客は「要求」に対して責任を持ち，作り手であるエンジニアたちは要求に対して「逸脱がない」ことで自らの責任を果たします。 責任を分担しているわけです。
エンジニアは自らの責任を果たすために製造に「プロセス」という概念を持ち込みました。 製造をいくつかの「工程」に分解し，工程と工程の継ぎ目（マイルストーン）ごとにチェックポイントを設けて逸脱をなくそうとします。 製造においては「プロセス」は常に改良されます。 よく「ソフトウェアは永遠にベータ版」などと言われますが，製造の現場においては「プロセス」こそが「永遠にベータ版」なのです。」
（「コーディング規約の勘所 -- 戯れ言++」より）

自画自賛で申し訳ないですが，私は「プロセスは永遠にベータ版」というフレーズがお気に入りです。 そこにこそ「創造性」が宿ると思うからです。

もうひとつ蛇足を付けるなら，「プロセスは永遠にベータ版」として改良を続けることは「未然防止」に役立ちます。 「再発防止」ではありませんよ。 「未然防止」です。 「未然防止」の概念は日本から生まれたものですが，何故か日本の企業・組織ににはあまり根付いていない感じです。 「未然防止」を理解し実行できれば「ゼロリスク信奉者」にならなくて済むんですけどねぇ。