僕は最近、
毎日のようにプログラムコードを書いている。
僕はできれば、
プログラムを書くよりも、
システムの設計とか構築をしたいんだけど、
それはあくまで希望であって理想であり、
現実は、
自分の希望を簡単には叶えてくれない。
設計をしていた時期もあったけど、
今の役割はプログラムを組むことなんだ。
ＳＥ（システムエンジニア）とＰＧ（プログラマ）の境界線も微妙というか、
あって無いようなものだと思う。
少し前までは、
ＰＧよりもＳＥの方が格が上（単価が高い）だったけど、
今では明確な境界線が無いに等しいので、
どっちが上なんてことは、
少なくとも現場ではあまり感じない。
まぁ、
大規模開発なんかだと、
きっちりと線引きされてたりもするんだけど。
ＳＥはシステムの設計をする人。
ＰＧはＳＥの設計を元にプログラムを組む人。
本来そのはずなんだけど、
実際、
システムの設計からプログラムを組むところまで１人でやっちゃう人も多い。
じゃあその人はＳＥなのかＰＧなのかって言えば、
曖昧になってしまうのだ。
ただ僕は、
個人的には、
プログラムを組むよりも、
システムの設計をする方が難しいと思っている。
プログラムは組めるけど、
ＳＥ業務は一切ダメって人は結構多い。
ＳＥってのは、
コミュニケーション能力も必要だし。
（ＰＧにコミュニケーション能力が必要無いというわけではなく）
ただ、
そういう人は結構需要がある。
特に大規模開発を行っているような現場。
何故かと言うと、
まず、
システム設計をしない（できない）ので、
単価を安く抑えることができる。
あと、
システム設計ができない（しない）ので、
設計者に文句を言わない。
少々語弊があるかも知れないけど、
僕の感覚です。
「お前達はただ言った通りのものを作ればいいんだ。」
みたいな扱いをされているＰＧは結構いる。
ただそういう人達の中には、
そういう立場を悪く思わない人も多い。
プログラムを組むのが好きな人達だ。
設計なんかやりたくない。
ただプログラムを組んでいたいんだ。
そんな人達。
別に悪いと言っているわけではなく。
スペシャリストな感じで、
職人な感じで、
全然アリだと思います。
僕には無理だけど。
なぜ僕には無理かというと、
僕はそんなにプログラムを組むことが好きではないのだ。
だから早くシステムの設計をする側に回りたいのだけれど、
さっきも書いた通り、
なかなかそう上手くはいかない。
余談だけど、
自らの職業をＳＥと名乗る人は要注意だ。
ＳＥの中には、
何もできない人がいる。
まぁ、
どんな職業でもできない人はいるだろうけど、
ＳＥってのは、
知ってる人じゃないと、
どんな仕事なのかが不明な場合が多いし、
なんかカタカナだし略してるしコンピュータ系だしＩＴ系だったりだしして、
ちょっとできるような雰囲気を醸し出す場合がある。
例えば、
大学を卒業して、
そのままＳＥとして企業に就職した人がいる。
新卒をＳＥとして採用するような企業は、
大抵の場合、
大規模プロジェクトを持ってたりなんかして、
自社のＳＥにはシステム設計や運用側を任せるケースが多い。
このパターンだけでは無いけど、
要は、
プログラムを組めない（組まない）ＳＥというのが、
これがまぁ結構存在するのだ。
プログラムを組めなくても、
ＰＧときちんと連携を取って、
まともなシステム設計・構築を行い、
自社に利益を生み出すのなら何の問題も無い。
問題は、
そのＳＥが仕事のできない人間だった場合だ。
プログラムは組めない。
システムの設計もできない。
だけど僕ＳＥ。
そんな人は意外とたくさんいる。
程度はまちまちだけど。
合コンなんかで、
意気揚々と自分の職業をＳＥだと宣言する人間は危険である。
まぁ、
あくまで僕の感覚ではあるけれど。
ただまぁ、
同じＳＥでも、
ＰＧからステップアップした人の方が、
仕事ができるイメージはある。
それは単純なことで、
プログラムの知識があるということは、
システムで可能なことと不可能なことを自分で判断できるので、
現実に沿った話をクライアントにできるし、
「できること」をＰＧに要求するわけだから、
実際にプログラムを組むのにかかる工数も大きくはブレない。
システム開発にかかる費用（利益）も逆算しやすい。
プログラムコードもＰＧの気持ちも分かるから、
実際にフォローもしやすいし、
そう、
ＳＥがＰＧをフォローするというのは結構大切なことで、
技術面でも精神面でもそれができるというのは、
かなり重要な要素だと思うのさ。
まぁそれでも、
色々と問題は発生するんだけど。
話が大きく逸れてしまったけど、
僕は毎日プログラムを書いてるんだ。
プログラムを書いてると、
よくハマる。
ハマるというのは、
自分の書いたプログラムが上手く動かないということだ。
もしくは、
上手く動かす為の手段が分からなかったり。
それはもう日常茶飯事で、
僕は３日に１回は何かにハマり、
無駄にその一箇所に時間を費やすことになったりする。
まぁ最近は、
ハマりかけてるな、
と感じたら、
そこは後回しにするように気を付けている。
気分を転換させれば、
案外簡単に解決する場合が多いから。
ハマる時は、
意識が一方向にしか向いてないから、
柔軟な考え方ができなくて、
案外簡単な答えを導けない場合がホントに多い。
発想の転換で、
それもホントに一瞬で、
問題が解消されることも日常茶飯事なのだ。
だから後回しにする。
ハマっている自分を楽しむような時間的余裕は無いのだ。
ハマっている時に、
今この瞬間もお金が発生しているのかと思うと、
僕はなんかやりきれなくなる。
本当の問題は、
発想を転換したぐらいじゃ解決しない。
そしてそんな問題は、
設計の段階で間違っていたりする場合が多い。
プログラミングには幾つものルールがある。
それは使用する言語によって、
または動作する環境によって変わったりするんだけど、
そのルールってのも曖昧で、
絶対に守らないといけないルールと、
できれば守るべきルールと、
そんなルール誰が作ったんだ！？
っていうのがある。
まぁ結局は、
「動けばそれでいいのか？」
という問題だ。
僕は思う。
問題なく動けば、
それでいいのだ。
システムの設計書通りに動けばいいのだ。
だってそれが、
プログラムを書く人間の仕事だから。
プログラミングのルールというのは、
思想のようなもので、
確かにこれでも動くけど、
こう書いた方がスマートじゃない？
とかいったレベルだ。
もちろんそれは重要な問題で、
美しいプログラムコードを書いた方が、
メモリの使用量もＣＰＵ使用率も抑えられるし、
システムの実行速度が変わったりもする。
僕も一時期、
美しいプログラムコードを書くことを信念にしていた時期がある。
今となってはそんな思想、
クソ食らえである。
もちろん、
なるべく美しいプログラムコードを書くように心掛けてはいる。
ただ、
やっぱり思った通りにいかないのが現実だ。
プログラム設計の問題もある。
クラスっていう概念があるんだけど、
その使い方にだって美しいと美しくないとがある。
こうすべきだ、
なんてネットにはいっぱい書かれてある。
どれが正しいのかを見極める必要はあるけれど、
理解してさえいれば、
答えは簡単に見付かったりする。
ただ、
それを採用するかどうかは別問題だ。
ルールにガチガチに固められたプログラミングは、
時間がかかるのだ。
ネット上には、
答えが落ちている。
自分の実現したい処理があって、
それを実現するプログラムコードが、
そのまま掲載されていることも多い。
僕は迷わずそれをコピーし、
自分のプログラムの中に貼り付ける。
中にはそれをルール違反だと言う人がいる。
クソ食らえである。
もちろん、
貼り付けた後に少し修正を加える。
そして、
その処理の内容をきちんと理解する。
そこまですれば何も問題は無い。
自分で作れば３０分以上かかるタスクが、
１／３以下で済む場合もある。
だらだらと書いたけど、
結局何が言いたいのかというと、
仕事は、
スピード勝負なのだ。
・設計通りに動く
・バグがない
・使用するコンピュータに損害を与えない
・他の人のために＜ある程度＞見やすいプログラムコードである
上記を守れば、
正直、
なんでもアリだと思っている。
現場では、
こうした方がメモリを消費しなくて済むとか、
こうした方が処理速度が上がるとか、
不毛な議論を熱く交わしているプログラマが結構いるけど、
そんなことは、
休日にファミレスにでも集まってやっていれば良いのだ。
もしくは２ちゃんねるとかそういった掲示板で議論していれば良いことなのだ。
もちろん、
その議論がまったく無駄だと言っている訳ではない。
僕だって興味はあるし、
時間があれば積極的に知識を吸収するし、
余裕があればそれを採用することだってある。
だけど実際、
そのメモリの消費がどうしたというのだ。
その処理速度の向上はどれぐらい求められているのか。
問題は、
実際にそのシステムを使う人がどう思うか、だ。
今の時代、
個人で使用するレベルのＰＣでも、
ある程度の処理であれば問題なくこなすくらいのスペックは兼ね備えている。
クライアントが体感できないレベルのパフォーマンスに関しての議論なら、
はっきり言って時間の無駄だ。
理想というのはある。
なるべく美しいプログラムコードを書く方がいいに決まっている。
だけどそれはプログラマのエゴだと思う。
求められているのは・・・
もちろんその時々によって異なると思う。
例えば、
システムの処理速度向上を最優先にされているなら、
当然、
それに沿ったプログラムを書かないといけないし、
処理速度を上げるための調査や、
時には議論だって必要かも知れない。
ただ一貫して言えるのは、
如何に早く仕事を終わらせることができるかだと思う。
自分の理想を追い求めるが故に、
完成までに時間がかかってしまうのなら、
それは仕事ができない人間だ。
だって、
実際にシステムを使う人は、
その中に書かれたプログラムコードの美しさなんて意識しないんだから。
仕事はお金なのだ。
利益を生み出すのが仕事なのだ。
美しいプログラムは、
休日に趣味で書いていれば良いのだ。
利益に直結しない拘りは現場にはいらない。
あくまで僕の考え方だけど。
僕の理想は、
完璧に美しいプログラムコードを書くことを、
最速でシステムを完成させる術にすることだ。
だけど実際、
そこまでのスキルは無い。
だからと行って、
勤務時間を自分の勉強（スキルアップ）の為に使うわけにはいかない。
常に時間（納期）は決まっていて、
大抵の場合、
それはいつも目前に迫っている。
自社で開発しているわけでは無いので、
長い目で見た利益など求められてはいない。
今、
如何にして納期に間に合わせるかだ。
どんな職業でも、
理想と現実には大きな開きがあると思う。
ちょっと悲しい気もするけど、
世の中、
お金なのだ。
理想を追いかけるなら、
一旦は社会から離脱しないと難しいと思っている。
大人って悲しいなー。
まぁでも、
理想という意味では、
完璧で究極に美しいプログラムコードを書くことよりも、
僕は早く設計側に回りたいんだけどｗ
毎日のようにプログラムコードを書いている。
僕はできれば、
プログラムを書くよりも、
システムの設計とか構築をしたいんだけど、
それはあくまで希望であって理想であり、
現実は、
自分の希望を簡単には叶えてくれない。
設計をしていた時期もあったけど、
今の役割はプログラムを組むことなんだ。
ＳＥ（システムエンジニア）とＰＧ（プログラマ）の境界線も微妙というか、
あって無いようなものだと思う。
少し前までは、
ＰＧよりもＳＥの方が格が上（単価が高い）だったけど、
今では明確な境界線が無いに等しいので、
どっちが上なんてことは、
少なくとも現場ではあまり感じない。
まぁ、
大規模開発なんかだと、
きっちりと線引きされてたりもするんだけど。
ＳＥはシステムの設計をする人。
ＰＧはＳＥの設計を元にプログラムを組む人。
本来そのはずなんだけど、
実際、
システムの設計からプログラムを組むところまで１人でやっちゃう人も多い。
じゃあその人はＳＥなのかＰＧなのかって言えば、
曖昧になってしまうのだ。
ただ僕は、
個人的には、
プログラムを組むよりも、
システムの設計をする方が難しいと思っている。
プログラムは組めるけど、
ＳＥ業務は一切ダメって人は結構多い。
ＳＥってのは、
コミュニケーション能力も必要だし。
（ＰＧにコミュニケーション能力が必要無いというわけではなく）
ただ、
そういう人は結構需要がある。
特に大規模開発を行っているような現場。
何故かと言うと、
まず、
システム設計をしない（できない）ので、
単価を安く抑えることができる。
あと、
システム設計ができない（しない）ので、
設計者に文句を言わない。
少々語弊があるかも知れないけど、
僕の感覚です。
「お前達はただ言った通りのものを作ればいいんだ。」
みたいな扱いをされているＰＧは結構いる。
ただそういう人達の中には、
そういう立場を悪く思わない人も多い。
プログラムを組むのが好きな人達だ。
設計なんかやりたくない。
ただプログラムを組んでいたいんだ。
そんな人達。
別に悪いと言っているわけではなく。
スペシャリストな感じで、
職人な感じで、
全然アリだと思います。
僕には無理だけど。
なぜ僕には無理かというと、
僕はそんなにプログラムを組むことが好きではないのだ。
だから早くシステムの設計をする側に回りたいのだけれど、
さっきも書いた通り、
なかなかそう上手くはいかない。
余談だけど、
自らの職業をＳＥと名乗る人は要注意だ。
ＳＥの中には、
何もできない人がいる。
まぁ、
どんな職業でもできない人はいるだろうけど、
ＳＥってのは、
知ってる人じゃないと、
どんな仕事なのかが不明な場合が多いし、
なんかカタカナだし略してるしコンピュータ系だしＩＴ系だったりだしして、
ちょっとできるような雰囲気を醸し出す場合がある。
例えば、
大学を卒業して、
そのままＳＥとして企業に就職した人がいる。
新卒をＳＥとして採用するような企業は、
大抵の場合、
大規模プロジェクトを持ってたりなんかして、
自社のＳＥにはシステム設計や運用側を任せるケースが多い。
このパターンだけでは無いけど、
要は、
プログラムを組めない（組まない）ＳＥというのが、
これがまぁ結構存在するのだ。
プログラムを組めなくても、
ＰＧときちんと連携を取って、
まともなシステム設計・構築を行い、
自社に利益を生み出すのなら何の問題も無い。
問題は、
そのＳＥが仕事のできない人間だった場合だ。
プログラムは組めない。
システムの設計もできない。
だけど僕ＳＥ。
そんな人は意外とたくさんいる。
程度はまちまちだけど。
合コンなんかで、
意気揚々と自分の職業をＳＥだと宣言する人間は危険である。
まぁ、
あくまで僕の感覚ではあるけれど。
ただまぁ、
同じＳＥでも、
ＰＧからステップアップした人の方が、
仕事ができるイメージはある。
それは単純なことで、
プログラムの知識があるということは、
システムで可能なことと不可能なことを自分で判断できるので、
現実に沿った話をクライアントにできるし、
「できること」をＰＧに要求するわけだから、
実際にプログラムを組むのにかかる工数も大きくはブレない。
システム開発にかかる費用（利益）も逆算しやすい。
プログラムコードもＰＧの気持ちも分かるから、
実際にフォローもしやすいし、
そう、
ＳＥがＰＧをフォローするというのは結構大切なことで、
技術面でも精神面でもそれができるというのは、
かなり重要な要素だと思うのさ。
まぁそれでも、
色々と問題は発生するんだけど。
話が大きく逸れてしまったけど、
僕は毎日プログラムを書いてるんだ。
プログラムを書いてると、
よくハマる。
ハマるというのは、
自分の書いたプログラムが上手く動かないということだ。
もしくは、
上手く動かす為の手段が分からなかったり。
それはもう日常茶飯事で、
僕は３日に１回は何かにハマり、
無駄にその一箇所に時間を費やすことになったりする。
まぁ最近は、
ハマりかけてるな、
と感じたら、
そこは後回しにするように気を付けている。
気分を転換させれば、
案外簡単に解決する場合が多いから。
ハマる時は、
意識が一方向にしか向いてないから、
柔軟な考え方ができなくて、
案外簡単な答えを導けない場合がホントに多い。
発想の転換で、
それもホントに一瞬で、
問題が解消されることも日常茶飯事なのだ。
だから後回しにする。
ハマっている自分を楽しむような時間的余裕は無いのだ。
ハマっている時に、
今この瞬間もお金が発生しているのかと思うと、
僕はなんかやりきれなくなる。
本当の問題は、
発想を転換したぐらいじゃ解決しない。
そしてそんな問題は、
設計の段階で間違っていたりする場合が多い。
プログラミングには幾つものルールがある。
それは使用する言語によって、
または動作する環境によって変わったりするんだけど、
そのルールってのも曖昧で、
絶対に守らないといけないルールと、
できれば守るべきルールと、
そんなルール誰が作ったんだ！？
っていうのがある。
まぁ結局は、
「動けばそれでいいのか？」
という問題だ。
僕は思う。
問題なく動けば、
それでいいのだ。
システムの設計書通りに動けばいいのだ。
だってそれが、
プログラムを書く人間の仕事だから。
プログラミングのルールというのは、
思想のようなもので、
確かにこれでも動くけど、
こう書いた方がスマートじゃない？
とかいったレベルだ。
もちろんそれは重要な問題で、
美しいプログラムコードを書いた方が、
メモリの使用量もＣＰＵ使用率も抑えられるし、
システムの実行速度が変わったりもする。
僕も一時期、
美しいプログラムコードを書くことを信念にしていた時期がある。
今となってはそんな思想、
クソ食らえである。
もちろん、
なるべく美しいプログラムコードを書くように心掛けてはいる。
ただ、
やっぱり思った通りにいかないのが現実だ。
プログラム設計の問題もある。
クラスっていう概念があるんだけど、
その使い方にだって美しいと美しくないとがある。
こうすべきだ、
なんてネットにはいっぱい書かれてある。
どれが正しいのかを見極める必要はあるけれど、
理解してさえいれば、
答えは簡単に見付かったりする。
ただ、
それを採用するかどうかは別問題だ。
ルールにガチガチに固められたプログラミングは、
時間がかかるのだ。
ネット上には、
答えが落ちている。
自分の実現したい処理があって、
それを実現するプログラムコードが、
そのまま掲載されていることも多い。
僕は迷わずそれをコピーし、
自分のプログラムの中に貼り付ける。
中にはそれをルール違反だと言う人がいる。
クソ食らえである。
もちろん、
貼り付けた後に少し修正を加える。
そして、
その処理の内容をきちんと理解する。
そこまですれば何も問題は無い。
自分で作れば３０分以上かかるタスクが、
１／３以下で済む場合もある。
だらだらと書いたけど、
結局何が言いたいのかというと、
仕事は、
スピード勝負なのだ。
・設計通りに動く
・バグがない
・使用するコンピュータに損害を与えない
・他の人のために＜ある程度＞見やすいプログラムコードである
上記を守れば、
正直、
なんでもアリだと思っている。
現場では、
こうした方がメモリを消費しなくて済むとか、
こうした方が処理速度が上がるとか、
不毛な議論を熱く交わしているプログラマが結構いるけど、
そんなことは、
休日にファミレスにでも集まってやっていれば良いのだ。
もしくは２ちゃんねるとかそういった掲示板で議論していれば良いことなのだ。
もちろん、
その議論がまったく無駄だと言っている訳ではない。
僕だって興味はあるし、
時間があれば積極的に知識を吸収するし、
余裕があればそれを採用することだってある。
だけど実際、
そのメモリの消費がどうしたというのだ。
その処理速度の向上はどれぐらい求められているのか。
問題は、
実際にそのシステムを使う人がどう思うか、だ。
今の時代、
個人で使用するレベルのＰＣでも、
ある程度の処理であれば問題なくこなすくらいのスペックは兼ね備えている。
クライアントが体感できないレベルのパフォーマンスに関しての議論なら、
はっきり言って時間の無駄だ。
理想というのはある。
なるべく美しいプログラムコードを書く方がいいに決まっている。
だけどそれはプログラマのエゴだと思う。
求められているのは・・・
もちろんその時々によって異なると思う。
例えば、
システムの処理速度向上を最優先にされているなら、
当然、
それに沿ったプログラムを書かないといけないし、
処理速度を上げるための調査や、
時には議論だって必要かも知れない。
ただ一貫して言えるのは、
如何に早く仕事を終わらせることができるかだと思う。
自分の理想を追い求めるが故に、
完成までに時間がかかってしまうのなら、
それは仕事ができない人間だ。
だって、
実際にシステムを使う人は、
その中に書かれたプログラムコードの美しさなんて意識しないんだから。
仕事はお金なのだ。
利益を生み出すのが仕事なのだ。
美しいプログラムは、
休日に趣味で書いていれば良いのだ。
利益に直結しない拘りは現場にはいらない。
あくまで僕の考え方だけど。
僕の理想は、
完璧に美しいプログラムコードを書くことを、
最速でシステムを完成させる術にすることだ。
だけど実際、
そこまでのスキルは無い。
だからと行って、
勤務時間を自分の勉強（スキルアップ）の為に使うわけにはいかない。
常に時間（納期）は決まっていて、
大抵の場合、
それはいつも目前に迫っている。
自社で開発しているわけでは無いので、
長い目で見た利益など求められてはいない。
今、
如何にして納期に間に合わせるかだ。
どんな職業でも、
理想と現実には大きな開きがあると思う。
ちょっと悲しい気もするけど、
世の中、
お金なのだ。
理想を追いかけるなら、
一旦は社会から離脱しないと難しいと思っている。
大人って悲しいなー。
まぁでも、
理想という意味では、
完璧で究極に美しいプログラムコードを書くことよりも、
僕は早く設計側に回りたいんだけどｗ