  |
はてなキーワード:OJTとは
> 「AWSの運用の強みは、経験豊富な余剰人員によって築かれており、人員削減を行えば、基本的な機能が崩壊し始めます」
たいていの現場で、新入りのエンジニアが「ドキュメントが充実していてありがたいです」的なセリフを吐くことがあまりに多いんだけど、正直なところ、ドキュメントが大量すぎて、AI使おうが「これ」という情報が見つからない。いや、そもそも必要なドキュメントが存在しないことしかない(日本語が変なんじゃない)。
ドキュメントの書き方を、OJTで形式的にしか学んでいないんだろうと思う。
そんでもって書きっぱなしで、「あ、今はそうじゃなくて、こうなってます」って口頭で伝えられることがあまりに多い。いや、修正しておくか、削除するかしろよ。
って、そんなどうでもいい経緯なんていらんわ！
経緯が分かったところで、何の役に立つと考えてるんだよ？
昔、アホなエンジニアありき。って記録以上でも以下でもないだろ。
そんでもって、正しいドキュメントがあったとしても、読んでも大してプラスにならん。
なぜなら、ただの自分用の備忘録以上でも以下でもないものでしかないから。
誰に向けて、何を伝えるためのドキュメントか、ちゃんと意識して書かれた技術ドキュメントに、ほとんど出会ったことがない。
って、なぜそれがこのタイトル、この内容のドキュメントに紛れ込んでるんだよ！
みたいなことがあまりに多い。
しかも最新化されてない。
たいていムカつく東大の〇〇研究室の量産型卒業生なんて、「これくらいできて当然でしょう」的に他人を小馬鹿にしたような態度をとってきやがるんだが、そいつらも普通の人よりキャパが少し大きいだけで、色々積み上がってきて、見落としが増えてきたら誤魔化しまくって、誤魔化せなくなったら「新しいことをしたいので」とかもっともらしい言い訳してやめていきやがる。
おい、これ、どうすんだよ！
残ったエンジニアには、つくり散らされた無秩序なサービスを「運用でカバー」の日々。
こういうの、マジで普段使ってる単語の意味、理解してねぇんだな。
単語帳みたいに訳、定義を丸暗記してるだけなんだな、ってため息しか出ないんだが。
これ、その場その場の行き当たりばったりな設計実装を増やしてしまうと、今時の複雑化、成長し続けるWebサービスは、簡単に認知力の限界を超えてしまうから、いくつかのパラメータからどこでも同じルールが適用されている状態にして、認知負荷を下げるってのが、ここ10数年のシステム構築界の常識なんだわ。
KISSの原則も、認知負荷を下げる(上げない)って文脈の上にある。
他の、いろんな手法だなんだも、基本的にこれを前提にしている。
のに、いわゆる「識者」は、箔をつけようとしてるのか知らんが、毎秒いろんな要素を取ってつけて、ゴテゴテとした悪趣味な神殿にして、崇め奉る「信者」から金を巻き上げようと、勉強会開いてるだろ？
おいらに言わせれば、「認知負荷を下げられない手法はくそ。カーゴカルトだ」だ。
今の日本のどのWebサービスも、いつ大規模障害を起こしてもおかしくない状態だよ。
「今動いてるからいいっか w」
じゃねーんだよ。
新卒で同期200人くらいの企業に入って、同期が20人くらいいる部署に配属された。
社内でも特に忙しい部署で、一年目の同期も毎日早くても19時、遅くて24時まで残業をしている。
でも私はめちゃくちゃ暇。今も暇すぎて増田をしている始末である。
・9月入社なので、4月の同期と比べて使えないので仕事を任せられない。私に仕事を任せるということは仕事を教えるということなので。
・OJTの先輩、めちゃくちゃ仕事ができるし、表彰とかもされている方なので新人に構ってやる暇がなさそう。
・私は背が低い、気の弱そうな顔をした女なのでゴリゴリ働いてゴリゴリ稼ぐ先輩社員たちからしたら扱いづらいのだと思う。でも学生時代は登山部で数日かけて山を登ったり一人で中南米に行ったりしていたので体力もメンタルもそこそこあるはずなのだ、、
仕事をもらえるように今していること
・毎朝OJTの先輩に「今日の午前中は◯◯やります。午後からの仕事は特にないので何か任せていただけると嬉しいです。もしなければ◯◯（マニュアル読むとか、資格勉強とか）します」みたいな感じで仕事を催促している。→2-3時間で完結する仕事をもらえる。先輩はいい人なのでFBもみっちり30分〜1時間かけてくれるが、これが負担になって仕事を振りたくない、、みたいな気持ちにさせていたら申し訳ない
・同じ部署の別の先輩に「手伝えることはありますか！？」と聞きまくっている。→たまに仕事をもらえる。嬉しい。
これでも定時内に仕事が終わってしまうし、何なら仕事がゼロの時間が1日に2-3時間はあるので苦しいです。今まで通り空気読まずに定時に帰っていいんですかね。どうすればいいですか先輩（この時間にはニートしかいないか）
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
ブコメやトラバに散見される「外国人を入れるから日本人の賃金が上がらない」「そんな会社は潰れればいい」といった主張。率直に言って、それ、経済としてかなり雑。
制度運用のまずさや個別の不正はもちろん是正すべきだけど、議論を“原理”レベルにまでざっくり落として整理してみる。
単純な時給の見比べで「安い」と即断するのは間違い。企業が負担するのは賃金だけじゃない。実務で発生する総コストはだいたい次の足し算だ。
・就労資格管理・法令対応（書類、更新、監査対応の事務コスト）
・言語・業務トレーニング（OJTの延長、通訳配置、マニュアル整備）
・離職・帰国リスク（短期で入れ替わると採用・教育が再度かかる）
時給が同じでも、これらを積み上げると総コストはむしろ割高になる局面が珍しくない。
にもかかわらず企業が受け入れるのは、「人が来ない（応募ゼロ）」という数量制約を解消できるから。
価格（賃金）より数量（確保できる人手）のボトルネックが効いているという理解が先。
「淘汰されるべきゾンビ企業」をなくせば生産性は上がる、という話はマクロの教科書にある。
ただし現実の現場は、介護・建設・農業・外食・物流のような需要が日常的で代替しにくい分野が多い。ここで雇用を一気に消せば何が起きるか。
・介護：入所待ちが延び、家族の介護離職が増える（世帯所得の目減り）
・農業：収穫期の人手不足＝出荷量減→価格上昇（食品価格の押し上げ）
要するに、企業の退出は「価格上昇」や「サービス縮小」という形で私たちの生活に跳ね返る。
退出を促すのが正しい分野もあるが、「人手が足りないから外国人に頼っている」タイプの仕事は、退出＝社会的機能の喪失になりやすい。
“いつでも”そうなるわけではない。給与は「生産性×交渉力×市場の需給」で決まる。外国人の増加が賃金に与える効果は、代替関係か補完関係かで変わる。
・補完の例：
介護現場で基礎業務を担ってもらう→日本人職員は記録・家族対応・加算取得など高付加価値業務の比率が上がる→組織全体の生産性が上がり、昇給余地が生まれる。建設でも同様に段取りや重機オペに日本人が集中できる。
・代替の例：
完全に同じ仕事を同じ条件で取り合うなら下押し圧力が出る。ただしこれは“違法・不適正な低賃金”が放置されている場合に強い。
対処法はシンプルで、同一労働同一賃金の厳格運用、最低賃金・労基法の監督強化、仲介手数料の透明化・上限など「ルールの執行」。受け入れ停止ではなく、待遇の底上げと平準化が筋。
現実には、人手不足が恒常化している職種では、受け入れによって「賃金は維持〜やや上昇、サービス崩壊は回避」という結果になりやすい。賃金を押し上げるには、受け入れを止めるより、付加価値を高める投資（DX・装備更新）とルールの下支えのほうが効く。
厳密な統計は置いて、粗いマクロの感触だけ掴むための思考実験。以下は“仮定”の数字。
仮定A：外国人労働者のシェアを全就業の3%とする（実際は職種によって偏在）。
仮定B：該当職の労働供給の賃金弾力性を0.2（賃金10%上げて労働供給が2%しか増えない、というイメージ）と置く。高齢化が進む現状では保守的に低めの値。
目的：同じ生産量を保つために必要な賃金上昇率（Δw/w）をざっくり求める。
必要な賃金上昇率 ≈シェア ÷弾力性 = 0.03 ÷ 0.2 = 0.15（=15%）
→物価やサービス価格に広く押し上げ圧力。とくに人件費比率の高いサービスは直撃。
必要な賃金上昇率 ≈ 0.15 ÷ 0.2 = 0.75（=75%）
→現実的にそこまで上げても人が来ない可能性が高い（地理・時間帯・体力要件）。結果はベッド削減・待機増・家族負担増に。
必要な賃金上昇率 ≈ 0.10 ÷ 0.2 = 0.50（=50%）
波及：
物流・建設の遅延＝あらゆる産業のコスト増 →さらに価格へ。賃金は名目で上がっても、実質所得（物価を差し引いた手取り感）はむしろ悪化しうる。
1.同一労働同一賃金の徹底＋監督強化（違反には実効ある罰則）。
3.日本語・技能トレーニングへの公的支援（現場の生産性を直に上げる投資）。
4.自動化・省力化投資の加速（“人にしかできない部分”を厚くする）。
5.在留資格の明確化とキャリアの見通し（短期回転を減らし、教育投資が回収できる関係に）。
受け入れを「止める/入れる」の二択にせず、“入れるなら同じ土俵で”を徹底しつつ、同時に生産性を底上げする。これが賃金を上げつつ、サービスの崩壊も避ける、一番現実的な線だと思う。
まとめると――
「安いから使ってる」ではなく「人が来ないから使ってる」が先にあり、ルールの執行と投資こそが賃金とサービスの両立を可能にする。
自分の経験だとこっちがどんだけ骨折ってもダメな人はいると思ってるけど、こいつダメだなって言えるのは本当に骨を折りまくった人だけだとも思ってる
その新人に対してはナレッジも含めて網羅してるドキュメントかレクチャーの動画を渡して数ヶ月様子見てダメだったら諦めてもいいと思う
レクチャーのなかでAIを実際に使って「この課題をこうすればこうなるから、こういう面便利だよ」とかを教えて、その様子を動画撮っていて参照できるようにしとくとかね
逆にそういうのをしてなくて口頭とかOJTでやってるんなら教える側の努力不足と思う
しっかり面倒見てあげてほしいな
あと今までどの職場でも入社してすぐシゴデキ判定もらってIQ130以上の俺でも、入社直後は異業種や異職種だと簡単な内容でも頭に入りにくかったし記憶も抜けが多かった
1人目は新卒入社の人だった。やる気はあったが、専門性が高いため、仕事は中々覚えてくれなかった。1人にするわけにいかないため、付きっきりで仕事をしたが、やはり本人には合わない仕事だったみたいで、希望もあっての異動となった。
2人目は隣の部署の人だった。何となくこちらの仕事を知っているのだが、やはり専門性が高く、中々仕事を理解してくれなかった。まあOJTだけじゃ無理なものは無理だと思った。最終的に元の部署へ戻っていった。
3人目は、出来たら経験者、最悪仕事が出来なくても別の仕事を任せられるような人でという事で希望を出したが、即戦力が来た。持っていた仕事全部やってくれるし、前職のやり方を小出しにしてくれて、こちらも勉強になっている。やはり即戦力は正義だ。
作年末、別部署の先輩に「どう？忙しくなってきた？」と話しかけられたので
「だんだん忙しくなってきましたね。〇〇さん(私のOJT担当の社員)ほどではないですけど……」
と返したところ
とめちゃくちゃ驚いたリアクションされて、呆れ果てた感じでツッコミを入れられた。
確かに、
「お前より世話係の社員のほうが忙しいのは自明だろうに、なんでわざわざそんなこと言うんだよ」
という違和感を覚えるも分からないではないのだが、別にそんな大袈裟にツッコミ入れてくるほどの返答ではなかっただろうと心の中でモヤモヤしている。
「往年の上方漫才みたいに間髪容れずツッコミを入れ、直後に呆れてみせる」
ムーブをするのをやたらめったら目にする。
また同時に、
相手の発言のなかに「ツッコミを入れる余地が何かないか？」とアンテナを高くしてそのチャンスを注意深く狙っているような人もやたらと多いように感じている。
例えば、
課長A「昔、〇〇社で✕✕があったじゃん。あれって結局どうなったんだっけ？」
課長B「いやあ、どうなったんだろ。あれ20年くらい前だよね？分からない…」
周りの社員「\\\ﾄﾞｯ///」
みたいな力業さえ珍しくない。
それとも日本の社会人、あるいは外国の社会人にも同じように備わってるもんなんだろうか？
個人的には、なんか日本のバラエティ番組の影響を結構受けちゃってないかと疑っているんだが実際のところどうなんだろうか？
そこに1年前に入社した。
OJT中心のところで、自分は技術習得の一環として一人の上司のもとで、指導を受けることになった。
しかし、その人は能力はあるけど、休職から復帰し時短勤務組で鬱病もち。
初めはその上司男性社員の言動や体臭に違和感だけ抱く程度だった、・・腋臭もちかな・・通勤電車でも体臭きつい人あるあるにも遭遇してたし・・・としか認識してなくて、あまりの悪臭に知らないふりをしていた。
立場的に面と向かって先輩・・・・においますって言い出しにくかった。
だが、その人は本当にいつも臭くて、夏にむけて汚臭がすさまじくなっていった。横で息ができない。むわっと汚臭が漂ってきてたびたび気分が悪くなる。
そして発達障害みたいな言動で話し方がいつもバラバラ。会話のやりとりもしにくい。私と会話していても一方的に長く話してきて、一方的に終わる話し方で次の話にすぐ入るタイプ。
それでも自分の技術習得を自分なりに構築しながら努力してみた。
臭いのを我慢していつも指導を受けるが、ガチ息吸えないから酸欠になりながら隣のPCで作業していく。マスク2重でも臭いし、呼吸できなくて息苦しかった。
本人目の前にマスク越しに会話をしていると、呼吸するために頻繁に角度を変えて息を吸わないといけない。
腐った生ゴミや掃除していない糞尿部屋臭っていうの・・・たまに地下鉄で見るホームレスから漂うようなあの強烈さ。
歯磨きも洗髪もしないから、体中ギトギトで口臭やばい。風呂に月１しか入らないらしいし、いつも同じ服。
帰宅してすぐにそのままの状態で寝て起きて出勤してくる信じられない生態系。。。
それでもかつては優秀だったらしい。
消臭スプレーや消臭剤、デスク用の小型空気清浄機を置いても一切効果なかった。
あまりのひどさに会社に訴えても「においの問題はあつかったことないなあ」「うちでは事例ないし、臭いなんて注意できないよ」「せっかく復職したのに傷つくでしょ」「指摘して傷ついて来なくなったらこちらの業務がまわらなくなる」
いろんな部署にスメハラの件を相談したり、頼んでみたが、まったく効果なかった。
そんな生ぬるいもんじゃない
体臭に耐えれず、今度は私の尊厳が脅かされていったように感じて私のほうがボロボロになっていった。
そして適応障害に至る。
臭いのもう勘弁やで
ほんとに体臭はある程度なら自分も耐えれるが、洗濯も風呂も歯磨きも洗髪も・・・人として最低限の清潔感だけは持って社会にでてよ
数年前の思い出話。中小IT企業の採用面接に「現場の若手」ポジションで入ることがあった。
募集要項は本当にこの条件の人材を現場で必要としているのか疑問になるほどユルい条件だったが、上司曰く「これくらいユルくしないと人が来ない」「何か欠点があっても大きな魅力があれば採用しないと人が足りない」とのことで、その判断をするのは上司なので黙って面接に参加していた。
求職者からの条件面や求められる人物像などの説明は上司が返答するが、たまに「〇〇のようなことは苦手なのですが、現場でキャッチアップ出来るでしょうか？」のような実務に関する質問は自分が返答する流れ。
自分は嘘にならない程度に印象の良い返答をしていた。
例:「〇〇が得意なメンバーが居るので、OJTしっかりやれますよ(得意なメンバーはクソ忙しいのでOJT担当を果たしてやれるのかは微妙)」
ただ、たまに明らかに上司が嘘を被せてくることがあった。「〇〇についてしっかりレクチャーします！」「最近は開発が落ち着いていて、教育の時期なので心配しないで！」
面接のあと、上司に聞いた。「開発が落ち着く予定とかあるんですか？」「そんなものはないけど、採用前に変に不安がらせると来ないから。採用したら皆なんだかんだ乗り越えるから」
人がどんどん辞めていくような職場だと、嘘ついてでも採用してそのなかの何人か1人気が弱い人が居れば御の字なのか。なりふり構わないってこういう事なのだなと勉強になった。
夏休みの宿題って、中学からあってもいい、高校はあったほうがいい位の認識。
さすがに意味がないとは思わないけど、計画的に進められなかった子の失敗体験を色濃くすることのダメージの方がデカすぎる気がする。
新卒だって仕事の進め方はOJTなりなんなりで教えてもらいながらやるのに、
宿題の手本は家の中でしかあり得ない上に、家庭環境に差がある。
やってこなければ怠け者、やる気ない子の烙印を押される。環境の要因が大きいだろうに、失敗を個人に帰属させる。いい子であれ、の呪いと祝福を受けた子どもたちには弱点属性をつかれたようなもので、「ええ、私はどうせ怠け者ですよ」などの防御反応的開き直りコースに進むしか自分を守れない。
やめよ
学生時代から10年くらい付き合った元カノと別れて、職場の後輩だった今の妻と結婚した。妻とは出会って4年くらい、結婚して1年ちょっと。けど正直飽きてる自分がいる。元カノとは10年も付き合ってたのに、別れる直前までずっと楽しくて、飽きるなんて考えたこともなかった。
元カノは一緒にいて最高に面白かったけど、結婚を考えると不安な部分が多すぎた。メンタルが不安定だったし、仕事は嫌い、子供も苦手、家事もイマイチ。買い物好きで、ちょっと贅沢なタイプだった。未診断だけど、たぶん軽度の発達障害っぽい感じもあって、長く付き合ってたから愛着はあったけど、将来を考えると踏み切れなかった。
今の妻にプロポーズするタイミングで、やっぱり元カノが忘れられなくて、ダメ元で復縁しようかと本気で考えた時期もあった。連絡取ろうとしたけど、彼女、もうこの世にいなかった。それで諦めて、妻と結婚することにした。妻はパートナーとしてめっちゃしっかりしてるし、うちの男だらけの職場で他に出会いもなさそうだったから、「まあ、これが現実的な選択だよな」って自分に言い聞かせて結婚した。マリッジブルーだろ、って思ってたけど、1年経ってもなんかモヤモヤが消えない。
元カノのことは今でも思い出す。あの子の魅力は、めっちゃ面白くて、顔も綺麗な上にタイプで、笑顔と声が特にかわいくて、エッチなこともノリノリだったこと。バカみたいな話で盛り上がったり、コンギョとか淫夢ネタで笑い合ったり、夜の話でも気軽に「こういうのやってみたい」って言ったら楽しそうについてきてくれる感じ。あのテンションは、妻にはないんだよな。
妻と出会ったのは、彼女が新入社員で俺がOJTの担当になった時。めっちゃフレンドリーで、誰とでもすぐ打ち解けるタイプ。ほとんど友達がいない元カノと違って男女問わず友達がたくさんいる。自然とプライベートの話もするようになって、元カノの話したら「え、それちょっとヤバくない？」って反応されて、ハッとした。自分でも薄々気づいてたけど、見ず知らずの後輩に言われて現実を突きつけられた感じ。
後輩は節約だといって毎日弁当作ってくるくらい料理が得意で、仕事も真面目。元カノとは正反対。ある時、ボーナスが出たからって、弟の大学合格祝いのプレゼント選びを手伝ってほしいって言われて、一緒に買い物に行った。それが元カノとの別れのきっかけになった。自分へのごほうびにボーナスで憧れのブランドの財布を買いたいって言うから、ついて行ったら、元カノが大好きだったブランドの店だった。元カノはそこにフラッと入って、店員に「いつもありがとうございます」ってチヤホヤされながらポンポン買い物してたけど、妻は「やっと買えた！」ってめっちゃ大事そうに財布持ってた。その差に、元カノの金銭感覚が自分の中で思ってた以上にぶっ飛んでるって気づいた。妻 後輩に話したら、「うーん、結婚するならちょっと考えちゃうかも」って言われて、なんかそれがトドメだった。
あと、街で子供見たとき、後輩が「かわいい！」ってニコニコしてたの見て、びっくりした。元カノは子供見るとムスッとしてたから、後輩の反応が新鮮で、なんか「こういう人と一緒になるべきだよな」って思った。買い物の後、飯食いに行っても、後輩はなかなか奢らせてくれなかった。元カノは財布出す素振りすらなかったから、余計にそう感じたのかも。
それで元カノと別れて、後輩と付き合い始めた。付き合ってみると、ほんと家庭的で、倹約家で、仕事熱心で、子供も好き。結婚向きなのは間違いない。でも、正直、付き合ってから物足りなさも感じるようになった。話がちょっと平凡っていうか、夜の相性もなんか淡白。元カノとガキみたいなアホ話で盛り上がったり、変なノリで笑い合ったりした楽しさが、妻にはないんだよな。
あと、妻のフレンドリーな性格も、増田に入り浸るような陰の者の俺には少し厳しい時もある。元カノは、同性の友達が僅かしかおらず、当然異性の友人なんていなかった。付き合ったのも俺が初めてだと言っていた。妻は異性の友達もそこそこいるし、人並みに恋愛経験もある。別に処女厨とまでは言わないが、全く気にならないといえば嘘になる。束縛が強いところもかわいかったな。躁の時は元気いっぱいで、丸一日ろくに連絡もしてこないのに、鬱気味になるとわかりやすく甘えてくるのも猫みたいでかわいかった。楽しそうに笑ってる彼女が一番好きだったけど、俺に縋ってくる鬱気味な彼女も好きだった。
生活面でも、俺、わりとズボラで部屋が汚くても気にならないんだけど、妻は結構細かい。しょっちゅうダメ出しされる。元カノは俺以上に片付け苦手だったから、なんも言われなかったんだけどな。今思えば、元カノとは喧嘩したこともなかった。妻とは付き合ってた頃からたまに衝突することがある。
妻と一緒だと、ちゃんとした生活できるし、パートナーとしては絶対にいい選択だったと思う。元カノは子供嫌いだったから、妻と結婚しなかったら子供を持つ未来もなかっただろうし（まだ子供はいないけど、妻は前向き）。でもさ、最近、収入もちょっと上がって、生活も安定してきた今、元カノと結婚しててもなんとかなったんじゃないかって思う時がある。元カノの実家、実は結構金持ちだったし、彼女の浪費も生活が破綻するレベルじゃなかった気がする。そもそも俺ってそんなに絶対子供欲しかったっけ？別に好きな人と2人で楽しく過ごすのもよかったんじゃないか？そもそも、元カノと付き合うまで結婚願望なんてなかった。ただこの人とずっと楽しく過ごしたいって思ってただけなのに、いつのまに結婚の条件とか現実的なことを意識するようになっていたんだろうな。ほんと一緒にいて楽しかったんだよな、あの子。
仕事をする上で、自分が扱っているものがどういうものか理解しているってのは当然の話だ。
試験受かりました！
っても、目の前のプロジェクトの中身とか勘所とか本質を理解できてなかったら、ただのタイムキーパー以下の存在でしかない。
ましてや、OJTでやってきました！
って言われてもな……。
システムって、本質的に「今存在しないもの」を作り出すことなので、予定通り、スケジュール通りってのは難しい。
工場の生産や建物の建築みたいに、物理法則の制約を受けて、ほぼお決まりの構成を組み合わせるだけだから、プロジェクト管理(生産管理)が定石通り進む訳だし、それでもうまく進まないことだってある。
建築途中に、欠陥を検査する仕組みもあるし、「数ミリなら問題ないと」って大成建設が札幌で建物をまるっと取り壊して建て直すなんてこともあった。
けど、システムはそういう仕組みないんよね。
指標もないし(いや、ないことはないけど、指標として機能するのか？ っていうと……)。
1、2年で、サービスの機能追加などがスタックする、ってことは、いろんな現場で起きてる。
初期に埋め込まれた設計上の瑕疵は、後から修正するのが難しいことが大半だから、そこから復活させるのも難しい。
80％程度は作り直すしかない。
おいらは、その作り直しをいくつもしてきた。
金かけたのに機能は増えてないどころか、減ってる。ってんで何人の経営者に逆恨みされてきたか……。
何年も開発してきたもんと同じだけの機能を半年とかで完全に実装なんてできるかよ。
経営者とかは、キラキラした素晴らしいサービスで、どんどん新機能を追加できて〜、とか信じ込んでるし、信じ込まされてるけど、実際はそうじゃなかったって、ある日知らされるんだ。
初期関係者たちがトんだ後に。
後に残されたエンジニアはどこに手を出していいかわからない、固まったスパゲティーを前に、毎日ドキュメントを書いて誤魔化すしかやることがなくなる。
そう言う未来が待ってるってのに、全てがそのまま惰性で進む。
最近思ったのが、PMなんて、人事評価の項目に、「スケジュール通りリリースできること」というのがあって、「根本的に間違えているから、将来に禍根を残す設計ミスがあるから、仕切り直しをする」と判断するインセンティブが存在しないんよな。
でも、理解できないんだろ？
エンジニアリングの知識、技術力、洞察力等々の欠如によって、何が起こってるか、近い将来何が起きるか、理解も認識もできてない。
とにかくリリース最優先で、全てが先送りになっていく。
その負債、すぐに返せなくなるよ。
こんなの昔のSIerとかあるあるだけど、今時の自社サービスはSIerと違って、納期に押し込んで検収受けれさえすればOKってわけじゃない。
その作ったやつを起点に、さらに機能を追加したり、既存機能を変更したり、保守運用を続けなきゃいけない。
すぐに破綻するよ。
1人の人間の人事評価のために、サービスの、会社の将来を潰す。
まぁ、本人はそれを理解してないんだが。
14手先で詰み。
は理解できないよな w
って評価されてるんだが、おいらが語っているのはシステム工学的な知見だ。
まぁ、頑張れ。
おいらは手を引く。
転職活動を経て管理職として中途で入社し、現在3ヵ月が経過した
最初は現場OJT。現場を知らなければ管理も務まらないというところで、現場は1ヶ月もない程度、残りは管理職のレポート作成を着手してみたりと慣れない業務で時間が秒で過ぎていった。
3ヵ月経過して、現在はSV業務の習得としてレポート作成を覚えていっているが、あまりにも現場が合理主義すぎる。
研修も最初は丁寧に教えてくれはしたものの、そのあとグッチャグチャになっているExcel関数ファイルを雑投げ。
どこを見てもVLOOKUPの完全一致検索しかなくファイルが激重すぎて処理が何度も停止した。
そのたびに修復や復旧を繰り返したり、数字が一部おかしくなり正しくRAWデータが反映しなかったりと、完全初心者殺しだった
そうこうしている内に作業に時間を費やす日々が続き、初めてレポート着手しているにも関わらず「時間が結構かかっているようなので効率改善のためになにが原因か考えましょう！」」と言われる始末。
初めてってそういうものじゃないですか…？
効率改善って慣れてからするものでは…？という考えの私にとって、この一言は「3ヵ月でも即戦力なので常にフルスロットルでやりきって」と言われているようで非常に辟易する言葉だった
私の甘えももちろん含まれているのだろうけども、これまでの職場はフラットな環境だったため現場の声を吸い出しやすく、「とりあえずやってみてだめなら戻しましょう」が通る職場だったため、
現在の職場はなにをするにしても「それよりも優先度が～」「インパクトがない～」などと言われ改善提案も握りつぶされたり後回しにされたり
そうこうしている内にガンガンタスクを積まれ「必要な知識なのでやってみてください」と言われ断ることもできない
会議の在り方も定義づけしろと言われ、正直「いやおまえがやれよ」とも思う
もうなんか語彙力がなくなるくらいだるい。タスクに追われるのは管理職として別にゆくゆくそうなる未来は見えているが、ある程度慣れるまではもうちょっとバッファを設けられるくらいのタスク量を分配してもらいたい
ちなみに上司の上長にあたる人に相談はしたものの、なにやら取り付く島もなかったらしい
とりあえずこの部署が自分の肌身にあわないことだけはめちゃくちゃわかるので、入社して3ヵ月だが部署異動を希望してもよいものか人知れず悩んでいるところ。
システムとか、Webサービスとか規模が大きくなると、決定的に抽象思考が必要で、中でも高度な「複数層の抽象レベルを扱う能力」が必須なので、具象思考しかできない「プログラマ」が出世してその辺りをいじり出すと、詰む。
マイクロマネジメント的にでかいシステムを扱うから、うまくいくわけがない。
なんかわからんけど、これをやれと言われてやってきて、やれてきた。
それの積み上げ。
新しく「××しなけりゃいけない」となったら、今時は便利で、ググったりAI使ったりすれば、HowToが並ぶ。
背後にある体系的な思考法とか、歴史的経緯とか、密接に関係する概念とか、全部すっ飛ばして、HowToだけ集める。
すると、全てがチグハグになる。
一個一個、ミクロに見ると、その場その場はそれっぽく見える。
ちゃんとやれてるように見える。
でも全体を俯瞰すると、背景にあるはずの何層にも渡った網の目のような抽象構造が存在しない。
DDDはこの「何層にも渡った網の目のような抽象構造」のための方法論の一つだって理解しないと、多分正しく適用できない。
画面に対する必要十分な実装とだけ考えると、画面に引っ張られまくる。
が、そこで扱われているデータは、ドメインレベルの抽象度のあるコンセプト(オブジェクト)であり、それにまつわる操作や属性を並べておけば、画面はそれの1断面を切り出しただけ、ってのがわかる。本体のコンセプトがちゃんと捉えられていれば、画面の常識の範囲内での変更は、大した影響はない。せいぜいが属性を増やす(そのあたり、DBの1カラムにしないで、Jsonにぶち込んでおけば、テーブルの変更すら不要な)程度の変動しか起こらない。
そして、それが変更容易性につながっているし、Jsonの1要素が増えるだけなので、処理の根幹は変わってないから、余分なテストは不要、ということだ。
そういう背景とかを知らんでDDD、特にこの「ドメイン」を「業務ドメイン」とか勘違いしているアホウには、到底辿り着けない境地だよね w
と、多分、今の日本のエンジニア業界の致命的な欠陥を指摘してみた。
あー、ちなみに、最近、AI、AIと言われるようになったけど、抽象化しないで具象レベルでAIを投入して多量のソースを生み出したら、まず間違いなく管理不能に陥るからな w
たとえば居酒屋で不審者に絡まれて警察呼んだとき、変人職質対応歴15人の猛者が来るのと、変人職質対応歴0人のかわいい警察官が来るのとどっちが嬉しいのか
圧倒的に前者の方が嬉しいだろ。お前が不審者側ならかわいい警察官に確保される方が嬉しいかもしれないが、本当に問題解決してほしい人は前者を願うわけ
強制できないけど完遂しないといけないという変人相手の職質は、無料で提供される高品質なOJTなんだよ
いい加減それを認めなさい
お前が先に認めたら俺も宣言するよ
パナソニックはなにを考えているのだろうか。自分にはよくわからない。
今回は1万人のリストラが数値目標になっている。国内5000人、海外5000人だ。
ここで気になるのがパナソニックは年間3500人の採用を行っているというところ。
分社化以降の2年間で7000人を採ってしまった結果、5000人が余ってしまった。なぜ分社化で7000人も必要になったのかというと、分社化する前は社内異動で余った人材を融通できていたのが、分社化後はそれぞれの事業会社内でしか人材を探せなくなってしまい、結果的に余った人は外に放出できず、足りない人は採用する必要があったからだ。
新卒から叩き上げるのが社風だったパナソニックが最近中途採用を大量に募集し、採用数の60%が中途になっていたのも、即戦力を欲していたからだ。しかし実際にパナソニックのブラックな開発現場で即戦力になれる人材など中途で集まってくるわけもなく、最初の3年くらいはベテランの3割くらいのパフォーマンスが出せれば御の字で、一方でその分ベテランはOJTなどに時間を取られて1～2割パワーダウンしてしまうので結果的に全体としての利益率の低下や、それどころか品質の低下にも繋がっていると思われた。
自分としては大量採用して、大量リストラするという今回の方針が、正しい経営のありかたであるという十分な説明は今回できていないと思う。何が間違ってそんなに大量採用してしまったのかの説明がまずあるべきだろう。もちろん新規採用した人達は若手で未来があり能力もあるが、過去からパナソニックに残っている人達は無能で、だからリストラするんだという実情があってもいい。でもそれはそれで、パナソニックでは何のスキルも得られない仕事を延々とさせていましたという話であり、そこに対して今後このようなことを繰り返さないためにどう手を打っていこうとしているのかなどの説明が追加で必要だ。
これでDDDなんかできるわけないじゃん
サービスの根幹に当たる部分を、複数のありものフレームワークの比較評価ドキュメントをWeb記事から作り出して、どれを使うか決めるとか普通にやってて、「ここ、DDDを採用している現場だよね？(-_-)」って愕然としている。
DDDを実践してきた身としては、とても違和感があるんだが、今時の「イケてるエンジニア」ってそんなもんなんかな？
「Java書けます」っていう場合、ライブラリの使い方知ってます、とほぼ同義と聞いたことが、ないことはない。
ということは「イケてるエンジニア」ってのは、フレームワークの評価とか選択ができます、ってのと同義ってことなのか？
あり物の組み合わせは他の誰でもやれるから、固有のサービスとしての武器にはならんのだが、早く動いて市場占拠しさえすれば勝てる、って考えなのかなぁ？
「ドメインコンセプト」の概念がなければ、中心的なドメインコンセプトの抽出もできないから、何を内製しなきゃいけないかの判断もできない。
あるいはあれか？
そういうフレームワーク的なモノを作る技術力がないだけなのか？
どちらにしろ、エンジニア名乗るの、いかがなものかと思うが……。
恥ずかしくないのかねぇ？
