ニフティ株式会社 の技術ブログ
全517件
ニフティに新卒入社したエンジニアは、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 <パス> 不要になった作業ツリーを安全に削除する。 よい並列開発ライフが送れることを祈っています！
はじめに はじめまして！技術基盤グループ SRE/QAチーム所属の鈴木です。 現在はニフティが提供するさまざまなサービスの品質保証業務を担当しています。 今回は、なぜ私がニフティへの転職を決めたのか、そして実際に入社してみて感じた「リアルな空気感」についてお話ししたいと思います。 これまでのキャリア 前職では客先常駐（SES）のQAエンジニアとして、さまざまなプロジェクトのテスト業務に携わっていました。 テスト計画から実行まで一貫して経験する中で、「第三者の視点」から品質を担保するためのスキルを磨いてきました。多様な現場の文化や開発フローを実体験として学べたことは、今の自分にとって大きな強みになっています。 転職のきっかけ 日々の業務にやりがいを感じていた一方で、外部からの支援という立場上、関われる範囲や期間に限界があることにもどかしさがありました。 リリースして終わりではなく、その後のエンドユーザーの反応を見ながら愛着を持ってプロダクトに向き合いたい！自分たちのサービスを自分たちの手で育てていく、という当事者意識を持って伴走できる環境を求めていました。 選考について 選考はオンラインで行われましたが、画面越しでも伝わってきたのは「対話の真摯さ」でした。 単に「何ができるか」というスキルの確認だけで終わらず、私がこれまでのキャリアで大切にしてきた価値観や、仕事に向き合う姿勢、そして「これからどんなエンジニアになりたいか」という将来の展望を、時間をかけて丁寧に掘り下げてくれました。 面接というより、これからの「理想のチーム」について一緒に議論しているような感覚になり、選考の段階から一人の仲間として対等に向き合ってもらえたことが、入社を決める大きな後押しになりました。「この人たちとなら、本気で良いものが創れる」と確信できたのを今でも覚えています。 入社後に感じたニフティの魅力 入社して驚いたのは、チームの垣根を越えたコミュニケーションの活発さです。 オープンな文化 チャットでのやり取りはもちろん活発ですが、何より「ちょっと相談いいですか？」と席を立ってふらっと声をかけられる、物理的な壁のなさが心地よいです。 チームやプロダクトが違っても、すれ違いざまに雑談からアイデアが生まれたり、困っている時にすぐ横から助け舟が出たり。リモートではなかなか難しい、「温度感の伝わるコミュニケーション」が自然に生まれるので、入社直後の私にとっても非常に心強い環境でした。チームの中に閉じこもらず、会社全体が一つの大きなチームのように動いている感覚があります。 「誰が」ではなく「何を」を大事にしてくれる 面接の時に感じた「誠実だな」という印象は、入社してからも全く変わりませんでした。 新しいメンバーの意見＝新しい視点として歓迎してくれる雰囲気があり、「それいいですね！」と受け入れてくれます。 「これを言ったら変に思われないかな？」なんて余計な心配でブレーキをかける必要が全くないので、入社直後から伸び伸びとチームに溶け込むことができました。 これからやっていくこと これから先、特に力を入れて取り組みたいミッションが2つあります。 「ニフティのサービスは使いやすい」を当たり前に ニフティには歴史あるサービスから新しいサービスまで幅広くありますが、そのすべてをユーザーの皆様に笑顔で使ってもらえるようにしたいです。 バグがないのはもちろんのこと、「安心して使い続けられる」という一歩先のクオリティまで、サービスの使い心地や安心感をQAの立場から支えていくつもりです。 QAの枠を超えて、みんなで「良いもの」を創れる組織へ 正直なところ、QAチームとしてはまだまだ伸びしろがある、とても面白いフェーズです。 ただテストをするだけではなく、開発プロセス全体を「品質」という視点で考え、エンジニア全員が品質に自信を持ってリリースできるような、攻めのQA組織を創り上げていきたいです。 最後に ニフティは、一人ひとりの「やってみたい！」という情熱を尊重し、それを叶えるチャンスをくれる会社です。 「この技術を導入してみたい」 「こんな組織にしていきたい」 そんな思いや、何か成し遂げたい志を持っている方に対して、「まずはやってみなよ」と背中を押してくれる仲間がここにはいます。 私たちと一緒に、ニフティの新しいサービス品質を、そして最高のチームを創っていきませんか？
はじめに お久しぶりです！3年目社員の藤岡、山本です。 2026年4月15日〜17日に東京ビッグサイトで開催中の「 AI・人工知能EXPO【春】 」に参加してきました。会場の雰囲気と印象に残ったセッションの学びをまとめます。 生成AIに加えて、AIエージェントやフィジカルAIまで幅広いテーマが扱われており、単に最新技術を眺めるだけでなく、「AIをどう業務に組み込むか」を考えるうえでも刺激の多いイベントでした。 前回は、2025年夏に開催された AI博覧会 Summer 2025 に参加し、その内容を社内ブログ記事としてまとめています。ぜひ、そちらも参照ください！ 前回の記事：AI博覧会 Summer 2025 に参加してきました！ AI・人工知能EXPO 会場入口の様子1 AI・人工知能EXPO 会場入口の様子2 AI・人工知能EXPOとは 開催日： 2026年4月15日（水）〜 17日（金）10:00〜17:00 会場： 東京ビッグサイト（西展示棟） 関連URL： AI・人工知能EXPO【春】公式サイト AI・人工知能EXPO【春】 は、NexTech Week 2026内で開催されている日本最大級のAI技術専門展です。今回のNexTech Week 2026では、全46講演、300社が出展しており、生成AI、AIエージェント、RAG、AIインフラ、ロボットなど、業務活用に直結する技術・サービスが幅広く集まっていました。 前回のイベントとの違い 前回参加した AI博覧会 Summer 2025 が生成AIの活用事例や社会実装によりフォーカスしていたのに対して、今回は AI エージェント、データ基盤、ロボティクスまで含む、より広い技術領域を扱っていたのが印象的でした。会場も東京ビッグサイトで3日間開催と規模が大きく、関連展示までまとめて見られる構成でした。 なぜ参加したの？ 現在、山本と藤岡は社内の AI CoE（Center of Excellence） というバーチャルチームに所属し、AIの社内活用推進や、実際の開発への導入支援を行っています。そのため、AI関連の最新情報をキャッチアップしたいという思いから、今回のイベントに参加し、社内に持ち帰れる学びやヒントを得ることを目的にしました。 ニフティで社外イベントに参加するには 今回も前回のイベント参加時と同じように ・藤岡・山本 「前回より大きい日本最大級のAIイベントがあるらしいんですが、行ってもいいですか？」 ・上司 「いいね。ぜひ知見持って帰ってきてください！」 社外イベントへの参加は、まずはこんな感じで気軽に相談すればOKが出ることが多いです。参加して得た知見を社内に持ち帰って共有する文化があるので、「行って終わり」ではなく、学びをチームや会社の成長につなげやすいのもニフティらしさだと感じています。 現地の様子 会場は東京ビッグサイトで、セミナーと展示を行き来しながら回れる構成でした。AIエージェントや生成AIに関するセッションの注目度は高く、業務効率化だけでなく、組織変革や新しい働き方までテーマが広がっているのが印象的でした。 まずはセミナーを中心に回りながら、気になるブースや関連領域の展示も見て回りました。 会場内の展示エリア入口の様子 セッション 特に印象に残ったのは、以下の2つのセッションです。 アプローチはそれぞれ違うのですが、どちらも「これまでAIとどう付き合ってきたか」「これからどう共存していくか」を改めて考えるきっかけになる内容でした。 1. フィジカルAIがもたらす産業変革 NVIDIAの荒井 謙さんは、フィジカルAIを「現実世界と相互作用し、自律的に判断・行動するAI」として整理し、ロボットや自動運転に限らず幅広い領域に広がる概念だと紹介していました。 実現には、モデル学習、実世界でのデプロイ、デジタルツイン／シミュレーションの3つの計算環境が重要で、現実データ収集のコストや危険を補うためにシミュレーションや世界基盤モデルの活用が鍵になります。 現在はまだ立ち上がり期ですが、生成AIと同様に今後急速に発展し得る領域として、監視・点検・製造・物流などへの波及も含め継続してウォッチしたいと感じました。 セッションの様子 2. なぜ企業はClaudeを選ぶのか——Anthropicの安全性という価値 Anthropic Japanの岡田 大志さんによる講演では、Claudeを「便利な生成AI」としてではなく、 企業が重要な仕事を任せられるAI として成立させるために、 安全性をどう設計し、どう検証し、運用に組み込むか が語られていました。 特に印象に残ったのは、Constitutional AI（憲法AI）やRed Teamなどで判断基準やテストを体系化している点に加えて、 安全性を優先できるように組織の仕組み自体にもガードレールを入れている 点です。たとえば、公益性を組織の目的に組み込むことや、長期的な利益を担保するための独立した仕組み（株主の意向が強く働きやすい場面でも、安全性へのコミットが揺らぎにくい構造）が紹介されていました。 AI活用バーチャルチームメンバーとして、社内展開を考えるうえでも、ツール単体の機能比較ではなく、アクセス統制・監査・データ保護・人の確認といった ガバナンス込みで設計する重要性 を改めて感じました。 セッションの様子 企業展示ブース 展示エリアには多くの企業が出展しており、生成AI、AIエージェント、データ基盤、ロボティクスなど幅広いテーマのブースが並んでいました。実際に見て回ると、単なる技術デモではなく、 教育・運用・現場導入まで含めてAIをどう業務に組み込むか を具体化した展示が多かったのが印象的でした。 展示ブース入口の様子 1. 株式会社KIZASHI 株式会社KIZASHIのブースでは、生成AIパスポート風の問題に答えながら「生成AIリテラシー診断」を体験でき、いまの理解度を手触り感をもって把握できる展示になっていました。生成AI活用普及協会（GUGA）に認定されている取り組みとのことで、学習コンテンツと診断をセットで提供している点も印象的でした。 ブースの様子 体験後にはノベルティで「生成AIパスポート」の書籍もいただけました。 そして何より、ブース内の診断を実際に受けてみたところ……なんとランキング5位にランクイン。会場でその場のノリのまま挑戦できる感じも含めて、かなり楽しかったです。 5位に入賞…！（名前は藤岡のニックネームです） 2. FlashIntel Japan株式会社 FlashIntel Japanのブースでは、CS（カスタマーサポート）業務を主戦場にした音声AIエージェントの展示が行われていました。音声モデル Chroma と FlashAI Voice Agents を軸に、営業コールや問い合わせ対応など「電話」を起点にした業務を、ナレッジベース化〜FAQ生成〜応対への反映まで一気通貫で支える構成がわかりやすかったです。 ブースの様子 特に印象に残ったのは、デモで体験できた“人に近い自然な音声”と低遅延な受け答えでした。 当社でもCSを内製で運営していることもあり、「一部でも試してみると面白そうだな」と素直に感じました。 FlashIntel Japan のデモ画面 他のEXPOも隣接して同時開催 NexTech Week 2026【春】は、AI・人工知能EXPOを含む 合計5つの展示会 で構成されています。1回の来場登録でまとめて見られるので、AI単体というより「周辺の技術・人材・実装」まで一気に俯瞰できるのが良さでした。 ブロックチェーン EXPO ：Web3、NFT、DAOなど、ブロックチェーン技術のビジネス活用を扱う展示会。 量子コンピューティング EXPO ：量子計算の研究から産業応用まで。まだ先の技術に見えつつも「触れておく価値」がある領域。 AI時代の人材・組織改革 EXPO ：旧「デジタル人材育成支援EXPO」。リスキリングや人材開発、組織づくりなど、導入を支える“人と仕組み”側の展示。 ヒューマノイドロボット EXPO ：人と共に働く次世代ロボットの実装・活用にフォーカスした新設EXPO。 ヒューマノイドロボット EXPOの様子1 ヒューマノイドロボット EXPOの様子2 今回のイベント参加で学んだこと 今回のイベントで特に印象的だったのは、フィジカルAIが想像以上に実用段階へ進んでいたことです。これまではXなどで見かける「まだ使えないロボット」の印象を持っていましたが、実際には着実に技術が前進しており、世界基盤モデルのような考え方も含めて、今後さらに広がっていきそうだと感じました。また、AI活用は特定の業界に閉じた話ではなく、さまざまな分野へ発展しており、業種が違っていても参考にできるアプローチが多くありました。現場ごとの多様なニーズに応える製品も多く、AIがより具体的な業務課題の解決に近づいていることを実感しました。 反省点 ブースがかなり多いので、あらかじめ自分たちが興味のある分野を絞っておくことで、当日落ち着いて回ることができると感じた フィジカルAIが世間的に注目されているのは知っていたが、事前知識不足により内容が難しく感じた こんなところにあのキャラクターが,,,! まとめ AI・人工知能EXPO【春】 は、最新技術を眺める場であると同時に、 これからの仕事の進め方をどう変えていくか を考える場でもありました。今回の参加を通じて強く感じたのは、AI活用の価値は新しい技術そのものよりも、それを現場の業務や組織の流れの中でどう定着させるかにあるということです。セッションや展示で得た気づきを、単なるイベント参加の思い出で終わらせず、今後の業務や社内でのAI活用推進にどうつなげていくかが大切だと改めて感じました。 ニフティのAI活用について ニフティでは、所属部署や職種を越えて有志が集まるAI活用のバーチャルチームが活動しています。日々の開発や業務改善の延長線上でAIを活用し、技術トレンドを「見て終わり」にせず、実際の業務にどう生かすかまで試せる土壌があります。だからこそ、AIに興味がある方、業務の中で新しい活用を試してみたい方、技術を使って働き方を変えていきたい方は、ぜひ一緒に挑戦しましょう！実際に手を動かしながら社内のAI活用を前に進めていける仲間を募集しています。 AI活用バーチャルチームについては、こちらのインタビュー記事でも紹介されています。 AI活用バーチャル チーム のインタビュー記事
ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。 今回はその一つである、「AI活用推進チーム」にスポットを当てます。ニフティ社内の様々な部署の課題に対し、AIツールを使って解決に導くことなどを目的とした活動。メンバー4人に、活動に参加することになったきっかけや、普段の活動内容、やりがいなどについて聞きました。 自己紹介 小林 雅幸 さん 2022年4月に新卒入社。普段の業務内容は@nifty光や@nifty with ドコモ光などの接続サービスの開発・運用。趣味は配信者のイベントやライブ参加、スノボ。雪に埋まりたい。 藤岡 渓人 さん 2024年4月に新卒入社。普段の業務内容はSSOシステム、無料会員サインアップシステム、コンテンツ販売システムの保守・運用。趣味は筋トレ、ゲーム、サウナ巡りというよりお風呂が好きです。 山本 勇樹 さん 2024年4月に新卒入社。普段の業務内容は@nifty光や@nifty with ドコモ光などの接続サービスの開発・運用。趣味は筆記具収集、革細工、AI関連（ニュース漁り&お試し）。 中井 大介 さん 2023年4月に新卒入社。普段の業務内容はSSOシステム、無料会員サインアップシステム、コンテンツ販売システムの保守・運用。趣味はプログラミング。最近はファミコンエミュレータを作ろうとしています。 所属部署も、AIに関する知識量も異なる4人が集まり活動 みなさんはそれぞれの所属部署での業務とは別に、チーム外活動として「AI活用推進チーム（以下、AIチーム）」にも参加されているとお聞きしました。はじめに、所属部署とAIチームでの役割を教えてください。 小林さん 所属部署では「@nifty光」や「@nifty with ドコモ光」といった接続サービスの開発と運用を行っています。ニフティにはAIの活用を推進するチーム外活動が複数あり、我々もその一つ。私は一応リーダー的な立場で、別グループとの情報共有やミーティングの調整、活動報告、あとはアカウントの管理といった、メンバーが動きやすくなるための色々な雑務もやっています。 中井さん 所属部署ではSSOシステム、無料会員サインアップシステム、コンテンツ販売システムの保守・運用を担当しています。AIチームでは、わりと自由にAIシステムやツールを作らせてもらっています。 藤岡さん 私も中井さんと同じ部署に所属しています。AIチームでは特に明確な役割はありませんが、主には社内からAI活用に関する相談を受けた時に調査をしたり、チーム内で議論をしたうえで改善提案をしたり、といった活動が多いですね。 山本さん 私は小林さんと同じ部署に所属し、業務内容もほぼ同じです。AIチームでの役割については決まったものはありませんが、個人的にキャッチアップしたAI関連の最新ニュースやトレンド、技術をメンバーに共有したり。他にも色々とやっています。 みなさん、入社前からAIに対する知見や興味はあったのでしょうか？ 小林さん 大学では機械学習を用いて異常を検知する研究を行っていましたが、本格的に業務で使えるAIに携わり始めたのはAIチームに入ってからですね。 中井さん 私は大学時代からプログラミングが好きで、自分で自動化ツールを作ったりしていました。AIが好きというよりは、自分がやりたいこと、自動化したいことをやる手段として捉えていました。 山本さん 大学時代に画像認識技術とIoTを組み合わせて、メダカの病気を自動判別し、さらには改善をするシステムを開発しました。それがAIとの最初の接点でしたね。 藤岡さん 私は3人と違って、学生時代はAIに触ったこともなければ興味もありませんでした。同級生は就活のエントリーシートのたたきを生成AIに書かせていましたが、私は「自分の言葉で書きたいから」と頑なに使わず。ですから、AIチームに入るまで何も知らない、使った経験すらないという状態でしたね。 チーム外活動をきっかけに、ご自身のAIに対する認識も変わりましたか？ 藤岡さん 変わりましたね。最初は「ChatGPTとOpenAIって何が違うんですか？」という頓珍漢な質問をしてしまうレベルでしたが、メンバーや他グループの方々から教わるうちに理解が深まり、正しく使えば非常に便利なものなんだなと。今は仕事以外でも、普段からAIを活用しています。 社内各部署の課題を、AIシステムによって解決する では、みなさんのAIチームがどんな目的で、どのような活動をしているのか教えてください。 小林さん 社内には大きく分けて3つのAIチームがあります。 まず「基盤レベル」。これはニフティの全社員が基本的なAIツール、たとえばGeminiやコーディング支援ツールなどを活用できる体制を作ることを目的とした活動です。会社が契約しているAIツールを、エンジニアだけでなく営業などのビジネス側にも使ってもらえるような状態を目指すというものですね。 次に「専門レベル」。こちらは職種ごと、チームごとのニーズに特化したAIエージェントの開発を目的としています。たとえばチームの業務を効率化したい、サービスの運用を改善したいなど、一部の限られたニーズに対してAIを活用していくというものです。 そして「事業価値創造レベル」。AIを事業フローに組み込んで、新しい活用を創造する。AIを使った新サービスを作るなど、会社に直接的な利益をもたらすことを目的に活動するチームです。 そのなかで、我々のチームは「専門レベル」を担っています。 なるほど。専門レベルチームは、どんな経緯で立ち上げられたのでしょうか？ 小林さん もともとは、私自身が所属する部署で、チーム内の業務効率化やサービス運用の改善のためにAIシステムを作り始めたのがきっかけなのですが、そのうち他部署からも似たような相談を受けるようになりました。「画像内の文字をテキストデータ化したい」「このAIツールを使っても大丈夫？」など。 そこで、そうした相談やエンジニア・ビジネスの様々な課題に対して、AIを活用した提案を行うチーム外活動としてスタートしました。今はSlack上に全社から相談を受け付ける窓口を設けて、各職種・チームに特化したAIシステムの開発、活用を目指しています。 中井さん 現在はその他にも、活動内容が広がっています。たとえば、AWSのサービスでAIを使えるのですが、コーディング支援や、AIシステムを作る時の検証環境を目的としてツールを使いたい希望者がいれば、期間を決めてアカウントを貸し出したり。あとは、私たち自身が普段の業務で解決したい課題に対して、AIシステムを開発するという活動も並行して行っています。 最初はAIの知識ゼロ。1年で急成長し、今では大きな戦力に 小林さん、中井さんはチーム立ち上げ当初からのメンバーということですが、山本さんと藤岡さんがこのAIチームに参加することになったきっかけを教えてください。 山本さん 私は学生時代からAIに関心を持っていたこともあって、入社後のOJTの最後の振り返りの場で、「自分はAIをどんどん活用して、社内にも広めていきたいです」という意気込みを語りました。その場に小林さんもいらっしゃったのですが、私が宣言した5秒後にはAIチームのSlack チャンネルに招待されていました（笑）。 小林さん スカウトのチャンスだと思って（笑）。 対照的に、藤岡さんはもともとAIにさほど関心がなかったということでしたが、なぜ参加しようと？ 藤岡さん まずニフティに入社してから、想像していた以上に業務で普通にAIを使っている人がいるんだなと感じました。あと、同じ部署の中井さんがAIチームに入っていて、話を聞いてみたところ面白そうだなと。それで興味が湧いて、中井さんを通じて小林さんに参加したいですと伝えました。 ただ、その当時は社内向けの相談窓口もなく、みんながやっていることを横目で見ながら、僕がちょこちょこ質問するみたいな感じでした。毎週そんなことをやっていたら、3人が話していることが徐々に理解できるようになってきて、チームに寄せられた相談に対する僕なりの対応策も、何となく提案できるくらいのレベルにまでは進歩したと思います。 AIを使って課題を解決すること自体が、徐々に楽しくなってきたりも？ 藤岡さん それはありますね。以前の自分からは考えられませんが、本当に楽しくて。たとえば、今は山本くんと二人で、セキュリティチーム向けのAIシステムを作っています。セキュリティチームって社内の色々な部署から、日々たくさんの問い合わせを受けるんです。それをAIに回答させるシステムを作れないかと同期から相談されて、やってみようと。AIチームに入った時から、何かしら形になるものを作って会社に貢献したい思いがあったので、これはチャンスだと思いました。毎週、業務外である程度の時間を作って活動に充て、今まさに開発中です。 いいですね。普段の業務とはまた別のモチベーションがあると。ちなみに、中井さんにお伺いしたいのですが、もともと藤岡さんはAIに関する知見やスキルを持っていなかった、言葉を選ばずに言うと「即戦力」になるメンバーではなかったのかなと思います。それでもチームに迎えたいと思った理由は何でしたか？ 中井さん 基本的に、色んな視点や考えを持った人に入ってほしいという考えがあります。一人が取得できる情報には限りがありますし、そもそも所属部署もバラバラなので、AIで解決したい課題も異なるんですよね。バッググランドが異なるメンバーがいてくれたほうが、チームに新しい知見を取り入れていくことができるのではないかということで、藤岡くんにもぜひ入ってほしいと。色んな人がいたほうが、単純に楽しいというのもありますしね。 今も人を選んでいる、メンバー数を絞っているということは全くなくて、興味があればどんどん参加してほしいと思っています。知識は入ってから身につけてもらえばいい。実際、藤岡くんも学ぶことが好きで、すぐに知識を吸収してチームを助けてくれましたから。 知識量やAIを触った経験に差があっても、それぞれができることでチームに貢献すればいいと。 中井さん そうですね。それこそ山本くんの場合は、AI関連の情報収集能力が本当にすごくて、僕らが全く知らない情報をどんどん共有してくれます。新しいAIシステムを作る時も、「このサービスを使えばできますよ」という言葉が、スッと出てくる。こちらとしても山本くんに負けていられないという思いもあり、彼に普段どんな方法で情報を集めているのか聞いて、キャッチアップに努めていますね。彼の存在が、私を含めメンバーのモチベーションアップにもつながっています。 と言われていますが、いかがですか？ 山本さん 山本さん 面と向かって言われると恥ずかしいですね。でも、ありがたいです。情報収集に関しては毎日の通勤中にもやっていますし、そこで気になったツールなどがあれば休日に自分で個人的に使ってみたり。ゲームや新しいアプリを試すような感覚で、色々遊んでいます。それをチームに共有しているだけなんです。 じつはニフティに入った時点では、そこまでAIを会社に広めたいという思いはありませんでした。ただ、OJTで色々な部署の色々な人と話すなかで、まだあまりAIが浸透していない、うまく活用できていないと感じて。トレーナーの方に、何気なく「このツール、面白いですよ」と言ってみたら、すごく喜んでいただけたんです。それが嬉しくて、もっとAIを社内で活用できる土壌を作っていきたいという思いが湧き上がってきましたね。 後編に続きます！ 後編では、「所属部署の業務とチーム外活動の両立」について、「4人が印象に残っているAIチームでのプロジェクト」について、「今後チャレンジしてみたいことについて」などを語ってもらいます。 今回はニフティのAI活用推進チームのインタビューの様子をお届けしました。続きは近日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報
お疲れ様です、エンジニアリングマネージャーの芦川です。 最近私の身に起きた「 奇跡のような時間 」 のお話をさせてください。 実は、有志のメンバー数名で 「 プロダクトマネージャーのしごと 」 という本の輪読会をやっていました。数ヶ月にわたる全16章の旅をようやく終えたのですが、これがもう、私のこれまでの社会人生活の中でも類を見ないほど、最高に濃密な時間でした。 何がそんなに凄かったのか。 一言で言うと、 「 斜めのつながり 」が起こした化学反応 です。 同じチームの人はほぼいない。上司・部下の関係もほぼない。 部署も年次も役割もバラバラなメンバーが、いわば「斜めの線」でつながって集まった、非公式な秘密の場所。そこで起きたことを、自分たちのふりかえり（KPT）の結果を交えながら、生々しく記録しておこうと思います。 きっかけは、忘年会の「ちょっとした立ち話」 そもそも、なぜこの会が始まったのか。 きっかけは、私自身のちょっとした「悩み」でした。 マネージャー同士で仕事をしていると、「もっと目線を合わせる必要があるな」と感じる場面が多々あります。だったら、何かひとつ同じ本でも一緒に読んでみて、共通言語を作ってみたらどうだろう？と考えました。 ちょうど私自身がプロダクトマネジメントを学習したいと思っていたタイミングで、「これをビジネス側のマネージャーと一緒に読んでみたいな」と思い立ちました。 そんな話を忘年会の席などで周囲にポロッとしてみたところ、 「あ、それなら私もやりたい」「自分も興味あります」 という声が予想以上に上がり、気づけば部署も役職も飛び越えた、今の面白いメンバーが集まっていました。 そもそも、何をやっていたのか？ 読んだ本は、オライリー・ジャパンの 「 プロダクトマネージャーのしごと 第2版 」 です。 プロダクトマネジメントの本質は「ビジネスと顧客の間の価値交換の管理人」であること。中身はスキルや手法もありましたが、それ以上に「どういう姿勢で人と向き合うか」という、ものすごく人間くさいことが書かれている本でした。 これを、毎週1章ずつ各自が非同期で読み進めてオフラインの場で感想をぶつけ合う。 ただそれだけのことなのですが、回を重ねるごとに、私たちの会話は本の内容を超えて、自分たちの「キャリア」や「組織のリアルな悩み」へと深く潜り込んでいきました。 輪読会を「ふりかえり」してみた 全章を終えた後、私たちはいつものようにKPT形式でこの会をふりかえりました。 そこに出た言葉が、この会の熱量を何よりも物語っています。 【KEEP】この会が最高だった理由 まず、全員が口を揃えて言ったのが 圧倒的な心理的安全性の高さ です。 「意見に対して否定されることがないので、心理的安定があった」（企画 管理職 井田さん） 「自分にはない視野を聞けた。キャリア相談もできて、自分が見えていたこともあった気がした」（企画 メンバー 安孫子さん） 業務上の利害関係がない「斜めの関係」だからこそ、普段の会議では絶対に言えないような「実はあそこ、失敗だと思ってます」とか「今のキャリアに悩んでるんです」という本音がポロポロと出てくる。 否定されない、マウントを取られない。そんな「聖域」のような場所になっていました。 次に、多角的な視点。 「自分とは違う立場の人から、違う意見を聞けて気づきやヒントをもらえた。納得感や共感がさらに生まれた」（企画 管理職 矢野さん） 矢野さんが言うように、エンジニアの視点、企画の視点、ビジネス側の視点。それぞれの「正義」や「制約」を知ることで、「あ、あの部署があの時あんな動きをしていたのは、こういう背景があったのか！」と、パズルが解けるような納得感が何度も訪れました。 吉田さんも、この多様性を評価してくれました。 「役職・部署・年次の異なるメンバーが集まったこと」（企画 プロダクトオーナー 吉田さん） この「バラバラさ」こそが、議論を立体的にしてくれた最大の要因でした。 泥臭く、人間臭かった「感想戦」のエピソード KPTのデータだけじゃ伝わらない、実際のやり取りの中で私の心に深く刺さったシーンを紹介させてください。 企画 管理職 井田さんの「型」への深い洞察 井田さんは、いつも一歩引いたところから、本質をズバッと突いてくれました。アジャイルやフレームワークの話になったとき、井田さんがボソッと言ったこの言葉が忘れられません。 「サッカーも茶道もアジャイルも一緒だな。ごく当たり前なことなんだけど、とっかかりとしてなにか型を用意したに過ぎないんだな！」 手法（アジャイル）を「目的」にするんじゃなくて、より良い仕事をするための「型」として捉える。この 井田語録 は、ツールに溺れそうになる私たちの目を何度も覚ましてくれました。 企画 管理職 矢野さんの「他部署へのリスペクト」 現場の最前線で戦ってきた矢野さんは、誰よりも「相手への想像力」の大切さを語ってくれました。 「開発の制約があることを想像しながらも、無視して『早く成果を出せ』と振る舞ってきたことがあった。反省。お互いの制約を理解しないと議論は噛み合わないし、そこを埋めるのが会社の成長に直結するんだ」 ベテランの矢野さんが、若手の前で「反省です」とさらっと言える。この潔さと素直さが、この会の空気をどれだけ温かくしてくれたか計り知れません。 企画 メンバー 安孫子さんが見つけた「自分の居場所」 安孫子さんにとって、この会は単なる勉強会以上の場所になっていたようです。 「年上の人とも、本という共通のツールがあることで対等に話を進めることができた。自分のこれからのキャリアについても相談ができて、自分だから見えていたこともあるんだと自信が持てたのが本当に良かった」 上司ではないけれど、経験豊富な先輩たち。そんな「斜めの先輩」にキャリアの悩みを打ち明け、認められた経験。彼女がこの会を通じて少しずつ自信をつけていく様子を見ていて、私も本当に嬉しくなりました。 企画 プロダクトオーナー 吉田さんの「対話への意志」 吉田さんは、本の中の抽象的な言葉を、いつも私たちの現場の課題に接続してくれました。 「『心地悪さは明確さの欠如の兆候』というフレーズが刺さった。放置すると将来の感情的対立や大きな障害になるから、恐れずに表面化させて、その都度対話することが必要なんだ」 「なんとなく気まずいから言わない」を卒業して、良いプロダクトのために「心地悪い会話」をする勇気。吉田さんの鋭い指摘は、いつも私たちに背筋を伸ばさせてくれました。 企画 メンバー 岡田さんが見つけた「改善の第一歩」 岡田さんは、日々の多忙な業務の中でも、いかにチームを良くしていくかを真摯に考えていました。 「大きなタスクはできるだけ分割して方向性を微調整できるようにする。また、お客様と同じ手順でサービスに触れることで、自分たちが本当に取り組むべき優先順位が見えてくる」 理想論だけで終わらせず、具体的にどう動くか。その一歩を自分なりに定義する岡田さんの姿勢は、メンバーにとっても大きな刺激になりました。 奇跡の時間の正体：なぜ「開発MTG」が楽しくなったのか？ ふりかえりのメモの中に、こんな一節がありました。 「読んだ自分の中で変化があったこと。開発とのMTGがたのしくなった。人の理解がちょっとできた」 これ、私も全く同じなんです。なぜ、たかが読書会でMTGが楽しくなるのか。 それは、この会を通じて 相手の背景にある制約や意図に好奇心を持つ訓練 ができたからです。 これまでは「なんで開発はこんなに時間がかかるんだ？」と不満に思っていたことが、「ああ、彼らには彼らの技術的な制約や、守るべき品質があるんだな」と想像できるようになった。 相手を「説得すべき対象」ではなく「共に航海するパートナー」として見られるようになった。 私はエンジニアですが、逆に企画の方に対してもこう強く思うようになりました。 これは、スキル以前の「人間としてのスタンス」の変化なのだと思います。 結びに：この集まりに名前をつけるなら 最後の感想戦で、私たちはこの集まりをこう呼びました。 上下左右輪読 奇跡の時間 役職（上下）、部署（左右）を超えて、斜めに繋がったメンバー。 秘密のDMグループという「非公式な場」で、誰にも否定されずに自分の経験を語り、仲間のキャリアを応援し、共に学習する。 これって、効率化ばかり求められる今の組織の中で、一見すると「無駄な時間」に見えるかもしれません。でも、本の中にあったように 「 無関心は反対よりももっと危険 」 です。 この輪読会に集まったのは、無関心ではいられなかった、熱い想いを持った「当事者」たちでした。 もし、皆さんの周りに閉塞感があるなら、ぜひ部署をまたいだ「斜めのつながり」を作ってみてください。一冊の本をダシにして、本音で語り合ってみてください。 そこには、どんなベストプラクティスよりも価値のある、 働くことをちょっと豊かにしてくれる奇跡 が待っているはずです。 一緒に走ってくれた井田さん、矢野さん、吉田さん、安孫子さん、岡田さん。 皆さんと過ごした時間は、マジで財産です。 「 未完成なものを素晴らしいものにするには、あなたの助けが必要です 」 本の中にあったこの言葉通り、皆さんの助けがあったからこそ、この輪読会は最高の「プロダクト」になりました。 本当に、ありがとうございました！ また次の「奇跡」を、みんなで探しに行きましょう。
こんにちは。ニフティ株式会社の statiolake です。 最近プロダクトに Go を採用したこともあって、なんだかチーム内で Go に対する関心が高まっています。最近 Go 1.26 がリリースされたということで、チームで新機能を眺める会をしていました。 さて、今回のリリースにはいくつかのコア言語機能の変更が含まれているのですが、その中の一つに「ジェネリック型がその型パラメータリスト中で自分自身を参照できるようになった」という変更があります。 一見すると型としての表現力上がったように思える追加機能です。がしかし、考えれば考えるほど「本当にこれが必要な場面ってある？」「公式の例、自己参照なしでも同じことできそうじゃない？」という議論になりました。 そこでもう少し詳しく調べてみたところ、なかなか面白い内容だと感じたので記事にしてみます。 忙しい人向け 以下が、今のところの私の理解です。 Go 1.26 から、ジェネリック型の定義の中で自分自身を参照できるようになった ただし 公式リリースノートの Adder の例 は自己参照なし (単なる A any ) でも問題にならない 実際に自己参照が必要になるのは、 ジェネリックなインターフェースとカスタム型が相互に参照し合う 場合 それも型システムとして本質的に必要だったというよりは、Go のメソッドの制約をインターフェース側で回避するための workaround として機能する …ただ、あらかじめ逃げ道を作っておくのですが、私は Go や型理論のことをよく知っているわけではないので、完全に正しく理解できている自信はありません。 定義の中で自分自身を参照するとは まず、新機能を確認しましょう。 Go 1.26 のリリースノート には次のような例があります。 type Adder[A Adder[A]] interface { Add(A) A } func algo[A Adder[A]](x, y A) A { return x.Add(y) } ここで重要なのは type Adder[A Adder[A]] interface { ... } という部分です。 Adder というインターフェースの定義がまだ完了していない段階で、その型パラメータの制約として Adder 自身が登場しています。Go 1.25 以前では、このようにインターフェースの定義途中で自分自身を型パラメータの制約に使うことはコンパイルエラーになっていました。これが 1.26 で解禁された、というのが今回の変更です。 もやもや: 公式の Adder 例、自己参照なしでも書けないか？ 正直に言います。最初に見たとき、「インターフェース側は A any にして、使う側で制約をかければ済むのでは？」と思いました。 type Adder[A any] interface { Add(A) A } func algo[A Adder[A]](x, y A) A { return x.Add(y) } 試してみると、これで普通に動きます。Go 1.25 でもバッチリです。 ではどういうときに本当に必要になるのでしょうか？ 必要なのはどういうときか？ それなりに考えましたが、自力では思いつけなかったため、調べました。するとそもそも実装されるきっかけになったと思しき Go の issue #68162 が見つかり、ここに答えがありました。 結論だけ簡単にお伝えすると、まず 型の定義側に型制約を書かざるを得ないケース が存在して、さらにその型制約が 相互再帰的に自分自身に返ってくる場合 に必要になるということでした。難しい。 まず、型の定義側に型制約を書かざるを得ないケースとはどういうことでしょうか？ 通常 Go のメソッドはジェネリックになることができませんが、型変数を一切扱えないとなると、ジェネリックな構造体に対してメソッドを実装できないということになってしまい、困ります。そのためレシーバだけはジェネリックになれるようです。しかし、関数と違って その場で型制約を表現することができません 。そのため、メソッド内でレシーバのジェネリクスに対して何らかの要求をしたい場合には、構造体の定義時点でその制約を課しておく必要があるということでした。 1 次に、その型制約が相互再帰的に自分自身に返ってくるとはどういう時でしょうか？ こちらについては、次の節から具体例で見ていきたいと思います。 必要なセットアップ まず、「比較可能な要素 ( Element ) のペア」を表す ElementPair という構造体を考えてみましょう。 type Element[E any] interface { Less(other E) bool } type ElementPair[E Element[E]] struct { First E Second E } func (ep ElementPair[E]) FirstIsSmaller() bool { return ep.First.Less(ep.Second) } ここで、 FirstIsSmaller() の中で ep.First.Less(...) を呼んでいます。すると E は Element である必要があります。ところが FirstIsSmaller がメソッドであるため、レシーバーである ElementPair[E] の E に対して E Element[E] という制約を 直接課すことはできません 。 ここでさきほどの議論の 1 つ目の前提が満たされ、 ElementPair には型定義の時点で E Element[E] という制約がつくことになりました。 ただし、ここまでは新機能の出番はありません。 相互再帰をすると問題が起きる 問題が起きるのは、 Element のメソッドが ElementPair を返したい場合です。 type Element[E Element[E]] interface { Less(other E) bool Zip(other E) ElementPair[E] // ← ここが相互参照のポイント } type ElementPair[E Element[E]] struct { First E Second E } func (ep ElementPair[E]) FirstIsSmaller() bool { return ep.First.Less(ep.Second) } Zip の戻り値として ElementPair[E] を書くためには、 ElementPair の型パラメータ制約である E Element[E] を満たす必要があります。そのため Element のインターフェース定義の時点で E が Element[E] を満たしていなければならない。 ここでさきほどの前提の 2 つ目が満たされます。結果、 type Element[E Element[E]] という自己参照制約が現れてしまいました。これが Go 1.26 で初めて書けるようになったものです。 相互参照の流れを整理するとこうなります。 ElementPair[E] は E Element[E] を要求する Element の中で ElementPair[E] を参照したい → E Element[E] が要求される type Element[E Element[E]] という自己参照が発生する 関数なら不要 ちなみに、メソッドではなく関数として書くのであれば、Go 1.25 でも問題ありませんでした。その場で制約が書けないのはメソッドに特有の制限だからです。 // インターフェースは E any にする type Element[E any] interface { Less(other E) bool Zip(other E) ElementPair[E] } // ElementPair も E any にする type ElementPair[E any] struct { First E Second E } // 関数なら利用側で制約を解決できる func FirstIsSmaller[E Element[E]](ep ElementPair[E]) bool { return ep.First.Less(ep.Second) } 制約の解決は関数の型パラメータ [E Element[E]] で行えるため、双方 any でよく、相互参照の問題が起きないのです。 まとめ Go 1.26 から、ジェネリック型の定義の中で自分自身を参照できるようになった ただし 公式リリースノートの Adder の例 は自己参照なし (単なる A any ) でも問題にならない 実際に自己参照が必要になるのは、 ジェネリックなインターフェースとカスタム型が相互に参照し合う 場合 それも型システムとして本質的に必要だったというよりは、Go のメソッドの制約をインターフェース側で回避するための workaround として機能する 普通のアプリケーションコードを書く分には出会わないまま過ごすかもしれませんが、Go のジェネリクスの仕様を深く理解する上では面白い題材でした。 まだまだわからないことが多いので、引き続き勉強していこうと思います。 なお、その制限が文法上の問題なのか言語の複雑性を増やさないための選択なのかは調べきれませんでした。公式 FAQ の こちら を見る分には文法上の制約っぽい説明がなされていますが、それだけかはわかりません。 ︎
はじめに はじめまして！カスタマーサポートグループサポートシステムチームの植田です。 プライベートでは、「旅行」「運動」「カラオケ」「勉強」、以外のことが好きです（インドア派です）。 お客様が自身の契約情報を確認する会員サポートページやカスタマーセンターのオペレータが使用する社内ツールの開発や運用を行っています。 直近ではカスタマーセンターのオペレータが使う社内ツールのAzureへのクラウド移行を担当しました。 これまでの経歴と転職のきっかけ 前職はCG業界で、CGプログラマーという仕事をしていました。 ただ、実際にCGを描いたり、ゴリゴリとプログラミングを書いたりする機会もなく、「自分のスキルを今後どう育てていけばいいのか……」とキャリアについて深く悩むようになっていました。 書けるのはpython,学部時代にちょろっとだけ触ったjava程度… そんな中でニフティの選考を受け、入社を決めた一番の理由は、「しっかりとした開発経験がない私でも、成長し活躍できるチャンスが十分にある」と感じたからです。 入社して感じたこと ギャップ：想像以上に「成長に貪欲」なカルチャー 入社前は、歴史ある企業ということもあり「保守的な雰囲気なのかな？」と勝手なイメージを抱いていました。しかし、実際に入社して良い意味で裏切られました。出会う人みんなが新しい技術や改善に対して前向きで、成長に貪欲なカルチャーが根付いています。 チームの雰囲気：温かく、熱量のあるコミュニケーション まったくの未経験に近い状態で入社した私に対しても、チームの皆さんは段階的に取り組めるタスクを用意してくださり、非常に温かく迎え入れてくれました。 一方で、会議になると次々と活発な意見が飛び交い、熱量に溢れています（自分も早く参加しなければ！）。 技術と業務：毎日が「はじめまして」の連続 前職では一人でPythonを書いていただけでした。しかし現在担当している、社内サービスの Azure へのクラウド移行では、 インフラ・環境構築: Terraform、Azure、Docker バックエンド・フロントエンド: Bash、SQLite、HTML / Jinja 開発プロセス: ペアプログラミング、コードレビュー などなど、はじめましての技術やプロセスが山のようにありました。覚えることは膨大で大変な部分もありますが、その分だけ「自分ができるようになっている」という成長実感も非常に大きいです。 今後の目標 短期的な目標 まずは、日々の業務でのさまざまな失敗や経験を通じて、エンジニアとしてのキャパシティを広げていきたいです。そのプロセスの中で、「自分はどんな作業が得意なのか」「どういう領域が好きなのか」といった、自分のエンジニアとしての特色を理解していきたいと考えています。 中・長期的な目標 ニフティには、多様な技術スタックを持つスペシャリストがたくさん在籍しており、その知見をオープンに共有し合う文化や習慣がしっかりと根付いています。 皆さんの知見を吸収して追いつけるよう努力しつつ、将来的には自分ならではの得意分野や役割を見つけ、「この分野なら任せて」と言えるような、発信する立場のエンジニアになりたいと思っています。 最後に 中途で入社すると、初めて触る技術やプロセスはもちろん、システム特有の業務知識、いわゆるドメイン知識（この言葉も入社してから知りました）など、キャッチアップすべきことが多くて不安になる場面もあると思います。 もちろんチームメンバーに相談することも大切ですし、頼りになるメンバーがニフティにはたくさんいます。ただ、ニフティには社内のナレッジが Notion にしっかりとまとまっており、さらに各種AIツールも積極的に活用できる環境が整っているため、「意外と何とかなる」環境だと感じています。 まだまだ未熟な私ですが、これからエンジニアとしてどんどん成長していきたいと思っています。「未経験のことが多くても挑戦してみたい！」「これからエンジニアとして本気で頑張っていきたい！」という方には、ニフティはとてもおすすめできる環境です。 最後まで読んでいただき、ありがとうございました。 皆さんと一緒に働ける日を楽しみにしています！
はじめに こんにちは。この記事はニフティの坂野とmoriです。この記事は共同執筆したものになります。 チームで開発をしていると、python,node.js等の実行環境やlinter,formatter等周辺ツールのバージョンを揃えたい、という場面は多いと思います。 そこでまず思いつくのがdevcontainerですが、ケースバイケースでオーバーエンジニアリングになりがちだと思っています。 やりたいのは「ツールのバージョンを揃える」だけなのに、コンテナ丸ごと用意するのは重すぎます。 Dockerfileやdevcontainer.jsonの構築・メンテナンスコストがかかる CI/CDで同じツールバージョンを使いたいとなると、GitHub Actions側でもコンテナビルドが必要になってさらに複雑化 ツール追加のたびにビルドし直し これらの問題は、 mise を使えばもっとシンプルに解決できます。 miseの強み mise はツールチェイン管理、環境変数管理、タスクランナーなど様々な機能を持つツールです。 以前はRTXという検索性の悪い名前でしたが、いつの間にか改名されていました。 mise.tomlというファイル1つで全部管理できます。 ローカル/CIで同じバージョン mise.tomlをリポジトリにコミットしておけば、ローカルでもGitHub Actionsでも同じツールバージョンが使えます。 CI側では jdx/mise-action を使うだけです。コンテナビルドは要りません。 TerraformのCIは例えばこんな感じで書けます。 # terraform-ci.yml steps: - uses: actions/checkout@v4 - uses: jdx/mise-action@v2 with: working_directory: terraform - run: mise check working-directory: terraform mise.tomlにツールもタスクも定義してあるので、CI側はmiseを入れて mise check するだけです。 devcontainerだとCI用のDockerfileを別途用意したり、コンテナレジストリの管理も必要になりますが、miseならtomlファイル1つで完結します。 コンテナ不要で構築コストが低い devcontainerは初回ビルドも再ビルドも待ち時間が発生します。 miseは mise install で必要なツールを直接インストールするだけなので、オーバーヘッドが小さいです。 新メンバーが入ってきたときも mise install だけで環境が揃うので、オンボーディングコストも低くなります。 ここからは、miseの各機能を紹介したあと、実際に弊社でどのように活用しているかを説明します。 Renovateでバージョンアップも自動化 Renovateはリポジトリ内の依存関係を自動検知し、バージョンアップのPRを自動で作成してくれるツールです。miseのmise managerにも対応しており、mise.toml内のツールバージョンを自動で検知してPRを作ってくれます。 前述の通り、mise.tomlはローカルとCIの両方で参照されるファイルです。つまり、Renovateがmise.tomlのバージョンを更新するだけで、ローカル環境とCIのツールバージョンが同時に更新されます。 弊社ではTerraformだけインフラへの影響が大きいので個別PRにし、それ以外のツール（tflint, trivy, gh cli等）はまとめて更新する設定にしています。 devcontainerだとDockerfile内のバージョン書き換え→イメージリビルドというフローが必要ですが、miseならtomlのバージョン文字列を書き換えるだけです。シンプルです。 miseの主な機能について ツール管理 様々なバックエンドに対応しており、一通りのツールがバージョン指定付きでインストールできます。 asdf aqua pipx npm cargo # npmバックエンドを使用した claude codeのインストール mise use -g npm:@anthropic-ai/claude-code # pipxバックエンドを使用した serenaのインストール mise use pipx:git+https://github.com/oraios/serena.git@v0.1.4 # 直接手に入る系（nvim, btop, uvなどもあります） mise use uv # ツールのアップデート mise upgrade ディレクトリごとのバージョン切り替え シェルの設定 をすると、ディレクトリごとにツールバージョンを切り替えられます。上位ディレクトリの設定は下位にも引き継がれます。 ~/hoge ❯ cat mise.toml [tools] uv = "latest" ~/hoge/fuga ❯ cat mise.toml [tools] uv = "0.8.1" ~/hoge/fuga ❯ uv --version uv 0.8.1 # fuga配下では0.8.1が使われる ~/hoge/piyo ❯ uv --version uv 0.8.23 # piyoではuv未定義だが、親のhogeの設定が効く 環境変数管理 ツール使用時やタスク実行時に使用される環境変数をmise.tomlに記述しておけます。 ディレクトリ下にいると通常のシェルでも呼び出せます。 [env] EDITOR = "code" mise.file = ".env" [tasks.hoge] env = { fuga = "piyo" } run = "echo $fuga" .envを読み込むこともできるので、認証情報などはそちらに分離するのがおすすめです。 タスクランナー mise.tomlに記述したタスクを mise run hoge で呼び出せます。 タスクを指定せず mise run するとTUIで選択できます。絞り込みも可能です。 ツールと同じく、上位ディレクトリのタスクも継承されます。 一例として、私が管理しているのTerraformリポジトリでは、fmt/lint/securityのチェックを全てmiseタスクで管理しています。 dir で実行ディレクトリを指定できます。DockerfileのWORKDIRと概ね同じです。 # terraform/mise.toml [tasks."fmt:check"] description = "Check Terraform formatting" dir = "cwd" run = "terraform fmt -check -recursive ." [tasks."lint:init"] description = "Initialize tflint plugins" dir = "cwd" run = "tflint --init --config=$MISE_PROJECT_ROOT/.tflint.hcl" [tasks."lint:check"] description = "Run tflint" dir = "cwd" depends = ["lint:init"] run = "tflint --recursive --config=$MISE_PROJECT_ROOT/.tflint.hcl" [tasks."security:check"] description = "Run trivy security scan" dir = "cwd" run = "trivy config --config=$MISE_PROJECT_ROOT/trivy.yaml ." おわりに 今回はmiseを使った開発環境のツール管理について紹介しました。参考になれば幸いです。