業務では Mac を使用して開発を行い、プライベートでは WSL を利用していました。
しかし、WSL の環境構築にうまくいかず、当時のスクラムマスターに教えてもらった elementary OS という Linux ディストリビューションを試してみたところ、快適に開発できるだけでなく、普段使いにも適している理想的なノート PC が手に入ったのです。
もちろん、Mac を選択することが一般的であり、理にかなった選択といえますが、様々な理由から Mac を選択できない人もいます。
そんな持ち運びに便利な PC を探している人に、軽量な PC に Linux をインストールするという選択肢を提案したいと思います。

話す内容

• elementary OS の特徴
• Mac を選ばなかった理由
• elementary OS を使用したきた感想

令和のエンジニアがどのようなキャリアでWebエンジニアになるのか。
そしてどのようにして「大吉祥寺.pm」のようなイベントに辿り着くのか。
その謎を追うべくわれわれはアマゾンの奥地へと向かった。

ターゲット

• 24新卒世代を知りたいプロエンジニアの皆様方

はなすこと

• Webエンジニアとして新卒就職するまでの道のり
• カンファレンスとの出会い、そして別れ
• これからのキャリア像(数十秒程度)

はなさないこと

• 本筋と関係ない自分語り
• 趣味の個人開発で作ったサービスなど
• 新卒で入社した企業の紹介

これっていわゆる生存バイアスなの…それとも何か普遍性があるの…本人にはわからないところがあります。けれど、どんな人にもやる前から諦めてほしくないんです。好きという気持ちがあれば一念岩をも通す、みたいな。

就職氷河期、文学部哲学科の私はSEの職に。新人研修で初プログラミング、言語はJava！でも配属はメインフレームの運用でCOBOL！？
Javaが好きという思いから、Javaコミュニティを立ち上げ10年間代表をしたり、海外カンファレンスに何度も参加したり、業務関係なくJava仮想マシン調べていたら仕事のチャンスをもらえたり、パッチを書いてコミッタになったりと歩んできました。思い返すとこうしたうれしい出来事と、動くがゆえに傷ついた出来事もやっぱりたくさんあります。

コミュニティとそこの友人たちのがいたからこその自分です。好きに向かって「やろう！」と思えるお話をしたいと思います。

ドメインモデリングに関する日本語の情報は『エリック・エヴァンスのドメイン駆動設計』や『実践ドメイン駆動設計』といった古典DDDの解説が多くみられます。ともすると、コードの整理術が中心に語られてしまい、共有メンタルモデルを表現し問題を理解しやすくする、という本来のドメインモデリングの役割が見えないこともあります。

そこで本発表では、ドメイン駆動設計を一旦離れた視点から、対象理解のための純粋なドメインモデリングのあり方を比較的新しい『Domain Modeling Made Functional』『Balancing Coupling in Software Design』『Runnable Specifications』あたりの書籍から読み解いてお話します。

ドメインモデリングの現在地点を知りたい方は、ぜひ吉祥寺にご参集ください。

クラフトビールは多様性が魅力的な奥の深いアルコール飲料です。
もっともっとクラフトビールに

・クラフトビール入門 〜飲み方、知っておきたい用語〜
・マイクロブルワリーの魅力 (「えっ、クラフトビールって「よなよな」的なやつ？」「それも美味しいんだけどね」)
・知ると面白いディープなクラフトビールの作られ方
・テック業界・スタートアップ業界と意外と近いクラフトビールの世界

今日からクラフトビールの世界に入門したい、もっとビールに詳しくなりたい、そんな方のための指南書となるようなトークを目指します。

こんにちは @sotarok (そうたろう) です。
このトークでは、ソフトウェエンジニアとしてキャリアをスタートした自分がどこかで間違って起業に至り、複数のスタートアップを経て今まさに経験しているコトをお話します。

こんな話:
・なんで3足のワラジ履いてるんだっけ
・ソフトウェアエンジニアがガチで飲食店やる話
・でもちゃんとガチでCTOやってる話
・そんな中で起業している話

Exitしたお金で悠々自適な飲食店経営生活？
いいえ、そんな単純簡単なモノではありません。

新型コロナウイルスの真っ只中にオープンした飲食店経営、CTOを務める所属会社も大打撃のハードモード、一生立ち上がらない事業、
起用にやっているようで結構大変なので、「起業」「CTO」「クラフトビール屋さん経営」の3足のワラジをどのようにはいているのか、実体験に基づく全く役に立たなそうな話しをしようと思います。

