「エンジニアと話すたびに、何を言っているのか半分くらいしか分からない…」
「技術的な話になると、つい相手に任せてしまう…」
ビジネス側として働いていると、一度はこんな経験をしたことがあるのではないでしょうか。
では、ビジネス担当者は開発のことをどこまで理解すべきなのか。今回はこのテーマを深く掘り下げていきます。結論を先にお伝えすると、「詳細まで知る必要はないが、構造と制約は必ず押さえるべき」です。
前提：ビジネスと開発は役割が違う
まず大前提として、ビジネスと開発はそれぞれ異なる役割を担っています。
- ビジネス側：何を作るか（What）、なぜ作るか（Why）、どう価値を出すか（Value）を考える
- 開発側：どう作るか（How）、どう実現するか（Architecture / Design）を担う
この分業はとても合理的です。エンジニアがビジネス戦略まで考える必要がないように、ビジネス担当者がコードを書けなくても仕事は成立します。
ただし、「役割が違う＝何も知らなくていい」ではありません。ここを履き違えると、プロジェクトは静かに崩壊していきます。
「何も知らない」ビジネス担当者が引き起こす3つの問題
実際の現場で、開発の知識がまったくないビジネス担当者が引き起こしやすい問題を見てみましょう。
① 実現不可能な要件を出し続ける
「このボタンを押したら全ユーザーに即時通知を送ってほしい」「既存システムを一切変えずに新機能を追加してほしい」といった要件が現場では後を絶ちません。技術的な構造を知らないまま要件を出すと、エンジニアは毎回「それは無理です」「かなり工数がかかります」と説明するところから始めなければならず、議論が前に進みません。
② コストや工数の感覚がない
「ちょっとした変更なので1日でできますよね？」という発言はエンジニアを最も消耗させる言葉のひとつです。ビジネス側から見ると「テキストを変えるだけ」に見えても、システムの構造によっては複数箇所の修正・テスト・デプロイが必要なことがあります。コスト感のなさは、見積もりのズレや納期遅延に直結します。
③ 技術的制約を無視した意思決定をしてしまう
「競合がやっているんだから、うちもできるはず」「とにかく早くリリースしてほしい」という発言も要注意です。自社のシステム構成や技術的な制約を無視した意思決定は、後から大きなツケとなって返ってきます。スピード優先で積み上げた「技術的負債」は、後から倍以上のコストがかかることも珍しくありません。
ビジネス担当者が理解すべき「3つのレイヤー」
では、具体的にどこまで理解すればよいのか。以下の3つのレイヤーを押さえておけば、ビジネスと開発の橋渡しとして十分機能できると思います。
レイヤー① 商品・サービスとシステムの対応関係
「この機能はどのシステムで動いているのか」「どの機能がコアで、どこが付随機能なのか」を理解することは、価値設計の基本です。
たとえば、ECサービスであれば「商品検索」「カート」「決済」「在庫管理」「レコメンド」それぞれが別のシステムやモジュールで動いていることが多いです。どの機能に手を入れると何に影響するのかを把握しておくだけで、要件の出し方がまったく変わります。
レイヤー② システム全体のざっくりした構造
詳細な設計図を読める必要はありませんが、「どのシステムがどこと連携しているのか」「データはどこに持っているのか」「どこがボトルネックになりやすいのか」という全体像は把握しておきたいところです。
たとえば、外部APIを使っている箇所があれば、そこがダウンしたときに何に影響するかを知っておくだけで、リスク管理の判断が変わります。また、データがどのシステムにあるかを知っていれば、「このデータを分析に使えますか？」という問いをより具体的に立てられます。
レイヤー③ 技術的制約とコスト感
「この変更は重いのか軽いのか」「どれくらいの期間がかかるのか」「なぜそれが難しいのか」を大まかに理解しておくことは、ビジネスの意思決定に直結します。
正確な工数見積もりはエンジニアに任せればよいのですが、「DB設計を変えるのは重い」「フロントエンドだけの変更なら比較的軽い」「マイクロサービス構成の場合、複数チームをまたぐと調整コストが高い」といった感覚を持っておくだけで、優先順位の議論が格段にスムーズになります。
逆に「やりすぎ」もよくない理由
一方で、ビジネス担当者が開発に入り込みすぎるのも問題です。
- 詳細な設計に口を出しすぎて、エンジニアの裁量を奪う
- 実装レベルの議論に参加して、時間と労力を消耗する
- 「自分が技術を理解している」という自信過剰から、エンジニアの意見を軽視する
ビジネス担当者がやるべきことは、「構造を理解したうえで、ビジネスとしての意思決定をすること」です。「この機能は本当に必要か」「どの順番で開発するか」「事業としてどう価値を出すか」——ここに集中するべきであり、実装の詳細はエンジニアに委ねるのが正解です。
ビジネス担当者が開発知識を身につける実践的な方法
「構造と制約を理解したい」と思っても、最初はどこから手をつければよいか分かりにくいかもしれません。以下のような方法が比較的取り組みやすいです。
- エンジニアに「全体像を教えてほしい」と頼む：詳細ではなく構成図レベルで説明してもらうと、全体像が掴みやすくなります。ほとんどのエンジニアは、こういう質問には喜んで答えてくれます。
- 技術系のブログや入門書を「概念レベル」で読む：コードを書けるようにする必要はありません。「APIとは何か」「データベースの設計とは何か」「クラウドとオンプレの違いは何か」といった概念だけ押さえるだけで十分です。
- 要件定義や仕様書のレビューに参加する：開発サイドのドキュメントを読む習慣をつけると、システムの構造や制約が自然と身についていきます。
- 「なぜ難しいのか」を都度聞く：「それは難しいです」と言われたとき、「なぜ難しいのか」を一言聞くだけで、技術的制約への理解が積み上がっていきます。
まとめ
- ビジネス担当者が理解すべきは「詳細」ではなく「構造と制約」のレイヤー
- 商品とシステムの対応関係・全体構造・技術的制約とコスト感の3つを押さえるだけで意思決定の質が大きく変わる
- 「何も知らない」のも「全部やろうとする」のも逆効果で、適切なバランスがビジネスと開発の橋渡しになる
次にやること
- 担当しているサービスやプロダクトのシステム構成図を、エンジニアに概要レベルで説明してもらう機会を作る
- 次に要件を出す前に「この変更は重いか軽いか」を一度エンジニアに確認する習慣をつける
- 技術的な説明で「なぜ難しいのか」が分からなかったとき、その場で必ず一言聞いてみる
コメント