脱Excelを1人で決めない。チーム体制での移行先選定・承認フロー

ひとり情シスの時代、脱Excelの移行先を決めるのは基本的に1人の判断でした。良くも悪くも、自分が良いと思ったツールを選び、必要なら経営者に一言説明すれば導入が進む。この身軽さは、30〜100人規模までは大きな強みでした。しかし社員が100人を超え、情シスチームが2〜3人体制になると、この「1人で決める」やり方は機能しなくなります。担当者Aが良いと判断したツールを、担当者Bが後から知って「なぜ相談なく決めたのか」と感じる。あるいは、実際に導入した後になって、別のメンバーが検討していた候補のほうが優れていたと分かる。こうした事態は、チームとしての意思決定プロセスが未整備なまま人数だけが増えたことが原因です。このガイドでは、複数人が関わる移行先選定において、誰がどの段階で関与し、どのように承認していくかのフローを解説します。

この記事で分かること

100〜300人規模の情シスチームが、脱Excelの移行先をチームとして選定・承認するための意思決定プロセスを扱います。個々の移行先候補の比較検討方法（kintoneかSaaSかなど）そのものは扱いません。技術的な選択肢の比較はExcelのデータベース化入門: Access・SQL・SaaSどれを選ぶに譲ります。

なぜ「1人で決める」から卒業する必要があるのか

ひとり情シスの時代に1人で意思決定できていたのは、判断に必要な情報も、判断の結果責任も、すべて1人に集約されていたからです。複数人体制になると、この前提そのものが崩れます。メンバーそれぞれが異なる部署とのやり取りを担当し、異なる情報を持っている状態では、1人だけの判断で決めた移行先が、実は他のメンバーが把握している別の事情と食い違っている、ということが起こりやすくなります。

• 担当者Aが良いと判断したSaaSが、実は担当者Bが以前に別部署で導入を試みて失敗した経緯のあるツールだった
• 移行先の選定に関わっていなかったメンバーが、後から利用部署への説明を求められ、十分に答えられない
• 決定の経緯が記録されておらず、後から「なぜこのツールを選んだのか」を説明できない

これらの問題は、意思決定プロセスに欠陥があるというより、「複数人が関わっているのに、1人だけで決める体制のまま」というミスマッチから生じています。チーム体制に見合った意思決定フローへ切り替えることが、この規模で必要になってくる整備の一つです。

意思決定フローの基本形: 5つのステップ

チーム体制での移行先選定は、次の5つのステップに分けて進めることをお勧めします。ステップを分けることで、どの段階で誰が関与すべきかが明確になり、後から「聞いていなかった」という食い違いを防げます。

1. 要件整理: 何を解決したいのか、業務要件を整理する段階。要望元の部署からのヒアリングを含む
2. 候補の洗い出し: 要件を満たしうる移行先候補を複数リストアップする段階
3. 比較検討: 候補ごとにコスト・機能・導入難易度などを比較する段階
4. チーム内合意: 情シスチーム内で候補を絞り込み、推奨案を固める段階
5. 承認・意思決定: チームの推奨案を、決裁権者（情シス責任者や経営層）に諮り、最終承認を得る段階

この5段階を意識的に踏むことで、「なぜこのツールになったのか」を各段階の記録から説明できる状態を保てます。特に、後から異動・入社してくるメンバーにとって、過去の意思決定の経緯が記録として残っていることは、業務理解の助けになります。

要件整理の段階で担当者を1人に絞らない

要件整理の段階でよくある失敗は、要望元の部署とのやり取りを1人の担当者だけに任せてしまうことです。ひとり情シスの時代であれば必然的にそうなりますが、チーム体制になった以上、少なくとも要件整理の内容はチーム全体で共有できる形にしておく必要があります。

具体的には、ヒアリングした内容を口頭やチャットの個別メッセージだけで済ませず、要件一覧として文書化し、チームメンバー全員がアクセスできる場所に保存することをお勧めします。この要件一覧が後の候補比較の土台になるため、ここで漏れがあると、後の段階で「実はこの要件も満たす必要があった」という手戻りが発生しやすくなります。

