トーク

チームでのWebアプリケーション開発において、コードレビューは多くの場合避けて通れないでしょう。
コードレビューを任されたけど、どのようにレビューしたらいいのかさっぱり分からない、ということはありませんか。あるいは、コードレビューが承認の儀式になっていませんか。

このトークでは、発表者が心がけているコードレビューの要点や、見落としがちだが重要であると考えている観点についてお話しします。

• コードレビューの前段階でやること
• コードレビューの指針
• コードレビューで見ること・見ないこと
• コードレビューが噛み合っていないと感じたら
• ケーススタディ？

小平市に軸足を置いて活動している IT コミュニティ「Co-KoNPILe(ここんぱいる)」では会議室に縛られない勉強会を模索中です．
過去，小金井公園での青空もくもく会，東青梅にある古民家での 2 泊 3 日の開発合宿を行なっています．

そこで，今までの青空もくもく会，ゆるい開発合宿の知見，会議室に縛られない勉強会運営についてまとめます．
みなさんに会議室に捉われない自由な勉強会運営への一歩を踏み出していただけるよう，情報をまとめて提案をいたします．

• 公園青空もくもく会が手軽に快適になるための公園選定基準
• 快適な開発合宿をするためのスケジューリング
• これから試してみたい市外局番 042 地区の公園と合宿の紹介

※ 起点は武蔵野公会堂ではなく，国分寺駅になりますことを予めご了承ください．

わたしは働くうえで気をつけていることがあります。
それは、主語をチームにするということです。

主語をチームにすることの対比として、主語を自分とすることがあります。

主語を自分とした場合、自分の考えを中心に据え自身の主張を優先することが多いです。
これは、他のメンバーの意見や能力を十分に活かせず、結果としてチーム全体のパフォーマンスやモチベーションの低下を招くことがあります。

一方、主語をチームとするアプローチでは、メンバー全員の意見や能力を尊重し、協力して目標を達成することができます。一緒に成長もできます。

わたし自身、昔は主語を自分として働くことも多かったですが、主語をチームとするようになってからはメンバーとのコミュニケーションがスムーズになり、成果も向上しました。

当トークでは、主語を自分としたときの弊害、どのように主語をチームに変えていけばいいのかをお話できればと思います。

組織によってさまざまな形態を取る評価制度。
例としてMBO、360（180）度、コンピテンシー、ミッショングレードなどがあります。

評価制度に対する個人的な思いの丈をLTにぶつけます。

何者にもなれないエンジニアの「これから」を決めるのは評価制度です。
しかしながら、その評価制度は目的に注目しきれていないように感じており、「評価制度のための行動」を生む存在に成り下がっているように思えます。

LTでは、これらの疑問を深堀りしつつ、「自分の考える最強の評価制度」を考察します！

エンジニアの成長に欠かせない要素の1つは「アウトプットすることの大事さ」だと思います。
私の組織は社内でのアウトプット文化はそこそこありますが社外へのアウトプット文化にはまだまだ成長の余地があります。

去年から自社テックブログをはじめたので、これを機会に社内にアウトプットの文化を根付かせたい！！
本LTではその取り組みのうちの1つ、「mkmk-tech（もくもくテック）」について紹介します。

mkmk-techでは名前の通りテックブログをもくもく書く会ですが、
この中には「アウトプットしたくなる仕組み」をたくさん入れています。
社のテックブログの継続に悩んでいる方、アウトプット継続に悩んでいる方に届けます！

話すこと
・なぜテックブログを書くのか
・なぜテックブログが継続できないのか
・mkmk-tech（もくもくテック）: 内省を促す・アウトプット前フィードバックの仕組み

作ると決められた物をスケジュール通りに作る。

この働き方に嫌気が指しつつあった僕は、より主体的にビジネスに関われるエンジニアになるため、2022年からフルサイクル開発をするプロダクトマネージャーを目指して現職で働いています。

・この機能は本当に作るべきものなのか。
・この機能はどこまで作り込むべきか。
・これ以外にも作った方が良さそうな候補はいくつかあるが、どれを優先すべきなのか。

