情シスが現場から「何もわかっていない」「使えない」と言われた時の「今すぐできる対処法」「やっておいた方が良い根回し・対策」

システム導入などの経験が評価されITコンサルから情シスに転職も、なかなか現場・経営との関係性が築けず悩まれる方が一定数います。特に、こちら側は尽力しているものの、現場からは「何もわかっていない」時には「使えない」といったきつい批判を受ける方も多いようです。

そこで、今回は、システム系のプロジェクトを進めるにあたって、「何もわかっていない」と言われがちな情シスの「今すぐできる対処法」「やっておいた方が良い根回し・対策」についてご紹介します。

題材として、業務現場に導入されている既存のシステムの老朽化対応を機に改めて業務現場のニーズを拾い上げた上で刷新、再構築するといったプロジェクトを想定してみます。

プロジェクトに取り掛かる際に今すぐできること、効果的に今すぐ使える対処内容や、プロジェクトを成功裡に導くためにやっておくべき対策、ネゴシエーションなども実際的な打ち手として含めて紹介します。

業務現場と協業で進めるシステム再構築に関するプロジェクトマネジメントにおいて、基本的な内容も多いですが、ご参考になれば幸いです。

【目次】

1. 情シス部やシステムそのもの信頼信用はあまりないのが常
2. 既存のシステムに対しての「物言い」は鬱積しているのが常
3. 現場導入されている既存システムの理解と業務検証をしっかりやっておく
4. 業務現場を巻き込むための「エサ」「アメ」を投げ込む
5. 既存システムで埋もれている機能を洗い出しておく
6. しかしながら経営層とのコミットメントは必須
7. 来るべき業務現場のラスボス攻略に備える

情シス部やシステムそのもの信頼信用はあまりないのが常

システム系全般に言えることかもしれませんが、良い評価というよりもダメ出しやイケてないといったような ネガティブな論調の方が目立つと感じている情シスの方は少なくない印象です。

何かにつけ些細な不具合を持ってシステム全体やそのアプリを全否定されたりしてしまうのが常でしょうか。
例えすぐにその不具合を改修して、相当なスピード感をもってサービスを再開しても「有料アプリだろ、こっちは金払ってんだ、当たり前じゃん」くらいならまだしも「そういうの多いんだよ、しっかりやれよ」と叱責を受けてしまう状況です。
不具合対応もスピード感持ってユーザーの声に対応していると、たまには褒めていただけることもある様ですが、マジョリティはスルーもしくはお叱りがほとんどです。

ヘタをすると機能としては実装していて、特に不具合もなく大半のユーザーは気持ちよく使ってそうなのに、あるユーザーが使い方わからない 、マニュアルやヘルプをよく読んでいない為に使えていないのに、くそアプリだと、相当な怒りを込めてダメ出しの酷評を長文でアプリ評価に書き込んであるのもよく見かけます。

アプリ自体の評価点数は星4.5と高評価にもかかわらず、評価コメント欄はダメだし、イケてないのオンパレードということもあります。アプリ評価をさらっと見たときに、あまりにも多数の星が低い評価とネガティブコメントが多くて、使えないのかな、と初見で感じたものの、よくよく見ると一つ一つのネガコメントに開発者側が丁寧にきっちり答えていたりしていて、それが逆にたくさんあって低い評価が目立ってしまっているという逆説的なイメージを与えてしまっていることもたまに見られます。

しかも、開発者がすべて真摯に答えて地道に潰していっているところに、「この前から伝えている、あの件の対応はまだか？いつか？」と被せている様なコメントも散見されます。

ちょっと論点がずれたように思われるかもしれませんが、「何もわかっていない」と言われがちな情シスの背景に、まずシステム評価に関して一般のユーザーレベルの認識はこのようであるということを、今一度思い返しておく必要があります。

既存のシステムに対しての「物言い」は鬱積しているのが常

社内や取引先のシステムユーザーは日々、業務のなかでそのシステムを使っているわけですが、その中で細かいところではあったとしても、不具合や操作性に不満を抱いているということをまず念頭に置いておかなくてはなりません。あらためて言葉にする必要もないかもしれませんが、不平不満がゼロのシステムは存在しないということです。

