IT業界で問題視されている多重下請け構造の
問題点（のごく一部）に関わることになってしまった不運。
突如として3次請けに組み込まれてしまった。
IT業界の闇と言われる多重下請け構造の中の人として体験した課題を記していく所存だ。
- 多重下請け構造（タジュウシタウケコウゾウ）とは
- 人生初、多重下請け構造に組み込まれたプロジェクトが開始
- 多重下請け構造の問題点１：必要な期間より短い納期
- 多重下請け構造の問題点２：ひたすら詰められる
- 対応策２：対顧客において、可能な限り１次請け（元請け）に近いポジション取りをする。
- 多重下請け構造の問題点３：下請けに提供される情報は未更新の価値のない情報。それなのに上位企業は顧客側に立って攻めてくる
- 対応策３：最大の武器であり防御になる技術力と、顧客と会話できるコミュニケーション能力が活路を開く
- 多重下請構造の問題点４：上流企業はベンダコントロールという名の管理が
多重下請け構造（タジュウシタウケコウゾウ）とは
顧客企業から仕事をもらった企業（元請け企業、一次請け企業とも言う。一般的に大手企業）が受注した仕事をいくつかの仕事に分割する。
その分割した仕事の一部を中堅の企業に割り振りを行う。
仕事をもらった中堅企業（二次請けとも言う）は、その仕事を更に分割し
中小企業へ仕事の割り振りを行う。
仕事をもらった中小企業（三次請けとも言う）は、その仕事を更に分割し
零細企業へ仕事の割り振りを行う。
仕事をもらった零細企業（四次請けとも言う）は、その仕事を分割し
フリーランス（五次請けとも言う）などに仕事の割り振りを行う。
もちろん、全ての仕事が５次請け企業に割り振られるわけではなく、途中で２次、３次、４次請けの企業が自社で対応する部分もある。
このように複数回にわたり下請けに仕事を出していく状態を多重下請構造(多重下請け構造と書く場合もある)と言っている。
元請けから下請けにかけてピラミッド型の構造。
建設業界では大手ゼネコンを筆頭にこのような構造が見受けられる。
人生初、多重下請け構造に組み込まれたプロジェクトが開始
実は、パスコーはこれまで１次請けもしくは２次請け（１次は伝票通すだけで実質１次請け）しか経験をしたことがなかった。
この度、とあるソフトウェアメーカーからどうしてもと依頼されて３次請けのオシゴトに関わることになった。
私の所属している企業から下請けには仕事を出さないので多重下請構造の末端ということになる。
初めての下請の役割、どうなるのかなと心配しつつプロジェクトがスタートしたのが先日のことです。
多重下請け構造の問題点１：必要な期間より短い納期
いきなり直面したのは無駄に短い納期。
今回、オシゴトの依頼がきたきっかけとなるソフトウェアは市場で多数のベンダーが取り扱っているものではなく少しニッチなものである。
たまたま、そのベンダーの認定資格を持っていた私のところへソフトウェアベンダー担当営業からヘルプのお声がかかって（経過省略）引き受ける流れ。
ややニッチなソフトウェアなため１次請け、２次請け企業はそのソフトウェアのことをほぼ知らない状況で、実質は丸投げに近い。
年度末目前の2月半ばスタートで、3末検収と言ってきた。
みっちり1ヶ月半はかかる想定だったので4月以降までもつれ込む想定だった。
受注時点でスケジュールがめちゃくちゃタイトだ。
打ち合わせの結果というか問答無用で要件定義・基本設計・詳細設計を今すぐ終わらせろという話だった。
準備と設計で2週間は要する 想定だと伝えた。
が、ここで多重下請け構造の顕著な特徴が出た。
２次請けPMの発言
６日目にはドキュメント一式出してください。
７～８日目で弊社チェックします。
９～１０日目で１次請けチェックし、顧客に出します。
何もしないのに納期が短くなる！
（ソフトウェア自体知らなかったのに納期の40%持っていくのか）
レビュー・受入のチェックをしてもらうのは当たり前にしても、ここまで当然のごとく削られるとは思っていなかった。
多重下請構造の課題、ここにあり。
対応策１：多重下請け構造に組み込まれるプロジェクトはバッファが必須
納期の交渉はしつつも１０日かければ良い仕事を半分の５日で終わらせて（６日目はバッファ）提出しなければならなくなった。
幸い、実はドキュメント類は過去のプロジェクトである程度充実しているので対応は問題ない。
インターネットで多重下請構造は闇があると知っていたので余裕があることを見せてはいけないと判断して必死であるように振る舞った。
（６日ですか？！なんとか、なんとか努めますと振る舞ってみた）
しかし１から検証したりドキュメント作成しなければならないとしたら時間外の労働は必須になる。増員も検討しなければならないなどプロジェクトスタート時点で、増員するか時間外勤務で埋めるしか手がないなんてつらすぎる。
５次請けとかになると、この仕事を２日で仕上げろとか言われるのだろうか。
背筋が凍る。
下請として多重下請け構造のプロジェクトに関わる際には本来必要な納期にバッファを積まざるを得ない。
ただし、納期は長めにとるものの工数自体は変わらないことは守りたい。
バッファでエンドユーザー価格が上がるのは本意ではないからだ。
多重下請け構造の問題点２：ひたすら詰められる
上位企業とのやりとりで、ひたすら詰められるという現象が発生した。
２次請け（以下、２）
「例のドキュメント、６営業日目の提出をお願いしていましたが４営業日目には未完成でも良いので見せてください」
パスコー（以下、パ）
「もともと８営業日はかかる想定なのでかなり厳しいです。
なるべく努めます。」
２「お願いします。４営業日目に出してください」
パ「ご期待に添えるよう努めます（◀ハイとは言わない）」
～２日後（まだ３営業日目）～
２「例の資料、どうですか。明日お願いします。」
「五月雨式で申し訳ないのですがアレとコレも必要なので回答ください」
パ「努めます（お前らググれ）」
２「（４営業日目早朝）資料何時にもらえますか？」
パ「約束通り本日中に提出させていただきます」
２「午前中にほしいです。お願いします。」
パ「努めます（ふざけている・・・・）」
パ「11:50 ドキュメント提出します。確認してください」
２「確認します。」
２「確認しました。アレとコレも明日には出してください」
パ「わかりました。（礼ぐらい言おうよ。アレとコレ、もう用意してるけどギリまで出してやらん）」
といったやりとりがあった。
上位SIerのプロジェクトマネジメントに気をつけろ
納期の40%短縮を押し付けておいて、まだかまだかとつつきまくって依頼した作業の邪魔をしてくるという始末。
そもそも、追加で飛んできたアレとコレは明らかに顧客が必要なのではなくて、上位の業者である１と２がソフトウェアのことを知りたくて（調べずに）聞いてきているようだ。
下請の立場はこんなにも理不尽で辛いのか。愕然とした。
１と２が行うプロジェクトのマネジメントは本来、メンバーたる下請の我々が気持ちよく、効率的に働ける環境を用意するのが役割のはずだ。
言うならば、植え付けを行う前に畑を耕し、肥料をまいておくことのはずだ。
１と２は、こういった役割なのだと私は理解をしていたが、ただ単につついているだけ。
プロジェクトマネージャーの風上にも置けない。
多重下請構造の上位業者はツンツンマシンだった。
一度ハイと言ったらもう負けだ。奴らは次から次へと要求してくる。
金さえ払えば何でもするのだと勘違いしているに違いない。
そ・も・そ・も、納期厳しくなったのは１と２の発注が遅れたためだ。
今回はある程度流用ができる資料と経験あったから問題なかったけれど流石に最終的に60%も納期短縮されたらたまったもんじゃない。
提出した基本設計書だって、既存のソフトウェアの設計書を出して、次のように言った。
２「時間がないので、これを踏襲してそのまま確定させます」
いざ提出したら次のように言う。
２「１が設計根拠を出せと言っています。根拠を明記してください」
お前ら・・・%^0○▶#$&"$%&!!(自粛）
設計根拠は既存の踏襲と指示したのは２なのに１に指摘されて丸投げしてくる。
４次請け・５次請けになると
本当に２日で仕事を仕上げろと言われかねない。
いや、上下関係があれば言うのだろうし、言われるのだろう。
冷静に考えて、このやりとりの間、私には何も生産しないメールでの報告義務と調査作業でストレスを感じた。
ゼンゼン気持ちよく仕事できないよ。PMさん。
多重下請構造の問題点として、下請業者が本来の力を発揮できないという大きな課題があることが浮き彫りになった。
多重下請構造に組み込まれてはいけない。
顧客の課題と期待される役割が見えてこそITは面白い！
前述の質問が真に顧客の声であるなら、一次請けはその質問の意図が何なのかを顧客に直接聞くことができる。
その納期理由も聞くことができる。
キャッチボールができるんだ。
下請にはその権限はない（もしくは限られている）。
下請だと上位の業者への説明をして、その質問が上位の業者にとって都合悪いことでなくて初めて顧客へ質問される。
回答はバケツリレーされて私のところへメールで転送されてくる。
回答を見て、そういうのを聞きたいんじゃなくて！ということもあった。
今回の経験で上位の業者に期待しすぎてはいけないことを学べた。
誰がどう見ても意味が伝わるような表現にすべきだった。
これは多重下請構造の課題だと思うけれど、今回は私の質問力・説明力を伸ばすための糧として仕舞うことにした。
さらに、下請企業は上位の業者から切り出された役割を担うだけになってしまいがちだ。
今回のパスコーのように初めて２と協業する場合はコミュニケーションルールも確立されておらず、特に顕著なのだと思う。
そもそも、何を達成するためにプロジェクトが立ち上がってどの課題をどのような方向性でもってITで解決しようとなっているのかがつかめない。
（パの担う役割部分しか説明もされない）
ITは手段だ。目的があってこそ、手段がある。
今の私の結論は、少なくとも一次請けに居たいということ。
顧客と接していられるところが望ましいと強く思う。
今回の経験は、ITならではかもしれないけれど、一次請けとして業務に従事できる環境を強くおすすめしたい。
対応策２：対顧客において、可能な限り１次請け（元請け）に近いポジション取りをする。
どこに所属をするのかによって仕事で求められるものが変わってくる。
今回の１のように顧客と対面する上流に所属すれば、そもそもの理由やきっかけを炙り出すコンサルティングやプロジェクトマネジメント、要件定義、役割分担する前の概要設計などに携わることが多いだろう。
ITだけどテクノロジーというよりは人と人のやりとりが多くコミュニケーションが大切だ。
言葉だけでなく、言った時の会話の流れや表情なども含めて目的の定義や課題の抽出、解決の方向性を顧客と作っていくことができる。
逆に、下流になればなるほど役割は細分化されてくる。
今回のパスコーは、あるソフトウェアの設計・初期構築を担当している。
純粋にソフトウェアの仕様や設計力を問われる。
コミュニケーションがあまり好きでなくて、ひたすら技術に重きをおきたい人には下請の方が合っている場合もあるだろう。
※上位企業との関係が良好で、伸び伸びと仕事ができる環境を見つけられれば、そこは幸せだ。あと、待遇も良ければいいね。
自身の目指す先と適正を考慮して選んで行くのが良いだろう。
パスコーは顧客が見えるところで働きたいと強く感じた。
近々、ようやく顧客と対面で打合せができそうなので、その結果は次のエントリーで書こうと思う。
え？なに？全工程に関わりたい？
問題ない。
一次請けで全て経験すれば良い。
もしくは、ユーザー企業で外注せずに内製すれば良い。
本来はユーザー企業でするべきだとさえ思わない？
そう。
コンサルティング・要件定義・プロジェクトマネジメントや概要設計・基本設計ぐらいまでは自社でできたほうがいいんだ。
詳細設計と開発は外部の専門家に任せる、それぐらいのバランスが望ましいんだと思うよ。
自分たちがなぜITを使うのか、どう使うのかを決めるのが外部の人間って変でしょ？
そうなんだよ。自分たちが決めなきゃ。
ユーザー系の企業で仲間と思いっきり自社のビジネスを突き詰めて考えて、自分たちで動き出すのが一番の理想だと強く思っている。
そんなことを思いながらIT下請企業などと検索をしていたら、２に読ませたいタイトルの本を見つけた。
検収書をもらって別れる時に手渡したい。
二次請けに特化しているのは珍しい。
この経験をした今、猛烈に読んでみたい。
下請を詰めろ！とか書いてたりして。。
多重下請け構造の問題点３：下請けに提供される情報は未更新の価値のない情報。それなのに上位企業は顧客側に立って攻めてくる
ようやく顧客と対面の打合せ実施
日々、１次請け（以下、１）と２次請け（以下、２）とのメールと電話のやりとりでずいぶんと消耗させられてきた。
点滴の管で常に血を抜き取られているようなそんな嫌な気分になるやりとりだ。
楽しさを感じにくい日々に耐えて、先日ようやくエンドユーザーと対面で打合せの機会を得た。この時を待っていた。
聞きたいことが山ほどある。
- どんな課題があるのか。
- このソフトウェアにはどんなことを期待しているのか。
- 競合ソフトとの比較で、このソフトウェアが良いと判断したのはどんなポイントからか。
- 現行のソフトウェアではどうしているのか。
設計以前に、本来提案時に確認すべき事項が未確認だった。
１次請けはこういうことを確認しなくても注文がもらえるのだろうかと疑問に思ったことも記しておこう。
２に確認しても回答が得られなかった未確認事項として残っています。
※なのに１と２は既存の設計書踏襲するとか
そもそもの選定理由を知らないとか顧客に失礼なことを言うのだ。
詳細は個別企業の内部事情が関係するのでかけないが無事にヒアリングと基本設計に必要な情報を得ることができた。
この結果として、現行の設計踏襲であれば問題ない。
本当はわかっているんだよね？１と２。
打合せの中で１と２が本領発揮。顧客側に立ち下請をいじめる。
打合せ時の話に戻ろう。
打ち合わせの場は２のオフィスだ。
提供側は、１と２（２は営業もいた）、そしてパスコー。
顧客は６名体制で打合せに望んでいる。
１と２はパスコー（の所属先）に要件すら確認せぬまま丸投げしてきていることを考えると、顧客６：パスコー１か。
いや、６：１：３（１と２は戦力外）か。
状況は決してパスコーにとって良いものではないけれど、顧客の声が聞ける環境こそITの面白さだと前回も書いた通りでこの場こそ私の望む環境だと言い聞かせた。
いざお客さんの話を聞くと、今更な無茶振りが来ることがあるけれど、だからこそのヒアリング・要件定義だ。
だからこその設計、レビューだと思っている。
必要な情報や要件は早い内に出るに越したことはない。
※一式受注するなら、本当は提案段階で確認すべきだ。
何も確認できていないまま、どんな見積と見積りの説明で注文をいただいたのかを考えると腹立たしい気持ちになるがここはビジネス。
与えられた役割はきっちりと果たさなければならない。
打合せ開始。
打合せが始まると、１と２はいよいよ本領を発揮し始めた。
彼等は・・・安全地帯から・・・憎いぐらい自由な発想で言いたい放題だ。
- 自分の知っている類似ソフトウェアてまはあんなことやこんなことができた。今回はできないのか？
- こんな妄想をしたんだが出来るか？
- そう言えば業務でこんな課題があったんじゃなかったっけ？
- アレ（２の担当するシステムではできないこと）とかもできますか？
- 汎用性が高いから色んなことが出来るって聞いているんだけど？
- このソフトウェアよく知らないので機能を全て説明してください
- 現行の設計度外視でいいので最適な設定を教えて下さい
などと、１と２は顧客側に立つスタイルで自由に妄想を膨らませて言いたい放題。
もはや６：３：１じゃない。
９：１の逆境。
負けるなパスコー。
パ「１つずつお話していきましょうか。（にこっ。（１と２…いつかお客さんに見限られるぜ）」
下請企業は、本来は受注前に確認しなければならない要件やソフトウェアの機能説明を受注後のタイトなスケジュールの中にねじ込まれることがあることを知った。
これは多重下請構造の大きな課題だ。
しかも、そんな工数は想定していないので見込んでいない。
納期は無駄に短縮、工数見込み外の作業をさせる、そして作業の邪魔をすると、下請け業者にはイバラの道が敷かれている。
辛い中、頑張っている自分に酔えるタイプじゃないとこれは過酷。パスコーには合わない。
ドタバタでも、イェーイ！って言えないと私が目指しているフォーチュン・クエストのようにいかないじゃないか。
だめだだめだ。
下請に踏襲するよう手渡された更新されていない設計書
こんな中だが、なんとか打合せをしてきた。
事前に手渡された現行の設計書をベースに基本設計書、詳細設計書を作ってきており、2の要求通り踏襲スタイルで進めようとした。
が、
お客さん（以下、お）からツッコミの一言
お「2さん、それ構築当初のものですね。情報すごく古いです。」
追い打ち来ました。
定番のドキュメント更新されていない事件。
あーあ。
こうなったらもうお客さんしかゴールを知らない。
チラッと見たら、2は沈黙。
あーあ。
1は知らんぷりしている…。
もう聞くしかないな、と腹をくくってヒアリング開始。
早々にさらなる問題が勃発。
今回のソフトウェアにはライセンスが標準ライセンスとアドオンの使える拡張ライセンスがある。
お客さんは拡張ライセンスを購入されていたので確認。
パ「どのアドオンを使いますか？どんな要件があったのですか？」
お「1さんが勧めてくれたから」
パ「1さん、選定理由を教えてください」
1「いや、、あの、、ソフトウェアのメーカーが推奨し…て…あの…（沈黙）」
パ「では、今日は使えるアドオンのご説明しましょうか。すべての機能詳細までは語れないですが（1、根拠ないのに提案しちゃだめだよ…）」
お「はい、お願いします」
１，２「・・・おねがいします」 ←声小さい
定番。設計書未更新。
このあと、利用できるアドオンを一通り説明して、おおむね方向性が決まったところでタイムアップ。
詳細設計の話をする予定だったが、（予想通り）基本設計までで終了となった。
もちろん、パラメータを決められる判断材料はないので、資料提供するのと、テスト機で検証しながら決めましょうとリードして打ち合わせ終了となりました。
対応策３：最大の武器であり防御になる技術力と、顧客と会話できるコミュニケーション能力が活路を開く
上記のような１や２の攻撃を対処するには担っている役割に関して仕様やノウハウを根拠に回答するしかない。
技術を高めるのは当たり前なんだけれど、下請けにとっては特に技術こそ最大の攻めであり守りとなることを学んだ。
役割に応じて求められるスキルの比重が違う。
あと、１や２が行き詰ったときに前へ出られるかどうかも大きな分かれ目だと思った。
私は普段から前へ出る打ち合わせが多いので普通に対応したけれど普段下請けで１や２のファシリテーションありきの仕事をしていると今回は全員沈黙、仕切り直しになったに違いない。
求められるスキルの比重はちがうけれど、広く浅くでも、スキルを伸ばしておくことも多重下請け構造を生き抜く上で重要だ。
時に、１と２の話を聞いているふりをしながらサラッとスルーしてその場をリードするぐらいのスキルが求められる。
１と２の言葉にプレッシャーを受けている場合ではない。
スルーできる力を発揮して前へ進めよう。
多重下請構造の問題点４：上流企業はベンダコントロールという名の管理が
多重下請構造なのに２が急に優しくなった怪しさ。
打ち合わせ後、１と２の、仕事を出してやってるんだぞ、下請は言われたとおりに働いてくれといわんばかりのスタイルが一気に改善した。
２から飛んでくるメールも、このように変化しました。
２（先日まで）
「資料は◎日までに出してください。内容は顧客が要求すると考えられるものをすべて抜け漏れなく盛り込んでください。」
とか
「資料を拝見しました。１と顧客から指摘を受けたので以下を明日までに修正して送付ください。」
↓
２（打ち合わせ後）
「先日送付いただいた資料ですが、A章の２項についてXXXという記載をお願いできますでしょうか。いつも無理を言って申し訳ありません」
激変！
まるで別人と思ってしまった。
２よ、最初から相談して一緒に要件を詰めていくことができたら、そもそも打合せでこんなに苦しい状況にならなくて済んだのに。
更新されていない古い設計書を踏襲した打合せを強行しようとしてお客さんに不信感を抱かせることなんてなかったのに。（第3話参照）
この態度の変化っぷりは、前回の打合せでの失態をなんとか取り戻そうと下手に出ているのだろうか。
それとも、心を入れ替えてフラットに会話できるようになったのだろうか。
今後のやりとりが楽しみでもある。
多重下請構造の上下関係は課題だ
多重下請け構造においては、上位の業者が下請をこき使うことがあまりにも当たり前になりすぎているように感じた。
双方の関係は、仕事を依頼している側と受ける側なのであって、どちらの立場が上とか下とかではないはずだ。
２はパスコーに仕事を出しているので２は仕事を依頼する側。
パスコーは仕事をもらっている側なので、もちろん期待に応えられるように務めるのは当たり前のこと。
しかし、無茶を押し付けたり押し付けられるのは正しくない。
そもそも、ストレス感じながら仕事をすると依頼された下請企業は本来のパフォーマンスが出ない。
多重下請構造の課題を顧客は見抜いている
多重下請構造において、上位の業者が下位の下請業者に仕事を丸投げしていて内容を把握できていないことがままあることを、お客さんは気付いているのだと考えました。
というのも、実は前回の打合せのあと、顧客からこっそりと声をかけられた。
パスコーの打合せが終了した時のことだ。
私はそのままビルの外に出たのだが、お客さんはまだ打合せが続くようだった。
一旦１５分ほど休憩のようで、恐らくタバコを吸いに外へ向かうであろうお客さんのキーマンの１人（Yさん）が私と同じエレベーターに乗り込んだ。
何か、突かれるのかな・・・
ちょっと身構える私に、Yさんは少し笑顔をみせて一方的にこう言い放った。
Y「パスコーさん、打合せありがとうございました。実はね、１（元請け業者）はあんまり当社のことを理解して進めてくれていないんだ。でも基幹システムを始めインフラ全般の保守もお願いしている都合があってね。国内でも超大手SIerだから我々は言われるまま。色々とお願いしている部分はあるのでお世話になっているのは事実なんだけどね・・・。」
「というのは置いといて、今回のソフトウェアの導入が無事に済んだあと、１の提供範囲外の部分で良いので直接提案してもらえることがないか会話できませんか？我々もリスクは分散させたい思いがあります。じゃ、また後日。」
パスコーは多重下請構造の闇を見た。
１や２はプロジェクトマネジメントという立場で旗振りをしているものの実質の作業は下請業者が担当しているし、１や２は詳細は把握できていない。
ふわーーっと概要だけ聞いて下請に丸投げしているので、顧客企業にとって本当に必要なことは分かっていないのかもしれないな。
多重下請構造は間もなく破綻する
顧客から直接声をかけてもらったことについて、パスコーの所属先がどのように振る舞うのかは営業担当とも話をする必要がある。
ここも、進捗があれば書ける範囲で書こうと思う。
今回のプロジェクトを依頼してもらった流れ（商流）があるので、そのままハイハイと行くわけにはいかないかもしれないだろうけれどお客さん自身が変わろうとしていることを強く感じた。
いつまでもSIerに丸抱えされ、高い費用を支払い続けることに疑問を感じ、変わろうと動き出している。
お客さんが自社でプロジェクトマネジメントを行い、自社で対応が難しい部分を切り出して外注することになればそれぞれのパーツは下請企業がそのまま対応できる。
旗振りだけをするSIerは不要になる。
多重下請構造が破綻する日は近いのかもしれない。
対応策４：多重下請構造に甘んじない下請こそプライムに立つ準備。
世の中で、こういう流れが起きつつあるのだと思う。
むしろパスコーが感じたのは遅いのかもしれないが。
技術力のある下請企業は大手SIerの下請としていつまでも我慢し続けなくても良いかもしれない。
今こそ、技術力と顧客の真の課題を解決すべく乗り出していくチャンス。
IT業界の多重下請構造はまもなく一度崩壊して再建の時を迎える。
そんな時代、どうやって自分が生き残って行くのかを改めて見つめ直す必要を感じた。
生き抜けるスキルを身に着けなければならないと確信した。
技術を持ち、顧客と直接コミュニケートできる人材を有する下請として準備をするのが良いように思う。
眼の前に迫る下剋上の準備を虎視眈々と進めるのが良い。
そういう意味では、下請としてプロジェクトに関わるのも（今回だけなら）悪くない。
特に、一次請けしか経験の無い人、もしくは下請しか経験したことのない人にとって、この一連の記事が擬似的な体験になると幸い。
今回経験してわかったんだけど、下請でプロジェクトに参加していると何かと辛いことが多い。
1や2がツンツンしてくるたびにストレスを感じるからだ。
下請企業に所属していて、心無い言葉に傷ついたり辛い過去の体験で悩んでいる方には次の本をおすすめしたい。
宗教・信仰の本ではなく合理的な考え方を会得するメンタルトレーニングができる書籍だ。
反応しない練習をして、心豊かに下剋上の準備をしてほしい。
では。