製品全体とはいかないものの、機能に関する裁量を渡されたエンジニアがどのような働き方をして、何を学んできたのか。

自身の振り返りや、キャリアに悩む人への参考情報として、2年間の学びを話せたらと思います。

こんにちは、私は新卒です！
4月は出会いと別れの季節。これまでとは違う新しい環境下で試行錯誤していた方もいらっしゃるのではないでしょうか。

このトークでは、学生時代に得た「これまでの経験」から、「これからのキャリア」を積み上げる1歩目として
私が入社後に意識的にやったことを厳選して3つお話します。

新しい環境で認知を広げ、今後に繋げるための最初の1歩。その行動に至るまでには、私の経験が深く絡んでいます。
私と同じく新しい環境に飛び込んだ方はもちろんのこと、
学業やお仕事を変わらず続けている方でも持って帰れるものがあるような、心に響くトークをお約束します！
入社して間もないからこそ出せる、「ギラギラした新卒トーク」が聞きたい方も是非💪

話すこと

• 私が入社してやった行動3つとその反応
• なぜその行動をしようと思ったのか
• 振り返って思う、その行動の良かったところ・改善点

エンジニアの多くは、自分が成長できる環境を望んでいると思います。

情熱プログラマーという本には "Be the Worst" （一番の下手くそでいよう） と書かれています。
優れた人々と一緒に仕事をすることで、自然と自分のスキルも向上するというものです。

しかし、実際その環境は、決して楽ではありません。
自分も近い環境にいる中で、以下のようなことで悩んでいたこともありました。

• タスクのレベルが高すぎてなかなか成果を出せず、チームに貢献できない
• メンバーからのフィードバックで自分の実力の足りなさを痛感し、自信を失う

しかしその環境の中で、考え方や行動を少しずつ変えていき、前向きに日々の業務に取り組めるようになっていきました。

本LTではどのようにチームの貢献しながら自信を失わずに日々仕事に向かうか、自分自身の経験を踏まえてお話しします。

コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、1対1のコミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、

コミュニケーションパスの数
1対1のコミュニケーションにおける対話（パス交換）
チーム間のコミュニケーション経路
というような、チームコミュニケーションにおける「パス」に着目して、私が大切にしている考え方を共有させていただきます。

コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、1対1のコミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、1対1のコミュニケーションにおける対話（パス交換）に着目して、私が大切にしていることを共有したいと考えています。

エンジニア学生としてインターンや学生団体でチーム開発、ハッカソンなどを経験して社会人エンジニアとなった今、エンジニアとして変わった意識や心構えなどスタンス面のことをお伝えしようと思います。

対象者

• エンジニア学生
• 社会人1年目のエンジニアの方

話すこと

• 学生と社会人で変わった意識、スタンス
• 社会人の働き方

話さないこと

• 具体的な技術的なこと

拡張の開発（ドキュメンテーションツールSphinxやVS Code）を通しての学びを共有する発表です。
主張としては、1回出会っただけでは分からないことが多いため、同じものと何度も出会って、螺旋を描くように理解を深めていくことのすゝめです。

計画的偶発性理論に説明されるように、偶然の出会いがキャリアに影響する素敵な出会いとなることがあります。
私もたくさん経験してきました。

一方、偶然出会っていても、その場で価値が分からずキャリアへの影響までは至らないことのほうが多いようにも思われます。
そのため私は偶然の出会いを増やすことよりも、すでに出会っているものに出会い直すことを重視してきました。

拡張開発は私にとっては出会い直しの好例でした。
繰り返し訪れることで理解が徐々に深まり、Sphinxを使いこなした実装に至れました。
また、複数の拡張開発を通して設計力の向上も達成しています

近年、オブザーバビリティの文脈で「eBPF」について触れられていると思います。本セッションでは、eBPFの概要とオブザーバビリティ以外でのeBPFのユースケースとして、プログラミング言語を問わないこれからのAPIテストについての話をします。

※技術コミュニティ活動＝X（旧Twitter）、技術ブログ執筆、勉強会・カンファレンスへの参加、登壇、オープンソースソフトウェアへのコントリビュートなどの業務外の技術的アウトプット活動全般の意味で使っています。

