【情シス入門】何故情シスはプログラミングを学ぶべきなのか

社内SE・情シス
スポンサーリンク

昨今ではプログラミングが子供たちの教育に広く取り入れられたり、社会人向けのプログラミングスクールも増えており、昔と比べても「プログラミング」はとても身近な技術になっています。

逆に、IT業界に勤める技術者の方が、プログラミングはプログラマ固有の技術であり、プログラマではない職種であれば、習得する必要はないと考える人も多くいます。

これは、特定の分野への専門性を高めることが技術者としての能力の高さに繋がるという考え方に起因しているのだと思いますが、個人的には、プログラミングはITの技術のなかでも非常に汎用的な技術であり、職種を問わず、習得しておくべき技術だと考えています。

そこで、今回の記事では、特に企業の情報システム部門に勤める人を対象に、プログラミングを学ぶ必要性や、活用することによるメリットなどを紹介していきます。

 

情シスの役割とプログラミング

所属している会社にもよりますが、我々情シスの業務は大変広く、自社で使用するPCなどの電子機器の管理や、社員が業務で利用する各業務システムの運用、サーバーやネットワーク機器の運用、情報システムのセキュリティ確保など、様々な業務を抱えています。

業務範囲が広いことにより雑多な業務で忙殺されていくことも多く、他部署や経営陣からの依頼事の対応や、社内の機器やシステムの維持をするだけで精一杯の状態になり、しばしば本来の「情シスの役割」を忘れがちになっていしまいます。

我々情シスは「企業のITサポート係」ではなく「企業のITを推進する役割」であるべきです。

ITを推進するあたり、本来プログラミング能力は大変有効なのですが、企業の情シスでは「プログラミングはIT企業のエンジニアやベンダーの仕事であり、我々情シスはそこまでしなくてよい」といった考えを持つ人も少なくありません。
確かに、SI作業を外注しているベンダーとの調整や管理に多くの時間を割き、自身でコードを書く時間や機会もないというケースも多いかと思います。
または、自身の担当業務は主に自社のインフラ関連の運用であり、プログラミング能力は求められないので必要無いという考えている人もいるかもしれません。

しかし、今や社会全体でプログラミング教育が推奨され、世の中の多くの企業でDXへの取り組みが広がるなか、情シスにとってのプログラミングは「あったら便利なスキル」ではなく、「習得しているのが当たり前のスキル」になろうとしています。
ITの世界はダイナミックに動いています。
自身の常識も日々アップデートしていくことが必要です。

 

情シスが業務に活かせるプログラミングの技術力

一言で「プログラミング」といっても、何らかのスクリプト言語で「Hello, World!」と表示させる入門レベルの技術力から、OSやブラウザなどの開発で求められる技術力では天と地ほどの差があります。
また、プログラムを記述するためのプログラミング言語や、その開発環境なども様々であり、具体的にどんな言語で、どの程度のことできれば情シスの業務において優位になるかも大事なポイントです。

そもそも情シスは、勤める企業によって求められる役割や能力も様々であり、一概にこの程度といった指標を提示することは難しいのですが、私が個人的に考えている「情シスに必要なプログラミング能力」としては以下になります。

 

まずはスクリプト言語を一つだけ

プログラミング言語において「スクリプト言語」と分類する場合は、「インタプリタ方式言語」と同類として扱う場合がありますが、当記事では、アプリケーション開発向けではない逐次解釈型の言語を指しています。

「プログラミング」と言われて多くの人たちがイメージするのは、仕事で使用するようなWebアプリケーションやWindowsアプリケーションの開発でしょう。
専用のメニュー画面や入力画面、一覧表示画面などがあり、それに対してユーザーはデータを入力したり、データを検索して必要な情報を表示させます。

このような画面を必要とする業務アプリケーションを作る場合に使用するプログラミングは難易度も高く、アプリケーション開発が主業務ではない情シスに求めるプログラミングスキルとしては過剰だと言えます。

情シスが習得するべきなのは、主にPC操作の自動化や、サーバー運用の自動化、業務システムの運用やシステム間連携を自動化させるためのスクリプト言語です。

具体的には以下になります。

  • PowerShell ：Windows標準のスクリプトでありコマンドラインシェル
  • Python ：Windows標準ではないが扱いやすいスクリプト
  • VBScript ：Windows標準のスクリプト(廃止予定)
  • bat ：Windows標準のコマンドラインシェル

一番おススメしたいのは「PowerShell」です。
Windows標準で利用可能であり、簡単なコマンド操作から、IF文やループ処理などの複雑な制御構文を含む処理の実装も可能です。
また、.NET Frameworkや.NET Coreの上で稼働し、それらの膨大な機能を呼び出して処理に組み込むことができます。
スクリプト言語とコマンドラインシェルの両方の役割を持たせられていることで、若干クセがありますが、基本的な構文を理解してしまえば、それほど難しくはありません。