要望元の部署が複数ある場合、それぞれの部署から寄せられる要望に優先順位をつける必要も出てきます。この優先順位付けについては、複数部署の脱Excel要望を同時に抱えたときの優先順位付けで詳しく扱っていますので、要件整理と合わせて参照してください。

比較検討: 主観を混ぜないための比較表

候補の比較検討を進める際、メンバーそれぞれが個別に「このツールが良いと思う」という主観的な印象だけで議論を進めると、声の大きい人の意見が通りやすくなり、チームとしての納得感のある結論に至りにくくなります。比較表を用意し、各候補を同じ基準で評価することをお勧めします。

• コスト: 初期費用・月額費用・ユーザー数課金の有無
• 機能要件との適合度: 要件整理で洗い出した項目をどの程度満たすか
• 導入・移行の難易度: 既存データの移行のしやすさ、社内への展開のしやすさ
• 運用の負荷: 導入後、情シス側でどの程度の運用工数がかかりそうか
• 拡張性: 将来的に利用範囲や利用部署が広がった場合に対応できるか

比較表を作成したら、チームメンバー全員でレビューする時間を設けます。この際、「なぜこの評価点になったのか」の根拠も併記しておくと、後から見返した際にも判断の妥当性を追跡できます。

「以前は担当者それぞれが個別にツールを調べて『これがいいと思う』と持ち寄るだけでした。今は同じフォーマットの比較表に全員が記入してから議論する形にしたので、感覚的な好みではなく要件との適合度で議論できるようになりました」

チーム内合意の取り方: 全員一致を目指さない

チーム内での合意形成において、全員が完全に同じ意見になることを目指す必要はありません。むしろ、全員一致にこだわりすぎると、意思決定そのものが停滞するリスクがあります。実務上は、次のような進め方が現実的です。

1. 比較表をもとに、各メンバーが推奨する候補とその理由を表明する
2. 意見が分かれた場合、その理由を掘り下げる（単なる好みの違いか、見落としていた要件の違いか）
3. 議論を尽くした上で、最終的な推奨案を決める役割（情シスチームのリーダーなど）を明確にしておき、その人物が結論を出す

この3番目のステップが重要です。「みんなで話し合って自然に決まる」ことを期待すると、意見が割れたときに議論が長引き、判断のスピードが失われます。あらかじめ「最終的に誰が決めるか」を決めておくことで、議論を尽くした後にスムーズに結論へ到達できます。これは担当分担の設計とも関係しており、兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方で扱っている役割分担の考え方とも整合させておくとよいでしょう。

承認・意思決定: 決裁権者への説明資料を用意する

チーム内での合意が固まったら、最終的な承認を決裁権者（情シス部門の責任者、経営層など）に諮ります。この段階で重要なのは、チーム内での議論の経緯をそのまま持ち込むのではなく、決裁権者が短時間で判断できるよう整理した説明資料を用意することです。

説明資料には、少なくとも次の要素を含めることをお勧めします。

決裁権者がITに詳しくない場合も多いため、専門用語を避け、業務への影響とコストという、経営判断に必要な観点を中心にまとめることが、承認をスムーズに得るためのポイントです。稟議のような形式で提出する場合の書き方については、稟議の考え方も参考にできます。

承認後の記録を残す

承認が得られたら、その決定内容と経緯を記録として残しておきます。この記録は、単に「承認された」という事実だけでなく、比較検討の過程、選ばれなかった候補とその理由まで含めて残しておくことをお勧めします。

理由は、後になって「なぜあのツールを選ばなかったのか」という疑問が出た際、記録があれば都度説明する手間を省けるためです。特に、担当者の異動・退職が発生した後にこの疑問が出ると、経緯を知っている人がいなくなり、答えられなくなるリスクがあります。この記録の保存場所や更新の仕組みは、100人を超えたら属人化台帳をどう運用に乗せるかで扱う台帳の運用と一体化させておくと、資料が分散せずに済みます。

意思決定フローが形骸化しないための注意点

意思決定フローを整備しても、実際の運用で形骸化してしまうことがあります。よくある形骸化のパターンとして、次のようなものが挙げられます。

