この記事の対象者 インナーソースやOSSのコントリビュート文化に興味がある方 社内でAIエージェントとGitHub Actionsを組み合わせた「IssueOps」を検討している方 こんにちは、エンジニアリングマネージャーの芦川です。 以前からいろいろとインナーソースに関連した話を書いてきました。 インナーソースが組織に広がりやすいパターン4選！ GitHubで育つコラボレーション文化 :ニフティでのインナーソース挑戦事例 ドキュメントライティング本をインナーソースの観点から読んでみた InnerSource Summit 2025にて写真撮影サポート ＆ 登壇させていただきました！ など。 あれから月日が経ち、AIの活用で社内のインナーソースの形そのものが少しずつ変わってきています。 今回書きたいのは、インナーソース x IssueOps x AIということについてです。 インナーソースはIssueOpsによって加速し、さらにAIによってIssueOpsも加速したな、ということ。 これまでのインナーソースの話 これまでのインナーソースは、OSSのコントリビュートフローをそのまま社内に持ち込んだような形でした。 コントリビュートしたいリポジトリの権限をもらう（あるいはフォークする） コードを読んで、修正方針を考える 実際にコードを直す アップストリームへPRを出す リポジトリのオーナー側がレビューする マージされる この流れは「エンジニアがエンジニアに対して」行うことが前提になっていて、次のような壁がありました。 対象リポジトリの技術スタックに慣れていないと、そもそも着手しづらい Gitの操作（ブランチを切る、PRを出す）に慣れていない人は参加すらできない 「他チームのリポジトリにPRを出す」ということ自体に、なんとなく気後れしてしまう IssueOpsがインナーソースを変え、AIが加速させてくれた 「Issueを起票すると自動でPRができる」という仕組み自体は前から存在していました。決まった書式のIssueテンプレートを用意しておき、そこに入力された内容をスクリプトが読み取って、設定ファイルを自動編集してPRを作る。いわばルールベースのIssueOpsです。 これはこれで十分便利で、たとえば 権限申請のような、入力項目が決まりきった依頼 特定のフォーマットのデータ連携定義を追加するような、パターン化しやすい依頼 にはとても有用です。わざわざ、リポジトリをcloneする作業も不要なので敷居を下げたインナーソースとしても以前からうまくハマり、実際に社内でも、こうした申請系の作業を自動化する取り組みは、AIエージェントが普及するより前から動いていました。 ただし、ルールベースである以上、対応できるのは「あらかじめ想定した書式・パターン」の範囲までです。少し込み入った依頼や、自然文でしか説明しづらい要望には対応できませんでした。 そこにAIエージェント（Claude Codeのようなコーディングエージェント）が加わったことで、状況が変わりました。 ルールベースの時代とAI時代の一番の違いは、Issueに入力する内容が「スクリプトがパースできる、かっちり決まったフォーマット」である必要がなくなったことだと思っています。以前は、項目名・選択肢・区切り文字まで含めて厳密に決めておかないと、後段の処理が動きませんでした。AIエージェントであれば、多少表現がゆれていても、あるいは自然文でだらだら書いてあっても、意図を読み取ってコードに落とし込んでくれます。 乱暴に言ってしまえば、日本語で「こうしてほしい」と書くだけでPRまで自動生成される、というところまでコントリビューターの敷居が下がったのが、今回の変化の本質です。つまり、IssueOpsという土台自体は以前からあったものを、AIがIssueOpsを自由にし、結果的にインナーソースを加速させる、というのが今の状況だと捉えています。 まあ流石に何でも自然文で通ってしまうと、意図しない範囲まで書き換えられてしまうリスクもあるため、どこかにガードレール（変更してよい範囲やレビュー必須のルールなど）を設けておくことは絶対必要です。 この3段階の変化を図にすると、こんな感じです。 見た目のステップ数はあまり変わっていないのですが、オレンジ（人がやる作業）がだんだん減って、青（自動化されている作業）に置き換わっているのがわかると思います。ルールベースの段階ですでに一部は自動化されていて、AIが加わったことで、起票そのものが自然文でよくなり、対応できる範囲も一気に広がりました。 実際どう使われている？ ずばり、こういうissueテンプレートです。これはプラットフォームチームが持つ定義ファイルに、社内連携システム側から定義変更の依頼を受け付けるものです。 変更内容と補足・備考あたりは、自然文を書いてもらい、その後、Claude Code GitHub Actionsを使ってPRまで作るということになります。 利用した人からは「簡単に依頼が出せた、フォーマットも迷わなかった」という声をもらえました。 とはいえ、いいことばかりではなく課題はあります。 課題 AIのコストを負担するのが誰なのか、という問題 ルールベースのIssueOpsは、実行コストがほぼスクリプトの実行時間だけだったので、あまり意識されていませんでした。ところがAIエージェントが実装まで担うようになると、そのコストが無視できない金額になってきます。これまでのインナーソースでは、コードを書くコスト（工数）はコントリビュートする側が負担していましたが、IssueOpsではその工数がAIエージェントの実行コストに置き換わり、しかもそのコストは多くの場合「リポジトリを持っている側」が負担することになります。 定義変更レベルでは消費されるトークンは少なくこのままでも問題なさそうですが、より大規模なPRとなっていく場合は議論しなければいけません。 意図とズレたPRが生成されることがある 自然文で起票できる分、自由度は高いのですが、AIが依頼内容を誤解して、意図と違う実装のPRを作ってしまうことも当然あります。実際に「IssueOpsで作られた設定が少しおかしかったので、直すPRを出しますね」という会話も社内でありました。結局、リポジトリを持っている側が手直しをすることになったわけです。ルールベースの時代にはこうした「解釈のズレ」はほぼ起きなかったので、これはAIが加わったことで新しく生まれた課題だと言えそうです。ただ、修正を加味しても楽にはなりました。 自然文の自由度には、ガードレールをセットで ヘタをするとリポジトリを破壊するPRも作ってしまう可能性がありますので、何らかのガードレールは必要だと感じています。たとえば： AIが編集してよいファイル・ディレクトリを限定する 本番直接反映ではなく、必ずPR経由で人のレビューを挙してからマージする バリデーションやCIを通さないとマージできないようにする どこまでをAIに任せてよいか（実装方針の判断まで任せるのか、定型的な修正に限定するのか）をリポジトリごとに決めておく このあたりは、IssueOpsの本体である「.github/workflows/xxx.yml」内のpromptなり、「claude/skills/xxx/SKILL.md」なりでしてはいけないことを明示しましょう。 まとめ 狭い意味でのインナーソース（フォーク → 修正 → PR → レビュー → マージ）は、まずルールベースのIssueOpsによって一部が自動化され、そこにAIエージェントが加わったことで、 Issueに自然文で起票 → AIがコードを修正してPRを作成 → レビュー → マージ という形にまで進化しました。「IssueOpsという土台は以前からあり、AIがそれを加速させた」というのが、この1〜2年の変化を一番よく表しているように思います。コントリビュートする側に求められるハードルが「自然文を書くこと」まで下がったことで、これまでリーチできていなかった人たちからの貢献が生まれています。 一方で、AIのコスト負担がリポジトリを持つ側に偏ってしまったり、意図とズレたPRが生成されてしまったりと、新しい種類の課題も出てきています。それでも全体として見れば、チームの内外でのコラボレーションを活性化させる、良い方向に進んでいるのではないかなと思っています。 まだまだ事例は増え続けると思います。何かインナーソース関連を見かけたらまた書きたいと思います。

はじめに こんにちは！ ニフティ株式会社、エンジニア定例運営の石田、高垣です。 ニフティでは毎年エンジニアの新人研修を先輩エンジニアが 内製 で行う文化があります。 （通称、 エンジニア定例 と呼ばれています） 開催期間としては短期集中的に5月末~6月中旬に実施し、準備は2か月前後で行います。 2023年から毎年資料の一般公開に取り組んでおり、今年も同様に一般公開いたします。 前年： ニフティ株式会社 エンジニア新人研修の内容を公開します | 2025年度版 新人研修の狙い ニフティ全体の技術力向上 体系立った基礎学習 チームでのサービス開発 短期的なサービス運用 生徒から講師による継続的運用 内製力の強化 育成強化 Webサービスを開発する上で必要なスキルを体系立てて学んでもらう スキルアップ 業務では学べない技術を積極的に取り組んでいく 今回の公開講義資料について 研修の到達目標として、「Webアプリケーションを独力で開発、クラウド上でリリースできるレベルの知識、技術力を身に付ける」を掲げており、それに伴う講義を行っています。 前年から追加された「生成AI」の講義は、最新動向を反映した内容にアップデートしています。 AIをチャットとして使うだけでなく、開発ワークフローに組み込んで業務を効率化することをゴールに、AIツールの紹介から GitHub Copilot を使った実践、注目を集めている MCP や Skills の説明までを扱っておりますので、ぜひご覧ください！ また、前年の「オブジェクト指向」の講義は、「Webアプリ開発」の内容の一部を取り込み、「設計入門 2026」として再編しました。オブジェクト指向からアーキテクチャまで、設計の考え方を体系的に学べる内容です。 それでは、以下公開可能な講義資料を掲示しますので、学習にお役立てください。 講義資料一覧 Git 2026 AWS 2026 サーバ運用入門 2026 コンテナ 2026 データベース 2026 セキュリティ 2026 生成AI 2026 設計入門 2026 Webアプリ開発 2026 モバイルアプリ 2026 ※ニフティ社内の開催日順で記載しています。 終わりに ニフティでは、長年にわたり内製の新人研修プログラムを継続しています。 今年も生成AI講義のアップデートや「設計入門」への再編など、時代に合わせた改善を行いました。こうした改善を支えているのは、前年度の新入社員が翌年には講師を務める循環型の仕組みです。学びを次の世代に還元しながら、研修全体の質を毎年高めています。 私たち自身、去年は受講者だったこの研修で、今年は資料作成を担当しました。「どこが分かりにくいか」を受講者目線で考えながら資料を作る中で、去年は曖昧なまま流していた部分に気づき、理解を深め直すことができました。これはこの仕組みならではの魅力だと感じています。 公開した講義資料が、皆さまの学習の一助になれば幸いです。 弊社のエンジニア育成への取り組みや、最新の技術動向について詳しく知りたい方は、ニフティエンジニアブログをぜひご覧ください。  

