ムック「Systems Engineer Vol.1」の同名の特集記事が加筆、修正の上、書籍化されました。
　第２章を担当させていただいております。
　２０代で身につけておく大事なこととして「自分自身で考え、確信を持って、あるいは前提条件を明確にしたうえで、自分自身で決断できるようになる」ということを挙げさせていただきました。
　確信を持つために必要な知識と進め方、必要な考え方など、書かせていただいております。。

　ご好評をいただいた「ＳＥの教科書」「ＳＥの教科書２」を一冊にまとめ、加筆修正をさせていただきました。
これらの書籍で書かせていただいていたことは、実は「仕様変更ゼロ」を実現した方法です。
以前は、「仕様変更ゼロなどと書くと（特にＩＴ業界の人々には）信用してもらえない」という理由で、あまり強調しておりませんでした。
とはいえやはり、『「仕様変更ゼロ」を目指してみる事によって、考え方、物事の見方、捉え方など、全てが変わった。』と断言できるところから、最近はより強調させていただいております。
　「仕様変更ゼロ」などと限界を目指して頑張るのは、あまり業界自体に求められていないかのようにも見えるのですが、実作業者にとって最も「ラク」であり、実は経営的にも「顧客には喜んでもらえるし、最もコスト効率が良い」方法でもあります。あとはそれを本当に評価できるかどうか（認識し、理解できるかどうか）です。

　ＰＭＢＯＫなど、さまざまな知識体系も提示されている中、なかなかプロジェクトの成功率が高まっているという印象を持つ事はありません。
　また、プロジェクトマネジメントを考える上で、「計画」が極めて重要、ということに異論はないと思います。しかし、現実のプロジェクトにおいて、しっかりと「計画」が行われているかというと、ほとんどそう言うことはありません。
　それはなぜでしょうか？
　これについては、（不思議なことに）過去多くの人々が、体系的かつ科学的な計画法を学ぶ機会が、義務教育から高等学校、大学を通じて無かったにもかかわらず、特に確たる根拠もなく「しっかりと計画はできている」と「組織として思い込んでいる」所にあると感じています。
　これは、小規模開発から、官庁の基幹システムまで行ってきた筆者の視点では、大規模開発ほど、この思い込みが顕著です。
　この書籍には、現実に官庁での開発などで「仕様変更ゼロ」を実現することのできた（これがどれほど難しくて辛く、実現可能性が低いかは、おわかりいただけると思います）プロジェクトの進め方など、書ける限りの事を書かせていただきました。
　トップページにありますように、ＪＲ東日本メカトロニクス株式会社様、日立ソフト様他での実践研修において、テキストと合わせて採用していただいております。

　ご好評をいただいた「ＳＥの教科書」の続編です。
　業務で研修等を行っていく中で気がついたのは、「ＳＥの教科書」などに書かせていただいた、様々な考え方や工夫など、全ては（言ってみれば失敗に対する恐怖感から）計画作成を可能な限り緻密に繰り返した結果、得られたモノだったということです。
　やっと最近になって「計画が全てだった」ということに、２０年以上もこれを行っていて、しかも「ＳＥの教科書」を書いた後になって、気がつきました。
　最近の研修業務では、これほど長い間、自分でも気がつかなかったことを研修でお伝えしようとしているということになります。
　実は軽視や誤解をされてしまう場合が多い、システム開発での計画活動について書かせていただきました。

　なかなかとっつきにくいＰＭＢＯＫ（第３版）ですが、書かれていることは筆者の過去の経験に照らして考えて見ても、極めて実務的な内容です。
　とはいえ、知識体系としての汎用な記述を目指すがために、折角の良いところが見えにくくなっています。
　何とか、そのあたりをうまく表現出来ればと思いながら書かせていただきました。
　この書籍である程度のイメージを作っていただき、さらにＰＭＢＯＫをシッカリと勉強していただければと思います。

　Gihyo.jp トップ

　「ソフトウェアピープル vol.5」に書かせていただいた「スペックパターン開発プロセス」を一般的なＩＴ用語で記述した記事に、加筆修正を行ったものです。
　思いもしなかったタイトルですが、内容を評価いただけたものと、大変嬉しく思っております。おかげさまで、発売当日に増刷が決定し、既に第５刷となっております。