はじめに

2026年8月3日、当社では社内LT会（Lightning Talk）を開催しました。

今回共有されたのは、仕事道具としてのキーボード、主要クラウドの比較、生成AIを活用したテスト自動化、提案活動の振り返り、AWSの新機能など、実に幅広いテーマです。

冒頭では、メンバーの一人がPMO関連資格の試験に合格したことも報告されました。今後は、実際に勉強したからこそ分かる学習のポイントや出題傾向を社内へ共有し、ほかのメンバーが挑戦する際の心理的なハードルを下げていく予定です。

資格取得を個人の成果だけで終わらせず、その経験を次の挑戦者へつなげていく。この姿勢は、当社がLT会を開催する目的にも通じています。

今回の発表テーマは、一見すると互いに関係がないように見えるかもしれません。しかし、すべてに共通していたのは「個人が得た知識や経験を、組織で使える知恵に変える」という姿勢でした。

成功事例だけでなく、うまくいかなかった取り組みや、そこから改善したプロセスまで率直に共有された、今回のLT会の様子をお届けします。

Talk 1：毎日触れる道具だからこそ、こだわってみる

続いてのテーマは、エンジニアにとって身近な道具である「キーボード」です。

キーボードには、テンキーを備えたフルサイズから、テンキーレス、60％サイズ、数字キーまで省略したコンパクトモデルまで、さまざまな種類があります。

キー入力を検知する仕組みも一つではありません。一般的なメンブレン方式、軸の種類によって音や押し心地が変わるメカニカル方式、物理的な接点を持たない静電容量無接点方式など、それぞれに異なる特徴があります。

発表では、社内メンバーが愛用する複数のモデルも紹介されました。

軽快な打鍵感を重視したもの、プログラマーから支持されるコンパクトモデル、クラウドファンディングから生まれた製品など、選び方にも使う人の個性が表れます。

キーボードを変えたからといって、作業速度が劇的に上がるとは限りません。しかし、心地よい打鍵感や音が、仕事を始めるきっかけやモチベーションにつながることはあります。

毎日使う道具だからこそ、自分に合うものを選ぶ。小さな工夫も、気持ちよく働くための大切な要素だと感じられる発表でした。

• 関連資料：LT会資料_Talk1.pdf

Talk 2：AWS・Azure・Google Cloudは何が違うのか

2つ目のセッションでは、AWS、Azure、Google CloudにおけるCDNとネットワーク設計の違いが取り上げられました。

同じ「クラウドサービス」であっても、リソースの考え方や構成方法はそれぞれ異なります。

CDNでは、AWSはAmazon CloudFront、AzureはAzure Front Doorを利用し、ストレージやAPIなどのオリジンと接続します。独自ドメインとの連携も比較的シンプルです。

一方、Google CloudのCloud CDNはロードバランサーの機能として提供されます。独自ドメインが自動的に払い出されるわけではないため、ロードバランサーのIPアドレスとDNSレコードを関連付ける設計が必要です。

ネットワークにも大きな違いがあります。

AWSのVPCはリージョン単位で構築し、複数リージョンを接続する場合には、VPCピアリングやTransit Gatewayなどを検討します。

対して、Google CloudのVPCはグローバルリソースです。サブネットをリージョン単位で配置するため、リージョンをまたいだ構成を比較的シンプルに設計できます。AzureのVNetでも、サブネットが複数の可用性ゾーンをまたぐという特徴があります。

重要なのは、サービス名を対応表として覚えることではありません。それぞれのクラウドが、どの単位でリソースを管理しているのかを理解することです。

違いを正しく捉えることで、特定のクラウドの考え方をそのまま持ち込むのではなく、要件に合った構成を選択しやすくなります。

• 関連資料：LT会資料 Talk2

Talk 3：生成AIを活用したE2Eテスト自動化——精度を高めた段階的アプローチ

生成AIを活用し、E2E（End-to-End）テストの作成を効率化する取り組みが共有されました。

当初は、利用可能な設計情報から自動テストを直接作成しようとしましたが、複数の画面にまたがる操作や前提条件を十分に捉えられませんでした。

そこで、必要な情報を整理し、先にテストシナリオを作成・確認してから、自動テストへ変換する方法に変更しました。段階的に進めることで、テスト作成の精度が向上し、データや仕様に関する確認事項も早期に把握できるようになりました。

テストで問題が見つかった場合は、AIにそのまま修正させず、人が原因と対応方針を確認します。AIは情報整理や作成作業を支援し、仕様判断と最終承認は人が担う運用です。

