  |
はてなキーワード: スタックとは
「共通言語たるドメインモデルを、そのままコードと1対1対応しなければならない、という思い込みや風潮。
既存のWAF(Web Application Framework) の利点を潰してどうする…」
こういう誤った思い込みをエンジニアにさせているのは、ドメイン駆動設計の原典である「エリック・エヴァンスのドメイン駆動設計」が、いかに抽象的な内容で、ある意味では哲学的であったかを、明示するものでは無いか。
プログラムとはメタファーであり、現実を、もしくはそれに準ずる写像的な世界観を、コードに忠実に再現するものでは必ずしも無いと考える。この記事の増田は「過度な抽象化」とも書いているが、プログラムというか、そもそも言語そのものが物事の全てを表象できるものではなく、ある一側面の一イメージしか切り取れない不完全なものだし、それ自体が問題ではない。現実とソフトウェアの溝を、ユーザーとエンジニアの溝を、ドメインとソースコードの溝を、いかにして埋めるかというのが、ドメイン駆動設計の本質だし、その埋め方についてはエリックエバンスは一例を示しているに過ぎない。EntityやValueObjectなど、必要なら使えば良いし、不要なら使わなければ良いのだ。ただし、元々何が問題なのか、問題だったのかという点について、いかにして向き合うかが肝要であり、それは技術論や方法論の話ではない。
ドメイン駆動設計の記事を書いたり、勉強会で発表をしている人間は、原典やそれに付随するドキュメントの内容を、無批判に信奉し、そのようにしなければならないという強迫観念に追われているのではないか。そもそも、本当に理解しているか怪しいし、不安だから教科書の内容にしがみつこうとするのだろう。さらにこの手の連中は、昨今のCQRSやイベントソーシングやマイクロサービスなどとも絡めて話をし出すから、タチが悪い。「ドメイン駆動設計はこの手の技術スタックと相性が良い」という言葉を何度も見かけたが、技術的な方法論はそもそも無関係だったはずだし、そうやって安易に結びつけてしまうから、ユーザーが置き去りになって来たんじゃねーのと、暴言でも吐きたくなる。問題の本質はどこにあったのかを、聖典の内容や、流行り廃りの技術とは切り離して、エンジニアは三思九思すべきだ。
別にこうあらなければならないという法律や決まりは無いし、好きにやれば良い。モデルと1対1にならなければ、分割する事を選択するのも一つの向き合い方だ。ドメイン駆動設計の信者ににゃんにゃん写真でも撮られて、ばら撒くと脅迫されているのであれば勿論話は別だ。恥ずかしい写真を魚拓されたくなければ、とりあえずEntity、ValueObject、Repository、Service（笑）位は最低限、用意するのが身のためだろう。
自分の頭で考えて、自分の責任で判断するという当たり前の事に立ち返りたいものだ。ドメイン駆動設計という盲目的な宗教からいかにして抜け出すかが今後のエンジニアの課題だろう。
追伸
https://anond.hatelabo.jp/20210228234557
を読んで，じゃあ准教授になるとどうなるのか書いてみよう。
コピペですむ部分はそのまま利用している。
40代前半で旧帝大の准教授 (任期有→もうすぐ任期無になる予定)。この業界ではそこそこ勝ち組と呼ばれる部類だと思う。
日本トップクラスとも言えるこのポジションで、私が普段何をしているのかを書いてみたい。
准教授とはいえPIなので在籍する研究室に居る学生のうち10名ちょいに対して研究指導を行っている。各人に対し、一対一のミーティングを月に 1 時間行うため、トータルで週3～4時間くらい。
それに学会論文チェックなども入るのでトータルだとこんな感じかな。
学生の研究の進捗を研究室メンバー全員で確認するための会。実質的な研究指導はここでおこなわれる。
学部生，大学院生向けの講義を週に平均すると2コマくらい受け持っている。
実際には前期後期で異なるので必ずしもこのとおりじゃないけど。同じ専攻の中では多いほうだと思われる。
数は少ないが非常勤などもそれなりの数あるので実質はもうちょっと多いか？
ちなみに講義の準備は一度したら終わりと思われがちだけど、意外なことに毎年それなりの時間をかけてアップデートしています。
月1~2回の会議が6~7個、一回2時間程度あるので平均するとこのくらいかな。
大学院、学部などの組織ごとに、運営、教育と異なる目的で会議が行われるのでかなり多い。
とはいえ、昨年はオンライン化されたおかげで自分と関係ない業務の際には全力で他のことができたのはありがたかった。
今後もこのまま進めたい。
うちは事務補佐員がいるので、基本的に雑用は全部お願いして週1回打ち合わせをするだけですんでいる。
補佐員を雇う前は週4時間くらいは領収書の処理とかをしていた気が。
ただし、事務補佐員は外部資金で雇うため、外部資金が切れるとまた事務作業との戦いになるので、
研究を継続するためにも研究費を切らせられないのでかなりつらい。
学会の運営 (研究会の準備など) は主に大学教員がボランティアでやっている。元増田には
とあったが、学会関連の雑務はステージが上がると異なる雑務が降ってくるだけな気もする。
助教氏は査読に結構時間をかけてくれているようだけど、その査読の割り振りなどが今度は仕事になってきたりする。「割り振りだけなら楽じゃない？」と思われるかもしれないが、結局論文を読まずには割り振れないので、論文を読む数は増える。
もちろんそれ以外にも研究会の運営やら学会の理事会やら・・・色々あります。学会運営委員とかなると、もう。
助教氏は書いていなかったけど、様々な研究プロジェクトに参加することが多いので、それに相当時間がとられる。
プロジェクトなら研究だろ、と言いたいところだけど、報告書の執筆やプロジェクトメンバーとの会議などを含めると相当時間を取られる。
大体いつでも本だの依頼原稿だのが2、3個はスタックにたまっている気がする。
それにプラスしてマスメディアからの取材とか、国や企業からの相談とかインタビューとかがある。
そして、講演。企業や団体からの講演依頼にこたえていくと結構時間がとられる。講演そのものは1時間くらいだけど、その準備になんだかんだ時間がかかる。
というわけで、トータルだとこのくらいになる気がする。
ということで、以上の項目の合計で 42時間。1 週間の所定労働時間 (8時間×5日 = 40 時間) はすでに赤字である。
え？自分の研究？もちろん、実際には(12時間×5日 = 60 時間)くらい仕事しているので、18時間くらいは何とか確保していますよ。
コロナ禍のおかげで移動しての会議が無くなったのでオンライン化最高だと思わざるを得ない。
最後に、助教氏は雑務をあまり押し付けられなかったとのことですが、うちの元ボスもそんな感じだったので、それを見習って若手のためにもなんとか雑務は自分たちで止めておきたいところですね。
その結果、その分自分の研究できなくなって老害とか言われるようになるのかもしれないけど。
そして、うちには助教いないけどな！
足りなかったねん(´・ω・`)
Android版バグについて開示された文書を少し読むだけでいくつかのデマが分かった。
https://note.com/mugura/n/ncc3c61de39ea で情報開示されたPDFを読むことができる。
議事録側はまだ読んでいない。
最初にHER-SYSの開発のためにパーソルプロセス＆テクノロジー株式会社と税込約2億の契約があった。
COCOA開発は原契約を税込約3億へ変更とすることで対応した。
契約変更の時、再委託先を株式会社FIXERの1社から以下5社へ変更する申請がなされた。
厚生労働省 ┗ パーソルプロセス＆テクノロジー 2億6771万（税別。以下同様） ┣ FIXER 1億2062万 ┣ エムティーアイ 1615万 ┃ ┣ E社 355万（MTIから） ┃ ┗ D社 41万（MTIから） ┗ 日本マイクロソフト 2201万
| 株式会社FIXER | 新型コロナ感染者等情報把握管理システムの開発、監視運用、サポートデスクの一部業務、およびサービスの提供 |
| 株式会社エムティーアイ | 接触確認アプリケーション開発の一部、リリース後のヘルプデスク/運用保守業務 |
| E社（MTIからの委託） | メールサポート（日本語/英語） 接触者に対する電話サポート（日本語のみ） |
| D社（MTIからの委託） | 初期検収業務の一部、および保守開発準備業務の一部 |
| 日本マイクロソフト株式会社 | PMO支援、技術支援 |
デマについて
・まず2億から3億の差額約1億がHER-SYS側への繋ぎこみおよびiOS・Androidのアプリ開発に充てられていることになる。アプリ開発が3億のように言うとデマ。
・そして3次請けの位置の2社は業務範囲に開発は含まれていない。「多重請負でたったこれだけに」みたいな図でここの金額が出てきたらデマ。
ここからは憶測や調べ切れていないこと。（議事録側で分かることもありそう）
・COCOAのベースはOSSのCOVID-19Radarで、開発に関してはどこかにOSS利用という線を引いた方が分かりやすい。
・OSS利用を0円発注の搾取とは通常言わないが、今回に限っては、1国1アプリの条件がある中で、6月中旬公開の宣言されて実質納期になったり、
初期の品質批判がコミッターに直撃してリタイアしたところを見ると受託者に近いようにも思う。
https://www.itmedia.co.jp/news/articles/2006/23/news107.html
・開示された文書での契約期間は2020/7/31までだが、それ以降の体制は未確認。
・2020/9/28にiOS版の不具合（通知あるのに接触なし表示）修正のためにアップデートが行われ、その時Android版にエンバグが発生した。
https://www.asahi.com/articles/ASP236SR9P23UTFL00R.html
・政府CIO補佐官(ブクマカ)のツイートでは、EN API自体の制約や、アプリで選定された技術から人材・機材の手配の難しさに言及している。
https://twitter.com/masanork/status/1358207125546127362
https://twitter.com/masanork/status/1358187420492001281
・人材についてはMSがいるのにと思ったが、MSの支援が切れる事情でもあったのだろうか。
・COVID-19Radarでない方のまもりあいJapan（の一般社団法人Code for Japan）は新型コロナウイルス感染症対策テックチーム第1回から参加していたが、採用されないことになったについて根拠が不透明とある。
https://medit.tech/code4japan-not-incharge-of-contact-tracing-app/
・COVID-19Radarの中心がMS社員であったことや、Azure DevOpsなどMS一色の技術選定であったことなどから経緯を訝しむ考察があった。
https://blog.rocaz.net/2020/06/2140.html
https://blog.rocaz.net/2020/06/2171.html
https://blog.rocaz.net/2020/07/2257.html
・そして今回の開示された文書でもなぜCovid-19 Radarが選ばれたのか不明とある。
・選定が不具合と直接関係ないとは思うものの、利用人口少ない技術スタックを選んで人材不足になったなら遠因にはなってる気がする。
・大きくやらかした時に責任取り切れず法人ごと消えることの無さそうな大企業を窓口に選びたいところまでは分かる。
日本の超大手企業(繊維系)の内製システムのエンジニア採用を受けて落ちた時の記録
虚実織り交ぜて書いてるので真にうけないように
受かった人の話を聞いてみたい
割と普通の内容だったがRubyのコードを見せられたときは面食らった
サービスのアーキテクチャ設計するときに気をつけていることは何？
セキュリティ面で気をつけていることは何？
唐突にRubyのコードを見せられ、このコードの悪いところはどこですか？
サービス規模の割に社員数が少ないけどどんな編成になってるのか
なんでもクラウドベンダーの特定技術に縛られたくないからKubernetes使いたいみたいなことを言っていた気がする(そういうための技術じゃないけど)
なぜアプリエンジニアと面接したか不明(当方の専門はバックエンド)
経営陣がクラウドの予算を出さないが24/365守れと言われたらどうする
交渉してだめだったら
24/365関連の質問です。サービスをスパイクさせないためにはどうしますか？
あなたの考える最強のバックエンドアーキテクチャをおしえてください
質問を変えます、月の予算1億円もらったらどんな構成にしますか
// 過去にアプリ開発をしたことがあったのでアプリ開発について質問を受ける
iOS/Androidのアーキテクチャを設計するとしてどこまで同じ技術を使うように強制しますか
SwiftUIはメモリ食いまくりで大規模アプリでは使い物にならないことですね(ドヤ)
SwiftUIではメモリ食いすぎてインフィニットスクロールが使えません(ドヤ)
先ほどSwiftUIについての質問を受けましたが御社のアプリではSwiftUIを導入されてますか？
外部協力会社とサービス開発をしているということだけど今後社員比率をあげる予定はあるか
正確にいうと持て余している。
それにかこつけてプロジェクターを導入しており、
このプレイヤーをありがたく頂いたのは、
プロジェクターから直接発されるペラペラの音に耐えかねたからだ。
さすがに映画を没入して見るためにはプロジェクター直出しの音質は心許ない。
端子がなく、光デジタルケーブルでの分離はどうやら不可能だったために、BTでの音声出力ができるプレイヤーは大変ありがたかった。
ところがfirestickを手に入れたところ、挿すだけで直接firestickからスピーカーにBT接続ができてしまうではないか。
やや音質が心許ない気はするが。
このプレイヤー、Amazonプライムのためにしか使用しないため、完全にお株を奪われた形なのである。
手放してもブルーレイが見られなくなるくらいのデメリットしかない。
売りたいが、頂きものに申し訳ないようなうっすらとした気持ちがある。ミニマリストにはなれないタイプだと実感する。
チューナーにスタックしているので劇狭ワンルームでもさほど邪魔というわけでもなし、扱いかねている。
そもそも我が家で持て余すほどのBTブルーレイプレイヤーに需要はあるのか。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 147 | 11670 | 79.4 | 29 |
| 01 | 34 | 3089 | 90.9 | 62.5 |
| 02 | 33 | 3581 | 108.5 | 47 |
| 03 | 30 | 9538 | 317.9 | 58 |
| 04 | 15 | 2067 | 137.8 | 88 |
| 06 | 13 | 6819 | 524.5 | 45 |
| 07 | 27 | 1274 | 47.2 | 32 |
| 08 | 46 | 5879 | 127.8 | 41 |
| 09 | 65 | 4207 | 64.7 | 28 |
| 10 | 119 | 12081 | 101.5 | 57 |
| 11 | 105 | 7717 | 73.5 | 47 |
| 12 | 83 | 7220 | 87.0 | 42 |
| 13 | 151 | 16300 | 107.9 | 46 |
| 14 | 141 | 10839 | 76.9 | 42 |
| 15 | 89 | 12894 | 144.9 | 30 |
| 16 | 125 | 9021 | 72.2 | 34 |
| 17 | 138 | 15380 | 111.4 | 58.5 |
| 18 | 147 | 12034 | 81.9 | 61 |
| 19 | 214 | 18317 | 85.6 | 36.5 |
| 20 | 145 | 20079 | 138.5 | 41 |
| 21 | 224 | 15904 | 71.0 | 47.5 |
| 22 | 177 | 16611 | 93.8 | 42 |
| 23 | 176 | 21285 | 120.9 | 44.5 |
| 1日 | 2444 | 243806 | 99.8 | 42 |
サマンサキングズ(6), キッチンシンク(5), 初夢(5), ２０２１年(7), スピンドル(3), タップル(3), ニップ(3), 薬理(3), 七草(3), あけおめ(14), 福神漬け(4), 正月(39), 会食(14), 別姓(12), 緊急事態宣言(29), チェーン(10), 早々(13), 財布(22), ことし(9), 新自由主義(11), 明け(13), 研究者(17), 今年(61), 産業(15), 菅(8), マッチングアプリ(10), 研究(40), 成果(14), ハードル(11), 抜き(11), よろしく(12), 政府(41), 冗談(12), 論文(10), しょうが(32)
■マッチングアプリで50人会ってやっと彼女できそう、なのにできてない /20210101060523(30), ■緊急事態宣言出さないこと文句言うけど /20210101095452(25), ■安全圏で騒ぐのは誰にでもできる /20201231040911(16), ■母が探しているアニメ（追記） /20210101104010(14), ■ /20201231205450(12), ■ヴィーガンなのでおせちが喰えない(´･ω･｀) /20210101094350(10), ■難関大理系学部卒だけど2ch見て就活したら人生うまくいった /20201231161221(10), ■2022年からタイムスリップしてきたけどなんか質問ある？ /20210101034651(9), ■浪人生ですが、もし4日に緊急事態宣言が再発出されたら /20210101073917(9), ■創作活動したいけど恥ずかしい /20201231223736(7), ■来世は過剰なぐらい承認される人生が欲しい /20201231131247(7), ■ /20201231235959(6), ■マナーの悪い人間や面倒な客のことを「○○おじさん」と揶揄するアレ /20210101193559(6), ■anond：20210101095452 /20210101173247(6), ■「『マザーボード』もそのうち言い換えられるのか」 /20210101044120(6), ■10代から30代を外出禁止にしたらコロナ収まる説 /20210101005353(6), ■お前らコナンを舐めてるだろ /20190101232257(6), ■無能のくせに自己顕示欲強いから辛い /20210101232339(5), ■一年の計はガンタンクにあり /20210101090914(5), ■もしかして今時ネットでは句読点使わないのが普通？ /20210101124446(5), ■なんでゴスロリ系の女＝地雷って認識なんだろ /20210101130827(5), ■大学への予算ってどのような理論で配られてるの？ /20210101194159(5), ■メーカー系SIer勤務の年収600万のプログラマーの技術スタック /20210101205107(5), ■白人至上主義 /20210101210930(5)
この程度でも600万は稼げるという夢を持つか、こんなのでもちょっと何かが違うだけで600万稼げるか否かが分かれてしまう業界に闇を感じるか、600万程度で何ドヤってるの？と思うかはご自由にどうぞ（外資系ってもっと稼げるの？）。
歳は30台前半。学部卒。BtoB向けのパッケージ製品の開発プロジェクトで、設計、コーディング、テストあたりを担当している。仕様について発注元との折衝もやっている。
業務で使う技術のうち、自分自身がそれなりに習得しているものだけを書く。プライベートでしか習得・使用していない技術は別。
以上。
PythonもgitもDockerもkubernetesもAnsibleもCIツールもAWSもGCPもRuby on Railsも知らなくてもなんとかなってしまっている。業務でこれらのスキルを要求されることは（今のところは）ないから。
楽でいいと思う一方、このままだと将来ヤバいとも思っている。いざ転職となったときに詰みそう。
でもいざとなったらググっていくらでも独学できるだろうとたかをくくっているので焦ってはいない。
というか「その他」のところに書いた能力が高ければ世の中大体はなんとかなるんじゃないの。知らんけど。
ちなみに自分は構築できないというだけで、プロジェクトではJenkinsとかgradleとかbabelだかwebpackだかでビルド環境は整えられている。
あとプライベートで、単純な仕様の独自言語のコンパイラフロントエンドをC++とLLVMで作っている（これで金が稼げるとは微塵も思っておらず、完全にただの趣味）。
努力不足でSESにしか行けなかったというツイートが話題になっていますね。
件の人に限らず、スクール卒業者が就職できないやら、採用したけど使えなかったとかという話をよく聞くので、そんな悲しいミスマッチを減らし、この業界を目指す人が希望と勝算をもってチャレンジできるようになることを願って思っていることを書いてみようと思いました。
業界に入って十数年、メガベンチャーで働きGAFAの関連企業から1X00万円のオファーを貰うくらいのスキルと経験はある。もちろん開発のスペシャリストとして。
新宿の雑居ビルにオフィスのある中国人が経営するSES会社からキャリアをスタート。最初の会社は雇用保険も払ってなかった。
新卒または第二新卒、文系または数学が苦手、プログラミング未経験者でスクールやサロンに入ってプログラミングを身につけて働きたいと思ってるひと。
理系やプログラミング得意な人は、学生ならインターン、働いてる人はなんでも良いからスクリプトで業務改善すれば実務経験になり、そこからならどうとでもなるのでこの記事は参考にする必要なし。
ふたこぶラクダ理論というものがあります。(https://ameblo.jp/bradnine/entry-11911830387.html)
要約すると、出来る人と出来ない人がいて、何が要因なのかわかっていないし、出来ない人への教え方も確立していないとのことです。
学び始めてすぐに判断を下す必要はないですが、スクールのカリキュラムを終える頃には周りとの成長スピードの差で自然に理解できるかと思います。
しかし、もし適正がなかったとしても悲観するのはまだ早いです。
プラグラミングの適性がない人にもこの業界にはポジションがある。QA、PdM、PjM、UIデザイナー、UXデザイナー、カスタマーサクセス、営業、採用、などなどいろいろあります。
なにはともあれ3割くらいは可能性があって外れても選択肢があるんですからポジティブに受け止めましょう。
エンジニアの生産性の差は10倍や100倍にもなると言う話は聞いたこことがあるかと思います、底辺と天才を比べた極端な話だと思いますよね？実はこれありふれた話です。超有名ベンチャーで難しい採用試験を潜り抜けて即戦力採用された人たちの中でも100倍の差があることもあります。それも瞬間風速的な話ではなく、年間の変更コード行数を計測してそうなります。10倍の差はもっとありふれた話です。
さてここまではプラス面だけの話ですが、マイナス面も考える必要があります。
あなたが無事現場に入ってわからないことを教えてもらう必要があるとします。面倒見のいい先輩がなんでも聞いて良いよと言ってくれたので、質問をして、3時間先輩の時間を使ってしまいました。先輩は100倍エンジニアだったとすると、その3時間であなたの二ヶ月分の作業量が消し飛んだ計算になります。あなたはそれに見合った成長をして恩返しできますか？
ちなみにそれくらい能力差があっても給与はあまりかわりません。良くて倍くらい。同じ給与ってこともまぁよくある話で、多重下請の現場では逆転してることも珍しくはありません。
そろそろ本題に近づいてきました。
ここまでの話を踏まえてどうするべきだと思いますか？
特別なことでも難しいことでもなく、いたってシンプルです。それは「足を引っ張らない」ことです。大抵の現場では初心者に毛が生えたような人にアウトプットを期待していません。ある程度の教育期間をとった後で普通の人の半分でもアウトプットを出してくれたら恩の字です。
あなたが天才でなければ、まずは自分でアウトプットを出すのは一旦諦めてください。先輩の時間を増やしましょう。例えば動作確認や他チームやステイクホルダーへの連絡、文書作成など、100倍エンジニアでも生産性が変わらない業務を肩代わりして先輩が開発にかけられる正味の時間を増やしましょう。これが現段階では正しいチームワークです。100倍エンジニアの時間を奪って質問するくらいなら、10倍の時間をかけて一人で調べた方が、10倍生産性が高くなります。聞くとしても調べた上での答え合わせと間違っていた時のヒントだけにしましょう。個人の学習効率をだけみてもそっちのほうが効率いいです。理解できない人には独学大全がオススメです。
ろくに動作確認をしていない可読性の低いコードをプルリクに出して、レビュワーになった100倍エンジニアが仕様確認したりローカルで動作確認したり、あまつさえバグを見つけてしまうなど、最悪です。
初心者だから間違えてもしょうがないというのは正論です。しかし、プロジェクトの時間とコストを考慮すれば逆の結論になります。あなたのアウトプットが数倍早くなろうが遅くなろうがプロジェクトには影響がないのです。学習時間とリスクを考慮してそういうふうにタスクを組んでいます。数倍時間をかけて慎重にやって良く、マイナスを生まない事を考えれば、初心者こそ絶対にバグを出してはいけないという結論になります。0は無理でもそういう気持ちでやりましょう。
ここまでは現場に入ってからの話でした。皆さんは現場に入る方法を知りたいと思いますが、もう少し辛抱してください。敵を知り己を知れば百戦危うからずの故事もあります。もう少し敵を知ってから戦術を立てましょう。
デスマーチと呼ばれているものには2種類あります。一つは定義通りのデスマーチ (https://ja.m.wikipedia.org/wiki/デスマーチ )。もう一つはデスマーチの要件を満たさないが、関係者の能力不足によってデスマーチの様相を呈しているもの。実は前者はとても希少で、世の中のきついプロジェクトというのはほとんど後者だと考えてください。
様々な点で両者は異なります。
真のデスマーチはほとんどの場合技術的な問題ではなく政治的な問題で発生します。そのため予算は潤沢ではないが常識的にはあり、技術は枯れてリスクが少なく確かな効果が確認されているものが採用されていることが多いです。工学的なアプローチで生産性を向上する仕組みなどが取り入れられていることもあります。管理プロセスも機能しておりコンプライアンス違反も少ない傾向があります。政治的な理由でプロジェクトが延長されている都合で、PMがプロジェクトを終わらせたいと思っていても、予算がある限り新しい要件が発生しつづけて終わらないという状況も発生しえます。こちらのタイプに参加するメリットとしては、よく管理運営されたプロジェクトを体験できる点、ドキュメントがしっかりしている点、低スキルの人が参加することを考慮して仕組み化されているのでキャッチアップにかかる時間が低いなどがあります。
なんちゃってデスマーチは技術力や要件定義能力、集団の合意形成能力などの不足によって起こります。PMやステイクホルダーは赤字を垂れ流すプロジェクトを早く終わらせたいと思っているので多少納期が伸びても必ず終わります。プロジェクトを終わらせるための提案であれば下からの意見でも柔軟に対応してくれることもあります。新しい技術と古い技術が混在していたり、新しい技術を採用しているのに使いこなしていないこともあります。CI/CDや自動テストが無い又は不十分な現場も多いです。こちらのメリットとしてはスタンダートが低いのでキャッチアップ戦力になれるまでの時間が短かったり、小さな労力で大きな生産性改善ができ職務経歴書に書ける良いエピソードが作りやすいといったことが挙げられます。
また両者には人の出入りが激しいという共通点があります。そのためドキュメントの有無にかかわらず新しい人が参加し、教育や環境構築を行いタスクを振って実務を行うという、一連の受入業務に現場の担当者が慣れています。またこれは両者それぞれのところで触れましたが、理由はそれぞれ違いますがキャッチアップして戦力になるまでの時間は小さいという共通点があります。
デスマーチでは残業が多いと思われていますが、新人は戦力として期待していないので残業する必要はないです。マネージャーからすると、無駄な残業代は払いたくないし事故って仕事を増やすリスクも嫌なので、1秒たりとも残業してほしくありません。早く帰ってリフレッシュするなり自習するなりしてプロジェクトのリスクを減らしてください。
そのため、デスマーチに入って残業というのは底辺層にとってはほとんどの場合杞憂です。テスト要員としてでも残業を頼まれたら戦力に数えられている事を喜んでも良いと思います。
翻って比較対照としてみなさんに人気のあるWeb系企業を考えてみましょう。GoogleやNetflixとまではいかなくても、ほとんどの会社ではそれらを模倣しています。共通点としてはだいたい自走・自律できることが求められます。辞める人は少ないので比較的受け入れ体制は整っていないケースが多いです。企業によってスキルレベルはピンキリですが、周りとのスキル差が大きくなるのでキャッチアップにかかる労力と時間は大きくなります。開発プロセスは整えられているため、あなたが工夫して改善できる余地は少ないです。
ここであなたが採用する立場になったと想像してください。「最新の技術スタックで言われた作業をやっていました。ついていくのがやっとで自分で工夫した点は特にないです。勉強はがんばりました」という人と、「技術スタックが古かったのですがXXを導入してXXをXX程改善できました」という人がいたとして、どちらが戦力になりそうでしょう？どちらを採用したいですか？
ここまで書いたことを理解して謙虚に面接を受ければそう悪い結果にはならないと思います。
現場の技術レベルが高い現場を望んでもメリットは無いので、少しでも自分が成果を出しやすい環境を探しましょう。
