100% AI コード生成開発！AI Agent 時代の信頼性と開発効率のためのガードレール/sre-next-2025-link-and-motivation

リンクアンドモチベーション登壇資料（2025/07/11）

100% AI コード生成開発！
AI Agent 時代の信頼性と開発効率のためのガードレール

#srenext #リンモチ

===========================================
【イベント情報】
■イベントページ
https://sre-next.dev/2025/schedule/#slot085

【株式会社リンクアンドモチベーション】
■お問合せ先
　engineer_pr@lmi.ne.jp
■テックブログ
　https://link-and-motivation.hatenablog.com/
■開発組織の公式X
　https://x.com/LinkandM_dev
=============================================

Transcript

1. © Link and Motivation Group 100% AI コード生成開発！ 株式会社リンクアンドモチベーション 川津 雄介 AI Agent 時代の信頼性と開発効率のためのガードレール
2. © Link and Motivation Group 2 自己紹介
3. 3 © Link and Motivation Group 株式会社リンクアンドモチベーション エンジニアリングマネージャー 川津 雄介 Yusuke Kawatsu • SRE・プラットフォームエンジニア • AI で生産性 x20 倍にする取り組みにも従事 • 最近は ELDEN RING NIGHTREIGN をしてます https://github.com/megmogmog1965 https://qiita.com/megmogmog1965 https://x.com/KawatsuYusuke
4. 4 © Link and Motivation Group 会社紹介 創業年月日｜2000年4月7日 上場市場 ｜東京証券取引所 プライム市場 従業員数 ｜約1,500名 (グループ全体) 売上 ｜374億 (グループ全体) ※2024年12月期 事業内容 ｜国内初の組織改善クラウドサービス AI活用 ｜専門チームを立ち上げ、方針・ツール・ナレッジを一元化 株式会社リンクアンドモチベーション
5. 5 © Link and Motivation Group 会社紹介 経営と現場をつなぐ オールインワンのサービス 国内最⼤級の12,870社、532万⼈（※）のデ ータベースをもとに組織状態を可視化・分析可 能。エンゲージメントサーベイだけではなく、 個⼈開発（360度診断）機能やWeb社内報（社 内ポータル）機能もご利⽤可能。 （※）2025年3⽉末時点
6. © Link and Motivation Group 6 本日お話したいこと
7. 7 © Link and Motivation Group 弊社では、昨年より AI Agent を用いた開発へのシフトを開始 「新規プロダクト開発を20倍速にする」 取り組み・研究を行っています 最近では、おおよそ方法が確立され、既存プロダクトの開発 においても同手法を 取り入れるようになりました x20 倍速 新規プロダクト
8. 8 © Link and Motivation Group コード生成比率の目標 新規プロダクト 既存開発 今は平均 20% くらい 目標: 100% 目標: 60%
9. 9 © Link and Motivation Group 弊社での AI の使い分け 本日お話する内容は、弊社では主に Claude Code で実践されております。 作業２ 作業１ 作業３ 作業２ 作業１ 作業３ 1 Issue small issue small issue small issue 直列 並列 順序性ある 一連の作業 完全に独立し た作業 Devin Claude Code (,Cursor)
10. 10 © Link and Motivation Group 特定の AI ツールに依存する話はしません 主に AI Agent の話にはなりますが、Claude Code、Devin など、 特定のツールの使い方等を話しには来ていません。 Devin Claude Code Cursor
11. 11 © Link and Motivation Group 本日のテーマ AI Agent 時代によって訪れた 高速開発 (CD) に対して 本番利用できる意図通りの コード品質 (Q) を生み出したい！
12. © Link and Motivation Group 12 AI での開発がうまくいかない？
13. 13 © Link and Motivation Group 爆速 で実装をしてくれる！ 人間が一日かかる作業もわずか数分で... コーディング AI Agent の良い点 Quality 品質 Delivery 納期 Cost コスト
14. 14 © Link and Motivation Group 特に Claude Code や Devin は、事前に作りたいものを 詳細に伝えて いれば、 実装完了まで一気に 自走 してくれる。 特に Claude Code や Devin XX 機能を 作ってね！ りょ！ 作業リストを作ろう... まずは YY API を作って... 次に ZZ 画面を... ビルド・テスト実行してみて... エラー出たから直して... １ターン (最後まで) できたよ！
15. 一方、みんな困っていること...
16. 16 © Link and Motivation Group なんか 期待してたのと違う のが生成される！ ◦ 思っていた コード (保守観点) と違う（e.g., SOLID原則） ◦ 思っていた 仕様 (機能面) と違う コーディング AI Agent の課題... Delivery 納期 Cost コスト Quality 品質
17. 17 © Link and Motivation Group • 細かいエラー が頻発して、都度修正を指示 • 期待と異なる仕様 で実装され、都度修正を指示 AI が自走できない（人間の介在が多い） XX 機能を 作ってね！✨ できました。 直しました。 エラーに なってる！ 😡 思ってた画面 と違う！ 😡 最初から やり直し
18. 18 © Link and Motivation Group ※ AI CPU 時間 XX 機能を 作ってね！✨ エラーに なってる！ 😡 思ってた画面 と違う！ 😡 実装 時間 実装 時間 ※指示待ち 時間 ※指示待ち 時間 ※指示待ち 時間 速い...？ プロセス全体で見ると実は 速くない...？
19. 19 © Link and Motivation Group ※ AI 開発がうまくいかない時の時間割 実装 時間 実装 時間 ※動作確認 ※指示待ち 時間 ※指示待ち 時間 実装 時間 ※指示待ち 時間 実装 時間 ※指示待ち 時間 実装 時間 実装 時間 ※動作確認 AI より遅いが、認識齟齬が少ない 「実装→確認→訂正指示」の回数の多さ （オーバーヘッド時間の増加） 人間が開発 AI コーディング
20. AI が自走できないのは、何が原因なのか？
21. 21 © Link and Motivation Group AI が自走できず、都度人間の介入を必要するのは、次の２点の原因があると考え ています。 1. AI が自分で ミス に気づけない 2. AI が機能開発の詳細を人間と 期待値調整 できていない 原因は２つあると考えます
22. 22 © Link and Motivation Group ランタイム例外 API 仕様齟齬 データ齟齬 構文エラー 少なくとも、一般的なエラー（コーディングミス）は AI 自身で解決してほしい。 ① AI が自分でミスに気づけない
23. 23 © Link and Motivation Group AI にとっての常識は、開発者の職場 ではなく 世間一般の常識 にあります。 ② AI が機能開発の詳細を人間と期待値調整できていない 丸投げ ログイン機能を 作ってね！ パスワード方式？ OAuth？ 新規にクラス作る？ 既存コードに追記？ DB スキーマ はどうする？ Auth0 とか外部 サービス使う？ ※決まっていないことは、 世間一般の方法に準拠するしかない
24. 24 © Link and Motivation Group 課題 ①、② の解説に入る前に、 弊社の新規プロダクト開発における開発プロセスの全貌を説明します。 次章、開発プロセスの全貌について
25. © Link and Motivation Group 25 開発プロセス
26. 26 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト 開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。 要件定義 デザイン （モックアップ） 実装計画 （AIが作る詳細設計） 実装 （UT & 動作確認） テスト （リリース） + イテレーション
27. 27 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト 開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。 要件定義 デザイン （モックアップ） 実装計画 （AIが作る詳細設計） 実装 （UT & 動作確認） テスト （リリース） + 要所要所で AI（GPTなど）は使いますが、やはり最終的には人間の「判断」が色濃く、AI よりも 人間 の活動比率が高い。 イテレーション
28. 28 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト 開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。 0 → 1 の初期開発 では、React (next.js) のモックアップを v0 や Claude code に生成させて、PdM レビュー。後の開発で AI が参照。 要件定義 デザイン （モックアップ） 実装計画 （AIが作る詳細設計） 実装 （UT & 動作確認） テスト （リリース） + イテレーション
29. 29 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト 開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。 後述しますが、AI に作らせた詳細設計書よりもさらに細かい文書。 AI が作成 し、人間がレビュー・承認 します。 要件定義 デザイン （モックアップ） 実装計画 （AIが作る詳細設計） 実装 （UT & 動作確認） テスト （リリース） + イテレーション
30. 30 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト 開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。 要件定義 デザイン （モックアップ） 実装計画 （AIが作る詳細設計） 実装 （UT & 動作確認） テスト （リリース） + 前述の 実装計画書 がきちんと書けていれば、ほぼ放置（AI 自走）でOK。 イテレーション
31. 31 © Link and Motivation Group 弊社の AI を用いた開発プロセス 0 → 1 の新規プロダクト 開発における弊社の開発プロセスです。 ※デザインまわりのプロセスはプロダクトが成熟したタイミングで従来のプロセス（Figma とか）に変えていきます。 要件定義 デザイン （モックアップ） 実装計画 （AIが作る詳細設計） 実装 （UT & 動作確認） テスト （リリース） + 残念ながらほぼ 100% 人間による手動。 要件定義からテスト仕様書を作るくらいには AI を活用。 イテレーション
32. 32 © Link and Motivation Group ① AI が自分でミスに気づけない ② AI が機能開発の詳細を 人間と期待値調整できていない 次章、①、② の課題に取り組む
33. © Link and Motivation Group 33 ① AI が自分でミスに気づけない
34. 34 © Link and Motivation Group AI の爆速開発（低品質）により、レビュー頻度が激増 👿 AI が生成したコードがバグを含んでいる場合、人間による介入 （動作確認・レビュー）が発生するので生産性は上がりません。 XX 機能を 作ってね！✨ エラーに なってる！ 😡 またエラー が出たよ！ 😡 実装 時間 実装 時間 ※指示待ち 時間 ※指示待ち 時間 ※指示待ち 時間 動作確認＆レビュー 動作確認＆レビュー
35. 35 © Link and Motivation Group 理想的には、こうありたいですね 🌞 昔の開発現場でよく言われていた「妖精さん」ですね。 XX 機能を 作ってね！✨ 寝てたら 終わってた！ 実装 時間 ※指示待ち 時間 ※指示待ち 時間 動作確認＆レビュー １発 完了！
36. 36 © Link and Motivation Group そこで、AI がミスに気づくための「ガードレール」 事前にガードレールを敷くことによって AI Agent に「コードの誤り」 を自分で気づけるようにします。 すると AI が人間の介入を必要とせずに最後まで自走 できます。
37. 37 © Link and Motivation Group アーキテクチャ（※弊社での一例） 弊社で採用している、新規プロダクトを開発する際の 初期アーキテクチャ を紹介 します。 弊社では初期はこのアーキテクチャで実践していますが、恒久的なものではな く、プロダクトが成熟するのに従って都度最適なものに変更 をする予定です。
38. 38 © Link and Motivation Group アーキテクチャ（※弊社での一例） 0 → 1 の新規プロダクト 開発における弊社の開発アーキテクチャです。 コード実装量を低減する目的で Vercel + Supabase を採用してます。 Client Component Route Handler tRPC Server Component PostgreSQL (Row level security) Auth Queue + Functions
39. 39 © Link and Motivation Group 型や静的解析によるコード不備の検知 次の事項を npm run build に仕込むなどして、AI Agent が必ず実施せざるを得 ないクオリティゲート としましょう。 • 型 (TypeScript) により、コード間の呼び出しの不整合はコンパイル時点で AI Agent 自身が認識できます。 • ESLint 等、各種静的解析も導入して、全てパスしなければコードが完成では ないと AI Agent に伝えましょう • もちろん ユニットテストコード を記述し、カバレッジ 80〜90% を目指しま しょう
40. 40 © Link and Motivation Group FE / BE のモノレポ構成（Next.js） フロントエンド、バックエンドコード両方とも モノレポ構成 で実装し、 AI が両者の構造を把握しやすくします。 Client Component Route Handler tRPC Server Component PostgreSQL (Row level security) Auth Queue + Functions
41. 41 © Link and Motivation Group FE / BE のモノレポ構成（Next.js） フロントエンド、バックエンドコード両方とも モノレポ構成 で実装し、 AI が両者の構造を把握しやすくします。 ディレクトリ 説明 / ┗ app React ページ・コンポーネント (*.tsx) 置き場。 ┗ api/trpc/[trpc] Next.js の Route Handler (API) ですが、API は全て tRPC で定義しているので、 ここでは Client Component からの tRPC 受付のみ実装。 ┗ components React 共通コンポーネント (*.tsx) 置き場。 ┗ trpc/routers tRPC による、バックエンド API 定義 (*.ts)
42. 42 © Link and Motivation Group FE / BE のモノレポ構成（Next.js） tRPC を用いて、フロントエンドとバックエンド（クライアントとサーバー）間の コードで 型が共有 されています。 Client Component Route Handler tRPC Server Component PostgreSQL (Row level security) Auth Queue + Functions tRPC Call tRPC Call
43. 43 © Link and Motivation Group バックエンドの API は tRPC で定義 tRPC を用いて、フロントエンドとバックエンド（クライアントとサーバー）間の コードで 型が共有 されています。 フロントからは 関数・メソッドを直接呼び出す のとほぼ近い体験になり、AI Agent 自身が フロントコードの API 呼び出しのバグを認識 できるようになります 戻り値に 型がある API 名 API 引数も きちんと型化
44. 44 © Link and Motivation Group ① のまとめ • 実装時のエラー（バグ）を AI 自身が気づける 仕組みを作る • 本スライドでは取り上げませんが、他にも次のような取り組みが一般的に有効 ◦ 画面上のエラーを知る（Playwright MCP） ◦ 画面仕様との乖離を知る（Figma MCP） ◦ DB データ・Schema の齟齬を知る（Aurora, PostgREST MCP） ◦ 実行時エラーを知る（Sentry 通知）
45. © Link and Motivation Group 45 ② AI が機能開発の詳細を 人間と期待値調整できていない
46. 46 © Link and Motivation Group 期待通りのコードを生成してくれない？ ここで言う「期待するコード」を具体化してみると、次のようになるかと思います。 1. 思っていた 仕様 とは違うものが生成された 2. 概ね期待する仕様の通りだが、細かい点での齟齬や漏れ が頻発する 3. 仕様上は正しいが、保守性の観点 で期待するコード（美しいコード）ではない
47. 47 © Link and Motivation Group なぜ、このようなことが発生するのでしょうか？ それは「人間と AI Agent との間で、細かい期待値調整ができていない」 ために起こります。 丸投げ ログイン機能を 作ってね！ パスワード方式？ OAuth？ 新規にクラス作る？ 既存コードに追記？ DB スキーマ はどうする？ Auth0 とか外部 サービス使う？ ※決まっていないことは、 世間一般の方法に準拠するしかない
48. 48 © Link and Motivation Group チャットによる逐次的な指示 現在の AI によるコード開発は「チャット欄での指示」で行うケースが多いです。 そのため、AI への指示は自然と 全体感が欠如した逐次的なもの になります。 ログインページを作って下さい。 あ、パスワードリセット画面 も必要でしたね。よろしく 言ってなかったですが、実は Email をログインID にしてほしい Users クラスってあるから、そこ に実装してほしかった... 勝手に新規のテーブル 作らないで... Stacks...
49. 49 © Link and Motivation Group AI ルール設定 (*.mdc, CLAUDE.md, …) ルールで救えるのは共通項だけ Cursor の *.mdc などのルール設定は有効ですが、これらは前章のガードレール に近く、個別のシチュエーションでの期待値調整 には向きません。 ディレクトリ構造 コーディング規約 パスワードは 英数記号 16文字 パスワードリセット のボタンも置いて
50. ちなみに、従来の開発では...
51. 51 © Link and Motivation Group 要件定義書や設計書（詳細設計）を書いている 従来の開発では、要件定義書に書かれたとある要件について、「何をどのような 手法・手順で実装するか」を事前に 設計書 に起こしてますね。 この設計書は、より上位のエンジニアの レビュー（承認） を経ているケースが多 く、この時点で 正しいコードの期待値合意 がなされています レビュー 作成 開発者 レビュア 設計書
52. よし、AI に「実装計画書」（≒詳細設計） を書いてもらおう！
53. 53 © Link and Motivation Group 実装計画書とは？ これから実装する内容を、従来の設計書（詳細設計）よりも更に詳細なレベルで AI に記述させた、実装の手順書です。 また、実装状況の 進捗管理 も兼ねており、チェックリスト形式 です 要件定義 デザイン （モックアップ） 実装計画 （AIが作る詳細設計） 実装 （UT & 動作確認） テスト （リリース） + イテレーション
54. 54 © Link and Motivation Group 実装計画書の冒頭には、実装全体のルール・方針を記載。 実装計画書とは？
55. 55 © Link and Motivation Group 実装計画書とは？ 実装完了した 項目に ✅ ファイル・クラス 粒度での詳細設計
56. 56 © Link and Motivation Group 人間は「実装計画書」をレビューする 人間（上位のエンジニアにあたる）が レビュー・承認 をすることで、AI Agent （実装担当のエンジニア）と作りたいものの 期待値の擦り合せ がされます。 レビュー 作成 AI 人間 実装計画書 Users クラスが既にある ので、そこに実装して！ Password クラスを新規作成し 再発行ロジックを実装します
57. 57 © Link and Motivation Group 「実装計画書」の INPUT 情報 入力情報は、ほとんどのケースでは「要件定義書」のことを指します。 画面を生成する場合は デザイン も実装計画書の入力になります。 生成 要件定義書 実装計画書 要件番号 XXX の 実装の仕方
58. 58 © Link and Motivation Group もし、うまく「実装計画書」を作れなかったら...？ それは INPUT 情報の誤り・過不足 であると判断をしなければなりません 生成 要件定義書 実装計画書 足りない要件記述
59. 59 © Link and Motivation Group INPUT 文書の方を正す！ どうしてもやりがちなのが、プロンプトで追加の指示をして直接修正する方法で すが、セッションと共に消えてしまう情報 なのでアンチパターンだと考えます。 生成 要件定義書 実装計画書 V1 実装計画書 V2 プロンプト で直接修正 足りない要件記述 本来、最初から「要件定義書」にかかれているべき 失われる...
60. 60 © Link and Motivation Group INPUT 文書の方を正す！ 元となった INPUT 情報（要件定義書など）を修正 して、 「実装計画書」を 再生成 しましょう。 生成 (失敗) 要件定義書 V1 実装計画書 V1 修正 再生成 要件定義書 V2 実装計画書 V2
61. 61 © Link and Motivation Group チャット欄に直接入力するプロンプトは、少ないほど良い！ チャット欄に直接入力するプロンプトは 少なければ少ないほどよく、 具体的な指示は要件定義書のような 永続的な文書情報 としてあるべきです ドキュメント名と 「作って！」しか言っていない
62. 具体的に見ていきましょう
63. 63 © Link and Motivation Group 「実装計画〜実装」フェーズのプロセス図 実装計画書 を生成する 期待通り 要件定義 + デザイン 実装を開始 全て✅？ 完了した 項目に✅ 実装成功 END YES NO YES YES 実装計画書 コード COMMIT 要件定義 を修正 NO NO St 実装計画 作成Prompt
64. 実装計画書を作る
65. 65 © Link and Motivation Group 1) Markdown の要件定義書 要件定義書は Markdown 形式のテキスト としてリポジトリ管理しています。 子ページに 構造化 TOPページ
66. 66 © Link and Motivation Group 2) AI に実装計画書の作成を指示 AI に「要件番号 XXX の実装計画書を作って下さい」と指示をします。
67. 67 © Link and Motivation Group 2) AI に実装計画書の作成を指示 実装計画書の作り方も「プロンプト」(またはルール) にしています。
68. 68 © Link and Motivation Group 3) 実装計画書 = docs/implementation_plan.md AI が実装計画書を生成します。 • このファイルは git branch で構成管理 されています • feature branch 毎 に内容を丸ごと書き換えています
69. 69 © Link and Motivation Group 3) 実装計画書 = docs/implementation_plan.md AI が実装計画書を生成します。 • このファイルは git branch で構成管理 されています • feature branch 毎 に内容を丸ごと書き換えています main feature A の実装計画書 feature B の... feature C の... マージ（開発完了） すると不要になる
70. 70 © Link and Motivation Group 4) 仕様の観点で誤りがあれば... 要件定義書を修正 して再度「要件番号 XXX の要件を変更しました。実装計画書を 修正して下さい」と AI に指示します。 生成 (失敗) 要件定義書 V1 実装計画書 V1 修正 再生成 要件定義書 V2 実装計画書 V2
71. 71 © Link and Motivation Group 5) 設計の観点で誤りがあれば... 訂正したい設計情報がプロジェクトに共通する ルール である場合は、 ルールファイル (*.mdc , CLAUDE.md など) を修正します。 ルールの修正後、「ルール YYY を変更しました。実装計画書を修正して下さい」 と指示して、実装計画書を再生成させます。 AI ルール設定 (*.mdc, CLAUDE.md, …) ディレクトリ構造 コーディング規約 新しい設計ルール
72. 72 © Link and Motivation Group ※ルールに記載するほどではない設計修正の場合は... 実装計画書の修正内容を 直接プロンプト で指示しましょう。軽微である場合は、 人間が手で直して しまってもかまいません ※ただし、一貫性が損なわれる可能性 は考慮しましょう。 AI は人間よりも結構ちゃんと全体を見てくれています
73. 73 © Link and Motivation Group 6) 実装計画書の完成 開発者（人間）が問題ないと判断したら、実装計画書は完成 です レビュー 作成 AI 人間 実装計画書
74. 実装を開始！
75. 75 © Link and Motivation Group 7) AI Agent に実装を開始させましょう 「実装計画書の項目 ZZZ の実装を行って下さい」と 対象の項目を指示 します。 小さな単位で「実装 → 動作確認」のイテレーションを回しましょう。 一気にやりすぎない
76. 76 © Link and Motivation Group 7) AI Agent に実装を開始させましょう 実装が完了した項目は AI 自身に ✅ をさせます。 終わった 項目に ✅ ✅ ✅ ✅ 次はここから 開始してくれる
77. 77 © Link and Motivation Group ※レビュー（PR）の単位は悩ましいです 実装計画書に対して１PR は 速度、自走率の点で一見理想的 ですが、 従来の開発でも「リリースが出来る最小単位で開発する」ことが ベストプラクティスではあります。 テスト・品質面 を考えると、従来の スモールリリースの観点 は守るべきでしょう
78. 78 © Link and Motivation Group 8) 実装が完了したら... PR を AI Agent に作らせ ましょう ローカルに github cli がインストールされていれば AI Agent が PR を 詳細な Description とともに作成してくれます。 Github MCP でも構いません。
79. 79 © Link and Motivation Group 9) 人間が PR レビューをします 最後に必ず人間が レビュー＆承認 を行います。
80. © Link and Motivation Group 80 まとめ
81. 81 © Link and Motivation Group よく AI Agent は「優秀な部下」である、と言われていますが... ...
82. 82 © Link and Motivation Group 個人的には部下というよりも、新しい入力デバイス これまでは「キーボード叩いて、プログラムを書いて」実装していたのが、「頭 の中の指示」を直接実現してくれる 入力デバイス になった、という感覚です。 実際、周りのメンバーには 音声入力 で AI Agent に指示している人もいます。 設計 指示 タイプ入力 プログラミング プロダクト ※ひとつ飛ばし 音声も可
83. 83 © Link and Motivation Group つまり、結局のところ... 「どう実装するか・すべきか」といった 設計 は 私達開発者が決めているのです。
84. 84 © Link and Motivation Group より高いエンジニアリング力が必要！ 結局 何をどう作るか決めているのは開発者 です。 単に実装が速くなった（タイプしなくなった）だけで、 ものづくりの楽しさは変わらない でしょう。 AI に正しく設計・実装をさせるためにも、 指示を出す 私達エンジニアの技術力がより一層重要になってきます。
85. © Link and Motivation Group 85 END
86. 86 © Link and Motivation Group ブースでお待ちしています！お話しましょう！ さいごにお知らせ リンクアンドモチベーションでは 「SRE」「テックリード」「EM」の仲間を大募集中です！ 公式 のフォローで ノベルティプレゼント！