トーク

本トークでは「技術を磨きつつ、長く豊かなキャリアを築く」ための指針を提示します。
特定の技術習得だけでなく、「心のあり方」と「学びの姿勢」に焦点を当て、「足るを知り、流れに身を任せ、循環を意識し、自分軸を持つ」という考え方を軸に、持続可能で充実した働き方を提案します。

おもな内容

• 「満ち足りる心」でコードと向き合う
  • 完璧主義を手放し、「ちょうどいい」価値を届け、心の豊かさを感じる開発姿勢。
• 「流れに身を任せる」学びと成長
  • 情報過多に疲弊せず、自身の興味やプロジェクトに合わせた「自然な学び」を追求。
• 「恵みへの感謝」と「循環」の精神
  • チームやコミュニティへの貢献を通じ、知識や助け合いの「良い流れ」を生み出す。
• 「比較を手放し」、自分だけの価値を見出す
  • 他者との比較から解放され、あなた自身の「情熱」を原動力とするキャリア形成。

開発が思うように進まず、チームに閉塞感が漂う。そんな経験はありませんか？
「誰かがやってくれるだろう」と感じてしまう時、その根底にはチームから「自分ならできる」という自己効力感が失われているのかもしれません。

本セッションでは、かつて停滞していた私たちのチームが、小手先のプロセス改善では越えられなかった壁をいかにして乗り越えたか、その「軌跡」をお話しします。

転換点は、技術的な特効薬ではなく、チームの「オーナーシップ」を再構築することでした。
一度立ち止まってUI/UXから要件を再定義し、「動くもの」を囲んで対話する。
そのプロセスを通じて、メンバー一人ひとりの「自分がやる」という思いがチームの推進力に変わっていきました。

この「軌跡」の共有が、皆さんのチーム、そしてあなた自身の「次の一歩」を踏み出すための具体的なヒントと勇気になれば幸いです。

心のどこかで最後は自分が何とかすると抱え込み、気づけばプロジェクトのボトルネックになっていた私。メンバーからも頼りにされていないと感じられてしまうこともありました。

そこで、私はチームメンバーへ「みんなを頼らせてください」と宣言しました。

ここに至るまで非常に葛藤がありました。リーダーが頼ることは、弱さをさらけ出すことだと思っていたからです。
しかし、頼ることは決して弱さではなく、むしろ強さであると気づきました。

当セッションでは、この決断に至るまでの経緯、その結果どのような変化が自分やチームにあったのかをお話しします。
「自分が頑張ればなんとかなる」と思いがちな方、リーダーとしての重圧に悩んでいる方などに、抱え込みを減らすヒントとなれば幸いです。

話すこと

• なぜ抱え込むリーダーになるのか
• 決断までの葛藤
• 決断後に起きた変化
• 頼ったうえでリーダーとしてやるべきこと

「トム・デマルコ」という名を、もしくは「ピープルウェア」の書籍名をご存知ではないですか？
多くのクラシックを生み出し、様々な影響を与え続け、氏の記述が引用されている場面は数知れません

そんなデマルコの書籍から、日本語で読めるものを「8選」紹介します！
初めてのデマルコに、あるいは知らなかったデマルコに出会うきっかけになれば幸いです

動機

プロジェクトの成功を探求する中で
「構造化分析」に始まり、昨今は「やる気」「ゆとり」と、主題や切り口が変遷してきたのがデマルコです
そうした変化を辿るのは、ますます変化が激しくなる今日を生きる我々のヒントになるのではないでしょうか

触れる書籍

• 構造化分析とシステム仕様
• ソフトウェア開発プロジェクト技法
• ピープルウェア
• デマルコ大いに語る
• デッドライン
• 熊とワルツを
• アドレナリンジャンキー
• ゆとりの法則

先日開催されたJJ〇G CCC 2025 Springにて、「イベントストーミングから始めるドメイン駆動設計」というテーマで45分間の登壇をしました。…が、結果は壮絶な時間配分ミス！
準備万端のはずが、核心部分を大幅に端折り、伝えたいことの半分も伝えられず不完全燃焼で幕を閉じました。
なぜこんな悲劇が起きたのか？本LTでは、この苦い経験を赤裸々に語り、敗因分析と、そこから得た教訓を共有します。「話したいこと」と「伝えられること」のギャップ、リハーサルの重要性など、登壇者なら誰しもが直面する可能性のある問題を、笑いと涙（主に私の）と共にお届け。この失敗談が、皆さんの今後の登壇活動、そして不測の事態への心の準備の一助となれば幸いです。そして宣言します、このリベンジはブログで果たす！…予定です！

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

私は18年のエンジニア歴の大半を与えられた環境で最善を尽くしてきました。
ただ、それだけでは自分の思考の枠を越えられず、枠の外にある課題は解消できないことに気付きました。

そうして昨年から勉強会やカンファレンスに参加し始め、外部の知見を取り入れることの重要性を実感しました。
また、ただ学ぶだけではなく、対話を通じて認知を揃えることの大切さを感じるようになりました。
今年は一歩踏み出し、実践したことを発信することで双方向の関係を築こうとしています。

まだ手探りの状態ではありますが、
こうした営みこそが、私の置かれた環境の「サイロ」を壊し、
より開かれた活性化された環境の土壌を育てると考えています。

本セッションでは、私自身の試行錯誤やその中で得た気づきをもとに、
サイロを壊す実践について共有させていただきます。

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

テストカバレッジ100%はアンチパターンと言われていること、みなさん知ってますよね。
しかし実際に10年間やり続けた話は、あまり聞いたことがないんじゃないでしょうか。

