「プログラマー」関連キーワード全てに何か答える 9/12

検索キーワードがアルファベットに突入しました。
しかし見慣れた単語が並びます。だいぶ冗長ですね。
一応最後まで頑張ります。

はい、第7弾「A」~「H」
キーワードの候補は、ラッコキーワードのGoogleサジェストから拾ってきています。
ラッコキーワード - プログラマ

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

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

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

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

ソフトウェアの「つくれば保守が増える問題」

なければ作ればいい。名言ですね。誰が言ったのでしょう。
リスクを考えたら何もつくれない。いやぁその通りです。
でも、後のことそろそろ考えませんか?

ソースコードを読むしかないと思わせるドキュメント。
意図の読み取れないコメントで構成されたソースコード。
ソースコードを読んでも全くわからない論理構造。

僕たちはどれだけ過去の遺産に苦しめられないといけないのでしょうか。
なぜ10年も20年も前の古い技術や古い思想のお守をさせられているのか。
もちろんユーザーの要求や環境が変化するからです。

今、僕は被害者ぶっていますが、自分のつくったソフトウェアに対する文句です。
僕のソフトウェアも10年選手が登場し始めました。

もうぶっちゃけます。
当時は丁寧に書いたつもりでしたが、今見るとソースコードもドキュメントもコメントも何を言ってるのかさっぱりわかりません。
毎日過去の自分に毒づいています。うへぇ。

とはいえ、自業自得と片付けるのはあまりに芸がない。
だって読みやすいドキュメントがあっても保守は辛いので。

エンジニアファーストの日本を!!

僕はエンジニアファーストな環境を作りたい。
我々何かを生み出す職業に不具合はつきものです。
評価する人は使って少しでもストレスを感じれば鬼の首を取ったように批判をしてきます。
僕らはバグを出した罪悪感と自己嫌悪に加え、評論家の人格攻撃に耐える必要があります。

僕らは弱い生き物で作ったものでしか自己表現ができません。
成果物の評価を常に気にしています。
否定の言葉一つで積み上げてきた自信が瓦礫と化します。
不具合を徹底的に批判していないで良い部分を褒めてあげればよいのに。
そんなことを思う今日この頃。ちょっと文章を書いていきます。

行先ボードでも作ってみるか⑰ – 行先ボードアプリの技術紹介

行先ボードアプリですが大したことをしていません。
ただ、簡単に実装できるのも色んな人が技術をタダで提供してくれているからだと思います。
敬意を払って使わせて頂いた技術についてご紹介します。

人付き合いの価値

人生において「やらないといけない」と思っていたことが
ただの思い込みだったなんてのはよくあります。
「人付き合い」もその一つです。

例えば以下のようなものです。

  • ご近所づきあい
  • 実家の会(盆・正月に親戚で集まるアレ)
  • 各種イベント事(年賀状・お歳暮・祝箸・結婚式)
  • 恋愛・結婚・出産

おそらく煩わしいと感じている若い世代は多いと思います。
僕はぶっちゃけ煩わしいです。若くないですが。
ぬくもりはワイフとこげ(猫)が必要以上に満たしてくれます。

個人的な話になりますが僕の実家は信心深い宗教一家で「助け合い」を重んじます。
僕も幼少期、何度も助け合いに関する神様のお言葉を読み上げましたし
助け合いを軽んじた人が不幸になる映像も何度も見ました。
こんな記事を書いて、たぶん僕はバチが当たります。

しかし、僕は技術者です。神罰は技術力で回避すべきと考えます。

IT界の風雲児インド – インド企業を人数で見ていきます

前回に続きまたインドネタ。
IT界の風雲児インド。現地技術者の給与面ではまだまだ低い水準にあります。
しかし技術力は日本のベンダーと比べても遜色ありません。
文化や宗教、考え方の違いはありますが、
インドは英語を公用語とする地域も多く、どこの国でもコミュニケーションが取れます。
万年IT人材不足の日本を含む諸国から見たらインド人の技術者確保は喫緊の課題です。
逆にインド企業から見ればアメリカや中国、日本は格好の狩場です。

今回はインドの企業について調べてみます。

巨人の肩の上に立つ – 論文を読もう

論文読んでますか?
偉そうに言ってますが僕も読んでいません。
一時期昼夜問わず読んでいたのですが、最近めっきりです。
これはいかんということで自分への戒めの記事です。

私がかなたを見渡せたのだとしたら、それは巨人の肩の上に乗っていたからです。

Wikipedia - 巨人の肩の上

DXの設計書⑰ – 会社全体を俯瞰してみる

会社全体を俯瞰してみましょう。
言うはやすし行うは難し。

とはいえ、会社の全体像を見るのはそれほど難しくありません。
雑にまとめてみても見えてくるものは多いです。
たたき台を作れば色んな人が補ってくれます。
「厳密には違う」おじさんがたくさん登場します。

ちょっとやってみましょう。

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

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

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

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