--- 追記ここから ---
（と思って一度書いたけど、その後「いや、AIがいい感じの判断を提示してくれるところまでは行きそうだな。。」って思い始めた。）
--- 追記ここまで ---

AIがどこまでできるようになってくるのかずっと考えていて、以前に以下の記事も書いた。

yaruki-strong-zero.hatenablog.jp

今回、なんとなく自分としては腑に落ちた考え方を見つけた気がするのでそれについて書いてみる。

結論から書くと「今のAIだとどこまでいっても判断する仕事は代替されずに人に残る」である。
これは「今はできないだけ」ではなく、仕組み上「できるようにはならない」だと思っている。

AIツールが存在するのに、僕に質問が飛んでくる現実がある

最近でもAIはものすごく日々進化していて、便利になるシーンも増えたと思うが、いまだに「この対応の進め方、案1と案2があるんですけど、どっちがいいすかね、、？」みたいな相談が飛んでくる。

社会人経験も10年単位で積んでいるとサクッと回答できたりする。

人単体が10年やそこらで得た知識など、AIの抱えている知識とくらべれば無いにも等しいと思うが、それがAIでは解決できずに僕に聞いてくるところが不思議な感覚があった。

なぜそんなことが起きているのかを考えた。

AIは精度の高い判断・決断ができない

AIは物事の重要さを決めることができない、ということなのかと思う。

一般的なことであれば判断できる。
例えば「同じことをできる2つの関数があるが、このシーンだとこの関数を使うべき」みたいなやつ。

しかし、今まさに自分（人間）の周りで起きている事象に対し、何が重要なのかの情報は持っていない。 その材料が圧倒的に少ない。 そして、全てをAIに渡すことはできない。非構造化データが多すぎる。

さらに、渡せたとして、それぞれの事柄に重要度をつけることができない。 「どの事柄がどれくらい重要なのか」の設定を人が渡してやらねばならないが、そもそもこれ自体が判断である。

少し理論の飛躍っぽいが、人が自発的にこれをできてAIができないのは、AIが個として生命活動を行なっているわけじゃないことによるのかなと考えている。　
人はこの重みづけを、死のリスクを避けることを源泉としておこなっているのではないかと考えている。

人が行なっている判断を大量に学習させれば精度の高い判断を模倣できるようになるか？

以下理由で不可能だと思っている。

・学習機会が少なすぎる。
下した判断が正解だったのかどうか、判明するのは割と先の未来だし、しかも正解だったのかどうか明確にわかるわけではない。

・良い判断かどうか？の定義がない。ケースバイケースすぎる。
アグレッシブな判断が結果的成功して良い判断とされることもあれば、失敗して良くない判断とされることもある。
人は、いろんなやつがいろんな立場でそれぞれが判断することで群生として成立している気もしてきて、そうなると優秀さのベースは「人であること。ユニークさも持ち得ること」あたりになるように思えた。

（ユニークさを持ち、個であることが可能なAIってのが出てきたらどうなるのか、も考えてみたい）

精度の高い判断・決断が求められる仕事は人に残る

上記の理由により、精度の高い判断・決断が求められる仕事は人に残ると思う。

以前より「AIにより、人はより高いレイヤーの仕事に注力するようになる」ってよく耳にしていたけど、結局これはその通りであったと思った。
前は「人にはできるがAIにはできない」の境界がわからず、今のAIの進化速度を見てると経営レイヤーだってAIに置き換わるんじゃ無いのか？とか思ってたけど、経営こそ判断・決断の本丸なのでAIに置き換わることはない。

エンジニアはどうか？

エンジニアには「精度の高い判断・決断が求められる仕事が存在するか？」ということだが、存在する。

以下、いい感じにAIにまとめてもらった。

実現可能性の検討と価値の最大化（要件定義）

アイデアを「動くシステム」に変えるには、技術の限界を知った上での交通整理が必要です。

技術的な目利き: 今の技術で「できること」と「できないこと」を切り分け、アイデアの核となる重要部分を、実現可能な形へ落とし込みます。

トレードオフの最適化（バランスの決定）

システム開発の本質は、相反する要素（コスト・納期・品質・リスク）の狭間で最適解を見つけることです。

AIの限界: AIは周辺状況（ビジネスフェーズ、予算、組織の技術スタック）の「重要度」を理解できません。

人間の役割: 「いい感じで」という曖昧な要求に対し、エンジニアの知識を用いて「何を優先し、何を犠牲にするか」のバランスを決定します。AIからの問いかけ（「どうしますか？」）に対し、最終的な意思決定を下すのは人間です。

