勝ちに不思議の勝ちあり負けに不思議の負けなし

多くの格言は、その内部に同語反復や矛盾を内包している。アメリカンフードがあまりにドライヴミーマッドなので、友達のメッセタイトルについて考えてみるという暇つぶしに没頭することにした。
曰く、「勝ちに不思議の勝ちあり負けに不思議の負けなし。」
言いたいことは明確である。勝ちは偶然にもたらされることもあるが、負ける時には常に原因がある、勝ちを謙虚に受け止め、負けた時はきちんと原因を分析しようということだろう。名将、野村克也監督の言葉として有名（オリジナルは他の人らしいが）である。この言葉を監督から聞いた選手たちはこの言葉を重く受け止め、おそらくはチームにプラスに働いたであろうことを想像しつつも、あえて考えてみたい。勝ちとは負けの対である。こちらのチームが偶然勝ったのだとすれば、当然ながら相手のチームは偶然負けたわけで、原因があるわけではない。またこちらのチームがピッチャーの乱調によって負けたのであれば、相手にとってはピッチャーを崩したのがそのまま勝因として当てはまるだろう。勝ちは偶然、負けは必然、どうしてもこの考え方には矛盾が生じてくる。

まあこうした言葉的な疑問には目をつぶっておくことにして、「負けた時は必ず原因を分析しましょう。」実を言うと僕はこの考え方もあまり好きじゃない。僕は以前、エンジニアとして3年間ほど働いていた。自分の担当箇所でバグを出してしまうと、必ず「原因」の分析を求められた。仕様に関する無知、言語に対する無知、他実装者との意識合わせの欠落、原因は様々である。しかし、バグを作らないプログラマというのは存在しない。どんなに優れた人がプログラムを作成しても、バグを作り込む率が0に近づくだけであって、完全には信頼できないからこそ、その後の工程において入念なテストが行われる。
どんなに詳細な仕様書を書いても、どんなに言語知識について詳しい人を用意しても、どんなに優秀なフレームワークを用いても、バグというのは必ず作られるのだ。だからこそ、実装者のスキルを評価するための基準として、バグ指標値というものがある。
バグ0は無理だけど、○○行あたり、バグを○○個以内に抑えましょう、というような指標値だ。実装者が、これを超えるくらいバグを作り込んでしまうなら、何か問題があるはず、原因を追究すべきという考え方は妥当だ。しかし、実装者のどうしようもないケアレスミスというのは、どうやっても（半ば偶発的に）発生する。そして毎回これに原因を求めて、ケアレスミスのないように次から詳細設計書に○○を記述するようにする〜などと対策を立てていったら、余計な作業を増やすことになり、生産性を下げることになる。
日本が残業大国として名を馳せているのは、その一因として生産性の低さがあって、これをなんとかしない限りはワークライフバランスの改善は難しい。中国人に開発をやらせると、こいつら適当すぎだろｗと思うことも何度かあったけども、日本人の完璧主義っぷりは、それ以上に病的であるように思えている。「失敗」も偶発的に発生する事象であって、そのことへの自覚というのも割と重要だ。バッターが、ハエを追い払おうとして振ったバットにボールが当たり、たまたまホームランになったのをピッチャー側から考察しても仕方ないじゃないか。

僕にとって、ハンターハンターでヒソカがトランプを積み上げたり壊したりして遊んでるシーンは印象的だ。人生ってあんな感じ。
広大な人生というフィールドで、トランプを積み上げて高さを競ってみたり、ある人は接着剤を作って楽をしていたり。
そのうち接着剤は汚い、ずるいという人があらわれて、純粋にトランプを積み上げている人が偉いんだ、というような価値観が生まれてきたり。僕も暇だったから、他人の作ったトランプタワーを蹴っ飛ばしてみた。ラーメン食った時ほどの快感じゃないね、これは。何にせよ、世の中に頭痛薬（ナロンエース）があって良かった、そう思った一日だった。