はじめに
最近、OSバージョンアップ対応のプロジェクトで、プロジェクトリーダーのような立場で仕事をしています。
私も手を動かし作業をしながら、
- タスクを整理する
- WBSに落とし込む
- メンバーにタスクを振る
- 進捗を確認する
といったことをやっています。
以前、開発チームのリーダーを担当していたときは、
システムのリプレース対応という括りだったので、機能単位でタスクを考え、協力会社さんにタスクを振っておりました。
もちろん開発でも設計やテストなど色々ありますが、少なくとも「何をするのか」は比較的見えています。
ですが、今回のOSバージョンアップ対応は、ほとんど経験したことがないプロジェクトです。
現在はまだ親会社との契約前ということで、実際のサーバー構築や移行作業が始まる前段階ですが、
その前段として、現行サーバーの環境調査などをチームで進めている状態です。
そして、この段階で悩まされているのが、
「WBS（タスク）をどのように整理していけばいいのか」
という問題です。
今回は、そんな私の悩みを整理してみました。
※今回の記事では、WBS上に記載する作業単位を、便宜上「タスク」と呼びます。
1. そもそも何をすればいいのかが分からない
今回のサーバー更改では、自分自身もサーバー更改の経験がそこまで多くありません。
なので、開発のときのように、
「この機能があるから、このタスクが必要」
のように想定タスクが洗い出せてません。
元々、自社にサーバ更改のナレッジが貯まっていればそれを元に調査が始められたのですが、
そもそも、
サーバーを更改するために、何を調査しておけばいいんだ？
というところから考える必要があります。
そのため、タスクを考える上で、最初は抽象度を上げて、
現行サーバーの調査
├─ OS環境設定周りの調査
└─ 使用しているソフト・アプリケーションの洗い出し調査
くらいの粒度高めのタスクを考えました。
ただ、これだけだと自分でも、具体的にどこをどうやって調べるのか？がわからない状態でした。
自分が依頼する側でも、「OS環境設定周りの調査をしてください」だけでは、メンバーにちょっと依頼しづらいです。
というか、具体的なタスクが決まっていないと成果物が人によってまちまちになっていまうため、ある程度具体的にタスクを落とし込む必要があります。
そんなとき自分は、まず現行の設計書がないか探しにいきました。
幸いにもうちの会社には、現行システムの導入当初に作成していた基盤環境設計書があったため、設計書を確認しながら、少しずつ抽象度を下げて具体的なタスクに落とし込んでいっています。
現行サーバー調査
├─ FWの送受信のルール調査
├─ コントロールパネルの設定
├─ サーバーマネージャの設定
└─ アカウントの調査
さらに、調査するうちに、また別の調査をしなければいけない時があります。
たとえば、以下のように
アカウントの調査（どのようなアカウントがいるか）
↓
アカウントの設定方法の調査
↓
アカウントはそもそも別部署に申請が必要（申請部署は？）
↓
申請書の記載方法は？
このようにやるべきタスクが増えていくため、最初から、WBSとしてタスクが落とし込めないことが多く、そのため期日も曖昧なものとなってしまいます。
とはいえ、いつまでに何をしなければいけないという期日はあるので、なかなか期日管理は難しいと感じています。
2. 何をもって「完了」なのか
タスクを具体的にしたいと思う理由は、もう一つあります。
それが、「何をもって完了とするのか？」 という問題です。
例えば、
OS環境設定周りの調査
というタスクだった場合、「調査しました」と言われても、「どこまで調査したんだろうか？」となります。
一方で、
FWの送受信のルール調査
であれば、どこをみてどこを調べたかという証跡をとってもらえれば、「調査に問題がなかった」ということが判断つきます。
このようにタスクを具体的にすることで、**「何をやれば完了なのか」**を考えやすくなると感じています。
特に今回のような、まだ手探りのプロジェクトでは、この「完了」が意外と重要だと思っています。
3. タスクを細かくしすぎるとかえって見づらい？
とはいえ、何でも細かくすればいいというわけでもありません。
例えば、
OS情報の確認
├─ OSバージョンを確認
├─ ホスト名を確認
├─ IPアドレスを確認
├─ パッチ情報を確認
├─ CPUを確認
├─ メモリを確認
└─ ディスク容量を確認
と、全部をWBSのタスクにしていくこともできます。
これなら何をするのかは非常に明確です。
でも、ここまでやると、
WBSを見るだけ項目多すぎて疲れる。
という問題が出てきます。
たとえば、
- 上司に報告する時もこれでは、うまく伝えられない
- 人数が増えた時に、管理しづらい
などの問題です。
（現在は、自分含めて4名のメンバーなので、具体的なタスクとして行なっていますが、、、）
そのため、**具体的にしたほうがいいけど、細かくしすぎると管理しづらい。**という状況が生まれ、そのいい塩梅というのが難しいと個人的に感じています。
また、これらのタスク振りについてはメンバーの能力にもよるところはあると思います。
ある程度抽象度が高くても、経験者であれば、ある程度汲み取って、レビューで吸収できるでしょう。
一方で、若手など知見に乏しい場合は、ある程度具体的に指示を出した方が、進みが早くなる場合もあるでしょう。
このようにメンバー管理は、メンバーの能力値をみて抽象度の上げ下げを判断していくことが重要だと思っています。
4. まとめ
以前は、
WBSは作業を一覧化して、進捗を管理するためのもの
くらいに考えていました。
ただ、今回のように、そもそも何をやればいいのか分からないプロジェクトを経験すると、
WBSを作ること自体が、プロジェクトの作業内容を整理することになる
と感じています。
今回、OSバージョンアップ対応の事前調査を進めながら、WBS（タスク）の粒度についてかなり悩んでました。
特に感じているのは、
手探りのプロジェクトでは、抽象的なタスクだけでは管理しづらい
ということです。
そのため、現段階の考えとしては、ある程度具体的なタスクまで分解したほうが、チームとして動きやすいと感じています。