こんにちは、新卒3年目でビジネスイノベーション統括本部ITD1-3の堀川です。 愛用しているキーボードは GoForty v2のOrtho配列 です。 今回、私が普段の業務で使用しているTypeScriptをテーマにした大型カンファレンス『TSKaigi 2026』の参加レポートを書かせていただきました！ 去年の参加レポート記事に引き続き、カンファレンスの様子や感想、魅力などを発信していきます TSKaigi2025で分かったTypeScriptの流行 ↑今年の愉快なTSKaigi参加メンバーたち カンファレンス概要 情報区分 カンファレンス詳細 イベント名 TSKaigi 2026 開催日 2026/05/22、2026/05/23 開催場所 ベルサール羽田 京急空港線羽田空港第3ターミナル駅から徒歩5分 ミッション 学び、繋がり、"型"を破ろう セッション感想 ここでは私が参加したセッションの中で、特に面白かったものを自分なりの理解を交えて紹介します セッション感想① 実践TanStack Start: 新規プロダクトを開発して確立した、サーバーとクライアント境界の設計パターン セッション概要 https://2026.tskaigi.org/talks/26 スピーカー Shimmy スライド資料 https://speakerdeck.com/kaminashi/practical-tanstack-start-server-client-boundary-patterns?slide=3 Next.js と同じ React 向けフルスタックフレームワークである  TanStack Start  に関するセッションです。まだ v1.0 未満でコミュニティや事例が少ない中、 実際に採用した新規プロダクトの設計知見 を聞ける貴重な内容でした。 loader と Server Functions の責務設計 TanStack Start を使う上で核心となるのが、この2つの責務をどう分けるかという問題です。 役割 loader ページ描画「前」に走る処理を書く場所 Server Functions クライアントから呼び出せるサーバー側の処理 Next.js ではこの2つの挙動がフレームワーク側であらかじめ決まっています。一方 TanStack Start は、どちらに何を書くかを 開発者自身が決める 設計です。 この違いは開発体験にも現れます。Next.js はキャッシュ挙動がフレームワーク内部で自動的に決まるため、「なぜデータが古いまま表示されるのか」を調べるために内部実装を読み込むことも少なくありません。TanStack Start はすべての挙動を自分たちのコードに明示する設計のため、 動作への理解を保ったまま開発できる というメリットがあります。 設計パターン：loader 編 loader 内の取得は最小限に留め、各コンポーネントが必要なデータを自分で取得する というアプローチです。 // loader では認証情報から tenantId だけを取り出すexport const Route = createFileRoute("/_authed/orders")({ loader: ({ context: { session } }) => ({ tenantId: session.tenantId }), component: OrdersPage,});// 各コンポーネントが useQuery で必要なデータを取得するfunction OrdersPage() { const { tenantId } = Route.useLoaderData(); const { data } = useSuspenseQuery(ordersQueryOptions(tenantId)); return ( <> <NotificationBadge /> {/* 子の中で useQuery */} <OrdersTable orders={data} /> <Recommendations /> {/* 子の中で useQuery */} </> );} // loader では認証情報から tenantId だけを取り出す export const Route = createFileRoute ( " /_authed/orders " )( { loader : ({ context : { session } }) => ( { tenantId : session . tenantId } ) , component : OrdersPage , } ) ; // 各コンポーネントが useQuery で必要なデータを取得する function OrdersPage () { const { tenantId } = Route . useLoaderData () ; const { data } = useSuspenseQuery ( ordersQueryOptions ( tenantId )) ; return ( <> < NotificationBadge /> { /* 子の中で useQuery */ } < OrdersTable orders ={ data } /> < Recommendations /> { /* 子の中で useQuery */ } </> ) ; } 設計パターン：Server Functions 編 ① 横断関心事は Middleware へ切り出す ログ出力や認証チェックなど、複数の Server Functions に共通する処理は handler に直接書かず、Middleware として分離します。 export const loggerMiddleware = createMiddleware({ type: "function" }).server( async ({ next, functionId }) => { const requestId = crypto.randomUUID(); logger.info({ requestId, functionId }, "handler:start"); return next({ context: { requestId } }); },); export const loggerMiddleware = createMiddleware ( { type : " function " } ) . server ( async ({ next , functionId }) => { const requestId = crypto . randomUUID () ; logger . info ( { requestId , functionId }, " handler:start " ) ; return next ( { context : { requestId } } ) ; }, ) ; ② handler にはロジックや I/O の詳細を直接書かない handler は「受け取って委譲する」だけにとどめ、実装の詳細は別の関数に任せます。 export const saveOrder = createServerFn({ method: "POST" }) .middleware([loggerMiddleware]) // 横断関心事 .inputValidator(saveOrderInputSchema) // 入力の検証 .handler(async ({ data }) => upsertOrder(data), // ロジックは別関数へ委譲 export const saveOrder = createServerFn ( { method : " POST " } ) . middleware ([loggerMiddleware]) // 横断関心事 . inputValidator (saveOrderInputSchema) // 入力の検証 . handler ( async ({ data }) => upsertOrder (data) , // ロジックは別関数へ委譲 この設計により責務が自然と分離され、人間にも AI にも読みやすいコードベースが実現できます。 まとめ もし TanStack Start を新規プロダクトへ導入するとしたら、Next.js との最大の違いは「フレームワークに動作を任せるか、自分たちで明示するか」という設計思想の差です。 使い分けの目安としては、SEOや高速な初期表示が求められるサービス、またはチームに Next.js の知見が豊富な場合は Next.js が無難です。一方、複雑なサーバー／クライアント間のデータフローを自分たちで制御したい場合や、コードベースの挙動を隅々まで把握したい場合は TanStack Start が向いているといえます。 Next.js に慣れ親しんでいるほど、最初は自由度の高さに戸惑うかもしれません。しかし今回紹介した設計パターンを最初から取り入れることで、コードベースの見通しを保ったまま開発をスタートできます。 「なぜこの挙動になるのか」を把握したまま開発したい新規プロダクトにおいて、TanStack Start は有力な選択肢になりそうです。 セッション感想②　AI時代に考える、Branded Types で実現する堅牢な型付け セッション概要 https://2026.tskaigi.org/talks/62 スピーカー 池奥裕太 / @yuta-ike スライド資料 https://www.docswell.com/s/4136989/Z6NJ78-tskaigi2026#p1 TypeScript の中でもさらに厳格な型定義を行う Branded Types について、その意義と具体的な魅力をわかりやすく解説したセッションでした。 型チェックの意義 まず前提として、型チェックには4つのパターンがあります。 実装 型チェック 評価 正しい 通る 嬉しい 間違っている 通らない 正常 正しい 通らない よくある・辛い 間違っている 通る 一番避けたい 「実装が間違っているのに型チェックが通る」とは、たとえば次のようなケースです。 <em>// 足し算関数 (number + number → number)</em>function add(a: number, b: number): number { return 0; // 常に 0 を返す} < em > // 足し算関数 (number + number → number)</em> function add ( a : number , b : number ): number { return 0 ; // 常に 0 を返す } 足し算を期待しているのに常に  0  が返ってくる実装ですが、戻り値の型は  number  として正しいため、型チェックでは検知できません。 これは極端な例ですが、AI に実装を依頼した際に「パッと見は問題なさそうだが、よく読むと意図した処理になっていない」という経験をした方もいるのではないでしょうか。こうした問題に対処するために、より厳格な型定義が求められます。そこで有効なのが Branded Types です。 Branded Types とは 同じ構造を持ちながら意味合いの異なる型（例： User  と  Book ）を区別するために、架空のプロパティ  __type  を付与して型を識別する手法です。 User  型を期待する引数に  Book  型を渡そうとすると、型チェックでエラーになります。 function createUser(user: User) { ... }const book: Book = { id: getUUID(), name: "吾輩はエンジニアである", date: new Date(2000, 0, 1),} as Book;createUser(book); // TypeError: Book 型を User 型に代入できない function createUser ( user : User ) { ... } const book : Book = { id : getUUID () , name : " 吾輩はエンジニアである " , date : new Date ( 2000 , 0 , 1 ) , } as Book ; createUser (book) ; // TypeError: Book 型を User 型に代入できない プロダクト開発における Branded Types の使いどころ セッションでは、Branded Types を効果的に活用するための方針として2つが紹介されていました。 ① ドメインモデルを区別する 変数名で区別できれば理想的ですが、AI が  FailedUploadingFileId  のような丁寧な命名を常にしてくれるとは限りません。せいぜい  FailedFileId  程度になることも多いでしょう。Branded Types と型チェックを組み合わせることで、その区別をコードレベルで担保できます。 ② 値の状態や属性を表現する たとえばバックエンドへ送る  string  型の値に対して、「型チェック済み」「ドメインチェック（記号を含まないなど）済み」という条件を本当に満たしているかどうかは、通常の型定義だけでは保証できません。Branded Types を使うことで、こうした「チェック済みの状態」を型として表現できます。 Branded Types によって型安全なコードを書くことで、コードの前後を読まなければ判断できなかった要素を、型定義を見るだけで把握できるようになります。 まとめ AI コーディングが普及した今、コードを書く速さよりも「AI が生成したコードを正しく検証できるか」が重要になっています。Branded Types が注目されている背景には、まさにこの変化があると考えています。 型定義を厳格にしておくことで、AI が生成したコードが意図通りかどうかを、コードを細かく読まなくても型チェックの段階で検知できるようになります。「関数の引数・戻り値の型を厳格に定義する」「副作用を持たせない」といった方針がレビューコスト削減につながる事例として挙がっている中で、Branded Types はこうした流れと特に相性の良いアプローチです。 「AI に実装を任せる機会が増えた」と感じている方ほど、導入を検討する価値があるといえるでしょう。 企業ブース 今年も1日目にかなりの数を回らせていただきました！ 去年とは違い、スタンプラリーは企業名別に区切られておらず、どのブースに行っているかの進捗を忘れてしまうことがしばしばありました... (今年はラムネがとても多かったです。嬉しい) セッション感想に力を入れ過ぎて、文字数がかなり多くなってしまったので、今回は1社さんだけの紹介になります... テイラー株式会社 テイラー株式会社は、TSKaigiに参加されている企業の中で特に印象に残った会社です。TypeScriptの特徴的な事業活用事例を持つ会社で、その内容がとても興味深かったのでご紹介します。 具体的には、エンタープライズ向けの大規模なERPを10倍の速さで構築できる、世界初のヘッドレスERPプラットフォームを事業として提供しています。 会社ページ ERP（Enterprise Resource Planning）とは、企業の基幹業務（会計・在庫・人事・販売など）を一元管理するシステムのことで、MicrosoftやFreeeなどのサービスが有名です。 しかも、このプラットフォームは会社独自のReactアプリケーションフレームワークで開発されており、その保守運用はもちろん、専門エンジニアとして開発サポートも担っているとのことでした。 独自フレームワーク（app-shell）のリポジトリ 会社の事業として独自のフレームワークを開発するだけでなく、その開発サポート、つまりテックリード的なことも担っているというのは、エンジニアとして琴線に触れるものがありました。 TSKaigiに参加して 去年よりもAIの活用をからめたセッションもありましたが、それ以上に型定義を厳格にするBranded Typesや最近出てきたTanstack Startに関する内容が複数あったのが驚きでした。 特にBranded Typesに関してはAIに実装を任せることが多くなったからこそ、型チェックを通した品質の担保に注目されているのかな、と感じています。 去年に引き続き、セッションや企業ブースでTypeScriptやフロントエンドの流行を学ぶことができ、とても貴重な経験になりました！ 業務はもちろんプライベートでの開発モチベにも繋がったので、これからも開発に励んでいきたい所存です。 おまけ 去年に引き続き、サプライ品がとても良かったので、社員証に付けさせていただいてます！ 今年は先端がカラビナ(?)になっており、付けやすくなっていました。ありがとうございます。 また、1日目のオープニングが終わった直後、見覚えのあるキーボードを見かけてお声かけした際、Xで一方的に存じ上げてた某モテるWeztermの人とお話しすることができました！ モテるターミナルにカスタマイズしよう（WezTerm） 特徴的なキーボードは名刺になります() ←Weztermの方のキーボード　　私のキーボード→

はじめに ITD1部開発3課のO.Aです！ 先日2日間にわたって開催された、TSKaigi2026に会社のメンバーと参加してきました。 TSKaigiとは 日本最大級 のTypeScriptをテーマとした技術カンファレンス。 TypeScriptに関する幅広いテーマを取り上げ、特定のライブラリやフレームワーク、フロントエンドやバックエンドなどの領域に限定せず、様々な分野のTypeScriptエンジニアの学びや活用事例を知ることができます。 今年で 3年目 になります。 ミッション 学び、繋がり、”型”を破ろう 公式サイト： https://2026.tskaigi.org/ イベント概要 日時 2026 5/22（Fri） - 5/23（Sat） 場所 ベルサール羽田空港 スケジュール 公式スケジュールは こちら 参加したセッション Day セッション名 登壇者 概要 1 tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか maguro DenoがTypeScript基盤をtscからtsgoへ移行する過程と技術的変化について 1 業務に残された「よくない型」で考える「TypeScriptの難しさ」 Saji 実務で遭遇する不適切な型定義を題材に、TypeScriptの型設計の難しさと改善を考察 1 権限チェックの一貫性を型で守る TypeScript による多層防御 北川 直昭 型システムを活用して権限チェックの一貫性を保証し、多層防御を実現する設計パターン 1 型の深宇宙へ飛び込め ─ tscを遅くする記述パターンの全解剖 ─ dowod TypeScriptコンパイラを遅くする型記述パターンを網羅的に分析 1 決定論的な型チェックへ：Go 製コンパイラによる10倍速の裏側で --stableTypeOrdering から見える並列化への挑戦 えーたろー tsgoの並列化における型チェックの決定論性の課題と--stableTypeOrderingの意味 1 アンチパターンを避ける型駆動React最適化 Kazuya Serizawa 型情報を活用してReactのパフォーマンスアンチパターンを回避する手法 1 Stage 3 Decorators でできること / できないこと susisu TC39 Stage 3 Decoratorsの仕様で実現可能なこと・制約・実用パターンの整理 1 密結合なバックエンドから TypeScript のコードを生成する kemuridama バックエンドと密結合した環境からTypeScriptの型定義やクライアントコードを自動生成する手法 1 TypeSpecで繋ぐ複数プロダクトの型安全 — スキーマ共有による「型契約」の実践 mitsui TypeSpecを用いて複数プロダクト間でスキーマを共有し、型安全なAPI契約を実現する事例 1 TypeScriptの型はAIに届いているか？ ― AIコーディングツール検証で見えた届き方の差 shotaro AIコーディングツールがTypeScriptの型情報をどの程度活用できているかの検証 1 Zod v4 Codec でスキーマに型変換を埋め込む REST API 設計 Ryutaro Yako Zod v4のCodec機能を使い、バリデーションと型変換をスキーマに統合するAPI設計 1 TS 7: How We Got There Jake Bailey TypeScript 7（tsgo）に至るまでの開発経緯。TypeScriptチームによるGo移植の技術的決断と道のり 2 制約と時代から読み解くTypeScriptコンパイラ設計史 Yoshiaki Togami TypeScriptコンパイラの設計がどのような制約・時代背景のもとで進化してきたかを読み解く 2 React の props は値の集合ではない — UI の状態を宣言するコンポーネント設計 nabeliwo propsを単なる値の集合ではなくUIの状態宣言として捉え直すコンポーネント設計論 2 型プラグインシステムの実装に使われるテクニック elecdeer TypeScriptの型システムを活用したプラグインアーキテクチャの実装テクニック 2 Auth.jsからBetter Authへの移行に見る「型とランタイム」の設計思想の変化 宇根昇汰 Auth.jsからBetter Authへの移行を通じて見える、型安全性とランタイム設計思想の違い 2 AI活用の格差をなくす：チーム全体のAI開発生産性を底上げする方法 中津川篤司 チーム内のAI活用スキル格差を解消し、全体の開発生産性を向上させるアプローチ 2 AI Agent に"攻略本"を渡したら、150フォームの移行が回り始めた話 高橋悟生 AIエージェントに移行ガイドを与えて150フォームの大規模移行を効率化した実践事例 2 AIコーディングエージェントの活用で、コードは静かに肥大化した —— 型・Lint・Skillsで挽回する10分 篠田 陽介 AIコーディングによるコード肥大化問題と、型・Lint・Skillsによる品質 維持の戦略 2 TypeScriptで実現する既存APIを活用したリモートMCPサーバー構築 鈴木翔大 TypeScriptで既存APIをラップしたリモートMCPサーバーを構築する方法 2 「バイトル」のTypeScriptリニューアル — 積み上がったレガシーとパフォーマンスに挑む現在地 横山 隼 大規模サービス「バイトル」のTypeScriptリニューアルにおけるレガシー対応とパフォーマンス改善 2 ts-morph でプロジェクト固有のアーキテクチャガードレールを作る msuto / Michimasa Suto ts-morphを使ってプロジェクト固有のアーキテクチャルールを自動検証する仕組みの構築 2 typescript-goで変わるリンターの世界 — Flintという第三の選択肢 Tamasho Tomoya tsgoの登場で変化するリンターエコシステムと、新たな選択肢「Flint」の紹介 2 Polymorphic Components パターンで作る、型安全でセマンティックな UI コンポーネント ryo Polymorphic Componentsパターンによる型安全かつセマンティックなUIコンポーネント設計 2 AI時代に考える、Branded Typesで実現する堅牢な型付け 池奥裕太/@yuta-ike AI時代においてBranded Typesが果たす役割と、堅牢な型付けの実践パターン 2 次世代リンターで探る、tsgo 時代における型認識カスタムルールの現実解 Yuta Takahashi tsgo時代に型認識カスタムルールをどう運用するか。Go バックエンドルール PoCと現実的な振り分け戦略 2 TypeScript7 - 非推奨設定から読む責務の変化 Ayu TypeScript 7で非推奨となった設定項目から読み解く、コンパイラの責務の変化 2 TypeScript Compiler はどのように未使用変数を検出しているのか？ つねみ@tocomi TypeScriptコンパイラの未使用変数検出メカニズムの内部実装を解説 2 プロパティの順序で型推論が壊れる!? TS6.0 の修正から Context-Sensitivity の仕組みを追う おおいし (bicstone) プロパティ順序による型推論の不具合とTS6.0での修正を通じてContext-Sensitivityの仕組みを解説 2 OST (Open Space Technology) TSKaigi運営 参加者主導のオープンディスカッション形式セッション 以下、特に実践的だと思ったセッションや印象に残った出来事について書きます。 業務に残された「よくない型」で考える「TypeScriptの難しさ」 登壇者： Saji (サイボウズ株式会社 / フロントエンドエンジニア) 資料： https://speakerdeck.com/sajikix/ye-wu-nican-sareta-liang-kunaixing-dekao-eru-typescriptnonan-sisa 要約 TSによる失敗パターンにはパターンがある -> そのパターンこそが TSの難しさ => プロダクトのよくない型（any, asによるcast, @ts-ignoreで型チェック無視、雑な型ガード）をAIで探すとおおよそ3つのパターンに分けられ細かくわけると 7つ に分類できた 1. 動的な境界での型落ち 1. DOM Event/ catch (e) 2. unknownでasでキャストしてしまう 3. 文字列 -> Branded型 / リテラル型の限界 2. 動的な配列・Object変換 1. Array.filter / includes / isArrayの絞り込み 2. Object.fromEntries / Object.keys 3. unionの扱いの難しさ 1. 対応させたい値を別に組み立ててしまう 2. 引数のUnionから返り値を推論しづらい 解決策様々 helperや型ガードをちゃんとかく（かけるものは書くことをチーム（orAI）で規約に） typeとvalueなど本来1対1で対応している型はセットで生成し、d-unionが使えるようにする設計に overload関数でなんとかする etc… リントで規約化したり、ガイドラインにチェックリストなど明記し、AIに同じ妥協を再生産させないことや定期的な棚卸しをする（させる）ことが運用面で大事！ 感想 会場で頷いている人が多いと司会の方も言われていましたが、確かにあるあると思いましたし、こうして、改めて明示的にパターン列挙されると数もこんなもので、みんながハマるポイントって同じなんだなという気持ちになりました。 改善策の大半は、ヘルパー関数、型ガード、overloadを開発者それぞれが意識して書いて担保する必要があるというのは昔から変わらない気がしますが、AI協業を考えるとより仕組み化させることの重要性を意識させられました。 unionの難しい型解決に関してはバージョンアップでより便利になると嬉しいですね…。 アンチパターンを避ける型駆動React最適化 登壇者： Kazuya Serizawa （株式会社PeopleX） 資料: https://speakerdeck.com/seriseri/tskaigi-2026-antipatanwobi-keruxing-qu-dong-reactzui-shi-hua 要約 ReactCompilerはこれまで人間が手動で行なってきた最適化（不要な再レンダリングを防ぐためのメモ化）を肩代わりしてくれる。 => コンパイラの仕組みを読み解き、より最適化されやすいコードを書くことが今後重要。 最適化されるか否かは 純粋性が証明できるか によって決まる。 最適化されるコードは結果として読みやすく、テストしやすく、壊れにくい。 ReactCompilerの中身を読み解くと、 React Compilerは何が何に依存するかの依存グラフとして読む。 依存グラフを使って、ReactiveScopeの概念を構築し、値の流れと再計算のキャッシュが必要な単位見ている。 依存構造でReactiveScopeを自動で発見すること => 我々がやること： コンパイラが依存構造を発見できる書き方をする（=純粋に書く） 純粋関数の条件 決定的であること（同じ入力に対して常に同じ出力を返す） 関数の外側に副作用（観測可能な可能性を一切与えない）がないこと ＜コードレビューでの上記のチェック観点＞ 1. 外部スコープの値を書き換えていないか 2. Propsや引数を破壊していないか 3. レンダー中に外の世界に値を渡していないか（ログ、API、DOM操作etc） アンチパターン コンパイラに諦められる4パターン（B >> C > AとDはベテランがよくふむ？） A. 副作用の混入（uuid, Date.now()…）-> hook, イベントハンドラに渡すのが正解 B. ミュータブル操作（sortは破壊的メソッド）-> スプレッド構文で一度コピーして展開する C. 参照不安定（境界を超える毎回new） D. 非決定的な依存（外部の可変参照 これらは型駆動で 仕組み化 して間違ったコードを書けなくすることが大事 Readonly でミュータブル操作を"書けなく"する 型で禁止すればコンパイラの検出を待たない 破壊的操作を思考から取り除く（型が思考のデフォルトを変える） Branded type と Pure <T> で純粋契約を型化 型でカバーしきれない部分（関数の振る舞いなど）はlinter（Biome, Oxc..）で守る。 => 型は 値と形 、lintは 振る舞いと規約 の安全性を守る 大規模プロジェクトの設計指針 副作用を持つ層（Effects）・純粋層（Domain）・UIを物理的に分ける 上記はコンパイラが最適化しやすい設計のため、設計の動機付けがより強くなった。 ～チームに残すルール～ ・副作用は専用フック/サービスに追い出す ・ドメイン関数はPureを強制 ・UIは純粋層の値を渡すだけ ・メモ化は書かない、書かせない←1番大事（lintでuseMemo/useCallback禁止） 感想 ReactCompiler、信じてるからな。（手動メモ、消します__） 「ReactCompilerの気持ちになって考えてみる」というセリフを別のセッションでも聞きましたし、今回のセッション内容でより、react19から登場したReactCompilerによってこれまで手動で行ってきたパフォーマンスチューニングから解放され綺麗なコードをかく意味合いが転換されたことを実感しました。 コンパイラのために純粋性を保つことが結果的に良い設計・良いコードにつながると言う視点は非常に納得感があり、業務ですぐ使える具体的なチェック観点やチームルールも多く紹介されており、大変勉強になりました。 その他 ランチ 今年もランチに出るお弁当の種類が日毎3種類くらい出ていて大変豪華でした。 鶏めし御膳人気すぎて一瞬でなくなっていた…。 スポンサーブース 今年は全部で77社のスポンサーがついているそうです（すごい） クイズやくじ引きなどを行なっているブースがあったり、初出展のブース企業の事業内容について聞いたり、AI導入やトレンドについて話したり普段こういった機会は中々ないので、大変刺激になりました。 ブーススタンプラリー 20個集めて抽選に参加！だったので回ってみましたが結果は参加賞（缶バッチ） エンジニアの願いが書かれた短冊 営業シミュレーションを体験する社内メンバー ソフトバンクのsatto事業開発本部 の エンジニアタイプ診断 皆さんもやってみてください。（自分は コードの預言者 でした。） 当日企画 昨年にはなかったセッション以外の企画も盛り沢山でした！ ネイル スポンサーブースの片隅にネイルコーナーが。 TSカラーの青で頼んでいる男性がいたり、爪磨きだけ等もできるようだったので結構盛況していました。ネイリストさんに聞いてみるとこういったイベント出張はやはり珍しいとのことでしたが、GitHubやAWSイベントでもネイル企画があったらしいので最近流行りなんでしょうか？ 自分はTSの水色に冒険する勇気出ず、普通にかわいいネイルをしてもらいました…^^; マッサージ マッサージも常に待ち列が。 マッサージ師さんが常駐されており、遠方から来ている人などはリフレッシュできて良さそうでした。 公式頒布物 今年は参加特典としてTシャツだけでなく、参加者1人1枚NFCカードが貰えました。 （最近名刺がわりにしている人もたまに見かけるのですが、専用アプリで、自分のサイトURLなど登録しておくとスマホなどでカード読み取ればさっとリンク先に飛べるようになるものです） OSTなどのエンジニア交流で即役に立ち、記念品・実用性両面兼ね備えたナイスな特典でよかったです。 参加してみて 今年で3年目となるTSKaigiですが、昨年に引き続き参加してみて、連年で参加したイベントも初めてなのもあり、昨年と比較してさまざまな面で大きな変化を感じることができたイベントだったと思います。 チケットが即完するスピード感に始まり、協賛スポンサーの増加、企画が様々増えていることなども実際に現地へ足を運んで昨年よりもレベルアップしているのを感じました。 内容に関しては、昨年は突如到来したAIバイブコーディングの波や、開催直前に出たtsgo previewがセンセーショナルな話題として圧倒されていたのが懐かしいですが、昨年は突如到来したAIバイブコーディングの波や、開催直前に出たtsgo previewがセンセーショナルな話題として圧倒されていたのが懐かしいですが、AIを活用することは前提として扱われていて、1年という短い期間でありながら、この1年の進歩がいかに怒涛であったかを実感しました。 基調講演では、TypeScriptコンパイラのGo移植を主導したMicrosoftのJake Bailey氏が登壇され、TypeScriptコンパイラをGoに移植する1年半の取り組みについてお話しされました。移植戦略の中でお話しされていた、約1万5,000個のスナップショットテストと差分ファジングによって「振る舞いを変えずに移植する」開発スピードと安全性を担保した手法が印象的であったのと、公式リリースされたtsgoによるライブでのコンパイル速度比較デモ（VS Codeで125秒→10秒、約12倍）も披露されました。 同時に、複数のセッション内容が同じテーマについて触れられていた（ReactCompiler, BrandedTypes...）のも特徴的で、エコシステムのデファクトスタンダードな話題としてわかりやすい年だったように思います。 OSTでは、外部エンジニアとこれからのキャリアや技術選定の悩みについて話したりなどしましたが、カンファレンスとしては他のコミュニティよりまだまだ若いので、着実に成長・輪を広げているTSコミュニティに引き続き注目、参加していきたいと思いました。 セッションの内容も実務に活かせそうな内容のものも多かったので、今回得た知見を業務に取り入れながら今後もキャッチアップしていきたいと思います。 今回の参加レポートが、TypeScriptを学びたい方やTSKaigiに興味があるけど参加したことがない方など、少しでもTypeScript に触れるきっかけになれば嬉しいです。 ここまでお読みいただき、ありがとうございました！

