トーク

2025年4月、新しいロールを任されてから、わたしは無力感に押しつぶされていました。

「自分はダメだ、何もできない」と思い込み、立ち止まってしまっていたなと今では思います。

状況を少しずつ好転させるきっかけになったのは、「できない自分」と向き合うことでした。自分を否定せず、感情と事実を切り分け、周囲を頼りながら、前に進む力を取り戻していけたと思います。

このトークでは、自己否定から抜け出し、レジリエンスを育てていく中で取り組んだことや思考の変化を共有します！

やっとスタートラインに立てたかなと思っている「今」をお伝えします。

近年、静的解析ツールは単なる「チェックツール」を超え、開発体験そのものを変える存在になりました。ESLintやRubocopを使ったことがある方なら、その可能性の広がりを実感できるはず。

本トークでは、自作した静的解析ルールがワークフローをどう変えたかを実例で紹介します。
「typoや瑣末なコーディングスタイルの指摘ばかりのレビュー」から「設計議論中心のレビュー」への転換、リファクタリング作業の大幅な効率化、そしてガードレールを整備して高速にVibe Codingする様はさながらピンボールのようです。

静的解析のおもしろさを改めて知るきっかけになるはずです。

本セッションでは、Terraformを中心としたIaC環境でAIを最大限活用するための実践的な戦略と、IaCxAIで実現できる新しい可能性について解説します。

話すこと

• AIドリブンなIaCの開発について
• AIファーストなTerraform開発環境/運用方法の提案
• AI x IaCが非エンジニアとSREの架け橋になる可能性

IaCとAIは非常に相性がよく、運用の難しいインフラIaC基盤の生産性を高められると感じており
うまく使うことで安全に、リポジトリの治安を守りつつ、AIが暴れられる環境をつくり、スケールさせる方法を提案します。

かつてソフトウェアは決定論的な機械だった。しかし今、LLMを基盤とする存在が「行為者性（agency）」を獲得し、確率的で予測不可能な振る舞いを見せ始めている。これは単なる技術革新ではない。デジタル世界における新たな「種」の誕生である。
環境を認識し、意思決定し、行動する。失敗から学び、経験を蓄積し、自らを改善する。私たちは今、AIエージェントという未知なる存在と出会い、共に進化する岐路に立っている。
本セッションでは、エージェントシステム設計の実践知を共有する。MVA（最小実行可能エージェント）から始め、モジュラリティによる複雑性の管理、マルチエージェントが織りなす創発、人間との協調がもたらす新たな可能性を探求する。
透明性と自律性、効率と倫理、管理と創造性。これらの二項対立を超えて、人間とAIが共生する未来への設計思想を提示する。エージェントは道具を超えた存在へと進化しつつある。

「ロールモデル」とは、自分のキャリアを考えるときに参考にする他者の生き方や働き方のことです。
かつては身近な上司や家族をモデルとするのが当然でしたが、昨今は働き方が多様化し、単一の人物を目指すことが難しくなってきています。
特に、IT業界ではここ10年でこれまでの10年になかった新しい職種も増えました。
このトークでは、複数の人物の良い要素を組み合わせ、自分だけの理想像をつくる「モザイク型ロールモデル」という考え方を紹介します。
エンジニアカウンセラーとして先例のない道を歩んでいる白栁が、自身のキャリアを例に、ロールモデルの活かし方と新しい設計法をお話しします。
──「あなたは誰かではない」
──「単一継承は、多くのオブジェクト指向言語では禁止されていますが、キャリアであれば大いにしていい！！」

TaskMD Shelfは「積極的棚上げ」によって、怠惰なハッカーでも持続可能なタスク管理を実現する、とてもシンプルな手法です。

今やらないことを明示的に棚上げし、集中すべきことに専念します。その際、「見直し日」を必ず設定することで、後からの見落としを防ぎます。

これらをタスクを全て意味付けられたMarkdownで管理するため自由に柔軟に管理できます。例えば、「見直し日」が来たタスクや、今やるべきタスクを簡単に一覧できるのです。

本トークでは、何故新たにタスク管理を考えたのか、既存のタスク管理手法の思想を振り返り、それらの手法で困ることをTaskMD Shelfでどのように解決したのかを紹介します。

また、テキストデータを使う「自由な」タスク管理の哲学や利点についても触れます。AIに秘書的なサポートを受けるやりかたや、具体的なタスク管理の手法や自動化についてもお話します。

ドメイン駆動設計文脈における集約の考え方は、私自身アーキテクトとして案件に入っている中でも長いこと上手く言語化できないものでした。

そんな中、RDRAという要件定義フレームワークを実際に使って運用してみる中で、
「こう考えたら、集約の範囲の決定やユースケースとの関係を把握しやすくなる！」と根拠をもって確信したものを発表したいと思います。
この考え方を基本にすることによって、たとえ分散アーキテクチャになったとしても、だいぶ運用しやすくなります。

