ニフティ株式会社は、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; }

はじめに こんにちは、ニフティの添野 隼矢です。 今回は、驚くべき出来事をご紹介します。なんと、クリエイティブ職の方※が直接コンテナ環境でデザインを修正し、GitHubでPRをあげてくださったのです！この画期的な出来事の舞台裏に迫ります。 ※クリエイティブ職の詳細については、こちらをご覧ください。 https://recruit.nifty.co.jp/career_top/ 経緯:施策スピードアップへのチャレンジ とあるサービスの施策で、画面にバナーを追加する作業がありました。 従来の課題 通常のフローでは、以下のような流れになります： 1. クリエイティブ職の方がデザイン要件を整理 2. 開発担当とのデザイン調整（複数回のやりとり） 3. 実装・レビュー・デプロイ このデザインやりとりで時間がかかってしまい、施策開始が遅れてしまうことが課題でした。 今回の経緯 そこでクリエイティブ職の方から「デザイン修正を自分たちでやってみる」という提案をいただきました。 既存の開発環境が生んだ偶然 もともと整備していた環境 私たちは自身の開発効率向上のために、以下のローカル開発環境を構築していました。 フロントエンド SvelteKit 開発環境 DevContainerで統一 品質管理 linter/formatter自動適用 コンテナ管理 Rancher Desktopを採用 これらの環境が、予想外にも「クリエイティブ職の方でも触りやすい」環境になっていました。 SvelteKit： エンジニア向けに選択したSvelteKitが、結果的にHTMLライクでクリエイティブ職の方にも理解しやすい構造でした。 DevContainer： 「エンジニア間で環境を統一したい」という目的で導入したDevContainerが、「誰でもワンクリックで開発環境を起動できる」仕組みとして機能しました。 Rancher Desktop： 無料で誰でもつかえるツールとして、クリエイティブ職の方にも導入しやすい環境を提供してくれました。 自動linter/formatter： エンジニアのコード品質を保つために導入していた自動フォーマッターが、クリエイティブ職の方が書いたコードも自動的にきれいに整形してくれました。 実際の作業プロセス 前提条件 バナー画像：クリエイティブ職の方で作成済み HTML/CSS：知識があり、触っている 実作業の流れ 環境構築サポート Rancher Desktopのインストールと初期設定のみサポート DevContainer起動 VSCodeのボタンひとつでローカル開発環境が完成 コード修正 普段のHTMLを書く感覚でSvelteファイルを編集 リアルタイム確認 ローカル環境ですぐに変更を確認 自動品質管理 保存時に自動でコードがフォーマット PR作成 クリエイティブ職の方からGitHubのPRを作成 成功要因の分析 実際にこの取り組みが成功したのは、前述の仕組み的な部分ももちろんですが、弊社に根付いている以下の文化も良い方向に作用しているように思います。 クリエイティブ職の方の積極性 組織内の垣根を超えて、自由に挑戦できる環境が弊社ではあります。 失敗を恐れない文化 弊社では、問題が発生した際に個人を責めるのではなく、仕組みやシステムの改善にフォーカスする文化が根付いています。 適用範囲と制約事項 今回成功した要因として、以下の前提条件があったことも重要です。 適用可能な作業 HTML/CSSの知識がある方による軽微なデザイン修正 画像やテキストの差し替え レイアウトの微調整 従来通りエンジニアが必要な作業 ロジックを伴う機能追加 データベース関連の修正 セキュリティに関わる変更 また今回、あげてくださったPRをエンジニア側でレビューしています。 おわりに 今回の経験から得られた知見は以下です。 開発環境の民主化が組織全体の生産性向上につながる 技術選択の副次的効果を意識した環境設計の重要性 組織文化と技術環境の相乗効果 この気付きをもとに、みなさまの環境の参考にしていただければ幸いです。

はじめに こんにちは。会員基盤チームの添野 隼矢です。 私はこれまで、課金請求系、セキュリティ、会員管理・ログイン認証など、様々な分野でキャリアを積んできました。現在は会員管理システムの開発に携わっています。 今回は、私が所属している会員基盤チームが持っているプロダクトと私たちのチームが挑戦する壮大なプロジェクトについてご紹介します。 会員基盤チームのプロダクト 当チームが管理している主要なプロダクトは以下の3つです： 会員管理システム クレジットカード情報を中継するシステム 認証・認可を行うシステム 大規模刷新プロジェクトの概要 現在、私たちのチームは下記の募集要項にあります通り、500万人を超える会員を管理するシステムの大規模刷新プロジェクトに取り組んでいます。 このプロジェクトは、単なる移行ではなく、未来のビジネスを支える基盤づくりを目指しています。 https://hrmos.co/pages/nifty/jobs/10303 まずは、現在のシステムをスリム化、コンテナ化しながらAWSに移行しています。 AWSに移行する際には、スケーラビリティと耐障害性を考慮した設計をした上で、Terraformを用いて、インフラ環境のリソース作成を進めています。 また100本以上あるAPIやバッチ処理をコンテナ化することで、現状デプロイしないと動作確認ができなかった処理をローカルで確認できるように改善しています。 AWSへの移行後は、お客様への利便性向上と新規ビジネスの早期立ち上げを目的とし、ISP固有の会員基盤からの脱却に向けて、各機能のマイクロサービス化を進めていきます。 まずは、目的を実現するために何が必要かなどの要件定義を、企画や営業の方、お客様サポートを担当している方を含めて行っております。 また、今後Javaで作られているシステムを、弊社内で主流となっているPythonへの切り替えを予定しています。 おわりに 現在、会員基盤チームではキャリア採用を募集しています。 500万人の未来を支える技術を、一緒に創り上げませんか？ 経験豊富なエンジニアの方、ぜひご応募ください。 https://hrmos.co/pages/nifty/jobs/10303 また所属しているチームのインタビュー記事が本ブログにて公開されています。 https://engineering.nifty.co.jp/interview/33486 そちらでは、会員基盤刷新プロジェクトの経緯や会社全体のことなどを話していますので、ご興味があればお読みください。

