エラー制御・ISUCONの振り返り・パスキー導入
- 07 Jan, 2025
僕は最近、竹内（@rikson_en）との車中トークを通じて、改めてエンジニアとしての姿勢や新しい技術の取り込み方について考えさせられた。 彼はアドベントカレンダーの記事執筆でTypeScriptのエラー制御に深く入り込み、さらにISUCON14にも参加し、それから仕事の一環でパスキー対応をリリースするなど、目まぐるしく動いている。 エンジニア仲間としてそれぞれの話題を聞くうちに「自分ならどう立ち回るだろう」と考える機会が増えた。
TypeScriptのエラー制御に関する記事では、リザルト型を導入してエラーハンドリングをより明示的にする手法に興味を抱いたという。 しかし、フロントエンドの場面では「ちょっとしたエラーがそこまで重大ではないケースもある」「そもそも型の複雑化にかけるコストはどうなんだろう」といった賛否があるらしい。 結果的には「しっかりエラーハンドリングが必要な領域なら、リザルト型のような仕組みを取り入れる意義が高い」という落としどころを見いだしたそうだ。 僕自身、TypeScriptで日常的に開発するときはそこまで大掛かりな仕組みを使わないが、彼のように「必要なら導入もアリ」という柔軟さも大事だと思う。
ISUCON14の話に関しては、僕も以前から興味があった。竹内はチームでNew Relicを入れ、データベースやキャッシュをいじりつつスコアアップを狙ったけれど、結果的には肝心のマッチングアルゴリズムを見直せず、思わぬ形で得点が伸び悩んでしまったという。 サービス全体の品質を向上させる発想が欠けていたという反省点は、まさに「部分最適に走りがちなエンジニアあるある」だろう。自分ももし参加するなら「ボトルネックの解消」にとらわれず、コード全体を俯瞰しながら「どうスコアに直結するか」を考えられるようにしておきたい。 彼が言っていたように、エンドポイント単体のパフォーマンスだけでなく、アルゴリズムや再起動テストの挙動もシビアに影響するというのはISUCONならではの難しさだ。
そして仕事でリリースしたパスキー対応の話は、聞いているだけで「テストケースが膨れ上がる現場の苦労」が目に浮かぶ。パスキーを“パスワードレス”としてでなく2要素認証の一部として導入し、 さらにiPhoneやAndroid、あるいは外部物理キーなど複数のパターンを考慮すると、自然にテストは増えるし、UXの設計も複雑になる。ただ、それでもパスキーを導入したのは「従来のSMS認証よりもUXを損なわずにセキュリティを高められる」からだという。 認証要素の「知識（パスワード）」「所有（端末内の秘密鍵）」「生体認証」などを組み合わせて実現する2要素認証は、確かに完成度が高い。
彼が言っていた「Windowsや別の端末にはパスキーが同期されない問題」をどう乗り越えるかも、興味深い課題だった。Apple同士ならiCloudでパスキーが共有されるが、AndroidやWindowsが絡むと途端にQRコードを使ったログインフローなどを整備する必要がある。 便利かつ安全な仕組みを追求すると、どうしても細やかな対応が必要になるわけだ。それでも一度軌道に乗ればユーザーがパスワードを覚える負荷も減り、セキュリティと利便性が両立するからこそ、今後パスキーは広まっていくのだろう。
こうして竹内と話していると、彼はいつでも「どんな技術を選ぶか」「どう実装し、どこにこだわるか」を深く考え抜いているように見える。一方で、いくら頑張っても結果が振るわなかったISUCONのエピソードからも分かるように、技術力や努力の方向性を正しく見定めることは難しい。 だからこそ、アドベントカレンダーの記事でも、パスキー対応でも、試行錯誤して学んだことを誰かに共有する姿勢が勉強になるし、僕にとっては良い刺激だ。
もし次に「愛媛チームを作ってISUCONに参戦する」となったら、僕も全力でサポートしたい。 もちろんTypeScriptで挑んでもいいし、Goが得意ならそれもアリだ。大事なのは、単にパフォーマンスを計測するだけでなく、サービス全体の品質改善につながる発想を持つこと。 それはちょうど、TypeScriptのエラー制御やパスキー導入にも共通する「どう作るか」だけでなく「何を目指すか」を見失わない姿勢だと感じる。彼から教わったことを活かしつつ、僕も新しい技術や競技に果敢に挑戦していきたい。
