幡ヶ谷亭直吉ブログ

娘のここねと格闘するエンジニア。

『なぜイノベーションは起こらないのか』を読んで ~ 気づいていないことに気づく重要性

読書メモ。2025年65冊目。
『なぜイノベーションは起こらないのか』を読んでの感想となります。(2025/9/29記載)

本の概要

イノベーションは依然として強力な力を持っているが、それを実現するのは容易なことではない。イノベーションが「ひらめきの瞬間」に依存することはほぼなく、バリュープロポジション(価値提案)を主軸に置いた従来のアプローチは極めて失敗しやすい。イノベーションによってプロダクトは人々の生活の一部とならなければならず、そのためには彼らの生活の中に潜む「真正の需要」を明らかにしなければならない。
本書は、科学的根拠に基づいたアプローチを通じ、隠された真正の需要を暴き出し、イノベーションを戦略的に起こすことを目的とした、全く新しいプロダクト開発の実践的ガイドである。

引用:

www.maruzen-publishing.co.jp

動機

  • 渋谷アジャイル#10で本書を知り読んでみたいと思っていた。

    hiliteeternal.hatenablog.com

  • エンジニアとしてディスカバリー領域についても知識は持っておきたいと思っている。
  • 結局行けなくなってしまったけど、翻訳者の方のワークショップをconnpassでお見かけし着手。

本書からの学び

普段の業務は主体的にイノベーションを考える役割にはないため多くの学びがありました。
特に、イノベーションの3つの種類、not not、イノベーションは状況に対して検討すべきことは、普段得ることができない学びとなりました。
エンジニアとしてプロダクト領域を意識していくには、持っていたほうが良い知識とも思いました。
機能開発に当たる際に、ペルソナとシチュエーションを明確に分けてUXを考えると良さそう。
また、イノベーションに限らず、自分の経験や知識に盲目的な依存をしたくないと思いました。

忘れたくないメモ

本書で特に印象に残ったポイントをふりかえります。

4分の1インチの穴

イノベーションマーケティングが効果を発揮する前に起こらなければならないのです。レヴィットは、顧客が4分の1インチの穴を欲しがっていることを知っていました。なぜなら、ドリルで穴を開けて物を留めることは既に確立された方法で、物を留める方法としては議論の余地のないものだったからです。つまり、イノベーションではなかったということです。根底にある真正の需要は、もはや秘密ではありませんでした。
それは一般的に確立されたビジネスにおいて言えることです。しかし、イノベーションはそのような秘密が暴かれる前に起こるものなのです。

顧客は手段ではなく目的の達成を望む。
イノベーションはそもそもの目的を明らかにすることから始まる。

not not

世の中には "not not”(しないではいられないこと)を見ることでよりよく理解できる状況がたくさんあります。(中略)”not not"は確実に実現しなければいけないことではありません。時には失敗することもあります。忘れていたり、別の状況が介入してきたり、あるいはもっと強い "not not"が優先されることもあります。しかし、いずれにせよ、それらは大切なことなのです。

しないではいられないこと。渋谷アジャイル#10でも印象的だった言葉でした。
日常の中にあるしないではいられないことを意識したい。

イノベーション

イノベーションは常に行動変容を伴います。それは、新しい均衡をもたらす持続可能で反復可能な変化であり、文化そのものの形の変化です。イノベーションと発明は別物です。発明は一瞬の出来事かもしれないし、新しいけれど、研究論文になるだけで終わったり、プロダクトに組み込まれても売れず、行動変容を起こすこともない代物かもしれません。しかし、発明がイノベーションの根底にあり、それによって形を変化させることもあります。

イノベーションに対し、短期的な発明は手段であると理解しました。
イノベーションは真正の需要を満たすための、継続可能な手段として捉えています。

充形的イノベーション

この種のイノベーションは、観客や企業が置かれている状況を変えることなく、何かを改良するものです。充形的と呼ばれるのは、状況の形を変えず、イノベーションはその形の内側で起こるためです。充形的イノベーションは、既に認識され確立された方向性に従って、プロダクトの漸進的な改善や、顧客の生活の漸進的な改善をもたらします。

私たちが日頃行っているエンジニアリングの多くが充形的イノベーションに含まれると理解しました。

変形的イノベーション

この種のイノベーションは、ある状況での、顧客や企業の行動の元となっていた前提を根底から変えてしまいます。前提を問うことは、企業や顧客の環境や状況に対する考え方を再構築することにつながります。変形的と呼ばれるのは、状況の形を変えてしまうからです。変形的イノベーションは飛躍的な可能性をもたらします。

私が扱っておりプロダクトや、私が提供しているサービスは全体から見ると変形的イノベーションに含まれると理解しました。

創形的イノベーション

状況を1から創り出すイノベーションのことです。事実上、 成功したすべての企業は、何か新しいもの、漸進的でないもの、他の何かを変形させただけでないものを創り上げることから始まります。

多くのスタートアップ企業はここに含まれるのかと想定しました。

変形的イノベーションの免疫反応

変形的イノベーションには、人々の心理的な「変革をはばむ免疫」の問題を中心に、非常に特殊な課題に対処することが必要です。変形的イノベーションが起こす変化はシステム全体に波及する可能性があるため、マネジメントレベルの人々は通常、システム全体をとらえ、変形的なやり方で変化をさせようとします。しかし、変形的イノベーションによって人々がこれまでとは違う仕事をしたり、 あるいは違う仕事について考えたりしなければならなくなった場合、彼らはしばしば一種の免疫反応を起こし、巧妙で目につかない方法で変化に抵抗し、イノベーションが根付かないようにします。

変化に対しての反発について、よくよく考えれば納得できるものの、とても興味深かったです。
改めて、変形的イノベーションの実現の難しさを感じました。

フォーカスすべきイノベーション

あるタイプのイノベーションを気にして他のタイプのイノベーションに気づかないのは、一種の盲点です。より明確な理解をするために、イノベーターは「ここではどのようなタイプのイノベーションが理にかなっているのだろうか?」と自問すると良いでしょう。あるいは、「もし行き詰まったら、 それは誤った種別のイノベーションを考えているからかもしれない」ということを肝に銘じておくと良いでしょう。戦略的イノベーションに必要なのは、フォーカスすべきイノベーションのタイプを検討・選択し、その領域に伴う課題を理解し、それに適したツールを使用することです。

イノベーションを俯瞰して取り扱う重要性と、その難しさを感じました。
イノベーションを手段とし、真正の需要に向き合う必要があると理解しました。

創形的イノベーションのゴール

創形的イノベーションのゴールは、何か変わろうとするものに無関心でいられない状況にある人々の市場を見つけることです。しかしそれが何であるかは通常隠されていて、彼らが今取り組んでいる問題とは別物です。だからあなたが取り組むべきは、実際に無関心であることと、無関心であるかのようにカモフラージュされているが非無関心なことを見分けることです。そうすることで、非無関心がどこから来て、どのように隠されているのかを明らかにしなければなりません。

非無関心をはじめて意識することができました。
無意識に従っている習慣の中に埋もれていそうなイメージがあります。

環世界

私達一人一人にとって、環世界はまるで白昼夢のようなものです。私達が住んでいると想像している世界と現実の世界を隔てているバイアスや認知的錯覚を見抜くことは、ただ良い訓練になる、どころでありません。そこには莫大なイノベーションの機会が存在するのです。しかしそれを行うのは容易ではありません。私達は自分が物事の存在に気づいてないと気づかないからです。

未知の未知を、いかに既知の未知にしていくか。
バイアスや認知的錯覚を意識できるようにしていきたいです。

知る前の意見形成

イノベーターはきちんと知る前に意見を形成してしまい、それに疑問を抱くということを絶対しません。顧客と対話するとき彼らは自信過剰になっていて、正しい質問をしているし、潜在顧客と正しくコミュニケーションを取れているし、顧客の回答を正確に理解している、と考えてしまいます。

いかに自分の思い込みを取り払うか。
そして思い込みが取り払われることをストレスとしないか。

知識の呪い

私達は覚醒している間、不適切で、しかしどうしてか完璧に適切だと感じる情報に基づく意見、志向、見解にまみれてしまいます。これは知識の呪いと呼ばれています。私達はどんな知識であろうと十分だと思い込む呪いにかかっているのです。

『FACTFULNESS』を意識していたいです。
特に自分の所属している領域の情報に盲目的にならないように注意したい。

特徴の誘惑

プロダクトはマッドパイです。その特徴が果たす役割を形作り、そして明らかにするのは、状況です。特徴か便益か、を考えることは真正の需要に光を当てることにはなりません。

特徴や便益よりも状況を対象にイノベーションを考える。
意識したい。

基本的帰属の誤り

