CCoE実践者コミュニティ関西 #5

こちらのイベントに参加していました。
https://ccoekansai.connpass.com/event/339731/
裏番組イベントに強力なのが複数ありましたが、本イベントも情報量抜群でした。
以下、メモを書いておきます。Sli.doに上がった質問はこちら。

1. MUFGにおけるAWS標準化の取り組み

• MUFGITのミッション
  • クラウドファースト
  • 基盤強化
• クラウドジャーニー
  • 2017年：AWS活用戦略を打ち出す
  • 2019年：基盤CoE発足
  • 2021年：クラウドネイティブ
  • 2022年：コンテナシフト
• クラウドファーストへのアプローチ
  • Productivity
  • Scrum Team
  • CCoE/Cloud First Approach
    • 比較せずにいきなりAWS
  • Security
• 共通基盤,マルチアカウント化を地道に継続してきた
• AWS標準化
  • StackSets管理にそったアカウントや権限の払い出し
  • ベースライン開発
    • ランディングゾーン
• クラウド活用：標準化推進のためのライフサイクル
  • 1案件に対して下記を行い、それを積み上げる
    • 情報共有→クラウド活用、利用→利用計画→AWS学習・ルール→相談、フィードバック→基盤要件分析
• AWS推進サイクルを作るコツ
  • 「仕組化、カルチャー変革」→「AWS標準化」を行うことで「楽しい」「自己成長」「わくわく」感を知ってもらう
    　【例】社内の問い合わせチケットをRAGに食わせる
• 今後の成長戦略（プラットフォームチームへ）
  • モダンな開発推進
• 参考：海外出張のススメ
  1. 技術トレンド把握
  2. 若手育成/次期リーダー
  3. 挑戦を後押し
     • みんなでre:Invent行くようにしたことで、プレゼンスの向上と育成につながった
       • 2022年：3名
       • 2023年：11名
       • 2024年：13名
• 質疑応答
  • AWS基盤を提供するにあたり、せきゅりて部門が要求するセキュリティベースラインをどのようにクリアしていったのか？
    • AWSのIAMを一つ一つ吟味して、プライベートクラウドユースケースになっているかを確認した
    • 多層防御の実装
  • クラウドならではの運用の難しさはあるか？金融としてのセキュリティの難しさはあるか？
    • オブザーバビリティほか
  • どのくらいの人数規模で基盤開発、運用をされているか？
    • プロパー社員：13人
    • パートナー：非公開
  • 何名くらいがre:Inventに行ったのか？
    • MUFGグローバル全体で50人規模
  • 基盤チームの人数構成を教えてほしい
    • 基盤チームというよりは400システムあり、それを維持運用しているアプリ担当がおり、その人数が9000人規模である
  • 案件審議や変更管理のガバナンスを継続する中で変化はあったか？
    • 権限移譲はある
    • 俊敏性を持つ仕組みになっていっていると思う
  • 金融はデータの精密性が求められるため、レガシーの改善が重視されると聞いたが、クラウド化できないものもあるのでは？
    • 海外の手続き対応とか一部オンプレはある
    • クラウド化できるものは自信を持って進めている
  • 重要なデータが多いので、アジャイルではなくウォーターフォールでしょうか？
    • アジャイルで進められるような形にした。コンテナシフトはアジャイルでやっている。
    • ウォーターフォールもある
  • ゼロからAWSを覚える際にまずやった方がいいことは何か？
    • 楽しみながらやる。社内にサンドボックスがあるとなおよし
  • アジリティを要求されない安定的なアプリもクラウドファーストで移行されるのか？
    • このテのやつは安定系になる
  • COBOLはなくなっていくのか？
    • MUFGにCOBOLワークロードはない。もっと古い言語ならある
  • AWSの資格は何をお持ちか？
    • Solution ArchitectのAssociate,Professional。講師自身も背中を見せるムーブをするようにしており、若手もこれらを取る人が多い。

2. 社員3,000名が参加する社内AWS技術者コミュニティ「TAWS-UG」運営の舞台裏

