プロポーザル

納期や品質のプレッシャー、大きな責任、はじめての挑戦。

こういったものは、人によっては辛くて、楽しくないかもしれないです。

一方で、諸条件さえ整えれば、結構楽しめるものです。成長すればするほど、そうしたプレッシャーのかかる場面が増えます。

自分自身のメンタルを健全に保ち、継続して仕事を楽しむために、責任とプレッシャーとどう向き合うといいか、を語ります。

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

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

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

私は去年の4月にプレイングマネージャーとしてEMになり、今年の4月からはEM of EMsとして専任EMになりました。この1年間で経験したロールチェンジは、思っていた以上に「持つべき視点」や「こだわりポイント」、「得られる喜び」を大きく変えるものでした。例えば、かつては「一つ一つの機能を作ってリリースする楽しさ」を感じていた自分も、今では「半年や一年などの期間を通じてどれだけアウトカムを作り出せたか」ばかりを気にして、個々の開発へのこだわりやそこから得られる喜びが薄れてしまい、少し寂しく感じています。

この考えも揺れ戻しで1年後には違うことを考えているかもしれませんし、今の考え方に染まってしまい寂しさすら感じなくなるのかもしれません。このトークではロールチェンジの真っ只中な今だからこそ感じる変化を、リアルなエピソードを交えてお話しします。キャリアに悩んでいる人への参考になれば嬉しいです。

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

おもな内容

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

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

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

転換点は、技術的な特効薬ではなく、チームの「オーナーシップ」を再構築することでした。
一度立ち止まって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が大半のコーディングをすることになるだろう近い未来。
ガードレールとしても重要になるテスト、そしてテストカバレッジ、今だからこそ再考してみませんか？

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

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

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

RSGT（Regional Scrum Gathering Tokyo）2025のClosing Keynoteで、ホンダのシティ開発に関わった本間日義さんの講演を聞きました。
それをきっかけに歴史を遡ったことで、スクラムの源流には日本の製造業──ホンダやトヨタ──の実践があることを知り、スクラムの“考え方”が一気に立体的に見えてきたんです。

それまでの私は、スクラムを「こうやるもの」として捉えていましたが、背景を知ったことで、運用の一つひとつに込められた意図がより分かるようになりました。
スクラムに対する理解が深まったことで、これまで以上に納得感を持って向き合えるようになったのです。

このセッションでは、私の追体験をもとに、そんなスクラムのルーツを5分で紹介します。
スクラムの形骸化に悩んでいる方や、なんとなくモヤモヤを抱えている方こそ、原点に立ち返ってみませんか？

データベースはいつの時代もビジネス、ソフトウェア共に中心に存在し、大きな貢献を続けています。
その裏にはコミュニティがあり、様々な支援活動を行っています。

PostgreSQLユーザ会（以下 : JPUG）もその一つ。
そんなPostgreSQLコミュニティですが、運営メンバーが入れ替わらずに平均年齢は毎年カウントアップされています。

このセッションでは直接的な解決策まで提示できません。なぜなら 今、PostgreSQLコミュニティが無くなるかもしれない危機 だからです。
そんなPostgreSQLコミュニティの理事の一人である私がどうやってコミュニティに向き合って、そしてどんな未来を目指していくのか。
10年後に「あのときは結構苦労したんだよな」とみんなと酒を飲みながらふりかえられるようなことをお話します。

コロナ禍を経て、エンジニアの働き方やコミュニティのあり方は大きく変わりました。「東京は（心理的に）遠い」と感じるようになった私は、地元に根差したエンジニアコミュニティを立ち上げました。しかし、地域コミュニティにありがちな「身内ノリ」は避けたい。オープンな場で「熱狂」を生み出すには何が必要か？

たった1年で参加枠が9時間で埋まるほどの盛況ぶりを達成した裏側には、緻密な戦略がありました。本セッションでは、「やらないことを明確にする」、「対話をオープンにする」といった具体的な工夫を惜しみなく共有します。

地域コミュニティのパイオニアである大吉祥寺.pmの精神にも通じる、参加者が「また来たい」と心から思えるコミュニティ運営の秘訣。この1年の東葛.devを振り返り、本気の“今”をお届けします。

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

「明日から役にたつLTをダメにする方法をあなたに」

5分間で想いを伝えるのは難しいぞ！
良かれと思ってやったことが命取りになる！挽回の時間も残されていない！それがLT！
私の経験から導き出した個人的見解に基づく、やめておけってLTを解説を交えながら実践します🕺
これであなたも最悪なLTが実践できるね！ﾔｯﾀｰ!!!

• 笑いを取るのはやめておけ
• 奇抜なキャラ付けは逆効果
• 自己紹介はいらない
• 伝えたいことは最初と最後に
• もうスライドはダサいくらいでいい
• 情報量が多いスライドを作っちゃった時に発するべき言葉
• 登壇の方向性が定まっていないとみんなが混乱する

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

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

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

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

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

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

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