チームメンバを巻き込んで方式検討したらトラブルが0件になったやり方

どうしてもプロジェクトチームを組むとプロジェクトマネージャからメンバに相談でも作業指示が伝えるような形態になってしまう傾向があります。プロジェクトマネージャなのだから仕方がないといえばそうなんですが、一から十まで全知全能ということはなくて特定分野の深い知識と広く水平方向へのものごとを概念的に捉えるスキルがあるからなんとかやっているのが実情でしょう。つまり、特定分野についてはメンバの専門性を持ってしてチームとして補完しあうのですよね。


プロジェクトマネージャとしては、方向性や判断に専念出来れば一番良い環境なのですが、プロジェクトマネージャの性格によりますがある程度関与したくなるわけです。ただ、アウトプットがプロジェクトマネージャの期待をキープできるメンバであればその関与は薄くして、他のメンバを重点をシフトしたいという心理も働くのです。


そのような環境を作るための1つのプラクティスがあるのでそれを。結局、メンバ全員を巻き込んで、必要な人が必要なときに他のメンバに自分が持っている知識や懸念を伝えられる環境を作れれば自然と指示命令をプロジェクトマネージャからトップダウンでする必要は無くなるんです。そのような環境が形作れ始めたらメンバの意識も変わり始めます。これは実体験すると感動しますよ。


実例のケースです。


前提知識:実運用中のシステムの対抗システムを立ち上げ、対抗システムのリリース時に実運用中のシステムからデータ同期をする。なお、対抗システムはシステム構築時に実運用システムと接続しなければ構成できない。
検討テーマ:構築方式の決定(検証フェーズは別途設ける)

検討にあたってのファシリテーション:プロジェクトルーム、プロジェクタ
出席者:チームメンバ全員

実際のファシリテーション
資料配布:紙の資料は配布しない。配布するとプロジェクタを見て話す人と資料を見る人と出てくるので同時に同じ情報を見ないことがあるため。
資料:プロジェクタで大きく映す。
進行:たたき台の資料を映し、たたき台版での想定を一旦説明する。質問、指摘はその都度受け、メンバが修正すべきとなったらその場で修正する。
   資料説明者もしくはプロジェクトマネージャは全方位的な視点で考慮漏れを見つけたいため、メンバ全員に意見を求める。担当の機能、ミドルウェア、NW的にどうか、と尋ねる。
   検討は局面ごとに行う。このケースでは、実運用中のシステム開発と同じ工程を列挙し、対抗システムはどこの局面から作業をするか、アウトプットは何かを洗い出す。
   #契約上は別にあるが、各メンバに何を作るかを意識付けするため。
   作業とアウトプットの洗い出しでは同時に実運用中のシステムへの影響範囲の特定がなされる。それができなければ対抗システムを接続することができないため。
   これをリリースの局面まで行う。

検証:一旦、すべての局面の作業、アウトプット、影響範囲の特定ができたらそれで正しいかを検証する。
   #検証の仕方は、テスト仕様をつくるのが一番よろしい。いわゆるV字モデルである。
   単体テスト結合テスト、総合テスト、移行と一通り検討する。
   検証でのテスト仕様は、テスト項目の大項目レベルかできて中項目レベルまでで止めること。テスト項目表を作るのが目的ではない。
   テスト仕様を検討することで、システム構築の設計方式の脆弱性が炙り出せる。ここで大きな誤りは出し切っておくこと。見つけたメンバは褒めること。
   ここのシステム環境の状態、NW、ドメイン、テストデータの種別、テストデータ量、切り替えポイント、切り替え時に更新されるリポジトリ、影響を受ける他システム、事前準備の申し入れをする必要のある他システムなどの切り口でテスト対象の対抗システムの開発方式をガンガン叩く。
   この観点でテスト仕様の大項目から埋めていく。
   叩くことで技術的に確立していない課題が多数出てくるのでそれを検証フェーズを設け(場合によっては闇検証として)そこで確立するために検証テーマ一覧に書き出しておく。

後日談:このやり方で大きなトラブルは1件もなし。