いま、ITエンジニアは人気職種です。
2000年代のはじめ、ITエンジニアは 新３Ｋと言われてました。これは、きつい、厳しい、帰れない を指してます。当時のわたしの勤務形態では、月の労働時間が 300時間だったこともありました。月の稼働を20日とすれば、一日、15時間の勤務ですね。所定労働時間は8時間ですので、いつも7時間の残業イメージ・・・。
ある日、22時に帰ろうとしたら、リーダーからーー
お！早いね！早く帰れる日は、早く帰った方がいいよ。お疲れ様！
なんて、声を頂く状況でした。
いまは、ITエンジニアの労働は劇的に改善されてます。もちろん、これは「働き方改革」によって長時間労働を規制した影響が大きいと思います。残業がない ITの仕事も普通にあります。
ただ、長時間労働に対する法的な規制は、IT業界に限った話ではありません。
わたしは、ITエンジニアの仕事でいちばん生産性が悪い、ITの開発プロジェクトに関わる作業が省力化されたことが エンジニア の労働時間削減に寄与していると思ってます。
一般的にプロジェクトの開発規模が増すと、生産性は低下します。それによって開発工数が加速度的に増えます（下図）。規模の大きなシステムは個々のプログラムの関係性が複雑化し、他システムとの連携も発生します。そのなかでインタフェース開発の調整業務に工数を取られます。
かっての会社業務の全体最適は、会社の業務で使うデータを集中管理するデータベースを構築することが重要と考えられていました。
この考え方はデータベースのあるべき姿として正しいのですが、ある業務分野でのアプリケーションの開発が、他の業務に及ぼす影響を常に考慮する必要があります。
たとえば、日本企業では原材料の購買に於いて、締め請求を取るのが普通なので、原材料の入庫と請求書の受領はタイミングが異なります。
資材の購買データと会計データが、大福帳のように一元管理している場合、購買に於ける原材料入庫段階に於いて、請求仮勘定で仕訳します。そして、請求書を受領したタイミングで買掛金として仕訳する仕組みです。
- 原材料 100 / 入庫請求仮勘定 100
請求書受領時の仕訳
- 入庫請求仮勘定 100 / 買掛金 100
そうすると、お金の流れを管理する担当者は、資材が入庫した段階で債務が発生するであろうと認識します。そのため、必要となる資金の運用を先手先手で行うことが出来るメリットがあります。
しかし、システム面で見ると、購買を管理するシステムと、会計システムが直結しているので、購買部分の開発を容易にすることが難しく、常に会計への影響を意識しなくてはいけません。
そのため、一見小さいと思われる IT開発のプロジェクトも利害関係者が多くなります。結果として、プロジェクトの開発規模が増します。
さらに会社のデータを集中管理したシステムは、障害が発生したときの影響が深刻です。最悪、一日中、会社全体の仕事がストップしてしまうかもしれません。ITの仕事は、システムの可用性を維持することがいちばんのミッションですので、障害が発生したら、その原因を追究し、解消するための切り戻しや、改修や、リソースの追加に追われます。
わたしも過去に急遽、会社近くのビジネスホテルを予約し、深夜残業と仮眠を繰り返した経験があります。
ちなみに可用性とは、情報セキュリティの３要素（機密性、完全性、可用性）のひとつです。許可された者が、必要な時に必要な情報にアクセスできることを確実にすることを指します。
情報セキュリティの文脈でシステムの可用性を損ねる事象としては、外部からの不正アクセスによるデータの暗号化や、DDos攻撃によるリソースの異常消費で語られることが多いのですが、通常の業務利用でも可用性を損ねる事象はもちろん発生します。
月末が近づくと、売上や仕入を確定するため、営業や購買の事務担当者によるデータ入力が多くなります。一般社員も月の勤怠登録を終えるために通常よりも多く、システムへのデータ登録作業が発生します。そして、月初になると経理の締め処理に伴うシステムへのアクセスが集中し、会計関連の帳票を出力するため、データベースから特定の期間を対象とした一括データの取得が発生します。
システムのリソース消費は、タイミングにより変化します。それが一定量を超えると、動作が重くなり、ついには落ちてしまうことがあります。
月末月初は、アクセスが集中し、障害リスクが大きいタイミングです。
また、システムの入れ替えによる障害も多くあります。いま稼働しているシステムは、改修プログラムを常時導入しています。改修は、利用者の使い勝手を向上させる改善もありますし、昨年の場合ですと、インボイス制度や、電帳法による法に基づく改修を多くの会社が実施していたはずです。
通常、システムの改修は本番環境とは異なる環境で行います。そして、本番環境への移行で完全な移行作業が出来てない場合があります。その場合、障害につながるリスクが大きくなります。障害が発生したら、早急な切り戻し（移行前の状態に戻すこと）が必要になります。
残念ながら、システムに障害はつきものですが、データを集中管理するシステムを導入すると、障害が発生したときの影響度が大きすぎるのが難点です。
集中管理ではなく、会計、人事、購買、販売、生産といった、会社の各業務で個別のシステムが稼働し、閉じた世界でデータを保持していれば、仮に会計システムで障害が発生しても、事業をするために必要となる生産や販売活動への悪影響は限定的です。
今日は個別のアプリケーションをより複数の小さなコンポーネントとして分割し、それらの複数の独立したサービスが連携しあう開発方式が主流になりつつあります。この方式は、マイクロサービスと呼ばれます。マイクロサービスの源流は2007年頃から注目された、SOA（サービス指向アーキテクチャ）にさかのぼります。
マイクロサービスを導入すると、開発サイクルが短縮され、開発規模はスリム化されます。そのため、開発の生産性が向上します。また、マイクロサービスによるコンポーネントは相互に影響しません。ですので、あるコンポーネントで障害が生じても、アプリケーション全体が落ちてしまうことはなくなります。
こういう歴史をたどった結果、ITエンジニアの仕事は、むかしに比べると、かなり軽減されたと思います。
最近は、ローコード製品や、ノーコード製品の開発基盤が、アプリケーション開発に活用されてます。プログラマーによるコーディング作業も、以前に比べるとかなり楽になってます。ただ、実際に製品を使ってみると、可能な処理に限界があることが分かります。ローコードで複雑なことをしようとすると、基盤そのものがダウンしてしまうなど、まだまだ発展途上の印象です。
そもそも、ITの仕事は、職種的にテレワークがしやすい性質があります。満員電車で通勤するのではなく、在宅勤務やワークスペースで働く人も多い職種です。
そうしたいくつもの要因が重なって、ITの仕事は、新３Ｋ 職種から、人気職種への転換に至ったんだと思います。
