はじめに こんにちは。ニフティ株式会社の仲上です。 CI/CDを構築する際、アクセスキーの管理が大変です。 アクセスキーやシークレットキーをGitHub secretsなどに格納する方法がありますが、管理が大変で、期限切れの対応などが必要になります。 そこで、本記事ではOIDCを利用した認証でAWSへのアクセス権限を管理する方法をご紹介したいと思います。 OIDCについて OIDCはOpenID Connectの略です。 OIDCはSSO(シングルサインオン)の実装手法の1つで、多くのサービスに利用されている認証フォーマットです。 他の認証フォーマットとしては、SAMLが有名です。 OpenID Connect の言葉の説明は以下の記事がわかりやすいです。 https://www.tohoho-web.com/ex/openid-connect.html 仕組みの解説については、以下の記事が有名です。 https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe AWSではこの認証方式を利用した権限管理機能が備わっています。 https://docs.github.com/ja/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services メリット メリットとしては以下の点が挙げられます。 鍵の管理が不要 ユーザーに依存しない認証方法になる トークンの期限に頭を抱えなくて済む デメリット デメリットとしては以下の点が挙げられます。 他のリポジトリからデプロイするようになった場合、再度認証が必要 設定をミスすると すべてのGitHub上のリポジトリからアクセスできてしまう 特に、AWSのIAMロールへのアクセス権限管理には細心の注意を払う必要があります。 今回はこの機能でリポジトリの認証設定を行い、デプロイしていくことにします。 設定手順 AWS の IAM へ GitHub のIDプロバイダを追加 デプロイ対象のIAMでIDプロバイダを選択します。 プロバイダを追加します。 以下の内容で設定します。 プロバイダのタイプ OpenID Connect プロバイダの URL https://token.actions.githubusercontent.com 対象者 sts.amazonaws.com IAMロールの作成 IAMロールから、カスタム信頼ポリシーを選択します。 カスタム信頼ポリシーの内容は以下の通りです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::{自分のAWSアカウントID}:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", "token.actions.githubusercontent.com:sub": "repo:{デプロイ対象のリポジトリ}:ref:refs/heads/*" } } } ] } 「許可」ではデプロイに使用する権限を選択します。ここでは以下の権限を付与します。 AWSCloudFormationFullAccess AmazonS3FullAccess AWSLambda_FullAccess CloudWatchLogsFullAccess IAMFullAccess AmazonDynamoDBFullAccess AmazonEC2FullAccess 権限はデプロイするテンプレートの内容によって変更してください。 ロール名と説明を追加して、「ロールを作成」を選択します。 ワークフローを作成する ここでようやく GitHubのワークフローが登場します。 認証には以下のアクションを使用します。 https://github.com/aws-actions/configure-aws-credentials こちらのアクションを使用することで、Role arnを指定するだけでAWS認証を行ってくれるようになります。 ワークフローを定義します。 GitHub Acrtions の画面から変数を登録します。 Repository variables を選択します。 AWS_OIDC_ROLE_ARNを設定します。先ほど作成したRoleのARNを書きます。 ワークフローを動かすため、デフォルトブランチをmain以外にしておきます。 以下のコードを作成してpushします。 name: 開発環境デプロイ run-name: Deploy ${{ github.ref_name }} to development by @${{ github.actor }} on: workflow_dispatch: push: branches-ignore: - main # allow use id-token permissions: id-token: write contents: read jobs: deploy: runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: Checkout uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v2 with: python-version: 3.12 - name: Setup SAM uses: aws-actions/setup-sam@v2 - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ vars.AWS_OIDC_ROLE_ARN }} aws-region: ap-northeast-1 - name: sam validate run: sam validate - name: sam build run: sam build - name: sam deploy run: sam deploy 動作確認 うまくいきました。みなさんもぜひOIDCを利用してみてください。 参考 https://zenn.dev/kou_pg_0131/articles/gh-actions-oidc-aws

若手エンジニアたちが最新の情報を共有し、スキルを高め合うことを目的としたイベント「NIFTY Tech Day 2025」が2025年2月8日、新宿ニフティ本社にて開催されました。 当日はメイン会場で繰り広げられたセッションの他、AIやChatBot、エンジニア向け脱出ゲームやスクラムラウンジ等、参加者が実際に体験できるブースに加え、豪華景品の当たる「ニフくじ」にもたくさんの方が訪れていました。 今回のイベントに運営チームとして関わった高田さんに、今回のイベントの目的について聞きました。 運営チームの高田さん 高田さんコメント 「多くの皆様にお越しいただき、誠にありがとうございます。Tech Dayの目的は『ニフティの全てをお見せすること』です。ニフティの雰囲気や、エンジニアたちがどのように学び、成長しているかをご覧いただきたいと思います。また、エンジニアの皆さんにとって、技術を共有する場となることを願っています。」 NIFTY Tech Day 2025の開幕です！ NIFTY Tech Day 2025開幕 NIFTY Tech Day 2025はニフティ社長の前島さんによるオープニングセッションで幕を開けました。 ニフティ社長の前島さん 前島「NIFTY Tech Dayはすべて社内エンジニアの手で作られたイベントです。ニフティ若手社員たちの日頃の努力の成果を、体験していってください！」 白熱のセッションが繰り広げられました メイン会場では、ゲストスピーカーと若手エンジニアたちが登壇し、それぞれ熱いセッションが繰り広げられていました。 メイン会場で行われたゲストスピーカーとニフティエンジニア社員によるセッションの様子。 ゲストスピーカーとして登壇したGitHub服部さんの講演内容は、AI時代にエンジニアに求められるスキルについて。第一線で活躍するエンジニアの生の話が聞けるのは貴重ですね。 ニフティの若手エンジニアたちによるセッション。 セッションを聞いていると、エンジニアたちの「成長していくことを楽しむ」という姿勢が伝わってくるようでした。 クオリティの高い配信により、オンライン参加の方も快適に視聴できていました。 個別のセッションの内容については以下のリンクよりアーカイブ動画をご覧ください。（※アーカイブ公開ごとに随時更新） AIと協働する次世代開発スタイル – 求められる新たなスキルと役割の変化 アーカイブ エンジニアの殻を破る：インナーソースと社外活動がもたらした成長 アーカイブ 登壇資料 自社製CMSからの脱却：10件のWebサイト再構築に学ぶ運用重視の技術選定 アーカイブ 登壇資料 スクラムマスター入門者のための学習マップ 効果的な学びと実践 アーカイブ 登壇資料 学びを文化に変える〜ニフティの内製研修と継続的成長の仕組み〜 アーカイブ 登壇資料 社内SEとしての進化：AIツールを活かすネットワークエンジニアの新たな挑戦 登壇資料 AWSでもOracleしたい！DB移行指南：マネージドサービス活用して属人化も解消 アーカイブ 登壇資料 ニフティLT大会大公開スペシャル アーカイブ 登壇資料① 登壇資料② 登壇資料③ すべてが手作りのイベントです NIFTY Tech Day 2025に来られた方は、おそらくこの規模のイベントには専門の運営会社が入っているんだろうなと思われたのではないでしょうか。 前島さんも話していた通り、実はこれぜんぶニフティ若手社員の手による内製なんです。会場設営から配布物の制作、配信にいたるまでぜんぶです。 配信チームもニフティ社員でした。趣味で得たスキルを生かしているのだとか。 来場者に配られたNIFTY TECH BOOK ＃2は、無料配布とは思えない充実の内容でした。これも表紙からすべてニフティ社員の手作りです。 このレポートを書いている安藤（左）も実はニフティOBです。右はセッション登壇前のニフティエンジニアの石川さん（後ろで笑っているのもニフティOBの棟近さんです）。 技術系のイベントというのは難しい人たちが難しい話をする場所、というイメージがあったんですが、現場で体験してみるとまったくそんなことはありませんでした。 エンジニアのみなさんが自分たちの興味分野について語る場であり、セッションの合間にはフリースペースで発表内容についての会話が自然に発生していました。 これは私がニフティに在籍していた時にも感じていたことなんですが、ニフティには社員の自主性を重んじる社風が根底にあるんだと思います。NIFTY Tech Dayは、まさにそういった社風が結実したイベントでした。 登壇を終えた若手エンジニアのみなさんが楽しそうにお互いを労っているところを、少し離れたところから社長の前島さんが嬉しそうに見ていたのが印象的でした。 ニフティエンジニアの強みの第一位が「やさしさ、思いやり」というのもニフティらしいなと思います。 体験型ブースも人気 セッションの合間には、これもニフティ社員による体験型ブースに人気が集まっていました。 凄腕エンジニアしか脱出できないのでは、と恐れられた脱出ゲーム（実際は丁寧にヒントをくれるので脱出できます！）。 セッションにも登壇していたスクラムチームによる「スクラムラウンジ」では、スクラムを導入して改善されたことやこれから学んでいきたいことなどについて、活発に会話が交わされていました。 もじこえブースからは音声チャットツールにより、常に「もじ」が「声」となって聞こえてきていました。 キッズチームからはこども向けAI活用事例の紹介が。子どもからの質問にマスコットキャラクター「ひよりん」が即座に答えてくれます。 すべてのブースをまわりスタンプを集めるとくじが引ける「ニフくじ」のコーナー。脱出ゲームなど、ハードルの高さもなんのその、豪華賞品が当たるとあってたくさんの来場者の方にくじを引いてもらっていました。 NIFTY Tech Day 2025では、セッション終了後の懇親会に至るまで、参加者と運営スタッフがみんな忙しくも楽しそうに会場の中を歩き回っていたのが印象的でした。 懇親会も盛況でしたね。 ご来場のみなさん、オンラインでご視聴いただいたみなさん、最後までありがとうございました！ 次回もやります！ 閉会挨拶では最上執行役員より、次回のTech Day開催が宣言されました。運営チームもすでに次回に向けて動き出しています。次回のNIFTY Tech Dayでまたお会いしましょう！ 最新情報は当ブログやSNS公式アカウント（ https://x.com/NIFTYDevelopers ）で発信していきますので、楽しみにしていてください。 NIFTY Tech Day開催までの間は、NIFTY Tech Talkでも技術情報などを発信しますので、ぜひconnpass（ https://nifty.connpass.com/ ）をご登録ください。 アンケートご協力のおねがい 会場でご参加いただいたみなさん、オンラインで視聴していただいたみなさん、後日アーカイブをご覧いただいたみなさん、本当にありがとうございました。みなさんからの感想やコメント、フィードバックが次のNIFTY Tech Dayにつながります。ぜひアンケートにご協力ください。 2025年3月31日までにアンケートにご回答いただいたみなさんの中から抽選で本イベント登壇者の服部さんの書籍を10名さまにプレゼントします。詳しくは以下リンクをご参照ください。 https://forms.gle/9n5uSFumWrSz7s5i6 記：安藤