• フローの手順は決まっているが、実際には特定のメンバーが独断で決めてしまい、他のメンバーは事後報告を受けるだけになっている
• 比較表を作る工程が形式的な作業になり、実質的にはすでに決まっている結論に合わせて後付けで数字を埋めている
• 承認プロセスが重すぎて、小規模な移行案件でも大規模案件と同じ重厚な手続きを踏まなければならず、現場が疲弊する

これらを防ぐには、案件の規模に応じてフローの重さを調整する柔軟性を持たせることが有効です。例えば、費用が小さく影響範囲が限定的な移行であれば、比較検討とチーム内合意までを簡略化し、承認も口頭の確認で済ませるといった軽量版のフローを用意しておくと、フロー自体が形骸化することを防げます。

小規模案件と大規模案件でフローを使い分ける基準

意思決定フローを形骸化させないための工夫として、案件の規模に応じてフローの重さを変える運用を紹介しましたが、実際にどの程度の基準で使い分けるべきか、もう少し具体的に整理しておきます。

この基準はあくまで目安であり、会社の規模や予算感に応じて調整する必要があります。重要なのは、「この金額・影響範囲を超えたら重いフローに切り替える」という線引きを、あらかじめチーム内で合意しておくことです。線引きが曖昧なままだと、案件ごとに毎回「今回はどの程度のフローで進めるべきか」を議論することになり、かえって非効率になります。

意思決定の記録を後任へどう引き継ぐか

チームでの意思決定フローが機能していても、その記録の引き継ぎが不十分だと、担当者が異動・退職した際に「なぜこの選定になったのか」という経緯が失われてしまいます。特に、比較検討で「選ばれなかった候補」の情報は、選ばれた候補の情報よりも記録として残されにくい傾向があります。

• 意思決定の記録は、結論だけでなく比較検討の過程も含めて、個人のメモではなくチーム共有の場所に保存する
• 新しくチームに加わったメンバーには、オンボーディングの一環として、過去の主要な意思決定の記録を一通り確認してもらう機会を設ける
• 記録のフォーマットは、引き継ぎ書と同じ骨格（前提・経緯・結論・理由）を使うと、読み手にとって一貫性のある資料になる

このような記録の引き継ぎは、個々の意思決定の質を高めるだけでなく、チーム全体の意思決定能力を蓄積していくことにもつながります。同じような検討を一からやり直すのではなく、過去の記録を土台に、より速く、より精度の高い判断ができるようになっていきます。

意思決定フローと現場の納得感

意思決定フローを整備する目的は、手続きを厳格にすること自体ではありません。最終的に目指すべきは、決定した移行先について、要望元の部署を含めた関係者が「妥当な判断だった」と納得できる状態です。

どれだけ丁寧なフローを踏んでも、決定の背景が要望元の部署に伝わらなければ、「勝手に決められた」という不満は解消されません。承認後は、決裁権者への説明資料をベースに、要望元の部署にも簡潔に経緯を共有することをお勧めします。特に、要望元が期待していた要件と実際の選定結果にギャップがある場合は、そのギャップが生じた理由を丁寧に説明することで、後々の不満を防げます。

意思決定フローにおける外部ベンダーの扱い方

移行先の候補比較には、SaaSベンダーや開発会社への問い合わせ・見積もり取得が伴うことも多くあります。この外部とのやり取りをチーム内でどう分担するかも、意思決定フローの一部として整理しておくべき論点です。

• 問い合わせ窓口を1人に統一する: 複数のメンバーがそれぞれ個別にベンダーへ問い合わせると、ベンダー側に伝わる要件がずれたり、二重の対応でベンダー側を混乱させたりすることがある
• ベンダーとのやり取りの記録をチームで共有する: 窓口担当者が把握している情報を、他のメンバーも参照できる状態にしておく
• 見積もりや提案内容の評価は、窓口担当者だけでなくチーム全体で行う: 窓口担当者がベンダーとの関係の中で特定の提案に肩入れしてしまうことを避けるため、評価は比較表を用いて客観的に行う

外部ベンダーとのやり取りは、社内の意思決定プロセス以上に、担当者個人の裁量に委ねられがちな領域です。複数人が関わるチーム体制だからこそ、この部分もフローの一部として明確にしておくことで、特定の個人の判断だけに依存しない意思決定が可能になります。

意思決定の「やり直し」が発生した場合の対応

