見出し画像

“合流地点”を意識するとプロジェクト進行がうまくいく

こんにちは、poipoiです。

私はテクニカルディレクターという職種柄、プロジェクトマネージャーを兼任することが多々あります。

これは自身で開発を行ったことがない方がテクニカルに関わるスケジュールについて勘所を働かせることが難しいことや、開発という行為自体が不確定要素のオンパレードであるため単純な日割りベースでのスケジュール立てが難しいことなど、開発に知見のある立場の人間がプロジェクト進行を務める必要があるためです。

そこで、私が普段プロジェクト進行をするうえで行なっている
「テクニカルディレクター目線で考えるプロジェクトマネージメント」
の TIPS のようなものを少しずつ紹介していこうと思っています。

初回は「合流地点を意識してプロジェクトを進行する」ということについて。


プロジェクトは依存関係でできている

私はプロジェクトマネージメントを担当しスケジュールを組む際に、各タスクの「依存関係」に意識を向けるようにしています。

プロジェクトは依存関係の塊です。

企画やデザイン、開発や運用…。さまざまな要素がそれぞれに影響し合い、絡み合いながらプロジェクトを構成しています。

その中でも特に、タスク同士の“合流地点”には注意が必要です。

・ワイヤーフレームが出来上がらないとデザイン作業に入れない、とか。
・デザインが完成しないとプログラムに組み込むことができない、とか。

こういった、タスクとタスクが合流してはじめて次の作業に移れる合流ポイントは非常に重要です。
例えば上記の例でワイヤーフレームの作成が遅れてしまうと、後に控えているデザイン作業が連なって遅れてしまうことになります。

こうなると、この合流地点が遅れたばかりにこれ以降のタスクがすべて芋づる式に遅れて行ってしまい、ひいてはプロジェクト進行全体が遅れてしまうことになります。
これはつまり、タスクの合流地点がプロジェクトのボトルネックに相当しているということを意味しています。

なので、このボトルネックに意識を向けてプロジェクトを管理することによって進行の遅れやつまずきを回避することができます。

例えば、大きい合流地点(デザインと開発のすり合わせ、開発から企画へのフィードバックなど)はプロジェクト初期に必要になりそうな項目を洗い出ししておいてマイルストーンとして設定。あらかじめ周知しておくことで全体の流れをプロジェクトメンバ全員で共有して意識できるようになります。

また細かい合流地点は都度、それぞれの担当者間のやりとりをウォッチしておいて、遅れやコミュニケーションがうまくいっていなさそうな雰囲気を感じたらキャッチアップする。

などなど、合流地点に意識を向けて適切にハンドリングするだけでも、ボトルネックを回避しかなりスムーズにプロジェクトを進行させることができます。

またプロジェクトマネージャーとしても、マイクロマネジメント的に個々の細かいタスクの進行を管理していなくても、合流地点のみに気をつけていれば良いため、自分の指示の遅れによって自分自身がボトルネック化しまうことを防ぐことにもなります。
(もちろんこの理由だけでなく、マイクロマネジメントはチームの生産性を下げるので避けるべきではありますが。ここら辺はまた後日書きたいとお思います。)


応用編 : 合流地点を前倒す

また私がよくやる応用テクニックとして、タスクの合流地点を前倒す、というのがあります。

たとえば、Aさんがセンサデバイスを開発し、そのセンサデータをBさんが開発するシステムで利用する場合。

普通に積み上げ式で開発を進める場合、AさんBさんがそれぞれの足並みで開発していき最後にシステム連携をさせる、というような進行になりがちです。
ですがこういった進め方をしてしまうと、どちらかの作業が遅れた場合にもう一方も引きずられて作業が遅れてしまいますし、プロジェクトの後半で齟齬が発覚した場合などは目も当てられない状況になりかねません。

こういった時、プロジェクト初期の時点でAさんにダミーデータを送信する簡易的なシミュレータを作ってもらい、あらかじめBさんに共有してもらうよう段取ったりします。

こうすることで、プロジェクトの初期段階でお互いにすり合わせができるため早い段階で齟齬を解決することができ、土壇場ですれ違いが発覚するような事態に陥りにくくなります。
またすり合わせ以降は個々が独立して開発を進められるため自身の開発に集中しそれぞれの足並みで作業することができるようになります。

このように、合流地点のうち、本質的にどの部分がボトルネックになるのかに意識を向け(今回の例の場合は、通信仕様のすり合わせがボトルネック)、
その部分のみを抽出して前倒しにすることによって、プロジェクトの進行をよりスムーズにすることが可能になります。

こういった形でタスク同士の合流地点を意識することによって、ボトルネックを極力なくしたりうまくコントロールしながらプロジェクトを進行していくことが可能になります。


おまけ : タスクの依存関係を表せるツール

タスク同士の依存関係を表すことができるプロジェクト管理ツールを使うことで、上記のような状況をチームで可視化することが可能です。

こういった依存関係に着目するマネジメントが一般的ではないのか、まだ私の中でも決定版となるツールに出会えていないのですが、参考までにいくつかあげておきます。

Mammoth Project

まさにタスクの依存関係に着目してプロジェクトを組み立てることに着目しているプロジェクト管理ツール。プロジェクトマップというタスクの依存関係を表す図のほか、ガントチャートやカンバン方式でもタスクを閲覧することが可能。

Wrike

言わずと知れた多機能プロジェクト管理ツールです。タスク間の依存関係が設定でき、ガントチャート上で閲覧することが可能。

Draw.io

ブラウザ上で図を書くツール。プロジェクト管理ツールがうまくなじまなければ図として書くのもアリかも。UMLのアクティビティ図がタスクの合流を表すのに合っているのでそれを使って書くのも良さそうです。

この記事が気に入ったらサポートをしてみませんか?