総務が初めてシステム開発を発注するときの社内合意の取り方

社員30人ほどの会社で総務を担当していると、ある日突然「うちもそろそろシステム化を考えないとね」という話が持ち上がります。ところが、いざ「では進めます」と言おうとした瞬間に手が止まります。誰の承認を取ればいいのか、どんな手順を踏めばいいのか、参考にできる前例が社内にないからです。

大企業であれば、情シス部門・経理部門・法務部門がそれぞれの立場で稟議を精査し、複数階層の決裁者を経て承認が下ります。書籍やネット記事で紹介される「システム導入の社内合意の取り方」も、たいていはこの多階層組織を前提にしています。しかし30人規模の会社には、そもそもそのような階層が存在しません。決裁者は社長一人、あるいは社長と専務の二人程度で、情シス部門どころか総務部門ですら自分一人ということも珍しくありません。

この記事では、決裁者が極端に少ない30人規模の会社に特有の合意形成の作り方を扱います。大企業型のプロセスを無理に真似るのではなく、「少人数だからこそ機能する」合意の取り方を具体的な手順で示します。

この記事が想定する読者は、社員10〜30人規模の会社で、総務・経理・人事のいずれかを兼任しながら「なんとなくIT・システム関連もあなたが見て」という立場に置かれている担当者です。専任の情シス担当がいる会社であれば、システム導入の稟議は業務の一環として型が確立していることも多いでしょう。しかしこの規模の会社では、その型自体をゼロから作らなければならないケースがほとんどです。

この記事で分かること

• 30人規模の会社に多階層の稟議フローが機能しない理由
• 決裁者が1〜2人しかいない組織での合意形成の実際の順番
• 「勝手に進めた」と受け取られないための、着手前の一言の重要性
• 反対や懐疑を示されたときの対処の型
• 合意形成を文書に残しておくべき理由

なぜ大企業型の稟議フローは30人規模で機能しないのか

多階層の稟議フローが前提とする状況は、次のようなものです。起案者が稟議書を作成し、直属の上長、関連部署の部長、担当役員、経営会議、社長というように、複数の関門を順番に通過していく。それぞれの関門には別の視点でのチェック機能があり、起案者一人では気づけないリスクを多角的に洗い出す仕組みになっています。

30人規模の会社にこの仕組みをそのまま持ち込もうとすると、次のような不整合が起きます。

• 関連部署の部長にあたる人がいない、あるいは総務担当者自身がその役割を兼ねている
• 決裁者(社長)が現場の詳細をすべて把握しており、稟議書の形式的な段階を踏むことにかえって違和感を持たれる
• 承認ルートを形式的に整えようとすること自体が、時間のムダだと受け取られる

つまり30人規模の会社では、多階層フローを「省略してよい」のではなく、そもそも前提となる組織構造が存在しないため「機能しようがない」というのが実態です。この違いを理解しておくことが、合意形成の設計の出発点になります。稟議という仕組み自体の基本的な仕組みは稟議で説明していますが、30人規模の会社ではこの仕組みを型通りに運用するのではなく、実質を保ちながら簡略化する発想が必要です。

決裁者が1〜2人の会社で機能する合意形成の順番

多階層フローの代わりに機能するのは、「早い段階からの相談」と「材料をそろえた一度の意思決定」を組み合わせた進め方です。具体的には次の順番を踏みます。

1. 着手前の一言: システム化の検討を始める前に、決裁者へ「〇〇の課題について、システム化を検討してみようと思っています」と一言伝える
2. 課題の整理と共有: 何にどれだけ困っているかを1枚のメモにまとめ、決裁者と認識をすり合わせる
3. 選択肢の下調べ: 既製品・外注・現状維持など複数の選択肢を軽く調べ、方向性の仮説を持つ
4. 決裁者への一次相談: 仮説段階で決裁者に見せ、方向性そのものに違和感がないか確認する
5. 具体案の作成: 方向性の了承を得てから、費用感・スケジュール感を含む具体案を作る
6. 最終合意: 具体案をもとに、金額と進め方について正式な合意を得る

