富田真光 (Tomita Masamitsu) | 神戸のソフトウェアエンジニア

シドニーひとり旅の記事をnoteに書きました

Tue, 22 Sep 2026 00:00:00 GMT

シドニーのフラットホワイトは最強

ぜひ日本でもフラットホワイトを飲みたい！

note の記事はこちら

シドニーひとり旅に行ってきました

『システム開発と「具体と抽象」』を読んで、要件定義の見方が変わった話

Tue, 18 Aug 2026 00:00:00 GMT

いま入っている案件で、基幹システムの要件定義と基本設計をやっている。顧客からの要望が毎週のように積み上がっていくタイミングで、細谷功さんのシステム開発と「具体と抽象」を読んだ。

これが今の自分に刺さりまくった。一番残ったのは、問題発見と問題解決では、そもそも搭載しているOSが違うということ。そして自分は、顧客の要望という「具体」を捌くことに追われて、その奥にあるWhyを問えていなかったということ。刺さったところを、自分の現場に引きつけて書いていく。

提案ができないのは構造の問題だと思っていた

この本、いきなりSI業界への耳の痛い話から始まる。決められた仕様の通りには作れるが、それ以上のことはできない（やらない）。

正直、最初は「いやいや」と思った。受託開発って決められたこと以外はむしろやっちゃいけない世界だし、言われた通りに作っていれば売上も利益も上がる契約構造なんだから、提案するインセンティブが弱いのは当たり前で。個人の能力っていうより、構造の問題じゃないの？と。

ただ読み進めると、その構造ごと問われてるのが分かってくる。AI中心の最近のDXは、業務のやり方を新しい技術に合わせて最適化するっていう逆の発想が要る。で、ITとAIの知識を持ってる人材は開発側に多いんだから、開発側から業務のやり方ごと提案していくしかない。構造のせいにして終われる話じゃなかった。

長年受け身でやってきた人にいきなり提案しろって言うのは「高校までメイク禁止だったのに、社会人になったらメイクは必須と言われるようなもの」っていう例えがあって、これが妙に刺さった。姿勢の問題じゃなくて、思考回路そのものを切り替える必要があるということ。

問題発見と問題解決では搭載しているOSが違う

この本の中心はここだと思う。川上の仕事は問題発見で、アウトプットは「問い」になる。川下の仕事は問題解決で、アウトプットは「答え」になる。問題発見は具体から抽象へ、問題解決は抽象から具体へ。問題が定義された瞬間に、ベクトルが反転する。

問題にも2種類ある。顕在的問題は顧客も認知してて、依頼として降ってくるもので、正解がある。潜在的問題は顧客自身が言語化できてなくて、仮説を立てて能動的に提案するしかない。「AIで何かやりたい」みたいなふんわりした要望は、潜在的問題を引き出す絶好のチャンスらしい。今までは「ふんわりしてて困る」としか思ってなかった。

自分に当てはめると、問題解決のOSはそれなりに動いてる気がするけど、問題発見のOSは全然スペックが足りてない。十分な情報が揃ってから動くっていう発想が染み付いてると、不十分な情報のまま仮説を膨らませることに抵抗を感じてしまう。この抵抗感がOSの違いなんだと思う。

デジタル千円札を自分も作っていた

この本で一番効いたのがこの例。お金を具体レベルでデジタル化すると、千円札がデジタル千円札に変わるだけっていう滑稽な産物が生まれる。「人々の共通の価値を交換するもの」って抽象化してからデジタル化するから、PayPayみたいなサービスが生まれる。具体から具体への置き換えは、トランスフォーメーションでも何でもないということ。

で、自分の過去を振り返ってみると、Excelをそのまま画面に置き換えるっていう同じことをやってしまった気がする。顧客が口にする要望をそのまま作るのは一見顧客志向っぽいけど、なぜやりたいのか、何を達成したいのかに踏み込まない限り、出来上がるのは個別最適の局所解にとどまる。耳が痛い。