人々はあらゆる類の特性を持ち、それは時を超え、場合によっては人生を通じてその人に備わるものです。そして、互いに親しい間柄や長い付き合いのある間柄の人に対しては、新たな状況で相手がどういう行動をするかをより正確に予測します。とはいうものの、特定の行動からパーソナリティを推測する、あるいは(想像上でも現実のものでも)パーソナリティを元に行動を予測するのは、その人が置かれている状況に着目するより遥かに不正確です。

人は状況に依存する。
イノベーションにおいては、ペルソナよりシチュエーションを考えたほうが良い。

確証バイアス

時に、この手の行動は推論を特定の動機に基づいて行っていることが原因となることがあります。もしあなたと他の誰かの間で、この金はどちらのものか、といった諍いが起こっていた場合、あなたは自分こそがその金銭のしかるべき所有者だ、とする主張を信じる動機を持ち合わせていることになります。しかし不可思議なことには、そうした動機が特定の方向になくとも、人々は主張を組み立ててしまいます。

批判的思考の重要性。
ただ、批判的思考を繰り返せば繰り返すほど自分に対する盲目的な自信にも繋がるから、第三者が重要になると思う。

ただ思いやるだけで、戦略的にイノベーションを起こすことができる

ダイアグラムの感情的側面は重要で、イノベーターの役割、つまり、どうしてイノベーションを起こすのか、に問いを投げかけます。イノベーターは技術的な試行錯誤をすると発明家になります。しかし、ただ思いやるだけで、戦略的にイノベーションを起こすことができます。顧客が心の底から大切にしていることに、自分たちの思いを一致させなければなりません。この「思い」という言葉には 2つの意味があります。関心を向けること、そして大事に思うことです。イノベーションはその2つにまたがって存在します。イノベーターは潜在顧客の置かれた状況に関心を向けることで、人々の "not not"を理解し、非無関心に気づくことができます。イノベーターは顧客の置かれた状況を大事に思うことで、その状況にある彼らの苦しみを和らげようと心を突き動かされるのです。

関心を向けること、大事に思うこと。
イノベーションが偉い人の特権的な営みではなく、誰にも与えられた営みであると意識できました。

参考

What is Startup Engineering? with Matt Chanoff 

youtu.be

プロダクトエンジニアのお仕事~toCプロダクトとtoBプロダクトの違いから見えるリアル に参加しました

プロダクトエンジニアのお仕事~toCプロダクトとtoBプロダクトの違いから見えるリアル に参加しました。
イベントに参加した感想をまとめます。

イベントの概要

虎の穴ラボ、SmartHR、Helpfeelの3社による「プロダクトエンジニアのお仕事」についてトーク&パネルディスカッションを行うイベントです。

課題発見からプロジェクトの遂行までを一貫して対応する「プロダクトエンジニア」。

本イベントではtoCtoBそれぞれのプロダクトの価値基準やスケジューリングの差など、異なるプロダクト特性から生まれるプロダクトエンジニアの仕事の違いについて具体的な思考法と実践術を共有します。

引用:

nota.connpass.com

イベント参加の背景

  • プロダクトエンジニアリングの実践の話を聞きたい。
  • 虎の穴ラボさん、SmartHRさん、Helpfeelさんいずれの企業のお話も聞いてみたい。
  • toCtoB、どちらのお話も聞けるだなんて!と現地参加です。

セッション

ユーザーの「好き」に応えるプロダクト開発:私たちはなぜ「Why」を考えるか

www.docswell.com

メモ

toCの話。
プロダクトエンジニアとは?
ユーザーとプロダクトの間にあるブランドを作って育んでいくこと。

プロダクトとは、サービスや企業、商品のイメージ、信頼性、価値そのもの。
感情的なつながりも含む。

ブランドイメージを意識しないでプロダクト開発をすると?
マック:アンケートではヘルシーな商品に対する希求がある。ただ、ブランドに合わない。
スターバックス:カスタマイズで従業員の手間が増えるとサービス品質下がってブランドに合わない

ユーザーの回答はHowに寄りがち。
プロダクトエンジニアはWhyを考え、ブランドに沿うものを提案していくことが重要。

エンジニアとしてやっていること。
機能要望の棚卸し。ブランドに合わないものはやらないとして整理。
ドッグフーディング
日常的なヒアリング。悩みを聞いて欲しい機能は聞かない。

サービスごと好きになってもらうことを目指す。
サービスのファンダムを作る。

学び

エンタメ系のtoCにおけるプロダクトエンジニアリングのやりがいを感じました。
ユーザーの回答がHOWによりがちな件、悩みは聞くが欲しい機能は聞かない件、
解決策を考えることよりも課題感に対する解像度をあげる重要性を改めて学びました。
ブランドという軸と顧客の要望という求心力でプロダクトを育てていく魅力を感じました。

BtoBプロダクト開発の深層:信頼性をエンジニアリングする旅路

メモ

CRE= Customer Reliability Engineering。

なぜエンジニアに向き合うか?
ユーザーの視点をプロダクトに取り込んでいくことが重要。
ただ、エンジニアの日々の業務のなかで実現していくことは負荷が高い。
CREは顧客の声なき声を拾い上げる仕組みをゼロから作るユニット。

参考:

speakerdeck.com


痛みへの応急措置。問い合わせ対応の巻き取り。
プロダクトエンジニアの負荷を軽減。
CREが一手に引き受けすぎているという課題もあった。
問い合わせ対応だけを引き受け続けるのは健全ではない。

CREの役割。
・トイル削減:手作業削減
・顧客信頼の砦:顧客の潜在的課題の特定も行う
・CS Ops
・Customer Observability:顧客状況をデータで可視化して先回りした課題の解消

CREが顧客の眠っている課題の声を拾い上げる。

学び

つい先日、songmuさんのポッドキャストでCREについて知ったばかりだったので興味深かったです。

oss4.fun

今後、プロダクトエンジニアリングという働き方が求められていく中、
機能開発の日常からプロダクト領域に思考をめぐらすために、
プロダクト領域の見晴らしを良くしていく働きが求められていくイメージを持てました。

Win - Win - Win を目指す:BtoBtoCプロダクトにおける価値の定義

www.docswell.com

メモ

Helpfeelプロダクトの話。質問を検索すると記事にたどり着けるFAQサービス。
BtoBtoC。Helpfeel - 顧客企業 - エンドユーザー。
求める価値。
Helpfeel:売上
顧客企業:問い合わせ対応工数の削減
エンドユーザー:疑問/問題解消

Win Win Winのフレームワーク、The Knowledge Journey。

www.helpfeel.com


エンドユーザーの自己解決が一番大事。自己解決率を最大化する。
3つの開発起点:顧客要望起点、社内要望起点、エンジニア起点

・顧客要望起点
Helpfeelは自己解決率を最大化するためのツール。
たとえ顧客要望でも自己解決に寄与しないと実現しない。
1社しか使わない機能は作らない。顧客の抱える真のペインを解明。データドリブンな開発。

・社内要望起点
社内からの要望。業務効率化、プロダクト品質向上、開発効率の向上。

・エンジニア起点
Create The Feature。経営者視点で新たな機能を実現する。

note.helpfeel.com


顧客視点:顧客要望の実現
経営視点:ソリューション新規開発
開発視点:プロダクトの磨き上げ

参考:

speakerdeck.com

学び

Helpfeelさんのハックを楽しむという考え方が好きで、本日のイベントも楽しみにしていました。
自己解決率を最大化するためのツールという定義がとても興味深かったです。

パネルディスカッション

toCでもブランドが求められる、機能性が求められるなどプロダクトによって違う。
主観で捉える部分、データで捉える部分とtoB/toCの兼ね合い

どういったエンジニアと一緒に働きたいか?熱量?ロジカル?

・虎の穴ラボ
両方できた方がベスト。ただ、パッションは重要。
データは再現性があるが、プロダクト開発を持続させていくための熱量は重要だと思う。

・Helpfeel
もともと個人開発者重視。エンジニアパッションを重視していた。
顧客が増えていく中で、顧客分析・データ収集が求められてきている。
文化はパッションを大事にしているが、近年はデータやデータ分析が求められている。

・SmartHR
企業のフェーズで変わってきている印象はある。
50人規模の頃はパッションで動く人が多かった。
最近は顧客要望、ユーザーヒアリングによるデータドリブンの動きが重視されている。
サービス/ブランドのファンを目指すために一緒に働ける人がよい。

採用で何を基にプロダクト成長ができるエンジニアとして見極めている?

・Helpfeel
今までどういった姿勢で仕事と向き合ってきたか。
仕事に対するオーナーシップ度合い。自分の言葉で伝えることが重要。
Helpfeelでは、事業部側に決定権があるが、エンジニア側でも判断している。
一人での開発はあるが、説明できることを重要視している。

・SmartHR
エンジニアは基本的にはプロダクトエンジニア。
チーム開発の経験、可能性を大事にしている。

・虎の穴ラボ
プロダクトエンジニアは中長期を見ていく。
そのために文章を残していくことも重視している。

今まで出会った人の中で一番惹かれた人は?

