生成AIへの質問をそのまま記事に
しばらくブログを休んでおりました。
理由として、急速に進歩する生成AI(LLM)をどう使った物か悩んでいたせいでもあります。
また、私自身ブログの今後の方向性をどうするか悩んでいたことも重なります。
取りあえず、今後どうするか暫定的結論が出たので、再びブログを書いて行きたいと思います。
生成AIをどう使うか
詳しいことは別の記事で書いていますが、生成AIを使う方法として、二つの手段を使うことにしました。
分からない事を生成AIで調べるのは、当然のことなので、説明しません。
一つは、記事の一部を生成AIに補足的に書いて貰い、主要な文書は自分で書く方法。
もう一つは、生成AIとのやり取りを、そのまま対談記事のようにブログに掲載してしまう方法。
今回の記事は後者になります。
今回のテーマは「欧米にはシステムエンジニアという仕事は存在するのか?」という質問を、生成AIのClaudeに質問してみました。
Claudeを選択した理由としては、他の生成AIに比べて「比較的調教されていないから」です。
この点についても、後日記事にしたいと思います。
「生成AIへの質問の記事」では、他の人に簡単にマネされてしまうのではないか、と疑問に思われるかも知れませんが、このような記事は、どちらかと言えば「事実の拡散」を目的としているので、「書かれている事実が世間に広まれば良い」と思っているので、マネされても良い内容の記事です。
では、早速、記事に入りましょう。
Claudeに問う「システムエンジニアという言葉は欧米には無いの?」
SE(システム・エンジニア)という役割は、日本独自のものだと聞いたのですか、欧米にはSEという役割は存在しないのですか。
SEという役割は日本独自のものではありません。欧米でもシステムエンジニアという職種は存在します。
ただし、SEの具体的な役割や責任範囲は、国や企業によって多少異なる部分があります。
一般的には、SEは以下のような業務を担当します。
– システム要件の定義
– システム設計
– システム開発
– テスト
– 運用/保守
日本のSEは、上流工程から下流工程まですべての工程に関与することが多いのが特徴です。一方、欧米では役割分担がより細かく分かれている傾向にあり、システムアナリスト、システムアーキテクト、プログラマー、テスターなど、工程ごとに専門家が担当することが一般的です。
しかし近年では、アジャイル開発の広がりなどにより、欧米でも上流工程から関与する総合的なSEの役割が増えつつあります。SEの概念自体は世界共通なのですが、その具体的な実態には、国や企業による違いがあるということができます。
SE(システム・エンジニア)という言葉は、欧米でも使われていますか。また、SE(システム・エンジニア)という言葉は欧米でも通じますか。
はい、”Systems Engineer”または”SE”という言葉は欧米でも一般的に使われている用語です。
具体的には、
– アメリカでは”Systems Engineer”や”SE”が一般的に使われています。
– イギリスでも”Systems Engineer”が使われますが、同様の職種を”IT Systems Architect”や”IT Systems Designer”と呼ぶこともあります。
– ドイツなどの一部の国では、”Systemingenieur”のような言葉で呼ばれることもあります。
つまり、欧米の企業やIT現場でSE(システム・エンジニア)という言葉を使えば、おおよその職務内容は通じるはずです。ただし、細かい役割分担の違いはあるかもしれません。
また、最近は”Software Engineer”や”DevOps Engineer”といった言葉も増えてきており、SEという言葉だけでなく、様々な職種名が使われるようになってきています。
全体として、SEという言葉自体は欧米でも一般的に認知されている用語と言えますが、その具体的な定義は多様化しつつあります。
では、日本と欧米で、プログラマーという言葉の定義や役割に、違いはありますか。
はい、プログラマーという役割には、日本と欧米で若干の違いがあります。
【日本】
– プログラマーは主にコーディング(プログラミング)を担当する役割
– 上流工程(要件定義、基本設計など)への関与は少ない
– SEやシステムアーキテクトの指示に従ってコーディングを行うことが多い
【欧米】
– プログラマーの役割はコーディングに特化されている
– 要件定義や設計など上流工程への関与はほとんどない
– “Programmer”ではなく”Software Engineer”という呼び方の方が一般的
– アジャイル開発が広く採用されている影響で、エンジニアがコーディングに集中できる環境が整備されつつある
つまり、日本のプログラマーは欧米に比べて上流工程にもある程度関与するケースがあるのに対し、欧米のプログラマー(ソフトウェアエンジニア)はよりコーディングに特化した役割を担う傾向にあります。
ただし、昨今では日本でもアジャイル開発の影響で、プログラマーの役割が徐々に欧米スタイルに近づきつつあると言えるでしょう。
欧米のプログラマー(ソフトウェアエンジニア)は、ソフトウェアの設計に関与しないのですか。
欧米のソフトウェアエンジニアは、ある程度設計作業にも関与することが一般的です。
より詳しく説明すると、
– 要件定義や全体アーキテクチャの設計は、システムアナリストやソフトウェアアーキテクトなどの役割が担当する
– しかし、個別のモジュールやコンポーネントレベルの詳細設計については、ソフトウェアエンジニア(プログラマー)が関与する
つまり、大まかなシステム全体の設計は別の役割が担当しますが、実装する個別機能の詳細設計までをソフトウェアエンジニアが行うということです。
アジャイル開発が浸透している影響で、最近では要件定義から設計、実装までを同じチームのメンバーでまとめて対応することも増えてきました。その場合、ソフトウェアエンジニアは要件定義にも参加し、さらに上流工程への関与が高まる傾向にあります。
ですので、「設計に一切関与しない」というわけではなく、一定レベルの設計作業は欧米のソフトウェアエンジニア(プログラマー)の役割に含まれていると理解するのが適切でしょう。
日本のプログラマーは、ソフトウェアの設計に関与しますか。
はい、日本のプログラマーは一般的にソフトウェアの設計作業にも一定程度関与することが多いです。
具体的には以下のような点が挙げられます。
– 上流工程のシステム要件定義や基本設計はSEやシステムアーキテクトが中心的に行うが、プログラマーもある程度参加する。
– 詳細設計の工程では、プログラマーが自分が実装する機能のモジュール設計やコーディング設計を行う。
– 開発手法としてウォータフォール型が一般的で、工程分担がかたくなりがちだったため、プログラマーも上流工程に関与する必要があった。
– 近年はアジャイル開発の広がりにより、プログラマーの設計関与はより高まる傾向にある。
つまり、日本のプログラマーは欧米に比べてソフトウェア設計への関与度が高い傾向があり、詳細設計はもちろん、ある程度上流の基本設計にも参画することが一般的でした。
ただし最近は、日本でもDevOpsの考え方が広まり、徐々に欧米スタイルのプログラマーの役割分担に移行しつつあります。組織やプロジェクトによっても違いがあるものの、プログラマーの設計関与度は徐々に欧米並みになりつつあると言えるでしょう。
日本のソフトウェア開発は、ウォーターフォールモデルで行われるためドキュメント(設計書)ベースで開発が進められる傾向があるのに対し、欧米ではアジャイル開発によりコードベースで開発が行われるため、ドキュメント(設計書)作成への関与が少ない、という認識で合っていますか。
はい、その認識は概ね正しいと言えます。
【日本】
– 従来はウォーターフォール型が主流だったため、詳細な設計書や仕様書の作成が求められた
– プログラマーも上流工程の設計書作成に関与することが多かった
– ドキュメントベースでの開発が中心だった
【欧米】
– アジャイル開発が広く浸透しており、コードファーストが原則
– 要件やアーキテクチャレベルの簡単な設計書はあるが、詳細な設計書は少ない
– プログラマー(ソフトウェアエンジニア)は設計よりもコーディングに注力
– コードそのものが詳細設計を含む”仕様”と見なされる傾向が強い
つまり、日本は従来設計書ドリブン、欧米はコードドリブンという違いがあり、プログラマーの設計書作成への関与度合いに大きな開きがあったということができます。
ただし、最近では日本においてもアジャイル開発の広がりに伴い、過度な設計書作成は避けられるようになってきました。状況によっては欧米スタイルに近づきつつある側面もあると言えるでしょう。
「コードそのものが詳細設計を含む”仕様”と見なされる傾向が強い」ということは、欧米ではプログラミングが設計そのものであると考えて良いのでしょうか。
もしそうなら、コーディングしているプログラマーはソフトウェアの設計を行っていることになりますよね。
はい、その理解で正しいです。
欧米のアジャイル開発においては、コーディング作業そのものが設計作業を含んでいると考えられています。
具体的には以下のようになります:
– アジャイル開発では、詳細な事前設計よりも実装を通じて設計を行うのが一般的
– プログラマー(ソフトウェアエンジニア)は、コーディングを進める中で設計を具体化させていく
– コードに設計の内容や意図が反映されるため、コード自体が詳細設計の役割を担う
– リファクタリングなどによりコードを継続的に改善することで、設計の質も高められる
つまり、コーディングとは切り離された”設計”フェーズがほとんどなく、コーディング作業自体が設計を行う作業と密接に結びついているのが特徴です。
ですので、欧米のプログラマーはコーディングを通して実質的に設計作業を行っていると言え、”プログラミングが設計そのもの”と考えられています。コードを書きながら設計を具体化し、洗練させていくというサイクルになっているわけです。
日本では、アーキテクトのような全体設計とは別に、設計書だけを作成するSE(システム・エンジニア)という役割が存在します。
SEが書いた設計書に従って、別のプログラマーがソフトウェアを開発するという事があります。
欧米にそのようなSEは存在しますか。
欧米においては、純粋に設計書のみを作成するSEという役割は一般的には存在しません。
欧米のシステム開発プロセスでは、以下のような役割分担がなされているのが一般的です。
– システムアナリスト – 要件定義、全体アーキテクチャの設計を担当
– ソフトウェアアーキテクト – システム全体の設計、アーキテクチャを担当
– ソフトウェアエンジニア(プログラマー) – コーディングと個別モジュールの詳細設計を担当
つまり、ある程度の上位設計はアナリスト/アーキテクトが行いますが、下位の詳細設計はプログラマー自身が実装を通じて行うのが一般的です。
設計書自体は、要件定義書や簡単なアーキテクチャ設計書はあるものの、日本の旧来のウォーターフォール型のような詳細な設計書を独立して作成する役割は基本的にありません。
一部の例外もあり得ますが、概して欧米のソフトウェア開発ではアジャイル的なプラクティスが浸透しており、過度な設計書作成を避け、コードを中心に開発が進められる傾向があります。
プログラマー(エンジニア)がコーディングを通して設計を具体化させていくスタイルが一般的なので、設計書のみを作成するSEのような役割は存在しにくいと言えるでしょう。
再度、確認させてください。
この場合(欧米)のSE(システム・エンジニア)とは、ソフトウェアアーキテクトを示すのですか。
ソフトウェアエンジニア(プログラマー)は、SE(システム・エンジニア)では無いという解釈で良いのですか。
はい、その理解で正しいです。
欧米においては、一般に:
– SE(Systems Engineer) = ソフトウェアアーキテクト
– ソフトウェアエンジニア(Software Engineer) = プログラマー
と捉えられています。
つまり、システム全体の設計やアーキテクチャを担当する役割が「SE(システムエンジニア)」と呼ばれ、実際のコーディングを行うプログラマーの役割は「ソフトウェアエンジニア」と区別されているのが一般的です。
ですので、ソフトウェアエンジニア(プログラマー)はSE(システムエンジニア)とは別の役割だと解釈するのが正しいでしょう。
日本のように、詳細設計を含む包括的な「SE」という役割はあまり一般的ではなく、役割分担がより細分化されている傾向が欧米にはあります。
まとめると:
– SE(システムエンジニア) = アーキテクチャ設計を担当
– ソフトウェアエンジニア = コーディングおよび一部詳細設計を担当
となり、両者の役割は明確に分かれています。
日本型SE(システムエンジニア)の問題
かなり以前に日経BPのマガジンの記事で「システムエンジニアという役職は海外には存在しない」という解説を読んだことがあり、それが本当かどうかを今回生成AIに聞いて確認してみました。
言葉の上では欧米でもシステムエンジニアという言葉も役割も存在するとの回答ですが、その中身を詳しく質問してみると、日本はドキュメントベースの開発プロセスモデルであるウォーターフォールモデルでの開発故に、システムエンジニアは主に設計書を作成する仕事になっているのに対し、欧米ではコードベース開発であるアジャイル開発が主流である為「コーディング作業そのものが設計作業を含んでいる」とのことです。
日本では、アーキテクトとプログラマーの間にシステムエンジニアが挟まっている体制ですが、欧米ではこれが無い。
欧米ではプログラマーはソフトウェアエンジニアでありコードベースであるが故に設計も担う。
以前読んだ日経BPの記事は当らずとも遠からずと言えます。
私も以前から設計担当者と開発担当者を別の人間にやらせる日本のSIerのやり方には不信感を持っていました。
設計と開発の人員を分けてしまうSIer的役割分担は、問題があると思いますね。ここでは個人的意見は避けるので、これ以上は書きません。
この記事は、ご覧のように生成AIの Claude に質問した内容をそのまま記事にしたものです。
情報が信頼できるかどうかは、Claude に直接聞いてご確認ください。
この記事の書き方は、記事の「権威と信頼性」をClaudeに任せることができるメリットがあります。
今後、しばらくこのやり方で、事実の探求を目指す記事を書いて行きたいと思います。
今回は、これまでです。
ではまた!