「IT稟議書通らない問題」の「ここ」が知りたい——イベント参加者の質問に対する回答は

　どうすればIT投資の重要性を経営陣にわかってもらえるのか、通る稟議書と通らない稟議書の違いはどこにあるのか、経営陣が通したくなるIT稟議書を作成するにはどうしたらいいのか——。　

　3月22日に開催したDarsana・AnityA主催のイベント「『通らないIT稟議書』は、どこに問題があるのか　経営層を納得させるためのアプローチとは」では、現役のITリーダーをゲストに招き、IT稟議が通らない理由を多角的な視点で探るとともに、その解決策を考えました。

　中編に続く本イベント記事の後編では、イベント参加者から寄せられた質問への回答をご紹介します。ビジネスサイドから情シス部長になったオルガノ株式会社の経営統括本部で情報システムグループ長を務める原田篤史氏、IT出身でビジネスを学ぶことの重要性を知るIMV株式会社 IT統括部長の宮西靖氏とAnityA（アニティア）代表取締役 中野仁の3人がお答えしています。

費用対効果（ROI）の呪縛を解く：「ないものは、ない」と言い切る覚悟

数字のでっち上げは厳禁。費用対効果以外の「顧客満足」を正直に語る

「システム導入で工数を減らしても、正社員をすぐに解雇できるわけではないため会計上のコスト削減に見えない。財務効果の説明を求められたとき、どう対応すべきか」という切実な質問に対し、原田氏は「小細工をして数字をでっち上げるのは絶対にやめるべきだ」と断言します。

でっち上げた数字で一度稟議を押し通してしまうと、導入後に「本当にそれだけのコストが浮いたのか」を厳しく追及され、後で自分が詰んで辛い思いをするだけです。「あるものはある、ないものはない」と正直に言い切るしかありません。

財務効果として直接見えないのであれば、小細工をするのではなく、「これをやることでお客様の満足度がこれだけ上がるんだ」「現場のこのしんどさが解消されるんだ」という、投資すべき本質的な理由を実直に経営層へ説明するべきです。もし、現場や顧客のために本当に必要な投資であるにもかかわらず、経営層が「ROIの数字」だけに固執して理解しようとしないのであれば、その会社に見切りをつけて転職活動を始めた方が、自身のキャリアにとっても健全だと言えます。

コスト削減のIT投資は「未来の可能性を前借りした負債の返済」である

中野氏は、ROIという概念そのものの適用範囲について指摘します。ROI（投資対効果）は、売上を伸ばすための「プロフィット（利益創出）系」のビジネス投資には非常に馴染みますが、社内のシステム刷新やセキュリティといった「コスト（守り）系」の投資に無理に当てはめようとすること自体がナンセンスです。

特に、古いシステムを長年放置してきた大企業におけるIT刷新は、投資というよりも「これまでちゃんと借金（技術負債）を返してこなかったツケの回収（取り立て）」に近いです。未来の可能性をごまかして前借りし続けた結果、これ以上引き延ばせない限界（マイナス）が来ている状態なのです。「これは儲かるかどうかの話ではなく、溜まりに溜まった負債の返済である」という論点を明確にして経営層と会話をしなければ、いつまでも噛み合わないROIの議論に付き合わされ続けることになります。

浮いた工数を「何に使うか」という経営側の明るい意志

宮西氏も、「解雇が容易ではない日本企業において、正社員の工数を数パーセント減らしたところで、圧倒的な正社員コストの前には焼け石に水（焼け石にウォーター）である」と同意します。

だからこそ、コストをどう減らすかという暗い話ではなく、「このシステムで現場の工数がこれだけ浮いたら、社長が以前からやりたがっていた『新しいあの施策』に人を割けますよ」という明るい話（経営戦略とのリンク）にすり替えることが重要です。

