IT”ゼネコン”と呼ばれるにはワケがある! ITゼネコンの仕組みを解説
ITゼネコンとは、大規模な情報システムを請け負って作り上げる大手システムインテグレータ(Systems Integrator、SIer)のことであり、また、多重下請など同じ問題を抱える建設業界のゼネコンに、彼ら大手SIerをなぞらえた言葉です。
そして、情報システムを作る現場のつらさ・過酷さ・理不尽さを、揶揄・侮蔑する意味合いの強い言葉でもあります。
いわゆるゼネコンは、建築や工事を請け負う会社なのは皆さんもご存知でしょう。建設業界の大きな特徴と問題点は、ゼネコンを一次請けとし、二次請け、三次請け…と延々と続く、下請けの多重階層構造(多重下請)です。
ゼネコンの中でも特に大きな売上高を誇るスーパーゼネコンたち。彼らが何かにつけて批判されるのと同じように、大手SIerたちもITゼネコンの名の下に頻繁に批判されます。
ITゼネコンが批判される理由は様々です。理由としては、的を射たものも当然あります。でも、的外れなもの、単なる感情的なもの、SIerの本当の役割を知らないまま同調しただけのもの…など、首をかしげたくなるものもあります。
筆者は、ITゼネコンとされる某社にSIerの立場で長年関わり、現在は建設業界向けの情報システムに関わる立場の人間です。この記事では、そんな筆者の観点から、ITゼネコンとは何か、ITゼネコンの批判される点、ITゼネコンの本当の役割などをお伝えします。
関連記事
目次
１．ITゼネコンの特徴
ITゼネコンとは、大企業や官公庁などから大規模な情報システムを請け負う大手SIerのことです。また、大手SIerによる情報システムを作るプロジェクトに関係した、IT業界の仕組みを指すこともあります。
IT業界の文脈で「ITゼネコンだから～」と言う場合、大体は以下のようなことを指しています。
- 大手SIerが、大手企業や官公庁などから、情報システムのプロジェクトを一次請けとして直接請け負う
- 大手SIerは、自らは情報システムを作る仕事はせず、進捗管理や成果物受け入れなどの管理業務を行う
- 大手SIerは、プロジェクトの作業を細分化して、グループ内の子会社や中小のSIerなどの下請け企業へ委託する
- 作業を委託された下請け企業は、さらに下請け企業へ作業を委託する
大手SIerの立場が建設業界でのゼネコンに似て見えて、さらに後述する批判される点も似ていたので、いつしかITゼネコンと呼ばれるようになったのです。
２．ITゼネコンへの批判
ITゼネコンは批判的に使われることが多い言葉です。よく挙げられる批判は以下のもので、似たような批判がゼネコンへもされています。
- ITゼネコンへの不公平感：ITゼネコンは仕事を割り振るだけなのに、一次請けという立場で莫大な利益を得ている
- 多重下請：下請けは二次請け、三次請け…と延々と続き、下層ほど利益が少なくなり、何をしているか分からなくなる。
- 人月計算：情報システムを作る値段の見積もりはどんぶり勘定で、しかも人の能力を無視している。
- 官公需案件の寡占：大手SIerは官公需案件を寡占しており、中小SIerは仕事を得るチャンスが少ない
ITゼネコンは、IT業界が抱える問題点の縮図でもあります。この中でも、多重下請と人月計算は特に批判されます。
多重下請の中層・下層での作業を行う人達からは、ITゼネコンの体制下で仕事をした結果、もう二度とIT業界に関わりたくないという声も出るくらいです。
官公需案件の寡占については、多重下請・人月計算などが原因でコスト高になりがちなことから、ITゼネコンに仕事を与えることは税金の無駄だ、という声も少なくありません。
２-１．ITゼネコンへの不公平感
ITゼネコンはプロジェクトから利益のピンハネをしているだけではないか、という批判や不満です。仕事を割り振るだけで自分は何もせず、濡れ手で粟、気楽な立場なのは道義的に許せない、ということでしょう。
この批判の背景には、ITゼネコンやゼネコンの本当の仕事内容や役割が、世間一般にはあまり知られていない、という現状があるのかもしれません。
後述しますが、ITゼネコンの仕組みの頂点にいる大手SIerは、彼らがすべき仕事、彼らにしかできない仕事をしています。つまり、プロジェクト内での立場や役割が、下請け企業とは大きく異なるのです。
それに、ITゼネコンも大規模プロジェクトを請け負った以上は責任を持ってやり遂げるという、非常に大きなリスクを負っています。
これは建設業界のゼネコンでも同じことです。
ゼネコンは建物などの設計や技術研究なども当然行いますが、建設現場での主な役割は施工管理と呼ばれる仕事をして、建設プロジェクトをスムーズに進めることです。ゼネコンは実際の建物は作りませんが、施工管理を通じてプロジェクトの安全管理、工程管理、原価管理、品質管理などに最終的な責任を持っています。
２-２．多重下請
２-２-１．多重下請の問題点
一次請けであるITゼネコンから、二次請け、三次請け、四次請け…と続く多重下請は、例えば以下のような問題を生みます。
- 作業が細かくなり過ぎて、自分が何を作っているのかわからない
- やっていることはごく単純なことだけで、ITスキルが伸ばせない、身に着けても生かせない
- 自分がどの会社の立場でプロジェクトに参加しているのかわからない
- 上位層からは、とにかく納期内に指示どおりに作ることを求められ、例外が許されない
- 上位層へのコミュニケーションを取ることが難しい
- 上位層は当然マージンを取るので、下位層になるほど利益が急速に少なくなる
これはIT業界の悪いイメージ、すなわちブラック、デジタル土方、デスマーチ、新3K(きつい、厳しい、帰れない)などの根源とも言えます。「土方」という言葉のとおり、建設業界に代表されるような「労働集約的」な業界である、というイメージを持たれてしまっているようです。
多重下請は、他の業界でも普通に行われていますし、もちろん合法です。ですから、多重下請そのものが、何が何でもなくすべき大問題だというわけではありません。
でも、人月計算のところでお伝えしますが、多重下請は人月計算の問題とも深く関係していると見てもいいと思われます。それに、プロジェクトの規模が大きくなって多重下請が続くと、現場の指示系統も混乱しますし、違法な偽装請負の状況に簡単になりかねないのは問題です。
もちろん、これが本来あるべき姿だとは、IT業界の誰も思っていません。IT業界の皆が是正すべきと思っていますし、国もこの状況を良しとはしていませんが、すぐには大きな改善が見られることはなさそうです。
２-２-２．多重下請はマンパワーを確保するための仕組み
現在のIT業界は、多重下請により作業者を流動的に確保できる体制を作りつつ、企業としてのリスク回避をしています。プロジェクトに必要なマンパワーを確保し、労働集約的な体制を作るには、現在の日本のIT業界の状況・構造ではどうしても多重下請になるのです。
ITゼネコンは、プロジェクトに必要なマンパワー全てを自社で抱えたくはありません。多くの社員を直接雇用すること自体が、企業にはリスクなのです。プロジェクトがない時も社員を雇用していると、給料の支払いが企業にはコストになり、利益を大きく圧迫して、企業の存続にも影響します。
ですから、ITゼネコンは下請け企業にマンパワーを求めます。でも、それら下請け企業も自社では多くの社員を雇用したくないので…と続きます。
しかも、そこに昨今のIT業界全体でのマンパワー不足が重なり、さらに状況を悪くしています。
２-３．人月計算
２-３-１．人月計算とは規模の計算
人月計算とは、何かの見積をする時に、これは“普通のエンジニア“なら「何人」で「何ヶ月(何日)」かければ作れるだろうか…と計算することです。
IT業界では、情報システムの規模を「作業者の人数×投入月数(日数)」である人月で表します。
その結果、情報システムの値段は、人月に作業者の月当たり単価を掛けた金額、購入するソフトウェアやハードウェアなどの金額、ネットワーク構築・運用にかかる費用、そして会社が得る利益を考慮しながら、色々な金額を積み上げて説明されるのです。
２-３-２．他業界での見積
人月は、人によってはずいぶんと乱暴な話だと思われたでしょう。特に、非常に細かいコスト計算をする製造業の人は、とても信じられないでしょう。
歴史が長い業界なら、この作業はこの規模だと何人がこの時間かけてやるものだという、標準化された値(標準工数、標準時間など)があります。それを使えば、受発注側双方にとって、しっかりとした根拠や納得感のある見積金額になることが期待できるのです。
建設業界でも発注金額の公平性や透明性のために、労務単価や積算基準などの、公になった明確な基準があります。
２-３-３．IT業界での見積
IT業界には、作り上げるべき、あるいは作り上げた情報システムの「価値」を測るための、明確・公平な基準がありません。代わりに情報システムの規模で測るのですが、規模を測る上でも人月以上に計算しやすく扱いやすい指標を編み出せていない、ということでもあります。
それに、人月は情報システムの値段を説明するために、システムの発注者であるお客様からも提示を求められることも普通です。お客様からは、プロジェクト全体の規模感を感覚的に掴めるので、分かりやすいと思われているようです。情報システム構築プロジェクトの費用はほとんどが人件費だから、という事情もあるでしょう。
人月と併用して、プログラムの行数での規模計測もよく行われます。作るべき画面数、帳票数、バッチ処理数などに、標準的な1機能ごとのプログラム行数を掛け算して、情報システム全体のプログラム行数を計算します。でも、プログラムの行数はどうやってプログラムを作るかや、特にプログラマのスキルにより非常に大きく変わるので、信頼度は決して高くありません。
これが情報システムの規模の測りづらさです。
２-３-４．人月計算は多重下請と相性がいい
人月計算は、前述した多重下請をする際の企業間での発注方法と相性がいいことも見逃せません。
下請け企業との契約内容は、「～というシステムの一部を作る」という完成物ベース(=請負契約)ではなく、「何人・何ヶ月分の労働力を提供する」というもの(=準委任契約)が多く、これはまさに人月の考え方なのです。
また、下請け企業も契約を労働力の提供のみとすることで、プロジェクトが上手くいかなかった時のリスクを負うことを、企業として回避しています。それに、作業者の数を確保できれば契約上は問題ありませんし、作業者によほどの問題がなければ、金額は少ないかもしれませんが企業は確実に利益を得られます。
ですから、下請け企業は色々な手段や経路を使って人をかき集めますし、これがITゼネコンは人の使い捨てを促しているという批判にも繋がるのです。
２-４．官公需案件の寡占
２-４-１．官公需案件の寡占は実績と信頼の裏返しでもある
ITゼネコンによる官公需案件の寡占というと、賄賂、天下り、不当廉売など、まさに癒着の温床のように思えたりもします。事実、そういうものはあります。贈賄罪などで告発された事例にも事欠きませんし、たまにニュースにもなります。
ですが、実際はもっと現実的な理由があります。官公庁は、皆の大事な税金を使うからこそ、確実に情報システムを作ってくれて、ずっと運用してくれる企業を選んでいる、とも言えるのです。
ITゼネコンは、ずっと昔から官公需案件を手掛けてきました。今動いている情報システムも、ITゼネコンが作って、ずっと運用してきました。何かの業務や制度に現場で最も精通しているのは、実際のところITゼネコンに属するベテランSEだ、ということもごく普通です。
それくらい、ITゼネコンはお客様である官公庁のことを業務・制度・経緯・展望含めて昔から知り尽くしていて、他企業の追随を許しません。
この長年の実績と信頼を覆すのはかなり難しく、ITゼネコンが官公需案件を寡占している一因でもあります。
２-４-２．官公需案件は期限内に必ず実現しなければならない
中小SIerでは作るべき情報システムの規模や納期に耐えきれず、途中脱落することもあり得ます。民間企業向けの情報システムならまだいいのですが、官公需案件では途中脱落は許されません。
しかも、情報システムを作る理由となる法律などの施行日は決まっていて伸ばせないので、何が起きようとも絶対に間に合わせなければなりません。
そこで物を言うのが、情報システムを請け負った企業の規模、体力、そして今までどのような情報システムを作って運用してきたか、と言う経験なのです。
もちろん、現在の情報システムがITゼネコンが作ったものであることも、実に大きな影響を及ぼしています。情報システムの仕様や動き方、運用の仕方や蓄積したノウハウなどは、他企業へ一朝一夕には引き継げないものだからです。
３．ITゼネコンの本当の役割
ITゼネコンは、大規模なプロジェクトを責任をもってやり遂げるための体制であるとも言えるでしょう。ITゼネコンは、ゼネコンと同じように、プロジェクトや会社の内部・外部からの想像を絶するプレッシャーの中、自分がやるべき、自分にしかできない役割を果たしています。
ゼネコン・ITゼネコンに共通しているのは、建物や情報システムを自分自身で作らないからこそ、客観的な視点でのマネジメントができることです。マネジメントは、ある意味では、モノを実際に作るよりもはるかに難しいとさえ言える仕事なのです。
さきほど、ゼネコンの建設現場での主な役割は、建設プロジェクトをスムーズに進めるための施工管理であると書きました。ここでは施工管理の四大要素である、安全管理、工程管理、原価管理、品質管理になぞらえて、ITゼネコンの本当の役割を説明します。
３-１．安全管理
３-１-１．ゼネコンの安全管理
ゼネコンの安全管理とは、建設現場で働く作業員の安全を何よりも優先して確保し、徹底し、維持することです。つまり人命最優先ということですが、そうしないと建設プロジェクトの存続や、下手をすればゼネコンの会社としての存続に致命的な影響があるからです。
３-１-２．ITゼネコンの安全管理
ITゼネコンでは人命に直結するような仕事はしませんので、ゼネコンと同じ意味での安全管理は行いません。でも、ITゼネコンが作り上げる情報システムは医療の現場で使われるものもありますので、安全への意識や緊張感は同じです。
それに、プロジェクトの存続に関わるリスクへは予防措置をし、早急に察知し、適切に対処して安全に進めなければなりません。
ITゼネコン内の打ち合わせ、あるいはお客様との打ち合わせでは、リスク検知と対処、予防措置や是正処置がどのように行われているかが主な議題です。作業進捗も大事な報告内容ですが、進捗は予定どおりに進むのが当たり前であり、そのためにどんな手を打ったかがITゼネコンが評価されるポイントです。
そのために、ITゼネコンはプロジェクトの情報をフォーマル・インフォーマルの区別なく、常に広範囲に収集して分析しています。そうしないと、プロジェクトの存続に関わるような未検知のリスクを抱えたまま、プロジェクトが進んでしまうからです。
３-２．工程管理
３-２-１．ゼネコンの工程管理
ゼネコンの工程管理は、作業そのものの納期に直結する大事な作業です。特に、作業員の手配や資材発注にかかるリードタイムとの関係もあり、作業は確実に予定どおりに進めなければなりません。
建物の設計図は、承認をいただいてしまえば変わりません。建物というハードウェアを作り始めてしまえば、変更も原則として行いません。出来上がる建物のイメージは、設計図から起こしたイラストやCGなどである程度具体的に表現できますので、出来上がるモノをお客様は事前に確認できます。
ですから、確定した設計図から作業工程を全て導き出してしまえば、あとはいかにして予定どおりに進めるか、になります。
３-２-２．ITゼネコンの工程管理
ITゼネコンでも、情報システム全体の設計図に相当する要件定義書から作業工程を導き出して、作業進捗の管理を行います。納期を絶対に守るために、できるだけ細かい粒度・頻度で作業の進捗を確認し、問題がありそうなら早急に手を打ちます。
ただ、ITゼネコンの工程管理での大きな問題の一つは、情報システムの要件や仕様がなかなか確定できないことと、後からでも比較的簡単に覆ることです。
ソフトウェアからできている情報システムは、目に見える形がないので、完成形のイメージをお客様と合意するのが難しいのです。ITゼネコンが情報システムの要件・仕様を決める時は、なるべくお客様にも分かりやすい文書・イメージ・図表を使うよう努力しています。でも、内容がどうしても専門的になりがちなこともあり、専門知識がないと理解しづらいものもあります。
それに、ソフトウェアなので後からでも変更ができるとお客様は考えがちです。それは、こうすると決めてお客様と合意してからもです。要件を決める時に漏れていたものの追加が必須だとか、この機能がなければ情報システムにお金を払わないという、強要にも近いご要望も出ます。
ITゼネコンはそんな理不尽な調整を、プロジェクトが始まってから終わるまで、お客様やプロジェクト内部・外部のステークホルダーと常にしているのです。あいまいなところも多い情報システムを整合性を持った形に何とかするべく、必死に努力を続けています。
３-３．原価管理
３-３-１．ゼネコンの原価管理
ゼネコンの原価管理は、建設工事で実際に使った人件費や材料費などのコストが、計画したとおりかを日々確認することです。これは、建設プロジェクトから得られるはずの利益が、予定どおりになるかどうかの命綱です。それに、ゼネコンが適切な会計処理(例えば工事進行基準)を行うための情報収集も兼ねています。
３-３-２．ITゼネコンの原価管理
同じように、ITゼネコンの原価管理とは、プロジェクトの利益が確保できるよう投入コストを管理することです。情報システムを作るコストのほとんどは人件費です。人件費は自社社員の投入分もありますが、ほとんどは下請け企業への発注分が占めます。
情報システムを作る仕事は、前述のとおり非常に不安定なものです。作っていたものの仕様が突然変わるとか、機能の追加は日常茶飯事です。また、下請け企業の作業要員はスキルレベルや作業品質が不安定なことも多く、予定どおりの発注では情報システムを作り切れない場合も多々あります。
そんな場合は下請け企業への追加発注を行いますが、これはコストに直撃します。後の工程に投入するはずだった要員も少なくなってしまいます。プロジェクトの利益を削ってなんとかしたとしても、良くて収支トントン、あるいは赤字になることもあります。プロジェクトは大炎上することもありますので、ITゼネコンの会社全体で何とか黒字、ということも珍しくはないでしょう。
ITゼネコンの社員は、常にこのようなコスト意識を持ってプロジェクトに臨んでいます。
下請け企業を選ぶ時も、今までしっかり仕事をしてくれた実績があるか、急な要員増の依頼に対応してくれるか、という視点で常に評価を繰り返しています。必ずしも、今までの付き合いが長いから…というような、なあなあな、いい加減な理由で選んではいません。
３-４．品質管理
３-４-１．ゼネコンの品質管理
ゼネコンの品質管理は、作った建物が設計図や色々な基準を満たすように作られているか、確認と記録をすることです。作業結果の現物をしっかりと確認して、写真などで明確な確証を得て、文書できちんと残します。建物が一旦形になってしまうと、後からやりなおすのはとても難しいので、工程が終わったタイミングで確実に品質を確認するのです。
３-４-２．ITゼネコンの品質管理
ITゼネコンの品質管理もゼネコンと同じで、各工程での成果物確認が基本となります。ですが、ゼネコンとまったく違うのは、確認すべき現物がソフトウェアおよびソフトウェアを動かした結果だということです。
下請け企業の成果物は、しっかりした企業なら必ずレビューし、指摘をします。プロジェクト内、あるいは企業には達成すべき品質基準がありますので、基準に沿った数字になるまでは、指摘と確認の作業がひたすら続きます。工程が進む際に集まってくる情報を分析して、発生が予想される品質リスクへの早期対応も必要となります。
何よりも、情報システムの「全体視点」から品質上の問題点を指摘できる能力を持つのが、ITゼネコンです。下請け企業は担当する機能だけに注視してしまう傾向があり、全体視点で問題ないかの視点が欠けがちになります。全体では何百以上もの画面・帳票・バッチ処理からなるような、大規模かつ複雑なシステムを破たんなくまとめあげ、お客様が業務を問題なく行える品質まで持って行くのは、並大抵の努力では決してできないことです。
また、プロジェクト内での様々な基準を定め、下請け企業に基準に沿って仕事をしてもらうよう指導するのも大事な役割です。そのような、品質確保のための努力を地道に続けています。
４．ITゼネコンを少しでも良くするために
４-１．価値に基づいた考え方をする
情報システムを、規模ではなく「価値」で評価していくこと。これがITゼネコンに代表されるIT業界の問題点を少しでも良くするための施策です。情報システムで出来るようになることの価値に対して、どれだけの値段を今付けるべきかと、SIerもお客様も考え方を改めることでもあります。
建設業や製造業では、全体を小さな部分に分解し、それぞれにかかるコストを積み上げて、全体のコストを計算します。部分のコストを積み上げる考え方は、標準的なやり方でのコストを積み上げることでもあるので、最終的には人月の考え方に繋がってしまいます。そして、このコスト計算には、作り上げたものが発揮する価値という思想はないのです。
IT業界の特徴は、知識集約的な面が強いことです。もちろん労働集約的・資本集約的な面もありますが、本質的には知識集約的な傾向の業界です。お客様は今抱えている問題・課題へのソリューションを、その道のプロフェッショナルたるIT企業へ常に求めています。問題・課題へのソリューションが具体的な形となったのが情報システムだということを、忘れてはいけません。
つまり、適切な対価を求めることを当たり前にしよう、対価の基準を規模ベースではなく価値ベースにしよう、ということです。決して、提供する情報システムに無茶な値付けをして暴利をむさぼれ、と言っているのではありません。
情報システムは、一品ものやワンオフな製品に近い、フルオーダーで作られる性質を持ったものです。一品ものやワンオフな製品はそれ自体に高い価値があり、またお客様がその価値に納得しているからこそ、適切な対価を支払っていただけるのです。
４-２．価値への対価を得る姿勢
下請け企業も労働力を時間売りで提供するのではなく、プロフェッショナルとしてのソリューションを提供できなければなりません。これが終わらない多重下請から下請け企業が逃れるためにやるべきことの一つです。
プロフェッショナルとしての価値を具体的なアウトプットとして提供することこそが、IT業界に属する企業の存在意義です。アウトプットにコミットすることこそが、アウトプットの価値に対して正当な対価を主張し、支払っていただくための根拠となるのです。
下請け企業もアウトプットにコミットすることで、今までは負っていなかった責任やリスクを抱えることになります。しかし、だからこそ、仕事のやり方を自身の裁量内で比較的自由にコントロール出来るようになるのです。
そのためには、企業に所属するエンジニアをITのプロフェッショナルとして育て上げて、本当の意味での実力を付けさせることが必要です。エンジニアを使い潰すのではなく、企業の価値を高めるために必要不可欠な、大事な「人財」として育て上げるための投資をすることでもあるのです。
そしてこれこそが、IT業界全体を活性化させ、魅力的な業界として今後も継続させるために、本当に必要なことです。
４-３．価値を実現する上での必須レベルを探る
官公需案件ではフルスペックの情報システムを一度に作らなければならない…という事情も、ITゼネコンの仕事に影響を与えています。一年以内に必要な作業を終わらせなければならないという単年度予算に基づく発注が基本であり、次年度以降も予算が付くとは限らないためです。
ここに、情報システムを少しずつ良くしていくという考え方を、広く導入していきたいものです。すなわち、情報システムが実現すべきことの必須レベルを探り、必要な価値を最終的には発揮できるよう、段階的に実現していくというやり方です。大きく複雑な情報システムを一気に作らなければならないという制約が、労働集約的なプロジェクトのスタイルとなる一因でもあるからです。
国の予算改革として複数年度予算制度なども検討されていますので、これらの動きと息を合わせて、ITゼネコンの仕事のやり方そのものを変えていかなければなりません。
また、ITゼネコンの情報システムがコスト高になるのは、実は一品ものでなくてもいい情報システムに、一品もののやり方を適用しているからでもあります。
現在は、デジタル・ガバメントやガバメントクラウドの実現に向けた大きな動きもありますので、これを機にIT業界が一丸となって、情報システムの作り方、情報システム間の連携のやり方を考え直すチャンスだとも言えるでしょう。
５．さいごに
この記事では、ITゼネコンの問題点と、彼らが負っている役割をお伝えしてきました。大規模なプロジェクトを請け負い、支障なく進めることに責任を持つのは、それだけでも大変なことなのです。
ITゼネコンは濡れ手で粟な、気楽な商売では決してありません。でも、会社の業績を確実に維持できる既存権益を守るべく、発注者とこっそり示し合せる例には事欠きません。全てのITゼネコンでのプロジェクトで、お伝えしたような役割や義務をITゼネコンが果たしていると言うつもりもありません。下請け企業に仕事を丸投げして、自分は何も行わない…という仕事のやり方のプロジェクトがあるのも、残念ながら事実です。
しかし、情報システムに限らず何かを作るという仕事には、全ての参加者がプロフェッショナルとして果たすべき役割があります。モノを作る、マネジメントをする、それらをきちんと作業分担して、一つの大きなものを、責任を持って共に作っていかなければならないのです。
そのためには、プロジェクトの参加者間の信頼関係が必要です。それぞれの役割のプロフェッショナルであることを、お互いに認識して尊重できるようにならなければなりません。お互いにいがみ合っているだけでは、文句を言っているだけでは、決して何も良くならないのです。
良い情報システムを作るための試行錯誤は、まだこれからも続きます。IT業界は、せいぜい数十年程度しか続いていない、まだとても歴史が浅い業界だからです。製造業や建設業などのように、人類の歴史が始まってから数千年も続いていて、経験やノウハウが蓄積された業界ではないのです。
今後、IT業界の特徴である変化への柔軟さを活かした変革が行われることを期待しながら、筆をおくことにします。
関連記事
コメント