↓に行ってきた時のメモ。 https://supporterz-seminar.connpass.com/event/371963/

オープニングセッション

感想：なかなか海外の文化と開発を絡めた話は聞けないので楽しかった。

ひろゆきとmizchiが考える、U35エンジニアの生存戦略

フリーランスCTOが増えてきた。社内の予算感、セキュリティとかみるとハードの知識いるし、人間と経営まわりはたくさん仕事ある。AIだけよりも、他のコネクションがある人は大丈夫そう。

AIが拾えていない人間の持つノウハウ（デバッグ系、設計ミスを見つけるセンス）は強い。

• ひろゆきのレスバスタイル文化
  • SNSのプロフィールから想像して他己紹介する遊びしてて、時間をかけずにレスばするのが好き。
• 新技術と死んでいく技術をどうみているか
  • h flush、action scriptみると、なくならないものやるのが楽そう
    • php遅かったけど、最近はpythonより速い場合もある。
    • ユーザ数に寄りそう
    • 新技術はバグ多かったり、ミドルウェアも使えなかったり
    • 堅いシステムは昔ながらが良いよね
  • m 枯れた後に終わるものもある（フェードアウトする）が、それを勧めるのはどうだろうか
    • h COBOLとかは希少価値ある
  • h 老害エンジニア押し付け問題はどこでも置きがちだけど、その仕組みの方が後から得するかも
    • 最近メモリ管理とかサーバ見ないけど、大規模システムのコスパ見る時に必要
    • 低レイヤの知識が必要ないかもだけど、結局必要ではある（アメリカのクラウド系企業に金を払い続ける
  • h 低レイヤ知識必要？
    • mizchi A. Rustはモダンだからやってるくらい。困ることはない
    • rustで出来上がったものは堅牢だけど、そこにいくまでがしんどい
      • 地頭力の性能と言語の賢さが大事
    • エンジニアの仕事。。。
      • 考案して最先端をやる→AIだと厳しい
      • 誰でもできることをやる→AIでもOK
        • 膨大な量あるから、AIで全部大体できる？？？
  • m なかなか社会適合しない新技術
    • 日本：FAXが廃れない
      • 銀行とかで印鑑して送るときにFAX必須（拡大縮小できたらダメ）
      • ↑の仕組みがあるうちは廃れない
      • 他の国はないから、FAXない。
    • →そうじゃなくて良いよね(高齢者)圧力が強すぎてインターフェースのイノベーションは起きない
      • 高齢者向けインターフェースを知っておくと仕事増えるかも
    • m 昔より比較的イノベーションは起きやすくなった？
      • PC触った人が増えたから
      • 理論的に可能でAIリプレースされるはずが、社会的にはできない
        • Googleも社内技術が社会の10年先に行ってるが、社会適合しないから公開しないことがある
        • 技術で進んでいるから社会に適合するとは限らない（技術は効率的だが）
      • h 学校も変わらない（非合理を求める人が多数派である）
        • →非合理な人の気持ちを分かった感を出す
        • 実際はAIだけど、話すときは人間感を出す、見せ方が大事
        • 如何にしておっさんを騙すか
        • mizchi→GoogleのSEO（既存の仕組み）できくと言ったらチューニングの仕事が増えた
        • おっさんがわかるように言うとお金出やすい（決済権持ってるから）
          • 社会の仕組みを利用すると通りやすい
          • エンジニアリング以外にも興味を持つ方が大事
• 技術志向 vs プロダクト志向
  • m どちらかで偏ると地獄
    • 日本ではプロダクト志向が作ったものを後から入った人が地獄を見るケース多い
  • h プロダクトベース→お金を得やすく、優秀なエンジニアが集まりやすいから安全
    • 後から直すことは否定してなくて、その方がやりやすくなる
    • 売り上げは全てを癒す
• プロダクトを考えるときに、何を意識するか
  • h チャレンジ：何かやっていく中で面白いものが見つかればOK
    • やろうかと思った人は有象無象、アイデア思いついた人はその後でもそこそこいる、その後の手を動かした人はほとんどいない
    • 日本以外に住むだけで日本人との共通点とか見えていいことがある
  • m タイムマシン経営当たる？
    • 海外でやってるものをパクってみるのはありかも
  • m 技術的イノベーションで可能になった機能や事業、プロダクトはプロダクト志向だとむずいのでは？
    • h 技術ドリブンは厳しいんじゃないか
    • 一定のユーザ数集めると誰も参入してこない（参入障壁）
      • ニコ動とか
    • 技術コストの高さも参入障壁高い（動画のストレージ高いとか
    • 技術的に安くなるとみんな始めてしまう。アーリーアダプトを押さえる方が良い
    • m 大体新規をやってると巨大資本で真似してくる会社が多い
      • クリーンで儲かる、は大金持ちになれない
      • yahooのpaypayもだめ（大企業が入れる
      • 大企業が入れないようにする
      • h モラルか、金で買えないものをコアに置く＝大企業が負えないリスクを負う
        • ベトナムの著作権無視漫画サイト
          • 日本からアップロードしなければ違法でもなかった
          • 従業員がミスって違反
    • m 社会的に影響を持つものは日本に会社置かない方が良い
      • ニコニコ→国内だと叩かれる
      • Youtube→アメリカだから叩かれない、クリーンなイメージは日本じゃないから
        • ゲーム実況の判定ツール（違反検知）はゲーム実況減るからやってない
        • アメリカ本社じゃなくて、アイルランドに本社置く（税制が良い。税金減るから）
