組織（チーム）とマネジメントとリーダーシップ

はじめに

自分がPM（プロジェクト・マネージャ）やPL（プロジェクト・リーダ）と呼ばれるポジションにアサインされるようになり、組織（チーム）とマネジメント及びリーダーシップについて考えるようになりました。私の現時点での考えをここにまとめます。

マネジメントとリーダーシップとは

まず、「7つの習慣」から引用します。

マネジメントはボトムライン（最終的な結果）にフォーカスし、目標を達成するための手段を考える。それに対してリーダーシップはトップライン（目標）にフォーカスし、何を達成したいかを考える。ピーター・ドラッカーとウォーレン・ベニスの言葉を借りるなら、「マネジメントは正しく行うことであり、リーダーシップは正しいことを行う」となる。成功の梯子を効率的にうまく登れるようにするのがマネジメントであり、梯子が正しい壁に掛かっているかどうかを判断するのがリーダーシップである。
出典：完訳 7つの習慣 人格主義の回復

ここで言えることは、役職としての「マネージャー」「リーダー」と役割としての「マネジメント」「リーダーシップ」は異なるということです。
開発プロジェクトであればプロジェクト・マネージャ(PM)／プロジェクト・リーダ(PL)という役職を設けることがしばしばあります。そして、PMがプロジェクト全体のマネジメント、PLが機能（開発・テスト、時にはサブシステム）をリードするという分担を行ったりします。
これは一見すると「マネジメント」と「リーダーシップ」が分離されているように見えます。ですが、実際には役職を問わず（PM/PL、もしくはメンバーであっても）、この2つの役割を切り替えながら仕事を進めているはずです。
例えば、PMはQCD(Quality, Cost, Delivery)の目標を設定します（リーダーシップ）。そして、その目標を達成するためにプロジェクト・マネジメントの手法を駆使します（マネジメント）。時に目標設定が達成困難と判明し、目標を再設定します（リーダーシップ）。そして、新たな目標に向かってプロジェクトの立て直しを図ります（マネジメント）。このように、PMは「マネジメント」と「リーダーシップ」という役割を切り替えながらプロジェクトを前へ進めていきます。

ケネディスクールのロナルド・ハイフェッツ教授は「NHK リーダーシップ白熱教室」でリーダーシップを「問題に立ち向かい、大勢を動かす手腕」としました。
書籍「アート・オブ・プロジェクトマネジメント」では「Ⅲ部　マネジメント」に「12章　リーダーシップが信頼に基づく理由」が含まれています。
これらからは一見、リーダーシップにマネジメントが含まれている、もしくはその逆のようにも取れます。ですが、その講義及び本の内容から考えると、リーダーシップとマネジメントは分けて考えるべきだが、その実践では切り離すことができないものとして扱っているように思います。

組織への適用

前節で「マネジメント」「リーダーシップ」は役職に属するものではないとしました。そしてこれらはすべての個人が持つべきものです。組織においても全員に要求されます。

例えば、組織のトップが利益目標を掲げたとします。
各部門のトップは割り当てられた目標額を達成するための方策を練り、部長に対して指示を出します。部長はより具体的な行動に落とし込み、課長に指示を出します…これが組織階層の全てのレイヤーで行われます。
この時、組織階層で一番下にいるメンバーは指示を出す相手がいません。ですが、自分自身に対しての目標を持ちます。これはセルフ・リーダーシップとなります。

こうして立てた目標ですが、やみくもに取り組んでも達成することはできません。目標の達成にはマネジメントが必要となります。
それは組織マネジメント、チーム・マネジメント、セルフ・マネジメントと呼ばれ、組織階層の各レイヤーで実践することになります。

組織において各自がなすべきこと

組織という枠組みの中でリーダーシップとマネジメントを発揮するために大切なことは、自分のポジションで期待されているのは何かを理解することです。たとえ、組織階層では一番下であったとしても、マネジメントもリーダーシップも要求されることを忘れてはいけません。

そして、リーダーシップにおいては自分自身を信じることです。「アート・オブ・プロジェクトマネジメント」ではそれを「自恃」という言葉で説明しています。

自恃の精神を持つ人は、自らに対して自信を持ち続けながら、他の人からの影響を受け入れ、将来についての自らのビジョンを定義することに役立てるとともに、ポジティブな変化すべてを受け入れることができるわけです。そして、自らのアイデンティティを否定することなく、過ちを犯し、それを認め、自らの意見を変えることができるのです。
出典：アート・オブ・プロジェクトマネジメント

おわりに

冒頭でも書いたように、このエントリは自身の今の考えをまとめたものです。このテーマは今後も知識や経験をもとに再考し、周囲と議論し、より発展させていきたいと考えています。いつかまた、その内容をもとに新しいエントリという形でまとめることができればと願っています。

参考

