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

意志を実装するアーキテクチャモダナイゼーション

nwiizoさん
https://speakerdeck.com/nwiizo/yi-zhi-woshi-zhuang-suruakitekutiyamodanaizesiyon

  • AIエージェント
    • 自律的に大きいタスクを任せられるようになった
  • Harness Engineering
    • 制約を付けてAIにコードを書かせる
  • AIはHowを加速する
    • WhatとWhyは加速しない
  • モダナイゼーション
    • 全部作り直すも全部残すも間違い
    • どこに投資すれば最もリターンが大きいかを判断する
    • 技術/組織/戦略
    • ビジネス目標がすべての起点
      • 技術を新しくしたいはビジネス目標じゃない
      • 何故今やるのか、やらなかったら何が起きるか
  • ソシオテクニカル
    • 社会的/組織的 + 技術
    • 縦割り
    • 時間軸の違い
    • 政治的コスト
    • レガシーの問題は組織/文化/プロセスに根ざしてる
      • 技術だけ変えてもダメ
      • コンウェイ/逆コンウェイ
  • BVSSH
    • モダナイゼーションの正か指標
    • Better/Value/Sonner/Safer/Happier
    • バランスを取っていくことが大事
  • IVS
    • Independent Value Stream
    • ドメイン整合/チーム自律/成果思考/疎結合
    • これらを満たす技術と組織が前提
  • DDDとチームトポロジー
    • ソフトウェアの境界とチームの境界
    • 一致させるとコンウェイが味方になる
    • チームを小さく保つ
    • 認知負荷を下げる

チームを増やしても、なぜ開発は速くならないのか? ― LeSS × SPACE × AIで見えた、生産性を阻害する構造と打破した壁

古賀 みゆきさん(デジタルガレージ)

  • やりたいことが多くて開発が追いつかない
    • 人を増やす
    • 結果はやくならず現場の疲弊が増えた
  • 人が増えると
    • コミュニケーションコストが増加
      • ナレッジが流通しない
      • 車輪の再発明
      • 認識のずれで統合の衝突
    • 担当が局所化して何をやってるかわからなくなる
      • リードの負荷が高まって設計やレビューが停滞
      • 個々のチームは頑張ってるのに全体は進まない
  • 2チームでの開発
    • 両方ウォーターフォールだった
    • 片方だけスクラムにしてスプリントごとに統合
      • 片方が痛みを引き取る
    • ウォーターフォールのチームの人がスクラムに入ってみたらそっちがいいとなった
    • -> LeSSへ
  • LeSS
    • 経験主義
    • 顧客中心
    • Scrum is Scrum
  • LeSSをやって
    • 1つのバックログ
    • 相互にレビュー
    • 常時統合し継続的な学習
    • 構造の改善による高速化
  • 立ち上がりで
    • 教科書通りに進まない
    • 役割の捉え方に差がある
    • 分かったつもりになって形骸化
    • -> 強制しないアプローチで納得感をもって
  • SPACE
    • 生産性のためのフレームワーク
    • 健全に価値を生み続けられているか観測
  • AI活用
    • チケットの作成
      • 暗黙知の明文化
      • サイズ感などの基準の統一
      • AIが作って人が確認
    • コードレビュー
      • AIがルールのチェックや明らかなバグのチェック
      • 人は妥当性や要件との整合性を判断
    • テスト
      • 要件からテストの生成

AI ネイティブ組織への変革:ビジネスとITの統合が拓く未来AIで“はたらく”をアップデートする人材業界パーソルキャリアのリアル

岡本 旬平さん(パーソルキャリア)

  • AI時代に5年後も今のままでやっていけるのか
  • 4つの足かせ
    • 技術的負債
    • 知識のサイロ化
    • アーキテクチャの分断
    • 形骸化したガバナンス
  • ITの役割
    • ゲートキーパーからアクセラレーターへ
  • サービス層とプラットフォーム層
    • 動的なビジネスロジック
    • 安定した共通基盤
  • 投資領域
    • AIプロダクトマネジメント
    • 全社AIエージェント推進
    • LLMインフラ基盤
    • 次世代データ基盤
  • AIプロジェクトの成否
    • ユーザ価値
    • 技術価値
    • 企業価値
  • AIの活用領域
    • 新規サービス開発
    • 既存業務のプロセス改善
    • 各個人の生産性向上
  • 事例
    • 法人向けの求人サービス
    • 候補者を探す時の検索という行為を効率化
    • 求人から自動で検索条件を設定

アクセシビリティをサービスの"当たり前"に!!~当事者協働で実現する届く行政デジタルサービス~

山内 晨吾さん(GovTech東京)
松村 道生さん(GovTech東京)

  • アクセシビリティを行政アプリのあたり前品質に
  • DXによって障害があってもアプリなど人の手を借りなくても使えるようになってきた
    • とは言っても取り残されてしまうところもある
    • 出来るところは増えても一連の体験で手伝ってもらわないといけないところもある
  • 行政のサービス
    • コロナワクチンの予約ページ
    • マイナンバーカードのパスワードは口頭で伝えて登録してもらってる
    • 民間サービスなら使わなければいいが行政サービスはそうはいかない
  • なぜ残念な状況がなくならないか
    • アクセシビリティに関する認知不足
    • 障害者は自分のサービスは使わないと思われる
    • 当事者が作る側に入っていない
    • 罰則規定が日本はない
  • 当事者が中に入って作っていく
    • 後からつけるものではなく最初から考慮する
    • あったらいいではなくあたり前に
  • アクセシビリティはアプリの成長とともに壊れてしまうことがある
    • 最後のテストをしておしまいではなく作る工程に入れる
      • 後からやると大量の指摘事項で対処できないことも
      • 後戻り出来ずに対応できないようなことも
    • 計画/設計/実装/テストの全てのフェーズで
    • ガイドラインに準拠
    • ペルソナに含める
    • ツールによる自動チェック
    • 都民のテスターによるチェック
  • 品質向上のアプローチ
    • ツールを利用したテスト
    • XCodeやAndroidStudioにアクセシビリティチェック機能が標準搭載されている
    • Stark for Figmaでコントラスト比や代替テキストのチェック
    • Claude Code for Figma MCPで文脈的な正しさのチェック

Claude Codeで実践するスペック駆動開発入門

吉田 真吾さん(ジェネラティブエージェンツ/セクションナイン)

  • AIエージェント
    • 環境を知覚して情報を取得し推論して行動する
    • ツールを選択肢駆使するループ
    • 事前定義型/適応型
  • バイブコーディング
    • 精度はどんどんあがっている
    • 本番運用に耐えうるものかどうか
  • 仕様駆動開発
    • 開発ルールのポリシーをまず作らせる
    • AI-DLC
      • inception
      • construction
      • operations
    • ステアリングポリシー
      • 全部与えるとコンテキストが消費される
      • 出来る限りルールは必要な時に必要な分読み込ませる構造
    • 監査証跡
      • 何をやったかは残るがなぜそう判断したかは不十分
    • 状態管理
      • フェーズごとの完了したタスクなど進捗を記録させる