• AWS認定試験の問題生成チャットボットClineを作った
• 組織の壁を越えた技術者育成：TAWS-UG
  • 2019年設立
  • 社員数の50％強が参加
  • Microsoft Teamsを利用
  • 運営時の工夫
    • 業務に必要なドキュメントはTeamsにしか置かないようにした
      （半強制参加だよなあ、これw）
    • 何かあったら、Teamsにワンメンションで流してる
    • AWS CCoE組織機能
      1. 再販/サポートサービス提供⇔3.エンジニア育成施策推進
      2. 技術者コミュニティ運営機能
      3. AWSへのコンピテンシー取得
      4. プレゼンス維持/向上施策推進
  • AWS CCoEの効用
  • AWSアカウント発行時のガバナンス統制
    • セキュリティプリセット
      • Cfnとか諸々一式
    • AWSマルチアカウントスイート
  • 社内AWS技術者コミュニティ機能
    • 組織をまたいだ課題解決、回答をBedrockで速攻返すなんてこともやってる
    • 障害情報の即時共有（1分以内）
      • 障害メールだと流すのが遅れてしまう
    • 最新ニュース/トレンド情報共有
    • AWSアップデート情報の共有
      • 購読者が減ってきており、生成AIで魅せ方を変えるということをやったりしている
        （統一フォーマットよりも如何に読んでもらうかを重要視）
    • AWS実践力養成マラソン
      • 180種類のトレーニング
      • 他社が公開している研修もバンバン使うよ
    • SharePoint活用
  • 組織が共通して抱える課題を、まとめて解決することを目指す
    • 全体を締めるときは締められるようにしている（放置している課題は全体メンションで「コラッ！」と言っている）
• 成果
  • AWS Ambassadorsに選んでもらえた
  • 社内の認定資格保有数が2000を突破した（AWS 2000 Certified）
  • トップダウンではなくエンジニアの主体性を高める施策としてマイナビ記事になった（これかな）
  • re:Inventに社員25名参加
    • 若手社員に海外を経験してほしい（啓発やマインドチェンジを重視）
    • 大海を知って、井の中から飛び出てもらいたいとの思いで投資
  • 若手社員に必要として教えていること
    • 「表彰されて終わりじゃない。それを周りに還元することが大事」
      1. 挑戦して、成果を挙げよう
      2. その成果で、人のために良い影響を与えよう
      3. 周りの成果を、自分事のように喜ぼう
  • AWS Summitで発表（たぶんここを検索したら出てくる「AWS 技術者コミュニティを内製化してみた！2,000 名が参加する TIS 流社内技術者コミュニティ活用術(パートナーセッション, PAR-11)」がそれ）
• 質疑応答
  • 好きなAWSサービスは何か？
    • Amazon Bedrock
  • 3000名のコミュニティとのことだが、分科会はあるのか？
    • 金融事業の有志がやってるFinTAWS-UGというのがある
  • CCoEを介さずにメンバ同士がナレッジ共有したり、課題解決等をTeamsでやっていた
    • いないことはないが少ない
    • TAWS-UG運営の後継者が欲しい
  • ユーザー企業さんがCCoEを実施し内製化したりベンダーマネージメントをするうえでユーザー企業側にお願いしたいことやこうしてくれればもっと良くなるのにということは？
    • CCoE設立支援の仕事でよく聞くものとしては「技術に明るい人の特命チームがあるといいよね」というのがある。そもそも、そういう人がいないところを相手にお仕事をしている（いわゆる伴走系のサービスのことと思ったらよさそう）
  • Teams使いにくくないですか？
    • いいところと悪いところがある。Microsoft 365との連携に強いので使っている
  • TAWS-UGは社内限定か？
    • 社内限定である。案件情報などセキュリティ面で課題があるため、パートナーさんとかは入っていない
  • 技術獲得に熱意のない人へ展開するにあたっての作戦はあるか？
    • 草の根で広げるしかないと思う。実際にやっていることは結構泥臭い。

3. 日本の組織開発を次の段階へ進める武器！日本初で日本発の新しいロール「リブーター」とは！