「運用」を見据えたリスクの重み付け

「作って終わり」ではないシステムにおいて、AIには決定的に欠けている視点があります。

■ AIにできない判断

AIは「今、何を優先すべきか？」という動的な状況判断ができません。

稼働中のシステムにおける各種リスク（性能、セキュリティ、保守コスト）の重み付けができず、運用の継続性を担保できません。

■ エンジニアの役割

現場の状況に照らし合わせ、「今この瞬間に、どのリスクを許容し、どこを死守すべきか」を判断します。

運用フェーズで発生する予期せぬ事態に対し、エンジニアがその知識で優先順位を決定します。

「正しさ」の定義とデグレの防止

AIによる修正やスクラップ＆ビルドが容易になったとしても、その品質を保証するプロセスはより困難になります。

AIによる修正のリスク: 問題を潰すための修正が、未知の箇所でデグレ（品質低下）を引き起こす可能性があります。

エンジニアの目: AIが「大丈夫」と言ったとしても、その根拠が技術的に妥当か、既存仕様を壊していないかを判断するには、深いエンジニアリング知識が不可欠です。「正しさ」を定義し、責任を持って「デグレしていない」と言い切れるのはエンジニアだけです。

おわりに

日々Xで有象無象のエンジニア不要論が流れてくるので、毎度毎度「マジか！？」とアテンションとられて疲弊してきた。
一旦ここで区切りをつけて、心穏やかにkaggleに取り組みます。

機能を開発・リリースするとき、確認・検証はしっかりやるよ、という話を書く。
当たり前だけど、割と泥臭く頑張ってるのでその辺り書いてみる。

開発中: 不確定要素はできるだけ時間的余裕があるうちに潰す

機能開発の中で、不確定具合が高い物事ってのがあったりする。
「これどうなんだろうな〜、どうやってやるんだろうな〜うまくいくのかな〜」って感じのやつ。
こういうのはハズした時に見積もりに与える影響がでかいので、なるべく早く確認しに行って、不確定具合を低くするように努める。

自動テスト: 既存で用意されているテストは気休めでしかないと思ってる

既存で自動テストが用意されてたりするが、自分が用意したものでもないし今回の自分の変更を100%担保してくれるテストは存在しないと思ってる。
実際内容見てみると意外とザルなテストだったりもする。

「今回のリリース、不具合は出ません！」と言い切れる状態を作るために、自分で必要なテストは用意する。
その際、できる限りパターン網羅できるテストを用意する。
パターン網羅ができるように、そもそもの機能の作り方も工夫する。

手動テスト: テスト方法は自分で考える

手動テストも実施したりするが、全パターンをテストするのは現実的に不可能な状況が多い。

そういう時は自分で「ここが確認できてれば大丈夫かな？」ってポイントを考えて、 そこをテストするいい方法がないかを考える。
あらかじめ用意されている手順などは存在しない。

あるデータが必要であればなんとかデータを用意するし、深夜時間帯でしかテストできないなら、深夜時間帯にテストする。 気軽にテストできない状態が嫌なので、mockを差し込めないか検討するし、一時的にコードを書き換えて再現できないかを考える。

書いてみると当たり前だが、簡単に「これはもうぶっつけ本番で行くしかないね」とは言わず、割としぶとくずっと事前確認する方法を考えている。
この点について、今まで僕よりしぶとく考えている人は見たことない。しぶとければいいってもんでもないかもだが、そのおかげで不具合を未然に防げている事実はあると思う。

生活

育児

自分の主張がかなり強くなってきた。一度イヤってなるとなかなか覆らないから一旦関係ない話するとか、注意を別に向けるテクニックみたいなのも身についてきた。
たまに奥さんが用事の時とか、子供と二人で過ごしたりするけど、普通に自分も楽しめたりしている。
大体は奥さんと子供と3人で活動することが多いが、3人だと雑念（ちょっとアレ調べたいなとか、仕事のこととか）抱いちゃったりするけど、2人だとそういうことなくて、今この時間に集中できる感じ。
その間奥さんは自分の用事済ませられるので、2人での活動をもっと増やしたいなと思ったりした。

自分時間

だいぶ時間使えるようになってきたけど、それでも少ないので配分を考えないといけない。
一時期、振り切って自己学習に割いていたけど精神的に辛くなってきて、10月くらいから一転娯楽に振り切るようにした。
といってもゲームするくらいしかないのだが、割と楽しかった。

