  |
はてなキーワード: SESとは
現場を見ていればわかるけど、BPをかき集めて数で殴る開発モデルはもう限界に近付いている。
SIだとコスト削減が真っ先に求められるので、上の人らは「人の代わりにAIを雇用する」と本気で舵を切り始めている以上、汎用的なスキルしか持たないBPが現場に潜り込める席はもうない。
ITの需要自体は減らないけど、求められるレベルが上がりすぎて並の人間は「需要の範囲」にはもう入れない。
指示待ち技術者の価値なんてマジでゼロ、下手したら普通にマイナスだと思う。
当たり前だけど要件定義の最前線にいる人やドメイン知識しっかり持ってる案件の柱みたいな人は全然余裕で生き残れるけど。
マネージャーが指揮するのは人間じゃなくてAIエージェント群あるいはAIで100倍の力が増幅されたつよつよエンジニアの少数チームだけになる。
SESで主体的に動けないメンバクラスや大手以外のSIerで要件定義すらパートナーに丸投げしていたプロパーは一気に居場所を失う。
ある意味業界が「健全化」されるわけだけど、あぶれた人間の受け皿なんて今後のIT業界には用意されないので今のうちにキーボードを捨てて体を鍛えておいてブルー転職した方がいい。
ITにしがみつくより生身の労働力を必要としている業界はいくらでもあるので、プライドを捨てて介護や物流に行くのが個人の生存戦略として一番正解なんじゃないですかね。
開発力ってところだとweb業務系はもうAIでほぼ完全に代替できる
（組み込みはハードやベンダの依存関係が大きいのでまだAIのコードをそのまま使うのは難しそうだけど）
テスターもAIがやってくれるしテストケースの設計さえできればあとはAIが回してくれるのでレビュアーも不要
テストケース自体も要件定義ができてればその時点でAIで生成できる
インフラも今はAIが勝手にクラウド経由でアーキテクト構築してテナントにサーバーDBを置いてくれる
「AIはまともにドキュメント作れない」とか言ってる人まだいるけど動けばいいのでそもそもそんなのいらない、AIにとっては文字通りコードがドキュメント、法令監査必須なとこは別だけど国の動向見てるとそういうのも減っていきそう
運用保守もAIに監視させてクラウドに可用性を投げれば基本は回る、障害対応も初動はAIが診断してくれる
（全部最初から作らせるとトークン消費がえげつないのでやり方を考える必要はあるかと、コストを考えると運用保守はあった方がいいが結局それもAIに監視させればよい）
要件定義できる人はまだ必要だと思うけど、ドメイン知識や決定権のある人がブラックボックスのサービスを作ればいい
つまり、プロパーの企画立案者が内部でプロダクトを決定してそれ以降の設計実装まではAIに投げればいいので、特にSIやSESらに金払う奴はいなくなる
あれ、育成論でもなんでもないからな。単に「スキルのない新人をねじ込める低単価案件がそこしかない」っていう、会社側の都合100%のポジショントークだ。
いいか、よく考えろ。
SES営業は口を揃えて「テストは品質の要。システムの全体像が見える重要な工程だ」なんて綺麗事を抜かす。じゃあ聞くけど、なんでそんな「重要」な仕事を、右も左もわからない未経験の新人に任せるんだよ？
本当に重要で、プロジェクトの成否を分ける工程なら、10年選手のベテランにやらせるのが筋だろ。でも現実はどうだ？ 現場にいるのは、昨日までプログラミングスクールに通ってたような奴とか、Excelのコピペしかできない連中ばかり。
結局、業界全体が「テストなんて誰でもできる単純作業」って見下してる証拠なんだよ。重要だなんだってのは、お前を安く買い叩くためのマインドコントロールに過ぎない。
単価を見れば一目瞭然だろ。
評価も報酬も業界最低水準。それが「テスター」という役職のリアルだ。重要だと言いながら金は出さない。やってることが矛盾してんだよ。
例えるなら、パイロットになりたいって言ってる奴に「まずは滑走路の誘導灯を磨け」って言ってるようなもんだ。そんなこと10年続けたって、操縦桿の握り方ひとつ覚えられねえよ。せいぜい「飛行機が動くのを間近で見られて勉強になりました！」って自分を騙すのが関の山だ。
一番タチが悪いのは、一度「テスター」としてキャリアをスタートさせると、「テスター属性」という呪いが解けなくなることだ。
職務経歴書に「単体テスト・結合テスト」が並んでみろ。次の現場も、その次の現場も「あ、この人テスト要員ね」って判断される。営業も「あいつはテストなら確実に決まるから」って、開発案件に挑戦させるリスクを取らなくなる。
そうやって、コード一行書けないまま「30代のベテランテスター（笑）」が完成するわけ。地獄だろ。
「下積み」なんて言葉に甘えるな。最初から「開発」ができる環境に死に物狂いで飛び込め。泥臭く自社開発を狙うか、せめて最初からコーディングをさせてくれるSES会社を選べ。
営業の「君の将来を考えて……」なんて甘い言葉は、お前を単なる「換金可能なコマ」として見てるだけだ。
テスターを長くやればやるほど、お前のエンジニアとしての寿命はゴリゴリ削られていく。気づいた時にはもう、キーボードを叩く指は仕様書のチェック項目を埋めるためだけにしか動かなくなってるぞ。
ウチは零細SESで、元請のオフィスに常駐してシステム開発支援をして、その対価として【発注金額】をもらっている。
で、常駐に必要な座席や機材は元請から「レンタル」扱いになっていて、ウチが元請に【席料】を支払う建て付けになっている。
ここまでは普通の話だと思う。
ウチから派遣しているのは5人なので、普通に考えれば【席料】も5人分になるはず。
ただ、実態としてレンタルされている座席・機材は5人分しかない。
つまり「存在しない3人分の【席料】」が計上されることになる。
ウチも元請も、数字上は出入りを相殺するだけで得も損もない……はずなんだけど、これっていわゆる循環取引ってやつじゃないの？？？
プライム上場企業であらせられる元請のご担当者様の仰ることが間違ってるハズがないのできっとワイの理解が浅いだけなんだろうとは思うけど……
CLAUDE.md や rules / skills みたいな形で、重要なコーディングルールはあらかじめかなり固めておく。
たとえば repository 層や Entity 層は具体的にどう書くのか、テストケースはどういう書き方をして、どういう観点で項目を洗い出すのか、みたいな AI への指示は最初から用意しておく。
あと、linter や ArchUnit、dependency-cruiser みたいなアーキテクチャ制約も、自分なりの定石を持っておく。
割と過剰なレベルでガチガチに固める感じで、アーキテクチャルールも「◯◯は XXX に依存できない」みたいなブラックリスト式じゃなくて、「◯◯は XXX だけに依存できる」みたいなホワイトリスト式の方が良いと思っている。
ts 前提だと eslint や tsconfig は一番厳しい水準に設定する、流石にきつい部分でてきたらそこだけ緩める、という運用
おすすめなのは、何かしらの小規模案件や個人開発アプリを1つオーバーエンジニアリング上等でガチガチ構成で作っておく。
そこで出てきた linter 設定やプロンプト設定を、別案件に横展開する感じ。
正直、ガチガチすぎると MVP とかレベルだとコード量は増えるけど、メンテする前提の案件ならバイブコーディング時代だと普通にペイすると感じている。
アイディアを思いついたら、AI と壁打ちしながら仕様を洗い出していく。
手書きでドメイン図を書いて、それを写メ撮って画像認識で仕様整理、みたいなのも割とアリだと思っている。
どういう画面があって、どういう入力項目や表示項目が存在するか、バックエンドはどういうエンドポイントが必要か、この辺りは最初に一通り洗い出しておく。
それに加えて、ユーザーが初めてトップページを開いてから登録・ログインして実際にサービスを一通り使うまで、みたいな流れをそのまま Playwright のシナリオテストに落とせそうな形で何パターンか仕様書にしておく。
フロントエンドで、DDD における集約みたいな概念がそのまま当てはまらない領域についても、設計時点で洗い出せているなら Entity 的なものやドメインサービス的なロジック用のレイヤを作って、ドメインオブジェクトとして実装していく。
最初に作った基本設計をベースに、◯◯Entity、XXEntity、△△Entity……を作るためのプランとチェックリスト形式の TODO を 1つの md ファイルに吐き出してもらう。
フェーズごとにフォーマッタ、linter、アーキテクチャルールなど一括実行したコマンド実行させて失敗してたら成功するまで修正繰り返させる。
ある程度わかりやすい単位で AI に依頼する感じで、出来上がったコードをレビューする前提なので、実装プランの md 自体はよほど分かりやすいツッコミどころがない限り細かくレビューしない。
mdのフォーマットは skills 側で事前に用意しておく。
フロントエンド用、バックエンド用の両方でドメイン層のファイルを作る。
当然、足りないロジックは後から絶対に出てくるけど、最初から完璧は目指さない。
TODO 一覧の中から自分の認知負荷が許す単位で「チェックリストのここからここまで実装して」と指示を出し、実装が終わったら TODO 項目のチェック状態を更新してもらう、mdファイルもコミットに含める。
コミット前にはlint ルールを無効化していないか、意図通りの実装になっているかは git diff の差分で必ず確認する。
git worktree を使うことが多い。
よくやるのはフロントエンドの画面モック作成とバックエンド実装の2並列で行う。
実装プランを考えてもらうときは「◯◯画面を実装プラン考えて」くらいの単位で依頼する。
実装プランの md ファイルを作るときのプロンプトには、基本設計の〇〇画面の項目一覧をベースに、◯◯のアイテムコンポーネント、リストコンポーネント、◯◯のボタンコンポーネント、Information コンポーネント、外部通信用の ◯◯Gateway を実装する、◯◯コンポーネントは既に ◯◯ 機能で実装してあるからそれを使って、◯◯は処理が膨らみそうだからドメインサービスで実装して、みたいな感じで頭の中のふんわりしたイメージを伝える。
バックエンドも同様で、◯◯のエンドポイントを作って、Gateway がこれこれ必要だから実装して、これはインターフェースと実装分けてね、Entityへの変換処理は関数分けて、◯◯の処理は Usecase 層で、◯◯の処理はドメイン層で、Usecase が膨らみそうだから ◯◯ の処理は独立したクラスにして、あ、似たようなのが ◯◯ 機能にあるからそれを参考にして、くらいの粒度で指示を出す。
フロントエンドの実装を待っている間に、バックエンドのプランを考えたり、タスク粒度を調整したり、リファクタリングプランを考えたりする、またバックエンドのAI待ち時間はフロントエンドのことをする。
フロントエンドオンリーの実装とかで作業が競合するリスクあるときは並列作業しない。
チェックリスト更新が終わるごとに差分を確認して、問題なければコミットメッセージを提案してもらってコミットする。
細切れにするコストよりも、レビューする人間の認知不可が許すレベルであればある程度まとまった単位でレビューして実装速度を優先する派。
テストは、ある程度実装が進んでリファクタリングが辛くなってきたタイミングで作ることが多い。
カバレッジやミューテーションテストなど、定量的にテストを評価できる仕組みは導入する。
バックエンド側のテスト実装は正直かなり楽で、行数や認知的複雑度を厳しく制限して単一責務の原則を守って実装しておけば、AI がかなり高精度なテストを出してくれる。
これもテストファイル実装プランを作ってもらって「ここからここまでのテスト20ファイルを実装してね」をレビュー挟んで繰り返す感じ、例えばミューテーションテストのkill率100%ならそんなに詳しくは見ない。
フロントエンドはテストの定量指標での評価が難しいので、そこはその分レビューを頑張るしかない。
自分はこんな感じでやっている。
感覚としては、優秀だけどシステムのアーキテクチャ全体の責務を負ったことはない経験不足の2年目やSESの部下を扱うEMに近いのかなぁ。
周りの話を聞いていると、もっともっと AI に自律的にいろいろやらせているようにも聞こえる。
これでも 1日1人で数万行レベルはコードを書けてるので、AIない時代に比べると数ヶ月分の成果を1日とかで出してることになるが、もっと本気出せるのかなぁ。
「全機能分プラン作ってね！そこから良い感じの粒度でコミットも自分でやってね！」みたいな指示を良い感じに出せたとしても、指示がでかすぎると、脆弱性盛々になったり、lint エラーループでパニクって linter オフにし始めたり、テスト通すためにエラー握りつぶして assertTrue(true) し始めたりする。
それは流石に許容できないレベルじゃない？が紛れ込むリスクが上がりすぎるんじゃないかなぁ。と思ってるんだがどうだろうか。。。
あとツールはあんま入れてないねkiroとかspec-kitとか、ガチガチ細切れで仕様書作るメリットもあんま感じなかった。
mcpもserenaくらいしかいれてないや、トークン節約してレートリミットの猶予伸ばした方が結局開発早くなるかなって。
いろいろ入れた方がいいんだろうか。
完全にオレオレでこんな感じでやっているんだけど、みんなspec駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。
https://note.com/igz0/n/n80b262ea33ba
なんかこの記事見て思いついた。きっかけなので内容はぜんぜん異なる。
40代男性、何度か転職して今はJTCの大きめの会社のシステム部門にいる。システムエンジニア。主に上流工程。PMとかPLってやつ。スキルは人並み。IPAの上級とかLPIC2とかその辺り
題名の通りで偉くなるには評価目標とか以外に付き合いってのが必要になる。なので営業から異動してきたやつとか1年外部のAI企業でAIサービスを企画・開発して出戻ってきたやつとかがどんどん偉くなってる。（後者は個人的には眉唾だと思ってる。1年で出来るレベルなら帰ってこないだろうし）
そもそも今の役職勢って今のシステムとか技術分かってるの？って思ってるし技術系の役員もいるけど経歴見たらバリバリ組んだり通信見てたよりは島耕作みたいに潤滑油ぶってたっぽい。純粋に社内でいろんなシステム携わっていて偉くなった人もいるけど弱いし、大勢のタートルネック趣味は筋トレコミュ強勢に負けている。チャットでの威勢だけはいっちょ前だが。
いわゆる社内政治じゃない評価している企業とかあるのかな。たぶん社内にシステム部門あるところとかは営業とかも絡んで恐らく同じだろうし、SESとかその辺はAIのおかげで怪しい。かといってとてつもない技術もないので研究開発も辛い。詰んでる
フリーランスになれとか言われそうだけどあれこそ営業力が肝だし、年収UPより大丈夫化の不安で身体こわしそう
同じような人いたらどうしているか教えてほしい。AIに聞いたら「まずは日々の活動を見える化しましょう！」言うけどそんな評価目標でやってること以外で悩んでるんだよっと怒ったらだんまり決め込みやがった。