さらに上記の集約の考え方は、チームの責任範囲の設計とも密接に関わりを持ちます。

コチラの内容のメインターゲットは、アーキテクトだけではなく、
チームの分割などを考えるPM・PdMさん、そしてビジネスアーキテクト向けです。

ITアーキテクトとしてシステムアーキテクチャ設計や技術選定、その他諸々の業務を遂行する際、じつに様々な思考方法を駆使しています。
「思考力」を鍛錬してきたからこそ、ここまで生き残ることができたと感じています。

思考力は、アーキテクトに限らず、どんな職種においてもたいへん重要です。
技術力の大部分がAIで代替可能となったとしても、思考力はそう簡単に代替されることはありません。
ITエンジニアとして成長し、活躍するためには、思考力こそが最大のレバレッジポイントだと言えます。

アーキテクトがビッグピクチャーを描き、その実現の過程で利用する思考方法ーー抽象化、メタ思考、アナロジー、推論（演繹・帰納・アブダクション）、etc。

激動の時代を、この先生きのこる武器を手に入れましょう。

2025年の今、私が皆さんに聞いてほしいのは、多くのモダン技術を支える「関数プログラミング」、その理論的基盤である「ラムダ計算」の話です。
本セッションでは、まず基本となる「型なしラムダ計算」を扱います。すべては関数であり、式の変換で計算が表現される世界を豊富な図解で解説します。理論の学習というよりは、シミュレーションを覗き込むような感覚で、関数プログラミングの動作原理に触れていきましょう。
これにより、高階関数や参照透過性といった、関数プログラミングの核となる概念がなぜ機能するのか、その本質が直感的に理解できてもらえるのではないかと思っています。セッション後には、関数プログラミングへの理解が一段と深まっていると思います。

2025 年 6 月某日。
「条件付き書式で色を塗りたいんだけど」
そんな軽い相談をきっかけに聞き出した要件は、結合セルだらけの “人間にはやさしいが機械には地獄” なスプレッドシートから、予定・人物・イベントが複雑に交差する三次元構造のスケジュールを可視化したいというものでした。

二次元の表に三次元の情報を押し込むという、物理的に無茶な要件を前に、他称スプレッドシート職人の私は腹をくくることになりました。

この発表では、2025 年の今、もはや業務でも趣味でも避けて通れない道具となったスプレッドシートの限界と付き合いながら、Google Apps Script、QUERY 関数、MAP 関数、LAMBDA 関数、スピル、条件付き書式などを駆使して、依頼者の求めるものにたどり着いた過程を、実際に使った関数や考え方とともにお話しします。

入社80日で取締役に就任し、組織コンディションに難のある状態からの建て直しに挑んだ1年間で得た結論は「会社経営の8割は兵站」でした。本セッションでは『戦略は兵站を磁化し、兵站は戦略を作る』を軸に、企業文化の再設計、Valuesの見直し、採用・オンボーディング・評価制度を貫く磁化ループの構築等、兵站のケイパビリティ向上に向き合った「HARD THINGSがブッつづく」1年をみなさんと振り返りたいと思います。B面タイトルは『人のHARD THINGSを笑うな』。

ClaudeCodeの性能はすさまじく、ついつい大袈裟に驚いてしまいそうです。
一方で、ある程度コードベースが育ってくるとなんの工夫もなしにはうまく動かず、「当てずっぽう」の変更を繰り返して、
tokenをもりもり食べながらガンガンコードを壊していく、パンクスのような挙動をすることもあります。

わたしは、ClaudeCodeを使い、「自分でコードは一切書かない」縛りで、20,000行を超える（プロポーザル提出時点）コードベースを開発/機能追加/保守しています。
「タスクの一部をやってもらっている」「小規模なアプリをVibeCodingした」という例はたくさんありますが、この規模をすべてAgent Codingしている例はまだ少ないのではないでしょうか。

このトークでは、事例を通じて得た発見を共有します。エモい未来予想や煽りはなるべく排除した、実際的な話を目指します。

ITエンジニアにとって、人に話を聞かせることは大事だと思う。
どんなにスキルが高くても、話を聞いて貰えなければスキルを役立てることは難しいです。

実際に話を聞いてもらうにはどうすればいいか。
これを、ヘルプデスクの経験とデータ解析の視点から実践できるノウハウとしてお伝えできればと思います。

......という建前のもと、ただ壇上に立って話たいだけです。
みんな！オレを壇上に立たせてくれ！！

