打開策はカンバンだけじゃない、Microsoft Projectをもう少し使ってみよう

非Scrumプロジェクトでカンバンが誤って使われている

最近は伝統的なSI開発の現場でもアジャイル開発の波の音が聞こえてくるようになりました。
特にScrumはアジャイル開発の中でも、その名を高めており、「試してみようか」という声を聞くことをが多くなりました。ただ、Scrumのツールとして知られるカンバンだけを採用し、それが誤用されている現場を見ることも増えています。

私はPMP保持者であり、CSM(Certified Scrum Master)です。そして、今まさに１つの案件のスクラムマスターをしています。
そんな私が、「プロジェクトのタスク管理に悩んでいるなら、カンバンもいいけど、もしMicrosoft Projectを使っているなら、それを上手く活用しよう」というのが本記事の趣旨です。
(ScrumでMicrosoft Projectを使おうという意味ではありません。)

「現場での状況」が以下に当てはまる場合は、この後もぜひ読んでみてください。特に非Scrumプロジェクトでカンバンを使って失敗した方は是非。

現場での状況

• 1つのお客様向けチームでも複数のプロジェクトが並行で動いており、たくさんのMicrosoft Projectファイルが存在する。お客様に工程を見せるために作るが、最初にWBSを作成した後は正しくメンテナンスができていない
• 同時期に複数のプロジェクトが動いており、Projectファイルが別れているので、各プロジェクトにおける重要イベントやマイルストーンが一覧できない。
• JavaやC#など同じ技術を採用したプロジェクトの兼任が発生しているが、MS Projectで登録するリソースが別々なため、メンバー毎ののトータルの作業負荷が見えない

無造作に使われるカンバン

こういう状況が数年続いていると、俺たちも今までのやり方じゃなくて、Scrumでよく見るカンバンを使うとよくなるんじゃないかという根拠レスな案がどこからか湧き出してきます。そして、開発の一部分だけなぜかカンバンを使い始めるといった現場をみたことはないでしょうか？
ホワイトボードに突然３つのレーンが現れ、付箋が貼られ始めるという状況です。
もちろんこんなことをしても何の改善も進まず、そのホワイトボードは２週間も経たずに、元の本来のホワイトボードの役割に戻ります。

カンバンはこういうものです

Scrumではタスクの管理に付箋を使ったカンバンを使うことが多いと思います。私もScrumでは実際使っています。こういうのですね。

出典:Wikipedia

Scrumはチームの自己組織化ということが最大の特徴です。意訳すると、「個人のスキルに頼るんじゃなくて、チーム全体でプロジェクトのゴール達成のためになんでもやろう」という感じです。

このカンバンが良いのは、一つ一つのタスクに担当者の名前が入っていないことです。Scrumではタスクは誰かに事前に割り当てるのではなく、チームとして取り扱い、個別担当は基本的にはその日の朝のデイリースクラムで決めるというのが基本的な考え方になります。

先に挙げたSIで急遽登場するようなカンバンは、単純にMicrosoft Projectでタスクの管理ができないことを理由にそれをカンバン化してしまっただけなのです。つまり、カンバンという見せかけだけを用意しても、それが自己組織化できていない、もしくはそれを推進しようとしないチームにおいてはカンバンは単に付箋を書く、貼る、移動する、落ちた付箋を拾う、というタスクを増やすだけの代物なのです。
SIでカンバンを使ってはいけないという意味ではないことはご理解ください。カンバンはアジャイル的な考えと合わせることでとても強力なツールになるということをお伝えしたいのです。

もし、この辺りに興味がある場合は以下の本をお薦めします。何回も読んで肉体化する必要はあります。私はこの２冊を今でも何度も読み直して気に入っています。
アジャイルサムライ−達人開発者への道
アジャイルな見積りと計画づくり

あなたのプロジェクトは兼任が増えてませんか？

多くのSIerではプロジェクトマネージャ/リーダは複数のプロジェクトを兼任していることでしょう。最初に言いますが兼任は悪です。ただし、会社の都合で兼任もやむを得ないこともあります。もう一度書きますが、兼任が理由で、以下のようなことが多くの現場で起きています。

1. 1つのお客様でも複数のプロジェクトが並行で動いており、たくさんのMicrosoft Projectファイルが存在する。お客様に工程を見せるために作るが、最初にWBSを作成した後は正しくメンテナンスができていない
2. 同時期に複数のプロジェクトが動いており、Projectファイルが別れているので、各プロジェクトにおける重要イベントやマイルストーンが一覧できない。
3. JavaやC#など同じ技術を採用したプロジェクトの兼任が発生しているが、MS Projectで登録するリソースが別々なため、メンバー毎ののトータルの作業負荷が見えない

これは次に記載するMicrosoft Projectの使い方でコントロールを取り戻せます。

Microsoft Projectを活用してコントロールを取り戻す

その方法はマスタープロジェクトの作成と共有リソースです。
これにより、兼務している複数のプロジェクトのマイルストーン、同時にアサインしているリソースを１つのプロジェクトだけで可視化できます。「アサインしすぎて、Javaエンジニアの田中さんだけ300％の稼働状況になってしまっている」なんてことは二度と発生しないでしょう。

1. マスタープロジェクトの作成
2. 共有リソースプロジェクトの作成

完成後のイメージは以下となります。

画像出典:Microsoft

マスタープロジェクト/共有リソースの作り方

マスタープロジェクトの作成

とても簡単です。以下の2ステップだけです。

1. 新規にMS Projectでプロジェクトを作成する
2. 既存のプロジェクトをサブプロジェクトとして追加する

詳細手順 →Microsoftサイト

共有リソースファイルの作成

1. 新規にMS Projectでプロジェクトを作成する
2. リソースシートにチーム内の全メンバーを登録する
3. 既存のプロジェクトで割り当てているリソースを「1」で作成したリソースから割り当てる

詳細手順 →Microsoftサイト

さらなる効率化

マスタープロジェクトはサブプロジェクトをショートカットのように展開します。そのため、大人数で利用した場合に誰かがプロジェクトを開いていて更新できないという状況が発生します。
それを回避するためには、マスタープロジェクトからの参照先のプロジェクトファイルを実運用ファイルのコピーとすることで安全に運用できます。これで、マスタープロジェクトをチームのみんなで開いていても、個別の更新用ファイルはいつでも更新可能となります。

ただ、毎日手作業でコピーするのは手間なので、自動化することをお薦めします。
極めてシンプルですが、コピー用のプログラムを用意しました。
以下のディレクトリやファイル名をご利用の環境にあった形で変更し、msproject-copy.bat などの名称で保存します。すると、当該ファイルをダブルクリックするだけでコピーが行なえます。
Windowsのタスクスケジュールに登録すると、ダブルクリックでの更新すら不要となります。

setlocal
   rem /* C:\sample.mppをD:\バックアップ\sample.mppへコピー */
   rem /* /Yはコピー時に同名ファイルの上書きを許可するためのフラグ */
   copy /Y C:\sample.mpp D:\バックアップ\sample.mpp

   rem /* 一時停止 */
   pause
endlocal

Microsoft Projectを効果的に利用し、兼任でも正しいプロジェクト運営が行われることを期待します。
Microsoft Projectをどう使うべきかということには、ほとんど触れていませんが、私は「SEの教科書 【完全版】　深沢隆二」を何度も読んで学びました。しかし、今は絶版なのか見つかりませんでした。リンクだけ貼ります。
SEの教科書 【完全版】