So What!?

カテゴリ

記事

連絡先

何か間違っている情報などがあればTwitterにてメッセージください。

ご注意

このBlogはアクセスデータをGoogle Analyticsおよび、Cloudflare Analyticsに送信しています。また研究開発用にSentryにパフォーマンスデータを送信しています。それ以外のデータは収集していません。

デブサミ2025夏

2026年7月17日

6年ぶりに参加してきた。今年のテーマは「エンジニアの事業貢献を応援する」。

自分自身社内にAIツールを導入しましょう!的な旗振りをしているが、なかなか思い通りにはいかず(おそらく経営層との目線を合わせられていない)、どう進めようかなーと空中を眺めていた感じだったので、なにか参考になればいいなーと思い参加した。

いくつかセッションを聞いて、なるほどなーと思ったことや、今後やろうとおもったことを書く。(セッションの内容をメモしているわけではありません。)

※ 途中で下書きが消滅してしまい

デブサミに参加する直前のスタンス

  • 前提として経営層の気持ちはわかっているつもり(投資対効果が気になるとか)
  • とはいえAIに関して言うと、、、
    • 個人的にはそもそも効率化を目的としていない。いろいろなツールやサービスがAI前提になっていく気がするので、いまAIを使っていないと、将来的にはアナログだねとかって言われるようになる気がする。
    • なにか導入しようとすると生産性が〜という話になるが、いまの生産性を測ってすらいないじゃないと思ってしまう。なにかしらの予測をしたとして、その仮説が正しいのかどうか判断するだけのデータがない。
    • AIツールの導入によって効率があがるのは検証しなくても明らかだろうと思ってしまう。自分で試していてもそうだし、世の中の情報を見ても。
    • つまり導入のためにあれこれ調査したりして考えている時間がもったいないと思っている。そんなことをしてるうちにどんどん置いていかれるし、どちらかと言えば試してみてダメだったら別のものを検討するとかそれくらいのフットワークの軽さが必要なのではないか。

チームで挑むAI駆動開発 ── エージェントを活かすための実践と設計

  • やっぱりアジリティが重要
  • Cursorで実際にどんなタスクができるのか、できないのか、はやっぱり事前に考える必要あり
  • AIに書かせたコードの品質をどうやって担保するのか
    • 担保すべき品質はなにか、これまでどうやって担保してきたのか
    • コードを書いたのがAIだろうと人間だろうとやることは同じ。ただしレビュアーの負荷が下がるような取り組みは必要な気がする
  • 今後どんな人採用する?っていう話があった。
    • 知的好奇心。それを確かめるために、これまでに熱中したこと(1時間くらいほっといても話せるようなこと)を聞くとか
    • チャンピオンの素質、リーダーシップ、フォロワーシップ
    • フットワークの軽さ

AI時代になって、エンジニアの見るべきスキルは変わった?変わっていない?

  • エンジニアとしての必須スキル+1としてのAIスキル。これまで必要とされてきたスキルがいらなくなるわけではない。
  • 採用時のコーディングテストはAI利用OKにしている
    • というか前提なんじゃないかと思う。そもそも興味をもってAIに触れられていない時点で、今後前線で活躍できる可能性は低い。歓迎するスキルではなく必須スキル。これはどんな職種にも言えると思う。
  • 採用のステップごとに見極めるポイントを変えているのが印象的だった。

新事業へ挑戦するエンジニアに必要だった3つのスキル

  • 資料読んだけどよく分からないとか、そもそも資料読む時間が無いんですとか、そういう場合は相手との歩幅や目線が合っていない、先走ってしまっている可能性がある。
  • 課題を洗い出した後で、その課題をグループ化すると、課題の本質的なところがデフォルメされて見えなくなり、最終的な解決策がありきたりでつまらないものになりがち。変にグループ化せずそのまま向き合うとか、定期的に本質はなんだっけ?を確認するタイミングを持つ必要があると思う。

エンジニアが事業に向き合うために必要だったこと、全部話します

このセッションが個人的には一番芯を食っていた。

CODE(Connection, Organization, Domain, Engagement)を読んで行動しようというメッセージも非常にキャッチーで良い。

必要なことだというのはわかっていたが、エンジニアから創業者になった人に言われるとやはり重みが違うのかな。

事業とエンジニアリングのつながり

経営と開発生産性は距離がある。経営層が見ているのは売上、利益、またはその先の企業価値だが、エンジニアが貢献しやすいのは「いかに開発生産性を上げられるか」ということ。だが、そこから企業価値まで辿り着くまでにはもっといろいろな指標がある。(言ってしまえばFour Keysなどはその距離を誤魔化すためのものだと思う)

だから、書いたコードがどう事業貢献につながるのかを直接的に判断するのはけっこう難しい。(とはいえエンジニアはコードを書いてりゃいいよという話ではない)

組織と事業

経営層のビジョン、経営戦略、目標、予算、計画が、チームや個人のものと揃っていることが大事。ここはとくに経営層とメンバーの間に立つ、マネージャー層の役割、というかマネージャーしか揃えることができないのではと思う。

どちらかと言うと私が働いている会社はエンタープライズ寄り(言ってしまうと保守的)だが、自分の考え方がスタートアップ寄りで話が噛み合っていないかもしれないとはおもった。とはいえ、AIに関して言うと、どんな企業にもスピード感が求められるだろうとは思うが。

人材育成に対する投資をするならしっかり費用対効果に落とし込むところまで設計する。ジャック・フィリップスの5段階測定モデルというのはしらなかった。

「ジャック・フィリップスの5段階測定モデル」と研修の効果測定

財務資料でよくでてくるのれんというのは面構え、企業がどう見えるかのことで、つまりはブランドや文化などが含まれる。自分も会社の中では比較的外向きの発信をするエンジニアだが、この領域は事業に貢献している実感を得るのが本当に難しい。

売上や利益以外の「企業価値」を言語化する必要がある。

事業領域、ドメインへの理解

ビジネスを理解し、業界を理解し、事業を理解した上で、業務に向き合うべき。それができているかどうかで成果物は変わってくる。

自分たちはどうやって売り上げを上げているのか、ビジネスモデルはなにか、競合優位性はどこにあるのか、どのポジションにいるのか。

  • これまでのタスクをAI前提で再設計する

Vibe Codingの幻想を超えて-生成AIを現場で使えるようにするまでの泥臭い話

参考になる取り組みが多かった。イベントを主催するのはいろいろハードルが高いかもしれないが、そのままでなくとも似たような取り組みはできる気がする。

あとはフォロワーシップ必要。推進する人だけが声を上げてもしょうがない。

スライドの最後に「メルカリにいる皆の成果の発表でした」と書かれていて、すばらしい姿勢だと思った。


1人推進はツライ。ボトムアップでいくならまずは仲間を見つけないと。(同じように思っているメンバーもきっといるはず…)

経営層がはっきりしないのもツライ。使える金がいくらあるのかも分からんし、トップダウンな指示があるわけでもない。もっとリーダーシップが欲しい。