今回の取り組みを通じて、AIと人の役割を適切に分けることが、テスト業務の効率と品質を両立する鍵だと分かりました。

Talk 4：生成AIを「知る」から「組み込む」へ

続いて、外部のクラウド事業者が主催する生成AI開発プログラムが紹介されました。

このプログラムでは、生成AI基盤を使った実装や、SaaS・パッケージ製品へのAI機能の組み込み方を段階的に学びます。フェーズが進むと、技術担当者と具体的なプロダクトへの導入方法について相談できる内容です。

生成AIは、エンジニアだけのテーマではありません。

「どの業務にAIを使うのか」「導入によって、どのような価値を生み出すのか」を考えるには、PMやPMO、コンサルタントなど、プロジェクトを推進するメンバーの視点も欠かせません。

当日は複数のメンバーが参加を希望し、新たな学びへ踏み出しました。関心を持った人がすぐに手を挙げ、学びの機会につなげる。そんな行動の速さも、今回のLT会を象徴する場面でした。

Talk 5：提案で大切なのは、方法論より顧客理解

5つ目のセッションでは、プロモーション活動と提案活動の振り返りが共有されました。

プロモーション活動——継続的な発信で顧客との接点をつくる

プロモーション活動では、動画コンテンツやSNSでの情報発信、他社との共同ウェビナーなどを継続しています。

こうした取り組みを通じて、既存顧客から問い合わせをいただくなど、情報発信が新たな接点につながり始めています。

自社の知見や取り組みを継続的に発信し、顧客が必要とするタイミングで思い出してもらえる関係をつくることが、プロモーション活動の重要な役割です。

提案活動——方法論よりも顧客理解を優先する

提案活動では、顧客の課題を具体的な利用場面へ十分に落とし込めず、提案の解像度を高めきれなかった経験が共有されました。

この経験を踏まえ、公開情報をもとに事業環境や課題の仮説を整理し、初回の打ち合わせでは結論を押しつけず、認識を合わせることを重視しました。対話を通じて仮説を更新し、顧客への理解を深めることが、より良い提案につながるという学びを得ました。

プロモーションによって顧客との接点をつくり、丁寧な事前調査と対話によって信頼を深める。
この二つを連動させることが、より良い提案活動につながるという学びが共有されました。

• 関連記事：「社長！あなたの会社教えてください。」に出演　共催ウェビナーのお知らせ

Talk 6：AWS Lambda開発の最初の一歩を簡単に

最後に紹介されたのは、AWS Lambdaのコンソールに追加された、AIコーディングツール向けのセットアッププロンプトです。

これは、ボタンを押すだけでLambda関数が自動作成される機能ではありません。コンソール上に表示されたプロンプトをコピーし、対応するAIコーディングツールへ貼り付けて利用します。

プロンプトを読み込ませることで、AIはLambda開発に必要な前提条件を把握し、AWS SAMやAWS CDKを使ったサーバーレス構成の提案、IAMポリシーの検討、エラー調査などを支援できるようになります。

これまでは、AIにAWSのドキュメントを参照させるための連携機能や開発環境を、利用者が個別に設定する必要がありました。あらかじめ用意されたプロンプトを使えば、その初期設定にかかる手間を減らせます。

特に、AIコーディングツールやサーバーレス開発をこれから始める人にとって、最初のハードルを下げる機能として期待できます。

• 関連資料：LT会資料 Talk6

おわりに

今回のLT会では、仕事道具のような身近なテーマから、マルチクラウド、生成AIによるテスト自動化、顧客提案の改善まで、多様な知見が共有されました。

なかでも共通していたのは、「便利な技術を使うこと」自体を目的にしない姿勢です。

AIを使ったE2Eテストでは、いきなりコードを生成させるのではなく、先に情報を整理し、テスト項目書をつくることで精度を高めました。提案活動では、方法論を説明する前に、顧客を深く理解することへ立ち返りました。資格取得も、個人の実績で終わらせず、次の挑戦者へ学びを共有しようとしています。

技術が進化しても、成果を生み出すために必要なのは、課題を正しく捉え、試行錯誤から学び、得た知識を周囲へ還元することです。

成功だけでなく失敗も持ち寄り、個人の経験を組織の知恵へ変えていく。これからも当社では、LT会を通じて、職種や役割を越えた学びと対話を育てていきます。

次回のLT会もお楽しみに！