「RESEARCH Conference Lightning Talk 2026」に参加してきました

地図作りの現在地

武田 透摩さん(株式会社プレイド)

  • 事業戦略 - 施策プロダクト - インタビューの方向性 - アクション
    • リサーチのステップの地図を作っている
    • どのステップでどんなロールの人が何をするか
  • 課題
    • データやツールが分散する
      • ツールが分かれていたり
      • データが微妙に異なっていたり
    • 情報へのアクセスのしやすさ
      • 情報を見つけ出すのが難しい
    • 情報の伝え方
      • アクションに繋がる示唆がないと意味がない
  • 対処
    • キーを統合して統一的にデータをとれるように
    • ダッシュボードだけでなく阻止kの関心に合わせた内容の共有

リサーチの"はじめの一歩"を標準化。やり方やマインドだけじゃなく、法務・経理・CS連携も可視化した、自社専用「リサーチ基本ガイド」作成ウラ話。

不破 昌代さん(株式会社リブセンス)

  • リサーチを始める時の課題
    • 自社でどう動けばいいか分からない
    • 何から手を付ければいいか
    • 意欲があっても動けない
    • 属人化や部署ごとのサイロ化
  • 自社専用のユーザーリサーチのガイド
    • 自社で明日から動けるように
    • 前提理解
      • なぜリサーチするか
      • 定性定量
    • 調査全体設計
      • 目的/手法/スケジュール/体制
    • リサーチ実務
    • 社内手続き
  • ガイドのポイント
    • 意義やマインドを冒頭で丁寧に
  • ガイドを作るのに
    • スコープが難しい
        • 誰のために
        • どこまで書くか
    • 工数が思ったよりかかる
      • パターンが多い
      • リーガルリスク
      • CS/経理
    • 正解を求めてしまう
      • 本当にあってるか考えると止まってしまう
    • まずはその場にいる人たちのために書いた
  • ガイドの展開
    • レクチャー会
    • 1on1伴走
    • 外部で学ぶ

兼業から専任へ。デザイナー出身リサーチャーの過去と現在

村上 輝泰さん(GO株式会社)

  • リサーチャー専任になるまで
    • もともとデザイナー
    • その中でリサーチも
    • Goへリサーチャーとして転職
  • 兼業での学び
    • 自己完結型でスピード感がある
    • 自分で作ったものを調査し改善
    • 難しく考えないのがいい
    • 1人でやらずに他部門とも協力
    • 小さく素早く
  • 専任での学び
    • 事業全体を深く客観的に評価できる
    • 関係者と密な連携ができる
      • 依頼ベースで動くことが多い
      • 何故調査するのか
      • 結果をどう活かすのか
    • ドメインの理解が重要
      • 調査のクオリティに直結する
    • リサーチを広く共有
      • ノウハウがたまっていく
      • 暗黙知になりやすい

AIを叩き台として、「検証」から「共創」へと進化するリサーチ

安達 美貴さん(株式会社LegalOn Technologies)
https://speakerdeck.com/mela_dayo/aiwokou-kitai-tosite-jian-zheng-kara-gong-chuang-hetojin-hua-sururisati

  • AIを使ったリサーチ
    • もっともらしい課題整理ができる
    • ユーザーをみているつもりになっているだけではないか
    • どうやって使っていくといいか
  • AIのいい使い方
    • 仮説の終わりではなく始まりとして使う
    • 結論とはみなさない
    • 不完全なたたき台を作るものとして使う
    • それを土台にプロトタイプの作成とインタビューを繰り返していく
  • 一般論に基づく答えは出せる
  • 特定ドメインの現場で起こっている業務のリアルや文脈までは理解できない
  • AIで変わること
    • リサーチの流れが変わる
    • これまでは仮説をもとにリサーチしてプロトタイプ作って検証
    • これからはAIで素早く仮説を立ててプロトタイプ作って検証していく
  • AIにHowを任せてWhyとWhatに時間をかける

メイキング・オブ ask toitta -リサーチ×AIエージェント開発のリアル

米山 弘恭さん(株式会社はてな)

  • ask toittaのきっかけ
    • 大型の開発を動かせるタイミングだった
    • ワークフローマップとモデルを整理
      • 課題は赤く
      • 因果関係は矢印で
    • マップを読み合わせてみんなで意思決定
    • たくさんのアイデアを戦わせてこの機能をやることになった
    • AIエージェントを使った機能
  • どう作るか
    • インサイトではなくファインディングに
      • ひらめきはAIに委ねずに人がやっていたい
    • エージェントの精度に正解がない
      • 人の手でデータを判断していった

デザインからプロダクトマネジメント領域への挑戦

ひとみさん(NE株式会社)

  • NEXT ENGINE
    • ECのデータ管理
    • 10兆円の市場の10%はこれを通ってる
  • デザイナーからプロダクトマネジメントへ
    • ユーザーに向き合うマインドセットを整える
      • 今までと違うのはみんな同じ
      • 環境を整える
    • ユーザーのことを理解する
      • 毎日小さなリサーチの積み重ね
      • 過去の商談の履歴みたり
      • ドメインの知識をためていく
    • 人を巻き込んでリサーチ
      • 知りたいことが明確になってくる
      • CSやセールスから情報収集

老舗ものづくり企業でリサーチが変革を起こすまで - 三菱重工DXの実践

上田 和明さん(三菱重工業株式会社)

  • 三菱重工でのリサーチ
    • 0-1フェーズ
      • なにが事業価値につながるのかわからない
    • 1-10フェーズ
      • 成功モデルが刺さるか田舎分からない
    • 活動の結果に向き合い続ける
      • 得られた結果からありたい姿に対する評価をする
      • 事業便益がどれほど改善したのかまで

「Database Engineering Meetup #9: NewSQL」に参加してきました

NewSQLユースケース7選

ミックさん

  • NewSQLの本が去年出た
    • これまではTiDB中心の本が多かった
    • この本は複数の製品に対応
    • ユースケースも書いてあるのが特徴
  • NewSQL
    • RDB - NoSQL - 分散クラウドネイティブSQL
    • RDBとNoSQLでトレードオフだったところの両取りができる
      • 水平スケーラビリティ
      • 分散データベース
  • 分散データベース
    • クエリレイヤー/ストレージレイヤーそれぞれで分散
    • プライマリーがない
  • 主要な製品
    • Cloud Spanner
      • PostgreSQL
    • yugabyteDB
      • PostgreSQL
    • TiDB
      • MySQL
    • CockroachDB
      • PostgreSQL
      • 日本法人はない
    • AuroraDSQL
      • 第三リージョンをどこの国に置くかが問題
  • 事例
    • 2020年代に入って採用数が増えてきた
    • 日本も海外も
    • DoorDash
      • 海外のリテールEC
        • UberEatsみたいな
      • コロナ禍で利用者急造
      • CockroachDBに移行して更新負荷をスケールさせる
    • Flipkart
      • TiDBでwrite/read両方の処理を自働でスケール
      • k8s上で動作することで障害児はノードが自働復旧するので可用性高い
    • みんなの銀行
      • Cloud Spannerを勘定系で使っている
      • 東京/大阪でactive-activeにできる
    • Form3
      • イギリスのFinTech系企業
      • A2A決済
      • AWSが利用不可になったらどうするかという規制当局からの指摘
      • 特定クラウドプラットフォームに依存しない体制
      • CockroachDBをAWS/Azure/GoogleCloudのk8s上で動かすようにした
      • 日本ではマルチクラウドはそこまでだが海外だと進んでいる
        • 欧州のように法規制で進む可能性
        • 地政学上の懸念
    • レバテック
      • 増えすぎたデータベースの統合
      • 80人の開発組織で50データベース
      • TiDBの1つのクラスタに統合
      • マイクロサービスはトランザクションが難しい
        • 失敗した時に取り消すパターン
        • これをDB側で担保できるよさ
    • DMM.com
      • 異種混合データベースの統合
        • RDBやNoSQLも
      • TiDBにまとめた
    • Netflix
      • CockroachDBを採用
      • 地理分散で低遅延を

NewSQL: ストレージ分離と分散合意を用いたスケーラブルアーキテクチャ

ぶーとさん(株式会社hacomono)

  • コンピュートとストレージの分離
    • コンピュート
      • ステートレスな計算層
      • クエリパース
      • オプティマイザ
    • ストレージ
      • ステートフルな保存層
      • データの永続化
      • フィルタリング処理
    • なぜ分離したいか
      • ノード追加時の負荷軽減と高速化
        • 既存データのコピー作業がいらなくなる
        • なので負荷が高まる前に事前にスケールしないといけなかった
      • きめ細やかなスケーリング
        • コンピュート層がステートレスなので必要な時に追加削除できる
      • 異なるライフサイクルの分離
        • コンピュート層は負荷に応じてスケールしたい
        • ストレージ層は一定の量が必要
  • 分散合意アルゴリズム(Raft)
    • クラスタで合意した値がくつがえらないことを保証する仕組み
    • NewSQLの中で普及してるのはPaxosとRaft
    • Jepsen Test
    • Raftがやること
      • クラスタのフェイルオーバー
        • クラッシュしても自働でリカバリー
      • データの同期
        • ログレプリケーションとよんでる
        • StateMachineへの命令のこと
      • 一貫性の維持と分断耐性
        • リーダーを必ず経由するモデルで一貫性
        • 分断時にも過半数のノードに届けば動く
    • 役割
      • リーダー/フォロワー/候補者
      • リーダーがクラッシュしたらフォロワーが候補者となり投票の結果リーダーになる
    • スケールの壁
      • 単一Raftの限界
      • データの再文化とリーダーの分散配置
      • Multi-Raft

パネルディスカッション

ミックさん
ぶーとさん(株式会社hacomono)
山田 浩之さん(Scalar)
こばさん(Scalar)

  • NewSQL本当にいるのか
    • 結局はRDBとNoSQLの折衷案
    • 分析系は苦手
    • HTAP
      • トランザクションも分析も
  • DBのどこが好きか
    • SQLのチューニングをずっとやっていた
      • オプティマイザを長くさわってた
    • kvsの層
      • 分散合意
      • 従来不可能だったことを可能にしていくレイヤー
    • スケーラビリティ/アベイラビリティ

サイボウズの自社k8s環境におけるTiDB運用の現在地

渡邉 洋平さん(サイボウズ)

  • TiDB Operator v1では安定運用できてる
    • v2では変更が多い
  • TiDB + TiFlash

Kubernetesでセルフホストが簡単なNewSQLを求めて

nnaka2992さん(スリーシェイク)
https://speakerdeck.com/nnaka2992/seeking-a-newsql-database-thats-simple-to-self-host-on-kubernetes

  • いまどきはHelm ChartsとOperatorが推奨
  • CockroachDBはドキュメント不備が
  • どれも使えるので誤差の範囲

Keycloak を使った SSO で CockroachDB にログインする

kota2and3kanさん

  • Keycloakでユーザ認証してCockroachDBにアクセスできるようにするデモ

「AIネイティブSaaSの現在地 - Carnot x nocall x SmartHR」に参加してきました

スピードと品質を両立するドッグフーディング

金岡 亮さん(株式会社SmartHR Head of AI)

  • AIプロダクトの企画はE2Eで素早く開発しきるのが大事
  • AIプロダクトは高コスト
    • ROIに見合うかの検討が大変
    • 不確実なアウトプットなので実験コストが高い
    • 監視が必須
  • 開発時のモードを切り替えてる
    • 無邪気モード
    • 学習モード
    • リリースモーぢ
  • AI機能
    • 正解を定義できるものとできないもの
      • OCRとかは正解がある
      • レコメンドとかは正解がない
    • 正解のない機能こそ無邪気モードが必要
      • 精度が判断できない
      • よさそう止まりで分からない
    • 精度を考える前に使えるものを作ってしまってユーザ体験を確認できるようにする
    • ドッグフーディングも積極的に
  • 良さそうな機能の解像度をあげて成功確率をあげていく
    • ユーザ価値が分かれば評価データも作れるようになる

