Japan SEO Conference 2026に参加!AI時代のSEOをPdM視点で持ち帰る

こんにちは!ニーリーでPdMをしている阿部です。

7月7日に開催された「Japan SEO Conference」に参加してきました!

ニーリーが運営するパークダイレクトは、月極駐車場をオンラインで検索・契約できるサービスで、自然検索はとても重要な集客チャネルの1つです。

検索体験がAIによって大きく変わっていく中で、最新の動向をキャッチアップしたいと考え、札幌から東京に出張してきました✈️ (7月の東京の暑さにやられるかな…と内心ビビっていたのですが、思いのほか涼しくて一安心。まずは天気に恵まれました笑)

この記事では、イベントの概要と、印象に残ったセッションの内容を紹介します。

Japan SEO Conferenceとは

東京でリアル開催された、Faber Company社が主催する、SEO・GEOに特化したカンファレンスです。

有料イベントですが、500名規模と日本国内では最大のSEOのカンファレンスになります。会場に到着した時には既にほぼ満席でした・・(すごい)

SEOのオフラインイベントに参加するのは初めてだったのですが、普段SNSで見ている方々から、直接話を聞けるのを楽しみに臨みました!

セッションは終日たっぷり。ここでは特に印象に残った3つのセッションについて記載してみます。 ※ 全て素敵な内容だったのですが、非公開のセッションもあり絞って記載します。

印象に残ったセッション

① 生成AIで検索体験はどう変わるのか?企業・ブランドの対応状況は?

AI検索の「現在地」を、Google視点・事業会社視点と複数の視点から眺められたセッションでした。

まず改めて確認されたのは、Googleのスタンス。「AI検索に向けて、従来のSEOから特別なことが必要になったわけではない」と打ち出しており、かつこれは基本的には正しいと。

ただ面白いのは、Googleが語っていない部分もあるということ。

Ahrefsなどが客観的に出しているデータとして下記の3点があります。

  1. ゼロクリック検索が広がっていること
  2. AI Overview(AIO)の参照元にYouTubeが多いこと
  3. AIOの引用元が検索上位である割合がここ半年で大きく変動していること

これらもまた、正しい。

このお話を聞いて思ったのは、AI検索においては特に、いま時点で正解だと思っているものが、1年後にはもう正解じゃないケースも頻繁に起きうるということ。「時間軸」を意識して施策の優先度判断や、分析・改善を回し続けることが重要だと改めて思いました。

加えて参考になったのが、事業会社の視点で、現状分析をどう行い、投資対効果をどう判断していくかという話です。具体的には、AI経由の流入シェアを可視化したり、狙うキーワードやプロンプトでどう表示・言及されているかをモニタリングしたり。そのうえで、どんな仮説を立て、どのくらいの予算感で施策を進めているか——というリアルな話が聞けました。
この判断は、事業会社のPdMとして参考になると同時に「わかる……」と深く共感するところでした。

② GEO/LLMO時代のテクニカルSEO最前線

実際に普段手を動かしながらSEO業務に従事されている登壇者のみなさんの、テクニカルの現在地がぎゅっと詰まったセッション。

印象的だったのは、「巷で言われている情報は、本当に確からしいのか?」を定量データで検証している登壇者のみなさんの姿勢です。

たとえばLLMボットのアクセス状況。llms.txtを見に来ているか、sitemapはちゃんと読まれているか、robots.txtは正しく効いているか。こういったことを実データで確かめていく。そうして初めて「これは本当にやるべき施策なのか」の解像度が上がるんだな、と。“みんなが言っているから”ではなく、自分たちのデータで確かめる。当たり前ではあるものの徹底的に実施されている姿勢に、背筋が伸びました。

もう一つ面白かったのが、国内外の違い。海外カンファレンスではテクニカル施策よりも、PRをどう強化するかに重心があるそうです。AIがクエリファンアウトも含めていろんな情報を参照して回答を返す時代。ブランディングの重要性がより増している、という共通見解を持たれている印象を持ちました(AI関係なくずっと重要な話でもありますが...笑)。

③ UCPでECはどう変わる?エージェンティックコマースへの備え

AIエージェントが購買まで担うようになったら、EC・検索はどう変わるのか。少し先の未来を扱いつつ、地に足のついた議論だったのが良かったです。

前提として、エージェントが購買を代行するための仕組みは整ってきています。ACP(Agentic Commerce Protocol)やUCP(Universal Commerce Protocol)といったプロトコルが登場し、技術的なお膳立ては着々と進行中。そのなかで「じゃあ実際どこまで置き換わるの?」という議論も行われていました。

特に考えさせられたのが、「その商材は、本当にエージェント経由で買いたいものなのか?」を一度立ち止まって考える必要があるという点。日常的に買うものなら、Amazonの定期購入のような仕組みが既にある。そこをあえてエージェント経由で買うのか。逆に、テスラのような高額な買い物を、エージェントに任せて決済したいと思うのか。

そのうえで、どのくらいのスピードで浸透するのか、時間軸の見立てを持っておく大事さ。「1000回モノを買うとして、そのうち何回が、どのくらいの時間でエージェント経由に置き換わるのか」。この見立てがあって初めて、施策の優先度に反映できる。今すぐ全力投資なのか、備えつつ様子見なのか——その判断につながる話が印象的でした。

社内でのシェア会

「参加して終わり」にしないため、チーム内でイベントで話されていたことをシェア・ディスカッションする会を実施しました。

カンファレンスで言及されていた内容が実際の社内データと相違ないかを確認したり、AI検索の広がりを見据えて「パークダイレクトならこういうこともできるのでは?」と施策案出しにつながったりと、実際の施策や優先度の判断にまで結びついていく手応えがありました。

最後に

事業会社の視点だと、AI時代のSEOは「何かやらなくて大丈夫なのか?」とどうしても不安になりがちな領域だと思っています。

