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を使った開発環境のツール管理について紹介しました。参考になれば幸いです。

1. はじめに 弊社では入社一年目のエンジニアは全三期のOJTを通して部署を渡り歩き、業務や会社について知見を深めていくという制度があります。 OJTについての詳細は、私の同期が入社一年目の経験を基に記事を書いていますので、是非こちらをご覧ください！ ニフティでの新卒一年目について そのOJTの第三期で、新システムへの移行に伴い旧システムの運用が停止したため、対象システムが動作していた環境を廃棄するための作業を行いました。 この記事では、システムの廃止で苦労した点、意識した点、学びを共有したいと思います。 2. 意識していた部分 「システムを廃止する」と聞くと一見単純に見えますが、実際には関連システムとの依存関係を一つずつ切り離し、必要なデータを保全し、ユーザー影響を最小化しながら進める必要があるため、想像以上に手順が多く、判断ポイントも多い作業でした。 特に、今回触れた環境は構築年代が古く資料が少ないため調査に手間がかかり、ネットワーク的にも隔離されている特殊な環境であったため、特有の制約があり苦労しました。 2-1. 順番が重要 廃止作業は、いきなりサーバを止めて消すのではなく、段階的に影響範囲を狭めていくのが安全です。 入口（ユーザアクセス）を別系統へ逃がす 周辺システムとの連携を止める 必要データをバックアップする ネットワーク的に遮断する（FWを閉じるなど） サービスを停止する リソースを削除する 2-2. 遮断の段階 今回一番意識したのは「一発で消さない」ことです。 例えばネットワーク遮断やサーバ停止は、どちらも使えなくするという意味では同じですが、復旧可能性と確認のしやすさが違います。 ここでいう「疎通だけ止める」は、FW（ファイアウォール）を閉じて外部から到達できない状態にする、といった対応です。メリットは、サーバ上のプロセスやデータを触らずに入口だけ塞げるため、切り戻しが必要になってもFWを戻すだけで復旧できる点です。 まず疎通だけ止める（FWを閉じるなどのネットワーク遮断） しばらく様子を見る 何も起きなければ削除に進む という順で進めると、万が一のときの切り戻しコストが下がります。 2-3. 「様子見」を挟む 古いシステムは依存関係がドキュメントに残っていないことが多く、停止後に思いがけない影響が出る可能性があります。 そのため、停止と削除の間に時間を置き、アラートや問い合わせなどの遅れて出る症状を拾えるようにし、切り戻しの手間とリスクを最小化しながら進めて行きました。 3. 実際の対応 システム廃止は、次の手順で進めました。 # 作業 1 新システムへのリダイレクト設定 2,3 周辺システムとの連携停止 4 バックアップ 5 FW遮断（疎通停止） 6 システム停止 7 リソース削除 3-1. リダイレクト設定 まずはじめに、旧システムへのアクセスを、新システムへリダイレクトする対応を行っていました。 事前に経路となるリンクを差し替える対応を行って頂いたのですが、念の為旧システムに来るアクセスを新システムにリダイレクトするようにしました。 Ansibleを用いて該当サーバで稼働するhttpdに設定を反映し、URLに付随するクエリパラメータにより遷移先が異なるため、動作確認は 3 パターン実施しました。 パターン 遷移先 用途 1 サービス終了ページ サービス終了済みの案内 2 新システム 新システムへのリダイレクト その他 新システム 例外処理 3-2. ファイル連携停止 関連システムとファイルの送受信でデータをやり取りしているバッチを停止しました。 この作業では他部署のシステムとの連携を解除するので、業務担当者との綿密な確認が必須でした。 手順としては、 先方でファイルの取り込みを停止 廃止するシステムでファイルの出力を停止 先方でファイルの出力を停止 廃止するシステムでファイルの取り込みを停止 の流れで行いました。 関連システムによってpull/pushの向きが違うなどの差がありましたが、基本的には取り込み処理停止→送信停止、の流れで行えば双方でのアラートを予防することができます。 3-3. 通信停止 上記とは別のシステムからのREST APIを使用した通信を切る対応を実施した。 こちらは部署内管理のものだったので構成の確認は比較的簡単にできたものの、開発経験がないPHPだったのと、ソースコードをコピペで作った関係で該当システムに無関係な記述が多量に含まれていて、必要な部分を抽出するのに手間取ってしまいました。 3-4. バックアップ 続いて関連情報のバックアップをしました。 バックアップ対象は色々考えられますが、今回は実際に動作していたソースコード(微妙にgitHub上のものと異なる)、他システムと授受していたファイル群、関連するログ、データベースのダンプ、実体をバックアップしました。 今回はサーバ上でバックアップ用ファイルを作成した後にAWS CLIを用いてバックアップを行いました。 なんとサーバ時刻の時刻がズレておりAWS CLI の認証が通らなかったため、作業前に sudo date -s で時刻合わせを行いました。普通であればNTPサーバの設定を行うところですが該当システムはもうすぐ廃棄するものであるため、dateコマンドで簡易的に時間をあわせるのみにしました。 # ソースコード tar czvf ./source.tar.gz {path_to_source} source # ログ tar czvf ./logs.tar.gz -C {path_to_log} logs # MySQLダンプ mysqldump {connection_info} > dump.sql # MySQL実体 # 実際にはmariadb sudo tar czvf ./mysql.tar.gz -C {path_to_mysql} mysqldb # httpdログ tar czvf ./httpd_logs.tar.gz -C /var/log httpd # dryrun で転送対象を確認してから本転送 aws s3 cp ./{backup_dir}/ s3://{bucket_name}/{backup_dir} \\ --recursive --dryrun --profile {profile_name} aws s3 cp ./{backup_dir}/ s3://{bucket_name}/{backup_dir} \\ --recursive --profile {profile_name} 3-5. FWを閉じる 続いてFWを閉じる対応をしました。 対象の環境に設定されているFWの設定を無効化することで、システムの停止をすることなく外部からの通信を遮断することができ、外部から見ると停止しているのと同じ状況を発生させることができます。 この対応を停止、削除の前に挟むことで切り戻しのコストを小さくしつつ、停止状況の再現ができました。 3-6. systemd unit停止 続いて本格的に停止を行っていきます。 停止対象は順番に、 zabbix-agent: システム状態の監視を行っている 事前にzabbixサーバから該当システムの監視を停止しておく必要があります。 keepalived: 主系/従系の切り替え用 httpd: php動作用 mariadb: phpのデータ保存に使用 です。 システム廃棄のための停止なので切り戻すことはありませんが、万が一のために順番を考えてsystemd unitを停止していきます。 停止したあと一日おいて問題が発生しないか様子見をします。 # 停止する順番を守る systemctl disable --now zabbix-agent.service systemctl disable --now keepalived.service systemctl disable --now httpd.service systemctl disable --now mariadb.service 3-7. リソース削除 最後にシステムを稼働させていたリソースを削除し、環境を完全に廃棄しました。 4. まとめ・振り返り 今回のシステム廃止では、単に停止するだけでなく、依存関係の切り離し、データ保全、利用者影響の最小化まで含めて段取り良く進める必要があり、想像以上に調整と確認が多い作業でした。 特に、構築年代が古く資料が乏しいことに加え、ネットワーク的に隔離された特殊環境だったため、調査と作業手順の確立に時間がかかりました。 システム停止に伴うトラブルを最小化するために詳細に調査を重ねた結果、想定外の対応範囲が増加し続け、当初の目標スケジュールを大幅に超過してしまいました。 また、周辺システム連携停止では、双方でアラートや業務影響が出ないように業務担当者と手順とタイミングを丁寧に合わせる必要があり、関係者調整の重要性を強く実感しました。 今回のレガシーシステムの調査、外部システム担当者との調整などの経験を本配属後の業務に活かしていきます。