Claude Codeではじめる、インフラ構築/運用

後 雄大さん(nocall株式会社 AIエンジニア/SRE)

  • インフラ運用におけるAIエージェント
  • 大事なコンテキスト
    • IaCの整備
    • 適切なログ出力
    • CLI/MCP/Skillsの整備
    • 適切な権限
  • IaCの整備
    • 手動で作られたインフラをTerraform化
    • 本番と検証のAWSアカウントを分ける
    • 命名規則を揃える
    • 本番ではplanまでで実行させない
  • Skillsの整備
    • Sentryのエラーを読み取りどこで問題が起きてるかとか
    • CloudWatchを見たりとか
    • 一般論ではなく具体的な調査手順を書く
  • Cloud環境でのAI整備
    • 人を介さずビジネス側が技術的な内容を確認できるように
    • 環境変数やシークレットを渡せるように設定
    • AWSはread only
      • これすらも常に与えるわけではない
    • SlackでCodexに問い合わせてもらえる環境の整備
    • SentryとCodexで勝手にslack上で議論してほしいがボット同士のやりとりは制限されてる

AIワークフローの基盤技術と業務適用

西森 悠太さん(Jinba Lead Software Engineer)

「ボトルネックを突破しよう!AI時代の品質向上LT会【D-Plus Tokyo #22】」に参加してきました

最強のAIエージェントを諦めたら品質が上がった話

段上 将門さん(株式会社ADWAYS DEEE)

  • AIコーディングでのレビュー
    • 人が何度も修正を依頼してループが長い
    • 一発でマージできるプルリクを出せたら楽なのに
  • AIエージェントに理解してほしいこと
    • プロダクト知識
    • アーキテクチャ
    • 組織のコーディング規則
  • unix philosopht
    • 1つのことをうまくやるプログラム
    • それらを連携する
  • Agent Skills
    • ドメイン固有のタスクに合わせて能力をカスタマイズ
    • Skillsを組み合わせて複雑なワークフローを構築

コードレビューをしない選択

Takuma Kajikawaさん(株式会社TechBowl)
https://speakerdeck.com/kajitack/no-code-review

  • コードレビューがボトルネックになってきている
    • コーディングは並列でもレビューは直列(レビュアーが1人なら?)
  • なぜコードレビューをするか
    • 知識の共有
    • 品質の担保
  • レビュー基準を見直していく
    • 今まではコードオーナーがapproveしてマージ
    • 変更後はレビュー方針に応じてセルフマージ
    • 作成物の性質に応じたレビュールールの使い分け
  • 多層チェックで品質を保つ
    • 型チェック
    • 静的解析
    • テスト
    • AIのレビュー
    • 人のレビュー
  • 人やること
    • コードを見る -> 設計を見る
    • コンテキストを整備する

AIが成長する今だからこそAIができなそうなことを全力でやってみた

平間 良成さん(techvan株式会社)

  • 品質という言葉の広さ
  • 立場によって気にする品質は違う
    • PM/デザイナー/エンジニアの考える品質
    • 経営層の考える品質
  • それぞれの言う品質を定量的に管理できるように
  • 総合的な品質をあげていく

障害対応におけるエージェントスキルを用いた品質改善の取り組み

山田 哲也さん(株式会社リーディングマーク)

  • 障害対応の課題
    • 初動が遅い
    • 人による調査品質
    • 報告書の手間
    • 属人化
  • フロー
    • アラート - ログ確認 - 原因推定 - 復旧対応 - 報告書
    • これらをスキル化してAIにやらせたい
  • Skills
    • 権限を絞って読み取り専用で安全に
    • AWSのリソースを特定できる命名のインプット
    • 報告書のテンプレートを用意してまとめさせる
  • 単純すぎる障害だと却って時間がかかることも
    • 人が見れば秒で分かるやつとかもいろいろ見に行って時間かかる
  • AIに与える権限はしっかりと

「Scrum Fest Fukuoka 2026(Day 2)」に参加してきました

初めて言語化できた、非開発業務へのアジャイル適用の意義 -営業支援ダッシュボード構築の実例から-

Moe Marumotoさん(日本生命保険相互会社)
Yui Tachikawaさん(日本生命保険相互会社)

  • 2024年頃日本生命本体でアジャイル推進開始
    • ニッセイ情報テクノロジーでは実績あり
    • レッドジャーニーの市谷さんが支援に入ったり
  • まずは日々の業務にアジャイル適用
    • 2週間のスプリント
    • カンバンでタスク管理
    • スクラムイベント
    • 短いサイクルを回すことで変化があった
    • 外から見た人によさを伝えるのは大変だった
  • 模擬開発でやってみた
    • 営業支援のダッシュボードをTableauで作る
    • 構成
      • 開発
        • IT部門で採用された人たち
      • PO
        • 現場経験はない
      • ステークホルダー
        • 現場経験豊富なベテラン
        • 忙しい
      • 開発とPOは拠点が離れてる
      • ステークホルダーに気軽に聞ける感じではない
      • ビジネス側の情報が後からITに流れてくる
    • 試したこと
      • プルトタイプをベースに会話
      • 短いサイクルで見せていく
    • 進めていく中での悩み
      • アジャイル的に正しいのか
      • SMとしてどうやるべきか
      • チームとして何が課題でどう変えていくか
  • 実開発へ適用
    • ハピネスナビ
  • 2026/4アジャイルCoE設立
    • ルールの整備
    • 案件拡大

AI駆動で爆速開発した結果、スクラムを形骸化させた話 〜「教会を建てる」目的を忘れたレンガ職人の反省記〜

Kenta Uwagawaさん

  • 受託時代の成功体験
    • お客様の期待を超えることが正義だった
    • 圧倒的当事者意識で
    • これがあれば便利を形にしていき感謝してもらう
  • AIで作れるようになった
    • AIと対話して進めていける
    • 動くものがどんどんできる
    • ただ、それで何が解決するのかというものができてしまった
    • 誰も日常的に使わないきれいな何か
  • AI駆動開発での対話の省略
    • 考えて実装するのサイクルが超高速に
    • 超短期間のスプリントを回してるような
    • 今まで大事にしていたイベントが省略される
    • 教会をたてる感覚ではなく高速にレンガを積む作業になっていた
  • AI時代だからこそスクラムイベントを再定義
    • AI駆動とスクラムの両輪
    • 開発は拘束してるがサイクルは変わらない
    • 新しい高速なスクラムイベントの再定義

System Fixer-組織へシフトレフトするQAの或り方

やまずんさん(testingOsaka)
https://www.docswell.com/s/55_ymzn/ZPR8G1-scrumfukuoka2026

  • System Fixerという動き方
    • 組織や仕組みの関係性としてのシステム
    • 単に戻すのではなく新しく組み直す
  • 事例
    • クレーム対応のチェックリスト
      • そのルールは昔からあって誰がオーナーかもわからない
      • その仕組を変えに行く
    • 部門を跨いだ問題
      • ある部門が認定しないと問題として扱われない
      • それが問題かどうか判定するのが属人化していて明白でない
      • アホになって何もわからないという場面
      • 現行踏襲したうえで明確さを提案していく
  • 手段を選ばずにシステムを再構築していく
    • でも苛烈になりすぎると自分自身も破綻していく
    • 自分の道徳心を大事にして照らし合わせて

モブプログラミング再入門 ― AI時代のチーム設計 ―

Takao Oyobeさん(HoloLab Inc.)
https://speakerdeck.com/takaking22/a-re-introduction-of-mob-programming

  • AIによってボトルネックが人の理解に移った
  • AI前後での変化
    • イメージは、コーディングフェーズが純減してその分はやくなると想定されがち
    • 実態は、AIに任せる前後のフェーズでAIのための作業が増えた
      • 仕様書を作りながらではダメでしっかり理解し作らないといけない
      • AIを動かした人にチェックがあるしその後のレビューも今まで通りある
  • SECIモデル
    • 暗黙知と形式知
    • 共同化 - 表出化 - 結合化 - 内面化
    • 形式知になってる結合化はAIによる代替可
    • 表出化と内縁可はAIによる支援可能
    • 暗黙知の共同化はまだ人のやること
  • AIを使っても人が時間をかけているところ
    • 暗黙知-暗黙知の人がやるところ
    • 今までもコードを書くところがボトルネックになっていたことはなかった
    • 昨今抱える問題はAIによって新しく出てきたわけではない
  • モブプログラミング
    • 同じ仕事を同じ時間に同じ空間で同じ環境で
    • ドライバー:キーボードをたたく
    • ナビゲーター:問題を考える
    • 交代しながら進める
    • ドライバーが考えて作業するのを見る取り組みではない
    • プログラミング以外でやってもいい
      • モビング
      • モブワーク
    • 分担作業との比較
      • 分担するための同期する作業も発生している
      • 設計とかレビューとか
      • 認識連れがあったら手戻りもある
      • 誰がやっても同じ結果になるような単純なものならこっちでも
    • モブプロは常に同期しながら進める
  • AI時代のチーム
    • チームが2,3人に小規模化
    • クロスファンクショナルに
    • モブプロがやりやすい環境
      • 人数が少ないから全員の時間を使うという抵抗がちいさくなる
      • いるメンバーで完結できるようになってきている
    • 仕事の中心が開発から理解へ
      • 理解したいのは個人ではなくチーム
      • 一緒にやることで暗黙知も形式知もまとめて共有できる
  • AIで空いた時間に何をするか
    • AIの結果を待ってる時
    • AIによって早く終わった時
    • 空いた時間で何をするかを空いた時間にチームで考えて実行する
      • チームとして判断し実行していくこと

Syncでつながるアジャイル ― 部署の壁を越えて進化し続けるチームづくり

Hiromi Takahashiさん(Mitsubishi UFJ Information Technology, Ltd.)
https://speakerdeck.com/muit/agile-practices-connecting-and-syncing-beyond-departmental-boundaries

  • 金融システム
    • システムのライフサイクルが長い
    • データのライフサイクルも長いから
      • 住宅ローンが35年とか
      • 50年の社債ちか
    • 銀行統合などの開発需要増に寄る対処
      • 内製では回らないので外注中心に
  • MUITでのアジャイル開発
    • 2014年ころから始動
    • 2021頃から大規模システムでも取り組むように
    • 2025/2にMUFGでのアジャイル運営を開始
  • エンタープライズでのアジャイル
    • 自己管理型の難しさ
      • POが決めたことをその上位層にひっくり返される
    • 3ヶ月とかの長いスプリントに
      • 真の決定権を持った人の声で話してもらう
      • プラットフォームやセキュリティなどの関係者にも参加してもらう
      • その中で2週間サイクルでのチームの活動
  • アジャイル推進部署
    • 採用や評価の見直し
    • 研修の企画推進
    • 開発プロセスなどのルール
      • 品質評価
      • 権限委譲
  • 社内外コミュニティ
    • 社内アジャイルコミュニティ
      • 毎週30分の意見交換/相談の場
    • 部長層以上全員へのアジャイル研修
    • アジャイルスクラム関連の外部イベントの参加推進
  • Respect(敬意)/Sync(同期)/Persistence(継続)

契約形態を超えた一体感!業務委託メンバーを巻き込むチームビルディングで自律したチームを創る

