はじめに こんにちは、エス・エム・エスでエンジニアインターンをしている、佐藤墾です。 半年間インターンをして、この会社についてわかったこと、感じたことを書き残します。 エス・エム・エスに興味を持っているけど、どういう組織かイメージがわかない。そんな方に向けて、この会社が大切にしていること、何を重要視しているかをインターン生の目線で書いてみます。あくまで僕のチームでの話ですが、雰囲気が伝われば嬉しいです。 そもそも私がいたチームは？ 私はカイポケコネクトの開発推進チームに参加しました。カイポケコネクトは介護/障害福祉事業者向けの経営支援サービスで、開発推進はカイポケコネクトの開発基盤やツール整備を担当するチームです。 そこで私はツールの導入提案や不要なコードの整理など、開発体験の改善に関わる仕事をしていました。 働き方について 大学の研究と両立する必要があったので、融通のきくシフトで勤務していました。 私は地方に住んでいたので基本はフルリモートでした。出社しても社員さんもリモートなので人が集まることは少ないですが、もちろん呼んだら来てくれます。 受け入れ体制について チームではレトロスペクティブで振り返りを行っていましたが、自分から気軽に相談するのがまだ得意ではありませんでした。フルリモートだと特にそうで、話しかければ答えてくれる環境ではあるものの、オフィスなら「ちょっといいですか」と相手の様子を見て声をかけられるのに対して、リモートだと相手の状態がわかりません。メンションすると通知が飛ぶので集中を削いでしまいそうで申し訳なく感じたり、返信がいつ来るかわからなかったり。これは自分がリモートでの立ち回りに慣れていなかったのもあると思います。 そこでメンターと週1回の1on1を設けてもらいました。決まった時間に必ず話せる場ができたので、仕事がかなり進めやすくなりました。他のチームでも雑談する時間が専用で設けられていたり、コミュニケーションに対するいろいろな取り組みがありました。 チームの文化 導入したいツールなどはバンバン提案できる環境です。実際に自分も、環境構築が少し複雑で対応に手間がかかっていたので、既存のツールと組み合わせて簡単にできるようにしたいと提案しました。 結局、費用対効果や保守運用の面から見送りにはなりました。ただ、自分の提案に親身に寄り添ってくれて、実際に運用する工程など自分がイメージできていないところの指摘ももらい、この提案に向き合ってくれました。 「便利になるから入れよう」だけでは通らない。それが組織のために、ユーザーのためになっているのかをしっかり考えるチームでした。 また、このチームはインターン生の成長に対して本気で向き合ってくれました。成果を早く出すことよりも、1つ1つのタスクを通じてしっかり学んでほしいという姿勢がありました。その具体的な話は次のセクションで書きます。 自分の成長と変化 プロジェクトに慣れるまで 初めはプロジェクトに慣れるためにも小さな修正から始めました。学生から見るととても大きなリポジトリなので、何がどうなってるのかわかりませんでした。AIを用いてインプットして構造を掴むところから始めました。その後少しずつ慣れていき、いくつかのチケットをこなしていきました。 AIを禁止にしてみた話 インターンを始めた頃は少しでも多く成果を出すために、タスクを並列で回して効率を求めていました。 でもチームから求められていたのはそうではありませんでした。AIが出せるアウトプットのためでなく、自分自身の成長に投資したいのだと。タスクを終わらせることがゴールでなく、そのタスクを通じて学び、今後より大きな課題に対応できる実力をつけてほしいという期待がありました。 色々取り組んできましたが、成果を出すべきと焦りすぎて学習へのリソースを割けていませんでした。フィードバックとして、1つ1つのタスクにより時間をかけて良いから深く理解してみることを提案されました。 そこで実施することになったのが、AIを禁止して開発することでした。自分はこれまで常にAIを使って開発を回してきました。アウトプット自体は出ていてももっと細部まで見る必要があったことを指摘され、一度立ち止まって進めることにしました。 AIを使っていると自然言語でやり取りするので、コード自体をぼんやりとしか見ていませんでした。雰囲気はわかるけど、見るべき細部が見えていない状態です。 でもAIをやめたら、構造体を1つずつ見て繋げるという理解の仕方に変わりました。システムでは多数の関数や変数が複雑に絡み合っていて、境界線がしっかりしているものです。それを自然言語で曖昧にぼかして理解していたから、理解の解像度が低かったのだとわかりました。別に全てを理解する必要はありませんが、輪郭はしっかり見えていないとそれぞれのつながりや作用するものを見つけることができません。 そして仕事の進め方も変わりました。AIを使っていると「〜という方針で実装しますか？」というように結論を早く作ってくれて、承認して速攻で作る、みたいなことはないでしょうか。これをやってしまうと、本当は考えるべきことがたくさんあるのに、検討しないままそれっぽく進めることができてしまいます。 実際にやめてメモに書き出すようにして開発し始めてから、考慮すべきことがたくさんあることを改めて認識しました。今まで気づかないうちに考慮漏れをたくさんしていたんだと思います。たくさんの問題がある中、1on1で相談しながら考えるべき問題と順序を整理しました。そうすることで物事を確実に一歩ずつ進められるようになりました。 いくらAIが書いても責任は自分にあります。AIのスピードに振り回されて自分自身が責任を持てない状況になってしまっては本末転倒です。 だからこそ、AIを活用するのは前提として、その上で自分がどう動いているのか、どういう構造なのかをしっかり理解しておくことが重要だと気づきました。AIをやめたことでその輪郭が見えるようになり、この状態になって初めて責任を持てるようになり、PRも出せるようになったんだと自覚しました。 なぜ、なに、どうやって チケットをもらったときに何が目的かわからない状態では、正しいPRを出せないことを改めて自覚しました。今まではなんとなくで理解して、すぐ「何を作るか」に意識が向いていました。結果、実現しても社員の方から「いや、それじゃなくて」という手戻りが起きていました。 チケットの段階では「何をする」が細部まで決まっていないことも多いです。だからこそ、その背景にある「なぜ」を理解しないと、適切な「何を」を自分で組み立てられないことを痛感しました。 自分は今までの経験で「何を作るか」をすり合わせる大切さを学びました。完全な個人開発ならこれは全て自分の中に答えがあるから必要ありません。しかしハッカソンやインターンで、「何を」を揃えないと正しいものが作れないと実感しました。 今回のエス・エム・エスのインターンでは、そこに加えて「なぜ」が入ってきました。物事の背景や相手の立場に立って初めて、本当に欲しいものがなんなのかを考えることができました。 今までは何かを作れる、Howを実現できるエンジニアが優秀なんだと思っていました。しかしそれだけでは足りず、そこからWhyを理解し適切なWhatを返せる、ここまでできて本当に優秀なエンジニアなんだと学びました。 特にAIの進歩でHowの部分はかなり強力なサポートを得られるようになりました。しかし、まだWhyやWhatをきっちり汲み取ることはAIには難しいと考えています。それを的確に言語化できる人はAIを組み合わせることで、より強力なバフを得られるのだろうと思います。 ただし、全員がそれをできるとは限りません。そこで自分たちエンジニアが正しくWhyを理解し、Whatを組み立てることが今後より重要になってくるのではと感じました。 導入だけでなく運用まで考える 先ほどチームの文化として紹介したツール提案の話ですが、自分自身にとっても大きな学びでした。 自分はここで、導入して便利になる以外にも組織でどう運用するかなど、保守の部分への意識が芽生えました。導入するときにどうやって継続的に負担を減らしつつも効果を出すのかを考える癖がつきました。 半年間のインターンを振り返って エス・エム・エスでの半年間はとても濃い時間で、とても学びが多かったです。何より会社として学習へのコストを惜しまず、成長を喜んでくれる組織でした。 1on1やチームでの振り返りなど適切なレビューをもらえて、新たな気づきや観点がかなり増えたと感じています。 ただ、基本的に受け身ではその気づきを増やすことはできません。手段は人それぞれですが、環境は整っているので自ら動いてその環境の恩恵を受けられるよう、さまざまな気づきが得られるような立ち回りをしてほしいと思います。 そういうカルチャーだったと、半年間いて感じました。 興味を持ってくださった方へ このレポートを読んで、少しでもエス・エム・エスが気になっている方の背中を押せたら幸いです。まずは気軽に応募やカジュアル面談から、私の感じた雰囲気を実際に感じてもらえたらと思います。

