経営に関する支援とまとめ | 情シスのお仕事（2019年度改訂版）

今回の「情シスのお仕事」は経営に関する支援と全体を通したまとめをお話します。
改めて「情シスのお仕事」で取り上げる弊社情シスの業務範囲を貼っておきます。

多くのユーザー企業にとってITやデジタルは本業ではなく、経営を効率化したり新たなビジネス展開へのトリガーとなって経営を「支援」するためのものです。
そういう意味では上記の１～１４は全て「経営に関する支援」と言うことができます。
今回のテーマをより正しく書くと「経営層からの指示への対応」です。
そう書くとあまりに直球すぎるし、やらされ感が強くなるのであえて柔らかい表現にしました。

また最後にこれまで取り上げたテーマを総括して、情シスのお仕事は結局何なのかをまとめたいと思います。

経営に関する支援について

経営層の指示を実現するためのプロジェクトビルド

業務改善やシステム導入について、トップダウンで指示が降りることも当然あります。
そういった場合情シスの立ち回りはプロジェクトマネージャーです。

経営層からの指示（＝経営層のやりたいこと）と、実態（＝実際にやらなければいけないこと）には差異があります。以下に指示と実態の差異を例示します。黒い文字が指示、灰色の文字が実態です。

経営層が実態のところまで事細かに指示することはあまりありません。

このプロジェクトが社内外の誰をステークホルダーとし、どこまでのスコープで、どういうメンバーでチームを構成すべきか。プロジェクトのビジネスベネフィットとリスクは何で、どのようなワーク＆スケジュールで完遂させるのか。
これらを押さえた素案を作成して「こういうイメージで合っていますか？」を確認するのがプロジェクトマネージャーの最初の仕事です。

※上記の単語については「プロジェクト管理手法について」という記事内にて紹介している「PM7key」を参照ください。

「その他諸々の保守と問合せ」の中でも何度も出てきた「要件の言語化」というのとも違う、「行間を読む」ほど感覚的なものではない、「要件を具体的に実行できる計画に落とし込む」ことがプロジェクト計画の第一歩です。

システム導入・業務プロセス変更の旗振り・調整役

システム導入の真の目的は、「システムを使うこと」でも「今の業務を楽にすること」でもありません。SaaS利用であれば、以下２つのメリットを享受するために業務プロセスをノンカスタマイズのシステム標準にあわせて変更することが目的です。

全てのシステムをパッケージ標準で使うことを推奨しているわけではありません。
他社との差別化を図るべきコア業務については手を加えることも必要でしょう。

しかし「売上の予実を管理する」「納品・在庫・出荷を管理する」等の業務を他社と差別化する必要があるでしょうか。むしろこれらの業務はシステムに合わせて標準化してしまい、売上を増やす施策に労力を振り向けるべきでしょう。

…ということを社内に説き続けることがプロジェクトマネージャーの仕事です。
トップダウンの場合経営層からも発信してもらえますが、現場の責任者がそれを目指さないとチームは目標を見失い誰も着いてこなくなります。

業務を実際に行うのは現場の担当者であり情シスではありません。
だからこそ現場の担当者が腹落ちするまでこの目的を説き続ける必要があるのです。

極端な話、そこを納得させることができればこのプロジェクトは７割くらい成功します。

あとの３割はベンダーコントロールです。
スケジュール、スコープ、品質を中心にチェックしていけば、よほどダメなベンダーでない限り、あるいはこちらの要件定義がよほどテキトーで無い限り、プロジェクトは簡単にはコケないと思います。

システムの導入はユーザーとベンダーの共同作業ですが、システムの利活用や効果の追究はユーザー側の責です。

「新しく導入したシステムが役に立たない」という声が現場から上がるのは本当にシステムが使えないからだけではありません。使い方を教えていない、そして使うことによって達成すべきゴールを伝えていないからでしょう。

そんなことを伝えなくても誰もが直感的に使えて業務が楽になり、経営層も自分たちがほしい情報を素早く正確に取得できる、そんなシステムがあれば言うことは無いかもしれません。
しかしそのシステムの目的は何でしょうか。何を達成させたいシステムなのでしょうか。
重要経営指標＝KPIを設定し、何がどうなることを目指したシステムなのかを明らかにすることは要件定義時から考える必要があります。

