経営者の鶴の一声で始まる開発案件を暴走させない進め方

「取引先の社長から聞いたんだが、うちも受発注をシステム化した方がいいんじゃないか。来月から動いてくれ」。ある朝、社長からこう告げられた総務担当者は、何から手をつければいいか分からないまま、返事をしなければならない立場に置かれます。

30人規模の会社では、システム開発の案件が、担当者からの提案ではなく、経営者の一存で始まることが少なくありません。経営者は経営判断のスピードを重視するため、詳細を詰める前に「やる」という結論だけが先に降りてきます。これは大企業であれば、企画部門や情シス部門が間に入り、経営者の意向を要件に翻訳する緩衝材の役割を果たします。しかし30人規模の会社にはその緩衝材がなく、総務担当者が直接、経営者の思いつきと現実の開発プロセスの橋渡しを担うことになります。

この記事では、トップダウンで降ってきた開発案件を、頭ごなしに否定せず、かつ暴走させずに、現実的な要件へと落とし込んでいく進め方を扱います。想定する読者は、社員10〜30人規模の会社で、総務・経理・人事のいずれかを兼任しながら経営者からIT関連の指示を直接受ける立場にある担当者です。経営者との距離が近いことは、意思決定のスピードという利点である一方、思いつきレベルの指示がそのまま現場に降りてくるリスクとも表裏一体です。

この記事で分かること

• トップダウン案件が暴走しやすい理由
• 「その場で断らない、その場で全部を受けない」返答の型
• 経営者の熱量を維持しながら要件を整理する順番
• 「本当にシステム化が必要か」を後から確認する技術
• 経営者の思いつきが変化・撤回された場合の対処

なぜトップダウン案件は暴走しやすいのか

トップダウンで始まる案件が暴走しやすい理由は、主に3つに整理できます。

1つ目は、経営者自身が現場の業務フローの詳細を把握していないことです。経営者は経営判断の視点から「システム化した方がよさそうだ」と考えますが、実際の業務がどのような手順で、どんな例外パターンを持っているかまでは把握していないことがほとんどです。この状態で発案された案件は、要件の解像度が低いまま進んでしまいがちです。

2つ目は、経営者の発言が「決定事項」として社内に伝わりやすいことです。30人規模の会社では、社長の一言がそのまま会社の方針として受け止められる文化があります。担当者が「まだ検討段階では」と留保しようとしても、周囲は「もう決まったこと」として動き出してしまうことがあります。

3つ目は、比較対象がないまま範囲が膨らみやすいことです。経営者が他社の事例や取引先の話を聞いて発案した場合、「うちもあれくらいできるようにしよう」という発想で、当初の課題以上に機能や範囲が膨らんでいくことがあります。判定基準に沿ってテーマを絞り込む発想については「まずは小さく」で失敗しないシステム化テーマの選び方で扱っていますが、トップダウン案件ではこの絞り込みを担当者から持ちかける必要があります。

その場で断らない、その場で全部を受けない: 返答の型

経営者から案件を告げられた瞬間、総務担当者に求められるのは「即座に全部を受け入れる」ことでも「その場で難色を示す」ことでもありません。どちらの反応も、後の工程で問題を引き起こします。

即座に全部を受け入れてしまうと、要件が固まらないまま「来月から動く」というスケジュールだけが独り歩きし、後で「思っていたのと違う」という食い違いが起きやすくなります。逆に、その場で難色を示すと、経営者の熱量を削いでしまい、「担当者はやる気がない」という印象を与えかねません。

この2つの極端を避けるための返答の型が、次のような一言です。

「承知しました。まずは現状の業務フローを整理して、どこまでシステム化できそうか、来週中にご報告します」

このひと言には、3つの意図が込められています。

• 「承知しました」で、経営者の意向を否定しない
• 「まずは現状の業務フローを整理して」で、いきなり発注に動くのではなく、確認のステップを挟むことを明示する
• 「来週中にご報告します」で、いつまでに何を返すかを具体的に約束する

この一言を返すことで、担当者は「検討する時間」を確保しながら、経営者に対しては「行動している」という印象を与えられます。社内合意の取り方全般については総務が初めてシステム開発を発注するときの社内合意の取り方でも扱っていますが、トップダウン案件では特にこの初動の返答が重要になります。