浮いた工数を次の成長ドライバーにどう再配置するかという「経営側の意志」がそもそもない状態であれば、いくら現場が工数削減を提案しても「でも実際に人は減らないよね」と一蹴されて終わるだけです。ITマネージャーは発注元である経営層が何を望んでいるのかを掴み、その解決策としてITを提案する「クライアントワーク」の視点を持つ必要があります。

ウォーターフォール原理主義を突破する「小さく作って現物を見せる」戦術

言語が通じない相手に「アジャイル」の概念を説明するのは時間の無駄

「アジャイルでのアプローチの際、事前に詳細計画を作って遵守することしか認めないウォーターフォール原理主義の人へ、どう説明すればよいか」という問いに対し、原田氏は「諦めの境地も必要だ」と語ります。

そもそもアジャイルの思想やメリットを理解していない人に対して、口頭や資料だけでいくら説明しても共通言語がないため伝わりません。それは例えるなら、「川で洗濯をしている人に向かって、電気洗濯機を持っていけばこんなに便利になりますよと説明しても、なんじゃそりゃと言われる」のと同じ状態です。

自分が決済できる小さなコストの範囲で、勝手に作って「現物」を見せる

説明しても分からない相手を説得する唯一の方法は、「説明を省略し、先に現物を作って見せてしまうこと」です。

わざわざ大きな予算申請をせず、自分が部長職などの立場で決済できる「ちっちゃなコストの範囲内」で、アジャイルの良さを活かしてチャチャッと動くプロトタイプ（アウトプット）を作ってしまいます。そして、「現物」を相手の前に持って行き、「こんなものを作ってみました。もしこれを最初からガチガチのウォーターフォールで要件定義からやっていたら、3倍の時間とコストがかかっていましたよ」と、結果を突きつけるのです。

人間は、実物を見ないとその価値を理解できません。特に、新規事業の立ち上げや撤退を繰り返してきたような野生の勘がある経営層や役員であれば、動く現物を見た瞬間に「あ、なるほどね、こういうことか」と本質を掴んでくれます。社内でITを売り込むためには、ITリーダー自身の「営業能力（社内調整・マーケティング力）」が極めて重要であり、説明能力のない上司の下にいるメンバーは、いつまでも古い開発手法に縛られて疲弊することになります。

kintone導入期に潜む「秘伝のタレ（野良アプリ）」を統制する「みんなの目」

ファイルサーバーの奥底に眠る「伝説のアクセス」よりは遥かにマシ

「内製化（市民開発）が進むと、稟議を通す必要のない業務上重要なシステムが現場で大量に作られてしまうが、どうガバナンスをかけるべきか」という、ローコード・ノーコードツール導入企業が必ず直面する課題について、宮西氏がkintoneを例に解説します。

現場がkintone等でチャチャッと作ったアプリが、いつの間にかその事業部のコア業務（秘伝のタレ）になってしまうケースは多々あります。しかし、これらはかつての「ファイルサーバーの奥底に眠る秘伝のExcelマクロ」や「誰が作ったか分からない伝説のAccess（アクセス）」に比べれば、遥かに管理が楽です。

なぜなら、kintoneのようなローコードプラットフォームであれば、どれだけ現場が好き勝手にアプリを作っても、「少なくとも会社で契約している1つのテナント（環境）の中にすべてが存在しているから」です。情シス側で定期的に棚卸しを行い、「中で似たようなアプリが乱立していないか」を把握することはシステム的に可能です。

隠すから野良化する。あえて「全社公開」して相互監視の体制を作る

オルガノ株式会社で実際にkintoneの全社展開を主導した原田氏は、ガバナンスを効かせるための具体的な工夫として、「現場が作ったアプリを、あえて最初から『全社公開』の状態にして、隠せないようにしている」と明かします。

秘伝のマクロが恐ろしいのは、個人のデスクトップや特定のフォルダの中に隠され、他人の目に晒されないからです。最初からすべてをオープンにし、誰がどんなアプリを作ったかを見える状態にしておけば、開発者同士で「それ、隣の部署のアプリと機能が被っているよ」「一緒にくっつけてもっといいものにしようよ」という自発的なコミュニケーションが生まれます。