この順番の要点は、ステップ1と4という「早い段階での二度の相談」を挟んでいることです。大企業の稟議フローでは、起案者が完成度の高い資料を用意してから初めて上に上げるのが一般的ですが、30人規模の会社でこれをやると、決裁者にとっては「いきなり完成した話を持ってこられた」という印象になりがちです。決裁者との距離が近い組織だからこそ、早い段階で軽く相談を挟み、方向性のズレを検討の後半で発覚させないことが重要になります。

具体案を作る段階でどんな資料が必要になるかは、30人規模の会社が外注費用を稟議に通すための資料の作り方で詳しく扱っています。合意形成の順番自体はこの記事の範囲、資料の中身は別記事という役割分担です。

「勝手に進めた」と受け取られないための一言の効果

決裁者が少ない組織で最も避けたいのが、「知らないうちに話が進んでいた」という印象を持たれることです。これは、実際に無断で進めたかどうかとは関係なく、報告のタイミングだけで起きる問題です。

例えば、総務担当者が良かれと思って複数の開発会社から見積もりを取り、比較資料まで作り上げてから初めて決裁者に報告したとします。担当者としては「準備を整えてから報告するのが丁寧」という意識かもしれませんが、決裁者からすると「自分の知らないところで社外の会社とやり取りが進んでいた」という受け止め方になりかねません。特に30人規模の会社では、社長が社外との窓口を自分だけが把握しておきたいと考えているケースも多く、この感覚のズレはトラブルの火種になります。

これを防ぐ最も簡単な方法が、前述のステップ1「着手前の一言」です。

「〇〇の業務がExcelでの手作業に限界がきていて、システム化を検討してみたいと思っています。まずは情報収集からで構いませんか」

このひと言があるだけで、後続のすべての行動が「決裁者の了承のもとで進めていること」に変わります。仮に途中で方向性を変えることになっても、「勝手に進めた」という印象は生まれません。逆にこの一言を省略すると、どれだけ丁寧な資料を用意しても、決裁者の心証を損ねるリスクが残ります。

反対・懐疑を示されたときの対処の型

決裁者が一人しかいない組織では、その一人が難色を示した時点で話が止まります。多階層組織であれば別の決裁者や部署が後押ししてくれる可能性がありますが、30人規模の会社にはその余地がほとんどありません。だからこそ、反対・懐疑への対処をあらかじめ型として持っておくことが重要です。

決裁者から示される懐疑は、大きく3パターンに分類できます。

いずれのパターンにも共通するのは、決裁者の懐疑は「否定」ではなく「情報不足のサイン」だという捉え方です。反論として受け止めて説得しようとするのではなく、「何が伝わっていないのか」を確認する質問を返すほうが、話が前に進みやすくなります。

小さく試す選択肢としてPoC（概念実証）やMVP（実用最小限の製品）を提示する場合、いきなり大きな金額の話にせず「まずはここまでの範囲で試してみましょう」という区切り方が有効です。ただし、どこまでの範囲を「小さく」の対象にするかの見極め自体が別の論点になるため、詳しくは「まずは小さく」で失敗しないシステム化テーマの選び方を参照してください。

社長からの発案の場合は順番が逆になる

ここまでは総務担当者が課題を発見し、決裁者に提案する流れを前提にしていました。しかし30人規模の会社では、逆のパターン、つまり社長自身が「システム化したい」と言い出すケースも頻繁に起こります。この場合、合意形成の順番はむしろ逆で、社長の発案の熱量を維持しながら、総務担当者が現実的な要件に落とし込んでいく役割を担うことになります。トップダウンで始まった案件特有の注意点は、経営者の鶴の一声で始まる開発案件を暴走させない進め方にまとめています。

合意形成のプロセスを記録に残しておく理由

もう一つ、決裁者が少ない組織だからこそ重要になるのが、合意形成の過程を簡単でよいので記録に残しておくことです。理由は主に2つあります。

