前回SEの任務について書いたが，筆者の不徳の致すところで，読者の方から「理想的過ぎる，現実は違う」「今は古きよき時代とは違う」というコメントや「馬場はSEを知っているのか？」「老害では？」など辛らつな言葉をいただいた。だがそれにも懲りず筆者はこの“今日の一言”を続けるつもりだ。

　ただ，そのコメントの中に「この手のことは“筆者が言うSE”を明確にした上で述べた方がよい」という助言があった。感謝・感謝である。

　実は筆者も最近の読者のコメントを見て「この人が考えているSEは筆者が言うSEとは違う様だ」「馬場が考えているSEを説明しないとまずそうだ。筆者が考えているSEが読者のそれと違っていたのでは話の噛み合いようがない」と気になっていたところである。

　そんなこともあり，今回は筆者がSEをどうとらえているか，「筆者が言うSEとは何か」について述べる。

人によって違う「SE」という言葉の意味

　ITの世界では日頃「SE」という言葉を多くの人が使っている。例えば「SEが持つべきスキルは？」「SEの役割は？」「SEのプロジェクト管理力は云々」などだ。だが，IT技術者のどんな仕事をする人がSEかというと，人によってそのとらえ方は結構違う。

　例えば，アプリケーション開発するのが本来のSEだとか，基盤構築ができない技術者はSEではないとか，またプログラムを作っている技術者をSEに入れたり入れなかったり，運用設計している技術者はSEだがITコンサルは違うと考えたり，人によっていろいろなとらえ方をする。そして，こういう仕事をするのがSEだという自分なりの考え方をもっている。事実，筆者のブログに寄せられたコメントを見てもその傾向がうかがえる。

　言うまでもないが，SEのとらえ方が違うとSEに要求する能力や期待する役割も違ってくる。そうなると，SEにかかわる問題を社内や同業他社の方と討議してもなかなか噛み合わない。ひいてはそれがSEの仕組み作りやSEの指導などに支障をきたす。多くのIT企業でSEのあり方やスキル・キャリアなどがなかなか改善されないのは，これが一つの原因だと言えよう。

　ではそのとらえ方の違いはどこから来るかだが，どうも筆者の経験ではその人の経験や見識によって違うように思う。筆者も現役時代，そのためにあれやこれやと色々苦労した。そこで筆者の当時の経験などを踏まえて，筆者がSEというものをどう考えてどうとらえているか，そしてどう定義していたか，それについて説明したい。

　読者の中にも，「SE」をどうとらえてよいか悩んでいる人少なくないと思う。何らかの参考になれば幸いである。ただ，学問的に見てどうかを語れる見識は筆者にはないのでその点はご了承願いたい。

様々な役割の選手がいて初めて野球ができる

　まず，図をごらんいただきたい。この図はITの世界で技術的な仕事を行う技術職の呼称を大まかにまとめた図である。

　筆者はこの図の中の黄色で示したIT技術職全体を「筆者が言うSE」としてとらえている。即ち，筆者が言う「SE」は黄色の呼称で呼ばれているIT技術職の総称である。プロジェクトマネジャやアーキテクトや○○スペシャリスト，アプリケーションスペシャリスト，ITコンサルタントなどはみなSEだ。これが筆者のSEの定義である。

　野球に例えて説明すると，SEはプロ野球選手と考えればわかりやすい。プロ野球選手の中には，投手もいれば捕手やセンター，サードや2塁手もいる。SEも同様に，プロジェクトマネジャやアプリケーションスペシャリストなど，いろいろな役割のSEがいる。そして，いろいろな役割の選手がいて初めて野球ができるように，SEもプロジェクトマネジャやアプリケーションスペシャリストなど，いろいろな役割のSEがいて初めてシステムの開発などができる。

　いや，SI企業はプロジェクト管理に強いSE，アプリケーションに強いSE,ネットワークに強いSEなどいろいろな能力を持ったSEがいないとビジネスが成り立たないのである。

　IT業界では往々にSEを十把一絡げに「SEはネットワークに強くなれ，何とか資格を取れ」などという声を聞くし，また当ブログのコメントの中にも「モノを構築するのがSEの仕事と思うならSEはドンドン人間関係が希薄なタコツボSEになってしまう」などとSEに批判的なコメントもあった。筆者は，そんな人はピッチャーだけで野球ができると思っているのかと疑問に思う。だが残念ながらITの世界にはそんな人は意外と多い。

アーキテクトもコンサルタントも日本の顧客から見れば「SE」

　なお，その他の留意事項として3点述べたい。

(1)アプリケーションプログラムを書くIT技術者（俗に言うプログラマ）は筆者の定義ではSEではない。それは，一般のプログラム作りは付加価値のある仕事とは言い難いからだ。なお，将来SEになるために若い時にプログラムを作っている人も，設計を行うまではSEではない。

(2)IT系のコンサルタントは，筆者の定義ではSEである。それはIT系のコンサルタントの定義があいまいであるが故に，SEと考えた方が分かりやすいからである。事実，コンサルタントの名刺を持った人がソフトの導入やアプリケーション開発を行っている企業もあるし，また，SEと称する人がビジネス設計などをやっているIT企業もある。

(3)システムと製品の基礎知識や，アプリケーション知識，ビジネス知識，ビジネス人としてSEとしての心構えなどは，筆者の定義による全SEが持つべき基本能力である。それは，プロの野球選手なら誰でも「走って守って打つ」という基本能力や，プロの心構え，チームワーク力を持っているのと同じある。

　以上色々述べたが，おおまかに言うと筆者は“SE”をこのようにとらえて当ブログを書いている。要は，筆者が言うSEとは，ソフトの導入屋でもないし設計屋でもない，ITコンサルタントやロジェクトマネジャやアーキテクトや○○スペシャリストなど，いろいろなIT技術職全体である。それをあえて文章で表現すれば「SEはビジネスや業務の分析を行い，ビジネス設計やITベースの新システムの設計・開発・運用を行う職種である」としか言えない。だがこれだけでは人によってSEのとらえ方に違いが起こりやすい故に要注意であろう。

　最近IT企業の中にはSEという呼称をやめて，アーキテクトとかコンサルタントとかPMなどと言う呼称に変えている企業もある。だが，日本の顧客から見れば，名前が変ってもIT技術者はすべてSEである。そしてそれらは図のどこかに黄色の名前で入るはずである。いずれにしてもSE関係者の方々は「SEはプロ野球選手だ」ととらえるとSEのあり方やスキルなども考えやすい。これが今日の一言である。