Step 2-19 監修者に聞きました：サイト制作あるある

Web担ビギナーの目次を知りたい方はこちら

今回はStep2の最後にあたり、これまで多くの項目を監修してくださっているキノトロープの濱田 優さん、濱 大洋さんにお話を伺いました。キノトロープさんは、Web担当者Forumの人気連載「Web担当者に喝！」を執筆してくださっていた生田昌弘さんが代表を務められている会社。これまで、1,000社以上もの企業サイト構築の実績をもっています。

制作プロジェクトを成功させるために、さぞかし数々のご苦労、工夫をされているに違いないと思い、2-16でも取り上げた「制作開始前の社内調整」の実例を中心にお話を伺いました。

転職して、Web制作の仕事に就きました

―― Webの仕事に関わるようになったキッカケから教えてください。

濱田 優さん（以下、濱田）：私はいろいろなビジネスをやってきましたが、音楽系の事業を立ち上げたときがあって、そのビジネスではWebサイトの問合せからの受注がメインだったんです。Webページが作れなかったので外注していましたが、キャンペーンがしたいときや文言を修正したいときには、その度に見積が必要で、ニュアンスが伝わらないもどかしさも感じていました。そこで、自分でサイトを作り上げることができたら、自分の考え、想いがすぐに形になるんじゃないか、と未経験でプログラムの会社に入ったんです。

プログラミングをゼロから学びながら仕事をするうちに、「Webの奥深さ」を知りました。それと、自分でビジネスをやっていたときに完璧ではなかったという思いもあって、「ビジネスの本質をみたい」と考えていました。それで、クライアントさんのビジネスに関われるコンサルティングもでき、これまでの自分の知識も活かせるキノトロープに転職したんです。現在は、システムコンサルタントとして、システム的な知見とビジネス的な知見の２つを合わせて、事業会社さんの問題解決を行っています。事業会社側だったときの「もどかしさ」を知っているので、クライアント企業に寄り添うよう心掛けています。

濱 大洋さん（以下、濱）：キノトロープに入る前は、アパレル系のOEMの会社で企画営業をしていて、服のデザインを描いて生産管理までやっていたんです。Webとはまったく関係のない仕事でしたが、趣味で服を作っていたので、それを売るために個人でWebサイトを作り始めて、「Webの面白さ」を知りました。それで、もっとWebの仕事がしたいと思ってキノトロープに入ったんです。

ぼくにはプログラムができるといったバックボーンはないので、入社したときからディレクターとして働き、今はプロジェクトマネージャーとして、クライアントさんへのヒアリングから制作までの全工程をとりまとめています。

社長や役員にダメ出しされないために＿役員会、報告会などで、細かく中間報告を行おう

―― ではここからは、これまでのご経験で制作中にご苦労された事例、印象に残っている事例をお聞きしていきたいと思います。たとえば「Step2-16 制作前の社内調整」では、社長から「いきなり結論をもってこられても、判断できないよ」とダメ出しされるという例を出しましたが、そのようなご経験はありますか？

濱：社長ではないんですが、ローンチ直前の役員会での報告で、プロジェクトに入っていなかった役員の方から「変えてほしい」といった意見が出たことがありました。キックオフ前に体制面の調整や確認は念入りに行って、「誰がOKならOKとするか」というところは詰めていたんですが、役員会で「待った」が出てしまいました。大企業では縦割り組織の壁もありますから、役員会の動きも確認することが重要ですね。ですから現在は、役員会で細かく中間報告をあげてもらえるよう、働きかけています。

それと、後からいろいろな意見が出てきそうな方を巻き込むことも重要です。要件定義の終了、デザインの終了といった、大きなマイルストーン（工程の中で節目となるポイント）のタイミングで、そうした方々にも参加していただいて、承認の報告会をやらせてもらったりもします。

ただし、会社によって事情は異なりますから、細かく画一的な対応ルールを決めるのは難しいです。事業会社の担当者の方と密にコミュニケーションをとりながら、その会社に合わせた対応をすることがプロジェクトマネージャーであるぼくの仕事だとも言えますね。

いきなりリニューアル担当者になって困った＿プロに相談してみよう

濱田：プロジェクトが止まってなかなか先に進まない原因には、現場の担当者たちの士気が上がらず、足並みが揃わないということもあります。経営層からの依頼で「リニューアルをしよう」ということだけが決まっているものの、担当者の方々には現状が伝わっていない、何から進めればよいかわかっていない場合があります。

そういう時には、外部のコンサルタントに依頼して、プロジェクトのゴールを一緒に考えるところから始めるとよいと思います。たとえば私たちはゴールとそれを成功させるともたらされるメリットを一緒に模索し、社内での説明用資料を用意したり、ときには代わりにプレゼンを行ったりもします。一人で悩まずに、コンサルタントや制作会社には、遠慮せずに、そうしたことも相談した方がいいと思います。

―― よくわからないのにWebリニューアルの担当者になってしまったというような場合は、お願いしている会社さんにゼロから相談するといいんですね。

濱田：そうですね。わからない時には、そのまま相談してほしいですね。たとえば、各部署で勝手にサイトを作ってしまっているけれど、1つにまとめてリニューアルしたいという案件で、このサイトはどの部署の誰が管理しているのか、どのようなシステムなのか、誰に聞いてもわからないことがありました。その時にはうちの開発メンバーが1つずつ調査して紐解いていきました。現状がどうなのかがわからないと、スタートラインに立てないですからね。

