/note/tech

むかし米国人の書いたコードをレビューした時のこと。データ量が少ない時は問題なくても増えてきたら必ず...

むかし米国人の書いたコードをレビューした時のこと。データ量が少ない時は問題なくても増えてきたら必ず遅くなる箇所があったので直すようにコメントした。すると相手曰く「なあ、それは今やる必要があるか?」。もちろん、今やっておかないと後で大変なことになる。「当然だ」と答えた。

@copinemickmack

すると「どれくらいの確率で問題になると思う?」と聞いてきた。まあ正直分からない。サービスが当たるかどうかなんて事前には分からない。そう答えると「そうだよな。だったら今やる必要はない。日本人てのは起きていない問題まで見つけてくるから大したものだ」。嫌味というより素直に感心している。

@copinemickmack

「心配事の大半は起きない。だったら期待値の低いことにリソースを振り向けるのは非効率だろ。もっと優先度の高い問題がある」。確かに機能面でもかなりの重大なバグが山積みになっている。非機能はどうしても後回しにされがちなのは日米共通だ。もうこうなると良し悪しというより価値観の問題だ。

@copinemickmack

結局、客とも相談してコードは直さないことになった。問題になったらまたその時対処しよう、ということになった。リリース後、心配していた性能問題は出なかった。でもその理由はサービスが当たらなかったからではなく、重大なバグが見つかって全面的に処理を作り直すことになったからだった。

@copinemickmack

日本語だと「不確実性」という一語しかないが、英語ではriskとuncertainty という言葉で区別する。riskは確率がある程度分かるもの、uncertainty はそもそも確率が分からないもの。riskの方は期待値で合理的に対処が出来るがuncertainty は扱いにくい。我々2人とも後者に翻弄されてしまったのだった。

@copinemickmack

risk管理は米国人も真面目にやる。といっても日本人みたいに全部潰すわけではなく期待値の大きものから優先度をつけて対処する。uncertainty については、ある種の諦念を持っているように見えた。「想定できないものは想定できない」という感じ。

過つは人の常、赦すは神の業。

@copinemickmack

ちなみに予測可能なriskと不可能なuncertainty の区別は、経済学者フランク・ナイトが行ったもの。これ豆な。

@copinemickmack

MEMO: