  |
はてなキーワード: バックエンドとは
フロントエンド開発を始めて早4年、界隈の雰囲気も好きになれないしトレンドを追いかけるのも疲れたよ。
Twitterを開けば否応なしに口論しているツイートが流れてくる。
あるいはライブラリのバージョンアップや新規ライブラリの公開ツイートであったり。
社内でもフロントエンドといえば私、みたいな立ち位置になりつつあって
有難いことだけどその分情報のキャッチアップから離れられない。
フロントエンド分野だったらなんでも分かるわけじゃないし、実装に時間がかかることだって多々ある。
期待に対しての成果を出すのが辛くなってきて、そんな風に捉える自分も好きになれない。
バックエンド担当の同僚と話していても、大きな変革もそこまで無くなんだか羨ましく感じる。
結局自分がコードを書くことに向いてないだけかもしれないけど。
始めた頃はちょっとしたコードが書けるだけで嬉しかったり、新しい情報が出ると一目散に駆け寄って自分で試したり出来たのに
いつからこうなったんだろう。
社会人になってからのぼんやりした目標でITを極めたいという思いがある。
一分野に特化したタイプではなくIT領域におけるオールラウンダーのような総合格闘家のような存在。
まずITを極めるとは具体的にどういう状態なのか。そのためには何をすればいいのかを考察する。
まずITを主要トピックに大別する。必ずしもMECEではない。
そしてどういうことができたらITを極めたと言えるかを思いつく限り列挙してみる
次は具体的に列挙した例について解像度を上げてどの要素に分類されるものかを考えた上で、それを極めるには何をすればいいかを考える。
https://twitter.com/satetu4401/status/1788854969711661464
一連のポストがあまりに的外れにも関わらず、「ほんまそれ」「耳が痛い…」みたいな反応があって、お前ら騙されるな！と思ったので書く
なお、私は仕事でバックエンド開発やデータ解析を行っている者です(要するにITエンジニア)
確かに経営者は「仕事をしたら給料を払います」と言うけど、それは労働者との契約なので断言するのは当たり前です
確かに飯屋は「この新商品は美味い！」と言うけど、美味いかどうかって個人の感覚によるので、実はこの発言はあまりリスクを取っていないです
「今月中に納品します！」と断言してきっちり今月中に納品する、これは信頼に繋がります 「今月中に納品できるかもです」と言って今月中に納品するよりも心証は良い
でも、普通の不織布マスクが「100%花粉を防げるマスクです！」と謳ってたらどうでしょう？
法律うんぬんを一旦置いておいても、100%花粉を防げるとは考えにくいし、な〜んか胡散臭いですよね
このように、断言することが誠実さに繋がらない場合もあるわけです
そしてデータや理論に基づいて仕事をする人は、「断言しない誠実さ」を示すべきシーンによく遭遇します
じゃぁ技術者は断言しないのか？と言うとそんなことはなく、しかるべき時にはちゃんと断言します
PL等から「すまん！来週までの予定だったタスク、今週中に出来ないだろうか…いろいろ手を尽くしたのだが」なんて言われたら、覚悟を決めて「今週中にやります」と断言しなんとか今週中に終わらせることはあります
今週中にできる確証はないにもかかわらず、です
「責任から逃れ」続けている技術者なんて少数で、場合によって使い分けてる人が多数なはずです、少なくとも弊社はそうです
.
さて、他にも有言不実行は危ないーとか調査に必要な工数がーとか言いたいところだけど割愛します、なぜなら一番言いたいのは↓これだから…
そもそも、砂鉄自身が「根拠の薄い断定」をするキャラとしてフォロワーを集めた人間ですよね
「自分が成功した方法は人にも適用できるはず」と考えるバイアスが働いていたとしても不思議じゃないです
そうじゃなくても、「あいまいな言い回し」について何かフォロワーが喜ぶ言説を言えないかな〜とインフルエンサー砂鉄として考えた時、自然とこういう論調になるでしょう
インフルエンサーが自分にとって耳触りのいい考えばかりを言っている時は、自分が手のひらで踊らされている可能性を考えたいものですね
.
.
.
てなわけで、砂鉄の一連のツイートは一つの偏った考えに過ぎないので、みんなは鵜呑みにしないようにしようね！
何をどう間違ったのか、超大手のITコンサルタント会社に入ってしまいました。
今までは事業会社でマネージャーをやってました。ITツールはそれなりに使っていて、Salesforceも使ってました。
しかし、これまで開発の経験はなく、自分でPythonとPHPを少し勉強したぐらい。基本情報技術者試験も受験したけど落ちました。
ITコンサルタント会社でマネージャーとして稼働していますが、はっきり言って何も分かりません。
ITコンサルタントのマネージャーというのはどういったスキルを持っている人なのでしょうか？
例えば 新規にプロジェクトを導入したいとなった場合見積もりを出さなければなりませんが全くアタリもつけられません。
システム開発の場合どのようなことを知っていれば 見積もりが作れるのでしょうか？
ITプロジェクトの場合どういったシステムを導入するか、という話になると思います。
特にSaaSであれば、どの製品を使うのか？という話になると思いますが、ITコンサルタントのマネージャーというのはどんな製品であろうと、あるていど見積のアタリをつけられるのですか？
各製品のことを知らなければ、開発の難易度もわからないし、どのくらいの期間が必要か、もわからないと思うのですが、どうやって乗り切っているのでしょうか？
それとも、ITコンサルタントのマネージャーというのは、ある程度ジャンルを限定した経験を、テスターなどから積み上げている人達のことなのでしょうか？
正直苦しくて仕方なく、ずっとモヤの中をさまよいながら仕事をしているような感覚です。
要件定義は当然わからない、開発は進捗がどうなってるか、くらいは確認できるのでなんとか出来る。でもその工数が妥当かどうかもさっぱりです。
一体なにを学べば、PoC、要件定義、開発見積、というのが出来るようになるのでしょうか？
こういう話しをすると、まずお前が何したいか？とかそんな話になるのですが、正直やりたいことが何か？というのも無いです。
ITコンサルタントのマネージャーとしてちゃんと稼働出来るようになりたいです。
例えば、GCPやAWSの資格取得を目指したらある程度わかるようになるのでしょうか？
インフラ系？ フロントエンド？ バックエンド？ いまいち違いもわかりません。
なにかの言語を学べばわかるようになるのでしょうか？
一体、私は何を学べばITコンサルタントのマネージャーとして一人前になれるのでしょう？
知恵袋に投稿しようと思ったけど、はてなの方が経験者多そうだと思い投稿しました。
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
テック会社のバックエンドのバックエンドくらいを書くのから、一般企業の内製に移って要件定義的なことからやることになったけど
こんなの外注に出せるほど定義するの無理だろ、世間の人はどうやってんだ、と思ってるわ
ユーザー自体が自分のビジネスプロセス知らねーんだもん、そりゃ無理よ
レガシーと同じようにってレガシーボロボロだから作り直してるんですよね？
データの持ち方もとりあえず入れといて損はないからって損ありまくりなんだよ！とりあえず入れといたらあっという間に手に負えなくなるぞ！
