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とエンジニアの意思決定プロセス～
- 責任追求は何故起きるのか
- 客観的に判断できるデータがない
- 客観的に判断できる基準がない
- 失敗を責めてしまう文化
- そういう環境で何が起きるか
- 職種どうしの対立
- 責任回避の防御的な行動
- イノベーションが生まれない
- 優秀な人材の離脱
- SLOとプロダクト指標
- ビジネスKPIを洗い出し把握する
- 技術指標をビジネスKPIに翻訳し理解する
- PMも見る共通のダッシュボード
- エラーバジェットで意思決定
- 失敗=悪にならないように
- 許容できるリスクをマネジメント
- ユーザ体験の状態をもとにどれだけリスクをとったり排除したりするか天秤にかける
- ポストモーテムで失敗を経験にする文化
- エラーバジェットを元にPMとエンジニアでリリースの判断をする
- 失敗からの教訓
- データドリブンで何でも決めすぎない
- ことではなく人に目が向いてしまうクトがある
- 判断材料の一部として使う
- １人で全部を変えようとしてた
- 共感者を見つけるのが最優先
- 当事者意識を持ってくれる仲間を
- 完璧を求めすぎた
- 指標を追うことに疲弊
- 見るべき指標が多いと疲れてしまう
- データドリブンで何でも決めすぎない
AI時代のエンジニアに求められる「技術の先」にあるスキルとは？ ─ログラス×SkillCanvasが実践するエンタープライズSaasを制する組織デザインー
林 宏昌さん(SkillCanvas)
広瀬 丈さん(ログラス)
川村 剛司さん(ログラス)
- ログラスのサービス
- エンタープライズSaaS
- 高信頼性
- 複雑なドメイン
- 長期運用
- AI時代他のサービスとの差別化が必要
- 技術スタックではなく人と組織の設計が競争力になる
- エンタープライズSaaS
- ジュニアミドルからリーダー層への壁
- カッツモデルの応用
- 基本となるスキル
- プロダクトエンジニアとして必要なスタンス
- プロダクトエンジニアとして必要な技術的知見
- 事業リーダーとしてのポータブルスキル
- 壁を突破できる人とできない人の差分
- スタンスやリーダーとしてのポータブルスキルが大きい
- 本質課題の特定と抽象化
- ステークホルダーとの合意
- リスクを踏まえた意思決定
- 逆算思考によるロードマップ
- 職種を問わないビジネススキルが差が大きかった
- これらを出来てる人を壁を超えた人としてるのでは・・？
- 技術を学ぶのは分かりやすくてやれてる人が多い
- レイヤーが高い人ほど大きい案件をやるからこれらの経験も積むことになる
- スタンスやリーダーとしてのポータブルスキルが大きい
- カッツモデルの応用
生命保険会社におけるテスト自動化の取り組みー品質と事業成長の加速
今村 貴紀さん(オーティファイ)
松井 康浩さん(オリックス生命保険)
- AIによってコーディングは加速している
- テストはそうなっていないことが多い
- 開発の中でテストの割合は4割
- テストがボトルネックになってくる
- 改修が進むにつれてテストの量は雪だるま式に増えていく
- テストの観点を出せるメンバーは属人化しがち
- 生命保険会社特有の事情
- テストにかける工数が全体の50%
- 主要システムだけで50以上
- ブラウザやOSのバージョンアップなどある度に手動でリグレッションテスト
- 不具合は許されない
- テスト自動化の取り組み
- 2020年頃から自動化のツール導入
- 作り込みすぎてテストのメンテナンスが大変
- 社内環境の制約もあり動作が安定しない
- 2022年にAutifyを導入
- マルチブラウザテストも自動化
- 社内で口コミで広まっていって定着した
- 2020年頃から自動化のツール導入
- 自動化のスコープ
- E2Eで繰り返し実行するテスト
- マルチブラウザテスト
- リグレッションテスト
- 実行の仕組み
- 週に一回とか定期的に実行
- 土日に定期実行
- 定期的に回してるとテストのメンテナンスの間隔も小さくなり対応が軽い
- 週に一回とか定期的に実行
- 実行環境
- 従来は
- 昔はテスト用の端末を借りて
- 充電して起動してOSバージョンアップが走ってみたいなことをしないと
- 手動でスクリーンショットとって社用PCに送ってエビデンス作って
- Autifyだと
- 一度作ったら使い回せる
- 拘束されるのは結果を見るとき
- 従来は
- IT部門では定着してきたので業務部門の受け入れテストにも今後は力を入れる
エンジニアキャリア図鑑～組織と事業を伸ばす「エンジニアリングマネージャー」の真価とは？
小田中 育生さん(カケハシ)
miisanさん(令和トラベル)
新多 真琴さん(LayerX)
- EMとしてやっていること
- ひとりひとりのポテンシャルを発揮させて組織としての生産性を上げる
- 構造的な課題を仕組みで解決
- プロダクトの価値を守ることはなんでも
- 人が増える中でのオンボーディング整備
- EMになったきっかけ
- 自分の給料上がらないなと思った時に事業がどんな構造か意識するようになった
- 大規模案件で人をつぎ込んで対応した時に持続性も必要だと感じた
- 自分がサービスをどうしたいかを考えた時にマネジメントの方があっていた
- 自分がそれをつくるだけでなくどういうチームで作るとか人に興味があった
- 現場にいたいからマネジメントやりたくない問題
- マネジメントのことをよく知ってないだけかもしれない
- EMとしての葛藤
- 自分が我慢すれば済むという方向に行きがち
- どこかで爆発してしまう
- マネージャー自身が持続できるか
- 三方よしにしないと
- メンバーには失敗しても大丈夫というが自分はそれに耐えられない
- マネージャーが人の力を借りれない時
- EM四象限の全部に強い人はいない
- けどそれを求めてしまう
- ジョブディスクリプションも全部できる人を求めてしまう
- そのタイミングで捨てていいものがあるはずなのでやらないことも決めないと
- 自分が我慢すれば済むという方向に行きがち
- エンジニアと事業視点
- 事業視点を持ててないと思ってるエンジニア多い
- でも本当に言われたことを言われた通りだけしかやってない人はいない
- それは何でなのかと考えられている人は多い
- マネージャーはそれを考えるのに必要な情報を渡さないといけない
