today::エンジニアに憧れる非エンジニア

今のところは、エンジニアとは言えないところの職種です。しかしエンジニア的なものの考え方に興味津津。

ランプサム契約考

ランプサム契約とは

「事前に全ての仕様を決定し、総額のみで価格契約する」という形態の請負契約を指します。英語の「lump sum contract」をそのまま日本語化したものです。日本語では「総価請負契約」「一式請負契約」「総価一式請負契約」などと称されます。日本において単に「請負契約」と称される場合、暗黙的にランプサム契約が想定される場合が一般的です。

ランプサム契約は請負契約の一種なので、受注側は契約に定められた仕事を完成させる義務を負います。

なお、ランプサム契約以外の請負契約の形態としては、「コストプラスフィー契約(コストレインバース契約・実費精算契約)」「ターゲットコスト契約(目標コスト契約)」等があります。

ランプサム契約の問題点

「まずやってみる、小規模からやってみる」というビジネスの進め方が求められる現代にあっては、「ランプサム契約は、アジャイルな仕事の進め方とは致命的に相性が悪い」というのが大きな問題であると思います。

また、ランプサム契約は、以下の記事で言及している「受発注の関係性」が先鋭化しやすいのも大きな問題です。

rapidliner0.hatenablog.com

成果物を事前に定義しなければならない

ランプサム契約は「事前に全ての仕様を決定し、総額のみで価格契約する」という契約形態です。アジャイルな仕事の進め方は、事前に全ての仕様を決定できないゆえに採用される仕事の進め方です。この時点で致命的に相性が悪いのは明らかですね。

また、ランプサム契約を含む請負契約においては、「何をもって仕事の完成とするか」を事前に定義しなければなりません。受注側は「完成させられなければ債務不履行責任を負う」という前提があるので、どうしても「自らの責務を軽くする方向に完成の定義を持っていく」という方向性に走りがちです。「完成の定義をめぐる駆け引き」が行われると、発注者・受注者の関係は、アジャイルな仕事の進め方で重んじられる「共創・協働」からはほど遠いものとなってしまいます。

発注者から見て、プロジェクトがブラックボックス化する

ランプサム契約は「総額のみで価格契約する」という契約形態です。そのため、受注者がプロジェクトをどう進めているかは、どうしてもブラックボックスになってしまいます。「プロジェクトが発注側から見てブラックボックス化している」という状況だと、受注者は「発注者を出し抜き、自らが超過利潤を得る」という方向性に走ってしまうものです。これまた「発注者と受注者の共創・協働」からプロジェクトを遠ざける大きな要素です。

受注者がリスク回避に走らざるを得ない

ランプサム契約は、「受注者が負うリスク込みで価格契約する」という契約形態です。受注側は、リスクを回避することによって自らの儲けを増やすことができます。その結果、受注者は「あらゆる手段でリスクを回避することにより、自らが超過利潤を得る」という方向性に走ってしまいます。受注者のリスク回避手段としては、「発注者にリスクを押し付ける」というものもあります。受注者が発注者にリスクを押し付ける…当然、「発注者と受注者の共創・協働」からプロジェクトを遠ざける大きな要素の一つですね。

発注側も追加負担を回避しようとする

発注者にとってのランプサム契約の最大のメリットは、「契約締結時点で金額を決定できる」という点でしょう。合理的判断ができる発注者が、当該メリットを自ら捨てる方向に動くのは非常に考えづらいです。ゆえに、発注側も追加負担を回避しようとするのです。

まとめ

  • ランプサム契約は、「事前に全ての仕様を決定し、総額のみで価格契約する」という形態の請負契約を指す
  • ランプサム契約の場合、発注者と受注者が対立関係になりやすい
    • ランプサム契約は、「発注者と受注者の共創・協働」を阻害する要因が多く含まれる契約形態である

元請通信建設会社にとって、サービス総合工事の元請会社変更は一大事

概要

rapidliner0.hatenablog.com

NTT東西のサービス総合工事(サ総工事)を受注する元請事業者は、エリア別に見た場合、一般には長期にわたり同一の事業者となります。しかしながら、何らかの理由により特定エリアのサ総工事を受注する元請事業者が変更されることは皆無ではありません。

実際に特定エリアのサ総工事を受注する元請事業者が変更されたら、元請事業者から見て何が発生するか。この記事では、その内実について記述していきます。

元請通信建設会社におけるNTT東西発注工事の施工体制