また、「Python」もおススメです。
プログラミングスクールの定番言語でもあり、初心者でも習得し易く、Windows環境への導入も比較的容易です。
様々なライブラリを利用することができ、それによってデータサイエンス用途で活用したり、Webアプリケーションの開発でも利用できます。

「VBScript」は、PowerShellがWindows標準のスクリプトになる以前に広く利用されていたWindows標準のスクリプトです。
Windows環境でしか利用できませんが、VB系の構文で処理を記述でき、プログラミング初心者でも容易に習得ができます。
Windows環境であれば様々な操作を自動化することができ非常に便利です。
しかし、その強力な機能がセキュリティ上の脆弱性として悪用されることも多く、PowerShellにWindows標準スクリプトの役割を引き継いだこともあり、将来的に廃止が決まっています。

「bat」は大昔のWindows時代から利用できる、原始的なWindowsのコマンドラインシェルです。
簡単な制御構文が利用可能であり、IFコマンドを使用した条件分岐やFORコマンドを使用したループ処理などを組み込むことができます。
まったく使えないよりは使えた方が良いですが、たいていは上記のPowerShellなどで代替が可能であり、今の時代に積極的に習得する必要はないかと思います。

これらのスクリプトのうち、先ずはどれか一つでも習得しておくだけで、様々な処理を自動化できるようになります。

今どきの情シスなら、これらのスクリプトを利用してサッとコードを書けるようにしておいてほしいと思います。

 

VBAは今も昔も情シスの定番プログラミング言語

企業のOA事務の殆どはMicrosoft Officeの「Excel」と「Word」が使われています。
なかには、Google Workspaceを導入し、「スプレッドシート」や「ドキュメント」を活用している企業も居るかと思いますが、他社とのやり取りなどでMicrosoft Officeが必要になるケースもあり、完全にMicrosoft Officeを排除してOA事務を行うのは難しいのが現状です。

また、企業のOA事務作業のなかでも、最も活用されているのがExcelです。
自身の終業時間の大半をExcelの操作に割いている人も多いかと思います。

多くの人が利用し多くの時間を費やす業務であれば、それを効率化することによる効果も非常に大きくなります。

Office製品では、OA事務作業を効率化したり自動化するためのプログラミング言語である「VBA (Visual Basic for Applications)」が組み込まれており、VB6に似た構文でプログラムを作成できます。
このVBAを活用することで、ExcelやWordなどの操作の多くの自動化したり効率化することが可能です。

ExcelなどのMS Office製品を利用したOA事務作業の場合、社内全体で多くの社員が行っている作業ではなく、部署単位や作業者単位で行っている小規模な作業が多いです。
当記事では、基幹システムへのデータ入力など、社内全体で広く行われている業務を「マクロ業務」と呼称し、担当者毎など小規模な範囲で行われるOA事務作業を「ミクロ業務」と呼ぶことにします。

この「ミクロ業務」は、作業者が数人や一人といった範囲で行っており、その業務に関わる人が少ないことから、社外のシステム開発会社に自動化をお願いしたいと考えても、その開発費用に見合うコスト削減効果を得ることは難しいです。
その為、その作業が俗人化して特定の担当者しか行えない状態になっていたり、担当者が残業してその業務に対応しているケースも多々あります。

ExcelなどのMicrosoft Officeのなかで行うOA事務作業の多くは、前述した「VBA」を活用することで効率化や自動化することが可能ですが、ミクロ業務の特性上、外部のシステム開発会社に依頼することも難しい。
では、その作業を行っている作業者自身でVBAを使って効率化や自動化させるといった案もありますが、VBAを利用するにはプログラミングの知識が不可欠であり、非IT職種の従業員にそのレベルの技術を要求することも難しいでしょう。

そこで求められるのは、企業の情報システム部門、「情シス」です。

情シスがVBAによって、社内のミクロ業務を効率化、自動化することで、社外のシステム開発会社に頼むことなく業務を改善できます。
また、同じ社内の情シスであれば、作業者が行っている業務内容を確認して、それをVBAの処理に落とし込む行為もやり易いと言えます。

VBAによる業務の効率化や自動化は、業務の俗人化やブラックボックス化の要因になるといった批判もありますが、それはあくまで、VBAによって改善した作業をシステム管理者や部署の責任者が管理できていないことに起因しており、VBA自体に問題があるわけではありません。

情シスにとってVBAは、今も昔も社内の雑多で面倒な多くのOA事務作業を改善できる強い味方です。
是非習得しておいてほしいところです。

 

Web APIを利用するために必要なスキル

ひと昔前の「業務システム」と言えば、外部のシステム開発会社が顧客の業務に合わせて一から作ることが普通でした。
システム開発会社が一から作ることになるため、初期費用は掛かりますが、顧客の業務を広くカバーしてシステム化してくれつつ、システムの運用支援もしてもらえる場合も多かったため、情シスはプログラミングなどのスキルより、システム開発会社の管理や社内の要件の取りまとめといったプロジェクト管理業務が重要でした。

