トーク

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

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

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

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

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

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

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

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

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

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

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

本トークでは、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

話すこと

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

みなさんは、マネジメントを実践していますか？

マネジメントの書籍はたくさんありますが、学んだマネジメントを実践する為の組織・プロジェクトは多く存在しません。
マネジメントを実践したい！マネジメントを実践で向上させたい！
そんな希望を持つ方に朗報です。
なんと、楽しく遊びながら実践的にマネジメントを学ぶ。そんな話が世の中にあるんです！！！

このトークでは、マネジメントを実践する小さな場として「ボードゲーム」を紹介します。
ボードゲームとは、テーブルの上で一人から遊べる電源を必要としないゲームです。
身近なトランプやすごろく、麻雀もボードゲームの一種です。

これらの中にはたくさんのマネジメントの要素が含まれています。
種類によっては、5分～１時間程度で遊ぶことができます。なんてお手軽！！

いくつかのボードゲームとそれによりどんなマネジメントが実践で学ぶことができるかを紹介していきます。

ここ数年でデザインシステムというワードが浸透し、双璧をなす形でエンジニアとデザイナーの関わり方に強い関心が向けられるようにもなりました。
そんな私はエンジニアからキャリアをスタートし、その後デザイナーへ転身、そこからまた更にエンジニアへと往復しました。

この発表ではデザインシステムの卵の育て方をエンジニア視点でお話します。
この卵は、いわゆる0-1フェーズから10-100フェーズへと受けつないでいくための架け橋へとなります。
あまたのフェーズを経ていく中で、プロジェクトに関わる人数も変わればプロダクト自身も成長していきます。
システム化できるものすらない状態から、どのようにデザイナーと関わっていくのか、共通認識を見つけていくのか、コードやデザインファイルに落とし込んでいくのか、人に変化があった時にどうするのか、などなどを私の過去の失敗談も踏まえてお話します。

私はこれまで事業会社のEMとして多くの時間を過ごしてきました。
直近の3年ほどは特に自社システムの品質(主に保守性)に強い危機感を持ち、改善のためにアレコレとやってきましたが、、まあうまくいかないんですよね。

ところが。
昨年の秋に転職して立場が変わったことで相対する人も・伝え方も・やれることも変わってくるわけで、EM時代にうまくいかなかったワケ？のようなものも見えてきました。

たかだか半年のことではありますが、これらの経験や気づきをご紹介させていただくことで、みなさまが同じ轍を踏まないためのアンチパターンとしてご参考いただき、みなさまのチーム改革・組織改革のお役に立てれば何よりです。

IT業界の経験は随分長くエキスパートなキャリアがある中(当方の場合はPM、PMPホルダー)で、新しいコトを初心者として学ぶハードルを感じていました。しかし、スコアを競うワークショップとの出会いが自分自身のエンジニア人生のゼンマイを再び巻き直すきっかけになりました( https://qiita.com/beajourneyman/items/3034a0059c6e23d3d069 )。初心者として歩み出し、社内技術研鑽のコミュニティに参加し、若い方の吸収力の驚異的なスピードに圧倒されながらも、技術力が乏しい1エンジニアとして学ぶ日々を楽しんでいます。多くのエンジニアが"新しいコトを学ぶハードル"を感じていると思います。その壁を乗り越えるきっかけになるメッセージを伝えられたら嬉しいです。

1989年、世界はワールド・ワイド・ウェブ（WWW）の登場という歴史的瞬間を迎えました。同じ年、私もこの世に生を受け、まさにWebと同じタイミングで人生をスタートさせました。
中学・高校時代にWebでのコンテンツの面白さ触れ、新しい発見と興奮の日々を過ごしました。SNSサービス黎明期にはWebにまつわる仕事と通じながら自分自身の今後を考えていくようになりました。
社会人ではWebデザイナーとしてのキャリアからスタートしましたが、コンテンツの表層としてでなくその背景にある技術仕様の理解を深めていくためにエンジニアとしての道を歩み続けてきました。
今、Webがコモディティ化し、生活の一部となった現代において、私たちはどう向き合い、どう進化していくべきか。Webの誕生と同じ1989年生まれの私が、自らのキャリアを通じて見てきた変遷とこれからの時代について、考察していきます。

IT業界10年目のUIデザイナーが、2014年から2024年までのデジタルデザインを振り返ります。

思い返せば、2014年頃は多くのデザインの現場ではAdobe PhotoshopでWebデザインをしていたかと思います。
2016年頃になるとスマートフォンの普及からレスポンシブ対応が普通になってきました。
2018年頃にはよりスマホアプリ開発が活発になってきたように思います。
2020年頃になるとIE対応を切る判断もされるようになってきました。
2022年にはTwitterが買収されました。もう2年前だそうです。
そして、最近ではAIを使ったUIデザインの手法も模索されています。

デザイナーにとってはPhotoshop、XD、Figmaなどデザインツールの変化も大きいものでした。
これまでの10年を振り返り、その変遷を辿ってこれからの10年に思いを馳せたいと思います。