情シスはプロジェクトファシリテーターであれ！：情シスをもっと強くしよう（2）（3/4 ページ）

基幹システムの構築から運用保守まで多岐に渡る作業に日々追われる身でありながら、ユーザー部門からは叩かれ、経営層からも認められていない情報システム部門は多い。その原因には経営上の狙いやユーザー部門の業務課題を解決できていないシステムの存在がある。今回はこの問題の解決策を考える。

[植松 隆，＠IT]

プロジェクトファシリテーターの役割　その2

STEP3：抽出した意見を整理する

　経営層やユーザー部門のプロジェクトに対する意見を、ひと通り抽出した後は、「挙がった意見を実現するための手段は何か？」という視点での整理に入ります。

　ビジネス課題や業務課題を解決するには、プロセスの改善や組織体制の見直しなどIT以外の実現手段も必要となります。それを明確にすることをしないままプロジェクトを進めると、ITに対する期待値が増殖していき、出来上がったITに対して「何も解決できてない」と評価されてしまいます。

　このような事態を避けるために、課題解決のためにITはどう貢献できるのか、IT以外にどのような実現手段が必要となるかを明確にするのがこのステップです。いいかえれば、ITに対する期待値コントロールのステップとなります。

　A社の事例では「引き出し」の段階で、挙がった経営層が課題と捉えている事項について、原因（原因が不明確なものはその仮説）を分析し、「どのような解決手段があるのか」「解決につながる施策は何か」を明確にすることで抽出した意見の整理を実施しました。

　以下がその整理結果の一部です。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

STEP4：創造的な合意形成

　「予算・期間ともに無限大。やれることはすべてやってみて、1つでも結果がでればそれでよし」などというプロジェクトはありえません。挙がった施策に優先順位を付け、最も効果が出るポイントに絞ってプロジェクトを実行する必要があるわけですが、この優先順位付けというのが困難を極めることを、皆さんも日々実感していると思います。

　プロジェクトファシリテーターのスキルが最も求められるのがこのステップです。

「挙がった施策に優先順位を付けます。どれが重要ですか？」
「そんなの全部だよ、全部」

　合意形成のステップを混沌とさせるこのような事態を避けるためには、「評価軸」「評価基準」「評価後の取捨選択基準」を事前に決定しておく必要があります。