やっつけ不定記

好きなときに好きなことをちゃっちゃと書いてます

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

IT 日記

第三回CCoE実践者コミュニティを覗いてきました。
https://ccoekansai.connpass.com/event/313334/
LT参戦した前回から4か月ぶりです。
過去2回開催分は基調講演とLTでしたが、今回は基調講演部分がCCoE先駆者による座談会でした。
同じCCoEでも、業種によって視点が違っているのが非常に興味深かったです。
以下、LTと合わせてメモ。

1. 【座談会】ちょっと先行くCCoE座談会

登壇者の業界

概ね自社サービスとSIerに大別される（所属詳細は上記イベントURL参照）

[お題] CCoEの立ち上げ背景と目的・具体的活動は？
  • 立ち上げ背景
    • 自社サービス
      • CCoE名乗らない系
        • 特に組織名として謳っているわけではなく、標準化の作業をやってる中でいつの間にかそういう仕事になってた
      • CCoE名乗る系
        • 元々は情シス、配信担当、CG担当の各部署が好き勝手にやっていたが、2022年頃に非公式組織としてCCoEが出来上がった。少人数だったので名乗ることから始めた。
        • 2017年設立された攻めのIT組織がルーツ（2～3人）
          • 「社内にシリコンバレーを作りたい」という考えのもと、エンジニアだけでなくビジネス系それぞれ取るようになった
          • SREが変遷してCCoEになっていき、現在は実質3人（情シスと研究開発部門系の人がやっている）
    • SIer
      • クラウドベンダーと戦わなければならず、クラウド技術者数名によるCCoE的な組織ができた。ここ5～6年、CCoE支援の引き合いが多い
  • 活動内容
    • 開発が進んでシステムを横串で見る人が必要になり、非機能要件的なところをまとめていった
    • CCoE内製化支援をやっている。昔は「クラウド使ってみたいんだけど・・・」系の話が多かったが、今は「モダンなシステムを作るにはどうしたらいい？」系の話が多く、CCoEはその中の1コンテンツとして出てくるイメージ。標準化資料を作ることから始めることが多い
[質問] 初期はクラウド弱い人も多いと思うが、初心者にはどう対応をしていったのか？
  • 自社サービス
    • ハードルを下げないといけないという考え方から、月一回で講習会的なものをやっている
    • 拠点都合でオンラインが多く、オフラインでは対応が難しいケースがある
    • クラウド専門業者に相談チャンネルを開いてもらうというやり方はあるが、大抵2年くらいで廃れる（自社内での自走が大事）
  • SIer
    • 全員エンジニアなので、そもそも訊きやすい状態にある
[質問] どういう質問が来るのか？それに対してどんな回答をしたか？
  • Dockerの使い方
  • このクラウドサービス使いたいがどうか？
  • システムトラブルの原因調査
  • 新規事業をやるときにクラウド使いたい
  • プログラム言語何使ったらいい？

※（感想）質問内容がピンキリなので、それなりにオールラウンドなスキルが求められるよなあ・・・

[質問] 質問はどんなルートで来るのか？また、1日何件くらい来るか？
  • 質問ルート
    • Direct Message
    • エンジニアコミュニティへの投稿
    • ふらっと席に来る
    • 質問用にチャンネル設けているわけではない（チャンネルを作ったところで、すぐに過疎る）
  • 件数
    • 分野は多岐にわたるけど、何だかんだで1件/日くらい
[質問] CCoEはどこまでフォローするべきか？
  • 相手がノーエンジニアであれば、その人がローコードでものを作れるところまで。エンジニアであれば、ものづくりができるところまで
  • コストの最適化ができるまで
  • 理想形：社員全員CCoE（重要！）
    • 全員が自走できる状態に持って行くべく、育つ環境を作る
[質問] 活動の中でうまくいってないことは何か？
  • コスト最適化
    • 課金爆死※
  • グローバルでのガバナンス
    • 海外拠点には独自に作ったルールが既にある
  • 専門組織ではないので時間とかけるコストに対するメリットが取れない
    • コストだけで物事を判断するのはやめてほしい（「安いからこっち」という思考は失敗のもと。QCDのバランスを見て考えるべし）
  • 取り組み方がボトムアップに寄りすぎた

※（感想）ちょっと前に「クラウド破産」なんてワードも流行ったよなあ

[質問] 標準化資料のアップデート運用はどうやっているのか？
  • オフィス系で作るのはやめた方がいい
    • [道半ば] 改訂が多いので、GitHubのテキストベースにして、改変したい場合はイシュー投げてもらう形の方がよい
  • 目的を定めてライトに作って、それを積み上げる形がいい。最終的にはベンダードキュメントに行きつくことになるので、そこにつないであげる形を意識している。

2. [LT] AWS Control Towerが怖かったけど使ってみたら少し怖くなくなった話

きっかけはbuilders.flashにあるCCoEとControl Towerの記事（たぶんこれ）

怖いポイント1：コントロール？ランディングゾーン？
  • ランディングゾーン
    • Control Towerで作られる環境の総称
    • 要は「ぼくの考えた最強のマルチアカウント環境」
  • コントロール
    • AWSの統制に対する思想とそれを実現する設定を一つの概念としてまとめたもの
    • 昔はガードレールと呼ばれていた
怖いポイント2：コストの不明点を調べる
  • AWS Configは高額になりがち
    • 空のアカウントでControl Towerを有効化するだけなら大した額にはならないけど、既存環境のアカウントで有効化すると、えらい目に遭うかもしれない

3. [LT] エンジニアゼロの組織から内製開発のDXをどう実現したのか？

Mys3という業務用省エネサービスにおける内製開発の話

  • CCoEが機能するための3つの環境条件 from AWS（この記事）
    • 会社／組織としてクラウド活用の意思を持つ
    • クラウド活用において、組織横断かつ構造上の課題を有する
    • クラウド活用スキルの不足やリソースの偏りがある
  • 業種的にIoT、アジャイルのような疎結合な組織とは相性が悪かった
  • AWS利用開始当初は無知状態だったので、ボトムアップの取り組み（やってみたの実践と共有）を重ねまくった
    • 社内コミュニティは人数をKPIにしてはいけない（人数を考えず、2～3か月に一回開催くらいがちょうどいい）
    • 社外コミュニティは得られる知見の数が全然違う
  • 内製開発の生き残り戦略
    • 上司の説得
      • Working Backwards（おそらくこれのこと）
      • 想定プレスリリース
    • 従来の開発形態（1次受け,2次受け・・・の体制）から内製へ
      • 準委任でデバイスメーカーに来てもらって伴走体制の形で進めた
  • 取り組みの効果と課題
    • 効果
      • PoC成功
      • サービスリリース後、他システムへの適用に波及
    • 課題
      • 組織がスケールしない（人事異動で抜けた, 他業務と掛け持ち）
  • 今後の講演予定（たぶん下記）

4. 告知

  • 次回は9月19日
  • 座談会の時間足らなかったので、再び座談会形式（パネラーおもろそう）

最近の戦利品