はじめに こんにちは、バックエンドエンジニアのかがの（ @ykagano ）です。 2026/8/27（木）に「PHP Tech Talk Night ～ after phpcon 2026 ～」を合同開催しました。 本記事では、当日の登壇内容や会場の様子についてお届けします！ イベント概要 「PHPカンファレンスの熱量を次につなげる」をテーマに、株式会社viviONさま・株式会社kubellさま・ピクシブ株式会社さま・BASE株式会社の4社合同で開催し、会場は株式会社viviONさまのオフィスをお借りしました。 vivion.connpass.com BASEからの登壇 人気商品が「ちゃんと買える」をつくる — ECの負荷改善（かがの） 今回の発表では、2026年1月からチームで負荷改善に取り組んだお話をさせていただきました。 3人のチームでしたが、まず負荷テスト環境の構築に全員で分担しながら取り組みました。 そして実際の負荷改善では、ログの計測を行い、分析して仮説を立案し、対策を行った上で、負荷テスト環境での検証を行います。 この一連の流れについてイメージをお伝えできていたら嬉しいです。 speakerdeck.com 参加したメンバーのコメント meihei( @meihei ) PHPカンファレンスの開催中にイベントの存在を教えてもらい、熱量そのままに参加させてもらいました。20分のトークが盛りだくさんで、どれも面白く、学びの多いものばかりでした。 特に、PHPカンファレンスで聞いた viviON さんのレガシーコードと向き合う話（ 30年価値を出し続けているPHPプロダクト ── レガシーと向き合い成⻑する戦略 ）が面白かったこともあり、同じ viviON さん（会場提供ありがとうございます）の竹下さんのお話も楽しく聞けました。片やレガシーと向き合いながらプロダクトを成長させる戦略の話、片やボトムアップで良い取り組みを取り入れていく話。目指すゴールが同じところにあるのが良かったです。 現地で見たセッションの感想 どのセッションも学びが多かったのですが、ここではゲスト登壇いただいたセッションを、現地で X に投稿した感想とあわせて紹介します。 ことみんの登壇資料の作り方〜登壇はいいぞ〜 / @kotomin_m speakerdeck.com スライドのデザイン作りすごい 😯 #php_night pic.twitter.com/VLGy7YBQ73 — ykagano (@ykagano) 2026年8月27日 PHPプロジェクトの結合バランスを可視化する / @kajitack speakerdeck.com 強度と距離と変動性によって改善したほうがいいか分かるんだ！ #php_night pic.twitter.com/D27jAcJOcv — ykagano (@ykagano) 2026年8月27日 「楽にすること」と「楽しむこと」は違う / @soudai1025 soudai.hatenablog.com 楽したい 🫠 #php_night pic.twitter.com/oPPsjPURDN — ykagano (@ykagano) 2026年8月27日 会場・懇親会の様子 開始前の会場の様子です。とてもおしゃれなイベントスペースで、こちらの写真の右奥には仮眠スペースがありました。また後ろの方にはファミレス席やバーカウンターがありました。 各社のノベルティ置き場も用意されていました。 懇親会では軽食とドリンクを囲んで、参加者同士で交流を深めることができました。 おわりに 「PHPカンファレンスの熱量を次につなげる」というテーマのとおり、どの発表も熱量のある内容でとても楽しかったです。合同開催いただいた株式会社viviONさま、株式会社kubellさま、ピクシブ株式会社さま、そしてご参加いただいた皆さまありがとうございました！ BASEではエンジニアを募集しております。よろしければ、採用情報もぜひご覧いただけますと幸いです。 binc.jp

「だいたい○○ケースくらいですかね」の正体 テスト計画でスケジュールを立てるとき、テストケース数の見積もりはどうやっているだろうか。 正直なところ、多くの現場では「前回と同じくらいの規模感だから○○ケースくらい」「経験的にこの手の機能なら△△ケース」という見積もりが主流だと思う。自分もそうだった。 これで困るのは3つの場面。 初めての領域。 過去実績がないから「だいたい」が通用しない 説明責任。 上席に「なぜその工数なのか」と聞かれたとき、根拠を示せない 精度のばらつき。 見積もる人によって2〜3倍の差が出る 結局、見積もりの「勘と経験」の中身を分解してみたら、ちゃんと数式

