従来モデルの例
【ソフトウェア開発モデル】Ｗ字モデルと要件定義以前について。
■骨子
ソフトウェア開発モデルにおいては未だに要件定義より前の段階が加味されていないため、それを原因とした不意な工数増大が減らないままである。
それを解決する方法として要件定義を構築するまでの段階を体系化する。
以下がW字モデルの図。
従来モデルの例
一般企業での似た手法の例
世の中の中規模以上の企業の多くはＷ字モデルに近い策定方法を行う。
それはＩＴに限らず全社的な策定でだ。
典型例の流れを挙げていく：
※前述のＷ字モデル図を引用する。
→まず起点として上層部が課題を提示する。図の全体課題に相当。
※上層部の役職は様々、最上級から部長級まで該当、要は下位組織を複数抱えているもの。
※ジャンルはＩＴに限らない。この時点では特定の技術や業務だけに完全に絞っていず、あくまで課題のみ。
→その課題を配下の各部署や管轄する各業務や技術に落とし込む。図の中間課題に該当。
※中間課題は複数段階の場合も有り、大抵は多数に分岐する。
→具体的な末端の項目にまで落とし込まれる。図の個別課題に該当。
→個別の課題毎に行わなければならないことを定義していく。図の個別定義に相当。
※この時点で具体的な技術や業務が判明する。ＩＴが含まれる場合も有る。
→個別定義は上位部署に伝達され、上位部署は自部署の個別課題全体の調整や中間管理職的業務を定義する。図の中間定義に相当。
→中間定義策定の際、中間課題との整合を取る。
※以降全般においても同軸左側との整合を取る。重複なため省略。
→最後に全体的な定義まで上がる。図の全体定義に相当。
→全体定義に基づき、まずは全体的な実行計画を立てる。図の全体設計に該当。
この際に、最上位が１つ下の層（≒中間層）を把握・管理する方法も策定されると共に、個別設計策定の際の自部署内での調整も行う。
→全体定義は中間層に落とし込まれる。中間層を上位が管理する実行計画も策定。図の中間設計に該当。
前述と同じように、改装の把握・管理・調整も行う。
→末端の実行計画にまで落とし込まれる。図の個別設計に該当。
→計画に基づき、個々の末端作業や業務や技術の分野ごとに試験的実施し、必要ならば再策定。図の個別テストに相当。
→中間管理業務の試験的実施。個々の末端の実行状況を中間層視点で検証し、必要ならば再策定。図の中間テストに相当。
※結果次第では個別のに戻る。
→全体管理業務の試験的実施。個々の中間層の実行状況を上位層視点で検証し、必要ならば再策定。図の全体テストに相当。
※結果次第では中間や個別に戻る。
Ｗ字モデルとは、このような流れにおいてシステム屋の参画を重視し、汎用的に体系的にしたものだ。
コンサルタント等も元から要件定義以前の段階を担っている
まぁ、言うのもアホらしい位に当たり前のことだが、一応書く。
彼らの対象範囲はＩＴに限らない。
まず第一に顧客上層部から課題を伺い、その課題を具体的な課題にまで至らせ、それを元に実行プランを提示する。
その先を行うかはぎょうしゃや状況次第、ＩＴの場合は下請けに丸投げする場合が多いし。
それに対し、Ｗ字モデルはシステム屋が自信で行う前提のものだ。
明確にコンサルな人達以外にも居る。
システム業界の会社の一部は営業やコンサル的業務の比重が大きい。
そういう会社では、実働部隊の多くがシステム屋である反面、彼らのような「きれいなスーツ着て口調やセンスも高い人達」が一角を占めている。
そういう人達の技術的知見は軽く見られる程度、それなのに高い給料をもらってる。
結果的に出す価値が高いからだ。
彼らは技術的知見が相対劣位だからこそ自分達の活路に精を出す。
その活路だが、要件定義以降はシステム屋の方が格段に上のため、それ以降には活路なんぞ有りやしないため、その前の段階となる。
もれは要件定義以前であり、社会科学的な努力でもあり、IT以外の技術的な知識もその都度学ぶことでもある。
で、同じ会社の人達が担うためシステム屋との連携も良く、Ｗ字モデルに近い状況になる。
余談、筆者自身様々なシステム業界を渡り歩くうちに「そういう会社」に幾度も見聞きし、ぶっちゃけ技術力は低く、筆者が貰う金の割には与えられる仕事のレベルは低い（この程度の仕事でこんなに金貰えるの？って感じ）、それでも手戻りや揉め事は比較的少ないし、受注先に言い包められて無償や安値でやらされることも比較的少ないため、結果的な利益や良さそうだった。
Ｗ字モデルの詳細
ＷではなくＮ字モデルの場合も有る。
Ｗ字モデルの個別定義から始まる場合もあり、その場合はＮ字の形になる。
下位の部署からの突き上げにより対策され始めるパターン。
要件定義以降の構造はＶ字モデルと同じだが、中間段階の内容は異なる。
要するに、従来モデルは技術者の考え方で、Ｗ字モデルは利用者。
例えば従来モデルでは、外部設計・内部設計・コンポーネント・サブシステム、これらが技術用語であるのと、殆どの利用者側にはそのような概念は無い（有るのはそれを使う業種職種のみ）。
それに対し、Ｗ字モデルにおいては利用者の考え方だ。
中間と書いてある理由は、そこでの考え方が利用者が毎に異なるため、漠然と中間と書くしかないからだ。
業務や組織の分類に応じてテストや設計も分類し、機能の分け方もコンポーネントのようなシステム開発技術ではなく利用者側の技術の言い回しや分類や業務分類方法に沿う。
そういうのは要件定義以前の段階の際に利用者側から伺い、設計やテストの際に利用する。
モデル図の
矢印や線全般において、従来モデルはシステム屋の中だけであり、Ｗ字システムは利用者側に伸びでいる点でも異なる。
例えばＶ字モデルの横線は要件定義や設計を作る人とテストや実装の人との間だけで、それらはシステム屋のみ。
ウォーターフローも同様。
それに対してＷ字モデルの横線は要件定義より前にも伸びていて、それらは利用者側であるのと、先に発生するもの＝基準になるものは利用者側。
それは、考え方全般において利用者側に即することでもあり、その点でも従来モデルと異なる。
開発モデルが一向に進化しない理由は、この業界の連中が知能高くないくせに独善で自惚れていること。
従来モデルの要求定義策定関連は２０年以上前から一向に進化しておらず、認識のずれや漏れによる追加工数増大も相応のまま。
それにより、客側を察する能力どころか意欲すら欠如している現実が露呈するものの、独善や己惚れた考え方のため、誰も全く疑問としない。
要件定義以前に対する手法を育成する気が無く、全然進化しない。
そして、凝りもせずに従来モデルのような「システム業界側だけの視野や概念で決め付けれる手法」を使い続ける。
実際の知能の程度は「２０年経っても１００万人以上居ても一向に客側意図事前察知能力が改善しない程度」なくせに、自惚れ独善が一丁前なせいで自分達の知能の低さを認めないので、客を伺う気持ちなんぞ出やしない。
さらに、集団極性化により否定的見解が全く出ない、だから改善するきっかけが全く出ない。
え？？？集団極性化の意味？？？君達は頭が良いはずだから基本的な心理学用語如き知っているはずだよね？？？………まぁ、この件に限らず、理系偏重の連中は社会科学的には馬鹿である上に独善で己惚れで集団極性化によって変りようも無い傾向、それと、集団極性化という概念が無いので自分達の状況を理解しない、そのため進歩は切欠すら出ない。
上記を書いたのは理由が有る。
Ｗ字モデルを使いこなすには、最低限、自分達の頭の程度を認め、それにより自分達よりも客側の知見を重視することと、自分達よりも相手側の手法や概念を重視すること、そのような人格が必須だからだ。
このモデルは分類方法や概念等の考え方全般において利用者を基準するが、どうせ独善や自惚れが治らないなら結局自分達基準になる。
要件定義以前に多く工数をかけるモデルだが、相手側を察する意欲が高くなければどうせ多く工数を書けやしない。
例えば中間段階の構築基準は自分達ではなく相手側だ、分類の分け方や、構造の組み方や、契約や段取り方法等。
けっしてコンポーネント(笑)サブシステム(笑)のようなシステム側基準ではない………そういう考え方は「利用する相手のために作るはずなのに、自分達の考え方で作る独善」であり、「利用する相手の方がその業務の熟練なのに、自分達の手法の方が良いと思う自惚れ」だ。
しかも大した知能でないくせに………２０年経っても１００万人以上居ても改善しない程度の知能のくせに。
こういう考え方をを辞めないならばＷ字モデルを模倣してもロクな事にならないので、この時点で読むのをやめろ。
以上。
既存モデルの改善方法について
従来の開発モデルにおいて、設計以降の仕様変更への対策は、
けっして利用者側の実情を捉える能力の向上ではなく、システム屋の内部だけで解決する方法が採用される。
◇プロトタイプ開発→早く高頻度に試作品を見せれば早く細かく指摘されやすくなり、手戻りも減る戦法。
たとえ顧客を伺う能力も手法も相変わらずでも、頻度や早さを上げれば相応に顧客への伺い具合は良くなる。
◇アジャイル→開発サイクルを小刻みにすることにより、大掛かりに作ってからの仕様変更を軽減する戦法。
相変わらず手戻り頻度や量を減らせないままでも、最終段階以外のテスト工数を少なくすれば相応に二度手間も軽減するし、一気に大掛かり作らないなりに手戻りの量も減る。
◇スパイラルモデル→何度も繰り返す前提にする。凝りもせずに顧客を伺う能力も意欲も低いままなので要件定義し直し等の後追い作業は減らない、ならば、その前提のモデルにしようと言うこと。まぁ、その独り善がりさ幼稚と言うべきなものの、システムや全体が集団極性化によって幼稚さが直り用も無いならば、その現実に合わせる方が現実的である。
◇多層アーキテクチャ→設計能力の増強で有り開発モデルではない。それと用語や構造が他も手法よりも遥かにシステム屋独自の概念ばかりである。
勿論顧客を伺う能力は全く向上しないため手戻りも頻度や量も減らいものの、設計効率を上げれば手戻りの効率も上がる。
※MVCモデルも同様。
まぁ、システム屋にとっては現実的だろう………独善なために利用者側を尊重しない人格、それが集団心理化してしまって改善の見込みは全く無い、ならば、彼らの内側だけで改善する方法を進化することが現実的。
中間段階とシナリオについて
まぁ、言うのもアホらしいことだが、世の中の他の業務や会社においても、複雑な流れにおいてはシナリオ(笑)に相当するものを描く。
複雑な物事の課題の策定、実行計画の策定、試験的実施のスケジュール等は、複雑になれば当然複数に分岐したり、複数段階を経るし、きちんと流れ図の書類に起こされる事にもなる。
しかしながら、システム屋どもは井戸の中の蛙な上に、集団極性化によって認識が無いどころかシナリオ(笑)は自分達独自の高知能なもの前提なため、一々書くことにする。
無論、企業規模が大きければ複雑総代になるし、扱う事象が複雑でも相応になる。
………それは言い換えれば、世の中の他の仕事の人全般においても、相応の知能を有していることでもある。
世界最高レベルの工作機械と生産ライン、世界規模の物流から経営全般まで統合したシステム、人事関連企業の長年培った社会科学的知見を盛り込んだシステム、等々。
最低限、そこそこの規模のWebアプリケーション作る程度の奴よりも遥かに知能が高い。
それなのに、アイツらはスタバででエンターキーを強く叩くかの如く高知能ぶる。
それは、余所の職種業種の知能の程度が分からない程度の知能という証明だ。
さておき。
そういうのは利用者側の組織にて元から構築されているのと、それはＩＴシステム単体ではなく企業全体全部門のものだ。
それと、利用者側は長年にわたって試行錯誤を繰り返し洗練されているため、それは「バグが枯れた」と言うか、長年かけて問題点の洗い出しと解決を繰り返している。
その程度は、システム屋のシナリオ(笑)のような短期間で少人数で現場を見ずに描く程度の代物とは雲泥の差だ。
ならば、原則として、その「洗練された知財」を重視すべきである。
しかしながら、システム屋は自分達基準でのシナリオを使う。
W字モデルにおいては、要件定義以前を進め始める頃から客側の【シナリオに相当するもの】を伺い、設計やテストの際には使えるようにする。
Ｎ字モデルの例と、必要なこと
例えば少量多品種生産の負担改善という課題。
その課題を提示したのは現場の課長や主任で、課内だけでは対応しきれないため上層部に助けを求めたとする。
そして、その課題は上の部署や他の部署に突き上げられたとする。
解決策は色々と出てくる：
【１】負担の割に価値が低いものを減らす。
【２】段取りを早くする支援をする。
【３】似た段取りの品種の連続生産による段取り部分の減少。
【１】の場合、少量多品種の価値には顧客の引き留めも有り、その判定は営業のため、営業との連携や情報のリンクが必要だ。
さらに単一製品ごとではなくセットで納めれてこその場合も多いため（※例、特定の顧客製品のための自社部品一式）グループ化も必要だが、それも営業による。
コストには製造部署だけでなく輸送や調達も絡むが、多くの部品に共通する材料や、購入ロットや大量購入割引契約も絡むため、早々に複雑になる。
例えば、
その部品だけのために調達している素材は調達負担が特に大きいし、逆に、一括大量購入しなければならない＋一括の量の負担が既に大きいとなると減るのは不都合。
等々。
それらもシステムに組み込まなければならないし、そのためには顧客に教えてもらわなければならない、何せ、単にデータだけ見ても分からないからだ。
逆の典型例はリレーショナルデータベース(笑)、アレは同じ語句や意味のものしかリンクしないため、あんなものだけ見ているようでは論外だ。
他のデジタルデータ全般も、紐づけは機械的に同じ語句とかの何らかの同じ要素に完全に依存するため同様だ。
……同じ語句を繋げる程度のことで賢いと妄想したい奴は従来モデルを続けてろ。リレーショナルデータベース(笑)のリンクが全てだと思ってろ。どうせ曖昧な事象をリンクさせるための社会科学的な知能なんざ無いのだろ？？？
【２】の場合、技術はＩＴだけでない、生産技術やメカトロやロボットも絡む。それらとの連携が必要だ。
それに対して既存の開発システムはITしか想定していないため、全く対応できない。
ああ、社会科学的に馬鹿なだけでなく、理系分野ですら偏狭な馬鹿。
さておき。Ｗ字モデルでは、下位から週間や上位に伸びてくにあたり、様々な部署や技術にも関わっていく。
……ＩＴしか考えたくない奴は従来モデルを続けてろ。ＩＴだけで解決すると思ってろ。どうせＩＴ以外に頭回すなりの知能は無いのだろ？？？
【３】の場合、理屈上では該当部署の中だけで出来そうだが、実際の現場では、該当部署で出来る事は凡そ既にて来ている。
そりゃ、自分達だけで出来る事なんざ柔軟に動きやすいので。
結局残るのは他の事象が絡むもの、他部署や技術等や取引先等。
パターンの一つを挙げるなら納期のひっ迫、直ぐに生産しなければならない物が多いことにより、似た商品を繰り上げる副作用で他の商品の納期を繰り下げることへの余裕が無いこと。
他の原因の仮定も上げていく：
根本原因として、人材の供給が後手後手で早く生産出来ない事、この場合は人事システムとのリンクが骨子となる。
仮に調達が全体的に遅くて生産開始も遅いならば調達も関わる。
こういう遣り繰りが出来る人材が足りてない（または、理屈上は居るが他の業務の追われて手が回りにくい）ならば、現場の作業練度に関する人事システム。
等々。
各々毎に対応すべき部署や分野は異なり、対応すべき内容も広がっていく。
しかし従来のモデルはそもそもＩＴのみだけだし、相手側の事情を把握するモデルではないため、程遠い。
……広く理解する意欲が無い奴は従来モデルを続けてろ。今見てる範囲が全てだと思ってろ。どうせ現状の範囲でも頭一杯だろ？？？
上記に上げたこと全般において、まず第一に満たすべきことが有る。
顧客が本音を言い、それによって顧客の経営手法や各部署や技術のリンク状況等の自称全般をよく理解できること。
何せ、現状以上に顧客を伺う能力を挙げるためには、（システム屋の知見では限界なため）顧客からの説明が向上しなければならないので。
そのためには顧客が本音を言う信頼を得ること、そうでなければ波及範囲やリンク方法等を詳細正確に教えてもらえない。
しかし、程遠い連中が多い、例えば：
◇スーツや作業用でない靴で現場に行く、そして相手は余所者と見なす（しかも、それに全く気付かない）。
◇現場の言葉を事前に理解していず、会話で露呈する（〃）
◇相手側の用語よりも自分達の用語を使う、それは余所者、更に横文字ならば煙たい奴（〃）
◇現場に居る最中に細々と発生する雑用に無頓着、そのため気が利かないし仲間ではない（〃）
◇相手側は技術分野は違えども長年培った知財が有り、知能も十分に高いが、ＩＴ屋の発言からにじみ出る価値観から「ＩＴ屋の方が賢い」勿論気に食わない奴（〃）
◇必要に迫った時しか来ない……多くの大企業での長年の取引先は常日頃から巡回して御用聞きする、その文化に応じていない、そして金の匂いにしか来ない奴扱い（〃）。
え？コレがシステム開発と関係有るか？？？そういう考えだからだ……根本的にお前らの人格が悪い。
極力相手の言葉を使え。
原則客先での横文字用語は禁止。
原則使って良いのは利用者側全般が肯定的なものだけだ。
利用者が
使ってないものまで提示していいケースは、利用者側が横文字全般に肯定的なケースのみ。
横文字に限らず、相手の言葉を調べてそれを使え。
嫌なら既存モデルを続けてろ、それならば、コンポーネント(笑)と言う自分達に冷めた視線を送る相手に遭遇することも無いから。
Ｗ字の先頭からの場合
要は企業のトップクラスから漠然とした経営課題が出て、それを各部署に落とし込まれていくもの。
これに関しては、当モデルには共通する詳細な手法は無い、何せ、原則、相手側企業の上意下達システムの一部に組み込んでもらい、その流れに応じるのだから。
前述と同じように顧客が本音を言う信頼関係を得ることが重要、※以下同じため省略。
相手側の上意下達に参画しながら（図の○○課題）ＩＴ企業が出来る事や適切な対応方法を考えていき、逐次相手側に提案して自社の仕事を獲得していく。
上意下達が下まで達したら、その時点で必要な画面やバッチなどの各部品が凡そ見えてくるので、それで予算や工数の早期概算とする。
下から上に返っていくに伴い（図の○○定義）、各部署間の情報や知財のリンクを教えてもらい、それをシステムに組み込んでいく。
そして一番上まで戻る、つまり既存手法の要件定義に当たる部分に達し、今までの流れで得た知識を活かす。
図の左端のものについて
W字モデルが走り始める当初から把握し始めるもの。
連携方法だが、どの企業でも当然のように部署全般での連携方法が有るわけで、システム屋も加わるための連携方法を策定し、実施し始める事。
重ねて言うが「加わる」だ、けっして従来モデルのようにＳＥが自分的に用事が有ると思ってる相手だけ掻い摘むものではない
……そのような方法だから、相変わらず開発の後半に利用者側のキーパーソンに変更させられる頻度が減らないのだ。
だがしかし、従来モデルは、そもそも連携なんぞ全く触れない。
………仕事で関わる相手全般と連携することは社会人として当たり前のはずだが、システム屋は独善が酷いというか、自分達同士でしか連携しようとしない。
逆に、Ｗ字モデルは組み込む。
シナリオ：
シナリオがＩＴ業界独自の高知能なものだと思い込んでいるようだが、実際には企業全般においては複雑な業務の把握していく際には流れを詳しく把握して適時図にしたりするわけで、それがシナリオに該当するわけで、それは単に横文字(笑)で言うてないだけで、同等なものが存在する。
既存モデルおいては利用者側の「シナリオに相当するもの」なんぞ全く語句に出てこないが、
Ｗ字モデルにおいては利用者を伺う際に「シナリオに相当するもの」も伺い、それを吸収してシナリオに応用する。
契約手法も似た事情。
従来モデルにおいて契約手法を気にする相手は、案件全体の管理者だけを漠然と想定しているというか、そもそも概念すら無い。
だがしかし、実際の企業運営においては各部署や主任クラスにも契約権限が有り、一部は自分が権限を持ち、それには当然システム改修も絡む。
無論、その権限者が案件の後半でひっくり返すことは少なからず。
だがしかし、その存在すら意識しない。
仮に相手側の各々の業務の権限者と話せれば話しが早くなるし、認識のずれや「伝言ゲームによる改変」も軽減出来るのだが、程遠い。
Ｗじモデルにおいては、どれだけ可能かはさておき、出来る限り各権限者と契約の話まで出来るように目指しはすること。
各段階の詳細
■全体課題
企業全般において上層部が全体的な課題や特に重要な課題を挙げて、社内の各部署に対応要否確認や実施を迫るもので、それにシステム屋が参画すること。
そのため、システム屋が行うことは自分が主導して行うよりも、参画してシステム面での支援をすることと、自分達の仕事に出来る分を獲得ししていくこと。
参画に伴い相手側上層部や熟練技術者等から直接的に伺えるため、従来モデルが案件担当者を介した又聞きであることよりも遥かに改善する。
■中間課題
上層部の課題の落とし込みに際してシステム屋が支援する。
その際に、システム面で何を行わなければならないかの洗い出しも行う。
特に、各部署や作業間での情報面のリンクに関してはシステム屋が活躍しやすいことのため尚更。
それに伴い、どのような設計になるかの予測も進む。
■個別課題
各作業員や主任クラスレベルへの落とし込みに参画する。
その際にどのようなシステム的な処理が必要かも伺っていく。
■頒布
個別課題まで詳しく見定められた場合、まぁ企業全般では当然のことだが、きちんと文章化し、周知すべき相手を洗い出して周知する。それが頒布。
その作業にシステム屋も参画する。
頒布文章においてシステム面で何を記述すべきかの策定に参画し、それもシステム屋の売上にしていくとともに、相手側との業務の理解を高める。
頒布物は出来れば（許可を得たうえで）自社に持ち帰り、設計や実装の作業者の教育に使う、これは特に重要で、システム屋が利用者側とずれる大きな原因の一つに、末端技術者の教育に使う資料が内部だけで考えたものだけになりがちなことがあるので。
■作業定義
個々の作業の事情を伺い、それを元にした定義を作る。
必要な画面の概要や、骨子となる機能等。
場合によっては、ハリボテの画面を作って現場の人に確認や操作してもらう。
伺う相手の例は熟練作業者や主任や課長、作業の実情を把握している人。
それに伴い、上記の人物たちとの人脈も獲得し、設計や実装の際の質問を行いやすくする。
それと、末端作業員と仲良くなれば相応に言い包めやすくなる、特に、相手側にとって重要でなくて工数がかさむ物事。
■中間定義
各作業定義毎に、関連する他の部署や担当者が居るわけであり、彼らに個別定義の結果を提示し、調整やリンクを行う。
また、同じ小・中分類にすべき業務を見抜き、実際に分類一覧も生成していく。
各々の分類全体に関わる作業や管理業務や情報処理も洗い出す、そのために各要素のキーマンに伺う。その結果も定義に含める。
この件でも言い包めやすくなるのは同様。
■全体定義
中間定義と同じ要領で、各中間定義を関連する他の部署や担当にリンクしていき、そが最上部を介して一つに繋がるまで行う。
各部署や作業間で調整すべきことも洗い出した結果を相手側の上層部に提示し、その権力を借りて確定に達する。
※権力も肝心、従来モデルは権力に無頓着なため、後から相手側の権力事情により変更させられる頻度が減らない。
上記全般において、「システム屋以外と仲良くする」や「権力の把握」等の社会科学的な業務が有るが、当然それらへの興味や努力が必要と言うこと。
社会科学だけでなく他の理系分野もだが。
Ｗ字モデルとは対応範囲を社会科学全般や他の理系にまで広げることでもある。
システムだけの狭い視野で居たい奴は従来モデルを続けてろ。
あとがき 自分自身で狭い社会から脱する
まぁ、人格がシステム屋と同じような人達は理系偏重な業務全般に居る。
化学、電気、マイコン等。
※補足、機械工学や食品科学は現場や消費者への興味や意欲が高い傾向なため該当しない。
自分達の常識での独善で、それで凄いと自惚れて、実際の知能は「社会科学や他分野にまで回らない程度」のくせに一点集中した知識（＝己の領域）だけを基準に己惚れているために人間の能力全般としては成長能力以前に成長意欲すら無い。
それよりも成果に物言わせて金や地位を得ようとするので尚更直りようも無い。
※その辺の話は前作の「逆説的成果理論」参照。
だがしかし、彼らの殆どは他の種類の人達に制御されている。
彼らの業務には他技術や法務や設備やマーケティングなど多数の事象との連携が凄く重要で、そのため彼らは多数の分野から成る経営の一角に属せねばならず、実際に属し、他の物事は他の人達が遣り繰りしてくれる。
………言わば、自分自身で狭い社会から脱する必要が無い。
システム屋はそうならなかった。
ＰＣや開発ツールやネットワーク機器等の「己の技術領域の事象」だけで事業が成り立ち、実際にそうする。
だがしかし、社会科学や他の理系分野との関りが重要な事は変わりやしない。
それを軽視するから、コンサルタント等に美味しい所を奪われまくり、手戻りの損害が甚だしく、ブラック待遇も相変わらずだ。
そういう対処は他の技術分野では他の人達（同じ会社の別の職種）がやってくれるが、システム屋には居ない。
この現状から脱する対策が出来るのは、システム屋にはシステム屋自身しか居ない。
自分達自身で社会科学や他の理系分野に手を広げるしかない。