ちょっと見かけたこちらの記事、まあ結局ケースバイケースなんだよなあ…って思うのでサンプルケースとして自分の感想かいておこうかなと。こういうのポエムって言うらしいですね。感想なんで元記事の本題からずれてるかもしれんが気にしない。
ただ 「縁を切れ」と言われたら「おっそうだな」としか思わない からまあリムブロしといてくれればいいなとは思います。そのほうがお互い平和に生きていける。
目次
(ちょっと追記)おそらく「エンジニア向け」の記事じゃない
スクールの活動内容や対象をみてると、対象にしてる客層は 「エンジニアとまでいかないけどプログラミングを学びたい人」向けなんだろうなと思いました。
それはそれで良いのですが…そうすると、こういう形で炎上するのは 「正論言ったらいけ好かない老害エンジニアがわめきだした！」 みたいに映ってるんだろうかなあとも。
ガチで数学必要になる仕事とか、サーバートラブルに緊急対応する仕事とかは本当の専門領域になるとは思いますが、逆にいえば専門でなければそこまで要らないもの事実で、ちょっと業務改善したいとかそういうところだったら要らないですしね。
逆に、「プログラミングを仕事にしてないけどちょっとやってみたい人」からすると、エンジニアの態度に思うところとかもあるんだろうなとは。(これはエンジニア云々ではなく、すべての職業と専門外の人の関係性だとは思いますけど)
狙ってそうなったかはわからんけど、そういうところに届く炎上商法になってるかなあと。ターゲット層にノーダメージだし見事な施策ですね。
だからまあ…うちの記事はすっかり話題ずれてるし取り下げはしないけど、反発するだけ思うつぼ感はあるね…
※ただ無駄に数学押し付けてきたり、意味もなくイチからサーバー作ってデータセンターに置こうとするようなのは普通に仕事としてご遠慮いただく気持ちです。「〜すればよいのでは」についてはシチュエーション次第なんだよなあ。
プログラミングはもちろんエンジニアの専売特許ではないし、むしろこれからパソコンみたく普通に使っていく技能になるかもしれないとは思うから、スクールの対象や方向性は良いように思えただけに残念でした。
「 数学を勉強しろ！」はどこまで？
数学知識をどこまで使うかは正直業種によるでしょう。としか。
記事だと「プログラミングに必要な数学知識は中２レベル」とありますね。連立方程式、一次関数、確率が含まれているようなので確かにこのあたりくらいかなとは。
個人的に仕事でやっている部分を振り返ると、 四則演算 は使うと思います。 更にハードルが下がった。
あと 確率 もたまに話に出てくるかな…
ただプログラム自体が数式の塊ともとれるし、関数 や 代入 なんかは日常的に使ってると言えるかも。
ゲーム・3D表現だとどうだろう
完全に門外漢なんで違ったらごめんって話はしとく。
昔はゲームつくるとき行列とかベクトル演算とか必須だったと思うのだけど今はUnityでぐりぐり回せちゃう からなあ…
衝突判定も コリジョンつけたら終わり だしなあ…
シェーダー書き始めたりしたら必要になってくるのかな…？
機械学習だとどうだろう
これも門外漢なんですが、ライブラリ使えば動くことは動くんだけど どう使えばいいかわからなくて統計の勉強始めた ような気はする。 そして挫折した(ごめん)
データアナリストやデータサイエンティストも統計とか必要になってくると、中2数学を遥かに超えたところ を求められるんじゃないかとは。
なんで今をときめくこの分野だと 数学必須 じゃないかなあとは思う。いずれライブラリが充実していらんくなるかもしれないですけどね。(でもそのときが来たとしてもむしろ数学知ってる方が価値が高い人材になってるだろうなとも)
「数学を勉強しろ！」は結局どうなのか
業種無視してマウントとってくるのは無視していいんじゃないかと思います。
職場で言われてるなら具体的に必要な部分を聞いて学んだほうがよいかもしれない 。
あと「○○エンジニアを目指すなら」って 業種の前置きがついてる 場合も、必要性を検討したほうがいいと思います。 実際必要な可能性ある と思うから。
亜種「○○を勉強しろ！」
いろいろありますね。「SQLを勉強しろ！」「アルゴリズムを勉強しろ！」とか。このへんも同様。 目的に沿って必要か必要じゃないか かなあとは。
「サーバーを0から構築する」のはどうなの？
昔の栄光を語る&サーバーを０から構築したがる
ってセットにされてるのが 解せぬ のだけどまあいいや。
今どきサーバーを0から(インストール画面から)構築する機会は ほぼない とは思います。私自身ももう数年、下手すると10年以上はそんなことしてないですね… ( 自分ちのWindowsが死んだ ときくらいですかね…サーバーじゃねえや…)
※自分個人の経験を元にしてるのでサーバー=Linuxサーバーと思ってもらえれば
ただAWSのEC2などで用意されているのは インストール直後のLinux なのでいろいろ足りない。実際に使える状態にもってくためにミドルウェアをインストールしたり設定したりは必要になります。
インストール後のセットアップを含めるなら「0から構築する」機会はそれなりにあると思います。
このあたりも今どきだと、「インフラエンジニア」って枠で別になっているから PHP書いてるだけだと縁がない 感じはしますけどね。 残念ながら逃げられると思うなよ。社内環境だけでも動作がおかしいみたいなのがつきまとってくるし長くサービスを続けているとバージョンの問題も絡んでくるし。
「0から構築したがる」ってのはそうする必要があるってのと、いざってときにそこまで知ってないと詰む って話の裏返しでもあると思います。(もしかしたら「数学勉強しろ」もそういう面があるかもしれない)
「0から構築する」=Dockerfileかも？
「0から構築する」を今風に言うと Dockerfileを書く になるかもしれんですね。あれはまさに構築手順の自動化なので。Dockerfileを用意したオリジナルコンテナで運用とか割とする機会あるんじゃないです？
マイクロサービスになっていくと、「どれをインストールしてどれを削るか」みたいなところの構成もコンテナごとに考える必要があるので、おっさんが昔からやってる「ゼロから構築」とは別の観点での「ゼロから構築」が必要になってくるかもしれない。
またAWSなどでは便利なサービスが揃ってて、RDSとかElastiCacheとか個別のサービスを使うことですべてのミドルウェアを自分で準備する必要はなくなってるし、いずれ全部サーバーレスになってコードを書くだけで済むかもしれんですけど。そうなってくれたらそっちのほうがいいわな…とは思います。
勉強のためならプログラマでもやってみるのアリかも
そういう現代なんで口に出す機会もあまりないですけど、 勉強のためゼロから作ってみるのはアリ なんじゃないのとは思ってます。古いPCにLinuxインストールからしてもいいですが、EC2インスタンスでPHPサービスが動くとこまで構築とか、OSインストール済みから始めてもいいですね。
「プログラム/サービスが動かない」って結構、回避する手段としてサーバーの設定をいじったりすることも多いですしね。 具体的にはメモリ上限を上げたりswapをぶっこむ んですが。大抵。
過去の栄光の自慢話
本当にすまない。飲み会の戯言だから聞き流してやっておいて。 自前でサーバー抱えなくてせいせいしてるから出てくる話 だよ。戻りたいとは思えないね…
「〜すればよいのでは？」
煽り口調なのでイラッとする 書き方ですね。こうは言ってません。
言ってませんがたぶん似たような言葉として「〜してはどうでしょう」みたいな文言を、主にPRレビューで多用しています。
「実際書いた人が一番その仕様に詳しいはず」と考えていて、そのスタンスで望んでいます。なので「こうしてください」と迂闊に書いてしまうと、「なんかおかしいよな」って思っていたとしてもコメントの指示通りにされてしまう危険性があるかもと思っていて、それを避けたいのです。
(その結果、「やっぱり元のままにします」とか「今はやめておきたいです」とか理由付きでコメントしてもらえれば、そのままでもOKです)
ガイドラインに反しているなど、修正を求める理由が明確な場合は「こう直してください」とコメントすることもあります。
あと、
「これはこれこれ、こうだと思うので、これをやってください」
は指示出しや依頼する際の方針としては正しいし、こう言えるよう努めてはいます。
ただ、たぶんですが元のセリフがでてくる場合って「なにかの行動に対するフィードバックやリアクション」が多いんじゃないかなと思います。
「〜すればよいのでは？」みたいなのを完璧に読み切ることはできないし、やってみた結果のフィードバックとして出てくることもあるし。
「なら最初に言えよ」って思う気持ちはわかるし 俺もそう思う どころか「なら最初に言えよ」って そのまま口に出る のだけど…結局全部そうするのも不可能なんだすまない…なるべくガイドラインや明文化するようにはがんばってるよ…
でも(文句出るのはしょうがないにしても)それが許容できなくてマイクロマネジメントしないと動けない ならまあ… その人に頼まないで自分でやる時間をスケジュールにいれたほうがコントロール効くしストレスない って結論になりますね… (煽り口調に耐えられないっていうならわかるが別の話になる…あと、フィードバック分の時間はバッファとして最初に用意した上でです。あまりやったことなさそうなところは特に)
自分でやった後でも思いますもん。やってみたあとで 「あっやべこうすりゃよかったんじゃない？」 って。
習熟度の順番
習熟度によってお願いするコストとリターンが変わってくる話もあった気がして、
1. 言われたことができる
2. 言われなくてもできる
3. 言われたこと以上の価値を提供できるみたいな感じかなあと思うのだけど。この話は1の時点にあたるのかな。
1の時点の人に2や3を安易に求めるのは無理(そのシステムに対する習熟度もあるし)。
しかし手が回らんとついそうなってるところはあるかもしれない。それはすまない。(そうならんように注意はしている…しているが…)
むしろ自分から聞くのはアリ
むしろ最初に「『これはこれこれ、こうだと思うので、これをやってください』というふうに教えて下さい」って話をするのは全然良いと思っています。頼む側からすると、わからないことを伝えてもらえているわけで。
表題のセリフが出てくるのは、結局なにかの行動を起こした後だと思うからすでに遅いけど…もし気づくなら行動起こす前に、不明点を確認しておくのは良いポイントではないかと思います。
結局聞き流して問題ないなら問題ない
まあ…ああいう記事にリアクションするのもどうかなとは思ったのですが…それなりに言われることも多いんだろうなあとも思ったのでちょっと書いてみました。私自身は とりあえずクビにならずに済んでる程度 のものなので偉そうなことはいえんですが 逆に参考になる んじゃないかなと思います。 いやせんほうがええか若人は。
本質的には「マウントとってくるやつがうざい」って話かなとは思うので…例示されているようなもので頻繁にマウントとられるとうざいんだろうなあとは思いますけど マウントは何で取られてもうざいだけ なのでこれに限った話じゃないですね。そういう意味ではこの記事もそうなんですけどまあ個人ブログの与太話なので。
雑談の過去語りは勘弁してくれ。おっさんになると時折思い出すんだよこの前もさぁみずほのHDD障害あったじゃないこういうのを見ると昔客先でHDD交換したときに（終わる