「表裏一体」のプロジェクトが成功のカギ
実際に、業務改革や経営課題の解決とNotesマイグレーションを表裏一体の形で推進し、成功した事例は多いようだ。
ある都市銀行のケースでは、経営企画部が主導することで立ち上げた「組織改革プロジェクト」にシステム開発部門が参加して、実質的なNotesマイグレーションプロジェクトを成功させたという。
また、ある企業では、システム企画部門が業務改革を主導することになり、前面には「Notesの更新に伴うシステム変更」をうたいつつ、その実態はビジネスプロセスの改革にまで踏み込んだプロジェクトを行った例があるという。
この企業では、情報伝達や共有の効率化が課題だったが、業務分析の結果、マネージャーがすべての情報流通のハブになっていることが非効率の原因と判明。状況を改善するために、ウェブ上に新たな情報共有の場を作ることで、ボトルネックの解消を図った。一見、単純なシステム変更のように見えるが、実際には、システムを先行して変更することで、情報の流れ方を変えてしまい、それによって組織の構造（ここでは、マネージャーの業務と役割）自体を抜本的に変えることができたというケースだ。
「企業コラボレーション基盤の改革を、単なる“システムの変更”で終わらせてしまうのはあまりにももったいない。企業独自の思想に基づき、情報の流れを改革し、結果として組織に大きな価値をもたらす。Notesマイグレーションというテーマは、それだけ大きな主題をはらむものだと認識すべきだ」（吉田氏）
「旗振り役」と「錦の御旗」が課題
ただし、問題が2つある。
1つは、誰がプロジェクトを進行させるべきかの判断が難しいことだ。コラボレーション改革の旗振り役はIT部門なのか、経営企画部なのかという議論は多い。
先に紹介した成功例では、銀行の場合はトップダウンで経営企画部が主導したが、ITにも通じたスキルやセンスを持つ担当者の存在が大きかったという。また、もうひとつのケースはIT部門が各部門で抱える問題を先導したボトムアップ型だった。成功の陰には、各部門が持つNotes DBの不活性を2年かけて調査するという、システム部ならではの地道な努力があった。
吉田氏は「もしIT部門だけでは荷が重すぎるのなら、経営企画部と連携して実行するのがよいだろう。企業独自の文化や意思決定方法によってケースバイケースに考えざるをえないのかもしれない」と話す。
もう1つの問題は、改革の手段になりうるポジティブな動機の存在。簡単に言えば、何をNotesマイグレーションの“錦の御旗”にするかだ。
この場合、企業合併や社外企業グループとの情報共有といった要請があれば、比較的プロジェクトを進めやすい。ただし、「情報共有のコストダウン」といった限定的な動機では、「総論賛成、各論反対」でプロジェクトが進まないことも多い。「改革のための強い動機」はぜひとも欲しいところだが、そう都合良く大きなイベントが発生することもまれだろう。大事なのは、チャンスを見逃さずに捕らえて一気に押し切ることであり、その機会の到来の前に、十分な根回しをしておく準備も怠るべきではない。