はじめに こんにちは！新卒一年目の関澤と福井です。 技術研修の一環として、AWS JumpStart 2026に参加してきました！この記事では、2日間のプログラム内容と、グループワークで設計したECサイトのアーキテクチャ、参加した感想を紹介します。 参加目的 参加前は、EC2やRDS、S3といったAWSサービスの名前や役割は知っていても、それらを実際のシステム要件に合わせてどう組み合わせればよいのかまでは、具体的にイメージできていませんでした。可用性・スケーラビリティ・セキュリティといった非機能要件を、どのようにアーキテクチャへ落とし込むのかを学びたいと考えていました。 AWSのサービスを個別に覚えることではなく、「どのような要件に対して、なぜその構成を選ぶのか」という判断基準を身につけるために、本イベントに参加しました。 AWS JumpStartとは AWS初学者のエンジニアを対象とした実践的な研修プログラムです。事前学習と2日間の集中的なオンラインワークショップを通じて、AWSへの理解を深めます。単なるサービスの学習にとどまらず、要件に合わせてアーキテクチャを検討・設計するところまで行います。 本プログラムのゴール 一般的なリファレンスアーキテクチャの理解 AWSのコアサービスの概要とその選定基準の理解 AWSのアーキテクチャ図を作成するまでの流れを知る 実施日時 2026年6月4日（木）〜 6月5日（金）の2日間 使用ツール Discord / Zoom / Miro / ハンズオン用AWSアカウント スケジュール   1日目 1日目は、フェーズに応じたアーキテクチャ設計の講義と、Webアプリケーションを構築するハンズオンを行いました。 午前 講義：1人から1000万人までのアーキテクティング AWSソリューションアーキテクトの方より、Webアプリケーションをスケール（拡大）させていく際のアーキテクチャ設計について講義していただきました。サービスの利用ユーザーが数十人規模のプロトタイプから1000万人規模の大規模システムまで、フェーズや目的によって目指すべき構成が全く異なることを確認しました。 講義では以下のような利用ユーザー数に合わせたフェーズごと設計のポイントを学びました。 プロトタイプ期（- 100人） ：限られたユーザーの利用が想定されるフェーズです。Amazon EC2 + Amazon RDS + Amazon Route 53のようなシンプルで安価な構成になります。この時点では、可用性・拡張性は考慮しません。 成長期（- 10,000人） ：サービスを一般向けに公開するフェーズです（午後のハンズオンで扱う）。「障害は起きるものと考え、起きても止まらないように設計する」という Design for Failure の思想に基づき、単一障害点を排除します。具体的には、Webサーバーとデータベースを分離し、ALBで負荷分散しながら複数のAZに冗長化します。 拡大期（- 1,000,000人） ：多数のユーザーが快適に利用できるように改善するフェーズです。Auto Scalingによるコスト最適化、Amazon ElastiCacheによるキャッシュ、計測・分析・改善のサイクルなどを導入します。 成熟期（それ以上） ：さらに意識して計測・分析・改善のサイクルを回すフェーズです。可用性や拡張性が強く求められるのはもちろんのこと、組織や運用もスケールする設計が求められます。非同期処理化や、NoSQLの利用、運用オペレーションの自動化などの改善をし続ける必要があります。 午後 ナビゲータとドライバーに分かれて以下の構成を目指し、コンソール上でのハンズオンに取り組みました。 単に手順通りにリソースを作成するだけでなく、AWSコンソール上での操作に慣れることと、それぞれのサービスがなぜこの構成に含まれているのかを理解することを意識しました。 1. ALB(Application Load Balancer) インターネットからのリクエストを受け取り、複数のアプリケーション実行環境へ分散する役割を持ちます。 単一のサーバーに依存せず、障害時にも正常な環境へ通信を流すための構成であることを理解しました。 2. ECS + Fargate（Amazon ECS on Fargate） アプリケーションをコンテナとして実行する環境です。 サーバー自体の管理を意識しすぎずに、アプリケーションを動かす仕組みを構築できる点を学びました。 3. RDS（Relational Database Service） アプリケーションのデータを管理するデータベースとして利用しました。 アプリケーション層とデータベース層を分けることで、それぞれを独立して管理・拡張しやすくなることを理解しました。   2日目 アーキテクティング 1日目に学習した内容を振り返るためのクイズワークショップから始まり、提示されたシステム概要からAWS構成図を作成するアーキテクチャ検討ワークショップに取り組みました。 クイズワークショップではAWSコアサービスの特徴を理解できただけでなく、 ”想定しているユースケースごとにアーキテクチャの最適解が変わる、複数存在する” という重要な知見を得ることが出来ました。丁寧に解説をしていただいたおかげで回答として提示されたものがより適している理由、自分の回答が最適となるユースケースを理解することができました。 アーキテクチャ検討ワークショップではクイズワークショップで理解した”ユースケースごとにアーキテクチャの最適解は変わる”ことを意識して取り組みました。言い換えればアーキテクチャを考えるにはユースケース、機能要件・非機能要件を具体的に想定することから始める必要がありました。 午前中は個人でアーキテクチャを検討し、午後はチームメンバー(各チーム5人ほど)ですり合わせて一つの構成図を作成しました。 福井チーム 想定するユースケース・要件 対象: 国内ユーザー 負荷特性: 多数の同時アクセスに耐えうるトラフィック制御とオートスケーリング 構成要素: 商品画像等の静的ファイルを大量に配信 決済・配送・在庫管理は外部サービスと連携 工夫した点 1. 高可用性・冗長性の確保 マルチAZの構成 VPC内に2つのAvailability Zone（AZ）を設け、Web/App層（Amazon ECS/Fargate）およびDB層（Amazon Aurora）を双方に分散配置することで、単一障害点を排除し、高い可用性と耐障害性を実現しています。 データベースの読み書き分離と可用性向上 Amazon Auroraを採用し、片方のAZにWriter（書き込み）、もう片方のAZにReader（読み込み）を配置しています。 データのレプリケーションによる冗長性を確保するとともに、読み込み処理を分散してデータベース全体の負荷を軽減・高速化しています。 2. パフォーマンス最適化と負荷分散 CloudFront × S3 によるキャッシュ・静的コンテンツの配信最適化 静的コンテンツは Amazon S3 に格納し、前段に Amazon CloudFront を配置することで高速配信を実現すると同時に、オリジンサーバーへの直接的な負荷を大幅に削減しています。 ALBによるアクセス分散 Application Load Balancer (ALB) を導入し、各AZに展開された Amazon ECS (Fargate) タスクへトラフィックを均等に分散。突発的なアクセス増加にも耐えうる構成としています。 3. セキュリティと認証の強化 エッジセキュリティ（AWS WAF） CloudFrontの前段に AWS WAF を設置し、Webアプリケーションへの不正アクセスや悪意ある攻撃（SQLインジェクションやXSS等）を最前線で防御します。 認証基盤の統合（Amazon Cognito） ユーザーの認証・認可処理を Amazon Cognito に委任することで、安全かつスケーラブルなユーザー管理を実現しています。 ネットワーク分離（Public / Private Subnet） コンテナ（ECS）やデータベース（Aurora）などの主要リソースはすべてプライベートサブネット内に配置。インターネットからの直接アクセスを遮断し、NAT Gateway 経由で必要な外部通信のみを許可する堅牢な構成にしています。 改善点 現場・実運用における問題意識 実際の障害ではAZが完全に停止するよりも「不安定に繋がり続ける状態（部分障害）」が発生しやすく、ALBでは2AZ構成の際に手動で切り離すことが不可能であるため、2AZ構成では障害AZにアクセスの半数が流れ続けてしまうリスクがある。3AZ構成にすることで手動での切り離しを可能にすると同時に影響を1/3に抑え、より堅牢な耐障害性を確保するようにすべき。 ログ取得・監視基盤の拡充 アクセスログやアプリログを取得・集約し、運用監視や監査ができる仕組みを導入する。 セキュリティ対策の高度化 脆弱性診断の導入や脅威検知など、セキュリティリスクへの継続的な対策の組み込み。 関澤チーム 想定するユースケース・要件 私たちのチームは「ユニコーン（本物）を売るECサイト」という空想的な設定で検討を進めました。アイデアを出してくれたのは、企画が得意な非エンジニアの方で、こういう突飛な設定でアーキテクチャを設計できるのはJumpStartならではでした。 最終的には、このテーマに「特定時間にアクセスが集中するECサイトを構築する」「顧客アカウントのセキュリティを厳重にする」といった各メンバーの要件をまとめて、可用性、セキュリティ、運用面などを重視したアーキテクチャを設計しました。 どう設計したか 設計した構成は、ユーザーのリクエストが上から下へ絞り込まれていく形です。リクエストの経路を辿りながら各構成要素の役割を紹介します。 Amazon CloudFront + AWS WAF ユーザーのリクエストが最初に到達するのは CloudFront です。ここに WAF をアタッチし、明らかに不正なリクエストを入口で遮断します。当初は WAF をどこに置くべきか迷ったのですが、攻撃をできるだけ手前で落とすほど後段への負荷が減ると整理できました。 WAF を通過したリクエストのうち、商品画像などの静的ファイルは、アプリケーションに届く前に CloudFront のキャッシュ、あるいは Amazon S3 から直接返します。静的なデータとアプリサーバーを切り分けることで、配信をエッジに寄せてオリジンの負荷を大きく削減できると気づきました。 Application Load Balancer（ALB）+ AWS Fargate（ECS on Fargate） 動的な処理は ALB を経由し、2つのAvailability Zoneに配置した Fargate のタスクへ振り分けられます。Fargateを選んだのは、サーバー自体の管理を抱え込まずに済み、アクセス増加に合わせて台数を伸ばしやすいためです。またALBについては、単なる負荷分散としてではなく「AZ障害が起きたときトラフィックをどう逃がすか」を考える起点として捉えるようになり、1日目に学んだDesign for Failureを自分たちの構成に落とし込めた実感がありました。 データベース ECサイトのデータは「読み書きが激しく、多少の遅延や反映の遅れを許容できるデータ」と「1件のずれも許されないデータ」に分かれます。1つのDBで両方を賄うと、どちらかの要件を犠牲にするため、性質ごとにストアを分けました。 Amazon DynamoDB ：大量・高速アクセスが求められるキーバリュー型データ（カート・商品カタログ） Amazon Aurora ：整合性が重要なリレーショナルデータ（ユーザー・注文・支払い・在庫） Amazon ElastiCache ：セッション管理とキャッシュ。Auroraの読み込み負荷を軽減 工夫した点 可用性 1つのリージョン 内に AZを2つ 設けるマルチAZ構成にし、リソースを両AZに分散配置しました。片方のAZに障害が発生してももう一方のAZで処理を継続できるようにし、単一障害点を排除することを目的としています。また全世界で使われるサービスのため、リージョンは最もアクセスの多い地域に置く想定です。 セキュリティ ログインや会員情報の扱いは Amazon Cognito に委ねています。「顧客アカウントのセキュリティを厳重にする」という要件に対して、認証を自前で実装するより、実績のあるマネージドサービスに任せるほうが安全だと判断しました。 スケーラビリティ アプリケーションが ステートレス であることを目指しました。セッション情報などの状態を外部（ElastiCache）に保存しておけば、1つのタスクが落ちてもALBが正常なタスクへリクエストを流せるうえ、Auto Scalingでタスクを増減させても、どのタスクでも同じリクエストを処理できます。 Auto Scaling によりFargateタスクを自動で増減させ、特定時間の急激なアクセス集中に対応しました。 運用・ログ管理 ログ管理は演習中に追加要件として提示されたもので、 Amazon Bedrock に質問したり、他のベストプラクティスを参考にしたりしながら、見様見真似でアーキテクチャに組み込んでいます。 最終的には Amazon CloudWatch でログを収集し、Lambdaで「異なるログフォーマットの変換」と「保存するログの取捨選択」を行い、S3へ格納する形にしました。さらにAuroraから QuickSight につなぎ、マーケティングチームが分析できる基盤も構成しています。 改善点 アクセス集中への対応強化 Auto Scalingのスケールアウトには数分かかるため、特定時間に集中するアクセスに対してはスケジュールドスケーリングによる事前のタスク増強を組み合わせるべきでした。また、スケールするのはFargateのみでボトルネックはDB側に移るため、そちらの対策も考えられたらよかったです。 WAF配置の見直し 今のWAFの配置だとALBへの直接アクセスを防げないので、セキュリティを重視するならCloudFrontとALBの両方にWAFを設定する、あるいは、ALB側でCloudFront経由のリクエストのみを受け付けるよう制限するべきでした。 感想 福井 私たちのグループにはAWSに詳しい方がいなかったので、各サービスについて調べ、不明点は運営の方々に質問しながらアーキテクチャを検討しました。そのおかげで、今まで曖昧にしたままだったAWSサービスの役割や使いどころを理解し、知識を定着させることができました。 特に印象に残ったのは、アーキテクチャ設計には決まった正解が1つあるわけではなく、想定するユースケースや重視する要件によって最適な構成が変わるという点です。可用性、アクセス集中への対応、セキュリティなど、 何を重視するかによって選ぶべきサービスや構成の優先度が変わるため、まずは要件を具体的に考えることが重要 だと感じました。 また、ALBやマルチAZ構成、CloudFront、S3などのサービスについても、単に名前や役割を覚えるのではなく、それぞれが どの課題を解決するために使われているのか を意識できるようになりました。改善点の検討では、2AZ構成であっても部分障害時には障害のあるAZにトラフィックが流れ続ける可能性があるなど、 実運用で起こり得る障害パターンまで考慮 する必要があることを学びました。 2日間と短いイベントでしたが、多くの学びがありました。今後AWSを利用したシステムや構成図を見る際には、「どの要件を満たすためにその構成になっているのか」「なぜそのサービスを選んでいるのか」を意識して見ていきたいです。また、今回の構成図に入れていないサービスについても調べ、実務でも活かせる知識として深めていきたいです。 関澤 2日間を通して知らないことだらけで、まさに調査の連続でした。それでも、調べた知識をすぐにハンズオンや設計課題で試せる流れになっていたため、AWSのサービスについてインプットとアウトプットを繰り返しながら学べる非常にいい機会になりました。 特に印象に残ったのは、システム停止に直結する「単一障害点」を排除する Design for Failure の設計思想です。1台のサーバーにすべてを集約する構成から始まり、Webサーバーとデータベースの分離、マルチAZ構成による冗長化へと、フェーズに応じて構成を進化させていく考え方はクラウドサービスならではでした。 また、チームでの設計や他チームの成果発表では、同じような要件に対しても様々なアーキテクティングの工夫があり、参考にしたい点が数多く見つかりました。目的やフェーズによって最適な構成は変わるという考え方は、今後の実務にも活かしていきたいです。  

