IT 管理: キャパシティ プランニング
プロジェクトの作業負荷について効果的で正確なキャパシティ プランニングを行うには、データ駆動型のシステムが必要です。
Ryan Haveson
私のスターウォーズのお気に入りのせりふは、ルークが、フォースを使って沼から彼の戦闘機を引き上げてみることをヨーダに伝えたときのせりふです。よく知られているように、ヨーダは、「やってみる、ではない。やるのだ。試しなどいらん」と言ってルークを叱りました。これは、ソフトウェア エンジニアにも適切なアドバイスです。
チームが納期を守れないことに気付いたときの気分は、チームのリーダーとして抱く最悪の気分の 1 つです。これは多くの理由から悪い状況です。納期が近づくにつれて、メンバーはいつも以上に懸命に働く必要があります。失われた時間を取り戻すために、深夜や週末に働く場合もあります。そのうえ、多くの場合、このような状況においては工程を省かなくてはなりません。これは、品質の低下を意味します。
納期になって、納期が過ぎても、プロジェクトが完了していなければ、そのような重労働は評価されません。あるのは納期を守れなかったという失望感だけです。悪いことはそれでは治まらず、納期に間に合わせるために省いたすべての工程によって、コードの状態はおそらく最善ではありません。このような "やってみる" の結果、標準以下の成果物が完成し、メンバー全員に嫌な後味が残ります。
厳しい納期で対応することをメンバーに強要しながら、同時にメンバーが背負える作業量について現実的に考える必要があるときが、マネージャーとしてバランスを取るのが難しい場面の 1 つです。作業量を見積もるのは困難です。これが、開発手法としてアジャイルが使用される理由の 1 つです。アジャイルでは、キャパシティ プランニングが特別得意である必要がないからです。
とは言え、数か月に及ぶプロジェクトでは、最終結果の状態と、最終結果に到達するまでに要する労力について予想を立てる必要があります。キャパシティ プランニングを習得するには、年単位の経験が必要ですが、メンバーが多くの作業量を背負い込みすぎている明確な兆候の 1 つは、「やってみる」という返事です。
全力を尽くす
だれかが「やってみる」と言うとき、私はすぐに頭の中で、「全力を尽くします。終わらせられないかもしれませんが、少なくとも、納期に間に合わせるために残業や休日出勤で対応しようと思います。納期に間に合わなかったとしても、私の責任は追求しないでください」と言っていると翻訳します。これは管理と対応が難しい状況です。だれかが無理をする (自分のキャパシティを広げて業務を引き受ける) ための熱意をくじくことは望まない一方で、チームとリーダーは労力ではなく結果に責任を負う必要があります。
だれかがミッション クリティカルなタスクについて「やってみる」と言った場合、私はいつも「やってみるより、できないと言ってくれた方が良い」と返します。「できない」という返事に対しては、さまざまな方法で計画が立てられます。たとえば、そのプロジェクトにより多くの人員を追加することができます。また、タスクの範囲を変更したり、詳細を調べて、あいまいなことを明確にし、タスクをより簡単なものにすることもできます。
「やってみる」という返事に基づいて計画を立てるのは困難です。リスクヘッジのために、プロジェクトに別のメンバーを投入する必要があるのでしょうか。それは非効率です。それでは、納期に間に合わない可能性が高いという見込みが既に立れられているにもかかわらず、このメンバーが納期に間に合うと盲目的に仮定するのでしょうか。それは賢明ではありません。
では、このような潜在的な危険はどう回避すればよいのかというと、メンバーが安心して「できない」と言える環境を作るのです。ほとんどのマネージャーは、自分のチームのだれかが「できない」と言うことを嫌がります。結局、それは弱さの証だと思うのでしょう。そのメンバーが単にもっと賢いか、もっと働き者であれば、その作業を終わらせられると考えるのが自然な思考過程です。この思考過程のもう 1 つ側面として、自分の印象を悪くすることを懸念して、人はできないということを嫌がります。
結局のところ、1 人の人間が成し遂げられる作業量には限度があることを覚えておく必要があります。メンバーがタスクを完了するかしないかは、メンバーのスキルと経験にかかっています。士気を鼓舞して、権力に物を言わせている間、メンバーはいつもより 10 ～ 20% 懸命に働きますが、生産性が 2 倍になることはありません。「できる」と言ったのにできないことは、「できない」と言うことよりも、印象が悪くなります 。メンバーが自分の限界とキャパシティを知るように促しましょう。最終的には、納期を予測して、納期に間に合わせるチームの能力が向上します。
チームのキャパシティを測定する科学的でデータ駆動型の方法が必要です。チームのメンバーが安心して「できない」と言えるようにすることについての教訓は学んだと思います。しかし、上司や幹部役員は、依然として、不可能な納期について「できる」とメンバーに言わせることが、優れた管理手法だと考えている可能性もあります。
協力的な環境で働いている場合でも、大きなチームの管理と何か月にも及ぶ作業の計画に対応しなければならない場合、単純にチームのキャパシティを推測に基づいて見積もるのでは不十分です。チームの総合的な処理能力を測定するためのデータ駆動型のモデルを導入する必要があります。考慮が必要な要素には、次のようなものがあります。
- 見積もりに対する実績を追跡する: チームが作業を開始する前に作業の見積もりを行うモデル (ウォーターフォール モデルとアジャイルモデルのどちらか) を採用している場合、メンバーまたはチームごとの見積もりコストに対する実際のコストを追跡します。その情報に基づいて、チームが適切に見積もっているものと、適切に見積っていないものの表を作って公開することができます。自らの指標を操作したり、見積もり方法を習得中のチーム メンバーと話し合い、指標の改善やメンバーの成長に役立てましょう。そうこうしているうちに、少なくとも自分の誤差幅は把握できるようになります。このようにすると、スケジュールを設定するときに、スケジュールに含める必要があるバッファ時間の判断材料の 1 つとして使えるデータを手に入れることができます。
- 寄せられるバグと修正するバグのペース、未処理分を追跡する: 一部のチームでは、寄せられる要求、バグ、および問題の未処理分を徐々に減らしています。(いくつかの 1 ～ 2 日単位のプロジェクトなど) 作業項目の規模がだいたい均一であれば、チームの総計を単純に追跡するのも容易な場合があります。バグが寄せられるペースとバグを修正するペースが等しければ (つまり、未処理分の量がだいたい安定していれば)、最大生産能力が発揮されています。未処理分が増えている場合、チームが要求のペースに付いて行けない状況に向かっているおそれがあります。チーム メンバーが大局を理解できるように、これらのメトリックスを公開し、このメトリックスを使って、幹部役員とリソース計画の話し合いを進めましょう。
- スケール ポイントをモデル化する: カスタマー サポート グループなどを管理している場合、ユーザー数によってチームの作業負荷が増減する可能性があります。寄せられるヘルプ要求数とユーザー数の間にある相関関係を示せるなら、会社の売り上げ予測を将来のリソース ニーズの見積もりに役立てられます。自分のチームが現在のコード ベースの維持にチームの時間の 10% を費やしている場合、今後のプロジェクトのキャパシティを見積もるときには、そのことを忘れないでください。スケール ポイントのモデルがあると、既存のデータに基づいて、さまざまなシナリオの結果を予測できます。
「できない」と言うことを学ぶ
自分自身が模範として先頭に立ち、それが正しい答えであるときには、「できない」と言いましょう。「できない」と言うことには、さまざまなメリットがあるにもかかわらず、実際に口にするのが難しい会話の 1 つです。何かができないと聞くことが好きな人はいません。自分や自分のチームの処理能力以上の作業を引き受けるように頼まれたときには、自分のデータ モデルについて話すことによって、その会話をリードすることが重要です。
ほとんどの人が数学を嫌っていますが、ほどんどの幹部役員はデータ駆動型のモデルに基づく会話に反応します。チームのキャパシティとスループットのモデル化が完了したら、スケール ポイントのモデルを持つようにしてください。既に権力に物を言わせて、いつもより 10 ～ 20% 高い生産性を確保している場合は、何ができるのかについての会話に適切な背景を設定する必要があります。チームがより多くの作業を行えるかどうかという議題に焦点を当てるのを止め、既存の作業と比べた場合の新しい作業の相対的な優先度に焦点を当てましょう。
次にだれかが「やってみる」と言ったら、ヨーダの言葉「試しなどいらん」を思い出してください。チームを駆り立て、チームの作業に切迫感を作り出す必要がある一方で、チームが価値ある情報を提供しなくなる一線を超えてチームを駆り立てることには注意する必要があります。それが正しい答えであるときでさえ、メンバーが安心して「できない」と言えない場合、有害無益にしかなりません。
チーム メンバーの言葉をうのみにしないでください。チームの総合的なキャパシティに関する科学的でデータ駆動型のモデルを持ちましょう。このモデルにより、キャパシティ プランニングがうまくなり、幹部役員とリソースやプロジェクトのスコーピングについて話をするのに役立ちます。
最終的には、マネージャーの成功は、結果を出すことにかかっています。納期を守れなければ、自分の信頼が損なわれます。自信とそれを裏付けるデータ モデルがあれば、チームが引き受けられる作業についての会話で優位に立つことが可能になり、自分自身とチームが大きな成功を収める態勢を整えることができます。
.jpg)
Ryan Haveson は、エンジニアリング チームを統率し、世界的に有名なブランドである Xbox や Windows などのソフトウェアとサービスの提供に 15 年以上携わってきました。Ryan は、Windows 8 の Windows エクスペリエンス チームのグループ マネージャーを務めていました。Windows エクスペリエンス チームでは、ライブ タイル通知プラットフォームや新しいタスク マネージャーなど、エンド ユーザーと開発者向けの機能をデザインして実現しました。現在は、米国カリフォルニア州のサンディエゴにある Qualcomm の Snapdragon 部門で Windows と Windows Phone のエンジニアリング システム グループを統率しています。連絡先は、ryanhaveson@hotmail.com (英語のみ) または linkedin.com/in/ryanha (英語) です。