・Helpfeel
個人開発者重視。個人開発で月間何十万を達成している人。
そうした人は自分のプロダクトに熱量を持っている。
そうした熱量を自社プロダクトに向けて貰えたらと考える。

・SmartHR
技術的にもコミュニケーション強いエンジニア。
一緒に働いていて頼もしい、奮い立たされるエンジニア。

・虎の穴ラボ
思想があるエンジニア。
未来を考える上で根拠がすべてではない。そのために思想が重要。
やりたいことを持っているエンジニアに惹かれる。

社員数が多い中で領域を分けないことを維持する方法

・SmartHR
採用は分かれてはいるが、あくまで軸足という意味合い。
フロント、バックの切り分けなど含め、チームに裁量を持たせている。

・虎の穴ラボ
面談時に確認をしている。より広い範囲を見えるように目指している。
分けないのはサイロを避けるため。速さを実現するため。

・Helpfeel
フロント、バックが分かるのは後になってから。両方できる必要がある。
それぞれの得意領域で活躍できるようにはなっている。

ユーザーの声をヒアリングする上で工夫している点

・虎の穴ラボ
ペルソナがはっきりしているので、その方に聞く。
反面、ペルソナを絞ると問題はある。
地域コミュニティで新しい気づきを得ている。

・SmartHR
toBは難しい。導入企業に対するユーザーヒアリングはしている。
ユーザーコミュニティでもユーザー同士のコミュニケーションから気づきを得ている。
製品の展示会で自分もブースに立って話を聞く。
商談の様子の録画を見ることができる。
マイナス面はドキュメントに残るが、動画だとプラス面も見える。

・Helpfeel
お金を出してくれるのは顧客企業。エンドユーザーからの要望は基本無い。
導入検討、乗り換え検討しているユーザーの声は重視している。
商談情報などすべてのドキュメントはCosenseにまとめられている。

学び

Helpfeelさんの個人開発者の文化に企業の力強さを感じました。
加えて、個人に埋もれないよう説明責任を持たせるといった仕組みが機能するイメージを持てました。
SmartHRさんの展示会でのブースに立つことに魅力を感じました。
テックカンファレンスでもエンジニアの方が企業ブースに立っている企業様は直接フィードバックを得ることができ、エンジニアの成長に寄与しそうと思っています。
虎の穴ラボさんの変動性の激しい世の中だからこそ、思想があるエンジニアを求めているといった話も好きでした。
また、プロダクトエンジニアリング = フルサイクルエンジニアリングと捉えた時、各社とも当たり前にサイロを作らないエンジニアリング組織を実現していて魅力的に感じました。
自分はtoBのプロダクトに携わることが多いですが、エンドユーザーを理解することの意義を改めて感じました。

懇親会

3名の登壇者の方たちそれぞれと直接お話できる運営が素敵でした。
イベントの主催について、リモートの働き方について、エンジニアリングコミュニティに対する捉え方など勉強になりました。
背景の異なる企業の方たちとコミュニケーションをさせて頂き、改めてプロダクトエンジニアリングに対する時代の要請を実感しました。
関係者の皆さま、貴重なお話をありがとうございました。

感想

特色のある3社のプロダクトエンジニアリングの実践のお話を聞き、改めて各企業ごとのプロダクトに沿ったプロダクトエンジニアリングの在り方があることが学びとなりました。
また、熱量の話がとても好きでした。それだけトライ&エラーを繰り返していくためには、技術力も当然ですが、ロングランしていけるだけのモチベーションが必要になる想定をしています。
改めて、イベントを通してプロダクトエンジニアリングに対する解像度をあげることができました。
プロダクトのその先を意識したエンジニアリングを実践していきたいです。

補足

配信も残ってるのうれしい!

www.youtube.com

PRODUCT HISTORY CONFERENCE 2025 DAY2に参加しました

PRODUCT HISTORY CONFERENCE 2025 DAY2に参加しました。
カンファレンス参加から得た学びをまとめます。

イベントの概要

「プロダクトヒストリーカンファレンス2025」は、AIの進化とともに変わりゆく時代のプロダクト開発に光を当て、未来への手がかりを探るテックカンファレンスです。PdM・エンジニア・デザイナーなど、プロダクトづくりの実践者たちが登壇し、プロダクトの裏側にあるリアルな試行錯誤や、普段語られない失敗・迷いに迫ります。2025年はご好評を受けて2日間に拡大。これからのプロダクトの在り方と進化を探る濃密な2日間を展開します。

引用:

lp-prohis.youtrust.jp

イベント参加の背景

  • 昨年のPRODUCT HISTORY CONFERENCEの体験がとても良かった。
    hiliteeternal.hatenablog.com
  • 昨年参加した方にセッションよりブースを楽しんだというお話を聞き、今回は自分もブースにも熱をあげようと楽しみだった。
  • 1日目は業務で参加できずでしたが、2日目は朝一のバイセル今村さんのセッションから、最後の懇親会まで終日参加。

参加したセッション

AI時代のCTO。プロダクト開発の今と未来

メモ

テックカンパニー化請負人。
バイセルは出張買取サービスのリユーステックカンパニー。
開発生産性についても連続受賞している。

CTOとは?フェーズごとに役割は変わる。
どのフェーズでも重要な役割がある。総合格闘家
経営者としての意思決定が重要。
中長期計画、プロダクト開発・エンジニア組織のマネジメントがそれにあたる。

CTOにとって中長期のビジョンが一番大事。短期は誰にでもできる。
CTOが経営戦略から逆算してテクノロジーやプロダクトをどう活用し事業を伸ばすかを考える。
未来から逆算する。
ビジネスモデル、現状/課題、今後へのビジョンからテクノロジー戦略/プロダクト戦略へつなげる。

参考:

ttj.paiza.jp


巨大な基幹システムを業務単位に分割した。
今までは必要なデータを抜き取って、BIツールに呑ませていたが、
今度はそのまま参照できるプロダクトを作った。
新しい基幹システムを作ったことでM&Aした企業に導入し、立ち上げを早くした。

DXの実現により、コスト削減などだけでなく、
グロース系の実現も顧客管理、買取など各プロダクトで実現できる状態を作った。
例:
・商品マスタ
リユース業界に商品マスタは無い。すべて網羅された情報がどこにも無い。
ゼロから商品マスタを作った。査定のための時間を短縮。
・在庫管理
リユース商品はすべて違う商品。おなじものは何一つない。
そうした要件に沿った在庫管理システムが無かったため内製し、
より多くを販売できる状態にした。

未来に向けて。
生成AI。インターネット登場からの伏線が色々回収されている感じもある。
数年後の未来になにを実現したいかをもう一度考える必要がある。
ビジネス職:
人間が注力すべきことは人間がやる。よりクリエイティブな仕事に注力。
定型化できる仕事は生成AIに。
エンジニア職:
AIネイティブな開発体制の構築による開発生産性の最大化。

全社生成AI基盤を作った。
通常オペレーションについての不明点をAI越しに確認できる状態を実現。
利用ガイドラインの整備。
生成AIツールには全力で投資を行う全社方針。
使用機会を増やすためにAIハッカソンを開催。知見共有のための勉強会開催。
昔だったら費用対効果が合わなかったことも、生成AIが軽量に実現してくれることを意識し、発想を柔軟に活用している。
CosmosがAPI化されているからこそ、AIとの接続が可能となり、業務オペレーションを更に進化することができる。

今後もAIネイティブなプロダクト開発体制づくりは続いていく。

学び

バイセルさんのプロダクトの改革に改めて凄みを感じました。
1つの巨大なプロダクトを分割することで拡張性を持たせ、そうしていたことで、今のAI活用もスムーズにいっていることに、エンジニアリングのありたい姿を改めて思い出しました。
そして、恐らく自分と今村さんが同い年なことにも恐縮しました。
インターネット凄かったし、iTunes凄かったし、YouTube/ニコ動恐かったし、AWAやばかったし、Netflixは劇的だったし。
そうした延長線上に生成AIがいるイメージがあります。

デザイナーはAIに何を任せ、何をデザインするのか

メモ

プロダクト開発におけるデザインの役割とAI活用。

・企画
情報収集に利用。データインプット、リサーチ効果の整理、ペルソナ生成、案だしに利用など。
活用例)ペルソナ生成。社内資料、アクセスログ、公開情報などからの分析・生成し、実際のインタビューなどの結果も踏まえて対話を繰り返すことで作成する。

・実装
パターン整理に利用。UIコンポーネント生成、バリエーション提案。レスポンシブ検証など。

・ベース
ルール化に利用。ガイドラインの整備、トンマナ、アクセシビリティチェックの自動化など。

AIはデザイナーを置き換えるのではなく、スピードアップする手段。

プロダクトデザイナーの注力ポイントは2つある。
・意味を問い直す力
・感情や文脈を読み取る力

学び