完訳 7つの習慣 人格主義の回復

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

NHKリーダーシップ白熱教室第6回（世界が君を待っている）まとめ - ぱと隊長日誌
NHK リーダーシップ白熱教室の第6回のまとめと第1～5回のまとめへのリンク集。

スケジュール計算とラグとカレンダーの関係

はじめに

ラグは先行アクティビティに対して後続アクティビティの開始を遅らせる時間の事です。本エントリではスケジュール計算にカレンダーを適用することで、ラグの調整を必要とするケースがあることを説明します。

カレンダーの影響を受けるラグ

ソフトウェア開発のプロジェクトを考えます。
このプロジェクトのタスクには「テスト」と「バグ修正」があります。「テスト」を進めてから「バグ修正」に取り掛かるため、この2つのタスクに3日間のラグを設定します。

カレンダーを適用しないスケジュールを示します。

次にカレンダー（土日休み）を適用します。

ラグには土日が含まれています。果たしてこれは想定通りといえるでしょうか？
このケースのラグは「テスト」を「バグ修正」に対して3日間分先行させるために設定しました。ですが、カレンダー適用後は「テスト」が実質1日分しか作業しておらず、想定と合っていません。
同様の問題は土日を考慮して設定したラグがスケジュール調整を受けて土日を挟まなくなった場合にも発生します。この場合は必要以上のラグとなります。
このように、ラグが休日の影響を受けるケースではスケジュール調整の都度、ラグの設定を見直す必要があります。

カレンダーの影響を受けないラグ

建設プロジェクトを考えます。
コンクリートの打設から固まるまでの3日間をラグとして設定します（ちなみに、実際の養生期間はもっと日数が必要なようです）。

カレンダーを適用しないスケジュールを示します。

次にカレンダー（土日休み）を適用します。

今回のケースであればラグの調整が不要です。なぜなら、コンクリートが固まるのに必要な日数は休日の影響を受けないからです。
ただ、このようなケースではスケジュール効率化のため、ラグが休日をまたぐようにスケジュール調整している場合があります。このような場合、スケジュール調整の際にタスクもしくはカレンダーの見直し（休日の変更）が必要となるかもしれません。

ワークアラウンド

ラグとカレンダーの関係（影響の有無）を設定したくても、ツールが対応していない場合もあると思われます。これに対する一つの案として、タスクに個別のカレンダーを設定可能であれば、ラグをタスクで表現する方法がありそうです。
つまり、ラグと同じ期間のタスクを作り、ラグに代えて前後のタスクとの依存関係をセットします。そして、ラグを置換したタスクには適切なカレンダー（土日休みもしくは休み無しなど）を設定します。こうすることで、スケジュール調整の際に全体のカレンダーに影響を受けず、ラグ（を置換したタスク）の計算が行われることを期待できます。

ただ、この方法は本来タスクでないもの（ラグ）をタスクで表現しているという問題があります。
また、ツールでタスクに個別のカレンダーを設定でき、かつツールが個別に設定されたカレンダーでスケジュール計算を行う必要があります。手元のツールではスケジュール計算がうまくいかず、このワークアラウンドの有効性を実証できませんでした。
より良い解決案などありましたら、コメントいただけますと幸いです。

まとめ

ラグにはカレンダーの影響を受ける場合・受けない場合があります。カレンダーの影響を受ける場合はスケジュール調整と合わせてラグの調整が必要となります。また、カレンダーの影響を受けない場合でもリソース効率化の面から調整の必要な場合があります。
タスクのラグを設定する際にはそのラグが何を意味しているのかを考え、カレンダーの影響を考慮する必要があります。

また、ツールによってラグとカレンダーの扱いは様々だと思われます。お使いのツールがどのような方針でラグとカレンダーを扱うか把握し、活用していくことが必要となります。

PDMにおいてSS/FF関係を持つアクティビティのトータル・フロートのパラドックスを解消する

はじめに

通常、スケジュールの計算はアクティビティが中断されることは無いという前提で行います。ただ、この前提では前後のアクティビティとSS/FF関係を持つアクティビティでトータル・フロートにパラドックス（矛盾）が生じます。
ここではアクティビティの中断を許すことで、このパラドックスが解決できることを示します。また、アクティビティの中断以外の解決方法についても触れます。

本エントリは以前に書いた以下のエントリをベースにしています。
ADM(アロー・ダイアグラム法)及びPDM (プレシデンス・ダイアグラム法)におけるタイミングとフロートの計算方法 - ぱと隊長日誌
PDM （プレシデンス・ダイアグラム法）のスケジュール計算における制約の影響 - ぱと隊長日誌

用語の説明

クリティカル・パスはプロジェクトにおけるアクティビティの最長経路のことです。つまり、クリティカル・パス上の活動に遅延が生じればプロジェクト完了予定日に影響が生じます。
また、クリティカル・タスク（クリティカル・パス・アクティビティとも呼ばれる）はクリティカル・パス上のアクティビティのことです。

