プロジェクトメンバを動かすために最初にしたこと

コミュニティから企画をスピンアウトすることに
コミュニティを立ち上げ、軌道に乗せたのもつかの間、コミュニティの活動のネタを組織全体の企画としてスピンアウトさせることになった。人は新しいことは最初のうちは興味を持って寄ってくるけれど、それが続くと次第に飽きてしまう。コミュニティだって、組織の中にしっかりと根付いたわけではないけれど、それと人の飽きることは違うものだから、コミュニティを主宰する立場としては、何かを考えたくなのが人情というものだ。
それが企画だったわけで、そのスピンアウトさせてて企画したものが一大イベントになることになってしまった。自分としては、その企画をとおして日頃お付き合いの浅い方々とcoworkできれば、より楽しいだろうし、その企画のテーマを自分も関心の高い内容に方向付けることで“楽しく”仕事が出来るだろうという算段もあったことはあったのである。
＃俺得

ちょっと予想外であったことは、スポンサー直下のプロジェクトマネージャに当たる責任者が自分になったことくらいだ...。

プロジェクトメンバを動かすために最初にしたこと
顧客向けのプロジェクトは、それはそれなりにこなしてきたし、マネージャとしてプラグラムマネジメントも長年しているから、そんなのは日常なのであるが、組織横断的なイベントは実は“オジサン、ハジメテ///”なのである。
もちろん、一人プロジェクトではイベントは動かないから、スポンサーに協力をもらいメンバを寄せ集め、イベントプロジェクトのコアメンバを寄せ集めることと、次のことからはじめる。

アジャイルのエレベータピッチを作る...どんなイベントかを定義する

ユーザストーリ...業務として何をするかを定義する

狙い...ワンセンテンスでこのイベントを表現する

体制...イベント関係者とSOW(statement of work＝役割分担)

調達一覧...お買い物、準備リスト

イベント会場図...会場と関連設備の配置と集客の導線

スケジュール...SOW別の日別の予定

これらは、一つひとつ順番に精緻に作ることはしないし、“してはいけない”。仕事の納期が守れないエンジニアは、例えば上記のようなドキュメントを作ることがタスクだった場合、一つのドキュメントを精緻に作り上げてようとして仔細なところで躓き、前に進めなくなったり、精緻に作り上げてしまったが故に先のドキュメントに進むことですでに精緻に作り上げてしまったドキュメントと矛盾が生じ、手戻りを生じさせてしまうからだ。

なんと言っても、ハジメテのお買い物状態であるから、元来、精緻にできないのである。それそ逆手にとって、全体が見えるように、イベントの地図を描いていく。それは、自分が理解するためでもあるし、メンバとゴールを共有して、“何をしたらイベントが成功するのか”方向を合わせるための“遠足のしおり”であるからだ。

最初に何から手をつけるか
上記の中で最初に手をつけたのは、スケジュールから。それもイベント当日以外はアバウトに、「この週のこの数日の幅で」くらいにタスクをプロットしていく。とにかく思いつくことを日の単位で。次はプロットしたタスクで依存関係があるものを結んでいく。そうすることで、チョー荒いシナリオが浮かび上がってくる。
その次は、人の確保である。ここでいう人の確保は、自分が所属する組織からの距離で遠い人から押さえていく。自分に近い人は融通が利くものだから、そういった優先順位で人を押さえることで、スケジュールを仮押さえしていく。

やっぱりプロジェクトマネジメント
人は言葉ですべてを理解することは難しいから、兎に角、何をどうしようとしているか伝わるものを“揃えながら”展開していくしか他はないのである。それは、“すべてが揃ったら”などというばかげたことを考えてはいけないということである。走りながら考えるから、頭にデータが回り、手に入ったデータで考え、情報にして、足らないデータを知り、それを充足するためのアクションをまわす。
なんか変な理屈のように思えるかもしれないが、このへんなやり方もプロジェクトマネージメントが役立っている。プロジェクトマネージメントのベースがあるから、それを実行する具体的なツールをその都度組み合わせ、なければ適当に走りながら作り上げて、実践に投入していくだけだ。それを実感するだけでもプロジェクトマネージメント万歳である。