はじめに デジタルテクノロジー戦略本部 AI戦略室 AIソリューション部 データサイエンス1課のN.Rです。 2026年4月22日から24日にかけてラスベガスで開催された  Google Cloud Next '26  に参加してきました！ 本記事では、今年のNext で注目を集めたテーマのひとつである 「Gemini Enterprise Agent Platform」  について紹介します。 Google Cloud Next '26 ってどんなイベント？ Google Cloud Next は、Google Cloud が主催する年次テックカンファレンスです。世界中のエンジニアや企業関係者が集まり、クラウドの最新動向や新しいプロダクト・技術が発表される一大イベントとして知られています。 イベントの幕開けを飾る Keynote では、Google のリーダー陣による重要な発表や大規模なデモが行われ、会場は大盛り上がりでした！ 今年は 2026年4月22日〜24日 の3日間、ラスベガスの Mandalay Bay Convention Center で開催され、 今年のテーマは 「The Agentic Era（エージェント時代）」。AI が「会話するツール」から「自律的に行動するエージェント」へと進化したことを象徴するイベント でした。 3日間のプログラム構成 各自聞きたい講演を事前に予約して、いろんな情報収集することができます。 Next は単なる講演イベントではなく、多様な形式のプログラムで構成されています。 プログラム 概要 Keynote イベントの方向性を決める基調講演です。CEO Thomas Kurian 氏による Opening Keynote と、エンジニア向けの Developer Keynote を含む計3本が行われました。新プロダクトの発表や大規模デモが披露される、まさにイベントの「顔」です。 Spotlight 特定テーマを深掘りする中規模セッションになります！ Breakout Session AI・データ・セキュリティ・インフラなど幅広いテーマをカバーし、Q&A で登壇者に直接質問もできます。 Workshop ハンズオン形式の実践型セッションです。Googler やパートナー企業の開発者から直接指導を受けながら手を動かせます。人気なので、予約が取れないです！ Discussion 少人数のラウンドテーブル形式です。参加者同士で特定テーマについて議論する感じです。 Solution Talk あらかじめ設定された課題に対して Googler が解決策を順を追って解説するセッション。実践的なアーキテクチャの参考になります。 Lightning Talk Developer Theater で行われる約20分の短時間デモ。最新トピックをサクッとキャッチアップできます。 Expo スポンサー・パートナー企業が出展する展示エリアです。最新プロダクトのライブデモを体験したり、エキスパートに直接相談できます。 Keynote はオンラインでもライブ配信されますが、Workshop で Googler に直接質問したり、Expo で最新デモに触れたり、Discussion で他の参加者と議論できるのは 現地参加ならではです。 私は、Workshopに一番参加したかったのですが、予約がとれず、Keynote、Spotlight 、Breakout Sessionをメインに参加してました！ 今回は、Keynoteで発表された、 Gemini Enterprise Agent Platformについて紹介します！ Gemini Enterprise Agent Platform とは 従来の  Vertex AI  から名称変更され、エージェント開発者向けの統合支援プラットフォームとして生まれ変わりました。 まさか名称変更されるとは、気に入っていたので少し寂しかったです。。。 Agent Platform は以下の  4つの柱  で構成されています。 柱 役割 主なサービス Build エージェントの開発 ADK / Agent Studio / MCP Scale エージェントの実行・スケール Agent Runtime Govern 認証・アクセス制御 Agent Registry / Agent Gateway Optimize 監視・可観測性 Agent Observability 開発から運用まで、エージェントのライフサイクル全体をカバーする構成です。 Vertex AIの時は、MLモデルも扱う感じでしたが、一気にエージェントのツールに振り切った印象を受けました！ エージェント開発の選択肢 — ADK と Agent Studio エージェントの開発手法は  コードベース  と  ローコード  の2種類が用意されています。 Agent Studio（ローコード） Agent Platform 上の UI で開発できるローコードツールです。 自然言語で入力するだけでエージェントを開発 できるようになりました！ 作成したエージェントのコードも見れるので、コードを書く人にとってもありがたい仕様になっております。 現在プレビュー版で、機能が後日追加な部分がありますが、これからの機能追加に期待です！ Agent Development Kit（コードベース） Python・Java・Go・TypeScript の  4言語  に対応し、詳細なカスタマイズが可能な開発キットです。 本格的にAIエージェントを開発するなら、ADK ** の方が優れています。 今回、 ADK 2.0** がベータ版でリリースされました。2.0からグラフベースのエージェント設計ができるようになり、条件分岐などに対応可能になりました。現場でエージェントを扱うためには必要な構造です！ エージェントの実行基盤 — Agent Runtime エージェントの実行環境は  3種類  用意されています。 実行環境 特徴 適用シーン Agent Runtime エージェント特化のマネージド環境。最大3,000エージェント同時実行、最大7日間の長期実行、Memory Bank標準搭載 本番運用・大規模デプロイ Cloud Run コンテナベースの汎用実行環境 カスタムランタイムでの柔軟なデプロイ GKE Kubernetes基盤。GPU対応やカスタムネットワーク構成が可能 大規模オーケストレーション 中でも  Agent Runtime  は、最大3,000エージェント同時実行、最大7日間の長期実行と、長時間稼働もできる環境になっており、現場でエージェントを稼働させるための環境といった印象を受けました！ また、セッション管理・Memory Bank等のメモリ系も標準搭載されている点はすごく驚きました。エージェント専用のDBとかを別で作らなくていいのは、手間が省けますね。 Memory Bank — エージェントの長期記憶 個人的に、今回のイベントで  最も注目した機能  が Memory Bank です。 セッション機能との違い セッション機能と何が違うのかというと、用途も少し違いますが、 セッションが短期記憶とMemoryBankが長期記憶のイメージでした！ 比較項目 セッション機能 Memory Bank 記憶の範囲 単一セッション内の会話のみ セッション横断で永続的に保持 保持期間 セッション終了時に消失 長期的に保持・蓄積 主な用途 会話中の文脈維持 ユーザーの好み・ビジネスルールの学習 デモで見た活用例 Next の会場では、 服のレコメンドエージェント  のデモが印象的でした。 ユーザーの好みの色や嫌いな色を Memory Bank に保存することで、次回以降は何も説明しなくても、好みが反映されたレコメンドが自動で生成されていました。 これは  パーソナライズ AI エージェント  実現の鍵になる機能だと感じます。 Govern & Optimize — エージェントの統合管理 エージェントを本番運用するうえで欠かせない、 セキュリティ・ガバナンス・可観測性を統合した管理基盤も発表されました。 機能 特徴 ステータス Agent Registry エージェント・MCPサーバー・ツールの統合カタログ Preview Agent Gateway トラフィックや権限、アクセス制御 Preview Agent Observability エージェントの挙動の可視化・追跡 Preview 認証・登録・通信制御からパフォーマンス監視まで、包括的な運用管理が実現できる構成になっています。 エージェントの本番運用となると、運用構成や、監視の仕組みが重要になってくるので、ここら辺の機能については、社内でも知見を深めていきたいですね！ まとめ 今年の Google Cloud Next は「AIエージェントを現場へ」というメッセージが 全体を貫いており、開発・実行・管理の各層で具体的なツールが揃ってきた印象です。 特に印象的だったのが、Memory Bank によるパーソナライズの可能性です。 デモでは、ユーザーの好みをエージェントが継続的に記憶し、次回以降の提案に自然に反映する様子が紹介されていました。単発の会話にとどまらず、パーソナライズした提案ができるような仕組みは、興味が湧きました！ 一方で、こうしたエージェントを実際のプロダクトとして運用していくためには、開発だけでなく運用面の設計が重要になります。エージェントが業務の中核に入り込んでいくほど、これらの運用基盤の重要性はさらに高まっていきます。だからこそ、単に新しい機能として捉えるのではなく、実運用を見据えた技術として理解を深めていく必要があると感じました。 今後は、こうした運用構成や監視の仕組みについても社内で知見を蓄積しながら、どのように自社サービスへ適用できるかを具体的に検討していきたいと考えています！ 来年行く人へ 講演を聞くのも楽しいですが、手を動かすのも楽しいと思うので、ぜひWorkshopに参加して欲しいです。また、講演を予約せずに、Expoを見て回り、今回発表された機能を間近で見れるブースがあり、社員に近い距離で質問できるのでこれもイベントの楽しみ方の選択肢の一つだなと思いました！ ぜひ、来年のイベント参加の参考にしてください。 初めてラスベガスに訪れたのですが、やはり印象的なのが華やかな街並みでした！ 今回の滞在中に訪れた有名な「ベラージオ」では、噴水ショーを見ることができました。 昼間はカンファレンスで最先端のテクノロジーに触れ、夜はこうしたエンターテインメントを体験できるのも、ラスベガス開催ならではの魅力だと感じました！ 最後までお読みいただき、ありがとうございました！

はじめに  就職ITソリューション1課のM.Yです。  本記事では開発の実務経験がないまま上流工程の業務を担当することについての自分の考えを述べています。自分自身も（配属時から数えると）まだ3年も経験していない身で恐縮ですが、自分自身の振り返りも兼ねております。  なお、本記事についてはあくまで個人的な考えによるもので所属部署・PJの方針ではないことをご承知おきください。  想定読者  ・新卒入社や異動などをきっかけに、開発経験がないまま上流工程を担当することになった方  ・開発経験が浅い状態で、要求整理や要件定義、関係者との調整を担うことになった方  ・開発経験はあるものの、上流工程を経験するのが初めての方  筆者の経歴  ～2023年3月：学生時代情報工学を専攻  2023年4月：卒業後マイナビ新卒入社  2023年7月：現所属部署の前身となる部署に配属  2023年10月：デジ戦に部署ごと異動  現在に至る 担当業務  新卒就活サイト「マイナビ20XX」開発担当  ・社内外の関係者との調整業務  ・新規機能の要求整理・要件定義（要求定義書の作成など）  ・基本設計レビュー  ・企業専用画面デザイン制作ディレクション  ・外部連携システムとのテスト進行や各種調整業務  　　..etc 開発実務経験がない新卒上流担当の置かれた状況  「開発実務経験がないまま上流工程を担当する」と聞いて、難しそうだと感じる方もいるかもしれません。  私自身も、配属当初は「本当に役割をこなせるのか」「内容を理解した上で要求・要件検討ができるのか」と不安を感じていました。  結論からというと「本人の努力次第でどうにかなりはするが、ハードルは高い」と言わざるを得ません。  まずは私自身がぶつかった、上流工程を担当するにあたってどういったハードルがあるのかについて述べたいと思います。  技術理解が浅い状態で要求・要件定義をしなければならない  インターンシップ等で就業経験のある方以外は、基本的に製造工程を経験しないまま現在の職務に就く形になり様々な壁にぶつかると思います。  私の場合、学生時代情報工学を専攻していましたし趣味でプログラムを書くくらいのことはしていましたが、実務レベルの技術理解がありませんでした。  実際に自分が困ったのは大きく下記の3つです。  技術選定の根拠となる前提知識や運用時の経験がないことにより、それらを想定した要求・要件検討が難しい  テスト設計時や障害発生時に押さえるべき「勘所」がわからず適切なテスト設計ができない  「勘所」がつかめておらず障害発生時に原因特定までに時間がかかってしまう  当社の場合は開発ベンダーさんに委託していたり、内製チームの皆さんに技術面のプロセスをお任せする場面も多く、承認などは上長やPM層が担うことが多いです。  そうした環境に加え、自分の場合は業務手順がある程度整っていたことや、先輩方のサポートを受けられる環境だったため、今となっては実務の中で少しずつ理解を深めていくことができました。  しかし配属当時は、先輩方にサポートいただきながらも、製造工程を経験されている方と比べると明確に理解度に差がある状態で業務に臨む形となってしまっていました。  しかしながら要件定義時の際にはある一定の理解度は求められます。事業部門に内容を理解した上で提案・説明する必要があったり、ベンダーさんとの要件定義を進めていく際にも、その内容が非機能要件も含めて当社側の要求を満たしているか等を判断する必要があるため、理解度が不足していると業務遂行に支障が出ます。  また、障害発生時には実際に手を動かすのがベンダーさんや内製部門の方であっても最終的に上流担当が内容を理解した上で対処・報告などをする必要があるため、そういった観点でも少しずつで良いので担当システムでどういった技術が採用されているかやシステム構成など、最低限技術理解を深められるように努力する必要があります。  さらに精神的な面で言うと、開発経験を積んできたというバックボーンがないままベンダーさんや事業部の担当者の方と(見かけ上は)ある程度対等にやり取りしなければならないというところも地味にきついです。  配属された当時の自分の場合、会議中事業部の方に「〇〇って技術的に可能なんですか？」と質問された際に、たとえ技術的に正しい知識を持っていて回答できる状態にあったとしても確信を持てず、なんとか「△△という方法で可能です」と回答するという経験がよくありました。  もちろん上長のバックアップのもとで対応しているため、仮に自分の認識が不十分でもフォローしていただける環境ではありました。  ただ、当時は技術的な内容を自信を持って説明することに難しさを感じる場面も多く、周囲の支援を受けながら少しずつ伝え方や整理の仕方を身につけていきました。 あくまで私の経験ではありますが、ここまで述べたように新卒で上流工程を担当する以上、最初のうちはこうした場面を避けるのは難しいと思います。  ビジネススキルが身についていない状態での調整業務  どんな職種にも言えることではあるのですが、ビジネススキルが身についていない状態で社内外のステークホルダーとのやり取りをしないといけないため最初は大変だと思います。  案件によっては職位の高い方との会議のファシリテーションなど新卒目線では中々つらい業務もあったりします。  （相手方は優しく見守ってくれる方が大半なので実はそこまで気にしなくても良いかも）  この問題は新卒であれば誰しも経験することなので気にしすぎも良くないですが、問題はそんな状態で要件定義などが絡む会議に参加したり、メールやチケットでのやり取りを行う必要があるということです。  曲がりなりにもそのPJを担当するということは当然自分自身が矢面に立って相手とやり取りする場面も多くなります。特に社外の方とやり取りする場合はこちらが経験が浅いということは関係ない訳ですから、可能な限り適切なやり取りが求められます。  自分の場合は、ビジネス会話・文書のスキルが十分でない中、「伝えるべき内容」「やりとりする相手ごとに適した伝え方」などを考えながら話す・書く必要があったため最初は苦労した覚えがあります。  幸い私は会議などで矢面に立ちやり取りすること自体は緊張はほとんど感じないタイプでしたが、前述の経験不足からくる不安や失礼な物言いをしていないかというところで緊張してしまうこともしばしばありました。  どう乗り越えるべきか  ここまですごく脅すような文章を書いてしまって申し訳ないのですが、自分が乗り越えるためにしたことを共有したいと思います。人によって対処の仕方は異なるかもしれませんが、自分が実際にやってきたことをそのままお伝えします。  技術理解の浅さに対してのアプローチ  私の場合、所属部署には他社でさまざまな経験を積まれた方が多く、技術面ではそうした経験豊富な方々に相談しながら理解を深めてきました。ただ、わからないことを分からないままにはしないようにしています。  例えば、ベンダーさんとの会議で知らない単語が出てきたら裏で検索したり、後で資料を読んでみたりなどしています。また、配属当時は「会議中にわからない単語を10個以上はメモして後で調べるか質問する」といったこともしていました。  幸い自分は情報工学の基礎知識はあり調べればある程度の概念は理解できるため、今では要件検討や運用に最低限必要なレベルではそれほど困ってはいませんが、配属当時は右も左もわからずで、「何が分からないかも分からない」という状態だったので前述したように部署の先輩や上長に質問することで何とかついていくようにはしていました。  また、インシデント対応についても積極的に拾うようにしていました。  所属部署では専門の運用チームが存在するため、基本的にはその方々に検知も含め1次対応などをお任せしてしまうことが多いのですが、開発チームも全く対応しないということはなく検知した人が拾ってそのまま対応、または運用チームに引き継ぐといったこともそこそこあります。  特に自身が担当した改修や担当領域に関連するインシデントついては担当者が対応した方がスムーズですし、規模や影響が大きいインシデントの場合は担当など関係なく早期の対応が求められるためこのような形態になっているのですが、その方針に則る形で自分なりに成長できるような取り組みを行うようにしていました。  もちろん配属当初は「自分の担当」と言えるものはほとんどなかったですし、周りの方がインシデント対応されていても何をしているのかさっぱりだったのですが、その中でもできることとして、  メールやチケットにて事業部などから問い合わせがあった場合に拾ってインシデント対応用の全体チャットに投げる(検知)  当該インシデントに関連する担当者が誰か調べてお繋ぎする（ 地味に重要 ） 先輩方が対応している間にたとえ役にたたなくとも自分なりに設計書などを参照し調査してみる  検知から対応までの流れを見て学習する  といったことを実践していました。  これにより、インシデント対応業務の理解が深まるのはもちろん、副次効果として「運用側の気持ち」や「仕様の把握」、「何が原因で障害が発生するのか」など、要件定義にもつながる知見を得ることができます。  （自分自身も最近やっとそれらが身になってきたかも…？と感じるくらいのレベルですが…） ビジネススキル不足に対してのアプローチ  こちらについては正直上流担当かどうかはあまり関係ないのですが、社内外含めステークホルダーが多い環境でどのように乗り越えていったかも含めお伝えできればと思います。  前提として、事業会社側の上流担当はたいていの場合「事業部門の担当者の方」「ベンダーなどの委託先」「社内の内製部門の方々」とやり取りすることがほとんどです。  実際に私の場合、社内の人間以外とは事業会社側の担当者としてやり取りすることが多いです。  一方で、そうした環境では、経験が浅いうちは無知ゆえに相手との関係性や適切な距離感を十分に理解しきれないままやり取りしてしまうことで失礼な言動をしてしまっていないかを気にすることもありました。  ただ、そもそもきちんとした文章を書いたり相手に伝わる話し方ができないと、相手に失礼かどうか以前に上流工程担当としての業務進行に支障が出ます。もちろん言葉遣いなどは新卒研修などで学んだりしているため問題ないと思いますが、実務に入ってみると一般的なビジネスマナーの他にも覚えることはたくさんあり、相手によってコミュニケーションの方法を切り替えたり伝える内容を調整することを身に着けるなど中々研修だけでは学びきれないことも必要になってきます。  あるいはビジネス用語を知らないことで、会議で周りが何を言ってるのかわからないなんてことあったりします。  例えば私の場合、「トルツメ（取ってつめる）」という単語が分からず先輩に聞いたりしていました。（今思うと恥ずかしい） こういった用語は今となっては当たり前に使うものですが、今思えばこういったビジネスシーンで多用される用語を研修で学んだりはしていなかったなと思います。しかも要件定義の場では「トルツメ」という用語はかなり出てくるため知らないとそこそこ困っていただろうことを考えると地味に重要かもしれません。  こういった状況で、文体が不自然で相手に伝わりづらい文章を書いてしまったり、喋り慣れていないために会議で発言に詰まったりしていましたが、その中で私が取り組んだこととしては、  とにかく先輩方のコミュニケーション（文章・口頭問わず）を観察し、真似る  組織構造を理解し、どの組織が何を担っているのかを知っておく（特に事業部側） 分からない単語があれば調べてそれでもわからなければ恥ずかしがらずに周りに聞く（社内用語か一般用語かも確認する） 最初のうちは文章を書くにも、会議で喋るにもしっかりと準備をする（先輩への推敲依頼、会議の練習など） アサーティブコミュニケーションを学ぶ  といったことを実践していました。  とにかく真似る、質問する、準備することを念頭に置いて業務に臨むことで業務に必要な知識を得ることや仕事の型を学ぶことはもちろん、「先輩と同じやり方でやる」「質問して疑問点を無くす」「準備をしてコミュニケーションへの不安をなくす」ことで精神的にも健全な状態で業務に臨めたかなと思います。  ちなみに、アサーティブコミュニケーションとはどんな立場の人とも敬意を持ったうえで対等に接するためのコミュニケーション手法で、上流工程業務では特に重要なスキルだと個人的には考えています。  職務上様々な立場の方とやり取りすることが多く、社内外問わず職位の高い方やベテランの方など、若手からすると接し方が難しい方とも合意をとってPJを推進することが求められることもあります。  立場や経験の違いによって遠慮しすぎたり、逆に一方的な伝え方になってしまったりすると、業務遂行に支障が出ることもあります。だからこそ、相手を尊重しながら必要なことを適切に伝える力を身につけることは、とても大切だと思っています。  相手に伝わりやすい文章の書き方や話し方なども学ぶことができるので、そういった面でも非常に役に立つと思います。  まとめ  自分が配属当時に苦労した経験をもとに、同じような立場の方に少しでも参考になればとここまで書きましたがいかがでしたでしょうか。  今回ご紹介したアプローチについては個別具体的な内容も含まれておりますが、一貫して重要だと私が考えるのは「分からないことはすぐに調べる・質問する」「先輩方のやり方を観察・真似をする」ということです。  自分だけで抱え込みすぎようとするとつらくなりますし、上手く行きづらいと思っています。自分なりにやってみることも大切ですが、まずは先輩方に色々聞いてみる、真似するということをやってみた上で自分なりに考えながら業務を進めてみると仕事の覚えも早いですし、課題解決もしやすいのかなと思います。自分も今回の記事を書くにあたって初心に帰って業務に向き合おうと思いました。（そもそもまだまだ若輩の身ですが…） 以上、ここまでお読みいただきありがとうございました。 