Whyには過去向きと未来向きがあるっていう話も良かった。なぜ障害が起こったのかっていう過去向きのWhyは、エンジニアには馴染みがある。でも、それで何を達成したいのかっていう未来向きのWhyは、意識しないと問えない。要件定義で問うべきなのは後者なんですよね。

Xでレスバが起こる理由も具体と抽象で説明できる

この本では、具体をレーザーポインター、抽象を懐中電灯に例えている。具体派は狭いけど濃い世界を見ていて、抽象派は薄いけど広い世界を見ている。だから具体派からは抽象派が「薄っぺらくて何も分かってない」ように見えるし、抽象派からは具体派が「視野が狭い」ように見える。現場の人とマネージャーや経営層のすれ違いも、だいたいこの構図で説明がつく。

これを読んで思ったのが、Xでレスバが起こる構造ってまさにこれなんじゃないかということ。広く浅く60点を取りに来ている発言に対して、自分が絶対に勝てるほんの一部の狭い土俵で勝負を挑んで、勝った気になって冷笑する。でも抽象で見てる側からすれば、ほんの一部の話だから痛くも痒くもないし、仕掛けた側はそのことに気づいていない。

大事なのは、自分を具体派か抽象派かのどっちかに二極化することじゃなくて、いま自分はどっちのモードで見てるのかをメタ認知すること。これができてないと、不毛な争いに巻き込まれるだけになってしまう。

AI時代に消えるのは職種ではない

この職種は安泰だ、この職種は危ない、って議論には半分しか意味がないらしいが、確かにそう思った、そもそもXの文字数制限の中での発言なら、抽象的だったり一部を全部と捉える人もいるからなおさらだと思う。どんな仕事にも、AIに置き換わりやすいタスクと、AIで価値が高まるタスクが同居してる。消えるのは職種じゃなくて、考えてるつもりで実は与えられた具体を処理してるだけの部分らしい。この本で一番怖い一文だった。

問題解決をAIが担えるようになってきたからこそ、人間の仕事の重心は問題を見つけて定義する側に移っていく。前に AI時代だからこそ基礎力が大事だと思った話を書いたけど、基礎力が問題を「解く」力だとすると、具体と抽象は「問いを立てる」力で、両方揃ってはじめてAIに正確に委譲できるんだと思う。

目の前の要望の山を一段抽象化してみる

というわけで、まずやることは決めた。積み上がってる顧客要望のリストを一件ずつ潰す前に、一段抽象化して「結局この顧客は何を達成したいのか」を仮説として言語化してから、次の定例に持っていく。答えを聞くんじゃなくて、仮説をぶつけて、その反応から潜在的問題を探る。

言われた通りに作る力は、これからも捨てるつもりはない。それは受託の強みそのものだから。その上で、場面に応じて問題発見のOSに切り替えられるようになりたい。具体と抽象の往復を、まずは目の前の要望の山からやってみる！

AI時代だからこそ基礎力が大事だと思った話

Sun, 26 Jul 2026 00:00:00 GMT

いま入っている案件で、要件定義と基本設計をやっている。

進め方としては、ユーザーに画面のモックを見せて、それをベースに話をしながら仕様を確定させていくというもの。そのためにTypeScriptとReactでフロントエンドを書いているのだが、ここで最近強く感じたことがある。

AI時代だからこそ、結局は基礎力が何よりも大事だということ。

Codexを使うと画面が一瞬で完成してしまう

まず、実装が本当に速い。

Codexを使うと、画面が一瞬でできあがってしまう。モックデータについても、MSW（Mock Service Worker）を使えばリアルなデータをそのまま注入できる。ユーザーから見れば、ほぼ本番と変わらない画面で議論ができる状態だ。

正直、実装のスピードという意味では、もう人間が手を動かす理由はほとんどないということを心の底から実感している。

