読者の皆さんは「Analysis paralysis」という言葉をご存じだろうか。

　記者はITproに所属する前，日経SYSTEMSという月刊誌の編集部に所属していた。その2006年10月号で「ITエンジニアのやってはいけない」という特集を担当した。SEがやってはいけない「アンチパターン」の特集である。

　この特集で，いろいろな人に今ソフトウエア開発の現場で起こっている「アンチパターン」を聞いて回ったのだが，そのときに聞いた話で今でも印象に残っている言葉がある。それは「Analysis paralysis」だ。

　Analysis paralysisは，日本語に直訳すると「分析麻痺」となる。米国では，結構有名な言葉らしく，Googleで検索するとヒット数は112万に上る。

　Analysis paralysisは，英語版のWikipediaにも載っている。その概要は以下の通りだ。

Analysis paralysisとは，「分析にかかるコストがメリットを超えたとき」に使う言葉で，意志決定のための分析など，多くの場面で使われる。たびたび，「extinct by instinct（本能による絶滅）」のように「 paralysis by analysis（分析による麻痺）」という言い回しをする。

ソフトウエア開発では， 限度を超えて長いプロジェクト計画や要求分析，プログラム設計/プログラミングのフェーズで現れるが，それによって，ほとんど何の付加価値も生み出さない。Analysis paralysisはシステム分析の経験不足によってたびたび引き起こされる。Analysis paralysisはアンチパターンの1つである。

　簡単に言えば，「分析しだすと止まらなくなる」ことをAnalysis paralysisを呼ぶ。

　この言葉を初めて聞いたのは，某コンピュータ・メーカーのベテランITアーキテクトだった。彼によれば，このAnalysis paralysisにかかっている若いエンジニアが最近多いという。

　例えば，オブジェクト指向分析開発で使われるユースケース（利用者から見たシステムの利用場面）のシナリオ（一連の処理の流れ）の作成時にも，Analysis paralysisはよく見られるという。「本来ユースケース・シナリオには，どんな条件で起動され，何をなし得て，終了したときにどんな状態になるかという流れだけがスッキリと書いてあればいい。にもかかわらず，シナリオの中にifやthenを使った中途半端なロジックやビジネスルールまで書き込むエンジニアが多い。中には，コードを書くエンジニアまでいる。ユースケース・シナリオで，これらは全く必要ない。かえって分析・設計のじゃまになる。しかし，『やめなさい』と言っても止まらない」（同）。

　このITアーキテクトによれば，Analysis paralysisは，ユースケース・シナリオの作成だけではなく，DFD（Data Flow Diagram）の作成でも見られるという。DFDをどんどん詳細化していき，止まらなくなるのだ。「そうしなければ不安なのだろう」（同）。まさにAnalysis paralysisである。

　Analysis paralysisにかかるエンジニアの気持ちも理解できなくはない。すべてを忘れて分析に没頭すると気持ちがいいのだろう。「自己陶酔」だ。しかし，プロジェクト・チームにとってはいい迷惑である。

　このITアーキテクトは，ユースケース・シナリオやDFDの作成などでAnalysis paralysisを起こすエンジニアは，その成果物の「本来の目的」を見失っているからではないか，と指摘する。ユースケース・シナリオの本来の目的は，処理の流れを明確にすることだ。DFDも，その時点で必要なレベルまで詳細化されていればいい。そして本来の目的を見失うのは，社内標準や書籍で読んだ知識にとらわれすぎているからはないか，という。

　もし，自分が「Analysis paralysis」的な行為に走っていれば，いまやっている作業と成果物の目的（どう利用されるのか）を，今一度客観的に把握するべきだろう。