今回の記事は、前回の記事の続きになります。
Claudeに問う「システムエンジニアという言葉は欧米には無いの？」
日本のIT業界では長い間、システムエンジニアとプログラマーが役割分担する開発体制が採用されてきました。
私の経験では、初期はシステムエンジニアとプログラマーの区別は無く、後から両者を区別するようになってきたという認識でした。
今回、その辺を生成AIの Claude に質問してみました。
Claudeに問う「ＳＥとプログラマーを区別するようになった理由」
日本のIT業界で、SE(システム・エンジニア)とプログラマーを区別するようになった理由を教えてください。
日本のIT業界で、SE(システムエンジニア)とプログラマーの役割が区別されるようになった主な理由は以下のようなことが考えられます。
1. 大規模システム開発の増加
1960-70年代に大規模システムが増えてきたことで、開発プロセスの役割分担が必要となり、設計者(SE)と実装者(プログラマー)に分かれた。
2. ウォーターフォール開発手法の影響
当時主流だったウォーターフォール型開発では、設計と実装が別工程だったため、役割分担が明確になった。
3. 上流工程のスキル重視
要件定義や設計など上流工程のスキルがますます重要視されるようになり、それを専門とするSEの役割が確立された。
4. プログラマーのスキル特化
一方で、コーディングにもスキルが必要となり、実装専門のプログラマー役割が明確化した。
5. ハードウェアとソフトウェアの分離
ハードウェアとソフトウェアの分野が分かれ、ソフトウェア開発にSEとプログラマーの役割分担が生まれた。
6. 技術者の処遇改善の影響
SEという肩書で技術者の処遇を改善する動きもあり、役割区分が進んだ。
このように、大規模化するシステム開発において効率化が求められ、ウォーターフォール型開発の影響もあって、上流と下流の役割分担が進んだことが大きな理由と考えられています。
「6. 技術者の処遇改善の影響」について、もっと詳しく教えてください。
「6.技術者の処遇改善の影響」については、以下のような背景があったと考えられます。
1970-80年代頃、プログラマーの処遇が相対的に低く抑えられがちだったことから、技術者の地位と処遇の改善が課題となっていました。
コーディングだけでなく、システム全体をマネジメントできる高い技術力が必要とされるようになり、SEという職能資格制度が生まれました。
SEという名称は、エンジニアと同等の地位と処遇を得るために意図的に導入された側面があります。単なるプログラマーというよりも、高度なスキルを持つSEと位置付けることで、社会的な評価と処遇の向上を図ろうとしたのです。
SEの資格を取得することで、技術者としての社会的地位が高まり、プログラマーよりも高い年収水準が得られるようになりました。こうした処遇改善の動きが、SEとプログラマーの職種区分を明確化させる一因となったと考えられています。
SEという肩書きは、単なる技術者ではなく、システム開発プロジェクト全体をリードできる高度な技術力を持つ存在として、社会的な評価とステイタスの向上を企図したものだったのです。
二つ質問があります。
この場合、プログラマーの社会的地位は低いままなのですか。
SEとプログラマーの役割を分離したことによって、SEはプログラミング業務を行わないことになりましたか。そのような社会通年が形成されましたか。
1. プログラマーの社会的地位について
SEの導入時点では、一般にプログラマーの地位は相対的に低いままでした。しかし、その後次第にプログラマーの重要性が高まり、近年では地位向上の動きがあります。
具体的には、
– IT技術の高度化に伴い、優秀なプログラマーの需要が高まった
– プログラマーの処遇が徐々に改善されてきた
– 最近ではエンジニアという呼称も一般化し、地位向上にもつながった
ですので、SEが導入された当初はプログラマーの地位は低めでしたが、近年では改善の兆しが見られるようになってきています。
2. SEとプログラマーの役割分離について
SEとプログラマーの役割分離が行われた結果、確かにSEはプログラミング業務から遠ざかる傾向にありました。
– SEは上流工程の要件定義、設計などに専念
– プログラミングはプログラマーの役割と明確に分かれた
しかし、近年のアジャイル開発の広がりにより、役割分離は次第に解消されつつあります。
– 開発手法の変化に伴い、SEもコーディングに参加するケースが増えた
– 現在は、SEとプログラマーの役割の壁は低くなってきている
つまり、導入当初はSEとプログラマーの役割分離が一般的でしたが、時代の変化とともに、その壁は徐々に取り払われつつある状況といえるでしょう。
確認ですが、1990年代から2020年頃まで、ウォーターフォールモデル開発を行っているときは、SEとプログラマーは明確に分離されており、近年プログラマー需要の高まりと共に、アジャイル開発などへのシフトが起こって、SEとプログラマーの区別は薄れているという認識で良いですか。
はい、その認識で間違いありません。
1990年代から2020年頃まで:
– ウォーターフォール型開発が主流
– 役割分担が明確で、SEとプログラマーは厳密に分離されていた
– SEは上流工程(要件定義、設計)を担当
– プログラマーは下流工程(実装、コーディング)のみを担当
2020年頃以降:
– アジャイル開発の広がり
– SEとプログラマーの役割の壁が次第に低くなる
– 開発手法の変化に伴い、SEもコーディングに一部関与するようになる
– プログラマーの重要性と需要が高まり、地位も向上
つまり、ウォーターフォール型開発が一般的だった時代はSEとプログラマーの役割分担が明確でしたが、近年のアジャイル開発の浸透に伴い、役割の垣根が低くなりつつある、という認識の通りです。
特に2020年代に入ってからは、アジャイル開発の影響でSEとプログラマーの区別は徐々に薄れてきており、今後もその傾向が続くと考えられています。
SEとプログラマーを分離する慣習は、現在何か弊害を起こしていませんか。
はい、SEとプログラマーを厳格に分離する慣習は、現在いくつかの弊害を引き起こしている可能性があります。
1. アジャイル開発への対応の遅れ
アジャイル開発では要求の柔軟な変更に対応できる必要があり、開発サイクル全体に関与するエンジニアが求められます。
SEとプログラマーを分離すると、この要求に応えにくくなる可能性があります。
2. コミュニケーションギャップの発生
設計とコーディングを完全に分離すると、相互の認識のずれから要件のずれや手戻りが発生しがちです。
開発の効率が低下する恐れがあります。
3. 知識の非対称性
SEがシステムの知識を一手に抱え込むと、プログラマーはドメイン知識が希薄になる恐れがあります。
システム全体の把握が困難になります。
4. 柔軟性の欠如
プログラマーがコーディングに特化し過ぎると、設計の変更に対応できなくなる可能性があります。
発展的な変更が困難になる恐れがあります。
5. モチベーションの低下
プログラマーが単なるコーディング作業に閉じ込められると、仕事へのモチベーションが低下する可能性があります。
このように、過度の役割分離は開発の効率性や質の低下、人材の育成の面でマイナスの影響を及ぼす可能性があります。アジャイル開発の潮流に柔軟に対応できないリスクもあるといえるでしょう。
その問題は、日本の企業社会全体で、どの程度認識されているのでしょうか。
問題があると認識されているのか、全く理解されていないのか。
日本の企業社会全体でこの問題がどの程度認識されているかについては、一概に言えない面があります。
以下のように、企業によってばらつきがあると考えられます。
【問題を認識している企業】
– アジャイル開発やDevOpsなどの新しい手法を積極的に取り入れている先進的な企業
– グローバル展開する大手IT企業など、欧米の動向を強く意識している企業
– SEとプログラマーの垣根を低くし、一体化を進めている企業
こういった企業では、役割分離の弊害は十分に認識されており、改善の試みが行われています。
【問題があまり認識されていない企業】
– 従来のウォーターフォール開発を継続している中小企業
– 製造業など一部のモノ作り系の大企業
– 組織文化が保守的で変化に強くない企業
こういった分野や企業では、いまだにSEとプログラマーの役割分担をあまり問題視していない可能性があります。
つまり、先端のIT企業などでは十分に認識されているものの、従来型の開発手法を踏襲する企業ではまだ意識が低い、という状況があるように考えられます。
ただし、全体として見れば、アジャイル開発の広まりとともに、徐々にこの問題の認知度は高まりつつあると言えるでしょう。業界や企業規模によっては温度差があるものの、今後さらに議論が活発化していく問題であると予想されます。
難しい質問かも知れませんが、企業社会全体に占める、両者の割合はどのぐらいか分かりますか。概算で良いので回答をお願いします。
可能なら、その根拠もお答えください。
企業社会全体における、SEとプログラマーの役割分離の弊害を認識している企業と、認識していない企業の割合を正確に推計するのは非常に難しいですが、概算で以下のように考えられます。
【SEとプログラマーの役割分離の弊害を認識している企業の割合】
15~30%程度
【認識していない企業の割合】
70~85%程度
この推計の根拠は以下の通りです。
認識している企業の割合が15~30%程度と見られる理由:
– アジャイル/DevOpsを導入している先進的なIT企業は15~20%程度
– 一部の大手製造業などでも認識が広がりつつあり、10%程度とみられる
認識していない企業が70~85%程度と見られる理由:
– 中小企業が全体の7割程度を占めており、その多くが従来型開発
– 一部の大手非IT企業でも、まだ役割分離の弊害があまり意識されていない
– 業種、規模、地域によってばらつきがある
つまり、アジャイル/DevOpsの浸透が十分でない中小企業や一部の大手従来型企業を中心に、まだ役割分離の弊害があまり意識されていない企業が大多数を占めているものと推測されます。
ただし、これはあくまで概算の推計です。実際にはIT化の進展状況や、地域・業種ごとのばらつきが大きいため、正確な割合を算出するのは難しい状況があります。
私の個人的経験
Claudeの説明ではシステムエンジニアとプログラマーの分離が行われたのは、1970年代以降ということです。
私の個人的な開発経験で言うとシステムエンジニアとプログラマーの分離された開発の経験は、1990年代後半からチラホラ見かけるようになり、2002年ぐらいから一般化してきた印象があります。
少なくとも1990年代から2002年ぐらいまでは、システムエンジニアとプログラマーを区別する慣習は一般的ではなく、基本設計からコーディング・単体テスト・結合テストまで、同じ担当者が従事するのが普通だったと思います。
おそらくこの辺は、所属する業界や会社によって、違うのだろうと思います。
ただ、2000年代にはシステムエンジニアが設計書を書き、プログラマーが開発をするという開発スタイルが一般化した印象があります。
設計と開発の担当者を分ける弊害
開発経験から言えば、SIer特有の設計者と開発者を分けるやり方は、とても弊害が大きいと思います。
ドキュメントベースの開発による設計者は、設計書の品質に責任を持たないことが多く、実質的に「間違いだらけの設計書」を書いて、その修正と品質保証は後工程のプログラマーに丸投げにする事が多くなります。
特に多くのSIerの開発プロジェクトでは、設計書を書いたSEは設計書を書き上げた時点でプロジェクトから離脱してしまい、その設計書を用いた開発段階でプログラマーが設計書のデバッグをしているのが現実です。
これでは実質的に設計書を作成しているのはプログラマーという事になり、システムエンジニアの存在意義がありません。
また、この体制だと設計書を書くシステムエンジニアは設計書の品質に責任を持つ必要が無くなるので、どんどん設計書の品質が低下するモラルハザードが起きます。
実際、2010年代になるとどんどんシステムエンジニアの書く設計書の品質が悪くなってきた印象があります。
マネジメントの点から見ても、システムエンジニアは設計書を作成後、そのままプログラミングを担当して、設計書の品質に責任を持たせる体制を取るべきだと思いますね。
コードベースの開発にシフトした方が良い
私はアジャイル開発の信者ではありませんが、現在のSIerが採用しているウォーターフォールモデル開発は、問題が多すぎると思います。それはとてもブログ記事一つで説明できるものではないです。
ここでは設計書をテーマに語りますが、現在のプログラミング言語は非常に可読性が高く、ソースコードにコメントや補足的ドキュメント(UML,markdown等)を付加すれば、コードベースで充分に設計作業は可能と考えられますし、実際コードベース開発を実施しているプロジェクトは国内外に多数存在するわけです。
現状のドキュメントベースの開発は、「不必要な設計書を作成する」という無駄な工程を挟んでいることになり、非常に非効率な開発体制になっていると思われます。
Claudeに聞く限り海外では、コードベース開発が主流になっているようですし、この辺が日本のソフトウェア業界が国際競争力を失っている数ある理由の一つなのではないでしょうか。
この問題を作っているのはシステムエンジニアではなく、その体制を作り採用しているマネジメント層の責任です。
技術の進歩や、海外情勢との関係から見ても、体制の見直しが必要な状況だと思いますね。
経産省のDXレポートもそれを見越してあのような内容になっているのだと思います。
今日は、これまでにします。
ではまた。
下はClaudeへのリンクです。
