  |
はてなキーワード: デザインパターンとは
平成も最後だし、なんかいつ不況が来るかもわからない状況な気もするし、
今のうちに年収上げておきたいなんて考えている人もいるのかなと思い、
本当に普通な感じで埋もれているエンジニアが転職した時の話をしようと思う。
現在私は同業界の大手企業で働いている。転職結果としては年収も大きく上がったし、
年齢：39歳
＜前職＞
中堅の独立系SI企業（WEBもSierもやってるような感じ）社員600名程度
に所属していた。勤続は7年目
＜技術力＞
技術力はほんとに並の下程度。
JavaとかPHPとかやっていて、PHPがメインだったかな。主にWEBサービスを作ったり、社内WEBシステム作ったりしてた。
プログラミングの基礎はあるし、SQLやその他DBの知識もそれなりにある。サーバーの知識はあんまりないし、
Linuxのコマンドは正直ちょっと苦手だし、AWSとか触ってないし、なんならApacheだってそんなに詳しくない。
ググっていつも解決する。フルスタックエンジニア？なんだそれ？こちらサーバーサイドエンジニアだ、文句あんのか？
新しい技術や言語は基礎があるので飲み込みは早い方だと思う。なので対応力はある方だ。Rubyでもpythonでもコード見れば読めるし、
大抵のことは理解できると思う。でも業務では使ってない。JQureyもまぁ普通に使えるけどJSのコードとかたぶん汚いと思う。
色々と新しい技術をググって記事見たりして「わかった気になるタイプ」だと思う。36歳くらいでやっと「デザインパターン」
知らないとやばいんだ。勉強しないと！と焦って本だけ一応読んで「わかった気」になった。
ここまで読めばわかると思うけどエンジニアとしてはだいぶ「ポンコツ」だ。
でも仕事のためにやってるエンジニアとか結構こういう人が大半な気もするんだよね。
立ち位置は開発リードとか設計とか上流も少しやってた。年齢のせいもあると思うけど、
まぁうまく立ち回って仕事してた感じだと思う。コミュ力はそれなりにある方だと思う。
もうエンジニアとかお前が名乗るなよとか言われそうだな。。。すまん。
このまま、今のポジションで仕事を続けてたら永遠に新しいこととか他の言語を使って業務をすることができそうになかったから。
嘘だ、人間関係だ。ほとほと同僚、後輩、パートナーに愛想が尽きたからだ。それと上司やその上の部長にもだ。
客先で顧客と一緒に仕事をしてたが顧客側の人はほんとにまともで良い人ばっかりだった。転職する時にそれだけ、ちょっと寂しくなったな。
ポンコツながらプロジェクトでは納期を守り何とかやり抜いてきたが、全く評価されない現実もあり、それも嫌だった。あと、給料安い。
表向きはいろんな理由があるだろうけど、転職する人の理由はきっとこれが現実だと思う。
＜概要＞
転職を決意
↓
↓
↓
DODAとリクルート系は良い思い出が一切ないので登録してない。
↓
↓
↓
↓
↓
ビズリーチ経由でB社で金融系ITに強めの転職エージェントに会う
↓
＜詳細と雑感＞
転職しよう！と思ってからとりあず動けーーー！って感じで動いた感じです。
総応募数は覚えてないけど30～50社くらいだったと思う。書類で超落ちる。年齢のせいも大きい。
エン転職のスカウトは全然ダメだった。めぼしい企業がなかったし、年齢のせいか知らんけど、
ギークリーから応募したのが一番多いと思うけど、とにかく手あたり次第に紹介してくる。
よさそうな企業もあったけど、面接まで行ったのは4社程度ですべてお祈りだった。
2次や最終までは行くが、いまいち紹介された企業に自分の志望動機を合わせる作業がどうにも苦手でうまく行かなかった。
ギークリーはほんとに求人が多いから、たくさん見て選びたい人には向いてると思うけど、自分には向いてなかったな。
他にもビズリーチ経由で4社くらい直接カジュアル面談があったけど、有名なY社とか、運輸系のY社のシステム会社とか、
印刷系のD社の子会社とか、どれも最初のカジュアル面談で、それ以後連絡なかったなぁ。
そんな感じで行き詰って2か月。心機一転また別のところ！というのと、
自分でもう一度ポンコツなりに職務経歴書を頑張ってブラッシュアップし、面接対策もして、改めてA社とB社とつながった。
B社からの紹介はとても面白い会社だったし、一次面接もかなり好感触だったのだが、なぜかその後に論文筆記があり、
書いて出したら、落ちた。どうやら思想が合わなかったらしい。
A社から紹介されたのが、医療系のWEBサービスの会社と誰もが知ってる大手企業。
どうやら大手企業とは結構つながりのあるエージェント会社だったみたい。
自分が大手に行けるか半信半疑だったが、面接対策も結構しっかりしてくれて助かった。
同じ質問を面接でされたので、うまく答えることができたと思うし、職務経歴書も一緒に見てくれた。
そして、2か月でこの医療系の会社と大手から内定を頂いた。転職活動は実質4か月くらい。
どちらも良い会社だったので、本当に迷ったが、大手の方にした。
断るのもエージェントがやってくれるのでこれも結構気持ちが楽だった。
＜振り返って思うこと＞
ポンコツなりにアピールできるポイントがあれば、それをしっかりアピールするような職務経歴書を作ったり、
私の場合は3回目の転職だったので、今までの経歴をきちんとよどみなくアピールできるような練習は有効だった。
転職活動初期は全然対策してないこともあって、やっぱり落ちたのかなと思う。
だんだんエンジンがかかって、面接にも慣れていき、最終的に大物ゲットできた感じだ。
そして、面接ではやっぱり自分はできる奴だ！ということをちゃんとアピールした方がいいと思った。
謙遜とかいらないし、こういう職務なんですができますか？と言われても、普通に全然問題ないです。くらいに言ってもいいと思う。
ハイスペックエンジニアとかいやいや十分すごいですわ的なエンジニアは、自分で活動して、普通に交渉もして、
自分がより有利な環境を手に入れることができると思うけど、私のようなポンコツは普通にエージェント使って、
普通に応募して、面接対策しっかりして、志望動機もちゃんと頑張ってたくさん考えて、ちゃんと喋る練習して、それで行けば結構いけると思う。
落ちるのはやっぱり職務経歴書がまだちゃんと練れてないのと、面接の練習や、志望動機が甘いんだと思う。そこを頑張れば良い環境に転職できると思う。
おススメのエージェントとかは特にないかな。自分に合ったものを自分で転職活動しながら、見つけるのが良いと思う。
1つ言うならエージェントを1つに絞らないことかな。忙しくなるけど、いろんな所と付き合って、自分に合うところを見つければいいと思う。
そういう意味ではビズリーチは大小さまざまなエージェント会社があり、そこから連絡がバシバシ来るので登録しておくとよいかもしれないです。
＜まとめ＞
こんな感じだ。読み返すとあんまり参考にならないかもしれない。。。
私は前の会社で全然評価されなかったが、今の大手に移ったら、普通に評価が上がって、給料もしっかり上がった。
環境次第で人の評価って全然変わるし、所詮評価する側のフィルターをかけた評価なんてやっぱり気にしなくていいんだと思った。
実際前職の部長に退職の旨と転職先の話をした時に「子会社ですか？」とか言われたし、「いえ、本体です。」と答えたら「マジで？」という顔をしてた。
部長のフィルターでは自分の評価はそんな感じだったんだなと実感した。
今ももちろん良いフィルターをかけて評価してもらっていると思うけど、自分にとってどっちが良いかは明白だし、
その良いフィルターが本当になるようにもっと努力したいと思う。
今の市況ならほんとに転職すれば年収上がるくらいの状況だし、勤続3～5年以上で、
自分の現状に不満があるなら、いっちょやってみるのも良いかもしれません。
誰かの参考になれば幸いです。
どうやったらプログラミング未経験者を1ヶ月で一人前のJavaプログラマーにできるだろうか？
1ヶ月でJavaをマスターした人がいたら、教材とか順番を教えてください。m(__)m
はてなブックマークでバズってた宣伝を見ると、４ヶ月の研修でRailsエンジニアを育成していた。
研修の成果を3行で
ざっくりスケジュール
4月
5月〜6月
7月
かなり余裕のあるカリキュラムで、OOPの基本を学ぶなら、（静的な型付けがないけど）Rubyはいいよね。
Javaは最初に覚えるべき知識が多過ぎて、初心者の学習用途には向いてないと思う。
PythonやRubyなど、グル―言語のLLでプログラミングの基本を理解する。その後にJavaで肉付けする。という順番が良いと思う。
でも、いきなりJavaの現場に放り込まれたら、そうも言ってられないわけで、無理矢理でも１ヶ月でJavaをマスターするしかない。
この無理ゲーをクリアするためには、教材と順番を工夫するしかないだろう。
どうだろ？
前回はオブジェクト指向プログラミング（OOP）の使いどころを学ぶために、MVCフレームワークを使ってみました。（ほんの触りだけ）
OOPに関する有名な本はたくさんあります。Amazonでレビューの評価が高い本は、定番の本が多いです。
だけど分厚い本は、ある程度プログラミングに慣れてから読んでみないと、最初は意味がチンプンカンプンだと思います。
（最初は意味が分からなくても）なるべく早い時期に1回は読んでみた方が良いと思う本をピックアップしてみます。
この本は、OOPの概要、基礎知識がコンパクトにまとめられています。
この本を１つの目安にして、今後の学習指針を立ててみて下さい。
https://www.shuwasystem.co.jp/products/7980html/4614.html
この本は、OOPも含むプログラム設計のノウハウや原則をまとめて紹介しています。
カタログ的に、各テーマを広く浅く紹介してるだけなので、詳しい内容は個別に掘り下げる必要がありますが、それでも概要を知る上では役立ちます。
今すぐ理解できなくても、「あー、そういえば、そういう話もあったな」と後で思い出せる程度に眺めておくだけでも十分だと思います。
（第3章にある「UNIX哲学」は、初心者にとってプログラミングの良い指針になると思います。）
https://gihyo.jp/book/2016/978-4-7741-8361-9
この本は、上記2冊の内容を具体的な事例で説明しているような本です。
これらの内容はそれぞれが1冊の本になるほどボリュームの多い内容ですが、本書ではそれらのエッセンスをうまくまとめていると思います。
サンプルコードはRubyで説明されていますが、何らかのOOP言語を使ったことがあれば、Rubyの文法を知らなくても、だいたい意味は分かると思います。
プログラミングの入門書を数冊読んだ程度の段階では、上記の本を読んでもいまいちピンと来なくて、意味が理解できないと思われます。
しかし、将来自分がぶち当たるであろう壁、課題を先取りしているつもりになって、「こんなことも考慮してるんだな！」と雰囲気だけでもつかんでもらえればいいんじゃないかと思います。
PHPを使って、OOPの基本的な仕組みを説明をしたので、PHPの入門書を挙げるなら、とりあえずこの１冊。
自分にとっては分かりやすい説明だと思うのですが、類書はたくさんあるので、実際に本屋で確かめてみましょう。
Javaの入門書で文法の基礎を学んだら、次に読んでみたい本。
「デザインパターン」という知識があると、他人が書いたプログラムを読むときに役立つと思います。
（なんでこういう書き方をしてるんだろ？とか、定番の書き方＝パターンがいくつかあるので。）
グチャグチャな汚いコードを綺麗にスッキリさせるノウハウがあります。
リファクタリングに関する知識を学ぶと、プログラムの書き方が改善されて、後で自分がメンテナンスするときに苦労が減ります。
今の段階では、パッと思いついた本はこんなかんじだけど、他にも良い本はいっぱいあります。
自分が分かりやすいと思う説明方法と、他人が分かりやすいと思う説明方法は、必ずしも一致してない場合が多々あります。
図書館や本屋で、実際に本の内容を確かめてみて、自分にとって一番分かりやすいと思える説明の本を探してみてください。
リファレンス（文法の辞書など）は、読む頻度が多ければ、買って損はしない＝元は取れると思うので、自分への投資だと思って、必要な本は買うようにしましょう。
（プログラミングの専門学校とかに行ったら、学費が何十万円もしますね？それを思えば本なら安いものです。）
プログラミングに限らず、他の勉強でも同じだと思いますが、最初は知らないことの連続ですね？
プログラムのサンプルコードを見ても、意味が分からなくて、中身が不明な「ブラックボックス」に見えると思います。
でも、いったん意味が分かるようになると、霧が晴れたように、急激に視界が開けてきます！
学習曲線で言えば、滑らかな右肩上がり（／）ではなく、ある時グイッと変わる階段状（＿l￣）の変化に近いと思います。
なので、最初は分からないことが多く感じても、それが当たり前なので、あまり気にする必要はないです。
理解を早める補助として、上記のような参考書も活用されてみて下さい。
今回までで、手続型言語（構造化プログラミング、オブジェクト指向プログラミング）の基本を知りました。
次回は、問合型言語（SQL）を学び、データベースを使いましょう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書 ←★今ここ★
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
：
ContainerPatternで"Ambassador Pattern"(Googleで直訳すると、大使の紋章..めっちゃかっこいい)というのがある。
https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador
なにが大使やねんというと、サービスAがサービスBに接続するときにサービスA'がサービスAの代わりにしてくれるかららしい。外交官的な。
接続にかかわるもろもろ、回線の監視だとかリトライ処理だとか認証だとかそもそも接続する設定値だとかそういったものを代わりにやってくれるサービスを別途にもうけようぜという仕組みだそうだ。
その仕組みがはまる例として
・異なるプログラミング言語だとかフレームワークのサービスを織り交ぜている
という時だそうだ。
ふむふむとうなづきつつ、アンチパターンの方で躓いた。
一つのプログラミング言語しか使ってない場合はメリット内からクライアントに直接通信用のライブラリ入れろよというのは納得...したんだが、
Consider the possible impact of including generalized features in the proxy.
For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent.
一般的な機能をプロキシに含める影響を考慮してください。例えば、リトライ処理をするとき、全ての処理(注釈: アンバサダー⇒リモートサービスに対する処理)が"冪等"でなければ安全ではないかもしれません。
冪等ってなに？え、リトライ処理でデメリットが生じることがあるの？(ログインの試行回数とか？)
有識者的にはあーっ知ってるよで終わる話(隣の技術者に聞いた感じ)なのかもしれないけどそもそもidempotentの訳を知らなかったので
ググると、"treasure data"の中の人のブログにたどり着いた。
これだよ！！これが俺が知りたかったことなんだ。ありがてぇありがてぇ。
接続しようとしている外部リモートサービスの話で合って、リトライする側のアンバサダーサービスが考える話ではないし、
接続しようとしているサービスに応じてアーキテクチャ設計が変わっちゃうと本末転倒感あるけど、
...はぁ、勉強したー!!
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 85 | 10358 | 121.9 | 73 |
| 01 | 55 | 9637 | 175.2 | 83 |
| 02 | 23 | 1974 | 85.8 | 44 |
| 03 | 12 | 3376 | 281.3 | 87 |
| 04 | 8 | 2076 | 259.5 | 73 |
| 05 | 4 | 188 | 47.0 | 17.5 |
| 06 | 16 | 1002 | 62.6 | 44.5 |
| 07 | 28 | 2941 | 105.0 | 49.5 |
| 08 | 50 | 5085 | 101.7 | 42.5 |
| 09 | 79 | 8225 | 104.1 | 44 |
| 10 | 99 | 9979 | 100.8 | 49 |
| 11 | 105 | 7644 | 72.8 | 43 |
| 12 | 103 | 13260 | 128.7 | 50 |
| 13 | 99 | 8894 | 89.8 | 58 |
| 14 | 58 | 10724 | 184.9 | 54.5 |
| 15 | 97 | 9081 | 93.6 | 56 |
| 16 | 154 | 13124 | 85.2 | 38 |
| 17 | 77 | 5721 | 74.3 | 34 |
| 18 | 83 | 5879 | 70.8 | 44 |
| 19 | 71 | 6843 | 96.4 | 53 |
| 20 | 91 | 8910 | 97.9 | 42 |
| 21 | 122 | 10416 | 85.4 | 37.5 |
| 22 | 138 | 12493 | 90.5 | 45 |
| 23 | 67 | 8714 | 130.1 | 58 |
| 1日 | 1724 | 176544 | 102.4 | 49 |
人(188), 自分(133), 話(93), 今(76), 意味(57), 仕事(57), 問題(55), 前(55), 女(55), 増田(54), 感じ(52), 人間(50), 好き(49), 日本(49), あと(44), 子供(43), 関係(42), 気(40), 社会(39), 普通(38), クレカ(38), 気持ち(37), 結婚(37), 男(37), 結局(36), 必要(36), 時間(36), 頭(35), 理由(35), ー(34), 場合(33), 会社(33), 相手(30), 一番(29), 最近(29), 金(29), 現金(28), しない(28), 無理(27), 他(27), 存在(27), 全く(27), 主張(26), 最初(26), 女性(26), じゃなくて(26), 自体(25), ネット(25), 馬鹿(25), 意見(25), ダメ(25), LGBT(24), 絶対(24), 嫌(24), 人生(23), 全部(23), 否定(23), 勉強(23), 政権(22), 目(22), 毎日(22), 年収(22), 正直(22), 内容(21), 世界(21), 別(21), 結果(21), 大学(21), 当たり前(21), オタク(21), 政治(21), 時代(21), 民主党政権(21), 親(21), 言葉(20), 手(20), いじめ(20), バカ(20), 出て(20), 人たち(20), 誰か(20), 世の中(20), 今日(19), 価値(19), 嫌い(19), 理解(18), 情報(18), 無視(18), 判断(18), 自民党(18), まとも(18), 仕方(18), 日本人(17), 全て(17), レベル(17), ただ(17), 確か(17), 家(17), 他人(17), いや(17), 表現(17), ゲーム(17), 事実(17)
増田(54), 日本(49), クレカ(38), じゃなくて(26), LGBT(24), 民主党政権(21), 自民党(18), 東京(15), 元増田(14), 被害者(14), スマホ(14), 同性婚(13), 飲み会(13), ネトウヨ(12), twitter(12), 可能性(11), ワイ(11), なのか(10), いない(10), 安倍(10), アレ(10), 石破(9), アメリカ(9), 社会的(9), わからん(9), KKO(9), 10万(9), 障がい者(9), ゾーニング(8), ラノベ(8), 民主党(8), ツイッター(8), ブコメ(8), 個人的(8), 自民(8), w(7), 韓国(7), アベノミクス(7), ブクマカ(7), お気持ち(7), 社会人(7), なんの(7), PC(7), キモ(6), カツカレー(6), 鳩山(6), 工作員(6), 非モテ(6), OK(6), アプリ(6), リアル(6), 睡眠時間(6), ブクマ(6), 中国(6), ？？？(6), 基本的(6), 普通に(6), 何度(6), いいんじゃない(6), ありません(5), s(5), SNS(5), なんだろう(5), ja(5), 何回(5), ガチ(5), 毎日(5), hatena(5), 3日(5), 自分たち(5), 就活(5), ツイート(5), あなたに(5), 価値観(5), 昭和(5), マジで(5), Twitter(5), モリカケ(5), 笑(5), NG(5), やな(5), 2ch(5), はてな民(5), 30分(5), いいね(5), ポケモン(5), イケメン(5), 8時間(5), 6時(5), 性的嗜好(5), ニート(5), 経済的(5), …。(5), 生産性(5), 知らんけど(5), リア充(4), 自部(4), キモカネ(4), 1回(4), 支持率(4), YouTube(4), 脳内(4), 野田(4), 暗黒時代(4), DINKS(4), -1(4), 数年(4), 差別主義(4), ネトサポ(4), 日本国憲法(4), FX(4), BGM(4), いつまでも(4), どんだけ(4), 40分(4), 30歳(4), 1人(4), 無料クーポン(4), コレ(4), 日本社会(4), ブックマーク(4), ネット上(4), コミュ力(4), 娘(4), 大企業(4), 生活費(4), 分からん(4), 8時(4), 積極的(4), パワーエリート(4), 夫婦(4), ブログ(4), 涙(4), パヨク(4), な！(4), gt(4), 自己肯定感(4), 自衛隊(4), 海外ドラマ(4), 優先順位(4), 統計データ(4), ダメダメ(4), ジップロック(4), AI(4), はてサ(4), ヘテロ(4), 7時(4), 私たち(4), サイコパス(4), 性的志向(4), TPP(4), LINE(4), キモい(4), 一緒に(4), 消費税(4), である(4), blog(4), 正義(4), 表現の自由(4), 加害者(4), 50代(4), にも(4), 専業主婦(4), 10分(4), 1年(4), 性犯罪(4), 米(4), 発達障害(4)
(3), しゃぶれよ (3), https://www.revive(2), これ、万が一全国ネットのテレビに出て(2), デザインパターン全く身についてないな(2), 島﨑信長 (2), つまり生産性がない (2), 資金力の差だな。 でも、日本の漫画や(2), 返信ありがとう。中退すると大変そうだ(2), はい (2)
■会社の社員がしょぼすぎる /20180921004242(14), ■出雲の阿国、冥土の土産、自由の女神 /20180920162045(13), ■自分をいじめてた人がお笑い芸人になってた /20180918012627(10), ■オタク生活を通して、人を学歴で判断するようになった話 /20180921130154(10), ■政治に興味がない若者です /20180921225703(9), (タイトル不明) /20180921090508(9), ■コミックの目次って意味あんの /20180920223440(8), ■ /20180921202656(7), ■一番理解できないの /20180921162358(6), ■継承って結局いつ使うの？ /20180921182403(6), ■性的消費 /20180921130159(6), ■あざとい語尾が鳥肌立つほど嫌い /20180919133727(6), ■いまのままではやはり同性婚を成立させるのは難しい /20180921120620(5), ■アベノミクスで雇用が増えたのではなく、団塊の世代が定年退職し始めたのと、改正高年齢者雇用安定法によって老人用の求人も出始めたからです /20180921214016(5), ■年収400万以下の男って存在してるの？ /20180921210240(5), ■東京に住む人は早死にすると思うしカリカリしてるのも当然：2 /20180921093437(5), ■35歳なのにまだ夢を追ってる夫が嫌いになってきた /20180919003925(5), ■プライドのない奴が「俺にも」「私にも」と言ってくる /20180921132011(5), ■食材を包丁でトントントントン切るコツを教えて /20180920102434(5), ■東大の友人「受かったときに鼻で笑われたのに絶望した」 /20180920125124(5), ■30歳になってから出し切ったはずなのに小便が漏れるようになった /20180921191850(5), ■余計なお世話 /20180921015930(5)
5635441(2053)
ほぼ愚痴です。
エンジニアなんだけど、ひどい同僚がいる。
酷い点を挙げればキリがない。当人が何も生み出さないだけならまだしも、他のメンバーの生産性まで下げるので、非常に手を焼いている。
インターンなりエントリー/ジュニアレベルであれば教育すれば良いだけなのだが、経験豊富なベテランという触れ込みでやってきてそれなりの給与をもらっているからタチが悪い。
一度もプレーせずに長年プロサッカー選手として生きたブラジルだかのおっさんのように、きっとこれまでも口の上手さであちこち渡り歩いてきたのだろうと推測する。
奴が入ってきて1年ほどになるが、上司は気づいているし、一緒のプロジェクトで働いたことのある他のエンジニアも皆気づいている。クビにするなり何なり手を打つように直談判すべきか。
「プログラマなら当然アニメ見るよね」みたいな論調の人をたまに見かけるけど、特に前置きもなにもなく「今期何見てますか？」みたいに決めつけないでほしい。昔より遥かにアニメは一般的になったとはいえ、みんながみんなアニメをチェックしてるわけじゃないと思う。
非技術者から言われるなら単に「白痴か」って思うだけで済むけど、同じプログラマからだとちょっと不快になる。
別に俺もアニメが嫌いなわけじゃないよ。クレヨンしんちゃんとかたまに見るし。深夜アニメも見たことがないわけじゃないし「こっち来んなアニオタ」などとは思ってないし、幼稚だとも思ってない。
アニメを観てる前提のコンテキストで話されても伝わらないから、プログラマ同士といえども、まずアニメを見てない可能性もあるってことをわかってほしいんだよね。
多くの場合、見てないと言っても「言うほど見てないだけ」と解釈されて、こっちが知ってる前提で話が継続するの悲しすぎる。
本当はもっとこの前勉強したプログラミング言語とかアルゴリズムとか英文法の話とかしたい。
追記
トラバを見て思ったけど、たしかにアニメの問題だけではないような気がする。
相手が英語を読めるかどうかに関わらず英語のサイトを見せたりするし、デザインパターンの知識の有無を確認せずに「Visitorパターンで行けそうですね」みたいな話とかするし、なんにせよ軋轢は生まれてしまうものなのかもしれない。
潔く、バカにされることは受け入れて、普段から「なんですかそれ。わかんない。初めて聞いた。教えて」という白痴モードで接するのが一番いいのかな。
ほとんどの人はもう既に気付いていると思うけど、あえてこの表題に言及している人はあまり多くないんじゃないかと思ったので書く。炎上したら💩なのでここに書く。
結論から言うと、プログラミングを何年やったからプログラミングの能力はこのぐらいと言うことは絶対にできない！
これは何もIT業界だけでなく他の分野でもそうだ。たとえば野球とか絵画とかにも言えることで、ただ年数を重ねればいいってわけではない。勘違いしてほしくないのは、他の業種ではただ年数を重ねればいいといっているわけではない。
コンビニだったら始めはレジ打ちから入るだろうが、だんだん品出し、他者とうまく調整できv、何が売れるか・何が利益率を叩き出すかを把握し、接客態度は絶えず磨き……というように、能動的にスキルを身につけるなければあっという間に「経験した年数」などというものは何の武器にもならないであろう。(「やっても給料変わんない」とかそういうのは抜きにしても）
個人的な経験によるサンプルしか無いが、ぼくの経験上では年数が高ければ高いほどいいと思ったことは全くない。もちろん2ヶ月の新人と5年目の人での比較はなかなか難しいが、情熱ある新人プログラマが半年で5年目を追い越すなどということはありふれた話だ。あたかも大人が小学生や中学生にさらっと数学や英語の能力で負けるように負ける。
残念ながらしっかりした実証などはないので、周りの環境がそうではない場合は納得できないかもしれないが、以下は明らかであろう。
経験年数とは時間であり、重要なのは、時間を代入すると成長度合を求められる関数(ここではFとする)の違いである。（F: time -> ability）
Fの方が大事な理由も明らかだ。timeはケチをつけようとする例外を除けば誰にとっても同じであり、おもしろくもなんともない。
Fの次元が違う場合は、能力の次元も文字通り違う。そのため、かなり重要だ。
「プログラミング歴2年だからこんなことを知っている」と周りから評価されるというのは、要は「プログラミング2年生」だということだ。これははっきり言って侮辱である。2年プログラミングをやったから知っているんじゃなくて、2年の間で勉強したことがたまたま別の箇所で出現したということだ。決して2年やったからではない。2年の間に獲得したスキルがいっぱいあるからだ。2年は重要じゃない。どれだけやったかだ。2年という期間それ自体は全く重要ではない！
「プログラミング歴2年なのにそんなことまでできるのか」というのが真の評価なのだｉ
これはまあまあ高い評価である。「プログラミングを始めてまだ半年なのにそんなことできるのか」という評価はより容易く得られる。年数を重ねれば重ねるほどこの評価に達するのは難しくなる。したがって「プログラミング歴10年なのにそんなことまでできるのか」という評価はほとんど得られない。ほとんどの場合、「10年やってるからできるんだな」とか、ひどい場合「10年やってるのにこんなこともできない」という評価になる。
これもある種、年数というものが全然重要じゃないとみなされている証左であろう。みんな知らず知らずのうちに周囲の人々の経験年数と能力とでおのおの相関図を作り上げて、標準偏差をなんとなく作り出して、「45歳……クソコード……チーン！こいつは偏差値37！落第！死刑！」みたいなことをやってるんだろう。
プログラミングも慣れてくると、特に新しいことを勉強しなくてもなんとなくできるようになってきはじめる。これが危険なシグナルだm
「自分はプログラミング歴が長いのに、HTTPSの仕組みもTCPの仕組みも詳しく知らず、JavaScriptもまともに書けず、WebAssemblyは全く知らないし、RDBのことは知らないし、もちろんRDB以外のDBはちんぷんかんぷんで、デスクトップアプリは作ったことがない、サーバサイドはRailsしか知らない。Railsがどう作られているかも知らない、gitの触りぐらいしか知らない、AWSやGCPは全然使いこなせない、公開鍵暗号方式もよく知らないし、アルゴリズムも簡単なものしかわからない。デザインパターンも勉強してないし、関数型言語もわからないし、C言語も全然読めない、アセンブリはやろうと思ったことすらない、正規表現も複雑なものはいまいちわからないし、機械学習はわからないし、そもそも数学が不安で、AndroidアプリやiOSアプリもまともなものはリリースしたことがなく、エディタは人が作ってくれたプラグインをただインストールするだけで、英語はほとんどできず、セキュリティに関してはザルもいいとこ」
のように自分を見直すべきである。もちろんほとんどの人はそうしているとは思う。そもそも「自分はプログラミング歴が長いのに」という部分はもはや要らないだろう。
あとはただ穿つだけである。能力は、どれだけ、何を、どうやったかとの方と強い相関を持つ。能力とは現在の状態であるのだから、強い相関を持つのは最最もである。
一刻も早く「プログラミング歴」でなんとなくの判定するのをやめて、プログラミング歴1秒の人に対しても、プログラミング歴1000年の人に対しても、そのFを見るようにし、自分はとっとと次元を越えて昇華したいものである。
プログラミング教えてと言われた。
自分のPCにサーバ立ててドメイン通してアクセスしてみて、HTMLとCSSとJavaScriptの概要を教えた。
http://hogehoge.comを叩くとぼくのローカルPC上のHTMLを見ることができるのだ。普通これは感激するはずだ。ヤツは少しも感動しなかったが。
タグのことを教えて、formタグ使ってみて、CSSを教えてセレクタの使い方教えて、なるべくDOMというワードは避けてJavaScriptのイベントの追加のしかたを教えた。
で「あとは色んなタグ覚えるだけ」「CSSで色んな組み合わせやってレイアウトを楽しんでね」「あとは色んなイベント覚えるだけだから」みたいな感じ。色んなイベントを追加してもらった。
その後データベースの話をした。
「まずエクセルのファイルからデータ取ってみよう(実際はCSV)」「あ、でもこれだと取りにくいし時間かかるね」「しかもこれだとデータ矛盾しちゃうしめんどくさいね」「そこでデータベースですよ」
って言って、sqlite3を教えた。エクセルで「これがインサート、これがデリート」って説明しながら、テーブルとレコードとSELECT, INSERT, UPDATE, DELETEを教えた。
ヤツは「なんでそんなわかりきったことをわざわざ文字で入力するんだ」と憤慨していた。こっちが憤慨したい。
で、次はWebフレームワークの話。まずWebフレームワークを使ってもらう前に、URLを叩いたらアプリケーションが走ることを確認してもらう。僕は「すごいでしょ！！」って言う。
さっきのsqlite3とつなげてみて、データを取得して表示してみた。ここで僕、「すごいでしょ！感激するでしょ！！」って言う。「ふーーん」っていう反応。「データをそのまま表示してるんだからそんなの当たり前でしょ？」みたいな。うるせぇWebサービスなんて大体そんなもんだわという言葉を飲み込みつつ、ここまで３時間。
ここで初めてサーバサイドの言語を教える。for-each文、関数までは順調。そしてクラス。クラスは若干詰まっていたのでぼくはまず構造体について説明した。
構造体のことはよくわかるみたいだ。まず青赤緑で構成された色の構造体もどきを作って、画面に色を出力した。ぼくがこの構造体もどきで画面にマリオを描くとヤツは感動していた。
そしてぼくはクラスについて教えた。「この構造体に関数がついてたら便利なときもあるもんだ」って感じ。説明がめんどくさいので「このクラスっていうのが型だよ」とか言っておいた。
「共通でいてほしいものもあるけど、共通でいてほしくないものもある」と言って、ぼくはキャラクタークラスを作ってマリオオブジェクトとクッパオブジェクトを生成し、FFを究極に安っぽくした感じのフィールドで戦わせた。
ヤツは興奮しているようだった。マリオは負けた。ぼくは「人は目に見えるものにしか興味が沸かないんだな」と達観した。
Webフレームワークに戻ってぼくはクラスを使ってView、Model、そしてControllerを教えた。彼はなんだかかなりよくわかった様子だった。ぼくは満足した。
そろそろ５時間になろうとしていたので、ぼくは「あとはデザインパターンと言って、プログラミングしていてよくあるパターンを集めたものがあるんだ」とか「アルゴリズムを知ると色々効率よく書けるよ」とか「非同期処理とかもあるし、とにかく色んなライブラリを試してみて」「他の言語とかも試してみて」とかそんなようなことを言った。
ぼくの仕事は終わった。あとはもうヤツは自分ひとりでなんでもできるだろう。ときどきぼくが質問に答えることもあるだろうけど、ヤツはサーバサイドに必要な大まかな知識を、こんなに短期間で得たのだ。ヤツは優れたエンジニアになるに違いない。ぼくはヤツの家をあとにした。お金ぐらい払ってほしいものだ。
「ごめん、HTMLってなんだっけ……？ていうかファイルってどうやって作るんだっけ……」
ヤツは何も覚えてなかった。俺は発狂した。俺はいったい、何を教えていたんだ。
あと俺、数年勉強しててこれぐらいのことしかわかってなかったのか？そう思って、なんだか猛烈に虚しくなってしまった。
そしてぼくは、二度と人に教えないことを決意した。
その知識を元に、ケーススタディといってビジネスを見て振り返ってというのを繰り返しやるのがＭＢＡだけど、
「生き残ってる」ベンチャー社長で、ある程度まともなのは、経営学、特にマーケッティングの知識を踏まえた行動をやらんと生き残れない。
生き残ったのが社長を続けているから、MBAで学ぶ程度の初歩知識はある。
一方、その最低限のマーケティング意識がないのもいっぱいいるから知識としてはやっぱり持っておかないとならない。
ビジネスが完全にわかる奴というのはまあ、たしかに世の中にはいないかもしれない。
いろんな人はビジネスはこんなもんだ。みたいなのを読んでの積み重ねでしかないんだろうね。
まあ、裏張りや「こんなあくどいことしても儲かるオレすげー、世の中バカwwww」みたいな苛立たせるような成金の書物もあるからそこはみさだめないと。
＞ ここ５，６年の悩みで最近はっきりわかってきたんだけど、俺いつのころからかどうやって勉強していいのかわからなくなった。
＞ 一番大きいのは結婚して子供できて自由な時間が減ったことなんだろうけど、でもそれ以前から勉強ぜんぜんできなくなったの。
お前は俺かってくらいまったく同じ状況。なので最近ずっと「俺ってもっと優秀な人間じゃなかったか」って思って自己分析してるんだけど、ここ数年で一気にスキルセットが変わったのが大きな原因かなと思ってる。デザインパターン、アスペクト指向、UML、プロジェクト管理手法、積み上げてきたものはたくさんあるけど、今はまったく使えない。若者より知識はものすごくあるけど、意味がなくなった知識ばかりなので実質的な比較をするとほぼ対等。アジャイル、クラウド、機械学習・・・新しく出てきて若い世代が中心的に学んできた技術の存在を考えると、おっさんたちはむしろ若者よりマイナスになってしまったわけ。知識の量は若者より多いのに関わらず。
なので、勉強をするときも「若者よりスタート地点がだいぶ低い」という観点で勉強しないとダメだと言う結論に至った。その方法とは、簡単なコンテンツを、大量の時間をかけて大量に吸収する、ということ。
後、子供はもう致命的な。特に休日今までは合計で16時間くらいは勉強に使えていたのが0時間になる。一ヶ月だと64時間くらい消えてるのね。勉強できないってより勉強してない。となると、前述の「大量の時間をかけて」が無理ゲーなので、すでに詰んではいる。
＞ もう俺は嫁さんと一緒にあと２０年近くかけて子供２人育てなあかんからITが好きか嫌いかで仕事選べる立場じゃねーーーの！
「すでに詰んではいる」と書いたとおりなのだが、これもまったくの真実。「技術ができない人」が「大金を得なければならない」。しかもそれは自分のためではなく、家族という他人のため。その行為は悪ではなく、善。
驚くべきことに結婚して子供ができると「能力の低下」と「収入の増加」を同時に満足させなければならない。そのためにできた制度が、おそらく年功序列であり、管理職なのであろう。そして今はその制度が壊滅しつつある。それでもこの矛盾と戦わなければならないので、結局は能力がなくても若者からお金を奪っていく方法を考えて、どんな手段を使ってもそれを実践していかなければ家族（言い換えると次の世代）を守れない、ということになるだろう。
管理職になる他にも、自分の持ってるレガシーな技術を後輩に強制して、自分のレガシーな知識が有効となる土俵に議論を持っていくという手もある。いずれにしてもろくでもない。
IT業界のプログラマなのですが、どれだけ技術が進歩しても何年も同じ開発スタイルから一向に改善しなくて限界を感じています。
例えば次の点が挙げられる
・こいつが手を動かすのは最小限で、なおかつビビりなのでよく確認する
・手だけが早くリリースしてから考えようぜって思っているタイプはバグを出すたびに個人攻撃される
・開発プロセスが雑
・レビューがない
・仕様を最初から作るつもりがなく、毎回担当者が長年の勘で仕様を考える
・故にどこかで矛盾が生じる
・担当者の長年の勘が頼りなので、作り手としては要求に答えるしかない
・一部しか担当していないので、一部しか知らないのだがそれを「もう何年もやっているのに担当したところしかできない」と言われる
・尚、これに対し口答えは許されない模様
・このあたりはOKなのだが、その内容は一切ドキュメント化されていないしするつもりもない
・変更できるのは問題ないが、言い方が「お客さんがバグ報告がきた」みたいな切り出し方
・バグではなくただの仕様だし「作る時にそう言いましたよね？」と言ってもドキュメントがないので根拠なし
・テストを書かない
・というか書き方を知らない
・xUnitすら使えない
・MVCを知らない
・単語は知ってて理解しているつもりなんだけど的外れ（いわゆる Fat Controller が普通だと思っている）
・新しい知識を覚えるつもりがない
・新人が入ってくるもこの調子なので２〜３年もすると社内の仕事はできるが若いのに技術力は10年以上前の技術者レベルになる（仕事に必要なことしか知らないのでそれ以下か）
構造的になっているような、設計が必要なタイプの話は中々議論ができない
できるとしたら、その筋のプロ同士とか、デザインパターンが決まったものについてとか、天才同士とか、そのくらいだ
だから、ブレストから始めると、構造的な問題に対する話が漏れる
結果「みんなで考える」より「ひとりを中心にして設計する」方がうまくいくケースが有る
そして、そういうケースは得てして非常に重要なものだったりする
何かしらの設計に携わる人は、この件について知っていたりするものだが
多くの人は「みんなで知恵を出し合えば解決する」と勘違いしている
そういう風にして手詰まりになるシーンを何度か見たことがある