「Developers Summit 2026 (Day1 Dev x PM Day)」に参加してきました

AI時代のプロダクトと開発 - 経営と開発の"両輪"で考えるAIネイティブ戦略

今村 雅幸さん(日本CTO協会 / バイセルテクノロジーズ)
泉 雄介さん(日本CTO協会 / UPSIDER)
梶原 大輔さん(日本CTO協会 / GENDA)

  • AIの使い方
    • 人間の補完 -> AIがやったことを人が確認
    • 主体が変化してきてる
    • 既存のプロダクトをAI化?最初からAIネイティブなプロダクト?
  • AIを中核にするにあたり経営陣をどう動かすか
    • 使っていかないと取り残される
    • お金はかかる
    • 予算を考えるのに人件費と比較したり
    • 売上アップしたり利益を創出する側でのROIの証明
  • AIの揺らぎをどう許容する
    • AIを使ってもいいけど出したものは責任を持つ
    • 非可逆な操作や意思決定
    • 人でチェックしてるところがまだ多い
  • あえてAIを使わない判断
    • ユーザと直接接する部分
      • AIを使って接する時間を増やす
    • 感情で動く場面
  • AIネイティブのプロダクト開発
    • ClaudeCodeが出て変わった
    • 人間がボトルネック
    • 介入しないといけないタイミングを減らしていってるがどこかで止まる
    • レビューが詰まる問題
  • エンジニアやPMの役割
    • どんどん上流に上っていってる
    • テストの品質

リゾーム構造をツリー構造へ落とし込む設計技術──DBとUIを整合するInformation Architectureの脱構築

中沢 大さん(Dress Code)
https://note.com/nkzw_a/n/n3ef878cf0e7d

  • ツリーは1つの点から始まる
  • ダイアグラムいろんな点から始まる
  • インフォメーションアーキテクチャをどう作っていくか
    • 建物に例えると
      • Foundation
      • Superstructure
      • Room
      • Equipment
      • Movables
    • 証明のスイッチとアクションボタンのように参考にされる
  • 情報を整理し脱構築をしながらIAを設計する
    • 結果としてDBとUIも整合する

LLMを入れたら障害対応が地獄に?Datadogで考えるAI時代の運用設計

萩野 たいじさん(Datadog Japan)

『誰の責任?』で揉めるのをやめて、エラーバジェットで判断するようにした ~感情論をデータで終わらせる、PMとエンジニアの意思決定プロセス~

川崎 雄太さん(ココナラ)
https://speakerdeck.com/coconala_engineer/shui-noze-ren-derou-merunowoyamete-erabazietutodepan-duan-suruyounisita-gan-qing-lun-wodetadezhong-waraseru-pmtoenzinianoyi-si-jue-ding-purosesu

  • 責任追求は何故起きるのか
    • 客観的に判断できるデータがない
    • 客観的に判断できる基準がない
    • 失敗を責めてしまう文化
  • そういう環境で何が起きるか
    • 職種どうしの対立
    • 責任回避の防御的な行動
    • イノベーションが生まれない
    • 優秀な人材の離脱
  • SLOとプロダクト指標
    • ビジネスKPIを洗い出し把握する
    • 技術指標をビジネスKPIに翻訳し理解する
    • PMも見る共通のダッシュボード
  • エラーバジェットで意思決定
    • 失敗=悪にならないように
    • 許容できるリスクをマネジメント
    • ユーザ体験の状態をもとにどれだけリスクをとったり排除したりするか天秤にかける
    • ポストモーテムで失敗を経験にする文化
    • エラーバジェットを元にPMとエンジニアでリリースの判断をする
  • 失敗からの教訓
    • データドリブンで何でも決めすぎない
      • ことではなく人に目が向いてしまうクトがある
      • 判断材料の一部として使う
    • 1人で全部を変えようとしてた
      • 共感者を見つけるのが最優先
      • 当事者意識を持ってくれる仲間を
    • 完璧を求めすぎた
      • 指標を追うことに疲弊
      • 見るべき指標が多いと疲れてしまう

AI時代のエンジニアに求められる「技術の先」にあるスキルとは? ─ログラス×SkillCanvasが実践するエンタープライズSaasを制する組織デザインー

林 宏昌さん(SkillCanvas)
広瀬 丈さん(ログラス)
川村 剛司さん(ログラス)

  • ログラスのサービス
    • エンタープライズSaaS
      • 高信頼性
      • 複雑なドメイン
      • 長期運用
    • AI時代他のサービスとの差別化が必要
    • 技術スタックではなく人と組織の設計が競争力になる
  • ジュニアミドルからリーダー層への壁
    • カッツモデルの応用
      • 基本となるスキル
      • プロダクトエンジニアとして必要なスタンス
      • プロダクトエンジニアとして必要な技術的知見
      • 事業リーダーとしてのポータブルスキル
    • 壁を突破できる人とできない人の差分
      • スタンスやリーダーとしてのポータブルスキルが大きい
        • 本質課題の特定と抽象化
        • ステークホルダーとの合意
        • リスクを踏まえた意思決定
        • 逆算思考によるロードマップ
      • 職種を問わないビジネススキルが差が大きかった
        • これらを出来てる人を壁を超えた人としてるのでは・・?
      • 技術を学ぶのは分かりやすくてやれてる人が多い
      • レイヤーが高い人ほど大きい案件をやるからこれらの経験も積むことになる

生命保険会社におけるテスト自動化の取り組みー品質と事業成長の加速

今村 貴紀さん(オーティファイ)
松井 康浩さん(オリックス生命保険)

  • AIによってコーディングは加速している
  • テストはそうなっていないことが多い
    • 開発の中でテストの割合は4割
    • テストがボトルネックになってくる
    • 改修が進むにつれてテストの量は雪だるま式に増えていく
    • テストの観点を出せるメンバーは属人化しがち
  • 生命保険会社特有の事情
    • テストにかける工数が全体の50%
    • 主要システムだけで50以上
    • ブラウザやOSのバージョンアップなどある度に手動でリグレッションテスト
    • 不具合は許されない
  • テスト自動化の取り組み
    • 2020年頃から自動化のツール導入
      • 作り込みすぎてテストのメンテナンスが大変
      • 社内環境の制約もあり動作が安定しない
    • 2022年にAutifyを導入
      • マルチブラウザテストも自動化
    • 社内で口コミで広まっていって定着した
  • 自動化のスコープ
    • E2Eで繰り返し実行するテスト
    • マルチブラウザテスト
    • リグレッションテスト
  • 実行の仕組み
    • 週に一回とか定期的に実行
      • 土日に定期実行
      • 定期的に回してるとテストのメンテナンスの間隔も小さくなり対応が軽い
  • 実行環境
    • 従来は
      • 昔はテスト用の端末を借りて
      • 充電して起動してOSバージョンアップが走ってみたいなことをしないと
      • 手動でスクリーンショットとって社用PCに送ってエビデンス作って
    • Autifyだと
      • 一度作ったら使い回せる
      • 拘束されるのは結果を見るとき
  • IT部門では定着してきたので業務部門の受け入れテストにも今後は力を入れる