Kyohei Somaさん

  • チームの見えない壁
    • 所属会社の異なるメンバーがいるチーム
    • 沈黙する対面レビュー
      • 一部の人しか発言しない
      • 知識差で噛み合わない
  • チームビルディング
    • チーム名を決める
      • これまではスクラムマスターの名前でxxさんチーム
    • バリューズカード
      • 各人の価値観を知る
    • 偶然の出会いを作る
      • 毎日ランダムに席替え
    • 業務外でのコミュニケーション
      • チームでランチ
      • 飲み会
  • チームの変化
    • 発言が増えた
    • 雰囲気の変化を感じるようになった
  • 学び
    • チームの問題を発見分生起することの重要性
    • 第三者視点で時間をとって考える

聖域を失う恐怖と向き合う - 恥をポジティブに受け入れるための考え方

Takehiro Nagashimaさん(TOKYOGAS)
https://speakerdeck.com/naga8naga/sheng-yu-woshi-ukong-bu-toxiang-kihe-u-chi-wopoziteibunishou-keru-rerutamenokao-efang

  • 弱みを見せること
    • 会話は解決できない問題をお互いに共有し共感し合うこと
    • 登壇資料を作るのに苦労話や弱みを入れた方が仲間ができていく
    • それがチームで動くことに役立っていく
  • 「いくつになっても恥をかける人になる」
    • 電通の人の本
    • 責任を追わない限り恥を書くことはできない
    • 自分で考えて責任をもってチャレンジできてる証拠
    • 迷ったら恥ずかしい方を選ぶ
    • 恥という感情をポジティブに受け止める
  • 「嫌われる勇気」
    • 人間の悩みは対人関係からくるもの
    • 対人関係のゴールは共同体感覚
    • 評価の軸を他者の目から貢献感/しょぞくかんへ変える
    • 恥と思っても自分は共同体の一員で何か役に立ってる
  • 恥をかく恐怖はある
    • 共感やつながりを生むというポジティブな面に来づけるようになった

AI×スクラムの「新・セオリー」を探す旅 — AI推進派の二人が直面した、予想外のジレンマ

Hiroki Hachisukaさん(Newbee inc.)
Yusuke Amanoさん(スクラムフェス仙台)

  • 1.「固定長スプリント」は足枷になり得るのか?
    • スプリントより早く作れてしまう
    • スプリントのリズムで計画/振り返りをするのは重要
      • 計画づくりは必要なのでプランニングは重要
      • レトロスペクティブで手を止めて方向性が正しいか振り返らないと
    • スクラムのお作法を守っている開発より守ってないバイブコーディングをひたすらユーザに見せる開発の方がいいものを作っている
  • 2.「バックログ爆発」とリファインメントの皮肉
    • 見積もりをして先の見通しを立てるのに時間をかけてるのはもったいなくなってる
    • 受け入れ条件をしっかりかければAIに渡して作れる
  • 3.「職能横断」の完成と、役割の消失
    • dev/SM/POの境界が溶けていく
    • ポジティブな意味で境界の撤廃
    • T字のように専門性の柱がない状態でやれるのか
    • 開発を超えたファンクショナル
      • 営業とか
    • 人との接点を最大化する
      • 開発の人数は半分にして他の職種に回した方がいいのでは
    • チームしか見れないSMはいらなくなる
      • そのロール入るけど選任するのは手厚すぎ
      • 組織に対する還元もできるような人じゃないといらなくなる

チェックリストの正体に迫る!

Yutaka Kameiさん(タイミー)
https://speakerdeck.com/yykamei/tietukurisutonozheng-ti-nipo-ru

今いい感じのチーム構成と営み2025冬 〜Scrumっぽいけどチョット違う形〜

Kenta Sasaさん(クリエーションライ)
https://speakerdeck.com/sasakendayo/jin-iigan-zinotimugou-cheng-toying-mi2025dong-scrumtupoikedotiyotutowei-uxing

あの日諦めたスクラムの答えを僕達はまだ探している。〜守ることと、諦めることと、それでも前に進むチームの話〜

手島尚人さん(マネーフォワード)
https://speakerdeck.com/tosite/2026-03-07-anori-di-metasukuramunoda-ewopu-da-hamadatan-siteiru-shou-rukototo-di-merukototo-soredemoqian-nijin-mutimunohua

大規模開発組織の縦割りサイロを壊したチームを立ち上げるためにやったことはほとんど『FearlessChange』と『スピード・オブ・トラスト』に書いてあった

Wataru Seinoさん(KDDI株式会社)
https://speakerdeck.com/say_no_w/scrumfes-fukuoka-2026-trust

同僚を社外コミュニティに誘うのは楽しいからだけじゃないよね。あなたは、なぜ同僚と社外コミュニティに参加するのですか?私は組織を良くしたかったからです。そんな私が同僚と社外コミュニティに参加するときに気をつけていること話すよ。

Yusuke Ohiraさん(ログラス)
https://speakerdeck.com/camel_404/tips-to-onboard-colleagues-into-communities

反応する前に「受容する」力を鍛える。 自分の安全地帯🌱 を育てよう

https://speakerdeck.com/spring_aki/cultivating-and-sharing-ventral-vagal-safety

その新人研修でアジャイルなマインドセットは「取り戻せた」のか?

https://speakerdeck.com/chinmo/designing-new-employee-training-to-reclaim-the-agile-mindset

「Scrum Fest Fukuoka 2026(Day 1)」に参加してきました

感想

  • 基調講演はすごい情報量でしたがあっという間で多くのことを考えさせられました
  • さまざまな勉強会で年に数百件は話を聞いているけどここ数年で一番自分にささる内容でした
  • アーカイブが出たらまた見たい

挑戦を、楽しめ。 定員割れ高校を変えた「挑戦する文化」のつくり方

柴山翔太さん(福岡女子商業高校)

  • 教員として
    • いい教育とは何か
    • 教育の歴史を知ってるか
    • 最新の教育を知ってるか
    • 世界の教育を知ってるか
  • 他の職種でも当てはまる話
  • 当たり前を捨てる
    • アンコンシャスバイアス
  • 全員校長のつもりで働く
    • 何のためにを常に考える
    • 全員が当事者意識として
  • 定員充足率40%超の私学
    • 教員や生徒の矢印の方向
    • どうせできないと思っていた
    • 他責思考/自責思考
  • フィックスドマインドセット
    • 能力は生まれつき
  • グロースマインドセット
    • できるかどうかは頑張り次第
  • マインドセットは人に移る
  • 一部しか見えてないのにそれを正しいと思ってしまう
    • それで諦めモードになってしまったり
  • 対話の心得
    • 私たち
    • 耳を済ませる
    • 否定せず断定しない
    • 答えは1つじゃない
    • 沈黙を歓迎
  • 挑戦と批判はセット
    • 何かを挑戦すると何かしら批判は必ずくる
    • 批判に影響されすぎてはダメ
  • 自主性と主体性
    • 言われたことを自分からやる
    • 何をやるかやるかどうかも自分で決める
  • 試行 - 経験 - 省察 - 概念化
  • コンフォートゾーン - ストレッチゾーン - パニックゾーン
  • 問いかけのモード
    • フカボリモード
    • ユサブリモード
  • 日本のリーダーは無免許運転
    • 肩書はついててもそれについて学んでいるのか
  • ストーリーテリング
    • メタ認知
    • アナロジー思考
    • リフレーミング
  • 人事評価
    • 影響力
    • その人が入ることで周囲はポジティブに感じるのか
  • トップダウンとボトムアップ
    • 景色が見えてたらトップダウン

「ソニーとコクヨが当事者と協働したインクルーシブデザイン|A11y Tokyo Meetup」に参加してきました

ソニーとコクヨが当事者と協働したインクルーシブデザイン

藤木武志さん(コクヨ株式会社)
湯山恭男さん(ソニーグループ株式会社)

  • インクルーシブデザイン
    • 多様なユーザを巻き込んで一緒になって開発していく
    • コクヨもソニーも力を入れてる
  • CROSSING VIEWS
    • コクヨとソニーは品川でオフィスが隣同士
    • 共同でイベントを開催
  • 両社の交流
    • コクヨとソニーのデザイナーでワークショップ
    • 両社のデザイナーとリードユーザも含めて観察から議論まで
    • その後プロトタイプの開発まで
    • 対話を通じて両社のデザイナーのスキルを合わせてプロトタイプを作った

「チームプロジェクトマネジメントとPMBOK第8版(Agile in Motion vol.6)」に参加してきました

プロジェクトマネジメントをチームに宿す

森實繁樹さん(レッドジャーニー)

  • プロジェクトマネジメントの視点
    • PMが頂点に立って計画を立て導いていく
    • 完遂することに意味がある
  • 組織マネジメントの視点
    • あらゆるケイパビリティを持って貢献してほしい
    • 本人が育つことに意味がある
  • 完遂する方法
    • チームで達成してもいい
    • チームのメンバーが力を発揮できる状況を作る
  • 旧来のプロマネとチームプロマネ
    • 型をただ守ることにこだわらない
    • 説明責任はPMにあるが実行責任はチームに
  • プロジェクトは人と関係性
    • 小さなリーダーを増やして役割を明確にし支え合う
  • 万能なやり方は存在しない
    • 状況に応じた役割設計とリーダーシップの共同所有
    • 個人の役割じゃなくて自分たちの役割
  • 価値は成果物ではなく変化
    • 段階的な複数ゴール
    • 前に進みながらバックキャストして見ていく
    • アウトカム志向で継続的価値創出

PMBOK第8版は第7版から何が変わったのか(PMBOK第8版概要解説)

渡会健さん(SHIFT)

  • PMBOKガイド
    • ソフトウェア専用ではない
      • 有期的な独自のものを作るプロジェクトで活用できる
    • ウォーターフォール専用ではない
      • 古くは世の中がウォーターフォールメインだからそうだった
      • 今は世の中の変化もあって変わっている
      • プロジェクトを成功させるためのものだから手法にとらわれないように
    • 5つの原則
    • 10の知識エリア
    • 49のプロセス
    • input - tool - output
    • 予測型と適応型の二元論ではない
  • 6〜8版
    • 6版は辞書のようでウォーターフォール向け
    • 7版で柔軟なないようになり判断を自分たちでするように求めた
    • 8版で中間的なところに整理された
    • 世の中の状況に合わせてアップデートされてる

対談:プロジェクトを始める前にやるべき大切なこと/それぞれの修羅場を乗り切った体験談

森實繁樹さん(レッドジャーニー) 渡会健さん(SHIFT)

  • 社内標準規程
    • 歴史があるほど古いバージョンのPMBOKを参考にしてる
    • PMBOKはアップデートされてるのにそれらは変わっていかない
    • 変えるの大変だし日々の業務も変えないといけない
    • でもそれを怠ってるから時代に遅れていく
    • エンジニアリングは日々進化してえるのにマネジメントはスピードについていってない
  • 自社開発とSI開発
    • 自分事として捉えられればあどちらも同じはず
    • 作るのを依頼する人と依頼される人の上下になってるのはよくない
    • ビジネスのプロと技術のプロが一緒に作るもの

「Engineering Management Conference Japan 2026」に参加してきました

冒険する組織のつくりかた

