今回の記事では、事業会社の情報システム部署で仕事を進めていくにあたり頭に入れておくと良いことや気をつけたいポイントを、私の超個人的な主観で紹介していきます。
情シス心の手引きってなに？
私が情シスのお仕事をするうえで、大事にしているポイントや意識して気を付けているポイントをまとめたものです。
因みに、適当に思い付いた言葉であり、ネーミングに深い意味はありません・・・。
情シス心の手引き一覧
当項では、当記事の主題である「情シス心の手引き」を紹介していきます。
尚、今回紹介する内容は、ITの技術的な内容はあまり含まれておりません。
事業会社の情報システム部署に勤めるにあたって、ITの技術はもちろん大切ですが、それ以上に「人との接し方」や「仕事の向き合い方や進め方」といった部分も非常に重要です。
あくまで超個人的な内容になりますが、今回紹介する内容が何方かのお仕事のヒントになれば幸いです。
社内提案には必ず魅力的な費用対効果を添えよう
情シスとして働いていると、社内のITをこう変えたいとか、こうするともっと良くなると考えて、社内の経営陣に提案をすることも多々あります。
そんな時に、以下のように感じることはないでしょうか？
- 上の人たちはITをなかなか理解してくれない。
- 経営陣はお金にシビアで予算をくれない。
それは、貴方の提案内容から費用的なメリットや効果を感じていないからではないでしょうか？
社内にはこのようなイケていない問題があり、それをこれこれこうすると良くなります。
費用はこれだけ掛かりますがきっと良くなるので導入したいです。
提案相手が同じくITに精通しており、貴方が提案した内容からメリットを汲み取ってくれるなら良いのですが、決裁権を持つ多くの偉い人たちはITを知りません。
ITを知らない人にITに関する提案をストレートにぶつけたところで、大きな費用が掛かる提案内容であるほど、許可はもらえないでしょう。
そこで提案内容に必ず加えておいてほしいのが、「魅力のある費用対効果」です。
社内にはこのようなイケていない問題があり、それによる機会損失はざっと試算して毎年〇〇万円です。
この製品を導入すると、最初に〇〇万円必要になりますが、1年半後にはその費用分が回収できて以降は毎年〇〇万円の経費削減ができます。
導入しないともったいないので導入しましょう！
あ、因みにこの製品は〇〇を便利にするためのものです。
お金の掛かる提案を聞いている間、相手は「この費用は〇〇を何個売ったら捻出できるのだろうか？」といったことや、「この費用は会計上のどの科目に組み込めば節税になるのだろうか？」といった感じで、まったく別のことを考えています。
提案内容で従業員がどれだけ楽になるかや、先進的な取り組みなのかはまったく興味を持たないと言っても過言ではありません。
経営者目線で言えば、費用が掛かるものは「投資」です。
「投資」では投下した費用に対してどれぐらいの「リターン」を見込めるのかがポイントになります。
投下した費用に対して大きなリターンが見込めるなら、提案内容の中身の良し悪しに関係なく「やろう」となります。
逆に、リターンが期待できない費用はただの支出や経費であり、なるべく抑えたいし、できることなら払いたくありません。
要は「費用対効果」が十分にあり、その根拠に納得ができれば良いのです。
そのため、情シスであれば、必ず「社員一人当たりの人件費」の目安は知っておく必要があります。
どこの企業でも、社会保険などの給与以外のコストも加味して、社員全体で均した人経費の目安があるはずです。
もし知らないなら人事部や経理部などに確認しておきましょう。
出来れば会社内の上層部で共有されてており、社内の経営における売上などを算出する際に使われる人件費が望ましいです。
ITに関する提案において、業務効率化によって得られる人件費削減効果は、最もわかりやすい費用対効果です。
ここぞというときには感情を込めて話をしよう
ITの仕事では、常に冷静でいることはとても重要です。
運用しているシステムで障害が発生したときや、予期せぬトラブルに見舞われたときに、ユーザーと一緒になって焦ったり動揺するのではなく、冷静に状況を分析して、適切な対応をしながら事を収束させていく必要があります。
もし冷静さを欠いてしまうと、状況を見誤り原因解決まで時間が掛かってしまったり、対応に失敗して被害を拡大させてしまうおそれがあります。
IT職の一つでもある情シスや社内SEでも、感情をコントロールして冷静を保つことはとても重要です。
仕事の相手が機械やコンピューターであれば、上記のように、常に冷静でいることが大事ですが、かたや人間相手の仕事に関してはそうとは限りません。
前項でも紹介した社内向けのシステム提案でもそうですが、如何に貴方が素晴らしい提案資料を用意して経営者に提案をしても、冷静に淡々と提案内容を説明するだけでは、その想いは相手に伝わりません。
人はコンピューターではないため、物事を考えるときには無意識にその時の感情にも影響を受けています。
また、人の感情や想いは相手に伝達します。
提案資料を説明しながら、貴方が本当にこの製品は素晴らしく、絶対に導入したいんだと熱く話をすることで、相手にもその感情や想いは伝わり、その提案が良いものに見えてきます。
論理的で冷静な説明では、良いものを良いものだと理解させることはできますが、相手が興味の無いものまで「良いもの」と思わせるような、心を揺さぶるような提案はできません。
上記の例にあげた社内提案だけに限らず、社内外のあらゆる交渉時などでも同様です。
因みに、勘違いしてはいけないのが、「感情を込めて話をする」ことにおいて重要なのは、本当にその感情に自分自身が飲まれないこと。
感情的に話をしているかのように見せて、心のなかでは冷静さを保ち、相手の一挙手一投足を気を配ることが重要です。
社内提案の目的は建前でも営業部門の効率化や改善
新しいサービスを自社に導入したい、非効率な業務をシステム化したいとなり、社内の上の人達に提案をする場合は、営業部門が楽になるといった営業部門への効果を主体としたメリットを打ち出しましょう。
企業の経営者やそれに近い立場の人たちから見た場合、「バックオフィス」へのシステム投資は、将来的な経費の削減程度しかメリットを見いだせず、積極的にはなりません。
逆に所謂「フロントオフィス」と呼ばれる、営業などの直接利益を生み出す部署への投資はさらなる売上を作り出す可能性もあり、積極的にはなりやすいと言えます。
ただ、現実的には営業部門だけにITを充実させて、バックオフィスの業務は電子化されずにアナログという訳にはいきません。
当然、バックオフィス系部署の業務改善を目的としたシステム提案も必要になります。
しかし、前述したとおり、バックオフィスへの投資は極力抑えたいと思うのが経営者です。
そこで、主の目的はバックオフィスへの業務改善であっても、必ず営業部門などの売上を生み出す部門に対するメリットを強調しましょう。
バックオフィスの業務効率化がしたい
↓
営業部門への支援が充実します！
一見すると半ば強引にも感じますが、強引な論法であっても、提案の詳細を理解できる人が決裁者に居ないのであれば、それがそのまま提案の主題として通用してしまいます。
それで全員が幸せになるなら、このような論点のすり替えや誤魔化しも適切に利用していくべきです。
会計へのデータの流れを意識してシステムを構築しよう
社内で稼働している様々なシステムは、様々な目的で利用されていますが、それらの全ては企業の経済活動を円滑に進めるという最終的な目的に集約されます。
その企業の経済活動の結果は、会計データに落とし込まれます。
稼働する多くのシステムで生成されるデータは、最終的に会計システムにどのように流し込むのかを頭に入れておく必要があります。
もちろん会計上はまったく関連しないシステムもありますが、なかには貴方が意識しないだけで、自社の経理や財務担当者からしたら、実は欲しかったデータかも知れません。
一般的にはERPなどのパッケージやスクラッチで作った基幹システムなどの根幹を担うシステムがあり、その周辺には業務やサービスごとに様々なサブシステムが稼働している環境も多いかと思いますが、各サブシステムごとに生成されるデータは、そのシステムで完結してしまっているケースも多く見受けられます。
そのシステムのなかで完結してしまうことの全てが悪いわけではないですが、会計の知識のあるSEや、ERPコンサルなどの会計と密接に絡むシステムに携わる技術者の場合は、必ず会計をシステムの中心に据えてシステムを検討します。
尚、会計を意識すると言っても、具体的にはどういうことでしょうか。
例としては以下です。
- お金に関する個々のデータを勘定科目に置き換える。
- 金額計算時の端数処理は会計側と合わせる。
- 会計システムに無加工で流し込むためのテーブル設計。
このような会計を意識したシステム設計は、IPO(Initial Public Offering)に向けての準備などにシステム管理者として関わると、監査法人から改善するように指摘をあれこれ受けるため、嫌でも習得していくことになります。
もし御社がIPOの予定がなかったり、上場企業ではなく外部からの会計監査を受けなくてもよいとしても、システムから生成されるデータは、最終的に会計に流し込むという原則を理解しておくことは、非常に重要です。
また、もしできることなら、貸借対照表や損益計算書などの財務諸表が大まかにでも読めるように、簿記を多少でも学んでおくことをおすすめします。
情報システム部門もプロフィットセンターを目指そう
コンサルや会計寄りの人がよく使う言葉で「コストセンター」と「プロフィットセンター」があります。
「コストセンター」は、費用だけが発生し、利益を生み出さない部門です。
企業内の本社にあるようなバックオフィスなどの管理系部門を指します。
「プロフィットセンター」は、直接利益を生み出す部門です。
営業部門や販売などの部門が対象です。
一般的に、企業における情報システム部門は「コストセンター」として扱われます。
古く大きな企業では、プロフィットセンターに所属していたが、適性が無く成果を出せなかった社員や、周囲に馴染めなかった社員は、コストセンターに移動させられるケースも多く見受けられました。
成果を出せない社員が居ることで、プロフィットセンターの一人当たりの平均した成果も下がりますが、コストセンターに移動させてしまえば、ただのコストになります。
ただし、この情報システム部門がコストセンターといった考え方は、企業の経済活動においてITの活用が不可欠である現代の実情とは合っておらず、非常に古い考え方と言えます。
最近では「DX」といった概念も生まれ、ITを活用して事業に変革をもたらすといった意識も広まっています。
同じバックオフィスと呼ばれる経理や総務などの部署では、事業に変革をもたらすほどのインパクトの大きい取り組みを進めることのできる手段は、情シスに比べると限定的であり、ITを駆使できる情報システム部門だからこそ、大きな可能性が存在します。
よく「DX」をただの業務のシステム化や電子化と勘違いしている人もいますが、本来のDXは、ITと自社の事業を組み合わせることで、新しい事業を創出したり、既存の事業を大きく拡大するきっかけを作ったりと、目先の売上や顧客の創出、将来の収益の柱となり得る仕組み作るといったスケールのものであり、効率化による経費削減といったものではありません。
また、そこまでだいそれたことを手掛けないまでも、企業がITを活用することで、情報システム部門でも、プロフィットセンターに近い立ち回りをすることはできますし、世の中のITを理解する企業はそういった立ち回りのできる人材の獲得に積極的です。
よって、コストセンターとしての扱いを受ける情シスは、プロフィットセンターとして転身できるように意識しないといけません。
そのためには、新しいIT技術や他社の成功事例などに対して常にアンテナを張り、積極的に情報を集めておく必要があります。
また、革新的な技術や便利なサービスも、自身の技術力が伴わなければ使いこなせず、理解もままなりません。
プロフィットセンターになるには、相応の努力は不可欠です。
主催する社内会議では必ずアジェンダを用意しよう
自分が主催して社内会議を開催することもあるかと思います。
マネージャーやリーダーとしての経験豊富な人であれば、手ぶらで会議に参加して、会議室にあるホワイトボード一つで、適切に会議をまとめ上げることができるかも知れません。
ただ、人前で話すのが苦手だったり、効率的に会議を進めたいのであれば、最低限でも必ず「アジェンダ」を用意して会議に臨みましょう。
「アジェンダ」という言葉には、使われる状況や場所によって様々な意味に扱われますが、会議の場で使うアジェンダは「会議の予定表」です。
その会議の主題や実施予定日時や参加者などを明記して、その日に話し合う予定の議題を箇条書きで列挙しておきます。
中身はスカスカでも結構です。
それを予めデータで配布しておくとともに、A4用紙に印刷して会議の場に参加者分印刷して用意しておきます。
紙で印刷してアナログだと思われるかも知れませんが、アナログならではの狙いもあります。
個人的にアジェンダを作る際に気をつけていることを紹介しておきます。
- その会議の幾つかの議題を簡潔に箇条書き。
- 個々の議題には必ず項番を振る。
- 議題に対して決めるべき事柄はアジェンダに明記。
- 箇条書きした議題と議題の行間は余白を広くとる。
- 個々の議題に対する予定時間を明記する。
「1.その会議の幾つかの議題を簡潔に箇条書き」を補足します。
このままの内容ですが、会議では議題が一つではなく、複数の議題に分かれていることが大半です。
※逆に、適切なスコープで議題を細分化しておかないと、話し合うべき話題がまとまらず、その会議は失敗します。
その個々の議題は、アジェンダ内に一行で簡潔に記載します。
「2.個々の議題には必ず項番を振る」を補足します。
議題に項番を振り忘れると、個々の議題に対して後から振り返って話をする際に、「〇〇の議題の件」といった呼び方になり、一意の指定ができなくなります。
「n番の議題」と言えるように番号を振っておくことは地味ですが重要です。
「3.議題に対して決めるべき事柄はアジェンダに明記」を補足します。
ここも非常に重要です。
会議は「話し合って意見を募る場」ではなく「意思決定の場」である必要があります。
会議の参加者が提示された案や予定などを確認しながら、物事を進めるためにコンセンサスをとって確定させていく場です。
よって、会議のなかでは必ず決めるべき事項が存在しているはずです。
それは必ずアジェンダに明記しておき、それが決まらない間は、次の議題に移らないようにしておく必要があります。
アジェンダに書いてあれば、その決めるべきことを全員が意識することになるため、うっかり決め忘れることも無くなります。
必ず明記するようにしてください。
「4.箇条書きした議題と議題の行間は余白を広くとる」を補足します。
これは紙ならではの考えからなのですが、会議に参加していると、その議題に関するポイントや重要事項をメモしたくなります。
もちろん自身のノートやパソコンなどの機器を持参していればそれにメモする場合もありますが、やはり手書きが好きな人も多くいます。
メモを取りたいときに、その余白に書いてもらうイメージです。
手元に配られているアジェンダの用紙に対して、必要によってさっとメモれるようにとの配慮が広めの余白です。
会議の冒頭でその旨を口頭で伝えておくと良いかと思います。
「5.個々の議題に対する予定時間を明記する」を補足します。
会議は複数人が一堂に会して話をします。
その時間は何の生産性もありません。
よって、決められて時間に決めるべきことを決めて素早く終了するのが望ましい会議の進め方です。
ただ、参加人数が多かったり、議題が紛糾するような内容の場合は、どうしても時間が掛かってしまう可能性があります。
その場合も、予め個々の議題ごとに予定時間を明記しておくことで、参加者がその議題に対しての制限時間を意識するようになります。
また、自身が司会や進行役の場合は、その予定時間を盾に早く議論を進めるように促すことができます。
このように、アジェンダは会議の場において、非常に重要なツールになります。
事業会社の情シスでは、自社内の他部署と会議をする機会も多く、自身が主催となって会議を進めることも多々あります。
効率良く会議を行えるようになることで、情報共有が十分になされ、他部署との認識のズレも解消されて、プロジェクトをトラブルなく進めることができるようになります。
会議の場はリーダーシップ力の測る場でもあり、会議を上手に取りまとめてコントロールすることで、マネージャーとしての能力も評価されるようになります。
IT技術は特定領域への特化ではなく浅く広く
システム会社に務めている場合は、ITに関するスキルは特定領域に特化するほど専門性が高くなり、それが自身の給与や社会的評価に繋がります。
「浅く広い」ITスキルは汎用性があり、IT業界でも重宝されるのでは？とも感じますが、実態はそれほど評価をされません。
※その人のポジションや役割などの状況にも寄ります。
特定領域への特化が求められるのは、より高度な技術を持つ技術者しか関われない仕事も多くあり、広く浅いスキルしか持たない技術者では代わりが務まらないからです。
例えば、転職のプロである転職支援サービスのエージェントの場合でも、IT技術者の能力を見る際には、広い経験より特定領域へ特化した経験やスキルを高く評価します。
ただ、これはあくまでシステム会社などのIT業界内で働く場合のケースであり、非IT系の事業会社の情シスとして働く場合はまったく逆になります。
少し格好良い言い方をするなら、企業における情報システム部門とは、オーケストラにおける「指揮者」の役割です。
社内には様々なシステムなどのIT資産があり、それらを駆使して業務と呼ばれる旋律を奏でます。
指揮者は個々の楽器について演奏者以上に上手に扱える必要はありません。
それよりも、個々の楽器の音色が組み合わさったときに調和が取れているかを監視して、調和を乱している演奏者に対して指示をします。
多くの演奏者が自律的に調和を取れるものではなく、それらを統合するバランサーが必要になります。
それが、企業のIT活用における情報システム部門の役割です。
企業で活用されるITでは、サーバーやネットワークといった、所謂「インフラ」系のITと、業務システムなどの「アプリ」系のITがあります。
また、それらの分野に広く広がるように「セキュリティ」に関するITも大事な要素です。
昨今では様々な物事が電子化し、一言で「IT」と言っても、対象は無限に広がっています。
それらを全て自社内で構築、運用するのは困難であり、外部のシステム会社などに適切に委託しながら進めていきます。
社内SEや情シスというお仕事では、必ず外部に技術的な支援や作業委託をすることが前提となるとも言えます。
特定の技術領域にのみ特化した尖った能力では、指揮者のように全体のバランスを見る役割は務まりにくいと言えるでしょう。
また、外部のシステム会社に依頼をして作業をお願いするにしても、広い知識がないと、システム会社の作業に対して良し悪しの判断もできません。
もし貴方が、「君のスキルは広いが特徴が無い」と言われたら、活躍の場はシステム会社ではなく、非IT系事業会社の社内SEかも知れません。
部分最適と全体最適を適切に実施しよう
業務をシステム化して自動化や効率化を行う場合に、その「システム化」する範囲や対象によって、システム化内容を「部分最適」と「全体最適」に分けることができます。
「部分最適」とは、特定の業務における一部分を「システム化」したり、すでにシステム化されているのであれば、それを改善するような行為です。
「全体最適」とは、社内の業務全体や特定の業務の全体を根本的に見直してシステム化するようなことを指します。
部分最適では、今ある業務を前提に、それを局所的にシステム化しながら自動化したり効率化をしていきます。
よって比較的容易に実現できます。
全体最適では、局所的な一業務や一システムだけを見直すのではなく、企業全体の業務やシステムを抜本的に見直して、システム化しながら効率化をはかることを言います。
前述した部分最適と比較すると非常に大掛かりとなり、実現は簡単ではありません。
世の中の論調としては、全体最適は良いものであり、部分最適は古いシステムや非効率な業務を延命させたり助長する要因でもあり、良くないものとして扱われることもあります。
ただ、そういった認識を持つ人やそういった発言をする人は、ある程度の規模のシステムを運用した経験が無いのではないでしょうか。
稼働させたシステムを安定させるのがどれほど大変で、システムと業務をスクラップ・アンド・ビルドするのがどれほど過酷なのかを知らないのでしょう。
情シスなどのシステム管理者にしても、そのシステムを利用するユーザーにしても、多少使いにくかろうが非効率だろうが、システムが安定して動いてくれるのが一番有り難いのです。
システムの安定性を損なわずに改善する手法が「部分最適」です。
古い木をバッサリ切り落として、そこに新しい木を植林するが「全体最適」であれば、「部分最適」とは、古い木の枝に接ぎ木をして延ばしていくイメージです。
大事なのは、この「接ぎ木」をやり方です。
例えばバラバラの種類の木で接ぎ木をしてしまうケース。
システムで言えば、こっちのシステムではRPAを使ってシステムを補完し、こっちのシステムではローコード開発ツールでアプリケーションを作るといったように、一貫性が無く、且つ計画性の無いような部分最適のイメージです。
接ぎ木をするにしても、本来同じ種類や近い種類の木を継ぎ足すべきですし、将来的に継ぎ足した枝の先にはどれぐらいの接ぎ木が追加されるのかも想定しておかないと、強度が足らずに、いつかは折れてしまいます。
このように、部分最適でも使う技術や設計に一貫性があり、将来を想定した計画性があれば問題はありません。
ただ、何れは古くなりすぎた木が、重くなった枝を支えきれなくなり限界を迎えます。
そうなってからでは遅いので、そうなることを見越して余裕を持って全体最適に着手していきます。
当項の冒頭では植林に例えましたが、別の例えとしては、「全体最適」は大きくなり広がりすぎた枝葉をバッサリ削ぎ落とし、必要な枝葉だけを再構成します。
言わばデトックスのようなものです。
「全体最適」と「部分最適」のどちらが優れているというものではなく、そのどちらともを時期に応じて適切に実施していくことが必要です。
まずは、社内の業務のシステム化や、社内システムの改修などが必要になった場合に、この対応は「全体最適」寄りの内容なのか、「部分最適」寄りの内容なのかを意識するようにしましょう。
最後に
今回の記事では、非IT企業の情シスとして、仕事を進めるうえで気を付けておくとよいポイントや、頭に入れておいてほしいことを、個人的な経験などから紹介させていただきました。
私の個人的な考えで書いており、果たしてどこまで一般的に通用するのかわかりませんが、どなたかの参考になれば幸いです。
今回も長々と読んで頂きましてありがとうございました。
それでは皆さまご機嫌よう！
