公開されたのは少し前のようだけど、PMBOKガイド第５版ソフトウェア拡張というものがPMIから公開されたようだ。これを紹介するInfoQの記事に書かれた「ソフトウェア開発の性質」が面白かったので、少し調べてみた。
ソフトウェア開発の性質
氏は，プロジェクト管理に影響を与えるソフトウェア開発特有の要素をいくつか挙げている。例えば，
ソフトウェアプロジェクトのこのような現実を改めて理解するべきだ，と氏は言う。このようなプロジェクトの計画と実行において，より探索的で反復性のあるアプローチが推奨されるのは，ごく当然のことなのだ。
元ネタの記事を斜め読みしてみるとこんな感じ。
- ソフトウェアの無形性
- →ソフトウェアは実体を持たないので「7フィートの高さ、3フィートの幅」というように明確に要求を定義できない
- 同じシステムを2度開発することはほとんどない
- →建築と異なりソフトウェア開発プロジェクトは新規でユニーク。教訓は抽象的にしか適用できない
- 要件の頻繁な変更
- →無形成と関連して、包括的で確定的な要求が得られず、後から生み出される
- リソースのスケーリングの非線形性
- →規模の不経済の話
- 完成の非線形性
- →ソフトウェア開発は独創・研究開発型の仕事であるため、完了時期が予測し難い
- プラットフォームや技術の変化
- →急速な変化によるリスクの複雑化
異論は無いけど、上記はMike Griffiths氏のブログ記事での表現であって、PMBOKガイド第５版ソフトウェア拡張ではもうちょっと違った事が書いてあるようだ。というわけでちょっと見てみた。
(実はパブリックプレビュー版を見て書いている。最終版では内容は異なっているかもしれない)
なぜソフトウェア開発プロジェクトはチャレンジングなのか？ (1.2.2 Why Are Software Projects Challenging?)
だいたいこんな事が書かれている印象。
- ソフトウェアは物理的な特性を持っていない
- →これは前述「ソフトウェアの無形性」と一緒の話
- ソフトウェア開発者の生産性が広く可変的である
- ソフトウェア開発プロジェクトの推計は困難かつ不正確
- →コストとスケジュールの正確な推計がソフトウェア開発プロジェクトでは特に困難。1)ソフトウェアの設計から製作のほぼ全てが技術者によって行われ 2)技術者の生産性は広く可変で 3)推計の基礎となる要求の収集はいつも不十分で 4)技術の変化がデータ蓄積を妨げているから
- ソフトウェア開発プロジェクトのリスク管理は、主にプロセス志向である
- →ソフトウェア開発は常にユニークなものであることから、常に異なるリスクを保持している。これをプロセスで管理する必要がある
- ソフトウェアは通常より大きなシステムの一部であり、独立していない。ハードウェア、ユーザ、保守担当者なども含む系の一部である
- ソフトウェアは全体の系の中で最も変更しやすい部分である
まぁ、言っていることはだいたい同じか。
とはいえ、こういったことがPMBOKの中で語られている、というのは興味深い事ではある。
PMBOKの最近の版ではアジャイル型開発プロセスへの言及などもされているらしいけれど、やっぱりPMBOKは「包括的なプロジェクトマネジメントに関する知識体系」なのであって、ソフトウェア開発プロジェクトは得意な分野ではないんじゃないかと思っている。
- ちょうど00年頃に、日本国内ではソフトウェア開発プロジェクトの大炎上が続いていてた。
- 日経コンピュータで「動かないコンピュータ」という記事が出たり
- 94年の米スタンディッシュ・グループのカオスレポート（成功したソフトウェア開発プロジェクトは16%だけ！）が流行ったり
- この状況下でタイミング良く輸入されたPMBOKおよびPMP(認証制度)が各ベンダーに大流行
- 教育ベンダーにも大流行
という流れの中で流行し、ソフトウェア開発プロジェクトのマネジメントの底上げには大いに貢献したと思うけれども、いろいろと無理もあったのではないだろうか。
ちなみにソフトウェア拡張そのものを読むかは悩み中。
あ、あと一応PMPは一度取得している(失効させたけど)
