トーク

"AI"の発展でますます「何にでも答えてくれる」存在として使われつつある電子計算機ですが、「計算機」が根源的に扱うのは今も昔も数値。 情報処理 ≡ 数値処理 なのは今も昔も変わらないのですが、それゆえに今も昔も変わらないのが「一個ずれる」(off-by-one)エラー。本talkでは筆者が実際に体験した二つ(以上?)の実例を通して、視聴者のみなさまにもその悲哀を共有していただきます。ちなみにどちらも見事 Perl 本体のバグも踏み抜きました。

• 計算機(Computers)にとって数値(Numbers)とは何か?
  • 整数 (Integers)
  • 浮動小数点数 (Floating Point Numbers)
• 例-0: JSONの数値が復元できない!
• 例+0: 負のデバイス番号?

転職などによって今まで慣れ親しんできた環境から未知の環境への移動を強いられることがあると思います。不安ですよね。未知の言語、フレームワーク、ワークフローなどなど…そもそも作っている製品自体よくわからん！　ということもあるでしょう。そんな新しい環境で自分がちゃんとバリューを出せているのか？　と頭を悩ませることもあるかと思います。
本トークのテーマは「今日から使える未知の環境でも生き延びるための"技術的な"テクニック100選」です。まずは「今日」を生き延びなければ「未来」はありませんからね！　トピックの一部は以下の通りです。この他にも様々な技法をご紹介する予定です:

• 実務grepテクニック
• IDE・AIを活用したコードリーディング
• GitHub検索の活用
• issueルンバ
• メトリクス・トレーシングからの推察

番外として気持ちのマネジメントなど非技術的話題も含む予定です。

数年前に、わたしの経歴を知った方から「あなたは行き当たりばったりの人生で計画性がない」と言われたことがあります。
言われたときには、そのシチュエーションから、その方がわたしに対してネガティブな評価をしているということがわかっており、非常に落ち込み、かなりの間引きずりました。
自分の性格やそれに起因する人生の行き当たりばったりさにも悩みました。

それから数年経ったいま。行き当たりばったりな人生をわたしは後悔しているでしょうか。
いいえ、まったく後悔していません。過去の任意の地点に戻れると言われても戻りたい地点がありません。

衝撃の日から時が経ったいまの、「行き当たりばったり人生」を生きるマインドについてお話します。

話すこと

• 人生の選択をするとき、未来を切り開いていくために重要だとわたしが考えていること
• 自分の人生を振り返るときに気をつけたいこと

皆さんが日々お買い物に使っているクレジットカード、どうやってできているか知っていますか？
クレジットカードの中には様々なセキュア情報や決済するにあたって重要な情報が詰まっています。身近に決済として使っているクレジットカードがどのような工程を経て製造されているか、また製造過程においてどのようなシステムを構築して製造しているかなどをカード発行事業を行ってきた得た知見を元に紹介します。

具体的に以下のような内容をお話しする予定です。

• カードに含まれるセキュアデータとして、どのようなデータを取り扱い、設定しているか
• カードの製造工程がどんなもので、どのようにプロジェクトを進めて製造が進んでいくのか
• カードを製造するために作っているシステム基盤の概要

「リファクタリング」「運用の自動化」「品質向上」つい後回しになっちゃいますよね。
とはいえプロダクトの成長フェーズでは、新機能の開発はもちろんシステムの安定性の向上や維持も重要です。

エンジニアだからこそ発見しやすい課題感。
何度も必要性を説明し、難しいながらも定量的効果も示したり。なかなか理解されないもどかしさ。
でも、ここで諦めたら大きな問題になってしまう。

本セッションでは、エンジニアとしてそんな難しさに何度も直面しつつ、それでもプロダクトの未来を見据え、
諦めずに一つ一つチャレンジしながら全員で開発を進めている。そんな経験を共有します。
泥臭さと向き合い悩みながらも前に進み続ける勇気、それをお届けできると嬉しいです。

対象

• 日々の開発に追われながらも、プロダクトの未来を見据えたいエンジニア
• 様々な職種の方々と協働する中で、理想と現実のギャップに悩むエンジニア