しかし、最近では様々なベンダーから業務システム用のクラウドサービス(以下SaaSと呼称)が提供されており、莫大な費用を掛けて自社の業務に合わせた業務システムを作るのではなく、月額費用を支払い、自社の業務内容に合ったSaaSを導入して利用するケースが非常に増えています。

SaaSを利用する場合、通常は顧客の業務に合わせてサービスのカスタマイズをしてはくれないのですが、その代わり、そのSaaS固有の「Web API」を用意しており、Web APIを利用して顧客側の既存システムや実業務と連携するような作り込みを可能にしているサービスも多くあります。

SaaSで提供されているWeb APIでよくある機能の例は以下です。

  • ユーザーアカウントの登録など
  • マスタ系データの登録など
  • トランザクション系データの登録や検索など
  • CSVデータの取込や出力など

ユーザーアカウントの登録や削除などのAPIが提供されていれば、一般的には情シスが担当しているユーザーアカウントの追加といったアカウント管理系の業務を自動化、無人化することが可能です。

マスタ系データの登録や削除などがAPIで行えることで、例えば、基幹システムのマスタと連動するような作り込みも可能になり、基幹システム側で保持するマスタと二重で管理せざる得ないようなケースを回避することができます。

日々蓄積されていくトランザクション系データの登録などがAPIで行えれば、大量のデータを一括で登録することができたり、別のシステムで登録したデータをSaaS側に自動登録するような連携も可能となります。

多くのSaaSでは、予め用意したCSVファイルを読み込ませることで、ユーザーアカウントやマスタを一括で登録できたり、登録済みのデータをCSV形式のファイルに出力する機能を用意していますが、SaaSによっては、これらの機能自体をAPIで操作できるようにしてある場合もあります。

上記のように、SaaSが提供しているAPIを利用することで様々な処理を自動化させることができ、あたかもシステム開発会社が作った業務システムのように、自社の業務や運用に合わせて利用することが可能です。

この便利なWeb APIですが、SaaSを提供している幾つかのベンダーの話では、APIを活用している企業(顧客)はそれほど多くはないという話でした。

何故、大半の企業ではAPIを利用しないのかと言えば、最も多い理由は「プログラミングスキルが必要になるから」です。

Web APIは、httpの通信を利用して、SaaS業者が提供しているWebメソッドを呼び出して実行します。
Web APIを実際に実行する場合、具体的には以下の流れになります。

  1. リクエストの作成：httpメソッドを指定し、ヘッダやパラメータ、ボディのデータを作成
  2. リクエストの送信：作成したリクエストをAPIに送信して実行
  3. レスポンスの受信：APIが返すステータスコードをチェックし、レスポンスデータを受け取る
  4. 結果の処理：必要によってレスポンスデータをパースして処理を行う

この一連の処理をプログラムに組み込んで実装することが必要になりますが、これらの処理は、普段皆さんが使用するブラウザがウェブサイトにアクセスしてhtmlページを取得させる一連の処理を手動で実装しているようなものであり、プログラミングにおける難易度も若干高めです。
よって、多くの企業ではこのプログラミングがネックになり、APIの活用ができていません。

しかし、プログラミングが出来ず、APIの活用ができないまま、社内システムのSaaS化を進めてしまった場合、例えば、個々のSaaSに対するユーザアカウントやマスタデータの管理といったシステム管理者の業務も増加する可能性があります。
また、SaaSを利用するユーザー側でも、異なるSaaS間で二重入力が必要になったり、大量のデータを一件ずつ手入力することが必要になるなど、管理者側と利用者側の両方で負担が増してしまうおそれがあります。

いくらそのSaaSの機能が優れていたとしても、そのSaaSを運用するために必要となる労力まで増えてしまっていては、SaaSの導入が成功したとは言えません。

では、自社でプログラミングすることを諦めて、SaaSのAPIを利用するプログラムを外部のシステム開発会社に作ってもらうという案もあるかと思いますが、用途的にバッチプログラムなど開発規模が小さいケースが大半であり、且つ、一般的には責任分界点の観点からも、システム開発会社は他社のAPIを使用するプログラムをあまりやりたがりません。

よって、SaaSのWeb APIを活用して業務の効率化を図りたい場合、その役割を担うことができるのは、その企業の情報システム部門になります。

Web APIを利用するためには、前述のようにプログラミング能力が必要ですが、プログラミング言語については、何でも結構です。
前項で紹介したPowerShellやPythonなどのスクリプト内でAPIを呼び出して操作することも可能ですし、VBAでOA事務作業と連携させることも可能です。

