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

2009年5月25日(月)
細川 努

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

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

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

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

Analysis Paralysis(アナリシス・パラリシス)

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

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

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

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

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

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

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

株式会社アーキテクタス
(株)アーキテクタス 代表取締役 技術士(情報工学)大手シンクタンクで金融系システム構築等を経験。現在、総務省CIO補佐官として、総務省内のシステム構築への助言等を担当している。要求開発アライアンス理事 日本Javaユーザー会(JJUG)監事

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています