最初からNotes移行を目的にはしていない
過去10年以上、Notesを利用してきたコクヨでは、2004年12月時点でグループ全体でのユーザーIDが4100を数え、その全員にデータベース（DB）開発権限を与えてエンドユーザーデベロップメント（EUD、業務の効率化を図るためにエンドユーザー自らがシステム開発を行うこと）を推進してきた。その影響から、調査時のデータベース数はおよそ3000にも達し、継続運用が懸念されていた。
Notesに限界を感じた要因のひとつが運用管理コストの負担だ。2004年当時、Notes/Domino R5からのバージョンアップ対応を検討したところ、一度「R6.5」を経て「R8」へバージョンアップを行い、さらにはウェブ化対応が必要との返答を受けた。そのために必要な数億円の投資と、バージョンアップから得られる効果のバランスに対して、経営層からは不満が示されたという。
コクヨは、Notesに関してかなりのヘビーユーザーであり、業務アプリケーションについても、Notesのスクリプトを使った決裁システムや与信管理システムなどが稼働している状況だった。上位互換の保証がない中で、旧DBを移行するにあたっては、さらなるコストの増大が想定された。
そしてもうひとつの要因が、実際にNotesを利用している現場ユーザーの不安だった。「社内に情報はあるのだが、それが相手に伝わらない」「欲しい情報が探せない」「他ユーザーが開発したDBを誰も引き継げない」といったデメリットを指摘する声が、次第に大きくなってきていた。
土山氏は「私たちは、Notes移行を最初から目的にはしていなかった。本来解決すべき課題を定義することで、その課題解決に取り組むチャンスとしてNotes移行を位置づけた」と、この取り組みが「単なる移行のための移行」ではない点を強調する。
もちろん、長期にわたってNotesを使ってきた現場からは、Notes完全移行の決断に対して強い抵抗もあった。特に、NotesのEUDに代わるほど、簡易にDB開発を可能にする開発基盤が他に存在しないことが問題とされた。
一時は「Microsoft Office SharePoint Portal Server 2003」を検討したが、コクヨ側の要望を実現するために検討した「InfoPath」は、クライアントのOfficeスイート製品を上位版に変える投資が必要とされ、開発作業自体もエンドユーザーにとってNotesほど容易なものとはいえないと判断された。
土山氏は悩んだ末、当時、次期コミュニケーション基盤の候補として検討をしていたEIP（企業情報ポータル）型グループウェア「INSUITE enterprise」（INSUITE）の国産ベンダーであるドリーム・アーツに相談を持ちかけたところ、新たなウェブDB製品の開発を進めることの合意を得た。その結果として生まれたウェブDBは、後に「ひびき Sm@rtDB」という名称の製品としてドリーム・アーツから提供されることになった。
こうした試行錯誤から、「短期間での完全移行は困難」と判断した土山氏は、当面はNotesとウェブが共存できる基盤を作り、最終的に完全にウェブベースのコラボレーション基盤を目指すという中期的なプロジェクトを組織することになる。
ウェブポータル化するためにNotesを捨てた
コクヨグループのNotes移行プロジェクトは、第1フェーズとして2005年7月に、全社共通性の高いグループポータルの構築とグループウェアの基本機能を実装。ユーザーがある程度環境になじんだ後、同年10月から第2フェーズとして、子会社独自の利用を進めるためポータルの横展開を開始した。
同時に、Notes DBの再構築も実施していったが、土山氏らWeb化推進グループを中心に、ユーザー自身がこつこつと作業を行うことでコストを大幅に節約できたという。ウェブポータルへ移行したことで、それまで閉じたシステムで各部がバラバラに作っていた「行動予定」「会議室予約」「社内電話帳」は、共通機能の「スケジューラ」「施設予約」「共通アドレス帳」に統一したほか、社内ブログシステムや動画配信、在席確認（プレゼンス）、簡易テレビ会議、ライブラリ（簡易ディスカッションDB作成）などの各機能も次々に実装するなど、最適なソフトウェアの選択が可能になることにより、拡張性やオープン性は一気に高まっていった。
「ウェブポータル化するためにNotesを捨てたといっても過言ではない」という土山氏は、「今後は、要件にあった専門性のあるソフトウェアをいかに組み合わせるかが問われるだろう。だが、それは新たな可能性が開けたという証拠でもある」と話す（図1）。
図1：現状のNotes活用レベルとウェブ化で目指すべき姿とのマトリックス分析。縦軸は「現状のNotes活用レベル」、横軸は「移行によって目指す情報活用の姿」を表す。ここでカギとなっているのは、エンドユーザー開発（EUD）に対するニーズ。移行の難易度は、現状と目標のサービスレベルが離れているほど高くなる（特に「☆」のケース）。移行によって何を実現したいかを検討するにあたって、こうした分析は不可欠だ（画像をクリックすると拡大表示します）