デザイン領域に対する知見があまりなく楽しみにしていました。
そして、とても学びになりました。
開発エンジニアと同様に、煩雑でそこまで価値を得ることができない作業はAIに任せ、
人間はより価値の高いことに注力していくことが重要になると感じています。
そして、AIが作ったペルソナに実際のインタビューなどを通した実データをもとに対話することで磨き上げるプロセスが重要であると感じました。

AIオールイン時代のプロダクト開発 ― DeNAの実践と学び

メモ

AIを使っての新規事業を作ってる。AIネイティブなプロダクト創りを進めている。

AIネイティブの定義。
プロダクトのコアな部分がAIによって継続して強化できること。

4oがなくなってショックを受けた人が多いことから、AIと人間には親和性の濃度があると考えている。生まれていた。
AIネイティブ論。ソリューション提供、機能リプレイス、体験のリプレイス、使えば使うほど親和性があがる。
DeNAでは体験のリプレイスと親和性のレベル感を重視している。
今までは企画書でやってたが手戻り大きかった。今はプロトタイプを必須にしている。

www.itmedia.co.jp


AIネイティブ度の高いプロダクト作りに必要なケイパビリティ。
PdM:生成AIを触ったモノづくりが好き。ユーザーのことを考えて作るのが好き。
デザイナー:AIネイティブなUI・UX作りに興味がある。
ソフトウェアエンジニア:AIネイティブなプロダクトのアーキテクチャや挙動整理に興味がある
AIエンジニア:AIそのものと事業の両立の仕組みを深く理解し、選定・性能改善ができる。

学び

AIネイティブのレベル感に今までなかった解像度を得ることができました。
人間とどこまで親和性をあげることが重要となるという話には、ラボットを思い出しました。
身体を持たなくても人間との距離感を縮めることができるユーザーフレンドリーなAIが重要となっていくイメージを持ちました。

AIエージェントの登場で大きく変化したプロダクト戦略の舞台裏

メモ

戦略とは、前提をもとに現状からVisionに向けた手段を戦略と定義できる。
前提が変わると取れる手段が大きく変わる。

大企業と中小企業ではAIの投資額も大きく違う。
日本の企業の多くは中小企業。日本の多くがAI投資ができていない。

前提を置くうえで大きな3つの観点
1. LLMの進化の限界⇒まだまだ進化すると思っている
2. AIが社会に受け入れられるか⇒導入には時間がかかる。結果、プロダクトの優位性を生む。
3. モデル開発企業は競合か⇒競合になりえる

モデルの進化を前提にスケーラビリティの向上に繋がるように仕込む必要がある。
AIの社会の浸透は、ユーザーに対する直接的なアプローチと、間接的なアプローチを切り分けて考える必要がある。
垂直統合が進む全体で、業務自体を管理できるようにする。

学び

kubellさんに以前カジュアル面談をして頂いたことがあり、
ChatWorkを展開されている中小企業にBPaaSを広げたいというお話を思い出しました。
そうした企業を活性化していくために、生成AIを活用していくことに共感します。

AIで 浮いた時間で 何をする?

speakerdeck.com

メモ

5、7、5。下の句、何をするかを考えたい。

・学習
AIの登場で世の中は劇的に変化し、あらゆる前提が崩れる変化を迎えている。

コード生成。
今まで構造化されていなかったデータの活用ができる。
設計、実装、テスト、レビューの一連で利用できるようにする、その前後でも活用できる。

ただ、ひとつずつが縮まるかたちで、最後に大きな余白ができる訳ではない。
コンテキストスイッチも多発し、結局は総量としては生産性が上がっていない気もする。
人間がAIに適応していく必要がある。

自分が理解できない部分をAIに任せるのは良くなさそう。
そうした意味でも、人間が学習して利用する必要がある。

何を学習するのか?
・関連技術、ドメイン、隣接領域
・AIツール、エージェントの仕組み
プロダクトマネジメント(何で作るかの部分)

学びを深めてAIと歩む。

・問い
作ることが簡単になることで、何でもすぐ作ってしまいたくなる問題がある。
ビルドトラップに陥りやすい。
なぜ作るかの問いの力を今まで以上にしみこます必要がある。

問いの底上げは、ユーザー理解と自分で考え抜くことで実現する。

問いを磨いて、答えを導く。
新しいことでは無く、昔から言われるプロダクトマネジメントの知見を活用する。

・禅
生産力が2倍になると人はどうするか。
2倍を3倍にする?適応を繰り返す?
AIで浮いた時間をさぼるという選択肢はないのか。

組織としてすぐには変化が起こらないと思う。
ただ、将来的には週休4日とかはあり得るかもしれない。

専門職のプレイヤーとしては楽しんで適応し続けることを考えていく方がよさそう。
ただ、加速し過ぎるのは気を付けた方が良い。
忙しくし過ぎるとクリエイティブな発想は生まれない。
AIの出力結果だけを頼り続けるのは今は避けた方がよい。
人間にとって価値のあるプロセスも手放してはいけない。

余白味わい、心を磨く。
AIを使わない対話も重視する。

学び

問いと創造する価値。
忙しくし過ぎるとクリエイティビティは失われるため、
我々はどうしても作ってしまう意欲に翻弄されがちなことを意識すべきと気付きました。
AIに適応することと同時に、退屈さを能動的に受け入れる必要があると思いました。

混沌を楽しめる組織が未来をつくる〜AI時代に変わらない大切なこと〜

メモ

・創業期(PMF前)
試行錯誤。
良かったこと:まず出した。新プリに作った。即決ルール。
良くなかったこと:作ってうまくいかないものもあった
理想ではなくて、ユーザー理解がすべてだった。

・成長期
限られたリソースで葛藤
良かったこと:セキュリティに挑戦。やらないことを決めた。本質的な課題を扱えた。

・拡大期
急成長に耐性が追い付かない
良かったこと:開発チームの分割(機能開発、運用基盤、品質向上)、AI導入

組織で大切にしていること。
・自分たちが一番のファンになる
・ユーザーと市場に徹底的に向き合う
・現場に飛び込む
・同じ志を持った仲間とチャレンジする
・大きな挑戦を掲げる
・小さなwinをたたえ合う

これから。
AIは劇的に進化している。
AIが答えを返す時代だからこそ、人間が問うことを重視する。

学び

試行錯誤を含めエンジニアリングの魅力を感じました。
特に自分たちのプロダクトを好きであることが、プロダクトを成長させていく原動力になると改めて感じることができました。

プロダクトを超えて事業をハックする ─ AI時代に、ドラフト1位エンジニアになる方法

メモ

事業貢献をしているエンジニアとは、社内ドラフト一位となれるエンジニア。
社内貢献は難しい。
プロダクト中心のフレームでは、プロダクト = Whyを越えづらい。
自分の役割を会社中心で考えてみる。会社もプロダクトとして捉えることができる。
事例:ドメイン知識の形式知化。PdMの物理的・時間的拡張。分析の民主化
weを最大化して、プロダクトバリューの最大化を目指す。
好奇心・創造性・探求心でエンジニアリングの強みを活かす。

学び

ソフトウェア以外のものごともプロダクトとして捉えられるといった及川卓也さんの言葉を思い出しました。
企業もプロダクトとして捉えることを意識できていなかったことに気付きました。
規模はコンテキストに依存すると思いますが、自分の所属する組織をプロダクトとして捉え変革していくイメージを持ちたいと思いました。

面接をするAI、面接を測るAI ─ 生成AI時代の開発と学び

メモ

harutaka。面接実施のためのサービス。
面接をコミュニケーションの場として捉えている。

harutakaはコミュニケーションAI。
顧客分析のための非言語解析、言語解析を実施し、面接をサポートしている。
AI模擬面接のための対話システムを実現している。
面接後のフィードバックも実現している。

現在1500万件のデータを持っている。データ基盤が重要となっている。
ただ、データを集約するにあたり技術負債の解消が課題となっている。
生成AIの活用で開発時間を80%短縮、PRドキュメント作成:100%短縮している。

非エンジニアにも生成AIの利用を促しており、顧客対応に当たる業務をAIなどで実現している。

AIの力を使って、人の力を引き出すことを考えている。

学び

ブースでも話をお伺いさせていただき、プロダクトの魅力を感じました。
面談の結果を判断するのではなく、面談の時間をより価値ある時間とするためにAIを活用することに、改めてAIを人間の営みを支援するために活用すべきと理解できました。

トヨタグループ内製開発組織が追求する、カルチャー×技術両輪によるAIとの協業

speakerdeck.com

メモ

効率はあがるが、収益はあがらない。
生成AI宣言。AIと人の手に両方で比較するなら迷わずAIを活用する。
事務生産性、開発生産性、クリエイティブで利用している。

AIを使いこなしているとは。
AIを中心に新しい価値を作っていく。既存の枠組にAIが適応していくこと。
効率指標から価値指標を目指していく必要がある。