こんにちは。会員システムグループでエンジニアをしている山田です。 昨年末、CloudFrontの標準ログに待望のアップデートが入りました。 https://aws.amazon.com/jp/about-aws/whats-new/2024/11/amazon-cloudfront-log-formats-destinations-access/ 今までの標準ログはレガシーな仕様を抱えており、特にすべてのログが同じパスに出力されてしまうという点が問題になっていました。Athenaでの検索などのために、ログを日付別パーティションに移動させるLambdaを動かしている方も多かったのではないでしょうか。 今回のアップデートにより S3の出力先パスに日付・時間を含めることが可能に JSONなどのフォーマットをサポート、カラムの取捨選択も可能に S3バケットポリシーに対応 など、今まで困っていた部分が解消されるようになります。さらにCloudWatch LogsやFirehoseへの出力もできるようになりました。 そして最近になってこの標準ログv2はTerraformでも設定できるようになりました。まだTerraformでの設定方法を解説した記事は少なそうですので、紹介したいと思います。 前提知識 まず大前提として、実はこの標準ログv2、 CloudFrontに設定する機能ではありません 。 これは 公式ドキュメント のAWS CLIでの設定方法を見るとわかるのですが、CloudWatch Logs Delivery(v2)という汎用的なCloudWatchのログ配信機能になっています。これにCloudFrontが対応したというのが実際のようです。 登場するリソースは以下の3つです。 DeliverySource DeliveryDestination Delivery これらの関係性は以下のようになっています。 ログ出力元(DeliverySource)とログ出力先(DeliveryDestination)を作った後、これらをつなぐDeliveryを作成するとログが送られるようになります。DeliverySourceにCloudFront、DeliveryDestinationにS3を設定することで従来の標準ログを代替できます。 Terraformでもこれらのリソースを作成していくことになります。 Terraformでの実装例 従来と同様、S3へ送る設定を紹介します。 Terraform AWS Providerは v5.89.0以上 が必要です。作成できるようになったのはv5.83.0ですが、apply後に状態不一致(tainted)となる複数のバグが修正されています。 S3の許可設定 S3の許可設定はバケットポリシーを設定します。もうACLを使う必要はありません。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AWSLogDeliveryWrite", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "<S3バケットARN>/<ログファイルまでのパス>/*", "Condition": { "StringEquals": { "aws:SourceAccount": "<AWSアカウントID>", "s3:x-amz-acl": "bucket-owner-full-control" }, "ArnLike": { "aws:SourceArn": "arn:aws:logs:us-east-1:<AWSアカウントID>:delivery-source:*" } } } ] } delivery.logs.amazonaws.com をprincipalとし、S3オブジェクトに対する許可設定を行います。上記設定ではアカウント内の全てのDeliverySourceからの操作を許可していますが、厳密にはDeliverySourceを作成後、そのARNを指定するとよいでしょう。 Log Deliveryの作成 次に本命となるLog Deliveryです。AWSコンソール上で以下のように設定する値がどこに入るのかを見ていきます。 なおLog Delivery関連リソースはいずれも us-east-1で作る 必要がある点に注意してください。送信先S3バケットは別リージョンでも問題ありません。 まずはDeliverySourceとDeliveryDestinationを作成し、CloudFrontとS3を指定します。 resource "aws_cloudwatch_log_delivery_source" "this" { name = "<適当なsource名>" log_type = "ACCESS_LOGS" resource_arn = "<CloudFrontのARN>" } resource "aws_cloudwatch_log_delivery_destination" "this" { name = "<適当なdestination名>" # AWSコンソールの「Output Format」に相当 # 従来どおりの場合は"w3c" output_format = "json" delivery_destination_configuration { # AWSコンソールの「送信先S3バケット」に相当 destination_resource_arn = "<宛先S3のARN>/<ログまでのパス>" } } DeliveryDestinationではフォーマットや出力先パスを指定でき、日付別パスなどの設定ができます。後述しますが、 destination_resource_arn にパス部分を書かない場合、Deliveryの設定に影響するので注意してください。 最後にDeliveryを作ることで完成です。 resource "aws_cloudwatch_log_delivery" "this" { delivery_source_name = aws_cloudwatch_log_delivery_source.this.name delivery_destination_arn = aws_cloudwatch_log_delivery_destination.this.arn # AWSコンソールの「Field Delimiter」に相当 # JSONの場合は指定できない # field_delimiter = "," # AWSコンソールの「フィールド選択」に相当 # 未指定の場合はデフォルト値(legacyと同等)が設定される # record_fields = [ ... ] s3_delivery_configuration { # AWSコンソールの「パーティショニング」に相当 # 年月日時以外に{accountid}、{DitributionId}を指定可能 suffix_path = "/{yyyy}/{MM}/{dd}/{HH}" # AWSコンソールの「ハイブ互換のファイル名形式」に相当 # trueの場合、プレースホルダの挿入値が"year=2025"のようになる enable_hive_compatible_path = false } } suffix_pathはDeliveryDestinationで設定した destination_resource_arn の後に続くパスになります。ここの指定が厄介で、 destination_resource_arn の値によって実際の設定値が変わります。 パスを指定した場合 指定した suffix_path がそのまま使われる パスを指定しなかった場合 指定した suffix_path の先頭に AWSLogs/{account-id}/CloudFront /が追加される このあたりの仕様はややこしいため、公式ドキュメントに載っている パスの設定例 を参照することをおすすめします。 注意 標準ログ(legacy)について 標準ログv2は従来の標準ログ(legacy)とは独立した機能です。v2用の設定を追加しただけだと二重出力になってしまうため、無効化を忘れないようにしましょう。 AWSコンソール上から操作した場合 AWSコンソール上から標準ログv2を作成した場合、その裏で先述の3リソースが作成されます。このうちDeliverySourceは ログを無効化しても消えず、残り続けます 。1つのリソースに対してDeliverySourceは1つしか作成できないため、残っているとTerraformからの作成も失敗します。 AWSコンソール上からは削除する手段がないため、AWS CLIから削除してください。 # 既存のDeliverySourceを検索 % aws logs describe-delivery-sources --region us-east-1 { "deliverySources": [ { # 自動作成されたDeliverySourceはCreatedByCloudFront-XXXの命名になっています "name": "CreatedByCloudFront-XXXXXXXXXX", "arn": "arn:aws:logs:us-east-1:{my-account}:delivery-source:CreatedByCloudFront-XXXXXXXXXX", "resourceArns": [ "arn:aws:cloudfront::{my-account}:distribution/XXXXXXXXXX" ], "service": "cloudfront", "logType": "ACCESS_LOGS" } ] } # DeliverySourceを削除 % aws logs delete-delivery-source --name CreatedByCloudFront-XXXXXXXXXX --region us-east-1 まとめ TerraformでのCloudFront 標準ログv2の設定方法をご紹介しました。 標準ログv2の登場により、CloudFrontのログ周りの辛さが一気に解消されるようになります。S3に送信する上では料金も変わらないため、積極的に移行をおすすめしたい機能です。 また実体となるCloudWatch Log Delivery(v2)はCloudFrontに限らない汎用的な仕組みになっており、他サービスへ展開していくことが期待されます。ALBのログなども対応すればより自由な設定が可能になるため、今後の展開に期待したいところです。 本記事が皆様の良きTerraformライフの一助になれば幸いです。

Notionの管理者をしている石川です。 先日行われたNotion Japanチャンピオンズコミュニティアワード2024で「Notionチャンピオンエンフォース賞」をいただきました！2年連続受賞です！！ 参考： Notionチャンピオンズコミュニティで「Notion導入推進賞」をいただきました！ – NIFTY engineering チャンピオンエンフォース賞 左は2023年の導入推進賞、右が2024年のチャンピオンエンフォース賞 チャンピオンエンフォース賞 　本コミュニティの活性化に寄与した方に贈られる賞です。 　SlackやNotionページでアクティブに発信など活動くださった方。 Notion Japanチャンピオンズコミュニティアワード2024から引用 本当に何も聞いていなかったので驚きました。 コミュニティのイベントには毎回参加していてファシリテートする回もありましたし、いつも新機能のフィードバックをし続けている点が評価されたのかなと思ってます。 今年もまたなにかしら受賞できるように、Notionをガンガン使い倒していこうと思います！ 2024年のNotion Notion AIのアップデートがすごかった印象ですね。 Notion AIの新機能を先に体験させてもらえて（事例紹介としても出させていただきました） 、Notion AIの社内普及にも大きく役立ちました！SlackとGoogle Drive連携の効果はかなり大きかったです。 あとオートメーションやWebhookアクションの追加、フォーム・チャート機能など、日々をもうちょっと便利にしてくれる機能追加など嬉しかったですね。やりたいことがついにNotion単体でできるようになったものが増えました。 また個人的には Make with Notion Showcase Tokyo にてSimonとFuzzyと対談するという貴重な機会をいただけて大変嬉しかったです。次は発表側として立ちたいですね。 参考： ICYMI: 2024年にリリースされたすべてのアップデート 当ブログでもNotionについてのよくある使い方から、これできないのかなという検証の記事など書いていますので、気になる方はほかの記事ものぞいていってもらえると嬉しいです。 参考： Notion – NIFTY engineering

