「一気にやるか、順番にやるか」で失敗が分かれる
刷新すべき対象がいくつも見えてくると、次に悩むのが進め方の順序です。受発注のシステム化、勤怠管理の見直し、古参ベンダーとの契約見直し——やりたいことが複数あるとき、それらを1つずつ片付けていくべきか、それとも同時並行で進めてしまってよいのか。
ここを見誤ると、逐次実行なら「いつまで経っても終わらない」、並行実行なら「どれも中途半端なまま現場が疲弊する」という、正反対の失敗に行き着きます。どちらを選ぶべきかは、気合いや意欲の問題ではなく、2つの資源——社内リソースと古参社員の許容量——がどれだけ残っているかで決まります。
見るべき2つの資源
刷新プロジェクトが1つ動くと、社内では見えにくい形で2種類の資源が消費されます。
社内リソースは、要件を整理する時間、ベンダーとのやり取りに割く人手、テストやフィードバックに付き合う現場の工数です。これは主に「時間」の制約です。
古参社員の許容量は、変化を受け入れられる心理的な余白です。1つのシステムが変わるだけでも、慣れた手順を崩される負担があります。これは「感情」の制約であり、時間をかければ回復するものの、社内リソースのように予定を組んで管理できるものではありません。
複数の刷新を同時に走らせるということは、この2つの資源を複数のプロジェクトで同時に消費するということです。どちらか一方でも余裕がなければ、並行実行は無理をした選択になります。
逐次実行を選ぶべきケース
次のいずれかに当てはまる場合は、1つずつ順番に進めるほうが安全です。
- 社内の担当者が兼任で、複数プロジェクトの窓口を同時にこなせない: 総務が経理と兼務でIT担当も背負っているような体制では、複数ベンダーとの並行対応そのものが物理的に無理です
- 過去に大きな変化があったばかり: 承継そのもの、あるいは直近の刷新プロジェクトで、古参社員がすでに変化疲れを起こしている
- 刷新の対象同士が業務でつながっている: 受発注と在庫管理のように、一方の仕様が固まらないと他方が決められない関係にある場合、無理に並行させても手戻りが増えるだけです
逐次実行の利点は、1つのプロジェクトに集中できることに加えて、最初の刷新の成功体験が次の刷新への抵抗を下げてくれる点にあります。最初の案件が現場に受け入れられれば、2つ目以降の説得は格段に楽になります。1件目と2件目の進め方に違いを持たせる視点は、2回目の刷新は、1回目とどう進め方を変えるべきかでも整理しています。
並行実行を選べるケース
逆に、次の条件が揃っているなら、複数の刷新を同時に進めても大きな混乱は起きにくいと言えます。
- 対象領域が完全に独立している: 経理システムの刷新と、営業のCRM導入のように、担当部署も業務フローも重ならない
- 各プロジェクトの窓口となる担当者が別々に確保できる: 1人が全部を抱え込む体制になっていない
- 古参社員への影響が部署ごとに分散している: 変化を受け入れる負担が、特定の1人や1部署に集中しない
この条件が揃うケースとして多いのは、ある程度の規模があり部署が分かれている会社です。逆に従業員10〜20人程度で、社長自身が実質的に全プロジェクトの窓口を兼ねているような会社では、対象領域が独立していても、社長個人の時間という一点で資源が競合してしまい、並行実行の恩恵を十分に受けられないことがあります。
判断を誤るとどうなるか
社内リソースが足りないのに並行実行を選ぶと、どのプロジェクトも中途半端な要件定義のまま発注してしまい、後になって「思っていたのと違う」という手戻りが複数同時に発生します。開発会社とのやり取りが後手に回り、追加開発の頼み方。小さな改修を安く早く進めるコツで本来避けられるはずの追加費用が積み重なることにもなりかねません。
逆に古参社員の許容量が十分あるのに、必要以上に慎重になって1つずつしか進めないと、刷新全体の完了が先延ばしになり、その間も非効率な業務が続きます。判断に迷う場合は、まず社内リソースの制約を優先して検討してください。感情面の許容量は事後にフォローできますが、物理的な時間の不足は後から取り戻せないためです。
まとめ
逐次か並行かの選択は、意欲ではなく資源の残量で決めます。担当者の兼任状況、直近の変化の有無、対象領域の独立性を確認し、社内リソースか古参社員の許容量のどちらかに不安があるなら、逐次実行を選んでください。両方に余裕がある場合に限り、並行実行で刷新のスピードを上げることを検討しましょう。