個人活用は進んでいるが、組織活用にまでは繋がっていない。
組織活用に繋げるために基盤を固めていく必要がある。
Gen-AIパラドックスを抜けだして、事業/PLに繋げていく必要がある。
AIエージェント導入以前に、組織的に導入できる状態を築く必要がある。

AI活用をAIネイティブ型、トップダウン型、ボトムアップ型、アーリーアダプター型と分けることができる。
技術進歩に合わせ組織進歩を戦略的に実現していく。

・生成AIツールを使ったプロダクト開発
内製化の意義:全員使える、独自機能の実装、生成AIツール開発力の醸成
社内に広げるために:期待を損ねない/離脱防止に向けた当たり前品質、継続的周知、計測による施策立案とロードマップ策定
測れるから伸ばすことができる。詳細な活用ログでデータ駆動的なアプローチを実施。
現状、浸透はできたため、次は成果を目指していく。
最低限の機能、独自機能の両面で継続開発を実現していく。

学び

開発生産性カンファレンス以来kintoテクノロジーズさんに大きな魅力を感じています。

hiliteeternal.hatenablog.com


AI活用に対するどちらか悩んだらAI活用に踏み倒せといった前傾姿勢に魅力を感じました。
また、「AIを使いこなしているとは」を定義することは、使うことに溺れることを防ぎ、オーナーシップを持った活用を進めることができるイメージを持てました。

ブース

ブースめぐりを楽しみました。
特に特別なお時間を頂いてお話を伺える仕組みは満足度が高かったです。

kintoさんにはプロダクトの種類や、プロダクトごとのチームや開発プロセスについてお聞きすることができました。
お土産にトミカ頂けることも嬉しいです。
Gineeさんにはプロダクトの特性や求められるスキルスタックについてお伺いしました。
自分に経験のない領域のプロダクトのためとても勉強になりました。Pythonの採択についての議論が興味深かったです。
パーソルキャリアさんにはプロダクトや開発組織の話をお伺いしました。内製化に向けた課題や生成AIの活用についての話が興味深かったです。

また、製造業のDX化やAI活用を促進するような企業様のお話が、自分にも遠縁ではないため興味深かったです。
LAPRASさんには最近テックブログを書き始めた人間としてフィードバックに励まされているため、感謝をお伝えできて嬉しかったです。

ノベルティもありがとうございます。お菓子類は帰宅後さっそく娘にあげました。

懇親会

一方的に知っている方やSNS上では繋がっていた方とご挨拶できて嬉しかったです。
カオナビ社、魅力的なエンジニアの方たち多い。
聖蹟でのエンジニアニメ開催も楽しみにしています。

学びと感想

1日通して刺激と学びの多い1日でした。
いつも行くカンファレンスなどではお会いできない企業の方たちにもご挨拶できて嬉しかったです。
エンジニアの世界広い。
PRODUCT HISTORY CONFERENCEの参加者はエンジニア率が高いといった話を聞き、プロダクトの歴史に興味があるエンジニアが集まるカンファレンスって素敵だなと思いました。
来年の開催も楽しみです。

会社の中で使えるファシリテーションスキルを向上するための研究会 -実践編 #1- に参加しました

会社の中で使えるファシリテーションスキルを向上するための研究会 -実践編 #1- に参加しました。
イベントに参加した感想をまとめます。

イベントの概要

昨今のシステム開発では、スクラム開発や学習する組織など従来のトップダウン経営ではなく組織力、チーム力を底上げすることで価値を生み出すという自律型組織という考え方が主流となっています。自律型組織を作るためには、メンバー間のコミュニケーションを通じて心理的安全の醸成や価値観の共有などが必須となっており、そのプロセスが非常に大事であると考えます。そのようなコミュニケーションが求められる中で、ファシリテーションというものに大きな可能性を感じています。

実際、ファシリテーションが使われる場面は多岐に渡ります。 スクラムイベント、チームイベント、ワークショップ、様々なふりかえり、などなど大小様々な場面でファシリテーションが必要とされます。

本イベントでは、ファシリテーションを実際にやってみてぶつかる壁や難しい場面に直面することで、さまざまな気付きや学びが得られ、現場で活かせるファシリテーションを身につける事を目的としています。 また、ファシリテーターの意図開きや参加者同士のフィードバックを行うことでより多角的な視点でファシリテーションについて学べる機会にしたいと思っています。

引用:

faci-ken.connpass.com

イベント参加の背景

  • チーム開発を進める中でチームとしての認知形成が重要だと思っている。
  • そのためにはいかにメンバー間のコンテキストを醸成していくかが重要だと思っている。
  • そのためにチームを有機的に醸成できるファシリテーションが重要だと思っている。

ファシリテーション実践

1回目シチュエーション:チームのコミュニケーション活性化施策を考えよう

自分がファシリテーションするつもりで事前準備(15分)

会議の事前準備の経験がほとんどなかったことに気づきました。

まず25分という会議時間に対し、タイムスケジュールの検討から始めました。
ただ、それだけでは効果的に場が流れる想定ができず、原動力となるチームの目的が必要となることに気がつきました。
その上で、目的は個々人の目的ではなくチームで認知が揃った目的であることが重要と考えました。
加えて、自分がこの場を最悪にするとしたら、どういった状態だろうと考えたら、自分自身が最強の一手を提示して押し切ることでした。
そうならないように、皆の意見をすりあわせてチームの満足するゴールを目指せたらと考えることができました。
そして、目指すべきは完璧な施策よりも、持続可能なチームの活性化に対する共通の目的意識であると思いました。
後だしですが、TRYを考えることよりも、チームの課題感のすりあわせを重視するふりかえりと一緒と気がつきました。

もしかしたら、このような事前準備をしなくても、同じファシリテーションができたかも知れないとは思いつつ、できない可能性ももちろんあるし、できなかった時に個人的な後悔はあるだろうし、何よりその場の参加者のもしかしたらより良い時間を過ごせたかもしれない可能性を奪う結果にもなると気づきました。
そのために事前準備のために個人の時間を使うことはファシリテーションする人間にとって重要な仕事であると思いました。

会議(25分)

なんとじゃんけんに勝ち続け、1回目のファシリテーターの座を頂戴しました。
皆々様ありがとうございました。
このような研究会に参加されている方たちだからこその有機的な場になった気がして楽しかったです。

ふりかえり(20分間)

会議が終わってから、具体的な発言をし過ぎたことに反省をしていましたが、自分で気になるほど人は気にはならないという気づきを得ることができたことが大きかったです。
そこで萎縮するぐらいなら、意識しない方が良い気もしました。

また、進行の補正を入れてくださった方からは、改めて場の進行はファシリテーターだけの仕事ではないことに気づきました。
極論、下手なファシリテーションでも、それがきっかけに場が機能して価値ある時間にすることができれば、それも効果的な選択肢のひとつになるのではと思いました。

自分の強みの再確認ができたことも嬉しかったです。

また、ファシリテーターとしての物理的なふるまいの重要性も改めて実感できました。
時計が確認できる場所でファシリテートする。書いた付箋は皆が見れるようにする。
当たり前だけどできていませんでした。
ただ、それは価値を実感できていなかったからで、見づらいよ、というフィードバックを頂いたので、それが経験となって今後意識していけます。
そうした意味合いでも、やっぱり実践は重要。

2回目シチュエーション:コミュニティ主催イベントのテーマとメインコンテンツを決めよう

自分がファシリテーションするつもりで事前準備(15分)

最初に、1回目と同じ時間や場の設計では会議のゴールに至れないことが想定できました。
一概に会議と言ってもその種類は様々であり、事前準備の重要性を更に気付くことができました。

今回、会議の目的である企画書がどういったものか分からず、以下のような進行を考えていました。
①企画書に書く必要事項のすりあわせ(テーマ、メイントピック、他に何か必要?)
②我々がどういったコミュニティであるかのすりあわせ
③②の内容を①当てはめていく

①をプロダクト開発におけるアーキテクチャと考えると、チームで調べて自分たちのものとした方が良いかを悩みました。
ただ、25分という会議の時間設定から、本当に集中したいのが②③と考えると、①には時間を使わず、事前にファシリテーターが調べた/定義したものを提示して、時短する手段を取っても良いと思いました。
そこで、改めてファシリテーターはタイムボックス内で会議のゴールに対する価値を最大化することを主な関心事とすべきと気づきました。

また、②については収束が求められると思っていました。
そこをどう実現していくかは実践しながら考えようと思っていましたが、
果たしてそれでうまくいったのか。

会議(25分)

小泉さんのファシリテーションに撃たれました。
ゴールに対する主体性を感じ、そのためにどうすれば良いかを常に考えながら進めるファシリテーションに、ボールを持って走る力強さを感じました。
また、目的と形式でそれぞれ置かれた付箋から、相互の関係が見えてきたときに議論が立体的になったように感じました。
その関係性を提示し、参加者の視野を広げられるのは、凄すぎました。
それを体験できただけでも、大きな価値があったと思っています。

