先日WBSの概要を記事にしたわけですが、チームメンバーに対してどれくらい浸透しているのか、正直わからなかった。
というのも、昨年、僕が今の会社に転職して半年くらい経った時に一度社内の勉強会で解説していたのだが、現状特に浸透して改善されてはいなかったからです。
WBSとなると、引き合いに出されるのは、大型案件が多いと感じます。
僕も解説する時に、例に挙げたのは大きめのECサイトでした。
ECであれば、要件定義から始まり、座組み、設計、デザイン、インフラ、フロントサイド、サーバサイド、量産オペレーション、試験、運用導入支援まで一通りの工程が存在するため、全体を説明するのに良いと思ったからです。
全体のWBSの話は現場には伝わらない
でも、これはきっと間違っていたのだと思います。
一度でもECサイトのプロジェクトをやったことがあったり、ECでなくても一通りの工程をプロマネとして通で経験したことがあれば、実体験から想像できるのですが、現場レベルのスタッフに全体のWBSを元に解説しても、そもそもイメージできなかったのです。
説明するときに、自分の体験談も合わせてできるだけリアリティを盛り込んでいますが、きっとそれは戦争体験者が戦争を知らない世代に話すようなもの。遠い昔の物語なんです。
それでもやらなければならないWBS
しかし、現場でのWBSの考え方の導入は、急務でした。
自分がチームに入ったことで、既存のクライアントだけではなく、幅広いクライアントや代理店さんから仕事を入れるようになり、職種的にも縦割りをやめ、経験したことがないスキルセットを積極的にやらせるようになりました。
そうすると、まず皆、時間がよめないのです。
そして時間がよめないだけでなく、「今何をやっていて、次にどうするか」という説明もままならなくなります。
説明ができなくなるということは、何か問題が起きてしまっても、ホウレンソウができず、チームとしてハイリスクな状態が続きます。
そして何より、スタッフ自体に恐怖心がうまれ、新しいことをやりたがらない、せっかくチャンスを与えても、結局重要なところは責任転嫁をする、という事態におちいり、個人的にもチーム的にも成長が止まるという最悪の自体になってしまいます。
未経験分野や、新しい対人関係の中で仕事をするとき、その後起こる可能性のあることを把握していないというのは、ライトをつけずに真っ暗闇の夜道を車で走るようなものです。
WBSをあらかじめやっておくことで、先々を下見し、危ないところには街灯を設置しておけるのです。
もっと小さな単位で体験してもらう
そこで実践し始めたのが、WBSを行う単位を小さくするということ。
例えばフロント実装を行っているスタッフに対して、理解をしてもらう場合、1ページ分で実践してもらいます。
彼らにとっての1ページのタスク完了は、以下に分解できます。
必要要素
・FIX原稿（ページに対して）
・FIXデザイン（ページに対して）
・画像素材の手配完了
・ガイドライン
・ベースコーディングの完了（共通パーツのコーディングが出来ていること）
・ページ内のリンク先の確定
・該当ページのURL
・メタ情報の確定
・ソーシャル仕様の確定
・解析タグの確定
・SEO要件がある場合は、SEO要件
・サーバサイドの組込が発生する場合は、関連仕様の確定
他のページと共通のものもあるかと思いますが、たった1ページに対しても、これだけの要素が必要になります。
これだけの要素が反映されて、やっと1ページをコーディングするとタスクが完了します。
また、各要素をFIX状態にするために、それぞれ以下の工程があります。
必要工程
・該当工程作業前のクライアントへの事前確認
・実際の作業
・内部確認
・クライアント確認
・フィードバック対応
・調整期間
・完了
すべてのプロジェクトや要素で、すべての工程があるわけではありませんが、だいたい上記の工程が発生するはずです。
上記工程がすべて完了した時点で、自分の手元にFIXした状態のデータが手に入るのです。
これらの工程を常に頭の中に入れておかないと、自分のなかで不明瞭な領域が生まれ、それはやがて漠然とした不安へと変わります。
どこが完了なのかわからないからです。
また、思わぬところでフィードバックや変更点を受け、自分の想像していたスケジュールにどんどんズレが発生します。
これが続くと、スケジュールがよめない、進捗を聞かれても明確に答えられないという状況におちいります。
実際のプロジェクトで、上記工程がすべてFIXした状態で、自分の作業が着手になる場合は、不可能に近いでしょう。
すべてFIXした状態でなければやらないと言うのは、ワガママに過ぎません。
ですので、要素・工程をしっかり把握した上で、何がどこまで終わっていて、現時点で作業すると、どんなことが積み残しになるか、積み残したものはどのタイミングでまとめて作業すれば全体として、スケジュールを守れるかということを考えるのです。
それが、まさにWBSだとおもいます。
この小単位のWBSを行うということは、要素や工程を理解するだけでは出来ません。
自信が関わる工程の人の状況を理解しなければなりません。
理解するためには、積極的に違う工程のスタッフとコミュニケーションを取る必要があります。これが大事です。
コミュニケーションをとることで、相手の状況を知ることができるだけでなく、相手に対して自分が「待っている」という状況を伝えることが出来ます。
すると、チーム全体の意識が変わり、全体としてスケジュールを守れるようになるのです。
おそらくただ待っているだけの人たちの集まりに比べたら、倍近いスピード感になるのではないかと思います。
プロジェクトのしんどさも半減するでしょう。
他人を知ることで
小単位のWBSでも、関わる人のことが知れるようになります。
これはもう一つの副産物を産みます。
他人の苦労を知ることができるのです。
自分のところにFIXデータが来るのが遅い
↓
前の工程の人と話す
↓
自分が思っていたよりも大変な作業を前の工程の人がやっている
↓
自分に待ち時間が出来てしまうので、手伝う
↓
新しい領域が増える
↓
更に先の工程が見える
↓
更に広い範囲のWBSができるようになる
↓
ちょっとずつ範囲を広げる
↓
気づいたらプロジェクト全体が把握できるようになる
↓
あなたのお給料があがる
ご理解いただけたでしょうか？
