DevOpsDaysTokyo2024に参加してきました

・生成系AIから信頼できる回答を得るのはほんとに難しそう
・LLMの回答の違いはlabのHPでも検証してる人もいたなーと思い出した
・LLMでも長い文だと中盤は無視される
・RAGのサービス、ファインチューニングは近々、サービスとしてコモディティ化する
⇒これを使って、価値に変換するスキルがとっても重要になるんだろうなー。
・プロンプト、データ、モデル、API、そしてそれらのオーケストレーション
・RAG Ops
・生成AIのテストを他のモデルで行う
・業務フローに生成AIを組み込んでしまう。いつぞやのRPA以上に判断の自動化をする。ルールベースの業務ではなく、人間よりも品質の高い出力をする
・LLM扱うプロダクト用のWAFがある
・クラウドネイティブと同じようにすべてのエンジニアがAIネイティブになっていく
・データサイエンスとエンジニアリングを統合したシフトライトの話、重要そうな気がする。もうちょっとじっくり考えたい。
⇒仮説検証が大事も、似た話な印象
・コモディティ化はブラックボックス化でもあるから、中身を知るのは大事な気がする

・アジャイルは「顧客中心」のやり方、納得
・イテレーティブに回したいのは、顧客の満足にリーチする一番効率的な方法だから
・ユーザー中心のチームは満足度高くいられる
・しかし、燃え尽き症候群になりやすい・・・
・トランクベース開発が生産性向上に有効
・シフトライトによるオペレーションコストの増加
・SREがとても気になるけど理解できてない

・情報発信に力をいれている（1月RSGT、2月devsumi、3月JaSST、4月Devops Days)
・JTCなので社内規定やフローが重い
・ログを転送すること、この権限管理下から抜けられないこと、のみ強制
・研究機関なのでソースも資産のため、盗難を監視
・統制しつつ、上から求められたら簡単に説明できる仕組みも構築している