ふりかえり(20分間)

会議が始まる際のファシリテーターとしてのあいさつや、自己紹介について、
最初こそテンプレとして感じつつ、それが効果を発揮することに気づきました。
場の始め方について改めて重要であると気付くことができました。

小泉さんにフリーレン完走した旨お伝え出来て嬉しかったです。

hiliteeternal.hatenablog.com

感想

イベントを通して大きな学びが多くありました。

とてもとても大きな体験となりました。
しょっちさん、gaoryuさん、交流させて頂きました皆様ありがとうございました。

補足

gaoryuさんの蔵書整理で頂いた一冊。嬉しすぎます。

『パタン・セオリー』を読んで ~ システムの制御から支援に

読書メモ。2025年64冊目。
『パタン・セオリー』を読んでの感想となります。(2025/9/14記載)

本の概要

本書『パタン・セオリー』は、現代の重要な思想家である建築家でシステム理論家のクリストファー・アレグザンダーカリフォルニア州バークレー大学名誉教授)の仕事を要約したものです。1979年、彼の著書のひとつである『パタン・ランゲージ』は、建築と人間生活に関する1100ページに及ぶエッセイで、50万人の読者を魅了するノンフィクションのベストセラーとなり、さまざまな分野の人々にインスピレーションを与え続けています。2002年から2004年にかけては、さらに幅広い4巻のエッセイ『The Nature of Order(秩序の本質)』が大著として出版されました。

アレグザンダーのライフワークは傑出しています。彼は、デザイン・パターンとパタン・ランゲージを手法の一部として用いることで、センター、全体性、変容という概念に基づくシステム理論、生命システムの一般理論を展開しています。アレグザンダーは、自然科学の伝統的な因果的機械論的パラダイムに対立する新しい科学的パラダイムを提案し、人々を可能にし、デザインプロセスへの参加を支援する方法として、新しい知識フォーマットを提供しています。

アレグザンダーの理論はすでに教育、組織開発、パーマカルチャーにおいて有用であることが証明されており、ソフトウェアにおいてはデザインパターンが主流にさえなっています。多くの学問分野がこの発展に追随しようとしています。パタン・セオリーによって、私たちは思考を変え、世界を見直し、より公正な社会へと向かうことができるのです。これは、より多くの参加とより高い持続可能性につながります。アレグザンダーのコンセプトは、社会の変化とイノベーションのための思考の道具箱を形成するのです。

引用:

patterntheory.jp

動機

本書からの学び

はじめてのアレグザンダー本でした。
ケントベックによる『エクストリームプログラミング』での以下一文によりずっときになっていました。

アレグザンダーは、建築家の自己中心的な関心事は、施主の関心事と一致していないと指摘している。建築家は仕事をすぐに終わらせて、賞を獲得したいと思っているが、重要な情報を見逃している。それは、施主がどのように生活したいかという情報だ。アレグザンダーの夢は、生活に最も大きな影響を受ける人の手のなかに、空間を設計する力を取り戻すことだった。

何も背景を知らない中で、安直にコンテキストを意識しない建売住宅的な建築に対する批判かと思っていましたが、本書ではより立体的に生活に最も大きな影響を受ける人に設計する力を取り戻すことが重要であるかが説明されていました。

特に何事にもセンターがあり、それをとりまく全体感があり、無意識を含めた有機的なかかわりにより相互作用が生きた空間を作っていくという考え方が興味深かったです。
進化的アーキテクチャアジャイル、リーン、チームの自己組織化にもつながるような考え方に、改めてソフトウェアとの親和性も感じました。
また、東洋哲学だけでなく、コモンズのような考え方との共通点も気になりました。
そして、プロジェクトマネージャーの視点からも意識をしたいと思いました。

また、改めてアレグザンダーからの学びをどのようにソフトウェア開発に活かしていけるかも気になりました。
ケント・ベックだけでなくアレグザンダーからの学びを発信している人の考えなども追いたい。
改めてプロダクト思考の重要性も学び成した。

忘れたくないメモ

本書で特に印象に残ったポイントをふりかえります。

美しい建物をつくるには

アレグザンダーが科学者としてのキャリアの開始時点で、「美しい建物をつくるにはどうしたらよいか」と問いかけたとき、きっと新しい哲学を創造しようとしたわけではないでしょう。効率性や合理性で物事を考えるのが当たり前になった現代の私たちの耳には、この問いは素朴に聞こえるかもしれません。しかし、伝統的な社会では主観的な「美しさ」を問うことは至極当然のことでした。優れた芸術作品や建築物は、常に人間の価値観を表し、精神的な概念を象徴してきました。

効率性や合理性を念頭にものごとを考えるのではなく、美しさを考える。
効率性や合理性を美しさを実現していったあとに整理できたものでしかない。

問題の根源は、機械論的なモデルを使って世界を説明すること

アレグザンダー自身は、現在の問題の根源は、機械論的なモデルを使って世界を説明することだと考えています。つまり、「機械論的・因果的な世界観」が支配的であることです。自然科学や技術は、この考え方をうまく利用し、私たちの生活をさまざまに変えてきました。しかし、この成功は、私たちの社会と人類全体を脅かすような副作用をもたらさないか、という疑問が残ります。

問題の根源は機械的に捉えられるほど単純なものではないことを認識すべき。

機能と形は世界のすべてのシステムにとって切り離せない

アレグザンダーは、機械論的手法には本質的な問題があると主張しています。それは、現実とその特性についての限定的な認識をもたらし、メカニズムに関する事実、真か偽かの二元的な態度、直接的な因果関係しか認めないことです。機械論的思考は、モデルが満たすべき機能的条件を特定します。その機能的条件にどの構造(形)が使われるかは重要ではないので、機能と形はほとんど関係がないものとして突然切り離されます。しかし、アレグザンダーは、機能と形は世界のすべてのシステムにとって切り離せないものであると指摘しています。

すべてのシステムは能動的であり機能や形と切り離すことができない。

機械論的世界観の結果

機械論的な世界観の結果として、建築の内外を問わず、思想や価値観の恣意性(何でもありの立場)が生まれ、芸術家にとって破壊的な結果をもたらしました。まず、世界観から「私」が取り除かれ、次に価値観も、取り除かれました。最後に芸術が人間の基本的な必要性から不必要な贅沢品へと変化しました。このような発展の過程で、秩序や美の概念は、客観性と主観性が分離しました。そして、美の概念は対象物と離れ、 その基礎と意味を失いました。因果的・機械論的な世界観は、感染症のように私たちのプロセス(動的構造)を傷つけ、建築やその他の構造物全般に美を生み出すことをほとんど不可能にしてしまったのです。

美しさは主観性が定義するものであり、客観性が定義するものではない。
主体が無いところに美を生み出すことはできない。

生きているシステムの発展を支援

アレグザンダーは、世界の現象やプロセスを理解するための別のパラダイムを示しています。すべてのものは多かれ少なかれ生命があるとみなされます。パタン・セオリーの最高の価値は「生命」であり、好ましいモデルは「有機体」であり、主たる目標は生きているシステムの発展を支援することです。

生きているシステムの発展≠外部から要望された発展。
外部からの要求・要望をもとにシステムは自己発展していく必要があると理解しています。

正の空間(相補性)

街の空間の利用は、家の形やそれらの間のポジティブな空間の両方と結びついており、それらは具体的には、広場や小道、道路などを形作ることになります。より抽象的に見ると、これは「正の空間」が相互に補完しあっていると言えます。スポーツ志向の人の割合が高いところでは、多種多様なスポーツが存在します。成功するプロジェクトでは、特別な団結心を介してチームメンバーがまとまり、相互に補いながらチームワークが促進されます

活き活きとした環境には正の空間があるとイメージしています。

場の感覚に鋭敏なファシリテーター

パタン・セオリーは、これらとは異なる理想と価値観を持っています。 文化を基礎として発達したパタンは、誰も独占しようとしたりしてはならない集合知であり共有財なのです。つまり、社会的・民主的な思想の根幹について語っています。アーキテクトの役割は、「先見性のあるリーダー」から「場の感覚に鋭敏なファシリテーター」へと変化します

コマンド型ではなくサーバント。ファシリテーターという表現が好きです。

自己成長

公園に計画された歩道が人々のニーズに対応できない場合、彼らはしばしば自分たちで道を作ります。したがって、あらかじめ形を決めてしまうのではなく、プロセスから形が生まれてくるようにするほうがより良い場合が多いのです。

対象が独自の発展を遂げることを支援することが重要。

常にもっとも重要なことを最初に行い、 それを正しく行う