システムが稼働した途端にKPIが達成されるわけではありません。
業務プロセスの変更を言葉で言うのは簡単ですが、企業にとっては大手術です。
これまで繋がっていた血管を切り、別の血管に繋ぎ変えるようなものです。
変更する業務が経営の核心に近ければ近いほど血管は太く、血液の量は多くなります。
業務を動かしているのは人間ですから、やり方を変えた途端から上手く扱えるわけがありません。
システムを稼働させた当初は計画通りに血流が流れなかったり、場合によっては出血することもあるかもしれません。

出血を食い止めながら手当を施し、なんとか新しい業務プロセスが定着した頃にはじめてKPIは達成されます。もちろん切り替えの期間は短いほど良いわけで、そのためには周到な準備と前述のような担当者の腹落ちが欠かせません。担当者を腹落ちさせて新しい業務プロセスを定着させるのは、ベンダーではなくユーザーの責任なのです。

設定したKPIの値をどうやって計測するか、トレースしていく方法も同時に準備しておく必要があります。これらが行き当たりばったりではシステム導入の効果は正しく測定できません。
「システム導入により作業時間を〇〇時間削減」というKPIだとすれば、その〇〇時間をどのように計測するか考えなければいけません。導入前後の数字を比較する必要がありますし、そもそも時間の計測自体が大きな負荷になるような方法は取るべきではありません。

何より「削減した時間はどうなったのか」が一番重要なはずです。
残業時間が減ったのか、他の業務にリソースを振り向けることができたのか、その時間は何時間なのか。

効果の数値なんか作ろうと思えばどのようにでも作れてしまいます。
数値に踊らされないためには、結局「このシステムは何のために導入するのか」を固めるしかないのです。

ROI精査と予算作成

システムの効果を測定する一つの基準がROI、日本語では「費用対効果」が最も近い言葉でしょうか。
「システムを導入することで売上が〇〇円上がった」「人件費が〇〇円下がった」のような目に見えるお金の動きだけが費用対効果ではありません。

システムはそれ自体が事業計画の遂行のための一つのリソースであり、システム単独で効果を測れない場合もあります。例えば「SFAを導入したから売上が上がった」のではなく、SFAを軸とした営業手順・管理手順へシフトしたことによって、俗人的な手法や不明確な基準がなくなり効率的・効果的な営業活動を行った結果、受注率を向上させることができるのです。SFAは道具でしかなく、重要なのは「効率的・効果的な営業活動」なのです。
新たな手順に取組んで成果を出した営業の手柄を、全部システムのおかげみたいな言い方をしてはいけません。

企業の中期的な事業計画の達成に寄与できるようにシステムや手順をステップアップすることができれば、それは十分な効果と呼べるのではないでしょうか。

オンプレだけでなく、クラウドであってもより良いサービスは日々リリースされます。
クラウドの利点は常に最新の状態にアップデートされることではありますが、コンセプト自体が全く違う新しいサービスが生まれると、追いつくことがどうしてもできない場合もあります。

そういう意味ではシステムはリリースされたその日から陳腐化していくのです。
どんなに苦労して導入したシステムであってもその流れには逆らえません。

ITへの投資はあくまで企業の事業計画とリンクしていなくてはその効果や価値を認められないと言ってもいいでしょう。
事業計画の達成には既存の陳腐化したITリソースで事足りるのか、新たな投資が必要なのか。
それを考えて更新計画を立てることがIT予算の作成なのです。

IT予算作成については「経理のど素人が挑むIT予算作成」という記事で詳しく紹介しています。
事業計画に食い込んだIT予算にするために、情シスはもっと経営に入り込んでいかなければいけないし、そのためには既存システムのお守りをする時間を捨てていかなければいけないのです。

まとめ：結局「情シスのお仕事」のスコープはどこまでか

今回も含めて１１回やってきた「情シスのお仕事」を総括しようと思います。

これらはあくまで私が所属する情シスの事例なので全ての企業に適用されるものではありません。
しかし「ユーザー企業の情シスでベンダーを顎で使う方が楽そうでいいよな」と考えているSEがいるのであれば、これらを自分の責において取り仕切れるか考えてみてください。
コーディングする機会こそほとんどありませんが、情シスはこれらのスコープを、周囲にITやデジタルに精通した人間のほぼいない中でやり遂げていかなければならないのです。
上位者を説得し、現場を味方につけ、ビジネスとして価値あるアウトプットを出し続けなければ、ただのコストセンターとして外注化されて切り捨てられる立場なのです。

私自身これら全てを滞りなくこなせているわけではありません。
しかしやらなければならないタスクとして認識しています。
そこにやりがいを感じることができれば、情シスは楽しい仕事です。
来年も頑張っていきたいと思います！