以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2026/02/19/171403より取得しました。


「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
    • ステアリングポリシー
      • 全部与えるとコンテキストが消費される
      • 出来る限りルールは必要な時に必要な分読み込ませる構造
    • 監査証跡
      • 何をやったかは残るがなぜそう判断したかは不十分
    • 状態管理
      • フェーズごとの完了したタスクなど進捗を記録させる



以上の内容はhttps://ozaki25.hatenadiary.jp/entry/2026/02/19/171403より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14