そんな中で、最新の事実や各社の考え方・向き合い方を自分の中に持ち帰れたのは、本当に価値がありました。参加して良かった、と心から思えるカンファレンスでした!

登壇者のみなさん、運営のみなさん、現地で話してくださったみなさん、ありがとうございました!

JaSST’26 Kansaiにゴールドスポンサーとして協賛いたします & テクノロジーセッションの登壇もあります!

ニーリーは、2026年7月3日(金)に開催される「JaSST’26 Kansai」にゴールドスポンサーとして協賛いたします。

JaSST’26 Kansaiの概要

  • 日程: 2026年7月3日(金) 9:00〜18:55
  • 会場: グランフロント大阪北館タワーB10階 ナレッジキャピタルカンファレンスルームタワーB
  • 主催:
    特定非営利活動法人 ソフトウェアテスト技術振興協会 (ASTER)
    JaSST'26 Kansai 実行委員会
  • 公式サイト: https://jasst.jp/kansai/26-about/

今回は「シン・ソフトウェアテスト~ 新時代に築き直すソフトウェアテストの入門・基礎」をテーマに、

コード生成やテスト自動化が高度化する中で、「テストとは何か」「SQAの役割とは何か」

というような情報交換がされる予定です。

協賛の背景

これまで幾度にわたってお伝えしてきていますが、ニーリーでは今まさにマルチプロダクトの波が来ています。 単にプロダクトが複数あるだけではなく、

  • Park Direct: 10→100
  • Park Direct for Business: 1→10
  • ワンデイパーク: 0→1

というフェーズの異なる事業が混在し全ての事業が高速に伸びている状況において、品質は最重要テーマの一つとなっています。 ニーリーにおけるQA組織では「品質は高く、しかも早く」をMissionとしてプロダクトグロースのプロセスに深く入り込みながら品質保証を行っています。

上述の通りプロダクトエンジニアとQAは常に連携を密にしながら、最速での価値提供に向けて活動をしています。
よろしければQAエンジニア紹介資料もぜひご覧ください!

セッションについて

今回は弊社のプロダクトエンジニアの古庄が
職種の境界を染み出しあう品質保証 – PdEがテストへ、QAが上流へ、AIとともに
というテーマで登壇します。 ニーリーの染み出しカルチャーの元で、いかにして双方に染み出し合いながら品質を保証しているのか、それによる変化は何か、AIはどの様に活用されているのか、など幅広くお話しできればと思っています!

ニーリーのブース出展について

現在ノベルティなどの準備を進めており、皆さんに事業/QA/エンジニアリングなど幅広くお伝えできるブースを作っていきたいと思っています。 セッションの合間や休憩時間に、ぜひニーリーのブースへ遊びに来てください。 事業の話、プロダクトの話、品質の話までざっくばらんにお話ししましょう!
なお当日は弊社QAの池端も会場にいます。ぜひぜひニーリーのリアルな話を聞きにきてください!

nealle-dev.hatenablog.com

では会場で皆様とお会いできることを楽しみにしています!!

クラウドネイティブ会議にSREチーム全員で参加しました!

こんにちは、SREチームの宇田川です。 5/14、5/15に名古屋の中日ホール&カンファレンスで開催された「クラウドネイティブ会議」にSREチーム全員で参加しました! この記事では、イベントの様子やセッションの内容を振り返ります。

会場の様子

「クラウドネイティブ会議」は、中日ホール&カンファレンスの1フロア、すべてを使い実施していました。

スポンサーブースもたくさんの企業が参加しており、休憩時間もいろんなコンテンツを楽しむことができました。 ブースに参加するとスタンプがもらえる、スタンプラリーもやっており、景品としてグッズもいただけました!

気になったセッション

ここからはSREチームの同僚に各セッションの感想について書いてもらいました!

ファインディにおけるマルチプロダクト横断の次世代ログプラットフォームの設計思想

https://speakerdeck.com/kouzyun/huaindeiniokerumarutipurodakutoheng-duan-noci-shi-dai-rogupuratutohuomunoshe-ji-si-xiang

SREチームリーダーの大木です!

Findy株式会社 原さんの「ファインディにおけるマルチプロダクト横断の次世代ログプラットフォームの設計思想」という発表がとても刺さりました。

複数プロダクトを横断するログ集約基盤の構築と、そこからそのログ集約基盤に対してBedrock AgentCoreを用いて自然言語でログをクエリできるAI Agent を作成し、Slack上でinterfaceを構築して全社に展開したという話でした。

我々ニーリーのSREも「信頼性を全員のものに」という表題を掲げてやっているのですが、社内の多くの人に使ってもらうためのスムーズな仕組み作りは常に悩みの種です そんな中、発表にあった「Slack上でインターフェイスを構築することにより、間口を下げ、使っているところを見せ、浸透させる」という話はとても良いなと感じました。 弊社でもプラットフォームエンジニアリングがより求められる状態になってきたので、「作って終わりではなく、ちゃんと届ける」ためのノウハウを吸収できた感触があり、とても良かったです。

生成AI時代に信頼性をどう保ち続けるか - Policy as Codeの実践

https://speakerdeck.com/akitok_/sustainable-reliability-with-policy-as-code

SREチームの高です!

キャディ株式会社 小林さんの「生成AI時代に信頼性をどう保ち続けるか - Policy as Codeの実践」がとても印象深かったです。

Production Readiness Checklist(PRC) のレビューが追いつかなくなってきたため、チェックリスト項目に対応するポリシーをコード化し、CI で検知できるようにした、という取り組みの紹介でした。

弊社でも PRC の運用を始めたところで、現状は SRE が、開発者にヒアリングしながら手動でレビューしている形です。我々の2〜3歩先を行く事例の共有で、「やっぱりこういう仕組みが必要だよな〜」「ウチならどうやれるかな〜」と思いを馳せながら聞いていました。