私は2007年頃から技術ブログを始め、2014年頃から各種勉強会・カンファレンスに登壇者として参加してきました。
それなりに長い年月技術コミュニティ活動をしているので、自分自身の技術志向・働き方の変化や、読んだ本・聞いたセッションの影響を受けて、何を考えて記事を書くか・何を話したくて登壇するかが変化してきたなと感じます。
どのような変化があったかふりかえり、直近ではどんな目的でやっているかについてライトニングにお話ししたいです。

開発者として日々できないことの多さにめまいがしませんか？
打ち負かされながらもその日々の中で勝利をつかみとっていきたいものです。

できないことが多く打ちひしがれることが多い中で、私はあることをきっかけに日々の取り組み方を変えました。
5 分の LT では日々の仕事への、開発への取り組みの変化について、以下のようなお話をする予定です:

• できないことから目を逸らして、できそうなことを探していないか
• 自分の蓄積にだけ甘んじていないか
• やれなくてもよいと最初から決めつけて食わず嫌いしていないか

自分のように技術力でねじふせられるわけでもなく、悶々としながら開発する日々を送っている開発者に向けて、
「すごいふつうの開発者」から「ふつうのすごい開発者」くらいにはなれそうな、すごくふつうな、前向きな話をします。

アウトプットを通した知識の整理が公私共に良い影響を与えるということを理解していても、企業が技術ブログを運営しようとすると途端に困難が立ちはだかります。

このトークでは開設から10ヶ月ものあいだ1記事しか投稿されておらず紛うことなき閑古鳥の鳴く技術ブログだったClassi開発者ブログに賑いを取り戻し月数本以上のペースを3年近く保てるようになるまでの取り組みを通して、持続的な技術ブログ運営のノウハウとそれを貫く「アウトプットが人々を豊かにする」という哲学の醸成について考えたいと思います。

組織の技術ブログ運営について悩んでいる方はもちろん、ブログや発信から遠ざかっている個人のみなさまも、今一度、発信すること・共有することのおもしろさについて再発見する一助になるきっかけとなるようなトークにしたいと考えています。

2024/03/23 に初の分散システム集会 @distributesys を開催し、5月時点で3回目の開催となりました。
VRChat では VRSNS という特徴から全国どこでも・世界中のどこであっても、インターネット回線さえあればイベントに参加できます。

アジェンダ

• VRChat上でのイベントや集会の様子
• ニッチな話が出来るVRChatの集会について
• 集会主催側の声や日々の生活との両立具合

参加者の方がPythonをちょっと触ることになったときに助けになる、最近（〜少し未来）のPythonスクリプトの書き方・実行方法についてLTします。

PythonにはPEPという拡張提案がいくつもされていて、最近「PEP 723 – Inline script metadata」が採択されました。
これはPythonスクリプトにメタデータとして依存ライブラリを明示できるようにするというものです。

PEP 723をサポートしたツールでスクリプトを実行すると、「仮想環境」という依存ライブラリ管理の仕組みをツールが担ってくれます。
人間が仮想環境を管理しなくてよくなり、6年程度のPython開発体験の中で劇的な改善を体験しました！

このLTでは愛用しているpipxをtips込みで紹介します。
PEP 723をサポートするツールには他にpip-runがあり、今後も増えていくでしょう。

ソフトウェアエンジニアとして10年近く過ごしてきて、これからのキャリアについて考えるようになりました。テックリードやスクラムマスターをやったことはありますが、他のポジションについては経験がありません。最近はCTOやVPoE以外にも、 IC (Individual Contributor) や EM (Engineering Manager)、スタッフプラス (スタッフエンジニア、プリンシパルエンジニア、ディスティングイッシュドエンジニア) などの名前も日本で耳にするようになりました。

「やりたいようにやってたらそのポジションになった」という形が自然かなとは思いつつも、ある程度の方向性は決めることができるのではないかと思っています。

プロダクト、デリバリー、組織、経営など、様々な軸でキャリアパスについてどう考えられそうか整理してを紹介します。一つの考え方として参考になったら嬉しいです。

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

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

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

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