はじめに こんにちは。普段は@niftyトップページの開発運用をしている宮本です。 最近 git worktree で並行して開発していたところ、 .terraform や node_modules フォルダが大量に作成され、気づいたらPCのストレージが限界に近づいていました。便利で多用していたのですが、掃除をしないと思わぬ落とし穴がありますね。 さて、今回の記事では自分が開発運用担当している一部のサイトで利用しているAmplifyについて、1年以上運用してみた感想について紹介させていただきます。 AWS Amplify AWS Amplify （以下Amplify）はフロントからバックエンドまでを一括で管理できるマネージドサービスです。 サイト運用に必要なAWSリソースを裏側で準備してくれるだけでなく、Gitリポジトリと連携することでブランチごとのサイトの状態を確認できたりすることが大きな特徴です。 前提 この記事ではAmplifyを利用してサイトを1年以上運用してきた経験を元に記述していますが、以下のようなサイトを運用しています。 Astro製SSGのWebサイトの運用がメイン Next.jsを用いたSSRは一部サイトのみ利用 CognitoやDynamoDBなどの各種AWSリソースの利用は無し GitHub連携を利用 AWS Amplify CLIは未利用 特にAmplifyを利用する際に大きな利点となりそうな他のAWSリソースとの組み合わせは試したことがないため、これについては触れません。 便利だった点 手軽にサイトを立てることができる PRごとに自動でサイトを作ることができる ブランチごとに環境変数を設定することができる Basic認証が機能として用意されている 手軽にサイトを立てることができる Amplifyを作成してビルド設定のファイルを用意してリポジトリと接続するだけでサイトを作れるため、特にSSRを用いるサイトだとコンテナ周りの煩雑な準備をせずに済むのが楽でした。 一方で、以下のような条件が重なった場合は必ずしも最も手軽とは言い切れないようにも感じました。 単純なs3+CloudFrontのみで事足りるようなSSGサイト AWS CDKなどのIaCツールを利用して運用することを前提にしている 特に単純な静的サイト用のIaCコードは簡単にAI生成できるため、リソースの準備は比較的容易です。リソースに加えてサイトのビルド+アップロードの構築もありますが、これもGitHub Actionsを用いることで比較的簡単に準備できると感じました。 PRごとに自動でサイトを作ることができる Amplifyを使っていて特に便利だった機能です。 コード変更をしてPRを提出した際、PRごとに専用に新しく割り振られたドメインでサイトの確認が可能になります。 マージ前に変更内容を確認するために、ローカルでブランチを切り替えずとも確認できるサイトが自動でデプロイされるのはとてもありがたかったです。 この辺りを自力で作ろうとするのはかなり大変なので、明確にAmplifyの利点だと感じました。 ブランチごとに環境変数を設定することができる 本番・ステージング・開発環境と複数の環境を常に用意していると、環境によってサイト自体の動作を変更したいケースがあります。 担当しているサイトではCMSを用いて運用していたため、一部の環境では本番公開前のデータを取得し、また開発環境では開発環境のCMSからデータを取得したいということがありました。 このときAmplifyアプリそのものを分けずともブランチごとの設定で分けられるのは便利でした。 Basic認証が機能として用意されている 本番環境以外を一般公開しないようにするため、デフォルトでBasic認証を仕掛けることができるのは便利でした。 デフォルトで組み込まれていない場合はWAFを設定したり、前段にCloudFrontを用意した上でCloudFront Functionsで制御する等々が必要になり、またブランチやPRごとに自動で作成されるサイトには追加することができないため一気に扱い辛くなっていたと思います。 詰まった点・もう少し便利だと嬉しい点 リダイレクトでワイルドカードを利用できる箇所が限られる IaC管理しようとするとやや複雑 ビルド通知を使いやすくしようとするとやや手間がかかる ビルド時のログを出力できない Git上のブランチに必ず依存する IaC管理しようとするとやや複雑 基本的にリソースは全てIaCで管理するようにしているのですが、Amplify自体の管理がやや複雑でした。TerraformとAWS CDKどちらも利用して作成したことがありますが、Amplify管理についてはこの二つの差はあまり感じませんでした。 IaCで管理しようとした場合、Amplify本体のリソースとブランチごとの環境を定義する必要があり少々記述量が多くなります。また、GitHubリポジトリとの接続でリソース作成時はPAT認証が必要になるなど、引っかかる点もありました。 この辺り、簡単にリソースを作成して煩わしさを省くためのAmplifyなので、厳格さを求めるIaCとは若干相性が悪いようにも感じました。 ビルド通知を使いやすくしようとすると手間がかかる Amplifyのビルド通知は、デフォルトではemailのみ対応しています。効率を考えるとslack等に流したいですが、機能としては存在しません。 ビルド自体はEventBridgeをトリガーに検知することができるため、そこからLambdaなどを使うことで通知することはできます。興味がある方は 以前書いた記事 をご参照ください。 ただ、そもそも必要なリソースを設定一つで用意できるのがAmplifyの利点にもかかわらず、別途細かい仕様を把握しリソースを作る必要があるという点が少々煩わしく感じました。 ビルド時のログをCloudWatchに出力できない Amplifyは連携されたコードを元に、Amplify上でコードをビルドしたものをサイトとして公開します。ここで厄介なのが、ビルド時のログそのものはAmplifyのコンソール画面でしか確認できない点です。 SSRでアクセス時に出力されるアプリケーションログはCloudWatch Logsに出力することができますが、ビルド時のログはCloudWatch Logsには出力されません。 よってSSGのサイトなどでビルド時にデータ取得に失敗した場合なども、どこで異常が発生したのかコンソールからたどる必要がある点が運用を考えると少々手間です。 もっとも、これについてはGitHub actionsなどでビルドする場合も同じかもしれません。普段AWSを使っているとCloudWatch Logsからアラートを流しているからこそ、少々物足りなく感じた部分もありました。 Git上のブランチに必ず依存する AmplifyのデプロイはGit上のブランチに紐づいていて便利ですが、このブランチがなくなると環境が消えてしまいます。 本番稼働ブランチなど設定することはできますが、特に保護されているわけでもなく依存しているブランチが消えた場合は該当のブランチの環境は容赦無く削除されます。 よって、本番で動作しているブランチについては確実にGitHubのブランチ保護のルールを仕掛けましょう。初歩的すぎてAmplifyを使わずとも注意すべき当たり前のことではありますが、Amplifyの場合はブランチの誤削除がダイレクトにサイトそのものの存在と直結します。そのためリスクは普段以上に大きく注意が必要です。 特に多くのサイトを管理している場合、うっかり一つでも保護漏れがないか注意しましょう。 まとめ 正直なところAmplifyの機能のさわり程度しかまだ利用していませんが、さわり程度でもPRプレビュー機能などかなり便利に感じる箇所は多いです。ECSで動作させているサイトでPRごとに環境を用意しようとした場合、環境の準備はもちろんデプロイトリガーの用意など考えることは多く、これを設定のチェック一つで実現してしまう点は非常に強力に感じました。 一方で物足りなく感じる点もあり、ビルドログやビルド通知などAmplify内で多くのことを自動的に処理してしまっているからこそ、そこをカスタマイズしようとすると思った以上に手間がかかったり、そもそも対応できないケースなどが出てきます。 この辺りは単にサイトをデプロイするだけでなく運用も踏まえて考えないと後から躓くポイントになりかねないので、少々厄介なポイントだと思います。 とはいえAmplify自体の機能アップデートも続いており、例えば以前はAmplifyにWAFを直接紐づけられなかったのですが、これも2025年にはGAされています。今後も不便に感じていたポイントがアップデートで解消される可能性もあるので、機能アップデートには注視していきたいです。 参考 https://aws.amazon.com/jp/amplify/

ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。 今回インタビューするのは、中途採用の強化を目的に、ニフティのエンジニアの考え方や働き方などについて発信する「採用ブランディングワーキンググループ」のメンバー。具体的な活動内容について語ってもらった前編に続き、後編ではチーム外活動を行うモチベーションや本業との両立、今後チャレンジしてみたいことについて聞きました。 本業では接点のない他部署のメンバーと活動できることもモチベーションに みなさんが本業とは別に、採用ブランディングワーキンググループ（以下、採用WG）に参加しようと思われたきっかけと、活動を続けるモチベーションを教えてください。 S.S.さん きっかけは、採用WGから「活動に興味ありませんか？」というアンケートが回ってきて、なんとなく「はい」と回答したらD.K.さんからスカウトされました（笑）。最初は正直「どっちかというと、『はい』かな？」くらいの温度感でしたが、当時からTech Bookを作りたい気持ちはあって、採用WGに入ることで結果的にそれが叶ったのはよかったですね。 モチベーションは、シンプルに言うとニフティの魅力を外部に伝えることですね。私は中途入社なのですが、入ってみたら想像以上に良い会社だなと思う反面、それがあまり外部には知られていない気がして。自分も何かしらの形で発信したいなと。 S.H.さん 私は今年で新卒2年目なのですが、1年目の時に”NIFTY Tech Day” という会社主催のイベントに運営として携わりました。そこで、「社外の人に、ニフティのことをどうやって知ってもらうか」ということに興味を持ったのが、採用WGに入ったきっかけの一つです。また、もともと興味があった『NIFTY engineering』のブログも採用WGが運用しているということだったので、ぜひ参加したいと。 K.R.さん 私もきっかけはブログですね。所属部署に採用WGでブログを運営しているメンバーがいて、「興味ないですか？」と声をかけられて。私自身、入社前からブログを読んでいて、更新頻度も高いし内容も面白いし、これに携われるのは面白そうだなと。最初は結構、ノリで参加してしまったような感じですね。 採用WGには本業では交流する機会がない、他部署のメンバーもたくさん集まっているので、色んなスキルや考え方を持った人とディスカッションしながら運用するのは楽しいですし、活動を続けるモチベーションになっています。あと、ページビューを毎週チェックしているのですが、記事がバズったりすると単純に嬉しいです。 本業とうまく両立しながら、チーム外活動でも成果を出す みなさんは所属部署での「本業」をこなしながら、採用WGでも活動されています。両立は大変じゃないですか？ D.K.さん 私は管理職なので、ある程度は自分の裁量で業務をコントロールできます。とはいえ、最近は本業の方で負荷のかかる案件を抱えていて、採用WGでの活動量が減ってしまっていますね。理想的には業務時間全体の3割から4割くらいを採用WGにあてられると、もっと色んなことができるのかなと思います。 3割から4割をチーム外活動にあてるとなると、それなりの成果も求められますか？ D.K.さん そうですね。正直、「採用のためのブランディング」って、分かりやすい成果を示すことが難しい活動ではあるので、そこは今後の課題でもあります。ただ、K.R.さんもそうですが、キャリア採用で入社した人が「事前にブログを読んで、ニフティに興味を抱きました」と言ってくれるケースも増えているので、こうした事例をどんどん増やしていきたいですね。 そのK.R.さんは、本業との両立というところはいかがですか？　うまくやれていますか？ K.R.さん 今のところ、あまりうまくいっていないですね。やはり本業が忙しくなると、どうしてもチーム外活動は後回しになってしまいます。ただ、どうしても参加が難しい時期は、採用WGの他のメンバーがフォローしてくれますし、逆に私がフォローに回ることもある。良い意味で、「お互いさま」という感覚が共有できているのかなと。理想としては、毎日30分だけでも採用WGの活動に時間を使えたらいいですね。自分自身もニフティのことが分かってきて、発信したいことも増えてきましたから。 S.S.さん、S.H.さんはいかがでしょう？ S.S.さん 両立に関しては、それなりにうまくいっていると思います。というのも、所属部署に共有する個人目標の項目に採用ブランディングの活動を入れていて、活動時間もあらかじめ確保しているんです。私に限らず他のメンバーも個人目標を立てていて、「この週は個人目標のために時間を使っていい」といった具合に、ある程度の融通が効くので両立はしやすいですね。 S.H.さん 私は所属部署での業務と採用WGでの活動に加え、もう一つ別のチーム外活動にも参加しています。そのため、採用WGに割ける時間は全体の1割程度になってしまっているのが実情です。限られた時間のなかでも成果を出すために、スケジューリングはかなり意識していますね。何をいつまでにやればいいか、綿密に計画を立てて実行しています。所属部署の上長はむしろ「どんどんやっていいよ」と背中を押してくれるくらい、チーム外活動に対して理解がありますし、そこで出した成果についても評価してくれます。私からも、「今はこんな活動をしています」とこまめに報告をしているので、やりやすい環境が作れているのではないかなと。 社外のエンジニアと接点を持ち、ニフティの魅力を継続的に発信していく 採用WGとしての今後の活動方針や、展望を教えてください。 D.K.さん 現在は人事と連携し、イベントなどを通じて接触のあった外部エンジニアの方などと、継続的に接点を持てるような仕組み作りを考えています。ニフティがイベントをやる時に案内をお送りしたり、ブログが更新された時にメールで告知したり。それくらいの、やや緩いつながりから徐々にニフティに関心を持つ人を増やしていけたらと。そうすれば、ブログなどのコンテンツや、社員のイベント参加などもより生きてきますし、メンバーも今以上にやりがいを持って活動してくれると思いますので。 ありがとうございます。では、最後にお一人ずつ、採用WGで今後チャレンジしたいことを教えてください。 S.S.さん 個人的には『Nifty Tech Book』の続編を作りたいと思っています。また、以降も4冊目、5冊目と号を重ねていきたい。私がずっと編集長をやるのではなく後輩に受け継いで、いずれはニフティの文化にしていきたいですね。 S.H.さん 今は採用WGから一方的に「こんな社外イベントありますよ。参加しませんか？」と情報発信していますが、今後は社員一人ひとりが自発的に面白そうなイベントを見つけて、社内にシェアするような状態にしていきたいと考えています。多くの人が社外イベントに関心を持って、参加もするし、他の人にも呼びかける。そうした循環ができていくと、ニフティ全体の発信力が高まり、認知度も上がっていくと思いますので。 K.R.さん まずは、もっと多くの人にブログを読んでもらいたいと思っています。これまでにも毎週のミーティングで記事の振り返りを行っていますが、ページビューが増えた要因などは深く分析できていないので、今後はそこの時間を割いて、色んな施策を試してみたいですね。 D.K.さん ブログに関しては、私自身ももう少し記事を書かなきゃいけないですし、私と同じレイヤーのマネージャー陣にも執筆してもらいたいと思っています。 K.R.さん 本当に書いてほしいです。やっぱり、マネージャーが普段どんなことを考えているのか、知りたい人はたくさんいると思うので。 D.K.さん はい、がんばります（笑）。 では最後に、採用WGとして、この記事を読んでくださっている社外のエンジニアの方へ何かメッセージはありますか？ D.K.さん ニフティでは、オンラインでのカジュアル面談も実施しています。「選考前にニフティのこと、業務内容など気になっていることを知りたい」「いきなり応募するのは不安」という方向けの面談ですので、少しでもニフティにご興味がある方は、ぜひお気軽にお申し込みいただきたいです。 カジュアル面談はこちらから https://open.talentio.com/r/1/c/nifty/pages/114049 前編もご覧ください！ 今回はニフティの採用ブランディングワーキンググループのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】ニフティで働く人の魅力や働き方、技術力を社外に発信。転職市場で選ばれる会社に【ニフティ 採用ブランディングワーキンググループ前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。 これまでにも、「オンラインサポートチーム」や「AI活用促進チーム」などの社内活動を紹介してきました。今回は、中途採用の強化を目的に、ニフティのエンジニアの考え方や働き方などについて発信する「採用ブランディングワーキンググループ」の取り組みを紹介。メンバーたちに、具体的な活動内容を聞きました。 自己紹介 D.K.さん 2003年4月に新卒入社。所属部署での業務内容はWebサービスの開発、運用チームのマネージャー。採用ブランディングワーキンググループでの役割は「まとめ役」。趣味は老舗の甘味屋巡り。 K.R.さん 2025年5月に中途入社。所属部署での業務内容はオプションサービス（セキュリティサービスなど）の開発、運用。採用ブランディングワーキンググループでの役割はエンジニアブログの運営。趣味はバレエ鑑賞。 S.H.さん 2024年4月 に新卒入社。所属部署での業務内容は自社コールセンターのシステム運用・開発。採用ブランディングワーキンググループでの役割は社外イベントへの参加促進。趣味は料理とプログラミング。 S.S.さん 2023年3月 に中途入社。所属部署での業務内容は「@nifty auひかり」申込システムの開発運用。採用ブランディングワーキンググループでの役割は新規企画の立案実行。趣味はボードゲーム、テニス。 ニフティのエンジニアが持つ知見や技術、考え方を発信し、転職市場で選ばれる会社に みなさんはそれぞれの所属部署での業務とは別に、チーム外活動として「採用ブランディングワーキンググループ（以下、採用WG）」にも参加されているとお聞きしました。はじめに、所属部署と採用WGでの役割を教えてください。 D.K.さん 所属部署では、ニフティのWEBサービスの開発や運用をするチームでマネージャーをしています。採用WGには立ち上げ時から関わっていて、現在は取りまとめ役としてメンバーの活動をサポートするのが主な役割ですね。 K.R.さん 普段はサービスシステムグループという部署に所属し、オプションサービス（セキュリティサービスなど）の開発、運用に携わっています。採用WGでの役割は、『NIFTY engineering』というブログの運営。このインタビュー記事もまさにそうですが、ニフティ社員の様々な活動を発信しています。 S.H.さん 所属部署での業務内容は、自社コールセンターのシステム運用・開発です。採用WGでは、ニフティのエンジニアの認知を上げる活動を行っていて、特に力を入れているのは、社外で開催されているイベントへ社内のエンジニアに参加してもらうための呼びかけやサポートです。 S.S.さん 普段は「@nifty auひかり」という回線サービスの申込システムの開発、運用に携わっています。採用WGでの役割は新規企画の立案と実行。採用強化につながる新しい施策を考え、実践していくのが主な活動ですね。 ありがとうございます。そもそも、この採用WGはどのような目的で発足したのでしょうか？ D.K.さん ニフティってもともと新卒入社の割合が多い会社なのですが、全社的に開発力や組織力を底上げしてくためには新卒だけでなく、力のあるエンジニアの中途採用にも力を入れていくべきだろうという話が、数年前から持ち上がっていました。 そのためには、改めてニフティという会社が何をやっているのか、社内のエンジニアがどんな仕事をしているのか、広く周知する必要がある。当時の私の上長がそんなアイデアを持っていて、有志を中心に採用WGが立ち上がり、活動がスタートしたのが4年ほど前ですね。 ただ、D.K.さんを含む発起人のメンバーは、採用まわりのご担当ではなかったんですよね。 D.K.さん そうですね。開発の部署になります。ただ、エンジニアの採用に関して、細かい技術のことを知っている開発の人間が協力するのは不自然なことではないのかなと思います。私自身も、「どんな人材が増えると、よりよい組織になるのか」「そのためにニフティという会社や働き方、技術などをいかにブランディングすべきか」といったことに関心がありましたので、ぜひ参加したいと手を挙げました。 社内のエンジニアが寄稿する「Tech Book」で技術力をアピール あらためて、採用WGの具体的な活動内容について教えてください。 D.K.さん 20人ほどのメンバーが、複数のサブチームに分かれています。ここにいるメンバーもそれぞれ別々のサブチームに所属していて、基本的にはチームごとの活動。週1回は全体で集まる場を設けて、各チームの活動報告や、現状の課題について話し合っています。 S.S.さんは「新規企画チーム」、K.R.さんは「ブログチーム」、S.H.さんは「イベント参加促進チーム」で活動されているということですが、これまでに関わった印象深いプロジェクトを教えてください。 S.S.さん 私が印象深いのは、『Nifty Tech Book #2』という技術書を作ったことですね。ニフティのエンジニアたちに「書きたい！」と思ったことを自由に執筆してもらった技術書で、イベントの際などに無料配布しています。もともと、私が採用WGに参加した当初からやりたかったプロジェクトなので、完成した時は達成感がありましたね。 こちら、総ページ数が144ページにも上ります。本業の傍ら、これだけボリュームのある技術書を作るのはかなり大変だったのではないですか？ S.S.さん 制作当時は、かなりの時間と労力を割いていました。ただ、#2とあるように、じつは2冊目のテックブックになります。以前に別の方が『Nifty Tech Book #1』を作っていて、当時のノウハウやシステムが残っていたので、それをうまく活用することで効率よく進めることができました。 執筆者は社員の中から募集して、私は主に原稿のレビューや印刷の手配などを担当しています。 イベントなどで配布されているということですが、反響はいかがですか？ S.S.さん イベントで配布した際には、「ニフティの回線使っていますよ」といった嬉しい反応を多くいただきました。技術書としても面白い内容になっていると思いますが、ニフティという会社自体を改めて認知していただく効果も、一定程度はあるのかなと感じます。 あとは、社内の新卒採用の場面でも活用されているようで、例えば、大学訪問の際に教授にこの本を渡して、学生に読んでもらったり、つい最近も中途入社の方から「転職活動中にこのTech Bookを読んで、ニフティに興味を持ちました」という声をいただいたりもして、とても嬉しかったですね。 S.H.さん 私の同期も寄稿しているのですが、内容的にも普通にお金を取っていいくらいレベルが高い技術書になっていると感じました。この本を通じて、ニフティのエンジニアが持つ技術、レベルの高さを知っていただけるのではないかと思います。 D.K.さん 採用WGがスタートした当初はブログだけで情報発信していて、本という発想は全くなかったんです。そもそも本業を抱えながらやるには、労力がかかりすぎるため、無理だろうと思っていました。ただ、そのめちゃくちゃ大変なことにS.H.さんはチャレンジして、実際に形にしてくれた。純粋にすごいと思いますし、それくらい熱心に活動してくれているのが嬉しいですね。 ニフティのエンジニアが「社外イベント」に参加しやすい環境をつくる K.R.さんはブログの運営をご担当されていると。 K.R.さん はい。具体的には、ブログの見栄えや使い勝手を良くしたり、コンスタントに記事が投稿されるような施策を実施しています。例えば、新入社員の方にリレー形式で記事を書いてもらったり、クリスマスの時期にAdvent Calendarというテーマを立ててブログの執筆者を募ったりと、色んな企画を行ってきました。 K.R.さんはブログの運営をご担当されていると。 K.R.さん ニフティの採用サイトにも社員にインタビューした記事はあるのですが、チームでの活動にスポットを当てた記事があってもいいんじゃないかということでスタートしました。チームの考え方や、目的意識、リアルな仕事の進め方を見せることで、入社後の働き方のイメージがより湧くのではないかと。そういう私自身も、入社前に別チームのインタビュー記事を読んでいて、ニフティでの仕事により興味が湧きました。 K.R.さんはこれまでの活動で印象に残っていること、あるいは印象に残っている記事はありますか？ K.R.さん やはり記事がバズった時は印象に残るというか、素直に嬉しいです。最近では、Advent Calendarの「ファミコンのソフトを作る。Rustで。」という記事がよく読まれました。 あとは新人さんに記事を書いてもらうこともあるのですが、クオリティの高さに驚かされます。私が読んでも普通に勉強になることが多くて、読者として楽しませてもらっています。 ＜関連記事＞ ・ファミコンのソフトを作る。Rustで。 ファミコンのソフトを作る。Rust で。 では、S.H.さんはいかがですか？　S.H.さんのチームではニフティのエンジニアが社外イベントに参加しやすいよう、サポートを行っているということでしたよね。 S.H.さん そうですね。ニフティではこれまで自社イベントを積極的に開催してきた一方で、社外イベントへの参加促進にはあまり力を入れてきませんでした。そこで、注目度の高い社外イベントにどんどん参加し、会社のことやエンジニアの考え方を発信していくことで、ニフティに関心を持ってもらおうと考え、昨年からその後押しになるような取り組みを強化しています。 具体的に、どんな取り組みを？ S.H.さん まず、そもそも社外イベントに関心を持っている、参加したいと思っている社員がどれくらいいるのかを知るためにアンケートを取りました。すると、8割くらいが関心を持っていると。 かなりの割合ですね。 S.H.さん 私たちも正直驚きました。ただ、関心はあっても、「イベントの準備をする時間が取れない」「自分に合うイベントが分からない」「参加にあたって、社内申請や手続きの方法が分からない」といった課題を感じていることが分かったんです。 こうした課題をふまえ、申請のフローを明確化したり、登壇資料の作成をお手伝いしたり、その方に合いそうなイベントを紹介したりと、少しでも障壁を減らすためのサポートを行っています。 ちなみに、これまでどんなイベントに、社内のエンジニアが登壇してきたのでしょうか？ S.H.さん ニフティも協賛しているSRE NEXTというカンファレンスのセッションに、社内のエンジニアも登壇してもらいました。ちょうどSRに関する活動をしている社員がいて、こちらから参加をお願いして実現した事例ですね。 D.K.さん 社外イベントへの参加促進に関してはまだ取り組みが始まったばかりですので、これからどんどん数を増やしていきたいと思っています。いきなり「登壇しませんか？」と言ってもハードルが高いと思いますので、まずは観る側・聞く側として気軽に参加してもらうことが大事です。実際、社内のイベント参加記録を見ても、採用WGが強化の取り組みを始めてから参加者が増えていますので、少しずつ成果が出始めていると感じますね。 後編に続きます！ 今回はニフティの採用ブランディングワーキンググループのインタビューの様子をお届けしました。後編の記事は近日公開予定です。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