エンジニアキャリア図鑑~組織と事業を伸ばす「エンジニアリングマネージャー」の真価とは?

小田中 育生さん(カケハシ)
miisanさん(令和トラベル)
新多 真琴さん(LayerX)

  • EMとしてやっていること
    • ひとりひとりのポテンシャルを発揮させて組織としての生産性を上げる
    • 構造的な課題を仕組みで解決
    • プロダクトの価値を守ることはなんでも
    • 人が増える中でのオンボーディング整備
  • EMになったきっかけ
    • 自分の給料上がらないなと思った時に事業がどんな構造か意識するようになった
    • 大規模案件で人をつぎ込んで対応した時に持続性も必要だと感じた
    • 自分がサービスをどうしたいかを考えた時にマネジメントの方があっていた
    • 自分がそれをつくるだけでなくどういうチームで作るとか人に興味があった
  • 現場にいたいからマネジメントやりたくない問題
    • マネジメントのことをよく知ってないだけかもしれない
  • EMとしての葛藤
    • 自分が我慢すれば済むという方向に行きがち
      • どこかで爆発してしまう
    • マネージャー自身が持続できるか
    • 三方よしにしないと
    • メンバーには失敗しても大丈夫というが自分はそれに耐えられない
    • マネージャーが人の力を借りれない時
    • EM四象限の全部に強い人はいない
      • けどそれを求めてしまう
      • ジョブディスクリプションも全部できる人を求めてしまう
      • そのタイミングで捨てていいものがあるはずなのでやらないことも決めないと
  • エンジニアと事業視点
    • 事業視点を持ててないと思ってるエンジニア多い
    • でも本当に言われたことを言われた通りだけしかやってない人はいない
    • それは何でなのかと考えられている人は多い
    • マネージャーはそれを考えるのに必要な情報を渡さないといけない

「SRE Kaigi 2026」に参加してきました

生成AI時代にこそ求められるSRE

山口能迪さん(AWS)
https://speakerdeck.com/ymotongpoo/sre-for-gen-ai-era

  • AIによる加速
    • 開発速度は上がるが不安定さも増大させる
    • 変更失敗率も上がる
    • 組織の持っているものが増幅される
  • AI駆動開発
    • 開発者がどうAIを使うかにフォーカスが当たりがち
    • デリバリーパイプラインについてももっと活用できる
  • コンテキストの補強/ガードレールの強化
    • SREがもともとやってきていたこと
    • SREがAI時代にもたらす価値になる
  • コンテキスト
    • システム固有情報はコンテキストとして与えないといけない
    • オブザーバビリティ
      • 今どういう風に動いているか知る
      • 従来だとCPU仕様率とかエラー数とかだけ
      • サービス名やトレース情報など高次元なイベントがとれるようになってる
      • テレメトリをとってれば解析してくれる
        • AWS DevOpsエージェント
        • Datadog Bits SRE
      • MCPサーバ経由で手元でも活用できる
    • IaC
      • 仕様書やアーキテクチャ図は本当にその通り作られてないことも多い
      • IaCのコードが一番正しい情報源
      • Everything as Code
        • あらゆるものをコードで管理
        • 再現性と一貫性
        • プレーンテキストがAIにとって読みやすい
        • commit履歴で経緯も読み取れる
    • ポストモーテム
      • AIが作成を支援
      • 成果物はAIも読む
  • ガードレール
    • ビルドプロセスは外部依存しないことが望ましい
      • セキュリティ
      • 冪等性
    • 密閉ビルド
    • サプライチェーンセキュリティ
      • 内部アーティファクトリで間違ったライブラリインストールしないように
      • もしインストールしてしまってもスキャンしてしてしまっても脆弱性を検知
    • 発展的なテスト
      • ファジング
      • プロパティベーステスト
    • Ppolicy as Codeによる統制
      • CI/CDで
    • SLOに基づいたリリース
    • AIの出力結果にNoといえる文化

制約が導く迷わない設計 - 信頼性と運用性を両立するマイナンバー管理システムの実践

内藤 翔太さん(DressCode)
https://speakerdeck.com/bwkw/zhi-yue-gadao-kumi-wanaishe-ji-xin-lai-xing-toyun-yong-xing-woliang-li-surumainanbaguan-li-sisutemunoshi-jian

  • 制約を使って設計判断を進める
  • 制約を洗い出すことが設計判断の第一歩
    • 外部から課される自由度を制限するもの
    • 法令/規制
    • ビジネス要件
    • 技術環境
    • チーム/体制
    • 運用ルール
  • 除外として効くものと比較として効くもの

SREが向き合う大規模リアーキテクチャ〜信頼性とアジリティの両立〜

守屋邦昭さん(シンプルフォーム)
https://speakerdeck.com/zepprix/sregaxiang-kihe-uda-gui-mo-riakitekutiya-xin-lai-xing-toaziriteinoliang-li

  • 法人の健全性をモニタリングするサービス
    • 不穏な動きがある法人を検知したいがノイズが多いと業務が却って非効率になる
    • 複合できな事象を組み合わせて検知が必要なケース
  • 業務要件実現のためのリアーキテクチャ
    • バッチが4時起動で7時がデッドライン
      • 通常は60分なので90分をSLOとして検知
    • 並行期間を設けてバグをつぶす
      • ダウンタイムゼロで移行

Embedded SREの終わりを設計する:「なんとなく」から計画的な自立支援へ

鷹箸孝典さん(Sansan)

  • Embedded SREのExit戦略
    • なんとなくで関わり続けてしまう
    • 他にもプロダクトはあるのに
  • SREのスケーラビリティの限界
    • プロジェクトごとにゼロから構築
    • 標準化が進まず車輪の再発明
    • SREがチームAの対応をしてる間にチームBやCが独自で動いてる
    • SREのリソースがボトルネック
  • Platform EngineerとEmbeddedSREの両輪で
    • 全社で利用可能なプラットフォーム
  • Exit戦略
    • 基盤構築期
    • 自立移行期
    • サポート期
  • SRE Knowledge Transfer Matrix
    • 開発チームのメンバーが何をどれくらいできるか可視化
    • 二軸で定量
      • 自信度
      • 経験
    • チームとしてどれくらいカバレッジがあるか
      • 最高スコア
      • 基準を満たした人数

SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル

川田雅彦さん(イオンスマートテクノロジー)
久保翔馬さん(イオンスマートテクノロジー)
https://speakerdeck.com/aeonpeople/sre-kaigi-2026

  • Embedded SREと開発チーム
  • 週一でダッシュボードを眺める会
    • エラーが増えてるとかコスト上がってるとか見る
  • 月一で特別回
    • ビジネス部門や関連システムの人も呼ぶ
    • 今後の施策やイベントの情報を共有してもらう
    • 先回りして対策が取りやすくなる
  • 眺める会の主催がSREから開発チームへ
    • 自然と移行が進みEnablingが上手くいった

