Python社内導入を提案して通すための手順|反対意見の返し方と実績の作り方

「Pythonで業務が楽になった。これ、チームにも広めたい」

そこまで思えたなら、もうかなり前に進んでいるんですよね。でも次の壁がある。上司に話すとき、何から説明すればいいかわからない。IT部門に相談したら「セキュリティが…」と止められた。「Excelでよくない?」と言われて返せなかった…。

私も同じ経験をしました。製造業の管理部門でPythonを使い始め、毎日1時間かかっていた集計作業を5分に短縮できた。「これは広めるべきだ」と思ったものの、いざ提案しようとしたら言葉が出てこなかったんです。

この記事では、Pythonの社内導入提案を通すために必要な「動き方の順序」と「反対意見への具体的な返し方」を解説します。読み終えたあとには、提案の筋道が見えます。

なお、この記事で紹介するアプローチが特に効く状況は「自分の担当業務でPythonを一度でも使ったことがある」「小さな範囲から試せる業務がある」という状況です。まだPythonを触ったことがない場合は、まずこちらの入門記事からどうぞ。

提案が通らない理由は「Pythonの説明」にある

提案が却下されるとき、多くの人はPythonの説明がうまくできなかったと思ってしまいます。でも実際は逆で、Pythonを説明しようとすること自体が失敗の原因になっていることが多いのです。

「Pythonというプログラミング言語があって、Excelより柔軟で、自動化ができて…」と話し始めた瞬間、上司の頭の中では「IT部門に任せればいい話では?」というモードになります。

社内提案で失敗するパターンは主に3つです。

  • 「Pythonがいかに優れているか」を語ってしまう(ツール紹介になる)
  • 実績がない状態で話を持ち込む(信憑性がない)
  • 「全社導入」を最初から求める(ハードルを上げすぎる)

上司が聞きたいのは「Pythonとは何か」ではなく、「それをやると自分たちの仕事にどんないいことがあるのか」だけです。この前提がズレていると、どれだけ丁寧に説明しても通りません。

提案前にやること:小さな実績を先に作る

提案する前に、まず「数字で話せる実績」を作ることが一番の近道です。これをやっておくかどうかで、提案の通りやすさが大きく変わります。

自分一人で使って「数字」を出す

提案書を書く前に、自分の業務でPythonを実際に使い、時間削減の数字を記録しておきましょう。

私がやったのは、毎朝1時間かけていた生産実績の集計をPythonで自動化し、「以前:60分 → 現在:5分」という記録を1ヶ月間つけることでした。これがあったことで、上司への説明が「試しにやってみたら、こんな結果が出ました」という事後報告になり、「やっていいか?」という許可申請より格段に通りやすくなりました。

実績なき提案は「お願い」になる

実績なしで提案すると、それは「Pythonを使わせてほしい」というお願いになります。上司の立場では、承認のリスクだけがあって、メリットが見えにくい状態です。

でも「この業務で月20時間削減できました」という実績があれば、提案は「お願い」ではなく「報告」に変わります。承認するのではなく、広める判断をするだけでいい状態になるのです。

記録しておくべき数字はシンプルで構いません。

  • Before:作業名・所要時間・頻度(週◯回、月◯回)
  • After:同じ作業の所要時間
  • 削減時間 × 12ヶ月 = 年間削減時間

上司への提案の組み立て方

「Pythonを導入したい」ではなく「この問題を解決したい」と話す

提案の入り口を変えるだけで、相手の反応が変わります。

NG:「Pythonをチーム全員が使えるように社内展開したい」
OK:「毎月末の受注データ集計に一人あたり3時間かかっているのを、30分以内に削減できる方法を見つけました」

上司の関心は「Pythonかどうか」ではなく「問題が解決されるかどうか」です。解決策の手段がPythonであることは、提案が通ってから説明すれば十分です。

刺さる伝え方:時間削減をコストに換算する

上司・経営層が一番わかりやすいのは「お金の話」です。時間削減をコストに置き換えると、数字の重みが変わります。

計算の枠組みはシンプルです。
「削減時間(月)× 人件費単価(時給換算)× 12ヶ月 = 年間削減コスト試算」

例えば、月20時間削減 × 時給換算3,000円 × 12ヶ月 = 年間72万円分の工数削減、という数字が出ます。この「72万円」という言葉は、「月20時間削減」より意思決定者の耳に残ります。

ただし注意点があります。この数字はあくまで試算として提示し、「コスト削減を確約します」と言わないことです。根拠のある試算として伝えることで、信頼性が保てます。

提案書の骨格5点

提案書を書く場合、長い資料は読まれません。A4で1〜2枚、または口頭でも話せる構成に絞りましょう。

  1. 現状の課題:どの業務に何時間かかっているか(具体的に)
  2. 解決策と実績:自動化で何分に短縮できたか(自分での実証)
  3. 展開範囲と期間:まず誰が・いつまでに・どの業務から始めるか
  4. 想定されるリスクと対処:セキュリティ・学習負担・引き継ぎ
  5. 次のアクション:承認後に最初にやること(小さく)

「全社導入」を求めない:小さく試す提案にする

最初から「全社でPythonを使えるようにしたい」と言うのは、承認者へのリスクを最大化する話し方です。

一番通りやすいのは「まず私が担当する受注データ集計業務に限定して、3ヶ月試させてほしい」という提案です。試験的な試みなら、承認コストが下がります。そして3ヶ月後に「こうなりました」と報告できれば、次の展開は格段に楽になります。

