ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。 これまでにも、「オンラインサポートチーム」や「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/

ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。 今回はその一つである、「AI活用推進チーム」にスポットを当てます。前編では、活動に参加するきっかけや普段の活動内容などについて聞きました。後編では、印象に残っているAIチームでのプロジェクトや所属部署の業務とチーム外活動の両立について、また、今後チャレンジしてみたいことについて語ってもらいます。 エンジニアだけでなくビジネスサイドからも「AIを使いたい」という声が挙がるように みなさんがAIチームで手がけたプロジェクトのなかで、特に印象深いものを教えてください。 藤岡さん 前回も少しお話ししましたが、セキュリティチームに寄せられる社内からの問い合わせに対して、自動回答を行うAIエージェントを開発しています。昨年の夏頃から着手し始めて、もう少しでリリースできるところまできました。 もともとはセキュリティチームにいる同期から山本くんが相談を受けて、スタートしたプロジェクトです。本当にゼロからの開発で、「どんなシステムを作り、どういったゴールを目指すのか」「どう工数を削減するか」「いかに効果を最大化するか」など、相談してくれた同期と山本くんと私の3人で試行錯誤しながら進めてきました。 上司から指示を受けたタスクではなく、自分たち自身でやりたいと始めたことが形になり、それが会社のためになる。入社2年目にしてそういう経験をできたのは大きいと思いますし、印象深いですね。 山本さん 私もその案件は印象深いのですが、他で言うとカスタマーセンターの部署から寄せられた相談ですね。お客様対応のログデータを分析するにあたって、個人情報や社内情報のマスキングを自動化できないかと。使えそうなツールや技術を使ったり試したりするうちに知見も溜まっていきましたし、単純に楽しかったですね。マスキングは個人的にあまり触れてこなかった領域でもあるので。技術的に難しい部分も多く完成には至っていませんが、なんとか形にしたいです。 中井さん、小林さんはいかがですか？ 中井さん 少し古い話ですが、2023年頃に社内のエンジニアがニフティ内で使うSlackBotを開発したんです。「myfriendGPT」という、ChatGPTのAPIを活用したツールでした。開発当初に比べてChatGPTのモデルも高性能になっていますし、画像読み込み機能もつけたいということで、私がツールを引き継いでリニューアルすることになったんです。これはエンジニアとしての価値観が変わったプロジェクトとして、印象に残っていますね。 ニフティって全社的にインナーソースを推奨していて、社内の誰かが作ったソースコードに別の人が機能を追加するなどして、「みんなで育てていこうよ」みたいな思想があるんです。ある時、自分がリニューアルしたSlackBotにまた別の機能を付与したBotを作った人がいて。それまで自分は「ツールを提供すること」が貢献だと思っていましたが、新しいツールのベースとなるものを作ることも、別の形の貢献なんだなと気づきました。 小林さん もちろん個別のプロジェクトで印象に残っているものはたくさんありますが、私のなかではAI活用を推進する活動を続けられていること自体への感慨がありますね。社内SlackにAI相談窓口を作った当初は10人くらいだったチャンネルが、今では80人に増えて多くの相談が寄せられるようになりました。嬉しかったのは、エンジニアだけでなく、営業などビジネス側の社員からも反応してもらえたこと。「これまであまりAIに触れてこなかったけど、このチャンネルを通じて興味を持ち、今は積極的に活用している」と言ってくれたんです。 AIシステムを開発するだけでなく、チャンネルに寄せられる相談に対して「こんなツールがありますよ」「こういった活用方法がありますよ」といった提案もしていて、少なからず各部署の工数削減に貢献できている実感がありますね。 チーム外活動も大切な仕事。本業との両立と所属部署の理解 山本さんはOJTが終了してすぐにAIチームへの参加を決めたそうですが、配属先が決定してこれから仕事を覚えていこうという時期にチーム外活動も並行して行うのは、負担が大きいのではないかと感じます。不安はなかったですか？ 山本さん 私が入った時点では、そこまで大きな負担になる印象はなかったです。当初は有志が集まって、各自の課題をAIで解決した知見を共有するくらいの温度感でしたから。私もそれまで趣味としてAI関連の情報は集めていたので、色々と情報交換ができたらいいなという気持ちでした。ただ、社内からの相談窓口を設けて、去年の年末あたりから少しずつ本格化してきたこともあり、段々と両立が難しくなってきていることは事実ですね。 それでもやはり、両方やりたいと。 山本さん やりたいですね。所属部署の業務はもともと私が持っていた技術とマッチしていなかったところもあり、インプットするべきことが非常に多いんです。最初はそこで気持ちが落ち込むこともあったのですが、AIチームの集まりが、ある意味「憩いの場」になっていました。本業以外で気分転換になったり、モチベーションをキープできる場があるというのは、とても大きいと思います。 小林さん 私と山本くんは同じ部署なのですが、本業も忙しいですしAIチームでの相談案件も詰まってきていて、現状は完璧に両立ができているかというと微妙なところです。ただ、私たちとしては所属部署での仕事も、チーム外活動もどちらも頑張りたい。マネージャーにも相談したところ、業務時間の2割はAIチームに使っていいと言ってくださっています。ですから、本業が多忙な時期でもなるべく2割はチーム外活動の時間を確保するようにしていますね。私の上司を含め、何かやりたいと言えば基本的には背中を押してくれるのがニフティの良さだと思います。 藤岡さんは、業務との両立についてはいかがですか？ 藤岡さん 私も割合で言うと、やはり本業8割、AIチーム2割といったところです。私と中井さんは同じ部署なのですが、わりと柔軟性が高いというか、上司、部署メンバーとも非常に理解のある方ばかりなんです。たとえば、AIチームのほうで緊急の大きな案件が入った時には、そっちに全振りしてもいい、くらいのことを言われています。つい先日も、丸々1日をAIチームに使わないといけない状況があったのですが、その時は所属部署の方がフォローしてくださいました。上長だけでなく、全社的にこうした活動への理解があるので、かなりやりやすいですね。 中井さん 本当にありがたい限りです。上長や部署のメンバーも「チーム外活動も、あなたの大事な仕事だからね」という理解のもと、背中を押してくださっていると感じます。だから、AIチームの仕事が忙しい時はフォローするよと。 あとは、チーム外活動も基本的には会社をよくするためにやっていることであって、それをみんなが理解してくれているんですよね。「確かに、それは今やるべきだよね。だから、部署のタスクのなかで期限に余裕があるものは調整して、AIチームにリソースを割いたほうがいいよね」といった柔軟性があるんです。それは我々AIチームに限らず、全てのチーム外活動に対して同じような意識があるのではないかと。 AIの価値を最大化し、ニフティ全体へ広げていく 最後に、みなさんがこのAIチームで今後チャレンジしたいことを教えてください。 山本さん 当面の目標としては、先ほどもお話ししたようにセキュリティチームへの問い合わせを自動回答するAIエージェントを形にしたいですね。また、それを実装して効果測定ができてからの話にはなりますが、カスタマーセンターだけでなく他の部署にもQ＆Aのやりとりはあるので、色々なケースで展開できるようなものを開発して効果を最大化したいと考えています。 もう少し、先の目線で言うと、そもそもAIって単純作業や運用作業を代替させて、人間が新しいアイデアを発想したり、サービスの品質向上に注力できる状況を生むためのもの。ですから、社内のAI活用をさらに推進して、ニフティの社員が本来やるべきことに集中できる環境をつくっていきたいですね。 藤岡さん 直近では、このAIチームで得た新しい知見を生かして、所属部署の業務改善につなげていきたいと思っています。自分たちを被験体にして、「こんなシステムを作って、この業務を自動化しました」という事例を数多く生んでいきたいですね。 最終的な目標は、それら事例を全社に公開して、今はあまりAIを活用できていない人が関心を持つきっかけを作りたいです。AIのことがよくわからない、うまく使えていない人の気持ちは、僕自身がそうだったからこそよくわかります。僕がこの1年間、AIチームで体験した驚きを、多くの人にシェアしたいですね。 中井さん 相談窓口に寄せられる相談を見ていると、どのお悩みにも共通点があるというか、同じ技術で解決できそうなことって意外と多いなと感じます。先ほど山本くんが話してくれたマスキングの件もそうですよね。 最初はイチ部門の課題を解決するために作ったシステムが、じつは多くの職種の業務に適用できるということになれば、我々がかけた労力が何倍もの効果を生んで報われます。ですから、相談窓口に寄せられる問い合わせをなるべく丁寧に拾い上げて、できれば具体的なプロトタイプを開発して提案するというところまで踏み込んでいきたい。そういう事例を多く作っていきたいと考えています。 では最後に、リーダーの小林さん、締めていただけますか。 小林さん まずは今やっていることを引き続き頑張ることですね。もっと多くの人に、幅広い部署に相談窓口の存在を知ってもらい、それに対して我々に何ができるかを突き詰めていく。あとは、AI活用のハードルを少しでも下げていきたいと考えています。たとえば、AIツールを使って開発したいエンジニアにAWSのアカウントを貸し出す時も、現状は申請の手続きにやや手間取る部分があります。もちろん、セキュリティ面も考慮してある程度のハードルは設けなくてはいけませんが、できれば多くの人がもう少し気軽に使ってみたいと思える仕組みをつくっていきたい。エンジニアに限らず、ビジネスサイドの人たちも当たり前にAIを活用できる環境をつくるためのサポートをしていきたいですね。 前編もご覧ください！ 今回はニフティのAI活用推進チームのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】社内各部署の困りごとをAIで解決。好きな分野を突き詰めながら、本業外でも会社に貢献する【AI活用推進チーム 前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