認知負荷を最小化するオブザーバビリティとSLOの導入 ―4名のSREが200名のプロダクトエンジニアを支援

樋口貴志さん(SmartHR)

  • 人事労務領域における社会インフラになる
    • 信頼性とアジリティ
  • 40の開発チーム200名のエンジニア
    • SREは4名
    • Enablingを主体に活動
  • SmartHRのSRE
    • SREに期待することは組織によって違う
    • SREチームと開発チームの責任分界点の明確化
      • SRE:SLO計測の仕組みを提供
      • 開発:SLO目標値の策定運用
      • 文書化して展開する
  • ロードマップを作って計画的に
    • RICEスコアで優先順位
  • 少人数での取り組み
    • ダッシュボードと分析手順
  • SLI/SLOの策定
    • 開発チームが策定しようと思っても難しい
    • CUJを考えて設計する
      • プロダクトの価値を考えてそれを実現する導線を整理
      • それを実現するのに通る画面やAPIから対象を決める
      • どれくらい品質が下がると価値に問題が出るかで基準を決める

15年続くIoTサービスのSREエンジニアが挑む、可観測性向上 〜技術をビジネス価値に翻訳する試行錯誤の記録〜

Banri Kakehiさん(エレクトリックワークス)
黒崎 耕平(エレクトリックワークス)
https://speakerdeck.com/melonps/15nian-sok-kuiotsabisuno-sreenziniagatiao-mu-fen-san-toresingudao-ru

  • 分散トレーシングの導入
    • k8s移行&マイクロサービス化でトラブルシューティングが難しくなった
    • 分散トレーシングを導入したがコストが想定の10倍
    • 担当メンバーも異動になり導入断念
  • 導入失敗の要因
    • 技術面
      • スクルや知識の不足
      • 計装のノウハウがない
        • いきなりデバイスからのE2Eを実装して複雑なことをしていた
      • コストの見積もり
        • 何をするとどれくらいコストがかかるかなど
        • SaaS利用料
        • 実装コスト
      • 何を可視化したいのか明確になってなかった
    • 認識面
      • ビジネス価値にどう貢献するか共通認識がなかった
  • 分散トレーシングで何をしたいか
    • 問いを明確化
    • 自動計装でいいか主導計装が必要か
    • サンプリング戦略
    • SaaSが必要かOSSでできるか
  • ビジネス価値への貢献度の見積もり
    • 問い合わせ調査時間の減少
    • 属人化の解消

SREのプラクティスを用いた3領域同時マネジメントへの挑戦 〜SRE・情シス・セキュリティを統合したチーム運営術〜

川崎 雄太さん(ココナラ) https://speakerdeck.com/coconala_engineer/srenopurakuteisuwoyong-ita3ling-yu-tong-shi-manezimentohenotiao-zhan-sreqing-sisusekiyuriteiwotong-he-sita-timuyun-ying-shu

IaaS/SaaS管理におけるSREの実践

多羽田 俊さん(MIXI)
https://speakerdeck.com/bbqallstars/saasguan-li-niokeru-srenoshi-jian-sre-kaigi-2026

ゼロからはじめるSRE:一人運用から複数プロダクト・SREチーム立ち上げまでの軌跡

籔下 直哉さん(TalentX)
https://speakerdeck.com/ybalexdp/srekaigi2026-serokarahasimerusre-ren-yun-yong-karafu-shu-hurotakuto-sretimuli-tishang-kematenogui-ji

コスト削減から「セキュリティと利便性」を担うプラットフォームへ、Sansanの認証基盤のこれまでとこれから

樋口 礼人さん(Sansan)
https://speakerdeck.com/sansantech/20260131-1

AIと新時代を切り拓く。これからのSREとメルカリIBISの挑戦

ogumaさん(メルカリ)
https://speakerdeck.com/0gm/aitoxin-shi-dai-woqie-rituo-ku-korekaranosretomerukariibisnotiao-zhan

SRE とプロダクトエンジニアは何故分断されてしまうのか

渡邉 美希パウラさん(ワンキャリア)
https://speakerdeck.com/onecareer_tech/why-are-sre-team-and-product-teams-so-disconnected

チームを巻き込みエラーと向き合う技術

maruさん(LINEヤフー)
https://speakerdeck.com/maruloop/talk-for-error-handling-with-swe-and-sre

開発チームが信頼性向上のためにできること: 医療SaaS企業を支える共通基盤の挑戦

kosuiさん(カケハシ)
https://talks.kosui.me/talks/2026/sre-kaigi-2026/

ファインディの横断SREがTakumi byGMOと取り組む、セキュリティと開発スピードの両立

米内 貴志さん(GMO Flat Security)
安達 涼さん(findy)
https://speakerdeck.com/rvirus0817/huaindeinoheng-duan-sregatakumi-bygmotoqu-rizu-mu-sekiyuriteitokai-fa-supidonoliang-li

M&A 後の統合をどう進めるか ─ ナレッジワーク × Poetics が実践した組織とシステムの融合

Shogo Watanabeさん(ナレッジワーク)
https://speakerdeck.com/kworkdev/m-and-a-hou-notong-he-wodoujin-meruka-naretuziwaku-x-poetics-gashi-jian-sitazu-zhi-tosisutemunorong-he

予期せぬコストの急増を障害のように扱う――「コスト版ポストモーテム」の導入とその後の改善

吉澤 政洋さん(アンドパッド)
https://speakerdeck.com/muziyoshiz/sre-kaigi-2026

クレジットカード決済基盤を支えるSRE - 厳格な監査とSRE運用の両立

水口 洋輔さん(スマートバンク)
https://speakerdeck.com/capytan/kurezitutokadojue-ji-ji-pan-wozhi-erusre-yan-ge-najian-cha-tosreyun-yong-noliang-li-sre-kaigi-2026-d099bc0e-9ba2-4d2b-81ac-7b3c152649a1

「StackNagoya Fes Vol.4「AIってどう使う?Web制作現場のリアル」」に参加してきました

新卒一年目が組織とデザイン業務を牽引するために取り組んでいること

みぴさん(スタメン)

  • サムネイルを作るデザイン業務を運用も見越して
  • 誰でも作業できる環境を
  • Figma Makeでジェネレーター
  • 技術の独占から民主化

もう ChatGPT からコピペしない!Cursor で実現する AI コーディング術