はじめに こんにちは！新卒1年目のなべしまです。暖かくなってきましたね。 夏休みにはまだ早いですが、Terraformで自由研究を始めました！今回はTerraformでの試行錯誤を共有したいと思います。 筆者について 入社： 2025年4月（新卒1年目） 担当業務： 基幹システムグループ（ジョブローテ中） 接続サービス申込みに関連するシステム刷新を担当中 きっかけ 現在担当しているシステムでは、AWSを利用しており、リソース管理にはTerraformを活用しています。Terraformコードを書く際、先輩社員から「 -generate-config-out オプションを試してみてはどうか」と助言をもらいました。そこで、試行錯誤や調査の記録をブログにまとめることにしました。 既存リソースのIaC化 -generate-config-out オプションでは、 import ブロックを利用します。はじめに import ブロックについて触れ、 -generate-config-out オプションによるIaCを紹介します。 importブロック 従来は terraform import というCLIコマンドを直接実行する必要がありました。一方で、Terraform 1.5で導入された import ブロックを使うことで、「インポートすること自体」をIaCで定義できるようになりました。 import ブロックの書き方は非常にシンプルで、以下の2つの引数を指定します。これらは別のファイルにまとめて記述するのが一般的です。 # importブロックの記入例 import { to = aws_s3_bucket.my_bucket # Terraform上のリソースアドレス（インポート先） id = "my-actual-bucket-name" # クラウドプロバイダ上の実際のID（インポート元） } -generate-config-out オプション -generate-config-out は、Terraform 1.5から追加された terraform plan コマンドの新しいオプションです。主な仕様と特徴は以下の通りです。 IaCの自動生成 import ブロックで指定したリソースのうち、まだ設定ファイル上に resource ブロックが存在しないものを見つけると、クラウド上の実際の設定を読み取り、指定したファイル名でHCLコードを新規作成します。 コマンドの構文 terraform plan -generate-config-out=<出力先のファイル名>.tf のように、出力したいファイル名を指定して実行します。 既存ファイルの保持 指定したファイルが既に存在し、何らかのコードが記述されている場合、Terraformはエラーを返し、既存のコードを誤って上書きしないように保護します。 # リソースのインポートのコマンド例 terraform plan -generate-config-out=generate.tf 実際に書き起こしてみる 実際にS3バケットを作成し、IaCを書き起こしてみます。下図に示すような、S3バケットをAWSコンソールから作成します。 fig. IaC管理対象のS3バケット import ブロック用ファイルの準備をします。 # インポート用.tfファイル import { to = aws_s3_bucket.my_manual_bucket id = "aws-s3-sample-bucket-2026-03" } terraform plan を実行します。インポートされているログが出力されます。 # ターミナル上で実行 $ terraform plan -generate-config-out=generate.tf ... Terraform will perform the following actions: # aws_s3_bucket.my_manual_bucket will be imported # (config will be generated) resource "aws_s3_bucket" "my_manual_bucket" { acceleration_status = null arn = "arn:aws:s3:::aws-s3-sample-bucket-2026-03" bucket = "aws-s3-sample-bucket-2026-03" bucket_domain_name = "aws-s3-sample-bucket-2026-03.s3.amazonaws.com" bucket_prefix = null bucket_region = "ap-northeast-1" ... 出力された generate.tf を確認します。s3の設定が書き出されていることが確認できました。 # 以下はgenerate.tfの内容 # __generated__ by Terraform # Please review these resources and move them into your main configuration files. # __generated__ by Terraform from "aws-s3-sample-bucket-2026-03" resource "aws_s3_bucket" "my_manual_bucket" { bucket = "aws-s3-sample-bucket-2026-03" force_destroy = false object_lock_enabled = false region = "ap-northeast-1" tags = {} tags_all = {} } -generate-config-out の注意点 作業をする中で、私がハマったポイントを2点紹介します。 importブロックの id について import ブロックを書く際、インポート元のリソースを指定する id という項目があります。リソースの種類によって指定すべき値（フォーマット）が異なります。 S3バケットの場合： バケット名 例： aws-s3-sample-bucket-2026-03 ECSタスク定義の場合：ARN 例： arn:aws:ecs:us-east-1:012345678910:task-definition/mytaskfamily:123 リソースごとの正しい指定方法は、Terraform公式ドキュメント（Registry）の各リソースページにある、Importセクションを参照する必要があります。これは、Terraform 1.4 以前の import コマンドでも同様です。 resource ブロックについて import ブロックの to で指定したリソースが、すでにどこかの .tf ファイル内で少しでも定義されている場合、Terraformはコードの出力をスキップしてしまいます。 # 属性が空のリソースでも、`-generate-config-out`時にはファイル生成がスキップされてしまう resource "aws_s3_bucket" "my_manual_bucket" {} Terraformにおける「インポート」とは、コンソールなどから手動で作成した既存リソースを、Terraformの管理下（Stateファイル）に取り込む機能です。 -generate-config-out を使う際、すでに .tf ファイル内に該当の resource ブロックが少しでも書かれていると、Terraformは「インポート先のコードは用意されている」と判断してしまいます。 コードを自動生成させたい場合は、対象の resource ブロックを事前に定義しないようにしましょう。 有効な活用例 ここまで紹介した terraform plan -generate-config-out は、「既存リソースをあとからTerraform管理に移したいが、まずは現状の設定を安全にコード化して出発したい」という場面で特に役立ちます。 手動で作ったリソースの棚卸し 先にコンソールから作ってしまったリソースなどを、後からIaC化して管理したい場合 既存環境のIaC化の第一歩 既存システムを一気に書き直すのが難しい場合に、一部リソースをインポートしてコード生成し、差分を確認しながら段階的に移行 ただし、生成されたHCLはあくまで“たたき台”です。不要な属性の修正やモジュール化は、運用方針に合わせて必ず見直す必要がありそうです。 おわりに Terraformの terraform plan -generate-config-out は、 import ブロックと組み合わせることで、インポート作業をIaCとして残しつつ、既存リソースの設定をコードに起こす手助けをしてくれる便利な機能です。 今回の検証ではS3バケットを例にしましたが、リソースの種類によって id の形式が異なる点や、既存の resource 定義があると生成がスキップされる点など、実際に触ってみないと気づきづらい落とし穴もありました。 同じように試している方の参考になれば嬉しいです。 参考文献 Terraform公式ドキュメント: Import ブロック import block reference | Terraform | HashiCorp Developer Terraform公式ドキュメント: terraform plan -generate-config-out terraform plan command reference | Terraform | HashiCorp Developer Terraform Registry: 各リソースの Import セクション S3バケット： aws_s3_bucket | Resources | hashicorp/aws | Terraform | Terraform Registry ECSタスク定義： aws_ecs_task_definition | Resources | hashicorp/aws | Terraform | Terraform Registry

イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントでは、ニフティグループの社員が業務を通じて学んだことを発信しています！ 2025年、ニフティ社内でエンジニアハッカソン合宿が開催されました。 AIをテーマにした今回のハッカソンにて、優勝チームがアイディア創出に挑戦と学びの物語などについてをTech Talk#26のテーマとして開催しました。 今回のエンジニアハッカソンの概要としては、AIを企画から開発までを通しで行い、短期間で成果を出す目的で行われ、そこに中堅エンジニアが挑戦するというものです。 チームに分かれ激しい競争の中で勝ち抜いたその成果について、当日見ていない方も興味があれば是非 アーカイブ からご視聴いただければと思います。 エンジニアハッカソン合宿の様子はNIFTY engineeringにてブログ掲載されておりますので、よろしければこちらもご覧ください。 中堅エンジニアたちの激闘2日間 in 熱海 ~AIと共に~ CS教育のDX AIによる育成の効率化 現場が抱える課題に対し、AIを使用して解決するというアプローチで開発をしています。 開発にAIを使うだけでなく、AIを顧客役としたり、評価をさせるなど活用をしています。 また、対人ではなくAIを相手にすることで教育を受ける新人の心理的負担の軽減など、人間味ある課題解決を考えているところも興味深い観点かと思います。 技術スタックも紹介されており、似たような課題を感じている方は参考になるものと思います。 資料 AI 開発合宿を通して得た学び AIが速すぎて人間のレビューが間に合わないという問題もあり、速すぎるのもたいへんだなぁと感じる点もあり。 また「動作する」レベルから本格的なプロダクション移行時の品質基準をどう設定するかの難しさなどの課題があったようです。 AI開発により開発スピードや実装コスト削減を活かし、今後どのようにしていくのか。どんな気付きや学びがあったのかは是非アーカイブ動画もご覧いただければと思います。 最後に 次回のTech Talkは未定ではありますが、開催が決まりましたら connpass や X でお知らせいたしますので、よろしければ登録してお待ちいただけると幸いです。 アーカイブ（YouTube） 発表資料（Speaker Deck）

