はじめに
同じエックスサーバー株式会社が関わるWordPressテーマでありながら、CocoonとXwriteでは、ユーザーからの要望や機能改善に対する対応の速さに違いを感じます。
その理由として「開発・サポートの人手不足」が考えられますが、単純な人員数だけでは説明しきれない部分があります。
この記事では、Xwriteフォーラムでの具体的な事例と、私自身がCocoonの機能改善に協力してきた約3年間の経験をもとに、両テーマの対応状況を比較しながら、開発体制や情報共有の仕組みについて考察します。
長期間進捗が見えなかったXwriteの事例
Xwriteの対応状況を示す事例として、ブログカードに関する要望が挙げられます。
2025年3月には、ブログカードの画像表示に関する要望が投稿されています。
さらに、2026年10月にも、ブログカードに関する要望が投稿されています。
このように、ブログカードに関する要望は、2025年3月の時点ですでに挙げられていました。
もちろん、複数の投稿があることだけで、開発側がその間まったく対応を検討していなかったとは断定できません。
ただ、ユーザーから見える範囲では、同様の要望が再び投稿されており、対応状況や検討の進捗が利用者に十分伝わっていない可能性があります。
開発には優先順位や技術的な制約があり、すべての要望にすぐ対応できるわけではありません。
それでも、対応に時間がかかる場合に検討状況や今後の見通しが共有されていれば、ユーザーの受け止め方は大きく変わるはずです。
要望を受け付けることと、対応状況を適切に共有することは別の問題だからです。
Cocoonの機能改善が進みやすい2つの理由
一方、私が関わってきたCocoonでは、機能改善や不具合対応がスムーズでした。
その背景には、主に2つの要因があると考えています。
ユーザー側から具体的な情報を提供している
私はCocoonの内部構造や既存機能の仕組みを理解したうえで、単に要望を伝えるだけでなく、具体的な仕様案、動作確認済みの試作コード、不具合の発生条件などを開発者のわいひら氏に提供してきました。
こうした情報があれば、開発者は要望の意図や実現方法を把握しやすくなり、実装方法をゼロから検討する負担も軽減できます。
もちろん、提供した仕様やコードがそのまま採用されるとは限りません。
最終的な採用可否や実装方針は開発者が判断しますが、具体的な検討材料があることで、実現可能性や修正方針を判断しやすくなります。
開発者と直接やり取りできる環境がある
もう一つの要因は、仕様や実装案について、開発者と直接やり取りできる環境です。
試作コードを提示した際に、仕様の確認や実装上の問題点についてやり取りできれば、認識のずれを減らしながら検討を進められます。
要望を伝えて返答を待つだけでなく、具体的な検討材料を共有し、必要に応じて修正や検証を重ねられることが、機能改善を進めやすくしていると考えています。
Cocoonはエックスサーバー社に事業譲渡されましたが、私が関わる範囲では、現在もわいひら氏個人を中心とした開発・判断体制が維持されています。
つまり、権利や運営主体が企業に移ったことと、実際の開発・判断の仕組みが組織的に変わることは、必ずしも同じではありません。
Cocoonでの経験からは、開発者個人の知識や経験に加え、具体的な情報を介して柔軟に協力できる関係が、対応の速さを支える重要な要素になっていると感じます。
個人の知見を組織全体の開発力に生かせているか
ここで疑問が生じます。
XwriteにはCocoonの開発者であるわいひら氏も参画しているにもかかわらず、なぜユーザーから見た対応の進み方に違いが生まれるのでしょうか。
考えるべきなのは、「個人の知識・ノウハウ」と「組織としての開発プロセス」は別物であるという点です。
CocoonとXwriteでは、テーマの設計や実装が異なるため、コードをそのまま転用できるとは限りません。
しかし、仕様の明確化、不具合の切り分け、試作コードによる検証、ユーザーとの情報共有といった開発プロセス上のノウハウは、テーマが異なっても応用できるはずです。
例えば、要望を具体的な仕様に落とし込み、再現条件を整理し、実装案を検証する手順がチーム内で共有されていれば、特定の担当者だけに負担が集中することを防ぎ、ほかの開発者も対応しやすくなります。
反対に、こうした知見が個人の経験にとどまり、チーム全体で共有・活用されていなければ、経験豊富な開発者が参画していても、その能力を組織全体の開発力につなげることは難しくなります。
ただし、フォーラム上で進捗が見えにくかったという事実だけで、Xwrite内部の情報共有や開発プロセスに問題があると断定することはできません。
内部でどのような検討が行われていたのかは、公開情報だけでは分からないためです。
それでも、ユーザーから見える対応状況を改善するという観点では、要望の優先順位付け、実装方針の決定、開発者間の情報共有、進捗報告などの仕組みが適切に機能しているかを考える必要があります。
特定の開発者が持つ知識や経験を、チーム全体で活用できる仕組みがなければ、個人の能力が組織全体の対応速度に直結するとは限りません。
CocoonとXwriteの違いを考えるうえでは、開発者個人の能力だけでなく、その能力を生かすための開発体制にも目を向ける必要があると考えます。
増員だけでは解決しない、開発体制の課題
開発・サポート体制を強化するために人員を確保することは重要です。
しかし、単に人を増やすだけでは、対応速度の改善につながるとは限りません。
新たな担当者が加わっても、テーマの構造や既存機能の仕様、過去の経緯を理解するまでには時間がかかります。
また、担当者ごとに判断基準や作業手順が異なれば、確認や調整に余計な時間がかかる可能性もあります。
そのため、人員の確保と並行して、開発ノウハウを組織全体で共有・活用する仕組みを整えることが重要です。
具体的には、次の3つが考えられます。
要望を具体的な仕様や再現条件に整理する
ユーザーから寄せられた要望を、そのまま開発担当者に渡すのではなく、実現したいこと、現在の問題、再現条件、期待する動作などに整理します。
必要に応じて試作コードや検証結果も共有できれば、担当者が実装方針を検討しやすくなり、認識のずれも減らせます。
検討状況や対応方針を利用者に共有する
すぐに実装できない要望であっても、受付済み、検討中、対応予定、見送りといった状況や、その判断理由を可能な範囲で共有すれば、ユーザーは要望がどのように扱われているかを把握できます。
すべての要望について詳細な報告を行うことは難しくても、進捗が長期間見えない状態を減らすことは、サポートに対する信頼性を高めるうえで重要です。
個人の知識や判断基準をチーム全体で共有する
特定の担当者だけが把握している仕様や不具合の原因、過去の対応経緯、実装時の注意点などを、チーム内で参照できる形に整理します。
こうした情報が共有されていれば、担当者が変わった場合や新たな人員が加わった場合でも、過去の知見を活用しながら開発を進められます。
私がCocoonで行っている、具体的な仕様や試作コードを用意し、開発者が検討しやすい環境を作るというプロセスも、こうした仕組みの一例です。
この考え方は、個人と開発者との協力関係に限らず、組織内部の開発フローにも応用できるはずです。
人員を増やすこと自体を目的にするのではなく、増員によって対応できる範囲が広がったか、機能改善が以前より進むようになったか、ユーザーへの情報提供が改善したかといった、実際の運用成果に目を向ける必要があります。
おわりに
CocoonとXwriteの対応速度の違いを考えるとき、単純な人員数や開発者個人の能力だけではなく、要望を実装につなげるための仕組みや、ユーザーとの情報共有のあり方にも目を向ける必要があります。
私がCocoonの機能改善に協力してきた経験では、具体的な仕様や試作コードを共有し、開発者と直接やり取りできる環境が、検討や実装を進めるうえで役立ってきました。
一方、Xwriteについては、フォーラム上で進捗が見えにくい期間があったことは確認できますが、その背景にある内部事情まで断定することはできません。
だからこそ、今後の改善を考えるうえでは、単なる増員だけでなく、個人の知見をチーム全体で活用し、ユーザーの要望を着実に実装へとつなげる仕組みが重要になります。
開発者個人の能力を、組織全体の開発力へとつなげられるか。
それが、ユーザーの要望に継続的に応えられる開発体制を考えるうえで、重要な視点ではないでしょうか。