このシリーズでは、当社のデジタルテクノロジー戦略本部（デジ戦）に所属する社員が、「なぜ当社を選んだのか」「入社して何を感じたのか」を率直にお届けします。入社前の期待や不安、入社後のギャップや魅力を通じて、働く環境を具体的にイメージしていただける内容です。 ■執筆者プロフィール職業：PdM社会人歴：9年目（※2026年現在）マイナビ歴：1年目（※2026年現在）所属組織：デジタルテクノロジー戦略本部前職：経営コンサル、教育系スタートアップ、フリーランス／起業など ■執筆者プロフィール 職業：PdM 社会人歴：9年目（※2026年現在） マイナビ歴：1年目（※2026年現在） 所属組織：デジタルテクノロジー戦略本部 前職：経営コンサル、教育系スタートアップ、フリーランス／起業など はじめに PdMやサービス／UXデザイナー等、サービス／プロダクトづくりに携わり、次の一歩を考えている方のキャリア検討の一助になればと思い、本記事を書いています。 プロフィールとこれまでのキャリア 現在は、マイナビのデジタルを横断する組織であるデジタルテクノロジー戦略本部（以下、デジ戦）にて、各種プロダクトのプロダクトマネジメントを担当しています。 これまでのキャリアとしては、コンサルティング会社やスタートアップで、ビジネス戦略からサービス／UXデザインまでの領域を中心に仕事をしてきました もともと、学生時代に国際開発や移民教育を学んでいたこともあり、 生まれた国や環境に依らず、人がその人らしく幸せに生きる仕組みを創る をテーマに、 教育やヘルスケアなど、人の人生に深く関わる領域（個人的には「ライフエクスペリエンス」と呼んでいます）のサービス／プロダクトに関わってきました。 転職を考えたきっかけと自分のキャリアの軸 転職を考えたのは、30代に入り、 自分の得意や興味が明確になってきたタイミングで、 もっと自分を活かして働きたい と思ったことが大きかったです。 20代は夢中になれるものを探し続け、目の前の仕事にひたすら取り組んできました。 その中でようやく前述したテーマに加え、自分の 好き＝ サービス／プロダクトの全体構想からユーザー体験まで一気通貫で設計する 得意＝ 複数ステークホルダーを巻き込み、全体を交通整理しながら、チームで共創する が見えてきました。 転職前の直近は個人で働くことが多かったですが、 自分の特性を、より活かせる環境で働きたいと考え、 環境を変えることを決意しました。 転職活動で重視していたこと 転職活動では、主に以下の3点を軸にしていました。 自分の専門性（サービス／プロダクト創り）を活かし、伸ばせること 人のライフエクスペリエンスに関わるサービス／プロダクトに携われること 中長期で腰を据え、サステイナブルに仕事ができること 具体的には、HR／教育／ヘルスケア領域の事業会社・スタートアップや、サービスデザイン／UX領域のコンサルティング会社等を検討していました。 マイナビに決めた理由 最終的にマイナビに決めた理由は、大きく3つあります。 1.プロダクトマネジメントに専門的に取り組める デジ戦はデジタルの専門組織であり、PdM業務にどっぷり浸かることができます。そのため、これまで自分が培ってきた専門性を活かせると感じました。また、自己研鑽のための研修、資格取得、PdM間のナレッジ共有が推奨されており、持続的に力を伸ばしていけることも魅力的に感じました。 2.人のライフエクスペリエンスに深く関わるサービス／プロダクトがたくさんある マイナビは新卒の就職活動サイトのイメージが強いかもしれないですが、実は学生から社会人まで、人の人生の様々な局面に携わるサービス／プロダクトをBtoC/BtoB共に多数展開しています。自分のテーマである「人のライフエクスペリエンス」に対して、複数のサービス／プロダクトを通してアプローチできることに魅力を感じました。 3.生活と両立しながら柔軟に働ける環境 マイナビにはリモートワークや時差出勤など柔軟な働き方が可能で、メリハリを持って働ける環境があります。家庭と両立して働かれている方も多く、自分の今後のライフステージの変化も踏まえ、長期の目線で、良いコンディションで働くリズムを整えやすいと感じました。 上記に加えて、 マイナビの パーパス「一人ひとりの可能性と向き合い、未来が見える世界をつくる。」と自分のテーマにつながり を感じたこと 選考を通じてお話させて頂いたチームの方が、柔らかく対話させて頂ける方たちばかりで、 「この人たちとなら、一緒にサービス／プロダクト創りができそう」 と思えたこと が最終的な決め手になりました。 入社前に感じていた不安 一方で、入社前にはいくつか不安もありました。 大きな事業会社のカルチャーに馴染めるか これまでの0→1中心の経験から、既存事業の改善・伸長にも貢献できるか 外部パートナーを含めた大規模なプロダクトマネジメントに適応できるか キャリア初期の転職とは異なり、何年か経験を重ねたからこそ 自分と会社が本当にフィットするか は気になるところではありました。 入社してみて感じたこと 会社・業務ともに徐々に慣れていっている最中ではありますが、 感じていた不安は解消されつつあるなと感じています。 まず、心配していたカルチャー面に関しては、 中途でも丁寧なオンボーディング があり、会社の事業内容や各部の取り組みをキャッチアップできる 特にデジ戦は、中途や異動など 多様なバックグラウンドを持つメンバー が集まっているため、自分自身の多様なバックグラウンドも受け入れてもらえる 経験・ポジションとのフィットについても、 サービス／プロダクトの種類もフェーズも多様 であるため、なにかしら自分の強みを活かせるプロジェクトがある デジ戦の組織自体も若く、 挑戦できる余白が多い と感じています。 また、入社して印象的だったのは、自社のプロダクト／サービスに対して、 日本の社会インフラ としての自負を持っている方が多いことです。学生から社会人、企業の方まで、日本全国の方々に長期的にご利用頂いているプロダクト／サービスを展開する、マイナビならではの視点だと感じました。 現在の業務と今後チャレンジしていきたいこと 現在は新卒採用領域の企業向けプロダクト等、複数サービス／プロダクトに携わらせて頂いています。事業部や海外の開発会社等、複数ステークホルダーの方と連携しながら仕事を進める機会が多く、 望んでいたチャレンジができている と感じています。 今後は、1つ1つの担当サービス／プロダクトでの経験を積みながら、 複数サービス／プロダクトを横断し、人の人生のあらゆるタッチポイントで、 その人が自分らしく生きられる仕組みをつくることに挑戦していきたい と考えています。 そしてこの挑戦は、既にユーザー様が多数いて、社内の開発・販売リソースがあるからこそできる挑戦だとも感じています。 これまで様々な環境に身を置いてきた自分だからこそ、 物事を大きく変える挑戦ができる時機はそうそう来ない ことも身に染みているので、 変化を生み出すことに挑戦できている今この瞬間を、後悔しないように仕事をしていきたいです。 最後に ここまでお読みいただき、ありがとうございました。 人にはそれぞれ大切にしたいものがあり、キャリアのかたちも様々だと思います。 読んでくださったあなたのキャリア、人生がよりよいものになることを祈っております。 ご興味を持っていただけた方は、是非お気軽にご連絡ください＾＾ 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。

はじめに ITD2-2-3のI.Hです。今回、RubyKaigi 2026 in 函館に参加する機会をいただきました。 RubyKaigiは、Ruby本体やエコシステムに関する最新の知見が集まる技術カンファレンスです。 今回の参加を通して、Rubyそのものについて学べたのはもちろん、他社エンジニアとの交流やスポンサーイベントでのLT登壇など、普段の業務だけでは得られない多くの経験をすることができました。 この記事では、Rubyに関する知見の共有だけでなく、技術イベントに参加すること自体の意味や価値についてもあわせてまとめました。 Day0(イベント前日) 函館に前日入り 場所が北海道の函館と言うことで、当日出発では間に合わないため前日の夜に出発しました。 空港に到着すると、空港の至る所にRubyKaigiの看板や垂れ幕がありました。 また、路面電車の車内外にもRubyKaigiの看板が。町おこしさながらの盛り上がりでした。 空港で明らかにrubyistの方（第一rubyist）を見かけたので、タクシーに相乗りしました。 有名なラーメン屋さんで降りるとのことだったので、一緒に食べながら技術の話やお互いの会社の制度・AIツールの導入状況などに花を咲かせました。 Day1 会場へ 会場は、JR函館駅から市電で30分ほどの場所にある「 函館サーモン・まるなまアリーナ/ホール 」でした。命名権を地元の水産会社が取得されたらしく、函館感全開の良い会場名とロゴになってました。 チェックインすると、首から掛けるストラップと名札をいただきました。 会場で「どこの会社の方ですか？」と度々聞かれるので弊社のロゴを手書き。 なんとか伝わりました。 基調講演 The Journey of Box Building 発表資料はこちら 初日の講演は、rubyコミッターでもある田籠 聡さんの基調講演から始まりました。 内容は、2025年12月25日にリリースされた  Ruby4.0.0  の新機能の一つである、 Ruby::Box  についてでした。 Ruby Boxはクラス等の定義の分離／隔離のための機能を提供する、実験的機能です。 実験的な機能として位置付けられているとのことでしたが、安全にコードの分離ができるようになる点は業務にも活かせそうでした。 Exploring RuboCop with MCP 発表資料はこちら Keynote以外の公演は基本的に大ホール・小ホール・サブアリーナで行われ、同時刻に開催される講演に同時に参加することはできないため、タイムスケジュールと発表内容を見て選ぶ形式でした。 英語での講演も多く、同時翻訳アプリで聴くことにも挑戦しましたが、やはり日本語の講演の方が理解しやすく、自然と日本語の講演を選ぶことが多かったです。 そんな中で、初日の午後に参加した伊藤浩一さんの RuboCop  x MCPの話が印象に残りました。 RuboCopは人間や他のプログラムによってトリガーされていました。AI時代においては、AIエージェントが新たなトリガーとして登場しました。本講演では、生成型AIとリンターおよびフォーマッターを組み合わせる実践的な方法について議論します。 決定性がLinterとしての価値だった中で、非決定性を持つLLMを組み合わせることでどんな価値が創出できるのか（又は失われるのか）という試行錯誤の話が面白く、こういったイベントに参加して直接コミッターの方のお話を聞く醍醐味だと感じました。 Day2 基調講演 Twenty Years of JRuby 2日目は20年以上 JRuby （Java仮想マシン上で動作するRubyの処理系）を開発している、Charles Nutterさんの基調講演から始まりました。 内容はJRuby が誕生してからの20周年の振り返りと、JRuby 10.1 のリリースについてでした。 業務を含めこれまでCRuby（C言語で実装されたRubyの処理系）しか触ったことがなかったのですが、JRubyやMRubyのような別の処理系にも興味が湧きました。 Practical TypeProf: Lessons from Analyzing Optcarrot 発表資料はこちら 2日目は TypeProf 開発者の 遠藤侑介さん の講演が印象に残りました。 メインの話は、TypeProfを実際に適用してみた事例です。題材に選ばれたのは、発表者自身が開発したRubyで書かれたNES（ファミコン）のエミュレータで、約6000 行の複雑なコードに TypeProf を適用したところ600個以上のエラーが出たとのことです。 対応としては、型推論結果に強く影響する箇所にRBSを書くことと、TypeProf 側の誤認識の根本原因を直すことの2方向から進められ、最終的には Ruby 55行＋RBS 67行、合計122行の変更でゼロエラーに到達したとのことでした。SteepやSorbetと比べても、既存コードへの変更量がかなり少ないという結果でした。 終盤では、AI コーディングエージェントが普及する中でTypeProfをどう位置づけるのか、という問いも提示されていました。エディタ支援を主目的としてきたツールが、AI 時代にどんな価値を持てるのかという点についても言及されていました。 Day2の交流会 2日目の夜は、Drink Upに参加し、LT枠が空いていたので発表しました。 3日目のRubyKaigiがより面白く聞けるようにと思い、Rubyが実行されるプロセスをParserの話からGCの話まで、一通りまとめてみました。 資料は marp  + Opus4.6で作成 Day3 Lightning-Fast Method Calls with Ruby 4.1 ZJIT 発表資料はこちら RubyKaigi最終日は、 国分崇志 さんのZJITの講演が印象に残りました。 注目度の高い ZJIT ですが、今回の発表では特にメソッド呼び出しの高速化に焦点が当てられていました。 Rubyでは依然としてメソッド呼び出しのオーバーヘッドが大きく（動的型付けだから仕方ないが）、YJIT によって改善が進んできた現在でも、なお大きなボトルネックとして残っているそうです。ZJIT ではこの処理の最適化が大きなテーマになっており、バックトレースや例外処理、ローカル変数アクセスに必要なメタデータをどう保持しつつ、無駄なメモリライトを減らすかが論点になっていました。 そこで紹介されていたのがLightweight Framesでした。これは、メソッド呼び出し時に必要なフレーム情報を最初からすべてメモリに書き込むのではなく、必要になるまで遅延させ、まずは最小限の情報だけを持つことでコストを下げるアプローチです。 Rubyの柔軟な書き心地は維持しつつ、高速に動くようにしていく取り組みをしていただいてる事に感謝です Matz Keynote もちろん最後は、Rubyを作った「 まつもと ゆきひろ 」さん（Matz）の基調講演でした。 ここ半年くらいは自分でコードを書かずに、ほぼ全てAIに書かせるという縛りを自らに課しているとのことでした。コードレビューやプロンプトを細かく制御できるからこそできる事だと思いますが、実務の現場でもAIエージェントは欠かせない存在になってきているのではないでしょうか。 そんな中で大きなトピックは、新しいRubyのAOTコンパイラ「 Spinel 」の発表です。RubyコードをC言語に変換してからコンパイルすることで、ネイティブバイナリを生成するという試みで、すぐに業務レベルで役立てられるものではなさそうですが、インタプリタ言語×AOTコンパイルという発想と開発過程が興味深かったです。（Rubyは動的機能が多いので、機械語にできる=高速化ではないことに注意してください） まとめ RubyKaigiに行って良かったと思う1番のポイントは、Rubyやプログラミングが大好きな人達の「熱」を感じられたことでした。普段「仕事」としてプログラミングをしていると商業的な観点で価値を測り測かられる癖がついてしまって、楽しいとか知的探求という側面を忘れていたなぁと思いました。 また、現地での他社のエンジニアとの交流も刺激的でした。今まで自分がマイナビ色に染まっている自覚はありませんでしたが、他社のエンジニアと交流すると明らかに各社個性というか雰囲気があって、たまには視野を広げるためにも交流して新しい知見を持ち帰ってくる必要があると感じました。

法人ディベロップメント課の S・Sです。 マイナビBiz / LIVING の新規開発・保守運用を行なっております。 今回は、下記のような、私と同じような不安をお持ちの方に向けて、書いています。 「エンジニアの仕事は、いつかAIに取って変わられるのでは?という淡い不安が、実際の業務内でAIエージェント利用が定着化してきて、いよいよ現実味を帯びて焦っている」 「かといって、 実際にAIエージェントの有能さも肌感覚で感じているので、この大波にどのように立ち向かったらいいのかが分からない ...」 はっきり言って、誰しもが、AIエージェントの普及、そしてその先に、どんな未来が来るかが100%分かる人はいないかなと思います。 が、あくまで個人的に、こんな向き合い方をしたらいいのでは？ということをカンタンにまとめて、前向きな気持ちで、今できることを進めていけたらいいなと思っています。 この記事で、 少しでもAI社会におけるキャリアの不安が和ぎ、精神衛生や業務パフォーマンス、あわよくば、その先の未来でも生き抜けるエンジニアに向かって、ナノマイクロレベルにでもなれば幸い です。 今回は、サクッとカンタンめにまとめていますが、さらに概要をつかんでいただくために、1枚絵を用意しましたので、お忙しい方はこちらをチラ見していただけたらと思います。 ここから先は、上記の概要を少しずつ補足していきます。 AIの強み弱み分析 まず、AI との向き合い方を考える上で、そもそも、AIの特徴を理解しなければ、向き合い用がありません。 なので、完璧に見えるAIの強み弱み分析をカンタンにしておきます。 AI の強み ざっくりと下記が、AI の強みかなと思っています。 大量のデータからのパターン発見 認知作業が高速で行える 70点前後のクオリティのアウトプットを高速で出せる 大量のデータからのパターン発見 AI は、渡したデータの文字列や数値、組み合わせ等を高速で処理ができ、パターン発見を高速で行えるのが強みだと思います。 人手で莫大なデータからパターンを見つけるのは至難の技なので、ここはもうAIには到底叶わない領域 ですね。 認知作業が高速で行える 1つ目と被る部分でもありますが、認知作業、つまり、 大量のデータから本質や構造を把握し、整理することが得意 です。 「このコードの資料の内容を要約して」 と依頼すると、あっという間に、本質を抽出して、人間の理解できる形でアウトプットしてもらえた経験は少なくないのかなと思います。 70点前後のクオリティのアウトプットを高速で出せる 主に、前述の2つの強みを駆使して、与えられたデータ、プロンプトを元に、ざっくり70点前後のクオリティのアウトプットが高速に出せます。 人が、 0 → 1 を生み出すのにはものすごいエネルギーと時間を要しますので、AI はここを凌駕してきている のかなと思います。 AI の弱み 境界条件や例外ケースに弱い 生成物の結果に責任を取れない データ、プロンプト依存が大きい 境界条件や例外ケースに弱い 細かい条件分岐や例外ケースを考慮してのアウトプットが苦手な傾向にあります。 人であれば、文脈や背景、ドメイン知識、経験を踏まえて適切に対応できますが、ここは 正確に細かく指示出しをしてあげないと抜け漏れが発生 します。 それでいて、 あたかも完璧なように、振る舞ってくる、かつ、アンカリング効果によって、境界条件や例外ケースを見過ごしたまま、成果物を完成させてしまう懸念 があります。 参考:  アンカリング効果とは？意味や活用シーンをわかりやすく解説 生成物の結果に責任を取れない 当たり前ですが、人が作ろうがAIが作ろうが、 最終成果物の責任は、企業や個人が負います 。 AI に「不具合の責任を取れ！」といった所で、プロンプト上で「申し訳ありませんでした。以後このようなことは....（ごにょごにょ）」という文字列が返ってくるだけですからね。。 データ、プロンプト依存が大きい AI はよく「 増幅器 」と言われることが多いです。 この通りで、インプットするデータの量・質、プロンプトによる指示出しの質に依存します。 つまり、 こちら側から良いインプットをしなければ、出てくる成果物も微妙になってしまう ということですね。 あくまで人が与えるものの質ありき 、ということかと思います。 AI との向き合い方 一言でまとめると、 ・AI の強みは最大限活用して、弱みの部分は、人間の強みを強化して補完するのが良い と考えます。 AI を最大限活用 AI の強みを活用し、下記を主に対応できると良いかなと思います。 大量の情報の整理 パターンで対応できる業務（手作業だと時間かかるもの） 設計書や実装などの叩き台作成 大量の情報の整理 大量の情報整理は、AI の得意領域です。 人が行うとエネルギーも時間も大量に使ってしまうので、AI に任せてしまうのが良さそう です。 与えるデータの質やプロンプトを正確に行いながら、その上で、過不足をチェックし合いながら共創することで良い成果物を出せるかなと思います。 パターンで対応できる業務（手作業だと時間かかるもの） パターン化された業務や作業は、AI は得意です。 ルールや例外、誤作動を防ぐプロンプトで制御しつつ、AI に任せてしまうのが良いかと思います。 設計書や実装などの叩き台作成 AIは、ざっくりと70点のクオリティを高速で出すのが得意です。 なので、 初期段階の設計書や実装の叩き台をお願いする のがいいかなと思います。 その上で、必要に応じてプロンプトで細かな指示出しをしたり、自身で思考・作業を行うことで、70点→ 100点を目指すのが良いかなと思います。 AI に勝る能力開発 AI を活用しつつ、人間として、どう立ち回るかについては、主に下記かなと考えます。 生身の良質な情報を蓄積していく セキュリティ、コンプライアンス/法律、倫理観を向上させる 技術的なアップデート情報のキャッチアップ（これまで通り） 生身の良質な情報を蓄積していく（一番重要） AIに依頼するにも、自らが作業をするにも、 大元のオリジンである「わたし」に、良質なインプットを蓄えるのが重要 だと考えています。 物事の良し悪しや生身で感じる感情や感覚、パターン化できない複雑で曖昧なもの、インターネットには出回っていないような1次情報などなど。 こういったものが、AIには補完できない部分かなと思います。 良し悪しですが、あえて人間としての至らなさや揺らぎがかえって良い成果物や味のあるもの、人間の心に響くものが作れる のではないのかなと思っています。 セキュリティ、コンプライアンス/法律、倫理観を向上させる AIの弱みでも書きましたが、 AIは、責任を取れません 。 一方で、アウトプットの数は増えるし、作業過程の一部をAIに任せてしまうことによるリスクは増えます。 さらに、悪意のある人が、AI を使った脆弱性をついてくるリスクも高まります。 （既に、Claude Mythos（クロード・ミュトス）は、世の中の大量の脆弱性を発見できるようです） それでも、 最終的には、人が責任を取ります。 なので、これまでよりも、さらに、セキュリティやコンプライアンス・法律・倫理観の向上が必要になります。 ここは、技術者としても技術力アップと併せて必須のスキルとして、知識/経験を深めていきたいですね。 技術的なアップデート情報のキャッチアップ（これまで通り） AI で出された成果物を最終確認する人として、 アウトプットが正しいのか、パフォーマンスや保守性を考えて最適なのか、を判断するために、技術的なアップデートは必要 です。 エンジニアには当たり前かもしれませんが、引き続き、いや、これまで以上にアップデートの質を高めていくべきだと考えます。 まとめ AI および、AIエージェントの発達で、アプリケーション開発の効率が劇的に上がっているのは嬉しい反面、セキュリティリスクや人間としての立ち回りについての課題が生まれてきていると感じています。 とはいえ、 悲観しているだけでは何も現状は変わらないので、想像力を働かせ続け、AIの力は借りつつも、人たる能力を高め続けて、AI と共存して良いものを生み出し続けていきたい と思います。 今回は、あくまでサッと思い浮かんだことをまとめてみましたが、もっと広く深く考え続けられるテーマかなと思いますので、日々考え、行動を止めずにいきたいですね。

はじめに 私たちが開発している GIJILOG（社員向け会議議事録生成AIサービス）では、Teams の会議を録音・文字起こしし、議事録を自動生成する機能を提供しています。 この機能を実装するにあたり、Microsoft Graph API を使って Teams の会議データをアプリと連携させる必要がありました。 その開発の中で、Graph API まわりでいくつかハマりどころがありました。本記事ではその経験をもとに、認証フローの設計・クエリパラメータの制約・データ構造の特性という3つのテーマについて整理しています。 Graph API 固有の話だけでなく、OAuth 2.0 + PKCE の実装パターンや OData クエリの扱いは他サービスとの連携でも活かせる内容だと思うので、ぜひ参考にしてみてください。 採用方式 GIJILOG は Next.js をベースとした BFF（Backend For Frontend）構成で構築しています。ユーザーの Microsoft アカウントと連携し、アクセストークンをサーバー側で安全に管理するため、以下の認証方式を採用しました。 OAuth 2.0 Authorization Code Flow + PKCE 外部サービスの API を呼び出すためのアクセストークンをユーザー委任で取得します。 PKCE（Proof Key for Code Exchange）は、BFF 構成での認可コードフローにおいて 認可コード横取り攻撃を防ぐために推奨されているセキュリティ拡張です。 認証フロー BFF 側エンドポイントの役割 エンドポイント 役割 GET /api/{service}/authorize PKCE パラメータ生成 → 認証 URL を返す GET /api/{service}/callback state 検証 → トークン交換 → Cookie 保存 → リダイレクト GET /api/{service}/session Cookie の有無で認証状態（ authenticated: boolean ）を返す プロバイダ管理画面での事前設定 callback エンドポイントの URL は、 プロバイダの管理画面にリダイレクト URI として事前登録 しておく必要があります。 未登録の URI へのリダイレクトはプロバイダ側で拒否されてしまうので注意してください。 Microsoft Graph API の場合は Azure Portal のアプリ登録画面（認証 > リダイレクト URI）で設定できます。 環境（開発・ステージング・本番）ごとに異なる URL を使う場合は、すべての環境の URI を登録しておきましょう。 Graph API クエリパラメータ Graph API は OData クエリオプションをサポートしていますが、 エンドポイントごとにサポートされるパラメータが異なります 。 未サポートのパラメータを使うとエラーになるため、各エンドポイントの対応状況を事前に確認しておくのがおすすめです。 カレンダーイベント一覧（ GET /v1.0/me/events ） クエリパラメータ 対応 内容 $filter ✔ start/dateTime ge '...' and start/dateTime lt '...' で期間指定 $select ✔ 取得フィールドを限定 （例: id, subject, start, end, onlineMeeting, isOnlineMeeting） $orderby ✔ start/dateTime desc で開始日時の降順ソート $top ✔ 取得件数の上限指定。デフォルト10件。 1週間分を取りこぼさないよう 200件 に設定しています オンライン会議一覧（ GET /v1.0/me/onlineMeetings ） クエリパラメータ 対応 内容 $filter ✔ joinWebUrl eq '...' で会議 URL を指定して絞り込み $top ✖ このエンドポイントでは使用不可 トランスクリプト一覧（ GET /v1.0/me/onlineMeetings/{id}/transcripts ） ※トランスクリプト＝会議の文字起こしデータ クエリパラメータ 対応 内容 $filter ✔ createdDateTime ge ... で取得範囲を絞り込み $top ✔ デフォルト10件、 上限100件 。 定例会議等で同一 URL にトランスクリプトが蓄積されることを考慮して 上限値の100件に設定しています トランスクリプトコンテンツ （ GET /v1.0/me/onlineMeetings/{id}/transcripts/{id}/content ） クエリパラメータ 対応 内容 $format ✔ レスポンスの形式を指定。 text/vtt を指定することで VTT 形式のテキストを取得できます データ構造と関連 Outlook のスケジュールイベント・オンライン会議・トランスクリプトは別々のリソースとして管理されており、それぞれ異なる API エンドポイントから取得します。 関連のポイント CalendarEvent → OnlineMeeting : 直接の外部キーは存在せず、 joinUrl （CalendarEvent）と joinWebUrl （OnlineMeeting）の値が一致することで紐付きます CalendarEvent と OnlineMeeting は多対1 : 定例開催や会議の複製で作成されたイベントは同じ会議 URL を共有するため、複数の CalendarEvent が1つの OnlineMeeting を指すことがあります OnlineMeeting → Transcript は1対多 : 録音の停止・再開によって複数の Transcript が生成されます CalendarEvent と Transcript は直接紐付いていない : Transcript の特定には、CalendarEvent のスケジュール時間と Transcript の録音時間のオーバーラップで判定する必要があります 問題：トランスクリプトの特定が困難になるケース CalendarEvent から Transcript を直接たどれない構造上、Outlook 内で下図のような状況が起こり得ます。 具体的なOutlook側のスケジュールだとこんな感じです 　　← 要約データが表示される会議　　　　　　　　　　要約データが表示されない会議 →　　　　 同一の会議 URL（OnlineMeeting）を使い回している場合、スケジュール時間内に複数の Transcript が存在することがあります。この場合、どの Transcript が対象かをオーバーラップの判定だけでは一意に特定できませんでした。 対応策：ユーザーによるトランスクリプト選択 前述の問題に対する根本的な解決として、現在ユーザーが手動でトランスクリプトを選択できる機能を実装中です。 具体的には、Teams 会議の参加 URL をもとに該当する OnlineMeeting に紐付くトランスクリプトの一覧を取得し、録音日時と長さをユーザーに提示します。ユーザーは一覧から連携したいトランスクリプトを選択することで、自動判定では特定できなかったケースにも対応できるようになります。 おわりに Graph API を使った Teams 連携を実装してみて、ドキュメントだけでは見えにくい挙動がいくつかありました。クエリパラメータのエンドポイントごとの制約や、イベント・オンライン会議・トランスクリプトが疎結合な構造になっている点はその典型で、上記のような対応策も含め、実際に手を動かして初めてわかることが多いと感じました。 同様の連携を検討している方のお役に立てれば嬉しいです。

