【前編】10年間チア一筋だった25新卒がシステム研修1か月受けてみた～DevSecOps偏～ / 開発者向けブログ・イベント

はじめに

自己紹介

はじめまして！GMOインターネット25新卒のビジネス職、緒方小夏（おがたこなつ）です。チアリーディングを中高大と10年間続け、中高一貫校では全国2位、大学でも全国6位という生粋の体育会系です。

当然ですが、
・ITの世界は完全に未知の領域
・サーバーって？回線って？
・AIは一切使わずに真面目にレポートを書きます
という状態で、ただ純粋に、GMOイズム※に共感し、カルチャーマッチで入社いたしました。

※GMOイズム：GMOインターネットグループにおける社是・社訓を総称するもの。「夢」「ビジョン」「フィロソフィー」として体系化された『スピリットベンチャー宣言』を中心に、AI活用や目標達成などの項目ごとに、一人一人が意識すべきことが毎日の行動レベルまで落とし込まれています。

このブログでは、そんな体育会新卒の私が1か月間のシステム研修でどんなことを学び、感じたのかを書いていきます。他の技術ブログとは毛色が違うとは思いますが、コーヒーブレイク感覚で楽しく読んでいただけますと幸いです。

研修スケジュール

1週間目：DevSecOps
2週間目：AWS
3週間目：LLM
4週間目：データマイニング
最終週：成果発表/データセンター見学

今回は特に印象深かった、DevSecOpsについて詳しく書かせていただきました！

DevSecOps研修内容

	研修内容	進め方	キーワード
1日目	DevSecOpsの基礎（概念・原則・メリット）	2人ペア（エンジニア＋ビジネス）調査/ディスカッション ▼ 発表質疑応答ディスカッション	開発生産性（バリューアップとランザビジネス） DevOpsライフサイクルトイル排除と開発体験向上（エンジニアDX/AX） 4keyメトリクス
2日目	DevOps （アジリティとツール）		CI/CD クラウドネイティブ自動テスト AI活用 GitOps（IaC）オートスケールオブザーバビリティ、APM SRE
3日目	Sec （セキュリティプラクティス）		シフトレフトセキュリティガードレール型セキュリティ OWASP SOC 脆弱性診断 SAST・DAST・SCA
4日目	現状分析・課題抽出	4人グループ（エンジニア2人＋ビジネス2人）調査/ディスカッション ▼ 発表質疑応答ディスカッション	一般的な企業における・システム課題・エンジニアリング組織課題 GMOインターネットにおける・事業特性分析・システムや組織課題抽出・緊急度・重要度マトリクスに課題をプロット
5日目	課題解決・プランニング	4人グループ（エンジニア2人＋ビジネス2人）調査/ディスカッション ▼ 発表質疑応答ディスカッション	GMOインターネットにおける・課題への解決プラン・ROI試算・優先順位・マイルストーン作成

DevSecOps週の印象的なシーン

毎日のアウトプット/発表

どんどん質問し合っていきましょう。
言いづらいかもしれないですが、今日は批判的な質問を意識しましょう。

指導者EL

エンジニア研修とビジネス研修の違い

5月まで受けていたビジネスサイドの研修では、発表時間やミーティング時間をきっちり厳守または巻くことが最重要で、「1分以内に発表」と言われたらどんなに分厚い内容でも時間内に収める工夫が求められました。

一方、このエンジニア研修では、発表時間や質疑応答の時間に縛りはあまりなく、時間以上に、「議論を深められれば深められるだけ素晴らしい」という印象でした。

どちらが良いというよりも、性質の違いです。
私はビジネス職ではあるものの、チアリーディングで10年間続けてきた「1つのことを深堀りたい欲」はエンジニア側のそれに似通っていたため、いろいろなOJTでの発表を経験しましたが、エンジニア研修での議論ベースの発表が難しくもありつつ、一番楽しかったです。

もちろん、時間厳守で発表するスキルも今後のために磨いていきますが、学びを深める姿勢は学生時代と変わらずに持ち続けたいですね。

エンジニアとの会話・率直な感想

なぜなぜ分析

なぜそのツールや概念がそもそも生まれたのか、表面的な知識ではなく、なぜなぜ分析をしてほしい。

指導者EL

率直な感想：