• 組織開発における優先度は「安定的な生産性」
  • よくある事例
    • 窓際社員、社内ニート
      • この人たちだけが悪いわけじゃない
      • 怠惰と思われがち（←本人だけじゃなく環境や状況が作り出す）
        • 足手まといではなく、組織の伸びしろなので「取り残されない仕組み」が必要
    • →リブーターというロールができた
  • リブーター
    • 思考の再起動
  • 働き蟻の法則（この辺とかこの辺）
    • 能動的意欲高い：2(通常はここが重視される)
    • 受動的：6迷う
    • なぜかうまくいかない：2（ココに該当する人に思考を再起動してもらうよう、伴走するロールがリブーター）
  • リブーターの考え方
    • 受動的を成長体験に変えることで、パレートの法則（この辺）になることをめざす
      1. 「能動的意欲高い2、成長体験2、受動的6になることで、受動的6の部分が一部が刺激を受ける（「なぜかうまくいかない」メンバーを下に見ていた連中が、「なぜかうまくいかない」メンバーの躍進に焦りを受ける）
      2. 繰り返し
  • 前提条件
    • 徹底的に寄り添って、現在の状態を共に把握する
    • 就労意識の変化や自身が楽しいと思える
  • 再起動するにしても状況によってやり方が変わる
    • メモリパンパン：回ってない
      • 落ち着く：余計なことを考えさせない
      • 探求心や野心を刺激：今自分が本当にやりたいことを考えてもらう
      • 他社への影響確認：やりたいことをやったことでの未来を一緒に考える（何をやってもらうか）
      • キャリアの意識（評価の可能性を放す）
    • CPUパンパン＋余計なプロセスが邪魔：わからないが口癖になる
      • タスクマネージャを開く
        • やらなきゃいけないと思っていることを羅列させる（プライオリティの低いものから書いていく傾向がある。後のものほどやばい）
      • 邪魔なプロセスをキルする
        • 羅列された最後と最後の一個前のタスクを考えなくて済むように除外する
      • 重圧を一度なくす
        • 現在の期待値もリセットする
      • 他人のことを考えない
        • 人を意識させないように、他人との接点を一瞬だけでもなくす
  • リブート実施の事例
    • レガシー案件で一人作業が多い50代エンジニア（3か月）
      • 就業意欲の向上
      • 生産性が2.5倍向上
      • チームを超えた信頼感
    • 評価制度の変更
  • リブートにおける問題
    • 過剰なギャップは毒になる
      • 急激な成長はよくない
      • リブートは継続的に行うべし
  • リブーターを育てるコミュニティができるらしい
• 質疑応答
  • リブートするためには、会社のキャリアモデルとか評価プロセスが透明化されている必要があるのではないか？
    • 回答の詳細はその場でのみ公開なので本記事では割愛
      （とりあえず、徹底してる感がハンパなかった）
  • リブーターに必要なスキルセットは何か？
    • 人に寄り添える力
    • 人の話を最後まで聞ける力
  • リブーターに辿り着く前に実施していたことは何か？
    • 組織開発（ジョブ型組織に変えた）

4. AWSネイティブなセキュリティ基準の判定と自動チェック技術の開発・展開

• 社内セキュリティチェックリスト（全社IT部門作成のExcelファイル）の内容がオンプレミス前提で、しかも有識者でないとわからないものになっていて非常につらいため、AWSに沿った内容への改訂とその自動チェック機能を作った
  • 背景1：クラウド活用の高まり
  • 背景2：ダイキン情報技術大学出身の若手社員が開発現場に出るようになった
    • 若手が対応に苦慮→有識者に相談したりしなかったり→工数増、対応品質にばらつき発生の悪循環
• セキュリティチェックリストリリースまでの道のり
  • 2023年1月にスタートし、リスト改訂,レビュー,自動チェックツール開発を繰り返しながら2024年5月に発行
• 誰でも一定の基準で対応できるリストを実現する2つの柱
  • R&D部門が執筆して全社IT部門に持って行くことで、全社ポータルサイトに公開できた
  • 抽象度を下げて、AWSでの具体的な内容（具体的なAWSサービスの設定方法や設計意図）を記載
• AWS自動チェック
  • AWS標準＋カスタムルール
    • Security Hubでは対応できないところがある
  • CloudFormation Guardを採用
    • IaCテンプレと実リソースのチェックに両対応していた事が決め手
      （【例】HTTPSでの公開を必須とするルールを作成（HTTPはReject））
    • 開発者
      • VSCodeのプラグイン
      • GitHub Actionsによるプルリク連動
      • CloudFormation Hook
    • 管理者
      • 管理者側でのチェック機能を実装（リリース前の最終関門の位置づけかな）
      • Amazon QuickSightで結果のダッシュボードを作成
• 質疑応答
  • リストのメンテはどのようにしているか？
    • re:Inventを区切りに更新している（年一回のペース）
  • 新しいAWSサービスが頻繁に出るが、それをリストへ反映するときに工夫していることはあるか？
    • リスト化するサービスは、社内でよく使われているものに絞っている
      （【例】ALB,EC2など）
  • cfn-guardでアラートになったリソースはSecurity Hubからチェックできるか？
    • 可能だが、一覧性に欠けるのでダッシュボードの方がよい
• 所感
  • CloudFormation Guardは登場直後くらいに少し触って、そのときは機能も安定性もまだまだ感で他のツールを選択したけど、今は機能が充実してて、安定性もめっちゃ上がってる印象。改めて検証してみないと。