今夏は１日だけの参加でした。
イベントの概要
技術の進歩とは裏腹に、エンジニアが直面する課題は年々複雑化しています。直近でいえば、積み重なった技術的負債がもたらす課題や、生成AIの登場によって一変したビジネス環境、また長きにわたるIT人材不足など、乗り越えるべき壁は多岐にわたります。
しかし、こうした解決の糸口も見えない複雑な問題を、なんとかすることができる力がエンジニアリングには眠っています。そして、その長きにわたって不確実性に向き合ってきた歴史と、AIのような最新技術の知見を組み合わせ、解決に向けて行動できるのはエンジニアだけなのです。
あとはこの2つの武器をどう使いこなすか。奇しくも、「なんとかする」も「使いこなす」も、英語では同じく"manage"という言葉で表されます。
「Developers Summit 2025 Summer」では、そうしたマネージャー層の方はもちろん、役割に縛られず「なんとかしたい」課題に挑む方、事業貢献に向けてmanageするエンジニアの皆さんを応援します。
AIエージェントを含めた技術を使いこなす方法、エンジニア同士が手を取り合い成果を上げる方法、そしてその成果を開発者の枠を超えて組織全体に広げていく方法をシェアし合い、明日から実践に向けて動き出せる時間を皆様と作り上げていきたいと思います。
引用：
イベント参加の背景
- 春のイベントが最高だった！！
- 今夏のイベントも１日は行きたかった…！！
- 増田亨さんとt_wadaさんを中心に魅力的な方たちのお話を聞きに２日目に…！！
セッション
ソフトウェア設計とAI技術の活用
メモ
①ソフトウェア産業と技術革新
革新的技術は短命で表舞台から消えていく。
本当に革新的な技術はじわじわ時間をかけて広がっていく。
なぜ時間をかけて広がっていくか。広い範囲の変化には時間がかかる。
先駆者の暗黙知の蓄積から始まる。
ある程度蓄積されてから形式知の発生と流通が始まる。
その後、広い範囲での取り組みが増えていく。情報の入り方がごく自然になっていく。
社会と技術の相互作用には時間がかかる。
ソシオテクニカルシステム。
人の感情、組織文化のような社会的要素が技術をどう使うかの要素となる。
社会的な要素と技術的要素が相互作用をしていくことで状況が変わっていく。
AI技術。発展途上である。
社会的要素とAI要素の相互作用はこれからである。
②ソフトウェア設計の基本スキル
ソフトウェア設計の課題。
・複雑。
・他の複雑なものとの違いとして、変化を繰り返す。複雑さが変化し続ける。
・設計に時間が限られている。後付けではいくらでも考えられるが、その場で決めざるを得なかった。
課題に対するアプローチ。
・複雑
認知できる単位に分解する。分解して組み立てる。
・変化の繰り返し
人の学習と成長とともに状況の変化に合わせ修正と拡張を繰り返す。
経験と共に新しい状況に対して取り組んでいく。
・設計に使える時間が限られている
費用対効果とともに優先順位をつけて取り組む。
モジュール化⇔学習と成長⇔事業戦略の理解
複雑さを分解するためにモジュール化する。
優先順位の見極めのために事業戦略を理解する。
状況変化に適応するために学習と成長を繰り返す。
モジュール化⇒関心の分離。抽象化。構造化。
形式知として理解していても実践知として活用できない。
モジュール化を失敗することで大きな泥団子になる。
混在を分離し、断片化を集約し、重複を一元化することを体験知として磨いていく。
事業戦略の理解⇒デジタル化の進展で領域が拡張し必要性が増した。
ソフトウェアエンジニアの事業理解の如何によって、事業価値の創出損失に繋がることになった。
参考にできる形式知も増えてきた。
参考：
差別化戦略をもとに設計の優先順位を判断し技術選定をする。
中核の業務領域を優先的に取り組む。
差別化戦略はまだまだ絵に描いた餅。具体的な判断材料としては使いづらい。
ただ、ソフトウェアエンジニアに限った話ではない。
一つの手段がビジネスルール。
戦略を実行するために適切な活動を刺激し、不適切な活動を制約する。
それを業務ロジックとしてコードとして表現し、実装をする。
事業戦略自体は入門書で学ぶこともできる。
差別化戦略の条件⇒独自価値の創造。排他的選択。適合性。継続性。
分析とモデリングの観点でも学ぶことができる。
・成長と学び。
継続的デリバリーのソフトウェア工学
モジュール化と学習が２本柱。
次から次に必要となる要素が出てくるため学習は続く。
基本と視点の多さを重要視する。
異なる知見を持ち寄り他者と共創することが学習と成長に効果的。
何を学ぶと成長できるか。
基礎、設計原則、全体像の掴み方、探求スキル、協働スキル
実践による学びを重視する。暗黙知を得ることが第一。
五感で体験知暗黙知を上げていく。他者と働くことで形式知にしていく。
コンテキストの違いを前提にしてお互いの知識を取り込む。
③AI技術
ソフトウェアエンジニアの知識がある人間の方が活用ができる。
設計技能がますます重要になる。
自分たちが設計をするための時間を確保するために、他作業をAIに任すのが適切な使い方となりそう。
感想
複雑なものを設計という手法で具体的なものに落としていく取り組みに置いて、
改めて試行錯誤の体験を通した暗黙知・体験知の蓄積と、チームでお互いのコンテキストの違いを理解した上で共有していくことが重要であると感じました。
ドメインをモデルとして捉え、ロジックとしてプロダクトコードに表現していくことは、形式知の表出であるともイメージが持てました。
それをチームで実現していくことがチーム開発の醍醐味なのかも知れない。
データ駆動経営の道しるべ：プロダクト開発指標の戦略的活用法
メモ
Teams+は開発工程だけでなく、戦略立案やプロジェクト評価にも視野を広げている。
指標との付き合い方
開発したものはアウトカムや組織インパクトに繋がっている。
ただ、開発に対する指標は測定を容易にするが、指標が目的になり本来の目的を見失いやすい。
アウトカムからの指標は本来の目的を見失いづらい。
開発の指標を測ること自体は良い。ただ、プレッシャーをかけると目的が歪んでいく。
インサイトを得るために使うのが良い。
事業目標を把握する。
EffortをOutcome、Impactに繋げる。
そのためには、事業目標を正しく理解し把握することが重要。
アウトカムをディスカバリーする。
顧客にいかに価値提供するか。
ディスカバリー手法を駆使してアウトカムを事業目標に繋がるアウトカムを探す。
事業目標とアウトカムを連結する。
但し、アウトカムを発見することは困難。一次情報、行動を信じるなどが重要。
アウトカムの不確実性は払しょくできない。
仮説検証サイクルを高速に回すことが重要となる。
やみくもに開発するのではなく、期待価値が高いものから取り組む。
優先度を決めるためには工数の見積りも重要。
工数見積もり難しい。実積使いづらい。新しい技術で経験が無い。人依存。計画外作業など。
精度を向上させるためにプラクティスがある。
MVP。規模を小さくして成功確率を上げる。小さくしていくことが大事。
再見積り。見積りはずれることが前提。不要なバッファがいらなくなる。
優先度の精度をあげて競争力をあげる。
優先度の高いものから素早くデリバリーする。
フロー効率を最大化する。優先度が高いものを最速で終わらす。
同時に開発できる数を増やす。
素早い仮説検証サイクルを回せているか。
予実を可視化する。Dora Core Model。定性・定量で確認ができる。
アウトプット量／スピード。
改善しやすく効果も高い。活用しないのはもったいない。
機能開発、改善、運用の可視化。開発時間の割合は意識的に把握する必要がある。
開発体制の最適化。
ダイナミックリチーミング。チームトポロジー。２ピザ。コンウェイ。育成。
価値の高いものを早くデリバリーするために、
アウトカム発見×開発スピード両面を高めていく。
AI時代の量とスピード。今はまだ検証フェーズ。
モニタリングすることで最大化できる。
利用率を可視化して分析することで最大化できる。
生成AIが作ったPRの比率を可視化する。
生成AIに委譲するからこそ、モニタリングが重要となる。
生成AIの活用基盤を整える。但し、今までの開発生産性で求められてきたことと一緒。
AI疲れに対する衛生面も気にしていく。
感想
インパクト、アウトカムに繋がる開発生産性をいかに健全に追求するか。
各領域に置いて主目的に向けて指標を効果的に扱うことで、プロダクト開発を健全に推進できるイメージが持てました。
開発を進めながら下敷きとして用意しておきたい内容でした。
明治エコシステム - 大企業 x マルチプロダクトの戦略と実践 -
メモ
DXにむけた戦略。何を達成するために取り組むかを深掘りしていった。
今、人口減少フェーズにいる。
結果お客様は減るので、代替バリューを挙げていく必要がある。
牛乳を飲む人の１日の消費量を増やすのは現実的ではない。
複数のカテゴリ棚で１つのブランドの名前を見れる企業は珍しい。
牛乳に加えて、他領域のものを選んでもらうことは現実的。
ブランド縦割りのマスコミュニケーション中心だった。
明示IDでの統合ID基盤を作った。
その外にデジタルマーケティング基盤を作り、それに対するデジタルサービス群を置いた。
近接領域に商品価値の提供ができるようにした。
ポイント、クーポンで横の領域にアクセスできるようにした。
独立したサービスが各々のAPIを通じて協調している。
巨大なモノリスを１チームでつくるのは大変だった。
システムの設計は分断の設計である。
人が分かれると分断が生まれる。分け方に意図的になった方が良い。
ビジネスの成功をもとに望ましいシステムの構造を考えた。
情報の集約や、横に繋げることなどインセンティブの構造からアーキテクチャを設計した。
分断を作ると全体最適、部分最適のコンフリクトがうまれる。
話し合いで解決しようとすると社内政治や対立が発生する。
社内政治は影響力によって意思決定に作用しようとする。
部分最適は自律性を重視したが、全体最適はトップダウンで決めることにした。
ソフトウェアの設計の周辺には人がいる。
その人間も含めたシステム（系）の設計が重要となる。
分けた瞬間に分断が始まるため、分断を意図するのが重要となる。
分断を橋渡しするのがマネジメントの仕事。
人と人が協調するためにデザインする。
感想
大企業 x マルチプロダクトにおける戦略的なドメイン設計のお話。
分断というと避けるべきものとして意識してしまうけど、責任をもって引き受けることが求められる環境があることを理解しました。
そうした場合、事業成功に合わせて設計をする責務がマネジメントにあることも理解しました。
自分の視野を広げることができる貴重な学びとなりました。
AI時代のエンジニア育成課題を『モデリング』と『LLM』でなんとかする：文脈知識の壁を乗り越えるには
メモ
・文脈知識
どうやって獲得してきた？
エンジニアが向き合うべきは本質的複雑性（なにをなぜつくるか）。
生成AIが生まれて必要性が顕著になってきている。
向き合うためには文脈知識（コンテキスト、背景を含む知識）が必要。
今まではコーディングを通して、模索しながら再理解していった。
今後のジュニアエンジニアがどう獲得していくか。
目的、背景情報がドキュメントには抜けがち。
AI-Agentの活用により形式知化が進んでいる。
ただ、ビジネスルールの背景は業務には不要のためそぎ落とされる。
自動化が進んでいくとビジネス知識がAI-Agentにカプセル化していく。
AI-Agentの進化が進み、業務エキスパートが代替わりするとどうなるか。
開発チームがコンテキストに触れる機会が失われていく。
・意味の構造とモデリングで乗り越える
文脈知識を形式知化するには、
既に失われた知識には、要求の背景を探求する必要がある。
意味の構造の関係から推論することで探求する必要がある。
MVVやPurpose。普段の業務で使っている？日々の行動に対するギャップが大きい。
つながりの表出のギャップをモデリングと生成AIを使って埋める。
モデリング。業務ルールの可視化。構造化によってつながりを見出す。
概念と概念の関係性、位置関係を洞察、推論することでモデリングする。
ここに生成AIも加えていく。
ドキュメントや音声を一か所にデジタル化して溜めて生成AIに入れる。
人が変わっても生成AIは残る。
生成AIは何万回でも答えてくれる。生成AIは知りたいところまで答えてくれる。
ビジネス知識を蓄えた環境は、ビジネスの整合性を保つことができる。
参考：
モデリングの目的は文脈知識を表出させること。
本質的複雑性を確認できるようにしていく。DDDにおける戦略的分析・設計プロセス。
ビジネスの言葉から上位の概念とのつながりを確認できる。
ストリームアラインドチームの活動を事業戦略と照らし合わせる状況をつくる。
戦略マップにより意味の構造を表現する。
ASIS：ビッグピクチャ。TOBE：どう変えていくかを深掘りする。
業務としてどう変えたいかを詳細化していく。
タイムボックスを区切ることが重要。
現実と理想の落としどころを見つけていく。
ビジネスインパクトと素早い価値提供を重視する。
TOBE検討とのギャップである負債を負って迄実現する価値があるかを考える。
意思決定はADRに記録し、コンテキストとする。
生成AIに充分な知識が蓄積されれば、新たな洞察に繋がるかも知れない。
人類はますますドキュメントを書かなくなる。
ビジネス知識は生成AIはカプセル化されていく。
それをモデルとナラティブを伝えることで回避していく。
開発チームの意思決定を生成AIに伝えていく。
アディッショナルタイム。
バイブコーディングの時代のエンジニアの価値とは？
人から言われるがまま作るのであればエンジニアはいらない。
Whyに見合ったWhat、Howを熟考する。
改めてエンジニアが実現できるビジネスの価値とは何か？
品質を落として進んでいくと、偶有的複雑性が増していく。
エンジニアのクリエイティビティは創造的解決。
参考：
クリエイティビティの価値とは？
保守性に宿る。保守性が事業の整合性とシステムの安定稼働をもたらす。
チームが創出する価値とは、知を表出化、共有化していくこと。
今エンジニアに必要なのは、
開発チームの開発チームによる開発チームのための戦略的設計。
価値の源泉を探り、後進に伝えていく。
感想
ドキュメントに目的や意図、背景を込めることが重要なのと同じかそれ以上に、生成AIに目的や意図、背景を残していくことが重要であるとイメージできました。
試行錯誤のためのプロセスを残すことによって、生成AIが目的に対する過程も含めて知識としてストックしてくれるイメージを持てました。
人間の試行錯誤の結果を通した形式知だけでなく、試行錯誤自体の暗黙知もデータとして残すことで、プロセスが価値ある体験の情報として残っていくのかも知れない。
そうしたデータが複数集まることで、新たな暗黙知が生まれるようなイメージも持てました。
昨日のログラスさんのイベントと合わせて尾高さんに直接ご挨拶できて嬉しかったです。
SQLアンチパターン第2版 ―データベースプログラミングで陥りがちな失敗とその対策
メモ
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…
— Andrej Karpathy (@karpathy) 2025年2月2日
バイブコーディングの波に対して、DB周りは後からリカバリできない。
UIは最悪後からいくらでも直せるからいいんだけどDBはそうではないので、Vibeする前に達人に学ぶDB設計とSQLアンチパターン読んで欲しいニャン
— 𝗉𝗈𝗍𝖾𝖻𝗈𝗒 (@_poteboy_) 2025年6月6日
DBアンチパターン初版。12年にわたるベストセラー。累計3万部突破。
第2版について。
12年は十分すぎる時間。ただ、RDBの世界は良い意味で枯れている。
それでも変更点はある。
例：第2版からアクティブレコードパターンの扱いが無くなった。定番パターンになった。
・論理設計のアンチパターン
テーブル設計のアンチパターン。データベース設計の話。
テーブル、列、関連の設計について。
世の中的には第一部の評価が高い。良かれと思って間違う内容が多い。
・物理設計のアンチパターン
テーブルやインデックスの定義。、データ型の決定など。
・クエリのアンチパターン
SQLの書き方。SELECT文に対する内容が多い。
・アプリケーション開発のアンチパターン
現在RDB独立して扱われることは滅多にない。
アプリケーションでSQLを用いる方法。
新たにストアドプロシージャの盲目的な利用を表す「さびついた開発標準」という章が追加された。
・ボーナス
外部キーの見直し。正規化のルール。
いくつかの章の末尾にミニアンチパターンが載っている。
・具体例：ジェイウォーク（信号無視）
各章の名前はパターンの名称。
短い言葉で問題や解決策を意思伝達することがパターン名に求められる。
今後パターンという技術が重要になっていく。
アンチパターンの目的。
人は良かれと思って選択したことが裏目に出てドツボにはまる。
プレッシャーが設計を歪ませる。
アンチパターンの見つけ方。
直面している問題やメンバー間の何気ない会話から気付くことができる。
アンチパターンを使ってもよい状況。
非正規化の文脈での利用など、十分検討した上での採用する余地はある。
コンテキストや制約が異なれば導かれる解決策も異なる。
ミニアンチパターン。
新たな失敗と安易な解決策が紹介される。
・おわりに
愚者は経験に学び、賢者は歴史に学ぶ。（ビスマルク）
原文では、他人の失敗を学ぶことで、自分の失敗を回避できることが記載されている。
この言葉がアンチパターンを表している。
失敗のダメージはDB設計においては大きい。
過去のデータも未来のデータも扱っていく必要がある。
良くある失敗を学んで回避することができる。
社内読書会にも向いている。
感想
自分が20代最後の頃に第1版がでたSQLアンチパターン。
当時、リーダブルコードとともに暗中模索のように感じていたエンジニアリングの拠り所ができた気持ちがしたことを覚えています。
今度、新規のプロダクト開発を予定しています。
テーブル設計も一から行う必要があり、チームとして実現していくにあたり、第2版をもとにチームの知見の底上げをしたいと思いました。
チームの拠り所としたい。
生成AI時代のDBの重要性について、JJUGでのそーだいさんのお話も思い出していました。
エンジニアリングマネージャー“お悩み相談”パネルセッション
メモ
エンジニアリングマネージャー向けの本を出版。
よくいわれることと実践の難しさとの橋渡し。
レビュアーに対象読者に近い目線で執筆中の原稿にツッコミを入れて貰った。
明日から使えるヒントを持ち帰る。
・小田中さん
フィードバックの速いプレイヤーからEMに転向することで、価値の転換を自分の意義に落とし込むのが大変。
長期視点、短期視点が描かれていることが印象的だった。
・miisan
専門性のない中でどうマネジメントしていくかが共感できると思った。
・三谷さん
幅広い悩みに対して親身に乗ってくれることが当書の良いところだと思っている。
テーマ① EMなりたての頃、何が難しかったか
・あらたまさん
CTO的な立場になって、横の人に対して技術的な会話をすると、自分の発案がそのまま通ることが恐かった。
それが責任と言われて腑に落ちた。
・小田中さん
マネジメントについて学ぶ中でサーバントリーダーシップが自分のスタイルにしたいと思った。
価値を生むことを考えていくうえで、チームのことしか見れていなかった。
メンバーだったら嬉しいことを考えることから、価値を生むチームにしていく上での目線をあげていくことが難しかった。
チームに対して貢献したいという思いと成果が遠ざかる。
・三谷さん
チームの目標設定が難しかった。
コンテキストを知らないメンバーとの目標設定が難しい。
会社として向かっていく方向に合わせて、それぞれのメンバーを知ることが難しかった。
・miisan
EMになることに自信が無かった。
エンジニアが組織の価値に気付くためには時間がかかる。それが難しく思っていた。
ロールモデルもいなかった。
・小田中さん
マネージャーになるタイミングでコーディングをやめることが覚悟が必要だった。
今までやってきたことを捨てるようなイメージもあった。
サーバントについて手触り感がエンジニアに近かった。
テーマ② 目標設定や方向性の共有、どうやっている？
・小田中さん
トップダウンでの目標は機能しない。
OKRもマネージャーとメンバーが一緒に考えることでチームのものとして腹落ちできる。
KRをメンバーに委譲したら、事業にも沿ったものが検討され、チームとして動き始めた。
・あらたまさん
上から作った目標はタスクになる。終わった後のことに視点が向かない。
セクショナリズムに繋がる。
目的をもとにメンバーが目標を立てていくことでオーナーシップを養う。
・miisan
目標を数字ではなく翻訳した言葉でメンバーをモチベートする必要がある。
中長期を考えると腹落ち感を持つことが重要。
メンバーが何に関心があって、何にチャレンジしたいかを理解して、事業進む方向にナビゲートする。
・小田中さん
120%達成という目標は形骸化していく。
形骸化していることを止めるのではなく、目的を問い直していくことが重要。
・あらたまさん
半年ごとにシームレスに点呼していくと良い気がする。
テーマ③メンバーとの信頼関係
・三谷さん
1on1。散歩しながらランチしながらが重要。
・あらたまさん
思い出すきっかけ作りとしてフォーマットを作っている。
・miisan
コーポレートの人たちとやり取りするにあたり価値観や人となりを知りたいと思っている。
雑談の内容やお困りごとなど話しているのを観察した。
その上で、1on1するようにしていた。
・小田中さん
相手が好きなこと、価値観を知ることで信頼関係を築くようにする。
成果を出すことで信頼関係を獲得する。
相手がエンジニアリングマネージャーに対する期待値を知る。
自分が何ができる、できないを伝える。
そうした関係のもとに成果を果たしていくことで信頼関係を築いていく。
キャリアの伴奏ができるのが良いマネージャー。
・あらたまさん
やったことがやっただけ次の成果に繋がるのが良い。
・小田中さん
教育は減点方式だが、仕事は失敗からの学びを成長に繋げていくことがマネージャーの役割。
・あらたまさん
事業をやっていくことは不確実性との闘い。
失敗はメンバーに言わない。得られたものセットで伝える。
・小田中さん
失敗からの学びをアクションで示す。
まとめ：明日からやっていくこと
・三谷さん
信頼関係の構築のためのテクニック、引き出しを増やしていく。
自分の武器として使えるようにしていく。
・miisan
失敗の数で学ぶ。点で見た失敗を別なものに変えていく。
そのために挑戦していく。
・小田中さん
失敗を大事にできる風土を作る。学習、前進として伝えられるようにする。
・あらたまさん
本は失敗だけでなくいろいろな悩みと向き合っている。
下敷きにして自分のアプローチを共有できる知見にしていくことを楽しみにしている。
感想
私はプロジェクトマネージャーとして自分と同じプロジェクトに参画するメンバーのマネジメントに携わっています。
プロジェクトをより健全にしていくために、もしくは、同類の他プロジェクトにメンバーが参画した場合に、メンバーが本人の志向に沿った成長、活躍ができるように伴奏ができればと思っています。
ただ、プロジェクトにプレイヤーとしても携わっており、個人のエンジニアとしての活躍と、メンバー個々人の成長と、チームとしての醸成の３つの観点で、自分自身の志向を整理することが難しく感じることがよくあります。
…ただ、今日思ったことは、難しいことは難しいこととして受け入れて、それでもプロジェクトの成功とメンバーの成長を紐づけていくことが、プロジェクトマネージャーとして自分が果たしたい役割であると思いました。
そのうえで本書のように、コンテキストが異なるエンジニアリングマネージャーの悩みとその解消を追体験することで、自分を見つめ直す機会を得ていくことが重要とも思いました。
サイン会
嬉しい…！！
休憩室であらたまさんと小田中さんにご挨拶できて嬉しかったです。
いつも小田中さんや広木さんが同い年と思うと背筋が伸びます。
t_wadaさんには開発生産性カンファレンスで第2版にサイン頂いていたため、プログラマが知るべき97のことにサイン頂いてしまいました…！！
きのこ。嬉しい。。
セッションは聞けなかったのですが、末村さん達にもサインを頂いてしまいました。
松浦さんには『入門 監視』の感謝もお伝え出来たことが嬉しかったです。
ブース
Works Human Intelligenceさんブースで一等を頂きました…！！
ありがとうございます！！
書籍のコーナーでは昨日のログラスさんのイベントでも紹介されていた野中郁次郎さんと平鍋健児さんの書籍を…！！
以前持っていたものを手放してしまっていたため再購入です。
感想
ProductEngineeringNight⇒生成AI*アジャイル⇒本日のデブサミ夏と続き、
改めて暗黙知の重要性と、それをチームの形式知として醸成していく重要性を学ぶ３日間でした。
devsumi夏、２日目のみの参加でしたが学びの多い１日でした。
最近、生成AIについて、普通自動車で時速100km以上出ても、60kmぐらいまでしか出さないもんなーとぼんやり思ったりしています。
正直、100kmの速度を持続して扱えないと思うし、60kmで充分行きたいところに行きたいタイミングで行ける。
で、逆に60kmだからこそ見えている景色はあるわけで、-40kmで得た情報をいかに価値あるものに転化していくかが重要なんじゃとも思っています。
ただ、その加速装置を前に進むためのスピード以外の用途で使っていくことも重要であり、学びを得るために使ったり、コンテキストを醸成するために使ったりするイメージが持てました。
生成AIの話が少なかった気がするのは、事業貢献という文脈ではまだまだ人の手が中心となるからか。
先日の開発生産性カンファレンスでもGene Kimの講演でも話がありましたが、今日の増田亨さんのお話でもあったソシオテクニカルにヒントがある気もしています。
得た刺激と学びを日々の業務に転換していきます。
