Shinnosuke Hirota

バックエンドエンジニア。筋トレ。分散システムをどう設計すべきかという命題に対して自分なりの答えを見つけたい。ここでの発言は全て個人の見解にのみ基づいています。

[広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi]

仕様が複雑になるのは、機能が多いからではなく、機能どうしが互いに干渉するからだ。直交していない仕様は、足し算ではなく掛け算で複雑さを増やしていく。確認すべきテストケースも、組み合わせのぶんだけ膨らむ。ではどうやって直交した形を見つけるかというと、要求の数を数えるのではなく、その背後にある「なぜ」を掘っていく。50通りに見える料金表が、基本料金と顧客区分と時間帯という独立した三つの軸の組み合わせに畳まれることがある。ここを取り違えたまま機能を足すと、複雑さは静かに膨らんでいく。要求の意図はコミュニケーションの飾りではなく、設計そのものに直接効いてくる。WHYは補足ではなく、設計図そのものだったりするのです。

https://t.co/eEPnfkbaJ5

[kawasima@99卒 @kawasima]

ドメインモデルの純粋性をレイヤー分離で担保する設計って難しくて煩雑だよなー、と再び感じたのでメモしておく。大したことしてないのにクラス作りすぎる原因になる。

[Shinnosuke Hirota @shin_developer]

多分これから厳選が進むだろうな。文系からでもSWEになれた時代が終わって、CSの知識を持ち、かつ頭がいい一部の層だけが新卒やジュニアとして採用されるとかありそうだなと。文系出身SWEは思いました

[Haruki Yano / Haruma-K @harumak_11]

コードを書かせるためではなく、シニアにするためにジュニアを採用せよ、という記事
https://t.co/AgvofNtQeM

・AIがコードを生成してシニアエンジニアがそれをレビューできるようになった今、給与コストを抑えるためにジュニアエンジニアを削減するのは合理的に見えるが、長期的には間違っている
・会社や業界が今後も生き残り成長し続けるためには、ジュニアを採用して基礎を築くことが不可欠である

・ジュニアが人前で急激に成長していく過程を見ることは組織全体に良い影響を与え、シニアはAIの言語モデルに対しては持たないような責任感を、指導する若手に対しては抱くようになる
・またジュニアは過去のやり方に固執する習慣がないため、チームにAIツールを新しく導入して定着させたい場合にも有利に働く

・現在エントリーレベルの採用が減っている本当の原因は、コスト削減と新しい価値の創造を混同している投資家にある
・その考えが経営層に波及し、目に見える成果が測りにくいジュニアが真っ先に削減の標的にされてしまっている

・AIを使うジュニアはコードを理解せずに出力するだけなので指導しにくいという意見もあるが、実際には数ヶ月で急成長して育成コストを下げる組織と、質の低いコードを生み出し続ける組織の二極化が起きている
・この違いは、組織が本気でメンターシップに取り組んでいるかどうかと、既存のエンジニアリングの基盤が整っているかどうかにかかっている
・古いコードやドキュメントの不足、指導者がいない環境にAIを導入し、その結果生じた問題をジュニアのせいにするのは間違っている
・今の時代に優秀なジュニアに求められるのは、単にコードが書けることではなく、成長したいという強い意欲や、困難を乗り越える気概を持っていることである

・今ジュニアの採用を止めて人材のパイプラインを更新しない組織は、5年後には変化に適応できず、知識の継承もできず、新人を訓練する余裕すらない状態に陥ってしまう
・その段階に達してしまうと、いくらお金を積んでも問題を解決することはできなくなる
・状況を正しく見ている企業にとって今は好機であり、採用されずに余っている優秀なジュニアを雇って適切に育成すれば、将来的に大きな競争力を得ることができる

[Shinnosuke Hirota @shin_developer]

スーツのバリエーションって量販店の中で圧倒的に青山が多い気がする

[Shinnosuke Hirota @shin_developer]

明日スーツ届くの楽しみ

[そーだい@初代ALF @soudai1025]

「◯◯が出来ません。」じゃなくて「我々には技術力が足りません」って言わないと次のステップには進まんだろ。
まずは自己認知よ。
今できないことが重要なのではなく、出来ないことを認知して体得していくために必要なステップを見つけて行くことが重要だろ。

[Shinnosuke Hirota @shin_developer]