厳格な社内ルールやガバナンス規定をいくら綺麗に作っても、現場は守りません。統制（ガバナンス）をかけるために最も効果的なのは、ルールによる縛りではなく、「可視化（オープン化）をキープし、『みんなの目』による相互監視を効かせること」です。この体制づくりこそが、内製化の無駄を省くための本質的なアプローチとなります。

経営層の目をセキュリティに向ける泥臭い戦術：「小さな事故で、あえて少し血を流させる」

「リテラシーが低い」と仲間内で愚痴を言う前に、彼らの言葉で喋る努力をせよ

「経営者のITリテラシーが低く、情報セキュリティに興味がない場合、稟議の前に話が通じない。経営層の意識を変える良い方法はあるか」という問いに対し、宮西氏はIT部門が陥りがちな傲慢さに釘を刺します。

IT部門の人間は、すぐに「現場のリテラシーが低い」「経営層のリテラシーが低い」という言葉を使いたがります。しかし、経営層や現場はITの専門家ではないため、リテラシーが低くて当然です。専門家ではない人たちにもしっかりと伝わる「みんなの言葉（ビジネスの言葉）」に翻訳して伝えることこそが、IT部門の本来の役割です。ITの仲間内だけで集まって専門用語で喋り、「これが理解できない経営層はダメだ」と切り捨てていては、いつまで経っても信頼関係は築けません。

日常の些細なインシデントを「あたかも大事件」のように報告する

原田氏は、オルガノの未来のビジョンを達成するために、あえて自分が「悪者」になって社内のIT知識を底上げするポジションを取っています。その原田氏が、経営層の目線をセキュリティに強制的に向かせるために実践している、非常に泥臭いリアルな戦術が「小さな事故を大きく扱うこと」です。

工場や日常の業務の中で、実害がほぼゼロに近いような「小さなセキュリティの事故やミス（インシデント）」は、探せばいくらでも転がっています。それを単に「問題ありませんでした」と処理するのではなく、「あたかも大事件が起きたかのように」大げさに経営層へレポートするのです。

「言い方は良くないですが、あえて少し『血を流させる』というか、小さな怪我を体験させるんです。そうすることで初めて、経営層は『お、これはやばいな、真面目に対策を考えないといけないな』と、こちらに目線を向けてくれるようになります」

経営層に対して「セキュリティは大切です」と正論（太陽アプローチ）を100回唱えるよりも、1回の具体的な危機の疑似体験（北風アプローチ）を与える方が、圧倒的に早く意識を変えることができます。正解のテンプレートなど存在しません。自社の文化や経営層のキャラクターに合わせて、こうした泥臭い戦術を使い分ける覚悟がITリーダーには求められます。

クラウド（SaaS）導入の新基準：迷ったら「デファクトスタンダード（大樹の陰）」を選べ

スモールスタートで実績を作り、それをベースに広げるための稟議を書く

月額課金のクラウド（SaaS）サービスが一般的になった現代における、従来のオンプレミス導入時との「稟議・判断基準の違い」について、宮西氏が解説します。

かつてはバカでかいサーバーの初期費用に何千万円もかけて一発勝負の開発をしていましたが、SaaSの最大のメリットは「初期費用を抑えて小さく（数人規模で）始められること」です。

費用対効果を説明するための稟議を通したければ、まずは課長や部長の決済権限の範囲内（稟議のいらない金額）で、5人〜10人程度の極小規模で勝手に契約して使い始めてしまいます。そこで「明らかに業務が楽になった」という現物の実績（エビデンス）を作り、それをベースにして「これを全社100人に広げたら確実にこれだけの効果が出ます」という、勝てる稟議書を書く。これが、現代のSaaS導入における最もスマートな進め方です。

ユーザーコミュニティの活発さが、サービスの寿命と機能追加を担保する

