SAPコンサルがしんどい・やめたいと思ったとき｜重いのはどの工程かと、辞めた先にある三つの行き先

「SAPコンサル しんどい」と検索する人が、何を知りたいのかを考えました。おそらく、しんどさの共感でも、根性論でもない。このしんどさが、いつまで続くものなのかを知りたいのだと思います。

私はSAPのFI（財務会計）を軸にコンサルティングをしてきて、独立して6年目です。事業会社の導入案件も、稼働後の保守も、途中から入る火消しも見てきました。そのうえで言えるのは、SAP案件のしんどさは案件全体に均等に散らばっていないということです。工程で割ると、はっきり山があります。

山の位置が分かると、いま自分が坂の途中なのか、頂上なのか、下りに入ったのかが判断できる。この記事は、それを工程の名前で書きます。コンサルという仕事一般のきつさについてはコンサルがきついと言われる理由に別に書いたので、そちらは職種としての話として読んでください。

しんどさは、工程ごとに種類が違う

SAPの導入案件は、だいたいこの順で進みます。呼び方はプロジェクトによって違いますが、並びはほぼ共通です。

1. 構想・現状調査
2. 要件定義（Fit&Gap／Fit-to-Standard）
3. 基本設計・詳細設計
4. 開発・アドオン実装
5. 単体テスト・結合テスト
6. 受け入れテスト（UAT）
7. データ移行リハーサル
8. 本番稼働（カットオーバー）
9. 稼働直後の支援（ハイパーケア）
10. 保守・次フェーズ

太字にした4つに、負荷が寄ります。それも、前半のしんどさとは種類が違う寄り方をします。

前半は「進まないしんどさ」、後半は「間に合わないしんどさ」です。同じ言葉で語ると対処を間違えます。

前半のしんどさは、「決まらない」

要件定義から設計にかけて、何がしんどいのか。技術ではありません。決める人が決めないことです。

現場のヒアリングでは「今のやり方を変えたくない」と言われ、上からは「標準に寄せろ」と言われる。両方を満たす案は存在しないので、どちらかを誰かが決める必要があるのに、その誰かが会議に出てこない。持ち帰りが増え、同じ論点が三度戻ってくる。

このとき削られているのは体力より気力です。作業量そのものは後半ほどではないのに、疲れ方が大きい。理由は、自分の努力で前に進まないからだと思います。

そして厄介なのは、ここで決まらなかったものが消えないことです。決まらなかった論点は、そのまま後工程に持ち越されて、受け入れテストで一気に噴き出します。前半の「待ち」は、後半の「山」に変換されて戻ってくる。これがSAP案件の構造です。

前半のしんどさは、いま辛いだけでは終わらない。決まらなかった分だけ、受け入れテストの山が高くなる。

だから、前半で本当に効く手は「頑張って作る」ではなく、決まっていないことを、決まっていないと見える形にして残すことです。議事録の宿題欄でも課題管理表でもいい。後半で「聞いていない」が起きたときに、山の高さがそれで変わります。

SAPの仕事の中身そのものについてはSAP FIコンサルの仕事内容に、モジュールごとの違いはSAPモジュールの選び方に書いています。

後半のしんどさは、「間に合わない」

受け入れテストで、初めて現場が触る

受け入れテスト（UAT）は、業務部門が自分の目でシステムを触る最初の場面です。ここで何が起きるか。それまで文書の上で合意していたものが、初めて実物として現れます。

そして、かなりの確率で「これ、思っていたのと違う」が出ます。悪意ではありません。設計書の日本語と、画面に出る実物は、別のものだからです。

ここが山になる理由は3つあります。

1つ目は、遅れの吸収先がここしかないこと。 設計や開発が押しても、本番稼働の日付は先に決まっています。押した分は、テストの期間から削られる。つまり、上流の遅れは全部この工程に集まります。

2つ目は、指摘の粒度がばらばらなこと。 「桁が違う」という重い不具合と、「ボタンの位置が使いにくい」という要望が、同じ一覧に同じ形で並びます。これを仕分けて、直すもの・運用で回すもの・次フェーズに送るものに分けるのが、この工程のいちばんの仕事です。作業ではなく判断なので、疲れます。

3つ目は、相手が本業を持っていること。 業務部門はテストのために雇われているわけではありません。月末が来れば締めがあり、テストは後回しになる。結果、テストの実施が期間の後半に固まり、指摘も後半に集中します。

移行リハーサルと、本番稼働

データ移行のリハーサルと本番稼働は、しんどさの種類がまた変わります。ここは判断ではなく、時間帯の問題です。

会計データの移行は、業務が止まっている時間にしかできません。だから作業は自然と、金曜の夜から月曜の朝までに寄ります。連休が使われることもある。技術的に難しいというより、生活が削られるというしんどさです。

しかも移行は一発勝負ではなく、リハーサルを何度か重ねます。1回目で残高が合わない、2回目で未決済の伝票が落ちる、3回目でようやく通る。そのたびに深夜が来る。

本当の山は、稼働後の「最初の月次決算」

ここを見落としている人が多いと思います。本番稼働の日そのものより、稼働してから最初の月次決算のほうが重い。

理由ははっきりしています。決算には外の締切があるからです。月次であれば翌月の数営業日、四半期なら開示の期日がある。システムが不安定でも、決算は延期できません。

そしてFI・COの領域は、数字が合うか合わないかしかない。販売や購買の一部の機能なら、暫定の運用でしのげる場面があります。でも残高が合わないと帳簿が締まらない。逃げ場がない。ここがSAPの中でも会計まわりの担当だけが背負う重さで、「SAPコンサルはしんどい」と言われるときの中身の、かなりの割合を占めていると思っています。

本番稼働はゴールではなく、いちばん高い山の入り口。稼働日ではなく、稼働後の最初の決算が終わるまでが1本の工程だと考えたほうがいい。

S/4HANAの案件で何が変わるかはS/4HANA案件の実際に、そもそもSAPコンサルという職種の輪郭はSAPとは何か・コンサルは何をするのかにまとめました。

工程ごとに、効く手と効かない手

しんどさの種類が違うので、打ち手も変わります。ここは実務的な話だけ書きます。

いちばん差が出るのは、受け入れテストの仕分けです。指摘を全部直そうとすると、稼働日までに終わらないだけでなく、直した副作用のテストがまた増える。「これは運用で回す」と言える人がいるかどうかで、その案件の後半の重さは倍くらい変わります。

そして、稼働直後に個人の携帯で問い合わせを受け始めると、その案件はその人が抜けられなくなります。しんどさが工程のものから、個人のものに変わる瞬間がここです。

そのしんどさは、工程由来か、体制由来か

ここからが、この記事でいちばん書きたかったところです。

工程由来のしんどさには、終わりがあります。 受け入れテストは終わるし、稼働後の最初の決算も終わる。3か月後には確実に軽くなる。

体制由来のしんどさには、終わりがありません。 人が足りない、決める人がいない、責任範囲が曖昧、といった状態は、工程が進んでも解消しない。むしろ次の案件でも同じことが起きます。

この2つを混ぜて「しんどい」と言っている限り、辞めるべきかどうかの判断はできません。見分けるための質問を3つ置きます。

1. いま重い作業に、終わる日付が付いているか。 付いているなら工程由来。「いつまでとは言えないが、とにかく忙しい」なら体制由来です。
2. 同じ問題が、前の案件でも起きたか。 起きているなら、案件ではなく会社の作り方の問題です。
3. 自分が休んだら、止まるか。 止まるなら、それは工程の負荷ではなく、体制の穴を人で埋めている状態です。

3つのうち2つ以上が体制由来を指しているなら、待っても軽くなりません。何歳まで続けられるかという話はSAPコンサルは何歳まで働けるかに書きましたが、年齢より先に、この見分けのほうが効きます。

「やめたい」と思ったとき、行き先は三つある

「しんどい」がしばらく続くと、次に出てくる言葉は「やめたい」です。このふたつは似ていますが、頭の中で起きていることは一段違います。しんどいは状態の言語化で、やめたいは出口を探し始めた合図です。

そして出口を探すとき、多くの人が「辞めるか、続けるか」の二択で考えます。実際には、行き先は三つあります。そして三つは、消えるしんどさと残るしんどさが、それぞれ違います。

順番に見ます。