今は少しずつまた自己学習に時間を使うように戻しつつ、まだゲームにも時間を使うようにしている。

※ 精神的辛さがMaxになってたころ、発散したくて快活クラブ新規加入して閉じこもったりしたが、緊急避難場所としていいかもしれないと思った。しかし、やはり時間が作れず、それ以来なかなか行けてない。

仕事やエンジニアリング

会社のTechBlogを書いた

会社TechBlogに記事を書いてみた。

techblog.lycorp.co.jp

初めての経験だったが、やっぱりこのブログ（やる気がストロングZERO）に記事を書くのとはワケが違って、かなりの勇気が必要だった。 またなんか書いてみたいと思っている。

AI

AIをシステム開発に使うことについて

「AIつかえ」圧がすごい。
個人的に、エンジニアの視点から感じるのは、
「システム開発の周辺作業（調べ物・資料作成・要約・翻訳とか）には便利だが、システム開発自体には使えるようになる気がしない」 である。

今年のお正月に書いた、この時と考え方は変わってない。

yaruki-strong-zero.hatenablog.jp

もともとAI以前から「実装作業は人に任せて、自分はより高度なレイヤーに集中する」というような戦略を求められることはあったが、自分はこれに懐疑的なスタンスだった。
「外部委託のエンジニア」に作業を依頼してたときも、「作業してもらえて助かる！」って感じよりも「手が空いてしまうとマズいので」ってモチベーションで依頼してた。
荒く作業を依頼すると品質管理難易度が高いので、管理できる範囲に作業を整えたり、先回して問題を潰しておいたり、という「作業切り出しのための作業」が割と負担で、「全部一人でやりたい」と思っていた。
さらに、自分で実装作業していれば、実装中に気がつけた「仕様の矛盾」などが、依頼していると（たぶん悪気はなく）うまく誤魔化されていたりして、リリースして実際に問題発生するまで気が付くチャンスが失われてしまっていたりもあった。

こういうのが「外部委託のエンジニア」から「AI」に変わってもそんなに状況変わってない気がする。

もちろん自分で実装するほどでもない一般的な処理を、AIが補完的に実装してくれる、みたいなのはすごくありがたいので、 「claudeCodeでガッとコードを書き上げてもらう」よりも、「copilotで要所要所を保管実装してもらう」あたりが現在の現実的なラインじゃないのかなと思っている。

外部委託やAIによるシステム開発で有用かもしれないと思うユースケースは、
「処理ユースケースが増えるので、すでにあるベースのこのロジックパターンを参考にして、処理を複製して対応してください」
みたいなパターンだと思う。ベースがあるのでそんなにハズさないし、割と手間がかかるのでやってもらえるとありがたい。

ただし、このユースケースが発生するのはそもそものシステム設計がマズいと思っていて、本来共通である処理がコピペでばら撒かれてしまう。
うまく設計構築できていれば、追加コードも少なく対応できて、そもそも人に依頼しなくてもできてしまう作業量になる。

多分AIって「その領域に熱意を持っている人」にとっては、AIのクオリティでは妥協できないので「使えない」と感じていて、そうでない人には「これでいいじゃん！」ってなる感じだと思う。

deeplearningについて勉強した

世の中が「AIすごい」「AIでなんでもできる」って風潮になってる。
僕は天邪鬼なので「本当になんでもできるのか？じゃあカネを稼いてくれるのか？カネを稼ぐのは無理なら、それはなぜ無理なのか？そこが人とAIの違いか？」みたいにずっと考えていて、とりあえずAIの元の元であろうdeepleaningについて勉強したりしていた。
deeplerningの世界もだいぶ奥が深そうで、結局はCNNあたりのネットワーク構成と、強化学習の仕組みあたりで息切れしてしまったが、割と興味をもてたので今後もちょいちょい学習を続けたいなと思っている。

実践としては、四則演算をdeeplerningで学習させて四則演算をだいたいの精度で算出するModelを作ってみたりした。学習させてない数値も算出できていたのはよくわからない感動があった。
今は一旦学習させる方は息切れしたので、学習済みModelで何か面白いことできないかと思い、顔認証の処理を書いてみたりしている。

AIと人の違い