複数のSaaSを導入して自社の業務を回しているような企業において、SaaSが提供しているWeb APIを活用することで、SaaSの運用における手間を軽減し、業務効率を大きく改善してくれる可能性があります。
今どきの情シスであれば、Web APIと連携するプログラムも書けるようにしておいて欲しいです。

 

SQLの基礎的な知識

SQLはRDBを操作するためのコマンド群であり、個人的にはプログラミング言語と分類するのは若干違和感がありますが、当記事ではプログラミング能力の一つとして挙げておきたいと考えています。

SQLと言うと、主にプログラマなどのアプリケーション開発寄りの人たちが習得する技術というイメージが強いかと思いますが、個人的にはネットワークなどITインフラ系の職種でも簡単なSQLは書けるようにしておいてほしいと考えていますし、情シスであれば必ず習得しておいてほしい技術だと思っています。

まず「簡単なSQLが書ける」ということは、併せて「RDBの基礎的な知識を有する」とも言えます。

例えば、SQLの「INNER JOIN」句と「OUTER JOIN」句が書けるということは、RDBにおける内部結合や外部結合を理解し、RDBの特徴である「テーブルの正規化」についても基本的な知識があると言えます。
また、「WHERE」句内で「IS NULL」を条件とした抽出ができるなら、RDBにおけるNULLの概念を理解できていると言えます。

SQLを学ぶことにより、自ずとRDB自体の仕組みや概念も学ぶことになります。
また、RDBに欠かせない「正規化」は、何もデータベースだけの話ではなく、あらゆるデータの管理において、データを効率よく管理し、データの整合性を担保する考え方として流用が可能です。
ITにおける基礎教養の一つ言っても過言ではありません。

RDBを正しく理解していれば、例えば顧客管理をExcelでやるといった発想はまず起こり得ないでしょう。

もし実務上はSQLを使用する機会がなかったとしても、RDBを学んでおくことにより得られる知識は汎用的であり非常に有益です。

また、世の中にあるシステムの多くはRDBでデータを管理しています。
大規模なWebサービスなどではNoSQLなど非RDBが使われていることもありますが、それはRDBよりNoSQLが優れているから採用されているわけではなく、後からデータの定義変更が容易であったり、スケーラビリティが高い、処理が高速といった特徴により大規模なWebサービスに向いていることから採用されています。
このような一部のシステムを除き、世の中にある多くのシステムでは、NoSQLなどの非RDBよりも一般的なRDBを根幹のデータベースとして採用しています。

最近では自前のデータベースサーバーを保有せず、前項で説明したようにSaaSを活用して自社のシステムを運用している企業も増えていますが、企業全体で見ればまだまだそのようなシステム環境の企業は少ないのが実態です。
今でも多くの企業では何らかのデータベースサーバーを保有し、社内システムの多くはそのデータベースを使用して稼働しています。

RDBは多くの企業で利用されている汎用的な技術であり、SQLはRDBからデータを取り出したり更新を行うなどの基本操作を行うための技術です。
企業はDXを掲げ、世の中のIT職ではない社会人もリスキリングと称して学び直しが求められているなかで、IT職である情シスであれば、汎用的な技術であるSQLを習得し、データベースの基本的な操作ぐらいはできるようになっていて欲しいところです。

 

何らかのWeb系言語とhtml

今は昔に比べてWebの技術を利用したシステムやアプリケーションが非常に増えており、Web系の言語も非常に進化しています。

何故Webの技術が広がっているかと言えば、最も大きいWeb系のシステムやアプリケーションの優れた特徴として、「ブラウザ一つあれば利用できる」ところです。

前述したVBAであれば、プログラムの実行環境としてMicrosoft Office製品が必要です。
昔からあるWindowsアプリケーションであれば、その端末へ実行ファイルのインストールが必要になったりします。
利用できるOSも限定されていることが大半です。

Webアプリケーションであれば、利用者はどんなOSを使用していても利用でき、また、Webの技術は標準化されていることから、どのブラウザであっても利用できるため大変便利です。
しかし、Web系のプログラミング言語の場合、これまで紹介したプログラミング言語と比べても若干難易度が高いです。
難易度が高い理由としては以下です。

  • 画面作成にhtmlの知識が必要
  • httpプロトコルの知識が必要
  • httpメソッドなどWeb固有のコーディングが必要
  • Webアプリを動かすためにWebサーバが必要

Webアプリケーションはブラウザ上で利用するため、画面の描写はhtmlを使用します。
また、サーバーサイドのプログラムでhtmlを動的に生成してクライアントのブラウザに返すため、基本的なhtmlの知識は不可欠です。

また、ブラウザでWebアプリケーションを読み込む際にはhttpの通信を使用します。
そのため、httpの通信プロトコルに関する知識も必要です。

後、WebアプリケーションではGETやPOSTなどのhttpリクエストメソッドを目的に応じて使い分けますが、Web技術に馴染みがないと、なかなかすぐに仕組みを理解するのは難しいです。
また、CookieやセッションというWeb固有の知識も学ぶ必要があります。

