はじめに こんにちは！ニフティ株式会社の坂野です！ 弊社は 2025年7月11日（金）と12日（土）の二日間にわたって開催された「SRE NEXT 2025」にゴールドスポンサーとしてブースを出展しました。 今回は、SRE NEXT 2025で個人的に聴講したセッションの内容の紹介と当日のニフティブースの様子についてお伝えします。 聴講セッションレポート 当日は多くの興味深いセッションが開催されていましたが、本記事では特に学びが多かった2つのセッションについてご紹介します。 複雑なシステムにおけるUser Journey SLOの導入 株式会社メルカリの土屋様により、お客様目線のSLOである「User Journey SLO」の導入についてご紹介いただきました。 「User Journey SLO」とは、個々のサービスにフォーカスしがちな開発者目線のSLOとは異なり、お客様の体験に焦点を当てた、サービス横断のSLOを指します。 土屋さんによると、SREチームはサービス全体の品質向上を目指していますが、全てのマイクロサービスを監視するのは現実的ではありません。そのため、コアサービスが機能しなくなるほどの「クリティカルな障害」を検知することに注力しているとのことです。 セッションでは、この障害を検知するための具体的な実装例として、クリティカルなAPIの探索方法とその自動化、障害発生時におけるユーザーへの影響範囲の自動通知などが提示されました。多数のサービスを運用する当社にとっても、大変参考になる内容でした。 サービス連携の“謎解き”を可能にする Datadogによる分散トレース導入の一歩 株式会社タイミーの徳富様により、サービス間のボトルネック発見を容易にするための分散トレーシング導入について、ご紹介いただきました。 講演では、分散トレース情報をサービス間で連携させる方式、特に伝搬フォーマットの切り替えや複数フォーマットへの対応を可能にするInject/Extractを用いた実装方法など、その詳細な仕組みまで丁寧に解説されていました。 私自身、分散トレーシングは概念しか知りませんでしたが、具体的な仕組みを学ぶことができ、大変勉強になりました。 当日のブース出展の様子 続いて、私たちがゴールドスポンサーとして出展したニフティブースでの活動についてご紹介します。 弊社のブースでは、技術的なご紹介だけでなく、ご来場の皆様と双方向のコミュニケーションを楽しむための中心企画として、パネルアンケートを実施しました。 当日は多くの方にご参加いただき、シールの数から皆様の興味や関心の方向性をリアルタイムに感じることができました。 今回はどら焼きやその他ノベルティに加え、「NIFTY Tech Book」を配布しました。これが想定をはるかに超える人気で、「本業がありながらこのレベルのものを執筆できるのは本当にすごい」と熱心に感想を伝えてくださる方もいました。 また、パネルアンケートの「ニフティを知っていますか？」という質問には、非常に多くの方が「知っている」にシールを貼ってくださり、中には「パソコン通信時代から！」といった嬉しいお声もいただきました。また、「ニフティのサービス」では、やはり主力サービスの「@nifty 光」の知名度が高く、ココログやホームページサービスといった長年提供しているサービスにも多くのシールが集まり、弊社の歴史と現在を改めて実感する結果となりました。 アンケートにご協力いただいた皆様、そしてブースで貴重なご意見を聞かせてくださった皆様、本当にありがとうございました。 おわりに 今回の「SRE NEXT 2025」、私自身は一日目のみの参加ではありましたが、セッションやブースでの交流、そして当社の 仲上によるスポンサーセッション のすべてを通じて、学び多き一日となりました。 そして、他社の皆様の活動から得た気づきを参考に、自分たちのSRE活動をさらに良くしていきたいです。 最後になりますが、素晴らしい学びの場を提供してくださった登壇者の皆様、運営スタッフの皆様、そしてブースにお立ち寄りいただいたすべての皆様に、心より御礼申し上げます。ありがとうございました。

はじめまして。 ニフティ株式会社の浅利です。 現在、私は既存のクラウド環境から新しいクラウド環境への移行するプロジェクトを推進しています。 移行の対象システムには、長年の運用を経て内部構造が複雑化し、いわゆる「ブラックボックス」となってしまったシステムもいくつか含まれています。 他にも要因はあるのですが、プロジェクト全体のスケジュールにも遅延が見え始めてきました。 この状況をどう乗り越えるべきかをAWSの方との定例相談会でこの課題を共有したところ、この記事のタイトルにある構成を紹介いただいたので、今回は導入部分と実際の利用の二回に記事を分けてお送りします。 導入にあたって事前に確認したポイントも併せてご紹介しますので、同様の課題を抱える方の参考になれば幸いです。 利用するサービスについて Cline, Amazon Bedrock Cline VSCode上で動作する拡張機能です。ユーザーがAIに指示を出す対話インターフェースとして機能し、その内容を背後にあるAmazon Bedrockへ送信する役割を担います。 Amazon Bedrock Clineからのリクエストを受け取るAWSのサービスです。Amazonやサードパーティ製の様々なAIモデルの中から、指定されたモデルを使って指示を処理し、結果をClineに返します。 Amazon Q, Amazon Q Developer Amazon Q VSCode上で動作する拡張機能で、開発者が直接対話するAIアシスタントの窓口です。コード生成などの指示を受け付け、そのリクエストをAmazon Q Developerに送ります。 Amazon Q Developer Amazon Q Developerは、リクエストに応じて最適な基盤モデルを呼び出して処理を実行します。 AI利用における情報漏洩や目的外利用のリスク 社内ソースコードをツールに入力した際、そのデータが外部のAIモデルの学習に利用されたり、意図せず外部に共有されたりしないかを確認しました。 結論から言うと今回の構成であればAIモデルの学習に利用されません。 Cline(VS Code拡張機能) Clineは、APIプロバイダーとして「Amazon Bedrock」を選択した場合、ユーザーのデータ（ソースコードやプロンプト）を自社サーバーを経由させず、直接AWSのエンドポイントに送信する仕組みになっています。 これはClineの利用規約にも明記されており「ユーザーが管理するインフラストラクチャ（Amazon Bedrockなど）経由ですべてのモデル呼び出しを指示する場合、Clineはユーザーの入力トークン、出力トークン、基盤となるコード、またはその他のユーザーコンテンツを受信または保存しない」と記載されています。 Cline Terms of Service (セクション3 “User Content”) Amazon Bedrockのデータ取り扱いについて AWSは、Amazon Bedrockに送信された顧客のコンテンツ(ソースコード、プロンプト、生成結果)を、ベースモデルの改善（学習）には使用せず、いかなるモデルプロバイダー(Anthropic社など)とも共有しないことを公式に明言しています。 Amazon Bedrock FAQs Amazon Bedrock Security and Compliance Amazon Q Developer AWSは公式FAQページで、Proプランのデータ保護について以下のように明記しています。 Pro Tier で Amazon Q Developer にアクセスするユーザーのコンテンツが、サービスの改善や、基礎となる基盤モデル (FM) のトレーニングに利用されることはありません。 https://docs.aws.amazon.com/ja_jp/amazonq/latest/qdeveloper-ug/data-protection.html (プライバシーのセクション「Amazon Q Developer はモデルのトレーニングに私のコンテンツを使用しますか?」) Cline + Amazon bedrock の導入 IAMユーザーの作成とアクセスキーの取得 マネジメントコンソールから「IAM」にアクセスし、ユーザーを作成します。 アクセスキーを作成し、キーとシークレットキーを取得します。 また、作成したユーザーにカスタムポリシーをアタッチします。 (ご利用の環境にあわせて適宜変更ください) モデルアクセスの有効化 今回は Amazon Bedrock で Claude Sonnet 4 を使用します。 使用可能なモデルはリージョンに依存しますが、Claude Sonnet 4 が利用可能な「オレゴンリージョン(us-west-2)」に切り替えておきます。 マネジメントコンソールから「Amazon Bedrock」にアクセスし、メニュー下部にある「モデルアクセス」をクリックします。 「特定のモデルを有効にする」のボタンをクリックし、「次へ」ボタンを押します。 必要な情報を入力し、「次へ」ボタンを押します。 最後に入力した内容を確認して送信します。 アクセスが付与されるまで数分待ちます。 Clineのインストールと設定 Visual Studio Codeを開き、拡張機能から「Cline」をインストールします。 Clineの拡張機能を開き、「Use Your Own API Key」を選択後、以下の設定を入れます。 「AWS Access Key」と「AWS Secret Key」にアクセスキーの情報を入力 Use cross-region inference にチェック (普段開発しているリージョンで、使いたいAIモデルが提供されていない場合) Use Prompt caching にチェック (応答速度を求める場合やコストを抑えたい場合) Modelは「anthropic.claude-sonnet-4-20250514-v1:0」を選択 これで「Cline + Amazon bedrock」側の導入は完了です。 Amazon Q + Amazon Q Developer の導入 IAM Identity Center ユーザの作成 IAM Identity Centerでサブスクライブ対象のユーザを作成します。 Organization環境下どうかで手順が異なりますので、ここでは詳細は割愛させていただきます。 ご利用の環境にあわせて、AWS公式ドキュメントなどを参考にユーザーの作成を進めてください。 Amazon Q Developer プロファイル作成 Amazon Q Developer プロファイルを作成し、VS Code で Amazon Q Developer にアクセスするための「スタートページ URL」を取得します。 マネジメントコンソールから「Amazon Q」にアクセスし、Amazon Q Developer の使用を開始します。 サブスクライブ対象のユーザのEメールを入力し、「続行」をクリックします。 Amazon Q Developer プロファイルを作成します。 (表示されているプロファイル名はデフォルトになります) プロファイルの作成が完了すると以下の画面になるので、「設定」ボタンを押すとセッティング画面に遷移するのでそこで「スタートページ URL」を取得します。 Amazon Q のインストールと設定 Visual Studio Codeを開き、拡張機能から「Amazon Q」をインストールします。 インストール後、サインインの選択画面で「Company account」を選択します。 取得した「スタートページ URL」の入力と、Regionには IAM Identity Center が存在するリージョンを選択します。 「アクセスの許可」をクリックするとRequest approved の画面が開きます。 以下の様に VScode でAmazon Q が利用可能になります。 これで「Amazon Q + Amazon Q Developer」側の導入は完了です。 次回は実際の利用とそれぞれの構成による違いについて触れます。