みなさんは、初めてエンジニアの門を叩いた日のことを覚えていますか？
入社して初めてプログラミングに触れました、という人は案外少ないのかもしれません。

今からちょうど2年前、私が所属する開発部に1人のメンバーが加わり、僕がメンターを任命されました。
彼女は人生で一度もプログラミングをしたことがない完全未経験で、最初の質問は「プログラムを『実行する』って何ですか？」でした。

そんな彼女が今や各種デザインパターンを駆使し、第一線で活躍するエンジニアへと成長しました。

一緒に歩んだ2年間の軌跡をぎゅっと凝縮したOJTのノウハウを伝授します！

多くの人々が、Zoom,Microsoft Teams, Google Meet, Discordなど、映像・音声通話が行えるサービスを使った経験があるでしょう。
しかし、これらの技術で使われているWebRTCについては、まだまだ知られていない部分が多くあると思います。

WebRTCは、Web Realtime Communicationの名の通り、Webブラウザで通話を行える技術として2011年に策定が開始され、2021年に標準化まで辿り着きました。
この10年間の間に、非常に多くのユースケースが追加され、現在の仕様は最初期のInternet Draftから大きく変わっています。

本セッションでは、10年間かけて変化してきたWebRTCと、今後のリアルタイムコミュニケーション技術について紹介します。

決定・決断というのはどうしてもストレスがかかるものです。しかし、決めることを恐れたり、特定の人があらゆる細部にまで踏み込んで全てを決めたりすると、チームやプロダクトは停滞していきます。

私がアプリケーションエンジニアとして仕事をする上で意識している、誰が何をどう決めるべきかという話をします。例えば、エンジニアがHowを決めるためにHowについて上司にお伺いを立てまくってもしょうがないよね、とか、逆にマネージャーにはWhyに関しては責任を持って欲しくてそこがブレていたり曖昧だったりするならツッコむべきだ、とかそういう話をします。

そして、こうして自分の責任範囲を理解し少しずつ広げていくことで、チームやプロダクトも前に進んでいくし、新卒でもエンジニア個人としての立ち位置を高めていけるという話をします。

ある日、自宅のインターネット回線が突然、仕事用のVPNは繋がらないのにYoutubeは見れるという状況になってしまいました。
このトラブルの対処の過程を追いながら、不可解な事象の裏で起こっていたこと、その技術的な背景についてお話ししたいと思います。

主にネットワーク関連（ルーター、IP、DHCP等）の初級レベルの話を扱います。

2019 年 11 月にスタートした Co-KoNPILe(ここんぱいる) という小平市周辺を拠点にする IT コミュニティがあります．
コロナ直前に産声を上げた，東京都西部に軸足を置いた IT コミュニティは今も変わらずに，勉強会を続けられています．

小平，国分寺．小金井，国立，立川，東久留米あたりを転々としながら，また，参加者は 23 区からさえもやってきます．
この背景には発起人である自分が北海道で約 15 年培ってきた，地域の IT コミュニティの経験が無視できません．
　
そこで，

• 北海道各地と小平市周辺の IT コミュニティ活動の共通項
• オンラインと現地活動の役割分担
• 上京と帰省と関係人口
  　
  の観点から現在の Co-KoNPILe を振り返り，都市部郊外と地方の IT コミュニティの継続的な協力関係について考えます．

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

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

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

五年ほどさまざまなところで登壇を続けてきました。今まで、登壇を繰り返すことで特別な何かになれる予感がありました。多くの人に自分の考えが評価されることで幸せになれると信じていました。しかし、それは間違っていました。
本当に大切なのは僕の話を聞いた誰かが動き、少しばかり幸せになることでした。

このトークでは人前で話すことの意義と要点について、下記内容に言及します。

• なんのために登壇をするのか
  • 人の心を揺り動かし行動を促す
• 他者の評価は自身の幸福に寄与しない
  • ショーペンハウアー哲学における幸福論について
• 他者の幸福実現を目指す
  • アドラーの共同体感覚について
• スライドでは何を伝えるべきか
  • ノイズを減らし印象をコントロールする
• たった一人に届ける

ソフトウェアエンジニア をやっていて避けて通れないのが各種調査です。
インシデントの調査や、ちょっとした不具合の調査、機能を追加するときの既存のコードの調査など、ソフトウェアエンジニアの仕事は調査の比重が割と大きいのではないでしょうか。
そのさい自分のためにもチームのためにも有用なドキュメントを作ることができます。それが調査ログです。
本LTではなぜ調査ログを書くのか、調査ログをどう活用できるとよいのかをお話できればと思います。

