こんにちは！Grow Group広報担当のイトウです。
2026年6月27日（土）に開催された『KUSANAGIサミット2026 WordPress編』に、弊社Grow Groupのサイトプランナーリーダーのサトウさんと、バックエンドエンジニアのオガワさんがダブル登壇いたしました！
今回は、お二人が普段の制作現場で実践しているディレクションとWordPressの実装方法について、セッション内容の振り返りを共有します。
目次
セッション概要
今回のセッションタイトルは『「実装できますか？」をやめる。顧客の「Why」をエンジニアと共有し、チームで正解を創り出すWordPressディレクション』。
Webサイト制作のプロジェクトでよくある失敗が、顧客から聞いた要望の背景（Why）を伝えずに、そのままエンジニアへ「これ、実装できますか？」と機能の可否だけをパスしてしまうことです。
セッションでは、単なる機能実装の可否確認、いわば伝言ゲームではなく、顧客の背景・意図（Why）を汲み取り、専門家であるエンジニアの知見を最大限に引き出すディレクション手法について、前半はマインドの部分を、後半はWordPressを用いた具体的な事例をもとに解説していました。
ディレクションにおけるエンジニアとの向き合い方
セッションの前半ではサトウさんから「普段、サイトプランナーとしてエンジニアとどう向き合っているか」というお話がありました。
Grow Groupが掲げるミッションは「成果をもたらす、課題解決を」です。
単なるWebサイト制作の請負ではなく、顧客のサイト運用改善や、最大限成果の出る提案までを行うことを大切にしています。
そして、このミッションを実現するためには、サイトプランナーの知見だけでなく必ずエンジニアの知見が必要になる、というのが今回のセッションテーマにつながっていました。
よくある失敗：「これ、実装できますか？」
サトウさんが指摘していたのは、『顧客の要望をそのままエンジニアに「これ、実装できますか？」と聞いてしまう』という、よくあるディレクションの失敗パターンです。
一見、丁寧な確認に思えるこの聞き方ですが、実はここに落とし穴があります。
「実装できますか？」と聞かれたエンジニアは、誠実であればあるほど「できます」か「できません」でしか答えようがなくなってしまうのです。
これは決してエンジニアのせいではなく、問いかけ方の問題だとサトウさんは語っていました。
また、この聞き方を続けることで生まれる問題点として、次の3つが挙げられます。
- エンジニアの知見を引き出せない：経験やアイデアを活かせず、ただの「作業の依頼」になってしまう
- 課題解決から遠ざかる：他にやりようがあったかもしれないのに、「できる／できない」の0か1かになってしまう
- 作り手のやりがいを損なう：顧客課題に対する知見を活かせる仕事になれるはずなのに、その機会を奪ってしまう
結果として、要望された機能自体は実装できても、顧客が本当に解決したかった課題は解決できていない、という状態に陥ってしまいます。
これはGrow Groupの制作現場として、もっとも避けたい事態だとサトウさんは強調していました。
解決策：顧客の「Why」をエンジニアに共有すること
それでは、どうすればエンジニアの豊富な知見を引き出すことができるのか。
これに対して、サトウさんが出した結論はシンプルでした。
顧客の要望の「Why（意図・背景）」を、エンジニアに共有すること。
つまり、「作業を依頼する」から「課題解決のための相談をしに行く」という、認識を変える必要があるということです。
具体的には「お客様はこういう課題を抱えていて、こう解決したいそうです。技術的な観点から見て、何かより良いアプローチはないでしょうか？」というように、背景も含めて相談する形に変える。
そうすると、「それは予算的には難しいですが、〇〇という理由ならこういう機能はどうでしょうか」というように、エンジニアならではの知見を活かした第三の答えが返ってくるようになるそうです。
前提を共有することで、エンジニアは知見を活かして課題感を把握でき、プランナーは自分の知見にはない最良の提案ができ、顧客は納得感のある課題解決を受け取れる。
この好循環こそがGrow Groupがチームで実現している価値だと、サトウさんはお話していました。
よくある要望と3つの実例に学ぶ、チームで導き出す代替提案
セッションの後半はエンジニアのオガワさんが、実際にWordPressサイトで起こりやすい要望と、それに対してチームでどのように課題解決の提案を組み立てるのか、3つの事例を紹介してくれました。
実際のセッションでは今回のウェビナー用に、エンジニアのキタハマさんがオリジナルで制作したデモサイトを使いながら解説していて、とても実践的な内容で分かりやすかったです！
CASE 01：製品・サービス一覧ページの絞り込み機能
顧客からの初期要望は「クリックしたらページを更新せずにタブ切り替えしたい」「絞り込み機能もつけたい」「結果がその場で変わる軽快な検索体験にしたい」というものでした。
ファッション系大手ECサイトで見られる、ページ遷移のないインタラクティブな検索体験を、自社サイトでも再現したいという意図です。
この要望をそのまま実装すると、次のような課題が生まれるそうです。
- Ajax構成の複雑化(※)：フロントとWordPressの連携や状態管理が必要になり、条件が増えるほど複雑化し、調整・検証の工数が積み上がる
- SEO不利：カテゴリーごとのURLが存在しないため、検索エンジンがページ内容を把握しにくくなる
- 共有しづらい：URLが変わらないため、絞り込み結果を社内や取引先に共有できない
また、こうした技術的な課題の裏には「営業でも使いたい」「SEOをしっかり意識したい」というビジネス上の要望が隠れていることが多いともいいます。
だからこそエンジニアは「実装できる／できない」ではなく、「このやり方で本当に目的は達成できるか」という視点を持つことが大切とのことです。
これに対してチームが導き出した代替提案は、カテゴリーごとに独立したURLを持たせるという構成です。
ページ遷移は発生するものの、URLが存在することで、SEO・ブックマーク・SNS共有・運用性のすべてに効果を発揮します。
さらに、軽快な検索体験という当初の要望についても、キャッシュの工夫によってページ遷移が発生してもスムーズな切り替えを実現できます。
このように、要望を断るのではなく、背景にある技術的価値を翻訳して伝えることの重要性を示す好例でした。
※Ajax：Webページを再読み込みせずに、画面の一部だけをサーバーと通信して新しくする技術
CASE 02：記事一覧ページの無限スクロール
続いての事例は、コラムやナレッジブログなど、記事一覧ページのリニューアル案件です。
顧客の初期要望は「スクロールするだけで次の記事が自動的に読み込まれるようにしたい。離脱しにくいサイトにしたいから」というものでした。
SNSやニュースアプリのような、いわゆる無限スクロールの体験を自社サイトにも取り入れ、滞在時間を伸ばしたいという意向です。
しかし、この要望をそのまま実装すると、次のような運用面・UX面の課題が生まれるそうです。
- 「離脱しにくい」＝「ゴールに届く」ではない：記事が際限なく読み込まれると、BtoBサイトのゴールである問い合わせや資料請求などのコンテンツに届きにくくなる
- 表示速度の低下：読み込む記事が増えるほどDOMが肥大化し、スクロールが進むほど体感速度が落ちることがある
- 計測・改善のしづらさ：どの区間で離脱したか、どの導線が効いたかをページ単位で計測しにくく、PDCAが回しづらい
「作れるかどうかというよりも、サイトのゴールに合っているかの方が本質的に大事」と、オガワさんは強調していました。
これに対してチームが導き出した代替提案は、「もっと見る」ボタン＋ページネーションによる区切りです。
記事の表示数をあえて絞ることで、フッターや記事の合間に配置したコンバージョン導線をきちんと見せることができ、興味のある人は次のページへ自然に誘導しつつ、相談したい人は問い合わせや資料請求へとつなげられる設計です。
もちろん無限スクロールが適したコンテンツも存在するとしたうえで、「回遊性だけがメディアにおいての正義ではない。コンバージョン設計こそが、BtoBサイトではより重要になってくる」というオガワさんの言葉が印象的でした。
また、「このコンテンツはどんな目的のサイトで使われるのか」「サイトのゴールに向かって適切な機能なのか」という視点を持って向き合う姿勢が大切、と締めくくっていました。
CASE 03：投稿機能の自由度と品質維持のバランス
最後の事例は、製品情報やサービス内容を量産していくサイトの案件です。
顧客の初期要望は「投稿ページは自由度高く編集・装飾できるようにしたい」というものでした。
担当者ごとに見た目を変えたい、コンテンツごとにレイアウトを工夫したい、といった意向です。
自由度を上げすぎた結果、起こりやすい課題としてオガワさんは次の3点を挙げていました。
- 更新事故・デザイン崩れ：ブロックの追加・削除・配置を自由にしすぎると、余白のずれや画像のはみ出し、スマホでのデザイン崩れなど、意図しない見た目になりやすい
- ブランド感の喪失：ページごとにレイアウトや色使いがバラバラになると、BtoBサイトで大切なブランド感・信頼感が薄れてしまう
- 将来の保守困難：担当者や外注先が変わったとき、前任者が作った独自レイアウトを引き継げず、更新のたびにルールがブレていく
これに対してチームが導き出した代替提案が、入力フォーマットを固定するという構成です。
タイトルやリード文、画像、本文といった一部の項目は自由に編集できるようにしつつ、レイアウト・余白・カラム・色といったサイトの骨格部分は編集できないようにする設計です。
使用できるブロックの種類をあえて絞り込んだり、リストのスタイルやCTAブロックなど、よく使うパターンをあらかじめ登録しておくことで、担当者が変わっても「このパターンで作ってください」という引き継ぎが可能になります。
「自由にしすぎないことの方が、サイトの価値になる。制限する設計の方が、お客様のためにもなる」というオガワさんのまとめは、WordPress＝自由に編集できるというイメージを持たれがちな中で、非常に説得力のあるものでした。
まとめ
ここまでのレポート、いかがだったでしょうか。
『顧客の「Why」をエンジニアと共有し、チームで正解を創り出すWordPressディレクション』セッションの締めくくりとして、今回の内容を次の2点に集約してみました！
- 顧客の「Why」を引き出す：要望の背景にある意図・課題を丁寧に掘り下げ、本当に解決すべき問題を見つけるためのヒアリングを行う。
- チーム全体で提案する：課題解決に繋がるのかをチーム全体で意識したうえで、顧客にとっての本当の価値（SEO・CVR・運用効率）を共に提案する。
今回のセッションを通じて、サトウさんとオガワさんが伝えたかったのは、単なるWordPressの技術解説ではなく、顧客の本当の課題を、チームでどう解決するかという、Grow Groupが日々大切にしている姿勢そのものだったように思います。
「現状のサイトに課題を感じている」「WordPressの運用設計を見直したい」という方は、ぜひ一度Grow Groupへご相談ください。
ご要望の背景にある「Why」を丁寧に汲み取り、チームで最適な解決策をご提案いたします！
