研修計画について

イントロダクション

RFI・RFPについての第９回、非機能要件詳細についての第６回目になります。
今回は前回に引き続き移行性についてお話していきます。

前回はデータ移行や運用切替について実例も交えて長々とお話してきました。
今回は研修計画についてです。

この１テーマだけで１回分できるか不安な気もしますが、いやいやこれがそうでもない。
「研修計画」という名前は入口で、実際にはその先まで考えなくてはいけないのです。

誰も使ったことのない新システムはいきなり稼働できない

これまで非機能要件について話してきた内容に共通するのですが、非機能要件とは「あたりまえにできていないとシステムとして使い物にならないこと」です。

可用性であれば、しょっちゅう止まったり、止まってから復旧までに時間がかかったり、そもそも復旧がかけられないようなシステムは使えません。
性能・拡張性であれば、処理速度が異常に遅かったり、利用者や処理の増減によって性能が大きく変わるようなシステムは安定した業務運営に支障をきたします。
そして今回の移行性ですが、システムが切り替わったとしても業務は前後で変わらず継続しているわけで、過去データであっても必要な情報にアクセスできなくなることで業務が継続できなくなる可能性があります。

そしてこれも根本的な話ですが、使い方がわからないシステムは運用できません。
システム導入の中で機能説明を受けることができるのはプロジェクトに参画するメンバーのみで、それ以外に利用者がいる場合にどうやって使い方を覚えるかが問題になります。
そこで必要になるのが「研修計画」です。

研修で覚えてもらいたいものは何か

研修計画でまず考えなければいけないのは、研修で覚えてもらいたいものは何かです。

一概には言えませんが、恐らく運用の比重が高くなると思います。
新システムになることによって今の業務のやり方がどう変わるのか。
それは入力エリアやボタンの位置ではなく、入力から決裁までの流れであったり、締め処理のタイミングであったりです。

そしてそれは利用者の立場によっても変わります。
入力者には入力者の、承認者には承認者の、管理者には管理者の運用が存在します。

誰に何を覚えてもらいたいかを正確に判断するには、現在の業務の流れと携わっている人、所謂登場人物をきちんと把握しておく必要があります。

研修方法の検討

研修といっても講義や操作研修だけが研修ではありません。
コンテンツ（Web、紙資料）による自席での学習も研修になります。

操作研修や講義形式の集合研修の場合、理解度は高いですが１回に研修を受講できる人数には限度があります。
講師も必要ですし、参加者の時間調整もいります。会場も確保しなければいけません。
操作研修であれば、研修用の機器や環境（パソコン、ネットワーク等）も必要です。
人数によっては膨大な時間と労力とお金が必要になります。

コンテンツでの学習は本人の自主性に任せることになるため理解に個人差が出ます。
ただし集合研修のような様々な調整が必要無いので、比較的簡単に行うことができます。

研修の実施やテキストの準備をベンダーに依頼するか自前で行うかによっても、労力と費用は変わってきます。

対象者、期間、浸透させなければいけない度合、費用等様々な要素を鑑みて、適切な方法を選択しなければいけません。

しかもこれをRFPの時点である程度の数字として提示しておく必要があります。
研修の有無や方法、回数等は提示される提案と見積に影響してくるからです。
研修はタダではありませんし、要件も決まっていない研修を見積もることもできません。

ベンダーから研修について提案を受けることになるかもしれませんが、提案内容の可否を判断するためには、必要としする内容を検討しておかなければいけません。

定着化への道筋、仮稼働の位置付け

研修で現在まだ使用していないシステムを覚えるさせるのは容易ではありません。
集合研修を選択したとしても、１回の研修で全てを覚えてもらうことは困難です。
研修実施後も含めて定着化のためのフォローも考えなければいけません。

どのようなフォローを行うのか、そのフォローのためにベンダーに依頼すべき内容が無いかを検討し、必要に応じてRFPに記載します。

システム移行において「仮稼働」もしくは「並行稼働」と呼ばれるフェーズが設定される場合があります。今回は「仮稼働」で統一します。
本運用を想定して同じ操作を一定期間行うフェーズで、前回お話した運用切替も含む場合があります。

仮稼働には様々な意味合いを持たせることができます。
現行システムと同じ内容を投入して結果が同じになるか確認する運用テストとしての側面や、操作習熟のため利用者に実際にシステムを操作してもらうこともできます。

ただ仮稼働も目的とスケジュールをきちんと定義しておかないと何の効果もありません。
「とりあえず試験的に開放するので、使ってみてください」では、投入されるデータが現行システムと同じ内容になるか担保できなくなるし、本当に使われるかもわかりません。
かといって現行システムと同じ内容になることを担保するために、操作者を絞って淡々とデータ投入だけを行っていけば操作習熟の効果は限定的になります。