1つ目は、後から「言った・言わない」の争いを防ぐためです。決裁者が一人しかいない組織では、口頭でのやり取りが多くなりがちです。「その金額でOKと言った」「いや、そこまでは了承していない」という食い違いは、記録がなければ水掛け論になります。メールやチャットで一言確認を残すだけでも、この種のトラブルは大きく減らせます。

2つ目は、担当者の異動・退職に備えるためです。30人規模の会社では、システム導入の経緯を知っているのが総務担当者ただ一人、というケースが起きやすくなります。この状態は属人化の一種であり、担当者が抜けた瞬間に「なぜこのシステムを、この会社で、この条件で契約したのか」という背景がすべて失われてしまいます。

記録を残す作業は、忙しい業務の合間ではつい後回しにされがちです。しかし、合意した直後のタイミングでメール一本を送るだけであれば、5分もかかりません。「先ほどはお時間をいただきありがとうございました。ご相談した◯◯の件、△△という方向で進めさせていただきます」という程度の簡単な文面でも、記録としては十分に機能します。この一手間を惜しんだために、後になって経緯を再現できず、稟議の資料作りに余計な時間がかかってしまうケースは少なくありません。

記録の形式は堅苦しいものである必要はありません。次の3点を、日付とともにメールやドキュメントに残しておくだけで十分です。

• いつ、誰に、どんな課題を相談したか
• どんな選択肢を検討し、なぜその方向性を選んだか
• 最終的にいくらで、誰の承認のもとに決定したか

この記録は、後述する稟議のための資料そのものではなく、あくまで経緯のメモです。正式な稟議資料の作り方は別記事30人規模の会社が外注費用を稟議に通すための資料の作り方に譲りますが、経緯メモがあれば稟議資料の作成自体もスムーズになります。

決裁者との「距離の近さ」を武器に変える

ここまで、決裁者が少ない組織の制約について触れてきましたが、視点を変えると、これは制約であると同時に武器でもあります。大企業では、起案から決裁まで数週間から数ヶ月かかることが珍しくありません。稟議書が複数の部署を回覧される間、担当者は次の関門に進めるかどうかをただ待つしかない時間が発生します。

30人規模の会社では、この待ち時間がほとんど発生しません。総務担当者が決裁者に直接話しかけられる距離にいるため、疑問点をその場で確認し、その日のうちに方向性を修正できます。この「意思決定の速さ」は、システム開発の外注においても大きな利点になります。開発会社との打ち合わせで出た論点を、その週のうちに社内合意まで持っていける組織は決して多くありません。

この利点を生かすためには、総務担当者が「決裁者への相談」を重い手続きだと捉えないことが重要です。前述の「着手前の一言」も、フォーマルな文書を用意する必要はなく、廊下やオフィスでの立ち話、チャットの一言で十分に機能します。距離の近さを生かすということは、形式を軽くしても実質を保てるという意味であり、逆に形式だけを重くしてしまうと、せっかくの距離の近さという利点を自ら消してしまうことになります。

決裁者が複数いる場合の役割分担

30人規模といっても、決裁権を持つ人が社長一人だけとは限りません。専務や役員が数名いる会社、あるいは創業家の親族が経営に関わっている会社では、決裁者が2〜3人存在するケースもあります。この場合に注意すべきは、「誰が最終的な決裁権を持つのか」を事前に確認しておくことです。

決裁者が複数いる組織にありがちな失敗は、次のようなものです。

• 専務には了承を得たが、実際の決裁権は社長にあり、専務経由の説明では十分な情報が伝わっていなかった
• 役員会での議題にするタイミングを逃し、次回の役員会まで1ヶ月待つことになった
• 決裁者Aと決裁者Bでそれぞれ異なる懸念を示し、両者の懸念を同時に解消できる資料を用意できていなかった

これらを避けるためには、合意形成のステップ1(着手前の一言)の段階で、「今回の件は最終的に誰の承認が必要か」を確認しておくとよいでしょう。「これは私の一存で決めていいのか、それとも役員会にかける必要があるのか」という一言を添えるだけで、後工程の手戻りを大幅に減らせます。

