プロジェクトマネージャという仕事(その11)
おはようございます。YO茶でございます。
久々にこのシリーズ書いてみたいと思います。
プロジェクトマネージャが、プロジェクトを進めるにあたって管理すべき項目というのはいろいろあります。スケジュール管理、コスト管理、リスク管理などなど。
で、そんな管理を行う中でも、リソース管理は非常に重要な管理項目だということを経験しました。リソース管理とは、プロジェクトを進めるために必要な人員の管理です。タスクに対して割り当てている人数は適切か、足りない場合に何人、どの期間増員するのかなどを判断していきます。
これはなかなかに苦労しました。例えば、設計を実施するフェーズでエンジニアの稼働がものすごく高くなったとします。ところが、設計というものは単純に人を追加すれば事足りるわけではありません。モジュール化して開発できるシステム単位であれば人の追加は考えやすいのですが、今回導入したシステムは、最初から一人で設計をしていかないと整合性をとりにくい性質をもっています。
なので分担するとしたら最初から参加していないと難しいのです。途中でポッと入ったとしても、その人にそれまでの設計方針やら内容を伝えるのにすごく時間がかかる。ただ、エンジニアがパンパンになっている状態でそんな説明をする時間を作ってもらう余裕はないのですよね、往々にして。
結局人を追加しても、効果的にメインエンジニアの稼働率が下がることはなかなかありませんでした。また、稼働時間というのはそのエンジニアの気質と能力にも影響します。
普通工数を計算する場合、エンジニアの能力は均質であるという前提で計算されます。しかし、これがそもそも間違いで、同じグレードのエンジニアでも経験年数がちがっていたり、得意な分野があったりで、必ずしも予定していた工数で設計が終わるとは限りません。これはエンジニアを経験してきたのでよくわかるのですが、そこまで細やかに一人一人の特質を考慮した工数計算はしませんね。
結局、最初から入っているエンジニアのミラクルながんばりに頼ってしまうというのが実情になってしまうのでしょうか。
この問題を解決しようとするのであれば、テンプレート設計を進めて行く事です。おおまかな設計項目は共通項目で設計しておき、あとはお客様によって可変なパラメータのみヒアリングしていくというスタイルを徹底化するということになります。
ただ、システムを一から理解しているエンジニア、特殊要件に対応できるエンジニアの育成ができなくなってしまいます。エンジニアとしては面白くないでしょうね。
これは組織論にもなってくる話なので、これくらいにしましょう。
そして、展開フェーズ。これはもう、お客様の都合で予定していた日程が変更になったりしたときの人の工面には苦労しました。最後は、本当に現場レベルの方々の都合をうまくつけてもらうことでなんとか乗り切った感があります。私が管理したとかいうよりは、現場に助けてもらった、ただそれだけだったと思います。
プロマネは人の稼働時間をモニタリングし、足りなくなさそうだと察知したら人の手当を前倒しでできればいいのですが、今度はコストと人材の問題もあります。そもそも人を増員するということはコストが上がります。お客様からの追加要件による稼働増加であれば追加料金を要求できます。(受けてもらえるかどうかはさておき)ただ、これが自分達の見積もりミスだったとしたらなんとかするしかありません。今回はお客様が追加料金を比較的払って頂けたので非常に助かりました。
で、人材。人がほしくても、いなかったらどうしようもありません。そういうときは社外のリソースを使ってでもなんとかしなければならない場合もあります。今回はある追加要件(ここは、お客様ともともとお願いしていた部分だった、と見解の相違があって揉めた所だったのですが)を満たすために、社外からリソースを用意しました。
リソース管理のポイントは、適切な人員配置によって、予定していた稼働率でタスクが進んでいるかチェックすること、それが許容範囲を超えて人が足りないとなったときに、適切な人材を適切な期間配置するよう手当し、プロジェクト成功へと導くことかなと思っています。
今回のプロジェクトの振り返りを行っていますが、リソース管理については、結果からいうと「自分がエンジニアとして感じた感覚にしたがってリソース手配をすることでうまくいった」でした。これは私個人としては良かったですが、本来のプロジェクトマネージャとしては正しくないかもしれません。
この「感覚」をどう共通化できるのか。そこは私の大きなテーマとなりそうです。
梅雨に入り、空には雲がひろがっていますが今日も一日頑張って行きましょう!!
#日々感謝 m(_ _)m