3D Secure unofficial ambassadorの@ohbaryeです。
このたび、3Dセキュアの歌こと"All You Need Is 3D-Secure"のRemix versionを公開しました。
原曲を作った2022年10月は、主要なクレジットカードブランドが3Dセキュア1.0のサポートを終了した年であり、2.0への移行が大きな話題となっておりました。
今年2025年はといえば、3月末に日本でも加盟店での導入が原則として義務化されており、普及は加速していると思われます。
未だに実態は深く知られていない3Dセキュアのミステリアスさを醸しつつも、普及の喜ばしき趨勢をアンセミックに表現した楽曲が本作品となります。
3Dセキュアの更なる発展を祈っております。
トークの正式タイトルは「5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム」。副題つきのタイトルは長くてブログタイトルとしては不利ですね。
Kaigi on Rails 2025は2021年から5年連続でスピーカーとしての参加になりました。
発表に用いたスライドは以下。
主張は概ね以下の2枚にまとまっています。
今回もまたこれまでやったことないアプローチに挑戦してみました*1。やり遂げた1つの課題を深掘りするのではなく、派手さはないが見逃されがちな一見小粒なノウハウや工夫を"編纂"することで大きなストーリーとして提示するというアプローチ。
たとえば運用パートで話した個々の取り組みはどれも大事だと思っているけどカンファレンスに単体で持っていくには強度が足りない。けれどもそれぞれが大きなストーリーの一部であるということを意識し、隣接する取り組みと並べることで意味が浮き彫りになる。そういう効果を生み出すような編纂をしてみました。*2
独立していた表現が、より大きな全体の一部となると、性格が変わる。見え方も違ってくる。前後にどういうものが並んでいるかによっても感じが大きく変わる。 (中略) 〝知のエディターシップ〟、言いかえると、頭の中のカクテルを作るには、自分自身がどれくらい独創的であるかはさして問題ではない。もっている知識をいかなる組み合わせで、どういう順序に並べるかが緊要事となるのである。
外山滋比古. 新版 思考の整理学 (ちくま文庫) (Japanese Edition) (pp. 40, 41-42).
発表時にXで実況的に感想をくださった方、発表後に話しかけていただいた皆さんありがとうございました。大変励みになります。
多かったのがSentryなどのエラートラッキングツールの運用の困りごとで、各社苦戦されているようですね。わかる......
とりわけ何度も質問されたのが「どうやって運用を改善する時間を捻出しているのか」という点でした。
今回話した運用面に関わる株式会社スマートバンクのサーバーサイドエンジニアは20名弱であり、基本的には事業を伸ばすための開発が優先で、運用専門のチームがあるわけではないです。つまり運用は全員が関わる横断的なテーマであり、こうした横断的課題にどう取り組むのか？という問いに今期は委員会制度という構造を作って対処しています。
この委員会のいくつかがシステムの運用に関して優先的に対処すべき課題を特定し、上期（2025年4-9月）にカタをつけてくれました。個人技で片付けられる課題もあればそうでない課題もあり、こうしたタスクフォースがあるおかげでうまくいった面は多分にあります。
もちろん細かいものを片付けたり個人の思いつきでガッと前に進めている出来事もたくさんあります。一気にお掃除するよりも日々tidyしていくことのほうが大事だったりもします。
こうした話も織り込みたかったのですが時間の都合上で触れられなかったためこの場で補足させてもらいました。
どうやったらわかりやすく伝わるかだけでなく、時間・場所が離れても資料としての価値が残ることを毎度意識しているので触れてもらえて嬉しいです。発表は見ていないけどスライドだけは見た、という人もいますしね。
正直、図表ぬきでスライド作るなら作業時間1/3ぐらいで済む...と思いつつも頑張っています。
トークの趣旨や流れを一枚絵で説明できるレベルにまで落とし込む、そうしたらあとはその図を流用していろいろ扱えます*3。なので最初に「今回の発表はこの絵だ！」みたいなのが"見"えるとだいぶ楽になります。見えないと最後まで苦しみます。
毎度発表準備や練習が大変で、Kaigi on Rails 2025当日を迎えるのは楽しみもあり不安もありという感じなのですが、初日で発表を終えたあとは懇親会や2日目は大いに楽しむことができました。
最後になりましたがKaigi on Rails 2025を開催してくれたオーガナイザーの皆様、今年もありがとうございました。いち参加者としてもスピーカーとしても不便なく過ごすことができ、皆さんの尽力に助けられています。
来年もプロポーザル出せるよう精進します。
2025年8月にO'Reillyから出版される『Vibe Coding: The Future of Programming』のEarly Release版として2つの章が公開されていたので読んでみた。
タイトルとは裏腹に"Vibe Coding"の話は少なく、むしろ副題の"The Future of Programming"やこれから AI を活用していくエンジニアに求められるスキルに焦点が当てられているのが興味深かった。実際には"AI-assisted Coding: The Future of Programming"という言葉のほうがタイトルにふさわしいように思うし、そういう期待で読むとよさそう。*1
タイトルにVibe Codingを使ったのはマーケティングのためかもしれないし*2、Andrej Karpathy氏が元々提唱したVibe Codingに過剰な期待を持って読みにきた人に説教するみたいな感じかもしれない。
まだ Early Releaseということなので印象に残った点をいくつかピックアップする程度の感想に留める。
繰り返し出てくる"70% Problem" という言葉。これは現代の AI ツールが基本的なコードの約 70%（boilerplate、浅いドメイン、easy bug fix）を生成できる一方で、残りの 30%（エッジケース、アーキテクチャ改良、保守性、深いドメイン）は依然として人間が介入・補完して解決しないといけないという問題。
デモを一発で作れて感動〜！しつつもデプロイなどのラストワンマイルでつまづいたり、機能拡張ができずにスタックしたり、一歩進んで二歩下がることの繰り返しばかり...といった話。まぁそれはあるよねという感じなのだが、本書は「残り 30%のためにエンジニアリングの専門知識が引き続き必要であり、その重要性はむしろますます高まっている」という点を強調している。
In essence, while agentic AI offers powerful tools for software development, it also amplifies the importance of foundational knowledge. To harness these tools effectively and responsibly, users must cultivate a deep understanding of software principles, ensuring they remain in control of the development process rather than becoming passive observers.
Software development is more than writing code, after all – it’s a whole workflow that includes planning, collaboration, testing, deployment, and maintenance.
ソフトウェア開発は単にコードを書くプログラミングだけでなく、「計画、コラボレーション、テスト、デプロイ、メンテナンスを含むワークフロー全体」という視点を持つことが重要だと。
In other words, while AI can generate code, it often struggles with engineering.
現時点では AIはプログラミングは得意だがエンジニアリングは苦手であるとか、『人月の神話』でいう「偶発的な複雑さ」の処理に優れているが「本質的な複雑さ」にはまだ対処できない*3、とも表現している。
ちなみにこの本の著者は Google Chrome のシニアエンジニアリングリーダーである Addy Osmani 氏。ソフトウェア工学やコンピューターサイエンスの専門性を十分備えているであろうエンジニアによる言説である点を付記しておく。
オライリー学習プラットフォームが Early Release で出している『Vibe Coding: The Future of Programming』を読み始め、どこかで読んだ内容だなと思ったら著者が Addy Osmani だった。これは期待できる！ / “Vibe Coding: The Future of Programming” https://t.co/aUK4n0avam
— Takuto Wada (@t_wada) 2025年4月18日
AI ツールを使ったソフトウェア開発のスタイルは 3 つに分けて説明されていた。
今の自分は主に First DrafterとしてAIを活用しており、Pair Programmer としては少しだけ、あまり Validator としては活用していない。それぞれのスタイルをもう少し実験してみたい。
Git を細かく使えとかジュニアとして扱えとかよく言われるものも含めて12個ぐらい。巷のブログではまばらに紹介されていることが多いが、本書に述べられている内容をメモしておくとよいのではなかろうか。
全部引用すると長いので特に良いなと思ったもの。
シニア・ミドル・ジュニアそれぞれのエンジニアに合わせたアドバイスは実践的な内容だった。こちらもボリュームがそこそこあったので面白いなと思った点を 2 つだけ。
1つ目は、AI-assisted coderであっても定期的なAI デトックスをするとよいとのこと。時には AIのブースターを外して素のコーディングスキルの研鑽を定期的に行うというアイデア。コアスキルの学習を省略してしまうとメタスキルが磨かれないという考え方に基づく。Vibe Coding の本なのに遠ざけているのは少し面白いが、本書の主張に照らし合わせれば納得感がある。
2 つ目は、AI時代にジュニア開発者が身につけられる最良の習慣の一つはコードのテストを書くことであるというアドバイス。テストを通じてシニアエンジニアのような審美眼を磨けるだけでなく、バグ発見ができたらそれはAIにできない付加価値としてチームに貢献できたことになる。ソフトウェアがどう振る舞うべきかの判断から入り、テストを書くことで AI-assisted Coding による成果物の品質と理解度も向上するとのこと。
冒頭にも書いた通り、現時点で読める2つの章ではvibe codingの話よりもAI-assisted codingが主流になっていく世界でどのようなスキルが必要なのか、どうスキルを磨いていくのかが中身であった。
技術革新が激しいので正式版が出る頃には世間の状況も一変していそうではあるが、普遍的なエンジニアリングスキルに焦点をあてるのであれば長く読まれる本になるかもしれない。
個人的には正式版と読み比べることで、Early Releaseで抱いた印象が変わるかどうかを楽しみにしている。
*1:余談だが昨今のAI codingという言葉に曖昧さを感じており、本書が用いるAI-assisted codingは指すものが明瞭でよい
*2:Simon Willisonは苦言を呈している https://simonwillison.net/2025/May/1/not-vibe-coding/
*3:関連: Out of the Tar Pit
2024年に読んで印象に残った本を振り返る。
万人におすすめしたいものではなく個人的な印象深さで選んだ本です。
プロパティベーステスト手法の巧みな紹介や実例といった内容が面白いのもある。それ以上に、プロパティベーステストのRuby版のライブラリを作り、2024年のRubyKaigiに登壇するきっかけとなった本なので実に印象深い。2024年初めからRubyKaigiにかけては何度も読み直した。
（ツール開発はしばらく手を止めていたが、最近不要な機能を落とすcommitsを積んだりした）
プロパティベーステスト手法は面白い。しかしながら自分の練度の問題もあり、なかなか実践の機会を得るのが難しいと感じている。多少試してみたこともあるが「いや、これは使いどころではないな」「通常のexample based testingや他のテスト手法で問題ないな」となってしまう。
これはおそらく普段の自分が書いているコードの性質にもよると考える。特に最近の業務で書くWebアプリケーションコードであればproperty based testingに頼らずとも型やスキーマ、ビジネス要件の整理といった入力値の空間や次元の極小化のほうが効率的かつ経済的な課題解決であると感じる。逆に言えば、世界中のあらゆるプログラマが無造作に使いうるようなOSSを書くとか、不特定多数のクライアントからコールされるWeb APIを保守するとか、そういった場面でスッと持ち出せる切り札として引き続き研いでおきたい。
昨今よく使われる "認知負荷" についての整理、コードにおける混乱の種類の整理等々、経験を通じて獲得される暗黙知のようなものを認知科学的なアプローチで言語化されていてよかった。単なるコーディングやコードリーディングそのものにおける問題以外についても多く触れられていたのが良かった。
たとえば最も貴重で有限な資源である集中力を妨げる割り込みについて、専門的な研究が紹介されていた。
プログラミング作業にはウォームアップ、困難な作業、クールダウンの段階があり、いわゆるゾーンに入るというのはウォームアップを終えることを意味する。割り込みとは、これらのステップのいずれかにおいて発生し、再開時にコードに関するコンテクストを再構築するために意識的な努力を必要とするもの。割り込みは他人からのアクションで起きるものだけでなく、コーディングで詰まったときにGoogle検索するとか、ChatGPT等に相談して返答を待つとかそういった行動も含まれる。
「完璧に覚えなくてもインターネットで調べればいい」という助言はよく使われるし自分も用いてきた記憶があれば、本書によればあまりよい解決策ではない。記憶している知識があるほうがコードリーディングにおける効率性と理解の促進において圧倒的に有利だし、先述の割り込みによる作業の中断が起きにくいためである。（Webブラウザを開いてメールを見たり、チャットツールを見たり、関連する別のページを見てしまったりする経験が誰しもあるはず）
また、なんらかの初学者が概念を獲得する過程について説明する"意味波"について知ることができて良かった。一般的で抽象度の高い概念を知り、具体的な事例を見て理解を深め（アンパッキング）、異なる文脈や言語に適用するために抽象化する（リパッキング）という交互浴が必要である、と。
このアイデアは自身が今後何かを習得するときにも有用だし、オンボーディングプロセスやジュニアの育成といったタイミングでも意識したいところである。
製造工学と設計工学の違いを自分の中に取り込むことができたのが大きかった。
ソフトウェア開発における製造とはビルドボタンのクリックである
我々はソフトウェア産業に製造現場の思考法を応用しようとしてきたが、それが誤りで、ソフトウェアにおいて製造は問題ではないと言い切っている。
真のソフトウェア工学は、私たちの創造力と、高品質で役立つものを自信を持って作る能力を引き上げます。アイデアを掘り下げ、創造力を伸ばせるようになり、大規模で複雑なシステムを構築できるようになります。
工学と聞くと鈍重なプロセス、平均的な人々をうまく働かせる方法、といった「製造工学を無理にあてはめようとするイメージ」を持たれることもある。しかし設計工学、とりわけソフトウェア工学はもっと個を引き上げるためにあるものだという主張に説得力を感じている。
ソフトウェア工学とは、ソフトウェアの現実的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことである。
せっかく2025年に生きているのだから、すでに見つかっている効率的/経済的な解を積極的に採用していきたいし、後進に対して高速道路を案内できるようなエンジニアでありたい。このことについてはYAPC::Hakodate 2024に参加して、個人技と工芸と工学について考えた - valid,invalidでも少し触れている。
マネジメントは専門技術ともいわれているので技術書枠。だが同書によれば、「マネジメントはサイエンスでもなく専門技術でもなく、実践の行為であり、主に経験を通じて習得されるもの」とのことで、レギュレーション違反かもしれない。
エンジニアリングマネジメント関連の書籍も充実してきているが、より源流というか、より大きく一般的かつ大局的なマネジメントのインプットも重要だと実感した一冊。
本書ではマネジメントをアート・サイエンス・クラフトのミクソロジーと捉えており、面白いことに読者を診断するちょっとしたワークシートがある。試したところ自分はほとんどクラフト寄りであり、自己の経験の範囲内に閉じこもる恐れがあるというフィードバックも得られた。マネジャー個人がすべてを兼ね備える必要はなく、チームにおいて不足する領域を特定して補うようなアプローチが有用とのことで、チームを見つめるときの1つの観点として用いている。
この本と直接は関係ないものの読了後の思索と併せて書いた記事が以下であり、本書を少しだけ引用した。本記事が多くの人に読まれたのも印象深さにつながっている。
今なら『ミンツバーグの組織論』のほうが新しくて良いのかもしれないがこちらは未読。
2024年は特定の言語やノウハウを深掘りするような書籍はほとんど読まなかったようす。ここに載せていないもの、非技術書も含めると能力の獲得や学習に関する本が多かったように思う。特に意識していたわけではないのだが自身の現在の課題意識や興味関心がそのあたりにあるのかもしれない。
非技術書も気が向いたら紹介したい。
表題の通り東京Ruby会議12に参加しました & 前夜祭で発表してきました。
僕の発表は前夜祭の10分枠だったのでライトなネタとしてGit scrapingについて話しました。
Git scrapingとは単にスクレイピングをするだけでなく、定期的に実行し、結果をgit repositoryに記録していくことで時系列データが得られるというものです。詳しくはSimon Willison氏の2020年の記事 Git scraping: track changes over time by scraping to a Git repository をご参照ください。
東京Ruby会議12のテーマは "Rubyと暮らす" だったわけですが、日々の生活の中にどうやってRubyが入り込んでくるかどうかは人によってまちまちです。特に、初学者であったり、業務でRails書いているだけのような感覚の方だとなかなか "Rubyと暮らす" 最初の一歩を見出しにくいのかもなと思います。その一歩目としてGit scrapingを選んでみるのはどうか、という提言をしたつもりです。
前夜祭も本編に劣らず面白トークが連発していて良かった。特にokuramasafumiさんの「Rubyで書いたらRuby-ishになってる」は最高にキマってる感じがしていたのと、makicamelさんのErdMapは知らないアルゴリズムの話が出てきて興味が湧きました。
本編ではキーノートの2本が印象深かった。jhawthornさんのGitHubの話はRubyとRailsがスケールすることを証明してきた会社ならではでありました。脚注でたくさん記事リンクが付いていたので、あとでそれぞれのテクニックやツールを深掘りしてみたい。eagletmtさんのRustは案外Rubyと近いというのも、面白かった。ifが式であるとかの式志向な言語は僕も好みなので2025年はRustもっと知ってみようという気持ちになれた。
前回の11は僕がRubyを始めた頃で当時は存在すら知らなかった...。osyoyuさんがリブートする形で開催をキメてくれたのが12。
地域Ruby会議も地域によって規模はさまざまだと思いますが、300人規模はさすが東京。さまざまな企画やスポンサーブースや海外から招聘されたキーノートスピーカー等々、半端ない労力が透けて見えるすごいイベントでした。オーガナイザーズの労力が大変感じられる作り込みがされていて良かったです。
ニッチなポイントかもですが前夜祭のソフトドリンクに伊良コーラがあって感動しました。高田馬場から少し歩いた下落合に伊良コーラ本店があり、そちらでいただいたコーラがあまりに美味しく、僕がクラフトコーラを自作しようと思ったきっかけでもあります。アルコールに弱くクラフトビールは飲めない者としてクラフトコーラを応援しています。
また、ランチも懇親会も初めましての方々と交流できたり、お久しぶりですが出来たりした。
改めて運営や関わった皆さんお疲れ様でした！
他の大型カンファレンスとは一味違った"色"を感じるとても良いイベントでした、オーガナイザーズのみなさん運営お疲れ様でした
— ohbarye (@ohbarye) 2025年1月19日
色とは何かでいうと、若者のすべて、駆け抜けた青春の煌めき的な"何か"があった (プリ機のせいか?) #tokyorubykaigi
2024年の登壇発表をまとめる。
1年間で6本、だいたい2ヶ月に1本ペース。
CFPへの応募形式が3本、YAPC::HiroshimaとRubyKaigiとKaigi on Rails。出したプロポーザルは4本で、落選したのはYAPC::Hakodate 2024。
また、所属会社主催のイベントでの発表が3本。
Idempotency-Key Headerについて2回目の発表。前回はKaigi on Rails 2021だったので、プロトコル策定にあたっての数年分のdiffを見られたら面白いと思いsubmitした。が、調査したら思ったよりも差分がなくてびっくりした記憶がある。
プロトタイピング、もっとやっていきたい気持ちで話した。諸事情あり、まだやれていないかもしれない。
RubyistとしてRubyKaigiの舞台に立てるとは長らく思っていなかったので、何よりも印象深かった。その他の感想は別記事にて書いたのでここでは省略する。
Data migration手法のレールがないよね、という話をした（なのでタイトルの on Rails にやや違和感を持ちつつ話していた）。4年前に調査して導入した手法を振り返る、4年前と今でのコミュニティの現状差分を見る、自分が知らないことは詳しい人にインタビューする、といった新しい要素を持ち込んだのがだいぶ好評だったようで嬉しい。
なんとなく経験と勘でやっている部分が多いプロポーザル執筆について、今ならある程度固めた発信ができるのではないかと上期が終わる頃に考えていた。その直後に機会をもらえてまとめることができ、良い思考の整理となった。
僕の過去記事で最も読まれているものの一つに状態、結合、複雑性、コード量の順に最適化する - valid,invalidがある。業務でも折りに触れてこの指針を参照したり議論したりしているので、何かしらの実例を紹介したいと思っていた。
完璧に意図したわけではなかったが2024年に開発した機能について振り返ったとき、この設計指針に絡めて話せそうということでテーマとした。
同僚のnakamuuuと共同発表という新しいスタイルも面白かった。
今年は昨年よりも多くプロポーザルを書いた年だったが採択率もほぼ下がらず満足できた。生成AIレビューなどを活用してみんなどんどんプロポーザル執筆が上手くなっていくはずなので、僕もさらに上手くなっていきたい。
自分の登壇発表を並べてみるとやはり、というかずっと思っていることではあるが、一貫したテーマがない。
ある時期に一番興味があることについて目標を立て、登壇発表のようなわかりやすいマイルストーンを置いて、実行する。達成したあとも同じテーマで延伸可能とは思いつつも、前目標に向かっている間に抑圧していた別の興味を抑えられず、そちらを次なる目標として軽率に置いてしまう。
楽しんでやれる範囲でやる、と決めているのでさほどネガティブには捉えていないが、一貫したテーマや代名詞のような作品を持つ方々の眩しさは今でも感じ続けている。