丁寧にフローを設計しても、実際に導入を進めた後で「想定していた要件を満たせていなかった」「別の候補のほうが適していたと分かった」というやり直しが発生することはあります。これ自体は避けられないリスクですが、やり直しが発生した際の対応の仕方によって、チームへの影響は大きく変わります。

1. やり直しが必要になった原因を、個人の責任追及ではなくプロセスの改善点として振り返る: 「誰が間違えたか」ではなく「どの段階で見落としが生じたか」を確認する
2. 同じ見落としが繰り返されないよう、意思決定フローの手順そのものを見直す: 例えば、要件整理の段階で特定の観点が抜けやすいと分かれば、要件一覧のテンプレートにその観点を追加する
3. やり直しの経緯も、通常の意思決定と同様に記録として残す: 失敗の経緯を記録しておくことは、将来同様の判断をする際の重要な参考資料になる

意思決定フローを整備する目的は、失敗を完全にゼロにすることではなく、失敗が起きた際にもチームとして学び、次に活かせる状態を作ることにあります。この視点を持っておくことで、フロー自体が硬直化することなく、実態に合わせて継続的に改善されていきます。

小さな成功体験を積んでフローへの信頼を築く

意思決定フローを新たに導入した直後は、チームメンバーの間でも「本当にこの手順を毎回踏む必要があるのか」という懐疑的な反応が出ることがあります。この懐疑を払拭する最も効果的な方法は、理屈で説得することよりも、実際にフローを通じて良い結果が得られた事例を積み重ねることです。

• 最初は比較的小規模で分かりやすい案件からフローを適用する: いきなり大規模な基幹システムの選定から始めると、フローの重さが負担として先に感じられてしまう
• フローを通じて得られた良い結果（後戻りが少なかった、部署から好意的な反応があったなど)を、チーム内で振り返る機会を設ける: 成功体験を言語化して共有することで、フローの有効性がチームの実感として定着する
• フローに従わずに進めた結果、問題が生じた事例があれば、それも合わせて振り返る: 比較することで、フローを踏む意義がより明確になる

このように、小さな成功体験を積み重ねていくことで、意思決定フローは「上から押し付けられた手続き」ではなく、「自分たちの判断の質を高めてくれる仕組み」としてチームに根付いていきます。

リモート・ハイブリッド環境での合意形成の工夫

拠点が複数あったり、リモートワークを併用しているチームの場合、意思決定フローの各ステップを対面で完結させることが難しい場合があります。この場合、非同期のコミュニケーションを前提にフローを設計する工夫が必要になります。

• 比較表やレビューのコメントは、非同期でも進められるようオンライン上の共有ドキュメントで行う: 全員が同じ時間に集まらなくても、それぞれのタイミングで意見を記入できるようにする
• 合意形成のための議論は、必要な場合のみ同期的な会議を設定する: すべてのやり取りを会議にすると日程調整だけで時間がかかるため、非同期で解決できる部分と、会議が必要な部分を切り分ける
• 意思決定の締め切りを明確に設定する: 非同期のやり取りは、締め切りを設けないと議論がだらだらと長引きやすい。「いつまでに意見を出してほしいか」を明示する

このような工夫を取り入れることで、拠点やリモートワークの制約があっても、チームとしての意思決定フローを機能させ続けることができます。

意思決定フローと予算計画の連動

移行先の選定は、多くの場合、年間の予算計画とも密接に関わります。意思決定フローを単独で運用するのではなく、予算計画のサイクルと連動させておくことで、承認を得やすくなるだけでなく、複数の移行案件を全体最適の視点で優先順位づけしやすくなります。

• 年間予算の検討時期に合わせて、翌年度に想定される移行案件を一覧化しておく: 個別の案件ごとに単発で予算を申請するより、年間を通じた計画として示すほうが、決裁権者にとって判断しやすい
• 予算の制約から、複数の移行案件に優先順位をつける必要が生じた場合、意思決定フローの比較検討の結果を活用する: 個々の案件についてすでに整理された情報があれば、予算配分の議論もスムーズに進む
• 期中に想定外の要望が発生した場合の予備予算について、あらかじめ方針を決めておく: 年度当初には想定していなかった移行案件が期中に発生することは珍しくないため、一定の柔軟性を予算計画に持たせておく

