Developers Summit 2025に参加
ホテル雅叙園東京で開催された『Developers Summit 2025』(2025/2/13~14)に参加しました！
会場はかなり豪華なホテルで、入るのに尻込みしました…
落ち着いた雰囲気で、リラックスしながら快適に過ごせました。
講演資料はこちらにまとまっています。
Developers Summit 2025 公開資料・Xアカウントリンクまとめ
参加したセッションはこちらです！
2/13
- 13-A-6 マイナビの内製開発を支えるコンテナ基盤設計開発の舞台裏～自動化で楽々デプロイ！でもアプリチームからはちょっと不評？～
- 13-B-7 プロダクトの価値を高めるためにコーディング以外にできること～共通言語でつくる異職種コミュニケーション～
- 13-E-8 不具合流出の減らしかた。不具合流出の予防に効くツール選択と開発体制づくりを掘り下げてみる
- 13-D-9 「Apple Vision Pro」の登場で何が変わるのか？ ITエンジニアとXRの可能性を語ろう
2/14
- 14-C-1 チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング
- 14-E-2 「mixi2の舞台裏」 TiDBで実現するSNSのスケーラビリティとパフォーマンス
- 14-A-3 プラットフォームエンジニアの目線で見たコンテナ技術と活用方法を解説
- 14-C-4 私が新卒からプロへと変わる3年間～「エンジニア基礎」研修資料で伝えたエンジニアになるまでの道のり～
- 14-A-5 現場で役立つAPIデザイン
- 14-A-6 テスト自動化、苦しかったときの話をしようか―これからの開発現場を効率化するためのベストプラクティス
- 14-C-7 エンジニア組織のジェンダーダイバーシティ推進への挑戦～Rubyコミュニティからの学び～
- 14-E-9 エンジニアコミュニティでひろがるキャリア、深まる人生 - “コミュニティへの還元”リレーション -
さらに懇親会 にも参加しました！
出発
早起きし、普段なら長靴を履くような雪の積もって凍った道を、東京用にスニーカーを履いてキャリーケースを持ちながら駅まで移動。 なんとか駅に辿り着き、あとは乗っているだけだとゆったりしていたら、空港行きのバスの車内で欠航が判明！
ということで次の便まで時間が空いたので、趣味のプログラミングを進めることができました✌️
そして東京に着きましたがすごく風が強く、体感では北陸より寒いのではとびっくりしました。
セッション
技術の話からテストの運用方法、組織作りなどいろいろなセッションがありました。
あくまで私の言葉で書いたものなので、発表内容とは異なることをご了承ください。
13-A-6 マイナビの内製開発を支えるコンテナ基盤設計開発の舞台裏～自動化で楽々デプロイ！でもアプリチームからはちょっと不評？～
アプリチームとクラウドエンジニアが分かれていて、それぞれでヒアリングと用件定義のフェーズがあるのが、私は経験がないので印象的でした。
チームで担当範囲が異なりつつも他チームの成果物を必要とする構造が、それぞれが専門領域に特化するためより深く携われたり認知負荷の軽減に役立つメリットがあると思いましたが、リードタイムが長くなったり運用の属人化が発生したりするのはなるほどと思いました。
また、今のIaCというのはAWSコンソールを触らずにかなり細かなところまでテキストファイルで定義できるということが知見を得られました。 リソースの集約とアプリチームによる申請内容を元にした構成作成の自動化という解決策が興味深かったです。
このような改善において、実際に使うユーザへのヒアリングを十分に行い、どのような効果があるのか、逆にどのような不便が発生するのかをきちんと把握し、協力しながら対策を立てることが重要ということを認識しました。
13-B-7 プロダクトの価値を高めるためにコーディング以外にできること～共通言語でつくる異職種コミュニケーション～
一つのサービスを運営するうえで、実装からビジネス面、サポートなど全てを完璧に把握することは限界があるので、チームとして事業を進めることのスケールメリットを活かすためにもコミュニケーションが大事なことを学びました。
伝達が意図通りにできていない「 ミスコミュニケーション 」と、伝達が行われない「 ディスコミュニケーション 」があり、それぞれを別原因として考えると改善すべき点が見えてきそうだと思いました。
- ミスコミュニケーション
- 伝えたいことを適切に言語化できていない
- 伝えている内容が一部抜け落ちる
- 意図通りに解釈されない
- ディスコミュニケーション
- そもそも情報を送っていない
異なる立場の人とコミュニケーションを取るには相手のことを理解することが重要ということで、情報を送る側はドメインを学ぶことで相手と近い視点や言葉でメッセージを発することができ、情報を受け取る側も社内勉強会などを通じて情報を送る側のことを知ってもらうと良いと知り、相手のことを知るという互いの努力が必要なのが重要なポイントかなと思いました。
ディスコミュニケーションを防ぐには会話を増やし曖昧なところを無くすことも、きちんとコミュニケーションを取ろうとする姿勢が重要に感じました。
このような改善は一朝一夕ではできないと思うので、「通信効率」が上がるような日々の心がけが大事だと思いました。
13-E-8 不具合流出の減らしかた。不具合流出の予防に効くツール選択と開発体制づくりを掘り下げてみる
正常であれば納期から逆算しバッファを設けたスケジュールで開発するところ、炎上プロジェクトでは要件定義から開発までに時間がかかり、無理やり時間を確保したり人的リソースを投入したりするケースを知り、やはりテストは犠牲になりますよね…と感じました。
テストの網目が荒くなると不具合を検知できず通り抜けてしまうことが多くなり、レイリーモデルの障害率を表す曲線の山が右側にずれていくそうです。
認知バイアスがあると怪判断をしやすくなるとのことで、まずは認知バイアスの存在を意識することが大事だと思いました。
開発プロセスを標準化しつつも、プロジェクトごとにテーラリング（具体的にしたり取捨選択したり改変するなど）できるようにすると良いそうです。 また、EPG(Engineering Process Group)というプロセスを見直し進化させていくグループについても知りました。
ツールの選定においては有償のものの方が選定責任が生じて結果的に導入効果が高いことや、ツール管理委員会を設置してレイトマジョリティへの浸透を図ることが大事なことを知りました。 また、痛い目を見て必要性を感じたり、比較を行ったり、導入した効果を実感できると導入が進みやすいそうです。
13-D-9 「Apple Vision Pro」の登場で何が変わるのか？ ITエンジニアとXRの可能性を語ろう
LODGE XR Talkなどのコミュニティ活動の存在や、書籍の出版などの活動を知りXRとの接点があるのは素敵だなと思いました。
まずはデバイスの種類としてゴーグル（ヘッドセット）型とメガネ型があるのが用途という面からも重要な違いだと思います。
いろいろなデバイスや開発環境がありますが、OpenXRというオープンの規格を知り、特定のメーカーにとらわれずに開発できるとXRの市場が大きくなるのが期待できると思うのでこれからさらに社会実装が進むのではと感じました。
Meta社は没入型のハードウェアを作り、Appleは空間コンピューティングということで考え方が違い、それは1アプリ＝1体験だったものが、同時に複数アプリを扱えるようになったことにも表れているそうです。
ビジネス的には今は実証実験の段階だけれども、ビジネス用途に使えたり仕事の仕方が変わる可能性にも期待が持てるそうです。
開発環境の例としてWebXRとUnity PolySpatialがあり、WebXRはJavaScriptでデバッグは実機、ネット上に情報が多いため生産性は高いそうです。ただし3Dのコンテンツは容量が大きいのでクラッシュしやすく、ポリゴンを減らすなどの試行錯誤が必要になるそうです。 一方のUnity PolySpatialはUnity自体が3D向けのソフトなので今まで通りに開発できるそうです。
習得するにはインターネットで調べたりコミュニティに参加して情報共有することが有効で、ネット上の英語や中国語の情報も避けずに知ろうとする姿勢が必要なそうです。 また、AIを活用したりStack Overflowで質問することも有効だそうです。
簡単なアプリならSwiftUIでも作れるということで、3Dの扱いに慣れるという点ではCSSで触れたり身の回りのものを3Dスキャンして表示してみるという方法もあるそうです。
ゴーグル型は重く、今は1時間かけるのが限界というのが課題だそうです。
今後日常的に使えるように使い、常にデジタルのディスプレイを使うのが当たり前の世の中になるかもしれないが、他人からの目線や見られ方も変わっていく必要があるようです。
VR・XRが登場してから10年が経つようですが、個人的にはまだあまり日常に浸透していないように感じます。 デバイス自体の改善や、両手を塞がずに常に目の前にディスプレイが存在することで便利になったり安全性が向上するなどの明確なメリットを活かせる使い方が見つかると良いなと思います。
14-C-1 チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング
チームトポロジーと、プロジェクトの成長に合わせて組織の構造も進化させていく必要があることを学びました。
最初は小さなチームで開発し始め、プロダクトが成長してもニーズに合わせて安定して早くデプロイしていく必要があり、そのための開発組織の構造の進化を考えるのに使えるのがチームトポロジーの考え方だそうです。
コンウェイの法則
シシテムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう
なので組織を望ましいアーキテクチャに合わせて設計する
→人的資源の効率よりも価値の効果的なデリバリーを優先
チームを中心に据えて、機能しているチームは長く保つことを意識し破壊しない
- 4つのチームタイプ
- ストリームアラインドチーム
- プラットフォームチーム
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
- 3つのインタラクションモード
- コラボレーション
- X-as-a-Service
- ファシリテーション
これが常に正しいとは限らないが、共通言語となったり見える化しやすいので共通理解を持ちやすい
最初は1チームでなんでもやるのでアーキテクチャはモノシリックになるが、人が増えていくと認知負荷が高くなりパフォーマンスが上がらないので5人くらいを超えたらプロセスを決めた方が良い
構造の見直しとしてEnd-to-Endで開発できるようにフィーチャーチームに分割
さらにチームが自律して動けるようにするためにドメインやサービスで分離することで、リリースタイミングを揃えなくて良くなる。
というようにチーム構造は変化し続ける（特に儲けているときや事業としてさらに進めていくとき）
ただし、チーム構造を変えるに当たってはメンバーの感情や文化を考慮する →ダイナミックリチーミングの活用
チーム構造を変えるときはキャリブレーション（調整）する
このセッションを通じて、自分の立ち位置や求められていること、開発組織として価値を効果的に生み出すためにどのようなコミュニケーションを取っていくかについて考える機会になりました。
14-E-2 「mixi2の舞台裏」 TiDBで実現するSNSのスケーラビリティとパフォーマンス
話題のmixi2が、初期の機能開発は4人、リリース時は7人ということに驚きました。 あんなにパフォーマンスやデータの管理が難しそうなプロダクトをその人数で作れるのかと思いました。
RDS ShardingとNewSQLの比較の結果今回はTiDBを採用ということで、個人的にはNewSQLは知見がないとハードルが高いイメージがあったので、新規プロダクトで採用されるほど導入のしやすさがあるのだろうなと感じました。
TiDBの特徴について知り、tiupコマンドやダッシュボードなど関連ツールが整っていそうなのが便利そうに感じました。
タイムラインの特徴や実装、負荷テストや障害テスト内容について知ることができ勉強になりました。 同時にフォローやいいねが発生した時のロック待ちをRedisで回避する方法などもなるほどと思いました。
機会があればハイパフォーマンスを求められる環境でNewSQLを使って大活躍してみたいですね笑。
14-A-3 プラットフォームエンジニアの目線で見たコンテナ技術と活用方法を解説
3層アーキテクチャーのようなレガシーシステムをクラウドへ置き換える際に、ラーニングカーブの増加や認知負荷の増大などの課題がある。
いろいろな部署と連携しなければならない状況で誰が担当するか
単にDevOpsを導入しようとすると、開発者があらゆる責任を負い、認知負荷は増大する一方のなか迅速なリリースを求められる→生産性が低下する
プラットフォームエンジニアリングの考え方を導入し、IdP(内部開発者プラットフォーム)を提供する。
プラットフォームエンジニアリングの目標
- Go faster
- Decrease risk
- Increase effiniency
プラットフォームエンジニアリングの目標はコンテナ技術と相性が良い。
コンテナランタイムの仕組みや変遷、オーケストレーションの仕組みなどについて知りました。
コンテナ技術を活用し開発者や運用者にとってメリットをもたらすには多くの知識が必要になると思いますが、仕組みを整えることでさまざまなメリットを享受できる可能性があることに期待し、今後もできるだけコンテナ技術についてキャッチアップしたいと思いました。
14-C-4 私が新卒からプロへと変わる3年間～「エンジニア基礎」研修資料で伝えたエンジニアになるまでの道のり～
高専卒で卒業年度が近い方なので、ぜひキャリアや働き方の参考にしたいと思い参加したセッションでした。
『エンジニア基礎』というマインドやスタンス面についての研修の資料をもとにプロのエンジニアとなるまでの道のりの紹介でした。
- 1年目は自分のタスクで精一杯
- 指摘を受けた
- 社会人としての自覚・プロ意識
- 視座
- 先輩が何の実装をしているか
- 意識が変わった
- 今まで見ているだけだったタスクを自分から取りに行った
- 他チームとの連携
- 一見自分とは関係なさそうなこともキャッチアップ(Slackとか)
- 指摘を受けた
- 目指すエンジニア像
- 明確にイメージするのに役立ったのが「評価制度」
- 次のグレードとの差分が道しるべになる
- 明確にイメージするのに役立ったのが「評価制度」
- 基礎のインプット
- 作るものに対して、何を、なぜ開発するのかを意識
- チーム開発の文化への理解
- コードレビュー、PR、コミットの書き方ややり方、報告・相談のやり方
- コードの「わかりやすさ」の徹底
- プロダクトコードへの意識の変化
- 考慮不足
- 歴史を知る
- できていないことへのフィードバックを受け入れて改善しようと思う
- 上司が改善するために一緒に向き合ってくれた
- 視座
- 主語を「自分」→「チーム」→「組織」で考える
- 仕事が大きくなると視座が高くなる
- 「3人のレンガ職人」
- 後輩に教えるために言語化
- 仕事をしていくうえでの考え方 を教えることが多かったが難しかった
- マインドが重要
セッションを聞いて、何のために働いているのか、今やっている作業は何のためなのか、何かを考えるときに視野が狭くなっていないかなどを意識して、一日一日が何かを改善したり成長につながるような行動をできると良いなと思いました。
14-A-5 現場で役立つAPIデザイン
REST APIの基本について学びました。
API仕様書は実装しながら作ると負債になりやすい→APIファースト（最初に共同で仕様を定めて合意する）ということに共感しました。 クラス設計やDB設計もですが、作り始めてから考えるよりも事前によく考えられたものを実装した方が負債になりにくいと思います。
APIデザインのアプローチとして3種類あることを知り、普段よく迷うものがどれにあたり、どのようなメリット・デメリットがあるかが具体的にわかり理解を深めることができました。
- インサイドアウト
- アウトサイドイン
- アジャイル
HTTP標準、Restfulの原則に従いつつ、「現実解」も考えると良いそうです。
Zalando RESTful APIガイドラインのように、自分たちのサービスに合わせたガイドラインを整備するのも方法の一つだそうです。
良い設計の例として、URLの名前やパスパラメータとクエリパラメータの使い分け、抽象化の粒度、HTTPメソッドやステータスコードの使い分け、データ形式を伝える方法やエラーハンドリング、そしてバージョン管理、キャッシング、セキュリティのための仕組みなど、APIを設計するにあたって考える必要のあるいろいろなことについて学びました。
基本や基礎をしっかり押さえて、誰にでも使いやすいAPIを設計できるようになりたいと思いました。
14-A-6 テスト自動化、苦しかったときの話をしようか―これからの開発現場を効率化するためのベストプラクティス
https://service.valtes.co.jp/t-dash/news/20250124
自動テストのカバレッジ○%目標
- 動かすのが大変
- テストデータを手で作る
- 繰り返し実行できない
- テストが失敗したときに手作業でリカバリーが必要
- 運用工数の発生
- 原因調査は手動テストより大変
- スクリプトが難しく修正が必要になってもできない
- テスト品質、自動化品質の一貫性がなくなる
- どこまでテストするか、検証方法などがバラバラ
- ローコードなのに保守が大変
- →テストの基準（ガイドライン）を作る
- どこまでテストするか、検証方法などがバラバラ
- ステークホルダーからクレーム
- 開発チーム
- 対応工数が増えた
- サーバリソースを圧迫した
- デバッグやデータの不安定さで失敗するのは当然
- 手動テストチーム
- テスト自動化がブラックボックスで何をテストしているかわからない
- 手動テストが楽になったと感じない
- 開発チーム
やはり色々なチームに影響のあることを進める際には関係者に行なっていることや目的の説明、そしてフィードバックを得て改善していくことが必要なのかなと思いました。
14-C-7 エンジニア組織のジェンダーダイバーシティ推進への挑戦～Rubyコミュニティからの学び～
参加のハードルを下げるために、どんな雰囲気なのかなどの情報発信が重要ということになるほどと思いました。
また、初参加者に笑顔で挨拶したり、誰かを紹介したりすることで入口体験を良くなるのは普段から実践できそうだと思いました。
カンファレンスやイベントに誘ったり、ネクストステップを紹介するなど、次の機会に繋げるきっかけを紹介する声かけが良いのも、何かを初めて触ったり参加したりする人に向けて良いなと思いました。
やはり、どんな属性でも誰でも、いろいろなものに触れる機会があって、誰でも参加したいものに参加できるような社会というか雰囲気になると良いですね。
14-E-9 エンジニアコミュニティでひろがるキャリア、深まる人生 - “コミュニティへの還元”リレーション -
「海外」で「登壇」するというすごい組み合わせを実現しようとしているのがすごいと思いました。IT関係は海外発の情報が多いと思うので、その中で日本からも色々発信したり、世界中に視野を広げて情報を得られたら素敵だと思います。
Developers Summitを通して「計画的偶発性理論」というワードを何度か聞いたように思いますが、いろいろな選択が人生を変えることに寄与するという内容がなるほどと思い、確かにそうかと思いました。
生まれたときから「〇〇するぞ」と考えてそれが今の人生や生活に反映されているわけではなく、色々な直面した選択肢の中から色々な経験を通じて得た材料をもとに判断をしていって、またそこで色々な選択肢に直面していると思うと、選択する機会は重要に思います。
そのために、色々な属性を持つコミュニティが存在し交流するなど場所を作っていくことが重要というのも確かにと思いました。
自分自身も、きっとすでに存在している「場所」に参加して、色々な経験をして色々な選択を重ねていけたら豊かな人生経験になるのかなと思いました。
「偶然×行動」！！
偶然の出来事に遭遇して行動をすることが人生の転機になるかもしれないということが同じように思います。 また、コミュニティや仲間に出会って交流していくのも、自分一人では思いつかなかったりできないようなことを外部の助けでできるようになるなど、いろいろなことに役立ちそうだと思いました。
- カンファレンスはレベル高そう→自分だけの体験を発表する価値
- 業務で悩んでいたことを、ちょうど発表で聞くことができた
- スタッフになるとコミュニケーションを取れる
- ひろがるキャリア、深まる人生
- 参加する目的が最初は受動的だったが、能動的になった
- 楽しいを増やすのは自分
懇親会
綺麗な会場で、飲み物や食事も揃っており楽しい機会でした。
普段は接する機会のないようなさまざまな業界、立場の方と名刺交換をさせていただき、数分話す機会を得られました。 いろいろなことを知ることができますし、多くの方とお話しできて有意義でしたし楽しかったです。
「Developers Summit 2025」2日間無事終了しました！ たくさんの皆さんにご参加いただき、本当にありがとうございます。デブサミの場が、みなさんの可能性がひろがるきっかけとなれば嬉しいです！またお会いしましょう！ #devsumi pic.twitter.com/kz09yZcUjF
— Developers Summit（デブサミ）🏔 翔泳社 CodeZine主催エンジニアイベント (@devsumi) February 14, 2025
感想
今回は運用や組織づくり、キャリア系のセッションに多く参加しましたが、広い視野を持ち、いろいろな偶然が起きる場所に参加して少しでも行動に移していきたいと思いました。
カンファレンスは短い時間でいろいろな知見を得られて、さらに人に会うことができるのが魅力的ですね。
今回も楽しかったです、ありがとうございました！