テストコード大好き人間の自分としては、Rego で書いたポリシーのコードそのものに対して、テストコードが書ける点が激アツだなと思いました。やっていきです。

そのSLO99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜

https://speakerdeck.com/vtryo/is-that-99-dot-9-percent-slo-really-necessary-design-philosophy-of-shared-responsibility-through-prioritized-slos?slide=2

SREチームの森原です!

株式会社Topotal VTRyoさんの「そのSLO99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜」が特に印象に残っています。

複数のプロダクトを抱える組織において、SRE・Devチームがどのように協業してSLOを管理をしていくのが妥当なのかというお話や、ビジネス価値を創出するためのSLOの利用方法について紹介いただきました。

弊社では、SREがSLOの管理・運用を行っている現状ですが、多くの新規プロダクトの立ち上がりに伴って、DevチームへのSLO運用の移譲や、それぞれのプロダクトのフェーズや性質に応じた最適なSLO設定がまさに必要になってきています。これらの取り組みを進める上での指針となるような考え方を学ぶことができ、大きな収穫となりました。

「OSSがあるなら自作するな」はAI時代も正しいか — Build vs Adoptの新しい判断基準

https://speakerdeck.com/kumorn5s/oss-build-vs-adopt

SREチームの久保本です。

株式会社サイバーエージェント 石川 雲さんの「「OSSがあるなら自作するな」はAI時代も正しいか — Build vs Adoptの新しい判断基準」がとても面白く、今後のOSS・技術選定などの際にも役立つと感じました。

AIコーディングで Build の実装コストは劇的に下がった一方、保守・障害対応・セキュリティ・引き継ぎといった所有コストはAIでも消えない。だからBuildアンチパターンの判定式そのものは変わっておらず、変わったのは「Buildできる領域の幅」だけ、というのが本セッションの趣旨だったと理解しています。

「Build = 所有コスト / Adopt = 依存コストの引き受け」という対比がまずわかりやすく、今後似た議論をする際にも共通言語化できるといいんだろうなと感じさせられました。 またKubeVela を 5 年前に Adopt した結果、根幹に食い込んでから OSS 側の方向性がズレてしまった、という登壇者ご自身の実体験から論が始まるので、話の重さが段違いでした。

弊社でもマルチプロダクト化の観点から、今後採用する OSS / SaaS は拡大していくのだろうと見込まれ、「タダで使えるから採用」「とりあえず Adopt」のまま定期見直しがないような状況は避けるべきだと思います。そこで今回紹介された 「コア要件 × 重要度」「結合度 × 持続性」の2軸マトリクスで採用 OSS を分析・棚卸しして、依存コストを可視化するところから手を付けてみたいと思いました。

脆弱性を削減し、安全なコンテナイメージを作るための新しいアプローチ:Hardened Container Images

https://www.docswell.com/s/tadashi0713/5N7J8W-cloudnative-kaigi#p1

そして私、SREチームの宇田川です。

Docker社の根本さんの「脆弱性を削減し、安全なコンテナイメージを作るための新しいアプローチ:Hardened Container Images」は、明日から実践出来る内容でとても参考になりました。

昨今AIの活用拡大に伴い、サプライチェーン攻撃のリスクも高まっています。 コンテナイメージも主要な標的となっており、対策が必要とのことでした。

具体的な対策として、以下が紹介されていました。 脆弱性や依存関係を最小化した「Hardened Container Images」 Docker製の安全なOSパッケージや言語の依存ライブラリを提供する「Docker Hardened System Packages」

「Hardened Container Images」への移行デモも行われ、簡単に移行できることが示されました。 大きな追加コストなく、セキュリティ対策をできるようになっているのはとてもありがたいです。

スライド内で指摘されていましたが、攻撃のリスクは利用者の慢心により放置・拡大されているものがほとんどであるとのことです。 日々の業務の徹底がリスクを最小化するということを肝に命じて、日々の業務に向き合っていきたいと思います。

最後に

多くのセッションを通じて、クラウドネイティブ周りの最新の動向や、組織や現場を持続的に改善していく実践知を学ぶことができました。

また、企業ブースや懇親会にて多くの参加者と交流したことで、セッション内では聞けない他社のリアルな取り組みや、課題感に触れることができました。

後日、振り返りを行い、自社がより成長していくためのどんなアクションが必要かを議論しました。

最後に現地の様子がわかる写真をいくつか貼ります!

1日目の懇親会ではDJブースがあり、大盛り上がりでした!

プラットフォームエンジニア募集中です!大木リーダー @2357gi までお問い合わせを!

herp.careers

会場内ではフードトラックが出店しており、名古屋名物のどて煮やおでんなどを味わうことができました!

会場の近くにサウナで有名なウェルビー栄があり、宇田川はここに泊まりました! 最高でした!!!

TSKaigi 2026 登壇とブース出展の振り返り

はじめに

こんにちは、 ARCH チームの立川です。

先日、 2026 年 5 月 22 日(金) 〜 23 日(土)の 2 日間にわたって「TSKaigi 2026」 が開催されました。今回はそのイベントについて、

  • 登壇してきた話
  • Gold スポンサーとしてニーリーが協賛し、ブース出展をしてきた話

の 2 本立てで書きたいと思います。

登壇について

今回、自分が提出したプロポーザルがめでたく採択され、「TypeScriptとAngular Signal で実現する保守性の高いアプリケーション設計 - 3層アーキテクチャによる責務分離の実践(たつかわ)」というタイトルで登壇してきました。

提出前は Angular の話かつアーキテクチャ寄りの話であることと TSKaigi は競争率高いので通るのは難しいだろうなと思っていましたが、結果的に通ってしまってびっくりしました。自分自身、初めての TSKaigi 参加でまさか登壇することになるとは...。選考担当の運営の皆さん、採択いただきありがとうございます!採択されてから登壇終了までの話をこちらで書こうと思います。

