プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある

プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある、という言葉に惹かれたのでメモ。
論理性のないラフなメモ。

【参考】
「曖昧さへの耐性の旅」が近い - 金融そして時々山

（引用開始）
「プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある」という部分でした。これは「世界一わかりやすいプロジェクトマネジメント」という本にでてくる話なのですが、受講者の皆さんはこれまであまり聞いたことがなかったのかもしれません。
（引用終了）

「曖昧性とのたたかい」より抜粋したプロジェクトマネジメントのチェックリスト - takuya0206's diary

（引用開始）
提案依頼書に要求仕様などの詳細が書かれていることはまずない
完璧で完全な契約にこだわりすぎると、顧客に嫌がられ失注する恐れがある
曖昧さが残る状態が避けられない以上、この曖昧性をいかにコントロールするかがプロジェクトマネジメントの最大の課題である
（引用終了）

プロジェクトの曖昧さは不確実性のコーンと同じと思う。
曖昧さが残る状態から開始するのは避けられない。
その曖昧さをどうコントロールするのか？

ウォーターフォール型開発では段階的詳細化によりスコープを狭めたり、QCDが合致切り目られた計画を元にQCDの予実管理で差異を事前に検知しながら、曖昧さをコントロールしていく。

一方、アジャイル開発では、短期間のスプリントでスコープをコントロールしながら、漸進的に品質を高める。
また、ユーザーストーリーはプロダクトバックログの優先順位でふるい分けられて、その時々の状況を織り込みながら、変化を取り込む。

エンジニアであるからには、ソフトウェアであれ、ハードであれ、要件とQCDの実現性のバランスを取るのが顧客から期待されている。
でも、曖昧さとQCDのトレードオフのバランス感覚は、いつになっても難しいと思っている。

プロジェクトマネージャに必要な能力は、そのトレードオフの感覚がいちばん重要なはず。

そういうトレードオフの技法をエンジニアリングとして形式知化してきた。

他方、特にソフトウェアのエンジニアは曖昧性に弱い。
結構自分の裁量が大きいので、作った後でユーザに見せると、全く違う、とよく言われる。
ソフトウェアはいろんな実現方法があるので、1つのロジックを複数のプログラムで表現できるために、コードクローンも発生しやすい。
その分、バグも出やすくなる。
似たようなコードが沢山発生するので、技術的負債はリリース直後から発生し、リプレースするまでその重みで保守すら難しくなる。

曖昧さのコントロールは、PMBOKでもアジャイル開発でもその難しさは変わらない。
QCDでコントロールするのか、スコープでコントロールするのか。