エンタープライズ第三本部データマネジメントコンサルティング２部の新見優果です。 先日、クロスイノベーション本部の大岡叡さんが主催する「25卒合同AWS勉強会 #2」に参加してきました！本ブログでは、その様子をお届けします。 私はAWSについてほとんど勉強したことがなく、業務でもサーバーの起動停止を担当している程度でした。しかし参加者全員が新卒1年目ということもあり、AWS初学者の私でも安心して参加できました。 開催背景（主催の大岡さんより） イベント概要 イベント内容 当日のタイムスケジュール 参加背景 発表した感想 他の発表を聞いた感想 まとめ 開催背景（主催の大岡さんより） ”#2”とあるように今回は2回目でした。第１回の勉強会については、以下のブログをご覧ください。 第１回の勉強会の後、各社代表（NECソリューションイノベータ株式会社の上田賢哉様、キャップジェミニ株式会社の遊佐康平様）と振り返りを行い、第2回の勉強会は「オンライン参加できるようにする」、「質疑応答の時間を設ける」、「テーブルを班の形にして交流しやすくする」など様々な改善を行いました。 イベント概要 開催日時：2026/3/6(金) 18:45-21:15 開催場所：電通総研 品川本社 19階会議室 開催形態：ハイブリット(対面+オンライン) 参加者：計32名 キャップジェミニ株式会社 (10名) NECソリューションイノベータ株式会社 (5名) 株式会社OptiMax (3名) 弊社 (14名) イベント内容 各社から1、2名が登壇し、AWSに関係するテーマで10分間ずつ発表しました。AWSのサービスや資格勉強、自身が開発したアプリについてなど、発表内容は多岐に渡りました。 質疑応答や交流タイム、懇親会もあり、他社の1年目との交流も活発に行われました。どのような部署に配属されたか、1年目でどのような業務を任されているかなど、なかなか聞く機会がない他社の話を聞くことができました！ 当日のタイムスケジュール 時間 内容 所属 発表者 発表テーマ 18:45-18:50 開会 - - - 18:50-19:05 発表① 電通総研 新見 優果 自社製品 BusinessSPECTRE XC AWS版をセットアップしてみた ーSAPデータをクラウドDWHへ転送するソリューションについて学ぶー 19:05-19:20 発表② キャップジェミニ 渡邉 篤弥 ALBでTLS終端するってどういう意味？〜NLB→ALB構成で分かった通信相手の話〜（Security Hubの警告をきっかけに調査した、TLSの通信相手について） 19:20-19:35 発表③ NECソリューションイノベータ 鈴木 千尋 AWS資格が「仕事で役に立つ」3つのメリット 19:35-19:50 休憩 - - - 19:50-20:05 発表④ OptiMax 高橋 光 Amazon Bedrock Agentsに対する間接プロンプトインジェクションの脅威と防御 20:05-20:20 発表⑤ 電通総研 河岸 歩希 「おごり自販機マッチング機能」をLambda×DynamoDBでつくってみた 20:20-20:35 発表⑥ キャップジェミニ 窪川 壌 エミュレータで始めるAWS節約生活（LocalStackの簡単な使い方と3月のアップデートについて） 20:35-20:50 発表⑦ NECソリューションイノベータ 上田 賢哉 SOA受験を実践で振り返る 20:50-20:55 閉会 - - - 20:55-21:10 歓談タイム - - - 参加背景 私が所属している部署ではクラウドに関連する案件が増えており、私もいつか勉強しないといけないなと思っていました。そうした時、Teamsで同期が「1年目だけの4社合同AWS勉強会」を開催すると知りました。「1人で資格勉強を始めようとすると腰が重いけど、勉強会で同期の発表を聞くだけなら！刺激をもらえるかも！」と思い、参加することに決めました。 発表した感想 こうして聴講者として参加する予定でしたが、発表3週間前に「登壇してみないか」と誘っていただき、急遽発表者として参加することになりました！これまで全く勉強してこなかったのに、一体何を発表できるんだろうと思いながら、せっかくの機会だと思い引き受けました。 そこで先輩に相談したところ、部署の自社製品である「BusinessSPECTRE XCのAWS版をセットアップしてみるのはどうか」と提案していただきました。それから製品のシステム構成を学習し、環境構築に取り組みました。 セットアップではプロキシのエラーなどに悩まされましたが、先輩方や同期に助けてもらいながら何とか終えることが出来ました。当日の発表では、AWSのGlueやCDKデプロイなど、セットアップをした中での学びを発表しました。 発表後は、実際に業務でGlueを使っている人や、これからCDKデプロイをしようとしている人から声をかけてもらい、有意義な情報共有の場になりました。1人で資格勉強に励むだけでは得られない経験をすることができ、改めて参加して良かったなと思いました。 他の発表を聞いた感想 他にも6名の方が発表しましたが、セキュリティやAIに関連するテーマから、アプリ開発や資格受験の経験談まで幅広いジャンルの発表があり勉強になりました。1年目だけの開催ということもあり、前提知識がなくても理解できる内容が多く、率直な質問もしやすい雰囲気でした。また何より、同じ1年目が勉強している内容を聞き刺激をもらうことが出来ました。1人で勉強を進めることが苦手な私でしたが、このイベントを通じて励まされました！ まとめ 当初はノリで参加を決めていたイベントでしたが、なぜか発表まですることになり大変でした！しかし、こうした機会がなかったら1人でAWSを触ろうとはしなかったと思うので、勉強する良いきっかけになりました。主催してくれた大岡さんをはじめ、参加してくださった皆さんには感謝です。 懇親会では学生時代の友達で集まったように盛り上がり、また次回以降も参加したいなと思いました！また多くの方に参加していただき、盛り上げていけたらいいなと思いますので、是非AWS初学者の方も安心してご参加いただけたらと思います！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @niimi.yuuka 、 @ooka.toru レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