ニフティの開発手法はチームやプロダクトの特性によって異なりますが、現在、多くのチームで導入されているのがスクラムです。 スクラムとは、決まった期間（スプリント）ごとに価値を少しずつ届け、検査と適応を繰り返しながら進めていくフレームワークのこと。 「プロダクトオーナー（プロダクトの価値の最大化に責任を持つ）」、「スクラムマスター（スクラムの確立とチームの効果性に責任を持つ）」、「開発者」という3つの役割があり、それぞれに認定資格が存在します。今回はそのうち、プロダクトオーナーとスクラムマスターの資格を持つ、エキスパートたちにインタビュー。ニフティにおけるスクラム開発の導入事例や効果を語ってもらった前編に続き、後編では組織全体としてのスクラムの浸透度合いや、今後の課題について聞きました。 数年前の「内製化」を機に、スクラム開発へとシフト ――ニフティにおけるスクラム開発の浸透度や、導入による変化について教えてください。 西野さん プロダクトとの相性を鑑みて、あえてスクラム開発をやっていないチームもありますが、開発組織全体で見ると浸透度は高いです。スクラムマスターの資格保持者も年々増えていて、現時点で十数人。それまでにもチーム内でスクラム開発は取り入れていたけれど、より本格的にやっていきたいということで資格を取るケースもあります。 現状やっていないチームも、いったんは導入してみたけどあまりフィットせずに中止したケースや、一時は断念したけど、またトライしてみたいと私のところへ相談に来られるケースもあり、少なくとも前向きではあると思いますね。 ――以前に比べて開発組織全体でスクラム開発の導入が進んだことで、プロダクトの開発期間の短縮や、ニフティのサービスの質向上などにつながっている実感はありますか？ 清水さん そもそもの背景として、スクラム開発を導入する以前に、2018年あたりから開発を内製に切り替えていったというのが大きくて。それまでのニフティって、どちらかというとサービスのシステムは外部の開発会社の方に作っていただき、社内のエンジニアは仕様を決めたり、できあがったシステムのテストや調整だったりが主な役割でした。 私が入社したあたりから、少しずつ内製にシフトしていく動きが出てきた時に、開発方法そのものの見直しを迫られたんです。それまでのやり方は、最初に仕様をがっちり固めて外部パートナーに発注。ある程度の工期をかけてしっかり作り込んだものを最終的にこちらでテストするという、いわゆるウォーターフォール型の開発手法でした。ただ、内製でやるならスクラム開発のほうが、社内のエンジニア同士のコミュニケーションが増える利点をより活かせるのではないかと。 ――エンジニアとしてのスタンスも、大きく変わりそうですね。 清水さん そうですね。それまでは「エンジニアは企画の人に言われたことをやればいい」というスタンスでしたが、途中で違うことを言われた時に困ることもありました。最初に仕様をガチガチに固めず、小分けで実装・開発・テストを回していくスクラム開発にシフトすることでそうしたストレスも減りましたし、エンジニアのマインドセットにも影響を与えたのではないかと思います。 西野さん 私が入社した15〜16年前のニフティって、「振り返り」の文化がほぼなかったんです。せいぜい半年に一度の評価のタイミングで、それまでにやってきたことや成果を振り返るくらいで。 それがスクラムを導入して以降、早ければ1週間でプロジェクトを振り返る文化が色んなチームに根付いてきたと感じます。チーム単体のみならず開発組織全体としてもそうした動きがあり、それはスクラム文化が浸透してきたことも一因ではないかと。 吉田さん 現代のような変化が激しく複雑性の高い状況では、アジャイルな考え方が有効な場面が多いと感じています。その意味で、開発組織にスクラムが浸透してきたのは良い傾向ですが、それを真に効果的にするためには、プロダクトオーナーを輩出する企画側の深い理解が欠かせません。 単に開発側の働き方に企画側を従わせるのではなく、どうしたらスクラムのプロセスが有効なのかを一緒に考え、自分たちのプロダクトに対してアジャイルの原則と価値が機能するように落とし込んでいく必要があります。 そのあたりのはしご役は、企画側のプロダクトオーナーである私の役割だと思っています。 スクラムを開発チームだけでなく、会社全体に浸透させていく ――いま吉田さんから課題について少しお話しいただきましたが、西野さん、清水さんはいかがでしょう？　今後、ニフティのスクラム開発をより深化、あるいは企画側も含めてさらに浸透させていくためには、何が必要でしょうか？ 西野さん 吉田が言うように、スクラム導入が開発側だけで先行している点は、課題だと感じています。前回も少し話しましたが、企画と開発のフロアが別々になっていて、物理的な距離があるのも一つの原因ではあると思うので、もっと対話の機会を増やしていきたいですね。（※） 私たちポイントチームの場合は、企画側に吉田がプロダクトオーナーとして立ってくれていることもありコミュニケーションは活発ですが、他チームでも企画と開発の垣根をなくしていくことが大事です。今は「同じプロダクトに関わる組織」というだけの関係であって、企画側と開発側が一枚岩で動けているケースはそう多くないと思いますので。それができるようになると、企画と開発がそれぞれ感じているプロダクトの課題を共有できて、「その課題に対処するためにはスクラムがいいよね」といった具合に、自然とスクラム開発を導入する方向に進んでいくのではないでしょうか。 （※）インタビュー時点。2026年5月にオフィス移転し、現在は同フロアになっています。 清水さん 私も開発側の人間なのでスクラム開発を当たり前のようにやっていますが、開発組織以外の、ニフティ全体で見るとまだまだ十分に浸透しているとは言えません。特にビジネスサイドでスクラムの知見を持った人って、現状は吉田さんくらいなのかなと思っています。とはいえ、こちらがいくら「企画側もスクラムをやりましょう」とか「プロダクトオーナーの資格を取ってください」と言ったところで、課題の本質が分からないまま導入してもあまり意味がない。 吉田さんがおっしゃったように、スクラムの意味やメリットを企画側にも納得してもらうことが重要です。そのためには、スクラム開発の本質や、開発側が感じている利点、ビジネス側がそれをやることでプロダクトやサービスにどんな影響があるかといったことを言語化して、丁寧に伝えていく必要がある。それはスクラムマスターである私の役割の一つだと思いますので、ボトムアップでじわじわと組織全体に浸透させていきたいですね。 自分自身の現状を知って初めて、チームの課題が見えてくる ――最後に、みなさんが今後、ニフティのなかでチャレンジしたいことを教えてください。 吉田さん まずは自分自身が、プロダクトマネジメントというものをより理解し、実践できるようにならなくてはいけないと考えています。また、自分一人だけではなく企画側も含めた組織全体として、ニフティにあるべきプロダクトマネジメントとは何なのか、どう進めていくべきかを考え、構築していく必要がある。 そのために、たとえば開発側、企画側の上長や同僚が参加するプロダクトマネジメントの勉強会などに自分も参加しているのですが、そういった場で何かしらの発信をして、プロダクトマネジメントやスクラムに関する知見を開発以外の部署にも広げていくような活動ができればと考えています。 清水さん 先ほど話したことにも通じますが、開発内だけでなく会社の誰もが部署の垣根を超えて、自分の考えをシェアできるような場や文化を作りたいと思っています。たとえばニフティでは年2回、全社会議の場で経営陣から活動方針を伝えられるのですが、現状は一方通行というか「聞いて終わり」になってしまっているのが、もったいなく感じていて。 もっと現場の社員同士でディスカションして、「自分はこう受け取ったけど、あなたはどう思う？」といった話ができるといいのかなと。そうやって経営陣のメッセージに対する理解を深めた上で、「じゃあ自分は今期、こういう活動をしていきます」みたいなことまでシェアできると、組織全体が一枚岩になれるのではないかと思います。今はAIの活用が進み、業務時間が短縮できているので、そこで空いた時間は組織全体でもっと本質的な問いについて考えることに使いたいですよね。 西野さん チームや組織を変えるためには、まず個々のメンバーが自分自身の現状や課題に気づく必要があると考えています。自分がいま何に悩んでいるのか、何にチャレンジしたいのか、何が成長を阻んでいるのか。それが理解できて初めて、チームにも目を向けられるようになる。組織をより良い方向に変えていこうという思考が生まれる。メンバーそれぞれがチームの課題を言語化できるようになり、チーム全体にシェアされる。その結果、場合によっては課題解消のアプローチの一つとしてスクラムの導入へと至るかもしれません。 スクラムを単に形骸化したフレームワークに終わらせないためには、そうしたプロセスを踏んでいく必要があると考え、そのファーストステップとして2年前から社内コーチングを始めました。今は私だけでなく吉田と清水にもコーチングの研修を受けてもらっていて、チーム外活動としてコーチングを提供していこうと考えています。最終的にスクラムの導入というゴールに至らなかったとしても、一人ひとりが気づきを得ることで仕事へのモチベーションがアップし、組織全体の活性化にもつながっていくはずですから。 前編もご覧ください！ 今回はニフティのスクラム開発を牽引するエキスパートたちのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】サービスを発展させるために「あらゆること」をやる。ニフティのスクラム開発を牽引するエキスパートたち【スクラムマスター 前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

はじめに！ こんにちは！新卒1年目のGokuと竹下です！ 新人研修の一環としてニフティ2026年度新卒入社の11名が AWS JumpStart2026に参加しました！ この記事では2日間実施されたワークショップの内容と、 グループワークで作成したアーキテクチャ設計図を紹介します！ AWS JumpStartとは？ AWS初学者のエンジニアを対象とした実践的な研修プログラムです 2日間実施され座学やサービスの学習だけでなく、実際の要件に合わせたアーキテクチャの 検討、設計まで体験できるのが特徴です！ プログラムの到達目標 この研修プログラムでは3つの到達目標があります！ １．一般的なリファレンスアーキテクチャの理解 ２．AWSコアサービスの概要とその選定基準の理解 ３．AWSのアーキテクチャ図を作成するまでの流れを知る 日程 6/4(木)～6/5(金)の2日間 研修内容 1日目 ・AWS体験ハンズオン 　簡易的なWebサーバーの構築 　ToDo管理アプリの作成 2日目 ・AWSのサービスの機能に関するクイズ ・アーキテクティング演習 1日目 午前 午前中はアーキテクティングのコツに関する解説や、以下の2つの構成で Webサーバーの構築を行いました！ ・VPCを作成しその中にEC2インスタンスを構築する方法 ・VPCを用いずにAmplifyを利用する方法 午後 午後はチームでToDo管理アプリを動かすためのアーキテクチャの構築を行いました！ 構成は以下の図の通りとなっております。 ユーザーがアクセスした際にApplication Load Balancer(アプリケーションロードバランサー)に通されその後、各プライベートサブネットに配置されたコンテナに振り分けられる構成となっております。いわゆる冗長化構成となっており、いずれかのコンテナがダウンした場合でもシステムを利用できる仕組みです。 2日目 2日目の朝は、クイズから始まりました。 出題されたのは「システムを運用していく上で〜〜という課題があり、それを解決するためにどのような構成が考えられますか？」といった形式の問題が中心で、このあとの課題に向けた、ちょうど良いウォーミングアップになりました。 ここで得た学びは、アーキテクチャの正解は一つとは限らないということです。 もちろん模範解答はあります。ですが、今回のクイズでは「これが絶対に正しい」「これが唯一の正解」といったアーキテクチャは存在しませんでした。コストや冗長性などの観点で、それぞれにメリット・デメリットがあるのだと学びました。 アーキテクチャ図を作成する 課題の内容 まず、このような課題が与えられました。 ECサイトをローンチ予定。 大々的なプロモーションを実施しており、半年後にはリリースする必要があるが、残念ながら既存のチームメンバーが 全員退職 してしまった。 AWSを中心に開発すること以外はまだ何も決まっていないが、時間がないので、皆さんには 本日中 にAWSでのアーキテクチャを考えていただきます！ チームメンバーが全員退職……？？ 今日中にAWSでのアーキテクチャを考える……？？？ そんな、なかなか衝撃的な設定からのスタートでした。 検討にあたっては、以下のような前提も補足として提示されました。 現状の構成（自由に変更可能） バックエンド：Java / Spring Boot フロントエンド：TypeScript / React データベース：MySQL ローカルはDockerで開発中だが、コンテナは必須ではない 必須機能 商品一覧・詳細ページ カート機能・購入機能 決済・在庫管理・配送システムは外部のSaaS APIを利用する アカウント管理機能 検討してほしい項目 機能要件 ：検討した構成で、ECサイトの各要件を実現できるか？ 可用性 ：あるコンポーネントに障害が起きても、システムを継続できるか？ スケーラビリティとパフォーマンス ：今後ユーザーが10倍になったとき、同じような構成で捌けるか？ 実践 4人チームで各自がアーキテクチャ図を作成し、途中でチーム内発表を挟みながら、良いと思った案を採用してブラッシュアップしていく流れでした。 最初は、そもそもAWSのどのリソースを使えばよいのか、そしてそれらをどうつなげればよいのかが、まったく見当もつきませんでした。 そこで一度AWSのことは脇に置き、「提示された要件で、ごく普通にシステムを組むとしたら何が必要だろう？」と考えるところから始めました。 Webサーバー、データベース、アプリケーションの実行環境……。こうして洗い出した要素を、AWSのリソースに置き換えていくイメージです。 とはいえ、AWSのリソース、とくにECS on Fargate、VPC、パブリック/プライベートサブネット、ゲートウェイ周辺については理解が浅く、厳密なアーキテクチャ図を1日で描き切るのは、さすがに難しかったというのが本音です。 最終的に、私（竹下）が提案したアーキテクチャが「スケールのしやすさや冗長性の面でメリットが大きい」とチームメンバーに評価してもらい、採用されました。 竹下チームが作成したアーキテクチャ図 主なリソースは以下の3つです。 AWS Amplify インフラを意識せずにWebアプリケーションをデプロイできる、フルマネージドなサービス GitHub等と連携し、Pushするだけで自動的にデプロイしてくれる機能などがあります Amazon ECS on Fargate サーバーの管理や構築をせずに、コンテナだけを動かせるサーバーレスの仕組み Amazon Aurora Serverless v2（MySQL） 0から数十万規模までのスケールアップに対応可能な、フルマネージドなDBサービス バックエンドはマルチAZ構成にして冗長性を確保し、片方のAZで問題が発生してもELBが自動的に振り分けることで、安定的に稼働できるようにしました。 データ分析には Amazon Aurora MySQL zero-ETL integration with Amazon Redshift を活用し、Auroraに負荷をかけずにデータをRedshiftへ反映し、QuickSightで可視化できるようにしました。 全体としては、マネージドサービスやサーバーレスを中心に据え、運用負荷を抑えながら、急激なアクセス増にも対応できるように、スケーラビリティとアベイラビリティの高い構成を意識しました。 感想 Goku 今回のイベントで、初めて本格的にAWSを触りました。 特に感心したのは、EC2インスタンスを起動してWebサーバーを構築するまでが、 10分程度で完了してしまう点です。 オンプレミス環境であれば、機器の準備からOSの導入、各種設定までかなりの時間を要する作業ですが、 それがマネジメントコンソール上の操作だけで完結します。 また、保有している機器を気にすることなく大規模な構成を組んだり、 用途に合わせた小さな構成を画面上だけで組んだりできる点も印象的で、 スピードが求められる現代のプロダクト開発に適したサービスだと感じました。 EC2やS3など、名前は聞いたことがあるものの実態がわからない状態からのスタートでしたが、 主要なサービスについては、どのサービスがどのような機能を持つのかを大まかに把握できるようになりました。 今後は資格試験の学習や実務を通じて、AWSに関する知見をさらに深めていきたいです。 竹下 1日目では、EC2でWebサーバーを構築する方法と、Amplifyで同様のWebサイトを公開する方法を体験するハンズオンを行いました。 EC2もAmplifyも最終的にWebサイトを公開できる点は同じですが、公開までの工数や設定項目が異なり、EC2（IaaS）とAmplify（PaaS）の違いを実際に手を動かして理解できました。Amplifyは数回クリックするだけでWebサイトを公開することができ、あまりの手軽さに拍子抜けしてしまいました。 2日目は、チーム内で「これで合っているのかな？」「要件を満たすにはどうすればいい？」と議論するフェーズ、ドキュメントを読みながら情報を集めるフェーズ、そして実際に図を書くフェーズを行き来しました。10分に一度くらいの頻度で情報収集に立ち返り、試行錯誤を重ねながら何度もブラッシュアップしていきました。 参加時点ではアーキテクチャ図を書いた経験もなく、AWSもほとんどわからない状態でしたが、提出する頃にはFargateがどのようなものかをある程度説明できるようになっていました。 さまざまなAWSリソースを知る大きなきっかけになったと思います。

