パスコーソフトウェア

育児まっただ中のSE(システムエンジニア)であるパスコーが経験するIT・子育ての現実を生々しくお届けするブログ

MENU

多重下請け構造の下流に組み込まれて経験した4つの課題と対応策

 

IT業界で問題視されている多重下請け構造

問題点(のごく一部)に関わることになってしまった不運。

突如として3次請けに組み込まれてしまった。

IT業界の闇と言われる多重下請け構造の中の人として

体験した課題を記していく所存だ。

多重下請け構造(タジュウシタウケコウゾウ)とは

顧客企業から仕事をもらった企業(元請け企業、一次請け企業とも言う。一般的に大手企業)が

受注した仕事をいくつかの仕事に分割する。

その分割した仕事の一部を中堅の企業に割り振りを行う。

 

仕事をもらった中堅企業(二次請けとも言う)は、その仕事を更に分割し

中小企業へ仕事の割り振りを行う。

仕事をもらった中小企業(三次請けとも言う)は、その仕事を更に分割し

零細企業へ仕事の割り振りを行う。

仕事をもらった零細企業(四次請けとも言う)は、その仕事を分割し

フリーランス(五次請けとも言う)などに仕事の割り振りを行う。

 

もちろん、全ての仕事が5次請け企業に割り振られるわけではなく、

途中で2次、3次、4次請けの企業が自社で対応する部分もある。

 このように複数回にわたり下請けに仕事を出していく状態を

多重下請構造(多重下請け構造と書く場合もある)と言っている。 

元請けから下請けにかけてピラミッド型の構造。

建設業界では大手ゼネコンを筆頭にこのような構造が見受けられる。

人生初、多重下請け構造に組み込まれたプロジェクトが開始

実は、パスコーはこれまで1次請けもしくは

2次請け(1次は伝票通すだけで実質1次請け)しか

経験をしたことがなかった。

 

この度、とあるソフトウェアメーカーからどうしてもと依頼されて

3次請けのオシゴトに関わることになった。

私の所属している企業から下請けには仕事を出さないので

多重下請構造の末端ということになる。

 

初めての下請の役割、どうなるのかなと心配しつつ

プロジェクトがスタートしたのが先日のこと。

多重下請け構造の問題点1:必要な期間より短い納期

いきなり直面したのは無駄に短い納期。

 

今回、オシゴトの依頼がきたきっかけとなるソフトウェアは

市場で多数のベンダーが取り扱っているものではなく

少しニッチなものである。

 

たまたま、そのベンダーの認定資格を持っていた

私のところへソフトウェアベンダー担当営業からヘルプの

お声がかかって(経過省略)引き受ける流れ。

 

ややニッチなソフトウェアなため

1次請け、2次請け企業はそのソフトウェアのことを

ほぼ知らない状況で、実質は丸投げに近い。

年度末目前の2月半ばスタートで、3末検収と言ってきた。

みっちり1ヶ月半はかかる想定だったので4月以降までもつれ込む想定だった。

受注時点でスケジュールがめちゃくちゃタイトだ。

打ち合わせの結果というか問答無用で要件定義・基本設計・詳細設計を

今すぐ終わらせろという話だった。

準備と設計で2週間は要する 想定だと伝えた。

 

が、ここで多重下請け構造の顕著な特徴が出た。

2次請けPMの発言

 6日目にはドキュメント一式出してください。

 7~8日目で弊社チェックします。

 9~10日目で1次請けチェックし、顧客に出します。

 

何もしないのに納期が短くなる!

(ソフトウェア自体知らなかったのに納期の40%持っていくのか)

 

レビュー・受入のチェックをしてもらうのは当たり前にしても、

ここまで当然のごとく削られるとは思っていなかった。

多重下請構造の課題、ここにあり。

対応策1:多重下請け構造に組み込まれるプロジェクトはバッファが必須

納期の交渉はしつつも10日かければ良い仕事を半分の

5日で終わらせて(6日目はバッファ)提出しなければならなくなった。

 

幸い、実はドキュメント類は過去のプロジェクトで

ある程度充実しているので対応は問題ない。

インターネットで多重下請構造は闇があると知っていたので

余裕があることを見せてはいけないと判断して必死であるように振る舞った。

(6日ですか?!なんとか、なんとか努めますと振る舞ってみた)

 

しかし1から検証したりドキュメント作成しなければならないとしたら

時間外の労働は必須になる。増員も検討しなければならないなど