はじめに こんにちは。ニフティ株式会社の山田です。 今回は、フロントエンドフレームワークとして最近SolidJSを試してみたので、その内容を紹介いたします。 そもそもSolidJSとは？ SolidJSとは、仮想DOMを使用しないJSX系宣言的UIフレームワークです。 宣言的UIフレームワークとしてはReactやVue.jsが有名ですが、この2つは差分レンダリングに仮想DOMを利用しています。 これは仮想DOMに一度書き込んだあと、差分を計算して実際のDOMに反映させるという動作を基本としています。プログラミングモデルが単純化される一方で、仕組みとしては重く、JavaScriptのサイズを肥大化させる原因ともなっています。仮想DOMへの書き込みを減らす仕組みも入っていますが、根本的な重さからは逃れられません。 一方で最近登場したのが、イベント駆動とトランスパイルを組み合わせるフレームワークです。 これらのフレームワークは、変数を「値変化イベントを発火させるオブジェクト」として取り扱うことで、その変数に関連するコンポーネントだけを再レンダリングするように動作します。 普通であればコーディングが複雑化しますが、ビルド時変換を多用することで極力簡単に書けるようになっています。 有名なフレームワークとしてSvelteが挙げられますが、SvelteはVue.jsに近いHTML/CSS/JavaScriptを1ファイルに書く独自文法を採用しています。 一方で、React同様にJSXを採用しているのがSolidJSです。 SolidJSは値変化の検出にsignalという仕組みを採用しています。この仕組みはknockout.jsで開発されたものですが、宣言的UIフレームワークに採用したのはSolidJSが初であり、その後PreactやVue.js、Svelte 5などでも採用が広がっています。 SolidJSのメリット 独自文法を採用せず、JSXベースのためセットアップが容易 SvelteはLinterなどのセットアップが辛い… Astroに部分的に組み込む〜　などがやりやすい 読みにくい挙動部分が少ない この辺りもReactの思想に近い Svelteのように Easy >>> Simple な思想とは真逆 仮想DOMを使用せず、動作速度・JSサイズともに軽量 デメリット 利用者がまだ少ない… React > Vue.js > Svelte >>>>> SolidJS くらいの肌感覚 周辺ツールのサポートも少ない Vitest Browser Mode 非対応なのが痛い SSRフレームワーク（SolidStart）の歴史が浅い 2024年4月にようやく1.0になったばかり 使い心地 基本的なコンポーネント import { createEffect, createSignal, onCleanup } from "solid-js"; const CountingComponent = () => { const [count, setCount] = createSignal(0); const interval = setInterval( () => setCount(c => c + 1), 1000 ); onCleanup(() => clearInterval(interval)); createEffect(() => { console.log(`count: ${count()}`); }); return <div>Count value is {count()}</div>; }; Reactに慣れている人であれば、 createSignal → useState createEffect → useEffect のように読み替えて理解ができるくらいにはそっくりです。 Reactでは状態変数をstateと呼びますが、Solidではsignalと呼びます。値の変化に応じて値変化イベントを発火させるオブジェクトになっています。 Reactとの違いとしては、以下となります。 コンポーネントは初期化時の1回しか実行されないこと Reactのように再レンダリングの度に実行される、というモデルではない signalが変化した場合、signalに関連する部分のコードだけを再実行する 定数宣言してしまうと初期化時に値が固定されてしまう signalに依存する別の変数を扱う場合は、関数として扱います const [base, setBase] = createSignal<number>(1); // Bad: これは初期化時に値固定され、以降変わらなくなる const multiply = base * base; // Good: これはbaseの変化に応じて変化する const multiply = () => base * base; returnは必ず1つでなければならない 複数あったとしても、使われるのは初期化時に使われた1つだけ 変化する値は関数を通してアクセスする 例えばcreateSignal()で返るのは定数ではなく、関数になっている TypeScript的にはAccessor<T>という型になっている type Signal<T> = [get: Accessor<T>, set: Setter<T>]; type Accessor<T> = () => T; type Setter<T> = (v: T | ((prev?: T) => T)) => T; createEffectに依存配列は必要ない ReactのuseEffectとは明確に異なる createEfffectの中で使われているsignalが変化したとき、自動で再実行される props import { type JSX } from 'solid-js'; type Props = { titile: string; url: string; }; const Component = (props: Props): JSX.Element => { return <a href={props.url}>{props.title}</a> }; propsもReact同様…ですが、オブジェクトの展開(destructuring)を行ってはいけないです。 （以下のように書くのはアウトとなります） const Component = ({title, url}: Props): JSX.Element => { ... }; // これはは以下の構文と等しい // つまり初回実行時の値をconstで取り出して固定化しているので、値の変化に追従しなくなる // const Component = (props: Props): JSX.Element => { // const { title, props } = props; // ... // }; 制御構文 「変数(signal)の変化に応じて再レンダリングする」という構造上、コンポーネントの出し分けに三項演算子やmap()を使用してしまうと無駄な再レンダリングを引き起こしてしまう可能性が高いです。（条件文の結果が変わらなくても、条件判定に使用するsignalが変わっていれば再レンダリングされるため） というわけで、コンポーネントの出し分けには独自のコンポーネントが必要になります。 Show <Show when={/* 条件文 */} fallback={/* else相当のコンポーネント */} > {/* コンポーネント */} </Show> if文や三項演算子の代わりになるのがShow。whenに条件文を渡して制御します。else相当のコンポーネントはfallbackに渡します。 残念な仕様として、whenによる type narrowingが効かない です。このためasなどを使用せざるを得ません。 const data: Accessor<string | string[]>; <Show when={!Array.isArray(data)} > {/* whenと↓のコンポーネントは文法上の紐づけがないので、!isArray()による型の絞り込みがされない */} <SomeComponent data={data() as string}> </Show> 一応、子コンポーネントを「whenの値を渡す形の関数」として記述でき、null・undefined判定だけならこれで解決できます。 const data: Accessor<string | undefined>; <Show when={data} > {(data) => <SomeComponent data={data() /* string型 */}> } </Show> For / Index forやmap()の代わりはForとなります。 <For each={/* forで回せるデータ */} > {(item) => <SomeComponent data={item()}>} </For> 同じ文法でIndexというものもあります。それぞれの使い分けはドキュメントに記載されていますのでそちらを参照してみてください。 https://docs.solidjs.com/reference/components/index-component createResource データの非同期取得のために、createResouceが標準で用意されています。 ReactのSWRやTanstack Queryのような別ライブラリを必要とせずにデータフェッチを記載できます。 const fetchUser = async (userId) => (await fetch('https://....')).json(); const userId = createSignal<string>(""); // 第一引数に与えたsignalに応じて自動的に第二引数の非同期関数を実行する const [user] = createResource(userId, fetchUser); // refetchなどを行いたい場合は追加の戻り値もある const [user, { mutate, fetch }] = createResource(userId, fetchUser); まとめ Good Point 挙動が理解しやすい Svelteのような、どう動くのか理解不能な局面が少ない 軽い Reactで書くと数百KBになるものが数KBで済む 運用が軽い 破壊的変更が非常に少ない Svelteは周辺ツールもふくめてそれなりに壊してくる & Svelte 5で超大規模変更が… JSXなので大体のツールが標準対応しており、余計なパーサーなどの設定が不要 罠はあるが、入門ドキュメントで覚えた程度で事足りる 公式ドキュメントに日本語あり Bad Point Showが辛い ここだけ型安全性が崩れる SolidStartの歴史が流石に浅い まだ半年程度… ベースになっているvinxiがまだ0.4でドキュメントも貧弱 Astro + Solidのような組み合わせが現状は安牌 今回はSolidJSを試してみた所感を紹介しました。SolidJSや他フレームワークの比較をされている際に参考になれば幸いです。