Claude Codeで仕様書を書くようになって、初稿の作成時間は劇的に短くなりました。 しかしながら、運用してみると、 リリースまでのリードタイム全体はほとんど変わっていない ことに気づきました。 今回は、「初稿は速くなったのにリードタイムが減らない」現象がなぜ起きるのか、自分の現場での観察をもとに整理してみます。 体感は爆速、でも実は遅い 正直、具体値を測っているわけではないんですが、 「仕様作成までは、爆速でおわる、仕様調整に時間がかかる」 といった実感があります。 ↓イメージ 「AIで爆速になった！」という体感はあるんですが、それは初稿フェーズの話だけだったんですよね。 AIの品質はこれからも上がっていくと思いますが、それは初稿フェーズをさらに効率化するだけ。 合意形成フェーズに手を入れない限りリードタイム全体は変わりません 。むしろ初稿が速くなるほど、合意形成の比重がボトルネックとして目立ってきます。 原因は2つあった リードタイムが減らない理由は、2つに整理できました。 ① 意思決定が二重に走るフロー構造 レビューの意思決定が二重化されていて、両方の合意を取らないと前に進めない、というやつです。 （大き目の企業あるあるですね） 多くの組織で同じはずで、純粋なエンジニアリングの速さでは削れない領域なので、今回は深追いしません。 できる限り、フィードバックから修正のループを回すことを主題として話します ② レビューフォーマットの不一致 ← 今回の本題のため大切 これが地味だけど致命的でした。 AIが書くフォーマット =  Markdow （git差分が取れて、Claude Codeが直接編集できる、AI親和的） 既存の意思決定フォーマット =  Excel （AIが直接触れない、非AI親和的） このフォーマットの違いが、二重構造をボトルネックに変えてしまっていました。 「最初のレビューはMarkdownで完結できるはず」なのに... 初期レビューだけならMarkdownで完結できるはず 、それなのに、なぜか毎回Excelに変換している運用が多い。 なぜか。答えはシンプルで、 下流のレビューフォーマットがExcelで固定されているから です。どうせ最終的にExcel化するなら最初から変換しよう、という運用が定着してしまっているんじゃないかと思います... つまり、エクセルに変換することが前提になっていること自体が、 上流のAI親和性まで殺している 構造でした。下流のフォーマットが、上流のワークフロー全体を規定してしまっています。 問題は、 ワークフローの設計  そのものにあります。 症状：Excel への片方向変換問題 このフォーマット不一致が具体的に何を引き起こすか。 「片方向変換問題のつらみ」とこの記事の中では定義しましょうか。 ↓ Markdown → Excel 片方向変換問題のつらみ  流れはこんな感じです。 Claude Codeで仕様書をMarkdownで書く 下流に渡すために、Excelに変換する Excel上で内部レビューも下流レビューも全部やる Excel上で手書きで修正する 気がつくと、Excelが事実上の最新版になっている 問題は、 Excel上の手動修正をMarkdownに戻す方法がない （あるいは超面倒）ということ。セルに書き込まれたメモを、関連セルとの整合性を取りながら構造化されたMarkdownに反映するなんて、やってられません... 結果として、 改修ループからAIが外れます 。せっかくClaude Codeで書いたmdは古いまま放置されて、次の改修サイクルも結局Excel上で手動でやることに。 つまり、AIで初稿を作るメリットが  「初稿の1回しか効かない」 構造になってしまっていたんですね。これがリードタイムを減らせない本当の理由でした。 ↓ 合意形成の時間は変わってない,,, 理想のループを定義してみる じゃあどうあるべきか。理想のループを定義してみます。 ↓ AIもレビュアーも1つループに納めたい 4ステップで完結する形です。 AIで生成・修正する ：Claude CodeでMarkdownのまま書く レビュアーにシームレスに共有する ：Excelに変換せず、Markdownのまま読める形で レビュアーがコメントを返す ：理想は直接編集も可能 AIがコメントを取り込んで反映する ：Markdownの上で完結する そして1に戻る、というループです。 ここで決定的に大事なのは、 正本はずっとMarkdown（git）であり続ける ということ。図のとおり、一度もExcelに転記しません。 この前提が崩れた瞬間に、さっきの「片方向変換問題」に戻ってしまいます。Markdownを正本として保ち続けることが、AI改修ループを生かすための必要条件です。 「これって理想論じゃないですか？」と思う方もいるかもしれませんが、実装手段はこのあと詳細を詰めていきます。 ループを実現する3つの優先度 理想のループを実現するための要件を、3つの優先度に分解してみました。 優先度1：Markdownに寄せる これは譲れない最初の制約です。 Claude Code(AIエージェント)が直接触れる形式じゃないと、改修ループにAIを組み込めない 。 逆にこれさえ満たせれば、ツールは後から選び直せます。 これを諦めると「初稿だけAI、残り全部手動」の現状から抜け出せないので、これが一番重要です。 優先度2：レビュアーにシームレスに共有 + コメントしてもらう これを満たさないと、共有のたびにExcel化が発生してしまいます。 機能要件はざっくり3つ。 MarkdownとMermaid図がきれいに表示できる ページ単位 or ブロック単位でコメントできる 理想的にはインラインコメント（行単位の指摘）も可能 ここが本記事の本丸です。 実現方法としては、 表示だけなら 、静的サイトジェネレータでいけますね。Docusaurusを使えば見た目も整います。 コメント機能 は、BackLogのAPIやMCPで自動で転記して、そこでフィードバックしてもらうことがいいでしょうか。 ※社内のセキュリティー上、IPを制限した上で、社内公開する必要や特定のSassに頼らないといけないこともあるはず 優先度3：レビュアー側が直接編集できる これが一番難しい優先度です。コメントを返してもらうだけでなく、軽い文言修正はレビュアー側で直接やってもらいたい、というケース。 満たそうとすると、 双方向 git sync (自動同期)  ができる仕組みが必要になります。Web UIで編集 → 自動でgitに反映、という流れ。 具体的にはGitBook級の有料ドキュメント管理ツールが該当します。企業単位で導入すると、月額数百ドル規模の大きさにはなってしまいますが...（  https://www.gitbook.com/  ） 全部満たさなくていい ここで大事なのは、 3つを全部満たさなくていい ということ。 1(マークダウン正本)だけで十分 → 今のGitHubで終わる（無料） 2(共有とコメント)まで必要 → 静的サイト + BackLog等に手動アップロード（低コスト） 3(双方向修正と同期)まで必要 → 有料の専用ツール（要投資） 組織の現状と必要度に応じて、どこまで満たすかを決めればOKです。すべての組織が3を目指す必要はないと思っています。 問題解決のための個人的結論 2までを綺麗に再現するとなっても、 GitHubのシームレスな連携 + コメント機能 + アクセス制限 の機能を持ったサービスはなさそうでした… 唯一対応できる、gitbookはめちゃくちゃ高いです… (小規模のチームでも、全員に権限を付与するとなると、年に数十万はかかりそうでした...) それなら実装してしまえばよいのではないか、といった気持ちにはなっています。 以前であれば、これだけでお金をとれるようなサービスだったかと思いますが、このくらいの要件ならギリギリ内製できそうですかね  ↓cluadeにデザインしてみてもらいました まとめ 今回伝えたかったこととしては、2点です。 ① ツールが現在のAIを組み込んだフローに対応できているのかを考える 現状、意思決定フローにおいて、AIの良さがなくなっている可能性があります。 あらためて、現在のプロジェクトの意思決定構造や、設計フローを見直す必要があると考えています。 また、理想を定義した上で、社内で使えるならどの課題まで改善するか、ということをあらためて考えてみると面白いかもしれません。 ② 最も守るべきは「正本がMarkdownであり続けること」 これさえ守れれば、ツールはいつでも乗り換えられます。逆にこれを諦めると、AI改修ループが切れて、初稿の速さしか享受できない世界線に戻ります。 そしてMarkdown正本化は、レビュアー側にとっても「最新版がどれか分からない」「Excelに散らばったコメントを追えない」みたいな問題が消えるので、関係者全員にとってメリットのある話だと思っています。 AI時代のドキュメント問題は、ツール選定の話ではなく、 正本のフォーマットをどう守るか、今の組織の中で、開発フローをどう設計するか を根本的に考えなすことが大切だと思いました。

はじめに：AIに 取って代わられる 恐怖よりも、エンジニアとして学ぶべきことの多さに恐怖している 4月で、エンジニアとして4年目に突入しました。まだまだ、エンジニアとして未熟だと痛感する毎日でございます。私は、プロダクト開発に関わる傍ら、AIを組織に導入したりその後の活用を推進するプロジェクトにも属していました。 プロジェクトの進行で必要な知識をつけるために、AIモデルプロバイダーが発信する知識や、LT会・カンファレンス・社外の事例の記事を調べています。その中で感じているのは、エンジニアとして学ぶべきことの多さです。AIについて調査すればするほど、取って代わられる恐怖よりも、「これからエンジニアとしてこんなに学ばないといけないのか…？」と学ぶべきことの多さに戦慄しています。 2026年4月22日（水）に Sansan株式会社Eight主催のテックリードカンファレンス に参加しました。本記事では、そこで感じたことを、それを増強するための書籍・動画で発信されている知識と組み合わせてお伝えしようと思います。 左: 和田 卓人氏(タワーズ・クエスト株式会社　取締役社長)　右: 佐藤 治夫氏(株式会社ビープラウド　代表取締役社長) なお、本記事は 4ヶ月前に書いた記事(AI時代も変わらない、ソフトウェア開発の基礎) の続きという位置付けでもあります。基礎の重要性を改めて確認し、より具体的な「ではどうするか」に踏み込んでいく内容です。 TL;DR（この記事のまとめ） 「AIに取って代わられる恐怖」や「AI爆速開発の焦り」への対応は、分からないことを放置せず基礎をコツコツ学び続けること。 AIは「簡単さ（Easy）」を極限まで高めたが、システムを「シンプル（Simple）」にしてはくれない。複雑性を切り分け制御できるのは、ドメインや技術を深く理解している人間の役割である。 「1人でAIと爆速開発」というリソース効率の罠から抜け出し、モブプログラミングや Agent Skills による「チームでの意思決定と暗黙知の言語化」へ向かう。 AIエージェントとの関わり方：物的生産性から離れ、対象物を深く理解する カンファレンスでハッとさせられたのは、和田卓人氏の「 AIによる物的生産性に血眼になっているのではないか？ 」という問いかけでした。 AIによってコードの記述スピードは劇的に上がりましたが、だからこそ「誰もいらないものを高速に作っても意味がない」状態になっています。和田氏は講演の中で、AIの登場によってプロトタイプを用いた価値の検証が容易になり、「 価値探索とプログラミングがかなり紐づいてきた 」と語っていました。コードを速く書くことではなく、対象物を深く理解し「何を作るか」を探索することに、エンジニアの主眼は移りつつあります。 この「 スピード（簡単さ）に溺れず、理解を優先する 」という姿勢の重要性は、世界的なソフトウェアエンジニアリングの潮流とも完全に一致しています。Netflix のエンジニア Jake Nations 氏による講演「 The Infinite Software Crisis 」では、次のように指摘されていました。 簡単（Easy）はシンプル（Simple）を意味しない。簡単とはシステムに素早く追加できることであり、シンプルとは自分のやった仕事を理解できることだ。簡単を選ぶたびに、私たちは「今のスピード」と引き換えに「後々の複雑さ」を選んでいる。AIは簡単さを極限まで高めたが、シンプルさを生み出すわけではない。 何を作るかを理解し設計することの難しさは、どのツールも排除できません。 また、「 Software Fundamentals Matter More Than Ever 」という講演でも、次のように語られていました。 「コードは安い」という言説は誤りである。悪いコードは今まで以上にコストが高い。変更しにくいコードベースは AI の恩恵を受けられない。 これは私が4ヶ月前に書いた記事でも触れた DORA レポートの「AI は増幅機」という主張と重なります。良いコードベースであるほど恩恵を受けやすく、悪いコードベースであるほど機能不全が拡大する。基礎の重要性は、AI 登場後にむしろ高まっています。 この点について、『ソフトウェアエンジニアガイドブック』（Gergely Orosz 著）の日本語版特別付録インタビュー（p.557）でも、次のように語られていました。 「問題は、経験の少ないエンジニアがAIに『主導権を握らせ』、AIが何をしているのか理解しないまま仕事を全部任せてみたくなるように誘惑されることです。したがって、『AIと共に学び続け、思考をAIに外注しないエンジニア』への需要は増加するものの、その供給はおそらく減少します！奇妙な時代が訪れることでしょう」 理解を放棄してAIに主導権を渡さない姿勢こそが、これからのエンジニアの価値を左右しそうです。 では、AIに主導権を渡さず、自分たちの理解を保ちながら開発するにはどうすればいいのか？  その具体的な対策として和田氏が推奨していたのが、 Test First でやる場所と、Red-Green-Refactor のように小さなサイクルで回す場所を分ける  ことでした。 エージェントに任せても良いと判断した領域では、ざっくりとした Test First で問題ない。一方で、人間がリアルタイムにレビューして品質を担保したい領域では、Diff（差分）の小さい TDD のステップを強制する方がよい。これは、人間が何千行ものファイルを一気にレビューして理解するのは現実的ではないからです。 AIの爆速な出力に流されず、人間の認知負荷を意図的に下げるために、理解できる範囲に留める仕組みとして、非常に納得感がありました。 開発速度の見直し：モブプログラミングの再評価とリソース効率の罠 AIの登場により、コーディング工程は劇的に短縮されたように感じる場面が多くなったのではないでしょうか。しかし、Tech Lead Conference 2026 でのSansan株式会社（笹川裕人氏）のセッションでも指摘されていたように、開発プロセス全体のボトルネックは「コーディング」から「レビューやテスト」へと移動しています。 かつてGitHubが普及した頃、「1人1ブランチで開発できる＝リソース効率100%」という発想が、プルリクのレビュー待ちというボトルネックを生みました。今、「コーディングエージェントをN列並列で動かす」という発想も、全く同じパターンにはまる危険性があります。 真のボトルネックは、コードを書くことではなく、人間側の判断・レビュー能力です 。 この点について、和田卓人氏は別の対談動画（ AI疲れとジュニアエンジニア育成、モブプログラミングの役割 ）で、次のように語っています。 コーディングエージェントによって、実行責任はエージェントへ、説明責任・品質保証は人間へ、という役割分担になっていく。テックリードが担っていた判断の負荷が全員に降りてきた。 AIが多様な要求に対して提案を返してくる中で、その判断を一人で全部こなすのは現実的ではありません。そこで和田氏が推奨していたのが、 モブプロの実施 です。 AI によってコード生成は十分に速くなっていたとしたら、人間はペアやモブを組む余裕があるはずです。複数人でエージェントと関わり、即時に判断していく。この判断を複数人ですることで、知識移転（教育）も行える可能性について言及していました。 そして、この「リソース効率からフロー効率への転換」と「教育」の重要性は、別の動画（ シニアのゲームに巻き込まれるな ）でも触れられています。 「AIで1日のプルリク量が何倍に」「数日で個人開発アプリを完成」という SNS 投稿に踊らされてはいけない。シニアには元々の積み上げがあるため同じ土俵では勝てない、という主張は、私としては耳が痛い話でした。 圧倒的な積み上げがあるシニアエンジニアと同じ土俵で戦おうとすれば、経験の少ないエンジニアは疲弊し、学びの機会を失います。私も、特に言われたわけではないですが、物的生産性にとらわれて、AIにコード生成させたりレビューさせて、そのまま使うみたいなことがありました。これを、意図的にやっているというより、誰からも要求されていないのに、無理して成果を出そうとしていたなと反省しています。物的生産性を多少下げてでもモブプログラミングの場にジュニアを巻き込み、「チームとしての判断力」と「教育」を両立する構造を作ることが、AI時代には不可欠ではないかと考えています。 開発プロセス：変わらないものと、Agent Skills による専門知識の言語化 AI時代になっても、チーム開発のプロセス全てがひっくり返るわけではありません。Sansan株式会社（笹川裕人氏）のセッションでも、「スクラム等のプロセスの本質（経験的に起きる課題への対処法）は変わらない」とはっきり言語化されていました。 一方で大きく変わるのは、AIという新しいメンバーへの指示の出し方です。合同会社Have Fun Tech代表の曽根武友氏は、「 AI時代における具体と抽象の往復 - 日常にチャンスがある 」というセッションの中で次のように語っていました。 AIへの指示も、結局は人間同士のコミュニケーションと同じ原理。「いい感じにして」が伝わらないのは、プロンプトの抽象度と相手（AI）の抽象度が一致していないから。 具体化には知識が必要であり、相手のドメインで話すにはそのドメインの知識が要る。 この「『いい感じに』という抽象的な指示を具体的な手順に変換するための知識」の重要性は、Anthropicの講演「 Don't Build Agents, Build Skills Instead 」でも強く主張されています。エージェントという曖昧な存在にすべてを丸投げするのではなく、特定のタスクを遂行するための「Skills（専門知識のパッケージ）」を構築すべきだというのです。 AIに的確な指示を出すための「Agent Skills」の整備は、単なるツールの設定ではありません。 チーム内の暗黙知を言語化し、共有知にしていくプロセスそのもの なのです。 国内の企業では、すでにこの「個人の暗黙知から組織の共有知へ」という取り組みが始まっています。 株式会社タイミーでは、「 Agent Harness Group 」という組織を立ち上げ、「個のAI活用」から「組織のAI駆動開発（AI-DLC）実践」へと協業を推進しています。また株式会社LayerXでは、モバイルチームで「 Claude Code Subagents祭 」と題した社内イベントを開催し、属人化しがちなAIへの指示やプロンプトをチームの共有知へと昇華させています。 私自身が推進しているAIエージェント活用においても、ここが最大のポイントになると感じました。単にAIツールを導入するだけで終わらせるのではなく、 Agent Skillsという機能を、AIというメンバーに暗黙知を伝える手段や、組織のベストプラクティスを誰もが簡単に再現できる方法として利用するための仕組みを作っていきたい と考えています。それこそが、AI時代における組織の長期的な競争力の源泉になるはずです。 学習：焦らず、理解を放置しない AIエージェントがコードを爆速で生成してくれる時代において、私たちが個人として取り組むべき最も重要なアクションは、「分からないところを放っておかない」という基本的な学習姿勢です。 Tech Lead Conference 2026でのセッションを通じて、登壇者三者の主張が見事に一致していたのが、この「継続的な学習の重要性」でした。和田卓人氏は、学習について次のように語っていました。 新人は、焦らずに学んでいく必要がある。自分がわからないところを放っておかずにやっていく必要がある。質を下げればスピードが上がるわけではない。トレードオフなのは教育である。質とスピードを担保させるために、教育することが必要になる。 曽根武友氏も、AI が発展しても変わらないこととして「 抽象と具体の往復スキル、ドメイン知識、継続的な学習 」を挙げていました。仕事の形は変われど、この往復の精度を上げることが本質である、と。 さらに、Sansan株式会社 のセッションでも、エンジニアのキャリアパスについて語られていたところで、「 仕事の総量は変わらない——AI で効率化されても別の仕事が生まれる。継続的な学習の必要性は変わらない 」という言葉がありました。この三者の主張は完全に一致しています。 『良いコード／悪いコードで学ぶ設計入門』の著者であるミノ駆動氏も、AI時代に漠然とした不安を抱えるエンジニアに対して、動画（ AI時代に“伸びる人・終わる人”の決定的な差 ）で次のように指摘しています。 漠然と不安に思っている人は、技術を学んでスキルアップすることが不安の解消に繋がっていると思えていないのではないか。不安を覚えるのなら勉強しましょう。 ミノ駆動氏は、AIは「ネット上の学習内容の平均」に収束する傾向があるため、設計的に問題のある構造でも技術知識がなければ素通りしてしまうと語っています。 AIが60〜70点のものしか出せないのは、指示する人間の基礎力（問題を見抜く力）が足りていないから でもあるのです。 また、ファインディ株式会社の高橋氏の動画（ ジュニア育成と組織学習 ）では、AI時代のエンジニア評価について、次のような組織側の変化が語られていました。 機能を何個作ったかっていうよりも、何を学んだかをアピールする時代になってきている。 これは個人の姿勢だけでなく、組織側にも問われることです。アウトプットの量だけを評価指標にすると、生成AIでいくらでも量産できてしまい、本当の力が見えなくなります。「何を学んだか」を評価し、基礎力を高め続ける仕組みを持っているかが、これからの人材育成の分かれ目になります。 最後に、和田卓人氏が別の対談動画の結びで語った、若手エンジニアに向けた言葉を引用します。 自分の能力をコツコツ上げていくことが、自分の競争力を上げていくことにそのままより大きく繋がる時代になってきたと思ってください。…（中略）… 焦らずにコツコツやっていけばいい。希望を持つ上でのコツは、人と比べないことです。比べるのは過去の自分です。 SNSを見れば、AIを使って爆速で開発している人がいくらでも目に入ります。しかし、そこで焦って理解を放棄するのではなく、自分の分からないところを放置せずにコツコツと基礎を積み上げていく。それこそが、AI時代を生き抜くための最強の生存戦略なのだと、改めて心に刻みたいと思います。 まとめ：教育とフロー効率を両立する3つの方向性 4つの観点を通じて感じたのは、ひとつの共通したメッセージでした。 AI は「理解の代替」ではなく「理解の加速器」として使う。 そのために、私たちが明日から取れる具体的なアクションは、以下の3つに整理できると考えています。 1. 物的生産性に流されず、対象への「理解」を深める姿勢と仕組み化 AIによる爆速なコード生成に流されず、「自分が理解できないもの」を放置しないことが第一歩です。分からない概念があればAIに説明させて基礎をコツコツ積み上げる「個人の学習姿勢」を持つと同時に、Test First でざっくり任せる領域と、Diffの小さいTDDのサイクルで回す領域を分け、人間の認知負荷を意図的に下げる「開発の仕組み」を取り入れること。アウトプットの量ではなく、「何を学び、どう理解したか」を重視する姿勢が問われます。 2. モブプログラミングによる判断とレビューの分散 一人がエージェントと対話して爆速で開発するリソース効率の罠から抜け出し、複数人のチームで専門性を持ち寄りながら判断するモデルへ。チームにジュニアが参加することで意思決定の OJT にもなる——教育とフロー効率の両立策として、今後試していきたい方法論です。 3. Agent Skills による組織のベストプラクティスの再現 「いい感じに」という抽象的な指示を具体的な手順に変換する Agent Skills は、単なるツールの設定ではありません。 チームのベストプラクティスを「AIという新しいメンバー」に伝える手段 として捉え直す必要があります。 実際に、株式会社タイミー では「 Agent Harness Group 」を立ち上げて AI との協業を組織的に推進していますし、株式会社LayerX では「 SubAgent 勉強会 」という知識共有の場を作っています。誰もが組織のベストプラクティスを簡単に再現できる仕組みを、社内でも作っていきたいと考えています。 おわりに AI にとってかわられる恐怖よりも、学ぶべきことの多さに恐怖している——というのは、裏返せば「学べば学ぶほど武器になる」ということでもあります。Tech Lead Conference 2026 で登壇者たちが口を揃えて言っていたのは、「 基礎知識を持つ人間がこれまで以上に価値を持つ 」ということでした。 特に4年目という、中途半端な立ち位置にいる自分にとって、和田卓人氏の「焦らずコツコツ自分の能力を上げていけば、それがそのまま競争力につながる時代になってきた」という言葉は、強い励みになりました。 焦らず、分からないところを放っておかず、基礎をコツコツ積み上げていく。その上で、AI を理解の加速器として使う。それがAI時代にエンジニアとして今後も活躍するための必要な考えかもしれません。 最後まで読んでいただきありがとうございました。

