イラスト：Alamy / PHOTAS
図 1.プロジェクト管理会議
Robert Vysotskyのモノグラフ 「Adaptive Project Management：Traditional、Flexible and Extreme Techniques」に記載されている既存のプロジェクト管理方法論の比較分析を使用します。 この本の第7版は最近、英語圏の聴衆が利用できるようになりました。 私の知る限り、まだロシア語に翻訳されていません。 残念なことに、この本は素晴らしいもので、明らかにアメリカのアマゾンでは無駄ではありません。Adjayl文学の中で4番目の評価を得ています。
先に進む前に、この記事および以下では、プロジェクト管理手法の理論的基盤であるフレームワークのみに関連する問題のみを検討することを読者に警告します。 これらの手法の実用化に関連するトピックを含む、他のトピックは考慮されません。
さまざまなタイプのプロジェクトライフサイクルを分類することから始めましょう。 以下は、ヴィソツキーの本で与えられた比較スキームと比較して、いくらか簡略化されています。
図 2.プロジェクトのライフサイクルと管理手法の種類
図2からわかるように、5種類のプロジェクトライフサイクルは、プロジェクトの既に完了した段階の1つに「ロールバック」する能力（または不可能）によって互いに異なります。 Vysotskyに続き、プロジェクト管理手法のこの特性は適応性と呼ばれます。 または、言い換えれば、適応性とは、ライフサイクルのさまざまな段階でプロジェクトの構成と作業計画を変更するためのプロジェクト計画およびプロジェクト管理方法論によって提供される機会です。
ライフサイクルモデルがダイアグラム上にあるほど、それに基づいた管理手法の適応性が高まります。 そのため、たとえば、Vysotskyによる最大限の適応性を備えた極端な管理手法により、プロジェクトのライフサイクルの最初に「ロールバック」し、プロジェクトの目標に至るまで大幅に変更することができます。
もう一度、Vysotskyの分類をわずかに変更して、上記のタイプのライフサイクルを2つのグループに結合します。 2種類の色：
-クラシック：つまり、完全に準備された作業の階層構造（以下JISと呼びます）およびプロジェクト計画は、作業の実行中に変更されません。 わずかな変更が許可される場合がありますが、Vysotskyが書いたように、通常よりも例外として可能性が高い
-アジャイル：いつでも勝手に「ロールバック」できる柔軟な最新技術。 これは、事前に計画されたサイクルに従って、定期的に実行できます。 JISを予備的に完全に割り当てる必要はありません。
それでは、プロジェクトの適応性と複雑さを座標で管理技術の2次元の世界の
まず、プロジェクトの複雑さの意味を決定します。
複雑さとは、作品の総数ではなく、JISとプロジェクトの個々の作品を組み合わせた作品間の関係の構造の複雑さを意味します。 実際には、プロジェクトはこのように定義されます。それは、作業全体だけでなく、個々の作業をプロジェクトに結び付ける関係のユニークな構造でもあります。
下の図3に示す図で、プロジェクトの複雑さの概念を説明しましょう。
図 3.プロジェクトの階層システム
最も単純なプロジェクトは、次の2つのレベルのみを使用して適切に説明できます。
図3：「レベル0」-プロジェクト自体と「レベル1」-プロジェクトコンポーネント。 プロジェクトを記述するためにより多くの階層レベルを持つ階層構造を使用する必要がある場合、プロジェクトは複雑です。 作業、リンク、階層レベルが多いほど、プロジェクトの複雑度は高くなります。
これでマップに戻ることができます-図に示されています。 4。
図 4.プロジェクト管理手法
図4では、プロジェクト管理手法の世界は、緑、黄色、青の3つの長方形と、右上の白い領域に分割されています。
黄色と青の長方形の交点である緑の長方形の内側は、最も単純なデザインです。 実務経験のあるプロジェクトマネージャーは、プロジェクトが非常に単純であるため、方法論の選択がそれらを管理するのにそれほど重要ではないことに同意するでしょう。 ここでは、クラシックとアジャイルの両方が機能します。
黄色の長方形は古典的な手法です。 かなり複雑なプロジェクト管理を利用できます。 古典的な方法の範囲は、上記からVysotskyに関して前述した適応性の限界レベルに制限されています。作業を開始する前にJISとプロジェクト計画を準備する必要があります。 この境界線は多少ぼやけています。 前述のように、WBSと計画の変更は許可されていますが、例外としてのみ許可されています。
この制限の理由は何ですか？ 簡単です。WBSとプロジェクト計画を作成または変更するとき、作業間の関係を手動で設定する必要があります。 定期的に、各スクラム後に、通信システム全体を手動でやり直さなければならないことを想像してください。 カールアダメツキー後ほぼ120年間、何も変わっていません。 鉛筆の代わりに、人はコンピューターのマウスとキーボードで作業する必要があります。 率直に言って、これは退屈で骨の折れる仕事です。 そして、ヒューマンエラーの原因。プロジェクトの複雑さが増すにつれて、その数は非線形に増加します。 手動で関係を確立する必要があることは、古典的な技術の柔軟性に対する制限であるだけでなく、建設や産業などのアプリケーションの古典的な領域でも複雑なプロジェクトの管理を複雑にする重大な欠点であることに注意してください。
小さな歴史的発言。 前の段落で述べたサンクトペテルブルク実用技術研究所の卒業生であるカール・アダメツキーは、1896年にロシア帝国技術協会の会議で、後にヘンリー・ガントによって命名された彼のダイアグラムの発明について報告しました。 そして同じ年に、アンリベクレルは放射能の現象を発見しました。 過去1世紀にわたって、核物理学と産業はかなり進歩しました。 プロジェクト管理理論はどうですか？ 私たちはまだ、昔ながらの方法で主な作業を手動で行っています。 世界中の数十万人のアクティブユーザーを抱える近年のファッションアプリケーションとサービスのUIとUXでの顕著な成果は、この悲しい現実を装飾するだけですが、完全に隠すことはできません。
したがって、この要因であると想定します。図に示すように、関係を手動で確立する必要があるため、上からの古典的な手法の範囲が制限されます。
柔軟またはアジャイル技術の範囲-図4の青い長方形も制限されていますが、右側にあります。 「この制限の定義は何ですか。この境界は座標系の水平軸とどこで交差しますか？」という質問に答えてみましょう。
Joel Spolskyはかつて彼のブログで私たちの目的に非常に適した言葉遣いを与えました：「...接続は非常に明確であるため、正式な追跡にエネルギーを浪費することは意味がありません」少し一般化すると、シンプルな通信システムと最小限の階層レベル。 しかし、適応性のレベルに制限はありません。 プロジェクトの複雑さの低さ、または上記のように、接続の完全またはほぼ完全な不足は、高い適応性を確保するために支払われる価格です。 また、Robert Vysotskyの定量的評価によると、プロジェクト（ソフトウェア開発を含む）の総数の80％で機能しました。
図面、より正確には、右上の神秘的な白い領域に戻りましょう。 おそらく、最も興味深いのは白い長方形の中にあるのでしょうか？ そうだと思います。 これは複雑なプロジェクトのための場所であり、その管理は柔軟な技術なしでは行えません。 複雑なソフトウェア開発プロジェクトはこちらです。 また、非常に高い不確実性を備えた革新的なハイテクもここにあります。 当然、ハードウェアとソフトウェアの共同開発プロジェクトもここにあります。 そして、複雑さの軸に沿って右に進むほど、そこで面白く、より革新的で、より高価なプロジェクトに出会うことになります。 これらの残りの20％には、上記の80％よりもかなり多くの資金が投資されていると思います。 そして、この傾向は1年以上有効です。
そのため、白い長方形の内部を快適に移動するには、プロジェクトの内部構造を考慮するだけでなく、その場で簡単に変更する方法を学ぶ必要があります。 これにより、あらゆる程度の適応性を備えた複雑なプロジェクトを管理できます。
作業を開始する前にプロジェクトのSRIを決定できませんか？ 怖がらないで、行方不明のコンポーネントを描きます。 すでに計画されているコンポーネントや完成したコンポーネントの一部を放棄しますか？ ISRから除外するだけで問題ありません。 WBSのコンポーネント間の関係のシーケンスを変更して開発シーケンスを変更したいですか？ お願いします。 時間や労力の予備的な見積もりを放棄しますか？ 問題ありません。
そしてさらにそれ以上。 そして、あなたが望んでいない場合、またはあなたは前もって特定の管理手法の枠組みに自分自身を制限することはできませんか？ 図1に示されている5つのフレームワークのうち1つだけを
もしそうなら、質問をしてみましょう：プロジェクト管理で可能な大統一理論の類似物は可能ですか？ 図1に示されている5つの異なるタイプのプロジェクト開発すべてを、可能な限り汎用的な単一の柔軟なフレームワークに結合することは可能ですか？
単一のフレームワークを使用する完全な汎用性または最大の柔軟性を確保するために何が必要ですか？ このためにリンクの自動化を使用してみましょう。 この作業を人からコンピュータに転送することが可能かどうか、そしてこの方法で目標を達成できるかどうかを見てみましょう。
読者が容易に推測できるように、著者はこれを行う方法について提案しています。 しかし、それについては次の記事で詳しく説明します。