ISP（インターネット接続サービス事業者）を主力事業に、成長を続けてきたニフティ。その屋台骨を支えてきたのが、創業当初からの会員基盤システムです。まさに会社の財産といえる一方で、老朽化したシステムによって新規サービスの立ち上げ速度が鈍るなど、長く同じ基幹システムを使い続ける弊害も生じていました。 2024年4月に立ち上がった「会員基盤刷新プロジェクト」では、この基幹システムを大きく見直し、2027年度中に抜本的なリニューアルを行うことを目指しています。ニフティのビジネスやサービスを、根本から変える可能性を秘めた一大プロジェクト。重積を担うメンバーに話を聞きました。 自己紹介 R.Aさん 2004年、新卒入社。バックエンドエンジニアとして、お客様向けログインシステムに関する開発・運用などを担当したのち、2018年からエンジニアリングマネージャー。現在は、会員基盤刷新プロジェクトのリーダーも務める。趣味は筋トレとジョギング。 S.Nさん 2007年、新卒入社。以降、一貫してバックエンドの会員基盤、認証基盤などの開発・運用業務に従事。社内のさまざまなプロジェクトに、バックエンドエンジニアとして携わる。会員基盤刷新プロジェクトではサブリーダーを担いつつ、開発、運用、他部署との調整業務などを幅広く担当。趣味は楽器演奏。トリニダード・ドバゴ共和国発の打楽器であるスティールパンのほか、オーケストラでトランペットも演奏する。 S.Sさん 2019年、新卒入社。課金キャンペーンに関する開発・運用やセキュリティなどの運用を経て、2025年から会員基盤刷新プロジェクトに参加。兄もニフティのエンジニア。趣味は音楽鑑賞。最近は推しのライブに行くこと。 ニフティのビジネスを大きく変える「会員基盤刷新プロジェクト」とは？ みなさんは2024年4月からスタートした「会員基盤刷新プロジェクト」を推進する中心メンバーということですが、はじめにプロジェクトの概要を教えてください。 R.Aさん @niftyの会員基盤システムは、いわばニフティ全社のビジネスを支える最重要のシステムです。この会員基盤全体を刷新し、お客様の利便性向上と新規ビジネスの早期立ち上げをはかることを目的としたプロジェクトになります。 S.Nさん 現在の@niftyの会員基盤は、ISP（インターネット接続サービス事業者）の創成期につくられたシステムです。これまで、何度も刷新を重ねてニフティの主力事業であるISP事業を支えてきた、会社の財産といえます。一方で、創業以来の老朽化したシステムであるがゆえの弊害も起こっていました。たとえば、新しいビジネスを立ち上げようとしても、「従来のシステム上にどう落とし込むのか」といった、無駄な議論が発生してしまっていたんです。そうした、ISP固有の会員基盤から脱却し、各機能のマイクロサービス化を進めようというのが、プロジェクトの最も大きな狙いですね。 ISP事業だけでなく、これから新たなサービスをどんどん生み出していくためにも、基幹システムの抜本的なリニューアルが必要だったと。 S.Nさん そうですね。今回のプロジェクトでは「XSP」というキーワードを掲げています。このXの部分にはさまざまなサービスがあてはまり、ISP事業もそのうちの一つです。つまり、ニフティという会社は今後、ISPだけでなく多種多様なビジネスを展開していく会社になる。それを可能にする基盤をつくるのが、私たちのミッションですね。 新規サービスの立ち上げだけでなく、お客様の利便性向上の側面もあるということですが。 S.Nさん 一例を挙げると、現状はシステムの都合上、サービスごとに複数のIDを取得しなければいけないケースもあります。会員基盤を刷新してシンプルにすることで、一つのIDでニフティの全てのサービスをご利用いただくなど、お客様にとってより使いやすいものにできるのではないかと考えています。 現状のプロジェクトの進捗と、今後の展望を教えてください。 R.Aさん 2024年4月にプロジェクトがスタートし、現在まで1年をかけて各部署のマネージャーたちと議論を重ねてきました。社内のあらゆるサービスに関わるシステムですので、関係者がめちゃくちゃ多くて。さまざまな立場の人の意見を吸い上げて調整したり、開発の優先順位を決めたりする必要があったんです。現状は、ようやく計画がフィックスしたところで、2025年の4月からいよいよ開発がスタート。2027年度までに段階的にリリースをしていく予定です。 他部署と「幸せな未来」を共有し、温度感を合わせる プロジェクトにおける、みなさんの役割を教えてください。 R.Aさん プロジェクトリーダーとして、メンバーが動きやすい体制を整えること、また、関係者とのコミュニケーションが主な役割です。特に、各部署のマネージャー陣との調整や交渉などがメインですね。 S.Nさん 私も各部署との調整を行いますが、上長レベルのコミュニケーションはR.Aさんにお任せして、私の方では現場レベルでの細かい設計などについての調整を担当しています。他には、開発運用、コーディングまで、本当に何でもやるような感じですね。 S.Sさん 私も同じく何でも屋です。設計、運用をはじめ、システムの構築にまつわる全てを担当しています。 S.Sさんは3人のなかで最も若手ですが、会社として最重要ともいえるプロジェクトを手がけることを、どのように捉えていますか？ S.Sさん 今後のニフティのビジネスを支えるシステムとして、長く使われていくものになるので、もちろんプレッシャーはあります。設計ひとつとっても高い品質を求められていますし、私自身もさらに成長しなければいけないなと。 特に難しさを感じているのは、他部署からの要望やお客様のニーズなど、さまざまな要素に対応する必要があること。私の場合はチームにアサインされて日が浅いこともあり、現状のシステムにおける課題感を掴みきれていないところもありました。ただ、当初から週に1度の頻度で他部署の方々とミーティングを重ねてきて、徐々に解像度が上がってきましたし、要求をまとめる力も身についてきたと思います。 R.Aさん、S.Nさんは、自身の役割のなかで難しさを感じる部分はありますか？ R.Aさん 私の場合は、周囲とのコミュニケーションですね。特に、このプロジェクトは他部署のメンバーにも実際に手を動かしてもらうことが必須で、協力を仰ぐためにはプロジェクトの意義や目的を理解してもらう必要がありました。 当初は関係者を集めてディスカッションをしようにも、なかなかうまくいかないところもありましたね。積極的に意見を出してもらえなかったり、堂々めぐりの議論になってしまったりと、関係者が多いゆえに思うように進まないストレスを感じていました。ただ、半年前ほど前からコミュニケーションや会議の進め方を見直して、徐々に議論が噛み合うようになっていったと思います。 S.Nさん 他部署にどこまでお願いしていいのか、そのバランスは難しいですね。やはり、これをやることで「どれだけ幸せな未来が待っているか」を、丁寧に伝えて温度感を合わせていく必要があると思います。 また、このプロジェクトは2027年度いっぱいかかる想定なので、「その間、他の開発ができなくなるんじゃないか」という懸念の声は多く挙がっています。私自身もプロジェクトのメンバーであると同時に、会員管理システムの開発・運用も担う立場ですので、そうした不安もよく分かる。システムの刷新と、その間の新規の開発をいかに両立していくかという点は大きな課題の一つですね。 チームは新たな仲間を募集中。望むメンバー像は？ プレッシャーも大きく難易度も高いミッションですが、そのぶん、やりがいも感じられそうです。 S.Nさん 個人的にはプレッシャーよりも、このプロジェクトに携われる喜びやワクワクのほうが大きいです。@niftyにはすでに500万人を超える会員様がいらっしゃいますが、会員基盤システムを構築して新しいサービスがどんどん誕生することで、お客様もさらに増えるはず。そう考えると、とてもやりがいの大きい仕事だなと。 これから実装に向けてプロジェクトが本格化しますが、現状の課題を教えてください。 R.Aさん 一つはチーム体制の強化です。2025年4月から、もう一つチームをつくり人も補充していく予定です。社内でもメンバーを公募していますし、本プロジェクト向けのシステムエンジニアの求人も行っています。 どんなメンバーを迎えたいですか？ R.Aさん まずスキルの面でいうと、設計から入る作業が多いので、コーディングだけをバリバリやってきた人よりは、上流工程の基本設計の経験をお持ちの方を求めています。性格の面では、ありきたりですが「この人と働いてみたい」と思えるような人間性を備えた方。僕だけの判断ではなくメンバーにも面談に入ってもらい、一緒に働く仲間を選んでほしいと考えています。 S.Nさん 僕は、日頃からアーキテクチャに対して「妄想」を膨らませている方に来てほしいです。こうした基幹系のシステムは、エンジニアからすると「もっと、こういうふうになっていたらいいのに」と思うことが多々あると思うんです。そこで「自分ならこうつくる」といった具合に思いをめぐらせている方がチームに入ってくれると、より議論が深まり、良いものができると思います。 性格面でいうと、積極的に動いてくれる人ですね。このプロジェクトは特に、上から言われたことをやるのではなく、自分たちでやるべきことをつくり出すという側面が強い。論理的思考に基づき、積極的にアクションを起こせる人が来てくれると、本当にありがたいです。 後編に続きます！ 今回はニフティの会員基盤刷新プロジェクトチームのインタビューの様子をお届けしました。続きは後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

