キャリア20年超。ずっとプログラマで生き延びている女のコラム。

プログラマの仕事ってどこからどこまで?

»

 今いる会社の採用面接を受けたときに、社長と「プログラマの仕事ってどこからどこまで?」という話をしました。

 普通、面接で出てくる話題じゃないような気がしますが、わたしは社長に対して「定年までプログラマとして働かせろ」という要求を出していたので、それはとても重要な問題でした。

 社長とわたしの間で「プログラマ」の認識にズレがあったら、後々で大惨事を招くおそれがありますからね。給料の話の何倍も時間をかけた記憶があります。給料よりも大事な「待遇」の話ですから当然です(いや、給料も大事ですよ、社長!)。

 「とりあえずコーディングを仕事の中心にして欲しいです」

 「そりゃあそうだろうね。設計とかはやるの?」

 「クラスや関数の詳細設計とかは当然やります。手が足りない時は概要設計もやってましたし、テーブル設計もやりました。UML図の描き方も一通り勉強しました」

 「ああ、やっぱり設計はするんだ。よかった」

 「普通やりますよ。コーダーじゃないんですから」

 「コーダーって最近きかないよね。もはや死語なのかな」

 「そういえばいつからかきかなくなりましたね」

 わたしがこの業界に入った時、「プログラマ」の下に「コーダー」というポジションがありました。わたしも最初はコーダーでした。

 コーダーのお仕事は、プログラマが書いたフローチャート通りにコードを書くことで、上からもらったフローからはずれたコードを書くことは許されません。プログラミング言語の文法をマスターしていれば誰にでもできる仕事です。フローチャートに従ってひたすらコードを書くだけの仕事でしたけど、つまらなかったという記憶は残っていません。

 今のようにネットが普及している時代ではなかったので、プログラミングに関する情報は書籍と先輩方から拾うしかありませんでしたから、フローチャートも重要な教材のひとつでした。コーダーはプログラマになるための丁稚奉公、といったところですかね。

 「実は設計をやってもらえるのかを心配してたんだよ」

 「プログラマは設計もやるのがあたりまえなんじゃないんですか?」

 「おれもそう思ってるんだけど、プログラマはコーディングしかやらないって考えもあるみたいで」

 「プログラムのデザインはプログラマの仕事です」

 「うん。おれと同じ考えでよかった。安心した」

 いろいろと圧縮してありますが、そんな感じでプログラマの定義の一致を確認した結果、わたしは「永世プログラマ」(←カッコイイ言い方を模索してみた)として入社することができました。

 現状では、労働時間の8割くらいはプログラミングをしています。ちなみに、データの処理方法について検討し、クラス設計や関数設計を組み上げ、実際にコードを打ち込み、一通りの動作確認をするところまでが、わたし的なプログラミングの範囲です。

 簡単に言っちゃえば、仕様を受け取ってから仕様通りっぽく動いてますという形にするまで、ですね。付け加えると、「コーディング」と「プログラミング」は、わたしの中では同義です(←気分で使い分けてる)。

 あと、運用、保守を担当させてもらってるシステムでトラブルが発生したときに、ソースコードを読んで問題点を発掘したり解決策を検討したり、仕様の追加や変更を行う場合のコードの修正点をピックアップしたりするのも、今のわたしの重要任務です。

 それと、今の会社に入ってからは仕様検討にも口出しをするようになりました。

 「技術的にこういうことができるんだけど、この画面で使えばユーザーさんにわかりやすくなるんじゃないか」とか「ここをこんな風に変えてもらえれば帳票の出力スピードをあげられる」とかいったことですね。

 でも、それをどう活かすか(あるいは殺すか)は担当SEに任せます。わたしの提案が、ユーザーさんの意向や全体のシステムデザインとマッチするかを判断するのは、SEの仕事ですから。

 今の会社に入るまで、仕様に口を出すということをやってこなかったのは、口出しをしては「プログラマは黙ってコードを書いてろ」的なことを言われる、ということを何度か繰り返したためです。ずっと派遣社員という立場で働いていたので、そういうことを言われたら黙ってコードを書くしかありません。心の中で「もっといいやり方があるのに!」とつぶやきながら。

 プログラミング技術で解決し得る問題について、SEに提案を行うのもプログラマの仕事のうちだとわたしは思っていますが、そう考えるSEは意外と少数派のようです。「余計な真似をするな」と嫌がられることもしばしばでした。

 ダメSEほどそういう傾向が強いので、仕事ができないんならせめて助言を受け入れればいいのに、と思っていたんですが、多分、逆なんですね。周囲の助言を聞きいれないから、いつまで経っても仕事ができる人になれないんですよ、きっと。

 プログラミング技術をベースにしてシステムづくりに関わる技術者がプログラマだ、とわたしは考えています。

 ですから、プログラマが仕様について提案すること自体は、SEに対する越権行為だとは思いません。

 逆をいえば、会社や業界が言うところの「SE」であっても、プログラミングを基点にしてシステムづくりを考える人は、「プログラマ」と呼んでいいんじゃないかと思います。

 労働時間の何パーセント以上をプログラミングに費やしているからとかいうことではなく、思考の原点がどこにあるかでプログラマかそうでないかを判定する方が、わたし的にすっきりするというか腑に落ちるんですが、他の方々はどう考えているんですかね。

 とまあ、プログラミングが仕事の中心でなくてもプログラマと呼べる人はいる、と考えてはいても、わたしはやっぱりプログラミングだけしていたいです(苦笑)。なので、わたしの「プログラマでいたい」は「プログラミングだけをやっていたい」という意味です。

 わたしが定義するところのプログラマに比べて、わたしがやり続けたいプログラマの仕事はもっとずっと範囲が狭いわけで……なんか、自分で自分の意見を否定してるような気がしてきた……(←話がオチてないし!)。