アナリティクス推進課の新井です。当課は、マイナビ全社のデータ活用/BI活用推進のため、TableauやPower BIのビジネス部門への導入支援、ツール利用サポートを行っています。 はじめに マイナビでは、BIツールの運用においてTableauを使う部門とPower BIを使う部門の両方が存在します。利用者には利用者の要望や都合があるため、アナリティクス推進課として利用するBIツールを制限していません。従って、BIツール活用の推進を行う当課としては、TableauとPower BIのどちらのツールに対しても知見を持つことが求められます。世間一般のビジネスデータ活用シーンからすると少数派の環境だと思いますが、なかなかおもしろい経験が得られます。 私がBIツールを使い始めたのはTableauが先でしたが、現在はPower BIを併用し始めてから時間も経ち、一定の知見がたまってきた感覚があります。また当社の本格的なBIツール導入もTableauの方が先でしたが、後発のPower BI利用者も増えてきており、どちらのツールに対しても導入支援や問い合わせ対応を行っています。このようにTableauとPower BIの両ツールを併用していると、Power BIを使っているときに「Tableauだったら○○の機能でできるからあっちの方が使いやすいな…」と感じたり、またその逆も起こり得ます。そこで今回は、実際に両ツールを使いながら私が感じた「UX（ユーザー体験）における大きな印象の違い」を1つご紹介します。なお本記事では、 BIツールを利用する上でのテクニックに関する話は出てきません！ （すみません） Tableauを利用したデータ加工～ビジュアライズ Tableauにおけるデータ加工はTableau Desktopでも行うことが可能ですが、複雑な加工や大規模な処理を行う場合はTableau Prep Builderを使う方が効率的です。両ツールは役割分担・住み分けが明確であり、 基本的に、データの加工はPrep、ビジュアライズはDesktopで行ってくださいというTableau（Salesforce社）からのメッセージを感じます 。 常にPrepとDesktopの両方を起動させておく必要はありませんが、状況によっては両方起動させなければならないこともあり、その場合両ツールを稼働させる分メモリも使うのでPCの動作が重いと感じることもあります。加えて「 両ツール間を行ったり来たりしなければならない 」という心理的な負荷も少し感じます（これは個人差もあると思いますが）。 以下の画面は、Prepで作成中のフローにおいて、フローの途中時点でデータがどうなっているか確認しようとしているところですが、ポップアップメニューに「Tableau Desktopでプレビュー」と表示されています。ここをクリックすると、Tableau Desktopが起動し、フローの途中時点のデータがDesktopで読み込まれた状態になります。そのままグラフ化などの検証を行うことが可能です。 ボタンなどのUIの原則として「クリック後に何が起こるか分からない曖昧な表現のテキスト、説明文を記載すべきではない」という考え方がありますが、この「Tableau Desktopでプレビュー」という記載は、クリック後に何が起きるかが分かりやすく、親切な表現であると言えます。 Power BIを利用したデータ加工～ビジュアライズ 一方、Power BIを使ってビジュアライズを行う場合、その前段階となるデータ加工はPower BI Desktop内の「データの変換」機能で行うことができます。この機能を使って大元のデータソースを読み込み、変換・加工処理を行い、Power BI内に読み込んでいきます。読み込み完了後にモデルビューで複数テーブル間のリレーションをはることもできますが、リレーションはあくまで論理結合であり、簡易的な関係性を持たせるに留まります。物理的な結合を行う場合は、「データの変換」機能の中で行うことができます。このあたりの概念は、Tableauに似ていると感じます。 …ということで、ここまで読んだ方は「Power BIはデータ加工とビジュアライズが1つのツールの中で完結するんだ」という印象を受けると思うのですが、実はこれは100％正確ではなく、「データの変換」は実は Power Queryエディターという別のツールが起動し、その中で行われます 。 以下のキャプチャのとおり、データの変換はPower BI Desktopのウィンドウ内で行われる機能ではなく、新しいウィンドウが開かれそちらで行われるもので、そのウィンドウにPower Queryエディターと明記されています。 UI/UXの違いから勝手に推察する、Microsoftの設計思想 「なんだ、じゃあ結局TableauとPower BIのどちらも、データ加工用ツールとビジュアライズ用のツールを使い分ける必要があるってことね」と思った方が多いと思います。それは正しいです。ただ私は、Microsoftには「 ユーザーにデータ加工ツールとビジュアライズツールの2つを別々に使っていると感じさせないUI/UX設計をしよう 」という狙いがあるのではないかと推察しています。 たとえば、Power BI Desktopでデータ加工をしようとしたときにクリックするのは、前述のとおり「データの変換」ボタンです。これはオリジナルである英語版も同様の表現で、「Transform Data」となっています。 日本版 英語版 UIの原則を考えると、この部分のテキストは前述のTableauパートで挙げた例のように「Power Queryでデータを変換する」であってもいいはずで、多少冗長ですがPower Queryエディターが起動することを教えてあげた方が親切であるとも考えられます。他社製品ではないのだから製品名を伏せる必要もありません。ただ、あえてなのかそうでないのかは分かりませんが、Power BIのUIはそのようになっていません。 加えて、Power BIで利用する目的でPower Queryエディターを起動するときの導線は、Power BI Desktopの「データの変換」ボタンであり、単体で起動することはありません。Tableauにおいては、プレビュー目的でTableau PrepからTableau Desktopを起動することもできますが、基本的にはPCのメニューや保存したワークブック/フローのファイルからTableau Desktop、Prepを個別に起動することが多く、両ツールを併用している感覚が強いです。 Power Queryエディターの起動導線がPower BI Desktop内にあることは、Power QueryがPower BI内の一機能であるかのように感じさせることにつながり、両ツールをシームレスに扱える印象を強めていると感じます 。 またそもそもの話ですが、Power QueryエディターはツールとしてはPower BIとは別であるものの、Power BIをインストールするときに同時にインストールされます。ユーザーに後から追加でインストールさせる選択肢をはじめから用意しておらず、ユーザーからすると 別のツールがインストールされたということすら気づきません 。 おわりに 本記事で書いたとおり、TableauもPower BIも、データ加工ツールとビジュアライズツールの2つを起動し使い分けているということに変わりはありません。記事に書いたことをもって両ツールに優劣をつける意図もありませんし、こんないち側面だけをもって優劣をつけることは不可能です。 ただ、UI/UX面では両ツールに大きな違いが垣間見え、その結果私個人が受けた印象も大きく異なっているのは、とても興味深いと感じています。プロダクトのUI/UX設計って大事だなと思いました。 とはいえ、何も考えずに適当な表現を当てただけという可能性も十分にありえますけどね…。真相は一体…！！

法人ディベロップメント課のS.Sです。 マイナビBiz / LIVING の新規開発・保守運用を行なっております。 この記事では、現在、私が関わっている、とあるPJ で、Techtus さまとの協業（オフショア開発）により、PJ を進める中での経験や気づきについて、ご共有できればと思います。（※ PJ は、現在進行中です） オフショア開発事情について気になる オフショア開発の難しい点や良い点について知りたい 経験を踏まえて、次回オフショア開発を進めるならどうしたいか という方には、お力添えになれる記事かと思います。 参照: Techtus とは オフショア開発の3つの良さ １、開発速度が本当に早い！ 協業で開発を進めて頂いた Techtus さまの開発チームの開発速度は非常に早く、こちら側で元々想定していたスケジュールから、1ヶ月以上巻きで進めてもらうことができました。 今回、実装して頂いた開発者は、2名体制でしたが、2画面/日ペースでPR レビュー依頼が届き、レビューコメントへの対応も基本的に 即時返信・対応で、滞りなくスムーズに進んだ 印象でした。 ２、にも書いていますが、 技術的なレベルも高く、技術的な詰まりなども、ほぼなく進めて頂けたのも開発速度が早い 理由なのかなと思っております。 ２、開発チームの技術力が高い！ 本PJでは、Next.js（v15） による開発を進めているのですが、新しい機能活用、技術/SEO提案などが、頻繁に飛び交いながら、PJ が進んでおります。 迅速に、依頼画面を作って頂くだけに止まらずに、 積極的に技術的な付加価値を提供頂き、ともにブラッシュアップして開発を進めていけた のも非常に感謝でした。 ３、言語の壁なく、素早く問題解決が進められるスムーズな連携！ オフショア開発をする、となった時に最初に思い浮かんだのが言語の壁でした。 しかし、Techtus さまでは、 コミュニケーター（マイナビと Techtus エンジニア間で日本語 / ベトナム語 でやり取りしてくださる人）がいるため、言葉の壁を感じず、いつもの開発のように進めることができました。 また、コードレビュー時には、お互いに英語でのやり取りが可能でしたので、ここも言葉で悩むことなくスムーズに進められた印象でした。 私自身、英語力に関しては簡単な英語の読解ができるくらいのレベルで伝えることには不安がありましたが、今は Google 翻訳があるので、そんなツールも活用しつつ、特にストレスなく対応できました。 やり取りを進めていく内に自然と、Google 翻訳に頼る頻度は減っていくので、さらにスムーズになった印象でした。 （副次的なものですが、初見PRレビュータイミングでは、訳さずに読解することで、英語力が少し上がるのもよかったです。（次は、ベトナム語にもチャレンジしてみたいな。）） オフショア開発で工夫した3つの点 １、ファーストレスポンスを最速で行う オフショア開発では、開発している場所・時間が物理的に違います。 そのため、お互いに相手方の状況が見えません。 したがって、 分からない状態での「待ち」が相当なストレスを生み、開発パフォーマンスに悪影響を与えてしまいます。 なので、普段の開発よりも増して、ファーストレスポンス速度を早めるように意識しました。 これによって、お互いに、分からない状態での「待ち」を作らないことで、互いにノンストレスかつ、滞り少なくトントンと開発を進めることができたのかなと思います。 ２、前提を含めた丁寧な説明 オフショア開発では、相手方は、初めて向き合うサービスであることがほとんどです。 自分たちが思っている当たり前や前提がほぼ 0 のため、なるべく丁寧に、前提説明をする ように努めました。 開発を進める中での質問やレビュー時には、 「こうこう、こういう理由で、こんな実装してほしい」 などを 具体的かつ論理的に伝えることで、納得感を持って開発を進めてもらえた のかなと思います。 ※ ここは、工夫した点でも、あり改善余地ありの点でもあるので、そちらに記載します ３、視覚的情報（+数値）を用いた意思共有 言葉の壁はありませんでしたが、開発文化やニュアンス、表現、受け止め方の違いは、あったかなと感じました。 そんな違いを問題にしないために、視覚的情報を用いるように工夫しました。 この手法を用いることで、 見たそのもの、そのままは、どこの誰が見ても基本的には同じように捉えることができます。 数字についても同様です。 なので、視覚的情報と、数値を用いることで、認識ズレを減らせたのかなと思います。 言葉のみの場合： タイトル: タイトルの位置を気持ち下げて、全体としていい感じに中央っぽく見えるようにしてください。 メール欄 メールの入力欄は、今より少し大きめにして、押しやすそうな印象に寄せてください。 パス欄 パスワードの入力欄も、メール欄と同じくらいのサイズ感に整えてください。 ボタン ボタンは角をもう少し丸くして、入力欄との間隔もちょっと広めに調整してください。 視覚的情報を用いた場合： 圧倒的に、後者の方がズレなく伝わることが体感できます。 オフショア開発で苦労した3つの点 １、仕様を認識ズレなく理解してもらうこと 先ほどの工夫の箇所でも書きましたが、 前提や背景知識が違うので、こちら側の当たり前は、相手方の当たり前ではなかった です。 特に、開発初期は、レビュータイミングで、認識がズレていたり、こちら側で当たり前としてしまっていたことが、相手方の当たり前ではないことでやり直しが発生してしまうこともありました。 早めに気づいて改善することで軌道修正はできましたが、当初は苦労しました。 ２、開発環境の共有 完全な自チームの場合であれば、AWSを含む各種アカウントの共有がなされている、かつ物理的に近い距離で開発ができ、環境共有に困ることは、ほぼありません。 しかし、 オフショア開発の場合は、各種アカウントの全てではなく、必要なものかつ、共有できるものが限られる中で対応を進めていく 必要がありました。 そのため、開発の進め始めに、あちらの local では動いているが、こちらの local では動かない、というようなタイミングがありました。（Github, Docker 利用をしていたのでベースの共有化はできてはいるものの。。） ３、開発手法や進め方の足並みを揃えること 当初、開発文化が異なるチーム同士で開発を進める中で、 どんな手法を用いて どんな粒度で どんなルールでやっていくか という所の認識合わせが困難でした。 事前に、キックオフ会の実施や、ドキュメントを作成して、足並みが揃うよう努めましたが、やはり、前提や背景、文化が違うもの同士で協業をするというのもあり、 「あ、この観点や考え方もドキュメントに追加しないとな」 というものがボロボロと出てきた印象がありました。 PJ を進める業務を行いつつ、こういった基礎の部分を同時修正していくことに苦労 しました。（もっと早めの段階の問題出しが重要だなと） ただし、ここを軌道修正したことで、様子見やすれ違い頻度も減り、スムーズにPJ が進むようになった印象がありました。 次回、オフショア開発をする時に、気をつけたい3つのポイント 最後に、ここまでの経験を踏まえて、次回、オフショア開発を進める際に、気をつけたいポイントをまとめたいと思います。 １、最初に、開発手法や進め方・ドメイン知識の共有の時間をしっかり取る 今回は、キックオフ（全体のスケジュール感や対応範囲の認識合わせ）に加えて、開発者向けドキュメントを作成し、共有することで、最初の認識合わせを終えました。 しかし、これでは、軌道修正タイミングが遅れてしまうなと反省しています。 最初に、 開発者の認識合わせの時間をしっかりと確保し、その中でこちら側、あちら側のそれぞれの認識を理解しあって、足りないものに気づき補うことで、開発スタートとともに素早くスタートダッシュを切れるようになる と思いました。 早めに問題を浮き彫りにした方が、全体として効率・改善速度は早められますからね。 ２、スプリント単位での依頼チケットの丁寧な概要説明と時間の確保 スプリント単位ごとに、チケット依頼タイミングに、概要説明の時間をしっかりと確保し、認識合わせを密にしていきたい です。 このようなやり方は、一見、工数がかかってしまうように感じてしまいますが、これにより、手戻りやスムーズなレビュー・マージができるようになるかと思いました。 チケット内容に、概要記載が前提なので、ある程度打ち合わせを繰り返す中で、OKなものはサクサク進めていけます。 そのため、 最初の最初は、工数かかる体感はあるかもしれないですが、段々とその負荷は減り、認識ズレもなくなるので、全体で見たら、最適な進め方 なのかなと思います。 このようなイメージです。 ３、検証環境の対応順序を早めにする 上記の通りですが、次回以降は、local でベースの環境構築ができたら、すぐに、検証環境の準備を進めていくようにしたいです。 デジ戦側・Techtus 側・事業部側が、共通して同じ環境で確認ができる検証環境を先んじて作っておくことで、同じ目線で動作確認や修正を前倒しで進めていくことができるため です。 検証環境の構築は、インフラメンバーへ構築依頼が必要になるため、始めにそう決めておかないといけない部分だと思っており（いきなり依頼は物理的に難しい）、次回、スケジューリングを立てるタイミングで必須で早めの設定と依頼を進めていきたいと思いました。 最後に ここまで、振り返ってみて感じたことの一言でまとめると、 共通認識を早めに、丁寧に、細かくアクションを取ることが重要 ということかなと思いました。 オフショア開発に限らずですが、より文化や背景、物理的な距離、ドメイン知識の違いなどがどうしてもある中で、 早め早めに、「共通認識」を持つ機会を能動的に作っていくことで、そのズレを無くし、スムーズなPJ 進行ができる のかなと思います。 こうして、文章で書いているとすごく当たり前ではあると思うのですが、 当たり前だからこそ、いざやるタイミングで抜けてしまいがち なので、未来の自分が新PJ スタートタイミングでこの記事を見て、戒めようと思います。