更に、最も大きな理由としては、Webアプリケーションを動かすには、Apacheやngix、IISなどが稼働するWebサーバを用意する必要があります。

このように、プログラミングで求められる技術のなかでも、Webアプリの開発については、これまで紹介した内容と比べて難易度が高いのですが、それでも将来的な目標としておススメをしておきたいと考えています。
尚、フォームをたくさん有するようなWebアプリケーションを開発するのは大変ですが、単一フォーム、又は少数のフォームしか使わない構成のものであれば、ちょっとしたWeb系プログラミングの知識で充分開発が可能です。
Web系の言語でちょっとしたアプリケーションが作れるようになれば、アプリケーションの配布もURLを提示するだけで済むようになり、大変便利です。

また、最近では、「ノーコード・ローコード開発ツール」も広く利用されています。
このようなプラットフォームで作成するアプリケーションは、たいていWebアプリです。
基本的なアプリの作成は一切コードを書かなくてもできるようになっていますが、入力フォームの制御を作り込んだり、動的な処理を実装しようとした場合、必ずWeb系言語の知識が必要になってきます。
更に、アプリケーションを一から作らずにSaaSを利用する場合であっても、JavaScriptなどを活用してユーザー側でカスタマイズできる機能と有しているサービスも多く、やはりWeb系のプログラミング知識は重宝します。

当記事の初めに紹介したPowerShellなどのスクリプト系の言語や、Microsoft OfficeのVBAなどでプログラミングの基礎を習得したら、次のステップとしてWeb系の言語も是非チャレンジしてみてください。

因みに、主な「Web系の言語」としては以下になります。

Web系言語の例
フロントエンド

  • JavaScript
  • HTML
  • CSS

バックエンド

  • PHP
  • Java
  • Ruby

 

情シスがプログラミングを活用することによるメリット

プログラミングは手段であって目的ではありません。
当記事で伝えたいのは、「情シスでもプログラミングをできるようにしよう」ということではなく、「情シスでもプログラミングをできるようにし、その能力を活用して自社の業務に役立てよう」ということです。

当項では、情シスがプログラミング能力を得て、それを活用することでどのような効果やメリットがあるかを紹介していきます。

 

日常業務の効率化や自動化

会社にもよりますが、多くの情シスでは常に人手不足であり多忙です。
情シスが担当する業務はITの知識や能力が必要になるものも多く、自社内の他部署に移管することも難しいケースが大半です。
社内のITを推進する役割を担う情シスが自部署の業務で忙殺されているようでは、会社全体のITを推進することは難しいでしょう。

そのような状況において、プログラミング能力は情シスの業務負荷を軽減する強力な味方になります。

プログラミング能力を活用することで情シスの負荷軽減に繋がる業務例は以下です。

月次のデータ集計業務

多くの企業でよく見られる光景ですが、月末や月初になると、情シスが自社の売上や事業で必要なデータをかき集めて、Excelを駆使して集計し、それを経営陣などに提出するといった定例業務を持っていたりします。

経営陣の経営判断で使われる重要なデータの場合もあれば、定例作業化したのち形骸化し、はたしてこの集計データは本当に必要なのか、誰が真剣に確認をしているのかよくわからなくなってしまっているケースもありますが、取り敢えず情シスの担当業務である以上、決められたとおりに提出しなければいけません。

集計表の数や作成手順の複雑さによっては、かなりの業務負荷に繋がります。

このようなデータ集計業務は、プログラミング能力を活用することで、大幅に効率化をすることが可能です。

具体的には以下のように活用します。

  • Excel VBA：Excelの表作成作業を自動化
  • PowerShellなどのスクリプト：加工したExcelファイルの配信やアップロードなどを自動化
  • SQL：VBAやスクリプトなどと組み合わせて集計の元データの取得処理を自動化

これらのプログラミング能力を組み合わせることで、データ集計作業の一連の作業をすべて自動化することも可能です。
さらに、Windowsの「タスクスケジューラ」なども活用することにより、集計表の作成処理自体を決められた日時に自動的に動かすこともできます。

そうすることで、作業の自動化から無人化へと進化させることができ、例えば作業の手間が大きくて月次でしかできなかった集計作業も日次で実行することもできるようになります。
以前は月に一回しかデータを確認できなかった経営陣は、日々推移するデータを毎日確認できるようになり、重要なデータであればあるほど喜ばれます。

一度無人化してしまえば、後は集計内容が変更されたり、自動化した処理で意図しないエラーが発生しない限り、集計表の作成作業で情シスの手を煩わせることはありません。

プログラミングを活用することで、自部署の業務負荷を軽減しながら経営陣も喜ばせる優秀な情シスに生まれ変われるかも知れません。

サーバーや業務システムの運用業務