こんにちは。KINTOテクノロジーズ（KTC）で、ユーザーファースト推進活動の運営に関わっているる かーびー です。 KTCでは 「ユーザーファースト」 を会社の重点方針のひとつに掲げており、社内勉強会「ユーザーに寄りそわNight!」の開催もその取り組みのひとつです。 Vol.02 のレポートに続き、今回はVol.03の内容をお伝えします。 テーマは「クイックなリサーチ」。サービスに感じた「このまま進めていいのかな」という違和感を、すぐに改善案にせず、手元にある情報から一度確かめてみる進め方です。 サービスの企画や改善に関わっていると、「この動線で、必要な情報までたどり着けるのだろうか」「説明の途中で迷う人がいるのではないか」と感じる場面があります。 こうした違和感は改善を考えるきっかけになりますが、その時点では本当に問題が起きているのか、ユーザーにどんな影響があるのかまではわかりません。 生煮えのままチームに改善案をあげたとして、関係者の立場によって持っている情報や前提が異なるため、提案に至った背景から理解を取り付ける必要があります。一定の共感は得られるとしても、関係者が多いほど時間がかかるものです。 Vol.03で取り上げたのは、この違和感と改善案のあいだに、「確かめる」を一段はさむ実践でした。 第3回の寄りそわNightでは、デジタル戦略部の上田貴弘さんに登壇していただきました。オンライン相談やVoC（Voice of Customer：お客様の声）の分析、ユーザビリティテストなどを通じて、ユーザーの声や行動を捉える業務に取り組んでいます。当日は、オンライン相談やVoCから見えてきた仮説を、新入社員とのユーザビリティテストで確かめた事例が紹介されました。 新入社員に実際のサービスを使ってもらう 今回の事例の出発点は、オンライン相談やVoCを見る中で生まれた「サービスの利用途中に、いくつかのつまずきが起きているのではないか」という仮説でした。 ただ、相談や問い合わせからわかるのは、ユーザーが言葉にした困りごとが中心です。実際の画面上のどこで手が止まり、何が理解しにくかったのかまではつかめません。 そこで登壇者の上田さんが紹介したのが、新入社員に協力してもらうユーザビリティテストでした。 入社したばかりのメンバーは、業務やサービスに関する前提知識がまだ少なく、社内では当たり前になっている言葉や流れにも、初めてサービスに触れる人に近い反応を示します。社内メンバーなので確認したい内容を共有しやすく、短い準備で実施できる。実践のしやすさも、この方法が選ばれた理由の一つでした。 もちろん、新入社員がそのまま実際のお客様を代表するわけではありません。 今回は、サービスのどこにつまずきがありそうかをまず確かめるための検証です。 テストでは、実際に画面を操作してもらいながら、利用中の発話や迷い、説明を読んだあとの反応を観察していきます。説明を何度も読み返す、次に進まずに考え込む、前の画面に戻って情報を探す。 操作の様子を追うことで、どの場面で立ち止まったのか、どの説明が伝わりにくかったのか、判断するために何の情報が足りなかったのかが具体的になっていきます。 設計上は、説明を読めばそのまま次の画面へ進める想定でも、実際には同じ箇所を何度も読み返している。反対に、作る側が課題だと考えていた箇所では、ほとんど迷いが起きていない。登壇を通して繰り返し語られていたのは、この「想定」と「実際に起きていること」を分けて見ることの大切さでした。 紹介された例のひとつが、本人確認書類の画像アップロードです。最新のスマートフォンで撮ったきれいな写真が容量の上限を超え、エラーになる。設計した時点では問題のなかった仕様でも、ユーザーの利用環境が変わることで、思わぬところにつまずきが生まれます。実際の利用を見て初めてわかるつまずきは、こうした単純なところにも潜んでいます。 エラーに遭遇した人は、そのあと撮り直して先へ進めているのか。それとも、そこで利用をやめてしまっているのか。実際の行動が見えると、次に確かめたいことが具体的になります。こうして、ひとりの違和感が、チームで確かめられる問いに変わっていきます。 オンライン相談やVoCから感じていた違和感に実際の行動が重なったことで、「使いにくそう」という感覚だけでは見えていなかった部分が確認できた。そんな事例でした。 提案の前に、同じ景色を見る 確かめた結果を、チームでどう使うのか。この話題で登壇のキーワードになっていたのが「同じ景色を見る」という言葉です。 ここでいう「同じ景色」とは、全員が同じ意見になることではありません。改善案を挟んで向かい合うのではなく、ユーザーの行動や声を真ん中に置いて、隣に並んで見る。ユーザーに何が起きていたのか。どの情報から、課題かもしれないと考えたのか。何が変われば、困りごとが解消されたと言えそうなのか。立場や役割が違っていても、まずユーザーを共通の起点にして考える、という意味です。 改善案だけが先に出てくると、受け取る側は、何を解決しようとしているのか、なぜ今扱う必要があるのかを、まず確認しなければなりません。ユーザーの行動や発言、問い合わせ、ログが先に共有されていれば、改善案への賛否を決める前に、「何が起きていそうか」から話し始められます。 直したい箇所のリストは、開発の現場ではいつも長くなりがちです。 「一部の環境で画像のアップロードがエラーになることがある」という一行の報告と、目の前でユーザーが何度も写真を撮り直し、手を止めてしまう様子とでは、同じ事実でも受け取る重みが違います。 実際の行動を関係者が一緒に見ることで、ユーザーへの影響を起点に、何から手をつけるかを話せるようになります。 最初に置いた仮説が、正しいとは限りません。確かめてみると、想定とは別の場所で迷っていたり、課題だと思っていたことが実際にはそれほど影響していなかったりもします。 それでも、見ていた事実と仮説が共有されていれば、想定と違う結果が出たときに、次に何を確認するかを考えやすくなります。 事実は、提案を通すためだけの材料ではなく、チームで次の判断を下すための材料にもなります。 今回の事例を貫いていたのは、この考え方だったように思います。 参加者から寄せられた質問 イベント後のアンケートや質問フォームには、今回の内容を実践する際に迷いそうな点について、具体的な質問が寄せられました。たとえば、次のような内容です。 「売上を伸ばす」のような大きな目的から、どの粒度まで課題を小さくして調査を設計するのか アンケートで集めた声を、設問の意図や対象者を踏まえてどう読み取るのか 集めた事実を、聞き手が判断できる量にどう整理するのか また、「ユーザー中心の視点でサービス開発を進めるには、何から始めるとよいのか」「プロジェクト名など、普段使う言葉をユーザー起点に変えることにも意味があるのか」といった質問もありました。 内容を理解して終わるのではなく、自分の業務で試すとしたらどこで迷うのか。その段階まで踏み込んだ質問が多かったことが印象に残っています。ここで挙がった論点は、次回以降のテーマを考える際の材料にしていく予定です。 まず、手元にあるものを見てみる ユーザーファーストの実践というと、大がかりな調査や専門的なリサーチから始めるもののように感じるかもしれません。 今回の事例の起点は、オンライン相談やVoCなど、すでに手元にあった情報でした。そこから気になったことを、新入社員とのユーザビリティテストで確かめる。日々の業務で生まれる「このままでいいのかな」という違和感も、事実とセットにすると、チームで検討できる問いになります。 私自身、気になることがあると、つい解決策まで一気に考えてしまいます。今回の話を聞きながら、答えを出す前に、まず何が起きているのかを一度見てみることを忘れないようにしたいと思いました。 次に何かが気になったとき、まずは手元のログや問い合わせをひとつ確認してみる。今回のレポートが、そんな一歩につながればうれしいです。 関連記事 『ユーザーに寄りそわNight!』Vol.02レポート ── my route開発チームのフィールドワーク事例 KINTO Technologiesにおけるユーザーファースト推進の取り組み 定量データと定性データを行き来する ── ユーザーインタビューわいわい会