はじめに こんにちわ！ マイ ニフティチームの寺島です。 普段はスマートフォン向けのアプリケーション開発に携わっています。 ブログ運営チームのメンバーでもあります！ 機能開発やバグ修正を進めていると、途中で「typo修正」「ログ出力追加」「ちょっとリファクタ」など、小さなコミットが積み重なることがありますよね。そのままプルリクエストを出すと、コミット履歴が細かすぎてレビューしづらくなったり、プロジェクト全体の履歴がノイズが多くなってしまったりします。 そんなときに役立つのが、Gitの rebase -i コマンドを使った「コミットの整理」です。 特に 複数のコミットを一つにまとめる（squashする） 方法は、プルリクエストを出す前の準備として非常に有効です。 今回、実際に手を動かしながら、 git rebase -i を使って複数コミットを一つにまとめる手順を解説します。 ハンズオン用のリポジトリを作成する 今回のハンズオンで使用するダミーのリポジトリを作成します。 適当なディレクトリで以下のコマンドを順に実行してください。 # 作業用ディレクトリを作成 mkdir git-squash-demo cd git-squash-demo # Gitリポジトリを初期化 git init # ダミーファイルを作成し、最初のコミット echo "Hello, Git Squash" > README.md git add README.md git commit -m "feat: add initial README file" # 状態確認 git log --oneline git log --oneline を実行すると、最初のコミットが表示されるはずです。 次に、まとめる対象となる複数のコミットを作成していきます。 いくつかの変更を加え、それぞれ順にコミットしてください。 # 2つ目のコミットを作成 echo "This is the second line." >> README.md git add README.md git commit -m "chore: add second line" # 3つ目のコミットを作成 echo "This is the third line for refactor." >> README.md git add README.md git commit -m "refactor: improve wording" # 4つ目のコミットを作成 echo "Add final sentence." >> README.md git add README.md git commit -m "feat: add final sentence" # 現在の履歴を確認 git log --oneline git log --oneline を実行すると、以下のように4つのコミットが積み重なっていることが確認できるはずです。（ハッシュ値は環境によって異なります） <最新のハッシュ> feat: add final sentence <3つ目のハッシュ> refactor: improve wording <2つ目のハッシュ> chore: add second line <最初のハッシュ> feat: add initial README file これで準備は完了です！ 最新の3つのコミット（”chore: add second line”、”refactor: improve wording”、”feat: add final sentence”）を一つにまとめてみましょう。 rebase -i を開始する git rebase -i コマンドは、「どのコミットまで」を対象にするかを指定して実行します。 指定したコミット より新しい コミットがインタラクティブなrebaseの対象となります。 今回は最新の3つのコミットを対象にしたいので、「最初のコミット（ feat: add initial README file ）」の次からを対象にします。 最新のコミットから数えて対象のコミットが何番目か分かっている場合は、 HEAD~N という形式で指定できます。 今回は最新の3つのコミットを対象にするので、 HEAD~3 を指定します。 これは「HEADから3つ遡ったコミットまで」を意味し、結果的に最新の3つのコミットが操作対象になります。 # 最新から3つのコミットを対象にインタラクティブrebaseを開始 git rebase -i HEAD~3 このコマンドを実行すると、エディタが立ち上がります（使用するエディタはGitの設定によります）。エディタには、対象となるコミットが古い順に表示されます。 pick <2つ目のハッシュ> chore: add second line pick <3つ目のハッシュ> refactor: improve wording pick <最新のハッシュ> feat: add final sentence # Rebase <ハッシュ値>..<別のハッシュ値> onto <別のハッシュ値> (<コミット数> ahead) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup [-C | -c] <commit> = like "squash" but keep only the previous # commit's log message, unless -C is used, in which case # keep only this commit's message; -c is same as -C but # opens the editor # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # create a merge commit using the original merge commit's # message (or the oneline, if no original merge commit was # specified); use -c <commit> to reword the commit message # u, update-ref <ref> = track a placeholder for the <ref> to be updated # to this position in the new commits. The <ref> is # updated at the end of the rebase # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # エディタでコミットを整理する エディタには、各コミットの左側にコマンドが記述されています。デフォルトは pick になっており、そのコミットを採用するという意味です。 複数のコミットを一つにまとめたい場合は、 まとめたいコミットの行の pick を squash または s に変更します。 squash はそのコミットを 直前のコミットにまとめます 。 s は squash の短縮形です。 今回は最新の3つのコミット（”chore: add second line”, “refactor: improve wording”, “feat: add final sentence”）を、一番古いコミット（”chore: add second line”）にまとめたいです。 2番目と3番目のコミットの pick を s に変更します。 エディタの内容を以下のように修正してください。 pick <2つ目のハッシュ> chore: add second line s <3つ目のハッシュ> refactor: improve wording <- ここを s に変更 s <最新のハッシュ> feat: add final sentence <- ここを s に変更 # コメント行はそのまま、または削除してOK ... ※一番上の行（今回まとめたいコミット群の中で一番古いもの）は pick のままにしておきます。 これがまとめたコミットの「土台」になります。 修正したら、エディタを保存して閉じます。 コミットメッセージを編集する エディタを閉じると、Gitがrebase処理を実行し、まとめたコミットの新しいコミットメッセージを作成するためのエディタが再度立ち上がります。 このエディタには、 squash に指定した各コミットのメッセージが自動的に結合された状態で表示されます。 # This is a combination of 3 commits. # This is the 1st commit message: chore: add second line # This is the 2nd commit message: refactor: improve wording # This is the 3rd commit message: feat: add final sentence # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch main # Changes to be committed: # modified: README.md # この結合されたメッセージを編集し、まとめたコミットとして適切なコミットメッセージに書き換えます。 不要な行（特に # で始まるコメント行や、元のコミットメッセージのヘッダー部分）は削除し、最終的なコミットメッセージだけを残しましょう。 例： feat: Add second, third, and final lines to README メッセージを編集したら、エディタを保存して閉じます。 結果を確認する エディタを閉じると、rebase処理が完了します。 念のため、 git log --oneline コマンドでコミット履歴を確認してみましょう。 git log --oneline 最新の3つのコミットが一つにまとまり、先ほど編集した新しいコミットメッセージになっていることが確認できるはずです。元の3つのコミットは履歴から消えています。 <新しいコミットのハッシュ> feat: Add second, third, and final lines to README <最初のハッシュ> feat: add initial README file これで、複数のコミットを一つにまとめることができました！ おわりに git rebase -i の squash オプションを使うことで、開発途中で増えた細かなコミットを一つにまとめることができます。これは、コミット履歴を綺麗に保ち、プルリクエストのレビューを効率化するために非常に役立ちます。 git rebase -i <対象の範囲> でインタラクティブrebaseを開始する。 エディタで、まとめたいコミットの pick を s (squash) に変更する。 一番上のコミット（まとめる先）は pick のままにする。 次に表示されるエディタで、まとめたコミットの新しいメッセージを作成する。 適切に使えば、Gitワークフローがより洗練されるはずです。ぜひ試してみてください！