元請通信建設会社から見た場合、NTT東西発注の通信設備工事の施工は、一般に以下のような体制で行なわれます。

  1. 元請会社は、発注者たるNTT東西から通信設備工事を受注する
  2. 元請会社は、NTT東西から受注した通信設備工事を、地域別に設立した連結子会社に下請発注する
    • 設計実務・施工管理実務も地域子会社に外注する
    • 現実には、「元請会社従業員が地域子会社に出向して設計実務・施工管理実務を担う」というケースも多い
  3. 元請会社の地域子会社は、元請会社から受注した通信設備工事を、各協力会社に再下請発注する
    • 昨今は、元請会社が各協力会社に直接下請発注するケースも増加している
    • 現場における技能労働は協力会社の従業員・一人親方等が担う
    • 元請会社およびその地域子会社が設計実務・施工管理実務の一部を協力会社に外注する場合がある

元請会社は、「施工管理の現場実務については、自らは法律等に定められた最低限の業務のみを行ない、できる限り連結子会社・協力会社に外注する」という方向性で動きます。特にサ総工事において、このような傾向は顕著に現れるものです。

サービス総合工事の元請会社が変更されたら何が起こるか

サ総工事の元請会社が変更されると以下のような事態が起こります。

  • 以前の元請会社の地域子会社が、新しい元請会社から暫定的に施工管理実務を受注する
    • 期間は「新しい元請会社の地域子会社による施工体制が確立されるまで」
    • 元請会社変更時点では、以前の元請会社の地域子会社が施工管理実務の多くを担っている
  • 新しい元請会社は、当該サ総工事エリアで事業を行なっている協力会社に対し、自身や連結子会社の工事の一部を下請け発注する
    • 「元請会社の変更を機に、新しい元請会社と親密な協力会社が工事を新規受注する」というケースも少なくない
  • 新しい元請会社の地域子会社が、当該サ総工事の施工管理実務を担うための体制を新規整備する

「施工実務を担う地域子会社が、以前の元請会社の系列会社から、新しい元請会社の系列会社に入れ替わる」という過程は一大事です。新しい元請会社の地域子会社は、「要員手配・組織整備・地域事情への習熟」等のプロセス整備を行なう必要があります。これらのプロセスを完了させ、新しい元請会社による施工体制を確立するには、一般に数年の月日が必要となります。

数年かけて施工体制を確立するだって?

「施工体制の確立に数年の月日を要する」というのも、よくよく考えると悠長な話です。そのような悠長な話が成り立つ理由としては、以下のような事柄を挙げることができます。

  • 発注者たるNTT東西と元請通信建設会社の関係が安定的である
    • 元請通信建設会社は、NTTグループ各社からの転籍を受け入れる慣習があり、経営陣~中間管理職の多くをNTTグループ各社からの転籍者が占める
    • 対象設備のユニバーサルサービス性・自然独占性等により、当該関係性は将来にわたり安定的であることが期待できる
  • 通信建設業界では、「元請会社が自身の地域子会社に施工管理実務の大半を外注する」という体制が一般的である
    • 外注体制の再構築は一大事
  • サ総工事のエリア別元請会社の変更は、10年以上に1回あるかないかである

…「そのような悠長な話が成り立つほどに業界構造が安定している」ということですね。

さん/くんシステム考

概要

以下の記事を読んでのまとめ・感想です。

diamond.jp

さん/くんシステムとは

以下の表に記載するような呼称・敬語使用の使い分けを行なう、組織内部における呼称システムです。

自分と相手の関係性 呼称
相手が自分より年上 さん付け・敬語使用
相手が自分より年下 敬語を使わない
相手が自分より年下の男性 くん付け

さん/くんシステムの実例

Y課長「Sくん、例の件だけど、こうしてみようよ」
S部長「なるほど、Yさんはそう思うわけですね。じゃあHくんはどう?」
Hさん「そうですね、私もYさんの意見に賛成です」
年下を「呼び捨て」にする会社員は、しだいに身動きが取れなくなる | 会社人生を後悔しない40代からの仕事術 | ダイヤモンド・オンライン

以上の会話例における各人の年齢・職位序列の関係性は、上述関係性・呼称の対応表から、以下の関係性であることが見えてくるわけです。

序列を決める要素 序列
職位 S部長>Y課長>Hさん
年齢 Y課長>S部長>Hさん

さん/くんシステムが広く存在する組織

