システム構築の流れに沿って全体日程を作成します。
ユーザ数1,000人規模のシステムを構築する場合は、少なくても1年半くらいの時間がかかると思われます。
概略の日程は以下の図のようになります。
先に「システム構築の流れ」で各フェーズで実施する内容を箇条書きで書きました。
その内容にいくつかの項目を追加して日程にしています。
各フェーズで実施する内容は、先行するフェーズから準備が開始されていることが多くあります。
ほとんどがそうかもしれません。
各フェーズで実施することがそのフェーズ内で完結するのはまれで、先行するフェーズからすでに準備を行い、その結果がそのフェーズで出る形です。
ですから、いかに全体計画を立て、早め早めの準備を行いながら、日程をチェックしていくことが大事かが分かると思います。
では、簡単に各フェーズにかかる時間の考え方について説明しましょう。
準備フェーズ
準備フェーズは、業務改革のプロジェクトを立ち上げ、システム、ベンダを選定し、会社に提案する前までの活動になります。
システムの導入を開始するまでの準備段階で、システムを導入して業務を変える、その意味を社内で合意するフェーズですが、その合意に手間取ると思ったよりも時間がかかります。
期間が読めないフェーズでもあります。
プロジェクト体制の構築
関係する人を集めて、プロジェクト体制を作ります。
打ち合わせ、定例、ステアリングコミッティなどのコミュニケーションルールを作成します。
それをまとめてプロジェクト憲章を作成します。
これらの作業を考えると、単純に考えると決めれば良い内容ばかりなのですが、関係する人たちにシステムを使った業務改革の内容を理解してもらうのに説明に時間がかかります。
いかに参加する人たちに危機感を持ってもらって、当事者意識を高めるか、地道な説得作業が続きます。
また、同一の組織でのプロジェクトであればまだ良いですが、組織をまたいだプロジェクトになると、人、予算の確保の交渉などが必要となり、時間がかかります。
システム/ベンダ選定
導入するシステムと、それを設計して販売するベンダの選定を行います。
ここでは、システム導入のための市場調査などの期間も入れています。
市場調査は世の中の動向を知る上で、非常に重要です。
これによって、世の中にどのようなシステムがあり、どのような会社がどのようなシステムを使った業務改革をやっているかを知ることができます。
最初はシステムを絞り込まずに調査する必要があるので、３～５システムを調査します。
調査のあとに数システムに絞り込んだ上で、細かな比較調査をするので、３ヶ月程度と大変時間と工数がかかります。
提案書の作成
収集した情報を基に提案書を作成します。
提案書は今回導入するシステムの提案だけの場合もありますが、将来構想を含んだ提案が必要な場合は、この日程に長期計画作成の日程が追加されます。
ここで提示してる約２ヶ月の日程は将来構想までは含まない日程です。
システムを使った業務改革は会社の上層部に提案するため、承認された場合はこの後会社の方針に直結します。
今後の業務に大きな影響を与えるので、提案前にはプロジェクトに関係する部署の合意を取り付けるなどの作業が発生します。
プロジェクト全体の見積もり
プロジェクト全体にかかる費用の見積もりをします。
提案をするためには、プロジェクト全体でおおよそどれくらいの費用がかかるのか、概算費用を出す必要があります。
まだ仕様も決まっていない中で、おおよそかかる費用を算出しなければなりません。
しかし、大方はここで、今回のプロジェクトに投資する金額が決定します。
システムを使った業務改革の構想書などを基にベンダの協力を得て数字を出しますが、打ち合わせによって大きく数字が揺れるため、プロジェクト内部での合意に時間がかかります。
よって、最低でも１ヶ月以上の時間はかかると思って計画しましょう。
提案フェーズ
準備段階でまとめた提案資料を持って、会社上層部へ提案を行い、システム導入の承認を得るフェーズです。
提案フェーズの期間は、関係する部署と、投資金額による社内稟議のレベルによります。
導入するシステムに関係する部署が多いと、多くの部署に対してシステム導入の合意を得る必要があります。
投資金額が大きいと社内の稟議のルールに従って、何度も社内会議にかけられる場合があり、大変時間を要します。
提案活動
作成した提案書を持って、会社上層部にプロジェクトの提案をします。
社内の提案のルールがあると思いますので、そのルールに従って会社に提案することになりますが、ほとんどのシステム導入の提案の場合、提案の内容を理解してもらうのにかなりの時間がかかります。
それはなぜかというと、会社の経営者にITの知識が無いため、簡単に提案の中身が理解できないからです。
中身が理解できないのに、その提案の金額は数千万円から数億とかなりの高額となっており、経営者が判断ができない状態に陥ります。
いかに会社経営者にITの知識を持ってもらい、システムを導入せずにそのままの状態になった場合に会社がどれだけ危険な状態になるか、危機感を持ってもらう必要があります。
何度も何度も説明し、会社経営者に知識を持ってもらい、理解してもらう時間をとりましょう。
契約
選択したベンダとプロジェクトに参加する外部の会社などと契約を行います。
契約はプロジェクト全体を包括して契約する場合や、フェーズごとに何度も契約するなど、いろいろなパターンがあります。
自社だけでなく、相手方のルールがあるので、事前によく確認しておきましょう。
相手方の社内の契約ルールが厳しく、契約がきまってから契約が完了するまでに数週間かかるなどになってしまうと、その期間次の業務ができない状態になってしまう場合があります。
契約できないから作業が進まない、そのような状態にならないように十分注意しましょう。
プロジェクトルームの設置
プロジェクトに参加するベンダや外注業者が集まり、作業する環境を整備することを「プロジェクトールムの設置」としています。
プロジェクトに参加するベンダや外注業者が使用する部屋や備品の準備をします。
大きなプロジェクトの場合は参加する人が何十人もの規模になるので、プロジェクトルームが必要になります。
突然会社に「専用のプロジェクトルームが必要です」と言っても、普通はそのような部屋の空きはありません。
またベンダや外注業者や社内で使用するパソコンも手配する必要があります。
今はリモート会議などのがあるので、会社に常駐の必要は無いと思いますが、最低限出社する人分の居室の確保が必要です。
また、それらの人が使用するパソコンの準備や社内のITシステムへの登録も必要になります。
社内のメールやサーバーの使用登録やルールを決めるなど、様々な準備が必要となります。
社内のIT部門と協業しながら進めましょう。
プロジェクトのキックオフ
会社への提案が通った段階で、プロジェクトのキックオフを行いましょう。
キックオフををすることによって、プロジェクトに参加する社員、ベンダ、外注業者の意識を高めます。
また、イベントを行うことで、社内へのプロジェクトの情報発信にもなります。
キックオフでは是非会社経営者に挨拶をしていただき、本プロジェクトへの期待、その効果をアピールしてもらいましょう。
会社経営者が社内に向けて直接情報発信をすることは重要です。
社内にプロジェクトの内容を伝えるよい機会です。
キックオフは数時間で終わると思いますが、多くの人達を呼んで開催しますので、失敗は許されません。
大きなプロジェクトになると、ベンダーの会社の経営層などが参加する場合もあります。
早めに準備に着手しましょう。
要求定義フェーズ
要求定義フェーズは、ユーザー側がシステムに対する要求をまとめるフェーズであり、検討、まとめ、合意を何度も繰り返す事になります。
この段階ではまだ要求をまとめるプロジェクト側と、実際に業務するユーザー側に新しいシステムや、システムを使った業務に対する理解度の差がある状態です。
なかなかプロジェクト側が考える事が、実際に業務するユーザーに伝わらず合意に至らない、などの状態になる可能性があり、それらが要求定義フェーズを長引かせる原因になります。
新業務フロー図の作成
現状の業務（As-Is）と新しい業務（To-Be）を作成し、業務がどのように変わるのかが分かる状態にします。
今回のプロジェクトの範囲の中の部署に対して、ヒアリングを実施し、業務フロー図を作成します。
１部署、１部署対面で実施することになるので、大変時間がかかります。
ヒアリングの前には予め分かる範囲で現場業務のフロー図を作成するなど準備をしっかりやりましょう。
そうしないと、時間ばかりかかって、進まない状態に陥ります。
要求の洗い出し
今回のプロジェクトの業務範囲で、変更したい内容を全て書き出します。
どの程度まで要求を書き出したら良いか、最初は迷ってしまい要求の「粒度」が揃いません。
それでも良いので、まずは考えられる要求事項を全て書き出し、最終的にはそれを整理します。
まずは、やりたいことを全て出し切ることが大事です。
プロジェクト内の要求が全て集まるので、大量の要求に対して、同一、類似の要求を精査する作業が発生します。
長い時間かけて要求を収集するのではなく、まずは短時間で要求を出してもらい、それをまとめた上で、追加する要求を出してもらう形が良いと思われます。
そうすることによって、要求のダブりなどが減らせます。
短時間で要求を出してもらい、その後その精査にしっかりと時間をかける、その考えで進めましょう。
要求仕様書の作成
洗い出した要求を精査して要求仕様書を作成します。
要求がどの業務に対する要求かが分かるように、業務ごとに分類して要求仕様書を作ります。
大量にある要求の中から本当に新しい業務に必要な要求を厳選して行く必要があります。
プロジェクトで出された全ての要求をただまとめただけだと、大量の要求になり、それを実現するには開発時間も開発費用も膨大となります。
必要最低限の要求にまとめ上げる必要があります。
しかし、はじめて要求仕様書を作成する場合などは、「何を書いたら良いのか分からない」状態に陥ります。
参考になる要求仕様書をベンダーにもらったり、一度書いた要求仕様書を社内のIT部門に見てもらうなどして書き進めましょう。
要求の合意
まとめ上げた要求仕様書をプロジェクトに参加する人、部署に説明し合意を取り付けます。
要求の合意はプロジェクトの中で一番手間がかかる業務です。
絶対に出した要求が取り下げられた人からのクレームが入りますので、その人へ丁寧に説明をして理解を得る必要があります。
また、ユーザーに要求仕様書の説明をする中で、要求仕様書の不備に気がつく場合があります。
その場合は要求仕様書の改訂が発生します。
要求仕様書の改訂は何度も発生するので、予め改訂の時間は取っておきましょう。
システム開発の概算見積もり
ベンダーに、要求仕様書を基に、この後のシステム開発にかかる費用を見積もってもらいます。
要求の数、要求の難易度によって費用が変わってきます。
大方の場合は、要求が膨らんでしまって、当初計画した費用から外れてしまいます。
要求を減らすか、ベンダーに対して価格交渉するかになりますが、ベンダーは要求に対する工数算出の計算式を持っており、ほとんど価格交渉は無理だと思います。
結果的には要求を減らすことになります。
プロジェクト内で一度合意した要求を減らすことは、これはまた大変な作業となります。
要求仕様書を作成する段階で、要求が爆発しないように注意しましょう。
開発環境構築
要求定義とは全く関係無い作業に思えますが、ベンダーと契約したならば、システム開発を行うための環境を構築します。
主にはサーバーなどのハードウェアの準備になりますが、環境には開発、本番、テスト、教育、データ移行などのいくつかの開発環境が必要になります。
今はサーバーもクラウド環境があるので、比較的手配は楽ですが、社内にサーバーを購入する場合は、サーバー選定、見積もり、見積もりの比較、設置場所の選定などサーバーの知識に詳しい人で無ければ判断できない作業が多くあります。
社内のIT部門にお願いするか、ベンダーに依頼して作業を依頼することになります。
思ったよりも時間と費用がかかるので、ベンダーと契約したらすぐに開発環境構築に着手しましょう。
データ移行準備
新しいシステムに旧システムのデータを移行する場合などは、データ移行の準備が必要です。
実はデータ移行は非常に難易度が高い作業です。
なぜならば、古いフォーマットのデータを、新フォーマットのデータに変換する事や、既存のデータから、新しいシステム用のデータを作るなど、多数のバリエーションの変換作業が発生するからです。
データ変換用にほとんどは変換システムを作ることになります。
それらの仕様も決め、発注しなければなりません。
既存のシステムとそこに格納されているデータの仕様を理解し、なおかつ、移行先の新システムの仕様も理解しなければならない。
そのため、旧システムを良く熟しした人の協力も必要となります。
要求定義でシステムに対する要求を決めながら、新しいシステムにどのようなデータを移行するか決め、データ移行の準備に取り掛かりましょう。