- 2024/2/16
- https://event.shoeisha.jp/devsumi/20240215
- https://codezine.jp/devonline/archive/17
- 2日目もセッションの傾向は1日目と同じ感じ
- 取り扱う分野が幅広いので昔の知り合いにも会えて話ができたのが良かった
- 雅叙園の時よりもスポンサーブースに立ち寄りやすい構造なのがよかった
ビジネスと開発が真のパートナーになる、事業に貢献するエンジニアの姿とは
- 榊 淳さん[一休]CEO
- 伊藤 直也さん[一休]CTO
- 押久保 剛さん[翔泳社]モデレーター
CEOとCTOの壁
- 伊藤さんがジョインして8年くらい
- 当初は壁があった
- レガシーなシステムで技術的負債がたくさんあった
- システムを整備したいエンジニアとそんなの関係なく進めたいビジネス
- 変化のきっかけ
- システムのことやってるだけでビジネスに貢献してない
- お客さんのところにいって声をきいた
- CTOが変わると壁の位置がだんだん下にずれていく
- 数年かけて現場レベルまで落ちた
- エンジニアの変化
- コロナ禍のgo to travel
- 仕様が決まってないけどやることが決まっていて大変だった
- エンジニア主導でビジネスを動かせた
- 越境するまで
- 得意なことだけやっていたかった
- その世界の中だけでも大変なこともあるしうまくやれれば称賛される
- 経営者としてはそれじゃダメだった
- 得意なことだけやっていたかった
- エンジニアが陥りがちなこと
- 責任を放棄しがち
- その納期じゃできないとか企画が考えたことがよくなかったとか
- 責任を放棄しがち
GitHubアーキテクトが語るGitHub Copilotが生み出すAIネイティブ開発の実践と次世代エンジニアに求められる新たなスキルとは
- 服部 佑樹さん[GitHub Japan]
- 新田 章太さん[ギブリー]
AIネイティブ開発
- エンジニアの領域で生成AIの利用が広がっている
- 実際に生産性が向上しているというデータもある
GitHub Copilot
- GitHub Copilot Chat
- IDE内でChatGPTらしい体験
- Copilot for Pull Request
- PR内でAIによるタグ付け
- 必要なテストの提案
- ハレーションの存在
- あたかもな振る舞いをするのがリスク
- AIを使いこなしたエンジニアリングが生産性を高める鍵
GitHub Copilotを使ったプラクティス
- 開発時
- コードを指定してチャットで聞けるようになっている
- 対象のスコープをワークスペースとか指定したところとかできる
- PR
- PR作成時に見てもらいたいポイントを勝手にコメントしてくれる
- PRの差分を見てる時に内容についてチャットで質問できる
- AIを使いこなすコツ
- ツールの違いを知る
- 補完/チャットで違う
- Copilotの特徴を知る
- 数百ミリ秒でライセンスが問題ないコードを取得できる
- プロンプトのコツ
- 文脈/意図/明瞭さ/具体性
- ツールの違いを知る
- Copilotデザインパターン
これからのエンジニアに求められるスキル
- 良いコードを書かせるにはそのためのスキルが必要
ログと徹底的に向き合うデータドリブンなサービス運用
- 田中 聡さん[うるる]
ログでデータドリブン開発
- データドリブン開発
- 顧客の行動や市場データをもとに開発を行う
GitHub Copilotは開発者の生産性をどれだけ上げるのか？ ZOZOでの全社導入とその効果
Copilot導入背景
- 開発生産性の可視化向上
- まず量を最大化
- リソース効率とフロー効率
- フロー効率を計測可能な状態へ
導入の懸念
- セキュリティ
- ライセンス侵害
- GitHubが補償してくれる(契約による)
- 費用対効果
- 利用料とコスト削減量
- 試験導入で検証してから入れた
- 利用料とコスト削減量
導入して
- 9割が生産的になったと回答
- 既存コードを読む助けになる
- XCodeが公式で未対応なので少しイマイチ
- 1日あたり1時間以上節約できたという人も
SIerな会社の中でXR(VR・メタバース）を用いた新規事業開発に挑戦して見えてきた景色
- 大北 拓哉さん[TIS]
- 伊藤 清人さん[TIS]
- https://fintan.jp/wp-content/uploads/2024/02/xr-devsumi-20240215.pdf
- https://fintan.jp/page/10293/
XRを使った新規事業
- XR: AR/MR/VRの総称
- 事例
- RE:COLLAB Rooms
- TeleAttend
- XRCampus
- BURALIT
XRアプリの開発
- 3Dモデルなどの部分を除けば普通のWebアプリ
- デザイン
- 事例が少なくノウハウがスクアに
- 触ってみるまで良し悪し判断できない
- プロト作って検証を回す必要がある
- システム構成
- 複数プレイヤーでのマルチプレイは特殊
- 頻繁なデータのやりとり
- 数十人とか動悸させるには専用サーバが必要でコストがかかる
- 複数プレイヤーでのマルチプレイは特殊
- アーキテクチャー
- unityの世界だとあまり確立したパターンがない
- テスト
- 普段とあまり変わらない
- モンキーテストで不具合を出し切る
- 体制
- XRエンジニアを集めるのは大変
探索型のプロダクト開発を始めよう～正しいものを正しくつくる2.0～
- 市谷 聡啓さん[レッドジャーニー]
- https://www.docswell.com/s/papanda/ZXYJY4-2024-02-16-170851
プロダクト開発
- ソフトウェアとプロダクト
- 前者は仕様があってそれを作る
- 後者は仮説検証して価値のあるものを作る
- スクラム開発
- 開発チームとPO分断しがち
- 間違ったものを正しく作るになってしまう
- 何を持って正しい？
- プロダクトを届けるのは大事だが届けるだけでもダメ
- アウトカムが発生しているかどうか
- アウトカムとは収益のこと？
- 収益は活動を続けるために必要な動力源なので目的そのものにはならない
- 収益は結果でしかない
- 後ろだけ見ててもダメ
- 前をみよう
- 成果を捉え直す
プロダクト開発における成果とは
- 成果
- ユーザの目的を果たせているか
- チームが健全であるか
- プロダクトが健全であるか
- チームとプロダクトの健全性を保たないと持続しない
- 3者は一定でなく常に変化する
- 今の判断はいつの根拠によるものか
- プロダクト探索に出て新たな学びを得よう
プロダクト探索
- 成果とはなにか
- ユーザ/チーム/プロダクトの3軸でOKR
- 成果と収益を混ぜない
- 3者の仮説を立てる
- 何がボトルネックか
- 道具は3観点で異なる
- ユーザ調査
- チームの振り返り
- プロダクトの指標計測
- 何がボトルネックか
- 探索活動をバックログ積む
- 開発や運用と同様にスクラムでまわす
- 最適化の罠にははならないように
- いつまでも動けなくなってしまう
- 複雑なことやいろんなことはできないので最初の1つを積んで始める
- スプリントを回して改善していく
- 熱意を持てるものを1つ選んで始める
- 新たな成果を上げるには新たな武器知識が必要
- 学ぶことを置き去りにしてはいけない
テストの完了をゴールにしない！～仮説検証を繰り返し、開発・QA・ユーザーが交流しながら開発することで見えてくる理想の姿～
- 風間 裕也さん[10X]
アウトプットとアウトカム
- アウトプット
- こなしたタスク
- 書いたコード
- アウトカム
- ユーザの行動の変化
テストの完了 = ゴールではない
継続的テストモデル
- いろんなフェーズでテストする
- 実装の前にするテスト
- シフトレフト
- リリース後にするテスト
- シフトライト
- 実装の前にするテスト
- テストはフェーズではなくアクティビティ
シフトレフトの例
- コード実装前に行うテスト
- TDDなどもあるが今回はそれより前段の話
- 受け入れ基準を作成する時のテスト
- リファインメントでやる
- 開発/PO/QAが集まって要件を確認する
- ユーザの操作としてどうなるべきなのかを受け入れ条件に入れるようにする
- 何をもってこのタスクが完了となるかはっきりする
- →テストと思ってないけど意外と自分はやってる気がする
シフトライトの例
- リリース後に行うテスト
ログを仕込んで効果検証
- そもそもの仕様が効果的かどうか検討もつかない時にログを仕込む
- ログだけ入った状態でリリース（機能はまだ変えない）
- 結果に応じて本当に修正を入れるか判断できる
- やみくもにログを仕込まない
- 扱いに困ってしまう
- リリース後のテストだけど検討はもっと前の段階から
実際のオペレーションの観察
- プロダクトがどうあるべきか認識する
- 現場リサーチ
- 教えたりするのではなくそばでただ観察
- 運用でカバーしてるところが見えてくる
- その現場固有の事象も見えてくる
- データだけ見てても気付けないことが分かる
- 全部を解決できるわけではないしする必要もない
- 気づきをアイデアの源泉にして次に活かす
- 使われ方をみることでリリースに意識が向くようになる
ユーザと協力してオペレーションが進行できるか確認
- 新機能を試す場を作る
- 開発者が現場に行って使ってみる
- 遂行できることを確認
- 業務遂行性
- スタッフ研修でユーザに試してみてもらう
- ユーザが本当にできることを確認
- 習得性
- 運用操作性
- 正式リリース
- 機能正確性
- 開発者が現場に行って使ってみる
- 最後のフェーズまではちょっとミスがあっても目を瞑ってもらう
- フィードバックをもらいながら調整できる
- 新機能に対してびっくりしない
徹底解剖!?JALインフォテック様が取り組む予兆検知/早期復旧を可能にするデータ分析/活用戦略とは？
データ連携基盤のオブザーバビリティ
- 旅客/運行/整備/空港/貨物などさまざまな領域のデータがある
- SOA、SOFIA、EPICの3分類
- 500近いシステムと接続
- 3000を超えるサービスとデータ連携
従来の課題
- ユーザ問い合わせなどが多くてやりたいことができない
- 本番アクセスしてログみて、みたいな作業
- ユーザが自由に見られるサービスを作る
- そのシステムのメンテに追われてしまって結局状況は変わらない
- データを管理するサービスを導入すると解決するかもしれない
Dynatraceの導入
- 他社製品と比べてDynatraceを採用
- 構築がはやかった
- 既存のソフトウェアともマッチしていた
- ライセンス費用は高いがお金で解決できるなら
Dynatrace導入後
- 初期の目標
- 自社開発サービスも併用したデータ検索
- システム構成可視化
- Ansibleで自動操作
- ユーザ向けダッシュボード作ったが利用されなかった
- トラブルが起きないと見ない
- 連動の可視化だけでなく何か起きた時の業務影響などもっと先まで求められていた
Dynatrace活用事例1
- 預け入れて荷物の振り分けシステム
- 去年末に障害があった
- ダッシュボードに監視対象が並んでるのですぐに確認できる
- データの流れを誰でも確認できる
- 以前なら担当者がサーバにアクセスしてログを見ていた
Dynatrace活用事例2
- 通常とは異なる流入数の検知
- 長期的にリソース情報を蓄積している
- 異常があると管理者に通知できる
- 自前で検知システムを作っていたが、Dynatrace側の機能でもできるかも?
- フロントエンドでエラーが起きた時にバックエンドのエラーと紐づけて確認できる機能がある
今後
- データをどう活用するか
- ビジネスプロセスの理解
- 予測AIの活用