社内で使用する業務システムやそれらを稼働させているサーバーを安全に運用するのも情シスの大事な業務の一つです。

プログラミング能力があれば、これらの業務も効率化をすることができ、稼働させている業務システムやサーバーの信頼性を高め、より安全に運用できるようになります。

業務システムやサーバーの運用でプログラミング能力が役に立つケースとしては以下が考えられます。

  • データのバックアップ：バックアップ作業やデータの世代管理を自動化
  • 異常データのチェック：データベースにクエリを投げて異常データのチェック作業を自動化
  • ログデータのチェック：ログが正常に吐かれているか、エラーが書き込まれていないかのチェック作業を自動化

サーバーのデータのバックアップ作業をスクリプトで自動化して定時実行させるような活用方法は昔から定番です。
Windows系サーバーならPowerShellなどで比較的容易に作れますし、Linux環境ならシェルスクリプトを使用するケースが多いです。

業務システムの運用しており、データベースを定期的に参照し、異常なデータが無いかチェックするといった作業も自動化できます。

異常なデータが出来あがるなら、本来はそのシステム側を直すべきですが、システムを改修するにはお金も費用も掛かりますし、次のまとまった改修をするまでの間は目視でのデータチェックやデータ修正で乗り切るといったケースもあったりします。

その場合もチェック作業をプログラミングで自動化して定期実行させることで、異常があればメールを送信して情シスなどのシステム管理者に通知するといった作り込みが可能です。

サーバーや業務システムを運用するうえで、ログのチェックも大事な作業です。

OSのシステムログや、業務アプリケーションが出力するログ、業務システムの夜間バッチ処理の実行結果を書き出しているログなど、サーバーやシステムを運用するうえで、チェックしないといけないログは多々ありますが、それらを目視で一件ずつチェックしていくのは非常に大変です。

この作業もプログラミングを活用することで、ログを読み込んで異常なエラーコードが発生していないかチェックしたり、エラーログファイルが新しく生成されていないか特定のディレクトリを監視したり、バッチ処理でエラーが発生していないかエラーログを読み込んでチェックし、何か問題があったときだけメールを飛ばすようにすれば、情シスなどのシステム管理者の手間は最小限に収まります。

あと、例えばサーバーの使用リソースや状態を一元的に管理したい場合は、Zabbixに代表される「サーバー統合管理ツール」を導入する場合も多いのですが、何らかの理由で導入できなかったり、サーバー側の事情でエージェントが入れられず監視対象に含めることができない場合もあります。

その場合に、プログラミング能力を活用することで、ディスクの空き容量をチェックしたりネットワークフォルダへの接続のチェック、Pingによる死活監視といった処理をスクリプトで実装して定期実行させることで、異常があればシステム管理者が気付けるようにするような環境を作ることも可能です。

これからプログラミングを習得していこうと考えているインフラ系業務を担当する情シスであれば、サーバーのバックアップ用スクリプトの作成からチャレンジしてみてはどうでしょうか。

アカウント管理業務

情シスの大事な仕事の一つとして「アカウント管理」があります。
これは、社内で稼働する様々なシステムやサービスのユーザーアカウントを管理する業務です。

新しく社員が入社した場合、その社員が社内の各システムにログインできるようにアカウントを作成する必要があります。
また、社員が退職した場合は、そのアカウントで社内のシステムにログインできては困る為、アカウントを停止させます。
システムごと、サービスごとでアカウントを管理することが必要であり、稼働するシステムやサービスが増えれば増えるほどアカウント管理業務の手間も大きくなっていきます。

企業によってはSSO(シングルサインオン)の技術とIDaaSの技術を活用し、システムやサービスごとのアカウントを一元的に管理して効率的に運用している場合もあるかと思いますが、新しい技術を導入して先進的な認証基盤を構築するにはお金も掛かりますし、利用している各システムやサービス側でもその認証方式に対応している必要があり、現実的にはその様な先進的な認証環境やアカウント管理の運用を作るのは簡単ではありません。

アカウント管理に付随して、社員の所属部署のデータ上の管理も必要です。
3月決算の企業であれば、4月は大規模な組織改変が行われることも多く、社員の部署移動を社員マスタや各システムやサービスのアカウント情報に反映させることが必要になり、その時期は多くの会社の情シスが残業しながら対応していたりします。

これらの作業もプログラミング能力を活用することで自動化することが可能です。

例えば私の会社の例ですが、アカウント管理をプログラミングで自動化する前は、某人事管理パッケージソフトに人事部が社員情報を登録し、情シスは人事部が共用してくれた社員情報を元に、基幹システムの社員マスタやグループウェア、メールアカウントや各システムのユーザーアカウントをそれぞれ個別に作成していました。
当然情シスは大変です。

