デザイン・開発・プラットフォームの3社座組で、認識齟齬と手戻りを防ぐ方法——あるECサイト構築案件で起きたことと、その学び
目次
合意したはずなのに、後からズレる
ひとつのプロジェクトに、デザインを担う会社、実装を担う会社、土台となるプラットフォームの提供元。立場の違う三者が並んで走るプロジェクトは、いまや珍しくありません。EC構築でも、業務システムでも、SaaSを基盤にしたプロダクトでも、複数社で分担する座組は一般的になっています。
関係者が増えるほど、認識を揃える難易度は上がります。デザインは仕上がっている、実装も進んでいる、プラットフォーム側も「できます」と言っている。それぞれが正しく仕事をしていても、組み上げてみるとデザインと実装の間に差異が生まれ、その修正に想定以上の時間がかかる——複数社の座組では、めずらしくない話です。
私たちが担当したあるECサイト構築案件も、この構造に近いものでした。デザインは別会社が担当し、実装を私たちが、基盤は外部のECプラットフォームが提供するという三者の座組です。実際に、デザインとコーディングの間に差異が生まれ、その部分の修正に当初の見積もりを超える工数がかかりました。さらに、プラットフォーム側に仕様をレビューしてもらい「実現可能」という回答を得ていたにもかかわらず、作り始めると実装上どうしても成立しない箇所が見つかる、という事態も起きました。
本稿では、この案件で実際に起きたことと、そこから得た学びを軸に、複数社の座組で認識のズレにどう向き合うかを整理します。
ズレは「人」より「会社の境界」に落ちる
複数社が絡むプロジェクトのズレを「コミュニケーション不足」の一言で片づけると、何をどう変えれば防げるのかが決まりません。感情的なトラブルとしてではなく、理想と現実のギャップとして構造的に捉えることで、はじめて手の打ちようが見えてきます。
複数社の座組で起きるズレは、個々の担当者の能力よりも、会社と会社の「境界」に落ちる論点を誰が引き受けるかが曖昧なことに起因します。今回の案件で実際に表面化したのは、次の二点でした。
ひとつは、デザインと実装の差異です。デザインを別会社が担当する座組では、デザインの意図が実装可能な仕様として正確に伝わらないと、実装側の解釈との間に差が生まれます。今回も、デザインとコーディングの間に差異が生じ、その修正に想定以上の時間を要しました。デザインの意図は、実装可能な仕様に翻訳されてはじめてコードに正しく落ちます。その翻訳を担う役割が曖昧だと、こうしたズレは起きやすくなります。
もうひとつは、「実現可能」という回答の粒度です。今回、プラットフォーム側にレビューを依頼して「実現可能」との回答を得た仕様が、実装段階で成立しない箇所を含んでいました。原因のひとつは、プラットフォーム側のレビュー時点での見落としにありました。「できます」という回答が、機能としての存在を指すのか、いま作ろうとしている具体的な仕様での実装可否を指すのかは、受け渡しの過程で曖昧になりがちです。前例のない機能を使う場合は、なおさら注意が要ります。
加えて今回は、見積もり時点での工数算出にもずれがあり、診断ページの動作テストが当初の想定より多く発生して工数がかさみました。つまり、デザイン側・実装側・プラットフォーム側・見積もりという複数の接点に、それぞれ小さなずれの種があったことになります。
複数社の座組で繰り返し起きるパターン
初回の認識合わせが全体像の確認にとどまり、画面単位・要素単位の細かい挙動まで踏み込めていないと、それが後のズレの一因になります。会議の記録で「合意した」とされた事項が、確定仕様なのか検討中の方針なのか区別されていないと、各社で受け取り方が変わります。
プラットフォームの「できます」を実装可能性の保証として受け取ってしまう。可否を確認した相手と、実際に詰まったときに技術的に解決する責任を持つ相手が異なる。リモート・非同期の体制では、対面なら気づけたはずの違和感が、表面化しにくい。こうした点も、複数社の座組ではつまずきやすいところです。
これらは、特定の担当者の不注意というより、複数社の座組には境界の論点を引き受けるディレクションが必要になるという、構造の問題でした。
ディレクターは「管理者」ではなく「ブリッジ」
では、境界に落ちる論点を、誰がどう引き受けるのか。Enlytでは、ディレクターを上から進捗を管理する人ではなく、クライアント・デザイン・実装・プラットフォームをつなぎ、曖昧な相談を実行可能な形に翻訳し、立場の違う関係者の認識を合わせる「ブリッジ」と捉えています。今回の案件で取った対応も、この考え方に沿うものでした。具体的には、次のような動きです。
- ただコーディングするのではなく、デザインの意図を一つひとつ、要素の挙動など細かい部分までデザイナーに確認しながら実装を進めました。診断ページは、ロジックの構築とフロント部分の実装を同時並行で進めました。
- 「実現可能」とされた仕様が実装段階で崩れたときは、仕様や方向性を各社で議論し、実現可能な形への仕様変更・実装方法の調整を行いました。あわせて、技術課題に対応するため、テックリードに一時的にメンバーとして参加してもらいました。
- デザインと実装の差異の修正には、他案件を調整してリソースを確保し、対応にあたりました。
- テスト工数の超過には、社内メンバーの協力で対応しました。動作テストが見積もり以上に多く発生したため、全テストを期間内に完了させています。
これらの判断の背景には、おおまかなリリース時期が決まっており、スケジュールを守りつつ動くものを作る必要があった、という事情があります。結果として、大幅な遅延なくリリースすることができました。
この案件から私たちが得た学びは、主に二つです。ひとつは、前例のない案件内容に対しては、工数やリソースの想定をより厚く持っておくこと。もうひとつは、コーダーのスキルに応じたアサインを考慮することです。今回、プラットフォーム上での開発もその機能の利用も初めてで、見積もりや実装の難所を事前に読み切れなかった面がありました。この経験は、前例の少ない領域では上流での想定をどこまで厚くできるかが効いてくる、という教訓として残っています。
ただし、こうした境界の引き受けを、ディレクター個人の目配りだけに頼ると、担当が変われば再現できない属人的な対応になってしまいます。Enlytでは、個人のブリッジに加えて、PMOという仕組みでこの引き受けを支えています。週次のヒアリングでリスク（まだ起きていない懸念）と問題（すでに起きた事象）を切り分け、「実現可能」とされた仕様のように曖昧さの残る論点を早い段階で拾い、火種のうちに議論の場へ載せる。前例の少ない機能を扱う場面では、可否確認の粒度をPMOのレビュー観点でもう一段詰めておくことが、後工程の手戻りを減らすことにつながります。
Enlytのチームには日本人だけでなくベトナム人メンバーも含まれ、リモート・多拠点でプロジェクトを進めています。文化差や価値観差がある体制では、「察してもらう」前提に頼れません。どこを明文化し、どこを可視化するかを、あらかじめ設計に織り込んでおく必要があります。
着手前に揃えておきたいこと
最後に、ここまでの内容を踏まえて、着手前に押さえておきたい観点を挙げます。自社の進め方に合わせて取捨選択してください。
役割と境界については、着手前に次の点を確認しておきます。デザインの意図を実装仕様に翻訳する役割を誰が担うのか。各社の責任範囲はどこからどこまでで、その「あいだ」の論点は誰が引き受けるのか。
プラットフォームの可否確認では、次を押さえておきます。その「できます」が機能の存在を指すのか、具体的な仕様での実装可否を指すのか。回答した相手は、詰まったときに技術的に解決する責任も持つのか。自分たちの作りたい仕様に翻訳し直して確認したか。前例のない機能を使う場合は、ここを丁寧に詰める価値が特に大きくなります。
会議の記録については、決定事項と検討事項を分けて残すこと、そして「合意した」とされた事項を関係者全員が同じ理解で合意しているか確認することが、ズレの防止に効きます。
さらに、これらの確認を個人の注意力に委ねず、仕組みとして回す観点も挙げておきます。週次のヒアリングでリスクと問題を切り分けておくと、「実現可能」とされた仕様の崩れのような兆候を、火種のうちに拾いやすくなります。また、ある案件で見つかったズレの型、たとえば前例のない機能における可否確認の甘さを、その案件限りの教訓で終わらせず、横展開して他案件のチェック観点に組み込んでおくと、同じズレの再発を組織として防げます。あわせて、エスカレーションの基準（どの段階で、誰に、何を上げるか）を先に決めておくことも、境界の論点を一人で抱え込まずに前進させる助けになります。
これらに共通するのは、何を・どのタイミングで・誰と・どの粒度で・どう明文化するかを、プロジェクトの早い段階で決めておく、という考え方です。
ディレクターの価値は、境界を引き受けられるかにある
複数社が並走するプロジェクトで難しいのは、それぞれの会社の仕事そのものよりも、その「あいだ」です。会社と会社の境界に落ちる論点を、誰かが自分の担当として引き受けない限り、小さなずれは静かに溜まっていきます。
今回のECサイト構築案件でも、デザインと実装の差異、「実現可能」とされた仕様の崩れ、テスト工数の超過といった、境界や見積もりに生じたずれに、その都度向き合う必要がありました。私たちが行ったのは、デザインの意図を細かく確認しながら実装し、問題が起きたら各社で議論して実現可能な形に調整し、テックリードや社内メンバーの協力でリソースを確保して、スケジュールを守りながらリリースにつなげる、という対応です。
Enlytが考えるディレクターは、進捗表をきれいに保つ管理者ではなく、曖昧さを減らし、期待値を揃え、関係者の境界をつなぎ、前進を設計する役割です。そして、その引き受けを個人の力量だけに残さず、PMOや標準化された運用を通じて、同じ進行品質を組織として再現できる状態にしておくことまでが、その役割に含まれます。今回の案件で得た「前例のない領域では上流の想定を厚くする」「スキルに応じてアサインを考える」という学びも、その役割を次にどう活かすか、という問いの一部だと考えています。
複数社の座組での進行に、ひとつでも心当たりがあれば
認識齟齬で手戻りが起きる、進め方が見えず不安になる──複数社の座組では、こうした詰まりが起こりがちです。Enlytは、受注前整理から進行設計まで、デザイン・開発・プラットフォームの「あいだ」を引き受けながら、”使われ、成果につながるプロダクト”へと伴走します。複数社での進行に少しでも不安があれば、お気軽にご相談ください。