以下のような組織には、さん/くんシステムが今なお広く存在するものと考えられます。

  • 「同期カルチャー」が今なお根強く存在する組織
  • 縦の序列や、指示・命令系統がはっきり存在している組織
  • いわゆる「体育会系」と形容される組織

「同期カルチャー」というのは、従業員を入社年次ごとに十把一絡げのものとして扱うカルチャーを指します。以下のような特徴を持つ組織に強く現れる風土です。

  • 人材採用を新卒一括採用に依存している
  • 離職率中途採用数ともに低水準である
  • 大量採用を行なう大企業である

「縦の序列や、指示・命令系統がはっきり存在している組織」というのは、請負契約に依拠する業種、とりわけ重層下請構造が存在する業種に多く存在します。特に建設業1は、このような特性が強いと考えることができます。

「いわゆる体育会系」というのは、「縦の序列がはっきり存在している組織」の代表的な例ですね。

さん/くんシステムの問題点

さん/くんシステムは、「年齢(または入社年次)によって、人との付き合い方を変える」というコミュニケーション手法です。そのような手法を日常的に用いていると、以下のような問題の発生は避けられません。

  • 年齢に基づく縦の序列意識が温存されてしまう
  • 「相手の年齢・職位・ジェンダーなどに応じて付き合い方を変える」という風潮が温存されてしまう

昨今、「縦の序列意識を取り払う」という目的で、社内における「役職呼び」を明確に禁止する組織が増えてきました。しかしながら、さん/くんシステムが温存されていると、「年齢に基づく縦の序列意識」は温存されてしまいます。さん/くんシステムが温存されていると、「役職呼びの禁止」のような施策を行ったとしても、その結果は不徹底なものとなる…というわけです。

「相手の年齢・職位・ジェンダーなどに応じて付き合い方を変える2」という風潮は、概要記載の記事でも言及されているように、ダイバーシティ(自分たちと異なる考え方を受け入れる)という考え方に反するものです。「相手の年齢・職位・ジェンダーなどに応じて付き合い方を変える」という風潮が温存されている組織は、若年者が寄り付かずor離れていき、長期的に衰退・消滅に至る危険性が高いです。

さん/くんシステムを乗り越えるために

さん/くんシステムを乗り越えるために、個人レベルでできることは多くあると考えています。

  • とりあえず自分だけでも、周囲の人全員を「さん」付けで呼ぶようにする
    • 概要記載の記事にも、この対応については言及されている
    • 年齢や役職は関係ない
    • 当初感じるであろう違和感は、意識して克服する必要がある
  • とりあえず自分だけでも、周囲の人全員に敬語を使うようにする
  • 「役割の違いは役割の違い」と、意識的に割り切って考える
    • 役割の違い・世代の違いを、身分の違いと捉えてはならない
  • ダイバーシティを実現できている組織では、『全員さん付け』というスタイルが一般的であること」を認識しておく
    • 概要記載の記事にも、この対応については言及されている
    • 年齢やキャリアの序列が把握しきれないほどバラバラになっている組織では、そうせざるを得ない

  1. 建設業は、請負契約に依拠する業種であるだけではなく、「付加価値創出の段階で、危険有害業務の発生が避けられない」「下請事業者の管理監督も含め、安全衛生の確保に関する義務・責任の多くを元請事業者が負う法制度が確立している」等の特徴があります。

  2. 個人的には、「相手の年齢・職位・ジェンダーなどに応じて付き合い方を変える」という問題は、「中高年向けメディアで顕著に現れる、女性を性的対象としてしか見ない風潮」にも通じる問題ではないかと考えています。

「受発注の関係性」とは

概要

昨今、ビジネスの現場において、以下のようなテーマに言及される機会が増えているように感じます。

  • 事業者間の関係性について、受発注の関係性を脱し、協働・共創の関係性を築き上げるための方法論
  • 社内で受発注の関係性が発生していることに起因する諸問題

しかしながら、「受発注の関係性」という語句の意味に関する文献は、様々なリソースに散らばっています。「受発注の関係性」に関する考え方について、個人的に1箇所にまとめて記述する必要性を感じたので、この記事を書くに至った次第です。

受発注の関係性とは

私個人としては、以下の関係性を指すと解釈しています。

発注者が受注者に対し、自らの仕事の一部を委任するという契約に基づいて成立する関係性

プリンシパル=エージェント関係

以下2つの当事者によって成立する関係性を指します。

