.png)
最近のシステム構築プロジェクトでは、ユーザ企業の情報システム部門が自分達でソフトウェアを作成しないケースが多くなってきました。協力会社のメンバにソフトウェア作成を任せ、情報システム部門の人達はプロジェクトマネジメントや利用部門との調整役として振る舞います。また、単なる調整役にとどまらずビジネスプロセスの変革に役立つことが、情報システム部の役割の1つと認識されている会社もあります。このような場合、新規業務設計や業務要件定義の工程では、業務仕様の確定に積極的に関与することになります。
相応の期間とコストをかけて情報システムを再構築するわけですから、新しい業務は今よりも品質や効率の面で良くなっていなければなりません。ところが、新しい業務を考えたり、業務要件定義ができる人財が不足しているというのが多くの情報システム部門の悩みです。
この問題にどう対処すれば良いのでしょうか？
立ち上がったプロジェクトに経験の浅いメンバを入れたところで、戦力にはなりません。プロジェクトリスクが高まるだけです。プロジェクトメンバは予めいくつかのスキルを身に着けておく必要があります。
(1)業務知識があること
新しい業務を設計するわけですから、既存の業務知識や他社も含めた一般的な業務知識が必要になります。ここに紹介する(1)～(4)までのスキルのうち、もっとも重視されるスキルです。
(2)方法論を知っていること
システム開発というのは、何をどういった順番で作成していくものなのか理解しておく必要があります。現状分析工程なのに新しい業務イメージを話し始め、会議がいつまでたっても終わらない光景をたまに見かけますが、今の工程の成果物に集中することによって生産性と品質が向上します。
(3)業務モデルを扱えること
ここでいう業務モデルとは、業務の全体を把握できる業務フロー図や概念データモデル図のことです。利用部門の人達は自分がかかわる業務については詳しいですが、業務全体を良く知っているわけではありません。
また、それぞれのユーザは自分が担当する仕事の視点で実世界を認識しています。実はいくらか偏った理解の人達が集まってシステム開発に参加していると思った方が良いくらいです。
情報システム部門の役割は、個々の偏った見方にとらわれているユーザをその固定観念から解き放つことです。全体に整合性のとれた業務モデルを使って、各ユーザの業務を位置づけなおすことにより、新たな業務改善点を気づかせるのです。
(4)ユーザと良好な関係を維持できること
これは技術的なスキルではありませんが、システム開発プロジェクトでは対人調整能力が高いことが求められます。ユーザどうしの議論を調整することもあれば、業務要件が膨らみすぎた場合は、何かをやらないことにするか、後回しにするようユーザを説得しなければなりません。
(1)～(4)までのスキルを持っている人財を探してきてプロジェクトメンバとすることができれば、こんなに楽なことはありません。実際は、そういったスキルを持っている人がいないから困っているのです。地味ですが、次のような解決策をお勧めしております。
解決策1
- 大規模なシステム再構築は、ある日突然発生することはありません。計画を練っている期間がそれ相応にあり、2～3年後に着手するといったケースも多く見受けられます。
- その間、小規模な保守案件が発生することがありますが、この中で①～④のスキルを徐々に向上させていく方策です。大変地味ですが、あまりコストをかけずに普段の業務の中で実施できることがメリットです。
解決策2
- システム再構築プロジェクトの前段で業務分析工程を充分な期間とり、現状分析OJTを通じてプロジェクトメンバのスキルを向上させます。時間とコストはかかりますが、プロジェクトメンバが業務モデルを扱うことに慣れる時間と業務知識を蓄える時間がとれるので、プロジェクトリスクをかなり低くすることができます。
いずれにしても解決策として銀の弾丸はありませんので、教育カリキュラムや保守案件の中で、スキルを向上させる方策が一番良いと考えています。