はじめに こんにちは。新卒1年目の佐藤、緑川、keyliumです。24新卒の開発研修にてAWS Amplifyを使用しました。 詳細につきましては以下のブログ記事をご覧ください。 今年もリアルハッカソン合宿に行ってきました！＠ノジマ大磯スクウェア ハッカソン合宿制作記② | 双方向通信の数字対戦ゲームを作成しました！ 開発をしていくなかで、公式ドキュメントが英語のみで、参考となる日本語のブログが数少なかったので、本記事で説明していこうと思います。 本記事は2025年2月20日現在の情報です。 最新情報につきましてはAWS公式ドキュメントをご確認ください。 AWS Amplifyとは？ 上記2つ目の記事で概要について説明しています。 AWS AmplifyにはGen 1とGen 2の2つのバージョンが存在します。 Gen 2は2024年5月6日に 一般提供が開始された 1年経たずのバージョンになります。 Gen 2の特徴としては以下の4つになります。 フロントエンドだけでなく、バックエンドもTypeScriptで開発が可能に SandBox環境を用意し、相互に影響を与えずに並行開発が可能に Gitブランチに対応した本番・ステージング環境を自動構築し、プレビュー後に本番へ反映できる ビルド・デプロイ・データ管理などの主要機能が統合されたコンソールで一元管理可能に Gen 1では、 amplify configure や amplify init 、 amplify add などのAmplify CLIを使ってバックエンド構築を行なっていました。 一方、Gen 2では上記のコマンドは使えなくなり、AWS CDKとTypeScriptでの構築が可能となりました。Amplify専用のコマンドはSandBoxの作成・削除があります。 使い方を調べる際に「AWS Amplify 使い方」と検索しても、2024年5月以前の記事はGen 1を使っており、AIツール（ChatGPTやGitHub Copilotなど）に聞いても、Gen 1の情報がほとんどです。 Gen 2の情報を知りたい場合は、 公式ドキュメント もしくは検索エンジンで、「Gen 2」の文字を必ず入れた上で期間指定も設定して検索してみてください！ アプリをデプロイしてみる 今回は公式ドキュメントの Quickstart を参考に、 TypeScript + React + Vite で説明をしていきます。 他にもNext.js, Angular, Vue, JavaScript, React Native, Flutter, Android, Swiftなどのフレームワークに対応しています。 1. 公式テンプレートを使ってGitHubリポジトリを作成する amplify-vite-react-template というテンプレートを使用します。 URLにアクセスし、右上の Use this template ボタンからリポジトリを作成してください。 また、Quickstartには記載ありませんが、 他のテンプレート も用意されています。 amplify-social-room amplify-backend-template 2. AWSにデプロイする AWS Amplifyのコンソール画面 AWS Amplifyのコンソール画面 AWS Amplifyのコンソール画面 リポジトリを作成したら、Amplifyに連携します。 連携すると、自動でビルドとデプロイが走り、　amplifyディレクトリ内の情報をもとにAWSリソースが作られていきます。 1. ソースコードプロバイダーを選択 1. ソースコードプロバイダーを選択 1. ソースコードプロバイダーを選択 2. リポジトリとブランチを追加 2. リポジトリとブランチを追加 2. リポジトリとブランチを追加 3. アプリケーションの設定 3. アプリケーションの設定 3. アプリケーションの設定 4. 確認画面 4. 確認画面 4. 確認画面 「3. アプリケーションの設定」にて、Node.jsのバージョンを指定したい場合は詳細設定のタブを開き、環境変数に画像の通りに設定してください。 また、個人の好みですが、YMLファイルを編集し、nvm（Node Version Manager）を使ってNode.jsのバージョン指定や、npmではなく、pnpmやyarnを使う設定を入れることができます。 デプロイ中 デプロイ中 デプロイ中 概要画面 概要画面 概要画面 ビルド・デプロイ状況 ビルド・デプロイ状況 ビルド・デプロイ状況 アプリケーション画面 アプリケーション画面 アプリケーション画面 アプリケーションが無事にAWSにデプロイできました！ このテンプレートはDynamoDBとAppSyncのGraphQLを使ったTodoリストになっています。 Todoを追加すると、1つのDBに保存され、他のユーザーに対して描画更新を行う処理になっています。 Amplifyの設定ファイルについて amplifyディレクトリ内でバックエンドとして使うAWSリソースの定義をしています。 ├── amplify │   ├── auth │   │   └── resource.ts │   ├── backend.ts │   ├── data │   │   └── resource.ts │   ├── package.json │   └── tsconfig.json amplify/backend.ts がバックエンドを定義している大元になります。 現在はauth（AWS Cognito）とdata（AppSync + DynamoDB）の設定がされています。 amplify/auth/resource.ts では認証にメールやパスワード、電話番号など、何を使うのか、の設定ができます。外部IDプロバイダー（GoogleやAmazon、Appleなど）も設定可能です。 amplify/data/resource.ts ではスキーマ定義がされており、必要なデータ構造を定義してあげることで、自動でDynamoDBにテーブルが作られ、AppSyncと連携されます。 現在ではTodoリストに登録された文字列のみ定義されています。 const schema = a.schema({ Todo: a .model({ content: a.string(), }) .authorization((allow) => [allow.publicApiKey()]), }); 以下のようにリレーションの設定もできます。 const schema = a.schema({ Rooms: a .model({ roomId: a.id().required(), // 必須項目 roomName: a.string().required(), maxCapacity: a.integer().required(), currentCapacity: a.integer().required(), status: a.enum(["OPEN", "CLOSED"]), users: a.hasMany("Users", "roomId"), // Added relation to Users }) .identifier(["roomId"]) // Primary Key .authorization((allow) => [allow.publicApiKey()]), Users: a .model({ userId: a.id().required(), // 必須項目 roomId: a.id().required(), userName: a.string().required(), room: a.belongsTo("Rooms", "roomId"), // Added relation to Rooms }) .identifier(["userId"]) // Primary Key .authorization((allow) => [allow.publicApiKey()]), }); authとdataの他にもstorage（Amazon S3）の設定が可能で、ファイルのアップロード・ダウンロードなどの機能が追加できるみたいです。 data（AppSync + DynamoDB）の操作方法 テンプレートでは src/App.tsx でDBに更新があった際に描画更新を行うSubscribe設定と表示されたプロンプトに入力したテキストをDBに登録する処理を行っています。 useEffect(() => { client.models.Todo.observeQuery().subscribe({ next: (data) => setTodos([...data.items]), }); }, []); function createTodo() { client.models.Todo.create({ content: window.prompt("Todo content") }); } create関数の他にもupdate関数やdelete関数も使用可能です。また、list関数やget関数を使用することで、対象のDBに保存されている全データのリスト取得やフィルターでデータを絞ることも可能です。 リアルタイムイベントのSubscribe設定にも4つ種類があり、データが新規作成されたことを検知するonCreate、すでに入っているデータが更新されたことを検知するonUpdate、データが削除されたことを検知するonDelete、全てをまとめたobserveQueryがあります。 const createSub = client.models.Todo.onCreate().subscribe({ next: (data) => console.log(data), error: (error) => console.warn(error), }); // Subscribe to update of Todo const updateSub = client.models.Todo.onUpdate().subscribe({ next: (data) => console.log(data), error: (error) => console.warn(error), }); // Subscribe to deletion of Todo const deleteSub = client.models.Todo.onDelete().subscribe({ next: (data) => console.log(data), error: (error) => console.warn(error), }); Subscribeを止めたい時は sub.unsubscribe(); で解除できます。 まとめ 以上が私たちが調べたAWS Amplifyの情報になります。 他にもAWS Lambdaと簡単に連携できたり、直近ではAI kitというものを使うと簡単にAIとの会話やAIによる画像生成が可能になったみたいです。 また、公式ドキュメントを読むのやだ！って方にはAmazon Q Developerを使ったコード提案に対応しています。現時点では日本語未対応ですが、うまく活用すれば、わざわざ日本語の記事を探さなくてもAWS Amplifyで開発できそうですね。 アプリケーション開発を簡易化できるAWS Amplifyの今後の機能に注目していきたいと思います！ 参考記事 https://aws.amazon.com/jp/builders-flash/202411/awsgeek-aws-amplify-gen2/

エンジニアリングマネージャーをしています芦川です。 2025年01月22日にAWS様にAmazon Working Backwardsワークショップを開催してもらう機会があり、社内からオフラインで15名参加しました。また、その後の内容のおさらいイベントを社内で実施し、30名の参加があり、社内でもかなり反響があったと思います。今回、その内容を公開します！ ※AWS様提供の資料は非公開のため説明はテキストのみになります。 結論 結論から先に言ってしまいますが 参加してよかった！！ につきます。 企業が提供するサービスは誰のためなのか？という再認識とそこを突き詰めるとこういう方法論に行き着き、知っておいて損は絶対にない ！ という話でした。 Amazon Working Backwardsとは？ Working Backwardsとは、Amazonがほとんど全てのサービス企画において実践している手法です。最大の特徴は、「お客様体験」を最優先に考え、そこから逆算してサービスを作り上げていく点にあります。 「お客様体験がどう変わるのか？」がサービス企画時の重要なポイントです。 Amazon GOの事例 この手法を理解する上で、Amazon GOの誕生プロセスは非常に示唆に富んでいました。きっかけは「シアトルで働く社員のランチ時間にスーパーが非常に混雑してしまう」という課題でした。この解決策として出てきたのが「レジをなくして待つ必要をなくす」というアイデアです。レジをなくす=無人化というと、人的コストの削減目標が最初にあったのでは？のように考えてしまいますが、そうではなく、あくまで課題解決をするためにお客様の体験をどう変えたか？ ということでした。（実際に完全無人化はしておらず人的コストは掛けているそうです。） イノベーションを支える3つの行動指針 Amazonでは、 Our Leadership Principles (OLP) の中でも特に以下の3つの原則をイノベーションの基盤としているとのことです。 Customer Obsession Think Big Bias for Action この行動指針を使って、サービスを考えていきます。特に大事なのは、Customer Obsessionであり、お客様を何よりも中心に考える、ということになります。また、Bias for Actionでは、意思決定スピードを上げるためには完璧な企画をするのでなく、やり直すことができる前提で過剰な調査や検討を避けよ、というところが私は個人的に好きなところです。 実践方法：プレスリリース駆動の企画開発 まず、お客様が誰で、どのようにお客様体験を変えたらいいのか？ということを以下の5つの質問に応えることでアイデア出ししていきます。 お客様は誰ですか？ お客様についてどんな気づきがありますか？ ペルソナ設定 お客様の課題や新しい可能性は何ですか？ 問題の設定 解決策と、お客様にとって最も重要なメリットは何ですか？ 解決策（複数書いてよい） 課題が解決した、新しいお客様体験はどのようなものですか？ どうお客様体験が変わったか？（複数書いてよい） どのようにお客様と検証し、何を成功指標としますか？ KPI そして、ざくっとでもやりたいことが定まったら、この回答を元にAmazonでは、新しいサービスや機能の企画において、以下の3つのドキュメントを作成します。 プレスリリース ：1-2ページで、お客様にとっての価値を簡潔に説明 FAQ ：想定される質問と回答を20-30ページ程度で詳細に記述 ビジュアル ：具体的なお客様体験をストーリーボードで表現 特筆すべきは、プレスリリース形式を採用している理由です。ここは今回のワークショップで目からウロコの点でした。 プレスリリースとは、そもそもの用途においてお客様が初めてそのサービスを知る入口となる文章です。何がどう変わるかをシンプルな文章でお客様体験の変化を表現する必要があります。社内のアイデアから企画する時点でそのフォーマットを使って書くということは、お客様体験がどうよくなるのかを最初から簡潔な文章で表現することになります。周囲のレビューを通してブラッシュアップしていくことで、お客様の何がどうよくなるのか、ということがさらに明確になっていきます。何十往復もレビューを繰り返すとのことでした。 で、さらに聞けて良かったと思ったところが以下でした。 テキストベースなので、プレゼンが必要なく、非同期で誰でもレビューできる。 企画が個人のプレゼンスキルに依存せず、アイデアを平等に評価できる。 プレゼン資料（pptなど）を作る時間が不要になる。 なんと合理的に企画を洗練するのか！ 流石だなあ、と思いました。 今回は体験版ということで、プレスリリースのワークしかなかったのですが、FAQ、ビジュアル作成のところもどこかで学んでみたいと思います。 ワークショップから得られた気づき 今回、参加者からは以下のような具体的な気づきの声が聞かれました。 「企画書をプレゼンではなく、プレスリリース形式で書くことで、お客様が実際にサービスを知る形に近づけられる点が画期的だった」 「各項目を3-4分という短い時間で区切って考えることで、逆に悩みすぎず、スピーディーにアイデアを出せた」 「黙読形式でのレビューは、プレゼンスキルに依存せず、純粋にアイデアの価値を評価できる点が新鮮だった」 「お客様のペルソナから課題、解決策という流れで考えることで、より具体的なサービス価値を描きやすかった」 「普段は実現可能性や運用面を先に考えてしまいがちだが、まずはお客様価値だけに集中して考えることの大切さを実感した」 特に印象的だったのは、多くの参加者が「プレスリリース形式」という手法の効果を実感していた点です。これは単なるドキュメントのフォーマットではなく、お客様視点でサービスを考えるための思考の枠組みとして機能していることが分かりました。 今後への活かし方 このワークショップで学んだ手法は、新規サービスの企画だけでなく、既存サービスの改善や、社内ツールの開発にも応用可能だと思います。 重要なのは、やはり常にお客様体験を起点に考え、その価値をシンプルに表現できるかどうかです。 今回、Working Backwardsの実践を通じて、私たちは「お客様にとって本当に価値のあるもの」を作り出すプロセスを学びました。この学びを活かし、より良いサービス開発に取り組んでいきたいと思います！いや、すばらしい。AWS様、ありがとうございました。

はじめに 初めまして！新卒一年目のけに、後藤、塚崎です。 本記事では、私達が参加したエンジニア定例合宿で開発した飲食店に関する投稿を行うサービス「ふーどぴあ」について紹介します。 エンジニア定例合宿の詳細につきましては以下の記事をご覧ください。 今年もリアルハッカソン合宿に行ってきました！＠ノジマ大磯スクウェア チームメンバー紹介 けに 今回の担当：バックエンド全般、DB構築、ログイン処理 一言：お金が貯まりません 後藤 今回の担当：API実装、SQL文作成 一言：散歩マスターになりました。 塚崎 今回の担当：フロントエンド全般、画像アップロード機能 一言：早朝、散歩で海に行くのが健康的で良かったです。 プロダクト紹介 概要 私たちが開発したのは、食べ物に関する投稿を行うサービスになります。 食べたいものや条件に見合う店舗を検索して探すようなサービスではなく、タイムラインに流れてきた投稿を眺めていて食べたいと思った店を見つけ、実際に訪れる。そんなサービスがあると面白いのではないかと思い、作成しました。 実装した主な機能としては以下になります。 各ユーザーが投稿したレビューを見ることができる 閲覧するだけではログインは不要 レビューを投稿することができる 投稿する際はログインが必要 画像の投稿も可能 使い方 まずはホーム画面です。ここには、ユーザーの投稿が一覧で表示されています。 この画面から、ログインや各投稿の詳細ページへ遷移することができます。 アカウントはユーザー名とパスワードを設定することで作成できます。 ログインボタンからログインを行うことができます。 また、投稿をクリックすると各投稿の詳細を見ることができます。 ※ コメントはダミーのものを入れています。 使用技術 開発言語はフロントエンドにはTypeScript、Next.jsを選択し、CSS FrameworkにはTailwind CSSとshadcn/uiを採用しました。 バックエンドはPythonを選択し、FrameworkにはFast APIを採用しました。 ユーザー情報や投稿内容を保存するDBにはPostgreSQLを採用し、写真データを保存するストレージにはMinIOを利用しました。 その他に使った技術スタックは以下になります。 開発環境 コード管理 Git / GitHub コンテナ環境 Docker フロントエンド 言語 TypeScript Framework Next.js CSS Framework Tailwind CSS shadcn/ui Linter / Formatter Prettier Package Manager pnpm バックエンド 言語 Python Framework FastAPI Linter / Formatter ruff Package Manager uv DB PostgreSQL オブジェクトストレージ MinIO 開発の流れ 0日目：事前準備 アイデアソン 実装概要検討 DB設計 1日目：環境構築、実装 開発環境構築 投稿一覧の表示画面、APIの実装 2日目：実装 午前 投稿機能系をメインに実装しつつ、ユーザー管理機能も実装 午後 画像投稿処理の実装 3日目：最終調整・成果発表 バグ修正 コメント投稿APIの実装 成果発表資料作成 工夫したこと 役割分担を明確にしたこと 私たちのチームではフロントエンドとバックエンドを分離して開発を行いました。 完全に分離することでそれぞれが得意な領域を担当することができ、効率良く開発を進めることができました。また、開発を進めていてコンフリクトが発生することもなかったので、そこもフロントエンドとバックエンドを分離する大きなメリットだと感じました。 フロントエンド 今回はフロントエンドの実装をするにあたって、Tailwind CSSやshadcn/uiなどのCSSフレームワークを採用しました。一からCSSを書いてスタイリングするとなるとかなり時間が掛かってしまいますが、今回はCSSフレームワークを用いることで短時間でUIを構築することができました。特にTailwind CSSはCSSのクラス名を考える時間が不要になるので、こういったハッカソンにおいては最適なフレームワークだったなと感じました。 バックエンド 今回はレイヤードアーキテクチャを採用しました。レイヤー毎に責務を分離したおかげで、細かい仕様変更やCRUD系機能の追加の際にスムーズに実装を行うことができました。 また今回はFast APIを採用していたこともあり、レスポンススキーマなどのバリデーションをpydanticを用いて入念に行いました。そのおかげで、レイヤー間のデータの受け渡しやレスポンスの型で戸惑うことがなく実装を進めることができました。 画像のアップロード機能 今回は画像をAPI経由で送信して、オブジェクトストレージに保存するように実装しました。 一般的にはオブジェクトストレージにAWS S3を採用することが多いと思いますが、今回はシステムをローカルで動作させている都合上、Dockerを用いてローカル環境にMinIOを建て画像を保存する方針としました。 MinIOはAmazon S3とAPI互換性を持っている点、既存のS3クライアントやアプリケーションをそのまま利用できる点、ローカルで構築できる点から採用しました。 今回実装した画像アップロード機能は以下の流れになっています。 フロント側でユーザーからアップロードされた画像データをbase64形式でエンコードし、文字列にする エンコードした文字列をバックエンドのAPIに送信する バックエンド側で受け取った文字列をデコードして画像データに戻す 画像データをMinIOのAPIを使って、MinIOに保存する MinIO側で画像にアクセスするURLが発行される 本来は画像サイズの制限、拡張子の判定などについても考慮する必要がありますが、時間制限の都合上、本開発ではこの形での実装となりました。 様々なサービスで実装されている機能のため簡単に実装できるものだと思っていましたが、実際に一から実装してみることで、その大変さを痛感しました。 学んだこと・成長したこと 良かった点 仕様策定、DB設計、API設計を事前に行った 開発が始まっていきなり実装に入るのではなく、細かいところまで事前に方針を決めてから実装に入りました。そのおかげで、DBで必要なカラムが足りなかったなどのトラブルは起きず、手戻りすることなく開発を進めることができました。 仕様変更にも柔軟に対応 仕様の検討段階では、AWS ECS上で動作させる予定で、WebSocketなど双方向通信を利用したシステムの開発を行う予定でした。しかし、実際に開発を行っていく中で進捗と期限を勘案すると間に合わないのではないかという話になり、ローカルで動作するものを完成させることに専念しました。実際にAWS上での動作を継続していたら完成が間に合わなかった可能性があったので、切り替える判断がすぐにできたのは良かったと思います。 また画像アップロード機能を開発するにあたって、画像ファイルの置き場所を検討した際に認証関係のリソースの作成を行うよりも、MinIOを利用してローカルにストレージを建てる方針を取りました。画像保存の方法については事前に話し合えていなかったのですが、開発の中で話し合って方針を修正することができました。 よくなかった点 実装コストの見積もりが甘かった 設計の段階ではコメント機能や投稿検索機能なども実装する予定でしたが、想定よりも時間が足りず、実装できなかった機能が多数ありました。例えば、コメント機能ではAPIの実装はできましたが、フロントの実装が間に合わなかったというケースがありました。 また、実装することを優先して急いでしまったためにレビューの時間が全くとれませんでした。 ログイン認証や画像アップロードなど想定より時間がかかってしまった機能などもあったため、事前の設計段階でもう少し作業時間を考慮できればよかったなと思いました。 開発の優先度 例えば、ログイン認証系の機能については、事前に機能として入れる前提のDB設計をしていました。しかし実際にログイン機能を実装するとなると、今までの経験上ある程度コストがかかってしまうなと感じていました。 ログイン機能は必須とはせずに匿名でも投稿できるような仕様にしておけば、その時間を別の実装にあてることもできたので、開発の優先度を考慮不足だったと感じました。実際に最終日にコメント機能のAPIは完成していたので、時間があればフロントからの投稿処理も可能でした。 今回の経験を通して、短い期間では開発コストを考慮して優先度を決めていくのはやはり重要だと感じました。 まとめ 今回のエンジニア定例合宿では、研修やOJTで培った知識と経験を活かし、効率的な開発を進めることができました。事前の仕様検討や明確な役割分担はいい方向に働く結果となりました。 また、限られた時間の中でタスクの管理や優先順位付けを行うなど、今後の業務でも発生しうる課題に直面しました。これらの一端をハッカソンで感じることができたのは今後の業務でも生きるいい経験になりました。 今回の合宿を通じて各自発見や課題が浮かび上がったと思うので、この経験を糧に更なる成長を目指していきます。

最近GitHubの認証情報の取り扱いで悩んでいる GHE管理者の石川です。 GitHub ActionsのOIDCを使った各種クラウドとの認証便利ですよね！ OIDC利用も増えてきたしPAT周りをもっと綺麗にできないだろうかと考えています。 classic PAT廃止してFine-grained PATとGitHub Appにしたい → いまどのくらい使われているのだろう → GitHub上に認証情報記載されてない？ といった具合に、整理よりも先に掃除の必要性を感じてきました。 弊社のGitHub組織には現状Publicリポジトリはないため、即座に危うい状態というわけではありませんが、連携先やデプロイ先で漏洩する可能性はあるので、昨年何度が記事を目にした Trufflehog を導入することにしました。 サンプルリポジトリでお試し 都合よく認証情報の入ったリポジトリは記憶にないので、公式が用意してくれている認証情報が入ったリポジトリをので体験してみます。 trufflehog github --repo=https://github.com/trufflesecurity/test_keys --issue-comments --pr-comments Trufflehogのサンプルリポジトリーをスキャンした検出結果 いい感じですね、コマンド一発でやりたいことができるのは素晴らしい！ 組織内全リポジトリに対してスキャン 組織内のすべてのリポジトリに対して実行すると、かなりの時間がかかるのでローカルではなく適当なサーバー上から初回スキャンをしてみます。詳しくは後述してますがGitHub API制限にひっかかりそうなのでスリープをいれて実行しました。 --no-verification で有効有無を問わず存在を確認して、どのようなDetectorが検証されたのか、検証ありで実行しても大丈夫そうか確認して、本番スキャンでは --results=verified,unknown にして実行しました。 結果、思ったよりたくさん検出されました！え、こんなにあるの！？と思った大部分はSlack Webhook。これは最悪漏洩しても影響は微量なので一旦放置。 ほかにも見過ごせない認証情報もありましたので、検知結果をIssue化する仕組みを作っていきます。 定期実行用GitHub Actionsを作成 事前準備 GitHub AppとPATを用意します。 更新リポジトリチェック＆Issue作成用GitHub App Read  access to metadata Read  and  write  access to issues and organization projects Trufflehogスキャン用PAT Read  access to code, issues, metadata, and pull requests WF1: 更新のあったリポジトリを取得してTruffehogを実行 日次で更新のあったリポジトリのみをスキャン対象としています。 GCSに入れた後BigQueryで集計したいので使いたいので結果は --json で出力しています。 cronで日次実行 更新のあったリポジトリ一覧を取得（GitHub App Tokenを使用） Trufflehogでスキャン（PATを使用） スキャン結果をGCSに保存 - name: Run get recent update repos script env: GITHUB_TOKEN: ${{ steps.app-token.outputs.token }} run: python get_updated_repos.py > /tmp/recent_update_repos.txt ... - name: Install Trufflehog run: | curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/refs/tags/v3.88.2/scripts/install.sh | sh -s -- -b /usr/local/bin # Trufflehog用のGitHub Actionsはあるが、全スキャン時に使ってたShellを使い回して実行している - name: Secret Scanning env: TRUFFLEHOG_SCAN_PAT: ${{ secrets.TRUFFLEHOG_SCAN_PAT }} run: | wc -l /tmp/recent_update_repos.txt /bin/bash trufflehog_scan.sh /tmp/recent_update_repos.txt - name: Upload scan results id: upload-files uses: google-github-actions/upload-cloud-storage@v2 with: path: scan_logs destination: <YOUR BUCKET> gzip: false 個々のリポジトリでCI時にスキャンしたい場合 git-secrets等でコミット前に防ぐのが最適ではありますが一応TIPSとして。 --since-commit で特定のコミット以降、 --max-depth で対象とするコミット数、 --branch で対象ブランチなどを指定すればスキャン時間を短縮できます。 --github-actions でGitHub Actions用の出力結果にすることもできます。 WF2: 検知結果を対象リポジトリのIssueへ登録 デバッグしやすいのでスキャンのワークフローとは分けてます。 WF1が成功したら実行 スキャン結果とIssue登録済みmd5をGCSから取得 スキャン結果のmd5を作成してIssue作成済みならスキップ or 特定のDetectorならスキップ 作成済みではない検知結果を リポジトリ・パス・Detector で group by （一つ一つIssueを作ったら邪魔なのである程度まとめる） 対象リポジトリにIssueを作成し、指定Projectに追加（GitHub App Tokenを使用） Issue登録済みmd5をGCSへ保存 - name: Download scanned results run: | gcloud storage cp gs://<YOUR BUCKET>/scan_result_issue_md5_hashes.txt scan_result_issue_md5_hashes.txt mkdir -p scan_logs gcloud storage rsync gs://<YOUR BUCKET>/scan_logs/date=$(date +%Y-%m-%d)/org=<YOUR ORG>/ scan_logs/ cat scan_logs/*.json > scan_results.json ... # Issueを作る権限のあるTokenを得るために作成対象リポジトリを取得 - name: Get scan result repos matrix id: repo-matrix run: | python get_scanned_results.py scan_results.json >> $GITHUB_OUTPUT - name: Create GitHub App Token uses: actions/create-github-app-token@v1 id: app-token with: app-id: ${{ vars.APP_ID }} private-key: ${{ secrets.PRIVATE_KEY }} owner: ${{ github.repository_owner }} repositories: ${{ join(fromJson(steps.repo-matrix.outputs.matrix).repos) }} # PythonからIssue作成とProjectへの追加を実行、例外処理もここで対応 - name: Run create_issue script env: GITHUB_TOKEN: ${{ steps.app-token.outputs.token }} run: python create_issue.py scan_results.json scan_result_issue_md5_hashes.txt continue-on-error: true - name: Upload md5 hash id: upload-files uses: google-github-actions/upload-cloud-storage@v2 with: path: scan_result_issue_md5_hashes.txt destination: <YOUR BUCKET> gzip: false GitHub Projectに追加することで、どのリポジトリにどのくらい認証情報が残っているか、一覧で確認することができます。 コード側は変更して対処したり、認証情報を無効化した場合、次回スキャン結果から消えます。それをトリガーに自動でIssueも閉じたら綺麗ですがそこまではやっていません。 ちなみに初回スキャンで見つけた検知結果はGCSに上げて、事前にActionsを手動実行することでIssue登録を済ませています。 気を付ける点 TrufflehogはGitHub App Tokenに未対応 Support scanning GitHub Orgs with GitHub App Token · Issue #1513 · trufflesecurity/trufflehog App対応していないので、個人のPATを使いましょう。 GitHub App Tokenで動かそうとすると、 Resource not accessible by integration エラーが起きます。 GitHubのAPI制限 Trufflehogがどの程度APIを叩いたかは、InsightsのREST APIのグラフからスキャンに使ったPATの所持ユーザーを選択することで確認可能です。 Trufflehogのスキャンに使っているPATのAPIリクエスト数 日次で更新されるリポジトリ数にもよりますが、いまのところ5,000req/hour の制限を超えることはまずなさそうです。 初回全リポジトリスキャン、1日に大量のリポジトリ更新、IssueやPRやコメントが大量にある場合はAPI制限を超えやすくなりますので、その場合は時間を分けてスキャンしたり、スリープ入れて1時間内スキャン数を抑えたりして回避しましょう。 参考： Rate limits for the REST API – GitHub Docs 認証情報側が更新されたらスキャンした結果も変わる リポジトリ上からは消えていないが認証情報は無効にした場合、 VerificationFromCache や ExtraData に変化がありました。検知対象の同一性を担保するユニークIDを作る時は、こういう要素を含まないように作成しましょう。これを理解していなくて、最初重複したIssueを作ってしまいました。。 Macから実行したとき error trufflehog failed to parse commit date エラーが出る trufflehog fails to parse localized timestamp · Issue #3338 · trufflesecurity/trufflehog 検出結果のTimestampが Timestamp: 0001-01-01 00:00:00 +0000 で表示されます。 Ubuntuではエラーは起きなかったので気になる方は、サーバーなりコンテナなりで実行しましょう。 今後の予定 Trufflehog初めて使いましたが、サクッといい感じにやってくれるし、痒いところにも手が届くツールでとても便利ですね。GitHub Advanced SecurityならSecret scanningも対応していますが、組織内全リポジトリを対象にしたいとなると金銭的に厳しいものがありますし、OSSでカバーできるのはありがたいです。 実は検出まではよくても、本気でGitHub上から跡形もなく消し去るのはかなり大変な作業だったりします。 参考： GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング そのため一旦のゴールとして以下が適当かなと思っています。 最新のコードに認証情報が含まれていないこと 一度でもGitHub上にコミットしてしまった認証情報は再発行すること 各人のgit-secrets等の設定厳密化 まだまだ先は長そうですが、少しずつでも今日よりも明日をセキュアにしていきたいと思います。

NIFTY TechDay 2025で登壇しました！ ニフティで開発チームのスクラムマスターをしながら、スクラムエバンジェリストという肩書きで情報発信をやっている西野といいます。 2/8（土）に開催されたNIFTY Tech Day 2025で「スクラムマスター入門者のための学習マップ 〜効果的な学びと実践〜」という内容で登壇したので、内容をブログにまとめました。 私のスクラム学習ロード、スクラムの学習マップ、それを踏まえてどう学習していくかという内容です。 スクラムマスター以外でも、スクラムの学習ってどこから手をつければいいんだろう？という方はぜひ読んでみてください。 スクラムマスター入門者のための学習マップ 〜効果的な学びと実践〜 登壇内容 このセッションの目的 スクラムガイド以外の学習リソース を体系的にマップ化することで、スクラムマスターの学習障壁を取り除く スクラムマスターは、個人学習だけでなく 共同学習する「仕組み」 をつくることで学習効果を最大化できる。どんな仕組みが必要かを伝える 私のスクラム学習ロード 6年間スクラムマスターをやってきたなかで、自分がスクラムを学んできて、効果的だったことや課題だったことををふりかえっていきます。 スクラムを始めようとおもったきっかけ アプリのPdMになったこと。サービスが急成長し、機能追加を急いでしまってリファクタが不足し、現場のエンジニアから危機感を覚える声があがる 自分もメンバーも今の仕事のやり方がベストとは思えない状態になってきたので、いくつかの開発手法を検討した結果「スクラム」にチャレンジ 未経験のスクラムにチャレンジした時期 学習効率、学習量は最高 。チームメンバーと活発にスクラムについて議論し、実践していた時期 一方、スクラムの実践で今まで見えていなかった問題もみえてきて、それを一人で解決しようとしてしまいつらい時期でもあった 自分のチーム＋ほかチームをサポートしていた時期 教えることで学習内容の定着や応用はできてきたが、 全体的な学習効率はやや低め スクラムの実践によりリリース数向上とリファクタが両立可能となり、成果が出てきた。自分としても、前よりはスクラムが「なんかわかった気分」になっている ほかチームにもスクラム導入がすすみ、教えてほしいと言われた時期 自分のチームではおきていなかった・見えていなかった課題を知るが、スポットでのサポートなので解決までのサポートは十分にはできず 社内外への登壇をしていた時期 学習範囲が広がり、学習量も増えるが、具体的な組織課題へのアプローチは手応えがなく 学習効率はそこそこ ジョインしているスクラムチームが成長し、スクラムマスターとしてスクラムチームにサポートできることが減ってきた時期 チームを超えて組織をサポートするためにリソースを使い始める 社内スクラムマスター同士で組織課題をとらえる時期 今現在はここ。 学習効率と学びの楽しさのバランスが一番いい いままではどう道を歩くかを考えていたが、いったん高台にのぼって全体をみるほうが効率がいいのではと気づけたような状態 充実した学習ができている理由は2つある 社内コーチングをはじめたこと。チーム内だけでなく、チーム外にコーチングを開始したことで、自分には知らなかった組織課題があることをが見えてくる 同じ課題を抱えた社内スクラムマスター同士で学習ができている 楽しく学べているシーンを思い出すと、「唸り」がある 自分たちの普段の仕事や課題に照らし合わせて「そういうことか」と思えるブレイクスルーがあるときは、必ず直前に「うーん」とうなっている このうなりはスクラム学習初期もあったが、問題を一人で抱えていたのでつらかった。 組織課題を捉えたいというメンバーと一緒に考えているので、学習初期の孤独感がない 6年間のスクラム学習・実践で気づいたこと スクラムガイド「だけ」では、スクラムの学習と実践には不十分 スクラムの関連知識の学習範囲が広すぎる 周辺にどういった知識があるのか、最初は手探り よい学習経験ほど、人と唸っている時間が長い 同じ課題を抱えている人同士で集まると「唸り」が生まれる ひとりで唸るのはつらいが、人と唸ったときは最終的に「面白い」「楽しかった」という感情につながった経験が多い スクラムの学習マップつくってみた スクラムガイド「だけ」では、スクラムの学習と実践には不十分という気づきがあったが、周辺知識が広すぎるためわかりやすくするために学習マップを作成しました。 学習領域の相互影響 前提として、学習のエリアには相互作用があります。わかりやすくするためにあえて4象限にしていることに注意して読んでください。 ものがうまれるコアには実装がある プロダクトやビジネスモデルは実装に影響を与える プロダクトをつくるのは人・組織 モノのやり方が一番上位概念 この4つは切り離せるものではありません。 スクラムの原理 黄色いエリアがスクラムのコアになる理論 スクラムはアジャイル開発のために生み出されたフレームワークである。さらに、システム思考、複雑性理論もスクラムの成立に関係があると考える 先が見通せないような複雑性が高いことをどう進めるか、という選択肢のひとつとしてスクラムがある プロセスと改善 この学習領域にあるわかりやすい要素として4つかいたが、もっとあると思う スクラムに直接的に関係するものをここでも黄色にしている スクラム関係なく注目されやすい領域。こういうプロセスで仕事をやるといいよ、という本はかなり多い ひとつのやり方にとらわれないよう、プロセスばかりでなく組織のこともあわせて学んでいくとよい 人と組織 黄色にはしていないが、スクラムガイドにも「リーダー」「コーチ」は単語としてはでてくる スクラムマスターとしては、チームをこえて組織的にスクラムを展開するには、ということを考えるために必要な領域 プロダクトとビジネス POと一番関わりが深いが、開発者もこれがわからないとうまく設計や測定ができなかったりする POとうまく会話するためにはここを共同学習していくといいのかなと思う 技術と実装 イベントに来ている人が一番興味関心が高いのはこの領域かと思う スクラムにおける役割別の学習領域 どのエリアから学ぶかは環境・人によって自由だが、どこから手をつければいいかという参考としてスクラムの役割と重ねてみた スクラムマスターは特に人と組織 開発者は特に技術領域 プロダクトオーナーはプロダクトとビジネス ステップとしては隣接するところを学ぶことがおすすめだが、どれを学んでもプロセスは関わってくる このマップの使い方 自分やチームの学習マップを描いてみると、一つの本が複数領域にまたがることが多いことがわかります。 元になったデータをPDF化したので、使いやすいようにご自由にカスタマイズしてご活用ください。 スクラムの学習マップ.pdf 効果的な「グループ学習の場」に必要な要素 学ぶエリアをきめたらどう学習するかを考えてみます。今までの経験のなかで、良い学習経験ほど「うーん」とうなっていることを解体してみると以下に気づきました。 唸るほど「考え抜く」仕組みをつくる 複雑な課題と、その解決に役立ちそうな学習内容とを照らし合わせて考えることを学習のメインにする 参加者の学習経験値に差がない（経験値は「0」が最も揃えやすい） 自分の経験だと、「教える」は記憶の定着としては良かったですが、学びが増える・次につながるかという観点でいうと限界がありました。 教わる方も先生役にきけばいいかとなってしまい、唸りがうまれない 唸るほど「考え抜く」仕組みをつくる 参加者に共通する課題があって、そこに役立ちそうな学習内容を学び、 参加者同士でアプローチしてみることまで含めて「学習計画」 なのだと思います。 まとめ 学び続けるために 「スクラムの学習マップ」見る・使う 「プロセスとカイゼン」「人と組織」「プロダクトとビジネス」「技術と実装」 「唸り」がグループ学習中にうまれるようにする うなりがない＝わかりやすすぎる、実践していない、本気でない 「うーん…」という時間があることが、結果、効率的な学習につながる 理論をどう学ぶかというマップを示したが、地図だけじゃなく実践、旅もしてほしいと思います。 学びたいことは行き方がわからない目的地です。 地図を囲んで旅行の予定を立てるように、悩みつつも楽しみな気持ちをもちながら、ワイワイ学んでいきましょう！

こんにちは。NIFTY engineeringブログ運用チームです。 ブログ運用チームでは、ニフティのエンジニアについての情報を世の中に広めるための活動をしています。 その活動の一環として、リレーブログを実施しています。 【リレーブログ企画第一弾】チーム紹介リレーブログをやります！ 【リレーブログ企画第二弾】24新卒リレーブログをやります！ リレーブログ第三弾のテーマは「CI/CDリレーブログ」です。 本記事に、CI/CDリレーブログのリンクをまとめていきますので、ぜひチェックしてください。 また、既に過去に投稿されたCI/CDに関する記事をまとめましたので、そちらもあわせてチェックしていただければと思います！ GitHubのOrganizationレベルで利用できるRunnerをAWS CodeBuildで用意する GitHub ActionsでPushしたついでにタスク定義も作ってほしい！ GitHub Actions self-hosted runner のマネージド型CodeBuildのrunnerとECSによるrunnerを検証する Docker Compose v1 が GitHub Actions で使えなくなった件 AWS CodePipelineを使用してWordPressへデプロイしてみる GitHubのプルリクにブランチごとのコメントを自動追加する GitHubのリリースノートを完全自動で公開したい GitHub ActionsとCodeシリーズを使用してモノレポ用のデプロイパイプラインを構築した話 プルリクエストの質を上げるGithub Actions活用法 AWS CodePipelineをGitHub Actionsへ移行してみた CI/CDリレーブログは以下のスケジュールで投稿予定です。お楽しみに！ 投稿予定 執筆者 記事タイトル 2025年2月中旬 渡邊 大介 Goで実装した複数のバッチを効率よくデプロイする 2025年2月下旬 IWS GithubActionsでもりもりデプロイしよう 2025年3月上旬 ブログ運営 未定

はじめに こんにちは。新卒1年目の佐藤、緑川、keyliumです。 本記事では3日間の社内ハッカソンにて私たちのチームが開発したWebアプリケーションについて紹介していきます。 開発合宿の概要記事はこちらをご覧ください。 今年もリアルハッカソン合宿に行ってきました！＠ノジマ大磯スクウェア メンバー紹介 普段、私たちはOJTジョブローテの3期目で、それぞれ異なる部署で業務を行っています。 佐藤 普段の業務：会員向けアプリ「マイニフティ」の開発 今回の担当：バックエンド ひとこと　：普段触らない技術に悪戦苦闘した楽しい3日間でした！ 緑川 普段の業務：IPv6関係のプロジェクトのAWS移行 今回の担当：フロントエンド ひとこと　：ギリギリまで粘って欲しい機能が実装できて安心しました！！！！ keylium 普段の業務：社内ネットワーク運用 今回の担当：ゲームロジック ひとこと　：作りたいものはシンプルでしたが、実際に作ると大変でした！ 制作物紹介 概要 複数人で整数を投票し、最小で固有の数字を投票した人が優勝するゲームを遊べるWebアプリケーション 遊び方 HOME画面にて、部屋を選択、ユーザー名を入力し、ENTRYを押します 投票画面へ遷移後、 同じ部屋の他ユーザーと数字が重複しない最小の数値 を予想して入力します 投票画面では数字のスタンプなどが用意されており、駆け引きができます 同じ部屋に3人が集まり、3人全員が投票完了すると結果発表に自動遷移します 3人の中で重複なし かつ 最小の数値に投票した方が優勝となります 投票画面とスタンプ 投票画面とスタンプ 投票画面とスタンプ 4が重複なしで最小なので勝ち 4が重複なしで最小なので勝ち 4が重複なしで最小なので勝ち システム構成 今回は フロントエンド：TypeScript + React バックエンド　：AWS で開発を行いました。 バックエンドには AWS Amplify を採用しました。 フロントエンドはAWS Amplifyにホストし、4つのDynamoDBとのやりとりにはAWS AppSyncのGraphQLを使っています。 AWS Amplifyとは？ Webアプリケーションやモバイルアプリの開発を高速化してくれるサービスです。 使用することで以下のメリットが得られます。 認証基盤やストレージ、データベースなど、開発に必要なリソースを自動で作成してくれる GitHubのリポジトリと連携することでCI/CDのプロセスを自動化し、環境ごと（本番 / 開発 / ステージング / ローカルなど）・プルリクエストごとに専用のリソースを作成してくれる 今回は開発日数が3日間と短い時間だったので、AWS Amplifyを使うことで開発スピードを早めることを図りました。 AWS Amplifyのおかげで、設定ファイルで必要なリソースを定義するだけで手動で作成することなく、また、PRが来るごとに正しく動作しているのか、実際にアクセスして確認することができました。 一方、デメリットとして、 自動でリソースを作ってくれるため、内部でどんな操作をしているのかが不明 Gen 2のバージョンの日本語記事が少なく、英語記事を読む or 手探りで開発をしていく必要がある の2点が挙げられます。 特に2つ目について、3人ともAWS Amplifyを使うのが初めてだったこともあり、とても苦戦しました。 後ほど、AWS Amplifyについての記事を投稿する予定です。 公式ドキュメント（Gen2 React版）は こちら 工夫した点 AWS Amplifyを使うことでCI/CDやAWSリソース作成の自動化 AWS公式のAWS Amplify用のテンプレート amplify-vite-react-template を使用し、仕様理解を促進 AWS AppSyncのPub/Subによってユーザーなどの状態をリアルタイムで監視 上記3つの技術詳細につきましては、後日投稿予定の記事にて記載いたします。 Notionを活用したスキーマ設計 UIコンポーネントライブラリ（ Material UI ）を使用することでデザインの統一 GitHubでカンバンを作り、それぞれが行う作業を可視化 アーキテクチャ図を早期に作って全メンバーで認識を共通化 学んだこと・成長したこと 初めて触るAWS AmplifyやReactの理解 公式ドキュメントを読み込むことの重要性 タスクの取捨選択の重要性 PRレビューへの積極的参加の重要性 開発における体力・集中力アップ まとめ 私たちが3日間で開発した制作物について紹介しました。 普段の業務の中でここまで集中して1つのものを開発できる機会はなかなかないと思うので、とても良い経験となりました。 十分なエラーハンドリングが無かったり、テストコードを書いていなかったりと、完璧ではありませんでしたが、3日間で動くものができた！ということを自信に、これからの業務に生かしていこうと思います！

はじめに こんにちは、新卒1年目の滝川、藤岡、山本です。 弊社では新人育成のため、毎年エンジニア定例という社内勉強会が実施されており、その集大成として先日3日間にわたる開発合宿に参加してきました。 合宿の概要については以下をご参照ください。 今年もリアルハッカソン合宿に行ってきました！＠ノジマ大磯スクウェア 3つのグループに分かれて開発を行い、今回私たちのチームは「降水量可視化ツール」として降水量を数値ではなく感覚的にわかりやすくするWebアプリを作成したので紹介します。 メンバー 滝川 普段の業務：社内セキュリティの維持、強化 今回の担当：AWSでのインフラ構築、CI/CDの構築 ひとこと　：みんなでスマブラをしたことが思い出です 藤岡 普段の業務：メールシステムの運用、問い合わせ対応 今回の担当：AWSでのインフラ構築、CI/CDの構築 ひとこと：合宿中に食べたお菓子の量No.1の自信があります 山本 普段の業務：お客様に提供している回線プランの契約書面作成システム関連 今回の担当：バックエンド、フロントエンド ひとこと：合宿中に食べた食堂の爆盛りご飯が今でも軽いトラウマです（少食人間） 降水量可視化Webアプリ 今回私たちのチームで作成した降水量可視化アプリは以下のような方針で作成しました。 天気予報の降水量をもとに、実際の雨の強さをグラフィックでわかりやすく可視化するWebアプリケーション 日常で「降水量○○mm以上なら傘が必須」など数字だけで判断しづらい部分を、視覚的な演出で補う狙い 100万アクセスに耐えられる設計を追求 背景 雨の強さを数値以上の直感的な形で伝えることで、「傘の準備」「服装の選択」などをわかりやすくサポートする インフラに強いメンバーが集まったのでインフラに力を入れた 技術構成 インフラ: AWS（TerraformによるIaCを採用） フロントエンド: 既存のライブラリrainyday.jsを使用し、雨の見た目を演出 CI/CD：GitHub Actionsによる自動デプロイの実装 天気情報取得：Open-Meteo APIを採用 ※非商用利用の場合に無料で使用が可能です。商用利用の場合は別途登録が必要となります。 バックエンド：Flask（Python）を使用。WebSocketを活用しリアルタイムチャットを実現 デモ サイトにアクセスするとマップが表示される。 位置情報の共有をオンにしている場合、現在地が反映された場所になる。 選択した地域で雨が降っている場合は、マップを閉じると雨粒が窓をつたうような表示される。 雨の強度によって、雨粒の量が変化する。 天気情報がリアルタイムの天候と異なっている可能性があるため、右下にリアルタイムチャットを作成。 同じ市区町村を閲覧しているユーザ同士でリアルタイムにチャットできる。 システム構成 今回のチームの方針である100万アクセスに耐えられるインフラを構築することを目標に以下のポイントについて頑張りました。 CloudFrontとS3を活用したキャッシュ戦略 ALBによる負荷分散 Auto Scaling 開発の流れ 0日目：アイデアソン 作成するアプリケーションの検討および仕様の詳細化 1日目：要件定義 チーム内でアイデアを提案し合い、システムアーキテクチャの決定および利用技術を選定 開発開始 2日目：開発 フロントとバックエンドに分かれて作業 インフラ組はTerraformを用いてAWSの環境構築 フロント組は雨粒表現が正しく動作することを確認しながら段階的に実装 3日目：最終調整・成果発表 動作テストを実施 発表資料の作成 最終成果をプレゼン 工夫した点 本プロジェクトでは、以下の点において特に工夫を重ねました。 インフラの堅牢性 CloudFrontとS3を組み合わせた効率的なキャッシュ戦略の実装 Auto Scalingによる柔軟な負荷対応 Terraformを用いたインフラのコード化による再現性の確保 ユーザビリティの向上 直感的に理解できる雨の強度表現 位置情報との連携による自動地域設定 リアルタイムチャット機能による情報共有の実現 開発プロセス GitHub Actionsを活用した継続的デプロイメントの構築 チーム内での密なコミュニケーションによる進捗管理 各メンバーの強みを活かした効率的なタスク分担 苦労した・学んだこと インフラ構築を通じて、事前の技術調査の重要性を痛感しました。 CDNでのキャッシュ機能の実装とWebSocket通信の実装を同時に行う際には、WebSocket周りのキャッシュを無効化する必要がありました。特にそもそもCDNとは何かのインプットから始まったため、WebSocket通信を使うための設定をするところまで実装するのにかなりの時間を要しました。事前にCDNに関する技術調査を行っておく事で、このような課題により効率的に取り組み、他の部分により注力することができたと感じています。 また、実装したインフラ上にローカルで作成していたWebアプリを載せる、環境統合テストの遅れにより問題の発見が遅くなったため、早期に実施することの重要性を学びました。 加えて、悩むよりも周囲と相談・共有することで、より効率的に課題を解決できる場面があることも実感しました。 さらに、座学だけでなく実際に手を動かすことで理解が深まること、そして計画的に進捗を管理することでトラブルを回避できることの大切さを学びました。 まとめ これまでに得た知見を存分に発揮し、フロントエンド、バックエンド、インフラの各領域において高い完成度の成果物を作成することができました。 チームメンバーそれぞれが自身のタスクに取り組むだけでなく、困難な問題に直面した際には全員で協力して解決にあたりました。その結果、各自の得意分野を活かしながら、苦手な部分を相互にカバーすることができ、非常に効果的なチーム運営ができたと感じています。 しかしながら、実現したい機能やアイデアがあっても、技術力がなく実装できなかった部分もあり、自身の技術力の不足を痛感する機会にもなりました。この経験を通じて、さらなる技術向上の必要性を強く認識しました。 この合宿は、成果を形にする喜びと同時に、今後の成長に向けた課題を明確にする貴重な機会となりました。

こんにちは、ニフティでエンジニアをしている江口です！ ニフティでは毎年、エンジニア定例という新卒1年目エンジニア向けの開発研修を行っています。そして開発研修の集大成として、ハッカソン合宿を実施してきました！ 私もエンジニア定例の運営として合宿に参加してきたので、その様子を公開いたします！ また、以下のブログで今年度の講義内容についても公開しているので、気になる方はぜひ覗いてみてください！ ニフティ株式会社 エンジニア新人研修の内容を公開します | 2024年度版 ハッカソン合宿概要 目的 座学で学んだ技術を 実践 することで知識を定着させる。 2泊3日というまとまった時間で 集中したアウトプット を出す経験をする。 既存システムのエンハンスではなく、 0からシステムを作る力 を身につける。 個人開発と チーム開発 の違いを学ぶ。 スケジュール 1日目 2025/01/21（火） 10:00 集合・チェックイン 11:00-12:00 開発スタート！ 12:00-13:00 昼食 13:00-18:00 開発 18:00-19:00 夕食 19:00- 自由（開発・入浴など） 2日目 2025/01/22（水） 7:00-8:00 朝食 8:30-12:00 開発 12:00-13:00 昼食 13:00-18:00 開発 18:00-19:00 夕食 19:00- 自由（開発・入浴など） 3日目 2025/01/23（木） 7:00-8:00 朝食 8:30-12:00 開発 12:00-13:00 昼食 13:00-14:00 最終調整 14:00-15:00 現地から成果報告の全社配信 15:00-16:00 終了連絡・撤収作業 16:00 解散 場所 ノジマ大磯スクウェア https://maps.app.goo.gl/qDRevCT8tqmRSnE88 JR東海道線 大磯駅から徒歩2,3分 合宿の様子 1日目 2025/01/21(火) 今回の合宿開催場所であるノジマ大磯スクウェアに到着！ 昨年は初日から雪が降っていましたが、今年は快晴でした！ 早速開発スタート。各チーム、アイディアソンで考えてきたアイデアを元に手を動かしていきます。 ちなみに合宿のルールとして、 合宿が始まるまではコーディング禁止 です！ 皆さん0から作っていきます。 あっという間にお昼ご飯タイム。 私も1年ぶりにノジマ大磯スクウェアのご飯を食べました！ 美味しいしボリューミーで最高ですね。 午後はひたすら開発をしていきます、初日からかなりいいペースで進んでいる様子。 こちらのチームはホワイトボードに巨大な構成図を書いていますね、インフラ構築を早い段階から始めている様子。 19時以降は入浴など休憩もしつつ、やりたいチームは残って開発をするというスタイルでした。 皆さん初日からアクセル全開で、全員24時までやっていました（笑） 2日目 2025/01/22(水) 2日目、朝から晩まで開発です！ 朝食は7:00-8:00の間に済ませます。 運営陣は朝食後、みんなで海辺に散歩しにいきました。ノジマ大磯スクウェアから徒歩で10分もかからず海に出れます、最高ですね。 皆さん昨日も遅くまでやっていたのに、めちゃくちゃ元気。ガンガン進めていきます。 AWS Amplifyを採用しているこちらのチーム、画面も形になってきましたね。 こちらのチームは2日目に作った構成図を元に、インフラ構築を進めていきます。フロントも順調そう！ 美味しそうなラーメンがたくさん並んでいるこちらのチーム。写真ではわからないですが、バックエンドの構成がかなり美しいです、すごい。 2日目も、まだ開発したいチームは残って開発をするというスタイルでしたが、皆さん明日の発表に向けて、しっかり24時まで作業していました！ 運営も元気な皆さんに必死で食らいついていきます。 3日目 2025/01/23(木) 最終日です！ 午前中はこれまで通り開発で、午後は成果報告会でした。 成果報告会では作成したサービスのデモや工夫点、開発での良かった点と悪かった点、成長したことや学んだことなどを、各チーム10分程で発表します。 運営も配信の準備を進めていきます。 配信スタート！ こちらの成果報告会は 全社配信 ということもあり、配信開始してすぐに80名近くの方に参加していただけました。 Slackに実況チャンネルを設けて、配信を視聴していただいている皆さんからの反応や質問なども、リアルタイムで見れるようにしています。 ハッカソン合宿に参加していたメンバーだけではなく、新人のトレーナーをしていた先輩社員や所属しているチームのマネージャー、人事や企画部門の社員など、多くの方に合宿の成果を見ていただける素晴らしい機会です。 では早速発表を見ていきましょう。（本ブログ内では概要のみの紹介となります。開発物の詳細については、今後投稿される各チームのブログをご覧ください！） まずはチームAです。食べ物特化のSNS、見ているだけでお腹が減っちゃいますね。投稿機能やログイン機能なんかもしっかりと整備されています。 次にチームBの発表。最小かつ固有の数字を投票した人が勝ち、という単純そうだけど奥が深そうなゲーム。実況チャンネルも盛り上がっていました！ 最後はチームCです。指定した場所の降水量をわかりやすく可視化してくれるといったサービス。インフラも充実していて、本格的なサービスですね。 多くの方にご参加いただき、素晴らしい成果報告が実施できました！ ご参加いただいた皆様、ありがとうございました！ 終わりに 今年のハッカソン合宿は、どのチームも非常にレベルの高い成果物ばかりでした。 使ったことのない技術なども積極的に取り入れ、運営の私たちも学びのあるハッカソン合宿となりました。 そして昨年に引き続き、快適にハッカソン合宿ができる環境を提供してくださったノジマ大磯スクウェアさん、ありがとうございました！ 各チームの開発物のより詳細な仕様や開発秘話など、それぞれブログが公開されますので、お楽しみに！！

はじめに ニフティでWEBサービスの開発・運用を担当している渡邊です。 2024年9月に@nifty天気予報のフルリニューアルを行いました。 このプロジェクトでは従来のインフラ構成を刷新し、サーバレスアーキテクチャを採用しました。 従来のWEB三層構造からサーバレス構成への移行によるコストの比較と、効果について紹介していきます。 旧環境の構成と問題点 構成 WEBサーバ、アプリケーションサーバ、DBサーバからなるWEB三層構造のアーキテクチャを、EC2とRDSを使って構築していました。 問題点 この構成には以下のような問題点がありました。 固定費用が高く、トラフィックが少ない時期でも一定のコストが発生 サーバーの保守・運用に多くの工数が必要 サーバレスの採用 従来の問題点を解決するため、トラフィックに応じた柔軟なスケーリングと、運用負荷の大幅な削減が見込める、サーバレスアーキテクチャの採用を決めました。 また、データ構造の変更にも柔軟に対応できる構成も目指しました。 採用したサービス AWSをクラウドに採用しているので、AWSが提供するサーバレスサービスを活用しました。 WEB Amazon ECS（Fargate） API AWS AppSync（GraphQL） バッチ処理 Amazon S3 AWS Lambda AWS Step Functions DB Amazon Aurora Serverless v2（PostgreSQL） 効果 約4ヶ月運用してみての効果を見ていきます。 インフラコスト サービス 旧環境 新環境 削減率 WEB 100USD 10USD 90% アプリケーション 400USD 110USD 72.5% DB 1,200USD 230USD 80.8% その他 400USD 300USD 合計 2,100USD 740USD 64.8% ※金額は実数とは変えてあります 旧環境はバッチ処理が複雑だったため、要求スペックが高い状況での運用を行っていました。 加えて、WEBサーバをECSにしたことで負荷に応じてスケールするようになったため、常時起動のときと比較すると削減率が非常に高くなりました。 アプリケーション（API）に関しては、AppSyncがフルマネージドサービスということもありますが、redisが標準で搭載されているため、キャッシュによるコスト最適化が大きな要因だと考えています。 加えて、バッチ処理もデータが更新されたタイミングのみしか起動しないため、削減効果が大きかったようです。 DBに関しては、AppSyncを使う以上、Aurora Serverless v2しか選択肢がなかったのですが、こちらもECSと同様に負荷に応じてスケールするため削減率が大きかったようです。 これは思わぬ副産物でした。 実装コスト サーバレスを採用したことでインフラコストだけでなく、実装コストも削減できました。 フロントエンドとバッチの実装では、コンテナを基盤として実装し、GitHub から ECR を経由してデプロイ先へという構成を構築することで、デプロイプロセスを簡略化できました。 アプリケーションサーバにAppSyncを採用したことで、GraphQLを実行するサーバが不要になり、スキーマとリゾルバのみの実装でAPIを構築することができました。 リリース以降、データ更新の遅延などの問題も特には発生しておらず、システムは安定稼働し続けています。 注意点 今回のリニューアルではサーバレス化により大幅なコスト削減を実現できましたが、これが全てのサービスに適しているわけではありません。 一般的にサーバレスはトラフィックが予測可能で、変動が大きいサービスに特に効果的と言われています。 一方で、常時高負荷が発生するサービスや、レイテンシーを重視するようなサービスでは従来型のサーバ構成の方が適している場合もあります。 また、サーバレスサービスはベンダーロックインが発生しやすく、細かな調整が制限されるので、サービス要件を満たしているかは十分に検討する必要があります。 最後に 今回はWEB三層構造で作られていた従来の構成から完全なサーバレス構成にインフラを切り替えた効果について書いてきました。 サーバレス化によって大幅なインフラコスト削減を実現できました。 当初予測していた以上の削減効果が得られたのは大きかったです。 今回のように全てをサーバレスにするのではなく、部分的にサーバレスを活用するだけでもインフラコスト削減は可能ですのでぜひ検討してみてください。 今回のプロジェクトの詳細については、以前行ったNIFTY Teck Talkにて話していますのでこちらをご確認ください。

はじめに 宮永です。2025年1月のJANOG55 meeting（以下JANOG55）に参加してきました。前回のJANOG54に引き続き、2回目の参加です。 感想などを書いていきます。 JANOG Meetingとは JANOGとはJApan Network Operators’ Groupを意味し、 インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより 日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。 https://www.janog.gr.jp/information/ 　より引用 年に2回meetingが開かれ、日本全国から様々なバックグラウンドを持つ人が集まります。インターネットに関する技術やノウハウについての発表や議論が行われます。 JANOGは「カンファレンス」ではなく「ミーティング」と呼ぶことを大切にしているようです。ただ発表を聞く会ではなく、関係者と積極的なコミュニケーションを取る場として全国から大勢のインターネット技術者たちが集まります。 どうして参加したのか？ 私は社内の「ISPオペレーションサブチーム」に所属しており、日々ニフティのお客様が快適にインターネットを使えるようにするための業務を担当しています。現在の業務にぴったりのコミュニティであると思い、参加しました。 参加にあたっての社内説得方法 私「前回のJANOG楽しかった。参加したいです」 上司「いいですよ」 これだけです。いやぁ、ニフティって本当にいい会社ですねぇ（ダイレクトマーケティング）（ここで採用ページのリンクを貼る） https://recruit.nifty.co.jp/ JANOG55現地 業務の都合上、全3日間のうち2日目夕方から参加しました。 JANOG55は京都府にある「京都市勧業館みやこめっせ」で開催されました。平安神宮のすぐ横にあります。立派な鳥居がありました。 建物内はおしゃれな装飾がされているところもあります。京都はどこに行っても京都らしさが見えて良いですね。 参加者はスーツの人2割、襟付きシャツ&カーディガンくらいの格好が4割、企業ロゴの入ったパーカー等を着ている人が2割、その他2割といった感じです。普段働くときに着ている服で来ているようで、企業の色もみえてきます。 参加者の所属企業も様々で、私のようなISP事業者だけではなくネットワーク機器メーカー、コンテンツ事業者などなど、様々な人が集まっています。また、インターネット関連企業でも技術者だけでなく、営業といった非技術者が勉強のために参加する方も多いようです。 プログラム 大きな会場3か所で様々な発表が行われます。どれも楽しそうな発表ばかりです。興味のある発表が二部屋同時に行われることもあり、どこに行くか迷います。 発表部屋はかなり広いです。奥まで探すと大体空席があるので、座席不足で困る感じではありませんでした。ただし、後ろの方に座るとスライドが見えず結構困るため、どうしても参加したい発表の際は早めに座席を確保したほうが良さそうです。 また、ストリーミングとアーカイブ配信のある発表もある中で、 オフレコ（撮影/録画/SNS投稿禁止)のプログラム もあります。同じ問題を抱える技術者同士で、大きな声では言えないけど困っている事やノウハウなどを共有・議論する場となっています。コミュニケーションを大切とするJANOGならではの仕組みですね。 JANOG Slack オンライン・現地参加問わず参加できるSlackがあります。発表会場ごとのチャンネルがあり、実況や質問・感想が飛び交っています。現地でマイク使って質問するよりハードルは低いかもしれまん。 より多くの意見を知ることもできるので、参加する際はSlackもチェックしたほうが良いと感じました。会場Wi-Fiはかなり整備されているので、インターネット接続も問題ありません。 会場NW不調について参加者が運営へslackで問い合わせしている様子も見れます。参加者がネットワークのプロなので、質問の仕方が相当専門的でおもしろかったです。 また、発表や会場についてのアナウンスだけではなく、現地のネットワーク情報現地の美味しいご飯の情報といった雑談も飛び交っています。slackで話題になっていたラーメン屋に行ってきました。とてもおいしかったです。 協賛ブース JANOGは他のカンファレンスよりも協賛ブースが充実しているのではないでしょうか。今回は158企業が協賛ブースを出していたそうです。 私のようなISP事業者だけではなく、インターネット関連企業・ネットワーク機器メーカー・コンテンツ事業者・サーバ関連企業などなど、様々な企業が展示を行っています。 協賛ブースでは普段の業務でお世話になっている方と何名かお会いすることができました。いつもはメールでしか接点が無い方と色々な会話をする機会になりました。（お声かけくださった皆様、ありがとうございました！） 展示を行っている多くの企業が特色ある展示・グッズ配布を行っており、どこを見ていいのか迷ってしまいます。プログラム発表だけではなく、しっかり協賛ブースを見る時間も確保したほうが良いです。 この広い会場がすべて協賛ブースです。 懇親会 2日目終了後、懇親会が近くのホテル会場で開催されました。 私は運よくチケットを購入できましたが、受付開始後すぐに売り切れになるほど大人気です。毎年早々に売り切れるそうなので、参加したい方は発売開始当日に粘る必要があります。 参加者は1000人を超えるそうです。相当大きな部屋にもかかわらず、まっすぐ歩けないほど人が沢山います。 会場には美味しそうな食事やお酒が沢山おいてあります。好きなだけ飲み食いしてよいスタイルです。学生の方も多く参加するので、ノンアルコールのお茶やジュースもありました。飲まない人も安心です。 知り合いのいない状態で参加し不安でしたが、名札の会社名を見て多くの方が話しかけてくださいました。話してみると意外なつながりのある人も多く、大変有意義な時間でした。（お声かけくださった皆様、ありがとうございました！） 反省点 もっともっと積極的にコミュニケーションをとればよかった 前回の反省を生かし、会場の名前を知っている人何名かに話しかけてみました。一度お話してみたい人と話せたり、業務上の疑問が解消できたりと、非常に有意義な時間となりました。 しかし、会場にはまだまだ同じような業務をしている人がいるはずです。今後のエンジニア人生のためにも、より多くのコミュニティに触れたいなと思いました。 大き目のカバンを持参するべきだった 協賛ブースでは多くの企業がたくさんグッズを配っています。どれも面白く、たくさん受け取ってしまうと持ち帰りが大変でした。 社名のわかる服装をすると話すきっかけになりそう ありがたいことに、 JANOGでお話した方はほぼ全員ニフティを知ってくださっていました。せっかく知名度のある会社に勤めているので、社名のわかるパーカー等を着たらより話しかけるきっかけが生まれたかな？と思いました。 着脱しやすい上着にするべきだった 会場は部屋や時間によって寒暖差が大きかったです。かさばる上着を何度も脱ぎ着する必要があり、後悔しました。夏のJANOGでも同じような後悔をしたので、季節問わず気を付けたほうが良さそうです。 まとめ インターネット技術者とのコミュニケーションや発表により、様々な知見を得たり、新たなコミュニティを知ることができたり、普段の仕事中ではなかなかできない経験ができました。 次回は2025年7月に島根県で開催されるそうです。みなさんもぜひ参加してみてください！

以前の記事 ではティザーサイトの公開をお伝えしていた「NIFTY Tech Day 2025」について、登録サイトを公開いたしました。 また今回、Xでのプレゼントキャンペーンもございます！ 概要 登録サイト https://techday.nifty.co.jp/2025/ 日程 2月8日（土）13:00〜18:40 　　　　　　 18:40～ 懇親会（オフライン） 開催方式 ハイブリッド開催 会場参加：ニフティ株式会社 本社（新宿フロントタワー 18F） オンライン：YouTubeライブ配信（配信URLは準備次第公式サイトに掲載予定） ※ 対面、オンラインのハイブリッド開催です。いずれかの方法で参加ください。 ※ 本イベントは、対面・オンラインどちらも登録制になります。登録は無料になります。 ※ 会場参加の方には、NIFTY Tech Day 2025 オリジナルトートバッグ、ステッカー、NIFTY Tech Book#2のほか、各種体験ブース設置など来場者特典を用意しています。 プログラム抜粋 セッション AIと協働する次世代開発スタイル – 求められる新たなスキルと役割の変化 スクラムマスター入門者のための学習マップ 効果的な学びと実践 ニフティLT大会大公開スペシャル など、7つのセッションを実施いたします。 その他のセッションにつきましては、 公式サイト をご確認ください。 体験ブース 「スクラムプチOST」 スクラムに関する悩みを共有し、みんなで解決策を探るインタラクティブなブース 「もじこえ体験」 テキストを読み上げてくれる画期的なチャットツール「もじこえ」を体験できます。 「ニフティキッズにおける生成AI活用展示」 「ニフティキッズ×生成AI」の活用をサービス、システム、アーキテクチャ含め大公開！ 「エンジニア謎解き」 ニフティ社員が謎を出題します！ 参加方法 公式サイト の「Tech Dayに参加する」からEventRegistにて、登録をお願いいたします。 プレゼントキャンペーンについて 現在、NIFTYDevelopers (@NIFTYDevelopers)のX公式アカウントにて、 抽選でAmazonギフトカードが当たるフォロー＆リポストキャンペーンで行っています！ 皆様のご参加をお待ちしております。 ■対象ポスト https://x.com/NIFTYDevelopers/status/1880086586844672323

この記事は、 ニフティグループ Advent Calendar 2024 23日目の記事です。 はじめに こんにちは、新卒1年目の後藤です。 今回は、S3内にあるALBのアクセスログをAthenaで確認する方法について、記載していこうと思います。 Amazon Athenaとは クラウドインフラの運用において、ログ分析は不可欠です。 AWSでは、多くのサービスがログをAmazon CloudWatchとAmazon S3で保存しています。 しかし、蓄積された大量のログデータを効率的に分析することは、いずれも困難です。 ここで登場するのがAmazon Athenaです。 Amazon Athenaは、標準SQLを使用してS3のデータを直接クエリできるサーバーレスの対話型クエリサービスです。 Athenaを使用することで、複雑なインフラ設定なしに、S3の大規模なログデータを効率的に分析できます。 環境設定 Athenaを使用するには、以下のAWSサービスへのアクセス権限が必要です： Amazon S3 S3バケットへの読み取り権限 Amazon Athena Athenaクエリの実行権限 S3バケットの設定 1. ログを保存するS3バケットを作成または確認します。 2. バケットポリシーを適切に設定します。 Athenaからの読み取り権限を許可する { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "athena.amazonaws.com" }, "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::your-bucket-name", "arn:aws:s3:::your-bucket-name/*" ] } ] } 必要に応じて、特定のIAMロールやユーザーからのアクセスのみを許可する { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/YourRoleName" }, "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::your-bucket-name/*" ] } ] } 注意: 上記のポリシーは一例なので、実際の環境に合わせて適切に調整してください。 3. 必要な権限を付与します。 s3:GetBucketLocation – バケットの場所を取得する権限 s3:GetObject – オブジェクトを読み取る権限 s3:ListBucket – バケット内のオブジェクトを一覧表示する権限 s3:PutObject – クエリ結果を保存する権限（結果を S3 に保存する場合） 設定 ログを保存するS3バケットを指定 Location of query result でログを保存するS3バケットを指定します。 Browse S3で選択することも可能です。 データベースの作成 以下コマンドをクエリで実行します。 CREATE DATABASE your_database; [Run]  (実行) をクリックするか、 Ctrl+ENTER  キーを押します。 左側の  [Database]  (データベース) リストから、現在のデータベースとして  your_database を選択します。 テーブルの作成 今回はALBのアクセスログ用のテーブルを作成します。 使用したいログやデータに合わせて変更してください。 作成したデータベース( your_database )を選択 クエリで以下コマンドを実行 CREATE EXTERNAL TABLE IF NOT EXISTS alb_access_logs ( type string, time string, elb string, client_ip string, client_port int, target_ip string, target_port int, request_processing_time double, target_processing_time double, response_processing_time double, elb_status_code int, target_status_code string, received_bytes bigint, sent_bytes bigint, request_verb string, request_url string, request_proto string, user_agent string, ssl_cipher string, ssl_protocol string, target_group_arn string, trace_id string, domain_name string, chosen_cert_arn string, matched_rule_priority string, request_creation_time string, actions_executed string, redirect_url string, lambda_error_reason string, target_port_list string, target_status_code_list string, classification string, classification_reason string, conn_trace_id string ) PARTITIONED BY ( year string, month string, day string ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe' WITH SERDEPROPERTIES ( 'serialization.format' = '1', 'input.regex' = '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) \\"([^ ]*) (.*) (- |[^ ]*)\\" \\"([^\\"]*)\\" ([A-Z0-9-_]+) ([A-Za-z0-9.-]*) ([^ ]*) \\"([^\\"]*)\\" \\"([^\\"]*)\\" \\"([^\\"]*)\\" ([-.0-9]*) ([^ ]*) \\"([^\\"]*)\\" \\"([^\\"]*)\\" \\"([^ ]*)\\" \\"([^\\\\s]+?)\\" \\"([^\\\\s]+)\\" \\"([^ ]*)\\" \\"([^ ]*)\\" ?([^ ]*)?' ) LOCATION 's3://your-bucket-name/access-log-folder-path/' TBLPROPERTIES ( 'projection.enabled'='true', 'projection.year.type' = 'integer', 'projection.year.range' = '2024,2050', 'projection.year.interval' = '1', 'projection.month.type' = 'integer', 'projection.month.digits'='2', 'projection.month.range' = '1,12', 'projection.day.type' = 'integer', 'projection.day.digits'='2', 'projection.day.range' = '1,31', 'storage.location.template' = 's3://your-bucket-name/access-log-folder-path/year=${year}/month=${month}/day=${day}' ); [Run]  (実行) を選択。 テーブル  alb_access_logs が作成され、 your_database  データベースの [ Tables ] (テーブル) リストに表示されます。 公式から追加した箇所の説明 PARTITIONED BYの説明 PARTITIONED BY テーブルをパーテーション化することを宣言しています。 パーテーション化は、大規模なデータセットを小さな、管理しやすい部分に分割することです。 year string , month string , day string パーテーションキーとして使用され、それぞれがstring型で定義されています。年、月、日の順で階層的にパーティションが作成されます。 TBLPROPERTIESの説明 'projection.enabled'='true' Partition Projectionを有効にします。クエリ時にPartitionを動的に生成できます。 'projection.year.type' = 'integer' , 'projection.month.type' = 'integer' , 'projection.day.type' = 'integer' 年、月、日のPartitionがそれぞれ整数型であることを指定します。 'projection.year.range' = '2024,2050' 年の範囲を2024年から2050年までと指定します。 'projection.year.interval' = '1' 年のPartitionが1年ごとに増加することを指定します。 'projection.month.digits'='2' , 'projection.day.digits'='2' 月と日のPartitionが2桁の数字で表されることを指定します。 'projection.month.range' = '1,12' 月のPartitionが1から12までの範囲であることを指定します。 'projection.day.range' = '1,31' 日のパーティションが1から31までの範囲であることを指定します。 'storage.location.template'  S3内のデータの実際の格納場所のテンプレートを指定します。 ${year} , ${month} , ${day} はそれぞれ年、月、日の値に置き換えられます。 データの取得 テーブルを作成したら、実際にデータを取得してみます。 基本的なクエリ 最新のログエントリを10件取得する： SELECT * FROM alb_access_logs WHERE year = 2024 AND month = 12 AND day = 12 LIMIT 10; コンソールの下に結果が表示されるので確認します。 パフォーマンスとコスト最適化 Athenaにデータを設定する際の最適化 1. パーテーションの活用 適切なパーティションにより、スキャンするデータ量を減らし、クエリ速度を向上させ、コストを削減することが可能です。 今回はs3://~/YYYY/MM/DDのようにデータが保存されているので、以下のように PARTITIONED BY でパーテーションを設定することが可能です。 PARTITIONED BY ( year string, month string, day string ) 2. 圧縮の使用 ログファイルをgzipなどで圧縮することで、ストレージコストとクエリ時間を削減できます。 gzipに圧縮した際は、テーブル定義の TBLPROPERTIES 内に 'compression.type'='gzip' を追加することを忘れないようにしましょう。 実際に検索する際の最適化 必要な列のみを選択 SELECT * の使用は避け、必要な列のみを指定します。 例: SELECT time, elb_status_code, request_url FROM alb_access_logs WHERE ... LIMIT句の使用 大量のデータを扱う場合、LIMIT句を使用して結果セットを制限します。 例: SELECT * FROM alb_access_logs LIMIT 100; これらの最適化技術を適用することで、Athenaの使用をより効率的にし、コストを抑えることができます。定期的にクエリのパフォーマンスとコストを監視し、必要に応じて調整を行うことが重要です。 まとめ Amazon Athenaを使用してS3のログを分析することで、大規模なデータセットに対して効率的かつ柔軟なクエリが可能になります。 主要なポイントは以下の通りです： Athenaの基本設定 クエリ結果の保存場所の指定 データベースとテーブルの作成 テーブル設計の重要性 適切なカラム定義 パーティショニングの活用 効率的なクエリ実行 基本的なSQLクエリの構造 パーティションを利用したデータフィルタリング パフォーマンスとコスト最適化 必要な列のみの選択 LIMIT句の使用 データの圧縮 Athenaを活用することで、複雑なインフラストラクチャを管理することなく、S3に保存されたログデータから迅速に得ることができます。 パフォーマンスとコストの最適化テクニックを適用することで、より効率的にデータ分析を行うことが可能です。 最後に、常にAWSの ベストプラクティス と セキュリティガイドライン に従い、コストとパフォーマンスのバランスを取りながら、Athenaを活用しましょう。 参考文献 https://docs.aws.amazon.com/ja_jp/athena/latest/ug/what-is.html https://docs.aws.amazon.com/athena/latest/ug/create-alb-access-logs-table.html 次の記事もお楽しみに！

ニフティは創業以来37年間、時代の変化に応じて挑戦を続け、最新技術を活用しながら社員とともに成長してきました。 「NIFTY Tech Day 2025」では、エンジニアたちがこれまでに積み重ねてきた知識や経験、これからの展望について発表します。 昨年度もご好評をいただきましたゲストスピーカーのセッションに加え、今年は「With Us, You Can (Learn). エンジニアの学習と成長」というコンセプトのもと、当社エンジニア社員が登壇するセッション、体験型ブース（会場参加者限定）等もご用意いたします。 開催に先立ち、先行登録受付のためのティザーサイトを公開いたしました。ご登録いただくことで登壇内容のアップデート時のご連絡や、参加申し込み開始時に優先的にご連絡させていただきます。 概要 ティザーサイト https://techday.nifty.co.jp/2025/ 日程 2月8日（土）13:00〜18:40 　　　　　　 18:40～ 懇親会（オフライン） 開催方式 ハイブリッド開催 会場参加：ニフティ株式会社 本社（新宿フロントタワー 18F） オンライン：YouTubeライブ配信（配信URLは準備次第公式サイトに掲載予定） ※ 対面、オンラインのハイブリッド開催です。いずれかの方法で参加ください。 　※ 会場参加の方には来場者特典を用意しています。 まずは通知登録を！ ティザーサイト の「開始通知を登録する」から、通知のご登録をお願いいたします。 ※ ご登録いただけますと、参加申し込み開始時にご連絡いたします。 ※ またセッションやノベルティなどの最新情報も随時お届けします。

この記事は、 ニフティグループ Advent Calendar 2024 21日目の記事です。 もうすぐクリスマスですね。みなさんはプレゼントをもらえるなら何が欲しいですか？ 私は最近寝ているときに乾燥で喉がやられるので強靭な喉が欲しいです。 SREチームの島です。 普段はサービスの信頼性向上のため障害数の削減やSRE推進をメインに活動しています。 私事ですがニフティに転職して来年の3月で丸2年になります。 今回は私がニフティでこの2年間でやってきたことや成長したと思うことを振り返ってみようと思います。 私の経歴について はじめに私の経歴について紹介します。 前職ではずっとプログラマーやチームリーダーとしてソフトウェアエンジニアリングに従事していました。そして2社目となるニフティでSREのポジションに就きました。 1社目(2009〜2023) 主にSES、SI事業に従事し、お客様先に常駐したり、自社のプロジェクトチームでソフトウェアエンジニアリングに携わっていた 入社〜8年ほどは開発工程をメインに、それ以降はプロジェクトリーダーとしてプロジェクト管理を経験 技術としてはJava、PHP、C#、TypeScript、MySQLなどなど。フロントエンド、バックエンド開発がメイン インフラやクラウド環境の構築経験はなし（クラウド環境での開発経験はあり） 2社目(2023〜現職) ニフティにSREとしてジョイン ニフティでやったこと SREとして 下記のSRE本のプラクティスに沿って私が主にやってきたことをあげていきます。 https://sre.google/sre-book/part-III-practices/ Monitoring SLI/SLO、アラート、ダッシュボードの作成 @nifty天気予報 のリニューアルプロジェクトにEmbedded SREとして参画しました。その際にAmazon CloudWatch Application Signalsを使ったSLI/SLOの計装、アラート設定、CloudWatch Dashboardの構築を行いました。モニタリングをSREが責任を持って担当することで開発者が開発に専念できたと思っています。 FourKeysの計装 FourKeysを計装し、社内のDevOpsチームへ導入を行いました。 社外カンファレンスで登壇 もさせていただきました。 こちらはその後全社的な取り組みへと発展し、現在はシステム・プロダクトごとの運用コストの可視化・最適化を行うプロジェクトに参画しています。 Postmortem / Root Cause Analytics ポストモーテムの実施支援 ポストモーテムの実施が滞っているチームに声をかけ、私がファシリテーションしながら一緒にポストモーテムの実施や再発防止アクションの促進を進めています。 Testing + Release producers 継続的デリバリの実装 こちらも @nifty天気予報 のリニューアルプロジェクトに参画したときの話で、ecspressoを使ったECSへのCDを実装しました。 Development IaCによるインフラ構築 いくつかのプロジェクトでIaC（Terraform）によるAWS環境の構築を経験しました。最初はコードでインフラ構築ができることに感動したことを覚えています。 その他 弊社にはチームを横断した活動を行うワーキンググループ(WG)という活動があり、私は下記の2チームに参画しています。 システム安定化WG 障害の検知、復旧までにかかる時間を短くする・障害数を減らすことを目的としたWGです。 このWGの取り組みとしては下記のようなことを行いました。 障害発生時のエスカレーションフローの見直し 障害報告書テンプレートの改善 ポストモーテムの実施支援 採用ブランディングWG ニフティのエンジニアリングカルチャーを知ってもらうためにエンジニアが主体となってテックやカルチャーの発信、ブランディング活動を行うWGです。 個人的な活動も含め、ブランディング活動としては下記のようなことに携わりました。 昨年開催した弊社テックイベント「NIFTY Tech Day 2023」の運営スタッフ 開発チームへのインタビューの実施・記事の作成 社外カンファレンスに登壇 弊社のテックトークイベント「 NIFTY Tech Talk 」に2回登壇 やってよかったこと ワーキンググループに入ったことで横断活動がしやすくなった 弊SREチームは社内のチームを横断した活動を多く行なっています。ただ、中途入社の身としては全く関係性のないチームに横からズカズカ入っていって「おい、SREしているか」と言いに行くのは抵抗感がありました。 しかし上に挙げたWGの活動を通して徐々に存在を認知してもらえるようになり、私自身も知っている人が増えてきたことで横断活動への抵抗感も薄れていきました。 そういった意味でもWGで活動したことはとても大きかったと思います。 社外のカンファレンスに参加するようになった 実はニフティに入って初めてエンジニアによる勉強会やカンファレンスが開催されていることを知りました。それまでは業務以外でエンジニアと関わることはなく、非常にもったいないことをしていたなと思います。 社外のカンファレンスに参加するようになって視野を広く持てるようになったと思います。例えば「こういう課題がある、どう解決したらいいんだろう。そういえばこの前のカンファレンスで他社のSREが同じような事例を紹介していたな」という感じで課題解決のヒントを探せるようになりました。 入社当初、分からないことだらけで絶望していた自分にとって社外カンファレンスは大きな支えになっていました。 成長したと思うこと 未経験の技術を習得した 前職とは技術スタックが全く違っていたので未経験の技術を多く学ぶことができました。学ぶだけでなく実務で使えたので身についていきました。実務で初めて使った技術、ツールだけでも以下のようなものがあります。 AWS Lambda CloudWatch StepFunctions EventBridge S3 IAM GCP BigQuery Cloud Run GitHub GitHub Actions ecspresso Terraform Python Grafana Tableau Looker Studio Notion SREingできるようになった まだまだできないこともありますが入社時と比べると多くのSREingができるようになりました。当時はSLIもSLOも机上の知識だけで、いざ設定、運用しろと言われてもできませんでした。今では目標値の設定から計算式の決定、計装まで実践できるようになりました。 ポストモーテムも入社前に学習はしていましたが実際に書いたことはありませんでした。ある日、障害が発生した際にポストモーテムをおこなう機会がありました。そのときの経験から、開発を進めながら障害対応を行う大変さを知りました。自身がDevOpsを経験することで開発者の思いを知ることができました。 IaCによるインフラ構築も、以前はインフラエンジニアが構築してくれた環境を使って開発をするだけでした。今ではすべてではないですがIaCを使って自分でインフラを構築できるようになりました。 まとめ 普段は「自分、成長しているな〜」と思うことはあまりないですが、改めて振り返ってみると色々できることが増えているなと感じることができました。その反面、まだまだプロダクトに貢献できていない、信頼性を向上できているのだろうかと悩むこともありますが年末くらいは今年やってきたことを自分で褒めたい思います。 みなさんも今年の振り返りをして自分を讃えてみてはいかがでしょうか。 明日は、@ryugakさんです！ それではMerry Christmas

この記事は、 ニフティグループ Advent Calendar 2024  15日目の記事です。 こんにちは！ ニフティでエンジニアをしている西根です！ 普段はニフティポイントクラブの開発運用保守をしています。 皆さんはgit revertは普段使用していますか？ 私は最近までほとんど使用したことがありませんでした。 この記事はマージした後にrevertしたけど、その後どうすれば良いか何もわからない！困った！という人向けに書いていきたいと思います。 背景 先日ステージング環境へデプロイしたところ不具合が見つかり、一度切り戻しを実施することになりました。 今までのリリースではほとんど切り戻しを実施することがなく、初めてGitHubのrevertを使用しました。 ステージング環境へ反映した内容に少し修正を加えるだけだったので、revertして切り戻し実施後に元々developブランチにマージしたfeatureブランチにそのまま変更を加えました。 が、再リリースでdevelopへのマージ時に見えないコンフリクトが発生し、どうしたら良いかわからなくなってしまったので、同じような人がいたら助けになれば幸いです。 そもそもrevertとは？ 公式ドキュメント では以下のように説明されています。 1 つ以上の既存のコミットがある場合、関連するパッチによって導入された変更を元に戻し、それを記録するいくつかの新しいコミットを記録します。これには、作業ツリーがクリーンであること (HEAD コミットからの変更がない) が必要です。 https://git-scm.com/docs/git-revert.html つまり、一言で言うと既存のコミットを打ち消すコミットを作成するコマンドです。 自分がいるブランチの最新のコミット（HEAD）からコミットしていない変更がない場合に使用できます。 なぜ再度マージする時にハマってしまったのか 前提としてブランチの運用ルールは以下の通りです main：本番稼働しているコード。 develop：ステージング環境で稼働しているコードで、本番反映時にmainにマージする。 feature：developブランチから切っており、機能開発時に使用する。ステージング反映時にdevelopブランチにマージする。 切り戻しを実施する時にdevelopブランチにマージしたPRをGitHub上でrevertし、 ローカルにリモート上のrevertを取り込まないまま featureブランチで修正を行なってしまいました。 今回はここが問題で、修正後のfeatureブランチをdevelopブランチにマージする時に、Gitが以下の状態を解決しようとしますが、同じ箇所に変更を加えている場合にはどちらの状態を採用すべきかを自動で判断することができず、コンフリクトとして扱われます。 featureブランチの変更（一度developブランチにマージされた変更とrevert後の修正） developブランチのrevertによる打ち消し コードの内容自体は同じように見えるのですが、Gitとしては変更履歴が異なるため、コンフリクト判定されてしまいました。 結論 今回のようなケースを避けるためには以下の手順でrevert後の修正をするのが良さそうです。 revertしたブランチをpullしてリモートとローカルの差分をなくす git pull origin { revertしたブランチ } revertしたブランチでrevertのマージコミットのコミットハッシュを調べる git log --graph * がついているものがコミット 以下の場合は コミットハッシュ3 のコミットがrevertのマージコミットになる revertしたブランチで再度revertする git revert -m 1 { コミットハッシュ } -m : mainlineのm。マージコミットは親コミットが2つあるのでどちらに戻すのかを指定してあげる必要がある。親コミットの番号は1, 2で指定でき、1はマージされた側・2はマージする側を表している 今回はマージされたdevelopブランチの方に戻したいので、1を指定する そこから修正ブランチを切る git switch -c { 修正ブランチ } 修正ブランチで修正しリモートにpushする git add { ファイル } git commit -m "{ コミットメッセージ }" git push origin { 修正ブランチ } GitHubでターゲットブランチにマージする まとめ （当たり前といえば当たり前ですが）リモートとの差分があるままローカルで作業しないことは常に心に留めておきたいですね。 目には見えないコンフリクトには皆さんもお気をつけください