はじめに AWS CDK（Cloud Development Kit）を使って、異なるAWSアカウント間（クロスアカウント）でリソースをデプロイする方法を解説します。 対象読者 ：AWSちょっとわかるレベル 所要時間 ：約60〜90分 実行環境 ：Windows PowerShell このハンズオンで学べること CDKプロジェクトの初期化とスタック構成 cdk bootstrap  の仕組みと役割 クロスアカウントデプロイに必要なIAM設定 --cloudformation-execution-policies  による最小権限の実現 cdk destroy  を使ったリソースの後片付け アカウント構成 本ハンズオンでは2つのAWSアカウントを使用します。 事前準備 必要なツール Node.js（v18以上推奨） AWS CDK CLI（ npm install -g aws-cdk ） AWS CLI v2 PowerShell AWSプロファイルの設定 本ハンズオンでは以下の2つのプロファイルを使用します。 プロファイル名 対象アカウント 用途 test-111111111111 アカウントA（111111111111） デプロイ先の操作 test-A アカウントB（222222222222）のIAMユーザー CDKデプロイの実行元 ~/.aws/credentials  および  ~/.aws/config  に各プロファイルを設定しておいてください。 Step 1：CDKプロジェクトの作成 プロジェクトディレクトリの作成 mkdir C:\github\cdk-cross mkdir C:\github\cdk - cross cd C:\github\cdk-cross cd C:\github\cdk - cross CDKアプリの初期化 cdk init app --language typescript cdk init app -- language typescript 実行すると以下のようなプロジェクト構成が生成されます。 cdk-cross/├── bin/│ └── cdk-cross.ts # エントリーポイント├── lib/│ └── cdk-cross-stack.ts # スタック定義├── cdk.json # CDK設定ファイル└── package.json cdk-cross/ ├── bin/ │ └── cdk-cross.ts # エントリーポイント ├── lib/ │ └── cdk-cross-stack.ts # スタック定義 ├── cdk.json # CDK設定ファイル └── package.json Note ： git config  の設定がない場合、 Unable to initialize git repository  という警告が出ますが、ハンズオンの進行には影響ありません。 Step 2：スタックの実装 エントリーポイントの編集 bin/cdk-cross.ts  を以下のように編集します。デプロイ先のアカウントIDとリージョンを明示的に指定します。 import * as cdk from 'aws-cdk-lib';import { CdkCrossStack } from '../lib/cdk-cross-stack';const app = new cdk.App();new CdkCrossStack(app, 'CdkCrossStack', { env: { account: "111111111111", <em>// デプロイ先アカウントA</em> region: "ap-northeast-1" }}); import * as cdk from ' aws-cdk-lib ' ; import { CdkCrossStack } from ' ../lib/cdk-cross-stack ' ; const app = new cdk . App () ; new CdkCrossStack ( app , ' CdkCrossStack ' , { env : { account : " 111111111111 " , <em> // デプロイ先アカウントA</em> region : " ap-northeast-1 " } } ) ; ポイント ：クロスアカウントデプロイでは  env  の  account  と  region  を 必ず明示 する必要があります。省略すると CDK が環境を解決できずエラーになります。 スタック定義の編集 lib/cdk-cross-stack.ts  を以下のように編集します。今回はシンプルなS3バケットを1つ作成します。 import * as cdk from 'aws-cdk-lib';import { Bucket } from 'aws-cdk-lib/aws-s3';export class CdkCrossStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); new Bucket(this, 'TestBucket', { removalPolicy: cdk.RemovalPolicy.DESTROY, autoDeleteObjects: true }); }} import * as cdk from ' aws-cdk-lib ' ; import { Bucket } from ' aws-cdk-lib/aws-s3 ' ; export class CdkCrossStack extends cdk . Stack { constructor ( scope : Construct , id : string , props ?: cdk . StackProps ) { super ( scope , id , props ) ; new Bucket ( this , ' TestBucket ' , { removalPolicy : cdk . RemovalPolicy . DESTROY , autoDeleteObjects : true } ) ; } } removalPolicy: DESTROY ： cdk destroy  実行時にバケットを削除する設定 autoDeleteObjects: true ：バケット内にオブジェクトが残っていても削除できるようにする設定（ハンズオン向けの設定です。本番環境では慎重に検討してください） CloudFormationテンプレートの確認 実際にデプロイする前に、CDKが生成するCloudFormationテンプレートを確認しましょう。 cdk synth cdk synth S3バケット・バケットポリシー・Lambda関数（autoDeleteObjects用）・IAMロールが出力されれば成功です。 Step 3：bootstrap（1回目） bootstrapとは CDKでデプロイを行うには、事前に対象アカウント・リージョンに CDKToolkit というCloudFormationスタックを作成する必要があります。これを  cdk bootstrap  と呼びます。 bootstrapのメリット デプロイの自動化 ：アセット（Lambda ZIPやDockerイメージ）のアップロード先（S3・ECR）が自動で用意されるため、手動でバケットやリポジトリを作成する必要がない IAMロールの一元管理 ：デプロイに必要なIAMロールがまとめて作成・管理されるため、個別にロールを設定する手間が省ける クロスアカウント対応 ： --trust  オプションで他アカウントからのデプロイを安全に許可できる 権限の最小化 ： --cloudformation-execution-policies  でCloudFormationが使う権限を絞り込める 冪等性 （何度実行しても同じ結果になる性質）：すでにbootstrap済みの環境に再実行しても、差分のみUpdateとして適用されるため安全に再実行できる bootstrapはアカウントとリージョンに紐づく bootstrapは  「AWSアカウント × リージョン」の組み合わせごとに1回実行 する必要があります。 アカウントAの  ap-northeast-1  にデプロイ →  aws://111111111111/ap-northeast-1  にbootstrap アカウントAの  us-east-1  にもデプロイしたい →  aws://111111111111/us-east-1  に 別途 bootstrap アカウントBの  ap-northeast-1  にもデプロイしたい →  aws://222222222222/ap-northeast-1  に 別途 bootstrap 同じアカウントでも リージョンが異なれば別のbootstrapが必要 です。 bootstrapで作成されるリソース bootstrapによって以下のリソースが作成されます。 S3バケット （StagingBucket）：デプロイ用アセットの保存場所 ECRリポジトリ ：Dockerイメージのアセット保存場所 IAMロール群 ：CDKがデプロイ操作を行うための各種ロール DeploymentActionRole ：デプロイ操作を担うロール CloudFormationExecutionRole ：CloudFormationがリソースを作成する際に使うロール FilePublishingRole  /  ImagePublishingRole ：アセットをS3/ECRにアップロードするロール LookupRole ：コンテキスト情報の参照に使うロール 組織のIAMポリシー制限がある場合 組織（AWS Organizations）のSCP（Service Control Policy）やセキュリティポリシーによって、 各種リソースの作成が制限されている環境 では、bootstrapをそのまま実行できないケースがあります。 その場合は以下のいずれかの対応を取ります。 既存のbootstrap済み環境を使う ：組織の管理者がすでにCDKToolkitをセットアップしている場合は、そのまま利用する（追加のbootstrapは不要） 別途ロールを手動作成して利用する ：セキュリティチームが承認した最小権限のIAMロールを事前に作成し、 --role-arn  オプションでCDKに指定する cdk deploy ` --role-arn arn:aws:iam::111111111111:role/MyCustomDeployRole ` --profile test-111111111111 cdk deploy ` -- role - arn arn:aws:iam:: 111111111111 :role / MyCustomDeployRole ` -- profile test-111111111111 アカウントAにbootstrapを実行（1回目） 確認ポイント ：デプロイ先アカウントにすでに  CDKToolkit  という名前のCloudFormationスタックが存在する場合は、bootstrapは 実行済み です。その場合は本Stepをスキップしてください。 まずはシンプルにアカウントAへbootstrapします。 cdk bootstrap aws://111111111111/ap-northeast-1 ` --profile test-111111111111 cdk bootstrap aws: // 111111111111 / ap - northeast - 1 ` -- profile test-111111111111 成功すると  ✅ Environment aws://111111111111/ap-northeast-1 bootstrapped.  と表示されます。 Step 4：アカウントAへのデプロイ（同一アカウント） まず、アカウントAのプロファイルで直接デプロイできることを確認します。 cdk deploy --profile test-111111111111 cdk deploy -- profile test-111111111111 IAMの変更内容が表示されるので確認し、 y  を入力します。 Do you wish to deploy these changes (y/n)? y Do you wish to deploy these changes ( y / n ) ? y ✅ CdkCrossStack  と表示されればデプロイ成功です。 Step 5：クロスアカウントデプロイの試行（失敗） 次に、アカウントB（ test-A  プロファイル）からデプロイを試みます。 cdk deploy --profile test-A cdk deploy -- profile test-A 以下のエラーが発生します。 Could not assume role in target account using current credentials(which are for account 222222222222)User: arn:aws:iam::222222222222:user/test1 is not authorized to perform:sts:AssumeRole on resource:arn:aws:iam::111111111111:role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1 Could not assume role in target account using current credentials ( which are for account 222222222222 ) User: arn:aws:iam:: 222222222222 :user / test1 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam:: 111111111111 :role / cdk - hnb659fds - deploy-role - 111111111111 - ap - northeast - 1 Note ：エラーメッセージ中の  cdk-hnb659fds  はCDK bootstrapが生成するデフォルトの qualifier（識別子） です。 cdk bootstrap --qualifier <任意の値>  で変更可能なため、組織の設定によっては異なる文字列になる場合があります。 本ハンズオンではデフォルト値（ hnb659fds ）を使用します。 なぜ失敗するのか CDKのクロスアカウントデプロイでは、操作元アカウントBのユーザーが、デプロイ先アカウントAの  DeploymentActionRole  を  AssumeRole（一時的に引き受ける）  することでデプロイを行います。 しかし現時点では、 アカウントAの  DeploymentActionRole  がアカウントBからのAssumeRoleを 許可していない アカウントBの  test1  ユーザーが  sts:AssumeRole  を実行する 権限を持っていない この2つを解決する必要があります。 Step 6：最小権限ポリシーの作成 --cloudformation-execution-policies  とは cdk bootstrap  の  --cloudformation-execution-policies  オプションは、 CloudFormationがリソースを作成・更新・削除する際に使用するIAMポリシー を指定するものです。 デフォルト（AdministratorAccess）の問題点 指定しない場合は  AdministratorAccess （全権限）が使われます。これには以下のリスクがあります。 CDKスタックのコードに誤りがあった場合、 意図しないリソースを削除・変更 してしまう可能性がある 最小権限の原則（Principle of Least Privilege）に反する 組織のセキュリティポリシーに違反するケースがある 最小権限ポリシーを使うべき理由 CloudFormationが操作できるリソースを スタックで必要なものだけ に限定できる 万が一のミスや不正アクセス時の 被害範囲を最小化 できる 組織のコンプライアンス要件を満たしやすくなる 今回のスタックで必要な権限は以下の3つです。 S3 ：バケットの作成・削除・ポリシー設定 IAM ：Lambda実行ロールの作成・削除・ポリシーアタッチ Lambda ：autoDeleteObjects用Lambda関数の作成・削除 ポリシーJSONの作成 @"{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:PassRole", "iam:CreateRole", "iam:DeleteRole", "iam:AttachRolePolicy", "iam:DetachRolePolicy" ], "Resource": "*" }, { "Effect": "Allow", "Action": ["lambda:*"], "Resource": "*" } ]}"@ | Set-Content cdk-minimal-policy.json @ " { " Version " : " 2012-10-17 " , " Statement " : [ { " Effect " : " Allow " , " Action " : [ " s 3 :* " ], " Resource " : " * " }, { " Effect " : " Allow " , " Action " : [ " iam:PassRole " , " iam:CreateRole " , " iam:DeleteRole " , " iam:AttachRolePolicy " , " iam:DetachRolePolicy " ], " Resource " : " * " }, { " Effect " : " Allow " , " Action " : [ " lambda:* " ], " Resource " : " * " } ] } " @ | Set-Content cdk-minimal-policy.json ポリシーをアカウントAに作成 aws iam create-policy ` --policy-name CdkMinimalPolicy ` --policy-document file://cdk-minimal-policy.json ` --profile test-111111111111 aws iam create - policy ` -- policy - name CdkMinimalPolicy ` -- policy - document file: // cdk - minimal - policy.json ` -- profile test-111111111111 作成されたポリシーのARN（ arn:aws:iam::111111111111:policy/CdkMinimalPolicy ）を控えておきます。 Step 7：bootstrap（2回目）―クロスアカウント対応 なぜ2回bootstrapするのか 1回目のbootstrapは「CDKToolkitを作成する」ための最低限の実行でした。この時点では： --trust  未指定 → アカウントBからのAssumeRoleが 許可されていない --cloudformation-execution-policies  未指定 →  AdministratorAccess  が使われている 2回目のbootstrapでは、これらを正しく設定し直します。CDKToolkitスタックは Updateとして適用 されるため、既存リソースを削除せずに設定を変更できます。 Tips ：最初からクロスアカウントデプロイを想定している場合は、1回目のbootstrapから  --trust  と  --cloudformation-execution-policies  を指定することで、2回に分ける必要はありません。 クロスアカウント対応のbootstrapを実行 cdk bootstrap aws://111111111111/ap-northeast-1 ` --profile test-111111111111 ` --trust 222222222222 ` --cloudformation-execution-policies arn:aws:iam::111111111111:policy/CdkMinimalPolicy cdk bootstrap aws: // 111111111111 / ap - northeast - 1 ` -- profile test-111111111111 ` -- trust 222222222222 ` -- cloudformation - execution - policies arn:aws:iam:: 111111111111 :policy / CdkMinimalPolicy 各オプションの意味： オプション 意味 --trust 222222222222 アカウントB（222222222222）からのAssumeRoleを許可する --cloudformation-execution-policies CloudFormationが使うIAMポリシーをAdministratorAccessから最小権限に変更する ✅ Environment aws://111111111111/ap-northeast-1 bootstrapped.  と表示されれば成功です。 補足 ：bootstrap再実行によって  CloudFormationExecutionRole  に紐づくポリシーが  AdministratorAccess  から  CdkMinimalPolicy  に切り替わります。 ただし、Step 4でデプロイ済みの  CdkCrossStack  に対して新ポリシーが適用されるのは、 次回  cdk deploy  を実行したタイミング です。 既存スタックのリソース自体はそのまま維持されます。 DeploymentActionRoleの信頼ポリシーを確認 bootstrap後、 DeploymentActionRole  の信頼ポリシーにアカウントBが追加されていることを確認します。 aws iam get-role ` --role-name cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1 ` --query "Role.AssumeRolePolicyDocument" ` --profile test-111111111111 ` --no-cli-pager aws iam get-role ` -- role - name cdk - hnb659fds - deploy-role - 111111111111 - ap - northeast - 1 ` -- query " Role.AssumeRolePolicyDocument " ` -- profile test-111111111111 ` -- no - cli - pager レスポンスにアカウントB（ arn:aws:iam::222222222222:root ）の  sts:AssumeRole  が含まれていれば正しく設定されています。 Step 8：アカウントBのIAMユーザーにAssumeRole権限を付与 アカウントAのロールを引き受けられるようになりましたが、アカウントBの  test1  ユーザー自身にも  sts:AssumeRole  の権限が必要です。 インラインポリシーのJSONを作成 @"{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111111111111:role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1" } ]}"@ | Set-Content assume-role.json @ " { " Version " : " 2012-10-17 " , " Statement " : [ { " Effect " : " Allow " , " Action " : " sts:AssumeRole " , " Resource " : " arn:aws:iam:: 111111111111 :role/cdk-hnb 659 fds-deploy-role -111111111111 -ap-northeast -1 " } ] } " @ | Set-Content assume-role.json test1ユーザーにポリシーをアタッチ aws iam put-user-policy ` --user-name test1 ` --policy-name AllowAssumeCdkDeployRole ` --policy-document file://assume-role.json ` --profile test-A aws iam put - user - policy ` -- user - name test1 ` -- policy - name AllowAssumeCdkDeployRole ` -- policy - document file: // assume - role.json ` -- profile test-A Step 9：AssumeRoleの動作確認 デプロイ前に、実際にAssumeRoleが成功するかを確認します。 aws sts assume-role ` --role-arn arn:aws:iam::111111111111:role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1 ` --role-session-name test ` --profile test-A aws sts assume - role ` -- role - arn arn:aws:iam:: 111111111111 :role / cdk - hnb659fds - deploy-role - 111111111111 - ap - northeast - 1 ` -- role - session - name test ` -- profile test-A 以下のように一時クレデンシャルが返れば成功です。 { "Credentials": { "AccessKeyId": "ASIAXXXXXXXXXXXXXXXX", "SecretAccessKey": "****", "SessionToken": "****", "Expiration": "2026-03-24T19:05:06+00:00" }, "AssumedRoleUser": { "AssumedRoleId": "AROAXXXXXXXXXXXXXXXXX:test", "Arn": "arn:aws:sts::111111111111:assumed-role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1/test" }} { " Credentials " : { " AccessKeyId " : " ASIAXXXXXXXXXXXXXXXX " , " SecretAccessKey " : " **** " , " SessionToken " : " **** " , " Expiration " : " 2026-03-24T19:05:06+00:00 " }, " AssumedRoleUser " : { " AssumedRoleId " : " AROAXXXXXXXXXXXXXXXXX:test " , " Arn " : " arn:aws:sts::111111111111:assumed-role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1/test " } } Step 10：クロスアカウントデプロイの実行 再度アカウントBからアカウントAへのクロスアカウントデプロイを実行します。 cdk deploy --profile test-A cdk deploy -- profile test-A ✅ CdkCrossStack (no changes)  と表示されれば成功です。（Step 4で既にデプロイ済みのため変更なしと表示されます） Step 11：後片付け [!WARNING] この手順は  本ハンズオン用に作成した検証環境を前提 としています。 業務システムや他の CDK プロジェクトでも同一アカウント・リージョンで CDK を利用している場合、以下の操作を実行すると 他のスタックやデプロイ処理に影響を与える可能性 があります。 cdk destroy  によるリソース削除 CDKToolkit スタック（bootstrap 環境）の削除 IAM ユーザー／ポリシー／アクセスキーの削除 検証環境以外で実施する場合は、 削除対象が本ハンズオンで作成したものに限定されていること を 事前に十分確認したうえで実行してください。 スタックの削除 クロスアカウント操作の確認ができたら、作成したリソースを削除します。 cdk destroy --profile test-A cdk destroy -- profile test-A Are you sure you want to delete: CdkCrossStack (y/n)?  に  y  を入力します。 ✅ CdkCrossStack: destroyed  と表示されれば削除完了です。 スタックが削除されたことを確認 aws cloudformation describe-stacks ` --stack-name CdkCrossStack ` --profile test-111111111111 aws cloudformation describe - stacks ` -- stack - name CdkCrossStack ` -- profile test-111111111111 Stack with id CdkCrossStack does not exist  というエラーが返れば正しく削除されています。 CDKToolkitスタックの削除 aws cloudformation delete-stack ` --stack-name CDKToolkit ` --profile test-111111111111 aws cloudformation delete - stack ` -- stack - name CDKToolkit ` -- profile test-111111111111 test1ユーザーのインラインポリシーを削除 aws iam delete-user-policy ` --user-name test1 ` --policy-name AllowAssumeCdkDeployRole ` --profile test-A aws iam delete - user - policy ` -- user - name test1 ` -- policy - name AllowAssumeCdkDeployRole ` -- profile test-A test1ユーザーのアクセスキーを削除 まずキーIDを確認します。 aws iam list-access-keys --user-name test1 --profile test-A aws iam list - access - keys -- user - name test1 -- profile test-A 確認したキーIDを指定して削除します。 aws iam delete-access-key ` --user-name test1 ` --access-key-id AKIAXXXXXXXXXXXXXXXX ` --profile test-A aws iam delete - access - key ` -- user - name test1 ` -- access - key - id AKIAXXXXXXXXXXXXXXXX ` -- profile test-A AWSプロファイルの削除 エディタで  test-111111111111  および  test-A  のセクションを削除して保存します。 削除後のプロファイル確認 aws configure list-profiles aws configure list - profiles 削除したプロファイルが表示されなければ完了です。 まとめ cdk bootstrap  は アカウントとリージョンの組み合わせごと に実行が必要 すでにbootstrap済みの環境では 再実行不要 。既存のCDKToolkitをそのまま利用する 組織のIAMポリシー制限がある場合は、 別途ロールを手動作成 して  --role-arn  で指定する cdk bootstrap --trust  でデプロイ先アカウントが操作元アカウントを 信頼する 設定を行う --cloudformation-execution-policies  で  AdministratorAccess を避け最小権限 を使う 操作元アカウントのIAMユーザーにも  sts:AssumeRole  権限 が必要 bin/*.ts  の  env.account  は 必ず明示的に指定 する 参考資料 AWS CDK ブートストラップ AWS CDK で使用する環境をブートストラップする

はじめに 普段の業務で、TypeScript, Ruby, PHPを使ってアプリケーション開発をしているY.Mです。 携わっているプロジェクトの保守運用を行なっていく中で、AWS側でパフォーマンス向上や負荷対策などを検討する機会も増えてきて、これを機にAWSサービスを包括的に学習できるSAA-C03試験を受けようと思いました。 昨日、AWS SAA-C03試験（ソリューションアーキテクト試験）を受験してきました！ 当日中に結果が返ってきて無事合格していました。 結果は 1,000点中  773点 （720点以上で合格） でした。 すごい余裕合格！ってわけではなく、残り2週間ぐらいで点数をグンと伸ばしてなんとか合格って感じだったので、そのプロセスを共有できればと思います。 試験形式 65問 130分（うち50問が採点対象） 択一問題・複数選択問題（記述問題はなし） 720点以上で合格（1,000点満点） 出題される65問のうち、50問が採点対象で15問がダミー問題ってのが他の試験と特色が違いますよね...w 【得点率40%スタート】試験4週間前（試験前時点） 当時の自分の実力 基本サービスの図解でのイメージを理解している状態（参考URLは こちら  ） 実務では、CloudWatch, CI/CD自動化, System Managerなどシステムの保守運用で触れている状態（自らの構築・設計経験はなし） 結果 Udemyの  SAA-C03版模擬試験①  を使って、最初の実力を計測しました。 感触 勉強する前は、実務で保守運用で使う数サービスを触っているだけで、自らのアーキテクチャの設計・構築はほとんどありませんでした（ハンズオンでちょっとだけ構築した経験あるくらい）。 その状態でどのくらいで取れるかな〜って受けたら、 そもそも知らないAWSサービス多すぎ（AWS SageMaker, EFS, Direct Connect...） 漠然と知っていて中身を知らないサービスも多すぎ（VPCエンドポイント, セキュリティグループの設定方法） 知っているサービスも深すぎ（S3のストレージタイプ多すぎ） って感じで、得点率が  41%  と合格には程遠いなあと遠い目になりました。 ググって他の受験者の体験記を参考にしてみて、3〜4週間後に、 得点率80%（800点）  を目指そうと目標を立てました。 【絶望の44%】試験3週間前（参考書1冊走破時点） 使用教材 AWS認定資格試験テキスト　AWS認定ソリューションアーキテクト - アソシエイト　改訂第3版 (ＡＷＳ認定資格試験テキスト) 学習内容 教材に載っているのAWSサービスをイメージで暗記（ こちら  の拡張版イメージ） S3, EC2などの頻出そうな単語は特徴まで暗記 結果 Udemyの  SAA-C03版模擬試験②  を使って、模擬試験を受けてみました。 感触 大体1週間くらいで参考書を1周しました。 勉強前時点よりもほとんど伸びてなくて、嘘だろ...と思いました。得点率まさかの 44% .... 一通り頻出で出るサービスは抑えたはずなので、大体60%は取れているだろう...とは思ったんですが、とんでもない過信をしていたようです。他の同様の試験も受けてみたんですが、案の定40%台だったので、点数がほとんど伸びていないことを痛感しました。 この結果を受けて、平日の夜もAWS勉強に捧げた時間はなんだったんだ...と1日くらい立ち直れなかったです笑 【一縷の望み】試験1週間前（Udemy動画視聴完了時点） 使用教材 【SAA-C03版】AWS認定ソリューションアーキテクト アソシエイト試験：短期突破講座（300問の演習問題） 学習内容 上記動画で見直す（基礎サービス・合格点到達に必須のサービス） 動画を見ながら、用語・用語詳細・サービス特徴・紛らわしい用語の違い をスプレッドシートにまとめて、自作問題を作成 自作問題・Udemy小テストを使ってアウトプット 動画で出てこない場合は、テキストで補完 結果 Udemyを使って、2回分模擬試験を実施してみました。 SAA-C03版模擬試験③ SAA-C03版模擬試験④ 感触 そもそもテキストだけだと僕の場合歯が立たないと思ったので、動画形式で学べるUdemyを使って、大体2週間くらいでUdemyを1周しました。 参考書を1周して点数が伸びなかったのは、 サービスを全体像で理解するだけでは点数に直結しない そもそもサービスの特徴の大半を抑えられていない シナリオにおいて、技術的な違いを問われた時に、絞りきれない問題が多すぎた といった感じで、用語理解からさらに1段階, 2段階踏み込めていなかったのが敗因だなと感じました。 そのため、Udemyでサービスの全容を掴みつつ、とにかくサービスの特徴（ECS/EKSの特徴, Amazon Kinesisの特徴 など...）、違い（ネットワークACLとセキュリティグループの違い...）などをスプレッドシートにまとめて、簡易的な問題を作成して、通勤時間の電車などで確認していました。 その結果、模擬試験のテストを受けて初めて合格点に届いた試験が現れました（まだまだギリギリですが...）。得点率も平均  64%  まで上がって、少し安心したのですが、試験まで1週間なのであと最低でも10%はあげないといけません。 正直気持ちに余裕はあまりなかったかな...って感じでした。 【合格が見えてきた】試験1日前（模擬試験完了時点） 使用教材 【SAA-C03版】AWS認定ソリューションアーキテクト アソシエイト試験：短期突破講座（300問の演習問題） 学習内容 上記動画で見直す（高得点を狙うサービス） 小テストの復習 結果 試験前日に3回分模試を解きました。 本番レベル模試① 本番レベル模試③ SAA-C03版模擬試験⑥ 感触 最後の1週間は、比較的アウトプット重視で勉強していました。 自分は問題解くことが割と好きなタイプなので、この期間の勉強は結構楽しかったです。 得点率も着々と上がってきて、平均で得点率  74%  まで上がっていました。 自分が予想するAWSのスコアに換算すると  766点  、試験前日になってようやく合格点に届いていそうな感じがしました。 ▼予想スコア換算方法 SAA-C03は、100〜1000点の得点が付与 → 900点分の点数レンジ式：100 + 0.74 * 900 = 766 ※実際のテストでは、すべての設問が採点対象でないことや設問ごとに点数が異なる(らしい)ので、一概に言えないですが目安としてこのくらいって感じで見積もりました。 【あれ手応え何処へ...】本番（受験当日） 試験直後は、「あれ...手応えあんまない...」って感じになりました。 感覚的には、自信あった問題・怪しい問題含めて、もしかしたら40問正解（ 100 + 40 / 65 * 900 = 653点 ）ぐらいもあり得るな...って不安になってました、、良くて700点かも...って感じにもなってました。あれ？落ちた？？って思いましたw 試験を受けて約6時間後に結果のメールが届いたんですが、そこに「 Congratulations! 」と書いてあって、嬉しさよりも、え？？見間違えじゃない？？って感じで疑いの目をかけてしまっていました。 実際のスコアレポートを見て点数が上回っていたのを確認してから、合格したんだぁと噛み締めてました。 実際は773点だったので、得点率を単純算出すると 74.8% でした。 最後に 得点率推移は下記になります。途中、絶望に打ち拉がれてたんですが、なんとか持ち直して一発合格まで持って行けてよかったです。 期間 得点率 AWSスコア(仮算出) 試験4週間前 41% 473点 試験3週間前 44% 501点 試験1週間前 64% 681点 試験1日前 74% 766点 本番 74.8% 773点 この体験記で、SAA-C03試験を勉強中だったり、これから受ける人へのエールになれば幸いです！ 自分もAWSの資格他にもとってみようかな... ちなみに弊社では、資格取得支援制度として、資格取得にかかる受験料を会社が補助してくれるので、こちらも有効活用できます！

はじめに 私たちは、マイナビでの業務で推薦システムの開発や面接対話システムの開発プロジェクトで自然言語処理の技術を使っています。 その知見を深めるべく、2026年3月9日〜13日に栃木県宇都宮市で開催された「 NLP2026 （言語処理学会 第32回年次大会）」に現地参加し、各種発表を聴講しました。 この記事では会場の様子や講演、ポスターセッションの様子をお伝えし、気になった発表についていくつかご紹介します。 言語処理学会とは 言語処理学会が主催する言語処理に関する理論から応用まで幅広く研究発表が行われます。 情報科学に限らず、言語学、心理学、認知科学など多様な分野から参加があります。 毎年３月ごろに開催され、アカデミアだけでなく多くの企業も積極的に参加しており、社会実装を主眼に置いた研究も多くなっています。 ChatGPTの登場から3年あまりがたち、自然言語処理に分野は大きく進展しました。 今回のトピックとしては、LLMの解釈性、法規制・倫理、複雑な対話や図表読解など高度なマルチモーダル研究が挙げられ、実世界での運用を一層意識した会となりました。 開催地の宇都宮について 近年西日本で開催されることが多かったのですが、今回は栃木県宇都宮市で行われました。 会場となったライトキューブ宇都宮は宇都宮駅の目の前で、周辺の飲食店や商業施設など充実していました。 開催期間中に宇都宮では 21年ぶりの大雪 に見舞われましたが、大きなトラブルなく参加することができました。 会場目の前の様子 宇都宮はギョーザの町としても知られていますが、マグロの消費量が上位の地域でもあります。 駅周辺には寿司屋が多数あり、ランチの時間はシャリの大きいお寿司を満喫しました。 会場の様子 初日にはチュートリアル講演、２～４日目は研究発表と招待講演、５日目はワークショップというスケジュールで開催されました。 今回の最終的な参加者は 2316名 、発表件数 797件 で、ともに過去最高の規模で行われました。 この発表件数の増加に対応するため、口頭発表は選考のうえシングルセッション形式のみとなり、ポスター発表が標準形式となりました。 招待講演は以下の2件で、いずれも盛況でした。 松井智子先生「非典型な言語発達と言語使用：発達障害とバイリンガルから考える」 尾形哲也先生「ロボット基盤モデルにおける言語の役割—運動と言語の統合—」 セッション以外のホスピタリティも充実しており、昼時には中庭にキッチンカーが出展されていたり、終日茶菓と飲み物が提供されました。 また、託児所やコワーキングスペースも設置され、幅広い参加者に配慮されていました。 発表の紹介 ここからは、学会を通して気になった発表を簡単にご紹介します。 ハルシネーションから学ぶ：内部表現への介入によるハルシネーション抑制 門谷 宙, 西田 光甫, 西田 京介 (NTT) NTT研究所からの発表でLLMのハルシネーションを低減するための研究です。 LLMが嘘をつく能力を容易に獲得することに着目し、嘘を含むデータでanti-expert LLMを構築し、この出力確率をペナルティとすることでLLMの事実性を向上させることができるという手法です。 この手法では二つのLLMを動かすことによる推論コストを、モデルの統合によって削減する新たな手法を提案しました。 この結果、出力確率の操作ではなくLLMの内部表現に介入して事実性を向上させることができました。 ハルシネーションの原因は知識不足と、知識の想起失敗とされていますが、この手法は後者に効くとされています。 RAGで知識不足を補うだけではなく、本手法のように原因別で対処することでハルシネーションを抑制することができます。 感想・考察 LLMのハルシネーション問題はLLMの登場からずっと問題となってきましたが、最近では内部的なふるまいの研究が進んでおり、この研究もその流れの一つとなっています。 業務でハルシネーションを可能な限り減らさなければいけない場面で、RAG以外で有効な対策だと思いました。 LLM の生成する方言テキストを音声合成したデータによる音声言語モデルの方言理解能力向上 三森 俊祐, 藤田 雄介, 水本 智也 (SB Intuitions) 国産LLMのsarashinaなどで知られるSB Intuitionsからの発表です。 音声言語モデルと方言を話すために、LLMで生成した方言を学習させた結果、方言性能が向上したという研究です。 手法としてはまず標準語を方言の指示プロンプトを与えLLMを用いて方言に翻訳し、これを音声合成で標準語の韻律で疑似方言データを作成する。このデータで音声言語モデルを学習し、方言適応を行いました。 標準語の翻訳と英語の翻訳の比較で実験を行った結果、文法や語彙については学習が成功したことが分かった一方で、実音声特有の音韻変化への適応は難しいことがわかりました。 感想・考察 日本各地で幅広い人に音声対話システムを使ってもらうとしたとき、方言理解が必要になることもあると思われるのでこれからの対話システムの開発で重要な発表だと思いました。 また、合成データのみでモデルの向上が期待できるというのも参考になり、商談や就職面接など機密保持の観点から学習が難しいデータでも合成データによって性能向上が見込めるかもしれません。 Transformer事前学習における最終層隠れ状態ジャンプの抑制 柴田 圭悟, 矢野 一樹 (東北大), 高橋 良允 (東北大/理研), 李 宰成, 池田 航 (東北大), 鈴木 潤 (東北大/理研/NII) Transformerにおける"最終層隠れ状態ジャンプ"の抑制が精度改善に寄与することを示した研究です。 まず、"隠れ状態ジャンプ"とはモデルの隠れ状態(ベクトル)の角度がある層を通したときに急激に変化することを指しています。 Transformerにおいて、この隠れ状態ジャンプが最終層付近でのみ発生していることが確認されており、中間層の冗長性が議論されているようです。 この研究では "Transformerの性能面において最終層隠れ状態ジャンプは悪い現象" と仮説立てています。 発表者は仮説から隠れ状態ジャンプを抑制するような損失計算を設計しています。 また、これを実際にベンチマークタスクで評価し、性能の向上を確認しています。 感想・考察 Transformer内部で起きている現象に着目し、そこから仮説を立て、直観的かつシンプルな修正によって性能改善につなげている点が非常に印象的でした。 近年は、データや評価から仮説を立て、入力、モデルを取捨選択、修正をするアプローチが主流になりつつあり、特にLLMの普及以降、そもそもモデル内部には手を加えないことも増えてきているように感じます。 そのような背景を踏まえると、本研究のようにモデル内部の挙動そのものに焦点を当てた研究は、今後も高い価値を持つと私は考えています。 また、Transformerの発表から9年経過している現在においても、十分に解明されていない現象が存在する点も非常に興味深く感じました。 おわりに 今回は、言語処理学会の様子をお伝えしました。参加してよかった点は、現在の自然言語処理の流れと今後の発展方向を直接把握できたことです。実社会でLLMの活用が一層進むなか、性能向上の方策や安全性の確保などに向けて、多くの示唆を得られました。 次回の開催地は福岡の博多ということなので、ぜひ次回も参加したいと思います。

