ユーザー部門のシステム導入プロジェクトについて | ひとり情シス事情

イントロダクション

ユーザー部門のSEにとって、日々の定型業務や問い合わせだけでも結構な分量があります。
それは単純に「量が多い」ということではなく、「定型業務や問い合わせの分量に応じて要員数が最適化されているから」だからです。もちろんそれが「最適」なのかどうか客観的な指標はなく、「業務が回っていれば適正、回っていなければ適正ではない」という判断の元、必死こいてなんとか回っているレベルであっても「最適」となることもありえます。
そこまでひどくなくても、ギリギリのバランスで「最適化」されているので、イレギュラーなことが起こると途端にバランスは崩れます。

スポット的なイレギュラーはある程度リカバリが効きますが、それが継続するとリカバリできずに業務が滞り始めます。その最たるものが「新システムの導入プロジェクト」です。
元SIer出身なので、導入プロジェクトには慣れているつもりでしたが、ユーザー部門で経験するプロジェクトは正直相当しんどいです。
ということで、今回は「ユーザー部門のシステム導入プロジェクト」についてお話したいと思います。

ユーザー部門のシステム導入プロジェクトについて

私が直近１年でやってきた導入案件

システム導入と一口に言っても、規模間は様々です。
過去の記事にもありますが、私がここ１年くらいで実際にやったものは以下の通りです。

その他細々したものもありますが、こうして見るとなんやかや色々やってますね。
パソコンと社内LANについては更新サイクルを含めた更新計画も作成しました。

ただこの辺は「そんなに大きくない案件」です。
携帯やメール、ネットワークは利用者の範囲や使用頻度、重要度は高いですが、基本は「更新」で、操作性や運用についてある程度利用者が認識しているので、展開に凄まじく労力がかかったわけではありません。
導入サービスの選定・決定の稟議さえ通ってしまえば、利用部門の意見を逐一汲みとるようなことはありませんし、当初に計画したとおりに粛々と進めていくことができます。

割と大変だったのは新拠点の立ち上げですが、これも他拠点という前例がある中で、必要なものを洗い出せれば後はスケジュールを決めていけばよかったので大きな混乱はありませんでした。

大きな案件は５～１０年に１回ペース

どの程度が「大きな案件」というかというと、概ね以下のような定義ではないかと思います。

代表的な「大きな案件」としては、ERPのような基幹系システムや、CRMやSFA等の営業支援系のシステム等、企業の事業運営そのものに直結するようなシステムでしょう。
投資額が数千万～数億円単位で、導入・開発等にSIベンダーが参画し、社内でも導入のためのプロジェクトチームが発足するレベルのものです。

特に基幹系システムは超大型案件になり、「１０年に１度」「情シスをやっていて、一生に２回あったら多い方」というくらいの激レア案件です。

ユーザー側はITプロジェクトの舵取りが不慣れ

ユーザー部門でのシステム導入プロジェクトの一番の難点は、「基本みんな素人」であることです。

SIer側は、毎回のプロジェクトは様々な要素が変わるとはいえ、基本的なWBSや成果物、プロジェクトとしてのゴールはほぼ同じであるため、メンバー個々に至るまで次に何が起こるか、何を決めないといけないかをある程度把握しています。

ユーザー側はそうはいきません。
ソフト１つ選ぶのにも、何を基準に選ぶのか＝導入の目的は何かを明確にし、ステークホルダー内で意思を統一するという作業だけでも、メンバー個々で考えていることが統一されておらず、纏め上げるのに多大な労力を要します。
「導入なんてベンダーに任せておけばいい」というような姿勢の人もいれば、「これだけはできていないと困る」という人もいますし、「将来的にここまでできるようなソフトを選定しておかないと」まで思いを持っている人もいます。