「なぜ、ここの部分にデータ連携がないんだろう」「二重インプットを強いられるんだろう」「どうしてこの不必要な表示のためにもたついた画面更新をするんだろう」「わざわざ深くまでこの一連の画面遷移をしないとこの入力ができないんだろう」「この画面いつまで経っても返ってこないこともあるし、いつもどうしてこんなにレスが遅いんだ」といった明確な信用を損なう不満もゴロゴロ転がっていることに気がつくはずです。

「このシステムの帳票ってあんまり使わないもの多いよね」や「なんかデザインが古臭いよね」といった些細なところから「システムのサービス提供時間が現場と合ってないよね」といった非機能要件寄りの部分もあったりします。

これらも信用を失うまでには至らないものであっても、あまり信頼されていない、といった要因になっていることは認識しておきましょう。これも情シスが「何もわかっていない」と言われがちな、あるある要因の一部です。

現場導入されている既存システムの理解と業務検証をしっかりやっておく

何事にも大切な基本のキ、ではありますが、 ここまで常々基本をちゃんとやれと言われるのも忘れられがちだから、ということに尽きます。あながち経験値がある、ちょっとこなれたPMやPLこそ、この基本のキの大変重要なプロセスでありながら、既存システムの分析や業務検証というプロセスをすっ飛ばすことがよくあります。慣れは油断大敵です。

要件整理という視点ではなく、今後のプロジェクト推進にあたっての現場へのネゴシエーションという意味でもこのプロセスは非常に重要です。一旦既存のシステムをリセットし新しいものをゼロから構築するとはいえ、そのシステムの現場提供を実際にできるようになるのはかなり先のことです。

刷新したシステム導入プロジェクトが開始されるということがアナウンスされた当初は現場にも歓迎されることでしょう。しかしながら実現されるのが、かなり先となってしまえば落胆も反動で大きいです。日々日々モチベーションが落ちていくことも想定もされます。

またシステム刷新導入のプロジェクトが実は前回も行われていて頓挫していた場合のリカバリのケースであれば、業務現場の協力を再度取り付ける必要があります。自身にとっては新しく着任したプロジェクトであっても、現場にとっては、あーまたか、というネガティブスタートに変わりはありません。

そこで有効なのが既存システムの業務検証の中で、すぐにも改善できることを見つけ即実行に移すことです。システム刷新での再構築と言った大きなプロジェクトのミッションの前に実は細かいですが即効的な打ち手がなされずに放置されている場合が多いです。

システムのエンドユーザーの不満は、情シス部門サイドから見るとほんの些細な所にあるということを申し上げましたが、裏返すとちょっとした改善でユーザーの満足度が上がると言うことです。

既存のシステムに関連する改修要件ではあるものの、即効性のある改善ポイントを既存システムの業務検証の中からピックアップしておくことが大変有効です。当然ながら新しく構築するシステムの要件にもつながってきます。

業務現場を巻き込むための「エサ」「アメ」を投げ込む

既存システム刷新のプロジェクトということですので、大きく既存の廃棄予定のシステムに追加改修や新規カスタマイズをするということはありえませんが 、例えば他システムとの外部連携でデータがうまく渡っていない場合などであれば、既存のインターフェイスを次のシステム構築時にも流用できる前提で項目を追加する、ということを想定に入れておけば先行して進めたとしても投資回収できなくもない、無駄にならない項目もあるでしょう。

既存のシステム改善と時期のシステム再構築をうまくマネジメントすることで、早々に現場メリットを提供し、業務現場のメンバーをプロジェクトに対し前向きになってもらう「エサ」「アメ」を投げ込むという打ち手です。

先ほど触れたシステムサービスの提供時間が問題であるのも、場合によっては解決しやすい即効性の高い課題であることもあり得ます。老朽化対応しないといけないシステムの場合、構築した時点で定められたシステム提供時間の時の制約条件とは違い、バッチのスケジュールなどが当初ほどタイトではない場合もあったりします。

保守運用チームでは気付いてはいたものの、今まで特段確認されていなかった、放置状態であっただけ、テーブルに上がらなかっただけというのも、あるあるの話です。

