Webサイト構築のマルチベンダーを進めるコツ5個【繋ぎが重要です】

「マルチベンダーのWebサイト構築プロジェクトをどう回して良いか分からない…」「フロントとバックエンドのベンダーが異なるプロジェクターで起こりやすい課題と対処を知りたい…」

web制作でマルチベンダー体制が初めての方が悩む課題をわかりやすく解説していきます

こんにちは、システムからフロント、ネットワークまで経験してきたうみにんです。

ウェブサイト構築プロジェクトにおいてフロント側（HTML領域）とデータを取得するバックエンド側（API領域）を担う会社が異なる事ってよくあります。

実はこのようなマルチベンダープロジェクトにおいては、シングルベンダープロジェクトと比較して課題が出やすいと思います。

 

そこで、こういったプロジェクトに慣れていない方に向けて、最低限気をつけておきたい5つの視点を深ぼって解説していきたいと思います。

fa-check今回はフロントの制作会社とデータを取るAPI部分の制作会社が異なるという状況の前提での解説です。

テーマ：Webサイト構築のマルチベンダーを進めるコツ5個

 
上記テーマで解説していきます。

どれもベンダーが複数のパターンの時に起きやすい課題です。

 
私も実際にこういったマルチベンダープロジェクトに経験するまではそう思っていました。

しかし、実際にプロジェクトの現場を見てみると頭では分かっていても上手くタスクに落ちていないことが多いです。

代表的な理由は、目下の機能要件に意識がいきやすいからです。

fa-checkそれでは、マルチベンダーならではの課題について意識が必要だよっということが伝わったところで深堀り解説をしていきます。

スケジュール：タスクのINとOUT

あなたが担当するプロジェクトのタスクスケジュールを確認し、ベンダー同士のタスクのINPUT/OUTPUTの関係が明確に線で結ばれているかを確認してください。

例えば、

 

なぜこのような確認をするかというと、ベンダー同士の接点に関する考慮が抜けやすいからです。

 

しかし、ベンダーは自社のタスクスケジュールを組むのは慣れているので得意ですが、別のベンダーの作業が見えない中全体的な部分まで考慮するのは実際問題難しいのだと予想してます。

「場合によっては、そこの役割はスコープ外です」と一線を引いてくる会社もあると思います。

fa-checkなので、例えばA社のタスクスケジュールをレビューするときは、そのタスクのINPUTとOUTPUTにベンダーBが登場するようにした方が良いです。（逆もしかりです。）

そして、最終的にはこの両者のスケジュールをまとめた形がベストです。

コミュニケーション：会議・課題管理

次にプロジェクトの会議と課題管理についてです。

 

マルチベンダープロジェクトでは、ベンダー双方が集まってお互いの接点に関する課題を協議する場とbacklogなどの課題管理ツールを持つ方がいいと思います。

なぜなら、これから説明するマルチベンダーだからこそ起こる課題に早急に、かつ漏れなく対処しないとコストやスケジュール遅延に影響する可能性があるからです。

 
ただ、プロジェクトが本格的に動きはじめて各ベンダーが忙しくなると日程調整が難しくなるのです。

私の過去経験では要件定義・設計では1会議1時間×週2回を事前におさえてました。

 
でも大丈夫です。議題があれば実施、なければ会議をキャンセルする形を取れば良いのです。

会議枠を押さえてなく、自身の作業中に急遽会議が差し込まれるより、会議がキャルセルになることによる作業時間が生まれる方がいいですよね。

ここまでは主にプロジェクト管理における視点でした。次は実制作における視点を解説していきます。

プログラム的な繋がりが合っているか？

フロントが欲しい項目をバック側に正確に伝わっているか、また、バックへのリクエスト方法と返り値の受け取り方が合っているかを事前に確認したほうが良いと思います。

なぜなら、マルチベンダーの場合、プログラムの作り方や考え方は全く異なるからです。

これは、「カレーを作ってください」って100人の主婦にお願いした時に100通りのカレーができるのと同じだと思います。

もし、このすり合わせをせずにプログラミングまで進んだ場合、「欲しい値が返ってこない（フロントの視点）」や「期待しているキー項目が入ってこない（バックの視点）」という事象が起き、大きくて戻りになってしまいます。

対処はシンプルで、フロントの画面設計書の中でバックエンド（API側）から欲しいデータにはマーキングするとともに、そのAPIはどんなキー項目でリクエストをかけるか事前にすり合わせすることです。

入力チェックの役割分担

次に、入力フォームのチェックについてお互いのベンダーで役割分担を明確にしたほうが良いと思います。

というのも、入力チェックにも大きく分けて以下2パターンがあります。

 

これに対して、フロント・バックがどういう役割分担をするかを決める必要があります。

役割分担を決めないと、三遊間に落ちてしまうリスクがあります。

私が過去経験したプロジェクトのノウハウだと、

 

どういう考え方かと言うと、②は画面の更新が入ってしまい画面表示上一番上まで戻ってしまいます。この動きを意識したときに、入力エラーによるお客様の画面操作体験を悪化させたくない項目を①で補うというイメージです。

この部分は、プロジェクト進行だけでなく、お客様が利用する部分に関わってくるので超大事な視点です。

画面遷移制御の役割分担

最後に画面遷移の話です。

画面遷移を行う処理を、フロントで実施するのかバックで実施するのかが宙に浮きやすいポイントです。

 
こういう事象が起きるのは、こういう動きにしよう！みたいな直感で分かる機能部分に関して視点が行きやすいからです。

 

確かに1画面だけだったらこの考え方で良いと思います。ただ、状態による画面の出し分けが発生する場合にこの役割分担がとても大事になってきます。

私の対処案をお伝えすると、バックからは画面の出し分けを判断するためのフラグを返却し、実際の画面の出し分けはフロントで行うことが多かったです。

こういう考え方にしているのは、フロントとバックを切り離したかったからです。

実践：さっそく動いてみよう！

本日深堀り解説した知識を活用するも、このまま知っているだけで終わるもあなたの次のアクション次第です。

まずは、以下確認をするアクションを起こしてみてください。

 

今日はこの辺で、終わりたいと思います！　ノシ