はじめまして！基盤システム部 業務基盤グループ所属のhirabayashiと申します。 2026年4月に入社し、OA機器管理・ヘルプデスクなどを担当しています。 これまでのキャリア 前職ではWebメディア企業にて、情シスとしてのキャリアを積んできました。 主な担当業務は以下の通りです。 OA環境の構築・運用 ヘルプデスク・マニュアル整備 セキュリティ対策の推進・ガバナンス強化 アカウント・ライセンスの統合管理　　　　など 社内ユーザーの利便性を保ちつつ、 安全なITインフラを支える業務全般に携わってきました。 転職のきっかけ 前職での仕事にもやりがいを感じていましたが、 ライフステージの変化とエンジニアとしての更なる成長を求め、転職を決意しました。 主な理由は 3つ あります。 内製化に強いプロダクト/組織文化への魅力 「各種システムやプロセスの内製化」 に注力している点に強い魅力を感じました。 既存ツールをそのまま使うだけでなく、 自社に最適な形を自分たちで作り上げられる環境で力を発揮したいと考えました。 「フルリモート」から「出社ベース」への働き方のシフト 前職はフルリモートが中心でしたが、 直接対面でコミュニケーションを取りながらスピード感を持って課題を解決する 「出社ベース」 の働き方に改めてチャレンジしてみたいと思うようになりました。 ライフステージの変化による挑戦の機会 子育てが落ち着いたタイミングで、 自分自身のキャリアに 再び全力でリソースを注げる環境が整ったことも後押しとなりました。 選考中について 選考を通じて印象的だったのは、 面接官（現在の上司）のお人柄とプロセスの透明性 です。 選考の各フェーズで非常に丁寧なフィードバックをいただけたことで、 会社が抱えている現在の課題や、 自分に対して何が期待されているのかが非常にクリアになりました。 「この上司・チームとなら安心して挑戦できる」 と確信できたことが、最終的な入社の決め手です。 入社後感じた会社のいいところ 実際にメンバーとして加わってみて、特に魅力的だと実感しているポイントは次の2点です。 声をかけやすく、意思疎通がスムーズな出社環境 リアルに出社しているからこそ、ちょっとした相談や雑談から課題が発見され、 その場でスピーディに解決へ動ける風通しの良さがあります。 新しいチャレンジを歓迎するカルチャー 「新しいシステムや仕組みを積極的に試していこう」 という前向きな姿勢が組織全体に浸透しています。 提案に対するハードルが低く、情シスとしても非常にやりがいを感じる環境です。 これからやっていくこと 現在は、社内環境をより快適にするため、以下の施策を中心に推進していく予定です。 AIを活用したヘルプデスク業務の効率化 問い合わせ対応の自動化やナレッジ化を進め、 社内ユーザーの利便性向上と情シス側の運用負荷軽減を両立させます。 PCキッティングシステムの再構成 セットアップフローの自動化やゼロタッチキッティングを見据え、 より迅速でミスのない受入体制を構築します。 改善と最適化 現在稼働している仕組みやシステムについて、現状の課題を洗い出し、 ユーザーにとって 「より使いやすく、便利な形」 へブラッシュアップしていきます。 最後に 当社は一人ひとりに裁量が与えられており、 「こうしていきたい」 というアイデアを形にできる環境が整っています。 「自分のやりたいことや課題意識が明確にある方」 にとっては、 間違いなく刺激的で成長できる環境だと実感しています。 情シスの領域から会社の成長を支えたい方、主体的に環境を作っていきたい方、 ぜひ一緒に働きましょう！

ニフティの開発手法はチームやプロダクトの特性によって異なりますが、現在、多くのチームで導入されているのがスクラムです。 スクラムとは、決まった期間（スプリント）ごとに価値を少しずつ届け、検査と適応を繰り返しながら進めていくフレームワークのこと。 「プロダクトオーナー（プロダクトの価値の最大化に責任を持つ）」、「スクラムマスター（スクラムの確立とチームの効果性に責任を持つ）」、「開発者」という3つの役割があり、それぞれに認定資格が存在します。今回はそのうち、プロダクトオーナーとスクラムマスターの資格を持つ、エキスパートたちにインタビュー。ニフティにおけるスクラム開発の導入事例や効果、アジャイル文化の浸透度合い、今後の課題について語ってもらいました。 自己紹介 吉田 龍太郎さん 2018年10月に入社（子会社より転籍）。ニフティポイントの企画チームに所属し、「ニフティポイントクラブ」のプロダクトオーナーを務める。趣味は服飾、サッカーゲーム、生け花、美術鑑賞、読書。 清水 利音さん 2017年4月に新卒入社。会員基盤チームに所属し、スクラムマスターとして「シングルサインオンシステム」の開発に従事。趣味はボルダリング、ウクレレ。 西野 香織さん 2009年4月に新卒入社。ニフティポイントの開発チームに所属し、「ニフティポイントクラブ」のスクラムマスターとして従事。N1!制度のスクラムエヴァンジェリストとして、社内各チームのスクラム導入やサポートを実施。スクラムマスターギルドを主催し、社内のアジャイル文化の醸成にも貢献している。趣味は漫画を読むこと、絵を描くこと。アフタヌーンティーめぐり、ボードゲーム。 ニフティのスクラム開発における「スクラムマスター」の役割とは？ ―― はじめに、みなさんの略歴と業務内容を教えてください。 吉田さん 2018年に子会社からニフティに転籍し、2020年から現在のポイントチームに所属しています。現在は企画側のプロダクトオーナーとして、「ニフティポイントクラブ」というポイントサイトの運営と方針の策定や、各ステークホルダーとの調整などをメインに行っています。 清水さん 2017年にエンジニアとして新卒入社し、2年目から会員基盤チームで働いています。現在、メインで担当しているのは、「シングルサインオンシステム」という、ニフティのさまざまなサービスにログインする際の認証システムの開発や刷新です。開発チームのリーダーでもあり、チーム内のアウトプットの最大化に注力しています。 西野さん 2009年に新卒でニフティに入り、現在は吉田さんと同じポイントチームで、スクラムマスターとして「ニフティポイントクラブ」の開発に携わっています。また、社内のN1!制度（※1）のスクラムエバンジェリストとして、別チームのスクラム導入を支援する活動も行ってきました。 （※1）N1!制度……特定の分野で突出した知識とスキルを持って活躍している社員の中から、 「N1！（NIFTY No.1）」として任命する制度。自身の知見を社内にシェアし、組織全体に新しい開発文化を根付かせる役割も担う。 ――ちなみに、ニフティのスクラム開発における「プロダクトオーナー」「スクラムマスター」の役割とは、具体的にどのようなものでしょうか。 吉田さん プロダクトオーナーは、シンプルに言うと「何を作るか」を決める役割です。顧客が何を求めているかを整理し、やるべきことの優先順位を決める、プロダクト全体の責任者ですね。 西野さん スクラムマスターの仕事は多岐に渡りますが、最も重要なのは、企画側と開発側のコミュニケーションをスムーズにするためのサポートや、対話を生むための環境づくりです。プロダクトをグロースさせる上で障害になることを取り除くと同時に、サービスを発展させるためにあらゆることをやる役割だと思っています。 また、自チームの改善だけでなく、組織全体にアジャイル文化やスクラム開発を浸透させるのも、スクラムマスターの使命。ニフティには私や清水くんのように別チームに所属するスクラムマスターが集まるギルドがあり、定期的に意見交換しながら社内のスクラムをより深化させる活動を行っています。 スクラム開発をより理解したい。スクラムマスターの資格を取った理由 ――吉田さんはプロダクトオーナーの資格を、西野さん、清水さんはスクラムマスターの資格をそれぞれお持ちということですが、資格取得のきっかけを教えてください。 吉田さん プロダクトオーナーの資格を取得したのは2024年の夏です。2022年頃から「ニフティポイントクラブ」の開発チームがスクラム開発を導入したのを機に、スクラムを意識し始めました。その際に企画側からプロダクトオーナーを出すことになり、私の上長がプロダクトオーナーを務めることになったんです。 ただ、上長は忙しくスクラムにコミットすることがむずかしかったので、私が代理として職務を任されるうちに、「ちゃんと学びたい」と思ったことが資格取得のきっかけです。もともと開発チームがスクラム開発を始めた時に、アジャイル開発のマインドセットやプロダクトマネジメント・スクラムといった知識は勉強し始めてましたが、プロダクトオーナーを全うするにあたって裏付けとなる知識やスキルを習得したいと考えました。 西野さん 私はもともとエンジニアではなく、フロントエンドのコーダーから制作ディレクターを経て、スマホアプリの開発チームに入りました。その際、アプリの売り上げが伸びて開発メンバーを補強することになり、私がチームリーダーになってしまったんです。エンジニアの知見がなく、開発そのものを牽引できるわけではない私が、どう開発者とコミュニケーションを取っていくかを模索していた時に出会ったのがスクラムでした。開発チームとステークホルダーの協力体制を作り、メンバーがスムーズに動けるようサポートする。それが自分にできる貢献の仕方と考え、スクラムマスターの資格を取得しました。 清水さん 私は学生インターンとしてニフティに来た2015年に、スクラム開発を体験するワークショップに参加しました。大学の研究室では、基本的に一人で活動するのが当たり前だったこともあって、こんな開発手法があるのかと、良い意味でショックを受けたんです。また、入社後に所属した会員基盤チームでも早くからスクラム開発を導入していて、徐々に「スクラムのことをもっと理解したい」と思うようになりました。そして、2021年に上長に相談の上、スクラムマスターの資格を取得したという流れですね。 私の場合は西野のように自分自身が旗を振ってスクラムを導入した経験はありませんが、スクラムマスターとしての知見を活かし、チーム内のコミュニケーションがより円滑になるよう働きかけを行っています。 「いきなり会議」はNG。コミュニケーションを増やすための泥臭いアプローチ ――西野さんがスクラムマスターとしてチーム運営に携わった、具体的な事例を教えてください。 西野さん 私は1年半前にポイントチームにジョインしたのですが、当時は複数のチームが別々に進めていたプロジェクトが終了し、チームを一つに統合するタイミングでした。当時の課題は、それまで同じポイントチームでありながら別部隊で動いていたため、チーム内で情報の分断が起きていたこと。そして、企画側と開発側の会話頻度が少ないこと。そこを解消するのが、スクラムマスターとしての私の役割でしたね。 ――どんなアプローチで、そうした課題を解消したのでしょうか？ 西野さん やり方自体はわりと泥臭いというか、難しいことは何もしていなくて。たとえば、企画側と開発側のコミュニケーション不足については、1日1回は私のほうから企画チームがあるフロアに足を運び、会話する時間を設けました。（※2）時には私以外の開発メンバーも連れていったり、企画側のプロダクトオーナーやステークホルダー、開発メンバーが打ち解けやすい空気づくりだったり、飲み会を企画して親睦を深めたり。色んなことをやりましたね。 コミュニケーションを深めようとして、いきなり会議を増やしたりすると、みんな嫌がるじゃないですか。会議を設定する前に、まずはシンプルに仲良くなることが大事です。その上で話してみると、企画側も開発側も共通の課題を抱えていることが分かったり、目指す方向が同じだったりすることも多い。そうした、根っこの部分を共有することが何より大事なのだと考えています。 ――企画側も開発側も目指すゴールは一緒。しっかりコミュニケーションさえ取れていれば、お互いに不満を抱いたりすることもなさそうです。 西野さん そうですね。たとえば、企画側としては「こちらは開発に色々と依頼しているのに、なかなか動いてくれない」といった不満もあったようです。でも、困っていてもなかなか言いづらい空気があり、不満だけが募ってしまう。ただ、開発側には開発側の言い分もあるわけです。そこはやはりスクラムマスターが間に入り、風通しをよくしていくことが大事ですね。 実際、今のポイントチームでは企画と開発の垣根を超えて本音が飛び交う、本質的な議論ができていると思います。ミーティングでも「今の話、よく分からないです」「それって本筋から外れていませんか？」みたいなことも遠慮なく言い合えて、互いに目指す方向は同じと分かっているから揉めることもありません。 吉田さん それまでは開発側とのやりとりが少なかったり、基本的にテキストベースだったりで、文章だけでは時に誤解が生じ、感情的になってしまうこともありました。西野がポイントチームに来てくれてから、細かいことまで話し合う文化が生まれ、そうした行き違いや認識の齟齬は減ったと思います。 （※2）インタビュー時点。2026年5月にオフィス移転し、現在は同フロアになっています。 吉田さん ただ、コミュニケーションは活発になったものの、自身も含めまだまだ改善の余地はあると考えています。今後は企画側も、スクラム以前にアジャイルのマインドセットやプロダクトマネジメントに関する理解を深めつつ、開発サイドに寄り添うメンバーをもっと増やしていきたいですし、それは企画チームのサブリーダーでもある自分の役割だと認識しています。 後編に続きます！ 今回はニフティのスクラム開発を牽引するエキスパートたちのインタビュー（前編）の様子をお届けしました。後編は近日中に公開します。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

はじめに こんにちは、エンジニアリングマネージャーの芦川です。なぜ基幹システムを担当している自分がこんな話をするのか。単純に、一度話してみたかったからです。 ニフティのコーポレートメッセージ にある「お客様起点」とは、結局のところ何なのか。プロダクトマネジメントを学ぶ中で、ずっとこの問いが根底にありました。AIとの協働開発が広がり、開発のスピードは上がっているのに、それが直接的な成果につながらないという声を色々な会社から聞くようになった今だからこそ、この考え方はより一層大事になってきていると感じています。 書いてみた後の感想ですが、読み返すと中身自体はいたって普通のことでした。ただ、目線を合わせるために、あえて少し強調するように書いています。 まずはプロダクト思考とよく対比される「受託開発思考」をみてみます。 受託開発思考とは何か クライアントや企画職が要件を考え、開発職がその要件をそのまま作る。一見どこにでもある普通の進め方に見えますね。ですが、これには明確なメリットとデメリットがあります。（プロジェクト思考と呼ばれることもあります）。 受託開発思考のメリデメ まずはメリットから。お客様に提供する仕様を計画当初から変えたくない場合、ソフトウェアのEOL対応やレガシー環境からの環境移行などやるべきことがはっきり分かっている場合、受託開発思考が適したケースは確かに存在します。 しかし、すべての開発案件にこの考え方を当てはめてしまうと、「要件通りに作ったのに価値が出ない、売れない」「お客様のために作ったのに使われない」といった、プロダクトアウトな状態に陥ることがよくあります。 そのサービスや機能は、リリースしてみないと使われるかどうか、売れるかどうかわからないものになっていませんか。これからお客様になる誰かが、お金を払ってでもそれが欲しいと言ったことはあるでしょうか。 さらにAIとの協働開発が進むと、開発側のループはどんどん速くなっていきます。けれど、提供する価値がそもそも求められていないものであれば、売れないものを増やすだけになってしまいます。開発生産性は上がっても、価値生産性は上がらない。アウトプット（結果）は増えても、アウトカム（成果）は増えないということです。 アジャイルにより動くソフトウェアを早くリリースしよう、と躍起になるだけでも同じことが言えます。 プロダクト思考になろう そのために基本的には、企画・営業・開発みんなが、それぞれプロダクト思考を持つ必要があるという話です。 企画者は市場やお客様の声を、開発者は実装の実現可能性やログ・データから見える利用実態を、それぞれ異なる立場から持ち寄っています。どちらか一方が持っている情報だけでは、お客様のために「なぜそれを作るのか（Why）」を十分に解像度高く描くことはできません。 だからこそ、企画がエンジニアの領域に越境してみる、エンジニアが企画の領域に越境してみる。双方が互いのフィールドに越境し合うことで、初めてWhyの解像度が上がっていきます 。ニフティのような自社に企画職も内製ができるエンジニアもいる意味は、まさにここにあります。 「お客様のこの課題解決、一緒に考えさせてください」「一緒にやりましょう」。そう言えるようになるには、お客様との接点や対話を通じて、どんな価値から対価が得られるのかを理解することが欠かせません。いま手元にあるお客様へ直接価値提供をするためのプロダクトバックログは、お客様の声を起点にしたものになっているでしょうか。 プロダクト思考とは、ユーザーの課題を深く理解し、解決策であるプロダクトを通じて「価値」を提供し、最大化しようとする考え方です。 そもそも「価値」とは何か ではそもそも価値ってなんでしょうか？機能はイコール価値ではありません。お客様にただリリースしただけでは、それは単なるアウトプットであり、価値ではないのです。お客様の体験が変わり、最終的に対価が得られて初めて、提供価値が生まれます。 どれだけ技術的に優れた、革新的なプロダクトを作ったとしても、事業価値につながらなければ意味がありません。マーケティングと掛け合わせてお客様に届け、実際に使われ、お客様の課題を解決し、お客様がそう感じ、最終的に対価を得られること。ここまでいって初めて、会社としての意味があります。 そもそも「プロダクト」とは何か プロダクトとはお客様体験そのものであり、機能やUI、コンテンツ、決済機能なども含まれます。お客様に何かを提供し、お客様体験に影響を与えるものすべてがプロダクトです。システムとプロダクトは同じではありません。 セールス、UI、機能・コンテンツ、ログイン、サポート、課金。お客様からすればこれらは地続きの一つの体験であり、プロダクト思考の上では分けて考える意味はありません。代理店経由の販路や電話でのアウトバウンドといったセールスの機能も、お客様体験の一部です。 そもそも「お客様体験」とは何か お客様体験には、他社の存在や、自社が直接関与していないリアルな体験まで含まれます。例えばECであれば、他社を含めた商品選びの段階からすでにお客様体験は始まっています。 インターネット回線で言えば、申し込み後の工事日程の調整や、ルーターの設置、設定方法がわからず家族に聞くといった、自社から一旦離れたリアルな行動もすべてお客様体験です。つまり、その出来事に関連してお客様が経験したすべてのことを指します。 ※文脈によって価値やプロダクトやお客様体験については意見が分かれるところがあると思いますが、今回の記事ではこのような位置づけで進めていきます。 社内システムやプラットフォームチームにも通じる話 プロダクト思考は、お客様と直接接点のある事業だけの話ではありません。社内担当者や基幹システムのようなプラットフォームチームでも同じことが言えます。利用者へのアンケートや個別ヒアリングを行い、組織全体の最適化を考える。ここでも、なぜそれを作るのかを対話を通じて理解し、利用者体験の現状を把握し、これから体験をどう良く変えていくか想像することが欠かせません。 さて、プロダクト思考についてはなんとなくわかりました。が、実際、プロダクト思考を持つエンジニアは、これから何をしていけばよいのでしょうか？ 明日からできる3つの行動 ① 越境を意識するコミュニケーション ビジネス側、開発側、CS、営業がそれぞれの領域を越えて理解を深めなければ、会社として良い仕事はできません。複数の業務や複数のシステムが横断して一つの価値提供につながっている場合、自分の担当範囲に仕事を閉じず、他チームに越境してコミュニケーションを取ることが大切です。部署を越えたプロダクトマネジメントの輪読会のような場は、立場の違う意見が交わされる貴重な機会になります。 ② いまあるものを理解する、お客様や業務ドメイン知識 長い歴史と多くの会員を抱えていることは、大きな強みです。自社のサービスや構造を知り、業務ドメインを理解する。既存のお客様がどこに価値を感じ、対価を支払ってくれているのかを理解する。歴史が長いということは、過去の失敗も多く積み重なっているということでもあります。 ただし、問い合わせをしてくるお客様はごく一部に過ぎず、その声だけが全体を代表しているわけではないという点には注意が必要です。データ分析やAIによる分析なども積極的に活用していきたいところです。 ③ いまないものを学ぶ、ニフティにはまだまだお客様との対話が必要 足りていないお客様との接点を増やすこと。お客様に直接インタビューを行い、他社を含めたリアルな行動や感情について聞いてみる。お金を払ってでも解決したいことは何かを、直接尋ねてみる。自分自身でサービスを利用し、お客様体験を学ぶことも欠かせません。 ここで注意したいのが確証バイアスです。「こういう機能があったらいいと思いますか」と聞いて「あったらいいかも」と答えられても、実際には「自分は使わないけれど誰かは使うかも」という温度感であることが多く、結果として使われない、買われないという事態につながります。拾えていない声や感情、体験にこそ、学ぶべきものがあります。 まとめ 受託開発思考は、依頼された仕様を正確に作るというスタンスで、スケジュール通りに納品し、開発生産性を上げることを重視します。要件が明確で進めやすく、納品という区切りがつけやすい一方、作ることがゴールになりがちであり、お客様への意識が弱くなりやすく、担当範囲の壁を越えにくくなるという側面もあります。 プロダクト思考は、提供価値を理解しユーザー課題を解決するために作るというスタンスで、なぜそれを作るのかを問い続け、価値生産性を上げることを重視します。ユーザー価値に直結した開発ができ、お客様体験の理解が深まり、企画と開発のゴールが一致しやすくなります。一方で、最初から正解が存在するわけではなく、お客様の求めるものを深掘りするには時間がかかります。また終わりはありません。 おわりに ニフティグループは、お客様、株主、社員、パートナー企業、地域社会などの夢をかなえるため、常にお客様起点で行動し、チャレンジャーとしてサービスを開拓し、社会に役立つ企業として新しい価値の創造に取り組み続けます。 このコーポレートメッセージは、まさにプロダクト思考そのものだと思っています。書いてみて改めて感じたのは、至極当たり前のことを、目線合わせのために言語化しただけだということです。それでも、こうして言葉にしてみることに意味があると信じています。