宇井 陸登さん(アップルップル)
https://speakerdeck.com/uidev1116/mou-chatgpt-karakopipesinai-cursor-deshi-xian-suru-ai-kodeingushu

  • AIでコーディング
    • ChatGPTなどだと出たものをエディタにコピペしていかないといけない
    • CursorのようなAIエディタを使うとプロジェクトの内容をコンテキストに入れて開発できる
    • AIの作業と自分の作業で並列化できるのがいい
  • 事前準備
    • AGENTS.md
    • 共通的なルール
    • サブディレクトリにも置けるので、そのディレクトリ内だけのルールを書いておくのもいい
  • 計画作成
    • Plan Modeでコードを調査して計画を立てる
    • OKならそれで開発してもらう
  • レビュー
    • AIにレビューしてもらう
    • diffを見て確認してもらうようにするといい
  • Cursorは音声入力ができる
    • プロンプト入れなくていいので楽

AdobeのAIって何ができるの?10分でざっくり紹介

岩田和也さん

  • Adobe Firefly
    • AdobeのAIモデル
      • フリーな素材で学習してるから商用利用できる
      • geminiなどのモデルも使える
    • ブラウザで使える
    • 素材作りに使う
    • CreativeCloud契約してなくても生成クレジットだけ買える(サブスクなので注意)
  • Illustratorの生成AI機能
    • プロンプト入れてベクターの画像生成したり
  • Photoshopの生成AI機能

AIとGASの力で、プロジェクト管理の「ちょっと面倒な作業」を自動化した話(仮)

ほっしーさん

  • 日常業務での見えないコスト
    • ツールを見て回る検索時間
    • 予定を調整する時間
  • Gemini x GAS
    • アサイン集計ツール
      • 誰が何件タスクを持ってるか
      • 手作業でCSV抽出してスプレッドシートでやってた
      • APIで対象タスクを取ってきてまとめてもらうようにした
    • 個人タスク管理自動化
      • ツールやタブをたくさん開いてしまう状態
      • 自分のタスクをまとめたサイト?
    • WBS作成自動化
      • 公開日から逆算して配置してというのを手動でメンテしてた
      • AIに社内ルールを踏まえた線引をしてもらうようにした
  • 非エンジニアのAI活用
    • エラーコードはAIへの指示書
    • わがままがツールを育てていく
    • 自動化で時間だけでなく心の余裕もできる

リサーチ初心者が、AIと一緒にプロセスを形にするまで

井斉花織さん

  • ユーザーリサーチ
    • LTV向上のための示唆を得るためにやった
    • 1年買い切りプランが終わると1ヶ月サブスクに移行する機能
  • ChatGPTでリサーチ計画
    • 教科書的なフォーマットで整理してくれる
    • わからない用語も聞けば教えてくれる
  • NotionAIで議事録
    • 録音して文字起こしや要約をしてくれる
    • リサーチ結果を分析
  • NotebookLMの活用
    • インタビュー結果からKAカードを生成してもらう
      • 出来事・心の声・価値
    • FigmaBuzzでアウトプット

Figma Makeで体験するAIと対話しながら進めるUIデザイン

長谷川広武さん

  • Figma Make
    • 対話しながらデザインを作ってもらえる
  • プロンプトとプレビューされたUIが並んで表示される
    • UIの場所をポインターで指定してそこを直してって言えたりする
  • プロンプトをしっかり作り込んでやらせないとちゃんとしたものが出ない
  • 画像やテキストがイマイチでもどんな情報を置くと良さそうかの参考になる

デザインツール無しでUIデザインを完結させる試み

綿貫 佳祐さん

  • AIベースの開発ではデザインデータありきではつらさがある
  • デザイントークンをセマンティックに作成
    • 色やサイズや余白などの基本要素の定義
    • red-500みたいな値に意味のある名前をつける
    • AIも人も意図を理解できるようになる
  • コード編集ができるAIで生成
    • Webチャットなどではコンテキストを毎回渡さないといけない
    • AIエディタで作っていく
  • CursorBrowserで調整
    • ページのプレビューでGUIで調整ができる
  • 直近だとPencilというサービスが出た

2025年の活動まとめ

勉強会

  • オフライン勉強会160件
    • 札幌1
    • 仙台1
    • 金沢1
    • 新潟2
    • 名古屋1
    • 京都2
    • 大阪5
    • 福岡2

読者

  • 技術書など41冊

資格

  • 資格取得7件

野球観戦

2025年12月に読んだ本

  • 2025年12月に読んだ本の記録です
  • 今月は4冊
  • 試験に時間をかけたのでほとんどは年末の駆け込み

ソフトウェアテスト教科書 JSTQB Foundation

www.shoeisha.co.jp

みんなのアジャイル

gihyo.jp

  • アジャイルに関する複数人のコラムから構成されている本
  • プラクティスの話やマインドの話、開発技術に寄った話などさまざまで、ところどころに自分に役立ちそうなTipsを発見できた

いちばんやさしいアジャイル開発の教本

book.impress.co.jp

  • アジャイルジャパンのブースでもらったので読んでみた
  • 少し古めの本ですが、中盤移行にある具体的なTipsがとても参考になった

現場の「あるある」から学んだ 今すぐ使える「UIデザイン」41の法則

www.shoeisha.co.jp

  • 業務支援システムを題材に使いやすいUIの例を紹介してくれてる本
  • 非デザイナーだけどUIデザインをしないといけない、といった立場の人にとても役立つ内容だなという印象でした

「Registered Scrum Master® Training」を受講してきました

  • 12/18と19の2日間Registered Scrum Master® Trainingを受講してきました

scruminc.jp

背景

  • 実はRSMの前進のLicensed Scrum Masterを2018年に受講したことがありました
  • 時間が経っていることもあるし、当時と自分の状況や経験も変わってきたので再受講してみました
  • 他のスクラムマスター研修でもよかったんですが、受けようと思った時に一番直近だったのがこれだったので

研修内容

  • 受講者は40人くらい
  • 最初にグループ分けのためにスクラム/アジャイルの経験順に並ぶというワークがありました
    • 自分の経験が何年か難しいけど少なめに4,5年と言ったら圧倒的に一番長い人になってしまいました
    • 2番目が3年くらいで1年以上は10人程度
    • 未経験もたくさんいた
  • 一度受けたことがあると言っても7年半前なのでだいぶ記憶は薄れてました
  • 知ってることと違うと思うこともあって、後から前回の資料を見返すと内容が変わってるところも多々ありました
  • カリキュラム自体は初めて知ったということはそんなになかったですが、QA対応がとにかく手厚くてたくさん質問にこたえてもらえました
    • QAの模造紙に付箋を貼っていくと合間に拾ってくれるスタイル
  • あとはグループワークがとにかく楽しかったです
    • 始めて会った人たちと2日間ワークしただけでしたが、このメンバーでもう何日もやってたいなという感想でした
    • チームとして何か動くことが好きなのかなと自分でも不思議でした

資格の認定

  • 研修終了後に試験を受けることで認定されます
  • 2018年に取得したものが復活して有効期限が延びるという形になりました