登壇日当日までの流れ

まず、登壇者の当日までの流れを順に説明していきます。次回登壇者の方の参考になれば幸いです。 プロポーザルが通ると、運営から TSKaigi の Slack への招待の連絡が届きます。ここから今後のやりとりは Slack のみで行っていきます。

次に CMS への登録を促されます。主にトーク詳細ページに表示される内容をここで登録します。タイトルと概要に関しては、プロポーザルで提出した内容から大きく変わってしまう変更は NG なので、プロポーザル提出前にしっかりと考えておきましょう。また、 TSKaigi 前日に登壇者のみが参加できるスピーカーディナーが開催されます。この出席確認も CMS 上で登録します。登壇資料については、 TSKaigi 開催後も登録可能なので、当日まで焦らずに資料を作っていきましょう(スピーカーディナー時でも登壇資料を完成されていない方が結構いらっしゃいました(笑))。

今回のスピーカーディナーは、アウトバックステーキハウス品川港南店で開催されました。立食ビュッフェ形式で登壇者や運営メンバーと気軽に交流ができます。

スピーカーディナー自己紹介票(会場の写真撮るのを忘れていてこんな写真しかなかった)

登壇資料の作り方、技術についての話、TSKaigi の運営についての話などさまざまな話を聞くことができました。特に登壇資料の作り方については登壇者ならではの話で、人によって使っているツールがさまざまで興味深かったです。その中でも deck というツールが気になったので次回はそちらを使ってみたいと思いました。

登壇日当日

ここまで来るといよいよあとは発表するだけです。 ブース出展の方でも仕事しなければならなかったので、Day1 の朝から会場に向かいました。一応、自分が発表するトラックの会場も発表前に下見しておいた方が良いなぁということで、仕事の合間に確認しに行ってみましたが...。

Leverages トラックの最後列から

広っ!予想を超える広さで緊張感増し増しでした。ただでさえ、朝からナーバスだったのに...。ブースの仕事には身が入らず、お昼休憩の時間もご飯が喉を通りにくかったです。

Day 1 14:20 からいざ登壇ということで、再び会場へ。ご視聴いただいていた方はざっと 200 〜 300 人でしょうか(前方から見たらまた違った緊張感がありました)。 わざわざ足を運んでいただいた方々ありがとうございました!10 分セッションが 3 つあるので他のセッション目当てで来ている方もいたかと思いますが、これだけの方にマイナーなフレームワークである Angular について共有できたのは感無量でした。本当にありがたい! Angular の布教活動をするという今回の目的を達成できた気がします...!スライドを一枚飛ばしてしまうなどのちょっとしたミス(?)はありましたが、なんとか無事完走することができました。

登壇時の様子
野呂さん、写真撮影ありがとうございます

いつも Angular の資料で一方的にお世話になっている lacolaco さんにも足を運んでいただきとても嬉しかったです!次の日にちゃんと自分も lacolaco さんの登壇を視聴させていただきました。

懇親会では、お互いちょっとした感想会ができて楽しかったです!lacolaco さんの「いつテストを書くか?―ソフトウェア開発における安心と不安について考える」 、すごく良い話だったので、会場に足を運べなかった方はアーカイブ動画が公開されたらぜひ観てみてください。

懇親会は参加者の数に圧倒されました

ブース出展について

登壇の部分でも少し触れましたが、ニーリーは今回 Gold スポンサーとしてブースを出展していました。2 日続けてのブース出展はニーリーでは初だったので、企画をやった方が良いのか、ノベルティは足りるのかなど色々と不安ポイントがありました。

開場前の様子

蓋を開けてみると、予想を超える数の人に足を運んでいただきました。ノベルティはフィジェットキューブというおもちゃを渡していましたが、こちらが大ヒット!

フィジェットキューブ

添付画像のようなもので、手持ち無沙汰なときに手を動かすことで気を紛らわせ、不安やイライラを落ち着かせるおもちゃです。実際に自分も登壇前にナーバスになっている時にブースで使用しており、手を動かしてカチカチ鳴らしながら宣伝していました(笑)。結構落ち着くんですよね、これ。他の登壇者の方もブースに立ち寄った際に、登壇前にこのキューブの存在を知りたかったという方も多かったです。 他のブースの関係者にも「みんなカチカチ鳴らしているから気になって来ました」と立ち寄ってくださる方が多く、隠れたところでも大ヒットしていました。

180 個のフィジェットキューブを用意していましたが、大ヒット御礼で 2 日間持たないという状況になり、急遽金曜夜に本社社員があらたなノベルティを用意する状況となりました(感謝しかないです!)。おかげさまで 2 日間最後まで完走することができました。

急遽準備いただいたアクリルキーホルダーと付箋

自分の登壇をご視聴いただいてからブースに足を運んでいただいた方も多くいらっしゃって、とても嬉しかったです。 また、以下のような嬉しい X 投稿もいただきました。ありがとうございます!そうなんです、ニーリーは「エンジニアも事業に染み出す」文化を大事にしているんです!

改めまして、ブースに足を運んでいただいた方々、ありがとうございました!

さいごに

登壇資料のレビューにご協力いただいた方々ありがとうございました!ブース出展に関わった皆様お疲れ様でした & ありがとうございます! また、 TSKaigi 運営メンバーの方々のおかげで様々な方々と素敵な交流をすることができました。ありがとうございました!

ブース撤収完了後の様子

次回は仙台!

奈良から片道6時間、スクラムフェス新潟2026に行ってきた

こんにちは、ニーリーでQAエンジニアをしている池端(@bacchiQA)です。

先週末に、スクラムフェス新潟2026へ参加してきました。 スクラムフェスへの参加は今回が初めてで、もちろんオフラインでの参加も初めてでした。 そして何を血迷ったのか、今回奈良から陸で行こうと決め?片道6時間(奈良→京都→東京→新潟)かけて行きました….遠かった....。