プロジェクトスタート時点で、増員するか時間外勤務で

埋めるしか手がないなんてつらすぎる。

5次請けとかになると、この仕事を2日で仕上げろとか言われるのだろうか。

背筋が凍る。

 

下請として多重下請け構造のプロジェクトに関わる際には

本来必要な納期にバッファを積まざるを得ない。

ただし、納期は長めにとるものの工数自体は変わらないことは守りたい。

バッファでエンドユーザー価格が上がるのは本意ではないからだ。

 

多重下請け構造の問題点2:ひたすら詰められる

上位企業とのやりとりで、ひたすら詰められるという現象が発生した。

 

2次請け(以下、2)

 「例のドキュメント、6営業日目の提出をお願いしていましたが

  4営業日目には未完成でも良いので見せてください」

 

パスコー(以下、パ)

 「もともと8営業日はかかる想定なのでかなり厳しいです。

  なるべく努めます。」

 

2「お願いします。4営業日目に出してください」

パ「ご期待に添えるよう努めます(◀ハイとは言わない)」

 

~2日後(まだ3営業日目)~

 

2「例の資料、どうですか。明日お願いします。」

 「五月雨式で申し訳ないのですがアレとコレも必要なので回答ください」

パ「努めます(お前らググれ)」

 

2「(4営業日目早朝)資料何時にもらえますか?」

パ「約束通り本日中に提出させていただきます」

 

2「午前中にほしいです。お願いします。」

パ「努めます(ふざけている・・・・)」

 

パ「11:50 ドキュメント提出します。確認してください」

2「確認します。」

 

2「確認しました。アレとコレも明日には出してください」

パ「わかりました。(礼ぐらい言おうよ。アレとコレ、もう用意してるけどギリまで出してやらん)」 

 

といったやりとりがあった。

上位SIerのプロジェクトマネジメントに気をつけろ

納期の40%短縮を押し付けておいて、まだかまだかと

つつきまくって依頼した作業の邪魔をしてくるという始末。

 

そもそも、追加で飛んできたアレとコレは明らかに

顧客が必要なのではなくて、上位の業者である1と2が

ソフトウェアのことを知りたくて(調べずに)聞いてきているようだ。

下請の立場はこんなにも理不尽で辛いのか。愕然とした。

 

1と2が行うプロジェクトのマネジメントは本来、

メンバーたる下請の我々が気持ちよく、効率的に働ける

環境を用意するのが役割のはずだ。

言うならば、植え付けを行う前に畑を耕し、肥料をまいておくことのはずだ。

 

1と2は、こういった役割なのだと私は理解をしていたが、

ただ単につついているだけ。

プロジェクトマネージャーの風上にも置けない。

多重下請構造の上位業者はツンツンマシンだった。

一度ハイと言ったらもう負けだ。

奴らは次から次へと要求してくる。

金さえ払えば何でもするのだと勘違いしているに違いない。

 

そ・も・そ・も、納期厳しくなったのは1と2の発注が遅れたためだ。

今回はある程度流用ができる資料と経験あったから問題なかったけれど

流石に最終的に60%も納期短縮されたらたまったもんじゃない。

 

提出した基本設計書だって、

既存のソフトウェアの設計書を出して、次のように言った。

2「時間がないので、これを踏襲してそのまま確定させます」

 

いざ提出したら次のように言う。

2「1が設計根拠を出せと言っています。根拠を明記してください」

 

お前ら・・・%^0○▶#$&"$%&!!(自粛)

 

設計根拠は既存の踏襲と指示したのは2なのに

1に指摘されて丸投げしてくる。

 

4次請け・5次請けになると

本当に2日で仕事を仕上げろと言われかねない。

いや、上下関係があれば言うのだろうし、言われるのだろう。

 

冷静に考えて、このやりとりの間、私には何も生産しない

メールでの報告義務と調査作業でストレスを感じた。

ゼンゼン気持ちよく仕事できないよ。PMさん。

 

多重下請構造の問題点として、

下請業者が本来の力を発揮できないという

大きな課題があることが浮き彫りになった。

多重下請構造に組み込まれてはいけない。

顧客の課題と期待される役割が見えてこそITは面白い!

前述の質問が真に顧客の声であるなら、

一次請けはその質問の意図が何なのかを顧客に直接聞くことができる。

その納期理由も聞くことができる。

キャッチボールができるんだ。

 

