  |
はてなキーワード: 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億円で、いや詐欺は悪いとは思うけど、でもやりきれないわな
「ダメなアルゴリズムで書かれたコードは、いくらでも捨てて書き直せる。しかしデータ構造に問題があった場合、プログラム全体の書き直しに発展してしまう」
この話と微妙にカブるようでカブっていないが、言い方だけ真似たものとして
「クソな下請けはいくらでも代わりを探せる。しかし元請けの回し方がダメだったら全員でデスマ確定」
という話もある。これまた開発経験者ならよくご存知だろう。
すなわち、最低でも年収500以上は確実に貰っているであろう、エリート様揃いのITゼネコンの中にも、一握りの、まさに一軍というべきデキる人達と、そうじゃない人達がいると。
そして一軍と二軍以下では、マネージメントにおいて天国と地獄くらいの差が出るのだから恐ろしい。
というかなんでそれだけの年収に見合う学歴がある人達なのに、デキる人が一軍扱いされるほど少数なんだよ、意味わかんねえ。
学歴というのは、努力の仕方、効率の見極め方についての上手い下手の最も分かりやすい数値だと個人的には思っている。
そうなれば当然高学歴は、システム開発という極めつけの頭脳労働で、そのパフォーマンスを遺憾なく発揮し、協力会社含めて皆をハッピーにするのだろう…そう、一軍ならね。って、全員じゃねーのかよ！
具体的にはこうだ。
良い方から説明すると、一軍のマネージメントは要件定義から寸分の隙もない。
顧客の経営戦略に基づいた要望を良く理解し、仕様に取り込んでいることは勿論、システム間通信のような、後でとんでもない話が発覚して色々揉めそうな部分も、既にこの段階において顧客の協力を取り付け、キッチリまとめていたりする。
とにかく裏で細かく調査していたことが見て取れて、仕事したんだね～という感じである。
それから設計に取り掛かるのだが、やはり要件定義の段階で「どうしても見えない部分」はあって、下請け以下が作業の過程で洗い出した結果、それが時にはリスケを招く事故になることがある。
しかし一軍の人らは、本来最後の手段であるリスケにも比較的前向きで、それについての顧客説明もしっかりしているのだろう、大して揉めること無く妥当な落とし所にたどり着くのだ。
また、下請けのグループ(≒サブシステム単位)に必ず1人以上プロパーを配置し、現場感の吸い上げと「同じ釜の飯を食ってる」感の醸成にも抜かりない。
それもあって、現場でよくありがちな「あの人ら(元請け)何も分かってない」という陰口は最小限になる。
強引にまとめるなら、リスクが常に頭にあって、かつその取り方について常に考えを巡らしている。「かもしれない」運転をしつつ、逃げ腰にならない姿勢は見事である。
そして、二軍以下は上述の一軍の振る舞いが全くできない。本当に全部できていないのだ。
要件定義は客の要望を汲み取る所から既に漏れ漏れ、当然後ろの工程で揉めそうな部分は一切見ていない。
設計の大元、ひいてはシステムの大元になる部分がこれだけ不完全だと、その時点でデスマ化・炎上は約束されたようなものである。
その後に起こる事態は、もはやここに詳しく書くまでもない。
穴だらけの要件定義を、場当たり的に客に相談しながら埋めていく作業が設計のお仕事になり、それが相次ぐ仕様変更を呼ぶ。
結果どこまでExcelやソースコードをいじっても作業量が減らない、いやむしろ増える。しかも成果物が増えてくる各フェーズの終わりが近づくほど、「横展開」という名目で作業量が爆発的に増大するのだから始末が悪い。
各成果物を直しきれず「修正漏れ」という事故を仕込むことも頻発し、それに伴い品質も凄まじい勢いで低下する。
それでもケツは絶対に動かない。それどころか人員の追加すら出来ない元請けもいる。お前ら見積もりドンブリ過ぎだろ。
現場では脱落者が日常的に出る。でも下請けチームにプロパーが1人もおらず、そうした危機的な現場感が上に届かない。それも合わさって「あの人ら何も分かってない」という愚痴が漏れ聞こえるようになるのだ。
こんな体たらくじゃテストに漕ぎ着けるなんて夢のまた夢だし、仮にどうにか辿り着いても、何がどう動けばいいの？ってレベルでグダグダだったり。
いやもう、マジで元請けの人らは何やってんの？という感じ。優秀な人が何十人もいるのに機能していないとか、なんでそんなことになるんだか。
今日も日本の何処かで、基幹システムのリプレースが行われている。
基幹システム…そう、古くは汎用機にCOBOLという、枯れるを通り越してまさに朽ち果てんとしているアレだ。
そもそも朽ちて土に還る前に建て直すためのリプレースだ。
てか朽ちないんだったら、もう半永久的に触るべきじゃないと思うんだけど、形あるものは必ず滅びるのだ、作り直すしかない。勘弁してくれーという感じだ。
じゃあ何を用いて作り直すか？またCOBOLが一番手っ取り早そう(ソースいじらず移植という意味で)だが、それは許されないのだそうだ。ふざけんな。
今だったら大体どこでもJavaで作り直しだ。どういうわけか今のトレンド()だ。
てかそれ、オブジェクト指向とWebアプリに夢見過ぎじゃね？別にそれ銀の弾丸でもないしエクスカリバーでもなければ伝家の宝刀でもない、ただの道具なんですけど。
その証拠に、色々共通化されて保守性も拡張性も格段に上がったとか言ってる割に、その実態は、数える気にもならないほどインターフェースをimplementしまくった、複雑怪奇なクラスファイルの乱立ですよ。
もちろんドキュメントも上から下のレイヤーまで、そのクラスの分だけ揃ってる。というか山のようにある。いやそれ分量的に読めねーから。
ちなみに、今時の銀行や大企業は、基幹システム一つだけなんて事は無いケースが多い。基幹システムは複数あって相互に通信する巨大システム群の中の一つに過ぎなかったり。
そこで基幹システムだけ今風に作り直した所で、コスト増大の根本原因である複雑さの解消に、微塵も貢献しているとは思えないのだが、その質問はダメらしい。
もうさ、ぶっちゃけちゃうと、そもそも人間という柔軟な脳を持つ生き物がこなしている業務を、人間より正確かもしれないけど全く融通が効かないコンピュータに代替することが限界なんじゃね？と思うんだわ。
基幹システムを見ていると、そんな暗澹たる気分になる。
そりゃCOBOLと汎用機しか選択肢のなかった時代から比べて、今は色んなソリューションやソフトウェアがある。どれもシンプルに造るため、分かりやすく造るためにある。
しかしこの国の基幹システムは、それでもなお複雑さを解消していない。
あるいは、そういう大きなシステムを抱えている日本の組織性の問題なんですかね？
爆発しなくてもいいから、Google辺りに生息している本物のプログラマが、そういう複雑さを一気に解決するような、黒船もびっくりなソリューションで、今のITゼネコンありきのSIの世界に風穴を開けてくれることを切に願う。
退職から一年が経過し、新しい職場（WEBベンチャー企業）での仕事に慣れたこと、
また、富士通の同期入社の友人から頻繁に転職の相談を受けるようになったこともあり、本エントリを執筆する。
はじめに、筆者の退職理由を簡単に述べると、富士通という会社に未来を感じなかったことと、やりたい仕事はできないだろうと判断したためである。
参考までに、筆者は公共機関向けのシステム開発部門に所属していた。
担当していた業務は様々で、小規模なシステム開発や、子会社・下請企業の管理であった。
富士通には、人材キャリアフレームワークという社員評価制度があり、現場には、入社何年目はこのレベルの仕事、といった暗黙の了解がある。
本人の能力や意欲とは全く無関係に、入社後の経過年数で、仕事の裁量の幅が大きく制限される。
このことはいわば、学習指導要領ならぬ、業務指導要領があるようなものだ。
このような枠組みや暗黙の了解が存在すること自体が問題なのではなく、その枠組から逸脱した人材を想定しない・評価しないことが問題なのである。
筆者がお世話になった優秀な先輩方は、この業務指導要領の要件を満たして手に余った人、
いわば天井にぶつかった人から先に、より大きな仕事がしたいという理由で辞めていった。
筆者もその一人である。
既存産業の大きな成長が望めなく、社員個々の多様性が重要視される昨今の経済情勢において、
高度成長期における横並び思想をもとの作られたやり方が未だに社内を謳歌しているのは時代錯誤というほかない。
富士通への提言として、これからの時代は、年齢も在籍年数も関係ない人材評価制度を作っていくべきである。
そして重要なのは、会社の既存事業でいかに利益を上げたかについての評価ウェイトを下げ、
いかに新しい発想で新しい事業を提案したか・実現したかという評価項目を設立するべきである。
なお、富士通には社内ベンチャー制度があるが、これはうまくいかない可能性が高い。
なぜなら、社内ベンチャーを承認するのは旧式の人材の典型例である高齢な経営層であるからだ。
いままで数十の社内ベンチャーの審査結果を見てきたが、彼ら経営層に事業の将来性を判断する能力はないと痛感した。
また、他の理由としては、富士通の既存事業と衝突すると社内ベンチャーが潰されるということがある。
将来性のない既存事業を残して、将来を託すべき社内ベンチャーを潰すという企業風土なのだ。
富士通という会社には多数の既得権益集団がいる。そして、社内のルールは彼らが決して不利にならないように作られている。
なぜなら、ルールを作る権限は、先頭を走る集団、1980年代に大成功を収めた既得権益層がガッチリ握っているからだ。
いわば、前を走る人を抜かしてはいけないレースのようなものだ。
このような出来レースで若手社員のモチベーションが続くはずはないことは明らかだ。
筆者は、決して年功序列主義を批判したいのではない。
既得権益層が年功序列を悪用して、部下の手柄を自分の手柄にし、部下の失敗を部下に押し付けている実態に対する批判である。
ノブレスオブリージュ、権利を有するものには義務がある、という思想がある。
富士通の既得権益集団には会社の技術力や社員を率先することで、企業としての地位を向上させていく義務がある。
実態は、社内の後進に抜かされることを恐れるあまり、後進の他社に抜かされている。
ちなみに、この既得権益集団に有利なルールが生み出した現状については、
同じく富士通OBである城繁幸氏の著書「若者はなぜ３年で辞めるのか？」（光文社新書）が詳しい。
経営学において「ヴィジョナリーカンパニー」という名著がある。
この本によると、会社が永続的に成長・発展していくためには企業理念（ビジョン）を社員ひとりひとりが持つことが必要不可欠であると指摘している。
富士通の企業理念は、変革に挑戦し続ける姿勢や、よりよいICT社会づくりに貢献することを掲げている。
しかし、富士通という会社の現状として、このヴィジョンを失っている社員、とくに管理職がとても多い。
30代を過ぎて会社に定住することを決めた社員に変革に挑戦しようという熱意ある人物はひとりもいなかった、
そういう人々にとってICTで社会づくりなどどうでもいいのだ。
ただ顧客の要求を聞いて、それを子会社や下請けに作らせて予算や利益を達成することにしか興味がない管理職が大半であった。
元GEのCEOであるジャック・ウェルチ氏は、たとえ成果を出していようと企業ビジョンを共有しないものはクビにしろと自著で語っている。
このポリシーを導入したら、富士通の管理職の80%はクビになるであろう。そのくらいに富士通の管理職は夢や熱意のない人物ばかりであった。
そのような人材が将来的に会社を破壊する、というウェルチ氏の指摘の正当性を、富士通という会社の惨状が示しているのは皮肉という他ない。
富士通への提言として、ウェルチ氏のやり方を実行すればよいのだ。
成果によって管理職のクビを決めるのではなく、ヴィジョンを共有できているかでクビを決めるのだ。
このやり方を実行すると既得権益を握って離さない経営層や管理職が一掃される。
既得権益にしがみつくだけの人物こそ、ヴィジョンを持たない人物である割合がとても多かったことを付け加えておく。
経営コンサルタントの大前研一氏は、日本の生産性がアメリカの半分しかなく、もはや発展途上国にすら負けていると指摘している。
その原因について、日本では業務標準化が全く進んでいないためであると述べている。
自分の住む自治体と異なる自治体のマイナンバーのITシステムを比較してみてほしい。
ここで、自治体が異なればITシステムも異なることに気づくはずである。
はたして自治体ごとに個別のマイナンバーシステムを作る必要があるのだろうか？
答えはもちろんノーである。全国どこでも一律の業務であるべきであり、同じITシステムを導入するべきである。
自治体ごとに業務フローが異なるために、別のITシステムを使用した時に業務がこなせないという事態が発生する。
そのため各自治体が個別にITシステムをITベンダーに発注することになる。
そこでITベンダーは各自治体ごとに個別のITシステムを作ることになる。
ITベンダー側からすると一度作ったことがあるものをカスタマイズして、業務の順番を入れ替えたり、扱うデータを多少変更するだけで済む。
それなのに膨大な金額を請求するわけだ、ITベンダーとしてはボロ儲けである。
（なお、主要ITベンダー決算書を見ていただくとわかるが、ITベンダーの利益率が高いわけではない）
特に自治体のITシステムは国民の税金で作られているわけである。
各自治体は、このような現状を放置していて、国民に申し訳ないと思わないのであろうか？
このことは、決してITベンダーにのみ責任があるわけではない。
総務省が陣頭指揮をとって各自治体の業務標準化・統一化を進めなくてはいけないのに、それが全くなされていないのは監督官庁としての責任放棄である。
このように業務標準化が全く進んでいない現状は自治体に限らず、民間企業においても同様である。
会計パッケージにおいて、世界のデファクトスタンダードになりつつあるSAP導入に失敗する事例を数多く見てきた。
失敗する理由は、個々の企業の業務に合わせてSAPをカスタマイズしており、そのカスタマイズでは対応できない業務フローが存在するからである。
問題なのは、そのような業務フローは、決して必然的な業務ではなく、過去の慣習から存在しているだけであることがとても多い。
ここにおいて、ITシステムが業務に合わせるのではなく、ITシステムに合わせて業務の方を変えていかなくてはいけないのだ。
このことは、サービス・流通業の顧客からSAPのカスタマイズで無理難題があがってくることが特に多いことと無関係ではないであろう。
富士通は、既存顧客の業務標準化およびデファクト・スタンダードとなるITシステムの開発の陣頭指揮をとる役割を果たすべきだが、その望みは期待できない。
なぜなら関係が深い企業において、業務が効率化すると大量の社内失業者を出すことになるからだ。
そのような"顧客との良い関係"を崩すようなことはやらない会社である。
日本という国のあるべき姿を長期的に考えた際に必然的なことであるにもかかわらずである。
富士通の企業理念である、よりよい社会づくりに貢献するとは、まさにこの業務標準化を推し進めることなのではないのか。
富士通には外国籍の社員が相当数在籍している。しかし、彼らに求められる日本人への"帰化圧力"がとても強い。
同期入社の中国籍の友人は、対外発表会のために完璧な日本語の発音の練習をさせられていた。
完璧な日本語の発音は日本人に任せるべきで、中国に精通しているというメリットを活かせる部署に配置転換するべきである。
なお、残った外国籍社員をみると、小学生から日本にいるなど、生まれたのが海外というだけのほぼ日本人だったりする。
外国籍社員の離職率が高いことに対して、本部長が提示した対策が、
長く働きたい会社とはどのような会社か、というテーマで外国籍社員を集めランチタイムにディスカッションさせるというものだった。
この席で「無能な人が本部長にならない会社で長く働きたい」という大喜利でもすればいいのだろうか。
富士通はグローバル企業を表明しているが、このような組織で海外進出などできるはずもない。
なぜならば富士通の利益構造では、海外において利益を上げられないからだ。
このカラクリの解説は大前研一氏が詳解されているので、参考にしていただきたい。※1
６．富士通の良いところ
ここまで富士通に対する批判と改善の提言を述べてきたが、富士通の良いところについても触れておきたい。
まず、個々の社員の仕事力や組織力といった点では、他の大企業と比較して遜色ない。ただし、富士通の主要グループ企業に限るが。
数十を超える大企業および中小企業と仕事をしたが、やはり大企業は個々の社員のレベルが高く、組織力も高い傾向にある。
顧客として他社と仕事を進めていくうえで、大企業の方が優秀な担当者に遭遇することが多く、仕事がとても進みやすかった。
この理由について、大企業の社員育成能力が高いことはもちろん、社内チェック体制が整っているからではないかと思う。
社内で質の悪いものは弾いており、社外に出さないようにしているのだろう。
また、富士通は顧客主義がきちんと徹底されている会社であると感じた。
筆者と富士通の顧客主義が異なっていた点はあるものの、顧客起点に立つという考え方は大事なことである。
柔らかい人が多く、職場の雰囲気はとても良かった。お世話になった直属の上司や先輩方は、優しく丁寧なご指導をいただいたことに感謝している。
７．おわりに
最後に、立花隆氏の著書「東大生はバカになったか」（文春文庫）から名文を引用したい。※2
「いま、この辞めたい気持ちを逃したら、この会社に骨を埋めて、あそこにいる連中と同じになってしまうと思った。」
結局、筆者の退職理由は、偉そうな顔をしているがロクなビジョンも打ち出せない富士通の上層部のような人間になりたくなかったからである。
富士通という会社に必要なのは、優秀な若手の育成などではなく、無用な老害の排除である。
筆者には、富士通という会社は、沈みゆく泥船にしか思えなかった。
※1「産業突然死」の時代の人生論、第44回 談合をなくす二つの妙案－"便利なゼネコン"はいじめの温床
http://www.nikkeibp.co.jp/sj/2/column/a/46/
（この記事のゼネコンをITゼネコン（ITベンダー）に置き換えていただきたい。）
※2 引用にあたり、語尾を改めた。
補足１．城繁幸氏の著書「内側から見た富士通」（光文社）についてのコメント
この本は富士通が先んじて導入した成果主義が、名ばかりで社員のやる気を奪う結果に終わったという実態を告発した本である。
この本について、いくつか述べたい。
まず、本題である、成果主義が経営層のご都合で導入されて、社員のモチベーションを奪うという最悪の結果に終わったという指摘はまさにその通りである。
また、この本が出版されてから10年以上経つが、実態は改善されていないし、する気もないのだろう。
（そもそも経営者のご都合成果主義の導入を失敗だと気づく能力が欠如しているのかも知れない）
管理職の仕事は、部下の成果を評価することではなく、予算内におさまるように部下の評価を調整することであった。
なお、成果主義の導入を評価している現場社員は誰もいなかった。
（成果主義を批判する幹部社員はいなかった。おそらく批判すると何らかのペナルティがあるのではないかと邪推している。）
補足２．転職について
筆者の転職について、考慮したことをいくつか述べる。
まず、次の会社・仕事の選び方および交渉の進め方については、山崎元氏の著書「会社は二年で辞めていい」（幻冬舎新書）を大いに参考にした。
転職は考えていなくとも、今の時代を働く考え方、人材価値のセルフマネジメントなどは一読の価値がある。
富士通という大手を辞めたはいいが、次の会社で苦労している人が多いという意見についてコメントしたい。
筆者に言わせれば、それは転職のツメが甘いのだ。
現職のどこに不満を持っていて、そのうち、どこが改善の余地があり、妥協するべきであり、次の職で改善を期待するのか、についての思慮が浅い。
社会のルールをわかっていないで転職したとしか思えないケースもある。
そもそも富士通という会社に勤めているにもかかわらずITゼネコンの生態系を理解していない社員がとても多い。
下請け企業にいけばもっとやりがいのある仕事ができる、などという浅い考えで転職する人はいる。
ITゼネコンの下請けを生業とする会社の社長は、中間管理職と何一つ違いはない。
上の指示（元請けの発注）を受けて下に伝達するだけであって、自身で新しい事業を生み出す能力のない企業である。
新しい会社は、自社で新しい事業を生み出す能力があり、きちんと利益を上げている。
転職において改善したかったこと、専門的な業務ができること、自分のアイディアを事業に活かすことができること、それらがすべて達成できた。