安斎勇樹さん(株式会社MIMIGURI)

  • ビジネスは戦争である
    • 戦略/戦術/軍の統率/領地の独占
    • 経営論は軍事的な世界観(1940年代)
  • キャリア観の変化
    • 会社中心で自分の人生がその中にある
    • 自分中心で人生の中に会社がある
  • 軍事的世界観 -> 冒険的世界観
    • 戦略計画の遂行
      • そのための管理/調達/育成
    • 社会のミッションの探求
      • ひとりひとりの自己実現の探求
  • 組織文化の型
    • 外部志向 - 内部志向
    • 統率正(権力) - 柔軟性(感情)
    • 軍事的文化/完了的文化/冒険的文化/家族的文化
  • 半径5mからできるマネジメント
    • 目標のマネジメント
    • 会議のマネジメント
    • 興味のマネジメント
    • 文化のマネジメント
  • 目標のマネジメント
    • 集団のパフォーマンスへの影響
      • 個人やチームにどのような目標がせていされてるか
      • それをメンバーがどう受け止めてるか
    • 軍事的マネジメントは視野を狭窄させて目の前のことだけをやらせる
    • 目標はSMARTの法則で
      • これは管理側の都合で整理されることが多い
    • ALICEの法則も(Adaptive/Learningful/Interesting/Visionary/Experimental)
      • 意味づけして内発的動機付けになるように
    • 目標設定の前と後のコミュニケーションが大切
      • 前:メンバーの意見を踏まえる/対話しながら考える
      • 後:前提や意図を丁寧に語る/取り組む意味をチームで対話する
      • 内発的動機を持てるように
  • 興味のマネジメント
    • 興味格差の時代
    • 興味のツボに刺さると目標がALIVEになる
    • 個別のX年後の目標を起点に育成するのが困難な時代
      • やりたいことを聞かれても将来のビジョンは難しい
      • willハラ
    • 眠ってる興味や好奇心を手掛かりに
      • これを把握し言語化出来てる人は少ない
      • ヒト寄りかとコト寄りか
    • 興味スタイル
      • 想像/解明/介入/運用とヒト/コトの掛け算
  • 会議のマネジメント
    • マネージャーが問いかけても反応の薄い会議
      • 何かないですか?を聞くだけじゃなにも聞き出せない
    • 問いかけの工夫がされるだけで変化がある
    • 「特にないですね」を誘発する問いかけに注意
    • オープンクエスチョンは答えるのが難しい
      • 点数をつけるとか選択肢があると具体的な回答が得られやすい
  • 文化のマネジメント
    • 風土
      • 集団の雰囲気やイメージ
      • メンバーがどう感じてるか
    • 文化/カルチャー
      • 他の組織には見られない
      • その組織固有の価値基準
      • 価値基準の集合体
    • 風土の改善だけでなく文化を耕す

「事業目線」の正体

sotarokさん
https://speakerdeck.com/sotarok/shi-ye-mu-xian-nozheng-ti-3tunohuezunoctojing-yan-karajian-etekita-emgachi-tubekishi-dian-at-emconf-jp-2026

  • マネジメント
    • 自組織のアウトプットを最大化する
  • エンジニアリングマネージャー
    • エンジニアの専門性との掛け合わせ
    • 事業を成功に導くためのマネージャー
    • 事業目線は必要
  • 事業目線
    • 経営目線
      • 売上/利益/コスト/戦略
    • お客さま目線
      • 価値/体験/使いやすさ
    • 事業
      • 営業マーケ/CS運用/管理部門/事業開発/プロダクト/・・・
      • エンジニアリングはプロダクトが主に関わるところ
    • 事業目線を持っていると自分の視点と他の立場の視点が接続できて関係性を理解できる
  • レベル1:数字を知る
    • 自組織に関わる数字を知る
      • トラフィック/売上/ユーザ数/登録数
      • 見えないものは考えられない
    • 事業予算の構造を知る
      • 売上目標 - 実現するための施策 - 各部門の役割
      • 自分の部門はどこに作用してるのか
    • 今日見てる数字は過去の意思決定の結果
      • 明日の問題を解決するために今日何をするべきか
  • レベル2:お客さまと隣接組織を知る
    • 数字が教えてくれるのは結果
    • お客さまを知る
      • 数字の裏にあるなぜの理解を深める
      • エンジニアとしてどう解決できるか
      • 出来ない時はそれがなぜなのか
    • 隣接組織を知る
      • 組織によってフローも力学も違う
      • ものを作るだけでなく組織運営も見えるようになる
  • レベル3:戦略に反映する
    • 知ったことを自組織の戦略に反映
    • ソフトウェアが事業に与える影響
    • 何を作っているかを理解したうえでの体制づくり
    • 自分の組織のアウトプットを高めたい
      • 自分だけが事業目線を持っていてもダメ
    • 仕組み化が必要
      • ダッシュボードなど数字が常に見える仕組み
      • CS研修を組み込む
  • 事業目線の正体
    • 自分の立場から事業の全体像へ接続できている状態
    • 全部出来なくても自分のチームにとって重要なところから
    • 全体像を理解した上でどこからやるか

ストレッチゾーンに挑戦し続ける

ぎーにょさん(Sansan)
https://speakerdeck.com/sansantech/20260304-1

  • ストレッチゾーンへの着目
    • 複数のエンジニアがキャリアの停滞感から退職申し出
    • 停滞感をうまないこともマネージャーの責務
  • ストレッチゾーン
    • コンフォートゾーンとパニックゾーンの間
    • もっとも成長しやすい領域
  • ストレッチゾーンがない時 適なチャレンジが分からない
      - Will/Can/Mustを言語化
      - Willをうまく言語化できるとは限らない
      - Willを言語化できないとMustと噛み合わずアクションできない
      - 具体と抽象のリフレーミング
    
    中で自然消滅しそう
      - 目標を立てる
      - 本当にストレッチなら不安がつきまとう
      - コンフォートゾーンの誘惑を断ち切るための武器になる
      - SMARTにたてる
          - 野心の低い設定にならないように
          - 忙しくて取り組めなかったにならないように
      - FASTにたてる
          - SMARTでカバーできない要素
    
    • 外部要因が阻害しないか
      • 実行を支援する
      • 権限移譲を明確に
      • 自分で決めていいのかわからないがアクションを阻害する
  • スケールさせるために
    • マネージャーがボトルネックになってしまう
    • そうならない仕組み作りは難しい
    • システム思考

守る「だけ」の優しいEMを抜けて

mitsuiさん
https://speakerdeck.com/maroon8021/shou-ru-dake-noyou-siiemwoba-kete-shi-ye-totimuwoliang-fang-jian-rushi-dian-woshen-nituketahua

  • 崩壊寸前のチーム
    • 入社してすぐ、退職や異動でチームが不安定に
    • 社歴長いメンバーが不在で日々のオペレーションで精一杯
    • 生存するための盾
      • 外部からの依頼を絞り込む
      • WIPを極限まで絞る
      • 対話とモブプロで知識共有
    • その間にヒトも増やして立て直し
    • 守りがうまくきいた
  • 転換点の時代
    • 新規プロダクト
      • 過酷なロードマップ
      • 急造体制
      • ドメイン知識のかたより
    • じっくりチーム組成したくても待ってくれない
    • 信じていたEM像
      • サーバントリーダーシップ
      • ビープルマネジメントの徹底
      • ボトムアップの組織
    • 特定領域だけにこだわった弱めのEMだった
    • 支援が停滞に変わる
    • 変えたこと
      • 合意形成から即断へ
      • 采配と調整を一手に
      • 設計の初動を引き取る
    • 変えなかったこと
      • スクラムイベントのリズム
      • 1on1と毎日のチーム相談会
      • 重要昨日の実装はメンバーに
  • 守るところと攻めるところのトレードオフ
    • 事業の推進とチームの健全さ/負債の解消
    • その意思決定に企業価値があるかどうかで判断するといい
    • DCF法
    • リスクが積み重なると企業価値を削っていく

「開発生産性」ではなく「事業生産性」こそが本質

江副廉人さん(株式会社ワンキャリア)
https://speakerdeck.com/onecareer_tech/kai-fa-sheng-chan-xing-dehanaku-shi-ye-sheng-chan-xing-kosogaben-zhi-roicdeniu-jie-ku-kai-fa-no-jia-guli-nozui-da-hua

  • 働く意義
    • 株式会社で働くこということ
    • 投資家から資本を集めて事業活動を通じて価値を最大化する
    • そのサイクルを回す
    • 投資家による資本で周ってる
    • 投資家の求めるリターン
      • キャピタルゲイン
      • インカムゲイン
    • キャピタルゲイン
      • これを生むのは
      • 企業価値の向上 - 株価上昇 - キャピタルゲイン
      • 将来生み出されるフリーキャッシュフロー
    • フリーキャッシュフロー
      • 利益によって会社が自由に使えるお金
    • DCF法
      • 将来のFCFを現在の価値に割引いて企業価値を算出
    • ROIC
      • FCFは結果に過ぎない
      • それだけだと現場がどう動いていいかは難しい
      • 投下資本に対する利益率
      • 事業生産性
  • 開発生産性の罠
    • 開発生産性のレベルは順に上がるわけではない
      • 仕事量の生産性 - 期待付加価値の生産性 - 実現付加価値の生産性
      • 開発チーム - プロダクト開発組織 - 事業部門全体
    • AIで生産性が上がっているのか
      • 生産量は増えている
      • でもそれは事業の生産性/ROICに直接つながるわけではない
    • 開発者としてROICをどう高めるか
      • 開発/運用コストを下げる
      • 雨天資本や固定資産を下げる
  • ROICを意識した取り組み
    • ソフトウェア資産に計上する開発の管理
      • エンジニアが投資対効果を説明
      • 作る活動にとどめず事業成果と結びつける視点を強化
    • 財務知識の向上
      • マネージャー対象に隔週で財務勉強会
      • DCF/ROE/ROA/ROICなどの指標の理解
      • 投資家目線/経営者目線の事業や開発の捉え方
    • 開発スピードの向上
      • 全工程にAI活用
      • 品質を維持しながらリードタイム削減

AI時代、mentoが考えるマネジメントのサクセスとその実践

松山勇輝さん(株式会社mento)

  • AI時代
    • アウトプットは激増
    • アウトカムは微増
  • エンジニアリングの現状
    • 全職種が直面する未来の予告
    • 「スタートアップ x エンジニアリング」が最前線
    • 非エンジニアやエンタープライズは少し遅れて来る
  • 次世代のマネジメント
    • AIエージェントをロングランできる工夫
    • セキュアにするためのサンドボックス環境
    • skillやCLAUDE.mdでの振る舞いコントロール
    • -> これらは本質的に自律化の支援でチームマネジメントと同じ構造
  • グローバルトレンド
    • スパンオブコントロールの拡張
    • 人の意思決定がボトルネックになる構造で階層を減らしてフラット化
    • グローバル企業では進んでる
    • フラット化はマネージャーを追い詰める
      • マネージャーのエンゲージメントは過去最低
      • 仕事の中断頻度は2分に1回という調査
  • EMは全社を救う先行事例
    • 最前線でAIによる高速な意思決定の渋滞を体感している
      • 全マネージャーにいかしていくことができる
    • 戦略的に余白を作り出して時間の使い方を変える
      • メンバーが自律的に行動する支援
      • マネージャーの労働力がボトルネックにならないように
    • 組織に意図のデータを落とす
      • マネージャーのコーチングスキルに依存していたところ
      • 動機のデータを落としていく
    • わがごと化された目標
      • 自律性につながる
      • フラットな組織になっていくとマネージャーが全員と向き合うことが現実的じゃなくなる
      • メンバー自身が目標に継続的に向き合ってフィードバックサイクルを回す
    • マネージャー自身が時代に合わせて行動を変える

組織崩壊と向き合う技術

山元亮典さん

  • 組織の変遷
    • 従業員が半数になるような崩壊が2回
  • 組織崩壊1
    • 資金調達で採用拡大
      • ハレーションで31名が14名に
      • 評価制度が整ってなかったりマネジメントが機能してなかったり
    • 制度設計やエントリーのマネジメントを改善
      • 評価制度刷新
      • 現状を理解して入社してもらう
      • 選考でオフィスに来てもらって現場の人と交流してもらう
  • 組織崩壊2
    • 新規事業の立ち上げで失敗
      • 55名が27名に
      • 権限移譲が機能せずコミュニケーション不全
      • 失敗後の改善も回せてなかった
    • 社長がトップダウンな体制を変えることを決意
      • プロダクト中心の執行
      • 経営陣の採用
      • これまでとシナジーの高い新規事業に注力
      • 売上は過去最高に
  • 学び
    • 組織は教科書通りにやることが大事
    • その中でも組織崩壊は起きる
    • 30人の壁50人の壁
    • 上手く言ってる時はいいが上手く言ってないと小さな違和感が積み重なって崩壊につながる