JavaScriptでは以前から日付の扱いが難しいと言われてきました。
JavaのDateクラスをそのまま移植したために起きた問題で、Java側はJava8（2014年リリース）でDate and Time APIが導入されて解決済みの課題です。

この、日付に対する課題を解決するために提案されたTemporal APIの実装を確認し、実際に使い物になるのか、注意点はどのようなところにあるのかを共有します。
※本プロポーザル提出段階ではJavaScriptで標準化された機能ではありません。

アジェンダ

• JavaScriptの標準化への流れ
• 今までのDateクラスの辛み
• 文字列 => 日時
• 日時 => 文字列
• 日付計算

対象

• 誰でも
• JavaScriptの最新の動向が気になる人
• JavaScriptの日付で苦労した事がある人

自分の未来を大きく左右するのは、今の自分の行動です。
では、今の未来の行動はどうやって変えていけば良いのでしょうか？

本セッションでは目標設定の方法から行動心理学をもとにした未来に繋がる行動を模索します。
セッション内ではEMとして1on1をする中でメンバーが抱えていた「目標」に対する悩みとそれに対する見解を含め話し、同じ悩みを持つ人の助けとします。

アジェンダ

• なぜ今行動できないのか
• なぜ目標を決めるのか
• なぜ目標が決められないのか
• バック/フォア キャスティング：目標を決めていくときの思考法
• 目標へのマイルストーンの定め方：目標達成に向かうアプローチ
• 目標との付き合い方：無理をせず、目標を達成する考え方
• 1on1と目標設定：会社での目標の考え方

対象者

• 誰でも
• 目標が今ない人
• 目標設定で毎年悩んでいる人
• 目標を叶えたい人

ペアプロ・モブプロは、チーム開発におけるベストプラクティスの一つとして知られています。
しかし実際には、どこでペアプロ・モブプロを適用するかといった悩みがあったり、
やってみたが残念ながらあまり効果を感じられなかった、ということはないでしょうか。

私は数年間にわたり、いくつかのチームで「ペア・モブで全部やる」スタイルを推し、実践してきました。
本トークでは、このスタイルの実践事例、具体的な方法をお話しします。
そして、ペアプロ・モブプロによって生み出されるたくさんのコミュニケーションが、
どのようなチームの文化、働き方や考え方を形成するのか、
そしてこのスタイルの楽しさ、魅力やメリットをみなさんにお伝えしたいです。

もっとチームメンバーと一体感をもちたい、コラボレーションしたい、チームみんなで未来に向かいたい、
そんな気持ちを応援するトークを目指します 。

キャリアというものをどう考えていけばいいかわからない、という人も多いのではないのでしょうか。
私もそうでした、というかキャリアというものについて、ちゃんと考えたことはないのかもしれません。

ですが、ソフトウェアエンジニアとして15年ほど働いたことで、結果的には自分独自のキャリアになりつつあるととも思っています。

私は前職ではSREや、SREチームのマネージャーとして働いていましたが、転職してコーポレートエンジニアになりました。
一見全く関係ないどころか、プロダクトへの関わりすらなさそうに見えますが、実はそんなことはありません。
自分ならではの理由がちゃんとあっての転職ですし、自分ならではの価値が出せることを感じながら仕事をしています。

これらのキャリアの変化を通じて、自分なりに考えるひとつのキャリアの考え方、メリットや楽しさについてもお話しします。

Polyrepo構成におけるGithubのリポジトリ管理戦略について話します。
弊開発チームではPolyrepo戦略をとっておりますが、世の中の多くのツールはMonorepoに適した仕様である場合が多く色々な課題があります。
このセッションではPolyrepoにおけるインフラ管理側の視点でのセッションとなります。

話すこと：

• Polyrepoにおけるリポジトリ設定の管理戦略
• Polyrepoにおけるソフトウェアのバージョンアップ戦略
• Polyrepoにおけるデプロイや夜間停止などインフラ戦略

サービス運用を続ける中で、リリース時には負債でなかったものが、サービスの成長とともに環境が変化し技術的負債となることがあります。
ユーザーに価値を提供し続けるためには、変化に応じてシステムを継続的にリアーキテクティングすることが重要です。