このシリーズでは、当社のデジタルテクノロジー戦略本部（通称：デジ戦）で働く社員が、どのようにスキルを伸ばし、キャリアの幅を広げてきたのかを紹介します。キャリアチェンジの背景や挑戦のプロセス、日々の学びを通じて、デジ戦で描けるキャリアの可能性をお伝えします。 筆者プロフィール 所属：ビジネスイノベーション第1統括本部 ITソリューション第3統括部 ビジネスシステム部 入社時期：2019年 中途入社 職種：システムエンジニア 経歴： 新卒で鉄道会社に入社し、駅係員などの業務に従事。 2019年2月にマイナビへ中途入社し、企画職としてマイナビ転職フェアのイベント企画に従事したのち、採用支援部門へ異動。 企業の採用を支援する商材の企画やカスタマーサクセス、部門の業務効率化支援などを担当。 2024年10月にデジタルテクノロジー戦略本部へシステムエンジニア職として異動。 現在は、ライフキャリア事業本部の社内システムの開発・保守・運用や、全社の業務ツールの内製開発などを行っています。 はじめに デジ戦への異動が決まったとき、うれしさと同じくらい不安がありました。30歳、未経験でシステムエンジニアとしてやっていけるのか。正直、自信があったわけではありません。 この記事では、私がITに興味を持ったきっかけや、デジ戦へ異動した理由、異動直後に感じたギャップ、現在担当している業務、そしてこれから目指したいキャリアについてお話しします。キャリアチェンジは決して簡単なことではありませんが、これまでの経験がどのように今の仕事につながっているのかをお伝えできればと思います。 現場で感じた違和感が、ITへの入口になった 私がITに興味を持ったのは、鉄道会社で現場の仕事をしていた頃でした。 駅係員として働く中で、「もっと効率的にできるのではないか」「この手間は仕組みで減らせるのではないか」と感じる場面が多くありました。そうした思いから社内プロジェクトに参加し、業務ツールの開発に関わる機会がありました。そこで、ITやデジタルの力で仕事の進め方そのものを変えられることを実感しました。 単に便利なツールとしてではなく、現場の負担を減らし、仕事の質を高める手段としてITに惹かれるようになったのが、この頃だったと思います。 企画職として働く中で、「使う側」から「つくる側」へ気持ちが変わっていった 2019年にマイナビへ中途入社してからは、企画職としてイベント企画や商材企画、カスタマーサクセス、業務効率化支援などに携わってきました。 この時期に特に力を入れていたのが、業務改善です。手作業や属人的な運用を見直しながら、VBA、GAS、BIツールなどを活用して、部門全体の業務効率化を進めていました。 その中で実感したのは、ITは単なる作業効率化にとどまらず、業務の進め方そのものを変える力があるということです。課題を整理し、関係者を巻き込み、運用まで含めて形にしていく経験は、今振り返るとシステムエンジニアとして必要な視点につながっていたように思います。 30歳、未経験でシステムエンジニアへ異動するという挑戦 デジ戦への異動が決まったのは、30歳のときでした。 それまでITツールや業務改善には関わっていましたが、システムエンジニアとしての実務経験があったわけではありません。うれしさはありましたが、それ以上に「本当にやっていけるだろうか」という不安もありました。 デジ戦には、技術畑を一直線に歩んできた人だけでなく、事業側の経験を持つ人や、さまざまな職種を経て今の仕事に就いている人もいます。そうした環境に触れる中で、システムエンジニアとして大切なのは技術力だけではないのだと感じるようになりました。 もちろん、未経験からでも簡単に通用するという意味ではありません。技術を学び続けることは前提です。そのうえで、現場を理解する視点や、業務を整理する力、関係者と認識をそろえながら前に進める力も価値になる。そう思えたことで、自分がこれまで積み重ねてきた経験にも、挑戦する意味があると前向きに捉えられるようになりました。 それでも挑戦しようと思えたのは、「現場や事業の課題を仕組みで解決したい」という思いが自分の中にずっとあったからです。やらずに後悔するよりも、まずは飛び込んでみたい。そうした思いを持つ中で、デジ戦へ異動することになりました。 また、マイナビには、研修やUdemyなどの学習機会に加え、キャリア希望申告や社内公募制度など、挑戦を後押しする仕組みがあります。自分のキャリアを考えながら、次の一歩につなげやすい環境だと感じています。 異動直後の3か月は、知識不足と向き合う時間だった 実際に異動してみると、最初にぶつかったのは想像以上の知識差でした。ベンダー様との打ち合わせではシステム用語が当たり前のように飛び交い、会話の前提も意思決定のスピードも速い。単語そのものは調べれば分かっても、その場の文脈や論点の重みまですぐにつかむのは難しく、最初の3か月は特に苦労しました。 会議が終わるたびにメモを見返し、分からなかった言葉を調べる。必要に応じて生成AIも活用しながら、一つずつ知識の穴を埋めていきました。その繰り返しで、少しずつ理解できることが増えていきました。 また、未経験だからこそ、実務に触れる量を増やさなければ前に進めないと感じ、できるだけ案件に手を挙げるようにしていました。加えて、後輩、先輩、上司を問わず、分からないことは素直に聞くようにしていました。初歩的な質問でも受け止めてくれる雰囲気があり、そのことに何度も助けられました。 今振り返ると、この3か月は知識を増やすだけでなく、未経験の立場で前に進むための姿勢を身につけた時間だったと感じています。 今担当している仕事と、そこで活きているこれまでの経験 現在は、ライフキャリア事業本部の社内システムの開発・保守・運用や、全社の業務ツールの内製開発に携わっています。 システムエンジニアの仕事というと、実装や設計のイメージが強いかもしれませんが、実際にはそれだけではありません。利用部門の要望を整理し、課題を言語化し、関係者と認識をそろえながら、開発や運用につなげていくことも重要な役割だと感じています。 業務では、たとえば以下のような技術・ツールを活用しています。 言語・スクリプト：OfficeScript、VBA、Python、SQL インフラ・クラウド：AWS ツール：Power BI、Power Automate 、Dify、denodo、Reckoner また、生成AIも情報整理や論点の洗い出し、理解が曖昧な領域のキャッチアップなどに活用しています。 ここで活きているのが、これまでの現場経験や企画職の経験です。現場で働いていたからこそ、「使う人にとって無理のない運用か」「本当に役立つ仕組みになっているか」という視点を持ちやすい。また、事業部門での経験があるからこそ、「何の課題を解決したいのか」「どう伝えれば関係者の認識がそろうのか」を考えることにも自然と意識が向きます。 全社横断プロジェクトのPJリーダー経験で、課題を仕組みに変える面白さを強く実感した 私にとって大きな転機のひとつになったのが、全社横断プロジェクトのPJリーダーとして取り組んだ、社内備品共有の仕組みづくりです。 事業部門にいた頃、まだ使える備品が十分に活用されないまま廃棄されていく状況を見て、「社内で共有できる仕組みがあれば、もっと有効活用できるのではないか」と感じていました。 そこから始まったのが、社内備品共有ツール「マイカリ」につながる全社横断のボトムアップ型プロジェクトです。課題意識を持つだけでなく、それを関係者と共有し、実際に使える仕組みとして形にしていく難しさと面白さを、このプロジェクトを通じて強く実感しました。 特に印象に残っているのは、デジ戦の方々と一緒に進める中で、単に機能を作るのではなく、「どうすれば使われるか」「どうすれば運用に乗るか」まで見据えて考える姿勢に触れたことです。立ち上げから約4か月で都内拠点でのリリースにつながり、その後、全社リリースまで進めることができたのは、多くの関係者の協力があったからこそだと感じています。 また、この取り組みは社内にとどまらず、日経GXなど複数の社外メディアにも掲載されました。現場の課題意識から始まったボトムアップの取り組みが、社外からも関心を持って見ていただけたことは、大きな励みになりました。 この経験を通じて、私は「ITを業務改善に活用する」だけではなく、「ITで仕組みそのものをつくる側に回りたい」と、より明確に思うようになりました。 関連リンク マイナビ サステナビリティニュース https://www.mynavi.jp/sustainability/news/2025/10/post_50484.html これから目指したいキャリア システムエンジニアとしては、まだまだ道半ばです。現在担当している社内システムの開発・保守・運用や、業務ツールの内製開発を通じて基礎を固めながら、今後はさらに扱える領域を広げていきたいと考えています。 具体的には、開発言語の幅を広げること、AWSなどのクラウドサービスへの理解を深めることに加え、AIも適切に活用しながら、開発や業務改善の質とスピードを高めていきたいです。 将来的には、既存業務の改善や運用支援にとどまらず、新規事業の創出にも関わっていきたいと考えています。現場や事業の課題を起点に、新しい価値を形にしていくプロセスにも挑戦し、仕組みづくりを通じて事業の可能性を広げられる人材を目指したいと思っています。 そのうえで目指したいのは、技術だけに強い人ではなく、現場や事業のことも理解したうえで、使う人にとって本当に意味のある仕組みをつくれる人です。 これからマイナビのデジ戦を目指したいと考えている方には、新卒・中途を問わず、これまで培ってきた経験や自分なりの視点を強みとして大切にしてほしいと思います。最初からすべてできる必要はありませんが、学び続ける姿勢に加えて、分からないことを素直に周囲に聞き、吸収していく姿勢はきっと力になります。自分の経験やこれまで培ってきた力を、デジ戦でどう活かせるかを考えながら、ぜひチャレンジしてみてください！ 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。

はじめに 普段はRuby, PHP, Typescriptを主に使ってアプリ開発をしているITエンジニア4年目のY.Mです。 AWSを勉強していく中で、「サービスめっちゃ多い」とか「どんな用途で使えばいいか毎回忘れる・混乱する」なんて経験ありませんでしょうか？ また、実際にAWSを触ってみて、VPC・ECS構築やCI/CD自動化などで「今自分って何でこの操作しているんだろう．．．」と思うことありませんでしょうか？ 自分はもうすぐ社会人4年目を終えるところで、AWSもちょこちょこ触ったりしているのですが、あまり頻繁に構築したりもしていないせいか、悲しいことに忘れてしまうこともかなり多いです。 そこで、どうしたらAWSを包括的にかつ長期的に概念を覚えられて、実務にも活かせるんだろうと考えていました。その時に思いついたのが、今回執筆する AWSの全体像をスーパーマーケットに例える という内容です。身近なものに例えて、脳に長期記憶を促そうといった狙いです。 今回の記事は、 AWSの基本構成を包括的に理解したい AWSの概念を長期記憶化したい といった初級者向けの記事になっています。 私は、実務ではCloudWatchでのログ監視やS3バケットへのデータ格納は使っていますが、正直AWSの理解が断片的であったり、1からAWSサービスを構築した経験はほぼないので、これを機にAWSのサービスを包括的に覚えてみようと思いました。私も実際にこの例えを活用したことで、AWSに対する全体の理解が一気に深まりました。 今回、身近なものに例えていくため、厳密な定義ではないところもあるかもしれませんが、この記事にて 「包括的」かつ「長期的」 にAWSサービス全容の大枠な理解が深まれば幸いです。 AWSの学習ロードマップ 今回、AWSの全体像を掴んでいくにあたって、 AWS学習ロードマップ （制作者 くろかわこうへいさん、小山雄太さん）が非常に有用だなと思ったので、こちらを使って解説していきます。 上記URLから、PDFでAWS学習ロードマップをダウンロードできます（営利目的の使用は厳禁と記載があります）。 こちらの学習ロードマップですが、全部でセクション数が12個あり、大きく3つに区切ると綺麗かなと思ったので、3つに分けてそれぞれ図解も交えて解説していきます。 AWSの基本構成 （Section 7まで） サーバレスなサービス導入 （Section 10まで） 分析・マルチアカウント作成 （Section 12まで） AWSの基本構成 (〜Section 7) AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例 (サービスはめ込み版) 解説 ここでは、スーパーマーケット、隣接する工場やオフィス、そして面している道路を使ってサービスの解説をしていきます。無色・薄い灰色のエリアがパブリック空間（一般市民が出入りできる空間）・濃い灰色のエリアがプライベート空間（専用の人間しか入れない空間）になっています。 AWS（Amazon Web Service） 概要：Amazonが提供するクラウドコンピューティングサービス 例示：地域全体 AWSは、Amazonが提供するクラウドコンピューティングサービスで、シェアNo.1を誇っています。 AWS空間にて、サーバーの構築・管理までを一貫して管理する集合体になります。 実世界では、地域全体と同等になるかと思います。 Route53 概要：ドメイン名を検索してIPアドレスに変換するサービス 例示：自動車のカーナビ Route53は、ドメイン名をIPアドレスに変換することで、コンピュータ内部で通信できるようにする役割を持っています。 例えば、「mynavi.jp」が入力されたら、「3.165.11.119」といったように変換されて通信されます。 これが、実世界では自動車のカーナビ（目的地名を入力し、ナビでもわかるようにピン表示へ変換する）でも同様なことが言えると思いました。 CloudFront 概要：コンテンツを近くから配信し、高速通信を可能にするサービス 例示：配送センター CloudFrontは、コンテンツを近くから配信することで、低遅延・データ転送性能向上を可能にするサービスで、コンテンツをキャッシュする役割を持っています。 実世界では、配送センター（中継所）のようなイメージで、遠方の倉庫から運搬してきた荷物を配送センターで保管し、必要な時に配送センターから届けることで、より短い時間で出荷可能になるのと同様になるかなと思います。例えば、スーパーで発注した食材が必要になった時に、倉庫（県外にあるとする）から出荷すると運送時間に比例して、鮮度やおいしさが落ちてしまうリスクがあります。ただ、配送センターから出荷を行うと、短い運送時間で出荷ができるため、新鮮な状態で食材を届けられるというイメージです。 ACM（AWS Certificate Manager） 概要：SSL/TLS証明書を管理できるサービス 例示：公認バッジ ACMは、SSL/TLS証明書を発行・更新・管理することで、安全な通信の一助を担うサービスになっています。 先ほどの配送センターの場合、配送センター自体が本物なのか、或いは悪徳業者が運営しているのかといった見分けが一般市民からは分かりません。そのため公認バッジを発行することで、本物・信頼の証であることを証明でき、安心安全な運送が提供できることを市民へも理解させることができます。 S3（Simple Storage Service） 概要：データを保存・取得できるストレージサービス 例示：倉庫 S3は、静的なデータ（ファイル・画像など）を保存・取得できるストレージサービスです。 実世界では、巨大な倉庫に例えるのが妥当です。 VPC（Virtual Private Cloud） 概要：専用のプライベート仮想ネットワーク 例示：スーパーマーケットの敷地内全体 VPCは、論理的に分離されたプライベートの仮想ネットワークです。この中で、EC2やRDSなどの個人情報が絡むサービスを設計していきます。 今回は、スーパーマーケットの敷地内全体が、プライベートの仮想ネットワークに該当します。 以降のサービスは、VPC内のサービス（スーパーマーケット内）を中心に解説をしていきます。 Internet Gateway 概要：VPCの内外間で通信を行うサービス 例示：スーパーマーケット駐車場出入口（警備員） Internet Gatewayは、VPC内部とインターネット間を通信するためのサービスです。 グローバルIPアドレスをプライベートIPアドレスへ変換し、セキュリティ機能を担保しながら通信する役割を持っています。 実世界に例えると、スーパーマーケットの駐車場の出入口に該当します。この出入口付近で警備員が立っており、怪しい市民を排除することで、スーパーマーケット内の安全性を高めています。 Public Subnet 概要：ブラウザから直接アクセスすることができる領域 例示：スーパーマーケットの商品陳列エリア Public Subnetは、ブラウザから直接アクセスできる領域になります。 実世界では、スーパーマーケットの商品陳列エリアに該当します。ブラウザを世界中の人間の集まりだとした時に、スーパーマーケットで通常の人間が入れるエリアは限られていて商品陳列エリアは入れるものの、従業員専用のバックヤードや有人レジの中には入ることができません。 Private Subnet 概要：ブラウザから直接アクセスすることができない領域 例示：スーパーマーケットのレジ（捜査側）・従業員専用部屋 Public Subnetに対して、Private Subnetはブラウザから直接アクセスできない領域になります。 実世界では、スーパーマーケット内のレジ（操作側）や従業員専用部屋など、一般の人が入れない領域に該当します。 ALB（Application Load Balancer） 概要：サーバに負荷を分散させるためのサービス 例示：レジの案内係 ALBは、サーバに負荷がかからないように適切に通信量を分散するサービスになります。 実世界では、レジの案内係に例えることができます。買い物客が一つのレジに集中的に並んでしまった場合、レジが混んでパンクしてしまいます。それを防ぐために、レジの案内係を用意して、レジへ均等に人が並ぶように調整することで、人の流れを最適化しています。 ECS（Elastic Container Service） 概要：完全管理型のコンテナオーケストレーションサービス 例示：レジ管理人 ※私の調べた限りだと、AWS学習ロードマップの各Private Subnetに置かれているECSはEC2インスタンスであり、それらのコンテナを管理するサービスがECSだったので、それを基に解説します。スーパーマーケット例では修正しています。 ECSは、アプリケーションを動かすためのコンテナを効率的に自動管理してくれるサービスです。 EC2インスタンスへの通信量に応じて、必要なコンテナ（タスク数）を自動増減してくれる役割を持っています。 スーパーマーケットでは、レジの管理人に例えることができて、レジに待つ人に応じて、稼働するレジの台数を増減する指揮官のような役割を果たします。 EC2（Elastic Compute Cloud） 概要：クラウド上の仮想サーバサービス 例示：レジ本体 EC2は、クラウド上の仮想サーバサービスで、アプリケーション本体を動かす根幹を担っています。 スーパーマーケットでは、レジ本体に例えることができて、店舗自体もレジ（売上収集）が存在するからこそ営業することができます。 RDS（Amazon Relational Database Service） 概要：クラウド上の仮想データベースサービス 例示：PC上での売上管理 EC2がサーバであれば、RDSはデータベースサービスになります。 スーパーマーケットでは、レジの売上データに例えることができて、一般人が入れない場所（今回の例では本社オフィスに置きました）で管理しています。 IAM（Identity and Access Management） 概要：役割に対する権限を管理するサービス 例示：スタッフの従業員証 IAMは、役割に対する権限を管理するサービスで、統合管理にあたってセキュリティを強固にする役割を持っています。 実世界では、スタッフの従業員証が該当します。有人レジの操作や従業員更衣室、本社オフィス内部など、一般の人が立ち入ることが禁止されているエリアにて、スタッフの従業員証（IAMロール）が付与されていれば、そのエリアへ入ることができるイメージです。 NAT Gateway（Network Address Translation） 概要：プライベートサブネット内から外部へ通信をするためのサービス 例示：従業員専用部屋（バックヤード）の出入口 NAT Gatewayとは、プライベートサブネットから外部へ通信するためのサービスになり、EC2インスタンスで構築されたアプリケーションから外部APIの接続など、インターネット側で通信したい時に使われます。 実世界では、バックヤードの出入口に該当します。お店の開店前に、レジでの売上金をATMへ入金する時や、発注商品の受け取りなどを行うイメージです。 CodePipeline 概要：CI/CDを自動化するためのサービス 例示：製品組立の現場監督 CodeDeployとは、アプリケーションを自動化するための管理サービスです。GitHubでソースコードの変更を検知したときに、ビルド・デプロイを一貫して自動で行ってくれる役割を持っています。 これを実世界に例えると、依頼された製品の組み立て・取り付けを監督する現場監督員が妥当です。製品の組み立てから取り付けまで一貫してサポートします。 CodeBuild 概要：自動テストやビルドを実行してくれるサービス 例示：製品の組み立て CodeBuildとは、ソースコードの自動テストやビルドを実行してくれるサービスです。 実世界では、現場監督管理のもとで、依頼分の製品の組み立てを行います。 ECR（Elastic Container Registry） 概要：コンテナイメージの保存・共有ができるサービス 例示：完成製品の保管庫 ECRとは、ビルドが完了したイメージの保存や共有ができるサービスになっています。 実世界では、完成製品の保管庫が近いかなと思います。AWS学習ロードマップでは、NAT GatewayとECRがつながっていることより、従業員がバックヤードから出て製品を確認できるようなイメージです。 CodeDeploy 概要：ソースコードの反映を行うサービス 例示：製品の取り付け CodeDeployとは、ソースコードの反映を行うサービスです。 上記のスーパーマーケットの図の例だと、顔認証システムの製品を取り付けているイメージです。 余談ですが、最近AI顔認証決済というものが出てきていて、事前に登録した本人の顔にクレジットカードを登録しておくと、財布やスマートフォンを出さずに登録したクレカで会計ができるみたいです…笑 世の中の進化で、どんどんデジタル化が進むなあと思い知らされます。 https://jpn.nec.com/fintech/face_settlement/index.html CloudWatch alerm 概要：AWSサービス監視にて使用率が閾値を超えた場合にアラートを検知するサービス 例示：異常検知センサー CloudWatch Alermとは、AWSサービス監視にて使用率が閾値を超えた場合にアラートを検知するサービスです。 実世界では、異常検知センサーが近いと思います。レジが混んできて待ち時間が長くなってきた場合に、スーパマーケット内の異常検知のセンサーの作動・放送が行われるイメージです。作動後は次で説明する「SNS」にて解説します。 SNS（Simple Notification Service） 概要：ユーザへメールを送信するサービス 例示：緊急連絡先センター SNSとは、ユーザへメールを送信するサービスを表しており、対策メンバーへの周知を行う役割を担っています。本ケースでは、Cloudwatch alermからアラートを受け取ったタイミングで、メールを送信するような流れになっています。 実世界では、レジの待ち時間が長くなってきた時にセンサーが発動し、緊急連絡先センターに連絡が届き、当該店舗の従業員へ応援を要請するようなイメージです。 Terraform 概要：オープンソースのインフラコード 例示：街を再現する設計図 Terraformとは、Hashicorp社が開発したオープンソースのインフラコードで、AWSの構築内容をコードで管理するサービスです。 具体的には、街を再現するための設計図のようなイメージです。仮に街で災害が発生して建物や周辺の道路が損壊してしまった時に、設計図が無いと元に戻すことはできません。そこで設計書があることで、万が一街が壊れてしまっても、構築内容を元通りに戻すことができます（ただし、ECSやRDSといった中身のデータは復元できないので注意してください）。 サーバレスなサービス導入（〜 Section 10） AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例　（サービスはめ込み版） 解説 Section7までで説明した基本構成より、オフィス内で分業化をしました。これまでオフィスにあったサービスはシステム部へ、今回説明する部署を総務部へそれぞれ部署を分割しました。総務部の中で、Lambdaを用いたサーバレスなサービスの解説をしていきます。 API Gateway 概要：APIリクエストの集中管理・ルーティング制御を行うサービス 例示：受付窓口スタッフ API Gatewayは、APIリクエストの集中管理やルーティング制御を行うサービスで、どのサービスにアクセスするかを振り分ける役割を担っています。 実世界では、総務部で働いている受付窓口スタッフに該当します。ここで受け取ったお問合せ内容について、誰に仕分けてもらうかを振り分けるのと同等になります。 WAF （Web Application Firewall） 概要：攻撃と思われる通信を遮断するサービス 例示：受付窓口スタッフ （門番役） WAFは、SQLインジェクションやXSSなどの攻撃などと思われる通信を遮断するサービスで、脆弱性を狙った攻撃攻撃に防ぐ役割を持っています。 先ほど説明した受付窓口スタッフは、お問い合わせ内容の仕分けだけでなく、怪しい人が入ってきた場合はオフィスへの侵入を阻止させることで、内部処理を安全に実行することができます。 Lambda 概要：サーバレスでプログラムを実行できるサービス 例示：作業者 Lambdaは、クラウド上に直接プログラムを定義・実行するサービスです。サーバ構築も不要であり、複雑化した機能ではなく1つの機能を実行するときに役立ちます。 今回の例では、作業者（仕分け人、実行者、回答作成者、感謝文面作成＋手紙送付者）に例えることができます。このように1つの作業の橋渡し役となる大事な役割を担っています。 DynamoDB 概要：高速なNoSQLデータベース（RDSと対で使われる） 例示：問い合わせ内容の記録簿 DynamoDBは、高速なNoSQLデータベースであり、RDS（高度なMySQLデータベース）とは対で使われる。RDSは高度なSQL操作ができるが取得に時間がかかり、DynamoDBはキーバリュー型（具体例として後述）で高度なSQL操作ができないものの、高速（数ms単位）で取得可能です。 今回の例では、スーパーマーケット利用者から頂いた問い合わせ内容の記録簿として機能を果たします。問い合わせ内容は、名前（キー）と問い合わせ内容（バリュー）で紐づけることができるため、検索が容易で高速に取り出すことができます。 SQS（Simple Queue Service） 概要：メッセージを受信・保存し、順番に送信するサービス 例示：お問い合わせ書類 SQSは、メッセージを受信・保存し、順番に送信するサービスです。 今回の例では、作業者（仕分け人）が仕分けたお問い合わせ書類が保管されており、作業者（実行者）によって処理されるイメージです。 Step Functions 概要：実行対象のワークフローを自動化できるサービス 例示：現場マネージャー Step Functionsは、実行対象のワークフローを自動化できるサービスで、今回はLambda関数を順番に実行する処理を管理しています。 オフィス（総務部）の例では、作業者（回答作成）→作業者（感謝の文面作成＋送付）の流れが問題なく動いているかを、現場マネージャーが監視しています。 Bedrock 概要：高機能な基盤モデル（FM）を搭載したサーバレス生成AIサービス 例示：専門家 Bedrockとは、高機能な基盤モデル（FM）に基づいて、サーバレスな生成AIを実現するサービスです。RAGと呼ばれる最新・関連情報を優先的に検索できるデータベースを使い、その知識を基に学習をしています。 実際には、作業者の回答作成の手助けをする専門家が妥当だと思います。専門家の長年培ってきた知識情報を駆使できるため、生成AIに近い表現ができると考えられます。 SES（Simple Email Service） 概要：クラウド型のメール送信・受信サービス 例示：郵便ポスト SESとは、クラウド型のメール送信・受信サービスで、受け取った回答情報を問い合わせをしたユーザへメールを送信する役割を果たしています。 今回の例では郵便ポストに例えられて、回答作成した内容を郵便ポストに投函し、やがて利用者の手元へ届く流れとなっています。 分析・マルチアカウント対応 （〜 Section 12） AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例（サービスはめ込み版） 解説 Section10の段階から新たに赤枠の部分である、データの分析・マルチアカウント対応・監視体制の強化が加わったことで、活用かつ堅牢であるサービス構成になったのかなという感じがしています。実際にスーパーマーケット版でも、本社オフィスのシステム部が追加されて、それぞれシステム部内で部署が新たに新設されたことで対応できていることが確認できると思います。このように、データの利活用・監視を市街地でも実施していくことで、安全なまちづくりを行える意向が伺えます。 また、追加した部署の概要は下記になります。 データ管理部 ：データの分析・可視化を行う部署（Glue, Athena, QuickSight） 店舗監視部 ：店舗の設備情報・利用者の動向を監視する部署（AWS Config, CloudTrail, GuardDuty, SecurityHub） 統制部 ：店舗全体のルール作成を行う部署（AWS Organizations, ControlTower, Terraform） Glue 概要：DBに登録されているデータの収集・変換を行うサービス 例示：スーパーマーケットの売上データの収集・変換 Glueとは、DBに登録されているデータの収集・変換を行うサービスで、データの分析や可視化をしやすい状態にする役割を持っています（＝SQL実行できる状態にします）。 今回の例では、DB＝スーパーマーケットの売上データになっており、分析・可視化しやすい状態にします。 Athena 概要：変換されたデータに対して、SQL実行を行うサービス 例示：売上データ（売上高・購買率など．．．）の分析 Athenaとは、Glueによって変換されたデータに対して、SQL実行を行うことで、データ分析ができるサービスです。 今回の例では、スーパーマーケットでの売上データをデータ単位で見やすくするようにします（例：利用者Aさんは今月10万円お買い物した、利用者Bさんの今月の購買率は40%だったなど．．．）。これにより、スーパーマーケットの運営改善を行うことができます。 QuickSight 概要：変換されたデータに対して、データの可視化を行うサービス 例示：売上データ（売上高・購買率など．．．）の可視化 QuickSightとは、変換データに対して、データの可視化を実施できるサービスです。AthenaはSQL実行して指定したデータを抽出するのに対して、QuickSightはグラフを用いて可視化する役割を持っています。 今回の例では、スーパーマーケットの利用者単位での売上高・購買率の可視化などが挙げられます。 AWS Config 概要：AWSの構成情報を管理するサービス 例示：スーパーマーケット内のレジ台数・従業員数の管理 AWS Configでは、EC2やRDSなどのサービスの設定を管理するサービスで、変更履歴も検知しています。 スーパーマーケットの例では、本社オフィスの店舗監視部が店舗内のレジ台数・従業員数を管理しており、変更をした場合は、具体的な日時まで記録しておくイメージです。 CloudTrail 概要：AWS内の操作を記録・保存するサービス 例示：店舗でのレジ利用者の行動監視 CloudTrailとは、AWSの中で行われた操作を「いつ・誰がしたか」という形式で記録・保存するサービスです。 スーパーマーケットの例では、各店舗でのレジ会計時に、利用者のログを記録して監視している表現が近いかなと思います。 GuardDuty 概要：AWS上のセキュリティの脅威を継続的に検出するサービス 例示：店舗の不審者・侵入者検知 GuardDutyとは、AWS上にてセキュリティの脅威がないかを継続的に検出し続けるサービスです。 スーパーマーケットの例では、店舗内で不審者・侵入者がいないかを継続的に検知し続け、発見次第アラートを鳴らすイメージが近いかなと思います。上記で説明した「CloudWatch Alerm」と一定の基準でアラート発動という観点で同一なのですが、それぞれ検知する種類が違いがあります。 GuardDuty：「悪意あるアクセス」を検知（＝侵入者を検知） CloudWatch Alerm：「リソースの逼迫」を検知（＝混雑状況を検知） SecurityHub 概要：セキュリティ設定・監視を一元管理するサービス 例示：店舗監視部の一覧表示モニター SecurityHubとは、セキュリティ設定・監視を一元管理するサービスを表します。 本社オフィスの例では、店舗監視部が確認している設定情報の管理（AWS config）、利用者の行動監視（CloudTrail）、不審者検知（GuardDuty）を、一覧でモニターに映し出すのと同等になります。 AWS Organizations 概要：複数のアカウントを一元管理するサービス 例示：各店舗リストの保管 AWS Organizationsは、複数のアカウントを一元管理するサービスになっています。 本社オフィスの例では、各店舗（本店舗だけでなく、A店、B店、C店など）のアカウント情報を一元管理するイメージです。 AWS ControlTower 概要：複数のアカウント管理にあたって、AWSのセットアップをしてくれるサービス 例示：各店舗のマニュアルブック AWS ControlTowerは、複数のアカウント管理にあたってAWSのセットアップを行うことで、ベースラインが構築できるサービスです。 本社オフィスの例では、各店舗に対応したマニュアルブックを指します。マニュアルがあることで、スーパーマーケットの規範が成り立つので、本サービスと同等の役割を果たします。 最後に 本記事では、約40のサービスを載せていたAWSの全体像に対して、スーパーマーケットを中心とした街で例えてみました。 それぞれのサービスについての説明もしましたが、各サービスの概要・役割のみの説明で、技術的な詳細な説明はしていないので、気になるサービスは調べていただけたらと思います。 僕もこの記事執筆から、ここで紹介しきれていないサービス含め、さらなるAWSサービスへの理解を深めていけたらと思います！ 最後に、スーパーマーケット図示完成版を下記に共有いたします。

