  |
はてなキーワード: SEとは
従業員に必要なスキルを、経営者にも同じように必要だと思っている頭の悪い人がいる。
経営者が心優しく従業員が偉そうで無知な場合、そうした事が度々起こる。
ビジネスモデルや価値の創出、事業に於けるグレーな部分のすべての責任を負っている。
にもかかわらず従業員が就職時に企業から求められるような細かい技術的なスキルを経営者に求める人がいる。
大まかに出来るだけででは不服で、専門家並みに細かい事が出来ていなと揚げ足を取ってくる。
例えば、ITの○○のスキルが出来るのか？とか、○○というのは言語など専門用語。例えば、マクロが出来るか？とか、そういう感じ。
他にも、TOEIC800点以上あるのか？とか…。細かい専門性に突っ込んできて揚げ足を取る。
英語能力を売りにして給料をもらっている従業員は、TOEIC900点以上欲しいだろうし、
ITスキルを売りにしてSEならば、ITの知識は欲しいだろうよ。
こんなことも分からない馬鹿大杉。バカと会話すると、本当にストレスが溜まる。
経営者の一番重要なスキルは、顧客が欲しいと思う価値の創出が出来、それを顧客に渡して売り上げを上げれるか？どうか、であって、売っているサービス・商品の専門性だ。
そこに集中しないといけないのに、足りない部分のあら捜しして足を引っ張る頭の悪いバカがいる。
自分が行うべき専門領域の仕事を、他の専門領域の人に求めたり、または他の専門領域の人を馬鹿にして優越意識を感じようとしている人の意味が分からない。
その仕事を、他の専門領域の人が本当にやり始めたら、あなたのいる意味がなくなるでしょう？と思う。
自分をもっと大事にしてほしいのか？自分の価値を分かってほしいのか？
どれだけ難しくて替えが効かず、おろそかに出来ない仕事なのか？説明をすればいい。
このたび転職出来たので書く。
スペックは30歳SE、いわゆるメー子で、その地方では一番売上高いSIerである。
再就職先を支援するため、一定の条件のもと転職活動を仕事として認める制度である。
ウチの場合は退職者が多いのか、サビ残に対する贖罪か、その制度が常設されている。
SEに戻ることは出来ない（戻る事の出来る企業もあるらしい）。
大卒3年目並の給料をベースに残業なし、時短勤務なので給料8/9、寮に入寮(独身の場合)、
転職支援会社に出社すると、就業時間把握のため、いつもと同じようにタイムカードを押す。
転職サイトから応募、エージェントを利用し非公開求人に応募、ハローワークから応募など
別に転職支援会社から求人を案内してもらうわけでもなく自分から動かないといけない。
とりあえず、SI業界で言えることはメー子以上であればこれに近い制度があるかもなので、
転職したい人は総務に聞いてみてはどうだろうか。ウチもそうだが、基本的に開示はしていないはず。
このたび転職する事が出来ました。
このぐらいの会社規模になると、非公開求人から書類を応募する際には、
Wordで作った職務経歴書オンリーで大丈夫とエージェントに言われる。(手書き履歴書・職務経歴書がいらない)
非公開求人だと筆記試験なしの企業もあり、転職はとても楽だった。
（エージェントは希望条件にマッチしないとメールでお祈りされる…
マイナビはお祈りされ、リクナビ、DODAは親身にしてくれた）
まぁ俺は言ったけど、言わなくていいとエン転職に書いてある。普通、リストラにあったと思われるとのこと。
この会社は嫌いだったけど、職歴が役に立ったという点では有難い。
初めは勤務地なんてどうでも良いのででかいとこに行くべきだね。
今のままで大丈夫か？と思っている方は一度間接部門の誰かに相談してみてはどうだろうか。
集中して転職活動して、自分のとこより良いとこないなと思うのも良し。
実際、条件が悪いが、今後の伸びに期待出来る企業に俺は就職した。
たくさんのシステムがある中、保守する人が大規模案件に連れて行かれいつの間にか担当システムが増えている。
それはいいんだけどさ、1回も触ったこと無い、障害対応もしたこと無いシステムのメンテ費用見積もれって言われてもわからんよ。。。
まず業務がよくわからん。いや、業務は何とか理解しようと努めているけど、メインフレーム上で山のようにバッチ処理があるって時点で体が拒否反応起こしちゃう。
プロセス見てもいろんなところからデータ引っ張ってきてるし、いろんなデータ吐き出してるし、途中でワケワカメになって最後まで辿り着けない。
機能全体通して検証するって言われても、どんなデータが必要でどういう順番で処理してなんか把握しきれないし。
それでも考えて前任者に確認して、「いいんじゃない？」ってなって一度は見積もり提出したけど、今日見てたらちょっと違うんじゃ？ってところ出てくるし。
明日は協力会社さんに説明するんだぜ。説明ってか相談だな。開発時のメンバーだって言うし。
もうこりゃ任せっるきゃない。何とかなる、いや、何とかしてくれ！
あーもーやだなー。なんでこんなに後ろ向きな気持ちなんだろう。
仕事やめる？
できないよねー。
でも仕事イヤだなー。
ニートから機械語の書き方を勉強してプログラマやSEに、みたいのはそれなりに現実味のあるルートとして話されることが多いけど、
今の「プログラマ」や「SE」ってのは一昔前のただの事務職と同レベルなんだよ。
「機械語勉強して」とか言うけど、実際にはそいつらが勉強したことなんてまったく意味ない。
別にんな勉強しなくても（まあ、キーボードの打ち方すら知らなかったらどうしようもないが）
出来る仕事が沢山あるわけで。
世の中の「プログラマ」や「SE]って言ってる人の殆どはそのレベル。
そういう誰でも良い底辺仕事だからニートがまず始めるには当たり前過ぎる仕事なだけ。
PGは、まず見積もりを依頼されます。この時ほとんどの場合、要求仕様書が無いか、あっても伝聞で情報が欠落もしくはエラーを起こしています。残念ながらエラー訂正機構は装備されていません。CRC、せめてパリティでも入っていればちょっとは違うかもしれません。期待出来ませんが。
ここでプロジェクトマネージャー（又は管理者・経営者等。以後PMと称する）から「最速でやった場合」「割り込みが入らない場合」「君がやった場合」or「部署内で最高ランクのPGがやった場合」「仕様変更が無い場合」という条件が付きます。
底辺PG諸君。ここでこの言葉を額面通りに受け取ってはいけません。
「【最速で】3ヶ月かかります」
と答えたらPMは【普通に】3ヶ月の工程を工程表に書き、見積書に3人月分の金額を書きます。そしてこれは後述する危険と隣り合わせとなります。
この危険を経験したPGは大抵リスクを込みで【黙って】見積もりを伝えます。
しかしPMはお見通しです。「高い」「そんなに時間がかかるわけが無い」と言い、受け付けません。何故なら実はPMの頭の中では既に「3ヶ月」なのです。PMは追い込むために見積もりの詳細を聞いてきます。
ここで素直に「リスク込み」と答えてはいけません。既にPMは前述の前提条件を述べているからです。無下に却下されます。
戦いたいPGかつPMが同じ会社であれば「後学のためにPMの詳細見積もりをお聞かせ下さい」と聞いてみるのも良いでしょう。ただし確実に印象悪化は避けられません。PMが発注元の場合は禁句です。まずキレます。そのまま発注されない事もあるでしょう。発注されなかった事を喜びましょう。
なぜキレるか。それは簡単です。「明確で論理的な理由が無いから」です。理由が無い上に実は既に予算が決まっており、それを超える事は許されません。予算を超えた見積もりはPMがさらに上層部・経営陣から怒られる事を意味するからです。理由が無いから理由をPGに考えさせているのです。PMが仕事をした気にさせるのも底辺PGの役目です。
予算を超えた見積もりはあり得ませんので、答えは「がんばります」しか残りません。しかしPMはそれすらもPGの口から言わせたいのです。でもよく考えて下さい。あなたの脳はオーバークロック出来ますか？
底辺PGが出来る事は、PMやユーザーが分からないように期間と予算を加算するくらいです。
一応、市場原理が働くため、安い方がいいに決まっています。金払いのいいユーザーや元請けってのはあんまり無いです。そして金払いの悪い所ほど後々してやられますので、最初の予算の付け方でどういう所かが大体予測出来ます。
そんなわけで、予算と期間に品質と内容は関わりがありません。もちろん企業の使命として、安くて良い品を、安くても利益を、は追求してしかるべきなのですが、日本の場合質と金額が比例するのは極一部。IT業では基本的に、安くて良い品を出来るだけ高速に、がモットーです。受注しなければ会社がやっていけないのは分かりますが、「安さ」だけしか売り物に出来ない会社は、IT会社として失格でしょう。
かくして、短納期低予算のプロジェクトが組まれるわけです。そのPMの理論からすると、高速バスで東京から新大阪へ行く方が、新幹線のぞみの指定席グリーン車で行くより高く、書留速達の郵便より普通郵便の方が値段が高い、という事になりますが。質、時間、価格の何がIT業と違うんでしょうか。
実のところ発注や作業開始は遅れている事が多く、納期に間に合わせるには発注前に作業を開始せざるを得ない場合が8割ほどです。実はここにも罠が仕掛けられています。
作業に取りかかろうとようやく出てきた仕様書を見ると、見積もり時の時と変わっていたり、追加されていたり、未だに仕様が無い場合がほとんどです。
「こんなものをこんな期間で出来やしない！」と憤慨してはいけません。なぜなら
という答えが返ってくるだけです。PMが見積もらない理由がここです。PMに見積もりを聞いてはいけない理由がここです。これは後々まで効いてきますので注意が必要です。「前提条件と違う」と反論するのは無駄です。PMはそれは忘れています。そもそも考えて発言していないので口が勝手に脊髄反射で言った事であり脳は関知していないのかもしれません。PMにとって最重要な事は「PG自身が言った事」です。そう、工程表にも議事録にも「3ヶ月」という数字のみが記載され、いわゆる「リスク」は何処にも書かれて残っていません。
PMやユーザーは絶対にリスクや前提条件を書き残しません。それがこの業界の伝統ある慣習だからです。
ここで言った言わないの不毛な戦いをしてもいいのですが、確実に査定は最低です。もしプロジェクトから外されたらそれは喜びましょう。
管理者や経営陣等からは「やる前に出来ない言うな。やってから言え」と怒られます。残念ながらこれも真に受けてはいけません。
設計、構築など作業をしている間もどんどん仕様変更・追加は流れ込みます。
PMは工程進捗を把握しているのでは無く、PGが【自ら】工程表や報告書に纏めます。遅延していれば遅延の理由も書き、挽回策があればそれも書きます。しかしPG個人が取れる挽回策などたかがしれています。と言うよりそれが分かっていれば遅延などしません。他の策は既に実行済みなので、挽回策には「残業・休日出勤」くらいしか書く事が残りません。しかしこれは現実にこれしか書く必要がありません。なぜならPMはこれ以外の挽回策は理解不能だからです。
仮に報告をしても「早すぎる。もっとやってみてから」「がんばれ」という答えが返ってくる事でしょう。
遅れを放置するPMもいますが、許容範囲はPMにもよりますがある程度遅れが見えてくるとPMから追求がやってくるようになります。
「なぜこんなになるまで報告しなかった」
そう、報告出来る時期というのは非常に限られています。多分プロジェクト工程（今の例なら3ヶ月）の中の30分くらいです。それより早いと相手にされず、それよりも遅いと怒られます。報告時期を見誤らないのもPG業の技です。
実装が難しかったり、無理難題は多々あり、その上工程が遅延しているので、相談をしに行きます。しかし、それは無駄です。
「自分で考えろ」
「やってから言ってるんじゃねぇ。やる前に言え」
他似たような答えしか返ってきません。非常に非生産的です。理不尽です。時間の無駄と考え報告・相談に行かないPGも多いとか。非生産的ですが、一応相談はしておきましょう。ただし時間は取られないように。
同僚やチーム員に相談してもいいのですが、昨今のプロジェクトは人員がスタンドアロンで動いています。したがって、隣の人やチーム員がが何をやっているのか知らない事が非常に多く、相談出来ない事も多いのです。PGにメンタル病が多いのは実は理由がここにあると自分は思っています。孤立感が半端無いのです。まぁ、元を追えば、そいういうチームを組む事、教育訓練しない事など、実は管理者・経営者が「カイゼン」や「効率向上」を題目に目の前の超短期的コスト削減だけを考えている結果なので、PGとしては何も出来る事はありません。管理者・経営者は中長期について考える必要が無いからです。なぜなら「その頃には自分は満額の退職金を貰って定年退職済み」だから。
実のところ単独の仕事をしていればいい、と言う事はあり得ません。同じプロジェクトの中からも割り込みや、他のプロジェクト・部からも割り込みは多々入ります。
始めに言ったじゃん。どうにかして。というのは無駄です。覚えてないし、「会社員なら当たり前だ」という答えが返ってくるだけです。「15分だけ」「ちょっとだけ」が頻発しますが、塵も積もればなんとやら、です。ちなみにこの件は査定・人事評価には全く影響がありません。
相談すれば「午前中はこの仕事、午後はこの仕事、定時後はこの仕事をすれば並列同時が可能だ」とあたかも新発見超名案を出したかのように返されるのが落ちです。そう、1日が24時間しかない事は忘れ去られ、PGが人間である事は忘れ去られ、思考の分断は効率を激しく低下させる事を知らないのです。
ここで断る勇気を持つのが大事ですが、職場内の雰囲気は格段に悪化します。評価は「人でなし」「自分勝手」「自分本位」「冷たい」。これらの視線に耐えられるのなら断りましょう。こちらからすれば「自分の時間を奪う方がよっぽど人でなしだ」と言い返したい気分です。
テスト工程も始まり、遅延が激しくなる上に、バグが発見されさらに遅延という状況が始まります。
ソフトウェアである以上、バグが無いプログラムなんてのはあり得ないのでバグを出す事自体は不可避です。
ところがPMは激しく怒り出します。バグの発見はPMに一報が行きPMが怒られるからです。
底辺PGはバグを出す毎にこっぴどく怒られます。中には仕様変更の事実がPGまで伝わっていないのにバグ扱いされる事も多々あります。
バグを出すと修正、テスト、再発防止策の考案などの厄介事が増えます。
再発防止策は通常「どうやったら自動的にそうならないか」を考えますが、あまりに根幹すぎるので、底辺PGの身分では権限が無く、出来る事が限られます。そしてPMが理解出来る策を考えねばなりません。結果「テストを増やす」「チェックシートを作る」とかになりがちです。しまいには「チェックシートのチェックシートを作る」などという意味不明の現象に陥ったプロジェクトを何度も見ています。
厳しく、それは厳しく怒られる上に、チームの前でさらし者にされる事、人格を否定される事も多々あるので、PGはバグを出さないように、見つけても出来るだけ極秘裏に解決しようとします。
「恐怖駆動型開発」
というもので、日本の場合ほとんどがこの開発手法をとられていると聞きます。この開発手法は書籍になっておらず、書籍としてよく売られているのはアジャイルな開発手法の本が多いです。知識として持っているのはいいと思いますが、役に立たないと思いますねぇ、恐怖駆動型開発の前には。まわりの人間も恐怖に巻き込まれないようにするため、どんどんスタンドアロン化が加速します。
その上、バグを隠すようになり、バグが出るようなテストを避けるようになるため、短期的に収束しているようにみえます。だから効果絶大と見るようです。リリースしてからが楽しみですね。
PMが空想から覚め、もう救いようが無くなった事が事実と認識出来るようになった時、ようやく、2度目の相談・報告時期が訪れます。ただし、PMの第1声は「どうしたらいい？」です。そんな事が分かっているのなら実行済みなので、黙っているしかありません。
するとPMは「何人入れれば良い？」と聞いてきます。意味が分かりません。IT業を労働集約型産業と勘違いしているのが未だに存在している事に驚きです。頭脳集約型の形態に人を入れて解決しようとはどういう脳をしているのか。一度解剖してみたいものです。多分、高校を受験する中学3年生の受験者が100人集まれば旧帝大の入試に合格すると考えているのでしょう。もしくは1Km走というのは1000人が一斉に1m踏み出せば1Km走った事と同じ記録である、と考えているのでしょう。
脳を電通で直結出来れば若干違うかもしれませんが、IT業の1＋1は2では無く、良くて1.5。ましてやこれで増えていくのは3～4人までが限界でそれ以上は人を入れても上がらないどころか、マイナスになる事が常。
PGなら他のプロジェクト、他の部、他の会社に信頼出来るエース級のPGを何人か知っているかと思います。なのでついPMに「エース級を3人」等と提案しがちです。しかしこれは叶わぬ望みです。その提案に対する答えは「そんな事出来るわけないだろ」です。そりゃそうです。予算が無いのだから。
自分の仕事があるのに、何故かこの後から来た人員を纏めるようPMから指示が出ます。PMが指示出来ないからです。破綻は間近です。いや、既に破綻しています。
プログラムが出来上がっていく以上、バグをつぶす速度以上の割合でバグを注入していく事になります。
「混乱しているプロジェクトに人を入れれば、なお混乱するだけ」
という有名な文を実感する事でしょう。なお、実感するのはPGだけであり、PMは実感出来ません。
この辺で思わぬ事態が発覚します。実は発注が遅れていた事です。
発注日以前にドキュメントがあっては監査にひっかかるため、今まで作ったドキュメントを作り直しをしなければならないという、まさに想定外の事態です。ほとんどのドキュメントには作った日付や判子が押されているはずです。それを全部作り直しするのです。納期は間際です。これも納期までに間に合わさねばなりません。
PM（重ねて書くが、プロジェクトマネージャだけでなく管理者や経営者も含む）が発狂し始めます。宛先は底辺PGです。
中には「お前を精神的に追い詰めるしか手がねーんだよ」とストレートに言ってくれるPMもいたりしますが、あまり出会った事は無いですね。
あの手この手で精神的圧迫を始めます。圧迫すれば脳がオーバークロックして作業が進むと考えているからです。残念な事に、脳の別の部位がオーバークロックしてショートしてしまいます。
こういうプロジェクトを経験し、運がいいのか実力なのか、生き残った人達がSEとなり、いずれPMとなっていきます。
不思議な事に日本では、PGが成長してSEに、SEが成長してPMに、とクラスチェンジするものだと考えられている会社が多のですが。
自分としては、座標軸のX,Y,Z軸の様にPG軸とSE軸とPM軸と全く異なるベクトルだと考えています。X軸の先にY軸Z軸があるわけでは無い、と。もちろん、軸に沿っているだけでは無く、他の軸のベクトルも併せ持つのもよいエンジニアでしょうし、ベクトルの方向を伸ばし続けるのもよいエンジニアでしょう。
ところが、クラスチェンジするものだと管理者・経営者は思っているから、給与体系もPG＜SE＜PMとなっていたりします。この時代錯誤的階級社会はどうにかならないものでしょうか。
自分はPMを否定しているわけではありません。いいPMの元でいい仕事をしたい、と思っているだけです。今までに何度かそういう良い経験をした事はあります。それは成功経験としてモチベーションを保つために必要な事なのです。
PG至上主義でもありません。分業形態として、SEやPMは必要不可欠だと思っています。ただ、PGを粗末に扱っておきながら高品質の製品を要求する風習・慣習が納得出来ないだけなのです。
情報処理だけじゃなくて、JavaとかPHPとかオブジェクト指向とかWebプログラミングとか細かく細分化して、このプロジェクトはC#認定試験とWindows認定試験をもってるプログラマしか採用しませんとか。
ペーパーテストで分かるのかって言われるかもしれんけど、今の経験年数で測るやり方に比べたら格段にマシになると思うわ。
経験年数10年だから技術力があるってことになっているけど、実際は初心者レベルだとかゴロゴロいるし。
Javaの入門書さえまとに読んだことないだろってレベルの人が飲み会で「Javaに関しては任せられる新人が育ってなくてね」とかドヤ顔で語っていて、サラリーマンだから形だけ顔を立てられるって認識でなくて本人もマジで技術力あるつもりなのかってビックリしたことあるわ。
で、そういう人がプロジェクトの技術的な方針を決めてるから、本当にぐちゃぐちゃで効率悪い。
プロジェクトに応じた各種認定試験に通ってないと、コーディングさせないとか設計させないとかっていうのが常識になったら、最低でも水準に達してないような人がプロジェクトにかかわることは避けられるからね。
まあこれやると、日本のプログラマやSEの60万人のうち、3割とかへたすると半分くらいは仕事できなくなっちゃうんじゃないかって気がするから、実行は無理だろうけど。
このまえJavascriptをコピペだけで10年やっていて初めてまともに勉強したってエントリが何百もブクマを集めてるのをみて、モヤモヤっと思ったから書いた。
自治体での仕事がどんなものか知らないが、そもそもなんでWindowsServerを使ってたのだろう？Exchangeかな？
もしExchangeを使いたいって理由だけでWindowsServerを使っていたのならば、金を捨てていると思う。なぜなら私は元「省」でのインフラを構築・運用をしていた経験があるからだ。
そもそもExchange含めグループウェアを使いこなせている企業は少ない、グループウェアを使うにはITスキルの必要性もあるが、根付かせる風土を構築する必要があると思う。
そのためにはそれなりのコンサルティング料金が必要だと思っているが、その必要性を理解してもらうには至らなかった。
官公庁では上が入れているシステムが絶対なのだ、予算も通りやすいのだろう。
そもそも官公庁のシステム担当者は知識が無さ過ぎて「サーバ」「サーバ内のソフトウェア」「クライアントのソフトウェア」を理解してくれないケースが多く見られる。
そもそもなぜ自治体ではIT関連の専門職を雇用しないのだろう？
自治体は事務職が多く、それなりの規模の仕事をしているのだから元IT出身での中途採用をすればかなりの人員削減ができると思う。
日本ではこれだけSEが薄給で酷使されているのだから、インフラ構築もできてVBA程度でもプログラミングができる人間を既存事務職と同等の給与で雇用するのもたやすいのに。
なぜライジングサンコーポレーションのSEってのはプログラマーに対して、仕様書に書いていない事をやらせるのか？
仕様書に記載していなかった事を作りこんでいなかったら、不具合扱いされた。
いや、書いてある事を実現出来なかったらそれは不具合と認めるよ。
「書いていない」というと「常識だろ」と言われる。あんたらの製品の常識かもしれないが、こっちには常識では無い。
ましてや、全てを底辺プログラマーのせいにして、なんとかという精神的追い詰め会議に呼び出すのはどういう事か？？？
それでも、「書いてくれ」と言い続けると、「全てを網羅出来ない」と開き直る精神がすごい。
なら「こちらも全てのエラー処理例外処理等を網羅出来ない」と言い返すのはタブーである。ここまで言うと、ライジングサンコーポレーションのエライ人達はキレる。
品質向上プロジェクトとかあるようだが、プログラマーをいびる事で品質が上がると思っていたら大間違いだ。
君たちのその開き直りを直す方が先ではないかね？
俺がリーダーになってから試しに導入してみたルールのおかげでチームの生産性が３倍になった。
誇らしいことだが、果たして一般的に有効な方法なのかどうか気になるので広く反応を集めたいと思って書く。
そのルールというのは単純、「一日に５時間以上コードを書かない」というものだ。
勤務時間の８時間のうち、本当に仕事をするのは５時間だけに制限する。
これで生産性は３倍になった。
社長はモーレツに仕事をする人で、社員にも同じようにモーレツに働くことを求めていたが、俺は同調しなかった。
それ以上の時間を使っても、単位時間あたりの生産性は下がるばかりだ。
ならいっそ、残りの時間は最高のパフォーマンスを発揮できる５時間を生み出すために使うことにした。
より具体的な働き方としてはこのようになる。
まず朝９時に出社すると、それから１時間は会議室でだべって過ごす。
もちろん、話の内容は最近の技術動向だとか、新しいアルゴリズムだとかの話が多いが、
プリッツをポッキーに変換するにはどうしたらいいか？ といったバカな議論に白熱したりもする。
全員が音も聞こえなくなるほど集中する。
昼休みを１時間取って、午後１時から３時までは午前中のコーディングの成果と新たに発見した問題点などについて話し合う。
午後６時になったら仕事は終わりだが、大抵の奴らは「残業」していく。
新しい技術の習得のために技術書を読んだり、数学の本を読んだりする。
これで従来の３倍の生産性が上がっている。
コードの品質は良くなりチームは常に最新の技術動向を掴んでおり、問題解決能力が向上した。
思うに一日の労働は５時間、後の時間は自分への投資のための時間であるべきだ。
自分をすり減らすというのは、未来の自分を損なうという意味だ。
局所最適に陥るということだ。
クリエイティブとは、こういうことだと思うね。
世の中のSEとかプログラマーって言われてる人って、やってる本人たちも勘違いしてるけど、
ほとんどが単に用意されたパーツを組み立てるだけの工場のライン作業みたいなもんだぜ？
勉強って、その会社で使われてるモジュールが何が何であるかある程度覚えるだけ。
(覚えるたって別に暗記して試験やるわけではないしその場で調べりゃすぐ出てくるから覚えることなんて無い。やってりゃ覚えるだけ)
その辺おぼえなきゃーとかいうことで勉強、とか言ってるとアホか、と言いたくなるだけ。
勉強ったって最初の道具を使える様になるとかその程度。そもそもそれを全く大学までにやってないのにそこへ就職したことがおかしいだけ、ってレベルの「勉強」のことを言ってることが多いから。
お前が何「勉強」してるのかしら無いけど、上みたいなただのライン工が、
パソコン先生になっちゃった感じでハッカソンだの勉強会だの行きだすけど、
そもそも何学んで良いのか分かってないからただ行きまくるだけ。
それを仕事に返すこともまずない。(ってか返せる場なんて無い)
そういうのが「イシキタカイケイ」なわけで、そりゃキモイだろ。
「世の中なめんな、どの業種でも勉強してるわ」
これが嘘だし、SEやプログラマも大して勉強なんかしてないのが普通なのでどっちもどっち。
受託開発やSIer、そこで採られる人月での見積と契約はスタートアップ・Web系・ベンチャーな方々から軽蔑されがちです。
けれど社会のインフラや企業の基幹を担うこともある重要なシステムでは残念ながらこれらの手法をとらざるを得ないのが現状となっています。
これを打破するイノベイティブでエポックメイキングでパラダイムシフトな変革は期待されていますが、文化や慣習、人手不足とレガシーコードはなかなかそれを許してくれません。やり玉にされがちなSIerのスタンスだけに帰せる問題ではないのです。
そんな状況でもわれわれSEは社会の繁栄のために、愛する（現在の/未来の）家族のために、そしてご飯を食べていくために働く必要があります。
しかし、この業界で難しいのは流動性が高い割にキャリア形成が難しいこと、自分の精神的・肉体的な健康を損ないやすいという問題があることで、苦労されている方も多いかと思います。
そして働く人が多いにもかかわらず、会社・システム・プロジェクト固有の用語や知識が多いことやセキュリティポリシーに抵触するか微妙なこともあってかなかなかノウハウや知見が共有されていないように感じています。一方で個々のプロジェクトに埋没している問題が共有されていないことへの懸念もあります。
今回は、これを打破するためにアドベントカレンダという不思議文化に乗ってみなさまがこれまで得てきたノウハウをドキュメント化していただけないかというご提案になります。ノウハウの共有は日本のソフトウェア開発文化の発展に、問題の共有は社会（発注企業・元請け上層部含む）への啓発につながればと期待しており、なにより自分がみなさまの環境に興味を持っています。
ぜひ、書いてみませんか？
トラックバック・ブクマを送っていただければここにリンクを貼っていきます。増田でも可ですし、重複・フライングも気にしません。
