器用貧乏が強みになるまで～「なんでもやる」が導いたエンジニアとしての現在地～

by KAKEHASHI

Slide 1

Slide 1 text

©KAKEHASHI inc. 器用貧乏が強みになるまで〜「なんでもやる」が導いた現在地〜 2026年02月20日もっち(松本明紘) Developers Summit 2026

Slide 2

Slide 2 text

器用貧乏 2

Slide 3

Slide 3 text

最近、器用貧乏だなあって思ったタイミング本書きたいなあって思ったけど、自分だったらこれだなってものがパッと出てこないふと副業を始めてみようかなって思ったけど、何を武器にするのが良いか分からなかった 3

Slide 4

Slide 4 text

深さ(専門性)が足りない気がする 4

Slide 5

Slide 5 text

XXXのスペシャリストって言いたい！ときもある 5

Slide 6

Slide 6 text

でも、同時にこうも思っている ● 器用貧乏だからこそ貢献できたこともたくさんある ● そんな自分でも良いと思っている自分もいる 6

Slide 7

Slide 7 text

つまり、今でも悩みながら進んでいる本日お話するのは、成功体験ではありません。 N1の正直な迷いと、それでも前に進んでいる現在地。 7

Slide 8

Slide 8 text

それでも本日伝えたいこと ● 器用貧乏は色んな変化の中でたくさんのチャレンジをしてきた結果 ● 変化の激しい時代だからこそ変化への耐性は強い武器になっている 8

Slide 9

Slide 9 text

株式会社日立製作所(２０09年4月〜2023年2月) 株式会社カケハシ(2023年2月〜現在) ● AI在庫管理、新規プロダクト ● バックエンドに軸足を置くテックリードもっち(X: @mottyzzz) 松本明紘自己紹介 9

Slide 10

Slide 10 text

大学生のときからコードを書くのが一番好きだった ● 構造を作るのが好きだったオブジェクト指向、アーキテクチャ、データ構造自動化 ● 毎日リファクタリングしてた ● 正月もコード書いてた 10

Slide 11

Slide 11 text

バイブル CODE COMPLETE Steve McConnell 著 (株)クイープ訳リファクタリング Martin Fowler 著児玉公信訳友野晶夫訳平澤章訳梅澤真史訳エンタープライズアプリケーションアーキテクチャパターン(PoEAA) マーチン・ファウラー著長瀬嘉秀監訳株式会社テクノロジックアート訳 Enterprise Integration Patterns (EIP) Gregor Hohpe 著 Bobby Woolf 著 Refactoring to Patterns Joshua Kerievsky 著 11

Slide 12

Slide 12 text

EP1：入社してミドルウェアを開発する部署に配属 APサーバー製品、データベース製品などを開発・扱っている部署で、コードもたくさんかけて楽しかったちょっとイキってた 12

Slide 13

Slide 13 text

ある日、ユーザーとの接点ができた開発以外は自分の仕事じゃないと思ってた人と話すのは嫌いじゃないけど、人見知りだから嫌な気持ちの方が強かったミドルウェア製品システム開発利用開発提案利用や導入の支援開発チーム（　） 13

Slide 14

Slide 14 text

良いモノを作っていると思ってた ● 開発者目線では良いプロダクトを作れていると思っていた ● ドキュメントも丁寧に正しくたくさん書けていた ● マニュアル読めば全部書いてあるじゃんって思ってた (いわゆる「公式ドキュメント」読めってやつ) 14

Slide 15

Slide 15 text

ユーザーの立場に立ってみて ● 巨大なシステムの極一部 ● ユーザーからの視点で見ると、使いやすい・分かりやすいとは思えなかった 15

Slide 16

Slide 16 text

モノからコトへの転換 ● 「モノ(機能・製品)を作る」から「コト(体験)を作る」への転換 ● どれだけ安全なプロダクトを作っても、それだけじゃ安心感を持ってもらえるわけではなかった 16

Slide 17

Slide 17 text

あれコード書いてるだけじゃ価値とどけられないじゃん 17