下請にはその権限はない(もしくは限られている)。

 

下請だと上位の業者への説明をして、その質問が上位の業者にとって

都合悪いことでなくて初めて顧客へ質問される。

回答はバケツリレーされて私のところへメールで転送されてくる。

 

回答を見て、そういうのを聞きたいんじゃなくて!ということもあった。

今回の経験で上位の業者に期待しすぎてはいけないことを学べた。

誰がどう見ても意味が伝わるような表現にすべきだった。

 

これは多重下請構造の課題だと思うけれど、

今回は私の質問力・説明力を伸ばすための糧として仕舞うことにした。

  

さらに、下請企業は上位の業者から切り出された役割を担うだけになってしまいがちだ。

今回のパスコーのように初めて2と協業する場合は

コミュニケーションルールも確立されておらず、特に顕著なのだと思う。

 

そもそも、何を達成するためにプロジェクトが立ち上がって

どの課題どのような方向性でもってITで解決しようと

なっているのかがつかめない。

(パの担う役割部分しか説明もされない)

 

ITは手段だ。

目的があってこそ、手段がある。

 

今の私の結論は、少なくとも一次請けに居たいということ。

顧客と接していられるところが望ましいと強く思う。

 

今回の経験は、ITならではかもしれないけれど、

一次請けとして業務に従事できる環境を強くおすすめしたい。

対応策2:対顧客において、可能な限り1次請け(元請け)に近いポジション取りをする。

どこに所属をするのかによって仕事で求められるものが変わってくる。

 

今回の1のように顧客と対面する上流に所属すれば、

そもそもの理由やきっかけを炙り出すコンサルティング

プロジェクトマネジメント、要件定義、役割分担する前の概要設計などに

携わることが多いだろう。

 

ITだけどテクノロジーというよりは人と人のやりとりが多く

コミュニケーションが大切だ。

言葉だけでなく、言った時の会話の流れや表情なども含めて

目的の定義や課題の抽出、解決の方向性を顧客と作っていくことができる。

 

 逆に、下流になればなるほど役割は細分化されてくる。

今回のパスコーは、あるソフトウェアの設計・初期構築を担当している。

純粋にソフトウェアの仕様や設計力を問われる。

 

コミュニケーションがあまり好きでなくて、

ひたすら技術に重きをおきたい人には下請の方が合っている場合もあるだろう。

※上位企業との関係が良好で、伸び伸びと仕事ができる環境を

 見つけられれば、そこは幸せだ。あと、待遇も良ければいいね。

 

自身の目指す先と適正を考慮して選んで行くのが良いだろう。

パスコーは顧客が見えるところで働きたいと強く感じた。

 

近々、ようやく顧客と対面で打合せができそうなので、

その結果は次のエントリーで書こうと思う。

 

え?なに?全工程に関わりたい?

問題ない。

一次請けで全て経験すれば良い。

もしくは、ユーザー企業で外注せずに内製すれば良い。

本来はユーザー企業でするべきだとさえ思わない?

 

そう。

コンサルティング・要件定義・プロジェクトマネジメントや

概要設計・基本設計ぐらいまでは自社でできたほうがいいんだ。

詳細設計と開発は外部の専門家に任せる、それぐらいの

バランスが望ましいんだと思うよ。

 

自分たちがなぜITを使うのか、どう使うのかを決めるのが

外部の人間って変でしょ?

そうなんだよ。自分たちが決めなきゃ。

 

ユーザー系の企業で仲間と思いっきり自社のビジネスを

突き詰めて考えて、自分たちで動き出すのが一番の理想だと強く思っている。

 

そんなことを思いながらIT下請企業などと

検索をしていたら、2に読ませたいタイトルの本を見つけた。

検収書をもらって別れる時に手渡したい。

二次請けに特化しているのは珍しい。

この経験をした今、猛烈に読んでみたい。

下請を詰めろ!とか書いてたりして。。

  

多重下請け構造の問題点3:下請けに提供される情報は未更新の価値のない情報。それなのに上位企業は顧客側に立って攻めてくる

ようやく顧客と対面の打合せ実施

日々、1次請け(以下、1)と2次請け(以下、2)との

メールと電話のやりとりでずいぶんと消耗させられてきた。

 

点滴の管で常に血を抜き取られているような

そんな嫌な気分になるやりとりだ。

 

楽しさを感じにくい日々に耐えて、先日ようやくエンドユーザーと対面で