EMからVPoEを経てCTOへ:マネジメントキャリアパスにおける葛藤と成長

yunon_physさん(カケハシ)
https://speakerdeck.com/kakehashi/emtocto

  • 経歴
    • EM -> VPoE -> CTO
    • チーム -> 組織 -> 経営
    • 抽象度が高い問題を解決する場面が増える
    • 役割が変わると無能感が出てしまう
    • その正体は問の変化
  • EM
    • 目の前のチーム課題にどう向き合う
    • Product/Project/People/Tech
    • 課題解決から仕組み作り
    • 目の前の課題解決 -> 課題解決の再現性 -> 新しい課題に対しこのチームで解くべきか考える
  • VPoE
    • どのチームでどの課題を取り組むか
    • 組織のルールやガイドライン
    • 新陳代謝をどう促す
    • 組織の崩壊を守る面
  • CTO
    • 2年後に売上を最大化するためにどこに投資するか
    • 3ヶ月でプロジェクトを立ち上げるために何を許容するか
    • どんなリスクを許容すると成功率があがるか
    • 自分の後ろには誰もいない
    • 責任の重さ
  • 向き合った課題
    • インシデント対応関連に20%使っていた
    • どこまで仕組み作って対処すればいいか分からない
      • チェックリスト増やしてもスピードが犠牲になる
  • 役割の変化
    • 体系的な知識をつける
      • MBA
      • 受託者責任
    • 小さくリスクを取る
      • プラスは見えづらくマイナスは見えやすい

AI Coding の先にある、Engineering Manager の本当の仕事

藤倉成太さん(キャディ株式会社)

  • ソフトウェアの価値
    • SaaS is dead
    • AIがどれだけ進化してもグラデーションの間を埋めることは必要
  • 革新的な技術
    • まずは人間の作業を代替
      • この段階ではマクロ経済では大きなインパクトはない
    • 新しい技術を前提にした何かしら
      • これが出ると革新的に変わる
  • 開発チーム
    • チームのサイズは小さくなっていく
    • 能力が一緒であれば人はたくさんいた方がいい
    • エンジニアに求められる能力が変わるから小さい方がいい
    • エージェントを管理して判断し責任をとる仕事
      • しんどい仕事
      • 1人のエンジニアに負わせるのは重い
      • できるだけ複数人がいい
    • 2,3人くらいになっていくのが妥当
    • いろんな職種でワンチームだった
      • 意思決定するだけになっていくから役割分担する意味が減ってくる
  • エンジニアリングマネジメント
    • プロジェクトマネジメントは相対的に重要性は下がる
    • 技術のマネジメントは一定のレベルでみんなかけるようになってくる
    • 人のマネジメントは重要なまま
    • 開発のスループットをいかにあげていくか
    • 向き合うべきチームのサイズ
      • 人数が減るから複数チーム見ることになる?でもその負荷は今までよりも大きい
  • 責任を引き受けるマネジメント
    • 未来を予想することに意味があるのか
    • アンテナ高くはって取り込んでいく

自律型組織の真実:『甘い自走』を捨てて導いた、EMによる戦略的組織変革

masayasu-sanoさん
https://speakerdeck.com/dip_tech/zi-lu-xing-zu-zhi-nozhen-shi-gan-izi-zou-woshe-tetedao-ita-emniyoruzhan-lue-de-zu-zhi-bian-ge-final

特定領域から複数領域へ、そのとき何を求められるのか?縦と横、2つの影響力:統合型を目指す大規模な開発組織での実践

朝妻慶太さん(freee)
https://speakerdeck.com/keitatomozawa/te-ding-ling-yu-karafu-shu-ling-yu-he-sonotokihe-woqiu-merarerunoka-zong-toheng-2tunoying-xiang-li-tong-he-xing-womu-zhi-suda-gui-mo-nakai-fa-zu-zhi-denoshi-jian

スーパーマンに頼らない"分権型組織"で作る強い開発チーム

三谷昌平さん(スマートバンク)
https://speakerdeck.com/shoheimitani/committee-system

経営と会計とエンジニアリング

前田和樹さん
https://kzk-maeda.github.io/event-slides/20260304_emconf/#/1

マルチロールEMが実践する『組織のレジリエンス』を高めるための組織構造と人材配置戦略

川崎雄太さん(ココナラ)
https://speakerdeck.com/coconala_engineer/marutiroruemgashi-jian-suru-zu-zhi-noreziriensu-wogao-merutamenozu-zhi-gou-zao-toren-cai-pei-zhi-zhan-lue

技術的負債の泥沼から組織を救う3つの転換点

nwiizo さん(スリーシェイク)
https://speakerdeck.com/nwiizo/ji-shu-de-fu-zhai-noni-zhao-karazu-zhi-wojiu-u3tunozhuan-huan-dian

トップマネジメントとコンピテンシーから考えるエンジニアリングマネジメント

山口徹さん(タイミー)
https://speakerdeck.com/zigorou/totupumanezimentotokonpitensikarakao-eruenziniaringumanezimento

マネージャー版 "提案のレベル" を上げる

小西裕介さん(Kyash)
https://speakerdeck.com/konifar/maneziyaban-ti-an-noreberu-woshang-geru

開発組織の課題解決を加速するための権限委譲 -する側、される側としての向き合い方-

藤井大祐さん(SEN株式会社)
https://speakerdeck.com/daitasu/kai-fa-zu-zhi-noke-ti-jie-jue-wojia-su-surutamenoquan-xian-yi-rang-suruce-sareruce-tositenoxiang-kihe-ifang

組織・文化・技術の壁に挫折したEMがアーキテクトとして「構造化思考」を手に再び保守開発組織の変革に取り組む

おだかとしゆきさん
https://speakerdeck.com/jgeem/ex-architect-em-driving-organizational-change

DX Improvement at Scale

浅野潤さん(Mercari/Merpay)
https://speakerdeck.com/ntk1000/dx-improvement-at-scale

「VibeCoding特集 from SoftwareDesign 2月号」に参加してきました

Software Design 2026年2月号 VibeCoding完全攻略

  • 執筆から3ヶ月たって
    • skillsの普及
      • マーケットプレイス
      • そこに上がってるものにセキュリティ的脆弱性
      • プロンプトインジェクション
    • Harness Engineering
      • 長時間回すような工夫
      • 並列に
      • 人間の負荷も増えてるがAIの自律性が高まってる
    • 人間フレンドリーにこだわることが増えた
    • Opus4.5が出た
      • コードを見なくてもいい場面が増えた
  • CLAUDE.md
    • コードを見て分かることは書かない方が良い
    • 300行を超えないようにするといい
    • 多段階で参照できるように?
    • skillsから知識は持ってってもらうように
    • ソースコードのコメントに書いた方がいいものも
    • 関数の外じゃなくて中にコメントを書くとか
    • ファイル名で検索されるから名前がだいじ
  • コンテキストの圧縮
    • plan.mdに書かせておけばあ圧縮したあとも大事なところは覚えておける
    • 今まで隠してたものを人も読める状態で出してくれるようになった
  • 仕様駆動開発
    • ラルフループ
  • プランモード
    • 中間生成物を見えるところに置いてもらう
    • それをしっかりレビューする
    • プロンプトエンジニアリングのプロンプトを生成してるような作業
  • MCP
    • ドキュメント公開すればいいやつをMCPにしない
    • MCPはdescriptionが必須で使い方を認識させられるのがいい
    • ghコマンドとかCLIも便利だけど使い方を教えないといけない場面もある

「デザインエンジニアMeetup #5 開発スピードを落とさずにUI品質を守る」に参加してきました

これからの体験設計と品質

表さん(株式会社estie)

  • つくるコストが0に近づいてる時代
    • 何を作るかが大事
    • ボトルネックは意思決定する人間
      • 何をつくるか
      • 体験として成立してるか
      • 品質を守れるか
    • つくるの前後にある意思決定
  • 人が介入するポイントを絞る
    • 汎用UIはAIが
    • 体験設計やフローモデリングは人間が
  • レイヤーと責務
    • 基盤層
      • CUJ
      • 組織として品質を担保する
      • 一般的なプロダクトであるべき部分
    • ストーリー層
      • 人が介入
      • ドメインロジック
      • 変更が多く壊れやすい箇所
    • 汎用UI層
      • AIやライブラリで自動化
  • 凝集度
    • 機能的凝集
      • 高い部分は人が開発するところ
      • feature層
    • 論理的凝集
      • 高いところはAIが
      • 共通コンポーネント
  • テスト
    • 自然言語でCUSを定義してプロンプトに
    • ブラウザを操作させてアサートする
    • ただしトークンの消費は激しい

マルチプロダクト企業でのデザインシステム立ち上げとAIとの未来

とんがりさん(株式会社マネーフォワード)

  • AIの時代にデザインシステムは必須
    • 新わせがとても高い
  • デザインシステムがないと
    • それっぽい一般的なUIが生成される
  • デザインシステムがあると
    • 提供されたコンポーネントを使って作ってくれる
    • 品質や一貫性も担保できる
    • 機械のためのUI開発基盤
  • デザイナーの成果物
    • これまではデザインを作って渡していた
    • 今はコードまで書けてしまう
    • コードの品質が問題
      • デザインシステムがあればある程度担保できる
  • デザインシステムははやくからあった方がいい
    • 後から作ると広めるのが大変
    • 後から取り込むのも大変
    • みんなで作っていく文化
  • AI最適化されたデザインシステム
    • AIがアクセスできるところにアセットがある
    • UI開発に必要な情報が揃ってる
    • 常に最新で正しい情報にアクセスできる
    • どのフェーズでどのツールを使っても効果的になるように
    • Reactコンポーネント用のMCPサーバ
    • Agent Tools

AI時代、デザイナーの価値はどこに?

tarariraさん(株式会社LayerX)

  • 作ることで考えるループ
    • 仮説検証を回していく
  • Howが加速している
    • デザインや実装のフェーズがAIで速くなった
    • 前後のWhat/WhyやQA/Craftの重要度が高くなった
    • 汎用的なところは任せてドメインの深いところに力を入れる
  • Howの前後もかそくさせる
    • 仮説を素早く形にしていく
      • 捨てるものは捨てて意思決定の精度を高める
    • さわって初めてわかる違和感がある
      • 高速に作りながら修正していく
    • 全てをデザイナーが見ることはできない

「内製開発Summit 2026」に参加してきました

三菱UFJ銀行におけるエンタープライズAI駆動開発のリアル 〜内製開発の具体手順デモ〜

尾根田 倫太郎さん(三菱UFJインフォメーションテクノロジー株式会社)
https://speakerdeck.com/muit/enterprise-ai-driven-development-at-mufg-bank-the-real-story

  • AI駆動開発
    • AIコーディングエージェントを前提とした開発
    • スキルが高い人ほど生産性が上がっていく
  • 三菱UFJ銀行におけるAI駆動開発
    • 2024末頃から調査開始
    • 2025/5にAI駆動開発ガイド
    • 2025/6から案件で適用開始
      • 融資審査システム(Java -> React)
      • 財務諸表を作成する分析システム(PL/1 -> Java)
      • FigmaからUIコンポーネントの生成
      • 会計パッケージ移行
    • 2025/10AI駆動開発研修
  • AI駆動開発ガイド
    • 80点の出力を期待する
      • 残りの20点を人がうめる
    • AIは補助で人がチェックする
  • エンタープライズ開発
    • 対象システムが数十万〜数百万行
    • 開発人数が数十人〜数百人
    • ドキュメントはエクセル方眼紙
      • エクセルは標準フォーマットなのでxml化できてAIに渡せる
    • インターネット接続ができない環境
      • 接続先を差し替えられるAIを使ってる
      • cline
      • ClaudeCode
      • 裏はBedrockで
  • ジュニアエンジニアをどう育成するか
    • よくわからないけど動いてますは許されない
    • 生産性を犠牲にするわけにもいかない