はじめに 「ニフティってどんな会社？」「入社したらどんな仕事をするの？」——就職活動中のみなさんが気になるポイントを、ニフティのエンジニアが実際に書いたブログ記事で紹介します。 この記事を読むとわかること： ニフティがどんな会社なのか ニフティで働くとどんな仕事ができるのか、1〜2年目では何をやるのか ニフティならではの面白いこと ニフティってどんな会社？ 数字で見るニフティのエンジニア ニフティエンジニア徹底分析！〜ニフティのエンジニアにあれこれ聞いてみました2025〜 115名のエンジニアへのアンケートから、ニフティのリアルがわかる記事です。新卒採用が約7割、好きな言語はPythonが最多。「優しさ、思いやり」がエンジニアの強みのトップに挙がるなど、人柄と雰囲気の良さが数字にも表れています。まずはこの記事でニフティの全体像をつかんでみてください。 AIをフル活用する文化 ニフティのAI業務活用事情 全社アンケートでは90%以上の社員がAIを業務で利用し、66%は毎日使っています。エンジニアだけでなく企画・営業職も含めて、新しい技術を積極的に取り入れる会社です。 社外からも評価されています Notionチャンピオンズコミュニティで「Notionチャンピオンエンフォース賞」をいただきました！ 社内のツール活用や情報発信が社外コミュニティで2年連続表彰されました。良いと思ったものをとことん使い倒す姿勢が伝わる記事です。 COMPANY DECK ニフティ株式会社 エンジニア向け Company Deck 2026年版 もっとニフティのエンジニアのことを知りたい方向けにCompany Deckがあります。 1〜2年目はどんなことをやるの？ 新卒1年目のリアル ニフティでの新卒一年目について ニフティのエンジニア職にはOJT制度があり、入社後の約1年間で3つの異なるチームを経験します。（現在は、2期制になっています。）実際に3チームを回った新卒社員が、業務内容ややりがい・苦労した点をエピソードベースで語っています。「入社後の1年」を最も具体的にイメージできる記事です。 新人研修の集大成はハッカソン合宿 今年はいつもと違う？ハッカソン合宿に行ってきました！@マホロバ・マインズ三浦 新卒1年目エンジニア向けの開発研修の集大成として、2泊3日のハッカソン合宿を実施しています。0からシステムを作る力を身につけ、AIも本格的に使える環境。研修から本気です。 社外の研修にも新人が参加 AWS JumpStart 2025に参加してきました ! 新人研修の一環として、新卒9名がAWSの実践研修プログラムに参加。1年目から社外イベントでどんどん経験を積めます。 学生でも現場に入れる長期インターン ニフティ長期インターンシップ体験記：未経験から運用・開発の現場へ 未経験から3ヶ月間、運用・開発の現場を経験したインターン生の体験記です。入社前にニフティの現場を知りたい方はぜひ。 ニフティならではの面白いこと 会社をあげての技術の祭典「NIFTY Tech Day」 エンジニアのためのイベント「NIFTY Tech Day 2025」を2/8（土）開催いたします！ エンジニアが知識や経験を発表する年に一度の大型イベント。ゲストセッションや体験型ブースもあり、社内外のエンジニアが集まるお祭りです。 中堅になっても合宿がある 中堅エンジニアたちの激闘2日間 in 熱海 ~AIと共に~ 合宿は新人だけのものではありません。中堅層向けのAI駆動開発ハッカソンを熱海で開催。何年目になっても、仲間と集中してものづくりに挑む機会があります。 社員手作りの技術書を「技術書典」で頒布 技術書の祭典「技術書典18」に出展！社員手作りの技術書を無料頒布します！ 有志のエンジニアが執筆した144ページの技術書を、表紙のデザインまで手作りして無料頒布。「書きたい！」を形にできる発信文化があります。 さいごに ニフティは、若手が現場でどんどん経験を積みながら、イベントや発信も全力で楽しむ会社です。エンジニアとしての第一歩に不安がある方は、こちらの記事もおすすめです。 これから始めるエンジニアの一歩！必読のアドバイス集 NIFTY engineeringでは他にもたくさんの記事を公開しています。少しでも興味を持ったら、ぜひ他の記事ものぞいてみてください。皆さんとお会いできる日を楽しみにしています！

ニフティに新卒入社したエンジニアは、3か月間の新入社員研修と技術研修を経て、7月からOJT期間に入ります。8か月の間に3つの部署をジョブローテーションし、業務知識やチームでのプロジェクトの進め方、エンジニアとしての技術を身につけたうえで、4月からの本配属に備えるという流れです。 実際にプロジェクトの一員として働くニフティのOJTは、単に仕事を覚えるだけでなく、自分自身の適正を知り、会社員やエンジニアとしての歩み方を見定めていく期間でもあります。前回は2025年度に新卒入社した4名の新人に、OJTで得た学びや気づき、入社前のイメージと実際に働いてみてのギャップについて聞きました。今回は、ニフティの働きやすさや休みの取りやすさについて、また、本配属を前にした決意を語ってもらいました。 ニフティは良い意味で「ゆるふわ」な会社？ 職場の雰囲気も含めた、働きやすさという点に関してはどのように感じていますか？ Nさん 職場の雰囲気はとても良いです。ニフティって固い会社だと思われがちなのですが、良い意味で年次による壁がないように感じます。1年目のジョブローテで3つの部署を回りましたが、どのチームもコミュニケーションを大事にしていて、新人が遠慮なく先輩や上司に相談できる雰囲気でしたね。 Sさん 言い方が適切か分かりませんが、ちょっと“ゆるふわ”な空気がありますよね。自分もどちらかというと緩いタイプなので居心地は良いです（笑）。また、今は原則出社なのですが、個人的にはそのほうがやりやすいですね。特に新人のうちは分からないことが多いので、色んな部署の人に直接会いに行ってコミュニケーションできるのはありがたいです。 Yさん 私も風通しの良さは感じます。たとえば、所属部署の定例会議に新人も参加するのですが、1年目なので理解できないことも多くて。ただ、分からないことがあってもSlack上にある「会議実況チャンネル」に投稿すれば、会議の合間で誰かが拾ってくれて、マネージャーや部長がその場で回答してくださるので全くついていけないということはなかったです。 Tさん 社内の雰囲気やコミュニケーションの部分については、私もみんなと同意見です。たまにオフィス内のフリースペースで仕事をしていると、他部署の先輩たちがフランクに話しかけてくれたりして、いいリフレッシュにもなっています。業務で凝り固まった思考を、雑談でほぐしてくれるんです。 自由参加の社内飲み会みたいなものも週1であって、ここにいるメンバーは全員参加したことがあります。他部署の人だったり、マネージャーだったり、普段の業務ではあまり接点のない人ともお酒を飲みながらコミュニケーションできるのがいいですね。 それから個人的に感じるのは、ニフティって「褒め上手」な人が多いなと。たとえ些細なことでも、誰かが何かしらの成果を出せば素直に称える。そんな文化が根付いている気がします。逆に、否定から入る人は少ないです。たとえば、私が出したアイデアに対して頭ごなしに否定されるようなことはなく、まずは検討してくれる。結果的に採用されなかったとしても、ちゃんと理由を説明してくれるので納得感がありますし、また提案してみようと思えます。 1年目から有給休暇をフル活用し、海外旅行へ ワークライフバランスに関してはいかがでしょう？　休みの取りやすさや業務量など、不満も含めて感じていることを教えてください。 Nさん 休みはすごく取りやすいです。有給休暇は1年目から20日間付与され、新人だから遠慮して取得しづらいみたいなことも全くないですね。逆に私の場合は取得しすぎて、あと3日しか残っていません。先日は海外旅行に行くために5日間ほど休みました。先輩たちも有給やフレックス制度をうまく使ってライブに行ったりと、仕事とのバランスを取りながらプライベートを充実させている印象です。 Yさん 逆に有給休暇を全く取っていないと、周囲が取得を促してくれます。私も、ほぼ使わずにいたら当時の上長から「ちゃんと有給を消化しようね」と言われました。有給休暇以外の休暇制度も充実していますし、雰囲気的にも休みを取ることに対する抵抗はないですね。業務量についてはまだ1年目ということでセーブしてもらっているところもあると思いますが、先輩たちを見ていても過重労働にならないようコントロールされているのかなと。 Sさん 有給休暇に関しては相談するというよりも、「この日に取ります」と宣言するような形ですね。取得するのが当たり前というか。今のチームではSlack上で申請するだけで勤務表への打刻まで自動でやってくれるシステムを使っているので、そういう意味でも取りやすい。私自身も有給はしっかり消化しています。土日休みとくっつけて実家にちょくちょく帰ったりしてました。 Tさん 私も有給休暇は積極的に取得しています。土日に趣味のイベントがある時に、月曜を有給にすることが多いですね。土日は思い切り楽しんで、月曜は静養に充てています。 休みも取りやすいですし、仕事中に体調が悪くなった場合もすぐに早退できたり、お子さんが急に熱を出した時に在宅勤務に切り替えたりと、急なアクシデントにも柔軟に対応してもらえます。フレックスタイムにしても在宅勤務にしても、現場の要望や社員の働きやすさを考慮した上で制度が設計されているように感じますね。 新人たちがこれからチャレンジしたいことは？ 1年目のOJTとジョブローテが終わり、4月からはそれぞれの部署に本配属となります。これからニフティで挑戦したいことや、現段階で思い描く将来像を教えてください。 Tさん 直近で取り組みたいと思っているのは、ニフティの会員様の満足度向上です。新しい会員を増やすことも大事ですが、今ご契約いただいているお客様に対してインターネットの接続サービス以外の部分でも、「ニフティの会員になって良かった」と思っていただけるような施策に携わっていきたいと思っています。 将来像については、ざっくりとしていますが「なんでもできる人」になりたいです。技術に関しても、何か一つを極めるというよりも色んな選択肢を持てるよう、幅広い知見を身につけたいと思っています。その点、幅広いサービスを手掛けるニフティはうってつけですし、オンライン学習や社外イベントへの参加を通じて業務外の技術にアプローチできる環境をうまく活かしていきたいですね。 Sさん OJTを通じて感じたことでもあるのですが、直近でやりたいのは社内業務フローの改善です。どんどん自動化を進めて工数を減らし、本来エンジニアがやるべき業務に注力できるような取り組みを進めていきたいですね。将来像はTさんと似ていますが、いわゆるフルスタックエンジニアとして、どんなことにも挑戦していきたいと思っています。そういう意味では、ジョブローテではバックエンド、フロントエンド、インフラ関連と、異なる領域に触れることができたので、いい経験になりました。 Yさん まだ配属先が決まっていない段階（2026年3月5日時点）ですので、やりたいことが具体的に固まっているわけではないのですが、現在ニフティでは全社的にAWSへの移行を進めていて、どのチームに配属されたとしてもクラウドにまつわる知見やスキルは重要になってくると思います。まずはそこを深めていきたいですね。将来は、社内インフラの整備やサポートといった、ニフティの社員に快適に働いてもらうための業務に携わりたいと考えています。 Nさん ニフティには職人的に技術をひたすら磨き抜いているスーパーエンジニアもいますが、私自身は技術に特化するというよりも、技術をベースとしつつもサービスの知識や、ビジネス側との調整スキル、顧客ニーズを捉える力などを総合的に伸ばしていきたいと思っています。プロダクトマネジメントに主眼を置いて、サービスをよりよいものにしていけるエンジニアになりたいですね。 前編もご覧ください！ 今回はニフティの2025年度 新卒社員のインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】入社から1年。成長の実感は？　新人たちが振り返るOJTの日々【2025年度 新卒社員 前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

ニフティ株式会社は、2026年7月10日（金）〜 7月11日（土）に開催されるSRE NEXT 2026にランチスポンサーとして協賛します。 SRE NEXTは、サイトリライアビリティエンジニアリング（SRE）に関する日本最大級のカンファレンスです。 ニフティは過去にも本イベントに協賛しており、SRE分野の発展に貢献できることを大変嬉しく思います。 SRE NEXT 2026に関する詳細は、公式サイトを覧ください。皆様のお越しをお待ちしております！ 公式サイト https://sre-next.dev/2026/ スポンサーセッションに登壇します 今年のSRE NEXT 2026では、 7月10日（金）12:20よりスポンサーセッション登壇します。 セッションでは、ニフティのSREの取り組みであるEmbedded SREを受け入れたチーム側の視点で、何が良かったかをお話します。 Track B Lunch Sponsor 7/10 12:20 – 12:35 Embedded SREと共に達成した会員管理システムのAWS移行 https://sre-next.dev/2026/schedule/#slot053 いつものどら焼きもあります ランチセッションにご参加いただいた方にはニフティのロゴを焼印したどら焼きをお配りします。ぜひご賞味ください。 過去の協賛 ニフティはSRE NEXT 2025にゴールドスポンサーとして協賛します SRE NEXT 2023 に GOLDスポンサーとして協賛 SRE NEXT 2022にGOLDスポンサーとして協賛＆登壇します！