今後について

  • 今回の受講は仕事に活かすというより趣味での参加でした(自費です)
  • 今の現場ではスクラムは合わないなというのを再確認できたという面もありました
  • ただ、アジャイル/スクラムの考え方が好きだというのは変わらなかったのでマインドとして大事にしていきたいです

「LayerX QA Night#1」に参加してきました

バクラク事業部QAについて

中野さん(LayerX)

  • QAチームのミッション
    • バク楽品質でワクワクする働き方を
  • QAチームのバリュー
    • 最速思考
    • 専門性高めながら何でもやる
    • 当たり前なQAを疑う
  • 再現性と標準化の壁
    • チームに1人ずつ派遣してるのでサイロ化しがち
  • スケールと効率化の壁
    • サービスの立ち上げがはやい
  • AI活用の促進
    • 使って入るがブレイクスルーは起こせてない
  • テストするチーム->チームが品質を作る
    • 品質をチームに移植する
    • QAコーチ制度
    • 伴奏 - コーチング - 自走
  • AIエージェント構想

AI Workforce事業部QAについて

山本さん(LayerX)

  • Ai Workforce
    • 受託より効率的にはやく
    • SaaSより複雑な問題を解く
  • QAチーム
    • 社員1人と業務委託1人
    • 即時リスク対応
    • プロセス整備
  • 現状の課題
    • フェーズの変化
      • PoCからPMFに到達した所
      • スピードもだけど信頼性や使いやすさも大切になる
    • 属人的なテスト
      • 少数精鋭な開発者で進めていた
    • Platform x FDE
      • この組み合わせでのQAの最適解の前例がないので模索してる
  • Platform QA
  • FDE QA
  • AIによる体系化
    • 誰でも同じ品質で実行できる環境

パネルディスカッション

中野さん(LayerX)
山本さん(LayerX)
小山さん(LayerX)

  • スピード感のある開発の中でのQA
    • 近い領域のプロダクトをさわってるかたまりでユニット
      • その中でかける体力を調整しながら
    • 毎週リリース日が決まってる
      • はやめにステージングにあげてもらってテストしてる
      • エンジニアも自分たちでテスト
      • リグレッションテストも
  • 割り込みが多くコンテキストスイッチの切り替えが激しい中でどう品質に向き合っているか
    • まとまった作業時間を確保
      • 木曜はミーティング入れないとか
      • カレンダーに作業の予定を入れてブロック
    • 多少の余白を持ったスケジュール
      • 割り込み前提
      • 80%くらいで
  • A4QA/AIをどうQAに活用していくか
    • 自律的な探索的テストをするエージェント
    • テストのプランニングより後
    • リグレッションテストがたくさんあるからコストを抑えた実行
      • 修正を見て必要なテストを選別させる
  • 複雑なドメインのキャッチアップ
    • AIに仕様書読ませてテスト項目作ってもらう
      • 間違ってることもあるがそれを指摘したりやりとりしてると理解が深まる

「JAWS-UG初心者支部#72 re:Invent &2025Update会」に参加してきました

re:Invent2025で見つけたコミュニティ参加の意味

深津 新太郎さん

  • 初回はAWS初心者
  • 2回目は資格全冠獲得して
    • セッションの理解は深まった
  • その後はコミュニティビルダーとしても
    • コミュニティとして経験できること

Keep calm and go build now Beginner

大槻さん

  • Brown your T
    • 深く探求する
    • それを教えて可能性を広げる
    • 更新者に役割を渡していく
  • 現地の人との交流
    • システム構成図は共通言語
  • 現地はKiroが溢れてた

Amazon Connect アップデート! AIエージェントにMCPツールを設定してみた!

鈴木陽介さん

  • Amazon Connectセンター
    • コンタクトセンターを作るサービス
  • Connect AI Agent
    • オペレーターを挟まずにAIが一次回答
  • Amazon Connect MCP
    • コンタクト属性
    • ナレッジ検索
    • タスクやケースの参照

待ち望んだre:Invet!そこで何を持って帰れたか

宮本雄樹さん(TIS)

  • 学んだこと(技術外)
    • ハンズオンを中心に受講できて使い方のイメージがついた
    • 外国のSAに質問できた
    • ディスカッション系セッションにはいるのが難しかった
  • 学んだこと(技術)
    • AIセッションが多かった
      • Amazon Quick Suite
      • Kiro autonomous Agent
      • AWS Security

リージョナルNAT Gatewayが追加されたのでNAT Gatewayについて改めて勉強してみた

なべみつ(渡邉光洋)さん

  • Regional NAT Gateway
  • Regionalになると
    • デフォルトでリージョンレベルの冗長性
    • パブリック型のみ
    • 置く場所を考えなくて良くなる
    • ルートテーブルの共用が可能

aws loginで楽に安全に

Hirotoさん

  • アクセスキーを発行せずにCLIを使える
    • ローカルにキー置かないから安全
    • 短時間しか使えないから安全
  • 時間制限の情報がjsonでロカルに置かれる
  • 15分がデフォルトで12時間まで設定できる

re:Invent初参加の成果と学び

久保征敬さん

「さようなら2025 〜AI・エンジニアリング・デザインの忘年会〜」に参加してきました

AIでAIデザインツールを作った1年間の実践

池上 涼平さん(株式会社Goodpatch/株式会社Layermate)
https://speakerdeck.com/seanchas116/aiteaitesainturuwozuo-tuta-1nian-jian-noshi-jian

  • Layermate
  • 開発した流れ
    • 要件定義 - 仮デザイン(AI) - 実装
    • SQLなどもいい感じにやってくれた
    • デザインのラストワンマイルは人
  • AIによるデザイン
    • 文字ベース
    • 画像ベース

KiroとFigmaで進めるAI仕様駆動開発について - エンジニア x デザインの境界線 -

佐藤 雄太さん(Amazon Web Service Japan)

  • AIが発展した今クリエイティビティとアイデアがより大事
  • Agentic IDE
    • Kiroなど
    • Figma MCP Serverと連携すればAIがデザインからコードを生成してくれる
  • VideCodingの課題
    • 単純な仕様以外はうまく作れない
  • 仕様駆動開発
    • KiroのSpecモード
    • 対話を通じてmdを書いてくれる
    • MCPをつなぎすぎるとコンテキストを圧迫する
  • Kiro powers
    • 動的にMCPを読み込める
    • KiroのIDEからワンクリックでMCPを設定できる

「宇宙×不動産」を生成AIで切り拓く

今川裕喜さん(株式会社WHERE CPO)

  • 衛星データから不動産の状態を推定
  • 不動産書類の構造化
  • 従来のNNと生成AIを組み合わせて

『喋れるデザイナー』を育てる組織論。コンテキスト力を高めるマネジメントについて

川村真央さん(株式会社SODA)

  • 喋れないデザイナー
    • ビジネス要件はPMが決めることと思って考えない
    • Howが欠如してFigmaを作ってしまう
  • マネージャーとしてどうするか
    • 情報を噛み砕きすぎない
    • なぜのノック
      • 作る前にロジック構築