そして6時間かけて新潟駅に着いてやることは決めていました。ラーメンです。

ラーメン好きとしては、初新潟でラーメンを食べない選択肢はなく、参加記なのに最初のハイライトがラーメンです笑。

今回は弊社からQAの自分とVPoE菊地(@_tinoji)の2人で参加しました。 スクラムフェス新潟はQAやテスト、品質保証まわりのセッションが多いと聞いていて、ずっと気になっていたイベントです。

実際に会場に行ってみると、登壇もブースも人の熱量もすごくて、初参加でもめちゃくちゃ楽しめました。 QAとして刺さる話も多かったし、現場に持ち帰りたいこともたくさんありました。 ブースもいくつか回って、気づけばいろいろもらっていました。

※ブースでもらった戦利品(ナレッジワークさん、カケハシさん、Findyさん)

この記事では初めてスクラムフェス新潟に参加してみて感じたことを、写真多めでゆるく書いていきます。 あと、結論から言うと、来年も行きたいです(行きます)。

聞いたセッションと感想

t_wadaさんの登壇

2026年のソフトウェアエンジニアリングを考える

初めて生でt_wadaさんを見れて勝手にテンション上がってました笑!

そしてt_wadaさんのセッションは、いくつかの「負債」の話が出てきて、テストでも普通に起きているなーと思いながら聞いていました。

技術的負債は昔からよく聞く言葉ですが、AIの登場によって認知負債という話が出てきて、さらに意図負債にも分けられる(意図負債は初めて聞きました)。 前までは人間たちの理解が先行していて、コードがその理解についてきていない状態だったのに対し、今はAIによってコード生成のスピードが先行して、人間の理解が追いついていない状態が起きている。

認知負債が溜まるとMTTRにも影響がでるのも納得感がありました。 人間が理解していない状態だと原因特定、影響範囲、暫定対応・ロールバック判断、検証、全てにおいて時間がかかる可能性がある。 なので去年一度断念したMTTR可視化に再チャレンジしてみたいと思います。 個人的には認知負債も可視化してみたい....ただ、今のところ理解の乖離を測るメトリクスはないのでそこから作っていかないと....!

あと、最後の「思考は外注できるが、理解は外注できない」という言葉も痺れましたね…。

AIに考える手伝いをしてもらうことはできる。 でも、理解することまでは任せられない。

AI時代だからこそ、作ること・テストすることのスピードだけではなく、チーム全体がちゃんとプロダクトを理解できているかを見ていくことも大事になりそうだなと思いました。

speakerdeck.com

ブロッコリーさんの登壇

「QA=テスト」「シフトレフト=スクラムイベントの参加者の一員」の呪縛を解く。アジャイルな開発を止めないために、10Xで挑んだ「右側のしわ寄せ」解消記

セッション聞き終わって思ったこと・印象に残っていること、

  • 「V字モデルの右だけ頑張っていないか?」
  • 「シフトレフトしているって具体的に何をしているか説明できるか?」
  • 「なんちゃってシフトレフトになっていないか?」
  • 「ちゃんと開発内容を理解しよう、要件のWhyや実装のWhyまでちゃんと理解しよう」

できている部分、できていない部分もあり、かなり刺激的でしたね。 特に試したいと思ったのが、Unit TestでQAが一緒にテストパターンを洗い出すところです。 この工程で、開発者自身も「何を、どこまで、どうテストするのか」の認識をQAと合わせられるのはいいなと思いました。

speakerdeck.com

miiさんの登壇

AI時代に越境し、組織を変えるQAスキルの正体

恥ずかしながらAXの意味もわからない状態で聞き始めましたが、当日一のパワーワードが出たと思っています。 「人の可能性を信じている人が広めればいい」、なかなか出てこないですよね....。

普段QAとしてやっていることが組織変革にもつながる話も良かったのですが、個人的には葛藤の話がすごく好きでした。

  • AIで生産性が上がっても、仕事が減るわけではない
  • むしろ余白ができた分、新しい仕事が増える
  • 昨日まで良いと思っていたやり方が、すぐに古くなる
  • 部門や職種によって温度感も違う

推進活動は外から見るとキラキラした話しに見えがちですが、実際にはこういう泥臭い活動も必要になってくる。 人の不安や抵抗感に向き合ったり、業務の現実に合わせたり、それぞれの正義に歩み寄ったりする必要がある。 このあたりは、すごく印象に残っています。

あと、「キャリアは計画するものではなく、越境した先に見えるもの」という話もかなり印象に残りました。 AI時代、技術も役割もどんどん変わっていくかもしれないなかで、キャリアをきれいに計画するのはたぶん難しい。 自分もQAという軸は持ちつつ、越境しながら経験と引き出しを増やし、AI時代におけるQAの価値を自分自身でもアップデートしていきたい。 そんなことを考えさせられる登壇でした。

speakerdeck.com

teppeiさんの登壇

反復開発の中で、探索的テストをどう実施しているか

探索的テスト、ふわっとしがち問題。

最初のここで「わかる〜」ってなりましたね笑。 探索的テストをちゃんと理解して、目的を明確にしないと、「適当に触る」、「テストケースと同じ内容をなぞっているだけ」、「時間があれば見る」みたいになりやすい。

ニーリーでも探索的テストは行っているが、基本的にはQAのみで実施しています。 今思うと二ーリーの探索的テストは経験のあるQAの勘所にもけっこう依存しているのかなと思っています。

  • ドメイン知識がある
  • 仕様に詳しい
  • 過去の不具合、実装者の考え方、過去の経緯を知っている

だからこそ「ここ怪しそう」「この組み合わせは見た方がよさそう」と思える。

