世界線を見誤るとアジャイル開発は上手くいかない
エンジニアになった（就職したの意）ときから、唯一メンタルモデルの元上司のプロジェクトにjoinするまではプロジェクトマネジメントという概念、知識は持っていなかった。プロジェクトマネジメントの知識（当時はPMBOK初版）は翻訳本を手に入れられたが、システム開発手法については案件ごとのPMのやり方についていくだけで知識としては持ち合わせていなかった。
システム開発手法、つまりウォーターフォールをまとまった知識として得られたのは大規模な金融システムのプロジェクトに参画し、プロジェクト内の今で言うPMOにアサイメントされたときだった。その経験により割ときっちりしたウォーターフォールでのシステム開発の形式知と実践知を手に入れた。
マネージャになり、ウォーターフォールでのシステム開発を任せていたプロジェクトで担当PMの推進に問題があり、立て直しにあまり介入することなく（介入をゼロにはできない。立て直しで手を出すので）、つまり、主体性は担当PMに残したまま立て直す手段を探していて見つけたのがスクラムやカンバンのアジャイル開発であった。このプロジェクトはかれこれ10年くらい前のことである。
ここまでは前振りというか背景的な前説である。
プロジェクト、それはSIerとしてのシステム開発でも良いし、サービサーのプロダクト開発でも構わない。そのプロジェクトは基本的にプロジェクトとして別々の世界線を持っている。PMBOKのプロジェクトの定義を記憶していればわかるだろう。わからない人はPMBOKを読むか、過去のエントリでの説明を読んで欲しい。
要は、プロジェクトは唯一無二である。
である（PMIもPMBOKでそう定義している）から、世界線が交わることはない。独立した世界を持ち、いつか、その世界は終わる（プロジェクトの成否に関わらず終わる）。維持管理フェーズはプロジェクトと呼ばない（期限性の性質を持つのがプロジェクトであるため）。
そうした違うものたちを敢えて分けるとすると、
の２つに分けるとする。言い換えれば、システム開発チームがシステムオーナ部門内か外かの種類に分ける考え方をする、ということであり、そこで線引きするかしないかということでもある。
これはプロジェクトの世界線は唯一無二というばかりではなく、それ以前にプロジェクトに厳密な役割分担の線引きをするしないという性質を持たせる。
ここまでを（自分のために）整理すると
- プロジェクトに線引きの性質を持っている
- プロジェクトは、唯一無二の性質を持っている
という前提を持つ。
その前提の上で、個々のプロジェクトでシステム開発手法は、プロジェクトの特性（リリースに対するビジネス要求、QCDへの要求などビジネスサイドで実現したい業務課題）を判断する。
見方を変えれば、別世界のプロジェクト（事案）は個々の都合で開発のお作法を選択しているであるから、個々の道具だけを並べて議論することに意味はない。
プロジェクトマネジメントの形式知の導入（実践知は除く）から入り、システム開発手法に関する知識を後に導入したPMの知見で言えば、トッププライオリティは役割であるシステムを実現したい方法で終わらせるということだけである。これは、道具は何でも良いから、ビジネスオーナのやりたいことを実現しよう、ということだ。
同じようにビジネスオーナサイドの立場で言えば、なんでもいいから業務課題を解決する方法で実現してくれ、である。
この両者には手段であるシステム開発手法についてはプライオリティは低い。フォーカスしているのは業務課題の解決（かそれを代行して実現すること）である。
アジャイル開発の知識を取り入れ、カンファレンスで講演が議論を聞いたときに思ったことは、それで自分の解決したいことが実現できるかどうかを知りたい（それはやってみないとわからないのでやり方の見通しに必要な道具と使い方の知識をどこでどれだけ手に入れればいいのか）のであって、道具の優劣の話なんて興味がないんだよ、ということであった。
そのときの感覚は、プロジェクトの世界線が違うことに由来しているからだ、と自分なりに紐づけられると割とすんなり受け入れらるのであった。
もしウォーターフォールで上手くいかない、アジャイルを組織に導入できないという事象に落ち入ったら、それはその前のプロジェクトの性質を見誤り、世界線を間違えているということかもしれない、と今の世界線を疑わなければいけない。