経営者の熱量を維持しながら要件を整理する順番

「承知しました」と答えた後、実際にどのような順番で要件を整理していけばよいのか。次の4ステップで進めることをお勧めします。

1. 経営者の発案の背景を確認する: なぜそのシステム化を思いついたのか、きっかけとなった出来事や課題を聞く
2. 現場の実際の業務フローを確認する: 経営者の発案と、現場の実情にズレがないかを確認する
3. 範囲を絞った具体案を作る: 経営者の意図を汲みつつ、判定基準に沿って現実的な範囲に絞る
4. 具体案を経営者に見せ、方向性を確認する: 「このあたりから始めるのはいかがでしょうか」という形で、範囲を提案する

このステップで重要なのは、ステップ1の「背景の確認」を省略しないことです。経営者がなぜそのシステム化を思いついたのかを理解しないまま要件整理を進めると、最終的な提案が経営者の真の課題意識とズレてしまい、「これじゃない」と差し戻されるリスクが高まります。

背景を確認する際の質問例を挙げます。

• 「どんなきっかけでそう思われたんですか?」
• 「取引先の会社では、具体的にどんな仕組みを使っているとおっしゃっていましたか?」
• 「今回のシステム化で、一番解決したい困りごとは何でしょうか?」

これらの質問を通じて、経営者の発言の裏にある本当の課題(例えば「取引先に見劣りしたくない」という体裁の問題なのか、「実際に業務が非効率で困っている」という実務上の問題なのか)を見極めることができます。この見極めが、後の要件整理の精度を大きく左右します。

経営者の発案と現場の実情にズレがある場合の伝え方

経営者の発案が、現場の実際の業務フローと食い違っていることは珍しくありません。例えば、経営者は「受発注を全部自動化したい」と考えていても、実際の現場では取引先ごとに異なるフォーマットでの発注書が届いており、単純な自動化では対応しきれない、というようなケースです。

このズレに気づいた場合、担当者は事実を正確に伝える役割を担う必要があります。ただし、伝え方には注意が必要です。「それは無理です」という否定形ではなく、「現状はこうなっているので、まずはこの部分から始めるのが現実的です」という提案形で伝えることをお勧めします。

具体例を挙げます。

「受発注の完全自動化を目指す前に、まずは取引先ごとのフォーマットの違いを整理する必要がありそうです。試算したところ、上位5社との取引で全体の7割を占めているので、まずはこの5社分だけを対象にシステム化するのはいかがでしょうか。残りの取引先は、状況を見ながら段階的に対応を広げていく形が現実的かと思います」

このように、「できない」ではなく「まずはここから」という形で範囲を再提案することで、経営者の当初の意図を否定せずに、現実的な着地点へ導くことができます。

範囲を絞った具体案の作り方

経営者の発案を現実的な範囲に絞り込む際、判定基準に沿った整理が有効です。詳細な判定基準は「まずは小さく」で失敗しないシステム化テーマの選び方に譲りますが、トップダウン案件特有の観点として、次の点も確認しておく必要があります。

これらの観点を押さえたうえで、具体案には次の3点を必ず含めるようにしてください。

1. 最初に着手する範囲(全体のうち、どこまでを対象にするか)
2. 概算の費用感(正確でなくても「〇〇万円〜〇〇万円程度」というレンジ)
3. 大まかなスケジュール感(いつ頃から動き出し、いつ頃に形になりそうか)

「本当にシステム化が必要か」を後から確認する技術

トップダウン案件では、そもそも「本当にシステム化する必要があるのか」という根本的な問いが、検討の初期段階で飛ばされがちです。経営者が「やる」と決めた前提で話が進むため、担当者が「そもそも必要か」を問い直すのは心理的なハードルが高く感じられます。

しかし、この問い直しを省略すると、後になって「思ったより効果が出ない」「実は既製品で十分だった」ということが判明し、投資が無駄になるリスクが残ります。担当者としては、頭ごなしに「必要ない」と主張するのではなく、調査の過程で自然に確認する形を取ることをお勧めします。

例えば、要件整理の一環として「同じ課題を解決できる既製のSaaS製品がないか」を調べ、その結果を具体案に含めて報告する、という進め方です。