エンジニアとして働き始めてから複数のプロジェクトで単体テストのC0/C1カバレッジを100%をテストの完了条件として実施し続けてきた時期がありました。
世の中では「テストカバレッジ100％は意味がない」「コストパフォーマンスが悪い」と言われていますし、どちらかというと自分自身も勧めるものではありません。
ただ、得られたものもたくさんあったなあと、今では感じています。
実際にやってみて何が得られたのか、どんな結果になったのか、リアルな経験から感じたことをお話します。

生成AIが大半のコーディングをすることになるだろう近い未来。
ガードレールとしても重要になるテスト、そしてテストカバレッジ、今だからこそ再考してみませんか？

「やる気が出ない。でも何かしなきゃ。」
そんな焦りに飲み込まれていた自分が、少しだけラクになれた経験をお話しします。

仕事での責務が増えてアウトプットが止まり、アウトプットするネタも浮かばず、周りがどんどんアウトプットしているのに自分だけが取り残されているように感じて、焦っていた時期がありました。
そこで私は、無理に動かず“できる範囲だけ続ける”ことを選びました。

このセッションでは、私が試してきた工夫や気づき、そして“やる気がない前提でどう設計するか”についてお話します。
やる気が出ないことにモヤモヤしている方、立ち止まっている自分に不安を感じている方へ、少しでもヒントになれば嬉しいです。

「このポケモンは何に進化するの？」と日々問いかけてくる5歳の娘に、私はポケモン図鑑をプレゼントしました。
チームトポロジーとは、開発チームがいかに価値を実現していくかを、まわりのチームとの関係性も含めた考え方です
娘と接するうちに、親は娘にとってのイネーブリングチームであることに気付きました。
自分で考え、動き、世界を広げていく娘の成長をチームトポロジーの考え方と照らしてご紹介します。

ジョン・ウィリアムスというクラシックギター奏者について昔先生が話したことを最近よく思い出す。
「ジョンの演奏の唯一の欠点はミスをしないことです」
彼の技術は非常に高く、クセがなく実に模範的な演奏をする。でもそれが欠点だと先生は言った。

最近不格好なものに触れる機会が減った気がする。登壇も同様だ。
AIのおかげなのか、はたまた大量に溢れる整ったテンプレートのおかげなのか、見栄えよく話も整っておりなんともストレスのない話が多くなった。

それでいいのか、と問いたい。速度や楽さに流されて一点ものであろうとする毒を抜かれてないだろうか？
批判を恐れ教科書的で隙のない言葉ばかり選んでいないだろうか？

気をてらうことは推奨しないが、本心が見えないほどにラッピングされたものはどこか悲しい。
だから今、過度に整ったものが与える心理と、不格好でいいから自分の言葉で伝える術について皆に話したい。

最近はプロダクト開発に必要なツールが多く開発されています。
最近ではObsidianやAI Agentなど、少し前だとFigmaやnotionがあったと思います。

これらを会社ないし、チーム内で活用を進めていくためには、ファーストペンギンが必要でもありますが、セカンドペンギンもいないとまったく普及しません。

本トークは一番最初に挑戦する人に追随してくれる「セカンドペンギン」の重要性について解説し、「セカンドペンギンになろう」と思ってくれる人が増えればと思います。

2025年。世間はオフラインに戻りつつ有り出社を必要とする会社も出てきました。
そんな2025年の1月に私は転職と引っ越しを同時にしました。引っ越し先は地元の甲府、転職先は今までと技術スタックの違うフルリモートの会社です。
引っ越しをして早数ヶ月、気づいたら山梨の技術コミュニティが盛り上がりはじめ、自分も3つほどの勉強会を立ち上げるに至りました。
このトークでは2025年の現在転職と引っ越しをするとどうなるか、そして現在についてお話します

たぶんこんな内容

• 引っ越しと転職
• 甲府の技術コミュニティ
• 異常な勉強会を立ち上げるコツ、気合、根性
• 崩壊する体調との付き合い

今密かに流行っているという噂のDesktopLinux
私は転職を期に大学院生ぶりにDesktopLinuxをNixOSとVAIO SX14-Rで始めました。
このLTではギョームや趣味の開発や様々をDesktopLinuxでする生活についてお話します

これは、私が友人のいとこの弟さんの娘さんの知り合いから聞いた話です。

その会社には、業界内では大変珍しいことに、システム内製チームがあったそうです。
そこには15年稼働している主軸となるシステムがあり、彼らによって日々、開発・メンテナンスされていました。

しかし長い年月が経ち、システムも大分くたびれてきました。
内製チームは決断しました。

「システムをリプレースしよう！」

と……

（たぶん）残暑が厳しい今、この話で一緒に涼をとりませんか。

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

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

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

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

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

「ふりかえりが大事なのは分かるけど、毎日は大変そう…」そう思っていませんか？

本LTでは、私が毎日実践している「4行日記」と週末の「ORID」を用いた、継続しやすく効果の高いふりかえり術を5分で凝縮してお伝えします。
日々の出来事から「事実・発見・教訓・宣言」 を引き出す4行日記と、週末に「客観・反応・解釈・決断」 のステップで多角的に内省するORID。
この組み合わせで、日々の小さな成功や課題を成長の糧に変える具体的な方法を、すぐに試せる形でご紹介します。

皆さんもこのLTをきっかけに、ふりかえりを始めてみてください。
自分自身について新たな発見を得られるかもしれませんよ。

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

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

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

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

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

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

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

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