はじめに 会員システムグループのkiqkiqです。 自チームではawsのインフラはTerraformで管理しています。Terraformはインフラストラクチャをコードとして管理する便利なツールですがその便利さの中にも注意すべき内容もあります。今回はリソース作成時に遭遇した、予期せぬリソースの上書きについて共有したいと思います。 遭遇した問題 自チームでは同一AWSアカウント内で複数のTerraformプロジェクトを利用しており、気付かず同じ名前のEventBridge RuleをTerraformで定義してしまいました。その状況で同一名称のEventBridge Ruleをデプロイしたとき、エラーが発生するのではなく元からあったリソースの内容を上書きするという挙動に遭遇しました。 例えば、以下のようなaws_cloudwatch_log_groupのリソースを作成した場合、同じ /example/example_logs というロググループのリソースがあると terraform apply 時にエラーとして出力されます。 resource "aws_cloudwatch_log_group" "example_logs" { name = "/example/example_logs" # ... その他の設定 ... } しかし、以下のようなaws_cloudwatch_event_ruleのリソースを作成した場合、 example-rule というEvent Ruleのリソースがすでに同アカウント内に存在しても上書きされてしまいます。 resource "aws_cloudwatch_event_rule" "example_rule" { name = "example-rule" description = "新しいルール" # ... その他の設定 ... } 同一Terraformプロジェクト内で定義している場合は、plan実行時に Error: Duplicate resource "aws_cloudwatch_event_rule" configuration というエラーが発生します。しかし、今回のように別プロジェクトで管理してるとterraform plan時の差分では確認できず、 terraform apply でもエラーが発生せずにデプロイできてしまいます。 予防策の例としては以下のようなものが挙げられます。 同一アカウント内で複数のTerraformプロジェクトを利用している場合はプロジェクト全体での命名規則を統一しプレフィックスなどで分ける 名前をあえて明示的に指定せず自動採番に任せる それぞれメリットデメリットがあり、他にも方法はいくらでもあると思うので状況に応じて適切なものを取り入れてみてください。 まとめ このようにリソース名の重複がある場合、大半のリソースは terraform apply 実行時にエラーとして出力してくれますが一部のリソースではエラーにならず既存リソースが更新される場合があります。今回の場合はTerraformプロジェクトが分かれていたということもあり、既存リソースが上書きされてしまっていることに気付くのが遅れました。特にEvent Ruleは定期実行されるまで気づけず障害になる可能性もあるため気をつけてください。 備考 関連issue:  https://github.com/hashicorp/terraform-provider-aws/issues/25598

はじめに 基幹システムグループの島です。この記事ではさほどAIに詳しくない私がRoo Codeを使って実際にコーディングしてみた体験を書きます。 Roo Codeは簡単に使えるのでAIの利用に不慣れな人にオススメだと感じました。そういった人の参考になればと思います。 ※ Roo Codeについては公式のリポジトリを参照ください 1 この方法はGitHub Copilotを利用可能な状態になっていることが前提条件です インストール VSCodeの拡張機能マーケットプレイスから「Roo Code」と検索するとRoo Codeが出てくるのでインストールします。 拡張機能からRoo Codeをインストール インストールすると左バーにロケットのアイコンが表示されるので、そこからRoo Codeを利用できます。 ロケットのアイコンをクリック 以上でインストールは完了です。次に初期設定を行います。 初期設定 利用するモデルを設定する はじめに利用するAPIプロバイダーと言語モデルを設定します。 API Providerは「 VS Code LM API 」を選択します。これはGitHub Copilotが提供しているAPIで、GitHub Copilotが使える状態であれば追加課金も発生せず、細かい設定も不要で気軽に使えます。 Language Modelはお好みのモデルを選んでください。今回は「 copilot -claude-3.5-sonnet 」にしました。 APIプロバイダーと言語モデルの設定 権限を設定する 次にRoo Codeの権限を設定します。画面下部の「Auto-approve」と書かれている部分をクリックすると権限設定を表示できます。 権限設定の開き方 権限設定の開き方 権限設定の開き方 Auto-approveにチェックをつけると承認ボタンを押さなくても自動でコードを読んで変更してくれます。 私はRoo Codeがどのコードを読んでどういう変更をしたかを理解しながら進めたかったのでAuto-approveはオフにして、承認しながら進めるようにしました。 権限はコードを読んで変更してもらうだけなら「Read files and directories」と「Edit fles」にチェックを付けておけば問題ないです。 権限設定 権限設定 権限設定 以上でRoo Codeを利用する準備ができました。ここからは実際にRoo Codeを使ってコーディングしていきます。 実際にコーディングしてみる 下部の入力欄にプロンプトを入力します。今回入力したプロンプトは以下です。 slack.rsの352行で投稿数が多いとSlack APIのrate limitエラーになってしまう。一度ユーザー情報を取得したユーザーについてはSlackAPIを呼ばずにユーザー名を設定するように変更し、APIの呼び出し回数を減らしたい プロンプトを入力 プロンプトを入力 プロンプトを入力 もっとざっくりしたプロンプトでも動きますが詳しく書いた方が精度は上がります。 プロンプトを送るとslack.rsを読みたいと返ってきました。Approveを押して承認します。 プロンプトへのレスポンス プロンプトへのレスポンス プロンプトへのレスポンス コードの問題点と変更内容の説明が提示されます。あわせて変更したコードも提示されます。Saveを押すと変更したコードが保存されます。Rejectを押したり、追加で別の指示を送ると別の修正案を提示してくれます。 変更したソースコードとその説明が表示される 変更したソースコードとその説明が表示される 変更したソースコードとその説明が表示される Saveすると次の修正箇所が提示されます。これも確認して問題なければSaveします。 次の修正コードが提示される 次の修正コードが提示される 次の修正コードが提示される これを続けていってすべての修正が完了するとTask Completedとなり終了します。 すべての修正が終わるとTask Completedとなり終了する 修正されたソースです。数行の修正であれば、確認しながらでも1~2分で終わります。複数ファイルの修正ももちろんしてくれます。 所感 1回のプロンプトで変更箇所の特定から複数のコード修正までやってくれるので使いやすかったです。また日本語に対応しているのも嬉しいポイントです。 自分は今後以下のような使い方をしようと考えています。 自分で変更したコードの答え合わせやより良い変更案を提案してもらう 最初にRoo Codeにコード変更してもらい、それをベースに自分で微調整する 毎回完璧なコードを書けるわけではないので、人の目によるチェックは必要です。 余談ですが最近はGitHub CopilotがGitHub上でプルリクエストのレビューもしてくれるのでAIに書かせてAIにレビューしてもらうこともできます。 GitHub Copilotによるプルリクエストのコードレビュー 簡単に使えるのでぜひ使ってみてください。 脚注 Roo-Code： https://github.com/RooVetGit/Roo-Code ︎

Cloudflare管理者をしている石川です。 先日開催されたCloudflare Meet-upで「Cloudflare Streamを使った簡単動画配信」というタイトルでLTしてきました。 Cloudflare Meet-up Tokyo Vol.7 – connpass 個人的にCloudflareは2年ほど前から使ってましたが、会社としては今回が初導入となります。前々からCloudflare使いたいなというシーンはあったのですが、今回ちょうどいい内容とタイミングでしたので導入と相成りました。 導入後にまず考慮するのは構成管理ですが、CloudflareはTerraformサポートしています。 現状アカウント管理だけIaC化して運用しています（Streamはコンテンツ管理しかないので構成は不要） 参考： Overview · Cloudflare Terraform docs WorkersやPagesを使っているときにも感じていましたが、複雑なことをしなければCloudflareはかなり使いやすいプラットフォームだと思います。Streamのその例に漏れず動画配信環境を簡単に作れますし、費用見積もりもしやすかったのが今回とても助かりました。 他の方のLTで気になったこと PagesとWorkers統合の気配 前々からちょいちょい確度の高い噂であったWorkersへの統合。 参考： 最近のCloudflare Workers – ゆーすけべー日記 Pagesなくなるとそこそこ困るんですが、お互いのいいところどりの形で統合してほしいですね。 4月か5月に行われるであろうDeveloper Weekで発表される可能性もあるので要チェックです。 参考： Developer Week | Cloudflare Cloudflareのざっくりとした権限 Cloudflareでアカウント管理し出してから私も知ったのですが、結構ざっくりとしたRoleしか用意されていません。 参考： Account roles · Cloudflare Fundamentals docs Pagesでビルドログだけ見せたいのに、WorkersのAdmin権限を与えないといけないなど、過剰権限で運用を強いられるシーンもあり、今後の組織での利用でちょっと頭を悩ませている点です。 このあたりも今後アップデートがあると嬉しいですね。

ニフティ株式会社の仲上です。以前Notionでの作図について記事を書きました。 【2023年12月版】Notionの作図機能紹介(会社編) 今回はdraw.io（Diagrams.net）に特化したお話をします。Notionでdraw.ioを使った作図をして困っている方は参考にしてみてください。 はじめに 設計とか要件整理とかしていると、よくdraw.ioで図を書くことが増えます。 ただ、そういった画像をpngやjpegで貼り付けると、あとから編集できなくて困ることがあります(編集元のファイルはマイドライブの闇の中へ……)。 そんな悩みの解決方法について話していきます。 その1 SVGでエクスポートするべし draw.ioはSVG形式でも読み込むことができます。 SVGは汎用的なファイル形式でどこでも使うことができるので、基本この形式で保存することをおすすめします(生のdraw.ioは独自形式のXMLファイル)。 その2 Notionにペーストすべし SVGにエクスポートしても、共有できる場所にはっておかなければ意味がありません。 Notionに貼って、誰でも見れるようにしましょう。 その3 draw.ioの拡張機能をいれるべし ぶっちゃけここまではこの機能を使うための前座でしかないです。 draw.io for Notion – Chrome Web Store この拡張機能をいれるとNotion上で直接SVGファイルを編集できます。 まとめ 全ファイルSVGにしておくれ！

障害報告を自動生成するbot はじめに こんにちは！SREチームの島です。普段はシステム障害によるお客様影響を減らすためにチームを横断したSRE活動をしています。 今回はSlackの会話履歴から障害報告を自動生成してくれるbotを作ったのでご紹介します。他社でも似たような事例はよく見かけますが、事例が多いということは同じような課題を抱えている人が多いということだと思うので、参考になればと思い、私の体験を書きます。 こんな人に読んでほしい この記事は以下のような課題を抱えているエンジニアやSREの方に特に読んでほしいです。 障害報告を書くのに時間がかかる。情報を集めてくるのが大変 障害対応中に途中から入ってきた人に状況を説明するのが大変 障害報告を書く負担を減らしたい 作った背景 課題を把握する 障害対応って大変ですよね。私はできるだけ障害対応者の負担を減らしたいと考えていました。そこでまずは障害対応における課題を把握するためにエンジニア全員へサーベイを実施しました。 サーベイの結果 サーベイの結果 サーベイの結果 その結果、「 障害報を書くのが大変・負荷が大きい」 という意見が半数以上の人から挙がりました。他にもさまざまな課題や要望が挙がったのですが、「この課題になら自分でもすぐにアプローチできるのでは」と思い、今回の開発に至りました。 ニフティの障害対応フロー ニフティでは障害が発生するとその障害の専用チャンネルを作り、チャンネル内でやりとりを行うルールとなっています。 ニフティの障害対応フローを簡単にまとめると以下のようになります。 ニフティの障害対応フロー（概略） ニフティの障害対応フロー（概略） ニフティの障害対応フロー（概略） このフローとサーベイ結果を踏まえると以下のような課題が見えてきました。 担当者は障害対応をしながら障害報を更新しなければならない 途中から障害対応に参加した人が一目で状況を理解しづらい（人に聞くか、チャンネルを読み返すか、更新中の障害報を読むしかない） 担当者は後日、Slackの会話を見返しながら障害報を完成させないといけない この課題にアプローチするため、障害情報を要約するbotを作成し、障害報作成の負担軽減を試みました。 障害要約botの活用イメージ 障害要約botの活用イメージ 障害要約botの活用イメージ 以上の背景を踏まえて、今回作成したbotについてご紹介します。 作ったもの 障害要約bot 今回作ったbotを「障害要約bot」と名付けました。 彼はSlackチャンネル内の会話履歴を読み取って障害情報を要約してくれます。 彼は以前からニフティに存在する「myfriendGPT」という有能な友達（社内ツール）のソースをベースに作りました。 1 ベースとなった社内ツール「myfriendGPT」 つまり彼はmyfriendGPTの弟分です。そういった意味も込めてプロフィールの顔写真をmyfriendGPTと同じWEBサイト（ThisPersonDoesNotExist）で作成しました。 https://this-person-does-not-exist.com/en 実際に使ってみる 作った障害要約botを実際に使ってみました。 使い方は要約をしたいSlackチャンネルで障害要約botへ空メンションを送るだけです。 障害要約botの使い方。空メンションを送るだけで呼び出せる 使い方はなるべくシンプルにして誰でも使えるようにしました。障害対応時にしか使わないため複雑な操作が必要だと使い方を忘れてしまったり、面倒で使わなくなってしまうと考えたからです。 数秒待つと障害情報の要約を返してくれます。 返ってきた障害情報の要約 伏せ字が多く見づらくてすみません。 Slackの会話履歴から読み取れる情報を要約してくれます。Slackから読み取れない情報（この例では影響金額と影響ユーザー数）は「不明」と返されます。返す項目は障害報のフォーマットに合わせているので、これをそのまま障害報にコピーすることができます。もちろんAIなので情報が正しいか精査は必要ですが。 対応ログやエスカレーションフローも返してくれます。（上のキャプチャの続きです） 返ってきた対応ログ、エスカレーションフロー 人力で対応ログを書くとなるとSlackを遡って何時何分に何が起きたかを調べないといけないので大変ですよね。対応ログの作成には特に障害要約botの活躍を期待しています。エスカレーションフローもmermaid形式で返してくれるので、例えばエンジニア以外の方などプログラミングの知識があまりない方でもエスカレーションフローを書きやすくなるのが嬉しいポイントです。 この要約を見ることで途中から参加した人でも素早く状況を理解できますし、Scribe（記録係）の人は要約を参考にすることで障害報を書く時間を削減できると期待しています。 myfriendGPTからの変更点 上の章で、既存ツールであるmyfriendGPTをベースに障害要約botを作成したと書きました。ここではベースとしたツールから「どこ」を「なぜ」変更したのか説明します。 1. チャンネル全体の会話を読み込むようにした myfriendGPTは1対1の対話式で使うbotなこともあり、スレッド内の会話のみ読み取る仕様になっています。今回の障害要約botは複数人の会話を要約するという役目があったので、チャンネル全体を読み込むようにしました。 しかし読み込むデータ量が増えるとその分APIのRate Limitエラーなどのエラーが起きる確率も上がるという問題もありました。そこでエラーの発生を減らし、要約の精度を上げるために以下のポイントを工夫しました。 大量の添付ファイルを読み込むとエラーが発生するので、メッセージに添付された画像やファイルは読み込まないようにした 読み込むメッセージ数が多いとエラーになってしまうので、過去の障害対応期間やメッセージ数を参考に読み込むメッセージを直近7日間、最大1000件までに制限した 人間以外の発言を読み取ると要約に余計な情報が入ってしまうため、人間の発言のみ読み取るようにした。下のキャプチャがその例です。 アプリからの通知や人間の発言ではないメッセージ。これらを無視するように設定 これらを無視しないと人間以外の発言が要約に含まれてしまい精度を欠く 2. 投稿日時、 投稿者を取得するようにした メッセージの投稿日時と投稿者名をAIに渡すようにしました。そうすることでいつ、誰がという情報を読んでくれるので、より詳細な要約を作成してくれます。 When,Whoを渡すことでより詳細な要約を作成してくれる なぜAI開発未経験で作成できたのか 1からこのようなbotを作るのは結構大変だと思います。自分もAIの開発経験がなかったので何もない状態から開発するのはおそらく無理でした。 では今回なぜ障害要約botを作るのことができたのか。その要因をご紹介します。 ベースとなるソースコードがインナーソース化されていた ベースにできるソースコードが社内に存在し、そのコードが「利用できる状態になっていた」ことが要因として挙げられます。ベースにしたmyfriendGPTはインナーソース化 2 、つまり社内で使えるオープンソースとなっていました。そのため、 初見でも理解しやすいようにREADMEが充実していた 2次利用することが歓迎された という後押しもあり、スムーズに利用できました。 また、ちょうどタイミングよく「コントリビュートお試し会」というお試しでインナーソースのコントリビュート 3 をしてみようという社内勉強会があり、それに参加していたことでこのソースが使えそうだと思いつきました。まさにインナーソースの利点を活かすことができました。 日々情報収集していた これは好きで続けていたことなんですが、スキマ時間に他社の勉強会の資料をチェックしたり、SNSを見て気になった技術記事を日々チェックしていました。今回も過去に似たような事例を見た記憶があったので、真似してみようと思い作ることができました。日頃から情報収集をして脳に情報を溜めておくことは大事だと感じました。 今回のbotは以下の他社様の記事を参考にさせていただきました。 Amazon Bedrock を用いた障害対応報告書とポストモーテム文書自動作成 『全員インシデントコマンダー』の体制構築から 1年経った現在地 まとめ 今回はSlackの会話履歴から障害報告を自動生成するbotを作成しました。 まだ公開したばかりで利用実績が少なく実績を報告できないのが残念ですが、これから社内で障害要約botが活躍してくれることを願っています。（SREとしては活躍する機会が少ないのが理想ですが） 障害報作成の負担を軽減することで担当者が障害対応に集中でき、対応にかかる時間やコストを削減できることを今後期待しています。 ※ 脚注 myfriendGPTについてはこちらの記事を参照ください。こちらも一読いただけるとより理解を深められます。 ChatGPT APIを活用したSlackbotを作成して、30分以内に会社内に有能な友達を作る ︎ インナーソースについてはこちらの記事で詳しく紹介しています。 インナーソースを導入してみた その① お試し導入編 ︎ コントリビュート：自分がオーナーでないリポジトリのソースを修正してあげること ︎

エンジニアリングマネージャーをしています、芦川です。 2025-02-26 に D-Plus Tokyo #11~受けてよかった！自分が受けたい！オンボーディング Part2 にて、社内で実施している業務ドメイン知識のオンボーディングの話をしてきましたので、ブログも書きたいと思います。（ 発表スライドはこちらです。 ） 20年も同じ会社にいれば、そこで初めて実感することがいくつかあります。今回もその中の1つで、プロダクトの寿命の長さや、プロダクトに関わるエンジニアの期間などの観点も含めて、オンボーディングの大事さについて触れたいと思います。 結論 この図が最も伝えたいことなので、先に示しておきます。 プロダクトを開発し、お客様に長くご利用いただくために、より便利な機能や体験を提供していきます。 より便利な機能や体験というものは、メールを送ったり、物流を通してモノを送ったり、決済手段を増やしたりと、プロダクトの周辺にものが増えてきます。これは、要するに、業務ドメイン知識です。 一方で、一般的にエンジニアはプロダクト全体の寿命に比べると携わる期間は短いものです。なので、これからもそのプロダクトを成長させるためには、開発に早く携われるようにしないといけません。 プロダクトを成長させるための開発は、単なるコーディング・テスト・デプロイという単純なものではなく、現在のお客様の体験を理解し、それを支えている仕組みを知らないといけません。つまり、周囲のものも含めて業務ドメイン知識の吸収が必要です。 そこで、業務ドメイン知識のオンボーディングが必要になり、うまくこの循環が回れば、よりプロダクトを成長させるサイクルを早くできると考えることができます。 で、業務ドメイン知識のコンテンツの作り方については記事後半にありますので、もしよろしければ、ご参考ください。 さてここからは、スライドからの抜粋と補足説明をしていきたいと思います。 ニフティの歴史は長く、10年以上続いているプロダクトも多数あります ISP事業は、すでに社会インフラとなっているのも関係しそうですが、長らくお客様にお使いいただける傾向があります。 そして、ISP的な仕組みの業務ドメイン知識とは別に、プロダクトが成長していくと、その周辺にいろいろなシステムが増えていきます。上の図はイメージですが、他にもSMSを送ったり、決済手段が増えたりといろいろあります。 そもそもオンボーディングで目指したいレベルは？ 徐々にオンボーディングの話に移りますが、まず目指したいレベル感を明確にしてみると、単なる「開発できるようになる」ではなく、「お客様のために開発できるようになる」をどうせなら目指したいと思います。お客様のために、というからには、お客様が現在どんな体験をしていて、それをささえる周辺のシステムはどのようになっているかわかっている状態が望ましいです。 プロダクトの寿命と1人のエンジニアが携わる期間について で、次は時間軸で考えてみたいと思います。ある1つのプロダクトの寿命というものを時間軸として切り取り、そこに会社やエンジニアのそれぞれの時間軸をタイムラインとしてプロットしてみます。 ある１つのプロダクトの寿命に比べ、1人のエンジニアが関わる時間は一般的に短く、イメージとしてはこんな感じかと思います。キャリアチェンジや入退社など様々な理由で、結果としてこのようになります。 なので、今いるエンジニアは将来入ってくるエンジニアのことを思い、ソースコード、ドキュメントを作ることが大事であり、読みやすいコード、シンプルな設計、意図がわかるドキュメントなど、いろいろ残しておかないといけないことになります。何をどう残すかみたいな話はいろいろ話したいことがあるのですが、今日の主題はここではなく、新たにジョインする人の話にフォーカスすると、そういうものをいち早く吸収して、プロダクトを成長させるための知識を得ないといけなく、その早さが大事になるということがわかります。 目指したい好循環 つまり、これまで説明したことをあわせると、こういう循環ができると思います。 プロダクトが成長すると、周辺にものが増えてきます、これは業務ドメイン知識と同義です。エンジニアはプロダクト時間軸に対してかなり早く入れ替わりが発生するため、よりプロダクトを成長させる開発ができるようには、早く育てる必要があります。で、オンボーディングで目指したいのは、ただ単に開発とテストとデプロイができるようになることだけではなく、プロダクトをグロースさせるために必要な周辺知識を知ってほしいと思います。つまり、どんなお客様が使っているのか？お客様体験をささえている周辺の仕組みはどのようになっているのか、ということです。それらを知っていることで、プロダクトの成長を見据えた開発、もっとアイデアが出たり何かを効率化したり、ということができてくるのかな、と考えています。 以上が、ドメイン知識のオンボーディングをすることにより、エンジニアの成長を早め、継続的にプロダクトの成長を促す好循環をもたらしていく、という説明でした。 どうやってドメイン知識のオンボーディングコンテンツを作ったか？ ここからはオンボーディングコンテンツ作成の話です。上のスライドにあるような順番で作成していきました。社内にいるドメイン知識のマスターたち（一番知ってそうな方）にお声がけしていき、それぞれのドメインでの担当者を決めて約1時間くらいの講義 / 小テスト 形式で、コンテンツを作成していただきました。さらにすべての講義については録画をすべて取り、今後ジョインする方々がすぐに閲覧できるようにしました。コンテンツについては、たいてい社内に既存のドキュメントがあるため、そこへのリンク集のような形で話の流れをまとめてもらう1ページのような想定です。 とてもじゃないですが、細かいところまで知ろうとすると非常に時間がかかることになり難しくなると思うので、浅く広く知ってもらうことを重視する考え方です。濃さの調整ですが、あるドメイン知識の講義時間を1時間確保するので、その中で伝えられる程度にしてください、と先に時間制限を設けました。 コンテンツはでき次第、講義を開催していき、既存メンバーに対して教育していきます。 結果的に、各ドメイン知識ごとに、ドキュメントの URL やビデオ集のページが作成されます！ すばらしい、これは宝です。 あとは、新しくジョインしていただいた方に漏れなくこのコンテンツが伝わるよう、Slackワークフローを使って自動的にメッセージが飛ぶように仕掛けました。 最後に 長期的なプロダクトの成長を支えるためには、技術力と業務知識の両方が不可欠です。特に、プロダクトの寿命が長く、複雑な業務知識が必要な場合、この両輪のバランスが重要になってきます。 私の経験から、効果的なオンボーディングとは、単なる技術スキルの学習ではなく、プロダクトを取り巻く業務全体への理解を深める機会なのだと思います。プロダクトを成長させるエンジニアは、コードを書くスキルと同じくらい、ビジネスや業務への深い理解が求められていると思います。 というところで、以上、プロダクトの成長を継続的に促すには「技術スタックだけじゃない、業務ドメイン知識のオンボーディングも同じくらいの量が必要な話」でした。

ニフティにはベテランから若手まで、多種多様なエンジニアが働いています。その考え方やキャリアパスも人それぞれですが、基本的には社員自身が主体的にキャリアについて考え、自ら道を切り開いていく自由な風土があります。今回は「マイ ニフティ」のサービスを手掛ける開発メンバー3名にインタビュー。エンジニアから見たニフティという会社の環境について、キャリアパスについてなど、現場で働く開発者ならではのリアルな視点で話を聞きました。 自己紹介 K.Nさん 2009年入社。デザインチームにコーダーとして配属され、ウェブサイトのディレクションを担当。2015年から、社内のスクラムエバンジェリストとして活躍中。CSMやA-CSMの資格を持ち、10チーム以上、40名以上のエンジニアに対してスクラム導入やサポートを実施してきた。スクラムマスターギルドを主催し、社内のアジャイル文化の醸成に貢献。プライベートでは、アフタヌーンティーとボードゲームを愛する一面も。社内ボードゲーム部の部長として、ドミニオンの普及にも尽力している。 M.Kさん 2019年新卒で入社。2022年から会員向けiOS/Androidアプリ「マイ ニフティ」の開発・運用を担当。チームに入った当初はiOS/Andoirdアプリ開発は未経験だったが、現在はアプリ自体はもちろんバックエンド、コンテンツ管理用の内製ツールまで幅広く担当している。最近は某パフォーマンスチューニングコンテストの振り返りをしながら、担当システムに活かせることがないか模索中。 A.Mさん 2019年新卒で入社。「ニフティ ニュース」チームに約4年半所属し、その中で、2021年のマイニフティアプリの立ち上げ時にiOSアプリを主導して開発。体制変更に伴って、2024年3月にマイニフティチームに異動。Jリーグ「横浜F・マリノス」のサポーターでもあり、サッカー駆動で全国各地に遠征をしている。家電などに詳しい。 お互いを高め合える同期エンジニアの存在 みなさんは「マイ ニフティ」を手掛けるチームのメンバーということですが、お互いに対する印象を教えてください。 K.Nさん 私は二人よりも10年先輩で、「マイ ニフティ」のスクラムマスターをやっています。A.Mとは前部署で「ニフティニュース」というサービスのアプリ開発を一緒にやっていた仲間でもあり、戦友のような存在ですね。アプリのエンジニアとして、非常に頼もしく感じています。ちなみに、彼はサッカーやポイ活、家電製品に詳しくて、私が家電を買い替える時は必ず相談して、薦められるまま買っています。 M.Kとは、彼が2022年に「マイ ニフティ」にジョインした時からの付き合いです。彼の長所は指摘されたことを真剣に受け止める素直さ。それまでアプリ開発の経験はなかったのですが、すぐに主戦力になって、今ではチームを牽引してくれています。漫画の趣味が合うので、よく好きな作品について話しますね。 私から見て、彼らは理想的な関係性だと思います。お互いにフォローし合いつつ高め合って、すごく良いムーブが生まれている。これからもタッグでチームを牽引してほしいですね。 では、K.Nさんはお二人にとってどんな先輩、リーダーでしょうか？ A.Mさん 僕が1年目の頃からお世話になっていますが、「温室」で育ててもらった感覚があります。もともと初対面の人とのコミュニケーションが苦手だったのですが、たとえば業務でチーム外の人と調整を行う時などは、K.Nさんにかなりフォローしていただきました。また、どちらかというとネガティブに考えてしまう性格も、ポジティブなK.Nさんに影響されて少しずつ変わってきましたね。今は落ち込むことがあっても持ち直す力がだいぶ身についたと思います。 M.Kさん 僕は新人の頃から社内インフラの開発や運用に携わっていたこともあり、「マイ ニフティ」のチームに異動した当初、ユーザーさん向けのサービスに関する知識がほとんどありませんでした。ただ、K.Nさんと企画チームのやりとりを見て、ユーザーさんに使ってもらうためにはどういう視点が必要か、いかにサービスを運用すべきかといったところを学びましたし、必要なスキルを身につけるためにサポートしていただきました。 「マイニフティ」は会社の顔。下手なものは出せない みなさんが手掛ける「マイ ニフティ」とは、どのようなサービスなのでしょうか？ K.Nさん @niftyの会員様向けアプリで、2021年にiOS版、2022年にAndroid版をリリースしました。@niftyのトップページやサポートページ、各サービスサイトなどが集約されていて、アプリを開けば知りたい情報にアクセスできます。また、利用料金やNifMoの通信料を確認したり、@niftyメールをチェックしたり、お知らせなども含めてホームタブで一気見できるようになっています。一言で言えば、お客様がインターネットやニフティのサービスを快適にご利用いただけるよう、サポートするためのアプリですね。 K.NさんとA.Mさんは「マイ ニフティ」の立ち上げメンバーで、M.Kさんは2022年のAndroid版の開発メンバーとしてアサインされたと伺いました。M.Kさんはそれまでアプリ開発の経験がなかったということで、かなり苦労されたのでは？ M.Kさん 正直、大変でした（笑）。ただ、そもそも「マイ ニフティ」には自らの希望で異動してきたので、未経験ながらアプリ開発を任せてもらえるのはありがたかったですね。もちろん、それまでの社内システムの業務にもやりがいを感じていましたが、徐々に顧客向けのサービスにも携わってみたいと考えていた頃に、社内で「公募制度」というものがスタートしたんです。新しい人材を必要としているチームが全社に向けて募集をかけられるというもので、「マイ ニフティ」でも開発メンバーを募っていました。ちょうどAndroid版の開発が始まったところで、市場でもニーズの高いアプリ開発に携われるチャンスだと考え、トライしてみようと。 ただ、大変だったと。 M.Kさん 当初は本当に何も分からず、どこから始めればいいんだろうという状況で。ただ、先輩が丁寧にサポートしてくれましたし、自分でもアプリ開発者が集まるカンファレンスなどに参加して、そこで聴いたセッションの内容を実務で試してみたりと、色んな角度から知識を深めていきました。 また、僕が入ったタイミングではすでにエンジニア同士の議論が尽くされていて、基本的な設計や構造などはあらかじめまとめられていました。そのため、自分はその流れに乗りつつアプリの学習やスキルの習得に注力できたところもありますね。 A.Mさんはいかがでしょう？　立ち上げ時に苦労したこと、課題に感じていたことはありますか？ A.Mさん それまで「ニフティ ニュース」のアプリに携わっていたとはいえ、運用や新しい機能の開発がメインで、さすがにイチからアプリを立ち上げた経験はありませんでした。どういう技術を使えばいいのかといった、本当に入口の部分から調べてやっていく大変さはありましたね。また、単純にタスク量が多く、期日までに終わるのかという不安や焦りもありました。 ただ、新規サービスの立ち上げはなかなか経験できることではないですし、開発を通じて成長できた実感があります。自分がこれまで触れてこなかった社内のドメイン知識も全て活用しながら開発にあたったことで、アプリのことだけでなくニフティ内部の情報の回り方みたいなところも含めて理解が深まりましたね。 K.Nさんはチームリーダーとして、サービス全体のクオリティなども見なければいけない立場だったと思います。当時、どんな意識で開発に臨んでいましたか？ K.Nさん お客様からすると、「マイ ニフティ」はニフティの顔だと思います。そんなサービスが何度もクラッシュしたり、うまく使えなかったりすると、ニフティに対する印象も悪くなってしまう。そんな意識で開発にあたっていました。また、今後もずっと運用していくサービスになると考えていましたので、最初にどこまでつくるのか、どれくらい先のことまで考慮してつくるのか、チームで何度も議論を重ねましたね。 それらの苦労を経てiOS版をリリースした直後のお客さんの反応はいかがでしたか？ K.Nさん 企画チームが周知を頑張ってくれたおかげで、早い段階で10万DLに到達しました。使っていただいたお客様からも、概ね高い評価をいただけて。ただ、リリース当初から目標として掲げていたのは、単に便利というだけでなく、@niftyのサービスを長く使っていただくうえで「なくてはならないアプリ」にまで持っていくことでした。極端に言えば、「マイ ニフティ」があるから@niftyを契約しましたと言ってもらえるくらいの機能と魅力を持つサービスに成長させていかなければならないと考えています。 後編に続きます！ 今回はニフティのマイ ニフティチームのインタビューの様子をお届けしました。続きは近日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

はじめに こんにちは。ニフティ株式会社の仲上です。 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です。指定した場所の降水量をわかりやすく可視化してくれるといったサービス。インフラも充実していて、本格的なサービスですね。 多くの方にご参加いただき、素晴らしい成果報告が実施できました！ ご参加いただいた皆様、ありがとうございました！ 終わりに 今年のハッカソン合宿は、どのチームも非常にレベルの高い成果物ばかりでした。 使ったことのない技術なども積極的に取り入れ、運営の私たちも学びのあるハッカソン合宿となりました。 そして昨年に引き続き、快適にハッカソン合宿ができる環境を提供してくださったノジマ大磯スクウェアさん、ありがとうございました！ 各チームの開発物のより詳細な仕様や開発秘話など、それぞれブログが公開されますので、お楽しみに！！