  |
はてなキーワード:ITゼネコンとは
ただしスタンドアロンのアプリを書いてる人については特に問題ない。
要はシステム構成がWindowsPC1台orスマホ1台のみで済むとか、組み込みとかね。
それからITゼネコンの末端で、詳細設計をコードに翻訳するライン工もどきみたいな立場の人も別に知らなくていいけど、それもうプログラマーじゃなくて単なるコーダーだよね。
こういうこと書くと
とか言い出すやつが絶対にいるんだけど、今やクラサバモデルのシステムは開発のメインボリュームで、かなりの数の開発者に関係する話じゃねーの？って思うから言ってるわけで。
あと、Linuxというか本当はUNIXなんだけど、現状サーバ用途のUNIX系OSがほぼLinuxで占められているので。
なんでLinuxが使えないと問題かというと、実際にサーバを運用しているエンジニアとまともにコミュニケーションが取れないから。
それが回り回って開発と運用が対立する、あるいは何かあったときに適切に連携できなくなる遠因になる。
本当は開発側がサーバ側の運用設計まで書いて、運用するSEに承認してもらうまでが仕事。
そのためには自分が作るシステムの動作環境の構築は自力でできなきゃダメだし、そのためにはLinuxの基本的な使い方を知っている必要があるわけで。
それにネットワークプログラミングなのだからある程度のネットワークの知識は必須で、Linuxも扱えない人がそういう専門家になれるとは到底思えない。
まあ流石にスイッチ・アプライアンス・ストレージみたいな話になると、カネ払ってベンダーのセミナーを受講しないとわからないと思うので正直厳しい。
その場合でも、Linuxに触れることで身につけたネットワークの知識が不要ではないどころか、
「今こちらのサーバでこういうコマンドを実行した結果がこうで・・・」
みたいな話をインフラエンジニア相手にできるとできないでは大きな差がある。
最近の流れで、そこらへんを全部クラウドにお任せするにしても、サーバとは一体何者か？レベルは体験的に知っておいたほうがよさそうだし。
昨日バズったワコムの件で思い出した。
1990年代前半から半ば。海外ではすでに産声を上げて久しかったMacとWindowsがさあこれから普及と言う段階だった。
同じ時期、日本ではパソコン関連の企業に旧オウムを始めとしたカルト教団のフロント企業（マハーポーシャなど）が紛れ込んでいることが結構な社会問題となり、パソコン関連の仕事に就くことが忌避されていた。例外はNTTデータ通信（現NTT DATA)や富士通やNECなど、後にITゼネコンと呼ばれるような誰もが知ってる大企業に限られた。「パソコン関連の仕事に就く」と言っても、その相手先が誰も知らないようなベンチャーとかだったりすると親族が全力で止めにかかると言う社会だった。
日本のIT業界が世界に対して立ち遅れたのはこの影響で5年くらいの遅れが発生したのが痛かったとみている。海外では次々と優秀なエンジニアがMac/Windows普及やブラウザ開発、Javaの立ち上げなどに投入されていく中、日本ではIT系に人を入れない方向に社会が動いていたからだ。
もしかしたら、オウムや統一教会などのカルトは日本のIT業界が立ち遅れることを狙って海外から派遣されたスパイなのかも知れない、がそこまでは考えすぎか?
IT土方からコンサル業界に転身した増田がコンサル業界の良いところを列挙してあげよう。
トップクラスの企業は言うまでもなく、二次請けクラスの企業でも割と簡単に年収1000万は行ける。IT業界だとITゼネコンの管理職クラスにならないともらえない年収だ。
これがIT土方との一番の違いと言えるだろう。お守りするシステムを持たないから、土日や深夜にシステムトラブルで急に呼び出されることはない。もちろん大事なプレゼンの間際の土日出社や深夜残業は発生しえるが、急に呼び出されることはなく、予定している休日はしっかり休める。
基本的に客先常駐かテレワークなので、間接業務…いわゆる会社の雑用が少ない。業務や自己研鑽に集中できる
IT土方も名目上は裁量性が高い職務とされているが、実際はWBS（アジャイル開発ならスプリントバックログ）という管理ツールで15分～1時間単位で管理されているのが実態だ。そんなのに裁量性はないだろう。
コンサルでもWBSは一応あるが、せいぜい１日単位の管理であり、裁量性はIT土方とは比べ物にならない。
IT土方が大企業顧客の幹部と顔合わせ出来ることはない。あるとしたら大規模障害やらかしてスケープゴートにされる時くらいだ。一方、コンサルは大企業顧客の幹部に提言をするのが仕事だ。嫌でも顔合わせ出来るし、そこでよい成果を出せれば後々の人生にも大いにプラスになる。最初の顔合わせ時も、まともなコンサル会社なら先輩コンサルがナビゲートしてくれるから安心だ。
IT土方は請負なので、成果物に対する瑕疵担保（契約適合）責任が発生する。近年の民法改正で責任期間は無制限になってしまった。つまり何かを請負で作ったら一生責任を負わないといけない。一方、コンサルは準委任もしくは派遣なので、成果物に対する責任はない。作ったらおしまいだ。
責任が軽く、裁量性は高く、休日はしっかり休め、後々役に立つ人脈が作れ、かつ給料が高いのがコンサルティング業界だ。東大生などの優秀な学生が殺到するのも当然だろう。
「赦し」がないから以外に何が考えられるのか。
むしろコンピュータとは、人類の「赦し」を試すために生まれてきたのかもしれない。
バグが出ても「赦す」、デグレードしても「赦す」、納期が遅れても「赦す」だけでよい。
そんなことは絶対に無理だろうと皆思うだろう。
SIの客、ITゼネコンの客、ユーザー企業の客…というように辿ってゆくと、最終的には個人消費者に至る。
個人消費者はどうか。
ミスを犯した企業は全て「悪徳企業」で、叩こうが虐めようが全てが正義だ。
つまり、IT業界をブラックにしている責任は、IT業界の末端のエンジニアを含む日本人全員にある。
私も似たような所にいたのでデジャブかと思った。ただ俺の場合は某大手メーカー。
ディープラーニングをこき下ろして自分たちのAIがより優れていると宣伝するのはどこの業界も同じなんだな。
某大手メーカーの研究所で作られたそのAIは「ディープラーニングのような旧世代の単純なものではなく、次世代の汎用人工知能」といった触れ込みで
AI事業をやっている我々SE部隊の所に降りてきた。AI事業というとかっこいいが、その中のSEは基本的に技術的なことはわからずITゼネコンの頂点として
PMをやっているような人たちが大半を占めるため、「技術的に顧客価値につながるか」ではなく、「顧客をその気にさせるパワポが用意されているか」の
ほうがよっぽど重要だった。また開発した研究所の方も、主任研究者だけは「そのAIすごい！」って心から信じてたみたいだが(笑)、
おそらくその他の研究者は詐欺っぷりには気づいていたと思う。でも「どうせSE土方共にはばれないだろｗ」という感じで押し付けてきた感あった。
その主任開発者の態度はまさに同じだったね。「なんでもできます。でも『チューニング』の必要があるのでPoCの費用はいただきます。」
という感じ。俺はそれをそのままスルーして客に伝えると「かの有名な○○さんがそういうならそうなんだな！」という感じで客は納得し、
数M～数百Mの金をポンと出す。PoCバブルの2018年頃はそんなボロい商売がいっぱい転がっていた。
しかし、このAIの中身は単に線形回帰程度しかしていないポンコツであり、ディープラーニングと比べるのもおこがましい代物。
「チューニング」といわれるものは実は有効な特徴量などを頑張ってSEや平の研究者が死にものぐるいで見つける作業であり、
全然「チューニング」レベルの話ではない。完全にカスタムAIをSIで作るような作業だった。しかも適当な特徴量でもある程度良い成果を出す
LightGBMやDeep Learningの使用は禁止され、ポンコツAIでも良い成果を出すような特徴量を見つけるという縛りプレイだった。
さらにアルゴリズムの部分がしょぼいだけではなく、エンジニアリングの部分もひどいものだった。
企業のソフトウェアプロダクトというのは開発した人ならわかるだろうが、一部のスーパープロダクトを除いて、正直コードやロジックは大したことがない。
でもテストは少しはしていてドキュメントは揃ってなんとか動くとか、使うための人力サポートは用意しているとか、最低限顧客を
ところが、だ。このAIに関してはデータサイエンス・アルゴリズムだけでなくソフトウェア・エンジニアリングの酷さもすごいものだった。
簡単なメモがあるだけでドキュメントはほぼ皆無、データを食わせると3回に1回はまともに動かない、非公開とゴネられたので
無理やり引っ張り出したコードを見ると大学生が卒検のために書きなぐったようなコード。おまけに「アルゴリズム」という名のくせに計算量解析すら
されていないロジック（そのため特定のサイズや値のデータを入れるとハングする）。
ここで疑問に思うのは「なぜこんなポンコツAIが全社的代表プロダクトになれたのか」であろう。
とにかくポンコツであることはひた隠しにして「次世代の汎用人工知能」というブランディングだけを
ひたすらフロントを使って確立させた事が大きい。さらに開発者は徹底的に外部の雑誌を避け自社の雑誌にのみ論文を大量に投稿し、
社外成果は特許、プレスリリース、雑誌のインタビューに絞ることでプレゼンスを上げるということをやっていた。
（当然だがディープラーニングより優れているなんて社外の学術雑誌に投稿しても「は？またトンデモ論文か」と言われてRejectされるだけである）
そしてこれこそがITゼネコンの真髄とも言うべきところであるが、子会社に専門部隊を作りいつでもそのAIを使ったビジネスをReady状態にする
社内体制づくりをしっかりやったところが大きい。例えばPFNあたりが「うちすごいAIあるんすよー」っていってよくわからん若造（実は東大IS Dr.）
とかが出てきて専門用語を並べ立てたりすると、古い企業からすれば「（どうも信用ならん・・・ほんとにコイツら仕事できるのか？）」となるだろう。
しかし、スーツをビシッと決めた営業と多少技術もわかるSE（もちろんスーツ）が来て、アルゴリズムの説明は一切なく、「ビジネスにどう効果があるのか」
「エンドユーザーへのインパクト」「金銭的効果」など一般人にわかりやすいパワポで説明し、来週から定例会議や進捗会議などPM面もおまかせ、
ふわっとした状態からの要件定義でもやってみせます！といわれる「（これは・・・いける！！）」となるのである。
また2018年あたりは顧客の方も偉い人から「AI使ってなんかしろ」という予算枠だけ用意されたふわっとした状態なので優れたアルゴリズムを使いたい
わけではなく、「AIを使ってビジネスしてます感」が重要なので、ここに刺さったのが大きかったね。
１．ITゼネコン元受けにおける旧電電ファミリー（NTTグループ、NEC、富士通、等）の占有率の高さ
組織体質が古臭い。組合支配による現業重視、エンジニア軽視。経営陣も組合との関係をうまくやってきた労務畑が強い。
予算と工数管理の手法がゼネコン的なウォーターフォールから抜けられない。多重下請け・人売り企業の繁栄。技術力よりもいざというときに赤字出しても責任とれる財務力が大事。
その年に使った開発費を損金計上できないので、税負担が重い。投資にブレーキがかかる。
セキュリティ統括部署のトップがエンジニアでなく法務出身だったりするので、わけわからずリスクゼロにしろと主張する。
５．エンジニアの雇用流動性が低い。エンジニアのキャリアパスが頭打ち。
年功賃金のため若い時に実績を上げても給料には反映されない。中高年になって偉くなるのは接待にたけた文系ばかり。エンジニアは中韓企業に高給で引き抜かれても、文系は忠誠心がないとなじるだけでポストは渡さない。社長は理系でも取り巻きは文系。
Winny事件が典型だが、法曹・警察権力は自分の権限拡大のためなら技術革新なんてなんとも思ってない。右翼も左翼も法学部出はほぼ同じ考え方。
そもそもITゼネコン主導の大規模開発は悪評まみれで、天国案件なんて数えるほどしかないと言われる。
なので誰がやってもしんどいと思うが、特に自分には全く合わなかった。
自分のプログラミングは、動かす前に「これで行けるだろう」と確信しながら、動かしてみて抜けや漏れが発覚するタイプなので、コードの品質は多分悪い部類に入るだろう。
つーか、仕事なんて楽に済ませたいから、コードなんて可能な限り書きたくないというのが一番にある、かなり独善的な人間だ。
一方で大規模SIのプログラマなんて、基本的にライン工か調整役以外お呼びでない。
そしてコミュ障でもある自分は必然的に、もらった設計書の長ーいフローをひたすらコードに翻訳するという、まさにライン工として身を粉にして働くしかなかった。
それこそif文の後のelseが何ページも先になろうが、ループが何重にネストしようが一切気にせず、可能な限り設計に沿うようコードを書き続けた。
元々コードを書かずに済ませたい自分には、正直目が眩みそうな作業だったが仕方ない。
しかし上述のように元来不注意な人間なので、品質は恐らくメンバーの中では最低レベルの代物を量産する結果となった。
コーディングもスケジュール的に余裕なかったが、テストに至っては必死にというか、死に物狂いで頑張らないと遅れてしまうくらい、作業量が半端なかった。
ちょっと込み入ったメソッドになると、それだけでテストケースが20とか30とか相当な数になるので、ケースの抽出から始まって、最終的にレポートにまとめてカバレッジと一緒に提出するまで、地獄のような作業の連続になった。
最終的には体調不良を理由に「すんませんクビにしてください」と言って現場を抜け、その責任を取って僻地に飛ばされ今に至る。
そんなことはどうでもいいのだが、それ以来、テスト自動化ツールに対しては、理屈抜きに憎しみしか沸かないようになった。
フレームワークの便利さを推す記事とか、むやみに持ち上げるヤツは一切信用できなくなったし、オブジェクト志向をやたら崇高で革命的なもののように吹聴するやつはもっと信用できなくなった。
↑の元増田です。
前提として、日本でシステム開発において、利益の中核になっているのは官公庁や大企業の基幹システム開発なわけで、ITエンジニアもほぼイコールそういうブラック上等の大規模案件でこき使われる人たちなわけだ。
んで、大元の意図としては、そんなブラック案件でお前らのやっていることはサイエンスでもエンジニアリングでもねーだろ？悔しかったら反論してみろよwwwという嘲笑ありきの煽りエントリだったわけ。
そしたら、本当にごく一部の一握りの中の、そのまた上澄みの更に一つまみレベルの、大真面目にサイエンスやエンジニアリングやってそうな人らからトラバが来たけど、肝心要のITゼネコン様(笑)とその奴隷たちからは、全然反論が来なかったと。
まあ今もどっかのビルのタコ部屋で詰められている真っ最中の奴らが、こんなゴミ増田にトラバしてる場合じゃねー！というのもあるかも知れないね。
でも、それひっくるめても、もう結論出てんじゃん。
日本のITなんて、技術も科学的知見も持ち合わせない、ゴミみたいな奴らが主流と。
マジで笑わせんなよ。
いや、馬鹿な客が一番のガンなのは認めるが、それにしたってダメすぎ。
これがインフラ系の構築や運用だと、ココらへん本当に美味しく立ち回れている。
そっちも客はいい具合にアホだが、それでもブラックに陥ることなく利益上げてんだよ。
それに比べて開発のグダグダな体たらく。下手すると死人まで出やがるもんなあ。
恥だと思うわ。
それとも、炎上プロジェクトの火消しに、恥ずかしいもへったくれもあるかって？
そういうのもう古いと思うよ。
ビッグサイエンスってのはデカい装置おいてごちゃごちゃやるあれね
俺がいた地方の国立大学なんて教授が10万円の研究費でもめてたの見たことあるんだけど
でもそういうのは科学者にとってもおいしいから批判なんか起きない、だから問題が表面化しない
例の二位じゃダメなんですかな富士通主導のスパコン京だってそう、あれ1100億円もするんだぞ
京は速攻で二位になったけど、抜いたのはアメリカのやつで開発費70億円ｗ
こんなのに金つぎ込んでるんだからいくら金があっても足りない、ITゼネコンおいしいわなｗほんとｗ
そんでPEZYの社長は逮捕される、たった4億円で、いや詐欺は悪いとは思うけど、でもやりきれないわな
Permalink |記事への反応(10) | 09:21
「ダメなアルゴリズムで書かれたコードは、いくらでも捨てて書き直せる。しかしデータ構造に問題があった場合、プログラム全体の書き直しに発展してしまう」
この話と微妙にカブるようでカブっていないが、言い方だけ真似たものとして
「クソな下請けはいくらでも代わりを探せる。しかし元請けの回し方がダメだったら全員でデスマ確定」
という話もある。これまた開発経験者ならよくご存知だろう。
すなわち、最低でも年収500以上は確実に貰っているであろう、エリート様揃いのITゼネコンの中にも、一握りの、まさに一軍というべきデキる人達と、そうじゃない人達がいると。
そして一軍と二軍以下では、マネージメントにおいて天国と地獄くらいの差が出るのだから恐ろしい。
というかなんでそれだけの年収に見合う学歴がある人達なのに、デキる人が一軍扱いされるほど少数なんだよ、意味わかんねえ。
学歴というのは、努力の仕方、効率の見極め方についての上手い下手の最も分かりやすい数値だと個人的には思っている。
そうなれば当然高学歴は、システム開発という極めつけの頭脳労働で、そのパフォーマンスを遺憾なく発揮し、協力会社含めて皆をハッピーにするのだろう…そう、一軍ならね。って、全員じゃねーのかよ！
具体的にはこうだ。
良い方から説明すると、一軍のマネージメントは要件定義から寸分の隙もない。
顧客の経営戦略に基づいた要望を良く理解し、仕様に取り込んでいることは勿論、システム間通信のような、後でとんでもない話が発覚して色々揉めそうな部分も、既にこの段階において顧客の協力を取り付け、キッチリまとめていたりする。
とにかく裏で細かく調査していたことが見て取れて、仕事したんだね～という感じである。
それから設計に取り掛かるのだが、やはり要件定義の段階で「どうしても見えない部分」はあって、下請け以下が作業の過程で洗い出した結果、それが時にはリスケを招く事故になることがある。
しかし一軍の人らは、本来最後の手段であるリスケにも比較的前向きで、それについての顧客説明もしっかりしているのだろう、大して揉めること無く妥当な落とし所にたどり着くのだ。
また、下請けのグループ(≒サブシステム単位)に必ず1人以上プロパーを配置し、現場感の吸い上げと「同じ釜の飯を食ってる」感の醸成にも抜かりない。
それもあって、現場でよくありがちな「あの人ら(元請け)何も分かってない」という陰口は最小限になる。
強引にまとめるなら、リスクが常に頭にあって、かつその取り方について常に考えを巡らしている。「かもしれない」運転をしつつ、逃げ腰にならない姿勢は見事である。
そして、二軍以下は上述の一軍の振る舞いが全くできない。本当に全部できていないのだ。
要件定義は客の要望を汲み取る所から既に漏れ漏れ、当然後ろの工程で揉めそうな部分は一切見ていない。
設計の大元、ひいてはシステムの大元になる部分がこれだけ不完全だと、その時点でデスマ化・炎上は約束されたようなものである。
その後に起こる事態は、もはやここに詳しく書くまでもない。
穴だらけの要件定義を、場当たり的に客に相談しながら埋めていく作業が設計のお仕事になり、それが相次ぐ仕様変更を呼ぶ。
結果どこまでExcelやソースコードをいじっても作業量が減らない、いやむしろ増える。しかも成果物が増えてくる各フェーズの終わりが近づくほど、「横展開」という名目で作業量が爆発的に増大するのだから始末が悪い。
各成果物を直しきれず「修正漏れ」という事故を仕込むことも頻発し、それに伴い品質も凄まじい勢いで低下する。
それでもケツは絶対に動かない。それどころか人員の追加すら出来ない元請けもいる。お前ら見積もりドンブリ過ぎだろ。
現場では脱落者が日常的に出る。でも下請けチームにプロパーが1人もおらず、そうした危機的な現場感が上に届かない。それも合わさって「あの人ら何も分かってない」という愚痴が漏れ聞こえるようになるのだ。
こんな体たらくじゃテストに漕ぎ着けるなんて夢のまた夢だし、仮にどうにか辿り着いても、何がどう動けばいいの？ってレベルでグダグダだったり。
いやもう、マジで元請けの人らは何やってんの？という感じ。優秀な人が何十人もいるのに機能していないとか、なんでそんなことになるんだか。
今日も日本の何処かで、基幹システムのリプレースが行われている。
基幹システム…そう、古くは汎用機にCOBOLという、枯れるを通り越してまさに朽ち果てんとしているアレだ。
そもそも朽ちて土に還る前に建て直すためのリプレースだ。
てか朽ちないんだったら、もう半永久的に触るべきじゃないと思うんだけど、形あるものは必ず滅びるのだ、作り直すしかない。勘弁してくれーという感じだ。
じゃあ何を用いて作り直すか？またCOBOLが一番手っ取り早そう(ソースいじらず移植という意味で)だが、それは許されないのだそうだ。ふざけんな。
今だったら大体どこでもJavaで作り直しだ。どういうわけか今のトレンド()だ。
てかそれ、オブジェクト指向とWebアプリに夢見過ぎじゃね？別にそれ銀の弾丸でもないしエクスカリバーでもなければ伝家の宝刀でもない、ただの道具なんですけど。
その証拠に、色々共通化されて保守性も拡張性も格段に上がったとか言ってる割に、その実態は、数える気にもならないほどインターフェースをimplementしまくった、複雑怪奇なクラスファイルの乱立ですよ。
もちろんドキュメントも上から下のレイヤーまで、そのクラスの分だけ揃ってる。というか山のようにある。いやそれ分量的に読めねーから。
ちなみに、今時の銀行や大企業は、基幹システム一つだけなんて事は無いケースが多い。基幹システムは複数あって相互に通信する巨大システム群の中の一つに過ぎなかったり。
そこで基幹システムだけ今風に作り直した所で、コスト増大の根本原因である複雑さの解消に、微塵も貢献しているとは思えないのだが、その質問はダメらしい。
もうさ、ぶっちゃけちゃうと、そもそも人間という柔軟な脳を持つ生き物がこなしている業務を、人間より正確かもしれないけど全く融通が効かないコンピュータに代替することが限界なんじゃね？と思うんだわ。
基幹システムを見ていると、そんな暗澹たる気分になる。
そりゃCOBOLと汎用機しか選択肢のなかった時代から比べて、今は色んなソリューションやソフトウェアがある。どれもシンプルに造るため、分かりやすく造るためにある。
しかしこの国の基幹システムは、それでもなお複雑さを解消していない。
あるいは、そういう大きなシステムを抱えている日本の組織性の問題なんですかね？
爆発しなくてもいいから、Google辺りに生息している本物のプログラマが、そういう複雑さを一気に解決するような、黒船もびっくりなソリューションで、今のITゼネコンありきのSIの世界に風穴を開けてくれることを切に願う。