前述したとおり、最近は「AIがどんどん優秀になったとして、AIがカネを稼ぐ時代は来るのか？それが来ないなら、なぜ人はカネを稼げて、AIは稼げないのか？」を考えている。
よく言われるのが「AIは責任がとれない」とか「主体性がない」とか「実際に考えているわけではない」だが、どれも自分もそうだと思うがあまりピンと来てない。
「責任を取る」ってどういうことなのだろう。
「主体性」は、なんか実装次第な気もする。claudeCodeとかで許可しておけば、勝手に色々できる気がする。
「実際に考えているわけではない」も、外から見て考えているように見えているのなら、それは「考えている」と言えるのではないか？とか。

最近達した個人的な結論としては「社会の仕組みがAIに対応してない（人間のための仕組みなので）から」になった。
AIが本当に人間と同等・それ以上の能力を得ても、社会の仕組みがAIに対応してないので、住民票とれないし銀行口座を開設できないし会社を登記できない。
打ち合わせに生身で行けないし、契約を取れない。

だから、めちゃめちゃ優秀になっても人間が主体になってしまう、と言う感じ、、なのかなぁ。。

新規開発プロジェクト

去年からやってた割と大きめな新規開発プロジェクト（外部システムの内製化）が無事リリースできた。
内製化ということで完全新規でなかったため、運用中のデータの移行などもあり新規開発よりも難易度が高かった。
ただ、既存システムの内部設計を参考にすることもできたので、その点は難易度が低かったとも言える。
既存システムの改善ポイントも盛り込むことができて、個人的には大成功と言えると思う。（切り替え時に想定外の事象があって寿命が2年ほど縮まったが乗り越えられた）.

システムはDWH系で「巨大なデータから自由度の高いクエリでの要求」に数百ms程度の低レイテンシで返答するシステムである。
今回初めてPaaSを使わず、自分でクラスタを構築し運用している。（社内提供になかったので）. 不安もあったが、オープンソースのコードを調べたり公式ドキュメントを隅々まで読んだり、経験としては濃かったように思う（運用してるので現在進行形）

リーダー業

やっぱりリーダー的なこともやらんとね、みたいな感じで小規模に練習してみている。
なんとなくやれてるのかなと思いつつ、 やっぱり違和感はある。

自分の強みは設計・実装力だと思っているので、マネジメントに時間を割くとこの強みを出せる領域が減る。
マネジメントに時間を割くのであれば、個人でやってる以上の価値をチームで出せるようにしないといけない。

後輩を育てられれば全体として価値の出力は上がるのだろうけど、個人的に「人を育てる」っていう感覚がわからない。
場合場合で「ここはこうの方がいいかも」とかは教えられるけど、毎回それでいいわけじゃないし、成長の本質は「そういう判断をできるようになること」だと思う。

自分で判断できるようになるには「自分で判断する経験すること」と「その判断の答え合わせをすること」を積み上げる必要があると思っているが、僕がいるとその判断に対して口を出してしまう。
結果、後輩は自分で判断する機会を失ってるかもしれないとも思う。

とはいえ僕も昔、上から色々言われて、自分の判断を曲げて実装したりしていたが、後で「あの判断は結果どうだったのか？」「自分の方針をとっていたらどうなったのか？」を考え続けていた。
その結果「あの指摘はそういうことだったのか！」とか「いやいや、やっぱり後で苦労したじゃん」とかが積み重なっていって、いざ自分が判断しなければならないタイミングで（年齢的に強制的にそのタイミングは来た）自信を持った判断ができるようになった気がする。
つまり「こう言う時はこうしたらいいよ」の積み重ねではなく、「それほんとか？」からの「本当はこうすべきだったんでは？」で自分で時間を使ってずっと答えを探し、自分なりの結論を積み重ねていたのが花開いたイメージ。

そういう経験から、人が成長するかどうかっていうのはその人の特性によるもので、やり方で制御できるもんではないと考えるようになった。
なので「人を成長させる」を求めて時間を割いても、成果がでるかはその人依存だし、効率が悪いんじゃないかと思っている。

であれば、自分が価値を出せる時間を削って、その分の時間を何に投下すべきなのか？
「マネジメント業」はやれるかもだが特に秀でた物にもならない気がするし、今までの積み重ねも別に活きないし、、うーんと言う感じ。

個人的には、人がなかなかできないこと（整合性の取れた仕様設計・全体設計・保守工数を小さくする実装）を自分はやれるので、そっち方向で伸びていきたいし、力を発揮していきたい。それはマネジメント方向で出せる価値ではないんじゃないかと悩んでる。

来年は？