そもそも現場からの要請というところで行けば、1時間もしくは30分早く遅くサービス開始または延長、というレベルで解決できることもあるでしょうし、そのレベルであればシステムスケジュールの調整を運用保守内で解決することで可能な場合も多いです。

このような情シス側にとっては少し手をかければ改善できる既存システムの課題解決を丁寧に新しく着任したPM、PLが、言葉は悪いですが宣伝効果を狙った上で、わざわざ進めましたよ、と現場を巻き込む為に効果的に行うことは有効ですし、もっと悪だくみをするとすれば、小出しに活用することで新規プロジェクトのモチベーションコントロールを行うことも可能です。

既存システムで埋もれている機能を洗い出しておく

せっかく機能が実装されているにも関わらず、使い方がわからなかったり運用が追いついていなかったりという要因で、設計時点にわざわざシステムの”売り”の機能として仕込まれていたものが、宝の持ち腐れとなってしまっていることが散見されます。

結構ありがちなケースではありますが、なぜそのアドバンス的な機能が使われていない、使えないのか業務検証しておくことが大切です。次の新システム要件にも重要、ということは言わずもがな、ですが実は既存のシステムへの連携データが不足していたり、構築時にはなかったシステムとの外結予定を前提に機能構築していたが、そのシステム自体の構築が延伸してしまっていたりで、置き去りにされているケースもあります。

これも既存システムへの非連携を次期システムの要件の一部を先行して対処し、埋もれていた機能を使えるようにした上で、業務現場で上手く活用可能かという検証を進めるという名目の下、新機能をリリースし業務負担軽減を行うという現場アピールで一挙両得を狙います。検証を兼ねた業務現場への点数稼ぎで、情シスが動いてくれるとこんなにも違うんだな、というイメージの植え付けです。現場の協力体制を作り上げる効果的な打ち手です。

三方よし、を狙いにいきましょう。上手くいけば、要件整理も進み、思ったほどの新規構築部分は少なくても現場の生産性改善に貢献できることも可能かも知れません。であれば、少しの機能改善をベースに、工期も抑え、すなわちシステム総投資も抑えた形で、要件定義も短縮した形のストレート移行で老朽化対応を完遂できるかも知れません。

しかしながら経営層とのコミットメントは必須

陥りがちなパターンとして、現場にPLやPMまで取り込まれてしまう場合です。もともとは経営課題や事業課題の解決のためにシステムを刷新するはずが、いつの間にか現場に寄り添うことが美徳のように、本来の目的を忘れたプロジェクトの進行となってしまう場合です。

パッケージ導入は、そういう意味では潜在的なリスクが大きいシステム導入案件です。PMやPLは経営ニーズと、現場のからの玉石混交なシステム改善要望を上手く整理しシステムソリューションとして具現化せねばなりません。
しかしながら要件整理を進めていくうちに、パッケージの基本機能から大きく外れ、アドオンやカスタマイズの応酬で元のパッケージの形がわからなくなるくらい盛られてしまうことも無きにしも非ずです。

経営陣や情シス管掌の担当役員はパッケージ導入で安価に済ませたい、アドオンやカスタマイズなんてホントは基本ゼロにしたい、と思っています。願わくば業務をパッケージに合わせる推進でBPRも一気にこの機に進めてしまいたいと考えています。

そんなところに現場業務にベッタリの要件整理をした進捗報告をベースに、パッケージの基本ベースの倍以上のアドオンが乗った概算見積もりを出せば大炎上は必至です。パッケージが前提とする業務とのFit&Gapをやったとしても、パッケージに合わせた現場業務を変え切ってしまう前提で臨まないと、必ずと言っていいほどプロジェクトは頓挫します。

特に人事や経理財務のようなバックオフィス部門は、対応するパッケージも事業現場向けのものよりも比較的多く存在し、その導入対象となりやすいですが、プロジェクトの失敗事例も数多く転がっています。そういう意味では特に人事パッケージは鬼門です。数知れぬ失敗談を噂に聞くことも情シス関係者では多いと思いますが、財務経理パッケージの失敗よりは、かなり深刻な人事パッケージ導入の悲話を耳にすることが多い様な気がします。

