第2回：「何を作るか」が価値になる ─ 設計力の時代
「AIはコードを書ける。でも、何を作るかは決められない」
コードより設計
前回、こう伝えた。
設計 × 言語化 × コミュニケーション ＝ イメージを具現化できる人
今回は、最初の要素「設計」について深掘りする。
なぜ設計能力が、AI時代に価値を持つのか？
答えはシンプルだ。
AIはコードを書ける。でも、「何を作るか」は決められない。
ここが重要だ。
AIにできること、できないこと
GitHub Copilotに「ログイン機能を作って」と言えば、コードを生成する。
ChatGPTに「ToDoアプリを作って」と言えば、HTMLとJavaScriptを吐き出す。
でも、こう聞いてみるといい。
「このビジネスに必要な機能は何？」
「ユーザーが本当に困っていることは何？」
「限られた予算で、最初に何を作るべき？」
AIは答えられない。
なぜか？
「何を作るか」を決めるには、ビジネスの文脈が必要だからだ。
ユーザーは誰か。競合は何をしているか。予算と時間の制約は。チームのスキルは。
これらを総合して「何を作るか」を決める。それが設計だ。
設計とは何か
設計と聞くと、「UIデザイン」や「システム設計書」を思い浮かべるかもしれない。
でも、ここで言う設計はもっと広い。
設計とは、「何を作るか」を決めるすべてのプロセスだ。
具体的には：
1. ゴールを明確にする
「売上を上げたい」は設計じゃない。
「新規顧客の問い合わせを月100件に増やす」が設計の出発点だ。
2. 制約を理解する
予算は？ 期限は？ チームのスキルは？ 既存システムとの連携は？
制約を無視した設計は、絵に描いた餅だ。
3. 優先順位を決める
全部は作れない。
何を最初に作り、何を後回しにするか。これを決められる人が価値を持つ。
4. 分解して構造化する
「ECサイトを作る」は大きすぎる。
「商品一覧」「カート」「決済」「会員登録」に分解する。
さらに「商品一覧」を「検索」「フィルタ」「ソート」「ページネーション」に分解する。
分解できなければ、実装できない。
プロジェクトマネジメントの再評価
そう、
これ、プロジェクトマネジメントの能力そのものだ。
要件定義。スコープ管理。優先順位付け。WBS作成。リソース配分。
PMBOKで学ぶような、いわゆる「プロマネスキル」。
これまで、プロジェクトマネージャーは「調整役」と見られることがあった。
「技術がわからない人」「会議ばかりしている人」というイメージ。
でも、数字を見てほしい。
PMI（Project Management Institute）の調査によると：
- プロジェクトマネジメントが成熟した組織は、予算内でプロジェクトを完了する確率が2.5倍高い
- スコープ管理が不十分なプロジェクトの失敗率は52%
- ITプロジェクトの成功率はわずか31%
- 失敗の主要因は「要件の不明確さ」と「スコープの膨張」
設計の失敗が、プロジェクト全体を殺している。
AI時代は違う。
コーディングはAIが担当する。設計は人間の仕事になる。
つまり、プロジェクトマネジメントの能力が「具現化」の鍵になる。
設計ができる人の強み
設計ができる人は、何が違うのか？
1. 曖昧な要望を具体化できる
顧客は「使いやすいアプリが欲しい」と言う。
これをそのままAIに伝えても、まともなものは出てこない。
設計ができる人は、こう変換する。
「ユーザーは30代の営業職。外出先でスマホから使う。主な操作は顧客情報の検索と更新。1画面で完結させたい。読み込み速度は3秒以内」
これなら、AIも動ける。
McKinseyの調査によると：
- デザイン主導の企業は、業界平均の2倍の収益成長率
- ユーザー中心設計を実践する企業は、顧客満足度が32%高い
設計の具体性が、ビジネス成果に直結している。
2. 「何が本当に必要か」を見極められる
顧客は「全部欲しい」と言う。
でも、全部作る時間も予算もない。
設計ができる人は、こう問いかける。
「この機能がないと、ビジネスが回らないですか？」
「最初の3ヶ月で絶対に必要なのは、どれですか？」
「この機能は、後からでも追加できますか？」
Harvard Business Reviewの研究では：
- 新製品の95%が失敗する主な理由は「顧客が本当に必要としていることを理解していない」
- Jobs-to-be-Done理論を適用した企業は、製品成功率が5倍向上
本当に必要なものを見極める。これが設計だ。
3. ステークホルダーの意図を汲み取れる
同じ言葉でも、立場によって意味が違う。
「セキュリティを強化してほしい」
- 経営層：「コンプライアンス対応をしたい」
- IT部門：「脆弱性を減らしたい」
- 現場：「ログイン手順を増やさないでほしい」
設計ができる人は、この違いを理解し、落としどころを見つける。
4. AIに正しい指示を出せる
設計ができれば、AIへの指示も的確になる。
「いい感じに作って」ではなく、
「ユーザー登録フォームを作って。入力項目はメールアドレスとパスワード。パスワードは8文字以上、英数字混合を必須。送信ボタンを押したらバリデーションして、エラーがあれば赤字で表示」
具体的な設計があれば、AIは正確に実装する。
設計力を持つ人が活躍する領域
AI時代に、設計力を持つ人はどこで活躍するか？
プロダクトマネージャー
「何を作るか」を決める専門職。ユーザー理解、市場分析、優先順位付け。
Product Planの調査によると、プロダクトマネージャーの需要は過去5年で35%増加。平均年収も上昇を続けている。
AI時代、最も需要が高まる職種の一つだ。
プロジェクトマネージャー
「どう作るか」を管理する専門職。スケジュール、リソース、リスク管理。
コーディングが自動化されても、プロジェクト管理は自動化されない。
ビジネスアナリスト
ビジネス要件を技術要件に翻訳する専門職。
「売上を上げたい」を「この機能を作る」に変換する。
コンサルタント
クライアントの課題を特定し、解決策を設計する。
AIは課題を特定できない。設計できるコンサルタントの価値は上がる。
「技術がわかるビジネスパーソン」
コードは書けなくていい。
でも、技術の可能性と限界を理解し、設計に落とし込める人。
共通点は何か？
「何を作るか」を決められる人だ。
設計力は学べる
「設計力は才能だ」と思う人がいる。
違う。設計力は学べる。
フレームワークを使う
設計には型がある。
ユーザーストーリー、ジョブ理論、リーンキャンバス、PERT図、WBS。
型を知れば、考えやすくなる。
分解の練習をする
大きな問題を見たら、小さく分ける練習をする。
「SNSを作る」→「投稿機能」「タイムライン」「フォロー」「通知」「検索」
さらに「投稿機能」→「テキスト投稿」「画像投稿」「編集」「削除」
これを意識的にやる。毎日やる。習慣にする。
「なぜ？」を繰り返す
顧客が「検索機能が欲しい」と言ったら、「なぜ？」と聞く。
「商品を探すのに時間がかかるから」
「なぜ時間がかかる？」
「カテゴリが多すぎて、どこにあるかわからないから」
本当の課題は、検索機能じゃなくてカテゴリ整理かもしれない。
「なぜ？」を5回繰り返す。これだけで設計力は上がる。
次回予告
設計ができても、それを伝えられなければ意味がない。
AIは「いい感じにして」を理解しない。
チームも「なんとなく」では動けない。
頭の中のイメージを、具体的な言葉に変換する。
これが「言語化能力」だ。
次回：言語化という具現化の技術 ─ イメージを形にする
まとめ：3つの洞察
-
AIはコードを書けるが、「何を作るか」は決められない
- 設計は人間の仕事。AIに任せられない領域
-
設計力 ＝ プロジェクトマネジメント能力
- ゴール設定、制約理解、優先順位付け、分解・構造化。PMスキルが成熟した組織は成功率2.5倍
-
設計ができる人が、AI時代に価値を持つ
- 曖昧を具体に変え、AIと人を動かす。それが設計力