反対意見への返し方

提案を進めると、必ず反対意見が出ます。想定外のタイミングで出ると焦りますが、パターンは限られています。事前に返し方を準備しておくだけで、提案の場が格段に安定します。

「学習コストが高い」への答え

よく言われる言葉:「Pythonって難しいんじゃないの? 習得に時間がかかるんでしょ?」

返し方の例:「私は文系・IT未経験ですが、週末に少し勉強して2ヶ月で今の自動化を実現しました。全員に習得を求めているのではなく、まず私が担当範囲で使い、効果が出た業務から少しずつ広げる想定です」

ポイントは「全員が学ぶ」という話にしないことです。最初は一人が担当すれば十分で、広がりは結果が出てから考えられます。

「Excelでよくないか」への答え

よく言われる言葉:「それ、Excelのマクロでもできるんじゃないの?」

返し方の例:「Excelマクロで対応できる範囲は試みましたが、複数フォルダをまたいだファイルの一括処理や、外部CSVの自動取り込みがExcelでは安定しませんでした。Pythonはこの種の処理が得意なため、この業務に向いています。Excelを置き換えるのではなく、Excelで難しい部分だけPythonで補う使い方です」

「ExcelかPythonか」ではなく「Excelで難しい部分をPythonが補う」という共存フレームで話すと、反発が少なくなります。

「セキュリティが心配」への答え

よく言われる言葉:「外部のツールを入れるのはセキュリティ的にどうなの?」

返し方の例:「Pythonはオープンソースのプログラミング言語で、世界的に広く使われています。今回提案する用途は社内データをローカルで処理するものです。外部への送信は行いません。情報システム部門に確認いただける形で資料を準備します」

「セキュリティ」という言葉が出たときは、反論するより「情報システム部門と一緒に確認する」という姿勢を見せる方が得策です。次の項で具体的な動き方を説明します。

「前例がない」への答え

よく言われる言葉:「うちでは前例がないので、ちょっと…」

返し方の例:「私自身がすでに担当業務で3ヶ月間使っており、その間に問題は発生していません。まず私の担当範囲に限定して継続し、3ヶ月後に結果を報告させていただきます。前例は、私がこれから作ります」

「前例がない」は実は反対理由ではなく、「まだ誰も試していない」というだけの話です。自分が試して問題がなければ、それが前例になります。

IT部門・情報システム部への根回し

上司への提案と並行して、IT部門や情報システム部への根回しは別ルートで進めておくのが一番です。

「業務改善の相談」として持ち込む

IT部門への相談を「Pythonを使っていいですか?」という許可申請として持ち込むと、審査モードになって止まりやすくなります。

代わりに「受注データの集計業務を効率化したいのですが、使用するツールについて確認したいことがあります」という業務改善の相談として話し始めると、協力モードで話を聞いてもらいやすくなります。

私の経験では、この持ち込み方の違いだけで最初の返答がずいぶん変わりました。「Pythonを入れたい」と言うと「それはちょっと…」となりましたが、「この集計を自動化したい、確認事項があります」と言うと「どんな確認?」と前に進む会話になりました。

確認してほしいことは事前に3点に絞っておきましょう。

  • Pythonのインストールは社内PCに可能か
  • 社内データをローカルで処理することへの制約はあるか
  • 作成したスクリプトの管理・保管ルールはどう定めるか

IT部門が「NG」と言うのは多くの場合、「よくわからないから止める」です。確認事項を3点に絞り、丁寧に説明することで「それなら問題ない」と言ってもらえるケースが出てきます。私の経験でもこのパターンでした。

提案が通ったあとにやること

提案が通ったあとは、焦らず小さく動くことが次の信頼につながります。最初の3ヶ月の動き方が、その後の展開を決めます。

最初の3ヶ月:「結果を出す」だけに絞る

承認が下りた直後は「広めたい」気持ちが先走りがちですが、まず3ヶ月は自分の担当業務で確実に動かすことだけに集中するのが一番です。

やるべきことはシンプルです。

  1. 1ヶ月目:提案した業務でPythonを安定稼働させる。エラーが出たら直す。記録をつける
  2. 2ヶ月目:Before/Afterの数字を更新し続ける。上司に月1回「現状報告」を入れる
  3. 3ヶ月目:結果をまとめ、次の業務への展開を提案する材料を作る

チームへの展開を考えるなら、以下の記事が次のステップになります。

まとめ:提案の前に「自分が動く」

Pythonの社内導入提案が通るかどうかは、Pythonの説明がうまいかどうかではありません。「すでにやっていて、こういう結果が出た」という事実を持って話せるかどうかです。

改めて流れを整理します。

  1. 自分一人で使い、数字で語れる実績を作る
  2. 「Pythonの話」ではなく「業務課題の解決策」として提案する
  3. 反対意見は事前に準備した返し方で対応する
  4. IT部門には許可申請ではなく業務改善の相談として持ち込む
  5. 最初は小さく、3ヶ月で結果を出して次に進む

これが「提案が通る人」のパターンです。Pythonの知識を深めることより、この順序で動くことの方が、実は何倍も重要なのです。


提案が通ったあと、次にぶつかる壁は「自分で作ったツールをどうチームに使ってもらうか」です。その動き方については、社内の非エンジニアにPythonツールを展開する方法で詳しく解説しています。