SREの藤原です。 MNTSQではセールス、コンサルティング、テクニカルサポートのメンバーなどが顧客からの問い合わせに回答する際に参照するセキュリティホワイトペーパーが存在しています。 このセキュリティホワイトペーパーを、これまではGoogle Docsにて管理していました。 これをマークダウン + GitHubリポジトリでの管理に移行したので、その事例エントリです。 Google Docsで管理する際に発生していた問題 Google Docs自体は共同編集ツールとしては非常に優れています。 一方で、社内で公式に参照する文書という観点では課題を抱えていました。 主な課題としては以下の2点です。 変更管理の難しさ 複数人で異なる変更を行う場合にそれぞれを個別に変更として取り込むことがGoogle Docsでは困難でした 最新版か否かの分かりづらさ Google Docs自体にも版管理機能はありますが、リリース版のファイルを個別で管理する必要があるなど少々面倒な側面があります。 特定のファイルが公式としての変更が加えられたものなのか、それとも変更は加えられているが、それがまだレビュー中なのか？といった判断が難しい（変更の提案機能などをつかうこともできるが、必ずしもそれを全員が使うわけでもありません） 解決策としてのGitHub管理 解決策は非常にシンプルでGoogle Docsではなく、GitHubでマークダウンとして管理するという方式にしました。 元のドキュメント自体もGoogle Docsでなければ困るような高度な機能を利用しているわけでもなかったため、マークダウンで実現可能な表現力で十分であるという判断のもと、マークダウン+GitHubに移行しました。 GitHubのリポジトリにて章ごとにホワイトペーパーが管理されている様子 章ごとにマークダウンファイルを分割することで、変更のコンフリクトが起こりづらいようにしています。 以降では、GitHubに移行することによるメリットについて述べていきます。 メリット1: 変更管理がPRベースになった GitHubに移行したことで、文書の変更がプルリクエスト（PR）ベースで管理されるようになりました。結果として以下を容易に実現できるようになりました。 どの章を、誰が、なぜ変更したか、がコミットメッセージとPR説明に残ります レビュアーは差分（diff）を見て内容を確認できます マージ前に承認フローを設定することで、「誰でも勝手に書き換えられる」リスクを排除できます これはコードのレビューとまったく同じフローだ。エンジニアにとっては馴染み深いプロセスなので、文書の品質管理がやりやすくなりました。 メリット2：Claude Codeで文書修正が容易になった 章ごとにマークダウンで分かれているため、Claude Codeを使った文書修正が非常にやりやすくなりました。 たとえば、まずは、キーワードのみをClaude Codeに与えて文章を出力した後に、文書内容を確認して、問題ないかといったことができるようになりました。またその修正結果はそのままGitのdiffとして確認でき、PRを作ってレビューするだけで取り込むこともできますし、他の人からのレビューもしやすくなります。 人が文章を記述するよりもClaude Codeの方が書き上げるまでにかかる時間は短く、文章の質ともより高いものになります。キーワードとおおよその文脈情報さえ与えれば、ほとんどの場合において、内容を確認して一部だけ修正することで改善できます。 メリット3: GitHub Actionsを使ったPDF出力と、リリース管理 「公式文書としての最新版管理」を実現するため、GitHub Actionsのワークフローを組みました。 仕組みは次の通りです。 任意のタイミングでリリース版作成のGitHub Actionsワークフローをトリガーします ワークフロー内でタグをきり、プレリリースを作成します マークダウンファイルを結合してpdfファイルを作成します 3で作成したpdfファイルを2で作成したプレリリースに成果物として付与します GitHub Actionsワークフローでpdf出力しているイメージ ここで、プレリリースまでとしているのはpdfファイルの体裁などが崩れていないか？を確認したのちに、リリースに昇格することを意図しています。 GitHubリポジトリに作成されたリリースの例、アーティファクトとしてのpdfも確認できる GitHubリポジトリのリリースを見れば、最新版のドキュメントにたどり着けるようになります。 移行時の注意点 ただし、マークダウンに移行する際の注意点としては、以下の2点が挙げられます。 日本語フォント GitHub Actionsでは日本語フォントを明示的にインストールする必要があります。 fonts-noto-cjkなどをインストールして利用しましょう。 pdfへの変換ツールの選定 本事例では md-to-pdf を利用しています。今回要求されている事例ではこれで要件を満たせていたため、問題はなかったのですが、高度な組版などが要求される場合はそれにフィットしたツール( Pandoc や Vivliostyle.js 、 Re:VIEW など)が必要になるかもしれません。 github.com pandoc.org vivliostyle.org reviewml.org まとめ ここまでGoogle Docsで管理されていたドキュメントをGitHub + マークダウン管理に移行した事例について述べました。これによって、ドキュメントの変更管理と最新版配布などが容易にできるようになりました。特に定期的な更新が発生しつつ、SSoTとして正確性が重要になる文書にはフィットするとおもいます。 本事例が文書管理に悩んでいる組織の参考となれば幸いです。

