ITPS、あるいは移行の大変さピンとこないよ症候群
地震や原発など、収束が見えない状況ですが、僕は「普通の仕事や生活を送れる方は、これまで通り普通に頑張ろう。それが結局は被災した方々の力になる」という考え方。
空気を読まず、通常通りプロジェクトについて書きます。
★死に至る病、ITPS
皆さんはITPSという病気を、もちろんご存じないと思う。移行の(I)、大変さ（T)、ピンとこないよ(P)、症候群(S)の略である。
システムの移行作業（旧システムから新システムにデータを移し、新システムでもこれまで通り業務が出来るようにすること）は大変な仕事である。とてもとても大変な仕事である。
「プロジェクトで必要な工数の4割が移行作業」とも言われている。
が、この大変さを分かっていない人、言われても大変さが想像出来ない人は実に多い。
ITコンサルタントの端くれとして失格なのだが、移行がどんなに大変かを一緒にプロジェクトをやっている人たちに説明するのに、僕はいつも苦労してきた。というか正直に言うと、いつも説明や説得に失敗してきた。
これだけ失敗が重なるということはなにか構造的な問題があるとにらみ、半年くらい前にITPSという病名をつけてみた。
大変怖い病気である。プロジェクトのキーマン、オーナーがITPSを発病していると、当然ながら移行作業へ充分な人と時間を割かない。4割どころか、1割くらいしか工数を用意しないケースもある。
そして準備不足なまま本番直前を迎え、どうにもならなくなる。
「移行作業が間に合わないから、本番稼動を遅らせます」
「移行データがぼろぼろなので、システムは正しく動くハズだけど、使い物にならない」
というプロジェクトは実に多い。
たちの悪いことに、システム構築会社が稼動遅延の責任を顧客に押しつける口実に、しばしば使われる。
★ほとんどの人が感染者
ちなみに、経験的にはITプロジェクトに関わるメンバーのうち、業務担当者（ユーザー代表）の8割、システム担当者（開発者）の6割がITPSに感染していると思う。
僕だってかつては「データ移行なんかに、何であんなに工数積むんだ？」と言っている上司に対して、何となくおかしいと思いながらも「そんなもんですかね～」と同調していた。ほんの6年くらい前の話。
あと、「今回のプロジェクトでは○○だから、移行は問題ない」というのもくせ者なんだよね。
なぜこんなに感染者が多いのか。僕の仮説はこうだ。
「作ることの大変さ vs 引っ越しの大変さ」の比率を考えたとき、引っ越し側がこんなに大変なことって世の中に滅多にない。だからうまく想像が出来ない。
例えば、PCの引っ越しを考えてみよう。PCの引っ越しってめんどくさいですよね。アプリをインストールして、メールログをエクスポートして、IME辞書をエクスポートして・・。ああ、誰か僕の代わりにやって下さい。
でも、「PCを1から作ることの大変さ」とは比較にならない。僕はチップ回路設計者でもPC自作派でもないから、そもそもどれだけ大変なのか、想像もつかない。
「家を引っ越す vs 家を一から建てる」の大変さ比較だって似たようなものだ。引っ越しが大変さの4割を占める訳がない。
つまり、大企業で使うオーダーメイド・コンピュータシステムの移行は、世の中の引っ越し的な作業のなかでも、例外的に大変なのだ。だから「工数の4割」と聞いた時、または移行作業のきちんとした見積りを見せられたとき「いくら何でもそりゃ過大見積もりでしょ」と思ってしまう。
こういう「錯覚の檻」から理性で脱出するのは極めて困難だ。いくら僕らがプロジェクトのプロ、システムのプロの立場から理を尽くして説いても、覆すのはしんどい。
★システム構築のベテランでも感染する
僕が一緒にプロジェクトをやっている方々のなかには、「この会社のほとんどのシステムはオレが立ち上げてきた」というようなベテランSEもいらっしゃる。
通常、そういう方はプロジェクトで凄く頼りになるし、プロジェクト管理に関する判断も妥当なことが多い。
だが、移行に関してはそうとは限らない。ベテランSEのITPS感染者も実に多い。なぜなら、移行は年々難しくなっているからだ。にもかかわらず、ベテランは過去の経験をベースに考える（当たり前ですね）。すると、必ずと言っていいくらい過少見積りになってしまうのだ。彼らが経験してきた過去の移行作業に比べ、桁が違う難易度になっていることが多い。
ベテランSEが経験してきた過去のプロジェクトは、
・それまで手でやっていた業務をゼロからシステム化するプロジェクト（規模大）
・基幹システムに機能を継ぎ足すプロジェクト（規模中。例えばホストコンピュータで構築した給与計算システムに、オープン系の人事管理システムを接続するプロジェクトなど）
・比較的小さな業務領域のシステム構築プロジェクト（規模小）
のいずれかであることが多い。
どちらも、移行のことは余り考えなくて良いか、極単純な移行作業で足りる。
一方、近年の大規模プロジェクトの例として、前述のホストコンピュータ＋オープン系で作った人事システムを、人事パッケージに置き換えるプロジェクトを想像してみて欲しい。
こういうケースでは、これまで蓄積してきた過去データをすっぱり捨てる訳にはいかない。人事情報をゼロから2万人分集めるなんてナンセンスだし、給与をいくら支払ったか、の実績情報がなければ年末調整も出来ない。
そして、経年劣化してきた旧システムのコード体系を全面的に見直したり、貯まったゴミデータをキレイにする（クレンジングと言います）必要もある。自然と、移行作業は過去の遺産が少なかった頃に比べ、格段に難しくなる。
だから、過去の経験を元に移行の大変さを推測すると、必ず痛い目にあうのだ。
ベテランSEの方々は偉くなっていて、プロジェクトの見積りや体制を考えるときに発言権が強いことも多いので、そういう方がITPSに感染していると、とてもやっかいだ。
まとめ。移行作業の難しさはピンとこない。だから移行でつまずくプロジェクトは多い。というか、大抵のプロジェクトは移行でつまずく。
長くなってきたので、今日はここまで。続き（なぜ移行が難しいのか、そして対処法はあるのか？）は明日アップします。