Webサイトのリニューアルや運用において、その中心に立つWeb担当者の皆さんは、社内の急な要望とプロジェクトチームの制約との間で、「板挟み」になっていないでしょうか？

上司からは「もっと安く、早く、いい感じに」と詰められ、プロジェクトを共にする制作・開発メンバーからは「その仕様変更、今の工程では難しいです」と言われてしまう。良かれと思った調整が行き違いになり、気づけばプロジェクトの進行が不安定になってしまうことも少なくありません。

実を言うと、これはアカウント1年目の私が現場で実際に体験した悩みそのものでした。毎日「なんでこんなに上手くいかないんだろう」と不思議でしたが、試行錯誤を繰り返すうちにこうした混乱は個人の努力不足だけではなく、プロジェクトが「属人的な頑張り」に頼り合い、合意形成の仕組みが「標準化」されていないことから生じているのかな、と思うようになりました。

そこで本記事では、1年目の私がもがきながら先輩たちに教わり、実践の中で身につけていった、プロジェクトの認識のズレや手戻りを減らすための「型」についてお伝えします。

なぜ、プロジェクトの進行が少しずつ崩れてしまうのか？

プロジェクトのトラブルは、ある日突然起きるものではありません。初期段階の小さな「認識のズレ」が雪だるま式に大きくなり、最終的に後戻りができない大きな手戻りとなって表れてくることがあります。

1年目の私が現場で「なぜかいつも話がかみ合わなくなる…」と頭を抱えていたとき、振り返ってみると、そこには3つの共通するつまづきがあったように思います。

• コミュニケーションの分断
  「了解です」と確認をしたはずなのに、お互いの頭の中で思い描いている内容が少しズレていることは珍しくありません。最初は小さな認識の差でも、プロジェクトが進むにつれてそのズレは広がり、終盤には大きな行き違いとなって表れてしまうのです。
• 暗黙の了解という名の「放置」
  「前回と同じイメージで」「この部分は言わなくても伝わるだろう」といった曖昧な要件や暗黙の了解の下で進んでしまうことがあります。そうした状態が続くと、終盤になって「想定していた使いやすさと違う」という指摘を生む原因となります。
• 安請け合いが招く「リスク」
  何でも「できます！」と言うパートナーは、一見すると心強く思えます。実は注意が必要です。キャパシティや技術的検証を超えた安請け合いは、納期直前での品質にしわ寄せがでたり、結果としてユーザーに不便をかけたりするおそれがあります。

個人の属人的な頑張りに頼りながら、認識のズレを「まあ大丈夫だろう」と見過ごしてしまうと、終盤で大きな手戻りが発生しやすくなります。
振り返ってみると、こうした積み重ねが進行管理を不安定にする要因なのではないか、と考えるようになりました。

進行の「標準化」が、目指すべきユーザー価値を確かなものにする

プロジェクトが不安定にならないように、先輩たちの仕事ぶりを見ながら、私が少しずつ理解していったのが、個人の気合や経験だけに頼らない「標準化」という考え方でした。

ここでいう標準化とは、ガチガチの規則で縛ることではありません。私が先輩たちの動きを見ていて感じたのは、Web担当者、デザイナー、エンジニア、PMといった多職種の専門家が、一つのチームとして認識を揃え、安定してプロジェクトを進めるための土台を整える大切さでした。Business Architects（以下、BA）では、この土台を大きく「関係性」「情報」「プロセス」の3つに整理しています。

• 「関係性」の標準化（マインドセット）
  発注・受注という上下関係だけでプロジェクトを進めるのではなく、全員がそれぞれの専門性を持つチームとして認識を揃え、突発的な要望にもユーザー価値を基準としたロジカルな代替案に変えていく関係性。
• 「情報」の標準化（ドキュメント）
  言った・言わないを防ぎ、プロジェクトに関わる全員がいつでも同じ判断基準に立ち返られるようにすることです。そのための土台になるのが、見積書や議事録といった記録情報です。
• 「プロセス」の標準化（ワークフロー）
  公開直前の「ちゃぶ台返し」を防ぎ、社内の合意形成を進めながら、目指すべきユーザー体験に向かってプロジェクトを着実に前に進めるための考え方です。ルールと行っても良いかもしれません。

これらがどう役に立つのか、具体的にどうあなたを守り、仕事を楽にするのか、次章から詳しく見ていきます。

「できません」を「納得」に変える：「関係性」の標準化

Web担当者として大変なことは、社内からの急な要望と、プロジェクトにおける「品質と検証の時間を考えると難しい」という制約の板挟みになることではないでしょうか。

たとえば、上司から「急きょキャンペーンが決まったから、特設ページの制作を3日後までに終わらせて！」と無茶振りな依頼をされたとします。スケジュール的に厳しいことをそのまま上司に伝えると「ちゃんと交渉したのか？」と言われ、制作会社側に無理を通そうとすれば品質にしわ寄せが出る。そんな板挟みの難しさは、私自身も打ち合わせの中で何度も感じてきました。。

かつての私は、こうした無理なスケジュールに対して、どう向き合って解決すればいいのか分かりませんでした。ただ「3日後なんて物理的に不可能なのに、どうするんだろう…」と戸惑うばかりでした。
そんな私に当時の先輩が教えてくれたのは、「突貫作業で無理に押し通しても、最終的に品質が落ちてユーザーにしわ寄せがいく。だからこそ、プロとして『これなら安全に価値を届けられる』という代替案をチームで考えることが大切だ」という向き合い方でした。

では、こうした場面で、関係性が整ったチームはどう対応するのでしょうか。

ただ「できません」と突っぱねるのではなく、「上司の『3日後の開始日に間に合わせたい』という目的を、品質を落とさずに実現するためにはどうしたらよいか」をチーム全員で考えます。そして、技術的・デザイン的な視点から見えてきた解決策を、上司が納得して判断しやすい「選択肢」へと整理して提示するのです。

Q（品質）S（速さ）C（量）の3軸での代替案提示

私自身も、要望をそのまま受け取るのではなく、いったんいくつかの軸に分けて考えることが大切なのだと、少しずつ学んでいきました。私のチームでは、主に次の3つの観点から整理し、代替案を考えています。

• Q：技術（品質）の転換
  「デザインをゼロから作り直すと検証時間が足りませんが、既存の共通コンポーネントをベースにすれば、品質を担保したまま納期に間に合わせられます」
• S：スケジュール（速さ）の可視化
  「どうしても全体を3日後までに公開する場合、事前の表示確認や動作確認の時間を削ることになります。不具合のリスクは高まりますが、その前提で進めても良いか、あるいは安全を優先して公開日を数日後ろにずらせないか、判断が必要です」
• C：スコープ（量）の分解
  「3日後の開始日に合わせて、まずはメインの申し込みページだけを先行公開しませんか？残りの詳細ページは、その2日後に順次公開していくスケジュールであれば、ユーザーへの動線を確保しながら対応可能です」

ただ「できません」と突っぱねるだけでもなく、「なんでもやります」と無理な安請け合いをするのでもない。「この条件なら、安全にユーザー価値を守れます」とチームで考えた根拠をもとに代替案を提示することが大切なのだと学びました。

もちろん、1年目の私がすぐにこれを実践できたわけではありません。それでも、アカウントという窓口の立場として、制作・開発メンバーの知恵を借りながら「こんな進め方はどうでしょうか」と上司に相談することを少しずつ意識するようになり、上司からも「なるほど、じゃあ今回はこの進め方でいこう」と以前よりも前向きに受け止めてもらえる場面が増えてきたように感じています。

見積書と議事録を「ブレないプロジェクトの防波堤」にする：「情報」の標準化

次に、「情報」の標準化です。

見積書や議事録を、ただの事務手続きの書類だと思っていないでしょうか。私自身、最初はそう感じていましたが、こうした記録があることで、プロジェクトの認識が揃いやすくなり、結果としてユーザーにとって必要な価値に集中しやすくなるのだと学びました。

見積書を「判断材料」に変える

上司に見積りを出して「高い！」と一蹴されてしまうのは、金額そのものというより、判断材料が足りないからなのではないか、と感じるようになりました。私のチームでは、見積書を出す際、ただの金額の一覧ではなく、「何のための費用なのか」「どこまでを含むのか」「どういう前提で成り立つのか」を整理する資料として扱うようにしています。

例えば、次のような観点です。

• Budget（予算）：
  1つの案だけではなく、松竹梅など複数のプランを提示し、何にどの程度のコストをかけるのかを選びやすくします。
• Authority（決裁権）：
  上司やその先の決裁者に説明しやすいよう、社内説明用の「比較表」を先回りして整理しておきます。
• Needs（目的）：
  単に「Webサイトを作る費用」ではなく、「何の課題を解決するための費用なのか」を明確にして、プロジェクト後半でのブレを防ぎます。
• Timeline（納期）：
  品質検証の期間や修正を含め、無理のない現実的なスケジュールになっているかを最初に共有します。

さらに重要なのが「除外事項（やらないこと）」を明記しておくことです。
「ここから先は追加の検討が必要になります」という線を最初に引いておくことは、冷たさではなく誠実さだと私は感じています。そうしておくことで、プロジェクト後半になって想定外に仕様が膨らむのを防ぎ、本来集中すべき予算とリソースを、本当に必要なユーザー機能へと集中させることができます。

