Amazon「変更を制する者がプロジェクトを制す！」 |
| もう大丈夫！変更に振り回されずに対処する方法 あなたはシステム開発で変更に振り回されずにうまく対処できていますか？１．計画や要件定義を入念にやるので 変更はほとんど発生しない。２．変更は発生の都度、柔軟に対処できており何の問題はない。３．それとも。。。 あなたがもし、これまでシステム開発で変更に振り回され、ストレスを感じたり、疲れたりしているなら、 あるいは、これから変更が多発しそうな恐れがあり不安をかかえているなら、きっとこの本は役に立つことでしょう。 なぜなら、かつての私がそうだったからです。新卒でシステム部門に配属されてから、これまで30年以上、 システム開発では変更、変更、変更との戦いでした。 教科書はウォーターフォール型のシステム開発方法論が主流で、基本的な姿勢は変更を出すな！です。 そのため要件定義をしっかりやって固めたら凍結し、それ以降に出てきた変更は「招かざる客」というわけです。 ところが実際のシステム開発では凍結したはずの要件、スケジュール、予算、人員とあらゆるものが変更され、 教科書とは程遠い惨状でした。長い間、教科書の理想と現実のあまりのギャップに悩みました。そして、なんとか 理想に近づけようと毎日、変更と格闘し、もがき苦しんでいました。 そんなある日、気が付いたのです。先のことは誰も分からないという事実に。日程や予算はもちろん、要件さえ。 変更はあって当たり前、凍結とか、変更を出すなとか言う方が無理！という当然のような事実。 ウォーターフォールの教科書が示す理想は、幻想にすぎないと。そして、今はより先のことが分からないVUCAの時代 と言われています。VUCAとは、Volatility：変動性、Uncertainty：不確実性、Complexity：複雑性、Ambiguity：曖昧性 の頭文字をとった造語です。 このような時代、DX（デジタルトランスフォーメーション）を推進するためにウォーターフォールに変わる アジャイル開発が注目されています。アジャイル開発の精神は「変更を受け入れる」ことです。 ええっ！？ウォーターフォールでさえ変更を抑止・制御できていないのに、変更を受け入れたらどうなりますか？ あらゆる利害関係者が変更、変更、変更と当然のように頻繁に出して来たら、それこそカオスです！ そこで提案です！ ウォーターフォールのように変更を無き者にするのでもなく、アジャイルで無作為に変更を受け入れるのでもなく、 いかにすれば変更を制御することができるのか、その方法がここにあります。私が30年以上、もがき苦しんできた末に 到達した境地です。私の経験だけではなく、アジャイル開発やリーン開発、トヨタ生産方式、五輪書、孫子の兵法など、 変更に対処するための先人の知恵や知見も取り入れています。もし、あなたが私と同じように何十年かの歳月をかけ、 自らの経験と学習によって変更を制するスキルを身に着けたいと思うのであれば、この本は必要ないかもしれません。 しかし、あなたがこの本を手にすることで、私が長い歳月をかけ経験し学習したことを、1時間ほどで共有することが できます。その上に、あなた独自の工夫を加えて、さらに新しい境地を確立することができるでしょう。 これからのVUCAの時代、システム開発に限らず「変更を制する者がプロジェクトを制す！」ことができるのです。 Amazon「変更を制する者が世界を制す！」 はじめに 「変更」は、プロジェクトの混乱を引起す主要因です。スコープ変更、要件変更、コスト変更、日程変更などの様々な変更、特に想定外の変更は、プロジェクトを失敗に陥れる元凶と言っても過言ではありません。このような変更が一切無ければ、プロジェクトは計画通りに進み、何の問題も無いはずです。しかし、現実にはＩＴプロジェクトの７０％が失敗していると言われています。その失敗の原因は、計画時点では想定しなかった、あるいは想定できなかった、意図する変更や意図しない変更によって、計画が狂ってしまうからに他なりません。 しかし、変更があったとしても、あらかじめ想定された範囲であれば、余裕を持って対処することも可能です。対処方法そのものを計画に盛り込んでおくこともできるでしょう。そこで、プロジェクトを襲う様々な変更に振り回されず、能動的な攻めの姿勢を持って、事前に変更を想定していくことがプロジェクト成功への道です。 本書では、このような考え方に基づいて、変更に適切に対処する為の『変更管理』を紹介します。また、「兵法」には戦闘における攻防の変化に対処し勝つために先人が考え出した知恵が多々あります。戦闘では、変化を制したものが勝つといっても過言ではありません。 戦闘での「攻防変化」とＩＴプロジェクトの「変更」には共通点も多く、応用できるテクニック、心構えや勘所等も随所で紹介していきたいと思います。 目次 はじめに 1. 混乱の原因となる「変更」とは 2. 変更によるプロジェクトへの影響 3. プロジェクトの主要成功要因 4. 主な変更内容とリスク 5. 攻めの変更管理プロセス 6. 変更に対する危険予知 7. 変更に対する影響分析/優先付け 8. 変更の実施 9. モニタリング 10. 是正処置／改善 11. 孫子の兵法 九変篇 あとがき |
DXでアジャイルやるなら必読！「変更を制する者がプロジェクトを制す！」
書籍
コメント