本社移転の日程が変わった。入退室システム導入を止めなかった「推進力」｜支援実績

本社移転に合わせて、新しい入退室システムを導入するプロジェクトが始まりました。

本社の利用者全体が使うシステムであり、移転日までに稼働させる必要があります。

プロジェクトが進む途中で、本社移転の日程とシステムへの要望が複数回変わりました。

日付や設定だけを直せば済む変更ではなく、ベンダーの作業、サーバーの設置、インフラ条件、検証の順番、関係者の確認予定まで、影響する範囲を整理し直さなければなりません。

すべての情報を、一人の担当者が持っていたわけでもありません。

製品の仕様はシステムベンダー、サーバーや基盤の条件はインフラ担当、本社移転全体の日程や利用者への影響は顧客側の担当者が見ています。

異なる立場の情報を集め、変更後も各担当者が次の判断と作業へ進める状態を作ることが、今回のプロジェクトで必要になった推進力でした。

入退室システムは、製品を決めれば導入できるわけではない

入退室システムの導入は、製品を選び、ベンダーへ設定を依頼するだけでは進みません。

利用者側が求める機能を確認して製品仕様と照らし合わせ、サーバーを設置できる環境と関連するインフラ条件を整える。さらに、ベンダーの作業工程と検証方法を決め、誰が結果を確認するのかまでそろえる必要があります。

本社移転を伴う場合は、システム側の都合だけで日程を決めることもできません。

設備工事や移転準備が進む中で、いつサーバーを設置でき、どの時点から検証を始められるのか。利用者が新しいオフィスを使い始める日までに、何を確認しておかなければならないのか。

一つひとつの作業には、前提となる別の作業があります。

サーバーの設置が終わらなければ、その環境を使う作業へ進めず、インフラ条件が確定しなければ、ベンダーも作業方法を決められません。検証が終わらなければ、利用開始を判断するための情報もそろいません。

入退室システムの導入は、製品を動かすための作業だけでなく、複数の担当者が持つ条件を、移転日という一つの期限へ合わせるプロジェクトでした。

誰か一人が、すべての情報を持っていたわけではない

今回のプロジェクトには、システムベンダー、製薬企業側のシステム担当、顧客側の担当者、インフラ担当など、約10名が関わりました。

それぞれが見ている範囲は異なります。

顧客側の担当者は、本社移転全体の日程や利用者への影響、社内で確認すべき事項を把握しています。

製薬企業側のシステム担当は、既存の社内システムとの関係や、社内側で必要になる確認を見ています。

システムベンダーは製品の仕様、導入条件、技術上の制約、作業工程を持ち、インフラ担当はサーバーや基盤の構成、設置条件、インフラ側で必要な作業を確認します。

各担当者が自分の領域だけを見ていたわけではありませんが、プロジェクト全体に必要な情報が、最初から一人の手元へそろっていたわけでもありません。

システム責任者は、それぞれから情報を集め、別の担当者が判断できる形へ変えて戻します。

顧客側から要望が出れば、製品仕様で対応できるかをベンダーへ確認する。ベンダーからインフラ条件を求められれば、質問を整理してインフラ担当へ渡す。得られた回答によって日程や検証内容が変わるなら、その影響を関係者へ共有する。

単に情報を転送するのではなく、誰が何を判断するための情報なのかを整理することが、システム責任者の役割でした。

専門外の領域を、曖昧なまま進めない

入退室システムを導入する中では、サーバー設置や基盤条件など、インフラに関する確認も必要になりました。

システム責任者が、インフラのすべてを専門としていたわけではありません。

専門外の領域を自分の推測だけで補えば、その後の作業条件が誤った前提で決まる可能性があります。

そこで、まず関連資料を調べ、理解できていることと確認が必要なことを分けました。

ベンダーが必要としている情報は何か。サーバー設置に当たり、どの条件を確定する必要があるのか。現在の説明だけでは判断できない点はどこか。

質問を具体化した上でインフラ担当や有識者へ確認し、得られた回答は、そのまま別の担当者へ転送するのではなく、ベンダーが作業条件として使える形へ整理します。

追加確認が必要なら再び質問を戻し、日程や検証へ影響する内容であれば関係者へ共有します。

専門外の領域を扱うときに必要だったのは、すべてを一人で習得することではありません。

自分が何を理解できていないのかを明らかにし、その情報を持つ人へ確認した上で、得られた回答をプロジェクトの次の作業へつなぐことでした。

日程変更は、予定表の日付を動かすだけではない

プロジェクトの途中で、本社移転の日程が変更されました。

日程が変われば、システムの稼働予定だけでなく、それまでに行う複数の作業を見直さなければなりません。

ベンダーは変更後の日程で作業できるのか。サーバーの設置はいつ完了し、インフラ側の作業と重ならないか。検証を始められる時期は変わるのか。結果を確認する担当者の予定を確保でき、未完了の作業を新しい稼働日までに終えられるのか。

日程変更への対応は、予定表の日付を一か所書き換えることではなく、前提となる作業がいつ終わり、次の作業を誰が開始できるのかを確認し直す仕事でした。

例えば、検証予定だけを後ろへ動かすのであれば簡単に見えます。

しかし、検証に必要な環境を使える期間、ベンダーが立ち会える日、結果を確認する担当者の予定が合わなければ、同じ順番で作業できるとは限りません。

変更後の日程を受け取ったシステム責任者は、影響する作業を分けて各担当者へ確認し、その回答を基に作業順、確認予定、未完了事項を整理し直した上で、新しい計画を関係者へ戻しました。