自然の発展は、常に「全体性」に基づいた段階的なプロセスだとアレグザンダーは言います。自然界には突然の変化はなく、いくつかの非常に素早いステップが連続して行われたときに、そのように見えるだけかもしれません。私たちは、常に一度に1つのことに集中して一歩一歩進んでいくという考えに、ゆっくりと慣れていかなければなりません。アレグザンダーは次のように勧めています。「常にもっとも重要なことを最初に行い、 それを正しく行うこと。このステップを終えて、次のステップに入る前に結果を確認すること。」

アジャイルやリーンの考え方と一致すると理解しました。

生命の概念は空間と時間の中で展開される有機的構造と直結

アレグザンダーは、この生命の概念が、空間と時間の中で展開される有機的構造と直結していると、提起しています。これらの構造は、明確に定義され、記述され、理解されます。例えば、建築の概念で言えば、庭の池に、生き生きしたアヒルが住み着くと、住まいはより生き生きしたものになるのです。私たちの精神は、周囲の生命や、私たちの周りの環境の生命力との関わりの中で成長します。

我々やプロダクトは日々の有機的なかかわりの中で進化を続けている。

当事者

自分たちにとって何が正しいのか、 何がベストなのか、それを見出すことができるのは、参加しデザインするという特別な状況にある当事者だけなのです。

経験主義と同じことと理解しました。

 

参考

Helmut Leitner: Pattern Languages and Christopher Alexander: Introduction and Crash Course

www.youtube.com

【書籍紹介】パタン・セオリー:クリストファー・アレグザンダーの理論に関する序論と展望

note.com

チーム開発を加速する!エンジニア・デザイナー・PdMの職種間連携【D-Plus Tokyo #18】 に参加しました

チーム開発を加速する!エンジニア・デザイナー・PdMの職種間連携【D-Plus Tokyo #18】 に参加しました。
イベントに参加した感想をまとめます。

イベントの概要

「良いプロダクト」をより速くユーザーに届けるためには、エンジニア、デザイナー、PdMといった異なる専門性を持つメンバーが、職種の壁を越えて連携することが不可欠です。
しかし、多くのチームにおいて「仕様の認識がズレて、手戻りが発生した」「お互いの専門領域に遠慮してしまい、踏み込んだ意見が言えない」「会議ばかりが増えて、開発スピードが落ちてしまう」といった課題が、あるあるの悩みになってはいないでしょうか。

本イベントでは、「チーム開発を加速させる職種間連携」をテーマに、
・エンジニア、デザイナー、PdMは、互いの役割をどう理解し、リスペクトしているのか?
・円滑な意思決定と素早いアウトプットを、どのようなプロセスやツールで実現しているのか?
・職種間の意見の対立を、どう乗り越え、より良いプロダクト作りに繋げているのか?
といったリアルな工夫や成功・失敗談を、最前線で実践する方々からLT会形式で共有していただきます!✨

引用:

d-plus.connpass.com

イベント参加の背景

  • D-Plusのイベントにいつも学びと刺激を頂いている。
  • プロダクト領域、デザイン領域に対するエンジニアの越境について学びたい。
  • 遅刻しつつ久しぶりの現地参加です!オンライン同時開催助かります!

セッション

プロダクトを超える!事業全体を前進させるデザイン連携の舞台裏

メモ

プロジェクト1:コミ単

giftech.io

エンジニアとして社会課題を解決するプロダクトを作れた。
開発中のヒアリングもエンジニアが主体で行った。職種間の越境侵犯を実現。
デザイナーも生成AI使っていない人にどう届けることを考えた。

プロジェクト2:N1エンジニアリング

giftech.io

参加エンジニアのスキルアップにつながる運用を実現した。
デザイナーは参加者の体験向上、+αを考えて届けることができた。
イベント全体に合わせたデザインも考えることができた。

エンジニアとデザイナー、領域が分かれているがリスペクトを基にした越境をすることで、事業全体を前進することができた。
事業全体に関わり、職種間の橋渡しができた。

学び

向き合うべきプロダクトに対する熱量が役割の障壁を溶かすイメージを持ちました。
役割で誰が何を行うのかを定義するのではなく、何をしたいから誰が何をするかを考えることができたら幸せだと思いました。

全員でゴールに向き合う!〜職種混合開発組織における合意形成の場の構築〜

speakerdeck.com

メモ

職種間連携がうまくいかないのは、
お見合い、修正漏れ、会話がかみ合わない、リソース不足が原因と考えることができる。
責務の違い、情報不透明性、優先順位の違い、フロー効率のボトルネックにより引き起こされる。
責務は明確にし、情報透明性は見える場所で議論し、フロー効率はフローを見直す。

責務はデリゲーションポーカーにより権限の再定義を行い、誰に何を決めて欲しいかを明確にした。
情報の透明性をあげるために、すべての議論をGithub Discussionに集約した。
修正漏れをなくすためにFigmaバージョン管理Issueを導入した。
結果、意思決定の停滞や仕様/デザイン変更の認知負荷を軽減できた。

開発サイクルの抜本的見直しのためにはAIエージェントを活用。
エンジニア組織は、越境を意図してあえて役割で区切っていない。
AIを活用して職種間の越境を目指した。
変化1:PdMがコードを読んで仕様理解が可能に
変化2:デザイナーがデザインモックを作成
変化3:デザイナーがカスタムコマンドを作成

AIエージェントの導入で職種の壁が解けつつある。

まとめ
・権限を明確化した。
・情報透明性をAIで解消した。
・今後、フロー開発の課題を全員で見直していく。

学び

AIが情報の透明性をあげる話に、先日のAI×開発組織Summitのメルカリさんのお話を思い出しました。
また、エンジニアだけでなく、事業全体でAIを活用することが新しいフローを生み出すことをイメージしました。

思考の渦から抜け出す - 個人・ロールを超えてコンテキストを揃える方法

メモ

・思考の渦とは?
個人ロールで思考が閉じてしまい、考えが閉じてしまうこと。
ロールの違いによる言葉の壁、優先順位の違いが原因となる。
ビジネス上の希求、プロダクト上での機能の役割、精度に対する関心
など役割によって求めることが違った。

開発サイクルのふりかえりで議論ができた。
目標の抽象度を無くし、チーム全体での具体的な目標を立てることができた。
チームのコンテキストを揃える重要度を学んだ。

・思考の渦から抜け出すためのチームの施策
ユーザーの声を起点とした会話を心掛けた。
ユーザーインタビューにエンジニアも同席。
表面的な機能要件ではなく、その背景にあるユーザーの事実に対する解像度があがった。
チームで共通の目的意識を築くことができ、ユーザーに対する価値を目指すことができるようになった。

各ロールが集まってゴールを決定した。
大事なことは最終的な決定を全員が腹落ちすること。
PdMが最終的な決定権を持ちチームはDisagree and Commitの精神で動いた。

議論を率直にするためにはチームの信頼性が重要。
そのために、ペア作業、PdMがAIで叩き作成、リフレッシュタイム、ストーリーライティングを実施。
インタビューを基にした事実・インサイトをもとにストーリーライティングを作成している。

各ロールが同じゴールを目指せるように動いている。

学び

現在、POともっとプロダクトについて語り合いたい熱があがっているため、身を乗り出して聞きました。
ストーリーライティング、学びたいと思いました。

要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める

speakerdeck.com

メモ

AI普及により生産性が1.5倍向上している。
その結果、開発より前の工程がボトルネックとなっている。
価値のデリバリーが速くなっておらず、チームサーベイにも課題が見える。

前工程のボトルネックを解消するために、Biz側からのPdM抜擢を実施した。
要件定義やFigmaでのデザイン作成を実施できる状態にした。
結果、人が増えることでコミュニケーションコストが増加し、
品質ばらつきなど新たな課題が浮上した。

人が増えてもコミュニケーションの質を下げないためにAIを活用した。
AIによって人が本質的な議論や創造的な取り組みに時間を充てることができるようにした。

デザインの最低限の品質担保のためにFigmaMCPを利用したデザインレビューを実施。ChatGPTによる要件定義。まずはフローに組み込むことを目的。成果物はチーム内でレビュー。

結果、AIによってコミュニケーションの密度を高めることができている。
AIにはできないクリエイティブな能力の強化を目指している。

学び

AIが役割の違いに対するハードルを下げていることを理解しました。
全体的に生産性があがった組織において、AIに作業を任せて少し体が空いた人間は
今まで以上に役割を越えた協業に向き合えるイメージも持てました。
そのためには、開発だけでなく事業全体でAIネイティブに向かう重要性も感じました。

懇親会

懇親会ではADWAYS DEEE豊島さんにストーリーライティングを中心にお話をお伺いすることができました。
チームはPdM、デザイナーを含めて5名程で、役割に関係なく日常的にDiscordで会話しているとお聞きすることができました。
改めてチーム人数が多いと誰かがやってくれるはずという変な力学が働いてしまうけど、人が少ないからこそ『自分たちでなんとかしなければ』という想いが強くなる、と感じました。
自分たちももっと日常的な会話から距離を縮めることができたらと思いました。
懇親会でお話させていただいた皆さま、ありがとうございました。
やっぱり、お互いのコンテキストをすりあわせることができる懇親会は貴重と感じました。
そして、いつの間にかぼっち感が薄れてきていて、嬉しく感じております。

