想定としてはプログラマとしてバリバリ開発をしていてそれなりに評価されたひとでこれからさらにPMにも手を出していきたい人や、PMに将来なりたいプログラマを対象としています。

とはいえ、プログラマからPMになろうとするときの話を私の経験に基づき書いたものですべてに当てはまるバイブルというものではありません。

顧客が存在するBtoBシステム開発プロジェクトを想定しています。

システム開発といっても色々な場面があります。社内システムを作る開発プロジェクトやゲーム開発のように社内に仕様を決める人がいてトップダウンですぐに仕様変更があるようなものはあてはまらない場合があります。

この場合は、顧客がいて、ある業務を行うためのシステム開発・構築を請け負い、お客様と要件定義交渉を通じて仕様を確定して設計をしたうえで開発を行う、IPAなどで発表しているソフトウエア開発プロセスなどに沿って進めていくようなプロジェクトです。(これらのプロセスは理想で誰もやっていないと思う業界や分野はあろうかと思いますが、官庁公共系の開発などではこれらを守ることを仕様書で要求されたりします。当たり前に行っているところも多いのです。)

とはいえ、システム開発プロジェクトであれば、言い回しはシチュエーションの違いはあっても大きく違うことはないでしょう。

小さなPJをやってきた人は本当にこんなことまで必要なの？と思うかもしれません。

言い換えれば、より大きなPJをやるのに何が必要か？という見方をしてもいいです（タイトルを変えて中身の同じ本をだそうかしら？）

もともと大型のPJをやってきているSIerのひとが見れば、「あたりまえじゃん！どこでもやっていることだ」か、「気持ちがわからん」という風になる内容です。

私は中・大型PJの仕事をやってきているので、社内システムや小さなシステム、オープンソースプロジェクトではここで述べていることはあまり当てはまらないかもしれません(どこまでやるかなどの品質に対する考えかた、費用に対する考え方など)。品質担保に対する方法論など大きな点は変わらないと思いますが、その点注意をして読んでください。

技術論や、プロジェクト管理手法にも触れていますが、あくまでも一例です。いらないところは読み飛ばしてください、本書は必要なところを拾い読みすることを前提に作られていますから、様々なレベルや状況について述べていてその意味での対象読者レベルの一貫性はありませんのでお許しを。