アイキャッチ はじめに こんにちは！ 2025年新卒で、もうすぐ2年目の先輩になるエンジニアのパクパクです みなさん、「 クリーンアーキテクチャ（Clean Architecture） 」という言葉を聞いたことはありますか？ OJTの最後にメール開発チームに配属されて、私もこのアーキテクチャにこれから触れていくことになりました。 この記事では、クリーンアーキテクチャを初めて触った新人エンジニアの視点で、概念を理解しつつ、実際のディレクトリにどう落とし込むかを順番に整理してみます。   1. 全部一つのディレクトリにまとめちゃダメですか？ クリーンアーキテクチャがなぜ必要なのか、 おもちゃ作り にたとえて見てみます。   Before：ひとり工房 皆さんが「ひとりでおもちゃを作る工房」を運営していると想像してください。設計図を描いて、部品を作って、組み立てて、梱包して… 全部ひとりでやります。 最初はそれでも回ります。でも注文が増えると、だんだん問題が出てきます。 問題1：1か所直すと全部が揺らぐ 問題2：部品だけを単体で検査できない 問題3：材料の仕入れ先を変えにくい   コードにすると、だいたいこんな感じです。 def make_and_ship_toy(): # DBから部品データを取得 db = mysql.connect(host="localhost", user="root") parts = db.query("SELECT * FROM toy_parts") # 組み立て指示書を作成.. instructions = create_instructions(parts) # 倉庫に保存.... s3 = boto3.client("s3") s3.upload(instructions, "instructions.pdf") # 通知を送信...... smtp = smtplib.SMTP("example.com") smtp.send(notification)   たとえば mysql.connect を PostgreSQL に変えたら？ db.query の戻り値 parts の型が変わり、本来 DB と無関係なはずの create_instructions(parts) まで修正が必要になります。   After：役割が分かれたおもちゃ工場 次は工場にアップグレードして、役割ごとにチームを分けてみましょう！ Nano Banana生成画像 工場のチーム 役割 設計チーム 「車輪は4つ、色は赤」みたいなコアのルールを決める 製造チーム 設計チームのルールに沿って、作る手順を指揮する 材料調達チーム 外部の業者から部品を仕入れる 注文受付窓口 お客さまの注文を受けて、製造チームへ渡す こうやって分けると、さっきの3つの問題がきれいに解決します！ 車輪の形を変えても → 設計チームだけ 直せばいい 車輪だけ単体検査できる → 設計ルールを 独立して テストできる 木材業者を変えても → 材料調達チームだけ 直せばいい（設計はそのまま）   これをプロジェクトのフォルダ構成に当てはめると、こうなります。 工場のチーム 業務のフォルダ 役割 設計チーム entities ビジネスルール 製造チーム usecases 処理の流れを指揮する 材料調達チーム gateways DB、S3、メールなど外部接続 注文受付窓口 apis 、 batches ユーザー操作や実行要求の受付   2. おもちゃ工場で見るクリーンアーキテクチャ 上のアーキテクチャを基にして、おもちゃ工場についての内容で画像を生成してみました。 Nano Banana生成画像   いちばん内側：きらきらコア（Entities） 工場の 核となる設計ルール です。 「車輪は4つで、色は赤」みたいに、誰が作ってもどこで作っても 絶対に変わらないルール です。 コードでは entities フォルダがこの役割を担当します。   2つ目の円：おもちゃをつくる手順（Use Cases） 工場の 作業手順書 です。 「1. 車輪を付ける → 2. 色を塗る → 3. 梱包する」みたいに、 具体的な手順の流れ を決めます。 コードでは usecases フォルダがこの役割です。 「部品を集めて → 組み立てて → 出荷する」みたいに、 処理の流れを指揮 します。   3つ目の円：つなぐための道具（Interface Adapters） 工場の 接続アダプタ です。大きく2種類あります。 どちらも「内側の世界」と「外側の世界」をつなぐ役割です。 入口 （注文受付窓口）：ユーザーの要求を受けて工場の中へ渡す → apis 、 batches 出口 （材料調達ポータル）：外から材料を持ってきて工場へ渡す → gateways   いちばん外側：外の世界の便利なもの（Frameworks & Drivers） 自分たちで作ったものではなく、 持ってきて使う便利な道具 です。 FastAPI（Webフレームワーク） SQLAlchemy（DB ORM）   依存は内側に向けてだけ！ クリーンアーキテクチャでいちばん大事なルールは、これひとつです。 内側の円は、外側の円の存在を絶対に知らないこと！ おもちゃ工場で言うと： 材料調達チーム（外側）が設計ルール（内側）を参照する → OK！ 設計ルール（内側）が「A社の木材で作れ」と特定の業者（外側）を指名する → NO！ 設計チームは「木材が必要」とだけ書いて、どの業者から持ってくるかは気にしません。 こうしておくと、業者をAからBに変えても、設計を変えずに済むからです！ コードでも同じです。 entities （内側）は gateways （外側）を import しない usecases （内側）は「どんな倉庫に保存して」のような具体的な保存方法は知りません。ただ「倉庫に保存して」と依頼するだけです。   3. プロジェクトのフォルダ = 工場の区画図 では実際に、プロジェクトの app/ フォルダを見てみましょう。 ここで紹介するフォルダ名（ entities 、 usecases など）はあくまで一例です。プロジェクトやチームによって命名は異なります。 app/ │ ├── entities/ コアのルール │ ├── toy_car.py ← おもちゃの車のルール │ ├── toy_robot.py ← おもちゃのロボットのルール │ └── ... │ ├── usecases/ 処理の流れ │ ├── gift_sets/ │ │ └── pack.py ← ギフトセットを梱包する流れ │ ├── toy_cars/ │ │ └── assemble.py ← おもちゃの車を組み立てる流れ │ └── orders/ │ └── cancel.py ← 注文キャンセルの流れ │ ├── apis/ 注文受付窓口 │ └── v1/ │ ├── toy_cars.py ← おもちゃの車の注文 │ └── orders.py ← 注文管理 ├── batches/ 指示書 │ └── pack_gift_set.py ← CLIコマンド │ ├── gateways/ 外部接続 │ ├── parts_db/ ← 部品データベース担当 │ ├── warehouse/ ← 倉庫（ファイル保存）担当 │ ├── delivery/ ← 配送（通知送信）担当 │ └── supplier/ ← 仕入れ先API担当 │ └── main.py   ポイント 1. gateways/ の下にサブフォルダがたくさんある！ gateways は接続先が複数あるので、 接続先ごとにサブフォルダ を切っています。 gateways/ ├── parts_db/ ← 部品データベースから取得・保存 ├── warehouse/ ← 倉庫へアップロード・ダウンロード ├── delivery/ ← 配送（通知送信） └── supplier/ ← 仕入れ先API呼び出し   2. usecases/ の中も、業務ごとにフォルダがある！ 手順書（Use Case）も種類ごとに分かれます。「ギフトセット梱包用」「おもちゃの車組み立て用」「注文キャンセル用」みたいな感じです。   動作の流れ おもちゃ工場には pack-gift-set という指示書があります。ギフトセットを組み立てて出荷する機能です。 実行すると、だいたいこんな順番で動きます。 [注文受付] [制作指示] batches/ → usecases/ CLIコマンド実行 処理の流れを指揮 　　　　　　┌───────────────┴───────────────┐ 　　　　[部品調達]　　　　　　　　　　　[完成品出荷] 　　　　 gateways/　　　　　　　　　　 gateways/ 　　　　DB参照・部品確認　　　　　　　　配送通知・倉庫保存   担当者がCLIでコマンドを実行 → batches/ が注文を受付 usecases/ の手順書が「部品確認 → 組み立て → 出荷」の流れを指揮 gateways/ が実際にDBから部品を確認して、ギフトセットを組み立て、配送通知を送ります   おわりに 今回はクリーンアーキテクチャを おもちゃ工場 にたとえて整理してみました。みなさん、イメージできましたか？ 私は難しい概念に出会うたびに、こうやって身近なものに置き換えて勉強しています。「これが工場だったら？」「これがレストランだったら？」みたいに考えると、急に難しかったものが少しずつ馴染んでくる気がするんです。 実はソフトウェアアーキテクチャには、クリーンアーキテクチャ以外にもいろいろあります。 レイヤードアーキテクチャ （Layered Architecture）：層を上から下に積み重ねる構造 ヘキサゴナルアーキテクチャ （Hexagonal Architecture）：ポートとアダプタで外部をつなぐ構造 オニオンアーキテクチャ （Onion Architecture）：クリーンアーキテクチャに近い玉ねぎ構造 この記事でクリーンアーキテクチャに一度触れておくと、別のアーキテクチャに出会っても「これも役割分担の方法のひとつなんだな」と、少し自信が持てると思います。 読んでいただき、ありがとうございました   参考資料 The Clean Architecture — Robert C. Martin (Uncle Bob)  

