WEB制作の範囲は、年を追うごとにどんどん広がっています。
昔は、デザインを作って、そのデザインをレイアウトごとに分割してテーブルのHTMLに貼り付けて、サーバーにアップする。
せいぜいCGIのフォームを作ってテストを行うくらいだったでしょう。
たった一人で把握して作れるようなものでした。
しかし、いま設計だけでも導線、画面、構造、インフラ、システム、運用などそれぞれの専門領域が多岐にわたっています。
それぞれ専門的な内容が必要で、一人の人間の手におえるものではなくなってしまいました。
さらに追い討ちをかけるように、業務の縦割り化が業界内で進み、
WEBサイト構築の全容をわかっている人というのは、プロジェクトの中でも相当経験値の高い、限られた人しかいなくなってしまいました。
これによって「仕事の見えない化」「スタッフの歯車化」が進んでしまった気がします。
そして、さらに恐ろしい、「宙に浮いたボールを誰も拾わない化」が生まれた気がします。
以下それぞれの解説です。
「仕事の見えない化」「スタッフの歯車化」
自分の担当している範囲のことしかわからないので、各パートで気の利いた動きができない。
上流から落ちてきた意図や、コンセプトが伝わらず、クリエイティブの質が下がる。
大きなプロジェクトでは、特に作業者が一つの歯車になってしまい、モチベーションが下がる。
「宙に浮いたボールを誰も拾わない化」
プロジェクトの工程は、必ず繋がっている。そのため、各パートのちょうど間のところは、どちらのパートがやるか不明確なところが出てしまう。
そうなった時に、互いに相手がやってくれるだろうという思い込みをし、結果的にどちらもやらずに、バグとして最後に発覚することがある。
Work Breakdown Structure (WBS)が解決してくれたこと
上記の現象は、自分の周りでも数多く起きていました。
Work Breakdown Structure (WBS)に出会ったのは、５、６年前だっただろうか？
事前に作業を細分化したタスクまで分解し、誰がいつやるかその前後関係を明確化するための作業だ。
ただ、本当に項目が細くて、最初は億劫だった。
実際に取り入れ始めたのも、教えてもらってから1年くらい経ってからだったと思います。
でも、今思えば、やっているのとやっていないので、プロジェクトに対する不安感が全然違いました。
それまでは、来たものを片っ端に前から片付けていくので、
「これはいつ終わるんだろう」という漠然とした不安にかられながら仕事をしていました。
当時は、若かったので、力任せに回せていたというのもあるかもしれません。
WBSを行えば、すごく良い点がいくつもありました。
まず、規模感をメンバーに共有できる。
クライアントも含め、プロジェクトを過小評価しがちです。
最初にWBSを行っておくことで、皆にこんなにやることがあるんだから、覚悟してくださいねという意識をつけることができます。
次に、スケジュール感が見える。
WBSをしたリストをそのままガントチャートにできるツールは数多くあります。
細かいところは、各パートに埋めてもらうとして、まずは大まかに全体のスケジュールとつながりを作ることができます。
次に、リソース配分がわかる
スケジュールを引くことで、その時期にそのパートに対してどれだけのリソースがさけるかがわかってきます。
エンドが決められているプロジェクトなどでは、その時期にパートナーも含め、どれくらい準備しておかなければいけないかが見えてきます。
次に、リアルな費用感が見える
スケジュールとリソース配分がわかったら、費用がわかります。
WBSをしていないがために、無理なスケジュールを少人数で乗り切らなけらばならないことも過去にはありました。
細かなWBSとスケジュールがあれば、クライアントと建設的なお金のはなしが出来ます。
最後に、宙に浮いてしまう作業を潰せる
ディレクターやプロジェクトマネージャーが行ったWBSは各パートに渡し、
さらに作業ベースで細分化します。
そうすることで、仮に前後のパートで同じ内容を記載したら、その場でどちらがやるか、決めることができます。
そして、WBSをしっかりやっていくために必要なのは、このスキルをディレクターや、プロジェクトマネージャーだけのものにせず、すべてのメンバーのスキルにしていくことです。
ディレクターではなく「ディレクション」、プロジェクトマネージャーではなく「プロジェクトマネジメント」というスキルベースで、現場の底上げしていくことが必要です。
上流で決められたものを、受け止めるだけはなく、現場で流れを理解し助け合える現場を目指していきます。
