はじめに はじめまして。大阪電気通信大学 情報通信工学部 情報工学科3年の多田早澄です。 2026年 ...

こんにちは！Girls Meet STEM in AWS 運営メンバーの守田です。2026 年 8 月 21 日、AWS は中高生女子の皆さんを 2026 年に開設したばかりの麻布台ヒルズの新オフィスにお迎えし、「自分のアイデアを AI アプリにする」体験をお届けしました。私は普段、アマゾン ウェブ サービス ジャパン合同会社 (以下、AWS) でソリューションアーキテクトとして働いています。 イベント概要 AWS は「Girls Meet STEM」に参加し、東京都港区の麻布台ヒルズの新オフィスにてイベントを開催しました。 「Girls Meet STEM」は、公益財団法人山田進太郎 D&I 財団が大学や企業と協力して実施するツアー形式のプログラムです。中高生女子が STEM（科学・技術・工学・数学）分野で働く人や学ぶ学生、実際の現場に触れることで、将来の可能性を広げる機会を提供します。 今回は 34 名の中高生の方々にご参加いただきました。「AWS ってどんなビジネスをしている会社？」「クラウドってなに？」といった紹介から始まり、生成 AI 体験ワークショップ、オフィスツアー、AWS 社員によるパネルディスカッションを実施しました。特に生成 AI 体験ワークショップに関しては、AI と会話することが当たり前になっている皆様に、もう一歩踏み込んで、 AI を”使う”側から、自分のアイデアを形にする”作る”側へ という体験をお届けしました。 プログラム詳細 1. 生成 AI 体験ワークショップ 〜 自分のアイデアをアプリにする 〜 ワークショップでは、AWS の有志を中心に開発された生成 AI アプリケーション「 Generative AI Use Cases (GenU) 」の「ユースケースビルダー」機能を使いました。ユースケースビルダーは、タイトル・説明・プロンプトテンプレート（AI への指示文）を入力するだけで、コードを書かずに自分だけの AI アプリを作れる機能です。裏側では Amazon Bedrock を通じて生成 AI モデルが動いています。 当日は、まず参加者の方々に「どんな AI アプリがあったら、自分や身のまわりの人が嬉しいか？」を考えてもらいました。テーマが決まったら、ユースケースビルダーにタイトルと説明を入力し、AI への指示となるプロンプトテンプレートを自分の言葉で書いてアプリを作成。完成したアプリを実際に動かして、思ったとおりの答えが返ってくるかを確かめ、うまくいかなければプロンプトを書き直して何度も試す——という流れで、自分だけの AI アプリを一から作り上げていきました。 このワークショップのポイントは、 「AI に何をさせたいかを自分で設計する」 という点です。生成 AI を利用する際は出力を受け取るだけですが、アプリを作る際は、入力項目の定義とプロンプト（AI への指示）の設計を自分で行う必要があります。参加者の皆さんには、この設計プロセスを通じて、アプリ開発の基本的な考え方を体験いただきました。 参加者の方々は、自身の興味や日常からテーマを設定し、テスト対策アプリ、恋愛相談に乗ってくれるアプリ、ファッション相談アプリ、読書感想文作成アプリなど、身近な悩みを解決するアプリを動く形へ落とし込んでいきました。「自分でアプリを作るのは難しいと思っていたが、実際に自分が使いたくなるようなアプリが作れてとても楽しかった」といった声もいただきました。 ユースケースビルダーの基本的な使い方や画面イメージについては、 GenU の開発ガイド で詳しくご紹介しておりますので、あわせてご覧ください。 昨年からのアップデート — 「考えを”図”にしてくれる AI」 今年、参加者から好評だったのが、 生成 AI が文章を”図”に変換してくれる 体験です。GenU のユースケースビルダーは画像の出力ができず、テキスト出力が主ですが、フロントエンドが Markdown 内の mermaid コードブロックを検出し、SVG としてレンダリングする仕組みが備わっています。例えば、「興味を入力すると将来の職業をおすすめしてくれるアプリ」を作った場合、マインドマップ形式で職業を表示することが可能です。 「職業おすすめ AI」のプロンプトテンプレート 先ほど例に挙げた「興味を入力すると将来の職業をおすすめしてくれるアプリ」は、次のようなプロンプトテンプレートで作成できます。難しい設定は必要なく、「新規作成」からタイトル・説明・プロンプトテンプレートの 3 つを入力するだけです。 プロンプトテンプレートには次のように記述しました。 あなたは中高生の進路相談にのるキャリアアドバイザーです。 以下の「興味のある分野」をもとに、関連する職業と必要なスキルをマインドマップで提案してください。 <興味のある分野> {{text:興味のある分野}} </興味のある分野> 作成したアプリで「興味のある分野」に「IT」と入力して実行すると、関連する職業のジャンルから具体的な職種、必要なスキルまでが枝分かれしたマインドマップが表示されます。 図の左上に「図を表示」「コードを表示」の切り替えボタンがあり、 生成 AI が実際に出力した Mermaid のテキストをその場で確認できます 。描画された図は SVG や PNG としてダウンロードすることも可能です。「画像が生成された」ように見えるものが、実際にはテキストから描かれていることが、この切り替えで一目でわかります。 Mermaid （マーメイド）はテキストで図を記述するためのダイアグラム記述言語で、生成 AI が出力しているのは画像ではなく、あくまでこの記述テキストです。参加者にとって Mermaid 形式は見慣れない内容ですが、画像以外にも図を表示する手法があるという観点に気づいた参加者の方もいました。 マインドマップに続いて、タイプ別のおすすめ職業や「今からできること」といった文章も出力されます。図と文章を組み合わせることで、全体像を俯瞰しながら具体的な行動まで確認できる構成になります。 2. オフィスツアー 〜 「働く場所」のイメージが変わる 〜 会場となった麻布台ヒルズの新オフィスをめぐるツアーを実施しました。このオフィスのデザインは日本の四季と伝統的な庭園文化にインスピレーションを得ており、働く人の活力と創造性を高める工夫が随所に散りばめられています。 参加者からは「パソコンがずらっと並んだ部屋を想像していたけれど、全然違って驚いた」「オフィスが綺麗で驚いた」「季節を意識したり、トンボをイメージしたライトなど、建物の工夫が面白かった」といった声が寄せられました。 3. AWS 社員によるパネルディスカッション 〜 進路の「軸」を見つける 〜 AWS で活躍する 4 名の女性社員が登壇し、学生時代の経験や、文理・進路の選択、なぜ今の仕事を選んだのかについてお話ししました。参加者の中には、文理の選択やなりたい職業について悩んでいる方が多くいらっしゃいました。そこで、AWS 社員も同じような悩みを抱えていたこと、そしてどのような興味をたどって今の仕事に行き着いたのかをお話しすることで、進路を考えるヒントを持ち帰っていただく時間となりました。「将来のことはほとんど決められていなくて不安でしたが、いろいろな経歴を経て今の職に就いた社員の方のお話を聞いて、自分なりのやりたいことの軸を見つけていけたらいいなと思いました。」といった感想もいただきました。 参加者の声 「自分好みの生成 AI を作ることができること、いままであまりよく知らなかった職業を知ることができたこと、会社員の方の高校時代のおはなしなど、とても学びが多い時間でした。今回の経験が自分の将来に必ず役に立つと感じました。」 「理系と文系を行き来した方のお話から、モチベーションと自分の中での軸があれば、自分の夢が叶うことがわかりました。」 「プログラミングに興味があり、日常で聞いていた AWS についても知れました。現役社員さんのお話は、進路を決める時にすごくためになりました。社内ツアーで社内を見せていただくことで想像もでき、少し楽しみになりました。」 参加者をサポートした AWS メンバーの声 「アプリを作れたという成功体験に、参加者が喜んでいました。『すごい！』という素直な感想が出たり、うまくいかなかったらサイクルを回すという試行錯誤ができたりと、良い経験になっていたと思います。」 「グループワークでは、進路相談などの雑談も一緒にできました。皆さんやりたいことがたくさんあって素晴らしかったです。」 昨年 2025 年夏に開催した Girls Meet STEM in AWS の様子は、 昨年の開催報告ブログ でご紹介しています。あわせてご覧ください。 著者について 守田 凜々佳 (Morita Ririka) Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心に、AWS をご利用になるお客様を技術面でサポートしています。好きなサービスは Amazon Quick です。週末はヴァイオリンの演奏を楽しんでいます。