• m 匿名コミュニティ、今減ってるけどどうしたら成立しそうか
  • h 日本人が匿名好きだからX使う（前提）。Facebookは使わない
    • それに合わせたものをやるかどうか
    • 2chは匿名と実名を選べる
  • m 2chまとめ、Xまとめだと匿名性が薄い
    • 人とプロフィールをまとめて読まされる
    • h 他の国ではまとめサイト、ランキングがない
      • 日本人は他人の好きなものが好き
        • 多くの人が持つ情報は持たねばならない観念がある
      • レコメンドは海外向き。その人に合ったものを
• AIひろゆき、のようなクローンを作られる感覚とクローンを作る時代
  • h 個人としては「どうぞ使ってください、ご自由に」
    • 著名人は勝手に使われる時代が来ているし、来ると思ったから
    • 記事を書いてすらないし、思ってないことが記事化される
      • そんなつもりないのに勝手に炎上も一緒
      • これを止められないから、乗っかる方がお得
  • h 今後、世界の中で日本だけ取り残されそう
    • しょうもないものを世界中の人が見ている（日本人は知らない）
    • 日本は日本特有のものだけを見る傾向にあるから、文化差が如実になりそう
  • m 日本はアニメ頼り
    • 日本のアニメを見る人は結局少ないから共通の話題になりえない

安野貴博が目指す日本の未来、エンジニアの未来

感想：エンジニアリングを政治に応用している。アジャイルな進め方がベース。

安野さんは本も書いている。 繋がってないように見えるが、同じ筋肉でやってきた感覚がある。 テクノロジーを通じて未来を構想する（アウトプットは問わず）

これまで→エンジニアリング 本・SNS→言語を書くだけで良い。実装不要 政治→技術を通じたアウトプットが政策になっただけ 動き方にラベリングするのではなく、必要なことはなんでもやる。

GitHubは開発者しか使えない →喋れるマニフェストを作成

• チャットを進める中、裏でMCPを使ったGitHubのPRを作成する
• 今度は提案が増えすぎてどう取り込むか難しくなってきた

大事だと思っていること

• 投票率を上げるだけでなく、ダイレクトに困っていることにできることの選択肢を与える
  • デジタル目安箱とか
  • 台湾ではJoinというサービスで実装されている
  • 実際に声が通ったり、発言したりすると政治への自信や関心が上がる

生み出すコツ

• 人の脳みそはインプットに影響を受ける：みんなと同じだとみんなと同じものしか出ない
  • →ユニークな情報源を得る
  • 有用だけど参照しない→一次情報
    • 例：話題になった場所・イベントに行くかどうか（少ない）
    • 前線に行く
• 変なやつエミュレータを脳内に作る
  • 常識的な自分でいきなりできることではない
  • 常識人としてピンチの状況を作る
    • そこに頭いいやつ、主人公を入れてみる
    • エミュレータ経由でやりそうなことを考える
    • →発想が出る
  • どうやって構築するか
    • プラクティカルなやり方：モノマネ力
    • 脳内で上司のモノマネやったり、アウトプットを予想してみたり
      • 予想と結果からバックプロパゲーションすると良い

AI時代はゲームチェンジの瞬間

• やろうと思えばチャンスを掴めるし、無限にある
• 行動を起こす人に機会がある

情熱なきエンジニアの生存戦略

感想：戦略とはかくあるべし。って感じ。自分自身情熱あるタイプだと思うけど、 情熱がない＝ネガティブに捉えるのではなく、だからこそできることは？と考えるスタイルは真似ていきたい。

情熱はなく、プロとしての責任だけ 主旨：情熱がある人に負けないためには？

キャリア戦略 ナンバーワンではなく、オンリーワン：スキルの掛け合わせで作る 例；100人に1人の技術力x100人に1人のコミュ力 = 1万人の1人

H型人材：人を動かす、人と何かすることに意味を見出す ジェネラリストは生成AI活用で補強できて強くなる。