こんにちは。ニフティの基幹システムグループ インフラシステムチームに所属している轟木です。 担当業務はオフィス及びデータセンターのネットワーク設計・構築・運用です。 今回は、育休中に感じた家事分担のモヤモヤをきっかけに作った「家事トラッキングシステム」について紹介します。 家事はお互いにやっているはずなのに、なぜか「自分の方が多くやっている気がする」。この感覚を減らすために、Slack、Google Apps Script、Google スプレッドシート、Looker Studioを組み合わせて、家事を記録・可視化する仕組みを作りました。 背景：既存アプリが我が家に合わなかった 夫妻で同時期に育休を取ったことで、家にいる時間が増えました。すると、これまで見えにくかった家事の分担が気になるようになりました。 お互いに家事も育児もしているのに、 自分の方が家事を多くやっている気がする 相手がいつ何をしてくれたのか分かりにくい 「やった」「やっていない」が感覚ベースになり、話し合いづらい という状態になっていました。 最初は家事分担アプリも試しましたが、用意されたテンプレートが我が家の家事の粒度や負担感と合わず、記録のためだけに新しいアプリを開く習慣も定着しませんでした。 そこで、普段から使っているSlackとスプレッドシートを中心に、自分たちの生活に合わせた仕組みを作ることにしました。 Claudeに要件定義から相談した 最初にClaudeへ、改善したい点と使いたいサービス名を伝えました。 入力はできるだけ簡単にしたい 夫妻それぞれの家事をポイント化したい Slack、Google スプレッドシート、Looker Studioを使いたい 将来的にはAlexaから音声入力したい するとClaudeは、目的、スコープ、システム構成、データ設計、運用ルールまで含めた要件定義書を作ってくれました。 育児中でまとまった時間を取りづらい中でも、普段の業務ではあまり触らないSlack AppやGASまわりの設計・実装を短時間で進められました。 作ったもの 今回作った構成は次の通りです。 流れはシンプルです。Slackで家事ボタンを押すと、GASがイベントを受け取り、Google スプレッドシートにログを書き込みます。そのログをLooker Studioで集計・可視化します。 ポイントは、入力導線を「普段から開いているSlack」に寄せたことです。よく使う家事はボタンとして常に表示し、頻度が低い家事はプルダウンから選べるようにしました。 実際のSlack画面は以下のような形です。 家事をしたら、該当するボタンを押すだけで記録完了です。できるだけ考えずに入力できるようにしたことで、記録のハードルを下げられました。 工夫したところ 家事マスタをスプレッドシートで管理する 家事マスタはコードに埋め込まず、Google スプレッドシートで管理しました。 家事マスタ内の家事項目やポイントを変えたい時は、スプレッドシートを編集するだけで済みます。運用しながら家庭内ルールを調整しやすいようにしました。 ポイントは1〜5点で、作業時間だけでなく、頻度・負担感・心理的ハードルも考慮して夫妻で決めています。 ログを集計しやすい形にする 家事を記録するたびに、ログシートへ1行追加する形にしました。 ログには、日時、記録者、家事ID、家事名、ポイント、カテゴリ、入力経路を保存します。後からLooker Studioで集計しやすいように、1回の家事を1行として扱うシンプルな形にしています。 Slackボタン方式にした Slack入力は、スラッシュコマンドではなくボタン方式にしました。 スラッシュコマンドは3秒以内にレスポンスを返す必要があります。一方、GASのWebアプリはコールドスタート時に数秒かかることがあり、タイムアウトする可能性があります。 そのため、ボタン付きメッセージからGASのエンドポイントを呼び出す方式にしました。ボタン選択にすることで、家事名の表記ゆれも避けられます。 Looker Studioで可視化する 記録したログは、Looker Studioで可視化しました。 主に見ているのは、今週の家事ポイントと、どのジャンルの家事が多いかです。 ポイントで家事の大変さを完全に表せるわけではありませんが、偏りや貢献が数字で見えるだけで、感覚だけで話すより冷静に振り返れるようになりました。 導入して変わったこと 導入して一番変わったのは、「自分ばかり家事をしている」という感覚が減ったことです。 数字として見えるようになると、相手がやってくれていた家事にも気づきやすくなります。また、自分のポイントが増えると少しうれしく、家事に対するモチベーションも上がりました。 誤タップをきっかけに「押したならやるか」と実際に家事をすることもあり、記録の仕組みが行動にも少し影響するのは想定外でした。 苦労しているところ：Alexa連携 次の改善として、Alexaからの音声入力にも挑戦しています。当初はAlexaをメイン入力、Slackボタンを補助入力にする想定でしたが、現在はDeveloper Consoleのシミュレータでは動く一方で、実機ではLambdaまでリクエストが届かない状態です。 今回は完成しているSlack入力を中心に紹介しましたが、音声入力までできると、さらに記録のハードルを下げられそうです。 まとめ Claudeに要件定義から相談し、Slack、GAS、Google スプレッドシート、Looker Studioを組み合わせて、家庭内の家事トラッキングシステムを作りました。 使っている技術はどれも一般的なものです。それでも、普段の生活に合う入力導線を作り、家事を自分たちの基準で定義し、リアルタイムに可視化することで、家事分担のモヤモヤを減らすことができました。 今回の一番の学びは、AIを使うことで、既存アプリでは合わせきれなかった家庭ごとの事情を要件として整理し、自分たち用の小さな仕組みに落とし込めることです。 同じように、家庭内のタスク管理や家事分担にモヤモヤを感じている方の参考になればうれしいです。