感想

今回のデザインへの越境というテーマに7月のProduct Engineering Nightとの関心の重複を興味深く感じていました。

hiliteeternal.hatenablog.com

PdENightがエンジニアの越境が関心の中心であることに対して、D-PlusがDevOps的な役割のサイロを壊す話が中心であったことも興味深かったです。
D-Plusさん、多角的な視点で開発組織、開発チームがより能動的に活動できるようにするためには、というテーマにいつも刺激と学びを頂いています。
今後も楽しみにしています!!

余談

なんとほにゃにゃさんからストーリーライティングについての資料を教えていただきました!!
ありがたすぎます!!

blog.engineer.adways.net

speakerdeck.com

www.youtube.com

 

ほにゃにゃさん合流後のD-Plusも楽しみにしています!!

 

渋谷アジャイル@スタートアップ#14 に参加しました

渋谷アジャイル@スタートアップ#14に参加しました。
イベントに参加した感想をまとめます。

イベントの概要

渋谷アジャイルは、スタートアップでアジャイルを試行錯誤している人たちが各々の関心を持ち寄り対話・議論する実践型のコミュニティです。毎月第2水曜日にミートアップを開催しています。

会はOST(全員参加型コンテンツ: 後述)を軸に進行しており、スタートアップのリアルな現場からアジャイルコミュニティを盛り上げることを目指しています。

スタートアップは不確実なものを取り扱う性質上、アジャイルとの親和性は高いと考えられます。しかし現実には、チームや会社、事業の状況が目まぐるしく変わるスタートアップならではの悩みも多く見られます。

  • チームが拡大しているが、カウボーイ開発からチーム開発に切り替えられていない
  • チームがアジャイルを学んでおらず、開発プロセスがないことをアジャイルと呼称している
  • 学んできたプラクティスを、チームの状況を考慮せずにそのまま適用してしまっている
  • 社内のステークホルダーと健全な対話ができておらず、PMや営業との対立構造に陥ってしまっている

渋谷アジャイルは、スタートアップに身を置く参加者それぞれが抱えるそんな課題や悩みにフォーカスを当てていきます。

引用:

shibuyagile.connpass.com

イベント参加の背景

  • #10の参加を通した発見と学びが多かった。
  • アジャイル開発を行っているが自分の領域を抜けられていない。
  • アジャイルを実践されている方たちのお話を聞いて学びたい。

会場

はじめてのタイミー社にお邪魔しました!

timee.co.jp

オープニングセッション:めちゃめちゃ営業利益が出るプロダクトをどう作るか

メモ

めちゃめちゃ営業利益が出るプロダクトをどう作るか。

例えば、「食事を楽しみたいけどダイエットをしたい」。
普段何してる?おいしいものでも脂っこいものをひかえる、など。
大切にしていること:健康に気を付ける。
我慢すると、まずい結果がある。美味しい食事に対する我慢。
結果、美味しい食事を楽しみたいというニーズが生まれる。
それによって、暴飲暴食などが生まれる。
結果、体重が増える。結果、もとのダイエットに戻る。
結果、行ったり来たりする。

こうした状態を上手く解決するサービスを提供したら、収益があがる。

健康を大切にする、食事を大切にする。
この2つのことを実現するために、以下をする。
・食事制限
・暴飲暴食
良いプロダクトはこの2つのニーズを満たすものを提供する。
今まで満たせなかったものを満たせるようになる。
そのためには、高価格のものでも提供ができる。

ニーズA:見込み客が何に苦しんでいるか、そのために致し方なく何をしているか
ニーズB:本当にしたかったこと

このニーズを満たせることが重要。結果、営業利益が出せるようになる。
プロダクトバックログアイテムなども、こうしたニーズを満たせるかを確認することが重要。

クライアントにそのまま質問をそのままの答えが返ってくるわけではない。
クライアントも無意識の中でトレードオフをしている。
質問を通してその内容を引き出していく。
クライアントがどれぐらい時間やお金を費やしてきているかが重要。

感想

自分は開発者側の立場ですが、プロダクトバックログを考えなしに受け入れてしまっていたことに気が付きました。
プロダクトバックログを解像度をあげて理解し、まずは自分のものとしても把握できるようにしたいと思いました。
そのうえで、スクラムチームとして扱えるようになりたいです。

OST

OSTの説明

speakerdeck.com

1回目:コードから離れたEMの寿命について / プレイングマネージャーについて語りたい

私はここ数年開発案件のプロジェクトマネージャーを務めてきました。
プレイの領域からは数年単位で離れてしまっていましたが、今年の4月から復帰しています。
そんななか今回のテーマはかなり関心がある内容でした。

以下、話し合われた内容のメモです。

  • コードから離れることで開発のコンテキストから離れるのが恐い
  • エンジニアのマネージャーであるには、エンジニアリングに対する理解が重要だと思う
  • エンジニアリングの理解がなくなったマネージャーはただの管理職になる
  • かつてのエンジニアリングに対する無理解な管理職にはなりたくない
  • 生成AI時代、少しの間でもコードを書くことから遠ざかるとエンジニアリングに対するコンテキストを見失いそう
  • かといって、プレイとマネジメントの両立は難しい
  • プレイに引きずられてマネジメントが不充分なプレイヤーになりがち

長い間プレイから離れてしまった自分にとっては共感できる内容ばかりでした。
また、自分の体験としては、久しぶりにプレイに帰ったことで自分のスキル不足は感じつつも、チーム開発というコンテキストを理解できたことが何より大きな価値と感じています。
同様に生成AIがどのように変化をもたらすかも解像度を上げて理解をしていた方が良いとも思っています。

ただ、反面、今更プレイの領域では強いメンバーに勝てるとは思っておらず、プレイは彼らに任せつつ、彼らがまだ持っていない知見を譲渡・醸成したり、彼らがプレイで活躍できる領域を守るためのマネジメントを行うことが重要と思えました。
改めて、お悩みをお聞きすることで、照らし合わせて自分の思考を整理することができました。
貴重な体験をありがとうございました。

2回目(前半):エンジニア脳とビジネスサイド(マネージャー)分かりあい

POともっと仲良くなりたいと考えている自分にとって今こそ聞きたいテーマでした。
主に以下の内容が話として出ました。

  • 同じチーム内でもメンバー間で役職などの上下関係があるとその関係に引きずられがち
  • ビジネスと開発で大事にすることの違いから歯車がずれがち

情報の非対称性や、共通目的の不明瞭さが、スクラムを機能不全にさせるイメージを持ちました。
改めてお互いに向き合うのではなく、共通目的に対する向き合いを大事にしたいと思いました。

自分の課題はそのような状態がある程度実現できているうえで、どうやったらPOとプロダクトの成長していく姿についてもっと会話ができるかでした。
まず、そのための時間を持ち、お互いの会話のテンポを合わせていくことが重要と考えています。
WhyとかWhatとかちゃんと腑に落ちるまで会話を終わらせちゃいけないんだとは思っています。もっと距離を詰めていきたい。
我々が知るべきはビジネスの話だとして、考えたいのはプロダクトをどのように成長させていきたいか。

2回目(後半):会社の人を社外(コミュニティ)に連れ出したい!どうしたらいい?

必ず週に1度は外出している人間として、自分も関心のあるテーマでした。
途中参加でしたが、以下のような施策が話し合われていました。

  • ログを発信し続ける
  • 会社の目標に合わせて能動的に動ける状態とする
  • 社内勉強会の延長線上で誘う
  • 自身の登壇や運営を理由に誘う

自分自身もSlackで気になるカンファレンスや勉強会の発信は随時行い、
登壇資料などの共有を行っているため、チームでも興味を持ってくれるメンバーが多いです。
ただ、次の一緒に参加するまでの距離を遠く感じています。
改めて、個人目標にアウトプットを設定することや、自身の登壇などを肴に外部参加を促したいと思いました。

いずれにせよ、自分自身の失敗経験から、自企業、自組織、自チームだけでの情報では井の中に陥りがちだと理解しています。
少しでもエンジニアリングの楽しさを味わってもらい、より文脈に依存しないエンジニアとしての成長を遂げられるように、外部に目を向ける取り組みを続けたいと思いました。

まとめ

2回目の参加でしたが、改めて多くの気づきと学びがありました。
また、前回よりもご挨拶ができる方も増えていて、そのことも嬉しかったです。
マネージャー、ビジネスと開発、コミュニティ、いずれも自分の関心のある領域を他者のコンテキストから悩みをお聞きすることで、気づく部分が多くありました。
また、帰り道はかつてアジャイルコーチとしてお世話になった方と一緒になり、近況のご報告ができて嬉しかったです。
貴重なイベントをありがとうございました。