・ビジネス、マネジメント、エンジニアの３者間のコラボレーションが重要だが、現場はなぜ分断して「最適化」してしまうのか？
・階層型組織のコミュニケーションラインから、部門横断のコミュニケーションと自己組織化を目指す
・”Shared goals”で複数チームが包含されている図
・bizDevOpsのライフサイクル
・ドメイン知識を押し付けるな、理解と同意形成をファシリテートせよ
・2!=2、2=2!(プログラマと数学者で真偽が変わる）

・devops大仮面（変な人がいた）
・わかっていても変革は難しい
・文化を浸透させたいなら物語を語る。物語というか理想の共通目標みたいな感じ
・完璧主義の文化は失敗が怖いので、失敗から学びを得る文化に
・やる気のパルスを共振させる
・サービス精神がすごかった！！ありがとうございます。

・コード＋ドキュメントで適切にエラーを運用したい⇒ただ、ドキュメントの管理はコストがかかる・・・⇒自動生成
・opsの負荷軽減のために情報の集約、連携が大事
・形骸化しない工夫が必要
・エラーを詳細化することで、誰でもエラーに対応できるようになる

・本番のログを確認できなかったはまぁ大体そうよね。。
・データスチュワードという概念を初めて聞いた
・チームが関連していき、自発的に起こる良い影響があった
・一つでもアウトカムがでたのはすごいと思う
・顧客や顧客に近い人を大事にする雰囲気が良かった

・ソフトウェアを支える技術として、インフラやテストが重要
・AIのテストはめんどくさい（本番の環境じゃないとテストできないなど）
・恣意的でないデータ準備が重要
・AIのテストは理系の技術と文系の考え方が必要
・QAの人だけど、アプリやAIも詳しそうで、業務領域を横断した知見をもつことって大事だなと思った

・SREに関して最初からFBをもらえるよう設計することが重要
・最初にジャーニーを作る！指標を決めて計測できるように実装、モニタリング！
・ロギングで出てきたエラーログの内容を自然言語で教えてと言ったら教えてくれるのは凄い
・groundingが生成AIの嘘を防ぐ

・楽しそうだった。こういう事をいつも考えている事が大事なんだよなぁと思いました。
・身の回りのカイゼンについてAIをしっかり使っていきたい

・MTのリスナー枠いいですね、我々も勝手に聞きに行ったりしてますよね
・タスク細分化のワークショップについてはTDDのリスト工程みたい
・DevOpsについて、スクラムの価値を意識して作業する感じに思えた。
・納得感の醸成は大事

・Devopsの講演では燃え尽きるというキーワードが多く感じた。どこも運用が大変なのかな。
・LeanとDevOpsの科学を読まないといけない気がした
・なぜ4keysか？の理解も大事だとおもった。なぜ4keysがビジネスに良い影響を与えるのか？のwhyを知らないといけないと感じた

・偽陽性を防ぐために、できるだけ有償ツールを使う。OSSは偽陽性が多くなりがちらしい
・プラクティス名とか知らなかった。書いてあることは当たり前のことでも、観点を考えるのに名前を知っておくことは大事だと思った
・顧客報告とか、指揮系統とか、確かに緊急時に疎かにしがちかも。事前にそういった整理も必要
・aki.mさんのセキュリティの続きが聞けてよかった！

・SODA構想（「チーム」を組織に「実装」する）気になる
・見える化できてもたいていの組織では改善するための仮説が立てられない
・イネイブリングチームがルール整備してあげないと、複数チームでの4kkeys測る等難しい
・無風が続くと、「スクラムだから遅い、会議が多すぎる」みたいな意見が出がち
・対応するために、EBMに注目して進めている
・オンプロダクト指標(チームがプロダクトと価値に費やす時間の割合）に注目した
・SPI-Enabling teamが実際、どのくらい組織改善に寄与できているのかとても気になる
・ソフトウェア開発は料理に似ている
・バリューストリームマッピングでボトルネックを特定してムダに対処する話、むしろシステム設計に適用したい

・my TOKYO GASは元々ベンダ発注していたが、内製に切り替えた
・ウォーターフォールまじりのオリジナルアジャイルはあるある・・・
・レガシーシステムの有識者を「仲間」としてきてもらう
・受発注の関係にしないと言うは易しここの本当のところは聞きたい
・プロダクトがどう世の中を変えられるのかを考える（言うは易し）
・ビジネスメンバーが開発メンバーと会話できるようになるために開発の知識を勉強するパッションはなにか？
・ビジネスに溶け込んで当事者意識を持つ、兼務は作らない
・DevOpsをやらないと絶対に内製化は無理
・アツかった、テクニックじゃなくてマインドだった
・パッションがすごかった!熱量、当事者意識、やる意義どれも大きい影響を与えるならかえちゃいけない要素だと改めて思った

・googleの20%ルールを参考にした
・寺子屋の価値観を合意するまでにどれだけの時間を要したのか気になる
・筋トレはスクラムのメタファーにちょうど良いと感じた
・このような取り組みに割く時間がないという声をよく耳にする。しかし、もしあなたがすでに会社の主要な目標を達成しているのであれば、10%や20%のプロジェクトに時間を割くことを許してもらうのはとても簡単なことだ。
・委託先でどうやって作っているのか、ブラックボックスになっているから簡単に内製に戻せない
・ビジネスサイドを巻き込むはなるほどな・・・そうなんだよな・・・

・アジャイルのアップデートは文化かテクニカルかで両方を含むものはないかもしれない
・番外:信頼貯金大切。10年やろう
・どんな学びがあるかわからない=計画外の出会いが大事
・DevOpsは実践者のコミュニティから生まれている
・DevOpsは継続的に顧客に価値を届けられるかを考えてやっていくもの。ツール導入すればいいとか規準満たせたらOKとかそういうことではない
・10 deploys per day
・障害時の対処と対応（対処:障害発生したときに本線に戻す/対応:障害が起きないようにするためにどうするか考える）
・変化が必要とされるけれど、日本は障害を恐れるフォースが強い気がする。
・組織が分かれてると、犯人探しに躍起になる可能性ありますよね。自分たちはやってない！お前らのせいだ！みたいに謎対立発生する
・自分でわかっていない人たちに運用させると、長大な手順書に従うしかなくて、ブラックボックス化するね。インシデントに対処できず、変化を恐れようになる
・計画外の出会いってやつを、社内でできると良いかも（DevOpsっていうキーワードだけ置いて集まるか）
・安定性を重視するか、変化を重視するか
・devopsがコミュニティから生まれたという歴史を知れた

・トランクベース開発を導入する目的が仮説検証のループを素早く回したいというのは良い
・フラグの削除重要
・自分がモノリポとポリリポのメリデメが良く分かってない。理解せねば
・今回はこのレトロだと嫌だなぁと正直に言えるチームはすごい
・WA多いな
・必ずしもみんなで、ではない、1人でさえなければいい
・自社のアジャイルを理解していない人に見せたい。神公演

・Lessで８年間開発、運用をしているのは凄い！
・ミッションクリティカルなので、DSの運用版などでカイゼン。バーチャルな運用チーム
・オブザーバビリティに対するカイゼンがスゴイ

・FindyさんはDevOpsDaysとあってるなー
・RICEスコア（Reach：影響を受けるユーザー数、Impact：ユーザーやビジネスへの影響の大きさ、Confidence：成功確度、Effort：開発に必要な工数）
・アウトカムへの影響を大事にする（フロー効率に着目）
・工数の遷移も見えるようにして不確実性のコーンを見える化する

・スクラムは銀の弾丸ではない
・スクラムで開発者の役割がどこまでかはいつもモヤモヤしてる気がする
・ウジウジの方、自分たちのラボではあんまり気にしてないな
・スクラムガイド勉強会とか自分達も結構やれているなと思った
・「境界を超え、より良いチームを目指すためにそれぞれが持つ個性や特性を認め合う」という部分について、たとえば新人や経験、スキルが皆無の人はどう、何が認められるのか、認められたとしてそれが「良いチーム」になるためにどう作用するのか、とおもった

・Confengine作っている人だった
・開発とデプロイを独立してやるインデプロイとして７つのプラクティスを紹介
・トランクベース開発：単一のブランチで開発。複雑すぎると言われることも有るが、とてもシンプル
・トランクベース開発ネタ多いなぁ。

・テストデータ作成自動化やった話
・howが先行するのは良くないよなぁ
・最後のテストピラミッドとアーキテクチャの話が興味深かった。

・制御盤のモック気になる。作成するスピードに驚いた
・クリーンアーキテクチャを大事にしていると言えるのがいいな
・ハードのソフト化は概念は分かるものの、実際どの程度大変なのかはとても気になる

・自分の部署の仕事ではない、ベンダーに任せるという態度は間違い
・NGな考え方に陥りがち（心機一転更地にして新システム構築）になると、古いシステムも残って結果効果が薄れる
・一から作り直すのは間違い（実態として、もっとお金がかかるかもしれない、危険。元々の目的は会計年度のコストを下げることだし、WF的アプローチをとってしまう。そもそも完全に全て新しいシステムに置き換えるのは不可能で、新旧併存することになる）
・全体の経営ゴールを理解すべし
・担当部門に地道に状況ヒアリングし続ける
・100%使われていない、と確信していなくても、リスクを想定の上で止めてみる（スクリームテスト、止めたら誰が叫ぶか）
・マイグレーションが完了すればコスト削減できる、というWF的アプローチはうまくいかない。やめろ。

・アジャイルに出会って価値にコミットできるようになったと実感⇒よい
・アジャイルの基礎知識１日で理解できるのか？気になった
・「声の大きさで作業がきまる」はある、ある
・面白い！モブ・ペアでしきれないところをこういう風に楽しく共有できるよ良いのかも
・howから浸透させていく？的なのはあるある
・１ヶ月５０人でwhyを深掘りしていった！すげー
・兼務でも、whyが理解できていればうまくいく？のか気になったと思ったらダメだったw
・成果発表会という名前良い！
・良くなると別の問題が出るやってみないとわからないな
・価値の情報(WHY)が抜け落ちてくるは良いと思う
・情報共有会の話について、共有会がしやすいように改善するたびデグレみたいに不満が出てくるのを根気強く、うまく解決していてすごいなと思った

・ルールは一般的な話であり、あなた個人の特殊性を反映しない
・パタンには個人の特殊性が含まれている
・物語、ナラティブに切り替えて、集団で美の共通認識を得る
・形で見える「モノ」文化や伝統といった固有のコンテキストを持つコミュニティにとっての意味である「コト」を連結する
・現場で建物が既にあるかのように「体感」する
・頭の中で言語で考えた理想が、現場の物理的な制約を受けて形を変える
・このずれを見つけて、それへの対処を工夫する。これが創造力だ。

・Not frigileは「Robust、Resilient（回復力）」の2つだけだったが、これにAntifragileが加わった
・改善を続けてプロダクトの価値を上げていく場合は、Antifragileな状態になる（Pain下がり、Gain上がる）
・PhoenixProjectはAnti Frigileを考えるうえでもは読んでおくべき
・Fragileな部分を取り除くにも技術負債を解決するのは重要
・Antifragileの例（ABテスト、マイクロサービス化、ソフウェアを小さくすることでリスクを下げられる）
・MTBFよりMTTRにフォーカスするのがAntifragile
・技術負債だけでなく組織的な負債（コミュニケーションなど）にも目を向けるべき
・組織負債特にトップの部分こそがボトルネックになる
・Antifragileの話で、組織的な負債の解決についてはもっと話が聞きたかった

・マインドセットが悪の組織っぽいw
・ふりかえりでプライベートなことも書けるのはいいと思った
・Design Docは試してみたい
・プロパー・パートナーは越境していきたい
・振り返りの際に誰が書いたかで印象が変わるのを防ぐために同じ色を用いるのはなるほどと思った

・アジャイルマニフェストが短い文章であったために誤解されることも多く今も完全に解けた状態ではない
・組織の中での部署の対立を壊していくのがDevOpsだと思う。開発と運用に限定しない
・DevOpsはツールだけ、人（文化）だけ、ではなく両方が必須
・people and AI working togetherになっていく
・我々が１つの仕事を成し遂げたら、それは既に過去のものになる。常に新しい仕事をしないといけない。
・

＜FunDoneLearn＞
・同じものを見ることで場の共有ができ、感想戦で話もできたので楽しかった
・知り合いと再会！現地ならでは
・浴びるように聞いていると熱にあてられる
・チームは人間の集合でナマモノだから、熱が重要だと学んだ。結局そこ。と言いつつ、ユーザーに寄り添うほど燃え尽きが起こりやすいらしい。そこまで行ってみたい
・若いスピーカーが多かった印象。。。すげー
・どの会社もDevopsやアジャイルを実施し内製化を進め、情報発信する流れになってると感じた。
・RSGTに参加してかなりラボ内の社外カンファレンスに対する意識が変わった気がする。
・イケイケな人や、今時の開発と比較して、自分/チームは今どこなのか？をリアルに体感する機会だなーと！
・業務にAIを活用することが当たり前の世界になってきたなと、肌で感じました
・若手が活躍してきていると感じた
・品質にかける費用比率が30年も変化なしということ
・リアクションしたりキャプチャはったりしたのが楽しかった
・セッション終了後にみんなでセッションに対しての話題でワイワイできた
・誰の話でも個人主義ではなくチーム主義、ヒーローになろうとするやつを抑える、犯人探しをしないなど個々の問題ではなくチームで改善するということに重きを置いていた。ただ連帯責任というニュアンスが一切感じないお話で興味深かった
・デプロイ頻度を高める工夫を聞けて面白かった！サービス運営をしていく中で自分達もやっていきたい！
・運用できてはじめて、価値を届けたい人に届けられるよなと思えた
・価値を届けるための人のかかわり方の話もたくさん聞けて、両輪あって価値を届ける活動なのだと分かった
・いくつになっても何かに熱中できる熱量を持つ人でありたい

＜Moyatto＞
・もっとがやがやしてみたいw。自分たちの心理的安全性もまだまだ？
・ちょこちょこ休憩はあったが、結構疲れた
・さらっと、ビジネスとITが協業してみたいなプレゼンや、CI/CDを構築してとか言われてましたが、そこに大変だったけどこうしたらなんとかなったというのが潜んでると思うので、そこが知りたい
⇒「whyを先行させよ」、という風に解釈しましたw。熱があれば、技術自体はどうとでもなる、的な・・・（というより、技術ではなく、人が原因で解決できない問題がほとんどで、人を解くために熱がいる？）
・結局、devopsには組織内での、価値類級への理解/説明が必要な気がする
・身近な業界（金融・保険）の話をもっと聞きたい（FINSUMで聴けばいいのかもだが）