何に困ってますか?と聞くことが超上流と考える3流

ソフトウェア開発において
超上流工程というのは問題を提議し課題を明らかにしていきます。

一般にソフトウェア開発者とユーザーは会話が通じません。
そこでどちらの知識も持った人が間に入って一つのシステムを作り上げます。
いわゆる通訳ですね。

僕が過去にインド人と仕事をした際、
日本語と英語の壁があり間に通訳が入りました。
通訳と言ってもインド人か日本人かによって全く理解度が変わってきます。
日本人の通訳が入るとこっちサイドはわかりやすいのですがインド人との会話はあまり通じて無さそう。
インド人の通訳が入ると僕は日本語には聞こえるが理解できない言葉に悩まされます。
ソースコードでなら会話ができるという異様な状況。
システム屋とユーザーの間の通訳も同じです。

インド人ほどではありませんが
日本語ネイティブ同士でも開発者とユーザーはあまり言葉が噛み合いません。
そんな状態で超上流工程を進めていきます。楽しいですね。

データベースとデータ – 引き分けか負けしかない世界

今回は、データベースとデータについて考えてみようと思います。
学術的な話ではないので、きちんと勉強したい人はしかるべきところへどうぞ。
データベースの嬉しさと大変さについて私の見解を語ります。

僕は生産管理系の業務アプリ開発が専門なのでそれなりにデータベースに触れてきました。
しかし、担当するジャンルによってはデータベースに一切触れません。
縁がなくあまり触れなかった人に、少しでも興味が沸く情報を提供できれば幸いです。

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

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

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

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

なぜ、とっとと失敗しないのか?

たかだか1万行程度のソフトウェア開発に、
何カ月もあるべき姿を議論し何カ月も課題を探す要件定義(?)に疑問を感じます。

GUIを持つアプリケーションであれば、1万行程度のものは画面数も片手で数える程度です。
慣れた言語でそこそこの経験があれば、開発は1人で2週間もあればそれなりの形になります。
テストも1週間もあれば終わるでしょうしドキュメント作成は数日で終わります。
1カ月がっつり使えれば普通に終わります。ぶっちゃけ1カ月も要りません。

DXの設計書㉔ – パッケージという選択肢

世の中に数多存在するパッケージソフトウェア(以下パッケージ)。
業務を包括するパッケージも存在します。
ERP(Enterprise Resources Planning)などはその最たるもので、数も多いし歴史も長い。

それなりのお値段もしますが、
スクラッチでつくるより値段も労力も抑えられるようになってきました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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