本発表では、あらゆるジャンルの商品を扱う「商品比較サービス」の商品データベース再設計の実例を通して、リアーキテクティングの勘所についてお話しします。
課題抽出、要件定義、技術選定・設計、開発・データ移行の各フェーズで実施した取り組みと押さえるべきポイントを共有することで、皆様がリアーキテクティングする際の参考になればと思います。

ソフトウェアアーキテクチャに絶対的な正解はなく、トレードオフを分析して自分たちの状況に最適な選択肢を選ぶ必要があります。
本発表を通して、自身のシステムのアーキテクチャを再考し、新たな未来を切り開くきっかけになれば幸いです。

ソフトウェアエンジニアとしてキャリアをスタートし、エンジニアリングマネージャーやVPoEを経て、現職では人事ポジションに転職しました。このキャリアチェンジは、私にとって未来を切り拓くための挑戦の一歩でした。
このトークでは、エンジニアとしての経験を活かし、新しい視点でエンジニア採用や組織づくりに取り組む中で、直面した課題や得られた教訓を共有します。キャリアの方向性を"People>Tech"へシフトさせることで得られたインサイトや、人事としての経験がエンジニアリングマネジメントにどのように役立つかについても触れながら、キャリアチェンジのプロセスで感じた悩みと葛藤、そして得られた成長と満足感について赤裸々にお話します。
キャリアチェンジを考えるエンジニアや、エンジニアリング組織を新たな視点から見つめ直したい方にとって、未来を切り拓くヒントとインスピレーションを持ち帰っていただければ幸いです。

最近、DevRel、Tech PR、技術広報という言葉をよく目にするようになりました。役割として専任で取り組む人が増えたり、新たにコミュニティが生まれたりと業界全体として盛り上がりを感じています。一方で、技術発信カルチャーの醸成においてTech PRの属人化を課題に感じている方も多いのではないでしょうか。

本セッションでは、属人化の緩和を目指しながらメルペイの技術発信カルチャーをアップデートするため、初めて作成したTech PR Roadmapの取り組みについてご紹介します。どのように周囲のメンバーを巻き込んでいくのか、どうやってジブンゴト化してもらうのかなど、具体的な取り組みをお伝えします。
このセッションを通して、何かしらの自社に合った取り組みや施策のヒントを得られ、参加者の所属企業の技術発信カルチャーがアップデートされることを期待しています。

突然ですが、サービスの中で最も寿命が長い要素は一体何でしょうか？おそらくそれは「永続化されたデータ」のはずです。コードは少しづつ改善していくことが可能ですが、データ、特にユーザーのアクション起因で保存されるものは全く変わらないこともあるでしょう。
しかし、例えばサービスをリニューアルするとなった場合に、永続化されたデータをそのまま利用することは可能でしょうか？リニューアルにあたって、データ構造を変えたくなることもあるでしょう。
とはいえ、どのように進めるとよいでしょうか？

このトークでは、複数のサービスリニューアルと、それに伴うデータの引越し経験を元に以下の点についてお話しします

• リニューアルにあたって、どこから手をつけるか
• 移行作業、その準備の進め方
• 実際の事例

また、 これまでの経験を元に、少しでも長くサービスを運用していくためのポイントも考察していきます。

2001年に創業した株式会社はてな。そのアカウント基盤は、2021年に密かにリニューアルプロジェクトが開始されていた。そして2024年、ついに「パスキー」とTOTPによる「多要素認証」に対応した。はてなの歴史あるアカウント基盤に一体何が起きていたのか！

このトークでは次のことを話します。

• Perlで書かれた旧アカウント基盤とそのクライアントの間の密結合をどのように解消したか。リニューアル後は、標準化された仕様に寄せることで密結合を回避した
• 「パスキー」を導入するにあたって、さまざまな認証の安全性について整理した。その上でセキュアさと便利さを両立し、なるべく多くの利用者の安全性を高められるように工夫を凝らした

はてなのログインが「未来」に向けてどのように変化したのか、そして長年運用されてきたアカウント基盤をリニューアルするとはどのようなことなのか、その秘密をつまびらかにします！

長期のプロダクト運営では、顧客体験の改善や開発者体験の向上のため、開発言語の移行が必要になることがあります。