こんにちは。タイミーでAndroid Chapter Leadをしているmurataです。 普段はAndroidコミュニティの運営やTech Lead的な動きをすることが多いのですが、今回はいつもの技術領域とは少し異なる視点を得たくて、今回のEngineering Management Conference Japan 2026（以下、EM Conf）に参加しました。 EM系のカンファレンスは初参加でしたが、新たな世界を見ることができた1日でした。 📝 注記 各セッションの「聞いたこと」は、私なりに理解し印象に残ったポイントの 抜粋 です。実際の講演内容と齟齬がある可能性があるためご了承ください。 印象に残ったセッション 冒険する組織のつくりかた 安斎 勇樹（Yuki Anzai）さんによる基調講演です。 「これまでのマネジメントは軍事的世界観で語られがちだったが、これからは“冒険的世界観”で組織づくりをする」という話が軸でした。 EM業に不慣れな自分でも理解しやすく、すぐに実践できそうな内容が多いセッションでした。朝イチから目が覚めるような学びがありました。 セッションで聞いたこと（抜粋） 危機感を煽るマネジメントは、いまの環境だと人が離れるだけになりやすい “冒険的”な組織は、外向きで、感情を重視する 「今すぐ改善できる、半径5mのもの」 目標のマネジメント 目標が機能しない背景に「納得がない」「内発的動機がない」「みんなでやる意味がない」がある 軍事的マネジメントは目標に対する視野狭窄をつくることだった SMARTだけでなく、ALIVEのような「取り組む側が前向きな意味を感じられる指標」も両立させる 会議のマネジメント 「何かいいアイデアないですか？」「FBないですか？」という問いは、発言を引き出しにくい 「この企画案、どこか1つ変えるとしたら？」「もしお客さんなら何点をつけますか？」のように具体で答えやすい問いにすると発言がすぐ飛び出す 興味のマネジメント 以前は「3年後のwill」を起点に目標を逆算しがちだったが、いまはwillが出てこないことも多い 「興味があるもの」「面白いと思っているもの」を聞いてキャリア支援する方が今に向いている 学び・感想 目標設定は感覚で“SMARTっぽく”やっていましたが、ALIVE *1 の観点は初耳だったので次から意識してやってみます 会議で「何かありますか？」を幾度となくやってしまっていたので、問いの設計を今日から変えます タイミーで取り入れているファイブフィンガー（手の本数で賛成度・懸念度を示すシンプルな意思表示の方法）は、この「問いかけを工夫して発言を引き出す」方向性と相性が良さそうだと感じました 「ストレッチゾーンに挑戦し続ける」ことって難しくないですか？ メンバーの持続的成長を支えるEMの環境設計 （ぎーにょさん） 「自分の目標ですらストレッチし続けるのは大変なのに、EMはメンバーにどのようにストレッチさせているのか？」という関心から、このセッションに飛び込みました。辛いですよね、目標設定。 セッションで聞いたこと（抜粋） 「ストレッチゾーンが無い」状態には、いくつかのパターンがある 今の自分に最適なチャレンジが分からない → 現状を分析する 途中で自然消滅しそう → 目標を立てる 外部要因で止まりそう → 実行を支援する EMが全部を背負うとボトルネックになるため、スケールに備えた“持続可能な仕組み”が重要 心理的ハードルを下げて変化を起こす施策として、ADRを用いて、コードベース全体に影響する提案と承認のプロセスをルール化する例が紹介されていた 学び・感想 ADRの話は、以前導入した タイミーAndroidChapter式LADR と狙いが近く、方向性は間違っていなさそうだと勇気づけられました 一方で、紹介されていた取り組みは“施策の寄せ集め”ではなく、「なぜストレッチが難しいのか」を構造として捉え、分析したうえで仮説→検証で進めている点が強かったです 自分は点でhowを増やしがちなので、システム的に捉える筋力を身につけたいです 余談ですが、スライドの写真と登壇者の雰囲気に違いがあり印象に残りました（どちらも素敵でした！） 守る「だけ」の優しいEMを抜けて、事業とチームを両方見る視点を身につけた話（Mitsuiさん） 「チームを守る盾」と「成果を出す槍」を状況に応じて使い分ける、実体験に根ざした話で、リアリティが強かったです。 セッションで聞いたこと（抜粋） 立て直しの局面では、まずチームを外圧から守りきることが重要 ただし、それだけを絶対視すると、求められる事業の成果とズレる局面が出てくる EMは、事業とチームの両方を見て判断するための軸と、実行の引き出しが求められる 学び・感想 mitsuiさんが「理想のEM像」として信じていた以下のポイントは、たしかに大事（で、私の理想ともほぼ一致しています）。 サーバントリーダーシップ ピープルマネジメントの徹底 ボトムアップの組織 ただし“常にそれが正”ではなく、最終的には事業貢献・企業価値への影響を最大化するのが目的。 その目的に照らして、状況で使い分ける意思とスキルが必要なのだ、と腹落ちしました 「開発生産性」ではなく「事業生産性」こそが本質（江副 廉人さん） セッションで聞いたこと（抜粋） EMとして「事業生産性」を意識し、投下資本に対する利益率（ROIC）の観点から“稼ぐ力”を最大化していくことが重要 企業価値の算出方法としてDCF法 *2 がある 学び・感想 自分の中で「ROICを意識する重要性」を理解できました ただ、現実の会話に落とす難しさも同時に強く感じました 各変数をそもそも数値化するためのスキルが必要 EMになると、こういった数字が“即答できて当たり前”なのか それとも、会社として“取りに行けば取れる”状態にしておくのが前提なのか 後者の観点で、全社としてROICや関連指標がパッと出るようにイネイブリングされると、指標としての活用が進み、事業生産性への意識も広まりやすいのではないかと無邪気に感じました ブースで印象に残ったこと（DRESS CODE様） DRESS CODE様のブースでは、写真のように「EMの取り組みとして無くなっていくもの」と「今後期待されるもの」について、たくさんの付箋が貼られていました。 一見「え、そうなの？」と思うものもあり、興味深かったです。特に目に留まったのは、「無くなっていくもの」にあった以下の2点です。 「睡眠時間！！」 エンジニアのAI活用によりアウトプットが増え、結果として仕事量が増えるため、という文脈 「定量的な評価」 今後はAIがデータを収集し、定量評価を代替していくため、という文脈 不要になるのかと思いきや、役割がスライドしたということですね さいごに 普段参加する技術系カンファレンスとは見える景色が全く違い、とても面白かったです。 特に印象に残ったのは、テクニックの話に入る前に「そもそも何を大事にするのか」がどのセッションでもきちんと語られていたことでした。 学んだら実践ということで、まずは半径5mの範囲で、問いの立て方や目標の置き方を変えるところから始めます。 「知った」で終わらせず、仕事の中で試して定着させ、“増殖”させていきます！ *1 : 目標の精度を高めるSMARTに対し、実行者の『感情・価値観・継続性』に焦点を当てた目標設定フレームワーク。 参照： 組織を活性化する目標設定：SMARTからALIVEへ ビズユーコンサルティング *2 : 将来期待されるキャッシュフローを、リスクを考慮した割引率で現在の価値に換算して企業価値を算出する手法。 参照： 【完全版】DCF法の計算手順や欠点を基礎からわかりやすく図解 株式会社STRコンサルティング