このように、意思決定フローを単発の技術的な検討としてではなく、組織全体の予算計画・経営判断のサイクルの一部として位置づけることで、フロー自体の実効性もより高まります。

トライアル導入をフローに組み込む

移行先の候補が複数残り、比較検討だけでは決めきれない場合、本格導入の前に小規模なトライアル導入を挟むという選択肢も、意思決定フローの一部として組み込んでおくと有効です。

• 候補が2つ程度に絞られた段階で、それぞれ限定的な範囲でトライアル導入を実施する: 一部の部署やチームだけで実際に使ってみることで、比較表だけでは見えなかった使い勝手の違いが明らかになる
• トライアルの評価基準をあらかじめ決めておく: 何をもって「良い」「悪い」と判断するかが曖昧なまま試すと、トライアル後の議論がまた振り出しに戻ってしまう
• トライアル期間は短めに区切る: 長期間のトライアルは、その間の意思決定自体が停滞する原因になる。数週間程度の期間で、必要な情報が得られる設計にする

トライアル導入は、すべての案件で必須というわけではありません。費用や影響範囲が大きく、判断を誤った際のやり直しコストが高い案件について、選択的に取り入れることをお勧めします。小規模な案件にまでトライアルを課すと、かえって意思決定のスピードを損なう結果になります。

意思決定フローの成熟度を段階的に上げていく

チーム体制での意思決定フローは、最初から完璧な形で導入する必要はありません。むしろ、チームの規模や経験に応じて、段階的にフローの精度を上げていくという発想のほうが、現実的に定着しやすいことが多くあります。

• 初期段階では、最低限「複数人でレビューする」というステップだけを徹底する: 5段階すべてを厳密に運用しようとすると、導入初期のチームには負担が大きすぎる場合がある
• 運用に慣れてきた段階で、比較表のフォーマットや評価軸を精緻化していく: 実際に何度か意思決定を経験する中で、どのような評価項目が本当に重要だったかが見えてくる
• チームの人数が増えるにつれて、承認プロセスの階層も見直していく: 2〜3人体制のときと、さらに人数が増えた段階とでは、適切な承認の重さも変わってくる

フローを完成形として最初から目指すのではなく、チームの成熟度に合わせて育てていくものと捉えることで、無理のない導入と定着が可能になります。

意思決定フローを支えるコミュニケーションの土台

これまで述べてきた5つのステップや承認の仕組みは、あくまで「型」であり、その型を実際に機能させるのは、チームメンバー同士の日頃のコミュニケーションです。意思決定の場面だけ急にオープンな議論をしようとしても、普段からの信頼関係が乏しければ、形式的なやり取りに終始してしまいます。

• 日常的な業務の中で、お互いの担当領域の状況を共有し合う習慣を持つ: 意思決定の場面になって初めて他のメンバーの状況を知る、という状態を避ける
• 異なる意見が出たときに、それを対立ではなく検討材料として歓迎する雰囲気を作る: 意見の相違を恐れて発言を控えるようになると、比較検討の質そのものが下がる
• 小さな意思決定の場面から、フローに沿った進め方を実践し、慣れていく: 大きな案件でいきなり型どおりに進めようとするより、日常の小さな判断から練習しておくほうが定着しやすい

意思決定フローは、手順書やテンプレートを整備するだけで自動的に機能するものではありません。それを使う人たちの関係性そのものが、フローの実効性を最終的に左右します。

まとめ: フローの目的は「後から説明できる状態」を作ること

チーム体制での移行先選定・承認フローを整備する最大の目的は、意思決定のスピードを落とすことではなく、「なぜこの選択をしたのか」を後から誰でも説明できる状態を作ることにあります。1人の判断で決めていた時代には存在しなかったこの説明責任は、複数人が関わる規模になった以上、避けて通れないものです。

要件整理・候補の洗い出し・比較検討・チーム内合意・承認という5つのステップを意識的に踏み、それぞれの段階での記録を残す。この積み重ねが、100〜300人規模の情シスチームが、場当たり的な判断から抜け出し、組織として信頼される意思決定プロセスを持つための土台になります。