こんにちは！ニフティの島、江田、坂内です。 2025年6月1日（日）に開催される「技術書典18」に出展することになりました！ NIFTY Tech Day2025で来場者にお配りしたニフティの技術書「NIFTY Tech Book #2」を無料頒布いたします！ イベント概要 イベント名: 技術書典18 日時: 2025年6月1日（日） 11:00～17:00 場所: 池袋・サンシャインシティ 展示ホールD（文化会館ビル2F） 参加：入場無料 ブース：「さ17」 （ https://x.com/techbookfest/status/1905070279279456395 ） 詳細は下記公式サイトをご覧ください。 https://techbookfest.org/event/tbf18 社員の「好き」と「学び」が詰まった、珠玉の9章立て！ 今回頒布する技術書は、ニフティエンジニアの有志が「書きたい！」と思ったことを自由にテーマにして執筆した技術書です。その結果、総ページ数 144ページ という大ボリュームになりました！ 気になる内容は、こちらの9章立てです！ 1章：元SIer系SEがニフティでSREになって2年間で得た成長と学び 2章：ニフティのインナーソース普及活動 3章：VyOSを使った自宅DNSのご紹介 4章：AITuberを作ろう 5章：新人エンジニアがGitの仕組みについて調べてみた 6章：Azure Functions徹底解剖(おまけ:日次課金通知アプリのサンプル) 7章：爆速でドメイン知識を獲得してチームにジョインする方法 8章：私のTerraformプラクティス2025 9章：メタバース×業務効率化 – バイタルデータによる実務適性の定量的検証 SREのリアルな経験談から、インナーソース活動、自宅インフラ、流行のAITuber制作、Gitの深掘り、Azure Functionsの実践、チームへの高速キャッチアップ術、Terraformの最新プラクティス、そしてメタバースを活用した業務効率化検討まで…多岐にわたるラインナップです！ きっと皆さんの知的好奇心を刺激する章が見つかるはずです。 表紙も手作り！そして、なんと…無料です！ そして本文だけでなく表紙と背表紙のデザインも当社のエンジニアが手がけています！細部にまでこだわりと愛情を込めて作成しましたので、ぜひその点にも注目してみてください。 これだけのボリュームと内容でありながら、なんと 無料 で頒布させていただきます！ ぜひ、私たちのブースへお越しください！ イベント当日は、執筆やデザインや表紙制作をした社員がブースに立つ予定です。 皆さんと会場でお会いできることを、社員一同、心から楽しみにしています。 ぜひ、私たちのブースにお立ち寄りいただき、熱い想いが詰まった技術書をお手に取ってみてください！

