ビッグデータとかそういう話ではないです。

チキンカウント

……って言葉があるはずなんだけど、検索しても出てこない。誰に聞いたんだっけ。「鶏は三歩歩くと忘れる」ってことわざに由来するのだけど、これ自体日本のことわざっぽいし、何かの勘違い……？

とりあえず3を超えると数えられないので、個々として扱う上限を2とする。みたいな。

他に似た言葉だと「三振制」とか使います。共通化を検討するのは三度出てきてからって言う、どちらかと言うと早すぎる共通化を押し留める言葉だけど、三度出てきたらアウトなんで共通化しないとねーと。ツーストライクまでは強振していい。と言う局面もある。ツーストライクに追い込まれる前にってのもあるので、どれも状況次第で使い分けなんだけど。

同程度の数を扱うものでDRYとかもあります。DRYは二度出てきた時点で繰り返しですが、Yourselfかどうかの識別が結構難しいので、コードの上っ面だけで語るものではないと思ったり。

量との取っ組み合い

システム開発は量と取っ組み合いです。

多くの処理対象に同様の処理を行って期待する結果を出すものを開発するのがシステム開発だと言っていいと思う。同じ条件だったら同じ結果を出すのがシステムは得意なわけだし、よく使われる文脈昔から今もこの辺のはず。違う文脈のシステムもあるけど、それは一旦横に置いておいて。

量に対して仕組みで対抗するのがシステム開発である。これは前提。前提なんですが、こと自身の仕事になった時に、なぜか量のまま対抗しようとするのをよく見ます。

なんで最初にチキンカウントに触れたかと言うと、「量が多い」の基準です。なんか10とか20くらいまで我慢して「まだ（手作業で）なんとかなる」って言うの。そう言う世界もあるんだけど、システム開発の文脈ではそうではないと思うのです。量が多いってのは二桁とか三桁とかでなく、マジカルナンバー（7±2）でもなく、チキンカウントで数えられなくなったくらい。つまり3以上を指すわけです。量が多いもので溢れてますね。

量に量で対抗するのを避ける

量のまま対抗するって表現は、量が多いのを作業量に結びつけてしまうことです。何かタスクをやる時に「数が多いので時間がかかる」と言うのが典型的。いやいや、「数が多い」と「時間がかかる」は直接は結びつかないよ？って思うんだけど、数が多いことと時間がかかることを結びつけることに当人も周囲も違和感が無いようで。

簡単な例だと、コードの出現箇所をgrepして書き直すようなもの。それも何箇所も。やったことあると思います。1箇所ずつ丁寧にやるのが量を量のまま扱ってるもので、量で対抗するには仕組みで対抗する。

例えば二度と同じ作業をせずに済むようにする。構造化と言ってもいいし、単一責任原則だとか言ってもいい、リファクタリングでの重複の排除だと言ってもいい。呼び方はここではなんでもいい。

例えば機械的に置換する。使うツールはなんでもいい。単にエディタの置換でも、何かしらのコマンドでも、ちょっとしたスクリプトを書くでも。

前者は処理対象自体を減らすアプローチ、後者は作業を減らすアプローチかな。何かしらの抽象概念を持ち込んで量を減らすわけです。

こう言うのは「あたりまえ」と思うのだけれど、案外そうでもないと言うのが私の観測範囲。類友かもしれないけど。先に挙げたような置換はやってたとしても、少しでも外れたるととたんに量（作業量、労働時間）で対抗しがちに見えるんですよね。

処理対象の量が多いものに、時間をかける作業量で対抗する方法は基本的に精度が低く、その検証も量でやってしまいがちで、往々にして漏れるものです。どこかのタイミングで量のまま扱うのをやめないと大変なことになります。大変になって、納期などの時間制約に押しつぶされて、後工程を省略したりする。量のまま扱ってたら当然ですよね……

システム開発をやってるんだから、自分たちの日常業務も対象にしていいと思うんです。医者の不養生、紺屋の白袴に並ぶことわざができる前に（もうあったりして……）なんとかしたい。どうしたらいいんだろう。

自分たちの業務の効率化を考えるのはいい練習になります。費用対効果とかも測りやすいですし、何より実践ですから何かしらのお題が与えられる例題をやるよりよっぽど身になる。例題とかだと「こうなったら正解」みたいなのがあってわかりやすいかもですが、誰も正解なんて与えてくれないことを生業にしてるんだから例題はほどほどでいいと思うんです。全くいらないとは言わない。

てことで、もしやってないなら、今すぐ自分が量に挑んでるものを別の方法で対処してみよう。きっとうまくいかない。うまくいくはずがないけれど、Fail CheapやFail Oftenを経験できるし、失敗を糧にする練習にもなるはず。仕事でも自身の裁量（時間制約など）をそれなりに見ておけば別に難しいことじゃない。

あ、仕組み化したら怒られるとかは別の話です。マクロ使ったらダメとか、そう言うのは別のアプローチが必要です。ここに記すには余白が狭すぎる。