内製開発の"共通言語"としてのFigma ─ AI時代のプロダクトづくり

谷 拓樹さん(Figma Japan株式会社)

  • アイデア -> 視覚化 -> 構築 -> リリース
    • デジタルプロダクトにおけるこれらをFigmaがカバーしてる
  • 内製開発が変えること
    • 工程や部門間の分断を解消する
    • 合意形成のスピードが上がり検証と開発が高速化
  • 生成AIによる高速化
    • 速さが分断を高速化させる
    • 探索があらゆる場所でおこなわれサイロを生み出す
    • スピードの裏にある手戻りのコスト
  • FigJamと生成AI
    • ChatGPT連携ができる
    • FigJam上で編集可能なダイアグラムを作ってくれたり
    • Claudeでも
  • FigmaMake
    • テキストからUIのコード生成
    • 既存のデザインをコンテキストとして持った上で
    • 非デザイナー(PdMなど)がプロトタイプまで作ってといった使い方も
    • 成果物をFigmaに持っていってブラッシュアップしていける
    • npmパッケージのデザインシステムを与えることもできる
    • MCPでnotionつないだりもできる
  • デザインからコードへ
    • DevMode
      • デザインから開発へのハンドオフ
      • 人から人への前提だった
    • Figma MCP Server
      • 既存コードの文脈を踏まえた上でのコード生成
      • 視覚に関するコンテキストを補完
    • Code Connect
      • デザインとUIコンポーネントの実装を紐づける
  • Claude Code to Figma
    • ブラウザのレンダリング結果をFigmaのデザインに変換できる
    • コードからデザインに
    • 画面上の特定の要素を選んでFigmaに持っていくこともできる
    • デザインの検討をするのに実装を先にやって議論をFigmaでやる

AI 駆動開発ライフサイクル(AI-DLC):ソフトウェアエンジニアリングの再構築とAWS の内製化支援

金森 政雄さん(アマゾン ウェブ サービス ジャパン合同会社)

  • 従来の開発手法
    • ウォーターフォールやアジャイル
    • これらは人と人が協調するための仕組みだった
  • 段階的な改善ではなくパラダイムシフトはどうすれば起こせるか
    • AI Managed
      • AIが自律的に構築/保守することを目指す
      • 人間が介入しない
      • よほど単純なシナリオでないと上手くいかない
    • AI-Assisted Development
      • 従来の開発プロセスのままでAIが得意なところを置き換える
      • 部分的な高速化はする
      • AIに仕事をさせるための人のマニュアルタスクが増えてしまう
  • 1人でのバイブコーディングははかどる
    • 組織のなかでAIコーディングすることとのギャップ
  • AI-DLC
    • AI Development Lifecycle
    • AIは計画やタスク分解やアーキテクチャ提案などの開発プロセスを実行
    • 開発者は検証や意思決定や最終的な責任を持つ
    • Inception - Construction - Operation
      • 各段階が次の段階のためにコンテキストを構築する
      • AIと人間がレビューしてコンテキストを作らせる
    • プラン - レビュー - 実行 - レビュー
    • 組織やチームがコミュニケーションをとってアクティブに開発できることを目指している
      • AIがチーム間のダイナミックなコラボレーションを促進させる
      • モブワークを前提とした考え方
      • 職種をまたいだモブワークで即座の意思決定
  • 次世代アジャイル
    • アイデア創出 - 理論的基盤- 概念実証 - 顧客検証
    • 素早い実験から学びを最大化
      • それを実現するための文化や風土が必要
    • チームが分割されえると学びが切断されてしまう
      • 学ぶための機能横断的な小さなチーム
      • End to Endで見れる必要がある
      • その実現は内製の方がいい

東京ガス「myTOKYOGAS」内製化の3年:プロダクトオーナーとエンジニアが語るリアル

迫田 賀章さん(東京ガス株式会社)
荒井 亮汰さん(東京ガス株式会社)
福田 美桜さん(東京ガス株式会社)

  • myTOKYOGASの開発体制
    • ビジネス/エンジニア/デザイナーが同じ組織に
    • スクラムで2週間スプリント
  • 内製開発を始めて
    • 2週間単位で要件決めて開発をしていく
    • 保守もしていく
    • 単に作業者が内部の人になっただけになってないか
    • 要求通りに早くよりも顧客価値の高速な検証
  • 開発プロセスの改善
    • 仕様検討段階からエンジニアも入っていく
    • 必要十分にとどめて要件を広げすぎない
  • 内製エンジニアとして重視してること
    • プロダクトエンジニアとしての事業価値創出
    • ドメイン知識や歴史の理解
  • 内製化領域
    • まずはフロントエンドから
    • バックエンドや基幹システムは他のグループ会社で
    • BFFにドメイン層を設けたら汎用的なものになってしまった
      • マイクロサービスとして徐々に切り出しへ
      • それに伴ってバックエンドも内製化
      • 高トラフィックなためDB設計など必要
      • いわゆるNewSQLサービスのTiDBを採用
  • プラットフォームチーム
    • エンジニアチームが価値を最大限発揮できるように
    • マイクロサービスのプラットフォーム
      • EKSからECSに移行
      • 運用してみると管理対象が多くバージョンアップ作業が大変
      • 運用コストが高すぎるのでECSに移行
    • リリース作業をエンジニアチーム単独で実行できる環境の整備
    • 組織がスケールしていった時にプラットフォームチームがどこまでやるかの線引を考え直さないといけない

なぜLIXILは内製化を選んだのか?10年間の挑戦と内製化戦略

原田 篤さん(株式会社LIXIL)

  • LIXILのDigital部門
    • 研究 -> 開発 -> 製造 -> 販売
    • 800以上のシステム
    • 150以上のスクラムチーム
    • 5社が合併して出来た会社
  • なぜ内製化の流れがあるのか
    • ビジネスの急激な変化
    • 競争優位性の厳選がソフトウェアへ
    • コア機能と補助機能
      • 自社で作るべき領域と外部から調達する領域の区別
  • 内製化のモデル
    • 何を作るか
    • どこまで内製で作るか
    • 誰がどうやって作るか
  • 採用と技術スタック
    • goよりもJavaの方が採用市場で人が多いとか
  • 5社の合併によるシステム統合
    • パッケージ製品に寄せる方向で刷新しようとした
    • 業務をシステムに寄せて変えないといけない
    • コンサル会社手動で要件定義しブラックボックス化
    • 外注だと業務を変えることのオーナーシップが不在
    • 将来性を考慮できてない
    • ベンダー依存/意思決定が遅い/ビジネスニーズへの追従困難
  • 顧客認証基盤
    • IDaaSの設計運用
  • 10年前の見積もりシステムの基幹刷新
    • 合併での失敗作のシステムの刷新
  • 内製開発のtips
    • コントロールできるようにできるだけミニマムに
    • 最低でも1人はエンジニアリングリーダーが必要
    • Job型で採用異動できる体制
    • AIの恩恵がビジネスに直結する

「使いにくい」も「運用疲れ」も卒業する。UIデザイナーとエンジニアが創る持続可能な内製開発

東影 勇太さん(NRIネットコム株式会社)
大林 優斗さん(NRIネットコム株式会社)
https://speakerdeck.com/nrinetcom/shi-inikui-mo-yun-yong-pi-re-mozu-ye-suru-uidezainatoenziniagachuang-ruchi-sok-ke-neng-nanei-zhi-kai-fa

  • 内製開発におけるUIデザイン
    • 機能は満たしているのに使いにくい
    • 仕様=画面になりがち
    • 開発集弁で変更要望で手戻り
  • 伴走型のデザイン
    • デザインを納品ではなくデザイナーが参加するスタイル
    • 見た目を整える以前に情報の整理が必要
  • デザインのAI活用
    • 飛躍的に向上している
    • Figmaをマスターとする場合
      • FigmaMakeで画面作成
      • htmlもできあがる
      • おかしなところをFigmaDesignで手直ししコードを再生成
    • コードをマスターとする場合
      • デザインシステムをClaudeCode二読み込み自然言語で画面生成
      • 生成されたコードを手直し

迷わず行けよ。行けば分かるさ。内製化の道。~三井住友海上、内製化との格闘の記録~

山戸 伸一郎さん(三井住友海上火災保険株式会社)

  • アジャイル推進組織をビジネス部門の中に設置
  • スクラムチームを構築
    • アジャイルCoE
    • 開発エンジニアは一部パートナー
    • アジャイルコーチを外部から
  • アジャイルに対する組織の視線
    • 失敗すると次につながらずアジャイルの流れがなくなってしまう
    • 動くものをはやく出して成果を見せないと
  • DevOps環境の壁
    • ネットワークにつながらない環境
    • SaaSを使うことでパートナー会社からもアクセス可能
    • GitLab SaaSを採用した
      • PoCやってその後本格展開
    • ビルド/デプロイのハードルが下がった
    • PoC -> MSの案件に展開 -> MS/AD前者に展開
  • インフラ構築のボトルネック
    • 従来はインフラ部門に依頼してやってもらってた
      • その部門もパートナーに依頼してやってもらう
      • 2-3ヶ月
    • グループ全体でIT構造最適化の流れ
      • クラウド基盤強化
      • 自分たちでインフラを作れる状況に
  • アジャイル体制の課題
    • 開発がパートナーに依存
    • 開発領域の担当が分かれて縦割り
    • チームが自己完結できていない
  • 内製化へ
    • テックリードの採用へ
      • 1人目が大事
    • 少人数の内製からスタート
    • インフラの完全内製化
      • 構築期間2倍短縮
      • 圧倒的なコスト削減
    • アプリは60%くらい内製

SIerが語る内製開発のすすめ──今こそビジネスの主導権を取り戻せ!

添田 直之さん(富士通株式会社)

  • 内製化が難しい?
    • 内製開発の対象があってないのかも
    • 誰にどんな価値を提供するのかの意思決定の内製化が必要
  • ビジネスの成功
    • 顧客価値と事業価値の両立
    • 日本企業は事業価値が優先されがち
  • アジャイル実践事例
    • ビジネス
      • ビジネスサイドからPOを選出
      • 社内受託ではなくアウトカムを追求
    • 組織
      • 自律的なチーム
      • マネジメントが口を出しすぎない
  • 生成AIに対する捉え方
    • 日本は便利ツールのいきをでない
    • 海外はゲームチェンジャーとして扱ってる
  • 目指す姿
    • 従来はITベンダー依存
    • これからはビジネス部門がイニシアチブ
  • そのために
    • ビジネス部門の積極的なデジタル適用
    • アジャイル型のプロダクトエンジニア
      • 事前計画型のプロジェクトマネジメントではなく
    • 内製化範囲を定義してケイパビリティを強化する
      • ビジネス部門からプロダクトオーナー
      • IT部門からアーキテクチャリード
  • 富士通の事例
    • 従来は人月のプロジェクト型のビジネス
    • これからはプロダクト型で共創するビジネス

住友生命「Vitality」に学ぶ内製化・内製開発で実現する顧客価値と事業×システム創造

