コーディング中の面倒な作業をGitHub Copilotに支援してもらう

本記事は  【Advent Calendar 2024】  23日目の記事です。
🌟🎄  22日目  ▶▶ 本記事 ▶▶  24日目①  🎅🎁

はじめに

こんにちは、草野です。
明日はクリスマスイブですね。私の部署では上司のみなさまからケーキのプレゼントがあるらしいので、それを楽しみに今日も頑張っています！

最近 GitHub Copilot を使う機会があり、一瞬でその魅力に取り憑かれてしまったので、プライベートのアカウントにも導入してみました。
今回は簡単に導入方法を記載したうえで、開発効率向上に繋がりそうな活用法を考えてみたいと思います。

想定している読者

• 普段からある程度開発をしている人で、面倒な作業はAIに任せたいと思っている人

私自身の普段の業務が開発寄りであること、またかなりの面倒くさがりな性格のため、偏った視点になってしまっていることをご容赦ください。

GitHub Copilotを個人開発で利用してみる

GitHub CopilotはGitHubアカウントを持っていれば簡単に利用することができます。
有料プランへの加入が必要ですが、個人用プラン（Copilot Individual）であれば 10 USD/月のうえ、無料トライアル期間もあります。
（※トライアルの利用であっても、住所とクレジットカード情報の入力が必要です。住所は英語表記で書く必要があるので少し大変です……。）
github.com

＜追記＞
なんと2024年12月19日からVS CodeではGitHubアカウントを持っていれば無料で使えるようになったようです！
リクエスト件数に上限があるなど一部制限はありますが、GitHub Copilotに興味がある方はこれを機に試してみてください！
code.visualstudio.com

GitHub Copilotの登録が完了したら、次はIDEに導入してみます。
今回はJavaの開発をしたいということもありIntelliJへ導入してみますが、VSCodeなどほかのIDEにも同じように簡単に導入できます。

1.GitHub Copilotプラグインをインストールする
まずはIntelliJのマーケットプレイスからこちらのプラグインを導入してください。
plugins.jetbrains.com 2. GitHubにログインする
ツール＞GitHub Copilotを選択し、GitHubにログインしてください。
このとき、IntelliJ上にDevice codeが表示されます。
別途ブラウザ上でGitHubが開くので、表示されたDevice codeを入力して認証を行ってください。
あとは画面の指示に従って進めていくだけで、IntelliJ上でGitHub Copilotが利用できるようになります！

開発に活用できそうな使い方を考えてみる

今回は、基本的な操作方法やショートカットなどの説明は割愛して、若手バックエンドエンジニア目線で開発効率向上に繋がりそうな活用法を考えてみたいと思います。
ここで押さえておきたいのは、Copilotの役割についてです。
Copilotは、和訳である「副操縦士」の名は体を表すように、作業の支援を担うのが本来の役割です。
それをふまえて、エンジニアとしてもまだまだ未熟な私がこのあたりの支援からなら任せてみてもいいいかも？と思った活用法を列挙していきます。

モデルを作成してもらう

