エンジニアがプロジェクトマネジメントする時に個人的に気をつけていること

nyakuro

自分がウェブ系のプロジェクトの進行をする時に、何気なくやってることを明文化してみた。

今回の話の範囲

・プロダクトの方向性チェック
・プロジェクトマネジメント
  ・リリースフェーズを分けたりとかの大枠のマネジメント
  ・やることの大枠が決まった後のフェーズ内のマネジメント -> 今回はここ

若手に一本プロジェクトを任せる前に伝えておこうかなと思って書きなぐったやつです。
今回は、PdM側ではなくエンジニア側がある程度スケジュール管理をしなければならない状態を想定しています。

※ これはnyakuroの場合のやり方です

nyakuroの経験則、nyakuroの特性に最適化されたものを書いてます。
自分は、「無駄な仕事を削って同等の効果を得たいタイプ」なので、別のタイプの人は一部合わないかも。

ちなみに、16TESTをやってみたらこんな感じでした。

今回の記事は、個人的な経験則をまとめただけなので、FACT的な所が不足してますが許してください。

さて、ここからが本題です

今考えなくて良いことは考えない

最初から全部を考えて動く必要があると思いこみがちだが、自分はそうは思わない。

プロジェクトの最初の方は不確実性の嵐。
不確実度が高い事に対処していくのは、かなりコスパが悪い。
なぜなら、不確実故に色々なパターンを想定せねばならなく、更にはせっかく色々想定してもどんでん返しを食らっておじゃんになる可能性が高いから。
色々なパターンを作ることも、おじゃんを食らう前に行っていた作業も、究極的には無駄なコストといえる。

先に他の部分を作って外堀を埋めていくことで、不確実性が高かった部分の確実性が次第に上がっていく。
機能の解像度が上がって未決定の総量が減ることで、不確実足らしめていた変数が減るから。
確実性が上がった時に取り掛かると無駄な作業までやる必要がなくて良い。

今対処する必要のあるものを漏らさない

考える事を減らしていくと、今対処する必要のあるものがより浮き彫りになっていく。
今決めないとリリースが遅れる…というクリティカルパス的なものは優先的に対処していく必要がある。

最初は全体を大枠を作り、後から詳細をつめていく

これも不確実性とセットの話題。

最初は確実性の高い大枠を作る。
これを行うと、スケジュール面での不確実性が減る。
どの機能にどの程度の時間がかかるかが体感的につかめ、見積もり誤差が減る。

作っているうちに気づくことも多い。
仕様の抜け漏れとか、不便な部分とか。
それをPdMやデザイナー、別のエンジニアにフィードバックして更に詳細をつめていく。

逆にいきなり細かい所まで作ろうとすると、
仕様が変わった時にせっかく作ったものを破棄せざるを得なくて無駄が生じたり、仕様の不備に気づくのが遅れてしまう事がある。

それらを防ぐためにまずは大枠から、全体が俯瞰できるような形で作っていく。

途中進捗を確認する

仕様決定、デザイン、詳細設計。
どれも1発で完璧なアウトプットが出てくることはまずない。

例えば、エンジニア的に仕様を1/31までに作って欲しいとする。
その場合、1/31に仕様確認をしていては遅い。
ほぼ100%そこから更にリテイクが必要になって、仕様の納品が更に遅れることになる。
であれば、締め切りよりもさらに前に進捗を確認する必要がある。

当事者意識を持つ。自分の領域内に閉じこまらない

弾を投げたから、もう自分の責任外…ではない。
プロダクトを無事リリースできるまでが自分の責任。
プロジェクト進行に問題が発生しそうだと気づいたら自ら弾を拾っていく必要あり。

強い気持ちでコミュニケーションをとっていく

その時その人をイライラさせてしまうかもしれないが、必要なコミュニケーションはこまめにとっていく。（もちろんイライラさせないに越したことはないが）
その後、確実に救われるので。

その手の詳しい人に意見を求める

部署内外の詳しい人に直接聴く。
社内に部署を横断した集いなどがあれば、そこでも聴いても良さそう。
色々駆使して意見を集める。

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