受発注の関係性は、「発注者をプリンシパル・受注者をエージェントとしたプリンシパル=エージェント関係」という側面が強く現れがちな関係性です。

プリンシパル=エージェント関係とは何か」については、以下の記事で簡単な説明がされています。

imidas.jp

請負契約の本質

請負契約は、以下2つの義務を根底とする契約といえます。

  • 当事者の一方(受注者)が、相手方(発注者)に対し、ある仕事を完成することを約束する
  • 発注者は、当該仕事の完成に対し、受注者に反対報酬を支払うことを約束する

請負契約に立脚する関係性は、「ステレオタイプ的な受発注の関係性になりやすい関係性」でしょう。

受発注の関係性のもとでは何が発生するか

発注者は以下のような考えを持つでしょう。

  • 「受注者が完成を約束した仕事の進捗を監視すること」を自らの責務であると考える
  • 「仕事」の範囲をできる限り広く解釈しようとする

一方で、受注者は以下のような考えを持つでしょう。

  • 「発注者に対し、約束した仕事の完成を認めてもらうこと」を目的として行動する
  • 「仕事」の範囲をできる限り狭く解釈しようとする

全体としては、以下のような事態が発生する危険性が高いです。

  • 発注者と受注者
  • 発注者が優越的地位を得る
  • エージェンシー・スラックが表面化する
    • 発注者と受注者の利害対立、またはそれに伴う軋轢

受発注の関係性の問題点

発注者による優越的地位の濫用

特に日本においては、受発注の関係性は、「発注者が優越的地位を得る」という関係性になりがちです。発注者が受注者に対して優越的地位を得た場合、往々にして「発注者が受注者に対する優越的地位を濫用する」という構図が発生します。「発注者による優越的地位の濫用」は、以下の事態の発生につながります。

  • 関係性の内実が、「受注者が発注者に対し一方的に責務を負う」という内実に変質する事態
  • 発注者が契約で定められた義務すら覆そうとする事態

受注側が必要最小限の行動しか行わなくなる

プリンシパル=エージェント関係におけるエージェントとしての受注者は、プリンシパルたる発注者の利益を最大化する責務を負っている一方、経済社会の一主体として自らの利益を追求する立場にあります。受発注の関係性において、受注者が発注者の利益を最大化する責務を負う範囲は、受発注の内容を定めた契約の範囲にとどまります。このような関係性において、「受注側が契約の範囲を超えて発注者の利益を最大化しようとする」という行動は、受注者自身の利益を損ねる事態になってしまいます。結果、受注側が必要最小限の行動しか行わなくなるわけです。

「協働」「共に新たな価値を作る」という考え方の不在

「発注者は仕事の範囲をできる限り広く解釈しようと考え、受注者は仕事の範囲をできる限り狭く解釈しようと考える」という図式が成立する環境のもとでは、発注者と受注者の間には、仕事の範囲をめぐる対立関係が発生します。仕事の範囲をめぐる対立関係が存在する環境下では、仮にメンバー個人が「協働」「共に新たな価値を作る」という考えを持っていたとしても、そのような考えは仕事の範囲をめぐる対立関係に埋没してしまうものです。

責任分界点に対し、異常なほど敏感になりがちである

仕事の範囲をめぐる対立は、「責任分界点に対する異常なほどの敏感さ」にもつながってきます。具体的には、以下のような事態の発生につながります。

  • 言い出しっぺの法則…言い出した側が責任を負うことになる
  • 「何を言ったか」より「誰が言ったか」が重んじられる
  • 責任を負いたくないあまり、「リスクを認識していても言わない」という行動が正当化されがちである

相互不可侵とされる領域が発生する

日本における「受発注の関係性」は、一般に「受発注者相互間における信義則の存在」を前提とするものです。「受発注者相互間における信義則の存在」は、「発注者と受注者の双方とも、契約上の権利義務の詳細まで立ち入るべきではない」という考え方を生みます。「契約上の権利義務の詳細まで立ち入らない」という考え方が暴走すると、相互不可侵とされる領域が発生するわけです。

相互不可侵とされる領域の発生は、以下のような問題の原因となります。

  • 関係性外部から見て、契約の実態が不透明になる
  • 優越的地位の濫用等、一方的な権利義務関係の存在が覆い隠されてしまう

関係性の外側が軽視される