はじめに こんにちは。NIFTY engineering ブログ運営チームです。 ブログ運営チームでは、ニフティのエンジニアに関する情報を広く世間に発信する活動を行っています。 本記事では、前回の記事から新しく行った活動についてご紹介します。 前回の記事については、 【祝20,000MAU！】NIFTY engineering ブログ運用チームの活動まとめてみた をご確認ください。 前々回の記事は、 【祝10,000MAU！】NIFTY engineer blog運用チームの活動まとめてみた をご確認ください。 ここで、改めてブログ運営チームについて少し紹介させてください。 ブログ運営チームについて ブログ運営チームは、弊社の採用をブランディングしているワーキンググループのうちの1サブチームとして活動しています。 現在、メンバーは4人で、全員専任ではなく自身の業務の兼務で活動しています。 それでは本題に入ります。 今回の活動紹介 NotionからWordPressに自動連携プラグイン追加 前回の記事で最後にご紹介したNotion連携について、社内で利用を開始しました。 本プラグインは、Notionで書いたものを、WordPress上に自動で連携してくれます。 また本文中内の画像や、WordPressの記事公開するときに必要なアイキャッチ画像や、タグについてもNotionのDBで設定すると、自動でWordPressに反映してくれます。 ブログ講習会開催 ブログ執筆に関するアンケートを毎年ブログ運営チームでエンジニア向けに実施しています。 そちらのアンケートで、WordPressの操作方法や文章の書き方、公開までのフロー、執筆のガイドラインがわからないといった声が多く寄せられていました。 そこで、ブログ運営チームではデモを用いたブログ執筆の講習会を実施することにしました。 ブログ講習会では、ニフティでのブログ執筆の仕方や、公開方法、また前述のNotionのWordPress連携の使い方を実際にデモしながら説明し、実際の執筆イメージをもっていただくようにしました。 この講習会には、希望者の他に、先輩を見習ってたくさん記事を執筆してほしいという思いを込めて、エンジニアの新人にも参加してもらいました。 アンケートでは、講習会自体の満足度は高く、積極的に書いていきたいや余力があれば書いていきたいといった声が多数寄せられたので、今後も継続的に実施を検討しようと思います。 リレーブログの継続 今回も前回に引き続き、リレーブログを実施しました。 今回のリレーブログ： 【リレーブログ企画第三弾】CI/CDリレーブログをやります！ また今後、以下のリレーブログの実施も予定しています。 今後のリレーブログ：25年新卒リレーブログ（近日中）etc その他細かい改善 ブログ運営チームでは、前述のブログアンケートで使いづらい点などが寄せられていたものなどをプラグインを追加したり、ソースを修正したりして、日々改善していっています。 直近ですと、シンタックスハイライトがわかりにくいという意見があったので、それを改善するプラグインとかを導入するなども実施しました。 おわりに 本記事では、最近のブログ運営チームの活動をご紹介いたしました。 こちらの活動のご紹介が、皆様のお役に立てれば幸いです。

はじめに こんにちは、添野 隼矢です。 ニフティでは、インナーソース活動が活発的に行われています。 その中で、私は今年からインナーソースを率先して広めていく活動に参加しています。 本記事では、インナーソースを社内に広めていく活動の一環として、第2回コントリビュートお試し会※1を先日開催したので、そちらについて執筆したいと思います。 ※1 第1回コントリビュートお試し会は、去年の12月に開催しました。 コントリビュートとは？ まずコントリビュートとは、オープンソースプロジェクトやインナーソースプロジェクトなどにおいて、コードの修正、バグの修正、機能追加、ドキュメントの追加など、何らかの形で開発に貢献することを指します。 今回はこのコントリビュートを試してもらうという会になります。 コントリビュートお試し会について まずコントリビュートお試し会を開催するにあたり、Good First Issueがたくさんあり、比較的触りやすいツールやプロジェクトを探しました。 今回は、以前本ブログで紹介した「 もじこえ 」と「 myfriendGPT 」の2つを、コントリビュートを体験してもらうリポジトリとして選定し、その2つのリポジトリのトラステッドコミッターにも協力してもらいました。 次に、社内のエンジニアのSlackチャンネルで、参加者を募集しました。 結果、今回は6名に参加していただけました。 ~~ コントリビュートお試し会当日 ~~ まず始めに、インナーソースについての説明と、コントリビュートなどをするためのインナーソースガイドラインが弊社では作成されているので、そちらをもとに座学を実施しました。 その後、前述のトラステッドコミッターの協力のもと、コントリビュートの流れを実際に体験してもらうハンズオンを参加者に経験してもらいました。 参加者からの感想 この会の実施後、参加者にアンケートをとったところ、以下の結果になりました。 また以下のようなコメントももらいました。 インナーソースをコントリビュートする流れや心構えについて理解できた。 一通りの流れを実際に見ることができてよかったです。 コントリビュートの手順や思っていたよりも難易度は低くてやりやすさを感じました。 今後について 社内にインナーソースを広めていくため、今後も定期的にコントリビュートお試し会は開催していこうと思います。 また組織的な話でいいますと、ニフティでは InnerSource Commons というコミュニティに参加し、日本のインナーソース活動を広めていく活動にも協力しています。 InnerSource Commonsの Connpass の参加、お待ちしています。 もちろん、ニフティの Connpass 参加もよろしくお願いします。

はじめに こんにちは。ニフティの並木です。 今回は、「Amazon CloudFront」+「Amazon S3」で構成されているサイトのキャッシュを削除する方法をまとめました。 手順 AWSマネジメントコンソールで、キャッシュ削除の対象となるCloudFrontを選択します。 「キャッシュ削除」タブを選択し、「キャッシュ削除を作成」を押下します。 オブジェクトパスにS3バケット名を入力し「キャッシュ削除を作成」を押下します。 おわりに 「修正したはずなのになぜか反映されていない…」という場合はキャッシュが原因かもしれません。 そのような場合は、ぜひ今回の手順でキャッシュクリアを試してみてください。

