プロジェクトマネジメントの基礎

「プロジェクト型業務」という概念に対して個人的な認識を先に述べておくと、あらゆる業務は結局のところプロジェクトに還元できる。例えば、アジャイルのイテレーション（スクラムで言えばスプリント）なども、結局のところプロジェクトとして認識できる。

ソフトウェア開発の文脈になるが、従来的開発とアジャイル的なるものとを峻別するために「それがプロジェクトであるか」なる問いを中心に置くのはナンセンスである。ウォーターフォール・アジャイルで区別しておくのが無難だ。

プロダクト中心的でありたい。だから、我々が行うのはプロジェクト型業務ではなくプロダクト改善業務である、という見方も概念操作としては可能ではある。

ただし、結局そのプロダクト改善にも計画がありその修正があり実行があり検査があるのには違いがない。プロダクトだのプロジェクトだのといっても、言葉の綾や標語くらいにしかならない。

もちろん、ロールとしてのプロダクトマネージャーを置くことは、製品価値をどう高めてゆくかについての組織としての思想を表現し、その業務形態を規定する点で明確な意味がある。また、個人的には単に語彙としてPdM, PjMを使い分けることには賛成である。

ここではただ単に、あたかも「自分たちの業務とプロジェクト概念には関係がない」と言わんばかりの態度を批判している。（このあたり、別稿でより精緻に言及したい気もしてきた）

長期的・多工数的なプロジェクトに対する反省はもちろん有益であり、アジャイルの価値基準は概ね正しいが、ウォーターフォール回帰を嫌うあまりに「プロジェクト」概念によって得られた先人の知恵を捨て去るのは惜しい。プロダクトの価値を高めるために、プロジェクトを、機敏にこなしつづけよう。

物事を一挙に解決する素晴らしいフレームワーク・メソッドは存在しない。思考を放棄せず、できることを、粛々とこなす必要がある。

遅れを申告して、取り返せるうちにどうにかできる体制を作るべきである。そのためにも、原義の心理的安全性は保たれるべきであり、ミスや懸念、自己のタスクの遅延状況を口に出すことにむしろインセンティヴが生じるようなチームを形作ると良い。

また、「まだ大丈夫だろう」や「大きいタスク単位だから後半で巻き返せる」もスメルである。これを予防するには、タスク単位は日を跨がない程度にするのが良い。そして、チケット名はタスク行動内容をちゃんと言語化したものになるべく近づけること。チケットは日を跨がないうちにしばくこと。やむを得ずチケットを分割処理する場合は、分割後の命名を「その2」とか「（続き）」とかにしないこと。

「メンバーはできないことをできると言わない」を原則とすること。逆から表現するなら、できると言ったことはやり切ることを原則として、（無理な稼働要求やパワハラは当然避けるにせよ）やり切ってもらえるようにマネージャーが働きかけること。

……というのは元ネタ理解としては不十分であるが、結論としては正しい。

正確にいうと、分割可能でコミュニケーションコストの低い業務は、人員追加によって速度改善が見込める。

しかし、プロジェクトが遅れている理由は、だいたい複雑かつ不確実な状況に求められるわけである。よって、遅れているプロジェクトのコミュニケーションコストは高いのがデフォルトである。

そのため、まず改善すべきは人員状況よりもコミュニケーションコストである。

対処すべき課題を明晰化して全体に共有することのスピードを高め、マネージャーがメンバーの状況を解像度高く把握している状態を先に作るのだ。

ただし、属人化が激しい業務（一人で広い領域を見ていて、即座に引き継ぎができないような）は、早い段階で解消しておくか、リスクヘッジを取るべきである。

遅延の否認を避ける意味でも大事で、そもそも早い段階で遅延に気づくためのゲートを築くべきである。

ステアリングコミッティや成果物レビューはそれに適する。

また、ウォーターフォールを自覚的に選択するのなら（自分はそれが事業的に上手くいくとは思わないが）フェーズゲートを築かなければならない。また、もし一度通過したフェーズゲートを引き返すのであれば、当然にその分だけ計画は後ろ倒しになる。このことを否認してはならない。

遅延状況に対する修正アプローチを話し合う。

それがステークホルダー間でバランスしている状態を志向する。

実施に際して、トレードオフ認識は共有する。

プロジェクトでは、不確実性を吸収するための構造を提供する必要がある。

期日を完全に固定する場合は、成果物内容や費用において妥協をすることが要請されることもしばしばであり、それらを全面的に拒否する場合、何らかの歪みが生じる。

また、チームが疲弊するような吸収方法を採用することには慎重であるべきである。

QCDがハイポジションでバランスするのは、チームの士気・個々の能力のいずれもが高い水準にあるときのみである。また、ソフトウェア開発なら、既存負債による減算も考慮しよう。

1リリースまたはデプロイあたりの業務量が多くなればなるほど、工数は指数関数的に膨らむ（cf. No Silver Bullet）。

リリース単位を小さくして、短いイテレーションでこれを繰り返す方が望ましい。

ビッグバンリリースは品質上の問題を生む蓋然性が高く、しかもそのリカバリを困難にする。細かいリリース・細かいフィックスで、「すぐ次に行く」動きを常に作ってゆくのが良い。

ある程度ポジティヴな感情を背景として意欲的に働くことの方が、そうでない状態よりも当然に持続可能である。綺麗事ではない。現実認識をシビアにすればするほど、むしろここは避けられなくなってくる。

もちろん、「モチベーションに左右されない働き方をするのがプロだ」という見解には一定の理があるし、道義的に正しい。しかし、実運用を考えてゆくと、破綻しやすい。プロとしての自覚を強く持ちそれを常に維持して働ける人員だけでメンバーを構成できているか、そしてそのことに十分なインセンティヴがあるか、をよくよく検討してみると良い。