Comment(14)

コメント

ひでみさん、こんばんは。

つまり、いわゆるSEのやるマネージメント以外はPGの仕事というわけですね。

私もそう思います。
儲かったら社長を雇って「設計とコーディングをやるだけの立場になってやる!」って思ってます。

闇に隠れて生きてるわけではないけれど、「早くプログラマになりたい!」ってとこです。

まぁ、業界としてマネージメントを高く評価しすぎというのが悪弊のひとつで、私は、それを正したいと思って馬鹿なことをやっています(苦笑)

インドリ

この業界は知らないものを管理できると思い込んでいるからね・・・
私の場合プログラマ=情報処理技術者だと考えて、全ての事を学んでいます。

にゃん太郎

ひでみさん、おはようございます。

 昔はSEって営業も入っていたような気がします。今はSEとPGの境界線が曖昧ですが、現場によっては「設計」「製造」と言う分け方もするみたいです。

 個人的には生島さんがおっしゃる通りマネージメントとグランドデザイン以外はPGだろうがSEだろうが関係ないと思います。私自身もそうあって欲しいと願ってます。

 ちなみに私はPMですが、「親方」って呼んでます(笑)マネージャーなんて柄じゃねーわ!

amiga

お初です

コーダーってのは、パンチカードの時代ですからねぇ

>コーダーのお仕事は、プログラマが書いたフローチャート通りにコードを書くことで
とありますが、そんな仕事の仕方があったんですか…
いきなり仕様書かいて 組んで テストしてましたがな

そもそもSE(システムエンジニア)って言葉、さすが和製英語なのですが
システムと言う言葉が大局的過ぎて、なにを指しているのか良くわらないと言うか…

アメリカなどで言われるソフトウェアエンジニアなら判り易いんですが
それだとプログラム関連以外の仕事はふれないから
システムエンジニアって言葉を使うのでは? と邪推してしまいます

