y.o

- AWS チーム (7 名) - CCoE (10 名規模) - 所属部署の運営体制 (30 名: チームコアバリュー策定、開発者体験の向上、DevOps 推進など) - 小規模 PJ チーム (4〜6 名)

- AWS チーム (7 名): インフラ構築の標準化 / 自動化、SRE 活動、目標設計 / 評価、リソース管理 (複数 PJ 横断) - CCoE (10 名規模): 全社的な AWS 利活用ルールおよびガイドラインの監修 - 所属部署の運営体制 (30 名): コミュニケーション設計、業務ツール運用ルールの監修 - 小規模 PJ チーム (4〜6 名): プロダクト開発のスムーズな進行、リソース管理

## AWS チーム (7 名) ### 問題や障害 - 私以外の AWS 有識者が社内に不在 - 採用は期待薄であるため、AWS 人材を社内でリスキリングしていく必要があった - AWS チームメンバーが増えるにつれて、実装や品質の統制が取れなくなってきた ### 思考や工夫 - 初期 (一人親方期) は !aC や CI/CD を最速で実装し、プロジェクトやプロダクトが増加してもなるべくデプロイなどの運用コストがかからない状態を実現 - 同時期に並行して、AWS 後任育成を実施 (手動での構築指導 -> レビュー & 学習内容のアウトプット指導 -> IaC 実践 -> コードレビュー -> プロジェクトアサイン & 技術サポートといった流れ) - メンバーが 3 名以上になったところで、AWS チーム方針やメンタリング制度、実装ルールなどの整備を実施 (ルール整備のみ現在進行形) ## CCoE (10 名規模) ### 問題や障害 非エンジニア部門やグループ各社の野良 AWS アカウントが点在し、 画一的な運用 (ガイドラインやルール) に則った組織的な管理が出来ていない ### 思考や工夫 - 当社担当の AWS の方々と協働し、ガイドラインの策定に乗り出し - 同時並行で全社 (他部署およびグループ各社含む) AWS アカウントの利用状況の調査を実施 - 自らが所属する DX 推進部門を先導部隊と位置づけ、AWS における運用ルールを続々策定 (現在進行形) - 他部署やグループ各社の AWS 環境にも踏み込んでいって、AWS Organizations による一元管理に巻き込んでいく (現在進行形) ## 所属部署の運営体制 (30 名) ### 問題や障害 - チームやメンバー間でお客様やプロダクトへの向き合い方、コミュニケーションを重要視する度合いに温度差があり、それによる不毛な衝突が一部で発生 - 業務ツールごとの最適な運用方法が検討されておらず、チームごとに独自運用が乱立していた ### 思考や工夫 - チームコアバリューの策定 (はじめは自部署向けに作成したものの、部長や会長の目に留まり、現在は DX 部隊全体で標榜している) - 業務ツールごとの運用ルールを整備 (タスクフォース的な有志チームを集め、Slack や定期 MTG などを活用し一気にルール整備 -> 一部のチームにトライアルしてもらいブラッシュアップを繰り返す) - Slack コミュニケーションガイドラインを整備し、コミュニケーションの活性化 & コスト圧縮 (チーム内部での牽制や遠慮などをなるべく減らすこと) を試みている ## 小規模 PJ チーム (4〜6 名) ### 問題や障害 - 手戻りが多い - 作るべき成果物が揃っていない - 組織として必要な手続きを網羅できていない ### 思考や工夫 - 4〜6 名から前述の 30 名に増員していく中で、以下の課題が顕在化してきた - (1) 業務フローが明文化されておらず、誰が / いつ / 何を/ どのようにすればいいかが曖昧だった - (2) 開発依頼からリリース、運用保守までの手続きが体系化されておらず、役職者や PM の独断でリリースされていた - (3) 運用保守フェーズではメンテナンスが積極的に行われていなかった - (4) 納品に必要なドキュメントが何か整理されておらず、またテンプレートも存在していなかった - (5) 開発業務に関わる運用ルールが散在し「どこにどんな情報があるのか」「どこにどんな情報をまとめればいいのか」が曖昧になっていた - そのため、開発業務フローの明文化やドキュメントテンプレートの整備、SSOT (Single Source Of Truth) に基づく情報源の集約 (Backlog Wiki や esa) などを行った