また、私たちの定例ミーティングでは「そもそもインターネットってどう考えるべきなの？」というお勉強的なことも行う場合もあります。プロジェクトが終わるころにはWebリテラシーが高まっている状態にもなっているので、公開してからも運用がスムーズに行えるはずです。

何がなんでもRFPを作らないといけないの？＿大枠の予算・スケジュール・やりたいことがわかればOK

―― Step2-12でRFPを作ろうという紹介をしていますが、「予算は〇〇で、来春くらいにリニューアル」といった、ふわっとしたことが決まっているだけで、委託先を探す場合もあるのでしょうか？

濱田：ありますよ。その場合は、「大枠の予算」と「スケジュール感」「最終的にやりたいこと」を伝えるとよいですね。最低限必要なのはこの３点です。その場合に気を付けたいことは、やりたいことが「200％コンバージョンをあげたい」であれば、それを達成するのは３年後なのか１年後なのか10か月後なのかも決めておくことです。3年後であればベースのサイトをしっかり作ろうという長期的戦略を立てる、10か月後であれば広告をガンガン打つところに予算をもっていく短期的戦略を立てるというように、やり方が変わるからです。

濱：「最終的にやりたいこと」は、「お客さま満足度を向上させたい」という場合もあると思いますが、濱田が例としてあげた「200％コンバージョンをあげる」といったような具体的な数値を、ひとまず仮にあげてもらえるといいですね。あと、だいたいの予算と納期がわかれば、ベンダー側が見繕ってくれるはずです。RFPを作って提示することは理想ですが、事業会社側であやふやなまま要件を作りこもうとすると、目的達成とのギャップが生じることがあります。やりたいことと予算と納期を伝えてもらって、あとはベンダー側と一緒に要件を決めていく方がスムーズにいく場合が多いかもしれません。

コストが膨れそうなとき、どうするの？＿当初の予算を把握して追加分を確認しよう

――「Step2-16 制作前の社内調整」では、経理部から「そんなお金、出せません」と言われてもめる例をあげました。コスト面で気を付けたいことはありますか？

濱田：私たちは、予算内でどこに重きをおいて成果をあげていくのか、優先順位を決めて実施していくんですが、なかには対象範囲が広がって追加コストが発生する場合があります。たとえば、あるサイトのリニューアルでスタートしたけれど、本当にやりたいことをクライアントさんに聞くと、ほかのサイトも含まないと思ったような成果が出ない、ということがあります。このように案件じたいが大きくなりそうな場合は、ベンダーに追加コストが発生するかを確認してください。

私たちは社内ですべての工程の制作をしているので「これを追加でやるならこれくらいです、予算の追加が難しければここの部分はやめて代わりにこちらをやりませんか？」といった調整・提案を柔軟にしています。

濱：途中段階で予算追加可否のコミュニケーションができていないと、終わってみたらコストが３倍になっていた、ということもあるかもしれませんね。先ほど濱田が話したように、やりたいこと、スケジュール、予算を伝えたうえでベンダー側に提案をもらえば、提案に、「〇〇を行うからいくら」という明細が記されていると思います。それを把握したうえで、ほかの部署からも新たな要望が出たときには、「提案とは外れてしまいそうですが、費用はあがりますか？」と聞いてみてください。あるいは、何かベンダー側から提案がある度に「予算を超えますか？」と確認していただくといいかもしれません。

人がどんどん増えたときどうするの？＿コミュニケーションがとれるコアメンバーを決めよう

濱：2-16には、人事部から「そんなに人が必要なの？」といわれる例がありましたが、確かにプロジェクトメンバーが必要以上に膨れてしまうことがあります。たとえば大規模プロジェクトのなかには、この部署から２人、この部署から２人というように、打ち合わせの人数が15人くらいに膨れていく場合もまれにあります。そうなると、形式的に体制に組み込まれた人たちもいて、定例ミーティングで内容を判断できないことが起こり得ます。

そこで、メンバーが膨れてしまった場合には、「ここはこうしよう」「こっちでいこう」と判断できる、３、４人のコアメンバーを選定してもらうとよいと思います。それ以外のメンバーは、必要なときにだけ個別に参加してもらうサブメンバーみたいな形で体制を組んでもらうといいですね。特にコロナ禍ではオンライン会議が増えて、15人で話していても表情が読み取れませんから、コアメンバーの重要性はより高まっていると感じています。

―― では最後に、監修していただいた範囲のなかで、これだけは注意しておくべき、というポイントを教えてください。

濱田：注意点としては、プロジェクトがスタートしたら最初に決めたRFPに固執せず、「何が最善か」を考え続けてほしいということですね。プロジェクトメンバー全員で現在の状況を知り、何が最適なのか、何が最高のゴール、形なのかをゼロベースで考え続けることが必要だと思います。

具体的には、現状の把握、要件定義、設計というそれぞれのフェーズごとに、みんなの認識が合っているのか、本当に向かうべきところに進んでいるのかを振り返り、次のフェーズでの予算のかけ方や方法について意識合わせしていくことが重要になります。いろいろな事情も抱えている担当者の方がいると思いますから、プロジェクトメンバー間でコミュニケーションをとって、その都度解決しながら進めていくことがポイントになりますね。

濱：最終的にOKを出せる人をなるべく早めに巻き込んで、承認をもらっておくのが一番大きいと思いますね。デザインができたタイミングでほかの部署の偉い人にお披露目することが多いんですが、手戻りが発生したときには大変です。その前の要件定義、戦略立案のときから巻き込んだ方がいいと思います。

―― 本日はありがとうございました！　引き続き、Step3の監修もよろしくお願いいたします。

Step 3-1