「調べたところ、御社の規模であれば、月額数万円程度のクラウドサービスで基本的な機能はカバーできそうです。独自開発をする場合との違いは、細かいカスタマイズができる点ですが、そこまでの独自性が本当に必要かどうか、一度整理させていただければと思います」

このように、選択肢の比較として自然に提示することで、経営者自身が「そこまでのカスタマイズは不要かもしれない」と判断を修正する余地を作れます。ノーコード・ローコードや既製品との比較検討を怠らないことは、トップダウン案件であっても変わらない重要な手順です。

経営者の思いつきが変化・撤回された場合の対処

トップダウン案件のもう一つの特徴は、経営者の意向自体が途中で変化したり、撤回されたりすることがある点です。「やっぱり今回は見送ろう」「思っていたのと違う方向にしたい」という変化は、担当者にとっては振り回されているように感じられるかもしれませんが、経営者の立場では、他の経営判断とのバランスの中で優先順位が変わることは自然なことです。

この変化に対して、担当者が取るべき対応は次の2点です。

1. それまでの検討過程を無駄にしない: 業務フローの整理や現状把握で得た情報は、たとえ今回の案件が見送られても、次にシステム化を検討する際の土台として残しておく
2. 変化の理由を確認し、記録しておく: なぜ方向性が変わったのかを把握しておくことで、次回同様の提案をする際に、同じ理由で見送られることを避けられる

トップダウン案件が見送りになったからといって、担当者の対応が失敗だったわけではありません。むしろ、範囲を適切に絞り込み、経営者が冷静に判断できる材料を提供できたからこそ、無理な投資を避けられた、というケースも少なくありません。

他部署の担当者からの反発にどう向き合うか

トップダウン案件では、経営者と担当者だけでなく、実際にそのシステムを使うことになる現場部署の反応にも注意を払う必要があります。経営者の発案で始まった案件は、現場からすると「自分たちの意見を聞かれないまま決まった話」に見えることがあり、「また上が勝手に決めた」という反発を招くことがあります。

この反発は、システム導入後の定着を妨げる大きな要因になります。せっかく開発した仕組みでも、現場が「使わされている」という感覚を持ったままでは、旧来のExcelや紙の運用に戻ってしまうことも珍しくありません。

これを防ぐために、担当者は要件整理の段階から、現場の担当者を「意見を聞く相手」として巻き込むことをお勧めします。決裁権はあくまで経営者にありますが、実際の業務フローや使い勝手に関する情報は、現場の担当者からしか得られません。「社長からの指示で検討を始めていますが、実際の業務のやり方を教えてもらえますか」という形で声をかけるだけでも、現場の担当者は「一方的に決められた」という感覚を持ちにくくなります。

現場の巻き込み方の詳細は「まずは小さく」で失敗しないシステム化テーマの選び方でも扱っていますが、トップダウン案件では特に、経営者の意向と現場の実情の両方に目を配る担当者の役割が重要になります。

トップダウン案件を稟議として正式化する

範囲と方向性が固まったら、最終的には正式な合意として社内に残す必要があります。トップダウンで始まった案件であっても、金額が一定規模を超える場合は、経緯と内容を整理した資料を用意しておくことをお勧めします。経営者自身が発案した案件であっても、後から「なぜその金額になったのか」を振り返られる記録があることは、担当者にとっても経営者にとっても有益です。具体的な資料の作り方は30人規模の会社が外注費用を稟議に通すための資料の作り方で扱っています。

実際の会話例で見る、初動の受け止め方

抽象的な返答の型だけでは実践しづらいため、具体的なやり取りの例を示します。

ケース1: 取引先の話を聞いて発案されたケース

社長「A社の社長と話してたんだけど、あそこは在庫管理を全部システムでやってるらしい。うちも遅れてるよな。来月から動いてくれないか」

>

総務担当者「承知しました。うちの在庫管理も、確かにExcelでの手作業が中心なので、検討する価値はありそうです。まずは今の在庫管理のやり方と、どのあたりに時間がかかっているかを整理して、来週中にご報告してもよろしいですか」

>

社長「ああ、頼む」