打合せの機会を得た。この時を待っていた。

聞きたいことが山ほどある。

 

  • どんな課題があるのか。
  • このソフトウェアにはどんなことを期待しているのか。
  • 競合ソフトとの比較で、このソフトウェアが良いと判断したのはどんなポイントからか。
  • 現行のソフトウェアではどうしているのか。

設計以前に、本来提案時に確認すべき事項が未確認だった。

1次請けはこういうことを確認しなくても注文がもらえるのだろうかと

疑問に思ったことも記しておこう。

 

2に確認しても回答が得られなかった

未確認事項として残っています。

※なのに1と2は既存の設計書踏襲するとか

 そもそもの選定理由を知らないとか顧客に失礼なことを言うのだ。

 

詳細は個別企業の内部事情が関係するのでかけないが

無事にヒアリングと基本設計に必要な情報を得ることができた。

この結果として、現行の設計踏襲であれば問題ない。

本当はわかっているんだよね?1と2。

打合せの中で1と2が本領発揮。顧客側に立ち下請をいじめる。

打合せ時の話に戻ろう。

打ち合わせの場は2のオフィスだ。

 

提供側は、1と2(2は営業もいた)、そしてパスコー。

顧客は6名体制で打合せに望んでいる。

 

1と2はパスコー(の所属先)に要件すら確認せぬまま

丸投げしてきていることを考えると、顧客6:パスコー1か。

いや、6:1:3(1と2は戦力外)か。

 

状況は決してパスコーにとって良いものではないけれど、

顧客の声が聞ける環境こそITの面白さだと前回も書いた通りで

この場こそ私の望む環境だと言い聞かせた。

 

いざお客さんの話を聞くと、今更な無茶振りが来ることがあるけれど、

だからこそのヒアリング・要件定義だ。

だからこその設計、レビューだと思っている。

 

必要な情報や要件は早い内に出るに越したことはない。

 ※一式受注するなら、本当は提案段階で確認すべきだ。

 

何も確認できていないまま、どんな見積と見積りの説明で

注文をいただいたのかを考えると腹立たしい気持ちになるが

ここはビジネス。

与えられた役割はきっちりと果たさなければならない。

 

さぁ打合せ開始。

打合せが始まると、1と2はいよいよ本領を発揮し始めた。

 

彼等は・・・安全地帯から・・・

憎いぐらい自由な発想で言いたい放題だ。

 

  • 自分の知っている類似ソフトウェアてまはあんなことやこんなことができた。今回はできないのか?
  • こんな妄想をしたんだが出来るか?
  • そう言えば業務でこんな課題があったんじゃなかったっけ?
  • アレ(2の担当するシステムではできないこと)とかもできますか?
  • 汎用性が高いから色んなことが出来るって聞いているんだけど?
  • このソフトウェアよく知らないので機能を全て説明してください
  • 現行の設計度外視でいいので最適な設定を教えて下さい

 

などと、1と2は顧客側に立つスタイルで

自由に妄想を膨らませて言いたい放題。

もはや6:3:1じゃない。

9:1の逆境。

 

負けるなパスコー。

 