期間や対象者を区切ったり、操作してもらう内容を限定したり、進捗を管理することではじめて仮稼働は効果が出ます。
行き当たりばったりでやってしまっては運用開始までに必要なノウハウが行きわたらず、運用を混乱させることになります。
そして仮稼働に期待することをベンダーに正しく伝えておかないと、描いていた計画が反映されずにプロジェクトがスタートしてしまうことになります。

操作マニュアル、運用マニュアル

操作マニュアルや運用マニュアルは重要なプロジェクト成果物であり、運用理解・操作習熟という意味では研修ともリンクしてくる部分が多いです。
研修でカバーしきれない部分はマニュアルを参照するしかない場合があります。

マニュアルはどちらかといえば機能要件に分類されるドキュメントかもしれません。
マニュアルは「実現しなければいけない要件が全て盛り込まれていることを確認するための成果物」として設計書と同等の意味があると言えます。
運用マニュアルを基本設計の、操作マニュアルを概要設計の成果物とする場合もあります。
ただしマニュアルは必ずしもベンダーが作るものでもありません。
特に運用マニュアルは「誰が、いつ、何をするか」を記載しようとすると、ユーザー側でしか知りえない内容を含む場合があります。
またベンダーに作成を依頼すれば、当然その分費用が発生します。

パッケージ導入の場合、パッケージ標準のマニュアルに変更点を書き添えたものになることが多く、わかりにくい場合があります。
かといってそれらをフルスクラッチで作成するとパッケージ導入によるメリットを減退させることにもなります。

マニュアルについて成果物として作成することを求めるのか、自前で作成するのかも併せて考えるようにしましょう。

ベンダー側で経験した研修の話

ベンダー側のSEとしてユーザーの研修計画を立てたり実際に集合研修の研修講師をやったこともありますが、受講者が100%満足を得られる研修にすることは非常に難しいです。

技術研修やビジネススキル研修と違い、システム導入研修は受講者の受講動機が受動的（受けないといけないから受ける）な場合がほとんどです。
受講者にやる気がないくらいはまだいい方で、システムの操作性や運用変更にケチつけられたり、「我々の業務を全く理解していない！」と怒号が飛んだこともありました。
もちろん全員がそうというわけでは無く、積極的にシステムの運用を覚えようと質問をしてくる方もいらっしゃいます。

ここにシステム導入の難しさが集約されていると言えるかもしれません。
最も理想的な導入はステークホルダー全員が、全ての内容を合意した状態です。
しかしプロジェクトに参加するのは主にキーマンだけで、全てのユーザーが同じ方向を向いているとは限りません。

ベンダー側としては、当初取り交わした計画に沿ってキーマンとフェーズ単位で合意を形成してきており、怒号一つで合意をひっくり返されることは基本的には無いので、気持ちがいいものではありませんが「システム導入とはこういうもの」とたかをくくってしまうこともできます。
しかしユーザー側はそうはいきません。
システムの安定運用には、エンドユーザーの協力が必要です。
どこかの課長さんが１人へそ曲げたくらい、と放っておくと、その所属からの協力が得られず処理が滞る場合もあります。
そこはベンダーではどうすることもできません。

日頃の付き合い方でうまく話が通せるようにしておくとか、上位上司や周囲に説得してもらうようお願いするとか、事前にネゴっておくとかいう非常に日本的な対応も必要になってきます。

移行性についてのまとめ

ソフトランディングへの道筋を逆算する

システムを切り替えることは、多かれ少なかれ業務のやり方を変えるということです。
どれだけ便利になるとしても、変化に対する抵抗感は少なからず発生します。

それを織り込んだ上で、少しでもスムーズな移行を行えるよう計画することが必要です。
そのためには切替後の姿を想定して、そこから逆算しながら取るべき対策を考える必要があります。

SE時代に聞いたことがあるのですが、あるユーザーでは基本設計を運用マニュアルの作成のみに充てて、そのマニュアルさえあれば稼働後の運用がはじめられるくらいの記述レベルに仕上げたそうです。
稼働後の運用の姿を完全に確定させることで、そのために必要な機能と準備すべき事項を洗い出すことができ、非常にスムーズな移行が実現できたそうです。

このやり方が必ずしも正とは限りませんが、道筋を逆算するという考え方には通じるところがあると思います。

RFPに書くときには、研修形式（集合研修、コンテンツ配布）や内容、テキスト、想定対象者の枠割と人数等を概算ででも記載しておきましょう。
その際に「研修が必要だからとりあえず」というのではなく、上記のような考えを持って準備しておくことが必要になるでしょう。

RFI・RFP／プロジェクト管理関連の記事を纏めています。