「設計をもっとよくしたいけど、具体的にどうしたらいい？」そんな悩みを抱えるエンジニアの皆さんへ。アジャイル時代における新たなモデリングの形を提案します。
その名も「ジャストインタイム・モデリング（JITモデリング）」。日々の開発現場で生まれる小さな気づきや課題感から、手軽に始める戦術的アプローチです。この小さな一歩が、具体的な問題解決と、設計に関する貴重な「身体知」をもたらします。
さらに、個々のJITモデルをチームで「接合」し育てていくことで、システム全体の「構造」とドメインの本質が徐々に明らかになり、戦略的設計への道を開きます。
本トークでは、このボトムアップなモデリング手法を通じて、アジャイルな現場で「ちょうどよい」設計を実践し、毎スプリントでの新たなイベント提案や、チームにおけるロールへの適応も念頭に、真に価値あるシステムを構築するための具体的な道筋を提示します。

Dockerが誕生し、コンテナが一躍インフラ系話題の技術となったころ、Linuxのコンテナはカーネルのcgroupという機能を使って実現しているという風に紹介されたcgroup。これは間違いですが、今ではLinuxでコンテナを動かす場合に不可欠の技術であるだけでなく、Linuxを起動する際にも不可欠な機能になりました。
不可欠になったために、Linuxカーネルには改良版であるcgroup v2が実装され、実運用環境でもv2が使われるようになりました。cgroupで何が実現できているのか? v2で何が変わったのかを詳しく解説したいと思います。
昨年、大吉祥寺.pmではコンテナの歴史を紹介しました。昨年の発表動画を見て今回の発表を聞くと、きっとLinuxコンテナ完全に理解した人になれるはずです。
Linuxのコンテナ技術ヲタクが、技術に特化した話を早口で語ります。

非定型うつ病は、突然の気分変動や激しい倦怠感が特徴で、世間にはほとんど知られていません。まずはこの病気を知ってください。特にエンジニアには、原因不明のパフォーマンス低下を感じたら、早く自覚して治療を受け、うまく付き合ってほしいと思います。

僕はこれをきっかけにソロプレナーへの挑戦をはじめました

Claude Codeを使い
設計のベストプラクティス
新人を育てる最速のパス
これからのエンジニア組織にについて
なども検討しています

これから世界は、AIとヒューマノイドにより激動期に入ります。この変化は新しい市場を生み出し、日本人にとって有利な国際環境を作り出します。このチャンスに皆がチャレンジして成功を掴んで欲しい

政府や自治体のサポートも多くありますが、実際に超低金利の創業支援融資をうけた経験からでメリットや気をつけないといけない落とし穴も伝えます。

最近ファシリテーションにものすごく可能性を感じております。
多くの方が大なり小なり会議の進行を行ったことがあると思いますが、上手くいくこともあればいかないこともあったのではないでしょうか。
私は、以前にうまくいかなかった会議をなん度も経験し本当に悔しい思いをしました。
そんな経験からファシリテーションを学ぶことの重要性を痛感いたしました。

また、ファシリテーションは突き詰めると、参加者の主体性を育むスキルであり、
ひいては自律型組織文化を作る可能性に満ちていると考えるようになりました。

当日は下記のような構成でお話ししたいと思っています。

1. ファシリテーションで自律型組織を作りたい
2. ファシリテーションを行う上で土台となる考え方
3. 会議の中で出会うちょっとした困りごとを打開するtips

ファシリテーションをする人だけでなく、される人にもぜひ聞いていただければ幸いです。

「テックリード」という響き、とてもかっこいいですよね！
そんなかっこいいテックリードが何をするのか知っていますか？

私は合議制による意思決定の遅さというチーム課題の解決と自身の成長を期してプロダクト開発チームのテックリードになりました。
しかし、待っていたのは「テックリードとして何をすべきか」が不明瞭な状況と、役割を見出すための深い葛藤でした。
本セッションでは、そんな暗中模索の時期から、どのように自身の役割を定義し、周囲の信頼を得て「自他共に認めるテックリード」になるに至ったか、そのプロセスと乗り越えた壁について、実体験に基づき、そのリアルな姿と乗り越えるヒントお伝えします。

テックリードを目指している方、テックリードという役割に悩んでいる方へ
皆さんの「テックリード」の解像度が少しでも上がれば幸いです。

新卒入社から2年半在籍していたプロダクトチームでテックリードを務めることになったと思ったら、プロダクトオーナーも兼務することになりました━━

異なる役割を同時に背負うことになった私が、テクノロジーマネジメントとプロダクトマネジメント、そしてチーム運営をどのように両立させようとしているか、具体的な経験談からうまく行ったこと・うまく行かなかったことの両面についてお話しします。

このような経験をした、あるいは将来する方はさほど多くないとは思いますが、リソースが限られる中でも残り続けた仕事にこそ大きな価値があり、そこから持って帰れる知見があるのではないかと思っています。