このやり取りのポイントは、担当者が「検討する価値はありそうです」と経営者の問題意識に同意しつつ、「まずは整理する」という現実的なステップを提示している点です。頭ごなしに「今は忙しいので難しいです」と答えると、経営者の熱量を削いでしまいますが、逆に「分かりました、すぐ手配します」と即答してしまうと、要件が固まらないまま話が先走ってしまいます。

ケース2: 経営者の抽象的なビジョンから発案されたケース

社長「これからはDXの時代だから、うちも紙をなくして全部デジタル化していこう」

>

総務担当者「デジタル化を進める方向性、私も賛成です。ただ『全部』というと範囲がかなり広いので、まずはどの業務が一番紙に依存していて困っているか、洗い出してみてもよろしいですか。優先順位をつけてご提案します」

このケースでは、経営者の発案が具体的な業務ではなく抽象的なビジョンにとどまっているため、担当者が範囲を具体化する役割を担っています。「全部デジタル化」という指示をそのまま鵜呑みにすると、収拾がつかない大規模プロジェクトになりかねません。範囲を絞り込む発想は「まずは小さく」で失敗しないシステム化テーマの選び方の判定基準がそのまま使えます。

トップダウン案件で担当者が陥りやすい心理的な罠

トップダウン案件を担当する際、総務担当者が陥りやすい心理的な罠がいくつかあります。これらを認識しておくことで、冷静な判断がしやすくなります。

• 「社長の指示だから逆らえない」という思い込み: 経営者の発案を疑問視すること自体がタブーだと感じてしまい、明らかに無理のある範囲や期限であっても、そのまま受け入れてしまう
• 「早く動かないと評価が下がる」という焦り: スピード感を見せようとするあまり、要件整理のステップを省略し、拙速に開発会社への発注に進んでしまう
• 「自分の判断で範囲を絞ってよいのか」という遠慮: 範囲を絞る提案は経営者の意向に反すると感じ、言われた通りの広い範囲のまま開発会社に相談してしまう

これらの罠に共通するのは、「経営者の指示は絶対であり、担当者は忠実に実行するだけ」という前提です。しかし実際には、経営者自身も現場の詳細までは把握しておらず、担当者が現実的な情報を持ち帰って提案することを歓迎するケースがほとんどです。経営者にとっても、後になって「思っていたのと違う」という失敗を避けたいのは同じであり、担当者による事前の整理は、経営者の意思決定を助ける役割を果たします。

トップダウン案件と担当者発案の案件が同時に走る場合

30人規模の会社では、経営者からのトップダウン案件と、総務担当者が自ら発見した課題(部署単位の小規模案件)が、同時に検討対象になることもあります。この場合、限られたリソースの中でどちらを優先するかという判断が必要になります。

基本的な考え方として、トップダウン案件は経営者の関心が高く、社内合意そのものは比較的取りやすい一方、範囲が曖昧で要件整理に時間がかかる傾向があります。一方、担当者発案の小規模案件は、範囲が明確で着手しやすい一方、経営者への説明・説得が別途必要になります。

両方を同時に進めようとすると、担当者のリソースが分散し、どちらも中途半端になるリスクがあります。可能であれば、まずトップダウン案件の範囲整理を優先し、その過程で見えてきた「本当に必要な部分」だけに絞り込んだうえで、余力があれば担当者発案の案件も並行して進める、という順番が現実的です。

契約形態の選び方にもトップダウン案件特有の注意がある

範囲や要件が完全に固まりきらないまま「とにかく早く動いてほしい」という圧力がかかりやすいトップダウン案件では、契約形態の選び方にも注意が必要です。請負契約は完成物に対して対価を支払う契約であるため、要件が曖昧なまま契約を結ぶと、後から「これは契約の範囲外」というトラブルが起きやすくなります。

一方、準委任契約は業務の遂行そのものに対価を支払う契約であるため、要件が固まりきっていない段階からでも動き出しやすいという利点があります。ただし、成果物の完成が保証されるわけではないため、進め方や報告の頻度について、事前に開発会社とすり合わせておく必要があります。

トップダウン案件で「来月から動いてほしい」というスピード感が求められている場合、いきなり請負契約で全体を発注するのではなく、まずは準委任契約で要件整理そのものを依頼し、要件が固まった段階で請負契約に切り替える、という二段階の進め方も選択肢の一つです。契約形態の詳しい違いは、コラム請負契約と準委任契約の違い:システム開発の契約形態はどちらを選ぶべきかで解説しています。