私は、2024年3月末に前職を退職しました。
退職後、有休消化と空白期間とを組み合わせ、1ヶ月半の無職期間をつくりました。

無職期間中は、「働いているときには絶対やらないような技術勉強をしよう！」と決めていました。

しかし、何にも縛られない自由な立場が無職です。
ゴロゴロしながら動画を見たり、ゲームをしたりする誘惑に打ち勝ち、一人で技術勉強をやり切るのはなかなか意志力のいる話です。

幸い、同じタイミングで無職をやっているエンジニア仲間がいました。
彼を巻き込み、毎日「無職もくもく会」を実施することに。
すると、勉強がとても捗りました。

このトークでは、エンジニア仲間と毎日もくもく会をしたら捗ったという経験談をします。
お互い無職という理想的な状態からはじまり、より良い進捗を心地よく生み出すために重ねた工夫、働き始めた今も継続していくためにどうしていくか、といったお話をする予定です。

エンジニア仲間と雑談Podcastをはじめて5年が経ちました。
数万リスナーの超有名番組！というわけではないですが、細く長くそして楽しく250回を配信してきました。

最近、周りで「Podcastやりたい」という声を聞きます。
テキストと比べより生に近いその時々の考えを音声という形で発信し、アーカイブしていくのはとても価値のあることです。

一方でなかなか難しいのが、配信を継続することです。
Podcast配信には多くの作業が存在し、これらが継続を難しくする要因となっています。

私たちがPodcast配信を継続してこられた理由のひとつは、「いかにラクに配信するか」を考え抜いてきたことです。
このトークでは、5年モノの番組を持つ私が、2024年のいま ”継続しやすい” Podcastのはじめかたについてお話します。

このトークをきっかけに、Podcast仲間が増えれば嬉しいです。

アジャイル案件でのPMとはなにか？？
システム会社のエンジニアとして、事業会社のWF・アジャイルのハイブリッド案件にアサインされてPMとして稼働するなかでの、改めて役割を明瞭化していった整理の共有をさせてください。
アジャイル/スクラムと、受発注という２本の文脈に照らして、システム開発会社のPMの役割・価値を見える化したいと考えています。

本業はソフトウェアエンジニアを行っていますが"ワインと鍋"という飲食店を経営しています。

飲食店をやりながら、ソフトウェアエンジニアをやってきた経験が生きているなと思うケースがたくさんあります。
マネジメント、改善プロセスの導入、各種ツールの活用やプロダクトマネジメントの手法を飲食業に応用することで有効だったケースが非常に多いと感じています。
具体的には飲食店と1つのプロダクト、運営する組織を1つのチームと捉えることで応用することができています。
手法を導入するにあたって、ただ単に手法を使うだけではなく、飲食店経営における定石や当たり前だと思われるような知識を考慮した上でいれる必要があり、そういった部分では苦労したところもあります。

そういった経験をされている方はあんまりいないと思いますのでこの経験を具体的な事例を含めてお話したいです。

少し前、スピーカーが開発に関わるサービスで使うメインのDBをMySQLからPostgreSQLに移行しました。

• AWS DMSを用いて移行する際のナレッジ
• DMS以外の移行テクニック
• 移行した後のPostgreSQL運用小話

などについて話します。 AWS DMSを使ってMySQLからPostgreSQLに移行したい人、必聴です。

Q, さくらいさんは、なぜエンジニアになったんですか？
A, 開発部に不満があるのに、何もできない自分が悔しかったからです。

たとえば、開発部へあげているはずの機能要望が一向に実装されない。
たとえば、開発優先度について聞いてみても納得できる回答が返ってこない。
こんな不満がCS時代の私にはありました。

「ならばエンジニアになってしまえ！」とジョブチェンをした私は、「勝手に諦めている」「勝手に諦められている」ことが不満の種だったことを知り、いま改善活動に努めています。
もとは毎日ユーザー対応をしていた元CSエンジニアだからこそ話せることを、実体験をもとにお伝えします。

話すこと

• 元CSの私が開発部に抱えていた不満と、その後の変化
• そこから学んだコミュニケーションで「勝手に諦めない」ことの大切さ
• 対CSコミュニケーションのアンチパターン