法人ソリューション開発課のS・Sです。 マイナビBiz / LIVING の新規開発 / 保守運用を行っております。 「開発タスクは、こなせるようになってきたけど、モヤモヤしている」 というあなたに向けて、お悩みやモヤモヤを解消するきっかけになればと思い、この記事を書いています。 自分自身、過去にモヤモヤ期を経験していて、なんとなく改善に向かえている感覚が見えてきたので、 ぜひ、体験談や考えていたことを知っていただくことで、あなたのモヤモヤの解決の一助になれれば幸いです。 内容は、モヤモヤを感じるまで、感じた最中、どう改善したかを思い出しつつ、書いておりますので、もし似たような境遇の方に届いたら嬉しいです。 かっこいい先輩エンジニアをがむしゃらに追いかけていた1~2年目 誰しもが、エンジニアの実務未経験から、右も左も分からない中、諸先輩方にサポートいただきながら、数年ほど、なんとか食らいついて、開発を進めていたのかなと思います。 とにかく、この時期は、先輩方のPJ進行、会議やスーパーコーディング、レビュー、顧客折衝など、 あらゆる点において、圧倒的に推し進める姿に感動し、純粋な気持ちで「かっこいいなぁ。。ああなれるように頑張ろう!!」 というモチベーションで、がむしゃらにも楽しくやっていたものだなと思います。 業務はもちろん、プライベートでアプリを作ってみたり、新しい技術を Udemy や技術書を見てはワクワクが止まらなかったですね。（React? わくわく⭐︎、Next? わくわく⭐︎） この時期は、良い意味で、ほぼほぼエンジニアとしてできることがないので、とにかく勉強、実践の繰り返しだったので、悩みやモヤモヤはほとんどなく、初心者エンジニア期を過ごしていたかなと思います。 1人称開発できるようになるも、次の一手に悩み、モヤモヤ期に突入した3~4年目 PJメンバーとして、新規開発〜リリース、運用保守、新規メンバーメンター等、エンジニアとしての一通りの業務経験を積んで、基本的なエンジニア業務は、1人称で対応できるようになってきたのが、だいたい3年目前後だったかと思います。 （あまり飲み込みの良いタイプではなかったけれど、なんとかおかげさまで） この時期になってくると、そこそこの専門性を出しつつ、開発業務やメンバーサポートなどもできるようになってきて、イメージを形にできるようになって楽しくもありましたね。 その反面、あの頃、憧れていたかっこいい先輩との距離や、そこに至るまでの大変さ、自分のできないことの多さについても、以前より良くも悪くも鮮明になってきました。 「あのかっこいい先輩に近づくためには。。」 ・チームメンバーをリードできるレベルのフロントエンドの知識、実践経験 ・チームメンバーをリードできるレベルのバックエンドの知識、実践経験 ・チームメンバーをリードできるレベルのインフラの知識、実践経験 ・PJマネジメントの知識、実践経験 ・メンバーのヒューマンマネジメントの知識、経験 ・PJ進行や保守運用するためのドメイン、サービスの熟知 ・関連部署との折衝、関係構築力 ・明るさ、前向きさ、エネルギッシュな振る舞い ・精神的/肉体的な体力 他にもあれやこれや、、、 といった感じで、新米エンジニア時代に、ざっくりとかっこいい、と思っていた先輩を構成している要素には、あげればきりがないほどの内容と、それに満たない自分が浮き彫りになり、一人で打ちひしがれてしまってしまいました。 自分で言うのもなんですが、目標達成のために、コツコツと少しずつ努力していくことはわりと得意な方だったのですが、目標の大きさと難しさに、この時は、どうやって良いのか分からなくなってしまいましたね。 とはいえ、先ほど挙げたように、客観的に見れば、足りていないもの、やるべきことは明確なんですけど、主観モードの当時は、本当に絶望に近い状態でしたね。 （そもそも、努力では埋められなさそうなものもあるし...） 落ち込んでいても仕方ないと思い、1つ1つ突破していこうと動き始めるも、モヤモヤが止まらないし、憧れの先輩にも近づけない 一瞬は落ち込みましたが、落ち込んだままでは前に進めないので、少しずつでも良いから、憧れの先輩と自分の差を埋められるように、動き始めました。 技術面に関しては、聞ける先輩や教材、実践させて頂ける環境等に恵まれていたので、自分なりのチャレンジを続けて、ゆっくりとではありますが、憧れの先輩に近づいている感覚は掴めていました。 苦手意識の強かったPJ面でも、サブリーダーや顧客折衝などを少しずつチャレンジさせて頂き、経験を積ませていただきました。 うーん、でもなんだかずっとモヤモヤはあって、常に憧れの先輩のようなエネルギッシュでガンガンと、業務を推し進めていくことはいつまで経っても、埋まっていかないなと感じ続けていました。 これまた、落ち込みましたね。。 うーん。 うーん。。 うーん。。。 あ゛ー。（天を仰ぐ） うーん。。。 ん...！？いや、待てよ。 できたとして、それは継続できるのか？ 多分無理。むしろ、そこは弱み。 強みで戦った方がよくない？ 自分の強みってなんだ？ よく周りから言われることってなんだろう.o0O ・穏やか ・安定感 ・丁寧さ ・傾聴力 ・誠実さ ・共感力 ・継続力 わりと、ここら辺を言われることが多いなと。 憧れてる先輩とは、かなり違った方向性だなと。 憧れの先輩が、攻撃型のミッドフィルダー型なら、自分は、ディフェンス型かなと。 サッカーには、チームとしてどのポジションも必要ですし、どちらも試合に勝つ（敵より1点以上多く取る）、と言う同じゴールを目指してプレーすると言う意味では、適切なところで活躍することが重要ですよね。 この考えに、気づくことができたタイミングで、モヤモヤがパッと晴れて、それまでモヤモヤを抱えながら努力していた他のことに関しても、身が入るようになって、とても良い方向に進んでいきました。 先ほどの性質の部分と同様に、技術面にも強み弱みがあることに気づきました（正確には頭ではわかっていたけれど、腑に落ちた感じです）。 インフラ・バック・フロント・マーケ・デザイン・営業などを全てを100%の超人になる必要はなくて、 例えば、得意がフロント・マーケ・デザイン領域なら、そこを武器として、反対に、インフラ・バックが武器の人と一緒に協力して、PJ開発を進めればいいんですよね。 （なんだか、いつの間にか、全てを完璧にこなせる神を目指そうとしちゃっていることに気づきました） 自分の強みに気づき、強みをチームに還元し、チームからは自分の弱みを補ってもらおう 私がお伝えしたいことをまとめると、ある程度の経験を積んできて、次のステージや更なる成長を目指したい場合は、 無意識的に外に目が向いてしまいますが、ぜひ、自分に目を向けて、自分の強みってなんだろうか、を認識して、その強みを発揮させて業務に活かすにはどうしたら良いか、を考えてみるのが良いのかなと思います。 嘘みたいな本当の話ですが、強みを生かして、チームの力を借りて働くことができると、周りにも感謝されますし、反対に、自分の弱みである点が得意なチームメンバーへの感謝もより強く持てるなと思います。 それでいて、不要なストレスも軽減して、パフォーマンスを発揮しやすいので、本当に良いとこ尽くめだなと感じています。 もちろん、業務をする上で、苦手なことや弱みの部分が出てしまうケースはありますが、そこは、変に焦りすぎずに、業務に最低限必要なレベルをまずは目指して、コツコツ努力や経験で埋めたり、それでも至らない所は、人の力をお借りするのがよいのかなと思います。 最後に この記事は、昔の自分と似た境遇の方に向けて書いた記事なので、もし同じような境遇でお悩みの方の改善のきっかけに少しでもなれたら嬉しいです。 参照元メモ 【得意で戦う、苦手は運用で回避】エンジニアの強み弱み分析と活用術 | マイナビエンジニアブログ

法人ソリューション開発課のS・Sです。 マイナビBiz / LIVING の新規開発 / 保守運用を行っております。 私は、前々職で、キャリアアドバイザーを経験しており、 強み弱みを理解し、活かすことで楽しく、結果も出しやすくなる ということを学び、エンジニアという職種でも、この考え方は同様かなと思うので、強み弱みの発見の仕方から、活かし方/対処方法をご共有できればと思います。 関連記事: 開発タスクは、こなせるようになってきたけど、頭打ち感でモヤモヤしているあなたへ | マイナビエンジニアブログ この記事では、 自分の 強み弱みを理解したい 日々の業務で 自分の強みが活かせていない 気がする 強み弱みは把握してるけど、その後の 活かし方がよくわからない という方に向けて、 【得意で戦う、苦手は運用で回避】エンジニアの強み弱み分析と活用術 について、ご紹介します。 先んじて、内容をご理解頂きやすいように、今回の内容の全体像を図に示します。 この図をイメージしつつ、読み進めて頂けますと幸いです。 そもそも、強み弱みとは？ 仕事における、強み・弱みとは、何だと思いますか？ ↓ ↓ ↓ ↓ ↓ ↓ 強み・弱みは、私なりの解釈では下記だと考えています。 ※ 仕事における強み弱み 強み = 再現可能な行動で、（他者）顧客や組織に対して価値提供できるもの 先天的な性質/性格（活発な性格等） 後天的に身についた習慣（家庭環境や学校環境、会社環境、交友関係等） 組織内での相対的に優れる能力 弱み = 強みの反対（一定の価値提供できる状態にするために、人よりも労力や疲弊を著しく伴うもの） 抽象的かつ漢字が多めで、イメージが湧きづらいかもしれないので、ポケモンで例えてみます。 （ポケモンは、ゲームで少しやっていた程度なので、細かいツッコミは目を瞑ってください🙇‍♂️） くさ、ほのお、みずタイプを用いて考えると、それぞれこんな感じです。 先天的な性質/性格: くさタイプポケモンのくさ技、ほのおタイプのほのお技、みずタイプのみず技 → 通常の1.5倍になる 後天的に身についた習慣: くさタイプだけど、レベルアップで覚えたじめんタイプの技 → くさタイプの弱点のほのおタイプに対抗できる 組織内での相対的に優れる能力: ほのおタイプ5匹の中にいる、くさタイプ → ほのおの弱点のみずタイプに強く、重宝される ここで重要なのは、下記です。 強み弱みは、 絶対的な優劣はなく、相対的 なもの 強み弱みは、 補い合うもの 強み・弱みの見つけ方 次に、強み弱みを活かすには、そもそも、自分が何が 強みなのか？ 弱みなのか？ を知る必要があります。 強み・弱み分析の3つの方法 方法としては、中長期の過去の経験 × 他者視点 × 短期のログです。 ※ ポイントとしては、主観ましましの「自己評価」だけで決めないこと Step 1：成果3つ／詰まり3つを書き出す（過去1〜2年） 過去の仕事の中での成果、詰まったことなどを3つずつ書き出してみましょう。 出来事ではなく、なるべく「 自分の行動」に寄せて、書き出してみるのがポイント です。 成果が出た仕事： 何が効いた？なぜ再現できた？といった問いをしてみる。 ex) API設計で、エッジケースを事前に洗い出し、手戻りゼロで実装完了 詰まった仕事： どの条件で崩れた？何が不足していた？といった問いをしてみる ex) 複数タスクの並行で、優先度判断を誤り、納期遅延 Step 2：周囲にいるあなたをよく知っている3人に聞いてみる エンジニアであれば、PJ で一緒にお仕事をしているメンバーがあなたのことをよく見てくれているかと思いますので、お力をお借りするのがおすすめです。 質問時に、あまり難しく考えすぎると率直なものが出づらくなります。 なので、 簡単で答えやすい質問をしてみることがポイント です。 ex) 「率直な印象や特徴はなんですか？」 「私に、任せたい仕事の特徴や内容は、何ですか？」 「逆に、任せると心配なポイントってありますか？」 Step 3：直近、1〜2週間の業務ログを取る 下記のような観点で、ログを書いていきましょう。 ex） ・集中できた作業／消耗した作業 ・見積もりが当たった／外れた ・パフォーマンスが発揮できた状況（時間帯、割り込み、前提の曖昧さ、など） ・ミスが出た状況（時間帯、割り込み、前提の曖昧さ、など） Step 仕上げ：3Stepでわかった共通パターンを見つけて言語化する この3つ（実際のデータ、あなたをよく知る他者からの客観的な意見）を行った上で、 共通するパターンを探して、自分がイメージしやすく言語化 しましょう。 ex) 強み: 構造化して考えるのが得意 臨機応変に柔軟な対応が得意 弱み: 集中力の波がある 一人で黙々と作業をすると捗らない 強みの活かし方 ~ 私の強み（共感性・調和性／継続力）と活かした事例 ~ 強み・弱みを理解した上で、それをどのように活かしていくか、について、私の事例をもとに、イメージをしやすくしていただければと思います。 私の強みは、共感性・調和性、1対1 の対話力でした。 意見が割れたり、温度感がズレたりする場面で、相手の背景や意図を拾って言語化する 摩擦を増やさずに論点へ戻す 双方が納得できる落とし所を作る といった形で、チームの安心感（心理的安全）を作ったり、チームの底上げの役割を担うことが多かったです。 もう一つは、継続力・安定性。 短期的な爆発力はあまりないですが、長期的な課題を計画に落とし、期限と品質を安定させて 淡々と前に進めることが強みでした。 それぞれ分かりやすく目立つものではないですが、前職では、さまざまなPJ に参画をしてきて、口を揃えて言ってもらえていたかなと思います。 弱みの対処法 ~ 私の弱み（瞬発判断が苦手）と対処した事例 ~ 一方で弱みは、その場で瞬発的に考えて判断することでした。 会議中に急に結論を求められる、想定外の論点が飛ぶ、といった場面で無理に即答すると精度が落ちやすいです。 実際に、焦って回答しようとしてオドオドしたり、思考が深めきれていない状態で曖昧な回答をして、後で訂正ややり直しが発生してしまうなどの失敗をしたことも多くありました。 そこで私は、この弱みを「克服」ではなく、どうしたら、顧客やチームに対して、悪影響のない形にできるか、最小限に損失を抑えられるかを考えました。 具体的には、下記のように工夫しました。 質問や相談がある場合は、事前に概要をもらっておく その場で解を出さず、宿題化する 自分の時間を確保して整理し、早めに相談・提案する （原則、その日に結論や過程の共有は最低限行う） このような感じで、 なるべく弱みが出ないような仕組みやルールづくりをすることで、対策を行う ことで、スムーズに仕事を進めやすくなったかと思います。 この例では書いていないですが、仕組みやルールに加えて、 チームメンバーがあなたの弱みを補ってくれることも多々あると思いますので、チームメンバーの強みを理解し、協力を仰ぐことも効果的 です。（反対に、自分の強みを活かし、ある人の弱みを補うのは大前提） まとめ ここで、書いた通りですが、自分の強み弱み分析をして、 強みを活かし、弱みを対策することで、お客様やチームに貢献しやすく、日々の業務が楽しく、成果も出しやすくなる んじゃないかなと思います。 私自身、まだまだ模索中ですし、身をもって実験中ですが、もし、今の働き方に行き詰まりを感じていたり、努力しているけれど空回りしてしまっているのであれば、一つの解決策として、お試しになられてみてはと思います。 まず、少しでもやってみることが大切かなと思います。 完璧ではなくてもいいので、できるもの、気乗りするものからお試ししてみて頂けたら嬉しいです。

このシリーズでは、当社のデジタルテクノロジー戦略本部（デジ戦）の職場環境やチームの雰囲気、日常のコミュニケーションを社員の視点で紹介します。大切にしている価値観やサポート体制、チームの多様性をお伝えし、働く日常を具体的にイメージしていただける内容です。 コンテンツプランニング統括部2部2課のT.Mです。 マイナビ転職のSEO記事の制作を担当しています。 今の部署に異動してから、もうすぐ1年が経ちます。 振り返ってみて、私が一番強く感じているのは 「とても安心して働けている」ということです。 今回は、その理由を日常のエピソードを交えながらお話ししたいと思います。 定例ミーティングに流れる、穏やかな空気 日々の業務の中で「雰囲気がいいな」と感じる瞬間は、いくつもありますが、 私が特にそれを実感するのが、週に一度の課の定例ミーティングです。 定例には、終始とても穏やかな空気が流れています。 ギスギスした感じは一切なく、仕事の話はもちろん、 ちょっとした雑談も自然に交わされる雰囲気です。 「会議だから身構える」というより、 「みんなで状況を共有する時間」という感覚に近いかもしれません。 失敗を責めない、共有を大切にする文化 定例では、全体数字や成果、各自の進捗状況だけでなく、 思い通りにいかなかったことや、想定外の結果に着地したことについても、 積極的に共有されています。 「良いことも、うまくいかなかったことも、きちんと共有しよう」 このスタンスが、課の共通認識として強く根付いていると感じています。 もちろん共有したからといって、責められることはありません。 結果だけでなく、そこに至るまでのプロセスや背景を大切にしてくれるからこそ、 失敗も隠さず話すことができ、次につながる前向きな議論が生まれているのだと思います。 上長・先輩との距離が近く、相談しやすい環境 私が所属している部署では上長との距離がとても近いです。 相談するとすぐにレスポンスをいただけて、 アドバイスもとても具体的。 アドバイスを踏まえて自分なりに検討し、実行してみた結果、数字がしっかり改善した。 そんな経験を、これまで何度もしてきました。 先輩方も同じで、質問すると気さくに、そして丁寧に答えてくれます。 「怖くない」「一人で抱え込まなくていい」と思えることは、 日々働くうえで、想像以上に大きな安心材料になっています。 提案を「まず受け止める」姿勢 定例は、進捗を共有するだけでなく、 自分なりの考えやアイデアを提案する場でもあります。 どんな内容であっても、 提案を最初から「難しいから無理」と切り捨てられることはありません。 まずはきちんと聞いてもらえる。 だからこそ、「せっかくだから発表してみよう」と、 自然と積極的にプレゼンできるようになります。 この「まず受け止める」空気は、 この課だけでなく、デジ戦全体に共通している雰囲気だと感じています。 柔軟な働き方が、日々の安心感につながる デジ戦では、月の半分を在宅勤務にすることが可能です。 また、課内では時差出勤を活用しているメンバーもいます。 私自身も、将来通勤ラッシュが厳しい路線に引っ越した場合などは、 迷わず制度を使うと思います。 無理をせず、自分の生活に合わせて働き方を選べること。 それが、日々の安心感につながっていると感じています。 安心できるチームで、自分の考えを生かしたい人へ 自分なりの考えはあるけれど、 これまでトップダウンの環境でなかなか提案できなかった人。 そもそも、意見を出す機会がなかった人。 そんな人にとって、 人の意見を否定せず、前向きに受け止めてくれるデジ戦は、 とても相性のいい職場だと思います。 「安心できるチームで、自分の考えをちゃんと仕事に生かしたい」 そう思っている方には、ぜひ一度知ってほしい職場です。 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。