実際の会話例で見る、相談のタイミングと言葉選び

抽象的な説明だけでは実践に移しにくいため、具体的な会話の流れを2つのパターンで示します。

パターン1: 総務担当者が課題を発見し、決裁者に提案する場合

総務担当者「社長、少しお時間よろしいですか。経理の請求書処理なんですが、月末になると毎回3人がかりでExcelに手入力していて、ミスも月に数件出ています。システム化を検討してみたいのですが、まずは情報収集から始めてもよろしいでしょうか」

>

社長「ああ、あれか。前から気になってたんだよな。いくらくらいかかるものなんだ?」

>

総務担当者「まだ調べ始めたばかりで正確な金額は分かりませんが、来週までに2〜3社に話を聞いて、費用感を持って改めてご相談します」

この会話のポイントは、総務担当者が「まだ金額は分からない」と正直に伝えている点です。無理に金額感を先取りして答えようとすると、後で実際の見積もりとの差が生まれたときに「話が違う」という印象を与えてしまいます。分からない部分は分からないと伝え、次にいつ・何を報告するかを明確にすることが、信頼を維持する会話の型です。

パターン2: 決裁者から急に「システム化してくれ」と言われた場合

社長「取引先から聞いたんだが、うちも受発注をシステム化した方がいいんじゃないか。来月から動いてくれ」

>

総務担当者「承知しました。まず現状の受発注の流れを整理してから、どこまでシステム化できそうか調べてご提案します。1週間ほどお時間いただいてよろしいですか」

トップダウンで案件が降ってきた場合、その場で「はい、やります」と即答してしまうと、後から要件の詳細を詰める段階で認識のズレが表面化しやすくなります。総務担当者としては、まず現状整理の時間を確保する一言を返すことが重要です。このパターンについては経営者の鶴の一声で始まる開発案件を暴走させない進め方でさらに詳しく扱っています。

他部署を巻き込む必要がある場合の合意形成

システム化のテーマによっては、総務担当者と決裁者だけでは完結せず、実際にシステムを使う現場部署(営業・製造・経理など)の合意も必要になります。30人規模の会社では部署間の壁が薄く、大企業のような部署間調整の複雑さはありませんが、それでも「現場の声を聞かずに決めた」という印象を与えると、システム導入後の定着に悪影響が出ます。

現場を巻き込む合意形成では、次の順番が有効です。

1. 決裁者への着手の一言と並行して、現場の担当者にも「困りごとを整理したい」と軽く声をかける
2. 現場担当者から実際の業務フローと困りごとを聞き取る
3. 聞き取った内容を整理し、決裁者と現場担当者の双方に共有する
4. 具体案の段階で、現場担当者にも内容を確認してもらう

ここで注意したいのは、現場担当者への確認を「承認を取る」という重い位置づけにしないことです。決裁権はあくまで社長(または役員)にありますが、現場の実情を無視した仕様で進めると、システムが完成しても使われない、という最悪の結果を招きます。現場は決裁者ではなく、正確な情報源として位置づけるのが実務的な整理です。

よくある失敗パターンとその予防策

最後に、30人規模の会社で実際に起きやすい合意形成の失敗パターンを整理します。

この表からも分かる通り、失敗の多くは「技術的な判断ミス」ではなく、「報告・相談のタイミングと伝え方」に起因しています。30人規模の会社での合意形成は、精緻な稟議フローを設計することよりも、こうした基本的なコミュニケーションの型を押さえることの方が、はるかに効果が大きいのです。

決裁者が「詳しくない」ことを前提にした説明の組み立て方

30人規模の会社の決裁者は、営業や製造、あるいは経営そのものの専門家であっても、システム開発の専門家ではないことがほとんどです。この前提を忘れて、開発会社から受け取った専門用語をそのまま伝えてしまうと、決裁者は理解できないまま「よく分からないが担当者に任せる」という曖昧な合意しか得られません。曖昧な合意は、後で「そんなつもりではなかった」という食い違いの温床になります。