クリティカル・タスクはトータル・フロートがゼロであると説明されることが多いです。ですが、それが成り立つのはアクティビティの制約を考慮しない場合です。制約を考慮する場合はクリティカル・タスクのトータルフロートはプラス、ゼロ、あるいはマイナスとなります。詳細は以下のエントリをご参照ください。
PDM （プレシデンス・ダイアグラム法）のスケジュール計算における制約の影響 - ぱと隊長日誌

アクティビティの分割を許さないことで起きるパラドックス

下図にスケジュールを示します。なお、ここではカレンダーの休日を考慮しません。

FP	フォワード・パスで計算したスケジュール。
BP	バックワード・パスで計算したスケジュール。
青い矢印	アクティビティの依存関係。矢印の横にテキストで依存関係の内容を記述しています。
赤い破線矢印	クリティカル・パス。

このスケジュールにおいて、アクティビティ「テスト」と「バグ修正」にSS/FF関係が同時に設定されています。これは、以下を想定したものです。

• テストが進まないとバグは見つからない（SS+1関係）
• テストが終わるまでは新たなバグが見つかるかもしれず、バグ修正も完了しない（FF関係）

「テスト」の最早開始日(ESD)および最遅開始日(LSD)は前後の関係から共に8/3となります。最早終了日(EFD)はESDから8/4に決まります。

では、「テスト」の最遅終了日(LFD)はどうなるでしょうか？
（一般式）LFD = LSD + (d - 1) = 8/3 + (2 - 1) = 8/4
（FF関係）LFD = 後続LFD - Lag = 8/5 - 0 = 8/5
異なる結果となりました。これはLSDがSS関係の影響を受けたためです。

また、TFE (Total Float Early) 及び TFL (Total Float Late、単にトータル・フロートとも) を計算してみます。
TFE = LSD - ESD = 8/3 - 8/3 = 0
TFL = LFD - EFD = 8/4 - 8/4 = 0
この結果は「テスト」の開始もしくは終了に余裕がない（「テスト」が遅れれば完了日も遅れるか、制約に違反する）ことを示しています。

ですが、現実には「テスト」の終了が1日遅れて8/5となっても全体スケジュールに影響することはありません。このパラドックスはスケジュール計算で「アクティビティが中断されることはない」という前提があるために起きています。

パラドックスの解決

このパラドックスを解消する一つの手法はアクティビティの中断を認めることです。
アクティビティの中断を認めた場合のスケジュールを以下に示します。

「テスト」のLFDが8/5となりました。これに伴い、TFE=0, TFL=1となります。
この結果は「テスト」の開始日に余裕はないが、終了日は1日の余裕があることを示しています。また、これは実際とも一致しています。

このようにアクティビティの中断を許す方法以外にも、以下の方法でSS/FF関係のアクティビティに生じるパラドックスを解消することができます。

• タスクにアサインするリソースを調整して制約に合わせた所要期間で調整する
• ADMでLadderを使って計算する

ADMでLadderを使って計算する方法は参考文献・資料"Links, Lags and Ladders"の"Ladders"を参照ください。

まとめ

"Links, Lags and Ladders"の"Conclusions"を引用します。

The developer of the PDM networking methodology, Dr. John Fondahl, was always of the view the only safe link to use in a precedence schedule was the Finish-to-Start link. Similar warnings are contained in the PMBOK Guide and the PMI Practice Standard for Scheduling.
The issues raised in this paper clearly demonstrate the inconsistencies and problems that can develop using S-S and F-F links. However, it is highly unlikely their use will diminish significantly.
Therefore, the responsibility must fall to the managers of schedulers, and the schedulers themselves to make sure the logical constructs used in their schedules are both sensible and mathematically correct.

http://www.mosaicprojects.com.au/PDF/Links_Lags_Ladders.pdf

PDMスケジュールをFS関係だけで表現することができれば、今回のようなパラドックスに悩むことはありません。ですが、それは現実的ではありません。現実のモデルで現れるSS/FF関係をFS関係に置き換えたとしても、それは依存関係のごまかしに過ぎず、また別の問題を引き起こすことになるでしょう。
スケジュール管理者は理論やツールの制約・限界を理解しつつ、現実的で正しいモデルに近づける努力をすることが必要です。

参考文献・資料

Links, Lags and Ladders

http://www.mosaicprojects.com.au/PDF/Links_Lags_Ladders.pdf

プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第5版

プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第５版 (A Guide to the Project Management Body of Knowledge)

建設エンジニアのためのPMSによるプロジェクト計画入門―基礎からリスクスケジューリングまで

建設エンジニアのためのPMSによるプロジェクト計画入門―基礎からリスクスケジューリングまで