私たちもJavaScript→TypeScriptやJava→Kotlinなどの移行を進めています。
本トークでは、GitHub内部で使用され、OSSとしても公開されているlinguistを用いて言語比率の推移をビジュアル化し、長期に渡る言語移行をモチベーション高く進める方法を紹介します。
※ 以下の記事でも解説しています。
　https://studist.tech/visualize-language-percentage-history-b588f1e413de

デモ内容
1 linguistによるタグごとの言語比率の集計
2 Googleスプレッドシートによる推移の適切なビジュアル化

現状のビジュアル化という小さな一歩から、プロダクトの大きな一歩を踏み出しましょう。

メルペイの急成長期において、決済プラットフォームは多くの決済関連機能を開発しましたが、同時に多くの技術的負債も蓄積され、プラットフォームの機能が複雑化しています。コード自体が過度な結合になっているだけでなく、新機能の開発や組織の管理にも影響を及ぼしています。

今後、メルペイのビジネスが多様化する中で、より複雑な要件を実現し、数倍のトランザクションを頑強に処理する必要があります。このため、私たちは決済プラットフォームを再設計するリアーキテクチャに着手します。最高な決済基盤をプロダクトチームに提供し、ミッション達成を実現できる次世代の決済プラットフォームの実現を目指す挑戦に臨みます。

本セッションでは、決済プラットフォームの今までの課題や、リアーキテクチャへの準備、遭遇した課題、そして目指すべき目標に対するアプローチとそれにどのようにたどり着いたかについて詳しく説明いたします。

近年、ChatGPTの登場を皮切りに生成AI/LLMの社会実装が急速に進んでいます。メルカリでは、昨年専任の生成AIチームを設置し、生成AIを用いた全社的な開発生産性の改善に取り組んでいます。

具体的な取り組みとしては

• Claude 3.5やGPT-4o、Gemini 1.5などの最新LLMが利用可能な社内ChatGPTの設置
• 全社共通の社内LLM APIの構築
• 技術ドキュメントに基づいた質疑が可能なRAGツール
• BigQueryテーブル情報を活用したSQLの自動生成ツール
• 期中のSlackメッセージに基づく自己評価支援ツール

などが挙げられます。

本セッションでは生成AIという革新的なテクノロジーを用いて開発者体験をOpen the futureするために、メルカリがどのような取り組みをしているか、またメルカリの生成AI活用の現状とこれからについてお話しします。

みなさんはWebサービス移転のためのデータ移行を実施したことがありますか? データ量が少なければ作業の間サービスを停止して実施すればよいかもしれません。ではデータ量が多く数日程度かかるなら? 移行先のサービス、とくにtoCのWebサービスを数日間に渡って止めるのは現実的でない場合が多いでしょう。動いているサービスにユーザ影響なくデータを移行するには困難が伴います。このセッションでは、筆者が携わったこのようなデータ移行の経験を元に、サービスを極力止めず大量のデータを移行する手法とその段取り、将来同様の案件に着手する際にどのようなことを考えておくべきかについてご紹介します。

話すこと:

• 移行にかかる時間の見積もりとメンテナンスウィンドウの調整
• 動いているサービスにデータを移行する手法の概要
• 不揃いなデータにどう立ち向うか
• どのように移行の結果を検証するか

デジタルIDウォレットを利用できる環境が整備されつつあり、「高度な保証レベルと優れたユーザー体験を備えた身元確認」が実現する未来がすぐそこまで迫ってきています。

「日本でのApple Walletの身分証明書機能の展開」のニュースのように、マイナンバーカードのスマートフォン搭載は、これまで以上に一般的になっていくでしょう。また、一般的なサービスがウォレットを利用する方法も、AppleのVerify with Wallet APIを始めとして、AndroidやWebでも準備が進んでいます。

本発表では、現状を振り返りつつ、開発者として今後この状況を楽しみ尽くすための知識として、ユーザー体験の概略や、HPKE(RFC 9180)、mDL/mdoc(ISO/IEC 18013-5)について解説します。また、プロダクトへの応用やもっと先の期待したい未来の話にも触れていきます。