AI活用の大前提：AIの確率的に出てしまう嘘に騙されない基礎力

主なアプローチ

1. 評価しやすくする
   • 細かくタスク分割（機械を一気に作るのではなく、部品作りから始める）
2. 成果物の質を上げる

AI活用は仕事の依頼と同じ。広い知識とコミュ力の掛け合わせ。

今、なぜH型人材が求められるか H型人材の強み＝広い知識とコミュ力＝生成AI活用力

仕事とは＝利益貢献

• 売上を増やす
• コストを減らす

エンジニアの場合→技術屋の専門性を第一の武器にして、利益貢献する

コスト

• 直接的な支出
  • 非アクティブユーザのライセンス料
  • 過剰なログのメトリクス料金
• 機会損失・リスク
  • UX悪化による解約
  • ダウンタイム→プロダクトブランドの低下
  • 技術負債、変更容易性
  • リリースサイクルの長期化
• 運用コスト
  • 自動化されてない提携作業
  • 割り込み

難しいことでも人を動かして物事を前に進める

1. 求められる情報を理解する
   • 主語は組織 or プロダクト
   • なるべく定量的に
   • 提案時に具体的な道筋を示す（ロードマップとか）
2. リスク評価を提示する
   • はっきりとつけつける
     • サービスを人質にとる
   • 正当な理由なく引き下がらない
     • 忙しい＝リスクとリターンを評価したか確認
3. 先行して飛び込んでみせる
   • オーナーシップを示す
     • 手伝う形ならやってくれる人は多い
   • 最低限の合意形成はやっておく

やりたいことがないからこそ、手段として実行できる。情熱がないことは強みになりうる

エンジニアの武器は技術力だけじゃない。ソフトスキル込みで考えて良い

創り手であれ（矛盾を超えイノベーションの創り手になる）

感想：やはり物事は創造主が強すぎる。みんな憧れたよね。 私は常にそちらになることを意識しているけど、めっちゃしっくりきた。 言語化がかなりわかりやすくて、最高！

テーマ：Q.卓越したSWEになるには？ 公演内：A.「創り手であれ」 多くの人の価値観を変えられる未知のモノが作れる人

• Ruby、TDD、Reactとかのプロダクト、OSS、言語、概念、アーキテクチャ、思想
• Staff Engineer、テックリード、CTOなどの社会的評価とは相関がない

①”創る側である”という精神

• 課題、問題がある時にどう捉えるか
• 創るチャンス？諦める？
• 開発以外→ルールを作り変えようとするとか（タイミング、好き嫌い…etc…）
• giver側に回る
  • 今までの概念を変えてより大きな価値を提供する
  • その上で、良い部分をtakeする

→（常に）創り手であれ その中で重要なこと ②”疑う”という精神＝クリティカルシンキング

• 今が正解か、より良い方法はないのか
• 自分以外にも、自分にも問い続ける

→（常に）（さまざまな物事を疑う）創り手であれ かといって、クリティカルすぎるのは違う

③”未来の顧客”という精神

• 全ての価値観にリスペクトし、吸収して未来のイノベーションの顧客として大切に想う
• プラマイを適切に評価し、課題を作る

（常に）（さまざまな物事を疑う）（あらゆる物事をリスペクトした）創り手であれ

④"ソフトウェアで解決する"という精神

• ソフトウェアエンジニアだからこそ、他にも創り手にはなれるけど、最後はソフトウェアに戻ってくる（重要）
• 創り手になるには、なんでもやっておいた方が良い
  • マネジメント、ハッカソン、ビジコン、盆栽教室
  • さまざまな創り手を知ること（優劣はない）
  • 価値観とプロセス、普段いないコミュニティから得られる課題感を知る
• 不満に思ったものをソフトウェアに注ぎ込めるか
• ソフトウェアで最後に解決できているか？を問い続ける

ばんくしさんの言語化（であることに注意） →（常に）（さまざまな物事を疑う）（あらゆる物事をリスペクトした）（最後ソフトウェアで課題を解決する）創り手であれ

特徴

• FBサイクルの速さ・アジャイル性（改善サイクルを自分で作れること）
• 自分で環境を作ること

AI時代のソフトウェア開発を考える

感想：t_wadaさん、バケモン。。。 当然だけど私と次元違いすぎるし、情報量が多すぎて酸欠。 資料で毎年読んでいるけれど、生で聞くと全然違う。 すごく楽しかったけど、こちらの技量不足で毎日聞くのは難しいかも。 エンジニアとして、t_wadaさんのことがすごく好きになった！

ティム・オライリー（2月）：AIの影響で既知のプログラミングの終わり＝変わっていく 5月のMaxプラン定額制≒インターネットが従量課金から定額制になったくらい →投機的プログラミングの世界へ（別称：ガチャ）

