software engineer is an engineer
つまり（よくも わるくも）特別では ない。
類語
(professional, working) programmer
software engineer
software developer
事実確認
そもエンジニアにも幅広い gradation がある。
土木以外にも、化学とか色々。
記述と規範を混同する なかれ。
免許や資格は本質ではない。
論考
crossovers（他の工学の技術者と“ソフトウェア・エンジニア”をともに体験した人々）に尋ねた記録。
対比
伝統的 engineering vs software engineering
craft vs engineering
aka. craftsman vs engineer
aka. artisan
職人との違いは？
技師 vs 技術者
cf. technician
trad
abbr. traditional
noun: initial payment or investment
ja: 先行投資、事前準備
physical vs intangible
連載
engineering は、社会的な合意で定義される。
本質的な差では ない
traditional engineering vs software engineering
software (engineering) を 矮小化や過大評価しがち
翻って、（伝統的）工学も誤認してる。
土木工学だけが工学じゃない。
誤認による対比
table:vs
伝統的工学 ソフトウェア工学
phased agile, adpotive
predictable unpredictable
manufacture design
rigorous not rigorous
slower faster
Spiral Model や V Model などの interative/incrimental approach は すでに あった。
trad: more upfront
≠ waterfall model
iteration 期間が長いがゆえの経済的に合理的な帰結
spectrum? design vs implementation
なんなら Agile風はソフトウェアだけじゃない
e.g. New Austrian Tunnel Method (NATM)
design vs manufacture/construction
mechanical engineers do as well
そもそも design（設計）の定義は？
土木工学が例外的な だけ。
rigor
ja: 厳格さ
ソフトウェアは 適用の幅が広がった だけ。検証を 厳格にも できる。
真の違い
ja: （変更）速度
変更コストが圧倒的に小さいため
vs. 変更のたびに費用が飛ぶ
次点で速い: 化学工学
→ 非ソフトウェアでも simulation での prototyping が一般化してる
cf. digital twin
しわよせ → ソフトウェア
cf. 機械屋 → 制御屋
e.g. 737 MAX 事故
物理的な限界による制約
キツい
ソフトウェアにも
キツくはない
kludg（ja: ごまかし、応急処置）
ソフトウェア → 戻せる
伝統 → （二度と）戻せない
特別でない以上は、相互に学び合える。
論点: 未来と改善について
事例
UXの書籍
why について
software engineer 用
機械工学者にも有用
じゃあ how についての本は software に あるか？
crossover
interdisciplinary research（学際研究）
学び
逆に伝統的な方に教えることも多い
要点
process of making a product
traditional engineers are better at the overall strategic process
software engineers are better at the day-to-day process
どっちも
全体の戦略
日々の行動
planning
methodical process = 系統的体系的プロセス
疑義
ソフトウェアの変更容易性重視
たしかに伝統のよりは計画を重視しなくても良い。
cf. upfront planning
考察
なんちゃってアジャイルとは違って
time metters
bit more time for (upfront) planning
aka. design upfront
伝統的engineeringほどに計画する必要はないが、計画しないのもダメ。
professionalism（プロ意識）
e.g. 現場を見る
discipline（規律）
(bad) mindset
software is not physical but intangible → software engineer gets less professinal
責任転嫁
vs responsibility
more pride
less responsible than 伝統
伝統 ones learn from software one
2 lessons:
open communities
aka. openness
better career opportunitys
practitioner-oriented conference は普通
学術でも企業でも ない
サイロ化を防いでる。
対比
伝統の難点
lack of diverse career opportunities
独学が難しい。
costly: 機器など
恩送りは普通のこと
大発明
git上のエコシステムの大きさ
e.g. GitHub
DevOpsが活発
わづかに違う問い「ソフトウェアのアプローチを伝統の方に近づけるには？」
まとめ
ソフトウェア・エンジニアは本物のエンジニアである。
特異な点は少ない。2つある。
伝統の強さや責任感。ソフトウェアのオープンさ。
概念分析
license（免許）は 必要条件では ない
数学、特に解析が 必要条件では ない
創造的でも 芸術的でも あり得る。
共通点がある。
それぞれに固有の特徴がある。
なんならサイロ化されてる。
engineering の 共通項
abstract thinking
tidy work
「ちゃんとやれ」
a good kludge in just the right place 「適切な場所での適切な応急処置」
応急修理や いわゆるハック
software engineering の 特徴づけ
3点
高い一貫性
高い速度
⇔ 低いコスト
ゆるい制約
分類の3軸
consistency
velocity
constraint