プロジェクト管理のアンチパターン

プロジェクト管理のアンチパターン

　ソフトウエア開発において、毎日の長時間残業や毎週のような休日出勤が続くなど、過酷な状況に陥ることを、デスマーチ・プロジェクトと言います。

　本来は、ソフトウエア開発者はITの進化を支える花形職業であるはずなのですが、開発の現場ではデスマーチ・プロジェクトが常態化した結果、3K（きつい、厳しい、帰れない）職場と揶揄（やゆ）され、学生の人気も今ひとつだと言われています。

　今回（第3回）は、こうしたソフトウエア開発プロジェクトにおける悪いお手本としての、代表的なアンチパターンを紹介したいと思います。

Analysis Paralysis（アナリシス・パラリシス）

　ソフトウエア開発を行う時には、システムに対する要求をきちんと分析することが大事であることは言うまでもありません。しかし、こうした作業にばかり時間がかかってしまい、なかなかプログラミングやテストに入れないというのも困りものです。

　このように、分析作業にばかり時間をかけてしまうことを、“アナリシス・パラリシス”（直訳すると「分析麻痺」）と呼んでいます。

　以下のような症状があれば、アナリシス・パラリシスアンチパターンにかかっている可能性があります。

・プロジェクトの方向転換や分析モデルの作り直しが頻繁に発生する
・設計と実装の話が分析の段階において入り込む
・分析がユーザーとの対話抜きで進められている
・分析モデルが複雑になっている

　こうした現象は、特にオブジェクト指向による開発の経験が浅いデベロッパーがオブジェクト指向分析設計を行った時に多く見られるものですが、それ以外の開発方法論（構造化設計、データ中心アプローチなど）においても同様のことは散見されます。

　なぜ、デベロッパーがアナリシス・パラリシスに陥るのかと言えば理由は簡単です。実際にプログラミングやテストを行う前に、完全な仕様の分析や設計を終わらせることに固執し、分析が完ぺきだと安心できるまで先に進めなくなってしまうからです。

　アナリシス・パラリシスにならないようにするためには、机上の分析設計だけで時間を無駄に費やさずに、プログラミングやテストを実施した結果をフィードバックしながら、仕様を改善していくことが有効です。