ニフティに新卒入社したエンジニアは、3か月間の新入社員研修と技術研修を経て、7月からOJT期間に入ります。8か月の間に3つの部署をジョブローテーションし、業務知識やチームでのプロジェクトの進め方、エンジニアとしての技術を身につけたうえで、4月からの本配属に備えるという流れです（2025年度時点）。 実際にプロジェクトの一員として働くニフティのOJTは、単に仕事を覚えるだけでなく、自分自身の適正を知り、会社員やエンジニアとしての歩み方を見定めていく期間でもあります。今回は2025年度に新卒入社し、OJT期間を終えようとしている新人たちにインタビュー。春からの本配属を待つ4名に、この一年を振り返ってもらいました。 自己紹介 Nさん 2025年4⽉に新卒入社。現在の担当業務は、ISMS（情報セキュリティマネジメントシステム）の推進、インシデント対応、社内セキュリティ対策の企画・運用。趣味はチェス、旅行。 Yさん 2025年4⽉に新卒入社。現在の担当業務は、社内システムの運用・保守・刷新。趣味は鉄道旅。 Sさん 2025年4⽉に新卒入社。現在の担当業務は、オプションサービスの開発、運用。趣味は映像・音楽・映画やアニメ鑑賞・散歩。 Tさん 2025年4⽉に新卒入社。現在の担当業務は、@niftyトップページ・ニフくじの開発・保守。趣味は料理・アニメ鑑賞・ボルダリング。 3つの部署を経験し、興味とスキルの幅が広がった ※本文中の部署名は2025年度時点 みなさんは2025年4月にニフティに入社し、7月から現在までの約半年間、ジョブローテーションで3つの部署を経験しました。この期間に、どのような学びや気づきがあったのか教えてください。 Tさん 1年目に複数の部署を回れたことは、各部署の役割や部署同士のつながりなど、会社全体の動きを知るという意味で良かったと思います。また、エンジニアといってもコードを書く以外に考えることも多かったり、開発現場のリアルな動きを知れたのも大きいですね。 Sさん 私は「課金システムチーム」「セキュリティSREチーム」「インフラシステムチーム」を経験しました。どのチームでもたくさんの学びがありましたが、たとえば課金システムチームでは、チーム開発の基礎やプロジェクト立ち上げにまつわる知識、システム同士の連携、ドメインについてなど、今後の業務に活かせそうな経験ばかりでしたね。 Yさん  私は情報系の大学出身ではないこともあって、そもそも技術面での学びが大きかったです。また、ジョブローテで回った3つの部署はいずれも社内向けのシステムを手掛けていたのですが、同じ社内向けでもチームによって考え方や仕事の進め方、コミュニケーションを取る相手がまるで違うことが分かったのは良かったですね。 たとえば、1期目に配属されたプラットフォームチームでは、人事部門や経理部門との連携が中心でした。2期目のデータの収集基盤チームでは、システム系の部門や、データを活用したい企画側との連携が増えるなど、チームによって関わる人が変わる。頭を切り替えて臨まないといけないし、求められる知見やスキルも異なることを痛感しました。 Nさん 私も、Yさんと同じく専門的に学んできたわけではありませんが、3期とも開発がメインのチームに配属されました。最初は不安でいっぱいでしたね。ただ、開発の知識はもちろん必要ですが、それ以上に分からないことがあれば素直に教えを請い、理解した上で伝える力が大事なのだと気づきました。それさえできれば、後から開発のスキルはついてくるのかなと。 特に印象深かったのは2期目ですね。カスタマーサポートの社員の方が利用しているシステムの運用・開発をするチームに配属され、コールセンター業務をしているオペレーターさんの声を聞く機会がありました。実際にシステムを使う人が感じている不便など、リアルな要望を聞いた上で改善策を考え、設計に落とし込むプロセスは学びだらけでした。 オンライン学習や社外イベントへの参加推奨。スキルアップ制度も充実 現場での実践経験に加え、スキルアップのための社内制度なども利用されましたか？ Nさん Udemyのオンライン学習はかなり利用しています。資格取得の講座や、気になった技術に関する動画も気軽に見られるので、ビジネスマンとしてもエンジニアとしてもスキルの幅が広がっていく感覚はありますね。 Yさん  私もUdemyのほか、個人の学習や自由研究のような開発に使えるAWSのサンドボックス環境の制度を積極的に活用しています。月額100ドルまでと上限はありますが、ハンズオンのためにAWS環境で簡易サービスを作ってみたり、色んな検証を行うのに役立てています。 Sさん  同じくAWSのサンドボックス環境は重宝しています。私の場合は、生成AI系のアプリケーションを作成できるBedrockをよく使っているのですが、他にもAWSの新しいサービスや機能をすぐに試せるのが嬉しいですね。あとは、社内のナレッジ共有ツールとして使われているNotionに「みんなのレポート」というページがあって、そこで他チームのナレッジや情報を閲覧できるので、勉強になります。 Tさん ニフティ全社的にAWSの資格取得を推奨する動きがあり、私もUdemyを活用して2つの資格を取りました。他には、社外イベントやワークショップに参加しやすい仕組みがあるのもありがたいです。会社が促してくれるので気兼ねなく行けますし、交通費も支給されます。OJTの期間中も、AWS系のイベントに新人全員が参加していました。 Sさん イベントに関しては参加した人が「みんなのレポート」に内容やそこで得られた知見をシェアしてくれるので、自分が行けなかったイベントからも学びが得られます。また、Slack内にイベント情報を共有するチャンネルもあって、フロントエンド、バックエンド、AI系など、自分が興味のあるジャンルのイベントをチェックしている人も多いです。イベントに参加しやすい雰囲気や、参加を促す仕組みがあるのがいいですね。 制度や仕組み以外の部分で、自身の成長につながったと感じられる体験などがあれば教えてください。 Nさん  ジョブローテで回った各部署で、色んな方と議論ができたのは良かったです。対面だけでなく、社内のSlack上でのやりとりもオープンで。ふと感じた疑問を投稿すると同じ部署の先輩、別チームの人、マネージャーや幹部クラスの方々もコメントしてくれて、どんどん議論が展開されていく。質問したことを教えてもらうだけでなく、議論をすることでより深いところまで思考できる感覚がありますね。 あとは、基本的に先輩たちが優しくて、何でも質問できるのがありがたいです。先輩自身も分からない時は、一緒に調べてくれたりもして。新人や若い社員への丁寧な接し方みたいなものは、ニフティのなかで受け継がれてきた文化の一つなのかなと思います。 Tさん  Nさんが言ってくれたように、誰かの発言に対してちゃんとリアクションする人が多いのはニフティの特徴の一つだと感じます。それも仕事だからやっているというよりは、いい意味でディスカッションを楽しんでいる印象です。たとえば、Slack上で自分専用のチャンネルを作って業務や活動について発信する文化があるのですが、そこで「今こんなことをやっているんだけど、何かいい方法ありますか？」と投稿すると、誰かしらが反応してくれる。悩みや困ったことがあっても、一人で抱え込むことなく前進できるので、成長を早めてくれる環境だと感じますね。 技術に対する感度の高さに驚き。ニフティに対するイメージに変化は？ 実際に1年間働いてみて、入社前のイメージから変化したことがあれば教えてください。 Nさん 入社前はWEBサービスとネットワークがメインの企業という印象でしたが、実際は想像以上に多角的なサービスやプロダクトを展開していました。お客様向けのサービスだけでなく、社員が使うサーバーやネットワークの構築も社内でやっていて。技術を活用して刷新や補修をしていく範囲の広さに驚きましたし、それだけ活躍の幅があるのかなと思いました。 あとは、新しい技術に対する感度も高いですね。毎週、休みが明ける度にSlackのチャンネルに社員それぞれがインプットしてきた技術にまつわる情報が投稿されて、追いきれないほどです。最近はAI関連の話題が熱くて、詳しい人が社内勉強会を開いたりと、新しい技術をどんどんキャッチアップして自分のものにしていこうという雰囲気があります。 Yさん いい意味でイメージ通りだったのは、会社の雰囲気や風通しの良さです。学生時代にインターンで来ていた時から先輩たちがフレンドリーに接してくれて、それがニフティを選んだ理由でもあるのですが、入社後もそこは変わらなかったですね。 ニフティのサービスに関しては、私もNさんと同じく「昔からあるサービス」の運用が中心なのかなと思っていましたが、ISP事業のような軸となるサービスがありつつも、幅広く事業をやっているんだなと。守りと攻め、両方をバランスよく展開している印象ですね。 Sさん 社内で使うツールやプラットフォームも、良いものがあればどんどん採用していく柔軟性があると思います。たとえば先日は、Notionのカスタムエージェントという機能がリリースされた当日に社内でワークショップを実施していて、あまりのスピード感に驚きました。 コーディングに関しても全社的にAIを活用して、工数の削減に取り組んでいるのは意外でしたし、いい意味でギャップを感じましたね。 Tさん 私は入社前からNIFTY engineeringのブログ記事を読んでいて、技術に関する感度が高い会社という認識を持っていましたが、実際に入ってみたら想像以上でした。NさんやSさんが言うように、開発現場でも最新のもの、良いものをどんどん試して使っていこうという意識が浸透していると思います。 たとえば、コーディングアシスタントはもともとGitHub Copilotを使っていましたが、Claude Code が出てきてエンジニアの間でも評判がいいということで、とあるチームがすぐに検証を始め、半年も経たずに全社的に使える状態になっていました。新しいツールに対する制約は特にないので、どこかのチームがとりあえず試してみて、良ければ自然と広がっていくような感じですね。 会社全体が新しい技術に対してオープンな姿勢だから、情報をどんどんキャッチアップしてシェアしようという意欲が生まれやすいのかもしれませんね。 Tさん そうですね。情報もそうですし、自分の考えも共有しやすいですね。Slack上などに何気なく投げた疑問に対して別角度から色んな意見が出てきて、それらを組み合わせることで自分の考えをブラッシュアップできる。そこはニフティのオープンな社風や雰囲気があってこそなのかなと思います。 後編に続きます！ 今回はニフティの2025年度 新卒社員のインタビュー（前編）の様子をお届けしました。後編は近日中に公開します。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

はじめに こんにちは。ニフティの塚崎・佐藤です。 5/22, 23の2日間にわたって開催された TSKaigi 2026 に初めて参加してきました。 TSKaigiとは？ TSKaigiは、日本最大級のTypeScriptをテーマとしたテックカンファレンスです。毎年、5月頃に開催されているようで、今年は現地参加者が約800名でオンライン参加者が約900名と合わせて1700名規模の大きなイベントとなりました。また今年の会場はベルサール羽田空港という場所で開催されました。 なぜ参加しようと思ったか 塚崎 元々、フロントエンド開発やTypeScriptが好きだったというのと、業務でも頻繁にTypeScriptを使うため今回参加することにしてみました。TSKaigi自体は昨年、オンラインで参加していたのですが、今年は同期の佐藤からの誘いもあり現地参加をしてみました。オフラインイベントへの参加経験もほぼなかったので、単純な興味というのも理由としてありました。 佐藤 普段は個人開発で最新のライブラリを試してみたり、毎日の習慣で技術ブログを読み漁ったりしています。現在所属しているチームの開発では割合としてはまだ低いですが、TypeScriptを採用する機会は増えてきており、APIの刷新ではHonoなどを採用しました。現在進行中の新規開発でも、引き続きTypeScriptを採用する予定です。 実務での経験を積むにつれて、他社エンジニアのTypeScript活用方法に興味が湧いてきました。そこで、普段からTypeScriptの話で盛り上がる同期の塚崎を誘い、今回のイベントへの参加を決めました。 塚崎のタイムテーブル 塚崎のタイムテーブル 塚崎のタイムテーブル 佐藤のタイムテーブル 佐藤のタイムテーブル 佐藤のタイムテーブル 印象に残ったセッション 塚崎 数あるセッションの中でも、特に印象に残ったのがKazuya Serizawaさんによる「アンチパターンを避ける型駆動React最適化」です。 https://2026.tskaigi.org/talks/17 こちらのセッションは、React 19から正式に登場したReact Compilerによってコンポーネントの最適化を行うという内容です。React Compilerが最適化できるのは純粋なコンポーネントだけですので、コンポーネントの純粋性をいかにして型とLintで担保するか、という型駆動のアプローチを紹介していました。また、コンポーネントを純粋に保つことは、最適化のためだけではなく、読みやすくメンテしやすいコードにも繋がると説明されていたのも印象的でした。 最適化ができない例として、以下の4つが紹介されていました。 副作用の混入 ：render中のDate.now() / ログ出力 / 乱数生成 ミュータブル操作 ：letの再代入、push / sortなどの破壊的操作 参照不安定 ：毎回新規生成のオブジェクトや関数を子に渡す 非決定的な依存 ：モジュールスコープの可変変数をrenderから触る これについては、以下のような型定義で対策をしていました。 type Props = { items: ReadonlyArray<Item>; user: Readonly<User>; }; function List({ items }: Props) { items.push(...) // コンパイルエラー const next = [...items, x]; // OK } ReactではPropsに対してミュータブル操作をしてはいけないのですが、これをReadonlyArrayやReadonlyを使って対策していました。型で定義し、そもそも書けないようにするというのは、TypeScriptの良さを最大限活かした設計だなと感じました。型定義であれば部分的にも導入がしやすいですので、現在担当しているプロジェクトにも適用してみようかと考えています。また、発展形として、Branded Typeを使った副作用のない関数しか受け付けない手法も紹介されていました。Branded Typeについては実務で使った経験もなく初めて知った手法だったので、もう少し調べてみようと思います。他にも型定義だけでなく、BiomeやOxcなどのLinterルールで防止するという多層的なアプローチも取られていました。型定義だけでは防げない操作をLinterで防ぐという手法で、型定義とLinterでより堅牢なReactアプリケーションが作れると実感できるセッションで非常にたくさんの学びが得られました。 佐藤 印象に残っているセッションは tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか（maguro） 業務に残された「よくない型」で考える「TypeScriptの難しさ」（Saji） の2つです。 前者は、型チェック（ deno check ）をはじめ、コードの解釈や実行を支える仕組みがどう変わってきたかをたどる内容でした。その中心にあるのが、JavaScriptで書かれた公式のTypeScriptコンパイラ tsc と、それをGoで再実装した tsgo です。タイトルの「tscからtsgoへ」が示す通り、Denoが模索してきた歩みが紹介されました。 jsr: や npm: 、Deno独自APIといった概念をTypeScriptが読める形に「翻訳」する仕組みが、 tsc を抱え込む状態から tsgo 、そして公式TypeScriptへと、次の3段階で外側へ移ってきたそうです。 Phase 1：embedded tsc — パッチを当てたtscをV8 isolate内で実行。挙動は安定する一方、巨大バンドルや上流への追随コストが課題。 Phase 2：forked tsgo — Go製のtsgoをサブプロセスで起動し deno check を高速化（簡易ベンチで約2.6倍）。ただしfork維持やLSP対応のコストが重い。 Phase 3：公式npmパッケージへ — forkを捨て、Deno独自の依存をローカルにmaterializeして公式TypeScriptが読める形に橋渡しする方向へ。 私自身Denoを使ったことはないのですが、 deno の裏側でこれほど大きな変遷が起きていたとは知らず、ツールの内部仕様を詳しく知ることができて、話を聞いていてとても面白かったです。「forkも再実装も避けたい」制約の中で、普段は意識しない内部の仕組みまで踏み込んで知ることで、内部アーキテクチャに対する理解が一段と深まったと感じています。 後者は、Sajiさんが実際の業務コードに残った「良くない型」（ as や @ts-ignore など）を収集・分類し、そこからTypeScriptの難しさや限界、チームでの向き合い方を考えるという内容でした。普段は細かい型まで意識せずに書いてしまうことも多いため、型との向き合い方を改めて見直す良い機会になりました。AI駆動開発にも規約として活用できそうです。 イベントに参加してみて 塚崎 TypeScriptの高度な型定義について学びが得られたのは大きな収穫でした。 他にもTanStack Start、Oxlintのような最新のフレームワーク・ツールに関するセッションもいくつかあり、技術選定やツールチェーンの見直しの際の参考にもなったかなと思います。 AI周りについても知見を深められました。特にAI活用が当たり前になった現在でいかにして品質を担保するかという視点での学びは大きなものでした。 今回のイベントに参加してみて、勉強のモチベーションも向上したので今後もTypeScriptについて勉強していこうと思います。 佐藤 登壇者や参加者の方々の知識の深さに触れ、自分のTypeScript理解の浅さを痛感しました。 セッション以外でも、各社がスポンサードでブースや企画に趣向を凝らしており、多くの学びがありました。特に、学生支援制度のあるイベントは参加者層が広く、会場全体が活気にあふれていました。参加して良かったなと思います。 高まったモチベーションをそのままに、帰宅後はさっそく自分のポートフォリオサイトの改修に取りかかりました。引き続きTypeScriptについて勉強していこうと思います。 おわりに 例年通りであれば、YouTubeにアーカイブ動画が掲載されると思います。また、登壇された方々が発表スライドを公開しているので、興味を持った方はぜひ覗いてみてください。 来年は社内のメンバーも数人誘って、一緒に参加できればと思います！ 本記事が来年以降にTSKaigiへの参加を考えている方の参考になれば幸いです。 参考記事 https://2026.tskaigi.org/