そこで私が以下のように変更しました。

  1. 人事部が人事パッケージソフトに社員情報を登録する。
  2. 人事パッケージソフトの機能である自動CSV出力機能で毎日社員情報をCSVで出力する。
  3. CSV出力先にあるCSVファイルを読み込み、前回分との差分を取得して基幹社員マスタに登録する。
  4. 基幹の社員マスタの更新日などを条件に、メールアカウントやグループウェア、各業務システムのアカウントを作成する。

上記の太字の工程の3.及び4.は、プログラミングで内製したバッチプログラムによって実現しています。
この流れに変更したことにより、情シスは手作業でアカウントをメンテナンスすることが殆どなくなりました。

尚、作成したバッチプログラムは、PowerShellやVBScriptを使用しているものが多く、基幹システムの社員マスタを参照したり更新するためにSQLも使用しており、外部のSaaSのアカウント登録を自動化するために、Web APIとの連携もしています。
アカウント連携先のシステムやサービスごとに連携用のプログラムを作成する必要はありますが、個々のプログラム自体はそれほど難しい処理ではありません。

上記のようなアカウント連携処理も、プログラミング初心者の人がすぐに挑戦して作れるってわけでもないのですが、最初は既存作業の半自動化など、手作業の部分を少しでも減らせるようにプログラミングを活用し、少しずつスキルアップしていくことで、いつかは全体の処理の自動化もできるようになるのではないかと思います。

 

ベンダー依存からの脱却

会社によっては、自社の業務システムの開発元であるSIerが保守も含め請け負っており、システムの運用業務も含めて取引先のSIerに委託しているケースもあるかと思います。
その場合、SIerが責任を持って運用に関わってくれるため、システムトラブルなどの問題が発生した場合でも情シス自ら原因を調査したり、対応方法を検討するといった事も不要になり、安心してシステムを運用することができます。

その反面、運用上の軽微な対応であってもSIerにお願いすることになり、何をするにしても対応が遅くなったり、社内の業務の変化に合わせて柔軟にシステムの運用を見直すといったことは難しくなります。
また、業務システムに対する軽微な修正もSIerでしか行えず、修正を依頼する度に改修費用が発生することになり、システムの運用コストも高くなってしまいます。

その結果、非効率なシステムの運用を我慢しながら続けていたり、また、使い勝手が悪く実態の業務内容と合わなくなっているシステムを改修することなく使い続けるといった悪循環が発生します。
SIerなどのベンダーが居ないと何もできなくなり、また、運用の効率化やシステムの改善もベンダー次第というベンダー依存の状態です。

ここまでのベンダー依存は極端な例ですが、自社の業務システムの開発や運用をSIerに委託している場合、システムの運用における足枷になるケースは多かれ少なかれあります。
情シスがプログラミング能力を持つことにより、ベンダー依存状態から脱却し、社内の業務の変化に併せてシステムの運用を見直すことができるようになったり、より使いやすいようにシステムを改修するといったことも可能になります。

では、プログラミングができることにより、どのようにベンダー依存から脱却ができるのかの具体的な例を以下で挙げてみます。

  • 業務システムの足りない機能をサブシステムとして内製で開発
  • データベースへのアクセスを可能としてデータの二次活用
  • 業務システムの改修を自社でも可能とすることによる改修対応の迅速化

ベンダーが開発や運用に関わっている業務システムを顧客である情シスが改修することは、プログラムソースの管理上の問題や、責任分界点の関係で難しい場合も多いですが、その業務システムで使われているデータを参照したサブシステムを自社で内製することは可能です。
予めベンダー側の承諾は必要ですが、承諾が得られるなら、既存の業務システムに対する改修は諦めて、新たなサブシステム側で本来欲しかった機能を実装してしまうことも可能になります。

また、業務システムで利用しているデータベースに対して、情シスでも自由にアクセスできるようになることで、データの提供をベンダーへ依頼したり現行のシステムにデータ出力機能を作ってもらうことなく、必要なデータが自由に取り出せるようになります。
業務システムが生成しているデータを自由に取り出せることにより、それらを集計したり解析するといったデータの二次活用が可能となります。

また、業務システムの改修自体を情シスでもできるようにすることで、業務システムの使い勝手のわるい部分や、実態の業務にそぐわなくなっている機能を改修するなどフレキシブルなシステム運用が可能になります。
情シスのスキルやリソースの余剰次第では、ベンダーが作った業務システムの代わりとなるものを自社で作るといったことも可能になります。

 

システム開発の技術力向上や知識の深まり

情シスがプログラミング能力を有し、社内の情報システムを積極的に内製していくことで、プログラミングスキルも向上していきます。
最初はやりたいことをプログラムで実現させるだけで精一杯だったのが、だんだんときれいなコードが書けるようになり、オブジェクト指向なども取り入れて合理的なプログラム設計ができるようになっていきます。

また、作成したプログラムがデータベースを参照させるような処理も伴う場合、データベースに対する知識も自ずと備わっていきます。