この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。 質問 #  うちのチームは既存システムの保守運用が中心です。不具合対応や改善要望への対応がメインで、大きな新機能をスプリントで計画的に作っていくような仕事ではありません。研修で習ったスクラムは新規開発が前提のように見えますし、うちは割り込みも多い。 うちにはスクラムは合わないのではないでしょうか？ 回答 #  合わないのは、スクラムではなく「スクラム解説の前提」のほうです。視点を変えると、保守運用はアジャイルにとってかなり自然な環境です。ウォーターフォール文化が身に染み付いた開発チームは、「最初にすべてを決めない」という考え方に慣れるのに苦労します。一方、保守運用の世界では「最初からすべて決めない」のは“当たり前”です。  さらに言えば、保守運用が向いているのはスクラムの「仕事の管理」の側面だけではありません。スクラムが定義していない、しかしアジャイルに不可欠なもう半分——テストや設計、リリースといった“モノづくりの技術”——を鍛える場として、保守運用はおそらく最良の舞台です。本稿の後半はそこに重心を置きます。  まずは、合う合わないを拙速に結論づける前に、「新規開発と保守運用は、本当に別物なのか」から考え直してみましょう。 「新規開発」と「保守運用」は、本当に別物か #  この質問の土台には、「新規機能の開発」と「保守運用の不具合対応・改善要望対応」はまったく違う仕事だ、という感覚があります。  スクラムを前提に、まずはここを疑ってみます。以下、前者を「新規開発系」、後者を「保守系」と便宜上呼び分けます。  バックログの視点で両者を並べてみると、こうなります。 新規開発系: 作りたい機能が並ぶ → 価値やリスクで優先順位をつける → 小さく完成させて届ける → フィードバックを得て次を決める 保守系: 不具合報告や改善要望が流れ込む → 影響度や緊急度で優先順位をつける → 直して届ける → 利用者の反応や再発状況を見て次を決める  　新規かどうかにかかわらず、価値のある作業項目が流入し、それらに優先順位をつけ、小さく完成させて届け、結果を見て次を判断する。一歩引いてみると、両者は構造的には同じです。スクラムが回そうとしているループそのものを、どちらの「系」も回しています。そしてどちらのバックログも、項目が後から流れ込むことを前提にしたリストです。全件が最初に揃っているべきというリストではありません。  では、何も違わないのかというと、差はあります。ただしそれは「種類の差」ではなく「程度の差」です。 項目のサイズと独立性 : 保守系の項目は小粒で、互いに独立していることが多い。新規開発系は大きく、項目間の依存が強くなりがち 流入の予測可能性 : 保守系は突発の流入が多く、来週何をやるかを今週決めきれない。新規開発系は（保守系と比べて）計画が立てやすい ステークホルダーの期待の形 : 新規開発系には「いつ、何が出るのか」が問われ、保守系には「どれだけ早く、確実に直るのか」が問われる  これらはスプリントの長さ、ゴールの立て方、キャパシティの配分といった「運用パラメータ（第1回参照）」を変える理由にはなりますが、「スクラムをやる/やらない」を分ける理由にはなりません。同じ考え方の上で、パラメータ＝調整のしかたが違うだけです。 スクラムが定義していない「もう半分」 #  もう一歩進めます。ここまでの話は、バックログと優先順位づけ、つまりスクラムが定義する「仕事の管理」の側面でした。しかしスクラムガイドを読み返すと、気づくことがあります。 スクラムは「どう作るか」を一切定義していません。 テストをどう書くか、設計をどう保つか、どの頻度で統合しリリースするか…これらはスクラムの外にあります。  アジャイルのこの「もう半分」を担ってきたのが、XP（エクストリーム・プログラミング）に代表される構築プラクティスです。自動テスト（そしてテストを先に書いてから実装するテスト駆動開発）、リファクタリング（動きを変えずに内部構造を整えること）、継続的インテグレーション（変更を頻繁に統合し自動でビルド・テストすること）、小さなリリース、シンプルな設計。スクラムだけを導入して「スプリントごとに動くものが出てこない」「スピードが落ち続ける」と悩むチームの多くは、この半分が欠けています。管理の枠組みだけあって、その中で回すモノづくりの足腰がない状態です。 保守運用は、その「もう半分」を鍛える最良の舞台だ #  ウォーターフォール文化に染まった開発チームがアジャイルに移行するとき、最大の障害はたいてい「全部決めてから作りたい」という習慣（いや欲求）です。線表を引き、要件を固め、設計を固め、実装へ…この習慣を捨てるのに、多くのチームが何ヶ月も、ときに何年も苦しみます。  ところが保守運用の現場を見てください。  来月どんな不具合が報告されるか、誰も知りません。半年先の対応計画を精緻に立てることに意味がないことを、全員が体で知っています。つまり、 「最初にすべて決めない」状態が、意図せずすでに達成されている のです。開発チームが苦労して手放す習慣が、環境としてそもそも成立しません。  そして、ここからが本題です。保守運用の日常業務は、XPの技術プラクティスの練習問題そのものです。 自動テスト : 不具合を直すとき、「まず再現するテストを書き、それを通す」のは最も自然な手順です。直した箇所が次の改修で壊れないよう回帰テストの網を増やしていくことも、保守の現場では「当然のこと」として受け入れられます。多くの未熟なアジャイルプロジェクトで「テストはリリース間際にやればよい」という誤解（開きなおり？）が平然と通っているのとは大きな違いです。 リファクタリング : 保守系の変更は小粒です。「触ったところを少しだけきれいにして戻す」を毎回やる習慣が、大規模な作り直しをせずにコードを健全に保つ唯一の現実的な方法であり、保守運用は開発者に練習する機会を多く与えてくれます。 継続的インテグレーションと小さなリリース : 項目が独立しているため、1件ずつ統合し、1件ずつ届けられます。「小さく完成させて届ける」サイクルが短く、ビルド・テスト・デプロイの自動化に投資する動機も見返りも、新規開発より明確です。 完成の定義 （何をもって「終わった」とするかのチームの合意）: スプリントごとに何度も「完成」を経験できるので、見積り・分割・「完成とは何か」の合意といった基本動作の練習回数を、新規開発案件よりはるかに多く稼げます。検査と適応のリズムも、障害の振り返りや再発防止という形で日常業務と地続きです。  このように見ていくと、「保守運用にスクラムは合わない」のではなく、むしろ「スクラムの管理の枠組みと、XP的なモノづくりの技術の両方を身につけるなら、保守運用は良い舞台である」という見方が、十分に成り立ちます。 でも限界も知っておこう #  ただし、限界もあります。保守運用で鍛えやすいのはモノづくりの側であって、スクラムの管理の側には練習しにくいことが2つあります。 スプリントゴールで仕事を「束ねる」力 。小粒で独立した項目をこなすだけなら、ゴールは「今スプリントの分を終わらせる」に退化しがちです。バラバラの作業を1つの目的に束ねる練習は、意識しないと発生しません。 価値の優先順位を巡る判断 。「直すのが当然」の不具合が相手では、「もたらす価値に基づいて何を作り、何を作らないか優先順位をつける」という、プロダクトオーナーの筋トレの機会が乏しくなります。  ほぼアジャイル初学者ばかりのチームが、いきなり本番開発に突撃して失敗している現場を少なからず見ていると、「まず保守運用でモノづくりの技術を身につける」→「新規開発でゴールやPOの筋トレに取り組みながら開発を進める」というアプローチは、十分に検討に値すると思います。  とりわけ日本では、この「モノづくりの技術」への投資が構造的に不足しがちです。経営層の中には、アジャイルを「早い、安い」という文脈で捉えている方が少なくありません。その結果、体制の編成は単価優先になり、育成への投資が省かれ、設計からコーディング、テストに至る“モノづくり”の能力がチームとして整わなくなります。スクラムの研修は受けたが、テストの自動化もリファクタリングも誰もやったことがない——そんなチームが「スクラムを始めた」と称して本番開発に突撃する光景は、珍しくありません。責めるべきは個々のエンジニアではなく、この編成と投資の意思決定です。  もっともこの意思決定も、コスト削減の制約の下では、その場その場では合理的な選択ではあります。合理的な選択の積み重ねが望まぬ結果に行き着く——この構造は、次回からの更改案件の話でも繰り返し登場します。  私見では、これがアジャイル開発の失敗の大きな要因のひとつです。保守運用を鍛錬の舞台にする提案は、この足腰を日常業務の中で鍛え直す提案でもあります。  経営層の方に、「早い、安い」の代わりに期待していただきたいのは、「変更1件のリードタイムが縮む」「切替やリリースの事故が減る」「見積の外れ幅が狭まる」という、測れる変化です。これらは、本連載の今後の回で採り上げようかと考えています。  そしてもちろん、開発チームを「価値の創造エンジン」という目で見ていただきたい。コストセンターとして単価を削る対象ではなく、 投資して育てる対象 として。 それでも現場で困ることへの処方 #  保守運用へ適用するとして、よく起こるだろう困りごとへの対処法もいくつか挙げておきましょう。 スプリントゴールが立てられない  前述したようにゴール設定はなかなか難しいかもしれません。スプリントを回し始めて数ヶ月のチームなら、ここでいっそのこと割り切って、ムリにゴール設定せず、まず「自動テストとリファクタリングを日常の手順に組み込む」といったモノづくりの基本動作に集中してもいいんじゃないかと思います。  もちろん、「ゴール決めを禁止する」意図はありません。ゴールを「機能のまとまり」で立てようとすると詰まります。改善・削減・安定化の観点で考えると立てやすくなるでしょう。「今月のアラート件数を半減する」「この手順書を廃止できる自動化を完成させる」「問い合わせ上位3件をFAQ化して問い合わせを減らす」。これらは立派なスプリントゴールであり、前述の「束ねる力」の練習にもなります。 割り込みで計画が壊れる  まず1〜2スプリント、割り込みの件数・時間・発生元を記録し、感覚ではなく実績の比率で「計画枠」と「割り込み枠」を分けてキャパシティを設計してください。詳しい運用（記録のとり方、当番制、受付の一本化など）は、第12回あたりでまとめて扱う予定です。 そもそもスプリントという区切りが実態に合わない  割り込みが恒常的に過半を占めるようなら、スクラムにこだわらず、カンバン（スプリントを区切らず、流れで仕事を管理する手法）の併用・移行を正面から検討してください。流れてくる仕事を順に引き取り、流れの速さと詰まりを改善するカンバンは、フロー中心の現場の実態に素直に合います。  スクラムは目的ではなく手段です。「スクラムをやめる」ことは「アジャイルをやめる」ことではありません。 なぜこの質問は30年繰り返されるのか #  理由は単純で、アジャイルの解説・研修・成功事例のほとんどが「新機能を開発するチーム」を暗黙の主人公にして書かれてきたからです。読者の多数派が保守運用に携わっているにもかかわらず、教材の主人公は常に新規開発チームでした。加えて日本では、新入社員研修でウォーターフォール型の開発はしっかり教えられる一方、アジャイルはほとんど扱われません。「教材がない」状態は、キャリアの入口から始まっているのです。  だから保守運用の実践者は、世代が替わるたびに「自分たちは例外なのではないか」「新しいアプローチに触れる機会が奪われているのではないか」という同じ不安を抱きます。  しかし本稿で見たように、例外なのは現場ではなく教材の前提のほうです。「先が読めない中で、小さく完成させ、学びながら進む」というスクラムの舞台装置は整っている。そのうえ、スクラムが定義しないモノづくりの技術を鍛える練習問題が、毎日流れ込んでくる。  保守運用は アジャイルの周縁ではなく 、むしろ その足腰を作る場所 だと考えてはいかがでしょうか？ 次回: 「アップグレード案件の『現行機能保証』にどう向き合う？」