パ「1つずつお話していきましょうか。(にこっ。(1と2…いつかお客さんに見限られるぜ)」

 

下請企業は、本来は受注前に確認しなければならない要件や

ソフトウェアの機能説明を受注後のタイトなスケジュールの中に

ねじ込まれることがあることを知った。

これは多重下請構造の大きな課題だ。

 

しかも、そんな工数は想定していないので見込んでいない。

 

納期は無駄に短縮(第1話)、

工数見込み外の作業をさせる(本作)、

そして作業の邪魔をする(第2話)と、

下請け業者にはイバラの道が敷かれている。

 

辛い中、頑張っている自分に酔えるタイプじゃないと

これは過酷。パスコーには合わない。

 

ドタバタでも、イェーイ!って言えないと

私が目指しているフォーチュン・クエストのようにいかないじゃないか。

だめだだめだ。

下請に踏襲するよう手渡された更新されていない設計書 

こんな中だが、なんとか打合せをしてきた。

 

事前に手渡された現行の設計書をベースに

基本設計書、詳細設計書を作ってきており、

2の要求通り踏襲スタイルで進めようとした。

 

が、

 

お客さん(以下、お)からツッコミの一言

お「2さん、それ構築当初のものですね。情報すごく古いです。」

 

追い打ち来ました。

定番のドキュメント更新されていない事件。

 

あーあ。

こうなったらもうお客さんしかゴールを知らない。

 

チラッと見たら、2は沈黙。

あーあ。

 

1は知らんぷりしている…。

もう聞くしかないな、と腹をくくってヒアリング開始。

早々にさらなる問題が勃発。

 

今回のソフトウェアにはライセンスが標準ライセンスと

アドオンの使える拡張ライセンスがある。

 

お客さんは拡張ライセンスを購入されていたので確認。

パ「どのアドオンを使いますか?どんな要件があったのですか?」

お「1さんが勧めてくれたから」

パ「1さん、選定理由を教えてください」

1「いや、、あの、、ソフトウェアのメーカーが推奨し…て…あの…(沈黙)」

 

パ「では、今日は使えるアドオンのご説明しましょうか。すべての機能詳細までは語れないですが(1、根拠ないのに提案しちゃだめだよ…)」

 お「はい、お願いします」

1,2「・・・おねがいします」 ←声小さい

 

定番。設計書未更新。

このあと、利用できるアドオンを一通り説明して、

おおむね方向性が決まったところでタイムアップ。

 

詳細設計の話をする予定だったが、(予想通り)基本設計までで

終了となった。

もちろん、パラメータを決められる判断材料はないので、

資料提供するのと、テスト機で検証しながら決めましょうと

リードして打ち合わせ終了となりました。

対応策3:最大の武器であり防御になる技術力と、顧客と会話できるコミュニケーション能力が活路を開く

上記のような1や2の攻撃を対処するには

担っている役割に関して仕様やノウハウを根拠に回答するしかない。

技術を高めるのは当たり前なんだけれど、下請けにとっては特に

技術こそ最大の攻めであり守りとなることを学んだ。

役割に応じて求められるスキルの比重が違う。

  

あと、1や2が行き詰ったときに前へ出られるかどうかも

大きな分かれ目だと思った

私は普段から前へ出る打ち合わせが多いので普通に対応したけれど

普段下請けで1や2のファシリテーションありきの仕事をしていると

今回は全員沈黙、仕切り直しになったに違いない。

 

求められるスキルの比重はちがうけれど、

広く浅くでも、スキルを伸ばしておくことも多重下請け構造を生き抜く上で重要だ。

 

時に、1と2の話を聞いているふりをしながらサラッとスルーして

その場をリードするぐらいのスキルが求められる。

1と2の言葉にプレッシャーを受けている場合ではない。

スルーできる力を発揮して前へ進めよう。

多重下請構造の問題点4:上流企業はベンダコントロールという名の管理が

多重下請構造なのに2が急に優しくなった怪しさ。

打ち合わせ後、1と2の、仕事を出してやってるんだぞ、

下請は言われたとおりに働いてくれといわんばかりのスタイルが一気に改善した。

 

2から飛んでくるメールも、このように変化しました。

 

2(先日まで)

「資料は◎日までに出してください。内容は顧客が要求すると考えられるものをすべて抜け漏れなく盛り込んでください。」

とか

「資料を拝見しました。1と顧客から指摘を受けたので以下を明日までに修正して送付ください。」

2(打ち合わせ後)

「先日送付いただいた資料ですが、A章の2項についてXXXという記載をお願いできますでしょうか。いつも無理を言って申し訳ありません

 

激変!

 

まるで別人と思ってしまった。

2よ、最初から相談して一緒に要件を詰めていくことができたら、

そもそも打合せでこんなに苦しい状況にならなくて済んだのに。

更新されていない古い設計書を踏襲した打合せを強行しようとして

お客さんに不信感を抱かせることなんてなかったのに。(第3話参照)

 

この態度の変化っぷりは、前回の打合せでの失態を

なんとか取り戻そうと下手に出ているのだろうか。

それとも、心を入れ替えてフラットに会話できるようになったのだろうか。

今後のやりとりが楽しみでもある。

多重下請構造の上下関係は課題だ

多重下請け構造においては、上位の業者が下請をこき使うことが

あまりにも当たり前になりすぎているように感じた。

 

双方の関係は、仕事を依頼している側と受ける側なのであって、

どちらの立場が上とか下とかではないはずだ。

 

2はパスコーに仕事を出しているので

2は仕事を依頼する側。

 

パスコーは仕事をもらっている側なので、もちろん期待に

応えられるように務めるのは当たり前のこと。

 

しかし、無茶を押し付けたり押し付けられるのは正しくない。

そもそも、ストレス感じながら仕事をすると

依頼された下請企業は本来のパフォーマンスが出ない。

多重下請構造の課題を顧客は見抜いている

多重下請構造において、上位の業者が下位の下請業者に

仕事を丸投げしていて内容を把握できていないことが

ままあることを、お客さんは気付いているのだと思うんだ。

 

というのも、

実は前回の打合せのあと、顧客からこっそりと声をかけられた。

 

パスコーの打合せが終了した時のことだ。

私はそのままビルの外に出たのだが、お客さんはまだ

打合せが続くようだった。

 

一旦15分ほど休憩のようで、恐らくタバコを吸いに

外へ向かうであろうお客さんのキーマンの1人(Yさん)が

私と同じエレベーターに乗り込んだ。

 

何か、突かれるのかな・・・

ちょっと身構える私に、Yさんは少し笑顔をみせて一方的にこう言い放った。

 

Y「パスコーさん、打合せありがとうございました。実はね、1(元請け業者)はあんまり当社のことを理解して進めてくれていないんだ。でも基幹システムを始めインフラ全般の保守もお願いしている都合があってね。国内でも超大手SIerだから我々は言われるまま。色々とお願いしている部分はあるのでお世話になっているのは事実なんだけどね・・・。」

 

「というのは置いといて、今回のソフトウェアの導入が無事に済んだあと、1の提供範囲外の部分で良いので直接提案してもらえることがないか会話できませんか?我々もリスクは分散させたい思いがあります。じゃ、また後日。」

 

パスコーは多重下請構造の闇を見た。

 

1や2はプロジェクトマネジメントという立場で旗振りをしているものの

実質の作業は下請業者が担当しているし、1や2は詳細は把握できていない。

 

ふわーーっと概要だけ聞いて下請に丸投げしているので、

顧客企業にとって本当に必要なことは分かっていないのかもしれないな。

多重下請構造は間もなく破綻する

顧客から直接声をかけてもらったことについて、

パスコーの所属先がどのように振る舞うのかは営業担当とも

話をする必要がある。

ここも、進捗があれば書ける範囲で書こうと思う。

 

今回のプロジェクトを依頼してもらった流れ(商流)があるので、

そのままハイハイと行くわけにはいかないかもしれないだろうけれど

お客さん自身が変わろうとしていることを強く感じた。

 

いつまでもSIerに丸抱えされ、高い費用を支払い続けることに

疑問を感じ、変わろうと動き出している。

 

お客さんが自社でプロジェクトマネジメントを行い、

自社で対応が難しい部分を切り出して外注することになれば

それぞれのパーツは下請企業がそのまま対応できる。

 

旗振りだけをするSIerは不要になる。

多重下請構造が破綻する日は近いのかもしれない。

対応策4:多重下請構造に甘んじない下請こそプライムに立つ準備。

世の中で、こういう流れが起きつつあるのだと思う。

むしろパスコーが感じたのは遅いのかもしれないが。

 

技術力のある下請企業は大手SIerの下請としていつまでも

我慢し続けなくても良いかもしれない。

今こそ、技術力と顧客の真の課題を解決すべく

乗り出していくチャンス。

 

IT業界の多重下請構造はまもなく一度崩壊して

再建の時を迎える。

 

そんな時代、どうやって自分が生き残って行くのかを

改めて見つめ直す必要を感じた。 

生き抜けるスキルを身に着けなければならないと確信した。

技術を持ち、顧客と直接コミュニケートできる人材を有する

下請として準備をするのが良いように思う。

眼の前に迫る下剋上の準備を虎視眈々と進めるのが良い。

 

そういう意味では、下請としてプロジェクトに関わるのも(今回だけなら)悪くない。

特に、一次請けしか経験の無い人、もしくは下請しか経験したことのない

人にとって、この一連の記事が擬似的な体験になると幸い。

 

今回経験してわかったんだけど、下請でプロジェクトに参加していると

何かと辛いことが多い。

1や2がツンツンしてくるたびにストレスを感じるからだ。

 

下請企業に所属していて、心無い言葉に傷ついたり辛い過去の体験で

悩んでいる方には次の本をおすすめしたい。

宗教・信仰の本ではなく合理的な考え方を会得する

メンタルトレーニングができる書籍だ。

反応しない練習をして、心豊かに下剋上の準備をしてほしい。

では。