プログラマーとは何か② – エンジニアとの違い

プログラマーはエンジニアではないかのようなタイトルです。
エンジニアは直訳すると「技術者」。
間違いなくプログラマーはエンジニアに含まれます。

しかし不思議な事にエンジニアリングを訳すと工学になります。
エンジニアリングを設計として使う人もいますが設計はデザインでしょう。
色々日本語英語は残念です。

今回は「工学」の方向から攻めてみます。

行先ボードでも作ってみるか③ – 要件定義(システム構成)

システム構成は要件定義なのか?
う~ん。どうなんでしょうね。
僕は機能一覧を出すのに必要なもの全て要件定義に含んでいます。

ステークホルダが納得しないと機能一覧になりません。
なので、システム構成も僕は含んでいます。

では、システム構成です。

プログラマーの年収と生活のイメージ

つい先日昔勤めていた会社の後輩と話をする機会がありました。

転職して給料上がりました?
と聞かれたので、

上がったよ。
と答えました。

やっぱ給料って大事ですよね・・・。

と、含みのあることを言っていたので少し気になりました。
役職ついてない彼の給料は何となく想像がつきます。
子供もいるようですし色々大変なのでしょう。

今回はITエンジニアの給料と生活感のイメージについてお話したいと思います。

DXの設計書㉓ – 既存システムの機能拡張

既存システムを機能拡張する場合、
他の機能への影響を考える必要があります。
一般に「ちょこっと機能を足すだけ」と思われがちですが、
既に存在する処理に新たに処理を加えていくのは中々骨が折れます。
今回は既存システムの機能拡張についてご説明します。

DXの設計書㉒ – 開発者のユートピア新規開発

新規開発はしんどさもありますが楽しいものです。
規模にもよりますが、昨今の請負開発の状況 - ソフトウェア開発分析データ集2020の"SLOC(コード行数) - 開発規模"の内容から推測するに、10000行以下のシステム開発が中心でしょう。クラスの数で言えば30以下。
偏りはわかりませんが、10000行以下のものも正規分布するなら10~20クラスくらいが中心ですかね。

これくらいの規模でしかも新規開発。
時間に余裕があれば非常に楽しいものです。
この楽しさはおそらく脳内の分泌物によるものでしょう。
知らんけど。

DXの設計書㉑ – システムリプレイスは簡単?ありえません。

DXをやるにあたっておそらくシステムリプレイスが浮上してくるでしょう。
周りは簡単に言うかもしれません。

パッケージ入れるだけでしょ?

これまでスクラッチ開発でのシステムリプレイスについては何度か述べました。
今回はパッケージを使ったシステムリプレイスについてご説明します。

システムリプレイスの難しさ – ゼノンのパラドクス

超高層マンションの大規模修繕をできる会社が少ないと伺いました。
建物はどんどん老朽化し、安全性の面から人が住めなくなっていきます。
定期的にメンテナンスが続けられれば良いのですが、
高度な技術が必要で超高層マンションを大規模修繕することは難しいようです。

システムやソフトウェアも同様でその器は老朽化していきます。
ソフトウェア自体も時を経て新しい技術が登場し、当時最先端だったものも古くなります。
レガシーな技術を扱える人も少なくなり、
騙しだまし使い続け導入初期メンバーがいなくなった時点で手に負えなくなります。

システムリプレイス。システムの置き換え。簡単に言うけど難しい。
そんなシステムリプレイスのお話です。

DXの設計書⑯ – ユーザーを味方につけよ

ゴールや目的が「XXシステムを構築する」になっているケースをよく見かけます。

手段が目的になってますが大丈夫ですか?

程度の差はあれど、システムやソフトウェアは秩序やルールに従わせるものです。
人にはそれぞれ価値観があり、そぐわなければ秩序もルールも煩わしいだけです。

何の縛りもなく自由にやれてたユーザーはストレスを感じます。
ユーザーにとってシステムの導入はストレスです。

DXの設計書⑧ – 業務フローのビフォーDX、アフターDX

業務フローの話です。
僕は現状のBPMNのみを書くことが多いです。
システム導入後のBPMNは必要に応じてですね。

設計書や資料の価値は、どれだけ見返されるかで測定できると思います。

問題や課題に関するビフォー・アフター(現状とあるべき姿)の洗い出しは困難を極めますが、
業務フローのビフォー・アフターは簡単です。