ITPS症状緩和法、あるいは移行で転ばぬ先の杖
前回（ITPS、あるいは移行の大変さピンとこないよ症候群）の続きです。
★移行はなぜ難しいか
前回は話を分かりやすくするために「大変」「工数がたくさん必要」という話をしてきた。でも、移行作業が本当にやっかいなのは、難易度が凄く高いことだ。
難しいから、それほど優秀でない人たちをたくさん集めても、結局進まないということもおこる。移行が難しくなってしまう理由を挙げてみよう。
1)旧システムと新システム、両方の知識が必要
移行とは簡単に言えば、旧システムからデータを抽出して、新システムに入れることだ。当然、両方のシステムについて理解していないと、どう移行すればよいのかを検討出来ない。
もちろん、データを加工するプログラムを作る「だけ」なら片一方しか理解していなくても出来るのだが、その人に指示を出す人はどっちにしろ必要となる。
システム構築プロジェクトになじみのある人なら想像していただけると思うが、ほとんどのケースで旧システムの保守担当者と新システムの構築担当者は別人だし、両方を理解している人をプロジェクトを通じて育成するのは構造的に難しい。
2)業務とシステム、両方の知識が必要
移行作業はデータを抽出したり、フォーマットを変えたり、また投入したり、とプログラマー的な作業だと思われることが多い。もちろんそれも必要なのだが、もっと必要なのは業務知識だ。
「新しい業務では受注の考え方がこう変わるので、旧システムのデータをこう組み合わせれば必要なデータを生成出来るはず・・」
ということを考えるとき、ポイントは「受注の考え方がこう変わるので」というところ。業務要件ですね。
「経理上、債権情報はこういう状態でなければならないから新システムでは・・」
というような時でも、検討の前提は業務知識があること。
3)ファシリテーション力が必要
でも、実際に旧システムも新システムも業務も全部把握しているようなスーパーマンは滅多にいない。まれにいるが、そういう人材は移行ではなくて、エースとして新システムのメイン設計者に抜擢されるのが普通だ（プロジェクトで人材配置を考える人もITPSに感染しているから）。
通常は、
a)旧システムのことだけ知っている人（大抵情シス部門の古参社員）
b)新システムのことだけ知っている人（パッケージに詳しいベンダーコンサルタントなど）
c)業務知識があるけど、システムには明るくない人
がバラバラに存在していることになる。しかも、みんな移行以外の自分の仕事で頭がいっぱい。
自分が知識を持っていないけれども、人から知識を引き出し、みんなを束ねて仕事をしてもらう人のことをファシリテーターと呼ぶ。
上記a,b,cと会話し、統合して「結局どう移行すればいいか」を描くのはとても高度な仕事である。
しかし実際のプロジェクトでは、大抵a)の様な人が移行担当に指名される（しつこいけど、プロジェクトで人材配置を考える人もITPSに感染しているから）。
4)問題解決力が必要
移行作業を進めていると、「実は旧システムを抜け道的な方法で使っていた」「こういうデータはあるはずがないのだが、ある」といった、想定外の事態にぶつかることが多い。
理詰めでコツコツと積み上げていけばよい新規開発と異なり、問題が出てはつぶし、出てはつぶし・・をやっていかなければならない。宿命的モグラ叩き。
ちんたらやっていては全然終わらないから、問題解決をスピーディにこなす力が、個人としても組織としても求められる。でも大抵の組織はモグラ叩き的に問題解決する、というワークスタイルに慣れていない。だから「移行が原因で稼動が遅れる」という事態に追い込まれることが多い。
5)全ての問題が表出するのが移行
システムはデータの流れである。新システムの設計がデータ面でイケてない時は「移行がうまくいかない」という現象になって表れることが多い。真の原因は移行以外にあるのだが、割を食うのは移行作業。移行担当者はタフじゃないとつとまらない。
★じゃあ、どうすればいいか a)移行作業を緻密に見積もる（正攻法） b)エースを移行チームに配置 c)移行設計専用フェーズ ※ここまで書いたところで、例の地震が来ました。僕は東京、しかも自分のオフィスではなく最新の免震ビル1階にいたので、こんなにひどいことになるとは想像出来ませんでした・・。 d)移行専用予備費 e)ヤバイぞアンテナを磨く まとめ。ITPSに対処するのは難しい。でもプロジェクトを成功させるためには乗りこえなければならない壁。みんな頑張りましょう。僕ももっと修行します。
僕もここから先は毎回痛い目にあっているので、特効薬的解決策は分からない。すみません。
苦肉の策としていつもやる方法はこんな感じ。
移行の計画をプロジェクトの早い段階（要件定義中など）に立て始め、開発見積の時に、移行プログラムの本数や難易度もきちっと見積もる。
周りの方々のITPSがあまり進行していない場合にできる方法。当然反対にあうが、ねばり強く説得する。
これも、ITPS症状が比較的軽く、スケジュールのやりくりがつきやすい場合。
エースを移行担当に配置するのが難しいなら、新規開発の要件定義や設計を一旦とめ、プロジェクト全体で移行のことだけに集中するフェーズを作る。嫌でも移行の検討に向き合わざるをえないようにする。
「何が起こるのか分からないのがプロジェクト、だから用途が決まっていない予備費を見積りに入れましょう」というのがシステム構築の見積りの常道。その一部として「移行で使う確率が高い予備費」という枠を設ける。当然予備費の総額は増やさなければ意味がない。
こんなことをするくらいなら最初から移行用の予算として見積もれば良いのだが、ITPS患者にとってはこちらの方が受け入れやすい。
周りのITPS患者の説得に失敗し、事前に充分な体制を組めなかった場合。被害を小さくするためには、うまくいかない兆候を真っ先に察知して、被害が大きくなる前に手を打つしかない。
事前に説明しても納得が得られないことでも、よほど重症のITPS患者以外は、うまくいかなくなってきたFactを示せば、対策を打つのに同意してくれる。
ヤバイぞアンテナの回で書いたように、問題が露見する様なイベントを仕掛けるのも効果的。
今日はここまで。