岸 和良さん(住友生命保険相互会社)

  • 住友生命のデジタル&データ本部
    • DXマインドセット研修
    • 顧客価値についての連載
    • 書籍出版
  • なぜ内製化がいいのか
    • 試して公開して改善して修正するサウクルが早いから
    • スキル・ノウハウが組織に残る
    • 新しい技術を試しやすい
    • コア人材を調達する課題が少ない
    • コストコントロールがしやすい
    • 顧客の声を理解し価値を作りやすい
  • 伝統企業は顧客価値が低いことが多い
    • ユーザから遠い
      • 真の要件提示者がいない
      • 要件通りに正確に作ることが義務付けられる
      • ユーザに聞かずに部長や役員に聞く
    • サイロ化した組織と心
      • ユーザ視点が消えて組織に無難なシステム
      • コンサルに提案してもらっても稟議を回す間に無難になる
    • ユーザを楽しませる知識やスキルがない
      • 楽しいUXや使い続けたくなるUXを知らない
  • 体制や取り組み
    • 社長直轄の3つのCoE
    • デジタル人材育成
    • 生成AI研修を内製で
    • 生成AIコンテスト
  • ビジネスモデルと顧客価値
    • 4つのビジネスモデル
      • デジタル集客系、マッチング、マーケットプレイス
      • デジタル商材系
      • リアルビジネス+デジタル
      • リアルビジネス
    • 顧客価値重視のアプローチ
      • パーソナライズ指向
      • 最小コスト最大ベネフィット指向
      • レコメンド指向(他人の意見)
    • 価値 = ベネフィット / コスト

「Claude Code実践テックトーク:開発現場のリアル事例【asken|GMOペパボ|Omiai】」に参加してきました

Claude Code の Skill で複雑な既存仕様をすっきり整理しよう

髙橋佑一朗さん(株式会社asken)

  • 既存コードの理解
    • 中途で入ってきて理解するのに時間がかかる
    • 設計やフローを調査してるだけでも時間を取られる
    • 不完全な理解だとレビューで指摘される
      • すでにあるコードを再開発してしまったり
      • 便利な開発の仕組みを知らずに進めてしまったり
  • ClaudeCodeのskillsで全体像をレポートしてもらう仕組み
    • クラス図をmermaidで出力
      • クラスの責務の整理
      • 境界の整理
    • シーケンス図の整理
      • ユースケースごとに
      • どういう条件でどういう変化が起きるのか
    • 画面遷移
      • 遷移のトリガーと遷移先

Claude Codeマーケットプレイス運用の実践:プラグイン管理の課題と自動化

深野悠吾さん(GMOペパボ株式会社)
https://speakerdeck.com/yukyu30/quan-zi-dong-dehui-se-claude-codemaketutopureisuyun-yong-shu

  • Claude Codeマーケットプレイス
    • プラグインを共有/配布する仕組み
    • スキルやフックやMCPなど
    • GitHubなどにホスティングできる
  • 作り方
    • テンプレートを複製
    • 公式のドキュメントの通り1から
    • marketplace.json
    • 社内のプライベートマーケットプレイスを作れる
    • ClaudeCodeに作りたいものを依頼するといい
  • 事例
    • 勤怠承認自動処理プラグイン
    • コード品質チェックプラグイン
    • デザインシステム参照プラグイン
  • 運用と自動化
    • 全プラグインが1つのJSONで管理されるのでコンフリクトする
    • 存在を認知しないと使わない
      • 似たようなスキルが増える
    • プルリクがマージされたら自働でslackに周知するように
    • プルリクオープン時に類似プラグインをチェック

PRが出るまでの課題をClaude Codeで仕組み化した話

太田龍乃介さん(株式会社Omiai)

  • コードレビューでの課題
    • セルフレビューができてなくて規約違反のまま出てくる
    • 説明が雑になる
  • レビュー&プルリク作成のskillsを作成
    • レビューがOK担った時だけプルリクが作成される
    • レイヤーを認識して該当する内容のチェックを行う
    • コンフル上の規約をローカルにキャッシュして使う
    • 説明にmermaidの図を生成して載せたり

BedrockをClaude Codeでproviderとして使いつつ、Guardrailsを設定

中山一仁さん(GMOペパボ株式会社)

  • ClaudeCodeの利用
    • AWS Bedrock経由で利用
    • カスタマーサポートもClaudeCodeActionsでユーザ問い合わせの調査を実施している
  • AWS Bedrock Guardrails
    • インプットとアウトプットにチェック処理を挟める
    • チェックのパターンが提供されている
      • 有害コンテンツ
      • 禁止トピック
      • 個人情報
      • プロンプトインジェクション
    • CLAUDE.mdなどもチェック対象になるので注意
      • authired-byにメールアドレスあってはじかれたり
  • ログの出力先
    • invocation logs
    • S3かCloudWatch
    • 何がはじかれたかの文言は見えない
  • プルリクの自働マージ
    • プルリクサイズを自働判定しラベル付与
    • AIによるレビュー
    • サイズが小さかったらオートマージ

Androidエンジニア、Claude Codeを指揮してAWSを超越する

佐藤忠さん(株式会社asken)

  • CSチームでのユーザ問い合わせの対応を効率化したい
    • 仕様確認をエンジニアに聞かなくても即座に確認可能に
    • DevinをSlack経由で起動できるように
    • Devinの一時解析結果をSlackに通知して初動の負荷を下げる
    • Slack -> API Gateway -> Lambda -> DevinAPI

Claude Codeを形骸化させない。Omiai流のKPI設計

大森翔太朗さん(株式会社Omiai)

  • findy team+を使っていた
  • Claudeを使ったプルリクにラベル付与
  • 利用率を計測
  • 障害対応でも活用

「SEB SUMMIT」に参加してきました

札幌から紡ぐ「感動のライフライン」~0から育む事業会社のエンジニア組織~

小林 洋一さん(ぴあ株式会社)

  • チケットぴあ
    • 札幌にエンジニアの拠点がある
    • 20人弱くらい
    • 運用保守は内製化
    • 開発も内製化を進めてる
  • なぜ内製化
    • コロナ禍を経てスピード感が必要になってきた
      • 事情規模が拡大
      • 現場の変化(電子化/転売対策)
      • 周辺ビジネスの多様化(チケット外の収益)
  • 内製組織の組成
    • 拠点選定
      • 地元愛
      • 他の地域との差別化
    • オフィス選定
      • 人が増えるたびに引っ越しは大変
      • 不退転の覚悟で
      • 60名入る大通りのオフィスに移転
    • 組織のブランディング
      • ぴあx技術というブランディング
      • PIA TECH LAB
      • 街頭広告
      • ぴあで持ってた枠をエンジニア採用に
    • 採用活動のテコ入れ
      • 人事主幹から部門主幹へ
      • 一次面接は部門で完結
      • 採用HPやイベント出店なども部門だけで
    • 事業ドメインの理解
      • 保守運用を足掛かりに新規もやっていく
      • オンボーディングの環境整備
    • 内製化推進パートナー
      • 既存ベンダーから業務を引き継ぐ

「地方在住×東京案件×フルリモート」で成果を出し続ける働き方の極意

松田さん(株式会社イーディーエー)

  • 地方からのフルリモートは不利なのか
    • 不利ではない
    • 成果は思考の質で決まる
  • 地方だと不利だと思われる理由
    • 情報が遅い
    • 人脈が弱い
    • チャンスが少ない
  • 成果を出す人
    • 環境のせいにする人はいない
    • 作業を終わらせるのではなく課題を解決して価値を出そうと思考してる
    • 再現性のある成果物

最先端の最後尾、インフィニットループのAI支援開発

萩原さん(株式会社インフィニットループ)

  • AI活用
    • 全職種gemini利用
    • 受託開発は顧客との調整の範囲内で
    • GitHub Copilotを中心にAgentic Coding
    • リスク管理を重視してツールを選定
  • ツール作り
    • 決定論的に振る舞う再利用性のあるワークフロー

札幌にいながら全国案件!?アジャイル開発で実現する場所を選ばない働き方

若松 剛志さん(KDDIアジャイル開発センター株式会社)
https://speakerdeck.com/wkm2/zha-huang-niinakaraquan-guo-an-jian-asiyairukai-fa-teshi-xian-suruchang-suo-woxuan-hanaidong-kifang

  • KAG
    • 全国13箇所にオフィスがある
    • 札幌は8人
    • 近いオフィスが札幌というだけでみんな出社してるわけではない
    • 全国横断でチームが編成されてるので札幌メンバーの担当プロジェクトもバラバラ
    • お客さんが東京だったりいろいろなので全員が揃うのは難しい
  • リモート
    • コミュニケーションツールは使いこなしている
    • 開発以外のバックオフィス系も全てSaaSに寄せているので出社しなくていい
    • 企業にとっては地方だからと言い訳できない時代
      • オンライン環境はコロナ禍で急速に進歩
      • 整ってないなら企業側の投資不足
    • 仕事に合わせて住む場所を選ぶ時代 -> 自分が住みたいところで仕事をする

札幌の開発拠点から大規模SaaS「ジョブカン」の安定稼働を支えるエンジニアの取り組み

なおっちさん/hanaさん(株式会社DONUTS)

  • DONUTS
    • 新宿の会社
    • 開発拠点として札幌に拠点ができた
    • 今は30人くらい
  • ジョブカン
    • DXクラウドサービス
    • SmartHRとかfreeeみたいな領域のサービス
  • 開発スタイル
    • 拠点横断のアジャイル開発
    • オンラインツールを使いながらコミュニケーション
  • 札幌で働いていいこと
    • 家賃が東京より安い
    • 子育てしやすい
    • 自然が豊か
    • ITのコミュニティやイベントも活発

札幌から届けるプロダクト開発〜大量データCSVエクスポートの設計と地方拠点のリアル〜

syuさん(フリー株式会社)

  • freeeの札幌拠点
    • 今は7人
    • 2023/6に拠点ができた
    • 全国で採用するのに近くに拠点がある安心感
  • チーム構成
    • PdM/PD/QA/エンジニアで1チーム
    • 拠点をまたいだオンラインでのコミュニケーション
    • 情報格差をなくす意識
    • 意思決定はテキストで残す
    • 必要な時は出張してオフラインで

「Developers Summit 2026 (Day3)」に参加してきました

なぜ、AIで生産性があがっていると錯覚してしまうのか?