初日の反省：検索したらすぐ出てくる知識を並べ、深い学びができなかった。
初日の学び：「課題→解決策」の技術的な歴史の進歩/サイクルを体系的に理解することが重要。
学ぶ楽しさup：ストーリー性のある日本史や世界史が好きな私にとって、なぜなぜ分析は難しい技術的な話にストーリー性を色付けする感覚に近く、より学ぶのが楽しくなりました。

アジャイル開発とウォーターフォール開発

アジャイル開発：小さな単位で計画・実装・検証を繰り返しながら柔軟に仕様を進化させる開発手法
ウォーターフォール開発：要件定義から設計・実装・テストへと工程を順序立てて一方向に進める開発手法。

２つの開発手法、実際どんな感じですか？

私

エンジニアの先輩

　ウォーターフォールはトップダウン的で、アジャイルはボトムアップ的かな。
ウォーターフォールは計画通りにいけばスムーズだけど、開発途中に競合が似たサービス出したら終了（は言い過ぎだけど！）。
　アジャイルは変更に柔軟で、スプリントゴール（”1スプリント＝1週間”が多い）はあるものの、全体像が見えずらいから、マネジメントする人の力量で左右される側面があるかも。

エンジニアさんのマンパワー感に親近感を抱きました。やっぱり現場にいる”人”をイメージするとビジネス職の私も理解しやすいです！

私

率直な感想：
どちらの方がいいとは簡単に決められないですが、ケースに合わせて開発手法を選択できるような、汎用的な人財やチーム、組織がベストだと思いました。

開発者体験とセキュリティのせめぎ合い

私

DevEX（開発者体験）という言葉も初めて知りましたが、ＧＭＯのDevEXって実際どうですか？

GMOの開発者体験は年々上がってきていて、今後も向上施策を打っていくよ。

指導者EL

開発者体験とセキュリティ、このせめぎ合いはあるっちゃある。

エンジニアの先輩

参考 DevSecOpsとは？DevOpsとの違いやメリット、ツールの種類を紹介

率直な感想：
SPACEという指標※ や、4keys＋信頼性※ など、さまざまな指標がありますが、目先の数値目標に追われると開発者体験が下がりそうだと想像しました。チームとしての揺るぎない目標を念頭に置いて逆算することで、目先の数値にとらわれすぎず、もっと大きくユニークに、自己効力感をあげながら開発できるのではないかと思いました。

SPACE：開発者体験を測るためのフレームワークで、Satisfaction（満足度）・Performance（成果）・Activity（活動）・Communication/Collaboration（協働）・Efficiency/Flow（効率/集中度）の観点で評価する指標。
4 Keys + 信頼性：DevOpsの成果を測る代表的な指標群で、デプロイ頻度・変更のリードタイム・変更失敗率・サービス復旧時間の4つに、システムの信頼性を加えたもの。

SOCの実態

SOC（Security Operation Center）：組織のシステムやネットワークを監視し、サイバー攻撃や不審な挙動を検知・対応する専門チーム（またはその拠点）

参考世界No.1のホワイトハッカー集団によるサイバー攻撃の防御・分析拠点「セキュリティ・オペレーション・センター（SOC）」を東京・用賀に開設

［SOCの方々］

エンジニアが常駐し活用するSOCはドラマや映画のような大画面ではない。上記参考はお客様への集中的なサイバー攻撃などの緊急時に、エンジニアが一同に会して防御・分析を行う「第二SOC」。
スピードとセキュリティの質の両者のバランスが難しい。
セキュリティはいろんな人と関わるから、聞き方も伝え方も工夫する。”相手をどう動かすか”の視点をもっておく。

［率直な感想］

現場はドラマのような派手さはないが、地道な作業の積み重ねがセキュリティの最前線を守っているのだと知りました。
効果を実感しやすいスピードと、しにくいセキュリティ。スピードは速いほどお客様の笑顔と感動を生み出せる”実感しやすい効果”がある一方で、セキュリティは万が一何かあった時に「やっておいてよかった」という保険のような”実感しにくい効果”の違いがあると感じました。
”コミュニケーション力＝営業”ではない。SOCの方々だけでなく、エンジニアの同期や先輩方もビジネス職の私に分かりやすく技術や実際の現場を教えてくれました。違う立場の相手にも伝わる説明力は社会人として日々磨きたいと思いました。