はじめに はじめまして。2025年4月に新卒でニフティに入社した宮村です。 ニフティのエンジニア職には On-the-Job Training（OJT） という制度があり、私が入社した年度では入社後の約1年間で 3つの異なるチーム を経験しました。各期約3ヶ月、実際の業務に携わりながら技術とチームワークを学んでいく仕組みです。 この記事では、私がOJTで経験した3つのチームでの業務内容や、やりがい・苦労した点をエピソードベースでお伝えします。 「ニフティのOJTって実際どんな感じなの？」 という疑問を持つ方に、少しでもリアルな雰囲気が伝われば嬉しいです。 OJTの前に：新人研修（4月〜6月） OJTが始まる前に、約2ヶ月間の 新人研修 があります。研修は大きく3つのフェーズに分かれています。 共通研修（4月） まずはビジネス職と合同の共通研修からスタートします。社会人としての基礎やニフティの事業について学ぶ期間です。職種を問わず同期全員で受けるため、エンジニア以外の同期とも関係を築ける貴重な機会でした。 技術研修（5月） エンジニア職のみの技術研修に移ります。外部の研修会社による講義形式で、Web開発の基礎を体系的に学びます。HTML/CSS/JavaScriptといったフロントエンドの基礎から、Linuxやサーバの基本、バックエンド技術、コンテナ、テスト手法まで幅広くカバーされます。プログラミング経験の差に関わらず、全員が同じスタートラインに立てるよう設計されていました。 エンジニア定例（6月頭） 最後に、 社内のエンジニアが講師を務める研修 （エンジニア定例）を受けます。Git基礎、AWS基礎、生成AIなど、ニフティの現場で実際に使われている技術や手法を先輩エンジニアから直接学べます。外部研修で得た基礎知識を、ニフティの実務にどう活かすかという視点で深掘りしていく内容で、OJTに入る前の総仕上げとなりました。 OJTの基本的な流れ 各期の流れはおおむね共通しています。 目標設定 — 配属後、トレーナーや上長と面談し、その期で達成したい目標を決めます 開発業務 — スクラムなどの開発手法を通じて、実際のプロダクト開発に参加します 振り返り — 期の終わりに目標の達成度を振り返り、次期への引き継ぎを行います トレーナーの方が日々の相談相手としてついてくださるので、困ったときにすぐ聞ける環境が整っています。 一期：SSOチーム（6/12〜9/20） チームについて サービスインフラチームの うさかぴサブチーム に配属されました。名前から想像し辛いかもしれませんが、ニフティ全体で使われている認証・認可システム 「SSO」 やその他ユーザー管理に使用されるシステム を開発・運用するチームです。 SSOは全社共通の基盤であり、止まるとニフティの多くのサービスに影響が出ます。そのため、変更には慎重さが求められる環境でした。 使用技術 OpenID Connect（OIDC） Python（Django） AWS 主な業務内容 SSOをOIDCの標準仕様に近づける改修 @nifty 優待サービスの販路拡大に向けた改修 新規サービスにOIDC導入するための改修 やりがい 最もやりがいを感じたのは、 SSOをOpenID Connect（OIDC）の標準仕様に近づける改修 を行えたことです。 実は大学時代にOIDCを活用した研究をしていたため、この分野には馴染みがありました。スプリントのプランニングで標準化の方針が検討されていた際、開発を進める中で「この修正だけでは足りない箇所がある」ことに気づき、自ら追加の修正を提案・実装しました。 結果として、OIDCのライブラリを導入するだけでSSOを使えるようになり、プロダクトの利便性向上に貢献できました。 学生時代に学んだことが実務で活きた瞬間 は本当に嬉しかったです。 苦労した点 一方で、初めての配属ということもあり、 実務の開発プロセスを一から習得する 必要がありました。スクラム、テストコードの書き方、本番環境を止めずに品質を担保するための工夫など、学生時代には経験のなかったことばかりで最初は苦戦しました。 また、障害対応の場面に立ち会った際に自分の無力さを痛感したこともあります。当時は「一人で解決しなければ」という意識が強く、難しいタスクを抱え込みすぎてしまうこともありました。これは後の期で大きな学びに繋がります。 二期：ポータルチーム（9/21〜12/20） チームについて 第一開発チームの @niftyトップページを担当するサブチームに配属されました。 @niftyトップページ の開発・運用に加え、新規事業の開発も手がけるチームです。 サービスの企画担当者と密にコミュニケーションを取りながら進めるスタイルで、AWSをはじめとしたモダンな技術スタックを使った開発が特徴です。スクラム開発（2週間スプリント）を採用し、デイリースクラムでチーム全体の進捗を共有していました。 使用技術 microCMS Next.js AWS（Terraform） 主な業務内容 「@niftyトップページ」の開発・運用 新規事業のAWSインフラおよびフロントエンドの構築 やりがい・苦労した点 この期で最もやりがいと苦労を感じたのは、 未経験の状態からAWS環境の構築にゼロから挑戦したこと です。 当初はフロントエンド寄りの業務を想定していましたが、チームの状況や自分自身の希望もあり Terraform未経験の状態からインフラ構築 を任されることになりました。正直、最初は不安もありましたが、これが結果的に大きな成長のきっかけになります。 先輩方が過去に構築した環境を参考にしながら、VPC・DNS・CI/CDパイプラインの作成を進めました。ただ、今回の要件と過去の構成には差分があり、初めて触る技術の中でその差分を埋める作業には非常に苦労しました。 一期での反省を活かし、 困ったときは一人で抱え込まず、積極的にチームへ相談する ことを意識しました。先輩方の手厚いフォローのおかげで、最終的には新規事業のフロントエンドインフラをほぼ一人で構築し、動作確認まで完了できました。 また、一期でSSO（認証）の経験があったことが二期で活き、新規事業のSSO導入時に的確な助言ができたことも印象に残っています。 異なるチームでの経験が繋がる瞬間 は、OJTならではだと感じました。 三期：金剛チーム（12/21〜3/20） チームについて 入会システムチームの 金剛サブチーム に配属されました。代理店様が光回線やオプションサービスの入会に使用するシステムの、開発・運用を担当しています。 代理店様との接点が多く、社内外の複数部署との連携が求められる環境です。 使用技術 PHP（CakePHP） AWS（Terraform） 主な業務内容 「@nifty つなぎモバイル」をより多くの方に申し込めるよう、獲得代理店様向けの申込ツールを改修 サインアップシステムにクレカチェック機能を追加 光コラボ入会時のオプションサービス申し込みフォームのデザイン刷新 「ニフティ会員特別でんきプラン」申し込みシステムのAWS移行（Terraform） やりがい・苦労した点 三期では 複数のプロダクトを横断して改修する という、これまでにない経験をしました。 中でもオプションサービス申し込みフォームのデザイン刷新は、サービスの企画や制作を行うチーム、光コラボ申し込みシステムのチーム等と連携しながら進行するプロジェクトで、初めて経験する 多方面とのマルチパスな調整 に難しさを感じました。ただ、一期・二期で培った「相談すること」「周囲を巻き込むこと」の大切さを実践できている手応えがあります。 また、でんきシステムのAWS移行では、一期のAWS経験と二期のTerraform経験がそのまま活きました。OJTを通じて積み上げてきた技術が 三期で統合された ように感じ、自分自身の成長を実感できた瞬間でした。 OJT全体を通して 3チームの共通点 スクラム開発 — 三部署ともスクラムを採用しており、一度身につけた開発の型はどのチームでも活きました AIの活用推進 — 一期ではAI推進チームのメンバーがおり、二期ではKiroを使ったspec開発も実施されるなど、各チームで積極的にAIを取り入れています 人の温かさ — どのチームでも、わからないことがあれば時間を割いて丁寧に教えてくださる先輩方ばかりでした 技術の幅の広がり OJTを通じて触れた技術は、期ごとに大きく異なります。 一期 : Python / Django / OIDC 二期 : Next.js / microCMS / Terraform 三期 : PHP / CakePHP / Terraform バックエンド → フロント＋インフラ → レガシー＋モダンの混在環境と、 毎期まったく異なる技術スタックに触れられる のはOJTの大きな魅力です。 一番の成長：「相談する力」 振り返ると、OJTを通じた一番の成長は 技術力よりも「相談する力」 かもしれません。 一期では「一人でやろうとしすぎていた」という反省がありました。二期ではそれを意識的に改善し、積極的にチームへ相談するようにしました。そして三期では、トレーナーから「自走できる」と評価されるまでになりました。 一人で抱え込まないこと は、技術を学ぶことと同じくらい大切なスキルだと実感しています。 こうした成長を実現できたのは、 3つのチームを渡り歩きながら、毎回新しい環境で「相談する」経験を積み重ねられるニフティのOJTだからこそ だと強く感じています。チームが変わるたびに関係構築からやり直す大変さはありますが、その繰り返しこそが「相談する力」を本物にしてくれました。 ニフティに興味を持ってくれた方へ 私が入社した年度では、OJTを通じて約1年間で 3つの異なるチーム を経験しました。毎回新しい環境・新しい技術・新しい人間関係にゼロから飛び込むのは正直大変でしたが、だからこそ 圧倒的に視野が広がり、確かな成長を実感できた 1年間でした。 私が伝えたいことは3つです。 学生時代の経験は活きる場合がある — 私の場合はOIDCの研究経験が一期で即戦力になりました。どんな経験も無駄にはなりません 困ったら相談してほしい — ニフティには優しい先輩方がたくさんいます。一人で抱え込む必要はありません 毎期が新しいチャレンジ — 「できない」が「できる」に変わる瞬間を、OJTでは何度も味わえます この記事が、ニフティに興味を持ってくれた方にとって、少しでも働くイメージを持つきっかけになれば幸いです。

ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。その一つが、オンラインサポートチーム。オンライン会議や社内イベントなど、配信関連のクオリティを向上させる目的で発足し、現在は10名ほどで活動しています。 前編ではチームのメンバーに、具体的な活動内容について語ってもらいました。後編ではチーム外活動を行うモチベーションやメリット、今後やってみたいことなどを聞いていきます。 チーム外活動の魅力は、「自分が興味のある分野」で会社に貢献できること みなさんが業務外の活動であるオンラインサポート（以下、オンサポ）に取り組む、一番のモチベーションを教えてください。 Sさん 私はやはり、好きな機材を触れるのが大きいですね。カメラだけじゃなく、大きめの照明やビデオスイッチャーなど、個人の趣味レベルではなかなか扱わないものを使って試行錯誤できるのが楽しいです。 それからオンサポには、たとえば Sさん だったら音響関係、 Aさん だったら動画編集など、自分がそれまで知らなかった分野に強い人たちも集まっていて、色んなことを吸収できるのも大きいですね。それを吸収したからといって自分のキャリアに役立つかどうかは分かりませんが、間違いなく人生を豊かにしてくれると思います。 Aさん 似た答えになってしまいますが、私もガジェットをいじったり、配信周りのソフトウェアを調整したりするのが好きなので、会社がそういう人材を求めているなら手を挙げてみようと。最近はオンサポの「チーム運営」を任されていて、それもいい経験になっています。本業では部署移動したばかりで、組織の動きまで考える余裕はなかなか持てませんが、そのぶんオンサポで経験できているのは自分のキャリアという観点でも大きいのかなと思いますね。 Sさん 自分は普段は社内プラットフォームチームという部署にいて、ニフティの従業員が使う社内ツールなどの運用を担っています。従業員が“お客様”という点は、オンサポも同じ。ユーザーがすぐ近くにいて、反応や感想を直接もらえるのはモチベーションにつながっています。 また、オンサポでは本業ではなかなか発揮する機会のない知見やスキルを活かして、会社に貢献することができます。それもやりがいの一つですね。 ちなみに、オンサポチームの活動と所属部署での業務の割合は、どのように定められていますか？ Sさん 明確なルールが定められているわけではなく、メンバー各自が所属部署の上長と調整してオンサポでの活動時間を確保しています。僕の場合はなんとなく「業務時間全体の3分の1くらいまで」ということで、上司の承認をもらっている形ですね。いずれにせよ、本業に支障が出ない範囲内での活動に止めるという認識はみんな持っていると思います。 上長の方は、チーム外活動に対しても理解があると。 Sさん 僕の上長に限らず、チーム外活動に対して否定的な人は基本的にいないという認識です。もちろん、本業が忙しくなって離脱していく人はいますが、最初から「やめてほしい」と言われることはまずないと思います。 オンサポ以外にも、さまざまなチーム外活動が発足 オンサポ以外にも、こうしたチーム外活動というのは盛んに行われているのでしょうか？ Aさん そうですね。私はオンサポ以外でいうと、「エンジニアリング可視化プロジェクト」という活動にも参加しています。ニフティには数多くのシステムやプロダクトがあり、関わる人数も膨大なため、各エンジニアがどのサービスにどれくらいの時間をかけているのかが把握しにくいという課題がありました。 また、そのサービスに精通している人が何人いるのか、サービス自体がどんな状態になっているのかも、より正確に把握できたほうがいいよねと。そこで、そうした様々なパラメーターやエンジニアリングの要素を見える化して、チーム体制やサービス自体の改善につなげるのがエンジニアリング可視化プロジェクトです。 Sさん 僕の場合はオンサポ以外に、採用ブランディングワーキンググループでも活動を行っています。採用にまつわるブランディングを行うことで、求職者にニフティのことを知ってもらおうというものです。 複数のチーム外活動を兼務するメリットというと、どんなことが思い浮かびますか？ Aさん まずは部署をまたいで色んな人が集まっているので、顔が広くなること。それから自分が所属しているチーム以外の文化や考え方、手法を知れることです。開発のアプローチ一つとっても結構チームによって異なるので、エンジニアリング可視化プロジェクトで実際にソフトウェアを作る時にも、他部署の先輩のやり方を学べるのはとても大きいですね。それを自分のチームに持ち帰ることもあって、本業にもいい効果が生まれていると感じます。 みなさんが今後、オンサポチームでやってみたいこと、あるいは、他に興味のあるチーム外活動があれば教えてください。 Sさん 私はとりあえず、オンサポの活動を続けていきたいです。これまでさまざまなイベントなどで試行錯誤を重ねてきて、今の環境下ではベストに近いクオリティの配信ができるようになりましたが、会場や配信場所が変わってもこれを維持できるように色んな構成を試してみたいと思っています。どんな環境でも高いレベルの配信を実現できるチームになりたいですね。 Sさん まずオンサポに関しては、2025年は Sさん が「 InnerSource Gathering Tokyo 2025 」という、インナーソースに関するナレッジの創出と共有に特化したコミュニティのイベントに、配信機器スタッフとして参加しています。今後もニフティが参加する外部イベントの配信に積極的に関わることで、ニフティとしてのブランディングにつなげていきたいという思いはありますね。それから、もう一つの採用ワーキンググループでも、「採用につなげる」「社内の知名度を上げる」など、より具体的な成果を出していきたいです。 Aさん Sくん が言うように、オンサポとして現在の環境下での配信クオリティの向上については、わりとやり切ったと思っています。ただ、このまま現状維持を目指すだけだと、モチベーションという意味でも活動を続けていくのは難しい。我々が持つ「配信もできるエンジニア」という特性を活かして、何か新しいことを見つけていかなくてはいけません。たとえば、先ほど Sくん が言ってくれた技術コミュニティのイベントに協力して、ニフティのエンジニアの外部露出だったり、ニフティ自体の知名度向上だったりに貢献していきたいです。 個々の「やりたい」という思いを尊重してくれる会社 それでは最後に、みなさんが感じる「ニフティの良いところ」を教えてください。 Aさん 先ほど Sくん も少し話していましたが、ニフティには個人が「やりたいこと」を尊重してくれる文化があります。有志によるチーム外活動がこれだけ盛んなのも、会社全体にチャレンジしやすい雰囲気があるから。少なくとも、会社をよくしようという思いで新しいことを始めようという人を否定する上長はいないので、そこはニフティの良さの一つですね。 Sさん Aさん に同感です。私はオンサポには途中参加なのですが、メンバーを募集していた時期がちょうど、本業がとても忙しい時期だったんです。ただ、それでも参加したいという思いがあり上司に相談したところ、「（本業の）今のヤマを超えたら本格的に活動を始めるとして、とりあえず応募しておいたら」と提案してくれました。上司からすると「この忙しい時期に何を言い出すんだ」と難色を示しても無理はないのですが、完全にダメとは言わない。メンバーの「やりたい」という思いを汲んで、いい方向に導いてくれる人が多いように感じます。 Sさん そもそも、そういったことを相談しやすい風通しの良さもありますよね。上司だからと変に遠慮をすることもなく、本音で話すことができます。チーム外活動もそうですし、たとえば今の部署では経験できない仕事や経験を積みたいと思った時に、部署異動の相談なども普通にできますから。本当に自分がやりたいことベースで、会社生活を送れるのはニフティの良さだと思います。 前編もご覧ください！ 今回はニフティのオンラインサポートチームのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】本業外の社内活動も、真剣だから面白い。配信における映像や音響のクオリティ向上に取り組む“オンサポ”チームの活動【ニフティ オンラインサポートチーム前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