広木 大地さん(レクター)
https://hirokidaichi.github.io/presentation/devsummit.html

  • AIコーディングでの生産性
    • 期待と現実のギャップ
    • 10倍くらいになってほしい
    • あって2,3倍程度で頭打ち
    • 場合によっては遅くなる
  • 体感と価値のギャップ
    • 体感の速さは価値の増加を意味しない
  • 本質的複雑性と偶有的複雑性
    • 前者はAIでも高速化は難しい
    • ソフトウェアの本質的な複雑さ
      • 複雑性/同調整/可変性/不可視性
    • アムダールの法則
      • 並列できない部分が全体を支配する
      • 並列出来るところを高速化しても詰まるところが出てくる
      • 本質的複雑性の割合が多いとスピードは頭打ちになる
    • AIの仕事は密度をあげる
      • 精神負荷の高い仕事ばかりになる
  • AIを長時間動かす設計
    • AIにいちいち聞かなくていい環境
      • コンテキストエンジニアリング
    • 本質的複雑性の比率を下げる
      • 並列化の上限が上がっていく
      • テンプレート化/大域アーキテクチャ
      • 認知負荷を下げる設計
    • 本質的複雑性の発生源に向き合う
      • 課題解決のプロセス自体をAI化
      • 暗黙知の形式知化
        • 暗黙知をコンテキストに
      • 問題の本質を捉えてAIが自律的に動けるように
  • 消える生産性
    • 空いた時間がどうでもいい仕事に吸収される
      • ブルシットジョブの増殖
      • ゆとりある労働
    • チームの改善が組織に届かない
    • AIのマクロ生産性への寄与は小さい
    • 価値を軸に仕事を再設計していく
      • やめる仕事を決める
      • 成果指標を返る
      • 学習へ再投資
  • AI活用は競争のスタートライン
    • 競争するのは人と人や企業と企業
    • お金を払ってでも人にやってもらいたい価値をうまないといけない
    • 差がつくのは使い方
    • 速くなってるのは自分たちだけじゃない
  • 相対優位が価値を決める
    • 学習速度が相対位置を決める
  • エンジニアリングの本質
    • AIがhowをやるほど人はwhatとwhyに集中する
    • やり方が決まったプログラミングはAIができる
    • 道の問題への試行錯誤がエンジニアリング
    • 意思決定中心のしごとへ
      • 何をなぜ作るのか
      • 長期的な判断
      • 創造性
  • ボトルネックの上流化
    • 暗黙知を取り出してAIが扱える形に変換する
    • 下流ほどAIで解決したり支援したりしやすい
  • 正しさは時代とともに変わる
    • 1980-90
      • 標準化/マニュアルの時代
    • 2000-10
      • 可視化/最適化
    • 2020-
      • できる化(頼む)
        • 人がやっていたことを他の人もできるようにすること
        • 判断基準の言語化
      • 自働化(任せる)
        • ワークフローやエージェントで仕組みで回す
        • 自分から手離れさせる
      • 自創化(指し示す)
        • 仮説検証や想像フェーズも自動化
  • アンラーニング
    • タスクは1つずつやる?
    • 自分がTODOをこなす側?
    • 速くすれば全体が良くなる?
    • 5人で半年のプロジェクトというくらいの粒度
    • 議論してから作業するという順序?
    • 職種ごとの役割の壁
    • 5万行のコードは大きいのか?
    • レビューは人間がやるものか?
    • 1リポジトリ1チーム?
    • 1チームは2ピザ?

2万人が「使える」生成AIをどう育てるか? 〜 損保ジャパン2万人の社員が使う生成AI機能を育てた、プロンプト改善とUX設計の軌跡 〜

小林 勇喜さん(SOMPO Digital Lab)
藤野 智彦さん(SOMPO Digital Lab)

  • 現場の業務改善
    • ユーザとのやりとりがLINEやメールなど多様で管理が大変
    • コミュニケーションの相互プラットフォーム
    • 生成AI活用で効率化も
  • 開発プロセス
    • 1週間単位のスプリント
    • ビジネスと開発が一体のチーム
    • フィーチャーフラグで安全かつスピーディーに
  • AIによる要約機能
    • 品質の安定性
      • 担当者の感覚に依存してしまう
    • コストのジレンマ
      • 品質を人が担保しようとするとトータル工数がむしろ上がる
      • 品質下限とコスト上限
    • 評価の自動化
  • ビジネスと開発のコミュニケーション
    • 品質の共通認識を持つ
    • 許容範囲の合格ラインを合意する
    • ワークショップでドメインを再認識
  • 開発とテスト
    • AIで定量的に評価 a - ビジネスサイドが改善のサイクルを回せるようにGUIからも確認できるように
    • プロンプトの改善提案も

AIが書けるからこそ、書かせない ― 少人数内製チームが、AI駆動開発で大規模なレガシー刷新に立ち向かう現実解

巣籠 悠輔さん(マルイユナイト)
https://speakerdeck.com/0101unite/2026-dot-2-20-developers-summit-2026-deng-tan-zi-liao

  • マルイグループのエンジニア組織
    • 20年物のシステムを内製化
    • EPOSカードが収益のメイン
      • 会員80万人
    • エンジニアは10人いない
  • 少人数のエンジニアチームでの開発
    • エンジニアチームがボトルネックにならないように
    • エンジニア以外でも内製出来る仕組み
      • Studio
      • microCMS
  • AI駆動開発で人間が何をするか
    • 理解/設計/実装のステップをAIは一気にやる
    • それらを紐解いてレビューしないといけない
    • コードの量というより理解/判断する量が増えているのが課題
    • 3段のフェーズをまたいだ作業をいっぺんにさせない工夫
      • ドキュメント用意してフェーズごとに作業させる
      • Claudeのskillsで
    • フェーズを分けることでアウトプットの質をコントロールできてきた
    • 制約をつけることでクオリティを安定させる-
      • 制約がないと独自の判断解釈で実装してしまう
      • 決定論的に近づける
  • フェーズの分離
    • 問を1つにする
      • 理解:どういう現状?
      • 設計:どう変える?
      • 実装:どう作る?
    • やっていいことやってはいけないこと
    • 実装フェーズではAIはただの作業者
    • うまくやると設計フェーズだけ人が判断すればいいという状態を作れる
  • AIへの期待
    • 賢さではない
    • 制約下での再現性

2026年のAIエージェント構築はどうなる?

御田 稔さん(KDDIアジャイル開発センター)
https://speakerdeck.com/minorun365/2026nian-noaiezientogou-zhu-hadounaru

  • 2025年はAIエージェント利用の元年
    • コーディング以外へのエージェント活用はまだそんなに
    • AIエージェントでパワポ作ったりM365にアクセスして操作したりなどいろいろできる
  • AIエージェントの作り方
    • フレームワークが充実してきた
      • LangGraph
      • mastra
      • Strands Agents
    • インフラ戦隊は簡単ではない
      • ストリーミング
      • 時間のかかる非同期処理
      • 認証認可
      • お金かけたくない
    • AWSのAgentCoreが便利
      • 作ったエージェントをAPI化してコンテナでデプロイすればいい
    • フロントエンドはどうするか
      • streamlit
      • Amplify Gen2
    • インフラ
      • IaCはどんな状況でも必須
      • コードになればAIが扱える
    • 型ができればアレンジも量産もできる
  • コスト削減
    • アプリはサーバーレスで作れるからかからない
      • ほとんどはLLMの費用
    • 工夫
      • 品質を保てるギリギリのモデルの見極め
      • プロンプトキャッシュ
      • 会話履歴のトリミング/要約
      • マルチエージェントは不要なことが多い

「触らないとわからない」を武器にする──AI時代のエンジニアが獲得すべき肌感覚と、没頭できる時間の確保

檀野 隆一さん(トヨタコネクティッド)

  • 組織への生成AIの導入
    • 使える環境ができても浸透には思ったより時間がかかる
    • 自分は使ってるのに周りは使えない状況
    • 個人差がある
    • 便利だと分かってもらう
    • 本人の特性
      • ポジティブ - ネガティブ
      • 手を動かす - 様子を見る
  • 活用してもらうために
    • 慣らし運転
      • 業務の中で使っていく
      • 答えがあるものからはいるといい
    • OJT&レビュー
      • 曖昧なところをさわって試してみる
      • 自分のやり方がいいやり方かフィードバックしてもらう
    • ストレッチしたゴール
      • これは出来ないだろうというギリギリをやってみる
      • どこまでできて何ができないか知る
      • 思った以上にできるかもしれない
      • どこまでできるか知ってるとモデルのアップデートで評価しやすい
  • 肌感覚を3つの観点で
    • 自分の実力がそのまま跳ね返ってくる
      • 周辺領域への拡大はできそうで難しい
      • 万能感と無能感
    • どれくらい信頼するか
      • 人間の方が間違ってるケースが増えてくる
      • 絶対AIがおかしいと思っても一回試してみるといい
      • それはすごいですねを真に受けない
      • 批評的な目線でというと辛辣になる
    • 運用/継続の視点
      • クラウド型はダウンする前提で
      • モデルのサービス終了
        • 代わりの新しいのが日本リージョンにないとかも
      • 作り込みすぎない設計を
      • 開発中にモデルが変わることは当たり前
      • なおすコストと乗り換えるコストの天秤
  • 学ぶにあたって
    • ソフトウェアエンジニアだからってだれてもすぐに適応できるわけではない
      • 人による
      • MLの領域だから性質は違う
    • すぐに成果がでるという誤解
    • 学習というより適応
      • 失敗じゃなくて投資
    • プロジェクトで慣れる時間を確保
      • 期間を人がやる時と同じだけとってダメだったら人力の選択を

HTTP最前線

奥 一穂さん(ファストリー)

  • HTTP
    • バージョン固有なもの
    • どのバージョンでもあるもの
      • Semantics
      • HHTPメソッドとかステータスコードとか
      • ほとんどがSemantics
  • プロキシはSemanticsレイヤで動作
    • 1で来ようが2で来ようが受け取って任意のバージョンで返す
  • HTTPバージョンはhop by hop
    • Semanticsじゃないやつはこれ
  • ほとんどのヘッダーはend to end
    • Semanticsなやつはこれ
  • HTTP Semantics
    • HTTPバージョンに依存しない機能
    • end to endで使える
    • これだけでアプリケーションを作れば互換性があって安心
  • Incremental HTTP
    • リクエストやレスポンスを徐々に送信したいケース
    • HTTPの上でそれをやる機能
      • 他だとServer-sent EventsとかgRPCとか
    • HTTPでサポートするべきものなのかという話はある
      • 現在の状況だとうまく動かないことが多い
      • 6本までしか同時に繋がらないからそれ以降は待たされる
    • Incrementalヘッダをつけることができる
      • 6本使ってたらエラー返してくれる
      • デバッグで原因が分かるようになる
      • RFC発行しようとしてるところ
  • PTTH
    • 現在はクライアント - CDN - ロードバランサー - HTTPサーバ
    • PTTHだとクライアント - CDN - HTTPサーバ
      • CDNで優先度に基づいた順序入れ替えが可能になる
    • 2025/7にカバーするユースケースを議論
    • どこのWGで標準化するか
  • QMax
    • Semanticsの下が複雑
      • 3つのプロトコル
      • 2つのTCP
    • HTTP3 -> QUIC -> UDPとHTTP2 -> TCP両方を対応し続けないといけない
      • TLSとQUICのAPIが違うのが原因
      • TLSの上にQMうxtおいう層を設けてAPIの互換性をもたせる
  • SCONE
    • Standard Communication with Network Elements
      • エンドポイントとネットワーク機器が強調して帯域利用を最適化
      • QUICの特殊なバージョンのパケット
    • ネットワーク帯域の大半は動画配信が占めている
    • 動画のフローをIPとかSNIで検出してスロットリング
      • 誤判定が多い
      • 無線電波の利用効率が低い
  • Rapid Start

とっても大きく育ったプロダクトを整頓しよう ~ モジュラーモノリスへ向けた段階的アプローチ方法~

深見 高志さん(楽天カード)

  • 楽天カード
    • サービスが増大
    • リファクタリングも困難
    • 属人化した知識
    • 改修が入った機能と別のところで不具合が置きたり
  • 大きなモノリスを分割したい
    • マイクロサービス化できるほど整ってない
    • モジュラーモノリス
    • 大きなモノリスをモノリスの中で整理していく
      • マイクロサービスを見据えた途中のステップ
  • モジュラーモノリス化に向けて
    • 単体テストを拡充してリファクタリング出来るように
      • 入口からDBまでつないだテスト
      • ベストケースと名付けた流れを網羅的に
      • Step by Stepで泥臭く仕様を読み解きながら
    • 正しい置き場に移動して業務知識の境界線
      • Presentation/Application/Infraなど
      • さらにそれを業務ごとに区切る
        • 境界をまたいだ呼び出しをなくしていく
        • 境界からのアクセスを受け取る場所を一箇所に
        • マイクロサービス化も見据えて
    • DDDの文脈でドメイン集約
      • 機械的にできるところから整理
      • ValueObjectを作っていく
    • 機能を1つのモジュールにまとめる
      • プロキシ的なAPI層にもロジックがあった
      • ビジネスロジックの層に移動していく
      • APIの受け口も統合してしまう