Vibe Coding：コードの存在を感じさせない＝コードレビューがない →流行語大賞になった。

• レビューできない分量がくると、人間がアクセプトマシンになってしまう
• Unknown - Unknown領域の拡大、セキュリティリスク

おすすめ：Googleのソフトウェアエンジニアリング

• 読んだ感想：世界最大規模のGoogleだからでしょ？
• 今：AIで大規模になりやすいから必要な知見になった
• TDDを教えるt-wadaさんから見ても、11~14章だけでも読む価値がある

目指すべき：AIとソフトウェアエンジニアリングの融合 Vibe Codingの真の革命

• 誰でも自分のための小さなソフトウェアを作れる（ニッチな課題）
• 今までは誰かに依頼しないと作れなかった →SWによる解決の裾野が広がる→SWの理解者が増える＝目が肥える→頂が上がる＝プロに求められる質が上がる

Agentic Coding（AIとの協業）、Zedも同様の話題を挙げている

• 上流工程含めて開発をAIと一緒に進める
• 手法
  • 直列：伴走（traditional approach）
  • 並列：委託（emerging approach）
  • どこで向いているか（DDDをはじめよう、の本。業務ロジックの複雑さx競合他社との差別化）
    • 両方大→伴走
    • 業務ロジックだけ→製品購入、外部サービス（自力で作らない）
    • 他→委託

仕様と設計を伴走して作り込む→委託 秋以降、最近はSDD(kiroとか)が概ねうまくいくレールに乗せてくれる

AIが自走できるように整地する

• プロンプトエンジニアリング（指示）
• コンテキストエンジニアリング（例：ルンバのための整地）
• 類似：k8s、ReactのReconciliation Loop（宣言的に記載すること）
• 今後の課題→機械学習：評価関数、アーキテクチャ：適応度関数を考える

これからは複数の品質特性を定量的にAIに共有して伝える

• 特性が少ないとハックされる（人間でも同じ）
• メトリクス設計が必要になる
  • メトリクス間で牽制しあってよくしていく

TDDの目的の変化

• 開発者に根拠ある自信を与え→AIに判断基準を与え

AIはファイル・インデックスサーチが基本→手元に集めることが良い

• モノレポ
• プレーンテキストを一緒に入れる。関連するものをまとめておく（凝集度）
  • 歴史により自明：コードの近くにあればあるほど同期される。遠いほど忘れられ、解離が進む
• 委託→非同期並列
  • スピードを活かしたいが故、マイクロマネジメントできない＝後で監査するのが大事
  • 規律あるGit利用でトレーサビリティを確保する（AIはよく勉強しているからキーワードで伝わるし、伝えるのが良い）
    • 説明を省略でき、コンテキストエンジニアリングで強い（少ないワードでたくさん働かせる）
    • うまくいっているパターン名を知る。そして、使い所を教える

ソフトウェア品質：しばらくの間はAIの影響で落ちていく

• バグリスク0から外れないと厳しくなる
  • 日本従来のバグ0ではやっていけない
• →SWはKnown - Unknownから Unknown-Unknownに戻っていく
  • プロパティベースドテストを知ろう（Kiroはやってくれる。＝戦い方を知っている）
• コードが増える＝コードレビューが増える
  • レビューコスト＝差分の多さ→なるべく小さくする（良かれと思って）
    • 複雑度・複雑性が上がっていってしまう
    • 影響範囲が増えて、変更容易性が上がる
    • →アンチパターン（良かれと思ってドツボにハマること）
  • Tidy First？の振る舞い変更（不可逆）と構造変更（可逆）を分ける
    • 構造はSWEの観点で仕組みかし、コストを０にする
    • 振る舞いはしっかり見る

DevOps領域レポートだったDORAも変わっている

• 高パフォーマンス組織→強みを増幅する
• 低パフォーマンス組織→機能不全を増幅する
• = AIは増幅器、AIはIA（インテリ amplifier）
  • 引き出せる性能は自分（個人・組織）の能力に比例する
  • →スキルアップから逃れられない
• スキルアップにも使える：学びの追い風
  • 例
    • 批判的な人格を与える
    • スタミナ強いから議論相手に。腹落ちする設計を作れる
    • 知識が多いからこそ、新しいことの学びに使う
  • オーガニック・コーディング
    • コード差分からDocs更新とか得意
    • →むずいとこを人がやる
  • 能力差を埋めるツールを使う
    • SDD系ツールから思考（しゅはり、の守）を学べる

AIバブル（今年）はアマラの法則が当てはまる

• 生存戦略的には半分位賭ければOK
• 不確実→２択を避けるべき
  • All in か賭けないはだめ
  • もっと他の可能性を模索しよう
  • 引いてみて、可能性を並べて、実際にやって評価すること