クラウドコンピューティングの初期の頃、AWS は世界中の都市で AWS Pop-up Lofts と呼ばれる物理的なスペースで建設業者を対象とした集中学習をサポートしていました。これらのスペースは、スタートアップ起業家、開発者、およびイベント、ミーティング、共同作業で AWS についてもっと知りたいと考えている人が利用できました。最近の生成 AI の登場により、 AWS Gen AI Lofts は世界中でポップアップスタイルのコラボレーションスペースを提供し、スタートアップや開発者に没入型の体験を提供しました。 私たちは、実践的な体験、コミュニティ主導の共有、技術的なコラボレーションを通じて、学生や開発者が学び、つながり、貢献できる常設のコミュニティスペースが必要であることに気づきました。2025 年 7 月にサンフランシスコでオープンして以来、最初の AWS Builder Loft は 22,500 人以上の開発者を迎え、地元の技術コミュニティが一堂に会するハッカソン、ワークショップ、デモナイト、コミュニティ主導のイベントを開催してきました。 2026 年 8 月 18 日、ベルリン、ハイデラバード、サンパウロに新しいビルダーロフトをオープンする計画を発表しました。各場所は、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コラボレーション/コワーキングエリア、イベント主催を提供する常設コミュニティスペースとなり、ドアを通り抜けたい開発者、学生、技術専門家向けに、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ作成スペース、コラボレーション/コワーキングエリア、イベントの開催が可能になります。 そこでは引き続き AWS の専門家に会うことができますが、それ以上に、 AWS User Groups や AWS Student Builder Groups 、すでに参加している独立した開発者グループまで、地域の技術コミュニティの本拠地を作りたいと考えています。テクノロジーコミュニティのリーダーとして、ミートアップを開催するためのスペースの予約を無料でリクエストしていただけます。 なぜ 3 都市なのか この拡張は、各地域の重要な人材とイノベーションの拠点である開発都市が急成長していることを反映しています。 ベルリン : AWS European Sovereign Cloud を立ち上げた後、私たちはヨーロッパの開発者コミュニティへの取り組みを深めています。ベルリンの Builder Loft は、デジタル主権に関する教育セッション、ハッカソン、セキュリティ対策ワークショップ、コミュニティミートアップを開催し、ドイツの成長を続けるスタートアップエコシステムと、より広範なヨーロッパおよび世界のテクノロジー環境をつなぐコミュニティミートアップを開催します。 ハイデラバード : Hyderabad Builder Loft は、インドの開発者に AI のスキルアップ、クラウドネイティブアーキテクチャの探求、次世代アプリケーションを構築する仲間との交流のための専用スペースを提供します。 サンパウロ : ブラジルのクラウド市場は毎年 30 % の成長を遂げており、サンパウロはラテンアメリカのテクノロジーブームの中心に位置しています。Builder Loft は、地域の開発者のハブとして機能し、地域社会、大学、スタートアップネットワークと連携して無料のプログラミングを提供します。 ビルダーロフトでの典型的な一週間 サンフランシスコの Builder Loft では、生成 AI に関する技術的なディープダイブからスタートアップのピッチナイト、学生向けのコーディングワークショップから地域全体の開発者が集まるネットワーキングセッションまで、毎週 4 〜 8 件のコミュニティイベントを開催しています。 スペースは柔軟に設計されています。火曜日の朝、トレーニングルームは 50 人以上の学生でいっぱいになります。夕方になると、スタートアップが潜在的なコラボレーターの部屋に最新のプロトタイプを披露するデモステージに変わります。週末には、コミュニティグループが独自のミートアップを開催します。 このモデルが機能する理由は、コミュニティ自体によって推進されているということです。地元の開発者、ミートアップ主催者、技術リーダーがプログラミングを形作ります。AWS はスペース、インフラストラクチャ、サポートを提供しますが、エネルギーは参加するビルダーから得られます。 今後のイベント を検索するか、サンフランシスコの Builder Loft での 独自のイベントの開催 をリクエストしてください。 ご期待ください Builder Loft は、今後のブログ記事で 3 都市でのオープンについて発表しますので、最新情報にご期待ください！ Builder Lofts の詳細を確認したり、最新情報を入手したりするには、 Rick のブログ投稿 と AWS Builder Loft のページ をご覧ください。 – Channy 原文は こちら です。

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの辻林です。2026 年 7 月 29 日に、大阪オフィスにて「AWS Business Innovation Series – West Japan」の第 3 回を開催いたしました。本シリーズは、西日本のお客様のデジタル変革を加速することを目的に、生成 AI を活用した実践的なプログラムを約 3 ヶ月に 1 回のペースでお届けしているものです。ご参加いただいた皆様に、改めて御礼申し上げます。 本ブログでは、イベントの背景や当日の様子、参加者の皆様からいただいた声をお届けいたします。 はじめに 本シリーズは 2025 年に関西を中心に開催したワークショップの高い満足度を受けて、2026 年は業界を問わず幅広い企業の皆様にご参加いただける形で継続しています。今回がその第 3 回です。 第 3 回のテーマは、第 2 回に続いて Amazon Quick です。ただし切り口を変えました。第 2 回はメール・ファイル・社内システムといった多様なデータソースへの接続と、チャットエージェントの構築が主題でした。今回はもう一つの入口、つまり BI とダッシュボードを起点に据えています。 データを可視化するところまでは、多くの企業がすでに到達しています。難しいのはその先です。ダッシュボードを前にしても「で、次に何をすればいいのか」が決まらない。決まっても、社内を動かす提案の形にならない。今回のプログラムは、この「見えている」と「動ける」の間にある溝を、半日で越えていただくことを狙いました。データを見渡し、AI と対話して深掘りし、外部の事例を集めて、最後にアクションプランと提案資料に落とし込む。そこまでを一気に体験する構成です。 過去開催分についてはこちらをご覧ください。 第 1 回：お試しから卒業！Kiro の仕様駆動開発を本格活用（2026/3/17） 第 2 回：データから業務アクション、展開まで繋げる Amazon Quick ワークショップ（2026/5/29） イベント概要 項目 内容 テーマ Amazon Quick ではじめるデータドリブン実践ワークショップ 日時 2026 年 7 月 29 日（水）13:00〜18:00 場所 アマゾン ウェブ サービス ジャパン 大阪オフィス（中之島三井ビルディング 26F） 参加者 10 社 25 名 満足度 4.13 / 5 タイムテーブル 時間 内容 13:00 – 13:10 オープニング 13:10 – 13:30 Amazon Quick 座学 〜 最新のアップデートをお届け 13:30 – 14:50 Amazon Quick ハンズオン 〜 データドリブンな意思決定体験ハンズオン 14:50 – 15:00 休憩 15:00 – 17:35 Amazon Quick ハッカソン 〜 Quick ではじめるデータドリブン実践ハッカソン 17:35 – 17:50 LT：数字は正しい。でも提案が通らない理由 17:50 – 18:00 クロージング 当日の様子 Amazon Quick 座学 〜 最新のアップデートをお届け 発表資料： Amazon Quick 座学 〜 最新のアップデートをお届け 最初のセッションは、ソリューションアーキテクトの大内より、Amazon Quick の全体像と最新アップデートをご紹介しました。 出発点は「なぜデータ分析をするのか」という問いかけから、勘や思い込みではなくデータに裏付けされた事実で判断する、施策の効果を検証する、次の一手を決めるためにまず現状を把握する — こうした目的のために BI があります。 そしていま多くの BI ツールで起きている「後付け AI」の限界について説明しました。既存の BI 基盤の上に AI 機能を足していくアプローチは、たしかにアナリストの作業を効率化します。しかしその AI が動く土俵は、あくまで BI のパラダイムの中 — データベースやデータウェアハウスといった構造化データに最適化された世界です。ドキュメント、メール、顧客フィードバック、市場調査といった非構造化データは、依然として届きにくいままです。結果として、従来の BI が扱ってきたデータの範囲でしか AI を活用できず、AI 起点の新たなサイロが生まれてしまいます。 この課題に対する答えが、AI を中心に据えた統合プラットフォームという設計です。2025 年 10 月、Amazon QuickSight は Amazon Quick（旧称 Amazon Quick Suite）としてリブランディングされ、これまでの QuickSight は Quick を構成する一機能（Quick Sight）という位置づけになりました。Quick は次の 5 つを軸に構成されています。 BI — 可視化・分析ツールでデータを探索し、インサイトを明らかにするチャートやグラフを作成する スペース — ファイルやデータなど特定の情報を集積し、チームで共有する場をつくる チャットエージェント — データを分析・計画・操作してタスク完了を支援する AI エージェントを構築する フロー — 目標を迅速かつ予測可能に達成するワークフローを作成・共有する リサーチ — 企業内外のデータソースを横断した包括的な分析で、複雑なインサイトや関係性を発見する BI についてはGenerate Analysis による自然言語からのダッシュボード生成、ダッシュボードの内容を理解した状態で質問できるダッシュボード Q&A、SQL を書かずに自然言語で分析クエリを実行できるデータセット Q&A（Text-to-SQL）、そしてダッシュボードを離れることなくチケット作成や通知を実行できるアクション機能をご紹介しました。数日かかっていたダッシュボード構築を数分に短縮できること、そして普段ダッシュボードを見慣れていない方でも自然言語で問いを立てられること — つまりデータの民主化が、この座学の中心的なメッセージでした。 最後に活用イメージとして、路線ごとの遅延傾向をその場で分析して会議中の問い合わせに答える例、AWS 利用料の上位項目を探索してベストプラクティスを調べ、Jira にタスク化して Slack に通知する例などを共有し、後半のハンズオンへ繋ぎました。 Amazon Quick ハンズオン 〜 データドリブンな意思決定体験ハンズオン 続いてソリューションアーキテクトの伊藤より、実際に手を動かすハンズオンです。このハンズオンではダッシュボード × AI × 追加情報の組み合わせでデータの理解を深め、データドリブンな意思決定を体験します。 最初にデータ活用を 4 つの段階で捉えるフレームで示しました。 探せる（Search） — 最低限必要な情報から始める起点 見渡せる（Visibility） — 何がどこにあるかを広げ、関連情報を含む広い範囲が見える わかる（Insight） — 何が起きているか、なぜかを深掘りし、深い考察ができる 動ける（Action） — 伝える / 決める / 作る / 記録する。データで判断し、次の一手を打てる 多くの現場は「探せる」「見渡せる」で止まりがちです。今回のハンズオンは、ダッシュボード × AI × 意思決定のための追加情報の組み合わせによって「動ける」まで到達させることを体験することに目標に置きました。 ハンズオンの流れは次の通りです。サンプルデータから自然言語でダッシュボードを生成する。（見渡せる）ダッシュボードのデータを自然言語で深掘りする。（わかる）リサーチ機能で業界事例やベストプラクティスといった外部データを集め、そこで得た事実と外部情報を合わせて、アクション・改善提案を検討、提案書の作成まで進む。（動ける） 「見渡せる → わかる → 動ける」を、Amazon Quick の中で一続きの操作として体験できる構成です。ここで基本の型を身につけたうえで、後半のハッカソンに臨みます。 Amazon Quick ハッカソン 〜 Quick ではじめるデータドリブン実践 続いてハッカソンでは題材として、あらかじめ用意したユースケースカタログから自業界・業務に近いユースケースを選んでいただきました。ハンズオンで型を覚えたうえで、今度は自分の業務に引き寄せて進める。ここが難所であり、同時に面白さでもあります。用意されたサンプルデータを自社の実態に近づけて調整し、自然言語で要件を伝えダッシュボードを生成し、必要な情報を考え、リサーチで外部の事例やプラクティスを集め、生成されたダッシュボードを起点にAI と対話して深掘りし、収集したリサーチ情報も加えて、アクションプランと提案資料まで仕上げることにチャレンジ頂きました。 終盤は成果をグループ内・全体共有をする場を設けました。選んだテーマとカスタマイズしたポイント、ダッシュボードやリサーチから得た発見とアクションプランを共有します。同じテーマを選んだ方同士では、出発点が同じでも自社の事情を反映させた結果が違ってくる — その差分がそのまま学びになります。 需要予測に踏み込んだ方、経理部門の課題を題材にした方など、業界も切り口も多彩な発表が並びました。 LT：数字は正しい。でも提案が通らない理由 〜 BI が知らない、現場の秘密 発表資料： 数字は正しい。でも提案が通らない理由 — BI が知らない、現場の秘密 最後に 、ソリューションアーキテクトの多田より「数字は正しい。でも提案が通らない理由」というタイトルでLTセッションを行いました。 データを分析したAIからこんな提案が返ってきました。「スーパーのお弁当コーナー、廃棄が多いので仕入れを減らしましょう」 — コスト削減の観点では正しそうですが、実際のスーパーは仕入れを減らしませんでした。なぜなら品揃えの豊富さそのものが集客装置だから。廃棄はその戦略のコストであり、数字だけ見れば「無駄」に見えるものが、実は意図的な投資だったりします。 このように提案が通らない理由は、こうしたビジネスコンテキストがデータに落ちていないことにあります。同じ「未使用の SaaS ライセンスが 63 件」というデータでも、コンテキストを持たない AI は全件の解約を勧めます。一方コンテキストを持つ AI は例えば「1 件は育休中のため未ログインで、9 月に復帰予定。今解約すると違約金が発生するため継続を推奨」と、例外まで教えてくれます。ただ、コンテキストは毎日現場で生まれるものです。都度拾い上げて反映するのは現実的ではありません。 そこで Amazon Quick です。チャット機能とMCP統合を通じて、現場の担当者が自分でビジネスコンテキストを記録できる。現場が主役のまま知識が積み上がっていく。デモでは 記録したコンテキストを踏まえてAIの回答が変わる様子を実際にご覧いただきました。 「数字 + 現場のコンテキスト = 同じ的外れを繰り返さない AI」。ハンズオンとハッカソンでデータと向き合った直後だったこともあり、多くの方に印象的なセッションでした。 参加者の声 イベント後のアンケートから、いくつかの声をご紹介します。 「Amazon Quick が 2 回目だったのでより理解が深まり、さまざまな使い方を学べたので良かったです。毎回テーマが違ってももちろん学びになりますが、複数回触ることで身についた実感がありました。」 「テストデータも準備していただいて、ハッカソンの時間に注力できて、いい体験ができたと感じました。この形式で Quick を社内に紹介するのも良いのかなと思いました。」 学びを今後の業務に活用できそうかという問いには、回答者全員から「活用できそう」との回答が寄せられました。「今回使いきれなかった機能もぜひ学びたい」という声もあり、次回以降のテーマ設計に活かしてまいります。 まとめ 第 3 回「AWS Business Innovation Series – West Japan」では、BI の側面からデータドリブンな意思決定を支援するためのAmazon Quick 活用プログラムをお届けしました。座学で「後付け AI」の限界と AI 中心のプラットフォームという設計思想を押さえ、ハンズオンで型を身につけ、ハッカソンで自社のユースケースでデータドリブンなアクション設計にチャレンジしました。参加者の皆様が、ご自身の業界のデータと格闘しながら提案の形まで作り上げていく姿は、印象的でした。 ご興味のある方は、担当のアカウントチームまでお気軽にお問い合わせください。皆様のご参加をお待ちしております。 本ブログは、ソリューションアーキテクトの辻林 侑が執筆いたしました。