必要だったのは、日程を決め直すことではなく、関係者がその日程で動ける条件をそろえることです。

要望が変われば、確認する範囲も変わる

プロジェクト中には、入退室システムへの要望も変更されました。

具体的な要望内容は公開できませんが、変更があれば、製品上で対応可能かを確認するだけでは足りません。

追加の設定や作業が必要になるのか。インフラ条件や検証項目、ベンダーの工程や日程へ影響するのか。顧客側で新たな確認や承認が必要になり、稼働日に必要な条件を満たせるのか。

一つの要望変更が、別の担当者の作業を増やしたり、すでに決めた検証内容を変えたりすることがあります。

そのため、変更を受けた時点で、何が変わり、既存の計画のどこへ影響するのかを分けました。

製品仕様に関する確認はベンダーへ戻し、基盤条件へ関係する場合はインフラ担当へ確認する。利用方法や社内判断が必要なら、顧客側の担当者へ確認を依頼する。

回答がそろった後は、変更によって追加された作業と、変更せずに進められる作業を整理します。

「変更へ柔軟に対応した」という言葉だけでは、この仕事は見えません。

実際に行ったのは、変更のたびに影響を分解し、必要な情報を持つ担当者を特定して、未確定事項を関係者が判断できる状態へ戻すことでした。

懸念事項は、問題になる前に確認へ変える

プロジェクトを進める中では、サーバー設置、技術条件、作業日程、検証工程など、後の作業へ影響しそうな点を洗い出しました。

懸念事項を共有するのは、不安要素を並べるためではありません。

そのままにするとどの作業が止まるのか、誰が情報を持っていて、何を確認すれば次へ進めるのか。いつまでに判断が必要なのかを明らかにし、確認する時間を先に確保するためです。

例えば、技術条件が確定していない場合、「未確定」と記録するだけではプロジェクトは進みません。

誰へ確認し、どの資料が必要なのか。回答を受けた後、ベンダーや検証担当へ何を戻し、作業日程へ影響するなら、いつまでに回答を得なければならないのか。

未完了事項には、担当者と次の行動を結び付けました。

ベンダーとの連絡でも、情報量を増やすことが目的ではありません。

要望の変更、顧客側の確認結果、インフラ担当からの回答、残っている技術上の確認、次に必要な作業を、相手が判断できる形で共有します。

連絡したという事実ではなく、その連絡によって誰が次に動けるようになったかを見ることが必要でした。

変更後も、稼働に必要な条件を保つ

プロジェクトは約9か月にわたって進みました。
移転日程とシステムへの要望は、途中で複数回変更されています。

そのたびに、影響する作業、担当者、確認事項、ベンダーの日程、サーバー設置、検証の順番を整理し直しました。

すべての変更を、システム責任者だけで判断したわけではありません。

製品についてはベンダー、インフラについては担当者、利用者への影響や社内確認については顧客側が、それぞれの役割を担っています。

システム責任者は、各担当者が判断するための情報を集め、変更後の作業を再びつなぎました。

最終的には、本社移転日に合わせて入退室システムの稼働を開始し、稼働後にも大きなトラブルは発生していません。

これは、最初に決めた計画を一度も変えずに進めた結果ではありません。

変更を受けるたびに、稼働に必要な条件を確認し直し、関係者が次の作業へ進める状態を作り直した結果です。

このプロジェクトでの「推進力」とは何だったのか

システム導入の実績は、実施した作業の数だけでは説明できません。

要件を整理し、ベンダーと調整して、インフラ担当へ確認する。サーバー設置に関わり、検証を進める。

一つひとつは必要な作業ですが、今回のプロジェクトで中心になったのは、作業を多く抱えることではありませんでした。

変更を受け取ったときに影響する工程を特定し、必要な情報を誰が持っているのかを見つける。相手が回答できる質問へ整理し、得られた情報を別の担当者が判断できる形へ変える。

さらに、未完了事項、確認する人、次の行動を明らかにしながら、移転日に必要な条件が保たれているかを確かめる。

こうした仕事を繰り返すことで、各担当者は自分が次に行う作業へ進めました。

ディーシステムでは、システム導入に必要な作業を実施するだけでなく、顧客、利用部門、ベンダー、インフラ担当など、異なる関係者の間に入り、要件、技術条件、日程、未完了事項を整理しながらプロジェクトを進めています。

すべての技術を一人で抱えるのではなく、必要な情報を持つ人へ確認し、その回答を次の担当者が判断できる情報へ変える。

今回の入退室システム導入は、会社資料に掲げる「作業力ではなく、推進力」を、実際の行動として示したプロジェクトの一つです。

この案件での推進力とは、異なる立場の情報をつなぎ、変更があっても、関係者が次の判断と作業へ進める状態を保つことでした。

移転に伴うシステム導入を進めるために

本社や拠点の移転に伴うシステム導入では、製品選定だけでなく、設備、インフラ、ベンダー作業、利用部門、移転日程を並行して整理する必要があります。

ディーシステムでは、要件が完全に固まっていない段階や、複数の関係者の役割が整理されていない段階から、確認事項、影響範囲、作業順序を整理し、プロジェクトを進める支援を行っています。

関連記事

• ディーシステムは、顧客現場で何を支援してきたのか。プロジェクト実績から見る仕事のかたち

• 基幹システム統合で、業務と周辺システムの接続をどう整理するか

• 運用とベンダー調整を任せたら、情報システム部の仕事はどう変わったのか

• ERP導入後は、どんな仕事が続くのか。運用保守で行う8つの業務