将来の技術的負債を作らないチーム作り

マネージャやプロジェクトマネージャがプロジェクトメンバを調達し、アサイメントする際に犯してしまう間違い…それは頭数を揃えてしまうことです。

プロジェクトマネジメントとしてプロジェクトの目的を達成するためには、プロジェクトの目的達成でのアウトプットを作成するために必要とするスキルセットを持っているリソースを調達しなければなりません。もちろん、リソースにはIT機器や人的リソースが含まれています。

マネージャやプロジェクトマネージャは、プロジェクトの立ち上げの準備作業で多忙という言い訳をしてプロジェクトチームとして必要なスキルとスキルレベルを充足するメンバを集めるまでを考慮せず、その手前の人数だけで揃えてしまうのです。これが間違いであり、プロジェクトチームに見積もりやプロジェクト計画で考慮されていないリスクを潜在的に抱え込ませることになるのです。

こうしたエンジニアの調達をどこかで見かけた記憶はありませんか。

そう、大規模プロジェクトの多重契約で見かける風景です。javaが書けるということになっているエンジニアを頭数だけ揃えて、あとはプロジェクトで教育してください、というやつです。これがどれだけプロジェクトにリスクを持ち込んでいるか、将来の技術的負債を持ち込んでいるかわかっているかを小1時間問い詰めたいし、負債解消のためのコスト負担を請求させて欲しいくらいです。 

どっちのチームがお好み

あなたがプロジェクトマネージャだとして、次のどちらのチームでプロジェクトを回したいですか。

  1. プロジェクト計画の見積もりで必要なエンジニアの頭数を揃えたチーム
  2. プロジェクト計画で必要なスキルセットの充足には一部足らないが精鋭なチーム

 個人的には項番2を選択しますが皆さんはどちらを選びましたか。

心理的に必要とするリソースを埋めたくなるのはわかります。でも、どちらを選ぶにしてもメリットデメリットがあるわけです。

将来の技術的負債には何があるか

 チーム1の将来の技術的負債にはどのようなことがそうてできるでしょうか。

  • チームとして必要とするスキルとスキルレベルを充足できない。
  • スキルとレベルに満たないエンジニアの教育コストが追加でかかる
  • スキルとレベルに満たないエンジニアのフォローのためにコミュニケーションコストが積み上がる
  • スキルとレベルに満たないエンジニアのフォローのためにできるエンジニアのリソースを使ってしまい進捗が出ない
  • メンバ別のスキルとレベルに満たないエンジニアのアウトプットがプロジェクトの品質目標に満たず修正コストが積み増す
  • スキルとレベルが足らないエンジニアの成果に対し、期待していた成果分のキャッシュアウトが発生する

将来の技術的負債の観点で抽出しているのでデメリットばかりです。スキルとスキルレベルが未達でも投入せざるを得ないケースも組織的な戦略上取らなければならないケースもあります。それは若手や技術転換などのエンジニアの育成です。このケースの場合は、組織からの財政的支援やKPI的な数値の引き下げなど組織的なサポートを考慮しつつそれでも行われるのは教育なので将来の投資の観点があり、将来的にはプラスになることを期待するからです。

 

チーム2の技術的負債で考えられることは何でしょうか。

 

  • プロジェクトチームとして必要とするスキルとレベルが不足した状況で運営せざるを得ない。
  • 進捗はメンバのスキルとレベルが充足される場合と比較して遅れる。
  • メンバに負荷が掛かる。

 

 でも、このくらいなんですよ。ここのエンジニアに対してのスキルレベルが必要とする分だけは充足されているので作成するアウトプットの品質は期待できます。

遅れることを是としてスケジュールを引けば、ですが。

さらに、低レベルなエンジニアが混入してこないのでコミュニケーションコストは想定の範囲で済みますし、期待するスキルとレベルを持っているのでフォローアップは必要ないので想定外のコストを払い出す必要もありません。

進捗についてさらに言えば、チームに必要とするフルなリソースでの計画に対して、足らない分だけの遅延で済みます。

将来の技術的負債を作らないチーム作りのメリット

育成以外であれば、無理して適切でないエンジニアをよそから持ってこない方がプロジェクト最適化の考えからいえば、ベターな判断です。

とはいえ、全く途中でエンジニアを補充しないのもアレです。基本的にはマネージャやプロジェクトマネージャは、不足した状態でプロジェクトを始めるなら、それでできる範囲でのスケジュールを引いてステークホルダと協議し、受けれてもわなければなりません。

ただ遅れるよという伝え方もありますが、プロジェクトの計画を多段階にする(=ステップ分けをする)など見せ方の工夫もできますし、全機能のリリースリミットを伸ばせるなら、人的リソースの面積は伸ばした方が品質管理上の観点からも合理的です。

まあ、その際には段階的リリースをすることでのメリットを前面に持ってくることが必要でしょうが。

 

 

人材開発研究大全

人材開発研究大全