社内異動が効くのは、しんどさが「工程由来」だった場合です。前の章の三つの質問で工程由来だと分かったなら、モジュールを変える、または導入フェーズから保守フェーズに回るだけで、負荷の形はかなり変わります。会社を出るコストを払わずに済むぶん、いちばん先に検討していい選択肢です。逆に、しんどさが体制由来だったなら、社内異動では動きません。上の人も評価の仕組みも、そのまま付いてきます。

**事業会社に移ると、締切の性質が入れ替わります。**プロジェクトの締切は無くなりますが、決算と監査の締切が来ます。しかもこちらは、毎年必ず、同じ時期に来る。「締切が減る」と思って移ると、話が違うと感じます。実際に変わるのは締切の量ではなく、同じ会社を何年も見続けられることのほうです。導入して去るのではなく、入れたものが五年後にどうなるかを自分で見る。ここに価値を感じるかどうかが分かれ目です。年齢と等級の線がどこで効くかはコンサルは何歳まで働けるのかに分けて書きました。

**独立で消えるのは、上と横の調整と、等級で決まる金額です。**残るのは稼働の谷と、営業も契約も請求も自分に返ってくること。そして受け入れテストや本番稼働の重さは、**独立しても一ミリも軽くなりません。**むしろ、その重い工程を一人で最後まで持てることが、発注する側から見た価値そのものになります。ここを勘違いすると、独立してから同じ場所でつまずきます。

三つに共通して残るものが、ひとつだけあります。期末と稼働のピークは、行き先を変えても来るということです。消えるのはピークではなく、「そのピークを、自分で選べないこと」のほうです。

戻りやすさも、書いておきます。社内異動は戻れます。事業会社からコンサルに戻る例も普通にあります。独立からも戻れますが、戻るときに効くのは独立した事実ではなく、独立期間に何を売ったかを説明できるかどうかです。この点は独立したあと、会社員に戻れるかに、独立して後悔する中身は独立して後悔するのは、辞めた日ではなく半年後に、それぞれ整理しました。

辞める・移る・独立するの判断を、山の中でしない

もう一つ。判断は、稼働のピークの中でしないほうがいい。

受け入れテストの最中や、稼働直後の決算の最中に「もう無理だ」と思うのは自然です。ただ、その時点で下した判断は、たいてい3か月後の自分の状況を織り込んでいません。睡眠が足りていない状態で、キャリアの選択をしないほうがいい。

現実的な順番はこうだと思います。

• 山の中では、記録だけ取る。 何がしんどかったのか、それは工程由来か体制由来か、日付と一緒に書き残す
• 山を越えて2週間たってから、読み返す。 記憶ではなく記録で判断する
• 判断は、次の案件が始まる前の谷で下す。 案件の途中で抜けるのは、自分の評判にいちばん効く

そのうえで独立を選択肢に入れるなら、見るべきは「しんどいかどうか」ではなく、一人で最後まで持てる工程を持っているかです。要件定義から稼働まで通しで見た経験があるか、決算の締めまで面倒を見たことがあるか。発注する側は、そこを見ています。

独立して実際どうなるかはSAPコンサルの独立の現実に、単価の考え方はSAPコンサルの単価に、踏み出す前に何が揃っていればいいかは独立の前提条件に、それぞれ分けて書いています。

まとめ

• SAP案件のしんどさは均等ではない。受け入れテスト・移行・本番稼働・稼働後の最初の決算に寄る
• 前半のしんどさは「決まらない」、後半は「間に合わない」。種類が違うので対処も違う
• 前半で決まらなかったものは消えず、受け入れテストの山の高さに変換されて戻ってくる
• FI・COが重いのは、決算という外の締切があり、数字は合うか合わないかしかないから
• 本番稼働の日ではなく、稼働後の最初の月次決算が終わるまでが1本の工程
• 受け入れテストで効くのは「全部直す」ではなく、直す・運用・次フェーズの仕分け
• しんどさが工程由来か体制由来かを、3つの質問で見分ける。工程由来には終わりがある
• 辞める・移る・独立するの判断は、山の中でせず、谷で下す

しんどさを人格の問題にすると、逃げ場がなくなります。工程の名前で言い直すだけで、終わりがあるものと、無いものが分かれる。まずはそこからだと思います。

いまの状態を工程の言葉で整理してみたい人は、30秒の独立準備診断も置いています。判断の材料に使ってください。