![](./spec_version_control_cover.png) 

## はじめに：よくある状況 

ソフトウェア会社で働いたことがあるなら、こんなファイル名を見たことがあるでしょう： 
`spec_v2.1_20250905_hotfix.docx` 

しかし、これは一体何を指すのでしょうか？ 
1. 本番環境のバージョン？ 
2. 開発中のバージョン？ 
3. 議論中のドラフト？ 

答えはどれでもあり得ますし、メンバーごとに解釈がバラバラなこともあります。 

## なぜバージョンの意味付けが重要なのか 

各状態の仕様書は、それぞれ重要な役割を持っています： 

- **本番バージョン**：カスタマーサポートや QA、顧客自身が現在のシステムの仕様を理解するため 
- **開発中バージョン**：開発チームが作業内容を正しく揃えるため 
- **検討中バージョン**：将来の方向性を共有し、関係者が計画や議論に参加するため 

さらに、本番バージョンにホットフィックスが入り、仕様に影響を与える場合は、さらに複雑になります。明確なバージョン管理ルールがなければ、ドキュメントはすぐに錯綜します。 
 
多くのチームは**あえてバージョン管理をしない**という選択をします。その結果： 
PM はそれぞれ独自の方法で管理し、色付け、コピー、上書きが混在します。メンバーは慣れたファイルだけを参照し、他のファイルは無視されます。最終的に、**全員が別々の下書きを見ながら作業している状態**となり、矛盾を会話でつなぎ合わせるしかなくなります。このリスクはプロジェクト後半で爆発します。 

### 🎯 実際の事例 

日本の顧客と台湾の開発チームを巻き込んだ大規模プロジェクトを担当したときのことです。 

厳密なドキュメント管理がなかったため、バージョンがバラバラで、翻訳のタイムラグと時差が重なり深刻な問題が発生しました： 

- 顧客はどれが正しい仕様なのか分からず、常に「この機能は今回入るのか？」と確認してきた 
- QA が「仕様と違う」と頻繁にバグ票を切るが、多くはそもそも今回のリリース対象外だった 
- 最悪のケースでは、顧客がまだ承認していない機能が誤って本番リリースされた 

この事故で顧客は 3 日間かけて再テストを行い、開発チームは 2 週間の残業でロールバックと修正に追われ、プロジェクトが遅延し信頼関係も損なわれました。 
 
原因は明確です：**単一の正しいドキュメントがなく、状態ラベルもなく、バージョン同期もできていなかった**。 

## なぜ問題に気づきにくいのか 

1. **ドキュメントの間違いは即座に壊れない** 
コードは壊れればコンパイルエラーで即発覚しますが、ドキュメントの間違いはテストやリリース段階でようやく発覚します。 

2. **会議やチャットで補完してしまう** 
短期的には口頭での同期で何とかなり、問題が表面化しません。しかしその分、見えないコミュニケーションコストが積み重なります。 

3. **責任が分散している** 
PM、デザイン、開発、QA が関与するため、誰もが責任を持ちつつ、誰も品質を担保しない状態になります。 

## コードの世界から学ぶ 

本質的には： 

- **コード = 機械のための仕様書** 
- **ドキュメント = 人間のための仕様書** 

コードには Git があります。ドキュメントにも同じ仕組みが必要ではないでしょうか？ 

## 解決策：ドキュメントにもバージョン管理を導入する 

### 1. 単一の「正」ドキュメントを定義する 
- 常に一つのメインドキュメント（Single Source of Truth）を用意する 
- このドキュメントは本番状態のみを保持し、ドラフトや提案は別の場所に置く 
- 関係者全員が「仕様はここを見る」と認識できる状態を作る 

### 2. 「マーク」か「別ファイル」かを決める 
- **同じファイルにマーク**（小規模、短期変更）：コメントやハイライトで「In Progress」「Draft」を明示 
- **別ファイルを作る**（大規模、長期変更）：`Spec_vNext` のように新しいファイルを作り、確定後にメインに統合 

### 3. ツール別のルール 
- **Google Docs / Word**：メインは `Spec_main`、ドラフトや提案はサフィックスを付ける 
- **Figma**：本番状態をメインページに保持、ドラフトは別ページ、決定後にマージして削除 
- **Notion / Confluence**：階層構造で管理し、ステータス欄で Live/In Progress/Draft を明示 

## 導入戦略：ルールを定着させる 

1. **まず痛点を集める** 
PM、開発、QA、デザイナーにヒアリングして実際の混乱事例を集め、チームに共有することで危機感を醸成。 

2. **チームと共にルールを設計** 
痛点を出発点に議論し、現場に合ったルールを共同で作る。 

3. **小さく始める** 
まず一つのプロダクトラインでパイロット導入し、効果を計測してから全社展開。 

4. **責任者を設定する** 
ドキュメントのオーナーを指名し、リリース前に更新を確認するチェックを追加。 

5. **継続的に改善** 
チーム規模やプロセスの変化に合わせてルールをアップデート。 

6. **成果を見える化** 
QA チケットの減少や会議時間の削減など、定量的な効果を全体に共有しモチベーションを高める。 

## 結び：アクションの呼びかけ 

ドキュメントの錯綜は単なる面倒事ではなく、大規模プロジェクトで最も高価な技術的負債の一つです。 

### 💡 今すぐできる 3 つのアクション 
1. **単一のメインドキュメントを決める**：全員がどこを見れば最新仕様かわかるようにする 
2. **マークルールを定義する**：どの変更が同一ページで済むか、どの変更が別ファイルになるかを決める 
3. **バージョン状態をラベル付けする**：最低限 Live / In Progress / Draft を明記 

👉 **「コードには Git がある、なぜ仕様書にはない？」** 
👉 **「ドキュメント管理は単なる事務作業ではなく、プロジェクト成功の基盤である。」**

final_v3_last_fixed.docx の裏側：大規模プロジェクトにおけるドキュメント管理という隠れた技術的負債

![](./ai_freelance_cover.png)

# AI時代の仕事再編：消失から再構築へ

ソフトウェア業界でPM兼エンジニアとして働く中で、AIツールが日々のワークフローをどう変えるかを観察しています。ニュースで取り上げられる大規模レイオフだけでなく、より静かな「再編」が進んでおり、仕事の形そのものが変わりつつあります。

## 見えない縮小

同じデスクに座っていても、周囲の同僚が一人、また一人と消えていく。退職者の補充はなく、業務が簡略化され、10人必要だったタスクが3人で回せるようになり、残りの役割は静かに消滅していきます。
 
 
実際、AIにより知識労働の時間は半分以下になることもありますが、需要側がその分拡大するわけではありません。余剰人員は自然に削られていくのです。
 
 
北米テック企業の相次ぐレイオフはその象徴です。Meta、Google、Amazonは2023〜2025年に繰り返し人員削減を行いました。AIによる効率化だけでなく、パンデミック期の過剰採用、景気後退、株主からの圧力などが背景にあります。他業界も同様で、Intelの大規模レイオフは組織的圧力の表れです。

## 中間層の役割消失

効率化と需要停滞のはざまで、最も圧縮されるのは仕事の「中間層」です。

- ウェブサイト制作が1週間から半日に短縮しても、顧客の需要が14倍に増えるわけではない。 
- マーケット分析が3人で1か月から1人で1週間に短縮しても、企業が10倍のレポートを求めるわけではない。 
- AI教材作成により1人でカリキュラムからクイズまで作れるようになっても、学校が3倍のコースを必要とするわけではない。 

その結果、これまで初稿作成者、編集者、デザイナー、テスターなど複数の役割が必要だったプロセスが、今では AI ツールを活用した 1～2 人で完結することも多くなり、中間的な役割は徐々に存在感を失いつつあります。私自身のソフトウェア業界での経験でも、以前はプロジェクトを進めるためにデザイナー、エンジニア、PM と最低 3 名の協力が必要でした。ところが現在では、もし POC を作る程度であれば、1 人が AI を使うだけで基本的なニーズをほぼ満たすことができてしまいます。

## フリーランスの過密とスキル要求

多くの人がフリーランス、副業、コンテンツ制作へ移行します。しかし **MBO Partners 2024年レポート** によれば、アメリカでは7,270万人が独立して働いており、市場はかつてないほど過密です。収入の安定性や保障は低下しています。
 
 
フリーランスはもはや「スキルがあればいい」という時代ではありません。営業、顧客獲得、プロジェクト管理、契約交渉、資金計画まで自分でこなす必要があります。多くのエンジニアやデザイナーにとって、これは高いハードルです。さらにプラットフォーム手数料やアルゴリズムの偏りが不均衡を悪化させています。需要が十分に拡大していないため、旧来型のフリーランスモデルは持続困難になっています。