「発注者と受注者が、お互いに相手側の当事者しか見えていない」という関係性の中では、以下のような事柄は軽視されがちになります。

  • 関係性の外側に及ぼす影響
  • その仕事を完成させることによってもたらされる社会的便益
  • その仕事を完成させた後、継続的に発生する責任やコスト

NTT通信建設業界における、NTT以外の発注による工事の扱い

概要

NTT通信建設業界に属する各企業の売上は、NTT発注工事のみで少なくとも50%前後を占めます。一方で、「NTT通信建設業界に属する企業がNTT以外の事業者が発注する工事を受注する」というケースも当然出てきます。そうした「NTT以外の事業者が発注する工事」に関して、NTT通信建設業界には以下のような業界特有の語句が使われます。

  • キャリアビジネス
  • 民需工事

当エントリでは、上記2つの語句について解説していきます。

キャリアビジネス

NTT通信建設業界においては、「NTTグループ以外の電気通信事業者1が発注する電気通信設備工事に関する事業」を指します。

キャリアビジネスとNTT発注通信設備工事は、工事種別としては「電気通信設備工事」で共通である一方、以下のような相違点があります。

  • キャリアビジネスには、全国大手3グループ以外の元請受注事業者2が存在する
  • NTT発注の通信設備工事に比べ、全体の市場規模が小さい
  • NTT発注の通信設備工事に比べ、発注者別の市場規模が小さい

民需工事

NTT通信建設業界においては、以下のような概念を指します。

文脈により、「民需工事」という言葉が何を指すかは異なる場合があります。具体的には、以下のような要素が文脈依存となる要素です。

民需工事」という表現は、「通信建設全国大手3グループが、その事業運営をNTTに強く依存している事実」を体現しているとも解釈できる表現です。特に「NTTグループ発注の電気通信設備工事」の対置概念として「民需工事」の語を用いた場合、そのような特徴は顕著に現れます。


  1. KDDIソフトバンク等、かつて新電電(NCC)と呼ばれた固定通信事業者」「NTTドコモ以外の移動体通信事業者」などを指します。

  2. NTT東西発注の通信設備工事は、「電気通信設備請負工事競争参加資格」の存在により、全国大手3グループに属する通信建設会社以外の事業者が元請受注できないようになっています。

Gitにおけるデータ管理の仕組み備忘録

Gitはデータをスナップショットとして保存する

  • 変更されたファイルの内容全体を保存する
  • 前のデータとの差分を保存しているわけではない

スナップショットを保存することのメリット

  • 頻繁に行われる基本的な操作が劇的に高速化する
    • 変更同士で差分を取る操作
    • 変更をマージする操作
    • ブランチに関する操作
      • 新規にブランチを切る操作
      • ブランチを切り替える操作
  • 堅牢なデータ管理が実現できる
    • コミット同士が疎結合になる
    • 「前のコミットの内容がないと、あるコミットの内容を復元できない」という事態が発生しない

スナップショットを保存することのデメリット

  • 巨大なファイルを扱う場合、リポジトリが肥大化しやすい
    • 特に圧縮済みバイナリファイルの管理には全く向かない

Gitリポジトリを構成する要素

blob

  • 管理対象ファイルの内容そのものを指す実体
  • git addコマンドの実行により、リポジトリ上に生成される
  • 生の内容そのものではなく、圧縮された上で保管される
    • 既に圧縮済みのバイナリファイルを管理対象とした場合、みるみるうちにリポジトリが肥大化していく
  • blobにはファイル名の情報は含まれない

tree

  • ディレクトリ構造全体のうち、変更が加えられた部分のスナップショットを表す実体
    • 一つのtreeの構成要素
      • ファイル名と対応するblobの組
      • サブディレクトリ名と対応するtreeの組
    • 変更が加えられていない部分を取得するためには、前のスナップショットを順次参照していく
  • git commitコマンドの実行により、リポジトリ上に生成される
    • その内容は、git addコマンドによりステージングエリアに生成されたindexの内容に基づいて定義される
  • 有効なtreeの条件
    • 有効なtreeは、blobまたは別のtreeを1つ以上参照していなければならない
    • treeチェーンがループすることはありえない
    • treeチェーンの末端にはblobが必要となる
  • 「空ディレクトリ」はGitでは管理できない
    • 上記の条件から導かれる