弊社では業務PCとしてノートPCが支給されますが、外付けキーボードやマウスを利用したい方は追加支給してもらうこともできます。ですが自分好みのキーボード・マウスを利用したい方は、各人の責任で持ち込んで利用することも認められています。 その流れで私は自作したキーボードを業務PCに接続して使っていますが、そのキーボードを作成した際の知見を少しまとめました。 小型試作基板から始まったハーフキーボード作り いつも基板製造でお世話になっている JLCPCB 様は、一度の注文は最低５枚からの注文となりますが、小さいサイズの基板を安価なディスカウント価格で試作してくださいます。 回路のテストを小さいサイズで繰り返し試せるため便利に利用しているのですが、ディスカウントの範囲で実用できる物を作れないかと検討した結果、縦横５キーずつのマクロパッドやテンキーパッドに似たものを作りました。 基板が届き組み立てたところで、ふと通常文字のキーキャップをはめてみたところ、２台あればキーの数も50個になるので通常のキーボードとして使えるのでないか？と思ってしまったところから今回の話が始まります。 半分のキーボードを常用するために 届いた５枚の基板のうち２枚を使って組み立てたキーボードが２台できあがり、左手用と右手用のキーキャップを装着して役割に対応する設定（キーマップ）を書き込みます。 こうして同一回路の基板でそれぞれ対応するキーマップに替えて使うことでキーボード一台分の種類の文字を扱えるようにはなるのですが、このキーマップをそれぞれの個体にはめたキーキャップに対応するものに変えるために qmk_firmware では通常、 違うキーマップのファームウェアバイナリを作って書き込む。 それぞれをレイヤとして定義して一時的に切り替える。 via や Remap , vial といったツールで動的に書き換える。 といったいくつかの方法があります。 1.の方法ではキーマップの割り当てが電源を切っても永続化する一方で、ファームウェアを修正して入れ替えるたびに都度それぞれビルドして対応するバイナリを書き込む必要があります。 2.の方法ではPCに繋ぎなおしたり電源を入れるたびに設定を変更する必要があります。 3.の方法は上記課題をクリアできますが、ファームウェアを修正すると初期化してしまい、その都度キーマップを作り直すことになります。 この手間を解消するため、2.の方法でありながら電源投入時の初期のレイヤを固定して3.のように扱うことができるようにしたいと思います。 qmk_firmwareのBootMagic機能 話は変わりますが、qmkでファームウェアのバイナリを変更するときには、マイコン基板やキーボード基板のボタンを押して書き込みモードにする方法の他に、書き込みモードに移る内部キーコードと、PCに接続するなどの起動時に特定のキーを押しておく BootMagic という機能があります。 このBootMagicの操作方法は半固定の永続設定の操作方法としてあっているのではないでしょうか？と言うことで調べました。 bootmagicの設定例(keyboard.json) "bootmagic":{ "matrix": [5,0] }, qmk_firmwareは背後にqmkの元になった tmk やマイコンの基本API(rp2040では ChibiOS )がありますが、qmkとしてはquantum/main.cの main()関数 がプログラムの根幹になっています。 プログラム実行直後に各種の初期化をおこなった後にメインループを回す構造ですが、初期化の中でBootMagicを判断しているのはquantum/keyboard.c の quantum_init() から bootmagic.c の　 bootmagic() を呼び出す流れの部分でした。 BootMagicを呼び出す流れの途中の関数には (weak) を宣言している関数があり差し替えることはできますが、通常の処理の流れを書き換えたくないため、 quantum_init() の中でファームウェア開発者に提供され呼び出されている keyboard_post_init_user() を実装します。 config.hで追加した定義 // 起動時のデフォルトキーマップ変更 #define BOOTMAGIC_L_ROW 2 #define BOOTMAGIC_L_COLUMN 0 #define BOOTMAGIC_R_ROW 3 #define BOOTMAGIC_R_COLUMN 0 #define BOOTMAGIC_N_ROW 4 #define BOOTMAGIC_N_COLUMN 0 特定のキーが押されているか確認するにはマトリクスのrow,colを指定して確認しますが、これはキーボードの基板の配線ごとに変わるところです。今回は左端上から２～４個目を押しながらUSBケーブルを接続するとキーマップが変わるように、それらのキーの配線を指定しています。 起動時に押すキーと役割（今回の例 keymap.cで記述する関数定義 // 起動時に特殊キーを押しているとデフォルトレイヤを変更する void keyboard_post_init_user(void) { uint8_t row = BOOTMAGIC_N_ROW; uint8_t col = BOOTMAGIC_N_COLUMN; matrix_scan(); if( matrix_get_row(row) & (1 << col)) { set_single_persistent_default_layer(_NPAD); } row = BOOTMAGIC_L_ROW; col = BOOTMAGIC_L_COLUMN; if( matrix_get_row(row) & (1 << col)) { set_single_persistent_default_layer(_LPAD); } row = BOOTMAGIC_R_ROW; col = BOOTMAGIC_R_COLUMN; if( matrix_get_row(row) & (1 << col)) { set_single_persistent_default_layer(_RPAD); } } 起動時に押していてほしいキーの情報は他の定義と同じように config.h などで定義することとして、一つの動作のキーごとに row(行) と col(列) を BOOTMAGIC_N_ROW, BOOTMAGIC_N_COLUMN などと定義しておき、これらのキーが現在のマトリクスマップの押下状況と比較してキーが押されているかどうかを、例では３回（左手、右手、テンキーの３種）判断しています。 マトリクスの押下判断手段は bootmagic.c の手法 に沿った方法でmatrix_get_row()で1行分の状態を取得して、colの位置のビット状態を確認します。 config.h で定義したキーが押されていると判断した場合に、 set_single_persistent_default_layer() を使って現在のデフォルトレイヤを変更すると共に、eepromに書き込んでデフォルトキーマップの変更を永続化しています。 このようにしてキーボードをくみ上げた後にキーキャップで決まる役割、それぞれに応じたキーマップに変更しつつ、その変更をeepromに記録して電源を入れなおしてもその役割を維持できるようになりました。 複数のキーボードを組み合わせて使うことについて このような経緯を経て、左右２台のキーボードを使うことでキーボード一台分の入力ができるようになりましたが、分割キーボードに比べると下記の違いがあります PCに接続するためのUSBポートが２口必要（Hubでも可） qmk機能が個々のキーボードに閉じるため、レイヤキーなどの操作が両手に分担できない（左でレイヤキーを押しても右のマップが変わらないなど） 同上の意味ですがRGBマトリクスなどエフェクトが左右別になる 片側だけでも動作・利用可能、途中で抜き差し可能 消費電力はそれぞれ別の上限になるため余裕がある これらの違いは、キーボードの種類と利用者それぞれの設定状況（キーマップや利用方法など）で受容できるかどうかが決まりますので、その時々の判断が必要となります。 とはいえ、個人的にはこの状況でキーの少なさ以外の不自由を感じずに日常業務で利用できていますので、変わり種の多い自作キーボードのバリエーションの一つとしていかがでしょうか。 おわりに 自作キーボードのファームウェアはソフトウェアと電子回路、機械的な事柄まで幅広い知識が身に着けられるのでソフトウェアエンジニアとして幅を広げるにはいい課題ではないでしょうか。 キーボードと言う毎日使うデバイスですので、活動の結果がQOLに直結する点も素晴らしいと思います。 この記事で興味を持って一人でも多くの仲間が現れることを期待しています。