Closed6

Developers Summit 2025 KANSAI(2025.09.17)(デブサミ関西)参加メモ

m.kitom.kito

変わる世界と技術者の選択

https://event.shoeisha.jp/devsumi/20250917/session/6268/


当日のTweet

  • ソフトウェアファースト型の組織からAIエージェント型の組織へ
  • 人間は、どうしていくべきなのか
    • AIに何を任せるかを設計する役割
      • なんの判断をAIに委ねるのか
      • どこに人間の関与を残すのか
    • AIの限界を理解する
        * 誤答、ハルシネーション、過学習、バイアス、暴走
    • ガードレール設計
      • 入力、出力、Human In The Loop
  • AIが支援するのは、意思のある人間
    • 置き換えでなくパートナーとしてのAI
    • 意思がなければ、主体性の欠如や依存になる

響いた言葉

正しく使うことの重要さ

m.kitom.kito

エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト

https://event.shoeisha.jp/devsumi/20250917/session/6273


当日のTweet

  • マトリックス型組織で発生した課題

    • 職能マネージャーがピープルマネジメント中心となり開発業務への関わりが薄くなる
    • 意思決定がプロダクトマネージャーに集中する
    • 事業戦略との接点が薄れ、チーム自体の目的に対しての関心が薄れた
  • 価値創造ラインのブレイクダウンとチームと事業の認識の齟齬をなくす

    • 製品の単位を細かくしてEMロールを配置
    • トップダウンではなく縦横関係のEM同士の会話からチーム目標のすり合わせ
    • HOWの部分の実装をチームに委ねる体制を構築
  • 組織変更の結果・・・

    • 組織を変える取り組みをしてから成果が目に見えてくる
       - 魅力的なリリースの増加
       - 事業戦略の実現に向けた投資や技術的負債への取り組みが進展した
       - 成果物に対してオーナーシップを持つことで、事業貢献を意識できるように
  • 今後の課題

    • プラットフォームエンジニアリングなど顧客から離れたチームのアライメント
    • 組織全体の認識合わせとマネージャーの充足
m.kitom.kito

「その開発、認知負荷高すぎませんか?」Platform Engineering で始める開発者体験カイゼン術

https://event.shoeisha.jp/devsumi/20250917/session/6284


当日のTweet
https://x.com/mkitokitom/status/1968196442864206094

  • 認知負荷が高いと本来の目的へのコミットの妨げに
  • プラットフォームエンジニアリングとは
    • 開発者がセルフサービスで利用できる、信頼性の高いプラットフォーム
  • 基盤作りだけがプラットフォームエンジニアリングではない
  • ドキュメント整備、テンプレート作成、共通ライブラリやCLI開発も重要
  • 開発者の課題を常に追求し続けることが大切
  • 全てを自分たちで解決しようとせず、社内外の専門家を巻き込む
  • 開発者の認知負荷は「サイレントキラー」
    • まずは課題の可視化から始める
  • 完璧なプラットフォームを目指すのではなく、開発者と対話し改善し続けるプロセスが重要
  • 身近な痛みを解消する小さな一歩から始める

参考

https://note.com/yoshifumi_tahira/n/n2c2b1d7f82e3

m.kitom.kito

つくる力をうちから、ダイキンのアジャイル内製改革

https://event.shoeisha.jp/devsumi/20250917/session/6276


当日のTweet

https://x.com/mkitokitom/status/1968223021338071386

  • 組織スケールの課題に対して

    • チームを特定のユーザータイプに注力するよう再編成
    • ドメインの境界を明確に設定
    • 各チームが自分のプロダクトゴールに集中できる環境を構築
  • チーム間の一貫性と自律性のバランス

    • デリゲーションポーカーの考え方を基にした権限の整理
    • 4つのレベルで決定権を明確化:
      1. チーム内で独立して決定できるもの
      2. チーム間の合意が必要なもの
      3. チームの合意があっても決定できないもの
      4. チームが積極的に活動しても実現できないもの
    • 各チームの権限を一つずつ整理し、共通認識を構築
  • 事業部との関係構築に対して

    • 社外の内製開発チームとの交流機会の創出
    • カンファレンス登壇への事業側メンバーの参加促進
    • ビジネス側と開発側が共同でワークショップに参加
    • プロダクトゴールやスクラム用語の共通言語化
m.kitom.kito

AIと共に、組織をどう進化させるか? 〜 “熱量”を“文化”へ昇華させる、持続可能なAI活用の仕掛けづくり 〜

https://event.shoeisha.jp/devsumi/20250917/session/6287


当日のTweet
https://x.com/mkitokitom/status/1968235160383668280

  • 創業25年で20年以上運用してきたレガシーシステムのモダナイゼーションが課題
  • モノリスシステムの分割・マイクロサービス化を目指している

2023年初期の取り組み

  • 社内Slackボットを開発し、GPTモデルへのアクセスを提供
  • GitHubコパイロットを先行者に展開
  • 全社でAIツール活用の模索を開始

2023年後期の取り組み

  • AIを活用したモダナイゼーションプロジェクトを小規模専任チームで開始
  • LangChainを使ったソースコード分析や仕様書作成ワークフローを構築
  • 内製ツールによりモダナイゼーション作業が1日→10分に短縮
  • 4ヶ月後、モデル・ツールの急速な進化により、内製よりも既存ツール活用へ方針転換

2024年の取り組み

  • AI駆動開発チームを創設
  • 組織全体へのAIツール展開と浸透を目指す
  • キャズム理論を適用:熱意あるメンバーから組織全体への展開

展開戦略:3つの取り組み

  • 熱量を文化へ昇華させる
  1. AI駆動開発ツール価値探索プログラム
    • 各チームからエヴァンジェリスト(熱意あるメンバー)を1名選出
    • AIツールの使いどころを積極的に探索
  2. トレーニングラボ
    • エヴァンジェリスト同士の繋がり形成
    • プラクティス共有の場を提供
  3. 道場
    • エヴァンジェリストの基礎スキル習得機会
    • ツールの基本的な使い方研修

実践から得た学び

  • レガシー環境の壁:非英語プログラミング言語や文字コードの問題により、AIが効果的に推論できないケースあり
  • ツールの効果差:人間を支援するツール(Cursor)より人間を置き換えるツール(Copilot)の方が効果的
  • 活用度の差:全エンジニア約400人中、ツールを積極的に使いこなしているのは約15人程度
  • 単純なツール展開の限界:ツールを展開するだけでは組織の生産性は大きく向上しない
このスクラップは2ヶ月前にクローズされました