はじめに 半年近くブログをサボっていた宮本です。意識していないと、なかなか書かないですね……。 今回はTerraformでNodeランタイムのAWS Lambdaを複数同時に作成しようとしたとき、遭遇した問題とその解決策についてご紹介しようと思います。 問題の発生した構成 業務でAWSを利用する際は基本的にTerraformを利用しており、Lambdaの管理もTerraformで実施しています。ただしLambdaはコンテナ形式では無く、昔ながらのコードをzipで固めてデプロイする形式にしていました。 このLambdaはNode.jsのランタイムを利用しており、コード自体はTypeScriptで開発してデプロイ時にterraform_dataリソースを使ってビルドしています。また、パッケージ管理にはyarn v1を利用していました。 resource "terraform_data" "build_code" { provisioner "local-exec" { working_dir = "${path.module}/app" command = <<EOT #!/bin/sh # 依存関係のインストール yarn install # ビルドコマンドの実行 yarn build EOT } } これ単体は正常に動作していたのですが、1つのプロジェクト内で同様の構成のLambda複数デプロイしようとしたところ yarn install のタイミングでエラーが発生するようになってしまいました。 error https://registry.yarnpkg.com/<パッケージパス>: Integrity check failed for "<パッケージ名>" (computed integrity doesn't match our records, got "<ハッシュ>") terraform_data同士に依存関係もないためTerraform上で同時に yarn install が動作したらしく、さらにこの2つの yarn install でインストールするパッケージに同一パッケージの異なるバージョンが含まれていたため、エラーが発生してしまったようです。 解決方法 今回試した限りでは、次の2種類の方法どちらかで回避できました。 yarnの実行時にキャッシュディレクトリを指定する yarn v1の利用をやめてpnpmやyarn v4に移行する yarnの実行時にキャッシュディレクトリを指定する yarnはパッケージのインストール時に、次回以降のインストールを高速にするためキャッシュを保存します。これがyarn v1だと、該当のプロジェクトではなくPC全体のグローバルなキャッシュとして保存しています。 今回は同一パッケージの別バージョンをよりにもよって同時にinstallしようとしたため、そのキャッシュ周りがおかしくなったことが直接の原因でした。 この解決策としては、実行時にyarnのキャッシュディレクトリを指定することで対処できます。 resource "terraform_data" "build_code" { provisioner "local-exec" { environment = { # キャッシュフォルダを指定 YARN_CACHE_FOLDER = ".yarn-cache" } working_dir = "${path.module}/app" command = <<EOT #!/bin/sh # 依存関係のインストール yarn install # ビルドコマンドの実行 yarn build EOT } } yarn v1の利用をやめてpnpmやyarn v4に移行する もう一つの解決策として、yarn v1の利用をやめることがあります。 同じyarnでもv4だとグローバルキャッシュ周りの動作が改善されているらしく、同じプロジェクトでも問題は発生しませんでした。また、pnpmでも試してみましたがこれも問題は発生しませんでした。 最新のパッケージ管理ツールだと、パッケージ同士の依存関係のバージョン差分の問題なども解決してくれるため、こちらの方がスマートな気はします。もっとも、パッケージ管理ツールを移行するとなると足が重いのも事実ですが……。 少なくとも、今後新しいNode.jsのプロジェクトを利用する場合は、最新のパッケージ管理ツールを利用したいですね。 おわりに 今回は、Terraformから複数のNode.jsのプロジェクトをビルドしようとした際に発生したエラーについて紹介しました。必ずしも発生する問題ではないと思いますが、もしyarn v1を利用していて似たような自体が発生した際に参考になれば幸いです。 参考 Provisioner: local-exec | Terraform | HashiCorp Developer yarn cache | Yarn

はじめに こんにちは。新卒1年目の大村です。 6月27日に開催されたDNS Summer Day 2025に先輩社員2名と共に参加してきました。 その感想をまとめていきます。 DNS Summer Dayとは https://www.dnsops.jp/event20250627.html 今年は日本橋のTKPガーデンシティPREMIUMで開催されました。 イベントの概要については、connpassに以下のような記載があります。 DNSは多くの重要な役割を持つ、代替となるものがないインフラサービスとなっています。一方で、DNSの運用については権威側にもリゾルバ側にも十分な関心が払われておらず、必要な予算や人材などもきちんと割り当てられているとは言えない状況が相変わらず継続しています。その状況を鑑み、DNSの基本的な話から突っ込んだ話までカバーしたイベントを開催します。 https://dnsops.connpass.com/event/358220/ イベントの応募には、キャンセル待ちが出るほどの参加希望者がいました。 会場の様子 広めの会議室が満席になるほどの盛況ぶりでした。 connpass応募者数の通りなら140人ほどだと思います。 あまり堅苦しい感じもなく、良い雰囲気のコミュニティといった雰囲気でした。 また、後方にはスポンサーのブースもありました。 なぜ参加したのか 私はOJTで「ISPオペレーションサブチーム」に配属となりました。このチームではDNSサーバの運用管理も担当しています。 ISPオペレーションサブチームの紹介はこちら 【インタビュー】ニフティのISPオペレーションチームについて【ISP前編】 【インタビュー】ニフティのISPオペレーションチームの過去と未来について【ISP後編】 チームとしてはDNS運用に役立つ情報収集のため、また私個人としてはDNSへの理解を深めるために参加しました。 参加してみての感想 特定のソフトウェアの仕様など詳細な話から、比較的理解しやすくても実践的な内容まで、多くの学びを得ることができました。 中にはユーモアあふれる発表もあり、DNSのみならず今後のプレゼンテーションの参考にもなりました。 このようなイベントにはほとんど参加したことがなかったのですが、今まで参加してこなかったことがもったいないと感じるほど充実した学びの場でした。 今回はブースを回るのも少し遠慮してしまったので、次回は積極的に参加したいと思います。 学び DNSについては初学者のため、見聞きしたもの全てが新たな学びでした。その中から特に印象に残ったものをいくつかを紹介したいと思います。 初めて“イベント”に参加してみて 前述の通り、私はこれまでこのようなイベントに参加したことがありませんでした。 しかし、初めて参加してみて次のような気づきがありました。 思ったよりも理解できる話が多かった 歴戦の猛者の集まりで、話がとても難しいようなイメージがありました。もちろん、そのような内容のものもありましたが、大半はある程度の事前知識があれば理解できるものでした。 雰囲気が良かった もっと堅苦しい超真面目な発表のイメージもありました。ですが実際は、ユーモアにあふれる発表が多かったです。 もっと声をかけてみても良かった 参加してみると、ブースの方とであったり、他の参加者と会話している人が多くいました。今回はかなり遠慮してしまったので、もっと積極的にしても良かったかなと思いました。 ドメインの廃止について ドメインの廃止には慎重にならなければならないということを学びました。 廃止した後に「ドロップキャッチ**」され悪用される可能性を考慮し、そのドメインがどのように運用されていたかの記録が十分に薄まるまで保持すべきとのことです。 つまり、廃止後もしばらくコストがかかるということですね。 将来、もしも新規ドメインの取得や廃止の話が出た際には、この話を思い出して検討したいと思います。 ** ドロップキャッチ: 他者が放棄したドメインを再取得可能になった瞬間に取得すること。詐欺などに悪用される可能性がある。 DNS as Codeについて 今回のイベントでは、DNSControl、octoDNSといった”DNS as Code”に関するセッションがありました。 DNS as Codeは初めて触れた概念で、非常に興味深く感じました。この手法は今後のDNS運用にかなり役立つのではないかと期待しています。 また、DNSには比較的硬派なイメージがありましたが、DNS as Codeと組み合わせて運用することで、そのイメージがかなり変わるだろうと思いました。 どこから情報を仕入れるか 登壇者の方々が詳しいのはもちろんですが、どこから情報を仕入れているのかが気になりました。 イベント全体を通して話を聞いていると、論文やRFC、ICANNのレポートなどを参照していることがわかりました。 まとめ DNS Summer Day 2025に参加しました。 イベントを通じて、DNSについて多くの知識と学びを得ることができたました。 今回はDNSに詳しくない状態での参加でしたが、今後知識を深めることでさらに理解が進み、より面白く感じられるだろうと思います。これからも学習を続け、来年もぜひとも参加したいと思います。

ニフティ株式会社は、2025年7月11日（金）〜 7月12日（土）に開催されるSRE NEXT 2025にゴールドスポンサーとして協賛します。 SRE NEXTは、サイトリライアビリティエンジニアリング（SRE）に関する日本最大級のカンファレンスです。 ニフティは過去にも本イベントに協賛しており、SRE分野の発展に貢献できることを大変嬉しく思います。 SRE NEXT 2025に関する詳細は、公式サイトを覧ください。皆様のお越しをお待ちしております！ 公式サイト https://sre-next.dev/2025/ スポンサーセッションに登壇にします 今年のSRE NEXT 2025では、 7月11日（金）14:30よりスポンサーセッションに登壇します。 セッションでは、ニフティがこれまでに培ってきたSREに関する知見や取り組みについてお話しする予定です。 Track B Gold Sponsor 7/11 14:30 – 14:40 モニタリング統一への道のり – 分散モニタリングツール統合のためのオブザーバビリティプロジェクト https://sre-next.dev/2025/schedule/#slot083 ブース出展もあります！ 開催期間中、ニフティは企業ブースを出展します。ブースでは、弊社のSREへの取り組みをご紹介するとともに、ご来場いただいた皆様に特製ノベルティを配布します。SREに関する情報交換の場として、またニフティのエンジニアとの交流の場として、ぜひお気軽にお立ち寄りください。 過去の協賛 SRE NEXT 2023 に GOLDスポンサーとして協賛 SRE NEXT 2022にGOLDスポンサーとして協賛＆登壇します！

ニフティ株式会社は、2025年7月11日（金）〜 7月12日（土）に開催されるSRE NEXT 2025にゴールドスポンサーとして協賛します。 SRE NEXTは、サイトリライアビリティエンジニアリング（SRE）に関する日本最大級のカンファレンスです。 ニフティは過去にも本イベントに協賛しており、SRE分野の発展に貢献できることを大変嬉しく思います。 SRE NEXT 2025に関する詳細は、公式サイトを覧ください。皆様のお越しをお待ちしております！ 公式サイト https://sre-next.dev/2025/ スポンサーセッションに登壇にします 今年のSRE NEXT 2025では、 7月11日（金）14:30よりスポンサーセッションに登壇します。 セッションでは、ニフティがこれまでに培ってきたSREに関する知見や取り組みについてお話しする予定です。 Track B Gold Sponsor 7/11 14:30 – 14:40 モニタリング統一への道のり – 分散モニタリングツール統合のためのオブザーバビリティプロジェクト https://sre-next.dev/2025/schedule/#slot083 ブース出展もあります！ 開催期間中、ニフティは企業ブースを出展します。ブースでは、弊社のSREへの取り組みをご紹介するとともに、ご来場いただいた皆様に特製ノベルティを配布します。SREに関する情報交換の場として、またニフティのエンジニアとの交流の場として、ぜひお気軽にお立ち寄りください。 過去の協賛 SRE NEXT 2023 に GOLDスポンサーとして協賛 SRE NEXT 2022にGOLDスポンサーとして協賛＆登壇します！

はじめに こんにちは！ ニフティ株式会社、エンジニア定例運営の後藤、佐藤です。 ニフティでは毎年エンジニアの新人研修を先輩エンジニアが 内製 で行う文化があります。 （通称、 エンジニア定例 と呼ばれています） 開催期間としては短期集中的に5月末~6月頭に実施し、準備は2か月前後で行います。 前年より資料の一般公開に取り組んでおり、今年も同様に一般公開いたします。 – 前年： ニフティ株式会社 エンジニア新人研修の内容を公開します | 2024年度版 新人研修の狙い ニフティ全体の技術力向上 体系立った基礎学習 チームでのサービス開発 短期的なサービス運用 生徒から講師による継続的運用 内製力の強化 育成強化 Webサービスを開発する上で必要なスキルを体系立てて学んでもらう スキルアップ 業務では学べない技術を積極的に取り組んでいく 今回の公開講義資料について 研修の到達目標として、「Webアプリケーションを独力で開発、クラウド上でリリースできるレベルの知識、技術力を身に付ける」を掲げており、それに伴う講義を行っています。 前年は「機械学習」の講義があったのですが、近年の生成AIの注目されているため、名前を改め、新しく「生成AI 2025」が今年から追加されております。 RAGや最近ホットなMCPの説明を入れておりますので、ぜひご覧ください！ それでは、以下公開可能な講義資料を掲示しますので、学習にお役立てください。 講義資料一覧 Git 2025 AWS 2025 サーバ運用入門 2025 コンテナ 2025 データベース 2025 セキュリティ 2025 オブジェクト指向 2025 生成AI 2025 [NEW!] Webアプリ 2025 モバイルアプリ 2025 ※ニフティ社内の開催日順で記載しています。 終わりに ニフティでは、長年にわたり自社開発の研修プログラムを実施しています。 このプログラムは、継続的な改善と進化を遂げており、教材の更新や新しい講座の導入、さらには前年度の新入社員が翌年には講師を務めるなど、独自の取り組みを行っています。 この研修制度の魅力は、 自らの学びを次世代に還元できる点 にあると強く感じています。 私自身、受講者だった時に疑問に感じたことを翌年は講師として解決できるため、理解が深まるとともに成長を実感できるのが魅力です。また、新人からのフィードバックは自分の説明力や技術理解を深める貴重な機会となっています。 この循環型の学習システムは、個人のスキル向上と同時に、研修プログラム全体の質の向上にも貢献しています。 弊社のエンジニア育成への取り組みや、最新の技術動向について詳しく知りたい方は、ニフティエンジニアブログをぜひご覧ください。

はじめに こんにちは！人事チームで新卒採用担当を担当している今泉です！ ドライブが趣味で、昨年ついに愛車のマツダのCX-3で日本三大酷道を全て走りました。おすすめは国道418号の温見峠区間です（初心者の方にはおすすめできないので、ドライブ慣れした上でしっかり準備して行ってくださいね！） ニフティでは新卒の学生さん向けに毎年夏のインターンシップを開催しています。 ブログ執筆中の6月下旬時点ではインターンシップコンテンツの企画や準備などを進めていまして、今決まっている内容の詳細をお伝えします！ 今年のインターンシップテーマは「自由研究」 新卒採用担当として、学生さんとお話しをする機会が多くあるのですが、皆さん様々悩みながら就職活動を進めていると感じます。 「IT業界に興味はあるけど、どんな仕事が自分に合うか分からない」 「エンジニアのリアルを知りたいけど、機会がない」 「自分の可能性を知りたい！」 学生さんが各々で抱えられている悩みが違う中、一つの答えのようなものを提示するのはできないのではないか。であれば、一人ひとりがインターンシップのカリキュラムを通じて、自由にキャリアを考えることができたら良さそう…！ そんな考えから「自由研究」をテーマに設定し、インターンシップの企画を進めています。 チーム開発5daysコース～企画からみっちり！アイデアソン×開発で自社サービスの実装研究！～ このコースの特徴は「エンジニアに必要なビジネス視点」を体感できること！5日間のうち1日目は各種データをもとに、当社のビジネス上の課題の解決や、顧客体験を向上できるようなWebサイトやツールなどをチームで考えていただきます！ その上で残りの4日間はチーム開発（スクラム）に取り組み、自社サービスをより発展させられる開発・実装に取り組みます。 技術力を活かしてビジネスの発展に繋げていく視点を身に着けられるインターンシップは珍しいのではないでしょうか。エンジニアとしてプロダクトや会社の成長に貢献したい方、ぜひ体感ください！ コース概要 ・日程: 2025年8月4日（月）〜8月8日（金） ・形式: 対面開催 ・場所: 東京都新宿区（ニフティ本社） ・対象: 2027年に卒業予定の大学院、大学、専門学校、高等専門学校生の方（学部・学科不問） ・交通費・宿泊費：支給（条件・上限あり） おすすめポイント ①エンジニアに必要なビジネス視点を体感できる！ ②チーム開発手法「スクラム開発」を経験できる！ ③メンターが1チームに1人つく！ ④多くの社員と会えるので会社の雰囲気を知ることができる！ 参加して身に着けられる力 ビジネス視点 ：技術がどのようにビジネスに貢献するのかを肌で感じ、エンジニアとしてのキャリアパスをより明確にできます 実践的な開発スキル ：スクラム開発を通じて、実際のビジネス課題を解決するWebサービスの開発・実装スキルを習得できます 企画力・提案力 ：データ分析に基づいた課題発見から、具体的な解決策を企画・提案する力を養えます 昨年参加者の感想 「ビジネス目線を持ち合わせたエンジニアとして働く面白さを体感出来た」 「チーム開発のやりがい、楽しさが想像以上だった」 「報告、連絡、相談をスムーズ出来るチームは強いということを知った」 「5日間を通じて、自分の適性ややりたいことの解像度がとても上がりました」 「5日間、特に3日目以降にもなると社員のエンジニアの方とフランクで自然な会話を通じて本当の雰囲気を知ることができたように思う」 参考記事 昨年の参加者の方がQiitaに記事を投稿しています。 事前に学習したことで役立ったことなど、参加した方ならではの感想も率直に記載いただいておりますので、ぜひご一読ください。 https://qiita.com/takutosan/items/dfa2745cd0b48badf75c Webサービス運用体験2days&1dayコース～Webサービスの安定稼働を守れ！トラブルの原因究明と再発防止策の調査改善研究！～ このコースでは、Webサービスの裏側であるバックエンドの運用に焦点を当てます。あるWebサービスの担当者であるあなたは、ある”トラブル”に直面します。ログ解析などを通じた原因究明や再発防止策の検討を通じて、サービスの安定稼働を支えるエンジニアの役割を体験します。 ITエンジニアと聞くと「プログラミング」や「開発」をイメージする方にこそ、バックエンドやインフラの仕事の面白さを知ってもらえるコースです！ コース概要 日程: ・2025年7月28日（月）～7月29日（火）※対面実施 ・2025年8月21日（木）～8月22日（金）※対面実施 ・2025年9月11日（木）※オンライン実施 形式: 対面実施/オンライン実施 場所：東京都新宿区（ニフティ本社）/　Zoom 対象: 大学、大学院、専門学校、高等専門学校生の方（学年・学部・学科不問） 交通費・宿泊費：支給（条件・上限あり） おすすめポイント ①充実の講義で知識や経験に自信のない方でも安心！ ②トラブルの原因究明を謎解きのように楽しく体感できる！ ③「プログラミング」以外のエンジニアリングを知ることができる！ ④メンターが1チームに1人つく！ 参加して身に着けられる力 問題解決能力 ：実際のサービス運用におけるトラブルシューティングを通じて、論理的思考力と問題解決能力を向上できます インフラ・バックエンドの知識 ：Webサービスの安定稼働を支えるバックエンドやインフラの仕組みや活用方法について実践的に学べます ITエンジニアの多様なキャリアパス ：開発だけでなく、サービスを支えるエンジニアの重要性と面白さを体感し、自身のキャリアの選択肢を広げられます 昨年参加者の感想 「大学の講義で習うwebシステムの各要素に対して、システム全体の構成を俯瞰的に捉える力を身につけることができました」 「ネットワーク関係の仕事が、集合的で協調的な問題解決の営みであると気が付くことができた」 「ログの大切さと、障害発生時の対応フローについて学べた」 「ワーク中にメンターの若手社員がついてくれるので、濃いコミュニケーションが取れた」 共通事項 応募について 応募締切： マイページ からご確認ください 応募方法： マイページ からご応募できます。先行は書類選考のみです 参加コース：お一人につき1コースのみ参加可能です。応募は複数コース可能です 参加者特典：早期選考のご案内があります その他のインターンシップ・仕事体験プログラム： 上記2コースの他にも、ニフティではサービス企画3daysコース、企画・営業を体験できるビジネス1dayコースも提供しています。 皆様からの積極的なご応募をお待ちしております。 メンターについて メンターの役割：インターンシップではメンター（若手社員を中心とした現役エンジニア）が各チーム専属でつきます。ワークの不明点や技術的などの困ったことはすぐに相談できる環境です。他にも就職活動についてなど様々なこともフランクに聞くことができます。 関連情報: ニフティ株式会社採用サイト-インターンシップ ニフティ株式会社 インターンシップ情報（マイナビ2027）

AWS管理者をしている石川です。 AIで作業を省力化してAWS運用を効率化できたので、LTで事例を紹介してきました。 Engineering Productivity Meetup #4 in 東京 – connpass AWS IAM Identity Center(IIC) IssueOps AWSセキュリティチェックリスト＆熟成度モデルの作成 AIで加速するAWS運用効率化 〜IAM Identity Center IssueOpsとセキュリティ基準自動作成〜 面倒で後回しにしていたようなタスクでも、「試しにやってみよう」と思えるほど心理的ハードルが下がるのは、AIエージェントのとても良い効果ですね。 AIエージェントについて 今回AIについては、GitHub CopilotとDevinを利用しました。 Copilot EnterpriseとDevinについては、検証も兼ねての利用でしたが、想定以上にうまく活用でき、良い利用ケースになったと感じています。 体験としては、GitHub Coding AgentはDevinやClaude Code Actionと大きな差はない印象です。ただそれぞれに機能差や個性はあります。 懇親会でお話ししたCoding Agentについて、検証して気になった点をおまけとしてメモしておきます。 ※いずれも本日（2025年6月23日）時点での情報です。 Coding Agentで使用されるモデルは指定できない Usage ReportでもModelが「Coding Agent」と表示される 以前は利用モデルが表示されていたはずだがわからなくなった 消費したPremium RequestはSessionから確認可能 小さい修正やサンプル作成を頼んだときは 1Session 40Request ほど使われた リクエスト数については instructionファイルやプロンプトで大きく変わると思います 既存のPRにはアサインできない Coding Agentが作成したPRのスレッド内でのみメンションに反応する コメントで追加依頼をしても、作業中のSessionが終わるまで対応はされない

こんにちは。サービスシステムグループの伊達です。 今回はenvsubstについてご紹介したいと思います。 envsubstって 環境変数の値で$hoge ${hoge} を置換する機能を持っているため、テキストの設定ファイルやシェルスクリプトの簡易テンプレートエンジンとして使われることが多いコマンドです。 が、 yum install gettextでインストールすることから分かるように元々gettextというツールの一部です。 gettextとは GNUのM17N（Multilingualization; 多言語化）のためのツールキットです。 ja.poやja.moのようなファイル名を見たことはありませんでしょうか。これがgettextの日本語用の言語ファイルです。 gettextを使うとプログラム中の文字列を多言語化できます。 gettextの使用例 例えば以下のような文字列を出力するプログラムがあるとします。英語話者以外には意味のないプログラムです。 puts("hello world") これをgettextを使って多言語化するにはこうします（gettextのライブラリはロードしておくとする）。 puts(_("hello world")) gettext一般では _() という関数が定義され、多言語化したい文字列をラップします。 ソースコードに _() をつける xgettextコマンドでソースから対象の文字列を抽出する → .pot ファイルができる .potは翻訳用ファイルのテンプレートです msgid "hello world" msgstr "" msginitコマンドで各言語用のpoファイルを作る 日本語だとja.po msgid "hello world" msgstr "" ja.poに翻訳文を書き込む msgid "hello world" msgstr "こんにちは世界" msgfmtコマンドでバイナリ化する → ja.mo ファイルができる プログラム実行時にgettextがロケールに合わせた.moを読み込んで多言語化してくれる イメージです puts(_("hello world")) $ LANG="C" ruby hoge.rb hello world $ LANG="ja_JP.UTF-8" ruby hoge.rb こんにちは世界 再びenvsubst envsubstの本来の使い方はシェルスクリプト用のgettextのコマンドの一部です。 詳しくは以下を読んでください。 envsubstの本来の使い方はシェルスクリプト用のテンプレートエンジンではない – Qiita 簡易テンプレートエンジンとしてのenvsubst ユースケース Dockerfileをビルドしたい環境に合わせてCIのときに書き換えたい 要件上EC2インスタンスしか使えないシステムで一つだけ短いスクリプトを実行せざるを得なく、APIのパスワードは直接書きたくないし、環境ごとに値を変えたい 後者の実例として、私の担当プロダクトではシェルスクリプト中のID、PASSを書き換えたいのでenvsubstをGitHub Actionsのワークフローで使っています。 まとめ envsubstは本来gettextの一部として開発されたツールですが、環境変数による置換機能の便利さから簡易テンプレートエンジンとして広く使われるようになりました。 用途に応じて適切に使い分けることで、設定ファイルの管理やCI/CDパイプラインでの動的な値の置換など、様々な場面で活用できる便利なツールです。 知っておくと、いざという時に役立つかもしれません。

はじめに こんにちは。ニフティの山田です。 2024年の9月にS3のライフサイクルルールを決めるリソースであるaws_s3_bucket_lifecycle_configurationに変更が入り、予期しないchangedやwarningが出るようになりました。 今回は、その解説と対処法について説明します。 影響範囲 transition_default_minimum_object_size Terraform AWS Provider 5.70.0以降 2024/10/4 Terraform AWS Provider 5.86.1以降 2025/2/11 の2段階 filter Terraform AWS Provider 5.88.0以降 2025/2/21 5.86.0以降でも影響あるかもしれません 内容 transition_default_minimum_object_size AWSのドキュメントに記載されている変更に対処するものとなります。 https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#lifecycle-configuration-constraints 従来はS3 → S3 Gracierへのオブジェクト移行はすべてのオブジェクトに対して行われていましたが、Gracierは 128KB単位での課金 となるため、128KB未満のオブジェクトを移行してしまうとコスト増になってしまっていました。 そこでAWS側に設定が追加され、 APIを叩くときに x-amz-transition-default-minimum-object-size ヘッダで最小移行サイズを設定できるようになる この値のデフォルトが128KBとなる つまり128KB未満のオブジェクトはデフォルトで移行されなくなる この挙動は2024/9月以降有効となる という変更が入りました。 これをTerraformで設定する項目が transition_default_minimum_object_size ですが、Terraform AWS Providerのバージョンでデフォルト値が異なります。 5.70.0 ~ 5.86.0 この時点では varies_by_storage_class (従来挙動)がデフォルト値でした。 AWS側のデフォルト値は all_storage_classes_128K なので、この間のバージョンを適用すると初回は必ずchangedとなります。 ~ transition_default_minimum_object_size = "all_storage_classes_128K" -> "varies_by_storage_class" 5.86.1 ~ これ以降は all_storage_classes_128K となり、AWSの挙動に揃うことになりました。 5.70.0 ~ 5.86.0で一度もapplyしていない場合はchangedが出ませんが、使用している場合はchangedが出ることになります。 ~ transition_default_minimum_object_size = "varies_by_storage_class" -> "all_storage_classes_128K" 対応方法 Terraform AWS Provider 5.86.1以降に上げる デフォルト値 all_storage_classes_128K に従う 基本的にAWS側のデフォルト挙動に従うべき項目なので、5.86.1以降の挙動で揃えるべきだと考えます。 5.70.0 ~ 5.86.0でapplyしてしまっていた場合は差分をapplyしてデフォルト挙動に戻しておきます。 filterを指定しない場合の設定 filterはライフサイクルルールの適用対象を特定パスなどに制限するための設定です。 filter { prefix = "logs/" } Terraform AWS Provider 5.86.0 ~ 5.88.0で行われた変更により、本来は誤った設定でもTerraform AWS Provider側で吸収していましたが、この挙動をdeprecatedにしてシンプル化することになりました。 filterの設定は言及されていませんでしたが、変更に巻き込まれており、filterを設定しない挙動がどうやってもwarningになるという状態になっていました。 紆余曲折あり5.99.0でようやく挙動が確定し、 filterブロックの省略は不可 filterを何も設定しない場合、空ブロックで指定する filter {} が正しいということになりました。 対応方法 Terraform AWS Provider 5.99.0以降に上げる filterを設定しないルールがある場合 filterを記述していない: filter {} を追加 filter {}を記述している: そのまま filterブロックを追加した場合については、5.86.0~5.98.0までで一度applyしている場合には差分となることがあります。applyしてもAWS上の設定値には変化はありません。 + filter { # (1 unchanged attribute hidden) } おわりに aws_s3_bucket_lifecycle_configurationの仕様変更について解説しました。 参考になれば幸いです。

こんにちは。ニフティ株式会社の島田です。 AppleのContainerizationフレームワークが6月10日に発表されましたが、この記事ではlima-vm + docker-cliで脱Docker Desktopをしてみました。 これは何？ limaでdockerを使おう https://lima-vm.io/ https://github.com/lima-vm/lima limaで Apple Virtualization framework + rosetta2 を使って低負荷高速にx86_64イメージを実行しよう https://developer.apple.com/documentation/virtualization https://developer.apple.com/documentation/virtualization/running-intel-binaries-in-linux-vms-with-rosetta limaで実行したdocker engineを使ってvscode devcontainerを起動しよう lima-vmとは Lima は自動的なファイル共有とポートフォワード機能つきでLinux仮想マシンを起動します(WSL2と同様)。 Limaは、Macユーザへ nerdctl (contaiNERD ctl) を含む containerd を普及させることを当初の最終目標に据えていました。しかし、Limaではコンテナ化されていないアプリケーションも実行することができます。 Limaは他のコンテナエンジン(Docker, Podman, Kubernetes 等)やmacOS以外のホスト(Linux, NetBSD 等)での動作もサポートしています。 https://github.com/lima-vm/lima/blob/v0.23.2/README.ja.md 現在は CNCF Sandbox プロジェクトとして管理されています。OSS(Apache 2.0) lima-vmは以下のようなプロジェクトにも採用されています。 Rancher Desktop Colima Finch Podman Desktop limaでvmを起動する limaのインストール https://formulae.brew.sh/formula/lima https://lima-vm.io/docs/installation/ brew instal lima vmを起動 https://lima-vm.io/docs/usage/ limactl start test vmにアタッチ limactl shell test vmを停止 limactl stop test vmを削除 limactl rm test limaでdocker engineを動かす docker desktopをアンインストールする https://docs.docker.com/desktop/uninstall/ /Applications/Docker.app/Contents/MacOS/uninstall docker desktopが作ったファイルを削除する rm -rf ~/Library/Group\ Containers/group.com.docker rm -rf ~/Library/Containers/com.docker.docker rm -rf ~/.docker 権限が足りないと言われる場合 設定> プライバシーとセキュリティ> フルディスクアクセス> ターミナルをオン 必要に応じてsudoを付けて実行 docker-cliをインストールする https://formulae.brew.sh/formula/docker brew install docker limaでvmを作成、docker engine(rootful)を起動する テンプレートから起動する場合、vmの名前がテンプレートのファイル名になる limactl create template://docker-rootful --vm-type=vz --rosetta --cpus=8 --memory=16 --mount-writable=書き込み可能にしたいパス(vscodeプロジェクトを配置してるパスとか) https://github.com/lima-vm/lima/blob/master/templates/docker-rootful.yaml rootlessでいい場合は以下のテンプレートを使う limactl create template://docker --vm-type=vz --rosetta --cpus=8 --memory=16 --mount-writable=書き込み可能にしたいパス(vscodeプロジェクトを配置してるパスとか) https://github.com/lima-vm/lima/blob/master/templates/docker.yaml 起動後に出力されるdocker contextを登録して切り替える docker context create lima-rootful --docker "host=unix:///Users/`whoami`/.lima/docker-rootful/sock/docker.sock" docker context use lima-docker-rootful rootlessの場合 docker context create lima-rootful --docker "host=unix:///Users/`whoami`/.lima/docker-rootful/sock/docker.sock" docker context use lima-docker-rootful docker engineとdocker cliが通信できることを確認する docker version 出力例 brew % docker version Client: Docker Engine - Community Version: 27.3.1 API version: 1.47 Go version: go1.23.1 Git commit: ce1223035a Built: Fri Sep 20 11:01:47 2024 OS/Arch: darwin/arm64 Context: lima-rootful Server: Docker Engine - Community Engine: Version: 27.3.1 API version: 1.47 (minimum version 1.24) Go version: go1.22.7 Git commit: 41ca978 Built: Fri Sep 20 11:41:54 2024 OS/Arch: linux/arm64 Experimental: false containerd: Version: 1.7.22 GitCommit: 7f7fdf5fed64eb6a7caf99b3e12efcf9d60e311c runc: Version: 1.1.14 GitCommit: v1.1.14-0-g2c9f560 docker-init: Version: 0.19.0 GitCommit: de40ad0 lima+dockerでdevcontainerを起動する compose、buildx拡張をダウンロードしてdocker-cliから使えるようにする https://formulae.brew.sh/formula/docker-compose https://formulae.brew.sh/formula/docker-buildx brew install docker-compose brew install docker-buildx mkdir -p ~/.docker/cli-plugins ln -s /opt/homebrew/bin/docker-compose ~/.docker/cli-plugins/. ln -s /opt/homebrew/bin/docker-buildx ~/.docker/cli-plugins/. docker compose version docker buildx version vscode(devcontainer)はdocker contextを使ってくれない 選択肢1: /var/run/docker.sock にシンボリックリンクを作成する vmが停止したタイミングでdocker.sockが消えるので起動するたびに張り直しが必要 sudo ln -s ~/.lima/docker-rootful/sock/docker.sock /var/run/docker.sock 選択肢2: vscodeが見るdocker endpointを変更する(基本こっちがおすすめ) vscodeを開き、 command + , で設定を開く dev.containers.dockerSocketPath で検索 自分のdocker endpoint( ~/.lima/docker-rootful/sock/docker.sock )に変更する その他覚えておくと便利なこと ドキュメントが優秀なので基本そっちを見たほうが分かります vm停止状態で limactl edit するとvmの定義ファイルを開いて編集できる https://lima-vm.io/docs/reference/ vmの設定は ~/.lima 配下にある ./lima/vm-name/lima.yaml に今の設定があるので削除前に保存しておくことができる シャットダウン時vscodeを起動したままだと次回起動後docker hostを認識してくれない vscodeを再起動する 自動採番されるdocker networkのipレンジを変更する 以下を参考に daemon.json を配置するように書き換える rootlessはmodeと配置先を変更する必要がある daemon.json # A template to use Docker (rootful) instead of containerd & nerdctl # $ limactl start ./docker-rootful.yaml # $ limactl shell docker-roootful docker run -it -v $HOME:$HOME --rm alpine # To run `docker` on the host (assumes docker-cli is installed): # $ export DOCKER_HOST=$(limactl list docker-rootful --format 'unix://{{.Dir}}/sock/docker.sock') # $ docker ... # This template requires Lima v0.20.0 or later vmType: "vz" rosetta: # Enable Rosetta for Linux. # Hint: try `softwareupdate --install-rosetta` if Lima gets stuck at `Installing rosetta...` enabled: true # Register rosetta to /proc/sys/fs/binfmt_misc binfmt: true cpus: 8 memory: 16GiB images: # Try to use release-yyyyMMdd image if available. Note that release-yyyyMMdd will be removed after several months. - location: "https://cloud-images.ubuntu.com/releases/24.04/release-20241004/ubuntu-24.04-server-cloudimg-amd64.img" arch: "x86_64" digest: "sha256:fad101d50b06b26590cf30542349f9e9d3041ad7929e3bc3531c81ec27f2c788" - location: "https://cloud-images.ubuntu.com/releases/24.04/release-20241004/ubuntu-24.04-server-cloudimg-arm64.img" arch: "aarch64" digest: "sha256:e380b683b0c497d2a87af8a5dbe94c42eb54548fa976167f307ed8cf3944ec57" # Fallback to the latest release image. # Hint: run `limactl prune` to invalidate the cache - location: "https://cloud-images.ubuntu.com/releases/24.04/release/ubuntu-24.04-server-cloudimg-amd64.img" arch: "x86_64" - location: "https://cloud-images.ubuntu.com/releases/24.04/release/ubuntu-24.04-server-cloudimg-arm64.img" arch: "aarch64" mounts: - location: "~" - location: "/tmp/lima" writable: true # containerd is managed by Docker, not by Lima, so the values are set to false here. containerd: system: false user: false provision: - mode: system script: | #!/bin/sh mkdir -p /etc/docker/ cat <<EOF > /etc/docker/daemon.json { "default-address-pools": [ {"base":"192.168.0.0/16", "size":24} ] } EOF - mode: system # This script defines the host.docker.internal hostname when hostResolver is disabled. # It is also needed for lima 0.8.2 and earlier, which does not support hostResolver.hosts. # Names defined in /etc/hosts inside the VM are not resolved inside containers when # using the hostResolver; use hostResolver.hosts instead (requires lima 0.8.3 or later). script: | #!/bin/sh sed -i 's/host.lima.internal.*/host.lima.internal host.docker.internal/' /etc/hosts - mode: system script: | #!/bin/bash set -eux -o pipefail command -v docker >/dev/null 2>&1 && exit 0 if [ ! -e /etc/systemd/system/docker.socket.d/override.conf ]; then mkdir -p /etc/systemd/system/docker.socket.d # Alternatively we could just add the user to the "docker" group, but that requires restarting the user session cat <<-EOF >/etc/systemd/system/docker.socket.d/override.conf [Socket] SocketUser={{.User}} EOF fi export DEBIAN_FRONTEND=noninteractive curl -fsSL https://get.docker.com | sh probes: - script: | #!/bin/bash set -eux -o pipefail if ! timeout 30s bash -c "until command -v docker >/dev/null 2>&1; do sleep 3; done"; then echo >&2 "docker is not installed yet" exit 1 fi if ! timeout 30s bash -c "until pgrep dockerd; do sleep 3; done"; then echo >&2 "dockerd is not running" exit 1 fi hint: See "/var/log/cloud-init-output.log" in the guest hostResolver: # hostResolver.hosts requires lima 0.8.3 or later. Names defined here will also # resolve inside containers, and not just inside the VM itself. hosts: host.docker.internal: host.lima.internal portForwards: - guestSocket: "/var/run/docker.sock" hostSocket: "{{.Dir}}/sock/docker.sock" message: | To run `docker` on the host (assumes docker-cli is installed), run the following commands: ------ docker context create lima-{{.Name}} --docker "host=unix://{{.Dir}}/sock/docker.sock" docker context use lima-{{.Name}} docker run hello-world ------

はじめに こんにちは！採用ブランディングWGの島です。 今回はニフティのエンジニアの実態を調査するためにアンケートを実施しましたので、その結果を発表します！ 今回は115名のエンジニアに回答いただきました！ 昨年の結果はこちらになります。 ニフティエンジニア徹底分析！〜ニフティのエンジニアにあれこれ聞いてみました〜 基本情報 在籍年数 継続的なエンジニア採用とベテランの存在 分布をみると全体の8割以上が10年未満となっています。これは近年、積極的にエンジニア採用を行なっている結果が現れているのではないかと推測できます。また15年以上のベテランエンジニアも17%存在し、新しい風を吹き込む若手と基盤を支えるベテランがバランスよく在籍しています。 採用形態 新卒採用が多め 新卒採用が約7割を占めており若手エンジニアの育成に力を入れていることが分かります。キャリア採用の割合も前回の29.7%と比べると微増しており、少しずつ増えている様子が伺えます。 技術について 好きなプログラミング言語 Pythonが最多、モダンな技術への関心 Pythonが34.5%で最も多く選ばれています。実際にニフティの業務でもPythonの採用率が高く、親しみもあるのでしょうか。また、Go（10.3%）やTypeScript（11.5%）といったモダンな言語も上位に位置しており、新しい技術への関心が高い傾向が見られます。 業務でよく使うプログラミング言語 業務で利用する言語も好きな言語と同じくPython（28.0%）が最多となっています。続いてbash、ShellScriptとなっておりスクリプト言語の利用率が高い傾向となっています。 業務でよく使うクラウドサービス AWSが圧倒的なシェアを占めています。前回と比較するとMicrosoft Azureが初登場しており、少しずつマルチクラウド化が進んでいる傾向が見られます。 ニフティについて ニフティエンジニアの強み 前回と同じく「優しさ、思いやり」がトップで「チャレンジ精神」も上位をキープしています。「チームワーク」や「コミュニケーション力」が前回よりアップしており、チームワークを重視する傾向にあることが分かります。 ニフティのいいところ こちらも前回と変わらず「人柄、雰囲気の良さ」、「ワークライフバランス」が上位となっており人的環境や働き方が高く評価されていることが分かります。また「内製開発を促進している」、「成長できる環境」も上位にランクインしており、自分たちで開発し成長していきたいという思いが表れています。 またニフティのいいところについてフリーコメントで以下のような意見が挙がりました！ 有給やフレックスを取得しやすい雰囲気 内製開発を促進していることで、フルスタックな技術の習得につながる 内製開発のため社内でスケジュールを調整でき、ワークライフバランスがとりやすい 前向きに仕事に取り組む雰囲気 話を聞いてくれる人が多くて、非常に仕事が進めやすいように思える。time文化も良い 優しい方が多く、困っていることがあるといつも誰かが助けてくれる プライベート 休みの日は何をしていますか？ ゲーム、睡眠とインドアが上位となりました。また「学習/自己研鑽」が続いており向上心の高さを感じました。（私も見習わなければ） 次点で運動やレジャーもランクインしており、インドア・アウトドア問わず様々な趣味を持った人がいることが分かります。ニフティ社内にもボードゲーム部やテニス部、フットサル部など様々なブカツがあり、積極的に活動しています！ こちらもフリーコメントで挙げられた回答を一部ご紹介します。 Udemyで気になる講座を見たり、家で使っている家計簿やセキュリティ、健康管理で使っているシステムの保守・運用などをしています。 個人開発 子どもとお出かけ お絵描き 将棋を指す 業務で利用予定の技術スタックの学習 ツーリング 犬と戯れる おわりに いかがだったでしょうか。ニフティエンジニアの雰囲気が少しでも伝われば幸いです！

※本記事に記載されている内容は、2024年12月時点の情報です。 はじめに こんにちは。ニフティの塚崎です。 今回は、AzureリソースをTerraformで構築する際にtfstateファイルを管理する方法をまとめてみました。 tfstateファイルをリモートで管理する際、AWSではS3 + DynamoDBの構成でバックエンドを構築すると思います。今回はそれのAzure版をやってみました。 Azureでtfstateファイルを管理するにはAzure Blob Storageを利用します。Azure Blob Storageを利用することでファイルの共有とロックができます。 やり方 今回はAzure CLIを使用します。インストール方法は以下を見てください。 https://learn.microsoft.com/ja-jp/cli/azure/install-azure-cli?view=azure-cli-latest  １．Azureログイン Azureにログインします。また、ログイン時にサブスクリプションの選択が求められるので、今回作業するサブスクリプションを指定してください。 az login サブスクリプション情報を確認するコマンド az account list --output table サブスクリプションを変更したい場合は以下を見てください。 https://learn.microsoft.com/ja-jp/cli/azure/account?view=azure-cli-latest#az-account-set ２．ストレージアカウント作成 ストレージアカウントを作成します。注意点として、ストレージアカウント名はグローバルで一意にする必要があります。また、ここではリソースグループは既に作成されていることを想定しています。（リソースグループが無い場合は適宜作成してください） az storage account create -n "ストレージアカウント名" -g "リソースグループ名" --sku Standard_LRS オプション：リソースグループの作成（無い場合） az group create --name "リソースグループ名" --location japaneast 参考 https://learn.microsoft.com/ja-jp/cli/azure/storage/account?view=azure-cli-latest#az-storage-account-create https://learn.microsoft.com/ja-jp/cli/azure/group?view=azure-cli-latest#az-group-create ３．アカウントキー取得 ストレージアカウントのアカウントキーを取得します。コンテナの作成にアカウントキーが必要になるみたいです。 az storage account keys list -g "リソースグループ名" -n "ストレージアカウント名" valueの値がアカウントキー（今回はkey1の方を利用） [ { "creationTime": "2024-12-06T04:10:41.047526+00:00", "keyName": "key1", "permissions": "FULL", "value": "xxx" }, { "creationTime": "2024-12-06T04:10:41.047526+00:00", "keyName": "key2", "permissions": "FULL", "value": "xxx" } ] 参考 https://learn.microsoft.com/ja-jp/cli/azure/storage/account/keys?view=azure-cli-latest#az-storage-account-keys-list ４．ストレージコンテナ作成 ストレージコンテナを作成します。 az storage container create -n "コンテナ名" --account-name "ストレージアカウント名" --account-key "アカウントキー" 参考 https://learn.microsoft.com/ja-jp/cli/azure/storage/container?view=azure-cli-latest#az-storage-container-create ここまでリソースの設定は完了です。 リソース作成 試しに、TerraformでAzure仮想マシンを作成し、tfstateファイルがストレージで管理されているかを確認してみます。 main.tfを作成し、以下の内容でapplyします。 provider "azurerm" { subscription_id = "<サブスクリプションID>" resource_provider_registrations = "none" features {} } terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "4.12.0" } } backend "azurerm" { resource_group_name = "<リソースグループ名>" storage_account_name = "<ストレージアカウント名>" container_name = "<Blobコンテナ名>" key = "terraform.tfstate" } } resource "azurerm_network_interface" "main" { name = "<nic名>" location = "Japan East" resource_group_name = "<リソースグループ名>" ip_configuration { name = "internal" subnet_id = "<サブネットID>" private_ip_address_allocation = "Dynamic" } } resource "azurerm_virtual_machine" "main" { name = "<vm名>" location = "Japan East" resource_group_name = "<リソースグループ名>" network_interface_ids = [azurerm_network_interface.main.id] vm_size = "Standard_DS1_v2" storage_image_reference { publisher = "Canonical" offer = "0001-com-ubuntu-server-jammy" sku = "22_04-lts" version = "latest" } storage_os_disk { name = "myosdisk1" caching = "ReadWrite" create_option = "FromImage" managed_disk_type = "Standard_LRS" } os_profile { computer_name = "hostname" admin_username = "testadmin" admin_password = "Password1234!" } os_profile_linux_config { disable_password_authentication = false } tags = { environment = "staging" } } 仮想マシンが作成されました。コンテナにもtfstateファイルが置いてあるので問題なさそうです。 おわりに 今回は、Azure Blob StorageでTerraformのtfstateファイルをリモート管理する方法について解説しました。 Azure環境でTerraformを活用される際の参考になれば幸いです。

こんにちは、エンジニアリングマネージャーの芦川です。 このたび、 InnerSource Commons Foundation 2025年メンバー として活動を開始しました！ グローバルコミュニティの一員として貢献できることを大変光栄に思っています。 （ホントに英語のスピーキング・リスニングに危機感を感じています。どなたか助けてください。） この記事では、InnerSource Commonsが掲げる2025年のテーマ「 RISE 」を紹介するとともに、私たちニフティ株式会社でのInnerSourceの取り組みについて改めて簡単にご紹介します。 InnerSourceとは？ InnerSourceは、 オープンソースの手法と文化を企業内で活用する アプローチです。 部門やチームを越えた知識の共有・コラボレーションを促進することで、 再発明の削減・技術資産の活用・開発文化の活性化 を実現します。 InnerSource Commonsの2025年テーマ「RISE」 InnerSource Commonsは、世界中の組織でInnerSourceを実践・促進する非営利コミュニティです。2025年は次の4つの柱「 RISE 」を重点テーマとしています。（次に紹介する、それぞれのキーワードの頭文字です。） https://innersourcecommons.org/about/ Reach：より多くの地域・業界へ InnerSource Commonsは、InnerSourceをより幅広く展開するため、日本や中国、ブラジル、アフリカといった新しい地域への普及が進んでいます。 私たちニフティも、こうした動きに共鳴し、 日本でのInnerSource事例の1つとして貢献できるよう活動しています。 ここでお知らせがあります。InnerSource Commons Japanの活動として、meetupを不定期に開催しております。ぜひ、 InnerSource Commons: エンジニアの組織内コラボレーションを加速する のconnpassグループにメンバー登録をして日本のInnerSource最新情報を見逃さないようにしましょう！（直近では、 【OST】チームの壁、ぶっ壊そ！壁の乗り越え方、一緒に考えよう！ をオフライン開催します。） もちろん、 ニフティ株式会社 のconnpassグループ登録も忘れずに！ Implement：導入と実践の道筋を整える InnerSource Commonsは、業界におけるInnerSourceに関する具体的な課題や混乱について、より詳細で質の高いドキュメントを公開します。この取り組みでは、大まかなガイドや指示書にとどまらず、InnerSourceが実際の状況でどのように機能するかを具体的に説明します。 ニフティにおいては2022年にInnerSourceの概念に出会い、パターンブックをもとに実験プロジェクトを開始しました。現在は20以上のリポジトリでInnerSourceを実践し、 開発部門だけでなく、ビジネス部門との業務フローなどにも活用の幅が広がっています。 チーム構造に合わせた導入効果の検証（チームトポロジーに基づく分析） ガイドライン整備と社内ポータルの構築 「コントリビュートお試し会」の開催による文化の育成 これらの取り組みを通じて、 「始めたいが、どう進めればよいか分からない」企業への道しるべ となる知見を蓄積しています。 最近では、 InnerSource Commons創設者 Danese Cooper氏 来日記念 Meetup で、これまでのニフティのインナーソース活動とナレッジをまとめた発表をさせていただきました。簡単ではありますが、こちらにまとめてありますのでよかったら見てください。 Summit：世界中で知見を共有する RISEの「Summit」は、InnerSource Commonsが主催する 国際的なサミットを通じたナレッジの共有と連携の強化 を意味します。2025年には 横浜、ベルリン、ニューヨーク での開催が予定されています。 こうした場では、企業や文化の違いを越えて、実践者同士が課題や成功事例を共有し、InnerSourceの進化をともに支えていきます。 私も国内イベントでの登壇を通じて、 日本企業の経験を世界と共有する重要性 を実感しました。今後は、サミットやコミュニティを通じて、 日本の声を国際的な場へ届ける役割 も担っていければと考えています。日本ならではの伝え方（漫画とか？）、というのもあるんじゃないかと思い探っている最中です。（が、なかなかAIで漫画の画像生成がうまくいかず、どなたか教えて下さい。。） Establish：信頼と継続の土台を築く 「Establish」は、InnerSource Commonsが 中立で信頼される情報ハブ であり続けるための基盤づくりを指します。 ブランドガイドラインや出版物の整備を通じて、 誰もが安心して参照・参加できるグローバルナレッジの場 を目指しています。 今後に向けて ニフティでは、InnerSource活動が徐々に組織内に根づきつつあります。 現在注力しているのは以下のような課題です： 社内全リポジトリの可視化と状態把握（活発／停止など） ソースコードに限らず、 ドキュメント・スライドといった「情報資産」もInnerSource化 仮想チームで結成された開発物のInnerSource化 InnerSourceは単なる開発プロセスではなく、 企業文化と技術をつなぐ橋 です。今後も、実践を通じて得た知見をコミュニティに還元し、よりよいコラボレーションの未来をつくっていきたいと思います。特に今年のテーマ「RISE」に見られたように「日本」ということをもっと意識すると「日本ならではの課題や解決方法」が見えてくるような気がしています。

自分が楽しいと思えるやり方、より成長できる方法を選べる みなさんが感じるニフティの強み、良さを教えてください。 S.Sさん ニフティの強みは自社でプロダクトを持っていること。なおかつ、それを内製で開発しているところだと思います。また、「いい人」が多いことも魅力ですね。部署が変わった時も周囲が積極的に声をかけてくれたので、すぐに馴染めました。 S.Nさん 事業面の強みは、やはりISP（インターネット接続サービス事業者）の事業の安定性です。ある意味、現状維持でも安泰なのかもしれませんが、さらに製品をブラッシュアップしてより良いものにしていこうという意識が会社全体に浸透していると思います。社内のSlackでも、毎日のように製品にまつわる様々な意見やアイデアが飛び交っていますから。 また、物事を建設的に考える文化がある会社だと思います。たとえばミスが起きた時にその人自身を咎めるのではなく、原因に着目して再発防止策を立てようといった考え方が当たり前に根付いている。私自身もこれまで何度も失敗してきましたが、怒られた記憶はほぼありません。S.Sさんが「いい人が多い」と感じているのは、そうした企業文化の影響も大きいのではないかと。 会社の制度や働きやすさという点ではいかがでしょうか？ S.Sさん 入社1年目の新人研修 は、特に役立ちました。技術についてだけでなく ニフティの開発の特徴 についてもしっかり学べて、早い段階で戦力になれるのは魅力ですね。 書籍購入費用の助成 やUdemyを利用した自己学習など、成長をサポートしてくれる福利厚生も用意されています。 働きやすさ に関しては、定時で上がれることも多いですし、1年目からでも有給休暇を20日間取得できるなど、ワーク・ライフ・バランスに配慮されていると思います。 S.Nさん もちろん繁忙期は残業が多くなることもありますが、休暇制度も充実しているためハードワークという感覚はありません。有給休暇以外の特別休暇も充実していて、たとえば私は結婚した時に特別休暇とリフレッシュ休暇（最低満10年の勤続年数から付与される休暇）を組み合わせ、10日間の休みを取って新婚旅行に行きました。 R.Aさんはニフティ勤続20年ですが、新卒から長く会社に居続ける理由を教えてください。 R.Aさん 「自分がやりたいようにやれる」というのが、最も大きいですね。達成しなければいけないゴールがあったとしても、そこに向かうプロセスは全て自分で考えることができる。自分が楽しいと思えるやり方、より成長できる方法を選べるのはニフティならではだと思います。たとえば、企画側から「こういうものをリリースしたい」という依頼があったときに、開発するシステムや使用するプログラミング言語の制限なく、エンジニアが自由に考えられます。また、手段だけでなく、逆にエンジニアから企画側への提案もしやすい風土がありますね。 おそらく自社サービスを手掛けていることも、自分たちで考えてつくれる自由度につながっているのだと思います。「どうすればユーザーさんが喜ぶのか」というところから逆算して、エンジニア同士で話し合ってより良い方法を考えられるのが、ニフティの開発の特徴です。 専門性を活かして会社に貢献する「N1！」制度とは？ S.Nさんはニフティの「N1!」制度を利用され、「IDアーキテクト」として活動しています。 ＜N1！制度とは＞ 「NIFTY No.1」の略。特定の分野で突出した知識とスキルを持って活躍している社員を「N1!」として任命する制度。任命された社員は1年間の任期中の活動目標を立て、その分野において高い専門性を発揮できるよう、担当業務の改善、社内における専門分野・技術の伝承と浸透、社外活動への参加などを通じて各自の専門性をさらに磨いていく。 IDアーキテクトの活動内容と、S.Nさんが「N1!」に任命された経緯を教えてください 。 S.Nさん 簡単に言うと、現在のシステムにとらわれない、新しい顧客管理システムのあり方などを検討・検証する活動です。任命の経緯ですが、私の場合は自ら立候補しました。理由としては、私は入社以来、ずっとID周りの仕事に従事してきました。会社の屋台骨を担ってきた自負がある一方で、どうしても私たちの仕事は、新しいサービスをつくった人に比べて注目されづらい側面があると感じていたんです。もっと、社内の基幹システムを扱うエンジニアにフォーカスが当たり、頑張ろうと思えるような環境をつくりたい。そのために、ID目線から会社を変えることを目指して「N1!」のIDアーキテクトになろうと考えました。もちろん会社を変えるだけではなく、自分自身のステップアップにつなげたいという思いもあります。 「N1!」として、具体的にどのような活動をされていますか？ S.Nさん メインの取り組みは、現在ニフティ全社で取り組んでいる「会員基盤刷新プロジェクト」（ 前編記事 を参照）です。2027年度中に、ニフティの基幹システムの抜本的なリニューアルを行うことを目指しています。 このプロジェクトに関わるまでは、自分が担当する範囲のことしか見えていませんでした。しかし、今回のように社内の全サービスに関わるシステムを構築するとなると、本当にあらゆることを考慮しなくてはいけません。部署によって求めるものもまるで異なり、自分が理想とするシステムとのギャップを埋める必要も出てきます。こうした経験が、自分の成長につながっていると感じます。 S.Nさんは自ら「N1!」に立候補されたということですが、他薦のケースもあるのでしょうか？ S.Nさん そうですね。周囲からの後押しによって、任命されるケースもあります。ただ、どの分野で「No.1」を名乗るかは、本人が決める形ですね。自分が得意なことで会社に貢献したり、伸ばしたい分野を伸ばしていけるような制度だと思います。 最終目標は「全ての人がニフティのIDを持つ世界」 最後に、みなさんの今後の目標やキャリアの展望についてお聞きします。それぞれ、目指している方向性を教えてください。 S.Sさん 自分は技術が好きで、特に、自動化や効率化を進めるというところに楽しさを感じています。基本的には、引き続きエンジニアとしての技術を磨いてキャリアを積み重ねていきたいです。あとはR.Aさんもおっしゃっていましたが、「自分がやりたいようにやれる」のがニフティの良さだと思いますので、自分らしく色んなことにチャレンジしたいですね。 R.Aさん S.Sさんが色んなことにチャレンジしたいと言ってくれましたが、私自身も20代の頃から「雑食」のように、あらゆることを経験してきました。そういう意味では、現在のエンジニアリングマネージャーというポジションは、技術に関する意思決定、マーケティング、チームビルディング、さらには採用活動など、業務内容が本当に多岐にわたるため、自分にとてもフィットしていると思います。 そのなかで、今後は採用活動を強化していきたいと考えています。特に、20代30代の若いエンジニアにニフティのことをもっと知ってもらい、転職の際の選択肢の一つとして挙げてもらえるようにしていきたいですね。 S.Nさん まずは「N1!」のIDアーキテクトとしての活動、会員基盤刷新プロジェクトを通して、これらのシステムに関わるエンジニアのポジションを高めていきたいと思います。 また、現在の業務を通じて最終的に目指しているのは、「全ての人がニフティのIDを持っている状態」です。現在の会員基盤は@niftyの会員の方だけにご利用いただくシステムになっていますが、これをたとえばGoogleやAmazonのように、ニフティのIDを使ってさまざまなサービスを利用できる形にしていきたい。ISPだけでなく、ニフティが多くの人の生活に欠かせない存在になる。そんな世界を目指したいですね。 前編もご覧ください！ 今回はニフティの会員基盤刷新プロジェクトチームのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】全サービスに関わる基幹システムを大幅リニューアル。3年がかりの一大プロジェクトに挑むメンバーたちの奮闘【会員基盤刷新プロジェクト前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

こんにちは！ニフティ株式会社の坂内です。 2025年6月1日（日）に開催された技術のお祭り「 技術書典18 」に、私たちニフティもサークルとして出展し、多くの方々と技術の楽しさを共有させていただきました。 本記事では、当日のブースの様子や会場の熱気、そして私たちが届けた手作りの技術同人誌についてレポートします！ NIFTY Tech Book #2 はこちらからご覧いただけます。 私たちの参加目的について ニフティには魅力的なエンジニアが沢山在籍しており、日々ユニークで面白い技術的な取り組みや研究を行っていることを、社外の皆様にもっと広く知っていただきたいという想いがありました。普段はサービス開発の裏側で活躍している彼らの情熱や個性を、技術同人誌という形でお届けしたいと考えました。 そして、技術コミュニティとの交流を深め、エンジニア同士が刺激し合えるような繋がりを広げていきたいという目的も持っていました。技術書典は、そうした出会いや学びの場として最高の機会だと感じています。 「NIFTY Tech Book #2」300部以上が皆様のお手元へ！ 今回の技術書典18で、私たちニフティは弊社社員が業務や趣味で培った知識や経験、探求したいテーマについて、有志で自由に執筆した技術同人誌を頒布しました。表紙や裏表紙、挿絵に至るまで、社員自身が手がけたこだわりの詰まった本となりました。 本日、技術書典18「さ17」ブースにてニフティのエンジニア有志が執筆した技術書「NIFTY Tech Book#2」を無料頒布いたします！数に限りがございますのでお早めにお越しください。お待ちしております！ #技術書典 #技術書典18 #nifty_dev pic.twitter.com/3pUb2kJIRB — NIFTY Developers (@NIFTYDevelopers) June 1, 2025 当日は、本当に多くの方に足を運んでいただき、用意した物理本200部がイベント終了を待たずして全てなくなりました！オンラインデータ版を合わせると350冊以上にのぼります。 手に取ってくださった皆様、そして温かい声をかけてくださった皆様、誠にありがとうございました。 戦利品から得た学び ここでは、技術書典に参加する中で筆者が特に心惹かれた戦利品について語らせていただきます。それは、mochikoAsTechさんの「 届ける工夫 ～欲しい誰かに見つけてもらえる60の方法～ 」という本です。 私たちも今回、自分たちの活動や成果を「どうすればもっと多くの人に知ってもらえるだろうか」「届けたい人にしっかり届けるためにはどんな工夫が必要だろうか」と考えながら参加していました。そんな中で出会ったこの本は、まさにタイムリーな一冊で、具体的なノウハウや考え方が詰まっており、大変参考になりました！ 特に、書籍の第2章で紹介されていた「タイトルで対象読者層を狭めすぎない」という視点には、強く共感し、ハッとさせられるものがありました。 私たちが今回頒布した「NIFTY Tech Book #2」も、技術書という体裁ではありますが、社員それぞれの興味や個性が反映されたバラエティ豊かな、いわばカジュアルな内容も多く含んでいます。そのため、今後の情報発信においては、タイトルや紹介文で無意識に間口を狭めてしまわないよう、より多くの方に気軽に手に取っていただけるような敷居を下げる工夫も大切だと改めて感じました。 今後の展望 今回の技術書典18への参加は、私たちにとって、技術の面白さや奥深さを再認識し、多くの刺激を受ける貴重な機会となりました。直接読者の皆様と交流できたこと、他の出展者の方々の熱意に触れたことは、今後の活動の大きな励みになります。 この経験を活かし、ニフティはこれからも、社員一人ひとりの「好き」や「探求心」を大切にしながら、より良いサービスや技術を社会に提供できるよう努めてまいります。 おわりに 技術書典18にご来場いただいた皆様、サークル参加の機会をくださった運営スタッフの皆様、そして素晴らしい技術や知識を共有してくださった全ての出展者の皆様に、心より感謝申し上げます。 ニフティは、今後もブログや各種イベント登壇などを通じて、積極的に技術情報を発信していきます。私たちの活動にご興味をお持ちいただけましたら、ぜひ公式X（旧Twitter）アカウント（ @NIFTYDevelopers ）のフォローもお願いいたします。 今後も、皆様に楽しんでいただけるような「良いもの」を届けて参りますので、どうぞご期待ください！ div.hiring-box, a[href="https://recruit.nifty.co.jp/career_top"] img[alt="recruit"] { display: none; }