引用させてもらいます。個人に依存して良いことは限られています。業務システムには運用があって、いくら開発時に「超生産性高い技術者」が颯爽と現れ短期間でカットオーバーできたとしても、もうその技術者は戻ってこないわけで。それ、誰が面倒見るのよ、と。http://d.hatena.ne.jp/gothedistance/20080529/1212033139開発時に超生産性高い技術者が颯爽と現れるところは、カオス化して手が付けられなくなったプロジェクトです。火消しと呼ばれる人たちは好きで保守性の低いコードを書いているわけではなく、圧縮された工期の中で仕方なくやっているだけです。そのような技術者を責めるのは間違いです。優秀な技術者はスケーラブルな設計をして、保守性の高いコードを書く人です。非エンジニアな人はよく勘違いをしますが、他人が理解できないトリッキーな実装を好む人は「優秀な技術者」ではありません。いまのSIerで問題なのは、優秀な技術者を増やして保守性を向上させるのではなく、誰が製造しても同じコードができるようにして保守性を向上させようとしていること。その手段がプログラミング言語を日本語に直したプログラム設計書であったり、猿でもできる手順書であったりします。プログラム設計書や手順書は不幸な現実を改善するためのエンジニアリングの結果であって、推進している人たちを責めるつもりはありません。根本的な問題は、手順どおりにやるだけでソフトウェアを製造できるほど技術が進歩していないことです。そもそも私は無理だと思っています。仮に実現してもソフトウェアの複製コストはゼロなので。製造業の手法がソフトウェア開発に通用しないことを認める時期ではないでしょうか。研究部門にはこの矛盾を感じている人はいるかもしれませんが、大企業の方針に背くことはできません。単価の高い少数の人が管理をして、単価の低い多数の人が手順どおり作業をすることは、経営者から見れば理想的でしょう。ソフトウェア開発はそれを100%可能にするほど進化していません。大規模開発が知識集約化するとは到底思えません。エンジニアリングが進むほど、作業はより労働集約的なものになります。知識集約化を期待できるのは、今まで人ができなかったことをITで実現する領域な気がします。その領域こそユーザ企業が主体的に挑戦してほしいと思います。追記この手のエントリは書きづらい。自分が今まで関わってきたソフトウェアエンジニアリングの根底を否定することになるから。あるべき姿は何だろうか。Requestを作成する2020-01-20アプリケーションの開発フローとGitOpsArchivesSearchはてなブログをはじめよう!int128さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。