commit

  • コミットそのものの情報を表す実体
    • 誰がコミットしたか
    • いつコミットしたか
    • 1つ前のコミット
      • イニシャルコミットに1つ前のコミットは存在しない
      • 通常のコミットの場合、1つ前のコミットは1つのみ存在する
      • マージコミットの場合、1つ前のコミットは2つ以上存在する
    • コミットメッセージ
  • git commitコマンドの実行により、treeと同時にリポジトリ上に生成される
  • branchやtagは、それぞれ1つのcommitに紐づけされる
    • branchであっても、枝全体を指すわけではない
    • branchが指すcommitはあとから変更することができる
    • tagが指すcommitをあとから変更することはできない

ローカルマシンにおける、Gitに関する実体

ローカルリポジトリ

  • 管理対象文書群のスナップショットそのものを記録していく領域
  • 上記blob、tree、commitを主な内容とする
  • branchやHEADもローカルリポジトリを構成する主体である

ステージングエリア

  • ひとまとめとしてコミット処理を行いたい一連の変更をひとまとめにするための領域
index
  • ステージングエリアに存在する実体
  • 「ファイルパスと対応するblobの組」をひとまとめにしたもの
  • git commitを行うと、indexの内容から新たなtree群がローカルリポジトリに記録される

ワークスペース

  • 実際にファイルの編集作業が行われる領域
  • git add時の処理

企業内部における擬制的親子関係について考えてみた

擬制的親子関係とは

kotobank.jp

「実の親子以外の者同士が双方合意の上で有する、互いに実の親子であるかのような一定の役割関係」を指す語句です。

擬制的親子関係という習慣は、洋の東西問わず見られる習慣です。例えば以下のような関係は、擬制的親子関係の一種と言えるでしょう。

  • 日本における「烏帽子親制度」「仮親/猶子制度」
  • カトリック圏における「代父・代母/洗礼を受ける子どもの関係」

擬制的親子関係の当事者の間には、一般に「義理と人情を伴った庇護・奉仕」の関係が存在します。

企業社会における擬制的親子関係

日本における伝統的終身雇用慣習には、雇用主と被雇用者との間に、擬制的親子関係が存在すると言えるのではないかと思います。具体的な庇護・奉仕関係の内容は、以下の制度・慣習の存在が一例と言えます。

  • 雇用主が被雇用者に提供する庇護
    • 定年までの終身雇用
    • ステレオタイプ的なライフスタイルに応じ、各時点で必要となる費用を反映した給与の支給(生活給)
  • 被雇用者が雇用主に提供する奉仕
    • キャリアプランや働き方の雇用主への一任
    • 特に若年期における、自らの人材価値に対して低い報酬での労働

私個人としては、「日本においては、雇用以外にも、『発注/受注』『請負』という事業者間の関係性にも擬制的親子関係が存在する」と考えています。具体的には、「以下のような慣習に擬制的親子関係が現れている」という考えです。

  • 専属下請
  • 発注者主導による、専属性の高い受注者の組織化(協力会組織)
  • 発注者から受注者への、正当性のある説明が不可能な天下り

企業社会における擬制的親子関係の問題

企業社会における擬制的親子関係には、以下のような問題があると考えています。

  • 組織形態がヒエラルキー型にならざるを得なくなる
    • 「仮親」を頂点、「猶子」を底辺とするピラミッド型構造
  • 「猶子」と位置付けられた事業者・個人が自主性を失う
    • 性悪説的・パターナリスティックな従業員統制
    • 事業体質的にも「子ども」を脱することができなくなる
    • 従業員のマインドセットも「子ども」のそれとなる
  • 「仮親」と位置付けられた事業者において、従業員以外のステークホルダーの利益を毀損する施策が正当化される
  • 擬制的親子関係に生きる事業者・個人は、「成人同士の関係」を築くのが困難になる
    • 事業者・個人同士の関係性を、「主君と家来」のような関係性でしか見れない
    • 擬制的親子関係に生きる事業者・個人に対しては、擬制的親子関係に生きていない事業者が寄り付かなくなる
    • 所属企業で擬制的親子関係に生きてきた個人は、退職後に社会に適応できずに苦しむことになる

「企業社会における擬制的親子関係」というのは、戦後復興期~高度経済成長期~バブル期の日本において、「日本社会の勝ちパターン」として作用してきたのは確かです。しかしながら、「豊かな社会が実現し、右肩上がりの成長が見込めなくなり、量より質を提供することが求められる」という現状においては、「擬制的親子関係の存在が、社会が求める質の提供に対して足かせとなっている」のではないかと思います。