## 一つの方向性：モジュール型協働

このような背景のもと、今後のフリーランスは、より構造的な **「モジュール型コラボレーション」** へと進化していく可能性があります。
 
 
その核心は、報酬体系を「工数ベース」から「価値と成果ベース」に転換することです。従来のプロジェクト報酬は、想定される作業時間に依存しており、時間が短縮されれば収入も減ってしまいました。しかし、モジュール型コラボレーションでは、プロが提供するのは「時間」ではなく、明確に定義された高付加価値の **成果モジュール** です。
 
 
たとえば、ウェブサイト制作の真の価値は、かけた時間ではなく、クライアントにどれだけの効果をもたらすかにあります。熟練の専門家が AI ツールを活用し、従来は 1 週間かかった **UI/UX 最適化モジュール** を半日で完成させたとしても、その報酬が減額されるべきではありません。むしろ効率が高まったことで、クライアントに早く成果を届けられる点で、価値はむしろ上がります。
 
 
これは一流の外科医が手術料を「手術室で過ごした時間」ではなく、「難易度の高い手術を成功させた成果」に基づいて設定するのと同じです。外科医は「手術モジュール」といえる高技術領域に集中し、術前評価や術後ケアは他の専門家に任せます。これにより、自らの核心的価値を最大化し、より短期間で多くのケースを担当できます。

### ソフトウェア開発の例

従来 5 人で 1 ヶ月必要だったプロジェクトも、モジュール型コラボレーションでは以下のように分解できます：

1. **要件分析モジュール**：AIがユーザーインタビューを要約し、ニーズと課題を抽出。 
2. **システム設計モジュール**：AIがアーキテクチャ図やデプロイスクリプトを生成。 
3. **開発モジュール**：AIがコードを生成・最適化し、人間が重要部分をレビュー。 
4. **UI/UXモジュール**：AIがデザイン案を作成し、A/Bテストを実施。 
5. **テスト・QAモジュール**：AIがテストケースを生成・実行し、不具合報告をまとめる。 
6. **コーディネーター**：進捗を管理し、週次チェックを行い、成果を統合。 

このような分業と効率化によって、各専門家はより高単価でモジュールを提供しつつ、同じ時間で複数のプロジェクトを完了できます。最終的に、報酬は労働時間ではなく、専門性と成果価値に直結することになります。

## 解決すべき課題

しかしモジュール型にも課題があります：

1. **市場規模**：需要が拡大しなければ、 pie を細切れにしているだけではないか。 
2. **価値配分**：難易度や貢献度に応じた公正な価格設定が必要。 
3. **調整コスト**：モジュール間の調整は誰が担うのか。コーディネーターの役割は不可欠。 
4. **品質一貫性**：分業化が進むほど、品質やスタイルの不一致リスクが増す。標準化とレビューが重要。 
5. **信頼と評価**：透明な評価・実績共有が、スケール化の鍵となる。 

## 今後の模索

AIは従来の役割を曖昧にし、再定義しています。フリーランスとして働き続ける人もいれば、モジュール型に移行する人、新しいモデルを作り出す人も出てくるでしょう。オープンに試しながら、公正かつ効率的な価値創出の形を探る必要があります。

---

## 参考文献