はじめに こんにちは。ニフティ株式会社の高垣と申します。 私が所属しているチームでは、会員様向けのお問い合わせに対応するコールセンターの業務改善にAIを活用しています。その中で、Amazon BedrockのLLMを呼び出すLambdaを実装する際に 「LLMの出力を安定してJSON形式で受け取りたい」 という課題にぶつかりました。 本記事では、この課題を Converse APIのTool Use で解決した方法をご紹介します。BedrockでLLMの出力を構造化データとして扱いたい方の参考になれば幸いです。 簡単な業務背景 弊社のコールセンターでは、お電話をいただいた際にお客様がニフティのご契約者かどうかを確認する「本人確認」のステップがあります。これにAIを活用することで、本人確認にかかる時間を短縮し、お客様がよりスムーズにお問い合わせできるのではないかというアイデアが生まれました。私はこの取り組みの中で、Amazon Bedrockを呼び出すLambdaの作成を担当しました。Bedrockから受け取った結果を後続の処理にJSON形式で渡す必要があったのですが、ここで課題が発生しました。 invoke_model の課題：LLMの出力が文字列になる 通常、Python（boto3）のLambdaからBedrockを呼び出す際は invoke_model がよく使われます。しかし、この方法ではLLMからの回答が「文字列（String）」として返ってきます。 LLMの特性上、出力は確率に基づいて生成されるため、たとえプロンプトでJSONを返すように指示しても、常に期待通りのデータ構造になるとは限りません。その結果、後続の処理でパースに失敗し、エラーを招くリスクがありました。 Converse APIのTool Useによる解決 そこで今回は、この不確実性を排除するために Converse API を採用しました。Converse APIを活用することで、LLMからの出力を安定して「JSON形式」で受け取れるようになり、後続処理への連携が非常にスムーズになりました。 Converse APIのドキュメント 具体的には、 toolConfig の tools に期待するJSONの形式を定義し、Converse APIでBedrockを呼び出す際にtoolを指定します。 以下にサンプルコードを載せます。 import boto3 bedrock_client = boto3.client("bedrock-runtime") #tool_listの定義 tool_list = [ { "toolSpec": { "name": "parse_json", "description": "JSONにパースする", "inputSchema": { "json": { "type": "object", "properties": { "A": {"type": "number", "description": "Aの説明"}, "B": {"type": "string", "description": "Bの説明"}, }, "required": ["A", "B"], # レスポンス時に必須なもの } }, } } ] # Bedrockを呼び出し response = bedrock_client.converse( modelId=MODEL_ID, #モデルIDを指定(anthropic.claude-3-sonnet-20240229-v1:0など) toolConfig={"tools": tool_list, "toolChoice": {"tool": {"name": "parse_json"}}}, messages=[ { "role": "user", # 送信者のロール "content": [{"text": user_prompt}], # ユーザーからの入力プロンプト } ], system=[{"text": system_prompt}], # システムプロンプトの設定 ) このサンプルコードでは {A: 1, B: "test"} のような形式のJSONレスポンスが返されます。 tool_list の inputSchema で定義したスキーマに沿って、LLMの出力が構造化されます。 レスポンスからJSONデータを取り出すには、以下のようにします。 # レスポンスのcontentリストからtoolUseブロックを探して取得する json_result = None for block in response["output"]["message"]["content"]: if "toolUse" in block: # toolUseのinputには、パース済みの辞書(dict)データが格納されている json_result = block["toolUse"]["input"] break # 見つけたらループを抜ける if json_result is not None: print(json_result) # {'A': 1, 'B': 'test'} else: print("レスポンスにtoolUseブロックが含まれていませんでした。") 終わりに invoke_model ではLLMの出力が文字列になるため、JSON構造を保証するのが難しいという課題がありましたが、Converse APIの Tool Use 機能を活用することで、この問題をシンプルに解決できました。 LLMの出力を構造化データとして扱いたい場面では、ぜひConverse APIを利用してみてください。 今後も、お客様の満足度向上のために、AIやクラウド技術を活用したコールセンター業務の改善に取り組んでいきます。 参考 https://catalog.workshops.aws/building-with-amazon-bedrock/en-US https://docs.aws.amazon.com/boto3/latest/reference/services/bedrock-runtime/client/converse.html