ITインフラエンジニアのWBSの作り方
1.ブログ記事化の背景
プロジェクト進行上、必要不可欠となっている進捗管理をするツールは何を使っていますか？
私はありきたりですが、WBSを使ってます。
WBSの作り方って、システム開発はよく書籍があったりするんですが、ITインフラ用のものを見たことないです。
（あるかもしれないですが、その時は勉強不足で申し訳ないです。）
考え方としては、タスクを書き出していって、計画を埋めていくといったところは一緒かもしれないですが、私の経験上、気を付けた点なども書きたいと思います。
2.作成手順
WBSは、Work Breakdown Structureの略称で、
自分の解釈だと仕事を小さい単位に分けていくという意味で捉えてます。
まず、仕事を大きい単位で捉える。
例えば、朝食を作ることをイメージしてください。
（朝食って作ったことありますか？無い人は、是非ご家族に作ってあげてくださいね。）
朝食を作ることを工程でいうと、
1.パンを焼く
2.卵焼きをつくる
3.コーヒーを注ぐ
が大きい単位です。これを大項目と呼びます。
（おかず少なくね？和食じゃないの？という方はしっかり朝食を摂れていると思うので、黙っててくださいね。）
次にもう少し仕事を小さく捉えます。
2.卵焼きを作る
という仕事は、2-1.卵を割る、2-2.卵を焼く
ともう少し小さくできます。これを中項目と呼びます。
最後に中項目から更に仕事を小さく捉えます。
2-1.卵を割るには、
2-1-1.卵を割る器を用意する
2-1-2.卵を割る
2-1-3.卵の中身を器に落とす
2-1-4.かき混ぜるための箸を用意する
2-1-5.卵を箸でかき混ぜる
2-1-6.卵が綺麗に混ざったか確認する
と小さくできます。これを小項目と呼びます。
卵焼きの作り方のタスクを洗い出して終わりそうなので、これ以上はやらないですが、
ITインフラ構築プロジェクトでも同じやり方でWBSを作ってきます。
WBSの前提
前提として、要件定義がつつがなく終わって、基本設計から始めているとします。
また、大規模プロジェクトではなく、要員が10人いかないくらいの小中規模プロジェクト・新システムの構築を実施するSierのPM、PLが作るようなWBSを前提に考えてます。
（大規模プロジェクトやれる人すげえ！私はやりたくねー。）
ITインフラは基本的にウォーターフォール型のプロジェクト推進をしてきます。
そのため、今回はウォーターフォール型のプロジェクトのWBSを作ります。
(1)大項目を作る
各工程は会社によって名前が違ったりもすると思いますが、大体こんな感じかなと思います。
機器やソフトウェアの調達があったりすると、もっと項目が増えますが、取り敢えずこんなところにしておきたいと思います。
1.基本設計
2.詳細設計
3.構築
4.運用設計
5.運用手順作成
6.単体テスト
7.結合テスト
8.システムテスト
9.運用引き継ぎ
10.本番展開
運用設計は基本設計に含めるのかとか、構築との順序は考えてしまいますが、まあ、考えた結論が正解です！
顧客とのコミュニケーションに定例会を入れるのであれば、定例会という項目も入れて良いと思います。
(2)中項目を作る
1.基本設計の中項目は、こんな感じです。
何度も言いますが、正解は考えた結論です！PMなり、PLが考えて導き出すしかないです。
1-1.システム概要設計
1-2.システム構成設計
1-3.可用性設計
1-4.性能・拡張性設計
1-5.セキュリティ設計
(3)小項目（タスク）を作る
1-1.システム概要設計の小項目は、こんな感じです。
1-1-1.システム概要
1-1-2.サーバ間連携
1-1-3.ネットワーク構成
もっと細かく管理したい場合や、違う要員に仕事を割り当てたい場合などに4段階目にいくWBSを作成する場合もあると思います。
それも正解だと思います。動きやすさを考えてタスクの単位を考えていきましょう。
(4)予定工数を入れる
項目を洗い出したら、タスクの予定工数を入れます。
私は1、2、4、8時間単位で書いてます。もちろん、2日かかることもあると思いますので、その次は9、10、12、16時間という感じです。
見積もり時にWBSも作成しているのであれば、これを基に算出できます。
受注後に作成されているのであれば、とりあえず、予想を書いておきましょう。
辻褄合えば良いですが、予想より低めに見積もられている場合は、会社内で相談しましょう。
(5)担当者を入れる
工数を入れたら、担当者＝タスクを実行する人の名前を入れていきます。
WBS作成前に体制が決まっている場合は、その役割に応じた割り振りをすれば良いです。
体制が決まっていない場合は、機能毎に仮の名前「A」とかを割り振っていき、体制が決まった時に名前を入れ替えるのがおススメです。
(6)予定日を入れる
担当者が決まったら、工程の最初から予定日を埋めていきます。
この時私が注意している点は、
・前工程が終わった後でなければ後工程が出来ない場合は後工程を前工程の翌日以降に日付を置く。
極端に言ってしまえば、基本設計が終わっていなければ詳細設計を開始出来ないので、基本設計が終わったタイミングの予定日を入れるような話です。
・1タスク5日以内とする。5日以上かかる場合は、タスクを分ける。
月～金に働いて土日を休む感じで考えてます。
・工数が8時間を超える場合は2日とか日にちを数日かける。
初めから残業するようなスケジュールは組まないです。残業するのは、予定外の時と決めておきます。
ここまで来たら、後は関係者と調整していきます。
(7)チームメンバーとの調整
体制が決まった後にメンバーと調整します。
メンバーもプロジェクト以外の予定も決まっていると思うので、現時点の予定を聞いておきます。
自分で埋めた予定日に合わない場合は、他の人に頼めないかを検討します。
最初から日にちを変える作戦は良くないかなと思います。
どうしても無理そうであれば、予定日を変えます。
他に確認するポイントは、工数です。
タスク毎にもっと必要という声も出ると思いますので、自分の算出根拠と比較して妥当性を確認します。
調整なので、自分の意見を言うのはもちろんなのですが、相手の意見を聞いて最適解を出します。
工数が増えたら、予定日を後ろ倒しする必要があるのかも再確認が必要です。
新規構築前提なので、切り替え等は特に考えてないですが、
リプレイス案件は移行や切り替えが発生するので、要件によって切り替え日の候補を出しておく必要があります。
ややこしくなるので、ここでは割愛しますが、休日や夜間が多いと思いますので、調整が必要となってきます。
(8)顧客との調整
チームメンバーと調整が終わったら、次は顧客と調整します。
顧客との調整は通常、納期に間に合うかという観点でされるため、大項目のスケジュール案を持っていきます。
細かく聞きたい担当者もいるので、その時はWBSをそのまま持っていくと良いでしょう。
ケースバイケースです。
その時、まずは納期よりもインフラの品質を優先したスケジュール案を持っていくべきだと考えてます。
例えば、テストを適切な量をこなすためには、テストケースを洗い出す必要があります。それには設計によって実現する機能を洗い出しておく必要があり、相応の時間が必要になります。
テスト量が少ないと要件で出されているテストケースを洗い出せているか分からず、狙った動作を保証するものがなく、不安要素となります。
下手すると、業務を停止するような障害が発生しかねません。
その後、どうなるかと言うと、テストはキチンとしたのか。こういうテストはやったのか。という話に発展しかねなく、PM、PLの責任を問われてしまいます。
顧客が言ったスケジュールに合わせたという言い訳は効かないです。普通はね。
もちろん、品質を考慮したWBSが納期に間に合うならそのまま調整していけば、すんなり承諾を得られるでしょう。
開始が遅くなったのに納期を変えられない顧客もいます。
そういう場合でも、最初に出すスケジュールは、PM、PLの考えた品質を重視したスケジュールです。
納期を事前に聞いてるでしょう。
でも、スケジュールは納期に合わないでしょう。
まずは、WBSを見せながらこれだけのタスクがあるから間に合わない、リスクを考慮していないことを伝えます。
そこから調整がスタートです。
顧客は納期に間に合うように調整してくると思います。
私なら寄り添います。
ただ無謀なスケジュールを引き直しても仕方ないので、例えば、基本設計と詳細設計を機能やカテゴリー毎に顧客レビューを五月雨で行い、スケジュールを厳守するために出戻りしないようにする約束を取り付けます。また、原則的にデフォルト設定として、運用中に変更する約束を取り付けたりします。
そうすることで、顧客レビューの待ち時間や設計にかける時間を短縮出来ます。
品質とスピードの両立はなかなか難しいと思います。新しいことに挑戦すればするほどです。
どっちが良いのか、顧客に選んでもらい、WBSを確定させましょう。
WBSを作るのは、ある程度経験があるエンジニアであれば簡単に作ることが出来るでしょう。
最後の調整がなかなか難しい人もいるのでは無いでしょうか。
重要なのは、顧客に寄り添うことと、自分の責任をどうやったら果たせるのかということです。
こうして、考え抜いてプロジェクト関係者と調整したスケジュールを使うとプロジェクトは軌道に乗ることが多いです。
良いプロジェクト運営の第一歩は、実現可能なWBSを作り、関係者と共有することだと思います。
管理系の話は、正解は一つではなく、PM、PLの考え抜いて出した答えが正解だと思います。
時にはメンバーに、顧客に相談しながら進めて、自分たちの正解を導き出しましょう。
