組織の規模としては比較的大きなもの、マネージャーレベルで年間一桁億円、部門で数十億円、事業部門で数百億円程度の組織を想定しています。

いろいろな「あるある」的な話は小規模ではあてはまらない物もあるかもしれません。

想定する組織構造としては単純化しますが、ピラミッド型で構造は、プログラマ、チームリーダ、サブシステムリーダ、などのローアーマネージメント、プロジェクトマネージャ、部長・部門長などのミドルマネージメント、事業部幹部・役員・社長などのトップマネージメントがあるピラミッド構造の前提ではなします。

プロジェクト全体を管理したりする課長レベルの職級(職位)をここでは課長、役割(役職)をプロジェクトマネージャと表現します。課長の職級を上でまとめるのが部長、ある区切られた範囲の課をまとめるのが部門長という役割として話します。部門を束ねて、事業責任を負うのが事業長・経営層と表現します。

組織によっては職級(職位)は第何等級という風に細かい数字(十数等級ある場合もある)で表現されることもあります。これらは給与レンジと密接で役割にかかわらない位を表現します(単純に給与等級を表すために職級がある組織もあります)。

★図、ピラミッド図　プログラマ、チームリーダ、サブシステムリーダ、プロジェクトマネージャ

各役割の想定定義については、本文の中で触れていきますのでそちらを参照ください。

ご自身の組織に合わせて本書の役割を何と呼ぶかで読み替えてください。きっと思い当たる節や、こんなことあるあると思っていただけることと思います。

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

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

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

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

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

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

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

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

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

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

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