概要 ニフティでは、エンジニアや企画・営業職・カスタマーサポートの方も含め、業務にAIを活用し、仕事の作業効率化をしています。 社内では、定期的にどのようなAIサービスを使っているか、AIによって削減した仕事はあるかといったAIの業務活用に関するアンケートを全社員・派遣社員にとっています。 今回は、このアンケート結果をお伝えします。 結果（2026年2月時点） 回答数：323件 弊社で働いている正社員・派遣社員を対象としています。 社内利用可能な汎用的なAIサービスを利用しているか 323人のうち約90%以上の方が、AIを利用しています。 利用しているAIを教えてください。 Geminiや、Notion AI、GitHub Copilotが多く使われていました。 補足ですが、ニフティでは「生成AIサービスを利用する上でのセキュリティ上の注意事項」がガイドラインとしてまとめられています。 ガイドラインに基づいて各種AIサービスの業務利用可否が確認されており、「業務利用可能なAIサービス」として数十サービスがまとめられていますが、広く常用されているのは一部になります。 ちなみに画像の一番上のmyfriendGPTは、以前記事( https://engineering.nifty.co.jp/blog/16019 )で公開しているものになります。 AIサービスの利用頻度を教えてください。 毎日使っている人が66%、週に数回とあわせても90%以上と頻度が高いようです。 AIサービスを利用する主な目的と、 1ヶ月あたりで 削減できたと思う工数を教えてください 今回エンジニア職以外でも同じ質問でお聞きしたので、ソフトウェア開発や運用で利用していないの回答数が多くなってしまっています。 どの目的でも1ヶ月あたり1~4時間は削減できたが多そうです。 AIを活用し始めた業務や、効率化が進んだ事例があれば教えてください。 各業種視点からいろいろな事例をいただきましたので、一部抜粋でありますが、以下にご紹介いたします。 エンジニアから C のソースが消失していてビルド済実行ファイルしかない状態から、依存している関数を逆コンパイルしてソースがある .c ファイルに移植し、正常に動作した。人間がやったらかなり時間の掛かる作業が 1時間足らずで完了した。 有識者不在のレガシーシステムのソース解析は大分助かってます。 etc 企画・営業職から 集計作業、週一の営業成績ランキング作成、コンテスト用ポスター作成 月1回の取引先への報告資料作成で、従来はNotionに記述した履歴50～100件を1件ずつスプレッドシートにコピペしていたが、AIを使って履歴を分析し自動的にスプレッドシートに記述するプログラムを作成させて、2日かかっていた作業を約2時間に短縮した 企画や施策の案を作る上での壁打ちや、概算費用の見積もり 損益計算表をAIに作成してもらってる。また、資料作成の際の市場分析にも利用している etc まとめ ニフティでは、業務のAI活用を積極的に推進しています。 社内でのAI活用を推進するために、社内有志によるAI活用推進のチームもあります。 先日インタビュー記事も掲載いたしましたので、ご興味があればご一読ください。 https://engineering.nifty.co.jp/interview/37140 AIに興味があり、業務でもAIを活用していきたい方など、ご興味があればニフティで一緒に働きませんか？

はじめに はじめまして。2025年9月に入社したshun-itoと申します。所属は基幹システムグループ インフラシステムチームです。担当業務はオフィス及びデータセンターのネットワークの設計・構築・運用・保守です。 趣味はバスケやボウリングなどで体を動かすことと、お酒（最近は特にクラフトビールと日本酒）を飲むためにお出かけすることです。 これまでの経歴と転職のきっかけ 前職では某事業会社（非IT系）の子会社に在籍しており、セキュリティ系システムのインフラ部分（ネットワーク、サーバ）の設計・構築を担当しておりました。 前職での私のポジションは顧客（親会社のシステム部）の要望のヒアリングや進捗報告、システム開発ベンダーへの依頼や進捗管理を担当しておりました。ですので、自分で手を動かしてシステムに触れる機会があまり無く、ステークホルダーとのコミュニケーションを取る時間が業務の大半を占めておりました。 私は自分の手でシステムに触れる方が性に合っていると感じ、ベンダーへ委託するよりも内製で業務を遂行する会社に転職したいと考えるようになりました。また、前職では運用・保守は担当していなかったので、より幅広い工程に携わりたいとも考えておりました。 業務を内製化していること・自身の技術領域（主にネットワーク）と一致していること・できるだけ幅広い工程に携われることの3点を軸として転職先の候補となる会社を調べていたところ、ニフティにたどり着きました。 ネットワークエンジニアとして当然ニフティは存じ上げており、転職活動の早い段階で候補に上がりました。他にも候補は何社かありましたが、他の会社と比較すると求められるスキルや経験が私の持つものと共通点が多く志向性が合いそうだと考えて応募し、幸いにも内定を頂くことができました。 入社して感じたこと 応募した職種は文字通り「ネットワークエンジニア」でしたので、概ね予想していた通りの業務内容ではありました。 しかし、一口に「ネットワークエンジニア」と言いましても、やはり会社によって採用している技術領域には僅かな違いがあります。先ほど「求められるスキルや経験が私の持つものと共通点が多かった」と申し上げましたが、僅かに違う技術領域の習得は必要になりましたので、慣れるまでの苦労はありました（ニフティに転職するまでは、CiscoやJuniperの機器を使用したオンプレのネットワークの経験しかなく、AWSやAzure等のパブリッククラウドを使用した経験がありませんでした） ただ、オンボーディングの内容が体系的にまとめられており、何をどの順番で習得していけばいいのかが分かりやすかったのが大きな助けになりました。 今後の目標・抱負 実は私は僭越ながらも「リードエンジニア候補」という枠で入社させていただきました。過去にもチームリーダーの経験（あまり自覚は無いですが周りからはそう見られていたようです）はありましたが、ニフティのリーダークラスの方々を見ていると、知識の広さや深さ、そして判断の速さに驚かされる機会も多いです。そういった方々が身近にいらっしゃることは大変心強いのですが、その一方で将来的には自身がそのような立ち位置に付いていることを期待されていると考えると「本当に自分で大丈夫かな・・・？」と不安になることもあります。 今後は技術や知識を身に着けていくことはもちろん、リーダーシップを発揮できるようなコミュニケーションスキルも身に着けていき、期待に応えられるようにリーダーとして活躍していきたいです。 最後に ここまで読んでいただきありがとうございました。 ニフティは提供サービスが多く、その分採用している技術領域の幅が広いので自分に合ったチームが見つかりやすい会社だと思います。 「自分の得意分野で活躍したい」という想いも「新しいことにチャレンジしたい」という想いも叶えられる環境があります。 少しでもニフティにご興味を持っていただけたのであれば、ぜひ応募していただき、カジュアル面談や面接でお話してみませんか？ 皆さんと一緒に働ける日をお待ちしております！

はじめに こんにちは！ マイニフティチームの寺島です。 最近はAIエージェントでの並列開発が活発になってきましたね。 同じリポジトリ内で、一つのタスクをしている間に別のタスクを実施したいことが多々出てくる昨今。 ついに私も git worktree に入門しました。 AIエージェントにバリバリ並列作業をしてもらう前に、機能について知っていると安心してお任せできますので、お勉強をしました。 せっかくの機会なので簡単に、 git worktree についてハンズオン形式でまとめてみましたので、良ければ読んでいただけると嬉しいです。 git worktreeとは Gitで「別の作業領域（ワークスペース）」を構築して並行作業を行う機能は、 git worktree （ワークツリー） と呼ばれます。 git worktree を使えば、1つのリポジトリから複数の作業ディレクトリを別々の場所に作成し、それぞれ異なるブランチを同時に展開しておくことができます。 1. ハンズオン用のリポジトリを作成する まずはベースとなるリポジトリを作成し、最初のコミットを行います。 mkdir git-worktree-demo cd git-worktree-demo git init echo "Initial commit" > README.md git add README.md git commit -m "feat: add initial README" 2. 新機能の開発を始める（メインの作業） 新しい機能（ feature/A ）の開発を開始します。 git checkout -b feature/A echo "WIP: Feature A working..." > feature_a.txt ここで git status を確認すると、 feature_a.txt が未追跡（Untracked）の状態で残っています。 この未コミット状態をキープしたまま 、次の手順に進みます。 3. worktree を使って別ディレクトリで作業する 現在のリポジトリディレクトリの外（一つ上の階層）に、 hotfix 用のディレクトリを作成し、新しいブランチ hotfix/bug-fix を割り当てます。 # 現在のディレクトリの隣に、新しく "hotfix-dir" という作業ツリーを作成する git worktree add ../hotfix-dir -b hotfix/bug-fix main 新しい作業ディレクトリである ../hotfix-dir に対して、 -b オプションで新ブランチ hotfix/bug-fix が main ブランチから作成されます。 作業ツリーの一覧を確認してみましょう。 git worktree list 出力例: /path/to/git-worktree-demo <ハッシュ値> [feature/A] /path/to/hotfix-dir <ハッシュ値> [hotfix/bug-fix] これで、1つのローカルリポジトリを共有しながら、2つのディレクトリで別々のブランチが展開されている状態が作れました。 4. 別タスクを実施する 新しく作られたディレクトリに移動して作業します。 cd ../hotfix-dir echo "Fix critical bug" > fix.txt git add fix.txt git commit -m "fix: resolve critical bug" 5. worktree を片付けて元の作業に戻る 別タスクが終わったので、元のディレクトリに戻り、不要になった worktree を削除します。 # 元のディレクトリに戻る cd ../git-worktree-demo # 使い終わったworktreeを削除する git worktree remove ../hotfix-dir Tips: もしエクスプローラー等で直接ディレクトリを削除してしまった場合は、 git worktree prune コマンドを実行することでGitの管理から綺麗に切り離すことができます。 最後に、元のブランチ（ feature/A ）の状態を確認してみましょう。 git status 先ほど作りかけた feature_a.txt が未追跡のまま、残っていることが確認できると思います。 おわりに 今回のハンズオンのまとめです。 git worktree add <パス> -b <新ブランチ名> <派生元ブランチ> 別ディレクトリに新しい作業ツリーを作成する。 git worktree list 現在展開されている作業ツリーの一覧を確認する。 git worktree remove <パス> 不要になった作業ツリーを安全に削除する。 よい並列開発ライフが送れることを祈っています！