linedinとかのビジネスsnsってどう使えばいいんだろう

[久松剛 IT・AX・DX・FDE組織づくりの水先案内人 @makaibito]

https://t.co/JtBBY2dh7v

[Shinnosuke Hirota @shin_developer]

大吉祥寺.pm 2026 に参加を申し込みました！ https://t.co/wpMhNSb8cA #kichijojipm

[Shinnosuke Hirota @shin_developer]

ゴールドジムに生息してるマッチョはスーツどうしてるんだろう

[Shinnosuke Hirota @shin_developer]

まだ体細いはずなのに、すでに合うスーツのサイズが厳しい。
AB4のスリムがかなりキツくて、BE4が選択肢に入ってくるけど既製品のモデル数がこっちは恐ろしく少ない

[Shinnosuke Hirota @shin_developer]

私は両方に書く派閥ですね。
ドメインオブジェクトに不変条件として記述し、違反を起こさないための契約としてAPIスキーマに伝播させる必要があると考えます。
冗長ではあるので削るとしたら、IF側の定義ですが、それは契約としてスキーマなどに表現できる場合にかぎるかと

[pospome@カミナシのVPoE @pospome]

"バリデーションはドメインオブジェクトとAPIスキーマ定義のどっちに書くべきか" https://t.co/Eh2LzyRBF4

[Shinnosuke Hirota @shin_developer]

セブンどこも折りたたみ傘置いてないけどなんで？もう売る気ないのか、売り切れなのかどっちだ

[Shinnosuke Hirota @shin_developer]

集約がトランザクション境界なのはべき論としてそうではある。ただ現実問題として不整合は許容したくないし、ドメインイベントをトリガーとしたワークフロー構築してリトライする仕組みにすると実装コストかかるので、現実解としてUsecaseに貼るに倒すは全然ありそう。

[ミノ駆動 @MinoDriven]

完全同意。
複数集約をまたぐ整合性維持はケースとしてそれなりにあるから、Repository内にトランザクションを張るのは現実的ではないし整合性を維持できなくなってしまう。

[加藤潤一(かとじゅん) @j5ik2o]

僕はこれとは真逆の戦略にしてる。
ユースケース＝トランザクション境界でデッドロックに苦しんだ経験があり…。
集約を跨ぐトランザクションをはっているなら、それこそが真の集約の境界。まぁ、ロールバックが不便になる代わりにデータ更新の依存関係が疎結合になるのでそのあたりトレードオフ。

[Shinnosuke Hirota @shin_developer]

先週末くらいに話題になったDeNAしかり、LINEヤフー、CyberAgent、ZOZO、エムスリーなど適当に有名企業数社くらい調べてみたけど、軒並みここ数年停滞してるな
インターネットサービス業界どうなるんやろな

[Shinnosuke Hirota @shin_developer]

技術力磨くのに、リテラシーが低いクライアントを説得する時間はかなりマイナス
いっぽうで大成すれば、どこからも必要とされる人材にはなれそう

[Shinnosuke Hirota @shin_developer]

やはり技術だけやってたい人にとっては良い選択肢じゃなさそう。金銭的待遇目当てにハードワークするならITコンサルよりも良いのかもしれない。

[酒井 駿 | スマートAI調達 @sakai_1910]

今まさにFDE的な動きをしてるけど、これマジで共感しかない。想像の100倍くらいハードです。

何がしんどいって、

1. 顧客のリテラシーの壁
特に中小企業だとITの前提知識がほぼない状態からスタート。言葉を尽くしてもなかなか伝わらないもどかしさ。

2. 業務フローの複雑さ
複雑怪奇なフローに、未経験の業界知識。そこへポンと飛び込んで整理していくのは至難の業。

3. 容赦ない「わがまま」への対応
今のやり方にシステムを合わせろと言われたり、無茶な要望が飛んできたり。ここをどう受け流して、どう手綱を握るかが勝負。

結局、ただ作るだけじゃなくて「お客さんを説得して、あるべき姿へ導く」という泥臭いクライアントワークが求められる。
理想と現実の板挟みになりながら一歩ずつ進める、本当に骨の折れる仕事だと思う

[Shinnosuke Hirota @shin_developer]

今更になって金融系のプロダクトの採用が盛んになってそうだけどなぜだ？NTTも参入するっぽいし、メガバンも内製化進めてそうだし背景が気になる