- [MBO Partners State of Independence Report 2024](https://www.mbopartners.com/state-of-independence/) 
- [Tech Layoffs Tracker by layoffs.fyi](https://layoffs.fyi/)

AI時代の仕事再編：消失から再構築へ

![](./rethinking-meeting-notes-cover.png)

---

### デフォルトになっている議事録の書き手

多くの職場でよくある光景：

 

「会議のたびに、議事録は結局PMが書く。」

 

明確な決まりがあるわけでもない。会議が本当にPMの意思決定責任と関係あるかどうかも関係なく、誰も指定しなければ、なぜかその役割が自然と誰かにのしかかる。そして、その「誰か」とは、たいていPMか、チーム内で一番若手、または「文句を言わなさそう」なメンバーだったりする。

 

文化によっては事情が異なる場合もある。たとえば、日韓の企業では、議事録は秘書や事務職が担うことが多い。彼らが「業務支援役」として制度的に位置付けられているからだ。

 

でも、多くの人にとってこれは「大したことない」こととして片付けられている。

---

### 背後にある職場の分担ロジック

でも、この現象の奥には、ある種のロジックが潜んでいる：

- 議事録は「本業」じゃない → 多くのリソースを割く必要はない
- 時給が安い人・肩書きが軽い人・文句を言わなそうな人がやるべき
- 誰かがやらなきゃいけないなら、抵抗の少ない人がやるのが自然

一見、合理的なように見える。

 

でも実際には、議事録だけでなく、会議室の予約、昼食の手配、資料の印刷など「誰かがやらなきゃいけない仕事」すべてが、その“議事録係”に集まってくる傾向がある。

 

これは「仕事ができる・できない」や「リーダーシップの有無」以前に、役割分担の初期設計や文化によるものだ。

 

そして、こういう文化で、本当に「当事者意識のある人」を育てられるだろうか？

---

### なぜ議事録が必要なのか、改めて考える

ここで立ち返りたい。

 

そもそも、なぜ私たちは議事録を残すのだろう？

 

よくある理由としては：

- 参加できなかった人に内容を共有するため
- アクションアイテムの進捗を追跡するため
- 数週間・数ヶ月後に背景を振り返るため

もしこれらの目的が本質だとすれば——

 

その情報の精度はかなり高くなければいけない。

 

つまり、議事録とは「文字を打つ」ことではなく、「翻訳し、理解し、共通認識を構築する」ことに他ならない。

 

そう考えたとき、「このトピックを一番理解していない人」にその作業を任せるのは、本当に正しい選択なのだろうか？ それとも、「どうせ読まれないなら、最初から作らない方がマシ」なのだろうか？

---

### 議事録は「誰が書くか」より「誰が設計するか」

議事録とは、会議の背景や議論の文脈を最も理解し、その後の価値を見据えられる人がリードして、内容や形式を設計すべきだ。

- 技術ディスカッションなら技術担当がリードすべき 
 例：PulumiとTerraformの使い分けを議論する会議で、新卒の非エンジニア系PMが議論の細部を記録するのは、少々酷ではないか？
- デザインミーティングならデザイナーがまとめ役になるべき 
 例：赤色の意味やビジュアル言語の話をしているのに、デザイン文脈に疎いエンジニアPMが「なんか赤の方が良さそう」とだけ記録するのでは意味がない
- 複数部門の連携やプロダクト方針に関わる議題なら、PMが担当するのが妥当だ 
 なぜなら、PMは各部門の役割・方向性がズレていないかを確認し、全体の認識を合わせる責任があるから

---

### 「でも、その人たちが書きたくないと言ったら？」

これはよくある現実。

 

情報量の多いキーパーソンほど忙しく、記録を書く時間も意欲もない。会議中にメモを取っていたら、集中して話を聞けないことすらある。

 

でも、それこそがテクノロジーとAIの出番だ。

- Google Docのようなクラウド共著ツールを使えば、話していない人がその場で追記したり、会議前に要点を事前記入することで、リアルタイムで負担を分散できる。
- 生成系AIツール（例：Otter.aiやFireflies.ai）を使えば、録音から自動で文字起こし・要約を生成し、あとから修正・確認することができる。

ただし注意点として、「AIによる要約」だけで十分かというと、そうではない。

 

議事録は「合意形成」や「暗黙の期待値」を含むコミュニケーションの一部であり、責任や文脈を正しく伝えるには、やはり人の判断が不可欠だ。

---

### 「誰がやるか」より「どうやるか」にフォーカスしよう

PMが全ての議事録を書くことに疑問を持つ必要はない。 
ローテーション制にしてもいいし、インターンや事務サポートに委ねてもいい。

 

でも、重要なのは：

 

**私たちが「どうやってやるか」を決めることが、組織文化そのものを作る**ということ。

 

役職や時給だけで分担するのではなく、以下のような観点をもとに柔軟に設計すべきだ：

- 関心度・当事者意識
- 理解度・背景知識
- 技術的／AI的な補助の有無

---

### ✅ 実践的な改善案（例）

- **「議題オーナー」制度の導入**：議題ごとに主担当を明確にし、その人が内容をレビュー・補足する体制をつくる 
- **AI＋人のハイブリッド運用**：AIによる録音・下書き後、人が要点を整える 
- **文化のアップデート**：「議事録＝雑務」ではなく「共通理解を残す行為」であるという共通認識を醸成する

---

### 最後に

議事録とは、**「私たちが何を記録に残したいか」という集団の意思表明**だ。

 

その出発点を、もっと柔軟に、そして誠実に選び直してもいいのではないだろうか。

会議録はいつもPM？分担ロジックを見直すときかもしれない

![](./pm-background-cover.png)

# PMはどれくらい技術を理解すべきか？エンジニアからデザイナーへ──異なるバックグラウンドを持つPMの突破方法

ソフトウェアエンジニア出身でPMに転職した私が、異なる背景を持つPMメンバーと仕事して気づいたことがあります：**「PMはどれくらい技術を理解すべきか？」とよく聞かれますが、**ほとんどの人は**「自分のバックグラウンドでPMに向いているか？」を聞きません。**

 

技術の深さを追求するよりも、次の問いを考えた方が有意義ではありませんか？ 
**デザイナー、QA、営業など異なるバックグラウンドの人は、それぞれどんな強みを持ち、どんな注意点があるのか？**

 

その前に、まずは PM の役割を簡単に定義しておきましょう。

---

## PM の主流2タイプ：プロダクトとプロジェクト

一般的に PM と言っても次の2タイプがあります：

### Product Manager（プロダクトマネージャー）

- プロダクトの方向性やビジョン、目標を担当
- 要件定義、仕様設計、受け入れ基準の作成
- KPI はプロダクトの市場パフォーマンス（ユーザー維持率、転換率、収益など）

### Project Manager（プロジェクトマネージャー）

- プロジェクトを期日通りに納める
- 部門間の調整、情報共有、進捗管理
- リスク予測、リソース配分、スケジュール管理

多くの企業では明確に分けていませんが、この分類があると「どのバックグラウンドに向いているか」を考えるのに役立ちます。この記事ではまず Product Manager に焦点を当てます。

---

## 異なるバックグラウンド別：Product Manager の強みと注意点

誰でも自分の得意分野を持っており、PMへの転職では特定分野での調整が必要です。以下は成長過程でよくある「注意点」です。理解しておけば、スムーズに成長できます。

### エンジニア出身の PM

**強み**：

- 技術アーキテクチャを素早く理解し、開発工数を見積りやすい
- エンジニアチームと深く解決策を話し合える
- APIやB2Bツールのプロダクト開発では、自身がユーザーとなるケースもあり強みとなる

**注意点**：

- 技術に集中しすぎて、市場やユーザーの声を見落とすことがある
- 完璧な構造を追い求めすぎ、検証→改善のサイクルが遅れる場合がある

 

→ 最初は「市場を検証する MVP を作り、運用しながら拡張する」姿勢を持つと、効率と品質のバランスを取れます

 

例：エンジニア出身のPMが、高度なマイクロサービス構成を設計。しかしまずはシンプルな構成で市場検証を行い、後で拡張する戦略が最終的には効果的だったというケース。

### デザイナー出身の PM

**強み**：

- ユーザー視点で体験とフロー設計を重視できる
- UI/UX に対する直感が強く、プロダクトが人に優しくなる

**注意点**：

- 実装コストを把握していないと、細部にリソースを割きすぎることがある
- 技術面で制約が出たときに、調整ではなく妥協する傾向がある

 

→ エンジニアとの対話を頻繁に行い、技術の制限と柔軟性をお互い納得しながら進められるとバランスが良くなります

 

例：オンボーディングのアニメーションにこだわりすぎ、全体の転換率にはほとんど影響しなかったケース。「美しさ」と「効果性」は別問題という学びの場面でした。

### QA出身の PM

**強み**：

- シナリオや境界条件を考えるのが得意で、エッジケースを逃さない
- 品質基準の意識が強く、受け入れ基準の整備に有利

**注意点**：

- 全てのケースを書き出しすぎて仕様が膨大になり、チームの焦点が散る
- 冗長なケースを優先しすぎると、プロダクト全体が鈍化する可能性がある

 

→ 重要なユーザーストーリーを中心に、優先順位をつけて整理すれば、よりわかりやすくなります

 

例：詳細な50ページの要件ドキュメントでは読み手が混乱しがちだったが、「ユーザーストーリー＋補助要件」にしたことで開発がスムーズに進んだというケース。

### 営業出身の PM

**強み**：

- 顧客ニーズや市場反応に敏感で、営業目線でプロダクト設計に貢献できる
- 社内や顧客との調整や交渉が得意で、販売につながるプロダクトの理解に強い

**注意点**：

- 個別顧客のニーズを一般化しすぎると、機能過多や技術負債を引き起こす可能性がある
- プロダクト全体の整合性や運用負荷に注意が向かない場合がある

 

→「他のお客様にも必要な機能か？」と確認し、設計や技術と一緒に共通パターンを検討することで、長期的な価値が得られます

 

例：特定顧客向けに機能を追加したが、同じニーズは少数で保守が重荷になったという状況も。

---

## PM の本質：本当の T 型人材になろう

これらのバックグラウンド別比較からわかるように、プロダクトマネージャーは以下をバランスよく見る必要があります：

- 技術アーキテクチャの実現性
- ユーザー体験と仕様設計
- 顧客ニーズとビジネス価値
- 市場投入とプロモーション戦略

ひとりで全てを極めるのは難しい。だからこそ、**チームでお互いの強みを補い合う T 型チームが理想**です。

そして、どんなに専門性が高くても、他分野への理解があるのが本当の強み。 
これは、PMが「製品のCEO」と言われながらも、実際には明確な権限を持たない存在である理由です。 
影響力は「専門性」で築き、その先は「協働力」で広げていくのが PM の鍵です。

---

## 習慣にしよう：学び続け、柔軟であれ

つまり、どの背景でも優秀な PMになれます。ただし、自分の専門に加えて**学び続ける姿勢**が欠かせません。 
「ただ主張するPM」ではなく、「学び、協働し、進化し続けるPM」になるために、次のアクションを取ってみてください：

- **他の役割を経験してみる** 
- **未知の分野の本や技術記事を読む** 
- **異なる背景の同僚に質問し、視点を広げる**

一歩を踏み出せば、新しい視点が見えてきます。製品の全体像を俯瞰し、複数の視点をつなぎ合わせられるPMに、あなたも近づくでしょう。

---

## 自己診断チェック：あなたはProduct Managerに向いているか？

1. **今、最も得意とする分野は何ですか？** 
2. **未知の領域を学び、異なる背景の仲間と協働できますか？** 
3. **情報が不完全で曖昧でも、決断を下せますか？** 
4. **失敗や間違いをしたとき、自ら責任を取ろうとしますか？** 
5. **学びを継続することに喜びを感じますか？**

上記の問いに、多くの場合「はい」「挑戦できる」と答えられるなら、あなたは立派なPM候補です。

---

## 結び：PMは自分自身の人生のようなもの

「プロダクトマネージャーはプロダクトのCEO」という言葉がありますが、私にとっては、**PMはまるで“自分の人生を切り開いていく”存在そのもの**というイメージです。

 

あなたには、あるビジョンやリソースがあり、限られた時間の中で価値あるプロダクトを生み出す使命があります。 
でも、誰も最初から教えてくれません。マニュアルもありません。 

 

あなたが選ぶ道、取る責任、そして決断がすべて。その重みと自由こそが、この仕事の醍醐味です。

 

全てを知る必要はありません。 
しかし、選択に責任を持ち、学び、柔軟に再出発する覚悟があれば、 
—あなたはすでにその道を進み始めています—

 

次回は Project Manager に求められる適性と背景について書いていきます。とくにQAやエンジニア出身の方向けの内容を予定していますので、どうぞお楽しみに。

PMに技術力は必要？エンジニア・デザイナー・QA・営業出身者それぞれの強みと注意点

![](./vibe_coding_part2_cover.png)

前回の記事では、Vibe Codingの概念と流れを紹介しました。 
しかし実際に操作してみると、さまざまな問題に直面します。
 
 

今回は、実際の事例を使って解説します。 
妻は中国語の先生で、生徒向けに「漢字とピンインのマッチングゲーム」を作成しました。音声読み上げやスコア表示も含まれ、インタラクティブ性を高めています。
 
 

この記事では、「起動」「デバッグ」「理解」の3つのシーンに分けて、ChatGPTへの質問内容、返答、そしてPromptをどう調整したかを具体的に紹介します。
 
 

🔗 完成作品：[https://afangchinese.github.io/wordmatch/](https://afangchinese.github.io/wordmatch/?data=JTdCJTIyZGF0YSUyMiUzQSUyMiVFNCVCOCU4MCVFNSU4MCU4QiUyQyVFMyU4NCVBNyVDQiU4QSUyMCVFMyU4NCU4RCVFMyU4NCU5QyVDQiU5OSUyMCUyMCU1Q24lRTUlODUlQTklRTUlODAlOEIlMkMlRTMlODQlOEMlRTMlODQlQTclRTMlODQlQTQlQ0IlODclMjAlRTMlODQlOEQlRTMlODQlOUMlQ0IlOTklMjAlMjAlNUNuJUU0JUI4JTg5JUU1JTgwJThCJTJDJUUzJTg0JTk5JUUzJTg0JUEyJTIwJUUzJTg0JThEJUUzJTg0JTlDJUNCJTk5JTIwJTIwJTVDbiVFNSU5QiU5QiVFNSU4MCU4QiUyQyVFMyU4NCU5OSVDQiU4QiUyMCVFMyU4NCU4RCVFMyU4NCU5QyVDQiU5OSUyMCUyMCU1Q24lRTQlQkElOTQlRTUlODAlOEIlMkMlRTMlODQlQTglQ0IlODclMjAlRTMlODQlOEQlRTMlODQlOUMlQ0IlOTklMjAlMjAlNUNuJUU4JUE1JUJGJUU3JTkzJTlDJTJDJUUzJTg0JTkyJUUzJTg0JUE3JTIwJUUzJTg0JThEJUUzJTg0JUE4JUUzJTg0JTlBJTIwJTIwJTVDbiVFOCU5OCU4QiVFNiU5RSU5QyUyQyVFMyU4NCU4NiVFMyU4NCVBNyVFMyU4NCVBNSVDQiU4QSUyMCVFMyU4NCU4RCVFMyU4NCVBOCVFMyU4NCU5QiVDQiU4NyUyMCUyMCU1Q24lRTklQjMlQjMlRTYlQTIlQTglMkMlRTMlODQlODglRTMlODQlQTUlQ0IlOEIlMjAlRTMlODQlOEMlRTMlODQlQTclQ0IlOEElMjAlMjAlNUNuJUU2JUExJTgzJUU1JUFEJTkwJTJDJUUzJTg0JThBJUUzJTg0JUEwJUNCJThBJTIwJUUzJTg0JTk3JUNCJTk5JTIwJTIwJTVDbiVFNiVBMiVBOCVFNSVBRCU5MCUyQyVFMyU4NCU4QyVFMyU4NCVBNyVDQiU4QSUyMCVFMyU4NCU5NyVDQiU5OSUyMCUyMCU1Q24lRTYlOTclQTklRTQlQjglOEElMkMlRTMlODQlOTclRTMlODQlQTAlQ0IlODclMjAlRTMlODQlOTUlRTMlODQlQTQlQ0IlOEIlMjAlMjAlNUNuJUU0JUI4JUFEJUU1JThEJTg4JTJDJUUzJTg0JTkzJUUzJTg0JUE4JUUzJTg0JUE1JTIwJUUzJTg0JUE4JUNCJTg3JTIwJTIwJTVDbiVFNiU5OSU5QSVFNCVCOCU4QSUyQyVFMyU4NCVBOCVFMyU4NCVBMiVDQiU4NyUyMCVFMyU4NCU5NSVFMyU4NCVBNCVDQiU4QiUyMCUyMCU1Q24lMjIlMkMlMjJsYW5nJTIyJTNBJTIyemgtSGFudCUyMiUyQyUyMnZvaWNlJTIyJTNBJTIyMCUyMiUyQyUyMnNvdW5kJTIyJTNBdHJ1ZSU3RA==)

＊ Vibe Codingの使える範囲や注意点については、前回の記事を参照ください： 
[Vibe Codingとは？誰に向いていて、何ができる？](https://www.louisan.dev/ja/blog/vibe-coding-getting-started)

---

## シーン①：起動編「ゲームを作りたいけど、どう始めればいい？」

初心者が最もつまずくポイントは、「どこから聞けばいいのか分からない」ことです。

妻が最初に入力したPromptは次の通りです：

> ピンインマッチングゲームを作りたいです。HTMLとJSを使ってシンプルなウェブページを作ってください。ユーザーが「漢字 ピンイン」を複数行入力して、「スタート」を押すとカードが表示される機能をつけてください。

ChatGPTの返答は以下の機能を備えた動作デモでした：

- 漢字とピンインのペアを複数入力可能
- スタートボタンでカード表示
- 漢字カードをクリックすると音声が再生（SpeechSynthesis API使用）
- 正解するとカードが消える

**📝ポイント：**

- 自分のスキルレベル、使いたい技術、利用環境などを伝えると、AIの回答がより的確に
- 最初の出力が完璧でなくてもOK。何度かやり取りしながら調整しましょう
- HTML、JS、サーバー、localStorage、ReactJSといったキーワードが分からなくても大丈夫。以下の補足をPromptに加えると安心です：

> プログラミング経験はまったくありません。ウェブブラウザで直接動かしたいです。サーバーやReactなどのフレームワークは使わず、HTMLと純粋なJSで作ってください。データ保存が必要な場合はlocalStorageを使ってください。

また、私が調整したPromptは以下のようになります：

> 漢字とピンインのマッチングゲームを作りたいです。入力欄で複数の「漢字 ピンイン」ペアを入力でき、前回の内容も保存されていて、ページをリロードしても消えないようにしてください。「スタート」ボタンで入力内容を使ってカードが表示され、生徒がマッチングするゲームが始まります。正解すればカードが消え、間違えた場合はそのペアが再度表示されます。全問正解で終了し、正解数・不正解数を表示してください。プログラミング経験はありません。サーバーやReactは使わず、HTMLとJSのみで、保存にはlocalStorageを使ってください。

---

## シーン②：デバッグ編「機能が壊れた！どうする？」

この段階は誰でも通ります。以下に実際に出た問題とPromptによる修正例をまとめました：

### 1. 正解後にカードの数が減ってしまう

> 正解した後、未マッチの単語からカードを補充して常に4組表示されるようにしてください。

### 2. 不正解時に赤くならない

> 不正解のときは、2枚のカードを赤くして、少し待ってからリセットしてください。

### 3. ピンインカードも音声が出る

> 中国語の漢字カードだけ音声が出るように修正してください。

**📝ポイント：**

画面が真っ白になったり、特定の機能が動かなくなったときは、以下のPromptを試してみてください：

> コードを貼り付けた後、画面が何も表示されません。ブラウザの開発者ツールを開いて、エラーを調べる手順を教えてください。

---

## シーン③：理解編「このコード、どういう意味？」

AIが提示したコードが何をしているのか分からない、あるいは期待する動作にならないこともあります。そんな時は逐行で説明を求めましょう：

> さっきの`speechSynthesis`って何？なぜ必要なんですか？

> `element.classList.add("error")`って何のため？ちゃんと動いていないけど、1行ずつ説明してもらえますか？

ChatGPTは以下のように丁寧に解説してくれます：

- コード全体の目的
- 各行の意味
- 書き換えの可否や代替案

---

## より良くするための補助ツール

### (A) ChatGPT + ブラウザだけでも十分！

- `.html`ファイルにコードを書いてブラウザで開くだけ
- 開発環境の構築は不要

**⚠️制限：**

- 自分のパソコンでしか動かない 
　→ 後述の(D) GitHub Pagesで公開可 
- コードが複雑になるとAIが壊してしまう可能性あり 
　→ (B) Cursorで一部だけ修正可能、変更点も分かりやすい 
　→ (C) GitHubでバージョン管理、壊れても元に戻せる

---

### (B) Cursor（AIコーディングエディタ）

- コーディングとAIチャットが一体化
- どこを修正したかが一目瞭然
- ファイル分割も可能で管理しやすい

**制限：**

- 有料（無料トライアルあり）
- 安定性を保つには(C)のGitHubと併用推奨

---

### (C) GitHub（バージョン管理）※やや上級者向け

GitHubはエンジニア向けのコード保管・共有ツールです。学習コストはありますが、慣れると非常に便利です。

**始めたい場合は以下のステップで：**

1. GitHubアカウントを作成 
2. 新しいリポジトリを作成 
3. 認証を設定 
4. 自分のパソコンのフォルダをGitHubに接続

以下のPromptでChatGPTに一緒に進めてもらえます：

> プログラムをGitHubにアップロードしたいです。アカウント作成、リポジトリ作成、認証設定、フォルダ接続まで一つずつ教えてください。

設定完了後は、ターミナル（Terminal）を開き、以下のコマンドでアップロード：

```bash
cd [あなたのフォルダのパス]
git add .
git commit -m "Update"
git push -u origin main:main
```
[あなたのフォルダのパス] を自分のものに置き換え、貼り付けてEnterキーを押せばOKです。安定した状態になったら、この手順でクラウドに保存しておきましょう。

---

### (D) 無料でオンライン公開する方法：GitHub Pagesなど

- 完成した作品を誰でも使えるように無料で公開可能
- (C)の設定が済んでいれば、以下のPromptを使ってChatGPTに公開方法を聞きましょう：

> GitHubにアップしたコードを、GitHub Pagesで一般公開するにはどうしたらいいですか？

GitHubを使わない場合も、無料のホスティングサービスをAIに尋ねることができます。

---

## まとめ：アイデアを形にする、その一歩は自分でも踏み出せる

プログラミングで一番難しいのは「書くこと」ではなく、「どう聞けばいいか」と「ツールに慣れること」でした。

今回のプロジェクトは、2晩で完成しました。時間の大半はPromptの試行錯誤と公開方法の学習で、「コードを書く」こと自体は少なかったです。

改めて感じたのは：

> AIでのコーディングはすでに実用的。けれど、それを使える形に仕上げる「最後のひと押し」がまだ必要。

この記事が、あなたの「はじめの一歩」を後押しできたら嬉しいです。

プログラミング不要！Vibe Coding実践編：完成Promptであなたのアプリを公開しよう

![](./japan-market-challenges_cover.png)

---

「日本人は細かい」と聞いたことはありませんか？実際のところ、日本人も人間です。ただ、文化的背景、社会構造、ビジネス上のリスク観により、細部・品質・信頼への期待値が非常に高くなる傾向があります。
 
高い消費力、成熟した産業構造、そして完璧を追求する姿勢を持つ日本市場は、多くの海外テック製品にとって非常に魅力的なターゲットです。\
しかし、日本進出に限らず、海外展開にはさまざまなハードルがあります。\
**中でも日本市場は、要求の厳しさや導入のハードルの高さという点で、特にチャレンジングな存在です。**
 
本記事では、筆者が実際に日本市場にプロダクトを導入する中で直面した課題を紹介し、台湾や米国など他市場との違いも交えながら整理しました。\
*なお、内容はあくまで個人の実体験に基づくものであり、企業や業界により状況は異なります。*

---

## 課題1：厳格な品質基準

**キーワード：細部、期待値管理、職人精神**
 
**共通点と違い：** 他国にもあるが、日本は基準がより高い

日本のユーザーや企業は、「安定性」「信頼性」「細部の使い勝手」に対する期待が非常に高いです。\
いわゆる「職人精神」はこの部分に表れており、バグがないのは最低限であり、操作の流れや導線が悪ければ不合格とされかねません。
 
**実例：**\
あるライブ配信機能の導入では、クライアントはライブ自体の機能よりも、入場時の案内、再生失敗時のリカバリ、事前リスク排除など、周辺体験の方に強い関心を持っていました。\
また、例外画面についてもテキストだけでなく**スクリーンショットの提出**を求められることもありました。こうした準備や説明には他国市場以上のコストがかかります。
 
**背景文化：**\
これは「他人に迷惑をかけない」という日本文化の価値観に根差しています。プロダクトは単なる機能集合ではなく、思いやりと責任感の表現でもあります。
 
**対応策：**\
あらゆるユースケースや異常パターンを事前に想定し、対策を用意する。クライアントから問われる前に、自ら細部への配慮と誠意を見せることが重要です。

---

## 課題2：複雑かつ繊細な組織内意思決定プロセス

**キーワード：根回し、合意形成、共同提案**
 
**共通点と違い：** 大企業ならどこもあるが、日本は特に繊細

担当者が意思決定権を持っているとは限らず、こちらの提案を上層部にそのまま伝えることも稀です。\
日本企業では「根回し」（社内での事前調整と説得）が不可欠で、それがなければ提案が正式に取り上げられることもありません。
 
**典型的な状況：**\
会議では和やかでも、実際には情報収集中で、評価プロセスには至っていないということが多々あります。
 
**リスク：**\
提案が社内で止まってしまい、想定外の理由で却下されたり、進行が大幅に遅れることもあります。
 
**実践的アプローチ：**\
担当者が孤軍奮闘で「売り込む」のではなく、**一緒に提案を進める姿勢**がカギです。例えば：

- 社内の利害関係者ごとのメリットや説明を一緒に整理
- 提案資料や図解などを提供し、社内共有を手助け
- 「同じチーム」という信頼感の構築

**対応策：**\
「任せる」のではなく、パートナーとして提案を一緒に推進する姿勢が成功の鍵です。

---

## 課題3：技術的ディテールへの深いこだわりと継続性の重視

**キーワード：技術の透明性、長期運用、構造の理解**
 
**共通点と違い：** 日本は他国より技術面の要求が深く、長期的視点が強い

多くの日本企業は「使いやすいか」や「革新的か」だけでなく、以下のような構造的観点に注目します：

- 基盤システムは安定しているか？
- 5年後でも保守できるか？
- 新機能がアーキテクチャを壊さないか？

**実例：**
ある企業から、データの事前処理・キャッシュ処理に関する詳細説明を求められました：

- どのデータが事前処理されるか
- 処理のタイミングと条件
- 処理成功の検証方法
- どのような状況で fallback が発動するか

これほどの技術深堀りは、他の国ではあまり見られないものでした。
 

**対応策：**

ブラックボックスな仕様や不完全なドキュメントでは信頼を得られません。\
明確な技術ドキュメントとバージョン管理計画を整備し、長期的視点での協業可能性を示しましょう。

---

## 課題4：ローカル規制とコンプライアンス要求を無視できない

**キーワード：法規制、業界ルール、隠れたリスク**
 
**共通点と違い：** 海外にもあるが、日本は独自のルールが多い

GDPR や米国の法律に準拠していても、日本では別の規制でつまずくことがあります。特に：

- 個人情報保護法の細かい運用
- 金融、医療、教育など業界別のルール
- 特殊な電子署名フォーマット（例：JPKI）、KYC 手続き

**具体的な例：**

- **Uber**：日本では個人ドライバーが使えず、タクシー業者との提携に限定されました。
- **Airbnb**：初期は法令未整備で、掲載物件が一斉削除された時期もありました。

つまり、**グローバル企業でさえ、日本市場特有の規制には慎重な対応が求められる**ということです。
 
**対応策：**

- 現地の法律専門家・コンプライアンスコンサルタントと早期に連携
- 開発段階から業界ごとの要件を確認する checklist を用意
- 柔軟にカスタマイズできる設計で、後からの調整に備える

---

## 課題5：取引から「信頼関係」への転換

**キーワード：信頼の重視、日本語対応、現地の安心感**
 
**共通点と違い：** 日本は長期的パートナーシップへの期待が強い

日本の B2B 取引では、単なる「サービス提供者」ではなく、**一緒に成長するパートナー**として見られることが多いです。評価対象は以下のような点にも及びます：

- 日本語でやり取りできるか？
- 返信が速いか？約束を守るか？
- 拠点はあるか？現地メンバーはいるか？
- トラブルが起きた時、責任を果たしてくれるか？

**背景：**\
顧客企業も自社のクライアントから信頼される責任を負っており、パートナー選定にも慎重になります。\
そのため、**曖昧な対応や誠意の見えない態度は早期にNG**と判断されがちです。
 
**対応策：**

- 現地法人やオフィスの設置、あるいは現地採用で安心感を醸成
- 難しければ、文化理解のある日本語対応の担当者を配置
- 日本市場に本気で取り組む意志とリソースを明確に伝える

---

## おわりに：文化を理解し、基礎を固めることが成長の鍵

今回ご紹介した課題は、筆者が日本のクライアントと何度も関わる中で繰り返し遭遇したものでした。\
世界中どこでも同様の悩みはあるかもしれませんが、**日本市場の「深さ」と「期待値」は一段上**であることを改めて実感しています。
 
日本市場に入るには、技術力や製品力だけでなく、文化的理解とコミュニケーション力が不可欠です。\
ただし、準備をしっかりすれば、そこから得られる信頼とロイヤルティは他国以上に強固で、**競合に対する参入障壁**にもなり得ます。
 
実は、これらの考え方は日本市場だけのものではありません。

文化を理解し、細部に配慮し、着実に実行する──\
それこそが、どの国でも通用する不変の戦い方です。

---

**次回の記事では、各課題に対する導入コストと必要期間を分析し、投入リソースの目安を共有する予定です。**

日本市場への進出は技術力だけでは足りない：私が踏んだ落とし穴と学び

![](./vibe-coding-getting-started_cover.png)

# プログラミングができなくてもプロダクトは作れる？ 

「こんなツールがあったら便利なのに」—— 
そう思ったこと、ありませんか？ 
でも「自分はプログラミングできないし」と、すぐに諦めてしまった。

以前なら、それで終わりでした。 
でも今は、AI があなたのひとことからツールを作ってくれます。 
それが「Vibe Coding（バイブ・コーディング）」です。

たとえば AI にこう伝えます： 
「うちの犬の成長を紹介するウェブページを作りたい」 
すると画面や機能が自動生成され、写真ギャラリーやタイムラインまで付けてくれます。

[こちらをクリックして Part 2 の実践編を読む](https://www.louisan.dev/jp/blog/vibe-coding-part2)

---

私は元々エンジニアで、今はプロダクトマネージャーです。最近は Vibe Coding を活用して 4 つの新しい作品を作り、既存のシステムも維持管理しています。

この記事では：

- Vibe Coding が初心者や上級者にどう役立つのか
- どんな場面で有効か、どこに限界があるか
- どう始めるのが良いか、何を学ぶべきか

をお伝えします。

---

## 1. Vibe Coding とは？なぜ注目されるのか？

Vibe Coding とは、「自然言語で AI に実行可能なコードを書かせること」です。\
つまり、自分でコードを書かなくても、AI との会話だけでツールが作れるのです。

背景によって、意味も異なります：

- **プログラミング未経験者や初学者にとって**：技術の世界への入り口。手を動かして体感できる、自信をつける第一歩。
- **経験者にとって**：新しい言語への橋渡し、MVP の高速試作に最適。

この記事では、特に初心者の目線で：

- Vibe Coding がどんな場面に向いているか 
- 始め方や必要な知識 
- どこまでできるか 

を解説します。

---

## 2. 初心者はどう始めるべき？

Vibe Coding に興味を持った人の多くが、こうつまずきます：

> 「ちょっと何か作ってみたいだけなのに、サーバーだの、ログインだの、いきなり難しすぎない？」

そこでおすすめするのは： 
**まずはシンプルな静的ウェブページから始めること。**

理由は以下の通り：

- **ほぼ何もインストール不要**：ChatGPT が生成したコードを、空のプレーンテキストファイルに貼り付けます（Windows は「メモ帳」、Mac は「テキストエディット」をプレーンテキストモードで使用）。そのファイルの拡張子を `.html` に変更し、ブラウザで開くだけで結果が表示されます。開発ツールやサーバーの準備は一切不要です。
- **ログインやデータベースなし**：最初の段階では不要。むしろ複雑になりすぎて挫折しやすい。
- **すぐに変化が見える**：修正して保存 → 更新すればすぐに反映。達成感につながります。

たとえば、このブログ（louisan.dev）も Vibe Coding で作りました。

<div style="text-align: center;">
 <img src="./vibe-coding-getting-started_example.png" alt="Vibe Coding 範例" width="60%" />
 ▲ Vibe Codingを使用して作成したブログページ
</div>

 

ただし、限界もあります：

- データはローカルのみ。ユーザー同士の共有や同期は不可 
- ログイン機能やクラウド保存などは実装できない 
- アクセス制御が必要な場面では機能不足 

つまり、「自分用のツール」や「アイデアのプロトタイプ」に最適です。

---

## 3. 基礎知識は必要？

今の自分に合わせて考えましょう：

### ✅ 全くプログラミング経験がない場合

最初は本当に何も知らなくても OK。GPT と話すだけで始められます。 
ただし、以下を受け入れる必要があります：

- 思った通りの画面にならないことがある 
- 少し修正すると他の機能が壊れることもある 
- 動かなくなっても理由が分からない 

問題なければ、コードを生成して Chrome で開いてみましょう。

もっと安定して動かしたい、細かい調整をしたいと思ったら、少しずつ学ぶタイミングです。

### 📘 初学者（少しわかる、もっとコントロールしたい）

以下の基礎を学ぶのがおすすめ：

- **HTML / CSS** – レイアウトやスタイルの構造を理解する 
- **JavaScript 基本** – クリックイベントやデータ保存（localStorage）など 
- **API 概念** – 外部データ取得の仕組み（天気、翻訳など）

なぜ学ぶのか？

- AI が返すコードの内容を理解できる 
- エラー発生時に原因を探れる 
- AI に頼らず微調整が可能になる 

「わかってから始める」ではなく、「始めてから学ぶ」でOKです。

---

## 4. 初心者が感じる Vibe Coding の限界とは？

最初は「AI、すごっ！」と思います。 
でも少し進むと：

> 「機能をちょっと変えたら、別のところが壊れた」 
> 「ログインつけたいって言ったら、専門用語だらけで無理！」

よくある理由：

- コードの構造や保守性が考慮されていない 
- A を直したら B が壊れるような不安定さ 
- サーバーなどの前提知識がないと、次のステップに進めない 

これは写真にも似ています：

- スマホ + アプリでいい写真は撮れる 
- でも細部や光の調整をしたければ、カメラの知識が必要 

Vibe Coding も同じです：

- 自分用ツールやアイデア検証には最適 
- 本格的に作り込むには学習が不可欠 

> 限界は AI の能力ではなく、どこまで学びたいか。 
> 使えれば十分、で止まってもいいし、 
> もっとやりたいなら、無限に広がる世界が待っています。

---

この記事ではまず基礎を紹介しました。 
次回は、具体的なプロンプトやおすすめツールを紹介します。

もし今、何か作ってみたいアイデアがあるなら、ぜひ ChatGPT に話しかけてみてください。\
あなたの「最初のプロダクト」は案外すぐそこにあります。

[こちらをクリックして Part 2 の実践編を読む](https://www.louisan.dev/jp/blog/vibe-coding-part2)

プログラミング不要でプロダクトを作れる？Vibe Coding の使い方と限界をわかりやすく解説


**AI 時代、仕様書だけが正解じゃない：ニーズを素早く形にする新しい選択肢**

> **なぜ読む価値があるのか？**  
> 要件が曖昧、仕様確定が難航、関係者との認識が合わない——そんな経験がある方にとって、この文章は新しいヒントになるはずです。私は DocuSign を用いた契約フローの自動化を、AI の力を借りて 1 週間で実装しました。この実体験をもとに、「動くプロトタイプを起点に合意を形成する」Demo-Driven Development という考え方をご紹介します。リソースが限られたフェーズや早期検証が求められる場面で、従来の手法に代わる現実的な選択肢となるでしょう。

---

![](./demo_driven_development_cover.png)

## 従来の開発プロセスの限界

従来の開発では、PM が要件定義を行い、デザイナーが画面設計をし、エンジニアが実装します。これは大規模組織では合理的ですが、その分、確認・調整のやり取りに多くの時間がかかります。

そしてもっと厄介なのは、ユーザーにとって「理解できること」と「実際に使えること」は別問題という点です。

- B2B プロダクトでは、「この画面通りに使えますか？」と顧客に確認を取りに行く必要があります。
- B2C の場合はアンケートなどで意図を推測しますが、実際に触ってみないと本当の反応はわかりません。

だからこそ、Scrum では 2 週間ごとのイテレーションが推奨されますが、それでもコストは高いままです。

## AI を活用し、1 週間で動くプロトタイプを作る

今こそ、別の選択肢を取るべきだと思います。

1～2人のマイクロチーム（PM とエンジニア、もしくは技術スキルを持つ PM）で、仕様書なしに直接プロトタイプを作る。

これは「アラインメントを無視する」という意味ではありません。**動くプロトタイプを基軸に、実際の操作体験を通じてニーズをすり合わせる**、という意味です。

AI コーディングツール（Copilot や LLM）を使えば、少ない人手でも十分なものが作れます。

## 事例：DocuSign を用いた契約プロセス自動化

最近、私が担当した案件では、営業チームが顧客との契約書や申請フォームをメールでやり取りしていました。

顧客数が増えるにつれて対応が煩雑化し、特に在庫確認などのプロセスが挟まることでスムーズな契約が難しくなっていました。

DocuSign を使って自動化したいと思いましたが、普通に進めたら大変です：

- DocuSign の API や webhook、template の概念を一から学ぶ必要がある
- 完全な仕様を詰められていない（営業も要件を確定できていない）
- 仕様書がない → 着手できない → プロジェクトが止まる

この状況を打破するために、私はまず簡単な PPT のフロー図で営業とアラインメントを取り、AI を活用してコーディングを開始しました。

そして一週間で、以下のようなシステムを完成させました：

- composite template を用いた「記入→承認→署名」のフロー
- 個人／法人ごとに異なる書類が自動送信
- 画面への埋め込み、テンプレートの自動選択、webhook による状態追跡

今では営業がこのプロトタイプを使って実際に顧客に提案し、顧客もその場で操作しながらフィードバックを返してくれるようになりました。

これが私の提唱する **Demo-Driven Development** です。

## 万能な手法ではないが、「方向性の検証」には最適

AI によるコードは不安定で壊れやすいこともあります。最終的にはプロのエンジニアによる保守が必要です。

しかし、方向性も定まらず、リソースも限られている状況では、このような方法で仮説を早く検証するのが合理的です。

最悪でも、無駄になるのは一週間だけです。

## 実質的には Lean MVP の一種

このやり方は、Lean Startup の MVP そのものです。
違いがあるとすれば、「プロトタイプによる理解の収束」を重視する点です。

つまり、会議や文章から始めるのではなく、**デモできる何か**を最初に作って、そこから考えるという順序です。

本質は「デモ」ではなく、**デモがあるから話が噛み合い、誤解が減り、検証が早くなる**というところにあります。

## 行動ベースの軽やかな開発思考へ

これは「PM がコードを書くべきだ」と言っているのではありません。

ただ、AI によって試すコストが下がった今、私たちは「まず動くものを作って試す」という選択肢を持つべきだと考えています。

特に、早期フェーズにいるスタートアップやリソースが限られているチームなら、ぜひこう自問してみてください：

> 「今、仕様を詰めるよりも、まず何か試作品を出せないか？」

プロダクトは会議ではなく、**実行から**生まれます。


仕様書よりも、まず動くものを見せる：AI 時代の新しいプロダクト開発アプローチ


> **なぜ読む価値があるのか？**  
> 本稿では、開発現場の90%以上において、プロダクトマネージャーが横割り（職能分担）ではなく縦割り（機能の完全な責任）を担うべき理由を実務的な観点から解説します。具体的な実務上の課題、組織構造の比較、そして実践可能な戦略と提案を紹介します。

---

![](./pm-vertical-cut-vs-horizontal_cover.png)

## なぜ「縦割り」がより実践的なプロダクト思考なのか？

縦割りとは：PMがユーザーストーリーや機能の全体に責任を持ち、ユーザーインタビュー、機能設計、技術選定、開発調整、市場投入、コスト管理、価格設定までをカバーすることです。

- 「UXだけ担当」「リリースは担当外」ではなく、成果に責任を持つこと
- 単なる成果物の提供ではなく、製品を売り込むこと
- 全体を把握することで初めて、製品が問題を解決できるか、適切な言葉で市場に訴求できるかを理解できる

> **例**：ある多国籍SaaSプロジェクトで、私はAPI設計、フロントエンド操作ロジック、ユーザー教育資料、価格戦略までを一手に計画しました。プレッシャーは大きかったものの、各決定は論理的な体系の中で行われ、一貫性の欠如やリスクの誤算を防ぐことができました。

---

## 縦割りvs横割り：効率と責任の綱引き

| 項目 | 縦割りPM | 横割りPM |
|------|----------|----------|
| 対象 | 完全なユーザージャーニー | 単一機能（例：API） |
| 責任感 | 高い（成果重視） | 分散的、受動的サポート |
| コミュニケーション効率 | 高い（クロスプラットフォームの論理統一） | 高い同期コスト |
| 組織適性 | 小規模チーム、革新的製品、新規市場 | 大企業、安定開発、プロセス重視 |
| 欠点 | 高いスキル要件、クロスドメイン知識 | オーナーシップの欠如 |

### なぜ縦割りの方が効率的なのか？

横割りのPM（例：バックエンドのみ担当や仕様書作成のみ）は、全体の要件について様々な関係者と同期を取る必要があります。変更のたびに会議、明確化、修正に追加の時間が必要です。要件が曖昧だったり開発シナリオが急速に変化する場合、このコミュニケーションコストは指数関数的に増加し、「ボールを落とす」リスクも高まります。

一方、縦割りPMはプロセス全体を主導でき、確認の往復を減らせます。また、経験を統合し、迅速に学習して次の開発サイクルを最適化しやすくなります。イテレーションサイクルも短く、より密度の高いものになり、製品の進化速度が自然に向上します。

---

## 「PMのスキルが広くない」という課題への対応

これは縦割り設計に対する最も一般的な反対意見です：「一人でこれほど多くの機能をマスターすることはできない！」

これは事実ですが、以下のメカニズムで解決できます：

### バーチャルサポートチーム

- 仕様書作成、マーケティング戦略、価格設定フレームワークなどのベストプラクティスを担当する知識重視の役割を創設（例：機能ドキュメントテンプレート、異なるビジネストーンのメール文例、要件収束と分解プロセスなど）
- PM間でテンプレート、ケース、ガイドラインを共有、またはシニアPMがジュニアPMをコーチング
- ChatGPT、ToneFlowなどのAIツールを活用して初期ドラフト作成を支援し、スキル障壁を下げる

> AIによって参入障壁は下がりました。現代のPMは全てを知る必要はありませんが、「誰に聞くか、どう調べるか、何を達成するか」を知る必要があります。

---

## 縦割りPMの支援策

縦割りの作業モデルを真に効果的にするためには、以下のシステムとプロセス設計が必要です：

- **明確なPM責任マトリックス**：他のチームが各モジュールに対応するPM、どの内容を誰に確認すべきかを明確に知り、情報の混乱や責任の曖昧さを防ぐ
- **定期的なPMアライメントミーティング**：PM間で定期的にアライメントミーティングを開催し、モジュールの進捗と戦略の整合性を取り、早期に衝突点やリスクを発見
- **統合された文書化されたベストプラクティス**：Notionやナレッジベース形式で、仕様書作成、要件分解、時間見積もり、技術協力プロセスなどの知識と経験をまとめ、PMチームの安定した出力基準を形成
- **透明なデリバリープロセスデータプラットフォーム**：開発、デザイン、マーケティングなどの他のチームが各機能のオーナー、タイムライン、設計方向を即座に確認できるようにする

これらの支援システムにより、PMは独立して作業しながらも体系的なフレームワーク内で協力でき、チーム拡大時の知識移転と責任の明確化に役立ちます。

---

## モジュール分割の実践的提案

「機能を完全に分離するのは難しい」という声がありますが、これは実は**MECE原則（Mutually Exclusive, Collectively Exhaustive）**の問題です。マッキンゼーのフレームワークから来るこの管理概念は、分割された項目が「相互に排他的だが、全体として網羅的」であるべきことを意味します。各PMの責任範囲は重複せず、かつ製品要件を完全にカバーする必要があります。

### 良い縦割りモジュールの例：

- **レコメンデーションシステム**：データ収集→アルゴリズム→フロントエンド表示までを1人のPMが担当
- **アカウントモジュール**：ログインロジック、権限管理、サードパーティ統合までを1人が統括管理

### 独立した分割に適さないモジュール：

- iOS/Android/Web FE/BEなど：これらは職能志向であり、単一PMによる管理には適さない

したがって、縦割りは技術やプラットフォームではなく、**機能**を中心に行うべきです。

---

## 全体の製品責任は誰が持つのか？

「全員が自分の機能にしか責任を持たない場合、全体の製品戦略は誰が管理するのか？」という懸念があります。

製品リード（Lead PMまたはHead of Product）の存在に同意します：

- 製品の方向性と原則を設定し、組織全体の運営を担当
- モジュール間の衝突を解決
- モジュールPMの経験が浅い場合、コーチと最終ゲートキーパーとして機能

この設計により、各PMは独立しながらも、全体戦略の断片化を防ぐことができます。

---

## 結論：分割の論理から製品の本質へ

PMの役割は、要件と開発の橋渡しだけでなく、製品の成功に実質的な影響力を持つことです。  
全員が特定の領域に特化させると、「それは私の責任ではない」という文化が生まれやすくなります。  
しかし、製品の成功は一連の完全な連鎖の結果です。

縦割りの思考は、PMに多くのことをさせるためではなく、より包括的に考えさせるためです。  
各機能、各ユーザー体験、各ビジネス決定に真のオーナーを持たせましょう。  
このようなフレームワークでのみ、PMは真に実行者から成果の推進者へと進化できます。

---

## 拡張思考：縦割り構造を採用したい場合、次のステップは？

- **あなたのチームに適したPM分担モデルは？**  
  現在のPM数、背景の違い、協力モデルを評価。縦割り運用の基盤はあるか？どの領域が調整や強化を必要としているか？

- **モジュール分割はMECE原則に従っているか？**  
  現在のモジュール分割を確認。相互に排他的だが全体として網羅的な論理に従っているか？どの機能モジュールが実際に1人のPMによって統括管理されるべきか？

- **PMがクロスドメイン能力を迅速に身につけるには？**  
  内部ベストプラクティス、AIツール、内部コンサルティングシステムなどのバーチャルサポートメカニズムはあるか？チームのクロス機能負担を軽減するために。

これらの質問に唯一の答えはありませんが、縦割り分担を導入する前に、チームと深く議論し設計する価値のある出発点です。 

PMの縦割りvs横割り：実務から見る責任と効率の設計

**三言語協業、役割分担、情報設計に関する実践ノート**

> **なぜこの内容を読む価値があるのか？** 
> 多言語開発における本当の課題は、言語そのものではなく、「情報がどう伝わるか」「誰が何を担当するか」「どうやって意思決定を確認するか」といった点にあります。本記事では、実際に中日英の三言語プロジェクトに携わった中で見えてきた6つの代表的な課題と、それに対応する実践的なアプローチ、可視化モデルを整理しました。PM、開発者、調整役、もしくはプロダクトの海外展開を検討中の方にとって、きっと役立つヒントが見つかるはずです。

---

![](./cross_language_collaboration_cover.png)

## 言語の問題は氷山の一角にすぎない

言語の問題は「通訳すれば済む」と思われがちですが、実際に現場でよく起こるのは：

- クライアントから技術的な詳細質問が大量に届き、回答までに3日かかる
- 中国語版の仕様と英語原本がズレていて、エンジニアの成果物が期待と異なる
- 同じモジュールを担当する上下流エンジニア同士で実装内容を把握していない

これらの問題は、単なる翻訳だけでは解決できません。

---

## 実務で直面する6つの課題とその対策

### 1. 英語の仕様書をクライアントが見てくれない

完全な英語の技術仕様書を提出したところ、「私たちは読めるが、エンドクライアントは絶対に見ない」と一蹴された経験があります。 
 
**対策：** 議論段階では英語をメインとし、User Journeyやフロー図を用意し、重要ポイントのみ中国語で補足。仕様が固まってから全訳を行うことで効率を保ちます。

---

### 2. 多言語仕様が同期されず、実装ミスに繋がる

英語版は古いままで中国語版だけ更新されていたり、その逆も。結果、開発チームごとに異なる理解で実装され、不整合が発生します。 
 
**対策：** 英語を唯一の「正規仕様（source of truth）」と定め、翻訳用ファイルを分離せず、1つのドキュメントに英語＋中国語を段落単位で併記。これにより翻訳漏れや更新忘れを防げます。

---

### 3. クライアント側の窓口が技術的な質問に答えられない

CDN構成やストリーミングの詳細など、非エンジニアの営業やPMが答えざるを得ない場面も。 
 
**対策：** よくある技術質問を日本語テンプレ＋図解でまとめたQ&A集を作成。さらに、各機能を一人の開発PMに責任付けすることで、問い合わせが一元化され、断片的な回答や漏れが防げます。

---

### 4. バイリンガルQ&Aが非効率

1つの質問に対して、中→英→技術回答→中、とやりとりが多く、2〜3日かかることも。 
 
**対策：** Q&Aテンプレート（質問原文、翻訳、技術回答、返信の文調提案）を用意し、すべてをスプレッドシートにまとめます。ChatGPTやToneFlowなどを使って、文調変換や初期翻訳を自動化するのも有効です。

---

### 5. ナレッジが分散して全体像が見えない

参加者が多く、資料はフォルダごとに散在し、誰も全体を把握していない。 
 
**対策：** Notionなどを使ってナレッジセンターを構築。タグ・テンプレート・更新ルールを整備し、「誰が・どこに・いつ更新するか」を明確に決めて強制実行します。でなければ知識は個人依存となり、属人化します。

---

### 6. 多人数・多言語の会議が非効率

翻訳・営業・技術・PM・顧問など10人以上が同席し、何も決まらず終了する会議も。 
 
**対策：** 会議前に目的・担当を定義し、会議中にライブで議事録を記録、終了後に日英中の要約を全員に送付。職能軸（横）ではなく機能軸（縦）で参加者を切ることで、必要な人だけが参加できます。この点は組織設計にも関わるため、別記事で詳しく述べます。

---

## 可視化モデル：コミュニケーションコストの構造

![](./cross_language_collaboration_diagram.png) 
▲ 左：全員が全員とやりとりする「フルメッシュ型」では、線の数＝n(n-1)/2となり、人数が増えるほどコストが急増。右：中心ノードを持つ「ハブ型」では、線の数＝n-1で済み、情報が集中・整理される。

 

各人を「点」、やりとりを「線」と考えてみてください：

- 協調のない状態では全員が全員と話す：n(n-1)/2
- 中心ノード（人・ツール・知識ベース）があれば：n-1

だからこそ、人力で回すのではなく、「仕組み」と「知識設計」が必要なのです。

ただし中心ノードにはそれぞれ課題もあります。以下参照。

---

## 中心化の手段とそのトレードオフ（人・ツール・ナレッジ）

| 種類 | メリット | 課題 |
|---------------------------|------------------------------|------------------------------------------|
| **人**（バイリンガル＋技術） | 柔軟、即応できる | ボトルネック化しやすく、疲弊する |
| **ツール**（AI RAG, Database）| 草稿の自動生成、時短 | Prompt設計が必要、レビューは人間任せ |
| **知識ベース**（Notion等） | チームで共有可能、履歴管理しやすい | 維持コスト高く、使われなくなる可能性もある |

どれを使うかが重要ではなく、「誰が、どうやって、いつ更新するか」を設計することが大切です。

---

## FAQ：多言語プロダクト開発でよくある質問

**Q1：多言語仕様をどうやって同期するの？** 
英語を唯一の正規仕様（source of truth）にし、他言語は補足とする。GitやNotionを使ってバージョン管理・翻訳ステータスの可視化を。

**Q2：中国や台湾側クライアントが英語ドキュメントを読めない時は？** 
中国語の要点まとめ・図解付きの簡易資料を別途作成する。理解促進や社内共有に効果的。

**Q3：Q&Aのやりとりが遅いけどどうすれば？** 
テンプレ＋ツールを活用。翻訳や文調調整を自動化して初期草稿を時短で作る。

**Q4：Notionは多言語ナレッジ管理に向いてる？** 
向いています。言語タグ・複製しやすいテンプレを活用し、複数言語の運用がしやすい設計にしましょう。

**Q5：敬語調整や翻訳精度にAIは使える？** 
使えます。内容に集中すべきで、文調や文化的配慮はAIに任せましょう。ToneFlowはそのために開発しており、敬語の調整や中→英→日などの切り替えも即時対応できます。

---

## 結論：問題は言語ではなく、責任と情報の流れ

多言語プロジェクトを数件経験すれば気づくはず。 
一番難しいのは「言語」ではなく、「誰が何を持っていて」「どう決めるか」「どう共有されるか」。

一見小さなことに見えるプロセス設計が、実は成功を左右する鍵になります。

---

## 今後の記事予定

- 維持しやすい多言語Q&Aシステムの設計方法 
- 文化や組織を超えたチーム設計のベストプラクティス 
- 多言語会議で合意形成を効率化する方法