ひでみさんのやってる事ってPGと言えるのか?
逆に言うと、PG経験が多少なりとも無い人に、システムエンジニアってのは出来るのか?

私はマネジメントまでやるのはマネージャーであって、システムエンジニアの仕事では無い気がします
マネジメントが出来るのなら、その人はマネジメントだけして欲しい

私が昔リーマンの頃いた会社では、仕事取って来れるのがSEと言ってました
そういう事もあって、いまだにシステムエンジニアってのが判らなかったりします

ぶっちゃけ、マネージャーとプログラマ(ソフトウェアエンジニア)でいいじゃんと(笑

また今は、言葉尻以外のコーダーは居ないのでは無いか? と私は思います

ひでみ

こんばんはです。ひでみです。
いろいろとコメントいただきありがとうございます。
コメント返しがいつも簡単ですみませんです。


生島勘富さん。

> つまり、いわゆるSEのやるマネージメント以外はPGの仕事というわけですね。
> 私もそう思います。

自分の考えが一般的かどうかわからなかったので、ご賛同いただけてうれしいです。
私と生島さんだけだったらどうしよう(←どうみても「一般的」じゃないし(笑))。

> 業界としてマネージメントを高く評価しすぎ

マネージメントを軽く見すぎているから、キャリアもなければスキルもない連中にマネージメントをまかせてしまうんじゃないか、という気がします。


インドリさん。

> 私の場合プログラマ=情報処理技術者だと考えて、全ての事を学んでいます。

うわっ、私が考えているよりもずっと範囲が広いんですね。


にゃん太郎さん。

> ちなみに私はPMですが、「親方」って呼んでます

えっと~、女でも「親方」ですか?(笑)


amigaさん。

>>> コーダーのお仕事は、プログラマが書いたフローチャート通りにコードを書くことで
> とありますが、そんな仕事の仕方があったんですか…
> いきなり仕様書かいて 組んで テストしてましたがな

新人の頃、そういう環境で働いていたんで、それが普通だと思い込んでいたんですが、あの環境が一般的だったかどうかはわからないですね、言われてみれば。
でも、いきなりプログラム組める人がコーダーってことは、プログラマの立ち位置はどうなってるんでしょうか?

> ひでみさんのやってる事ってPGと言えるのか?

とりあえず私と社長の間で合意がとれているので私の中では問題ないんですが、一般的なプログラマの守備範囲は私も知りたいところです。

> マネジメントが出来るのなら、その人はマネジメントだけして欲しい

マネジメントできるけどコードを書きたいって人に、マネジメントだけやれ、と言うのは気の毒かと思います。
両立が難しいのは確かでしょうけど。

虚人

欧米と日本とでは、職種に関する定義が違いますよね。
日本だと、マネージャとプログラマ以外は存在しないのかもしれません。プログラマの範囲は非常に広いと思います。(マネージャ教育はほぼ壊滅しているので、業務の大半の部分を、プログラマが背負っていると思っていますが)
欧米だと役割分担がきっちりしてますよね。プログラマが設計者に”提案”(口出しとも言う)をしたら、プログラマは首になりますしね。
なにごともすり合わせ文化の日本ならでは、というところでしょうか。

hideaki

はじめまして。

今まで20名にも満たない会社を2社経験し、
現在は数百名くらいの会社に勤務する20代後半の者です。

SEだのPGだのという分け方がない、会社で働いてきた
せいか上で書かれているような働き方をしてきました。
(というか小規模過ぎて「SEだからプログラムをしない」
「PGだから設計をやらない」と言ってられない)

現在の勤務先でいう「プログラマ」とは上の「コーダー」
のような存在になっています。

「設計書に関数のことなんて書いてなかった」
「設計書にクラスを作れなんて書いてなかった」
「SEが完璧な仕様書を作ってくれないと作れない」
という会話がよく聞こえてきます。

ですので、「プログラマの仕事ってどこまでの範囲
なんだろう?」と最近考えておりました。

やはり会社によって考え方というのは変わってくるのでしょうね。

友ぞう

ひでみさん、こんにちは

プログラマとSEをきっちり定義するのって難しいですよね。
私は設計や文書作成がほとんどで、プログラムを書くときは
プログラミングリーダーの基でやってます。
私は職種上はSEなのですが、
以前は売上も上げて回収をしたりもしてました。

今は売上は営業がやってますが、以前は人が少なかったので
営業的なこともSEがやっていたのです。
ハードは営業、ソフトはSEみたいな。
だから、SEっていうと営業もSEもPGもやるのがSEって感じでした。
SS(セールスSE)なる訳のわからない言葉まで作られてましたが。

でも、派遣のPGさんで仕様に書いてないから実装してません。
て言われたことがあったり、設計は契約にありませんから、と言われたこともあります。そうやってPGさんから線を引かれると困ってしまうんですよね。
ひでみさんのようにこうしたほうがよくなるとか提案してもらえると
本当に助かるんですけど・・・

私はプログラムするのは好きですが(書いてるときは楽しいし)難しい部分になると荒が出てしまうので、プロフェッショナルな部分は全面的に精通した人にお願いしています。その分、文書にまとめたり資料を作って説明・説得する部分は私の担当なんです。だから私はPGかSEかって言われたらSEなんでしょうね。

kuma

ひでみ様


いつも記事を楽しみにしております。
寄せられた多くの方のコメントも、他の技術者の
考え方がかいまみえて、参考になります。

ひでみさんがお考えになっているのは、
プログラミング中心思考(指向)と捉えてよろ
しいでしょうか? おもしろい考え方です。


マネ―ジメントが求められるのは、お金が
上~下に流れていくのと、プロジェクト
のQCDがうまくいってないからじゃないでしょう
か、そのぐらいしか思いつきません。

Tasuku

PGとSE。 という区分は、とっても昔のCOBOLでパンチカード。が前提だった頃の話ですから、今時、PGとSEを定義付けすること自体、無理がありますよね。
[情報処理試験]自体が、1種/2種から脱却して久しいのに、営業上は未だにPGとSEの分類なのですから、不思議な業界です。
敢えて定義するならば、マネージャ/テクニカル・エンジニア。 という観点で分けるのが、現実的なのではないでしょうか?

ひでみ

こんばんはです。ひでみです。
昨日、コメント欄が完全に沈黙していたので油断していたら、いきなり増えていてビックリしました。

先月『プログラマなんかで終わりたい』というコラムを書いた時に、ありがたいことにたくさんのコメントをいただきまして、その時に、プログラマの定義をはっきりさせないで記事を書いたせいで、ちょっとした行き違いが発生しているのかな? と思いまして、私の定義するところのプログラマはこれなんです、というとこを明確にしておこうと思ってこの記事を書いたんですが、皆様のコメントを読ませていただいていたら、やっぱり定義が個人や会社でまちまちなんだなあ、ということがはっきりわかって、ちょっとだけすっきりしました。


虚人さん。

> 欧米だと役割分担がきっちりしてますよね。プログラマが設計者に
> ”提案”(口出しとも言う)をしたら、プログラマは首になりますしね。

それは知りませんでした。私、欧米だったら簡単にクビになってますね(苦笑)。
もっといいシステムになる余地があるのに黙っているなんて、仕事をサボってるような気持ちになるんですけど。


hideakiさん。

> 「設計書に関数のことなんて書いてなかった」
> 「設計書にクラスを作れなんて書いてなかった」
> 「SEが完璧な仕様書を作ってくれないと作れない」
> という会話がよく聞こえてきます。
> やはり会社によって考え方というのは変わってくるのでしょうね。

私の考える「コーダー」が「プログラマ」な会社もあるんですね。
ということはやはり入社前に確認しておくのが無難、ということになるんでしょうか。
面接の際に「御社のプログラマの定義は…」とか訊いたら、変わった人だと思われそうですが(苦笑)。


友ぞうさん。

> 派遣のPGさんで仕様に書いてないから実装してません。
> て言われたことがあったり、設計は契約にありませんから、と言われたこともあります。
> そうやってPGさんから線を引かれると困ってしまうんですよね。

設計をやらないのは、プログラマの仕事範囲じゃないと考えているからなのか、設計をやって何か問題が発生しても責任をとれないからなのか、どっちなんでしょうね。
前者だったら私と考え方(姿勢?)が真逆ですけど、後者だとすると、長いこと派遣として働いていた者として、その気持ちはわかります。


kumaさん。

> 寄せられた多くの方のコメントも、他の技術者の考え方がかいまみえて、参考になります。

私も皆さまのコメントのおかげで、世の中には多様な考え方がある、というあたりまえのことを再認識させていただいています。

> ひでみさんがお考えになっているのは、プログラミング中心思考(指向)と捉えてよろしいでしょうか?

「プログラミング中心思考」とか書くとカッコヨイですね。
「最下層のレイヤがプログラミング思考」や「基底クラスがプログラミング思考」(←ひそかにそんな呼び方をしていた)よりはずっと響きがヨイです。


Tasukuさん。

> 今時、PGとSEを定義付けすること自体、無理がありますよね。
> [情報処理試験]自体が、1種/2種から脱却して久しいのに、
> 営業上は未だにPGとSEの分類なのですから、不思議な業界です。

無理がある、と思っているITエンジニアが大半だと思います。
無理を通したことによる弊害に、業界自体も苦しみ始めてるような気もします。

> 敢えて定義するならば、マネージャ/テクニカル・エンジニア。
> という観点で分けるのが、現実的なのではないでしょうか?

マネージャとSEというのもまた定義がはっきりしないんですよね。
私は予算か人事に関して権力を持ってる人をマネージャと呼んでいますが。

ビガー

一つだけ聞きたいのですが、プログラミング自体に意義を感じられる瞬間はどんなときですか?

現実、様々な利害関係があるので提案が通らないことなど茶飯事でしょうけど、
私の場合は、私が必要と考えている情報を集められるだけ集めて必ずシステム分析を
してからつくるため、理解関係者に納得いただけるモノができる確率が割り合い高いのですが、
それでも使う方はできて当たり前みたいな風潮にガックシするときもありつつも、
使う方がストレスなく使っている姿をみることに意義を感じます。

ひでみ

ひでみです。
ビガーさん。こんにちは。

> プログラミング自体に意義を感じられる瞬間はどんなときですか?

「プログラムが動くこと」ですかねえ。
なんか、それだけのことのような気がします。抽象的すぎますかね。

ユーザーさんが出してくれるお金で食べていけてる者としては、「正確に効率よく動くプログラムをつくることによってユーザーさんにメリットをもたらすこと」で、払うべき「対価」をきっちり払った、という満足感をおぼえます。
設計屋さんのお仕事は「ユーザーさんにメリットをもたらす冴えたやり方」を探すことかと思いますが、それを忠実に具現化できるプログラマでありたいと思っています。

> 使う方はできて当たり前みたいな風潮にガックシする

これだけのことをするのにこっちがどんだけ悩んだのわからせてやりたい! という欲求にかられることはありますよね。
「これくらい簡単だろ」と言われるのもムッときます。何を基準に「簡単」と判断してるんだ! と。

daisuke

SEとPGを明確に区別しているその考えではいい仕事はできませんよ。
プログラミングだけをやりたい、なんていうのは単なるエゴで、
プロの言葉ではないですね。

あと、SEという肩書きの人を見下しているのはよくないです。
あなたも、もしかしたら上から評価されていないかもしれませんよ。

出来る人っていうのは、SEだろうがPGだろうが、すべてできます。
その都度の肩書きが変わるだけです。

あなたのレベルがさらに上がることを願います。

コメントを投稿する