この二段階の進め方を経営者に説明する際は、「急いでいるからこそ、最初の段階で正式な契約を急がず、要件を固める期間を挟む」という理屈を丁寧に伝えることが重要です。急いでいるという理由で契約形態の検討まで省略してしまうと、後になって「思っていた内容と違う」というトラブルが起きた際に、契約上の解釈でも揉めることになりかねません。スピードを優先することと、契約の丁寧さを保つことは、両立できないわけではないという点を意識してください。

まとめ: 「受け止める」と「絞り込む」を両立させる

経営者の鶴の一声で始まる開発案件は、否定するのではなく、まず受け止めることが出発点です。そのうえで、次の4点を実践することで、暴走を防ぎながら現実的な着地点に導くことができます。

1. その場で全部を受けず、「まず整理して報告する」という一言で時間を確保する
2. 経営者の発案の背景を確認し、真の課題意識を見極める
3. 現場の実情とのズレがあれば、否定形ではなく提案形で伝える
4. 既製品との比較を含め、「本当に必要か」を自然な形で確認する
5. 契約形態も、要件の固まり具合に応じて柔軟に選ぶ

これらはいずれも、経営者の指示を軽んじる態度ではありません。むしろ、経営者が下した「システム化する」という大きな判断を、実際に成果につながる形で実現するための、担当者にしかできない橋渡しの仕事です。トップダウンで降ってきた案件だからこそ、担当者が現実的な情報と選択肢を提示する役割の重みは大きく、その積み重ねが経営者からの信頼にもつながっていきます。

一度この進め方を経験しておくと、次に同じような形で案件が降ってきたときの初動が格段に早くなります。「まず現状を整理してから」という返答自体が、担当者にとっても経営者にとっても、当たり前の共通認識として定着していくためです。トップダウン案件への対応力は、一度きりのスキルではなく、繰り返すほど組織に根付いていく習慣だと捉えてください。

最後に付け加えておくと、トップダウン案件がすべて悪いわけでは決してありません。経営者が課題意識を持ち、自ら動こうとすること自体は、会社にとって前向きなシグナルです。担当者の役割は、その前向きなエネルギーを止めることではなく、実現可能な形に整えて着地させることにあります。受け止め方と絞り込み方さえ押さえておけば、トップダウン案件は暴走ではなく、会社を前に進める推進力に変えられます。範囲の絞り込み方や社内合意の取り方、稟議資料の作り方は、それぞれ別記事で詳しく扱っていますので、自社の状況に応じて併せて読み進めてください。

これらを実践することで、経営者の熱量を削ぐことなく、かつ会社にとって過大な投資にならない、現実的な開発案件へと落とし込むことができます。範囲の絞り込み方や社内合意の取り方は、それぞれ別記事で詳しく扱っていますので、あわせて参照してください。

開発会社に相談する段階での注意点

範囲を絞り込んだ具体案がまとまり、実際に開発会社への相談に進む段階でも、トップダウン案件特有の注意点があります。それは、「経営者が直接、開発会社とのやり取りに参加したがるケースがある」という点です。

経営者自身が発案した案件であるため、経営者が打ち合わせに同席し、その場で担当者が想定していなかった追加の要望を口にしてしまう、ということが起こりえます。これは決して珍しいことではなく、経営者の熱量の表れでもありますが、その場のノリで範囲が再び広がってしまうリスクがあります。

この事態を避けるために、担当者は打ち合わせの前に、経営者と次の点をすり合わせておくことをお勧めします。

• 今回の打ち合わせで合意したい範囲(スコープ)を、事前に一枚のメモとして共有しておく
• 打ち合わせの場で新しい要望が出た場合は、その場で即決せず「持ち帰って検討する」という運用を、経営者にもあらかじめ了承してもらう

このすり合わせをしておくことで、打ち合わせの場が感覚的な要望のぶつけ合いになることを防ぎ、事前に整理した具体案に沿った、生産的な打ち合わせにすることができます。初回打ち合わせで確認すべき事項全般は、コラム開発会社との初回打ち合わせで聞くべきことも参考にしてください。