もちろん、それ自体はQAの強みだと思うが、その勘所に頼りきると、どうしても属人的になりやすい。

探索的テストを「QAが触る時間」で終わらせずに、何を見たのか、なぜそこを見たのか、何がわかったのかをチームで残していきたいなと思いました。

speakerdeck.com

感想会

スクラムフェス新潟に参加して終わり、ではなく、後日一緒に参加したVPoE菊地と感想会もしました。

今回はFigJamを使って、聞いたセッションで印象に残ったことや、ニーリーに持ち帰れそうなことをざっくり出していく形でやりました。

こういうイベントは、現地ではめちゃくちゃ刺激を受けるのですが、帰ってしばらくすると普通に日常に戻っていきがちです。 聞いたことを自分たちの現場にどうつなげるかまで考えて、初めて参加した意味が出てくると思っているので、ちゃんと時間を取って振り返れたのはよかったです(2人だと寂しい…..笑)。

参加して終わりではなく、

  • 印象に残ったことを言語化する
  • よさそうだと思ったことを少し試してみる
  • 誰かに共有して、会話のきっかけや気づきにする

そこまでやって、ようやく自分たちの現場につながっていく気がしています。

おわりに

最後に新潟で撮った写真をいくつか。

ネットワーキングパーティーでのごはん

2日目のお昼ごはん。新潟のお米美味しすぎた

妻へのお土産(自分はお酒飲めない)

QAとして刺激を受けるセッションが多かったですし、現地でしか感じられない空気もありました。 登壇者のみなさん、運営のみなさん、現地で話してくださったみなさん、ありがとうございました!

来年は空から行きたいと思います!笑。

ついに決定!ニーリーの次期バックエンド開発言語はKotlin!

はじめに

結局この記事の後編を書いていない野呂です。

ところで、これまでバックエンドの開発には一貫してPythonを使ってきたニーリーですが、この度、共通基盤において新たな言語を採用することになりました。

nealle-dev.hatenablog.com今後は絶対にPythonは使わない!というわけではなく、むしろPark Directのバックエンドの中心は引き続きPythonなのですが、採用状況や時流、会社・事業のフェーズ感などを考慮した結果、その新しい言語を中心に使っていくことになりました。
別にもったいぶる訳ではないですが、あえて意思決定を順を追って紹介した上で、どの言語を選定したか紹介したいと思います。

技術選定を行う理由

では、具体的に何故わざわざ別の言語を使うのかを書かせていただきます。

前提として、Pythonは万能で良い言語です。
ここのところ型のサポートが手厚くなってきていて、書きやすさも向上しています。
その上で何故別の言語を選ぶのかというと、以下の理由が大きいです。

ニーリーのエンジニアは基本的に静的型付け言語の経験が厚い。

ニーリーの作るサービスはドメインロジック(仕様)が複雑になりがちなので、表現力の高い堅牢な型が求められている(と僕は確信し)ました。

そこで「静的型付け言語を使いたいに違いない」という前提を元にアンケートを実施しました。その時最初に挙げた候補は以下でした。

  • Rust
  • Kotlin
  • Java
  • TypeScript
  • Go
  • Python
  • Ruby
  • 静的型付け言語であればなんでもいい
  • 動的型付け言語であればなんでもいい

結果、総得票数圧倒的一位は
「静的型付け言語であればどれでも良い」
でした。 元々アンケートだけで選定するつもりはなかったので、ひとまず「やはり静的型付け言語が人気そう」ということが把握できたところで、真剣に選定に入りました。

言語に求めるもの

先に挙げた通り、複雑なドメインの知識を記述できる型の表現力と堅牢さが欲しくて言語の切り替えを決意した経緯があります。
TypeScriptは型の表現力は申し分ないですが、型を活かした開発を行おうとするとスキーマライブラリやORMの管理などが煩雑になりそうなのでBFFに採用しよう、ということだけ決めてBackendへの採用は見送りました。

また、Rustについては、型の表現力も堅牢さも非常に高いですが、ライフタイムや所有権を管理することが有利に働くような開発はしばらく行われないだろうことが予想されたため、こちらも採用を見送りました。

個人的にRustは大好きですが、ニーリーの事業領域に合わないだろうな、というのが素直な感想です。BackendとFrontendで共有したいロジックが出てきた時には再び選択肢に挙がるかもしれません。

そして残ったJava、Kotlin、Goでそれぞれ、会員基盤のプロトタイプを実際に作って比較してみることにしました。

ちなみにPoC開始前の時点では次の理由で「Javaが良さそうだな」と思っていました。

  1. 近年のJavaはかなり活発に開発が進んでいること
  2. 既に「Kotlinよりもモダン」なイメージがあったこと(switch式やRecord型、パターンマッチングの導入など)
  3. JVMはJavaの都合で変化するが、Kotlinの都合では変化しないだろうと予想されるため、Javaの方が磐石ではないかと考えたこと
  4. ニーリーのプロダクトエンジニアのJava経験者比率が高いこと

4 は結構重要ですが、JavaとKotlinであれば書き味にそこまで大きな差はないだろう、とも思いました。どちらかというとJVMのチューニングのノウハウの方が影響が大きそうなので、その辺りが解っている人が多いのはアドだな、くらいの認識でした。

JVMの問題点

JVM系言語が近年抱えている問題として「Cold Startが遅い」があると思っています。FaaS的なものや、コンテナオーケストレーションに採用しようとすると、起動の遅さがネックになるシーンは意外とあります。

元々共通基盤のAPIは全て Lambda に載せる構想だったため、スケールアウトのタイミング問題だけでなく、レスポンスが遅れることが許容できるか?という観点で向き合う必要がありました。

ニーリーではその問題を、Quarkusを採用することで解決しました。Quarkusはクラウドネイティブな環境で動くことを前提にRed Hat主導で開発されているOSSで、以下のような特徴があります。

  • 起動が早い(数100ms)
  • メモリ消費量が少ない
  • Native Compileが可能
  • Reactive