内製したシステムを複数名で利用する場合は、そのシステムを稼働させるサーバーを用意することになり、その結果サーバーの構築や運用に関する知識や経験が得られます。

そのサーバーでシステムを稼働させるにあたり、通信経路を用意したりアクセス制限を設けることが必要になれば、ネットワークに関する知識や経験も得られます。

企業で使用される様々なシステムは、上記のようにプログラミングやデータベース、サーバーやネットワークといった様々な分野に跨った技術を利用して動いており、どれが欠けても動きません。
情シスが自身でプログラミングをすることにより、プログラミングに関する技術はもちろんのこと、プログラミング以外の技術についても身に付いていきます。

また、プログラミングやシステム開発に関する知識や技術が身に付くことで、更に以下のメリットもあります。

  • システムの改善方法の選択肢増加
  • ベンダーとの意思疎通の改善
  • システム開発費用の工数妥当性のチェック

情シスがプログラミング能力を得ることで、自社の様々な困りごとについての対応方法の選択肢が大きく広がります。

システム開発会社などのベンダーに対する調整能力も、プログラミング知識があることによって、営業に対しては正確に要件を伝えることができるようになり、SEに対しては、設計や仕様について具体的に指示をすることができるようになります。

また、ベンダーが提示してくるシステム開発費用についても、ベンダー側の提示工数をそのまま受け入れるだけでなく、妥当性のチェックなどもできるようになります。

 

情シスによる生成AIのプログラミング活用

昨今ではAIがめざましい進化を遂げています。

会社によってはDXへの取り組みの一つとして、社内のAI活用を掲げている企業も多く、情シスはその取り組みを推し進める役割を担います。

AIを社員に活用させて社内の業務効率化を図ることも大事ですが、情シス自身もAIを積極的に活用するべきです。

AIの活用方法は色々ありますが、AIが得意な処理として代表的なものの一つに「プログラミング」があります。

AIにプログラムを書かせる場合、文章生成AIを利用することになります。
主要なAIサービスとしては主に以下があります。

  • ChatGPT ：OpenAI
  • Copilot ：Microsoft
  • Gemini ：Google

どのAIが優れているかについては賛否両論ありますが、比較的小さなプログラム、且つ適切なプロンプトを与えてあげる限り、どのAIであっても精度の高いコードを自動的に作成してくれます。

当記事ではプログラムを自分自身で書くことを前提とした内容でまとめておりますが、現代の情シスには「生成AI」という強力なツールが利用できるため、必ずしもコードを1から10まで自分自身で書く必要はありません。

本来プログラミングは集中力を必要とする作業であり、雑多な業務が多い情シスにおいて、コードを書くことに集中させてもらえないこともよくあります。
生成AIを活用することで、業務の隙間時間で効率よくプログラミングを行うことが可能です。

生成AIの登場以前であれば、プログラミングの習得の敷居は高く、情シスの誰もがコードを書けるようにすることは現実的に難しい状況でした。
しかし、今は生成AIが登場し、誰もが上質なコードを出力できる時代です。
それであれば、情シスも積極的にAIを活用し、プログラミングを業務に取り入れていくべきだと思います。

但し、生成AIが作成したコードを安全に業務に活かすには、ある程度のプログラミングの知識や経験は必ず必要です。
生成AIが作成したコードの意味を理解できず、実装内容が適切か否かの判断をできるだけの能力がないまま、AIが作成したコードを自社の業務に取り入れてしまうのは非常に危険です。

よって、生成AIをプログラミングに活用して効率よくプログラムを作成すること自体は推奨はしますが、まずは当記事で書いたような内容を生成AIに頼らず、自分自身の能力だけでやれるようにしてください。
生成AIはあくまで自身のコード作成における補助役としての関わり程度に留めておくことが必要です。

 

最後に

当記事では、今どきの情シスが何故プログラミングを学ぶべきなのかを、私の個人的な考えでまとめさせていただきました。

私自身、情シスの立場からプログラミング能力を活かして自部署や自社の業務を自動化していたり、簡易的な業務アプリケーションを必要によって内製し、外注するシステムと内製で対応するシステムを効率よく使い分けています。

個人的な感覚としては、情シスが自らプログラミング能力を活用することが当たり前過ぎて、もし私がプログラミングを一切行わずに情シスの業務や社内の業務改善をしろと指示されたとしても、大したことはできない気がします。

今回の記事で紹介したように、「プログラミング」は現代の情シスにとって、無くてはならない技術だと考えています。
自身の仕事を楽にしよう、社内の人たちに喜んでもらおう、会社の事業に貢献しようと考えたときに、プログラミング能力は強い味方になってくれます。

今回の記事をきっかけに、少しでもプログラミングに興味を持ってもらえたら嬉しいです。

ここまで長々と読んでいただきましてありがとうございます。
それでは皆さまごきげんよう。