議事録を「ロードマップ」に変える

私も最初は、議事録は単なる「会議のメモ」だと思っていました。 でも実際には、関係者の認識を整理し、あとから話が迷子にならないようにするための土台になるのだと学びました。 議事録は、関係者間の合意形成を整理し、プロジェクトが後から迷子にならないための「ロードマップ」に近いのかもしれません。

• 「未決定事項」「継続検討事項」の可視化
  「誰が、いつまでに持ち帰って判断するのか」を明確にしておくことで、宿題が宙に浮いたり、タスクのボールが落ちたりするのを防ぎやすくなります。
• 「不採用になった理由」の記録
  「なぜA案ではなくB案にしたのか」の経緯を残しておくことも大切です。これが残っていないと、後から事情を知らない社内から「なんでこの案にしたの？」と聞かれたときに、ブレずに説明ができません。
• 形容詞を「共通言語」に翻訳する
  「もっとキラキラさせて」「なんかシュッとさせて」という曖昧なフィードバックはそのままチームに流しても伝わりません。たとえば、「彩度を上げる」「グラデーションを調整する」といった形で意図を具体的に言い換えることで、認識のズレを防ぎます。

こうした内容を、ミーティングの翌営業日までを目安に共有し、記憶が鮮明なうちに認識のズレを埋めていく。こうした積み重ねが、プロジェクトを軌道から外さないための助けになるのだと感じています。

成果で社内に応える：「プロセス」の標準化

紆余曲折を経る中で、私が少しずつ実感するようになったのは、Webサイトを無事に公開することだけがゴールではない、ということでした。

本当に大切なのは、新しくなったWebサイトの先にいるユーザーが、「使いやすくなった」「便利になった」 と価値を実感してくれることです。そして、その成果がきちんと社内にも伝わり「今回のプロジェクト、よくやったね」「成果につながったね」と、中心に立って進めてきたWeb担当者の方が評価される。この順番こそが、本来あるべき姿だと考えるようになりました。

そのためには、日々の進め方そのものを整えていく必要があります。私が所属するチームでも、合意形成のプロセスをできるだけ整理し、上司や決裁者が判断しやすい形で情報を渡せるように工夫しています。

上司（決裁者）の視点を先回りする

• 「社内報告用サマリー」の作成支援
  上司への進捗報告や承認をもらうための資料を、Web担当者の方がゼロから作るのは大変です。私のチームでは、施策のメリット・デメリット・リスクを簡潔に整理し、そのまま上司に共有しやすい形のテキストやスライドを用意しています。
• リスクの「先回り」提示
  「スケジュール通り進んでいますが、来週の社内確認が長引くと、公開が1週間遅れるリスクがあります」といったように、起こりうる懸念点を先に共有し、対策とあわせて伝えることも意識しています。そうしておくことで、不測の事態が起きても、担当者の方が社内に対して「すでに手を打っています」と説明しやすくなります。

Web担当者の方の「社内説明の負担」を下げることで、プロジェクトを本来の目的へと前進しやすくなる。それこそが、プロセスを標準化する本当の意味なのです。

まとめ：心強い「伴走者」として

アカウント1年目の私は、日々のやり取りを見ながら、「なんでみんな、一度決まったことをこんなに何度も蒸し返すんだろう？」と、不思議に感じていました。

でも、振り返ってみると、それはメンバーの記憶力が悪いわけでも、やる気がないわけでもありませんでした。ただ単に、プロジェクトの中に情報を整理し、合意形成を支える仕組み＝「標準化」がなかっただけだったからだと思います。

標準化によって、「無駄な言った・言わない」の確認や、突発的なトラブルに振り回されにくくなり、 心に大きな「余裕」が生まれます。その余裕があって初めて、Web担当者の皆さんは「これからこのサイトを使って、どうビジネスを成長させるか」という、本来向き合うべきクリエイティブな仕事に時間を割くことができるようになります。

Business Architectsでは、この「標準化」の思想を何より大切にしている会社です。私たちは、単なる制作ベンダーではありません。情報の交通整理を徹底的に行い、専門チーム間の認識を揃え、ユーザー価値に向けてプロジェクトを前に進めるビジネスのパートナーです。

プロジェクトを「成功の定型」へと導き、ユーザーに納得の価値を届けるために。Business Architectsは、あなたの心強い伴走者として、いつでもお待ちしています。

もし、現在のプロジェクト進行に不安や課題を感じていらっしゃるなら、ぜひ一度私たちBusiness Architectsにご相談ください。まずは、いま抱えている小さなお悩みからでも、お気軽にお問い合わせいただければ幸いです。