実際にLambdaに乗せてみると、GraalVMでネイティブビルドしていない状態でコールドスタートでも300ms、 スタンバイ状態なら6msと爆速でした。

こうなってくると、もうDBへの接続などの方がボトルネックになってくるので、JVMに乗せたままでも十分運用できると結論づけました。どうしても困った時はSnap Startもあります。

実際PoC段階では、ネイティブビルドしても全体のレスポンスタイムに大きな差は出ませんでした。
元々ネイティブビルドされる想定で作られていることもあり、ビルド自体のハードルはそれほど高くありませんでしたが、機能が一部制限されてしまうなどがあるため困るまではJVM上で動かすことにしました。 

結果

ということで、実際に作って比べた結果、ニーリーは Kotlin を次期Backend言語として採用することになりました!

Kotlinと比べてJavaがしんどかったところとして、Lombokなどのコンパイル時にclass flieを生成する系のライブラリをLLMに認識させる手段がかなり限られていたことがありました。
人間はIntellij Ideaを使って開発すれば良いのですが、Claude Codeに認識させようとすると別途MCPを用意したり、複雑な設定を書いたりしなければならず、強めにペインを感じました。
MCPを使ってLombokを認識させる方法もあるようでしたが、それだけのためにトークンの消費が増え、tool call分開発速度が落ちるというところも採用を思いとどまらせた一因になっています。
Kotlinはその手のライブラリを使用しなくても、言語仕様として(LSPがカバーしている範囲で)効率的なコードが書けるため、LLMが意に反したコードを出力することが少なく、生産性に大きな差を感じました。

また、Kotlinと比べてGo言語がしんどかった点として(書き慣れていないからというのもありますが)nullの排除や再代入の禁止が機械的に行えず、ルールがやたら長くなりコンテキストウインドウを圧迫する、という点がありました。
妥協するとすぐに読み解きにくいコードが生成され、理解負債が大きくなりそうな予感もありました。
AIが(Genericsでなんとでもなるような場面で)すぐに interface{} を使おうとするのも個人的には許容できませんでした。この辺りはGoにとても詳しいエンジニアが揃っていれば大きな障害ではないのかもしれませんが、生憎弊社にはそこまで沢山Goを普段から書いているエンジニアはいませんでした。

一方で、「GoはディファクトになっているOSSのライブラリがあまりなく、自分たちで専用のライブラリをモリモリ作る必要があると」いう先入観があったのですが、今回のPoCの範囲では特に困らず、状況は変わってきているのかも、とも思いました。

というわけで、

  • 型の表現力が高い
  • LLMに効率よくコードを書かせられそう
  • 理解負債を小さくできそう
  • JVMに慣れたメンバーが多い

という観点でニーリーはKotlinを採用しました!

もちろん、これは言語の優劣や本質的なLLMとの親和性の話ではなく「ニーリーの今の状況にマッチした」というだけにすぎません。
もっと性能が必要になれば部分的にGoやRustを使うこともあるでしょうし、Javaの変化の度合いによっては途中でJavaに乗り換えることもあるかもしれません。

おわりに

Kotlinを使った最初のサービスである会員基盤が組み込まれた機能が、先日リリースされました 🎉
1日単位で駐車場をネットから予約できる「ワンデイパーク」で使われています!
とっても便利なので是非、友人宅への訪問、コンサートや試合観戦など日々のお出かけにご利用ください!

技術の総合格闘技でプロセスをハックする!ニーリーの「サクセスエンジニア」がFDEっぽくて面白い

こんにちは。ニーリー VPoEの菊地(@_tinoji)です。

ニーリーでは現在、マルチプロダクト化を加速するためにエンジニア採用をめちゃくちゃ強化中です。共通基盤プロダクトエンジニアとプラットフォームエンジニアに続き、ポジションの宣伝をさせてもらいます。

nealle-dev.hatenablog.com

nealle-dev.hatenablog.com

事業が急成長している & オペレーションの重要度が高い から生まれる役割

今回紹介するのはサクセスエンジニアというポジションです。ニーリー独自のポジション名なので聞き馴染みがないと思いますが、めちゃおもろポジションなので語らせてください。タイトルに「FDE」と入れて流行りに乗ろうとしている下心が透けて見えてしまいますが、読んでいただければ分かると思います(笑)

サクセスエンジニアは以下のように定義しています。

  • カスタマーサクセス(toB/toC両方)などの社内のオペレーション部門を主な対象として
  • プロダクト開発「以外」の領域で
  • 各種KPIを上げることをミッションに活動するエンジニア

ニーリーの事業には「プロダクトとオペレーションの掛け算」で価値を生み出しています。そりゃそうでしょ感がありますが、『Park Direct』はtoBユーザー(不動産管理会社様)に対しては「駐車場管理を一切しなくてもよくなる」ことを目指している、BPO的な側面も強いサービスです。必然的にカスタマーサクセスなどのオペレーション部門の質や効率は、事業ポテンシャルの1つの大きな要素になります。

オペレーションの効率化やキャパシティ向上による事業貢献の度合いが高いという特性があると言えます。

また、Park Directを始めとする複数の事業は全て急激なスピードで成長しています。このフェーズではどうしても、ユーザーや社内のニーズにプロダクト開発が追いつかないというシチュエーションが発生します。

そのため、プロダクト開発が行われるまでの間、ツールなどを作って"隙間"を埋めることの価値が大きくなります。 サクセスエンジニアのリードが「会社が急成長していないと生まれないポジション」と言ってました。本当にそうだと思います。

この2つの状況こそが、サクセスエンジニアの介在余地です。
note.nealle.com