決裁者への説明では、次の3つの言い換えを意識すると伝わりやすくなります。

• 機能の話を「困りごとの解決」に言い換える: 「API連携で自動反映されます」ではなく、「今は手作業で転記している部分が、自動で反映されるようになります」
• 契約形態の話を「支払いの仕組み」に言い換える: 「請負契約です」ではなく、「完成した成果物に対してお金を払う形です。途中で仕様が変わると別途費用がかかります」
• スケジュールの話を「いつまでに何が起きるか」に言い換える: 「要件定義フェーズが4週間です」ではなく、「最初の1ヶ月は打ち合わせが中心で、実際に動くものが見られるのは2ヶ月目からです」

こうした言い換えは、決裁者を子ども扱いすることとは違います。むしろ、専門用語を右から左に伝えるだけの担当者よりも、自分の言葉で咀嚼して説明できる担当者の方が、決裁者からの信頼を得やすくなります。用語そのものの意味を確認したい場合は、要件定義や請負契約といった個別の用語集ページも参考にしてください。

合意形成にかける時間の目安

最後に、実務上よく聞かれる「合意形成にはどれくらいの時間を見ておけばよいか」という疑問について触れておきます。会社の状況や案件の規模によって幅がありますが、30人規模の会社における目安は次のようになります。

合計すると、着手からおおよそ1〜2ヶ月程度が現実的な目安です。この期間は、大企業の稟議フローと比べれば圧倒的に短いものの、担当者が「本業の合間に」進めている以上、焦って短縮しようとすると準備不足のまま決裁を仰ぐことになりかねません。決裁者に「いつ頃までに結論を出したいと考えているか」を早い段階で伝えておくことで、双方にとって無理のないペースを共有できます。

まとめ: 「フローの正しさ」より「早い相談」を優先する

30人規模の会社における社内合意の取り方は、大企業型の多階層フローを縮小コピーすることではありません。決裁者との距離が近いという特性を生かし、次の3点を押さえることが現実的な合意形成の型です。

1. 着手前に一言相談し、「知らないうちに進んでいた」という印象を避ける
2. 決裁者の懐疑を否定ではなく情報不足のサインと捉え、必要な情報を追加で示す
3. 合意形成の経緯を簡単でよいので記録に残し、属人化を防ぐ

この3点を押さえたうえで、実際にどのテーマからシステム化に着手すべきか、社長発案の案件をどう受け止めるか、稟議資料をどう作るかは、それぞれ個別の記事で扱っています。自社の状況に近いものから読み進めてください。

合意形成がうまくいかなかったときのリカバリー

どれだけ丁寧に手順を踏んでも、決裁者から明確な否定的な反応を受けることはあります。ここで焦って引き下がってしまうと、そのテーマは二度と俎上に載らなくなり、Excelでの手作業や属人化した運用が温存され続けることになります。逆に、否定的な反応を受けた直後にもう一度同じ提案を繰り返しても、決裁者の心証は変わりません。

リカバリーの基本は、「なぜ今回は難しいと言われたのか」を切り分けることです。断られる理由は、大きく分けて次の3種類に整理できます。

• 金額そのものが今の予算規模に見合わない: この場合は、範囲を絞った小規模な提案に組み直すか、次の予算編成のタイミングまで待つのが現実的です
• 緊急度が低いと判断された: 他に優先すべき課題がある場合は、その課題が一段落するタイミングを見計らって再提案する余地を残しておきます
• 担当者への信頼がまだ十分でない: 初めての提案でこの理由が背景にある場合は、小さな成功体験(例えば簡単な業務改善)を先に積んでから、大きな提案に進む方が近道になることもあります

いずれの理由であっても、「今回はタイミングではなかった」というだけで、その課題自体が消えたわけではありません。数ヶ月後に状況が変わったとき(繁忙期でミスが増えた、担当者が退職しかけたなど)に再提案できるよう、最初に整理した課題のメモは捨てずに保管しておくことをお勧めします。属人化した業務がシステム化されないまま放置されるリスクについては、社内での危機感の共有を継続してください。