Slide 18

Slide 18 text

EP2：自社ビルのトイレ混雑問題を解決する改善活動業務外で自分たちが困っていた課題に対しての改善活動チームも自分たちで構成する 18

Slide 19

Slide 19 text

自席から空いているトイレを見つけられるようにしたみんなのラズパイコンテスト2015：［優秀賞］社内トイレの空き個室を自席で確認、距離センサーで扉の開閉チェック | 日経クロステック（xTECH） https://xtech.nikkei.com/it/atcl/column/16/060700122/062000022/?i_cid=nbpnxt_child_parent 19

Slide 20

Slide 20 text

サーバー用意してセンサーつけて開発は簡単簡単！ 20

Slide 21

Slide 21 text

実際、モノはすぐにできた 21

Slide 22

Slide 22 text

ソフトウェア以外のところで課題がたっくさん ● Raspberry Piを会社資産に ● 設置許可 ● 総務、社内IT部門、警備との調整 22

Slide 23

Slide 23 text

他部署との調整とか自分の仕事じゃ…(略 23

Slide 24

Slide 24 text

パワフルに色んな部署と調整してくれた先輩の存在 24

Slide 25

Slide 25 text

正直、先輩かっこいいなと思った 25

Slide 26

Slide 26 text

そして、やってみての気付きも多かった ● トイレの屋根裏に電源とWiFi届かない ● ハードウェアの故障に気づかない ● 人感センサーの精度が悪い 26

Slide 27

Slide 27 text

マインドセットが変わってきた ● 他部署との調整もやるようになってきた ● 価値を届けるためには、コード書く以外にも大事なことたくさんある ● 他のエンジニアや、エンジニア以外の職種へのリスペクト 27

Slide 28

Slide 28 text

イキってたのも落ち着いた (視野が狭かったあの頃の自分恥ずかしい) 28

Slide 29

Slide 29 text

コード書くのも好きだけど価値を届けるのも好きだな 29

Slide 30

Slide 30 text

基本スタンスも変わってきたやったことないのでやってみたいです！ 30

Slide 31

Slide 31 text

EP3：新規サービス+プロダクトの開発 ● 初めての開発提案 ● その中でも自分はプロダクトの開発部分が中心 ● 第三次AIブームの中での機械学習系のプロダクト ● 尖ったコア技術があったサービスプロダクトコア技術 31

Slide 32

Slide 32 text

たくさん勉強もしたし、たくさん考えた ● 機械学習自体の仕組み、フレームワーク、ライブラリ ● コア技術のプロトタイプを製品化するためにアルゴリズムを理解 ● データ分析の方法論、プロセス ● ターゲットとなる顧客のドメイン知識 32

Slide 33

Slide 33 text

自分が予算獲得することになるととても大きなプロジェクト 33

Slide 34

Slide 34 text

すごい (自分比) 34

Slide 35

Slide 35 text

これまでと違う責任感まあまあ胃が痛い 35

Slide 36

Slide 36 text

そして(自分の)見積もりもあまく、追加費用分を提案胃が痛い 36

Slide 37

Slide 37 text

他にも色々やった ● 契約書の文章考えたり ● インシデント発生時のエスカレーションフロー考えたり ● ニュースリリース出したり ● 他社のソフトウェア製品を調達したり ● OSSライセンスたくさん調べたり ● R&Dの組織とも連携して未来を見据えた技術検証を進めたり 37

Slide 38

Slide 38 text

引き合いは結構きた ● 提案しに行ったり ● お試しの無償PoCをやったり ● 数カ月の有償PoCをやったり 38

Slide 39

Slide 39 text

でも本導入には至らなかった ● いわゆるPoC貧乏 ● 機械学習になると100点を求められる現象 ● 顧客側の導入決定のプロセスや体制が見えていなかった 39

Slide 40

Slide 40 text

最後、資産滅却した 40

Slide 41

Slide 41 text

最後はさすがに結構思うところがあった 41

Slide 42

Slide 42 text

悔しい 42

Slide 43

Slide 43 text

ユーザーだけを見ていた ● 相手も大企業であることが多かった ● 顧客（意思決定者・予算決定者）が見えてなかった ● プロジェクトの責任者がどのように稟議を通しているかが見えていなかった 43

Slide 44

Slide 44 text

失敗するにしても ● Fail Fast ● もっとアジャイルなプロセスにもチャレンジすべきだった 44

Slide 45

Slide 45 text

価値を届けるためのプロセスも大切 45

Slide 46

Slide 46 text

他にも色んな経験をさせてもらった ● 特許書いたり ● PjMなど、まったくコードを書かない期間 ● 外部委託の発注書を書いたり ● 障害報告書を書いたり ● データサイエンティストとして工場にマイクを設置しに行って、工場の録音データを聞きまくる期間 ● 週に1日だけのはずの愛知県出張、いつのまにか週4日で行くことになったり ● 一人で顧客先のデータセンターに籠もったり ● プロジェクトを複数兼務する辛さを味わったり 46

Slide 47

Slide 47 text

結果的に器用貧乏に ● 技術的な深さを諦めてたわけではない ● 一人で全部やってきたわけでもない ● 最初はきっかけをもらって、その後は自分で選んで、人を巻き込みながら前に進み続けた結果が「器用貧乏」 47

Slide 48

Slide 48 text

色んなことに飛び込んだ結果肩書き（名刺の表現）経験したロールや職種(体制図などの表現) ● エンジニア ● ソフトウェアエンジニア ● アプリケーションエンジニア ● アプリケーション基盤エンジニア ● バックエンドエンジニア ● プラットフォームエンジニア ● ソリューションアーキテクト ● IoTエンジニア ● プロジェクトリーダー ● プロジェクトマネージャー ● MLエンジニア ● UXエンジニア ● アーキテクト ● テックリード ● データサイエンティスト ● データアーキテクト ● データエンジニア ● アカウントエンジニア ● テクニカルエンジニア ※うろ覚えの名称もあります 48

Slide 49

Slide 49 text

Slide 50

Slide 50 text

(与えられた) ロールなんてなんでもいい 50

Slide 51

Slide 51 text

ふりかえるとロールの範囲のちょっと先に大切なものがあった 51

Slide 52

Slide 52 text

できてないと思うこともたくさんあった 52

Slide 53

Slide 53 text

行動しないと気づかなかったものばかり 53

Slide 54

Slide 54 text

「なんでもやる」が広げたものそして現在地

Slide 55

Slide 55 text

「なんでもやる」が広げたもの ① 曖昧な状況でもとりあえずやってみる力 ② エンジニアリングの幅 ③ ロール間をつなげる力 55

Slide 56

Slide 56 text

① 曖昧な状況でもとりあえずやってみる力 ● 正解がない中でも前に進める ● 新しい技術領域でもまず触ってみる ● 「やったことない」がやらない理由にならなくなった 56

Slide 57

Slide 57 text

答えが目の前になくても不安じゃなくなった 57

Slide 58

Slide 58 text

② エンジニアリングの幅 ● 技術の幅インフラ(オンプレ、クラウド) 機械学習、データエンジニアリング IoT ミドルウェア Web ● 問題解決の手段の幅プロジェクトマネージメント人や他チームを頼る開発しないで解決する 58

Slide 59

Slide 59 text

問題が発生したときに技術以外の選択肢をとれるようになった 59

Slide 60

Slide 60 text

● 色んなロールの視点でものごとを見れるようになった ● 時代の流れとともに、ロール自体が変化しても変わらない強み ③ ロール間をつなげる力 60

Slide 61

Slide 61 text

開発を上手に進めるために必要な色んなものに気づけるようになった 61

Slide 62

Slide 62 text

カケハシでテックリードとしての現在地 ① ふわっとした初期検討から声をかけてもらえる ② ゴール設定自体をまかせてもらえる ③ EMやPdMと補強し合いながら進められている 62

Slide 63

Slide 63 text

① ふわっとした初期検討から声をかけてもらえるプロダクトややることが明確にならない中でも一緒に検討から始められる ● 曖昧な状況でも嫌がらない ● その時に必要な粒度の決定を支援できる自分自身が思っているポイント 63

Slide 64

Slide 64 text

② ゴール設定自体をまかせてもらえる「コスト削減」「信頼性向上」という曖昧な目標だけがある状況からどこまでやるか、どうやって進めるかを決められる ● 答えが確実にならない中でも決断できる ● 状況を見ながらそのゴールも変化させられる自分自身が思っているポイント 64

Slide 65

Slide 65 text

自分自身が思っているポイント ③ EMやPdMと補強し合いながら進められているこれまでの経験ではあまりなかった、組織やチームの変化に対してお互いの役割を補強しながら必要なものごとを進められている感触 ● 変化がある中で、役割にもグラデーションを持って対応できる ● チーム、プロジェクト、プロダクトの課題感に対して提案できる(もちろん得意不得意はある) 65

Slide 66

Slide 66 text

不確実なものが少しずつ確実になっていくエンジニアリングの醍醐味 66

Slide 67

Slide 67 text

マネージャーにはならないの？ 67

Slide 68

Slide 68 text

ならない！！！って今は言い続けているなんでもやるとか言いながら 68

Slide 69

Slide 69 text

たぶん好きなコードを書くことにもまだ向き合いたい気持ちがあるから 69

Slide 70

Slide 70 text

生成AI時代に考えていること

Slide 71

Slide 71 text

一番楽しいところを奪っていくのか 71

Slide 72

Slide 72 text

Slide 73

Slide 73 text

コード書くのも好きだけど価値を届けるのも好きだな 73

Slide 74

Slide 74 text

構造を作る楽しさ ● ソフトウェアを変化に強くするための構造はより重要になった ● 増えた時間で、これまで妥協していた周辺の仕組みを整えていくのが楽しい 74

Slide 75

Slide 75 text

価値を届ける力は強化された ● 探索や実験の数を増やせるようになり、質を上げることができるようになった ● やったことないことに対する最初の一歩のハードルが下がった 75

Slide 76

Slide 76 text

自分がやりたいことはまだ何も奪われていない 76

Slide 77

Slide 77 text

とにかく変化が楽しい 77

Slide 78

Slide 78 text

自分のことを「器用貧乏」だと悩んでいる人へ

Slide 79

Slide 79 text

悩みながら進めばいい 79

Slide 80

Slide 80 text

悩みながら目の前のことに向き合いながら進めばいい 80

Slide 81

Slide 81 text

悩んでいいし同時に誇っていい 81

Slide 82

Slide 82 text

大好きな言葉たいていのチャンスのドアにはノブが無い自分からは開けられないだれかが開けてくれたときに迷わず飛びこんでいけるかどうか漫画「ちはやふる」第23巻第121首より “ ” 82

Slide 83

Slide 83 text

器用貧乏は、チャンスをもらえるように行動してきた証 83

Slide 84

Slide 84 text

器用貧乏は、何度も自分からチャンスに飛びこんでいけた証 84

Slide 85

Slide 85 text

ただその言葉に甘えないでほしい「器用貧乏」を自らの制約にしてはいけない ❌ 「器用貧乏だから、深い技術を学ばなくても良い」 ❌ 「幅広くできることを目指しているから、　　技術の詳細は知らなくても良い」 85

Slide 86

Slide 86 text

僕も今でもチャレンジを続けているこれも言い続けているやったことないのでやってみたいです！当時よりはやりたいことが明確になってきた声に出して誰かに伝えまくると、意外と叶う 86

Slide 87

Slide 87 text

僕も今でもチャレンジを続けているこれまでの経験であまりやれてなかった登壇 87

Slide 88

Slide 88 text

今日の話がみなさんのキャリアを改めて考えるきっかけになれば嬉しいです 88

Slide 89

Slide 89 text

ありがとうございましたカケハシの技術に関連する情報を発信しています！ 𝕏 @kakehashi_dev 是非フォローもお願いします！ 89