SIerはユーザー側のフロントに立つメンバーとだけコミュニケーションを行うので、そういった内部的な調整にはあまり関与しません。コンサル的な入り方で（あるいは本当のコンサルとして）要件の取りまとめを行う場合はありますが、その場合も最終的な意思決定はユーザー側で行わなければいけません。
SIerやコンサルの言いなりになるのを良しとしない人もいますし、「もっと多角的な分析が必要なのでは」と問題を一般化してターゲットをうやむやにしだす人もいます。

プロジェクトの肝は、メンバーが同じゴールに向かって意思を統一することにあります。
そしてプロジェクトには必ず期限があります。
「何時までに決めなければいけない」から逆算して結論を導き出せるようコントロールしなくては、まず結論は出ません。

当事者意識が希薄

「ITは会社（あるいは情シス）が決めたものを使うもの」という意識があると、自身の業務に影響することであったとしても当事者意識が薄く、「自分が意思を持って決定しなければいけない」という思いが欠如しがちです。

みんな「わからないことに口を挟んでも責任が取れない」とばかりに自分で決定しようとはしません。この状態だとどれだけコンサルに入ってもらったとしても、堂々巡りになって結論は出ません。

上位の経営層は「現場の業務は担当者に聞かないとわからない」となり、現場の担当者は「経営的な優先度は担当者ではわからない」となります。
そんなことはわかっています。だから責任を持ってその双方を調整して前に進めるために設置されるのがプロジェクトなのです。

というプロジェクトの位置づけ自体がまずよくわからないまま、保守期限目前のシステムの更新に向けてとりあえず発足される、という状況もままあります。
それは何故か。「１０年に１度」だから、誰もやりかたを理解していないからです。

SIer上がりの情シスの役割

では情シスはどのような立ち回りをすればよいのでしょうか。
基幹システムにしても業務システムにしても、プロジェクトの主体はその業務を行っている人たちであり、情シスは基本的にテクニカルアドバイザです。
技術的な見地でソフトの選定や環境構築、非機能要件的な要素に助言を行うことが主たる役割です。

ただし、上記のような状況を踏まえると、「テクニカル」の範囲は「IT技術」だけではなく「プロジェクトマネジメント手法」まで拡大しなければいけない場合があります。

誰かにそれをやるように言われたわけではなく、見ていてイライラしだすから手を出さざるを得なくなる、というのが正しいかもしれませんが。

PMPの取得までしていなくても、PMBOKの知識エリアくらいは知っていて、要件整理やプロジェクト管理をある程度経験していれば、ユーザー部門においては一端の専門家です。
業務については逆に素人同然ではありますが、現行業務の整理・ヒアリングに同席し続ければ嫌でもある程度は理解しはじめます。
むしろ同じ会社でやっていることなのですから、理解しなくてはいけません。これから自分がそのシステムのお守りをしなければいけないのですから、是が非でも理解することが必要になります。

ここで業務部門や経営層に説得力を持ってプロジェクト推進を訴えられるかは、日頃の業務でどれだけ信頼を得ているかにかかってきます。結局それ無しには一情シスの担当者の意見には重みは出てこないのです。

それでも情シスはプロマネではない

できるのはお膳立てまで

このようにプロジェクトを成立させるためにプロ管としての経験と知識を総動員したとしても、情シスは基本的にはプロマネではありません。
あくまで「テクニカルアドバイザ」であり、プロマネを技術的にサポートすることが役割です。

各ステークホルダーにネゴったり、意見集約の方向性を整理したりしたとしても、最後に号令をかけるのはプロマネの仕事です。そこを取り違えると出しゃばり野郎になりかねません。

情シスは基本的には黒子です。
でも黒子無しには舞台は回りません。

しかし「黒子としてこれだけ立ち回った」ことは、自身の上位上司だけには必ずアピールしていかなければいけません。
評価される機会は逃さず活かしていきましょう。

ということで、大半はここ最近の私の愚痴になってしましました。
大型プロジェクトの立ち上げは大変ですが、やりがいはあります。
ただし日常業務に大いに支障をきたします…。