それでもDB設計は自分の頭で考えないと詰む

一方で、これはAIに丸投げできないと痛感したのがDB設計だった。

ユーザーと話していると、こんな場面がよくある。

このテーブルのスキーマ、どうなってたっけ？
ユーザーが言っているこの要望、受け入れてしまっていいのか？
受け入れたとして、全体で破綻しないか？

ここで自分が設計を理解していないと、かなりきつい。何が分かっていないのかも分からない状態になるので、AIに聞いてると遅いし、回答を待っている暇もない。もちろんやるやらないは持ち帰って検討するにしても、技術的にできるかできないかくらいは伝える必要がある。

画面は後から作り直せる。でもデータ構造の破綻は、後になるほど効いてくる。だからここだけは自分の頭で考えて、理解した状態で設計しておく必要がある。

基礎があるからこそ、AIに正確に委譲できる

基礎があるから応用ができる。そして基礎があるからこそ、自分の仕事を正確にAIに委譲できる。

AIに全部考えてもらうのではなく、自分で考えた上でAIを使う。この違いは大きくて、前者だと出てきたものが正しいかどうかを判断できないが、後者なら意図した通りに実装させて、違っていたら指摘することができる。

そもそもの順番として、業務が先でAIは後。ここは変わらないと思っている。

そして結局は、AIを使いこなす自分のレベルが低いままだと、いいアウトプットもアウトカムも出せない。委譲するには、委譲する内容を自分が分かっている必要があるし、AIが賢くなればなるほどこの前提が効いてくる。

結局は基礎力だし、自力は必要ということ。

徹底的に基礎を理解して、詳細をAIに委譲する

というわけで、いまは達人に学ぶDB設計徹底指南書を読んでいる。徹底的に基礎を理解して、詳細をAIに委譲する。どこまで行っても基礎が大事！

WordPressをやめて、AstroとCloudflareでサイトをリニューアルしました。

Mon, 20 Jul 2026 00:00:00 GMT

このサイトは、もともとWordPressのオリジナルテーマで作ったポートフォリオサイトでした。今回それをやめて、Astroで作り直しました。この記事はそのリニューアル後の1本目です。

なぜWordPressをやめたのか

理由はシンプルで、運用のシンプル化と爆速化です。

本体・プラグインの脆弱性対応に追われる
サーバーやDBの管理が必要
サイトの表示速度を上げるにも限界がある
そもそもWordPressである必要がない

個人のサイトに管理画面もDBも必要ないと気づき、静的サイトに全振りすることにしました。当初はNext.jsも検討していたのですが、軽量さと手軽さからAstroにしました。

新しい構成

フレームワーク: Astro
CSS: Tailwind CSS
ホスティング: Cloudflare
コンテンツ管理: Markdown（Gitで管理）

AstroはデフォルトでJavaScriptをほぼ配信しないフレームワークです。このサイトで動いているJSは、ダークモード切替の数行だけに厳選しました。あとはビルド時に生成された静的なHTMLとCSSだけで動いているので表示速度が爆速です。

あとは記事の管理の作成・管理をマークダウンでしたかったというのも大きいです。 CMSを別で用意することなく、VS Codeで記事を書いて、mainにマージされれば自動的に配信されるという快適さも得ることができました。

また、ホスティングにCloudflare Pagesを選んだのは、世界中のエッジサーバーから高速に配信でき、Githubと連携したCI/CDまで無料で完結するためです。今の構成でかかってくるコストはドメイン代だけになりました。

シンプルにプロダクトとしてCloudflareが好きだからというのもあります。

こだわったところ

とにかく速く

Webフォントを使わず、OS標準フォントで表示
画像はビルド時に最適化
静的ファイルをCloudflareのエッジから配信

これからのこと

このブログでは、技術のこと・作ったもの・気になっていること・日々の活動について書いていく予定です。よろしくお願いします。