子供と色々遊びに行きたい。そろそろ自分も興味もてるようなところに一緒に行けそう。

キャリアどうしていくか？はまだしばらくなやみそう。
大きい仕事が完了して、運用もあまり手がかかってないので、なんか大きい仕事あるといいな。

AIはどこまで成長していくのかは楽しみ。
仕事を一緒にこなしていくような感じを探ってみるか。（FEよりも動きが激しいのでとっかかるタイミングを失ってしまっている。）

今の会社に転職して、早いものでもうすぐ4年目になる。 今はチーム内での技術リードみたいな感じでやらせてもらっていて、大きめのシステムの新規構築など色々やった。

今の立ち位置での価値は割と安定して出せるようになってきていて「次のステップを」ってなるとどういう方向になるのかなぁって感じで悩んだり考えたりしたので書いてみる。

現状状況について

上記したように、今の立ち位置での価値の出し方としては十分認識されていて、会社からは「より高い価値を」と求められる状況になっている。
僕の昔の状況から思うと考えられない、ありがたい状況である。

もちろん自分としてもそうしたいと思うのだが、今までみたいに「僕個人の技術力を高めていく」だけでは達成できないように思い「何をすればいいのだろう？」って感じで悩んだ。

どうやって「より高い価値」を出せば良いのか？

現状の僕の持ってる技術力で「高品質なシステム」を「スケジュール通り」に構築し「安定して運用する」ってことは割とできている。
もう僕個人の技術力を高めても、出せる価値の総量はあまり変わらない状況になっている。

そして、僕が面倒を見れるシステムの数は限られている。
「担当するシステムの数を増やすことで価値を増やしていく」というのは難しい。

「人に手を動かしてもらうことで、面倒を見るシステムの数を増やす」は無理

よく聞く考え方の一つに「自分は設計などの作業に注力し、実装は他の人に任せる」 という方針がある。

こうすることで「実装にかかる時間を節約し、より多くのシステムに関わることで、価値の総量を増やす」みたいな感じである。

しかし、僕個人としては、このやり方では十分な価値を生み出せないと考えている。
理由は、この方法ではシステムの品質を維持できない可能性が高いと思うからだ。

たとえ僕が設計をまとめ、実装方針を細かく指示したとしても、最終的な品質は実装担当者の手に大きく左右されると思っている。
初期段階で作る設計は完璧ではない。勘違いや考慮不足が多く含まれている。
実装の過程で矛盾や考慮不足が見つかり、設計を修正しながら育てていく必要がある。

もし自分が実装を行わなければ、そうした重要な情報を直接得ることができず、結果として不十分な設計のまま実装が進んでしまう恐れがある。 もちろん、作業者からの報告や相談という形で情報は得られるが、その量は限られており、どんな情報が上がってくるかも担当者の力量に依存してしまう。

担当者に力量があれば問題ないが、無い場合に品質を担保しようとすれば、自分で（実装をおこなわずに！）情報を集める必要があり、それには実装作業とほぼ同じ工数がかかる。
さらに、他人に作業を任せることでコミュニケーションコストも増えるため、結果的には自分一人でやるよりも効率が悪くなってしまう。

「人に任せて価値を高めるはずが、逆に価値を下げてしまう」みたいなジレンマに陥る可能性が高いと感じている。

「設計対象のレイヤーを上げていく」は可能かも？

僕は今「ユーザーに提供する機能を支えるコンポーネント群のうちの1つのコンポーネント」にあたるシステムを担当し、その設計などを行っている。
ただ、今後は設計対象をもう一段上のレイヤーに広げ、「ユーザーに提供する機能を、どのようなコンポーネントを組み合わせて実現するか」という部分にも携われるようになるのがよいのかもしれないと思った。

各コンポーネントの責務を整理し、適切に設計することで、システム全体の品質を高められるはず。
たとえ一部のコンポーネントの品質が低くても、その影響を局所化し、全体の品質に大きく響かないようにする。
さらに、新機能の追加や既存機能の仕様変更も、できるだけ低コストで行えるようにしたい。
そうした全体システムの設計をできるようになることは、自分自身が目指したい方向性でもあり、目指していけるのではないかと思った。

これは上記した「人に手を動かしてもらうことで、面倒を見るシステムの数を増やす」というアプローチとは異なる。
その違いは、コンポーネント単位での「品質維持」は他の人に任せており、私は全体設計による品質の底上を目指すことで責任分離を行っていて、キャパオーバーになるのを避けているところである。