なぜSupabaseがAI開発のバックエンドとして使われるのか

タイラーさん(Supabase Engineer)

  • Supabase
    • 週末に簡単に作れるけどmillionまでスケールするというコンセプト
  • 機能
    • ログイン
    • ストレージ
    • リアルタイムコネクション
  • AIツール連携
    • AIにアプリを生成させる時にSuperbaseが使われることが多い
    • PoCで作ったものをそのまま本番に持っていける

2026年、デザイナーはなにに賭ける?

飛田 和浩さん(サイボウズ株式会社)

  • 2025年
    • MCPサーバが普及
    • FigmaのDev Mode MCPサーバ
    • Figma Schema
    • Cursor Visual Editor
  • Figmaで実装ができるし、エディタでデザインができるようになった
  • 何に賭けるといいか
    • 体験に磨きを書ける
      • 動くものを見ての議論がしやすくなった
      • 作るハードルが下がったので差別化が難しい
    • 資産を増やす
      • AI Readyな状態を作る

LLMの取り組み、全部(一部)見せます!

髙橋 健太郎さん(株式会社LayerX)

  • 価値検証の速度があがった
    • 問題が起きる速度もあがった
  • QAに効率化
    • notion/FigJam/FigmaをPDF化してGPTにインプット
    • テストケースを作ってもらう
    • 特定フェーズだけでなくプロセス全体の効率化を意識するといい

TypeScript製 Strands Agentで作ったAIエージェントをAgent Core Runtimeにデプロイしてみた

江口 純矢さん(株式会社コドモン)

  • Strands Agent
    • AI Agent作成用のSDK
    • Python版もあるがTS版が最近出た
  • HTTPサーバでラップするとAPIとして簡単に公開できる
    • コンテナ化して公開する
  • Agent RuntimeにデプロイするとAWS上で動かせる

コムデマネージャーがプロダクトデザインに挑戦した。むずかしくて楽しかった。

早津 あいみさん(ファインディ株式会社)

  • コミュニケーションデザインとプロダクトデザインの違い
    • ドキュメンテーション大事
      • 関わる人が多く言語化力が問われる
    • リリースがゴールではない
      • 納品して一区切りではなく改善が始まる
    • 中間成果物ゆえに調整が大変
      • 合意を取る相手が多い
    • 全体像をつかむのが難しい
      • 画面が多く分岐も多いので影響把握が大変

Figma Makeで、LLM連携プロトタイプを作る方法

村上 隆紀さん(株式会社Awarefy)
https://note.com/ryuuuuuyr/n/n3c093e6beb70

  • Figma Makeでプロトタイプが作りやすくなった
    • ただAI体験を作ろうとすると難しい
    • 動かしてみないとわからないことが多い
    • ダミーを入れてみるくらいしかできない
  • Figma MakeでAIを動かす
    • Figma Makeで裏側でLLMつなげることができた
      • Supabaseを呼んでいる
    • リアルなデータと動きで検証すると改善点が見えやすい

ブラウザの組み込みAI Gemini Nanoで自動制御チャレンジ

菅原 のびすけさん(プロトアウト)

  • Chromeの組み込みAI
    • オフラインでローカルでgemini使える
      • 4GBくらいダウンロードされる
    • マルチモーダルで画像も音声も読める
    • 無限コストで使える
  • ブラウザゲームをやってる様子を読み込ませて操作させる

「JSTQB認定テスト技術者資格 Foundation Level」に合格しました

jstqb.jp

きっかけ

  • QAやテスト界隈のコミュニティに顔を出すことが多く、基礎知識としてよく聞くので受けたいと思ってました
  • アジャイルジャパンでJSTQBがスポンサーになっていて宣伝していたのを聞いて勢いで申し込みました

受験に向けた勉強

  • 参考書が何種類かありましたがこれを使いました
  • 勉強に時間をとれなかったので前日に一周読み終わって、直前にざっと二周目を読んだくらい

www.shoeisha.co.jp

  • 試験申し込みの前にちょうど読んでたこちらの本も知識としては役に立ちました

gihyo.jp

結果

  • 点数は非公開ですが合格してました
    • 合格ラインが全40問の60%なので割と余裕はあったと思います

受験してみて

  • テスト技法の話は仕事上での馴染みもあるし、しっかり学べて面白かったです
  • テスト計画やテストコントロールなどあんまり考えたことがないフェーズの話も新しく学べてよかったです

「React Tokyo ミートアップ #12」に参加してきました

感想

  • ディスカッションや交流が多めのイベントで今回が2回目の参加でした
  • 最近Nextをさわる時間が増えたので周りの意見が聞けて有意義でした
  • 会話しやすい空気感なのでまた参加したいです

読みやすいコードとはなにか?

じょうげんさん

  • co-location
    • 関連するコードを近くに集める
    • 技術レイヤーごとにフォルダがわからていると処理を追う時に飛び回らないといけない
    • 近くにまとめるとディレクトリを分けなくてよくなりネストも小さくなる
    • 同じファイルにまとめてしまうという選択もある
    • コンポーネントの関数内にuseCallbackで定義してしまう案もある
  • なぜコードを遠ざけるか
    • 整理されてるように見える
    • 過去の慣習
  • ファイル内での宣言
    • 上から下へ読めるように
    • メインの処理が最後にあると読みづらい
  • 脳のリソースを意識する
    • 記憶して読んでいかないといけないのはつらい
    • 正常系は最後に

「紅白LTセッション & 2025年ラストMeetup#6(agile effect)」に参加してきました

まなぼう!

田中 基淳さん(株式会社レッドジャーニー)
https://www.docswell.com/s/mot0aki/KYVXQ3-2025-12-11-192720

  • アジャイルでスキルが上がるか
    • きっかけにはなるが
    • ペアプロとか振り返りとか
    • スキルそのものをつけることにはつながらない
  • 技術的卓越性と優れた設計技術に不断の注意
  • AI使ってコードは書けるようになったが
    • スキルにはつながらない
    • AIは増幅器
  • 学ぶのにAIを使う
  • ソフトスキルとして言語化抽象化力

スクラムマスターから聞いたお悩みについて考えてみた

Haradyさん

  • アジャイル向きでないチーム?
    • やる気成長意欲がない
  • 向き不向きを判断するのは外の人じゃない
    • 何でも話してもらえてるわけではない
    • 興味を持って受け止められているか

スクラムマスターがチームの成長を止める瞬間

荒木 康司さん(富士通株式会社)

  • スクラムマスターと現場の問題
    • 過干渉により自律性を阻害
    • 指示待ちになってしまう
    • 開発のリーダーがスクラムマスターになるようなケース
    • 善意でやってしまってるケースが多い
  • 教える人でなく引き出す人でなければならない
  • スクラムマスターの役割
    • 奉仕する真のリーダー
    • ティーチングではなくコーチン
    • 指示型から委任型
  • 待つ/問う/見守る

大企業の壁を突破せよ!中途社員が仕掛けるアジャイル革命