プロジェクトを成功裡に進めるためには、まず経営層とのコミットメントが大切です。一円も余計に投資したくないというのは現実無理であることをしっかり伝え、ある程度のアドオンが必要であることを説得する必要があります。

一方で情シスの立場としても、アドオンが多すぎると折角のパッケージのアドバンテージを失うことを忘れてもいけません。パッケージはパッケージゆえにある意味勝手に進化していく、バージョンアップしていく、というところを有利に取り込むことがキーポイントです。

これを阻害してしまうようなアドオンやカスタマイズは避けなければなりません。どうしても必要な場合もあるかと思いますが、そのような箇所を最小限に留めることを誓いつつ、一定範囲のアドオンやカスタマイズの裁量を経営陣から事前に取り付けておくネゴシエーションが必要です。

来るべき業務現場のラスボス攻略に備える

人事パッケージ導入のサーガ、業務現場に巣食うラスボスとの苦闘の物語はもう人ごとではありません。入念なその領域の予習を行ったとしても、専門書を紐解いて法令を予習して臨んでもダメな場合も多々あります。例えば部署で定められ運用している会社ルールが世の中のルールと違っていたりするのも日常茶飯事です。

そのことを下手すると現場のみならず、人事課長すら知らないまま、法令と運用ルールのギャップが常態化していたりします。唯一の黄金律として絶対的に君臨している部署ルールの存在に出くわすことでしょう。

法令とのギャップのあるあるは、部署ルールをそのまま運用すると、もしも違反してしまった場合にシャレにならないことになるので独自の会社規定などでバッファを持たせたルールを作っておき、そのラインで運用するというものです。

分かりやすい例では三六協定の運用でしょうか。月60時間の残業上限は協定違反になってしまう為に、手前の40時間を月間の上限として社内規定として定めるといったものです。システム的には完全にパッケージに対するカスタマイズとなります。これはある意味致し方ないアドオンかも知れませんし、経営に説得できるアドオンの範囲かも知れません。

しかしながら、そう明快に整理できるものだけではないことは想像に難くないでしょう。

就業管理のルールもそうですし、給与計算の独自ルールも闇が深いです。多種多様な手当の計算方法など計り知れない運用ルールが潜んでいます。ここを司る、ラスボスと対峙せねばなりません。

ラスボスは自分がやり易い環境をしたたかにじっくりと時間をかけて築いて来ました。その洞窟の最奥に片道切符で乗り込んでいく情シスチーム、名前だけのPMになり代わり、PLの自分がプロジェクトメンバーを率いて決戦に臨む、、という構図です。

ワタシがルール、オレがルールのラスボスと戦う、決戦を挑むのであれば、その為の修行や経験値蓄積がマストですが、基本アウェイの情シスPL如きでは惨敗に終わる、相手側ホーム現場フィールドであり、相当のソリューション提案力が必要です。ここは懐柔策や出来れば懐に飛び込むくらいの芸当もやってのけなければ、プロジェクトは成就しません。

=================

＞情シスのキャリアに関する記事

【実話】SIerのSE・PMから情シスやDX推進部への「転職後のよくある落とし穴」と「対策」
https://www.axc.ne.jp/media/careertips/sepmcareerchangetips

“SE・PM”から”事業会社”転職後【年収1000万×部長職級】にたどり着くための具体的なスキル・経験とは
https://www.axc.ne.jp/media/careertips/sepmannualsalary1000

=================

いかがでしたでしょうか。PMやPLとして基本のキを徹底し、業務現場の声に耳を傾けつつも、経営ミッションを冷静に完遂していく、という高度なバランスが要求されるプロジェクトマネジメントが出来る様、日々精進するしかない、という文字で書いてしまうと凡庸な帰結です。しかしながら、実践は相当難しいですよね。

今回は、システム系のプロジェクトを進めるにあたって、「何もわかっていない」と言われがちな情シスの「今すぐできる対処法」「やっておいた方が良い根回し・対策」についてご紹介しました。

キャリアでお悩みの方は、ぜひアクシスコンサルティングにご相談ください。