ドメインやエンティティなどは設計時に具体的な内容が決まっている場合も多いですよね。
フィールドが`2、3個のモデルなら手書きでも問題ないですが、フィールド数が多いモデルは書くのがちょっと手間かもしれません。
そういったときに設計書をもとにさくっとCopilotに作ってもらうのはアリかもしれません。
私は英語が苦手で命名に時間を使ってしまいがちなので、日本語のプロンプトをもとにいい感じの命名をしてくれるのはかなりポイントが高いです。

ライブラリを使ってリファクタリングしてもらう

先ほど提案してもらったモデルは、Getter/Setterメソッドがベタに書かれていましたが、Lombokのアノテーションに置き換えたいと思ったとします。
アノテーションを使うにはbuild.gradleに追加の記述が必要なのですが、一旦そのことは無視して命令してみます。
指示通りに対象のクラスを修正してくれるだけでなく、ライブラリが足りていないからbuild.gradleに追加してね、と教えてくれました。
今回build.gradleにライブラリの依存関係を記載していない状態で命令したのでこのような提案をしてくれましたが、すでに記載されている状態だと提案してきません。
このことから、複数ファイルを参照の上で最適な提案をしてくれていることがわかります。
私はなんとなく生成AIは単一ファイルしか見てくれないという偏見があったのですが、ワークスペース全体を見てこういった提案をしてくれることに初見ではかなり感動しました。
やりたいことを命令するだけで簡単に環境構築を行うことができるので、sandboxや学習用環境を作るときにも便利そうです。

コメントを書いてもらう

クラスやメソッド単位でjavadocのようなコメントをきちんと書くのはわりと大変です。
そんなときもGitHub Copilotにお願いしてしまいましょう。
明示的に型情報を書くように指示すると型情報までを書いてくれます。 柔軟性があるので、プロンプトを工夫することで自分の好みやコーディング規約に沿ったコメントを書かせることが可能です。
いわゆる生成AIっぽい文章が出力されるので適宜人力で修正が必要ですが、コメントの土台を書いてもらうには十分だと思います。

コメントから実装を提案してもらう

先ほどとは反対に、コメントから実装の提案をしてもらうことも可能です。
コメントを書くと薄い文字色でコードサジェスチョンしてくれるので、その提案を採用したければTABキーを押すだけで簡単にコードを書くことができます。
複雑なロジックを持たないメソッドであれば、この提案だけである程度形になりそうです。
ちなみに、今回はあらかじめsaveメソッドを定義したRepository Interfaceをインジェクションしてあげているので、コメント内容すらもサジェスチョンしてくれました。便利。

ドキュメント化してもらう

コード内のコメント以外にも、実装をドキュメントとして書き起こすこともできます。
仕様書が整備されていないプロジェクトのドキュメント化に対しても有用ですが、ライブラリやフレームワークの仕様をささっと確認したいときにも便利です。
さきほどのGetterアノテーションに対して説明してもらうとこんな感じの結果が返ってきます。

テストを書いてもらう

テストを書くことはもちろん大切ですが、ある程度網羅するように書いていると、冗長になったりテストコードを書くことが実装コードを書くこと以上に大変……という本末転倒な事態になってしまうことも珍しくはありません。
そんなときはGitHub Copilotを頼ってみるのもいいかもしれません。
テストケースが決まっているのであればそのケースをもとにテストコードを作成してもらうのもよいですし、単に「xxメソッドを全網羅するようなテストコードを書いてください」といった雑な指示でも通ります。
もちろん人の目でのレビューは必要となりますが、うまく活用することで開発効率はかなり向上するはずです。

おわりに

いかがでしたでしょうか。
生成AIは業務で使用するには制約がつくことも多いですが、個人開発や学習に利用する分にはうまく使えばかなり有用だと思います。
設計書を丸投げしてロジックを丸々書いてもらうこともできますが、個人的には普段の開発においてちょっと歯がゆさを感じているところから使っていくのがいいんじゃないかなと感じました。

ただ、生成AIを適切に利用するためには、やはりコーディング知識や言語仕様をある程度理解しておく必要があります。
将来的にどうなるかはわかりませんが、今のうちに知識を蓄えておくことで、生成AIがより発展した未来でもうまく共存できるんじゃないかなと思っています。
2024年ももうすぐ終わりますが、これからも日々精進していこうと思いました！
メリークリスマス！

AWS CodeBuildを使ってAndroidアプリをビルドしてみた

本記事は  【Advent Calendar 2024】  22日目の記事です。
🌟🎄  21日目  ▶▶ 本記事 ▶▶  23日目  🎅🎁

はじめに

こんにちは。クラウド事業推進部の松野です。 普段は主にモバイルアプリの開発・運用を行っています。

今回はアプリのビルドサービスを試してみようと思います。
アプリのビルドを自動化している方は多いと思うのですが、私はあまり利用してきませんでした。
バイナリを作成する頻度が低いのもあって、普段は手動で対応することがほとんどです。

Jenkinsは以前使ったことがあるのですが、ほかもいろいろ試してみたいと思っていたので、 今回はモバイルアプリ以外で利用したことのあるCodeBuildでAndroidアプリをビルドしてみました。

AWS CodeBuildとは？

AWSが提供するフルマネージドなビルドサービスです。
コードのビルドやテストを自動でやってくれます。
従量課金制で必要最小限のコストで利用できます。

AWS CodeBuild（継続的スケーリングによるコードのビルドとテスト）| AWS

CodeBuildプロジェクトの作成

CodeBuildでアプリをビルドするための設定をしていきましょう。

ソースプロバイダの選択

CodeBuildのソースプロバイダはGitHub、 Bitbucket、 GitLab、S3、CodeCommitから選択可能です。
私はGitHubにアプリのソースを配置しておいたので、GitHubで設定しました。

ビルド環境の設定

AWSマネージドの環境にはandroid-sdkは入っていませんので、インストールする必要があります。 Dokerイメージを設定できるので、今回はDockerイメージを使いました。 自分で作ってもいいですし、とりあえずビルドしてみるならDockerHubで探して利用でもいいと思います。

Dockerイメージを使う場合は「環境イメージ」を「カスタムイメージ」に設定します。 「コンピューティング」はカスタムイメージに設定するとEC2しか使えません。 環境タイプ以降の設定は利用するDockerイメージに合わせて設定してください。

ちなみにMacの環境は選べないので、iOSアプリをビルドする場合は別途EC2などにMacのサーバーを立てる必要があります。

Buildspecの記載

Buildspecとは、ビルド実行時のビルドコマンドや設定を記載するYAML形式のファイルです。
CodeBuildでは 今回はビルドしてapkファイルを作成までを実施しようと思いますので、以下のように記載してみました。

version: 0.2

phases:
  build:
    commands:
      - ./gradlew assembleRelease
artifacts:
  files:
    - app/build/outputs/apk/debug/app-debug.apk

Dockerイメージを利用しない場合はandroid-sdkのインストールをするように記載します。
以下ドキュメントを参考にカスタマイズしてみてください。 docs.aws.amazon.com

アーティファクトの設定

できあがったapkの置き場所を設定します。 私はS3バケットのapkフォルダ配下に保存するように設定しました。

これ以外の設定はこだわりがなければデフォルトでよいです。 そのままプロジェクトを作成します。

CodeBuildでビルドしてみる

環境ができたらいざビルド！ 「ビルドを開始」を押下してビルドしてみましょう。
ステータスが最終的に「成功」となれば完了です。

今回の設定であれば、「ビルド詳細」タブのアーティファクトにあるS3バケットにapkファイルが作成されます。
指定したフォルダ内でapp/build/outputs/apk/debug/app-debug.apkで作成されていました。

ちなみに

今回ソースプロバイダをGitHubにしていますが、それならGithub Actionsを使う方が簡単です。
iOSもワークフローのYAMLを記載だけでビルドできるので、Mac環境を別途作らなくても問題ありません。

例えばAndroidで検索したらAndroid向けのワークフローが出てきますので、これをベースにカスタマイズしていけばよいです。

CodeBuildで実施した内容と同じことをするなら以下のようになります。

name: Android CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: gradle

    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
      
    - name: Build with Gradle
      run: ./gradlew assembleRelease

    - name: Upload APK
      uses: actions/upload-artifact@v4
      with:
        name: app-debug.apk
        path: app/build/outputs/apk/debug/app-debug.apk

まとめ

CodeBuildはモバイルアプリ向きではないのでもっと大変かと思っていましたが、Dockerイメージを使えるので想定より簡単にビルドできました。
ただandroid-sdkは用意しないといけないですし、iOSをやろうと思うとMacのサーバーの準備も要るので、やはりGithub Actionsなど他サービス使うほうがいいですね。
AWSサービスとの連携はCodeBuildのほうがしやすいので、AWSを利用しているプロジェクトの場合はCodeBuildを利用しても良いと思います。
もっとモバイルに特化したサービスもあるようなので、今後も別のサービスやもっと運用に近い設定をいろいろ試してみようと思います。

参考

https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/welcome.html https://aws.amazon.com/jp/blogs/mobile/automatically-build-your-android-app-with-aws-codebuild/

TerraformとCDKのコードの書き方を比較してみる

本記事は  【Advent Calendar 2024】  20日目②の記事です。
🌟🎄  20①日目  ▶▶ 本記事 ▶▶  21日目  🎅🎁

こんにちは、後藤です。
今回はIaCツールの代表格であるAWS CDKとTerraformについてのお話です。
AWSリソースの管理にはCloudFormationを使われるシーンもありますが、近年の注目度や利用率を見るとAWS CDKかTerraformを採用しているケースが多いです。そのため当記事ではAWS CDKとTerraformに焦点を当てて比較し、その中でも選択の決め手に大きく関わるコードの書き方に着目したいと思います。
私自身、CDKとTerraformを使い込んできましたが、IAMリソースの作成において両者の違いが顕著に感じられましたので、IAMリソース作成の具体例を通して、これらの特徴の違いを比較していきたいと思います。

そもそもCDKとは

CDKとはAWSが提供するインフラコード化のためのフレームワークで、AWS環境に特化したインフラ管理に適しています。CDKの内部ではCloudFormationを使われており、TypeScriptやPythonどの一般的なプログラミング言語を使って定義できるため、より柔軟なプログラミングが可能です。抽象化という概念があり、すべてのパラメータを記載せずともベストプラクティスに沿ってツール側が自動で設定適用するようにすることも可能で、これが非常に魅力的です。
ちなみにCDK for Terraformという、CDKの内部で動作しているのがCloudFormationではなくTerraformになっているツールも存在しますが、採用率が比較的低いため本記事では割愛します。

そもそもTerraformとは

TerraformはHashiCorp社によって提供されているインフラ構築ツールで、HCL（HashiCorp Configuration Language）という専用言語を使って、クラウドインフラをコードで定義します。AWS以外のクラウドプロバイダー（Azure、Google Cloudなど）や、オンプレミスのインフラも管理できるため、マルチクラウド戦略に柔軟に対応します。

コード量の比較

それでは実際に比較していきましょう。まずはコード量の違いです。
CDKを使って、最低限の設定で以下リソースを作っていきます。
・EC2
・S3
・IAMロール (S3参照権限有)
・EC2にIAMロールをアタッチ

CDKを使ったリソース定義部分

#EC2作成
  const instance = new ec2.Instance(this, 'Instance', {
    vpc: vpc,
    instanceType: ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.MICRO),
    machineImage: new ec2.AmazonLinuxImage({ generation: ec2.AmazonLinuxGeneration.AMAZON_LINUX_2023 }),
  });

#S3作成
  const bucket = new s3.Bucket(this, 'my_Bucket', {
    bucketName: 'mybucket2024-example'
  });

#S3への参照権限を持ったIAMロールをEC2に付与
  bucket.grantRead(instance);

続いてTerraformのコードです。同様の構成を作ると以下のようになります。

Terraformを使ったリソース定義部分

#EC2作成
resource "aws_instance" "ec2" {
  ami           = "ami-xxxxxxxxxx"
  instance_type = "t2.micro"
  subnet_id = "subnet-xxxxxxxxx"
  iam_instance_profile = aws_iam_role.role.name
}

#S3作成
resource "aws_s3_bucket" "s3" {
  bucket = "mybucket2024-example"
}

#IAMロール作成
resource "aws_iam_role" "role" {
  name = "ec2-example"
  assume_role_policy = << -EOT
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "ec2.amazonaws.com"
        },
        "Action":  "sts:AssumeRole"
      }
    ]
  }
  EOT
}
    
# インスタンスプロファイル設定
resource "aws_iam_instance_profile" "Instance-profile" {
  name = aws_iam_role.role.name
  role = aws_iam_role.role.name
}

#IAMポリシー作成
resource "aws_iam_policy" "policy" {
    name = "example-policy"
    policy = << -EOT
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": [
                    "s3:GetBucket*",
                    "s3:GetObject*",
                    "s3:List*"
                ],
                "Resource": [
                    "arn:aws:s3:::mybucket2024-example",
                    "arn:aws:s3:::mybucket2024-example/*"
                ],
                "Effect": "Allow"
            }
        ]
    }
    EOT
}

#IAMポリシーをIAMロールにアタッチ
resource "aws_iam_policy_attachment" "attach" {
  role = aws_iam_role.role.name
  policy_arn = aws_iam_policy.policy.arn
}

一目瞭然でCDKの方がコード量が少ないですね。コード量が少ないと可読性が高く、記載ミスの可能性も減ります。特にIAMリソースの定義部分がほとんど不要で、grantReadメソッドの1行で実装できました。

コードを読み書きする難易度の比較

続いて、難易度の比較です。
CDKは一般的なプログラミング言語で記述できるため、自由度の高いコードが書けます。しかし自由度が高いがゆえに、関数の使い方や構造設計が多様であり、第三者が書いたコードを読み解くのに時間がかかることがあります。さらに抽象化の概念を理解する必要があり、インフラエンジニアにとっては慣れないプログラミング言語も習得しなければならない場合があります。これらの要因からプログラミング言語や抽象化の理解が前提となり、とっかかりのハードルが高い印象があります。ただし苦戦するのはほんの始めの部分だけで、慣れてしまえばなんてことはないです。プログラミング言語をTypeScriptにすれば、VSCode等のIDEの型補完機能が効くので利用可能なプロパティやメソッドを簡単に確認でき、ドキュメント参照する手間が省けるので非常に便利だと感じられます。

一方、Terraformに関しては自作関数も作れなければif文も使えないので、ある程度限られた使い方になってきます。流派がわかれるとしたらどのようにモジュールを分けるか、どのようにディレクトリを分けるかといったぐらいでしょうか。シンプルなツールで学習コストが低い印象があります。とっかかりのハードルが低いことに加え、ネットに落ちている情報がとても多いので開発もスムーズに進みやすいです。

AWSに関する前提知識の比較

続いて、AWSの前提知識の比較です。
CDKでIAMリソースを作る場合は「IAMポリシーにはs3:GetBucketアクションが必要」や「IAMロールを紐づけるためにインスタンスプロファイルを指定する必要がある」といったことを知っている必要がありません。しかも最小権限になるように簡単に実装できます。このように、すべてのパラメータを記載せずともベストプラクティスに沿ってツール側が自動で設定し、「それらしく動く」ものが作れてしまいます。

一方、TerraformはAWSサービスへのより深い理解が求められます。上記コードのとおり、詳細設計書を埋めるようにコードを書いていくことになり、インフラエンジニアにとっては馴染みのある作業になるでしょう。
「Terraformコードの書き方がわからない」＝「対象AWSサービスの理解が不足している」という状況であることが多い感覚です。

上記を表にすると

比較項目	CDK	Terraform
コード量	少	多
開発に必要な前提知識量	少	多
開発のしやすさ	高	高

まとめ

CDK採用が良いパターン、Terraform採用が良いパターンを考えてみました。

CDK採用が良いパターン：
・アプリ開発者もAWSインフラを扱う場合
・技術検証をササっと行いたい場合

Terraform採用が良いパターン：
・チーム内にアプリ開発経験者がいない場合、もしくは少ない場合
・プロダクション環境のような細かいパラメータ設定が必要で、暗黙の設定値を避ける場合
・プロジェクトが始まったばかりなど、今後AWS以外のパブリッククラウドを扱う可能性がある場合

大学院に進む価値とは？2年目エンジニアが語るキャリアへの影響

本記事は  【Advent Calendar 2024】  20日目①の記事です。
🌟🎄  19日目  ▶▶ 本記事 ▶▶  20②日目  🎅🎁

こんにちは！牛塚です。私は院卒2年目のエンジニアとして、日々奮闘中です。私が大学院に進学した当時、いろいろな不安を抱えていました。同学年より2年遅れて社会に出ることや、自分の研究が本当に役に立つのかなど、悩んでいたことを振り返りつつ、実際にどうだったのかをお話しします。大学院進学を悩んでいる方の参考になればうれしいです。

同学年と2年間の差がつくことへの不安

大学院進学を決めたとき、最初に感じたのは「同学年より2年遅れる」という不安でした。 学部卒で就職する友人たちは、大学院に進学する私がまだ研究室で過ごしている間に、会社で経験を積み、給料をもらいながらスキルを磨いています。

「社会に出るのが遅れた分、就活で不利になるんじゃないか」 「2年分のキャリアの差は簡単に埋められないのでは」

こういった考えが頭をよぎり、進学を選んだことが本当に正しいのか悩んでいました。

研究分野がニッチなので仕事に役立つのかという不安

私の研究テーマは、「AIを使ってネットワーク遅延を予測する」というものでした。自分としては専門性を感じる面白いテーマでしたし、自分の研究に誇りを持つこともできました。しかし、当時は「こんなニッチな研究が就職後も役立つのだろうか？」という疑問がずっとつきまといました。大学院の研究はとてもニッチなものになりやすく、仕事に生かすことが出来るのかという不安は入社するまでなくなりませんでした。

IT企業が求めるのは汎用的なスキル（プログラミングやシステム設計）だと思い込んでいたため、研究で培った知識、技術がどこまで評価されるのか不透明に感じていました。

加えて、研究に集中するあまり、業界全体のトレンドや実務的な技術についていけなくなるのではないかという心配もありました。

実際はどうだったのか

では、実際に社会に出てみてどうだったのか。入社してからの2年間で私の想像していた不安は払拭されました。

同学年と遅れた2年の差は？

もともとは同学年の「先輩」たちに、社会人経験で遅れを取っていると感じる場面は多々ありました。例えば、ビジネスコミュニケーションや業務の進め方、専門知識などかつての同級生は何段階も上のレベルにいて圧倒されていました。それだけではなく、2歳下の同期でも私に足りない能力をもっている人がたくさんいました。

私が感じたのは、年齢や社会人歴によって能力がつくというわけではないということです。先輩たちは2年先に社会人になったから能力が長けているわけではなく、2年間の努力によって今持っている能力を手にしていることに気がつきました。つまり、社会人にしろ、大学院生にしろ2年間どのように過ごすかによって2年後の自分が決まってきます。2年後には他の人が持っていない力を自分が持っていることもあるかもしれません。

社会人経験の差によって能力や知識の差が生まれてしまうことは明確です。しかし、大事なのは他人と比べるのではなく、自分に足りない部分・長けている部分を分析して、過去の自分と比べることだと感じました。

ニッチな研究テーマはどう役立った？

これまで、「AIを使ったネットワーク遅延の予測」というニッチな研究が、直接業務に活きる場面は多くありませんでした。ただし、研究を通じて培った以下のスキルは大いに役立っています：

• 論理的に考える力
• 未知の課題を調査し、解決するスキル
• 人前で落ち着いて話す能力（発表を通じて鍛えられた！）

発表に関しては、大学院生活で自分の研究の発表の機会がとても多かったです。その時は自分より何倍も知識がある人たちに向けて自分の研究内容を説明しないといけません。 そのような機会を通じて人前で落ち着いて話す能力などが身に着けられ、社会人生活でも活用できていると思います。（いまだに緊張はしますが...）

大学院進学の価値とは？

大学院進学は、決して「全員にとって最適な選択」ではありません。しかし、私にとっては「じっくりと専門性を磨きながら、自分の強みを見つける貴重な時間」でした。 また、自分の興味のあることを徹底的に追求できるチャンスであり、人生の中でも貴重な経験となりました。

どんな進路になったとしても一段ずつ成長していきましょう！

もし、あなたが以下に当てはまるなら、進学を検討してみてもいいと思います：

• 自分の興味を深めたい分野が明確にある
• 問題解決力や専門性を強みにしたい
• 早く社会に出るより、自分を磨く時間が欲しい

不安はあって当然ですが、それを乗り越えた先には成長があります！進学に迷っている方の参考になれば嬉しいです。

re:Invent2024 KeynoteのAmazon Q考察 - 開発者の生産性を向上させる新機能群

本記事は「Japan AWS Ambassadors Advent Calendar 2024」の19日目の記事です。

こんにちは、志水です。「おもちゃのチャチャチャ」のメロディーで「カボチャのサラダ」と歌っていたところ、3歳の息子が「おもちゃのチャチャチャ（や）でー」とツッコミを入れてくるほど、関西人らしく育ってきました。顔芸も達者なので、今後が楽しみですね。
今回はre:Invent2024 Keynoteで発表されたAmazon Q Developerの新機能群について考察してみます。

はじめに：Amazon Q Developer新機能群の狙い

re:Invent 2024のMatt Garman氏によるKeynoteにおいて、AWSは開発者向けに以下の新機能群を発表しました。

www.youtube.com

開発生産性を向上させる基本機能

• Amazon Q generates and applies unit tests
• Amazon Q generates accurate documentation
• Amazon Q performs code reviews
• GitLab Duo with Amazon Q

運用効率を改善する機能

• Amazon Q Developer: Investigate issues across your AWS environment in a fraction of the time

システムモダナイゼーションを加速する機能

• Amazon Q Developer: Transform .NET applications from Windows to Linux
• Amazon Q Developer: Transform VMware workloads to cloud native architectures
• Amazon Q Developer: Transform mainframe applications to accelerate migrations

これらの機能は、なぜ今必要とされているのでしょうか。現代の開発現場が抱える課題から見ていきましょう。

開発現場の時間の使われ方を理解する

開発者の実態

Gartnerの調査によると、開発者が実際に新しいコードを書くために統合開発環境（IDE）で過ごす時間は、1日あたり1時間未満、週に4-5時間程度に過ぎないことが分かっています。この現状を踏まえ、AWSは2023年4月にCode Whisperer（現Amazon Q）を発表しましたが、単なるコード生成から、開発生産性全体の向上へと焦点を移す必要性を認識しました。

www.youtube.com

ソフトウェア開発ライフサイクル（SDLC）の理解

この開発者の時間の使われ方をより詳しく理解するため、ソフトウェア開発ライフサイクル（SDLC）の観点から見ていきましょう。SDLCとは、開発チームが質の高いソフトウェアを設計および構築するために使用する、費用対効果と時間効率の高いプロセスです。具体的には以下のフェーズで構成されています。

1. 計画フェーズ：

   • 要件定義と分析
   • リソースの見積もりと割り当て
   • プロジェクトスケジューリング

2. 設計フェーズ：

   • アーキテクチャ設計
   • テクノロジー選定
   • 開発ツールの特定

3. 実装フェーズ：

   • コーディング
   • ユニットテスト
   • コードレビュー

4. テストフェーズ：

   • 統合テスト
   • システムテスト
   • 受入テスト

5. デプロイフェーズ：

   • 環境構築
   • アプリケーションのデプロイ
   • 設定管理

6. メンテナンスフェーズ：

   • 運用監視とインシデント対応
   • パフォーマンスとセキュリティの改善
   • 技術スタックの更新管理
   • 技術的負債への対応

aws.amazon.com

SDLCにおける開発者の課題

このSDLCの各フェーズにおいて、開発者は以下のような課題に直面しています。

開発者の時間を奪う3つの課題

1. ドキュメントとテストコードの管理負荷

   • 仕様書やAPI仕様の更新・管理
   • ナレッジの属人化と共有の難しさ
   • テストコードの作成と保守

2. 複雑化する運用監視

   • インシデント対応の遅延
   • システム性能の把握と改善
   • セキュリティリスクの検知と対応

3. システム移行の困難さ

   • レガシーシステムの理解と分析
   • 移行リスクの評価と対策
   • 段階的な移行計画の立案

Amazon Qによる開発者の課題解決

これらの課題に対し、Amazon Qは以下のような支援機能を提供し、開発者の生産性向上を実現します。

1. ドキュメントとテストコードの管理支援

   • READMEやデータフロー図の自動生成
   • コードベースの包括的なドキュメント化
   • ユニットテストの自動生成と品質向上

2. 運用監視の効率化

   • CloudWatchアラームからの自動調査開始
   • AWS Systems Managerと連携した問題解決
   • リソース間の関係性を考慮した根本原因分析

3. システム移行の包括的支援

   • .NETアプリケーションのLinux移行支援（コード解析、互換性チェック、自動変換）
   • メインフレームアプリケーションのモダナイゼーション（COBOLからJavaへの変換、ドメイン分割）
   • VMwareワークロードのクラウド移行（ネットワーク構成の自動生成、移行ウェーブの最適化）

SDLCフェーズとAmazon Q機能のマッピング

つまり、Amazon Qの新機能はSDLCの各フェーズにおいて、以下のようにマッピングされます。

1. 計画フェーズ

   • なし

2. 設計フェーズ

   • ドキュメントの自動生成

3. 実装フェーズ

   • コードレビューの自動化
   • GitLab Duoによる機能開発支援

4. テストフェーズ

   • ユニットテストの自動生成

5. デプロイフェーズ

   • なし

6. メンテナンスフェーズ

   • 運用上の問題調査の自動化
   • .NET、VMware、メインフレームの移行支援

Amazon Qの強みと今後の展望

このように、Amazon Qは開発ライフサイクルの各フェーズをカバーする包括的な機能を提供することで、開発者の作業効率を劇的に向上させることができます。

特筆すべきは、他の生成AIツールとの大きな差別化ポイントとして、メンテナンスフェーズにおける強力な機能群です。AWSのインフラストラクチャと深く統合されているからこそ実現できた特長と言えるでしょう。

さらに、開発者はAWSマネジメントコンソールから直接Amazon Qにアクセスし、システムの状態確認や問題調査を行えるため、より効率的なトラブルシューティングが可能になります。まさに、クラウドネイティブな開発支援ツールの真価がここにあります。

将来の展望：新たな専門エージェントの可能性

また、SDLCのフェーズマッピングから見ると、今後のAmazon Qの進化の方向性も見えてきます。現在カバーされていない計画フェーズやデプロイフェーズに対して、以下のような専門エージェントの登場が期待されます。

1. 計画フェーズ向けエージェント

   • 要件定義の支援と要件間の整合性チェック
   • ストーリーポイントの見積もり支援
   • プロジェクトリスクの分析と対策提案

2. デプロイフェーズ向けエージェント

   • CI/CDパイプラインの設計と構築支援
   • デプロイ戦略の最適化（Blue/Green、Canaryなど）
   • インフラストラクチャのコード化支援

これらの専門エージェントは、ユニットテスト生成機能のように特定のタスクに特化し、高度な自動化と意思決定支援を提供することが予想されます。このように、Amazon Qは開発ライフサイクル全体をカバーする総合的な開発支援プラットフォームへと進化していくでしょう。

まとめ：次世代の開発支援ツールの可能性

Amazon Q Developerの現状と展望

Amazon Q Developerは、開発者の時間の使い方の実態を踏まえ、以下の3つの課題に対して包括的な解決策を提供します。

1. ドキュメントとテストコードの管理負荷の軽減
2. 複雑化する運用監視の効率化
3. システム移行の包括的支援

以下が現時点での制限事項と今後の展開です。

• 対応言語は現在、Java、Python、JavaScriptが主な対象です
• GitHubサポートは2024年後半に完全統合される予定です
• APIは2024年中にパブリックリリースされる予定です

実務導入のポイント

組織への導入を検討する際は、以下の点が重要です。

• セキュリティポリシーとの整合性確認
• チーム開発プロセスの段階的な移行
• カスタムルールセットによる組織固有の要件対応

また、SDLCの各フェーズに対する機能の充実度を考慮し、以下の順序での段階的導入を推奨します。

1. メンテナンスフェーズの運用効率化から着手
2. 実装・テストフェーズの自動化機能の導入
3. 設計フェーズのドキュメント自動生成の活用

結論

Amazon Q Developerは、AWSインフラストラクチャとの深い統合を活かし、特にメンテナンスフェーズにおいて他の生成AIツールとの差別化を図っています。開発者が本来の価値創造に集中できる環境を実現する強力なツールとして、今後のSDLC全体をカバーする総合的な開発支援プラットフォームへの進化が期待されます。

執筆者志水友輔

2023,2024 Japan AWS Ambassador / 2021,2023,2024 Japan AWS Top Engineer / 2021-2024 APN ALL AWS Certifications Engineers / 2024 AWS Community Builder（Serverless）
大阪でAWSを中心としたクラウドの導入、設計、構築を専門に行っています。Generative AIとIaCとつけ麺が大好物

X：https://twitter.com/shimi023

Amazon著者ページ：Amazon.co.jp: 志水友輔: 本、バイオグラフィー、最新アップデート

CCoEって何？AWSでは何をするべき？

本記事は  【Advent Calendar 2024】  19日目の記事です。
🌟🎄  18日目  ▶▶ 本記事 ▶▶  20日目①  🎅🎁

こんにちは、西内です。
先日のJAWS-UG朝会 #64にて本記事と同じタイトルで登壇を行い、CCoEについて発表しました。 本ブログでは、JAWS-UG朝会 #64で発表した内容を説明していきます。

発表資料

speakerdeck.com

はじめに

今回の記事では「CCoEとは何か」について説明しますが、その前に「そもそもなぜクラウドが重要とされているのか」から解説し、最後にAWS上で行うCCoE活動の例を示します。

そもそもなぜクラウドが重要なのか

クラウドはシステム開発におけるアジリティ（俊敏性）が高い

世間ではクラウドによるシステムの開発・運用が浸透していますが、何故ここまで重用されているのでしょうか。
以下にクラウド利用のメリットを書き出してみます。

• システムの導入・運用コストがオンプレミスシステムと比較して低い
• ハードウェアの調達が不要
• 従量課金により簡易な技術検証が実施しやすい　など

これらを総合して考えられることは、アジリティ（俊敏性）が高いということです。
ここで、従来のオンプレミスシステムによる開発の流れを考えてみます。
下図のように、インフラストラクチャーの準備を終えてアプリケーションの開発に着手するまでに、様々な前準備が発生するかと思います。

オンプレミスシステムの開発までの流れ

一方で、クラウドによる開発の流れは下図のようになります。
サーバに入れるOSの検討こそすると思いますが、それ以外は前準備をすることなくサーバの立ち上げが可能です。
スペック（CPU性能、ストレージ容量）も一旦仮の値で立ち上げて、後から変更も可能です。
また、起動までの作業もAWSであればWebブラウザ上で数クリックするだけで完了します。

クラウドシステムによる開発の流れ

このように、従来型のシステムと比較してクラウドは開発のスピードがより速くなります。

アジリティの高さはDX（デジタルトランスフォーメーション）推進において非常に重要

先述のアジリティの高さは、昨今様々な企業で求められているDXにおいても重要な要素となってきます。
DXの定義を見てみましょう。

企業が、ビッグデータなどのデータとAIやIoTを始めとするデジタル技術を活用して、業務プロセスを改善していくだけでなく、製品やサービス、ビジネスモデルそのものを変革するとともに、組織、企業文化、風土をも改革し、競争上の優位性を確立すること。

引用元：DX（デジタルトランスフォーメーション）| 用語解説 | 野村総合研究所(NRI)

ここでポイントとなるのは「デジタル技術を活用して」「製品やサービス、ビジネスモデルそのものを変革する」ことです。
製品やサービス、ビジネスモデルに変革をもたらすには様々な施策を早いスパンで試行錯誤していく必要があります。
その際に、クラウドによる開発のアジリティは親和性が高く、DXを進めるうえで重要な要素となります。

一方でアジリティの高さだけを見てはならない

ここまでの話でクラウドによるシステム開発はアジリティが高く、DXにおいても重要であるということをご理解いただけたかと思います。
しかし、アジリティの高さは時に様々な問題を招いてしまいます。

• 必要なセキュリティ対策が講じられない可能性がある
• 不要なリソースへの請求が発生する可能性がある
• 重要なリソースを誤って削除してしまう可能性がある　など

このような問題の発生を防ぐためにも組織内のクラウド利用を適切に管理しつつ、活用推進をしていく組織が必要となります。

CCoEとは

CCoEは何をする組織か

先ほどの章で、クラウド利用をするにあたり適切な管理を行う組織が必要な話をしました。
CCoEはこのようなクラウドの管理や活用推進を行う組織になります。
なお、CCoEの正式名称はCloud Center of Excellenceです。

CCoEが推進することの例としては「ハンズオン環境の提供・管理」「課金状況の把握・コスト管理」「アカウントへの適切なセキュリティ設定」「ユーザアカウントごとの権限設定」「人材の育成」などがあげられます。

CCoEで推進することの例

CCoE活動は部署をまたぐ

先ほど述べたCCoEが推進する事項は一つの部署内で完結せず、複数の部署とのやり取りが発生するものになります。
例えば「アカウントへのセキュリティ設定」は情報セキュリティ部とコミュニケーションを取りながら社内のセキュリティガイドラインに適合する対策を検討しつつ、アカウントを所有する部署へ内容を伝達する必要があります。
他にも「人材の育成」であれば、人事部とコミュニケーションを取りながら研修の制度や資格取得補助の仕組みを考える必要があります。

このようにCCoEの取り組みは全社的なものであり、案件を持つ部署以外にも本社機構の部署とのコミュニケーションが多く発生します。

CCoE組成の一例

では、CCoEはどのように編成していくのが良いでしょうか。
様々な組成の仕方があるかと思いますが、一番明快なのは情報システム部等の元々存在した社内の部署をそのままCCoEとして昇格するという方針が考えられると思います。トップダウン・ボトムアップで考えると、トップダウンの色合いが強いでしょう。

一方で、「複数の部署とやり取りが発生する」という側面に着目して、各部署から人材を引き抜く・兼務してもらうという形で組成する考え方もあります。こちらはボトムアップの色合いが強いでしょう。

「どちらが正解か」と問われると「どちらか一方が正解とは限らない」というのが回答になります。
会社の内部事情や各部署の人員の都合があるため、会社ごとに正しいあり方は異なると考えられます。
ただ、CCoEの役割として複数の部署とコミュニケーションを取るという点を考慮すると、後述のボトムアップ型の方が業務の遂行がより円滑に進められるのではないかと考えられます。

AWSを使ってCCoE活動を進めるには

AWSでの具体的な取り組みの例

概念的な話が続きましたが、ここからはAWSを社内で利用している場合CCoEとしてするべきことは何か、について考えてみます。
こちらも何を取り組むべきかは正解が一つではありませんが、例としては下記のようなことが考えられるでしょう。

• アカウント分離
• AWS Organizationsを使った複数アカウントの管理
• IdP導入およびAWS IAM Identity Centerとの連携
• AWS ConfigやAmazon GuardDutyなどのセキュリティ設定の導入

上記の事項について具体的にこれからご説明します。

アカウント分離

まず一つ目はアカウントの分離です。
シングルアカウントでAWSを利用している場合、不都合が発生することがあります。
「開発環境用のサーバを誤って削除してしまった」「請求金額を部署単位で分けて把握したいが全体の金額しか見られない」などです。
これらの課題に対するアプローチがマルチアカウント管理という考え方です。
アカウントを環境・部署・プロジェクト等に応じて分けることで、予期せぬ誤操作を防ぐことが出来、且つ請求の金額を分離して把握することが可能になります。

AWS Organizationsを使った複数アカウントの管理

先述のマルチアカウント管理を更に効果的に行うには、AWS Organizationsを使うことが推奨されます。
Organizationsでは複数のアカウントをOrganizational Unitという単位でまとめ管理することが出来ます。
例えば、Sandboxとしての検証環境の単位、開発アカウント群、本番アカウント群、部署といった単位で分けて管理することができます。
また、それらのまとまりに対して権限統制を敷くことも可能です。
また、Organizations内に取り込んだアカウントはコンソール上やCLIから一覧を取得することも可能になります。

IdP導入およびAWS IAM Identity Centerとの連携

アカウントが増えることで新たな課題も発生します。それは、アカウントへのログインをIAMユーザで行っている場合、アカウントの数だけID・パスワードが増えるということです。
マルチアカウント管理の弊害ともいえる課題でしょう。しかし、この課題を解決するサービスがあります。
それがAWS IAM Identity Centerです。このサービスにより、複数アカウントへログインする際のユーザやアクセス権限を一元管理することが可能になります。

AWS ConfigやAmazon GuardDutyなどのセキュリティ設定の導入

セキュリティサービスの導入も重要な事項です。
Organizationsで管理しているアカウントに対して必要なセキュリティ設定を検討し、全てのアカウントに対して導入を行う必要があります。
これは各アカウントの所有者に任せるのではなくCCoE側から設定を導入し、各アカウント側からは解除できないようにするのが良いでしょう。

最後に

今回はCCoEという概念とAWSでは具体的にどのようなことを実施するべきかを書きました。
クラウドは便利ですが適切な管理を行わなければ、多額の請求やセキュリティインシデントが発生してしまうことがあります。
社内のクラウド利用状況を俯瞰して適切な管理を行うような組織を作ることが大変重要になります。

不安でいっぱいな人のためのre:Invent参加手引

こんにちは、システムエンジニアの檀上です。 普段は顧客の社内システムの要件調整・基本設計などを担当しています。

さてこの度、アメリカ ラスベガスで開催されたAWS re:Invent 2024に参加させていただきました。 参加をさせていただくことになったものの、過去のre:Invent参加録を見たところ、「一日3時間睡眠が普通」「毎日2万歩から3万歩歩く」「アドレナリンと気合で乗り切れる」みたいな恐ろしい記事をたくさん見かけました。

私はそんなに長時間労働にはなっていない普段の業務でも、体力的にも精神的にもいっぱいいっぱいです。なんとかやってます。毎日が日曜日とは言わんからせめて週休3日になってくれといつも祈ってます。 そんな私がAWS re:Inventを乗り切れるのか非常に不安になっていました。

しかし、その不安をばねに色々と準備したところ、なんとか1週間無事に乗り切ることができました。 そこで、「これよかったよ！」「こうしたほうがよかった」というTipsを共有します。

「AWS re:Inventに参加したい。でも自分みたいな体力・ガッツが少なめの人間でも大丈夫なのかな。やめとこうかな。」 と考えている方にもぜひ行ってほしいと思っているので、その背中を押せる記事になればと思います！

現地の気候について

気温について、ラスベガスは東京と同じくらいの緯度で、日本の都市と気温はあまり変わりませんでした。 会場は暖かく、外は寒いため、温度調節のできる服装が良いと思います。私は屋内では極暖ヒートテック、薄手のセーターを着て、屋外ではいつも冬に来ているアウターを着て、寒ければウルトラライトダウンベストを足すという方針で丁度良かったです。

湿度について、日本の12月は湿度60%程度ですが、現地は湿度20%程度です。湿度対策として下記を実施して、喉は壊さずにすみました。

• 寝るときは濡れマスクをつける。
• 部屋ごとにエアコンが設定できる場合はエアコンを切る。
• 水分を多めにとるように意識する。（会場では無料で水筒に水を補給できます。）
• のど飴を常にリュックに入れておき、喉がいがいがしてきたら食べる。
• 顔・体の保湿グッズは日本だとやりすぎなくらいがちょうどいい。
  • 私は体の保湿が不足していたためか、後半は乾燥や摩擦によるじんましんや持病のアトピー性皮膚炎が再発しました。服は数着だけ持っていきごしごし洗って干していたため、服がごわごわしていたのも一因な気がしています。肌が弱い方は、洗濯用の袋を購入して持っていくか、荷物は増えますが日数分の服を持っていった方が良いと思いました。
  • 同僚は、後半は顔に化粧水を塗っただけでピリピリすると言っていたので、顔もちゃんと保湿したほうが良いです。

現地は砂漠のど真ん中です

現地での食事について

各会場で朝食(7:00-9:00)と昼食(11:00-13:00)が食べられます。会場のご飯は野菜も多く、かつ無料です。ここでしっかりご飯を食べましょう。 原材料はすべて公開されているわけではないですが、各会場の細かい材料が見れるページが用意されています。（会場入り口の看板にQRコードがあります）

私はナッツ類全般・タコなどの一部魚介などにアレルギーがありますが、会場のビュッフェ前に置いてあるメニュー表にかなり詳しく材料が書いてあるため、それを読んで判断していました。 強いアレルギーをお持ちの方は、会場のスタッフに質問すれば答えてもらえるかもしれません。（すみません、私は実践できませんでした。）

現地の食事だけではつらくなり、出汁のきいた日本のご飯が食べたくなる可能性があります。 メイン会場のVenetianにあるジャパンサポートデスクでは、味噌汁・日本茶・割りばし・紙コップ・お菓子などを無料で提供してもらえたそうです。行ってみると何かいただけるかもしれません。 また、ラスベガスのホテルには部屋にケトルがないため、トラベルケトルを購入して持参しました。お湯を使うインスタント食品を持っていく場合は用意しておきましょう。 電子レンジはないため、電子レンジ必須のインスタント食品は諦めましょう。

現地での休憩について

疲れたときは会場のソファで休憩したり、素直に部屋に戻って休憩しましょう。仮眠をとるのもよいです。 現地に行く以外の方法でセッションを見る方法もあるので、適切に利用しましょう。キーノートはオンラインで視聴できますし、セッションによっては各会場にあるContent Hubという部屋でリモートで上映されている場合もあります。

また、各会場にReflectionRoomという部屋があり、祈りを捧げたり、ヨガをしたり、休んだりする人のための暗い静かな部屋として提供されています。私は最終日にここで1時間ほど休みました。

処方薬、市販薬の持ち込みについて

基本的には持っていって問題ないです。機内持ち込みもできました。市販薬としては、胃薬、整腸剤、頭痛薬、痛み止め（解熱剤）あたりがあると安心です。

空港で止められた時のために、処方薬は医師による処方箋（とその英訳）、市販薬は箱ごと持参し、薬が正当に処方されたもの・成分に問題がないものだと証明できるようにしておく必要があります。 私は出発数日前に風邪をひいたため、すぐにかかりつけ病院に行き1週間分の薬（錠剤と吸入器）を処方してもらい持ち込みました。

参考リンク：海外渡航先への医薬品の携帯による持ち込み・持ち出しの手続きについて｜厚生労働省

歩数について

会場は本当に広く、会場間・部屋間の移動が大変です。歩数を減らすため、できるだけ同じ会場内の移動のみになるようにスケジュールを組みました。 例えば、朝Venetian（メイン会場）で朝食をとり、キーノートを現地で聞く。→MGM（別会場）までバスで移動して昼食をとり、セッションを1～2個聞く。と言った具合です。

また、GameDayやWorkshopなどの2,3時間かかる長めのセッションをとるとその分細かい移動はしなくて済む、、かもしれません（その分、頭を使って疲れますが）。 私はキーノートとWorkshopを中心に予定を組み、1日14,000歩程度に歩数を抑えられました。

毎日夜にストレッチをして、足を休める湿布を貼って寝ていました。1日サボったところ翌日明らかに辛かったので、絶対にやった方が良いです。

会場の1つ、Mandalay Bayの外観です。ホテルの周りの木の大きさでスケールが大きいことが分かります。。

睡眠時間について

日によりますが、セッションの終了時刻は、早い日は18:00頃、遅い日は21:00頃です。 会場ではディナーは提供されないため、ホテルに戻ってご飯を食べたら部屋に戻るのは遅くて23:00頃。それからシャワーを浴びたり、その日の整理・翌日の準備をしていたら、0:00を超えて就寝となる場合も多いです。 また起床時間について、例えば2日目のキーノートは8:00開始で、現地で翻訳機を受け取ろうと思うと1時間ほど前から並ぶことになり、起きるのは6:00頃ということになります。 このため、何も考えないと「1日の睡眠時間は3時間です！」というような猛者ムーブが必要になってしまいます。

下記のような方針を立てると睡眠時間が確保できるのではと思います。

• 翌日早朝のセッションがある場合は、前日のセッションは早めに切り上げる。会食が設定されている場合は別日に調整する。
• 夜遅い用事がある場合、翌日朝のセッションは宿泊ホテル近くの会場にする。
• 疲れたときは部屋に戻って仮眠をとる。疲れた状態でセッションを聞くと何も入ってきません。

私は結局平均睡眠時間5時間弱でした。かなりしんどいですが、ギリギリやっていけるレベルでした。

睡眠時間が少なめなのは業務の宿題がある状態だったせいです。。ちゃんと宿題を終わらせてから出張していれば、平均6時間弱確保できたはずでした。

自分のやる気と体力について

あれもこれもと欲張ると、なかなか成果が得られません。 なので、「私はこれを勉強して/経験して帰るんだ！」という目標を決めておくといいと思います。

私は、一緒に参加した同僚が私から見てAWSのエキスパートばかりだったので、「私はいったい何をすればいいのか」と悩みました。 そこで、私は普段AWSを業務で触らないので、1日最低１つはワークショップに参加して実際にシステムを作ってみる、という目標にしました。 逆にそれ以外は休憩やコミュニケーションに費やしてもいいと考えていました。

また、サプリにも頼りましょう。私はアリナミンを持っていき、毎日飲んでいました。

やる気を回復できるような、自分なりのリラックスグッズを持っていくのもよいと思います。 私は3日目に急に気力が0になってしまったのですが、お味噌汁といつものカフェオレを飲んで、大好きなパズルゲームを少し楽しんだら気力が回復しました。

おわりに

私は実際に現地に行って良かったなと思ったことが3つあります。

1. 1週間業務を離れて、技術やアーキテクチャ、エンジニアのキャリアパスについて考える時間がとれた
2. 語学やクラウド技術など、もっと勉強していたらもっと興味のある分野の話が聞けたな、と感じ、学習意欲が湧いた
3. 学習した技術を自分の業務に活かすならどうするか？を考えることがあり、担当システムの今後の開発計画についてアイデアが湧いた

日本にいてもできるやろ！と言われたらそうかもしれませんが、普段の業務に追われている中でこうしたことに取り組むのは難しいのが実情です。 こういったきっかけを作れたという意味でも、今回参加できて本当によかったです。

「行ってみたいけど、色々と不安です」という方も、ぜひぜひ一歩を踏み出してみてください！