ちなみに「カスタマーサクセスエンジニア」という役割を置いている企業も多いと思ますが、サクセスエンジニアは以下のような点で異なるポジションです。

  • 顧客を直接サポートするのではなく、オペレーションを技術的にアップデートすることで間接的に価値を届ける。
  • 顧客に対する製品導入サポートなどではなく、ツール作成や社内プロダクトの開発がメイン(開発のウェイトが極めて大きい)。

技術の「総合格闘技」でプロセスをハックする

サクセスエンジニアは社内ではよく「総合格闘技」と称されています。技術的にも職域的にも縦横無尽に動いて課題をなんとかする様をよく表していて、とても気に入っているワードです。気に入りすぎてプレーリーカードに刻みました。

技術的な広さ = Web開発の言語やフレームワークだけでなく、AI/LLM、ノーコードツールやスクレイピング、データ分析などあらゆる技術を手段にします。クラウドインフラの設計やモニタリング、DBのチューニングなどをやる機会も多く、まさにフルスタックと言って差し支えないでしょう。

職域的な広さ = オペレーション業務/プロセスをハックするには、まずその業務を深く理解する必要があります。実際にその部署飛び込んで、まずは手を動かして1次情報を得るところから始めます。定量化の設計・測定も主導し、感覚だけに頼らず数字を分析した上でストラテジーを策定。そこから課題をどう解くのかを設計してフルサイクルに開発。当然解決策が現場に定着して成果が出るまで伴走し続けます。

「プロセスをハック」した実例

ちょっとイメージが湧きにくいと思うので、サクセスエンジニアがプロセスをハックした実例を1つ紹介します。

Park Direct事業におけるオンボーディング業務の1つに「公開」というものがあります。簡単に言ってしまえば、新しい駐車場の情報を登録してPark Direct上に公開する(これを1件行うと「掲載中の駐車場」が1台増える)ということなのですが、それを実現するには多くのオペレーションが必要です。

不動産管理会社様からいただくデータは様々なフォーマットがあるのでクレジングや整形が必要で、工程数も多くミスも許されない大変な作業です。そもそもデータは紙媒体しか存在していないことも少なくありません。これを毎月膨大な量こなすので、1人が時間当たりどれだけの台数を公開できるのかという効率が事業KPIに直結します。

昨年、このオペレーションの量が課題となり、効率を数十%向上させないと事業目標に到達できないことが見えてきたタイミングがあり、サクセスエンジニアが課題解決に当たりました。

この「公開」という作業を行うために、従来ではPark DirectにCSVをインポートする機能とそれに合わせたスプレッドシート、そしてそのシートを完成させるためにGASなどで作成された複数の補助ツールが使われていました。しかしこれらの既存コンポーネントをアップデートしても「数十%」という効率化は到底不可能なので、完全に新しいツールを作成しました。

  • 複数のスプレッドシートやツールに散らばっていた情報を集約し、データの不整合を防ぐ。
  • ワンクリックでデータを反映できるようにし、投入→修正のサイクルを高速化する。
  • 顧客ごとに料金設定等のデフォルト値を保持し、手入力の項目数を減らす。

サクセスエンジニアが実際の作業にdeep diveした結果この3つのコンセプトに集約され、作られたツールはPark Direct Connectと名付けられました。現在は社内のデファクトスタンダードなツールになっています。

Park Direct Connectの画面

OSSのNocoDBでスプレッドシートライクなUIを提供し、最終的にはPark DirectのAPIを叩くことになりますが、その過程では精密なバリデーション・データ変換・ジオコーディング・キューイング・セッション管理などを行っている高度なシステムです。ミッションクリティカルなシステムなので、当然メトリクスやログの監視も導入しています。

冒頭でプロダクト開発「以外」とは言いましたが、これはどう考えても1つのプロダクトですね(笑) もちろんノーコードツールなども駆使して効率化を行いますが、ときにはこれぐらい重厚な開発も選択肢に取ります。

Park Direct Connectの構成図

Park Direct Connectにより1時間あたりの公開台数はなんと35%向上し、1ヶ月に公開できる台数が飛躍的に向上。高い事業目標の達成に大きく寄与しました。

何年も継続していた運用を大きく変える必要があったので、もちろん定着までの伴走を行った結果です(また、こういったときに素早く新しい運用に切り替えられるレジリエンスが、ニーリーのオペレーション部門の強さです)。

実際に使っているメンバーの言葉を借りれば「Park Direct Connectが無い世界なんてもう考えられない」。まさにプロセスをハックして、オペレーションのキャパシティを非連続に変革させた例です。

また、数字のインパクトを見ていただければ、開発チームなのにKPI向上が明確にチームミッションに入っていることにも違和感がないと思います。それぐらい威力を出せるチームです。

FDEとの共通点と違い

ここまで読んでいただくとタイトルに「FDEっぽい」と書いた理由が分かっていただけるかなと思います。

自分の拙い理解だと、FDE(Forward Deployed Engineer)とは「顧客の現場に入り込み、自社の標準プロダクトだけでは解決できない個別の複雑な課題を、ソフトウェアやツールの開発とその定着で解決する。足りない機能はプロダクトへフィードバックして汎用的に価値を生むようにする」役割ですが、かなりの部分でサクセスエンジニアと共通していると思います。

一番の違いは、入り込む現場が顧客なのか社内なのかという点です。

ニーリーの事業は前述の通りプロダクトxオペレーションで価値を生み出しているので、社内のオペレーションも「最前線(Forward)」の1つと解釈しています。サクセスエンジニアがコミットするのは社内なので、やったことは自社事業の強化に100%還元されるという点は大きな違いだと思います(めっちゃポジショントークです)。

FDEのようなチャレンジングな働き方をしてみたい、でもお客様と直接対面するよりも社内で価値を生み出すのが好き、そんな方におすすめです!!

herp.careers

少しでも気になった方はお気軽にカジュアル面談に!

またはやサクセスエンジニアのリードの増田へラフにDMください!