荒木 慶彦さん(三菱電機株式会社)

  • Serendie Street
    • みなとみらいのオフィス?
  • スプリントゴールは未来の成果で
    • プレスリリースを想像したり

課題解決はマネジメントの◯◯

大瀧 純平さん(ディップ株式会社)

  • 課題を解決すること
    • 課題があるということ
    • 課題になる前の種をつぶしておきたい
  • 放置したら課題になるなということ
    • 見つけるための仕組みはさまざまある
    • 形骸化してると見つけられなくなる
  • 効果のある検査
    • ゴールと計画を共通認識として持てている
    • 周囲で起きてる影響を与えそうなことが見えてる

アジャイルをDevOpsする

森實 繁樹さん(株式会社レッドジャーニー)
https://www.docswell.com/s/samuraiRed/ZQXD77-2025-12-12-072100

  • アジャイル
    • 今を認知し学習を継続していくこと
  • アジャイルでやりたいこと
    • 驚き最小の原則
    • 何かあったらすぐに戻せる
  • 計画は必要
    • 検証と再適用
    • 計画を変更するプロセス
  • アジャイルが速いとは
    • 学習の早さ
    • 頻度と深さ
    • 自分たちの今までとの相対的な速さ

「Encraft #21 QAキャリアこれから会議──AI時代をどう生きる?」に参加してきました

パネルディスカッション

松谷峰生さん(MIXI)
青海貴大さん(令和トラベル)
上原晃義さん(ナレッジワーク)
家登あずささん(ナレッジワーク)/モデレーター

このままで通用するのか

  • コードも書けないといけなくなってきた
    • AIに書かせることもできる
    • 必要なものを必要な時に作れる
  • 仕様が詳しいだけだとAIに勝てない
  • 開発スピードが上がってQAがボトルネック
  • 開発者もQAをやってるケースが多い
  • 今のQAに求められること
    • テストの戦略としてのスペシャリストは今も求められているところ
      • すぐに身につくようなところではないスキル
    • テスト以外で品質を担保できること
    • 人のミスを防ぐ仕組み
      • 実装が悪かったで終わらせない
      • どうやったら根本的で再現性のある仕組みができるか
    • AIのQAをどうやっていくか

スキルとキャリア

  • AIとの向き合い方
    • テスト業務をAIに合わせて変えていく
    • 好奇心をもって学んでいく
  • QAとしての最初の一歩
    • テスターとしてキャリアを積んで〜というのがAIでなくなる?
    • 人がやるテストはまだ残り続ける
    • 自動テストから始めるのはしばらく需要はありそうだからよさそう
  • QA以外にも手を伸ばしてシフトしやすいようなキャリア
  • 他の職種の人が簡単に追いつけないQAのスキル

明日から何ができるか

  • AIを使いこなす
    • いろんな事例が出てるから真似してみるところから
    • 試すことで合う合わないなど調整していける

「Agile X Conference」に参加してきました

日立建機におけるアジャイルの取り組み

猪瀬 聡志さん(日立建機株式会社)
鈴木 雄介さん(グロース・アーキテクチャ&チームス株式会社)

  • 建設機械
    • 長期間かどうする
      • 10年以上や30年超えることも
    • 大きな負荷がかかる
      • ひとすくい70tだったり
    • さまざまな環境
      • 粉塵、雨風、振動、温度
  • LANDCROS Connect
    • 機械の情報などを可視化するシステム
    • 他社も含めた機械を一元管理
  • 従来のシステム
    • システム間の連携が密で変更が他に波及してコストが高い
    • API化してマイクロサービスにしていくことを考えた
    • ストラングラーパターン
  • 現在のシステム
    • k8sが960pod
    • 年間600デプロイ
  • 開発の変化

日産が挑むアジャイルとAI駆動開発による「内製化」への道

工藤 然さん(日産自動車株式会社)
安田 忠弘さん(クリエーションライン株式会社)

  • 販売現場のDX
    • 顧客接点/ディーラー接点
    • シームレスなコミュニケーションを店舗でもオンラインでも
  • 発注文化/完璧主義/ベンダーロックイン
    • 自動車メーカーの文化として完璧なものを作って出す
      • 確実にやるけどとても遅い
    • ビジネス側の人員は入れ替わりが激しい
      • 運用の委託先が長くて詳しいという状態になる
      • ブラックボックス化されて中身が分からなくなる
  • AI駆動開発
    • AI駆動でプロトタイプ開発
      • 従来の3.5倍の速度で
    • 見えるものができるまでの速さが大きな変化

「若手育成」"放任"じゃダメ、"介入"しすぎもダメ

武富 健志さん(株式会社酉島製作所)
天野 勝さん(株式会社永和システムマネジメント)

  • 酉島製作所
    • ポンプを作ってる会社
  • アジャイルのプロジェクト
    • 人と話ながらものづくりをする 

Agile X Conference ニッセイ x レッドジャーニー

練尾 諭さん(日本生命保険相互会社)
市谷 聡啓さん(株式会社レッドジャーニー)

  • ニッセイにおける組織/開発課題
    • 過渡なリスク対応力
      • 全てにおいて同じレベル感である必要があるのか
    • 受発注の関係
      • システムは子会社がやってる
      • ワンチームになれない
    • グループ会社では実績があるが本体ではPoC止まり
  • アジャイルへの期待
    • 権限委譲
      • 決めるべき人が決められるように
      • きっかけとしてアジャイル
  • ハピナビ
    • 新規事業を赤いるで
    • PoCではなくtoCの実開発
    • 部長課長はスクラムチームの外に
      • 決めるべき人が決められるように
  • アジャイルCoE
    • whyから始めた
      • 合宿で
    • ステップを刻んでCoE設立
    • まずはDoアジャイルでもいい
      • 裾野を広げていく
  • アジャイルについての気付き
    • 現場のメンバー
      • 圧倒的なスピード
      • 開発量が増えた
      • ウォータフォールはできる人は手が相手持て余していた
      • アジャイルだと必要以上のこともやろうというモチベーション

ゼロからの疾走!三菱電機×KAGが実践した、アジャイル初挑戦のリアル

江口 貴紀さん(三菱電機株式会社)
山田 嘉彦さん(KDDIアジャイル開発センター株式会社)

  • 新しい事業の始まりでアジャイルを選択
    • 主要製品担当の各課から1名ずつ選出
    • メンバーはアジャイル開発の経験はなし
    • 予算はもらえたのでKAGの支援を受ける
  • プロジェクト
    • 24年2月に始めて24年8月に無償のPoCを開始できた
    • 25年3月に満足度85%を突破し25年5月に有償化を決定
  • 異文化の融合
    • KAGは関東で三菱電機は名古屋
    • 製造業のドメイン知識
    • 同じ目線で議論できるチームに
      • 課題や価値観
      • 同じ情報を持つ
    • お互いのオフィスに行ったり
    • バーチャルオフィスを使ったり