また、クラウドサービスを選ぶ際の具体的な判断基準として、宮西氏は「ユーザーコミュニティが発達しているかどうか」を重視しています。

せっかく良いサービスだと思って導入しても、半年後や1年後にベンダー側が「サービス終了」を発表してしまい、移行コストで大ダメージを負うリスクは常にあります。Salesforce（セールスフォース）のように、ユーザーコミュニティが活発で情報がネットに溢れているツールは、それだけ多くの企業に「絶対に生きて使われている」という強力な証拠になります。ユーザー数が多ければベンダーにお金が回り続けるため、サービス終了のリスクが低いだけでなく、今後の機能追加やアップデートも高頻度で行われます。

製造業にとって、ITシステムそのものは「守りの常設的なインフラ」であり、そこで他社と尖った差別化をして金を稼ぐ必要はありません。「迷ったらデファクトスタンダード（業界の標準製品）を使って大樹の陰に隠れておく」のが、最も手堅く失敗のないクラウド選定の基準です。

まとめ：いつでも会社を辞められる「市場価値」が、経営と対等に戦う武器になる

心が折れそうになったときの乗り越え方として、宮西氏は「気心の知れた同業者と美味しいお酒を飲んで一晩で忘れること」を挙げ、原田氏は「いざとなったら辞めたるわ。俺は水処理の技術があるからどこでも食っていけるよ、という心意気をどこかに持っておくこと」を挙げました。

中野氏もこれに強く同意し、「最悪、別の会社に行っても構わないという自分の市場価値（スキル）の準備ができている人ほど、会社に依存せず、経営層に対しても忖度なく、本当に正しいIT投資の提案（良い仕事）ができる」と締めくくりました。

会社の理念や古い文化に共感できず、自分の意見も通らない環境で、「住宅ローンがあるから」「家族がいるから」と、ただ最小限の仕事だけをこなしてしがみついている人間は、近い将来、間違いなく生成AI（ChatGPT等）に仕事を奪われて淘汰されます。

自社の情シス部門やIT組織が「稟議が通らないカオス」に陥っていると感じるリーダーは、小手先の稟議テクニックを磨く前に、まずは自分の言葉をビジネスの言葉に変え、小さく現物を作って会社を動かす、そんな「諦めの悪い挑戦」から始めてみてはいかがでしょうか。

動画インデックス

・Q&A
　-Q1：（1）費用対効果の見せ方（2）システムで工数削減をしても、人を解雇するわけではないので会計上で見えるコスト削減にならないわけですが、財務効果の説明を求められます。こんな時の対応例をお聞きしたいです。（3）アジャイルでのアプローチの際に、「詳細計画を事前に作って遵守」という考え方のみしかない方々にどう説明すればいいか悩んでいます。【00:01:15】

　-Q2：内製化が進むと「稟議を上げる必要のない業務上重要なシステム」が大量に作られます。どうやってガバナンスをかけていますか？【00:12:35】

　-Q3：そもそも経営層のITリテラシーが低かったり、情報セキュリティに興味がなかったりした場合、稟議書以前に話が通じません。 社内の情報セキュリティ教育によるITリテラシーの底上げや、情シスで完結していたセキュリティインシデントの周知が効果的かと考えていますが、それ以外に経営層の意識を変える良い方法があればお教えください。【00:16:47】

　-Q4：最近はSaaSのような月額課金のクラウドサービスが一般的になっています。従来型のシステムを導入する時と稟議書を通す上で気をつけることがありますか？ また、そもそもクラウドサービスを導入する際の判断基準が自分の中で漠然としており、登壇者の方々が気をつけていることがあればお教えください。【00:22:43】

　-Q5：登壇者のお二人に質問です。心が折れそうになった時はどのように乗り越えていますか？【00:26:12】

　-Q6：会社の理念、文化に共感できない場合は（1）最小限のことをやってあとは好きなことをする（2）会社を去る——のどちらを選べばいいと思いますか？【00:28:32】

登壇者プロフィール