ニフティ社内で従業員が使う社内メールや予定表、カレンダー。さらには、SlackやGoogle Workspaceといった外部ツールまで、数多くのプロダクトの運用を担うのが、プラットフォームチーム（以下、PFチーム）です。従業員を「ユーザー」と呼び、日々みんなが滞りなく業務を行えるよう、縁の下で支えています。 前編では普段の業務内容や、印象深いプロジェクトについてメンバーに語ってもらいました。後編ではニフティという会社の良いところ、チームに迎えたいメンバー像、さらには各々が描く今後のキャリアについて聞いていきます。 部署や社歴の垣根なく、誰とでもコミュニケーションを取りやすい みなさんが日々感じている「ニフティの良いところ」を教えてください。 Y.Kさん まず思い浮かぶのは、フットワークの軽さと、現場に与えられる裁量の大きさですね。たとえば、私たちPFチームで新しい外部サービスを導入しようという時や、既存のツールにAI機能を追加するといった時にも基本的には現場主導で、上司の承認が下りれば推進することができます。 また、労働環境に関しては休みやフレックスの調整がとてもしやすく、柔軟な働き方ができると思います。当日朝の連絡でも調整がつけば出社時間を遅らせることができて、そこは他のIT企業で働いている人からも驚かれるポイントですね。 D.Kさん 確かに休みは取りやすいです。ちゃんと調整をすれば、平日にポンと3日くらい休暇を使って旅行に行くことも可能ですから。もちろん周囲に嫌な顔をされることもなく、むしろ「旅行どうだった？」と楽しく話を聞いてくれます。制度があるだけでなく、「休める時は休みましょう」という雰囲気が醸成されているように感じますね。 K.Gさん 会社やチーム全体に「お互いさま」という意識があって、フォローし合う文化が自然と根付いていますよね。急な体調不良で休むことになっても、本来自分がやるはずだった業務を先輩たちが回してくれていたりするので、とても助かっています。 労働環境以外の面ではいかがですか？ D.Kさん おそらく他のチームへのインタビューでも語られていると思いますが、一番は「人」が魅力的なことです。PFチームは従業員全員が「ユーザー」なので、さまざまな部署の人たちと会話をする機会があります。いつ話しかけても嫌な顔をせず対応してくれる、やさしい人が多いと感じますね。業務以外でもSlackで雑談が盛り上がることも多く、部署や社歴に関係なくコミュニケーションを取りやすいと思います。 そもそも私がニフティに入社する決め手になったのも、社内見学の際に社員が楽しそうに働く姿に惹かれ、人に魅力を感じたからです。実際に入社してからもその時のままの印象で、ギャップは感じませんね。 K.Gさん 私も先輩たちの優しさは日々感じています。このチームに入ったばかりということもあり、最初は分からないことだらけでしたが、誰に相談しても親切に対応してもらえます。PFチームに限った話ではなく、OJTで指導してくれた他チームの先輩たちも基本的に優しい人ばかりでしたので、ニフティという会社全体の傾向なのではないかと思いますね。 D.Kさんもおっしゃっていたように、他チームの方々からも口々に「ニフティには優しい人が多い」という言葉が出てきます。たまたまそういう人が集まっているのか、それとも面接時に人柄を重視されているのか、どうしてだと思われますか？ D.Kさん 色んな理由が考えられますが、一つは労働環境が良く、あまりギスギスした空気にならないことも大きいのではないかと思います。あとは、いま上にいる人たちも先輩に親切にされてきたから、自分も後輩には同じように接しようという気持ちが芽生えるのかもしれません。だとすれば、とても良い文化だと感じますし、自分たちも継承していきたいですね。 新しい知識に貪欲、パワフル……。チームが求めるメンバー像は？ そんな雰囲気の良いチームに、これから新しいメンバーを迎えることもあると思います。PFチームにはどんな人が向いていると思われますか？ K.Gさん 新しい知識を習得することに対して、意欲的な人でしょうか。特に、私が担当するアカウント系の仕事には幅広い知識が求められ、分からないことがあった時に一人で悩んでいてもなかなか解決しません。そこは遠慮なく、分かる人にどんどん質問して、貪欲に知識を吸収していく姿勢が大事だと思います。先ほども言ったように、先輩たちは嫌な顔をせず、丁寧に教えてくれるはずですので。 Y.Kさん 今の話と少し似ていますが、私は「周囲を上手に巻き込める人」が向いていると思います。PFチームではツールの刷新や新しい機能の導入といった仕事も少なくないのですが、一人で抱え込んでいてもなかなか前に進みません。周囲にどんどん声をかけ、仲間を集めて推進していくことが望ましいですし、私もそういう人と一緒に働きたいなと思います。 D.KさんはPFチームではサブリーダーという立場ですが、マネジメント視点で望むメンバー像などはありますか？ D.Kさん 現状、PFチームには8名のメンバーがいますが、それぞれ違う個性やスキルを持っていて非常に良いバランスだと感じます。そのうえで強いて言うなら、目標に向かってどんどん突き進むパワフルさを持った人ですかね。「あれもこれも導入したい」、「どんどんプロジェクトを前に推し進めたい」という強い意志を持ち、実行できる人がいると、社内システムのさらなる利便性向上や、全社的な業務効率化につながっていくはずです。ニフティはそんな意志を持った人の背中を押してくれる会社ですし、力を存分に発揮できる環境だと思います。 目指したいキャリアをふまえ、さまざまな経験を積める環境 みなさんの直近の目標や、今後のキャリアの展望などがあれば教えてください。 K.Gさん 直近の目標、というよりも課題と言うべきかもしれませんが、まずは自分が携わっているプロダクトへの理解を深めることですね。当たり前ですが、チームの先輩たちは私よりも知識豊富な方ばかりなので、そこを超えられるような知見とスキルの習得を目指したいと考えています。 今後の展望としては、開発系のスキルも高めたいという思いがあります。PFチームでも刷新系のプロジェクトなどで開発案件に関わる機会はあるので、チャンスがあれば経験を積んでいきたいですね。もちろん機会を待つだけでなく、たとえば「ここのシステムが古くなっているから刷新しませんか？」といった提案も積極的にやっていけたらと思います。 Y.Kさん 私は一つのプロダクトの成長に、最初から最後まで貢献できるような仕事をしてみたいです。今のところプロダクトの新規開発と運用のところまでは経験できているのですが、そこからさらに「成長」となると、データの分析といった要素も必要になってきます。新人の頃からデータ分析の知見やスキルも磨いてきているつもりなので、これまでに培ったものを組み合わせてプロダクトを大きく育てるような仕事にチャレンジしたいですね。 D.Kさん 私はPFチームのサブリーダーになって半年なのですが、まだまだ力不足でチームのメンバーを支えきれていないところがあると感じています。当面は、そこをしっかりやっていくことが目標です。 長期的な展望については、やりたいことがありすぎて道を決めきれていないというのが正直なところです。たとえば、セキュリティ方面の仕事もその一つ。今のPFチームで担当している社内情報システムは利便性を追求するだけでなく、みんなが安心して使えるようセキュリティの面でも万全を期す必要があります。セキュリティの知識を深めることで現在の仕事にも生きると思いますし、どんな部署に移ったとしても自分の大きな武器になると思うので、どこかのタイミングでがっつりと経験したいですね。 希望すれば、セキュリティチームへの異動も叶うものなのでしょうか？ D.Kさん そうですね。キャリア・チャレンジ制度（社内公募）がありますので、自分が経験してみたいチームが人材を募集していて、現在所属しているチームとの調整がつけば異動は可能です。 実際、スキルアップのためにさまざまな部署を経験している人もいて、本人次第で多様な経験を積める環境ではあるのかなと思いますね。 前編もご覧ください！ 今回はニフティの社内プラットフォームチームのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】社内プラットフォームを滞りなく運用し、従業員みんなの業務をサポートする【ニフティ プラットフォームチーム前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

ニフティ社内で従業員が使う社内メールや予定表、カレンダー。さらには、SlackやGoogle Workspaceといった外部ツールまで、数多くのプロダクトの運用を担うのが、プラットフォームチーム（以下、PFチーム）です。従業員を「ユーザー」と呼び、日々みんなが滞りなく業務を行えるよう、縁の下で支えています。 既存ツールの運用だけでなく、新規の外部サービスの導入検討や、時にはツールの開発までを担うというPFチーム。その詳しい業務内容や印象的だったプロジェクト、また、仕事のやりがいについて、メンバーに話を聞きました。 自己紹介 D.Kさん 2020年4月に新卒入社。業務内容はID基盤システム、コラボレーションツールの保守・運用。趣味はコーヒー。最近はハイカカオチョコにハマって自席に常備。 Y.Kさん 2019年4月に新卒入社。業務内容は社内システムの運用・保守・刷新。趣味は散歩と、温泉でゆっくりすること。 K.Gさん 2024年4月に新卒入社。業務内容は社内システムの運用・保守・刷新。趣味はゲーム、サッカー観戦、音楽を聴くこと。 「使えて当たり前」を担保しつつ、ユーザーの利便性を高めていく みなさんはニフティの「プラットフォームチーム（以下、PFチーム）」のメンバーということですが、具体的な業務内容を教えてください。 D.Kさん PFチームでは、ニフティの従業員（以下、ユーザー）が使う全ての社内システムの運用・保守・刷新を担っています。社内メールや予定表、カレンダーのほか、SlackやGoogle Workspaceなどの外部ツールまで、管理しているプロダクトは25程度。そのほか、他部署のシステムの管理のみを委託のような形で請け負ったりと、社内で使うツール関係については、大半を私たちのチームで取り扱っています。 具体的な仕事内容ですが、メインの業務は運用です。社内システムは「使えて当たり前」であり、トラブルが起こった瞬間に業務に支障が出てしまいます。ユーザーに滞りなく業務にあたってもらうため、問題が生じた場合でも影響を最小限に抑えながら運用する必要があります。 また、既存のツールの運用だけでなく、外部ツールの新しい機能を取り入れたり、新規サービスの導入を検討したりと、現在の水準は保ちつつユーザーさんがより便利に仕事ができるようサポートするのも、私たちの重要な業務ですね。 現在、PFチームは何名体制で業務にあたっていますか？ D.Kさん 現在は8名です。チームは大きくアカウント系、コラボレーションツール系に分かれていて、K.Gさんには主にアカウント系のプロダクトを、Y.Kさんは主にコラボレーションツール系のプロダクトを担当してもらっています。 では、それぞれご担当されている領域やプロダクトの詳細について、お二人からご説明いただけますか？ K.Gさん 私はアカウント系のチームで、主にユーザーのIDやパスワードの管理を担当しています。新たに入社された人が初出勤して仕事をスタートする前日までには、アカウントを付与して使える状態にしておかなければいけません。他にも、会社から支給されるパソコンのクラウド上での通信の管理や、セキュリティファイルの管理なども行なっています。後者で言うと、たとえばファイルのなかに個人情報が入っていないかをチェックするなど、幅広い業務がありますね。私はこの部署に来てまだ日が浅いのですが、かなり幅広い知識を求められる仕事だと感じています。 Y.Kさん 私はコラボレーションツール、分かりやすいところではSlackやGoogle Workspaceなどですが、その他にもさまざまな外部ツールをユーザーが「普通に使える状態」にするというのが大きな役割です。仮に不具合などがあって使用できない時に対応にあたったり、ユーザーからの問い合わせにも回答したりしています。 そうした運用以外に、「刷新」の役割も担っています。いま使用しているツールよりも便利なもの、新しいものが出てきた時に導入を検討したり、実際に置き換えを推進したりする仕事ですね。今もちょうど、RPAツールを別のものに置き換えるプロジェクトが動いています。 新しいツールに置き換える判断は、ある程度チームに委ねられているのでしょうか？ Y.Kさん そうですね。基本的にはプラットフォームチームのメンバーで検討し、上長のOKが出れば導入を推進できます。その後、セキュリティの要件を満たしているかどうかなどのチェックを経て、最終的に判断をするという流れですね。 ただ、もちろん刷新前のツールのほうが使い慣れていたり、愛着を持たれているユーザーもいるので、いきなりガラっと変えるのではなく、従業員と対話をして新しいツールの情報を伝えたり、利点をアピールしたりといったコミュニケーションは大事にしています。 外部サービスの利用から「自社開発」に切り替え、業務効率化を実現 これまでに担当したプロジェクトのなかで、特に印象深いものを教えてください。 Y.Kさん 私は、アルバイトや派遣社員用ID作成システムの刷新プロジェクトが印象に残っています。新しく入ったアルバイトの方の情報を入力するとアカウントが自動発行されるというシステムなのですが、もともとはかなり昔に外部のパートナー企業に作成してもらったもので、当時の仕様書も実際のソースコードも確認できないような状態。半ばブラックボックス化していたんです。 しかも、古いシステムなので頻繁にエラーが起こるような状態になっていて、その度にサーバーを再起動していたのですが、そうした運用を続けていくといつかシステム自体が使えなくなってしまう可能性もある。そこで、システム自体を刷新することになりました。 既存システムの運用だけでなく、そうした、いわば「古い遺産」を刷新するような業務もあるということですね。K.Gさんはいかがですか？ K.Gさん 私が担当した印象深いプロジェクトは、社内セキュリティレベル間のファイル移行ツールを刷新するというものです。もともとは外部提供を受けていたSaaSのシステムを社内で開発し直し、さらに改良を行いました。最も大きな改良点としては、それまではファイルを移行する際に、外部への不正なデータ持ち出しがないかどうかを目視でチェックしてから承認していたのですが、一部にAIを導入して自動で検知できるようにしたこと。いわゆる、DLPのシステムを導入しました。これにより、コスト削減とセキュリティレベルの向上につながり、ファイル移行ツールを使う業務の効率化につながったと思います。 そもそも、外部サービスから自社開発に切り替えた理由は何だったのでしょうか？ D.Kさん 一番は自社開発であれば、色んな機能を追加したり、使いやすくシステムを改良したりと、カスタマイズがしやすいことです。ファイル移行ツールに関しては、先ほどK.Gさんが言ったように、それまでのツールでは目視で一つひとつチェックしていたため、膨大な人的リソースが割かれていました。DLPを導入しようにも、既存のサービスの仕組みではなかなか組み込むことが難しい。また、DLP以外にも、今後ユーザーからの要望に応じてカスタマイズしやすいものにしたほうがいいだろうということで、自社開発に舵を切りました。 プラットフォームチームというと「既存システムをいかに滞りなく動かすか」がメインの業務というイメージですが、開発寄りのプロジェクトも結構あるのですね。 D.Kさん 最近はちょこちょこありますね。プラットフォームチームは企画から開発、さらには運用までを担うほか、レイヤーもインフラのサーバーからネットワーク、アプリケーションに至るまで、本当に「何でもやります」という感じのチームなので、活躍の幅が広い部署と言えるかもしれません。 ユーザーの「顔が見えること」が一番のやりがい みなさんは現在のプラットフォームチームの業務において、どんなところに楽しさ、やりがいを感じていますか？ Y.Kさん 一番はユーザーが社内という、最も身近な場所に存在していること。問い合わせに対して回答や解決をした時にも、すぐに「助かりました。ありがとうございます」と反応をもらえるのは嬉しいですし、やりがいにつながっていますね。 K.Gさん 私も似た答えになってしまいますが、ユーザーさんと直接やりとりできる点ですね。「こういう機能があるといい」といった要望も直で伝えてもらえるので、とても取り組み甲斐があると感じています。時には難しい要望もありますが、どれだけユーザーに寄り添えるか、実現に向けて努力できるかが自分の仕事だと考えていますので、そこはこれからも大事にしていきたいです。 ちなみに、K.Gさんは3人のなかでは最も若手ですが、プラットフォームチームのように色んなことができる現場だと、幅広い知見やスキルを獲得するという点でも大きいのではないでしょうか。 K.Gさん それはありますね。どちらかというとニフティには開発がメインのチームが多いと思います。そのなかで、システムの運用だったり、ユーザーさんと直接コミュニケーションできたりするのは貴重な機会。なおかつ、開発の案件もたまにあるので、おっしゃる通り色んな経験を積むことができるチームですね。 D.Kさん 私自身もわりと何でもやりたいタイプなので、今のチームはとてもフィットしていると感じます。あとは、二人が言ってくれたように、ユーザーと直に話ができるのは大きなやりがいにつながっていて。ユーザーと対話をして、トラブルシュートをして、その後のリアクションまでもらえる。そういう体験ができるチームって、ニフティのなかでもあまりないと思いますので、そこは大きな喜びですね。 後編に続きます！ 今回はニフティの社内プラットフォームチームのインタビュー（前編）の様子をお届けしました。 続きは近日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

2026/6/18 に開催される 【日経×ニフティ×シンプレクス】AI活用の試行錯誤を再現可能にするための事例紹介 に当社エンジニアが登壇いたします。 ニフティのエンジニアの小林が、AIを活用した開発業務の効率化についてお話しします。 ドキュメントの作成や管理は開発業務の中でも重要なタスクの一つですが、対話の中で発生する設計の意図や判断を残すことはかなり手間暇がかかることでした。この課題にどう取り組んだのでしょうか？ 登壇のスケジュールは以下の通りです。 タイトル 「なぜそう決めたのか」を残し続ける仕組み ― Notion AI カスタムエージェント × Slack連携による設計判断の自動記録 日時 2026/6/18(木) 19:00 〜 21:00 （イベント開催日時） オンラインで視聴可能なイベントです。ぜひ以下のイベントページからご参加ください。 https://nikkei.connpass.com/event/394429/

5/29（金）の19:00に開催されますLeSS’ Morning 「プロダクトバックログリファインメントについて探求する」にニフティが会場提供いたします。 イベントの詳細は以下をご覧ください。ScrumやLeSSに興味がある方、学びたい方はぜひご参加ください。 https://techplay.jp/event/995813 ニフティは2026/5/7に品川インターシティへ本社移転いたしました。 西新宿ではありませんので過去にニフティに来社された方はご注意ください。 https://www.nifty.co.jp/company/outline/