  |
はてなキーワード: SIerとは
栄光のメーカーから落ちぶれたSIerの経営者よ、「猿まね力」がないなら変革は無理だぞ
https://business.nikkei.com/atcl/gen/19/00322/121300024/?P=2
社名を出さないで「落ちぶれた」などと言っているのも感じが悪いので、はっきり書いてしまおう。メーカー落ちぶれ組とは、もちろん富士通、NEC、日立製作所のことだ。日立は最近「IT×重電」などでDX（デジタルトランスフォーメーション）に成功しつつあるとの評判だが、私は留保をつけさせてもらう。IT部隊だけを見ればSIerであることに変わりがないからだ。この3社にNTTデータを加えた4社が、ハイテク産業のふりをした労働集約型産業であるIT業界で親玉中の親玉として君臨しているわけだ。
偉い人の思いつきでDX予算が着いたらしく、流行りのビッグデータによるデータサイエンスやAIを駆使した販売促進システムの開発プロジェクトに巻き込まれてて月曜の出社が苦痛すぎて辛い。
詳細はぼかすが、店舗でのポイントカードの購買履歴に基づいてAIがリアルタイムで自動的に販売動向をチェックし、効果的な販促(アプリからのプロモーションとか)ができるシステムを作ろうとしてるんだけど、仕様を決めてる偉い人のセンスが壊滅的で盛大に炎上している。
何がヤバいかっていうと、元々のポイントカードの購買データがAIによる処理に向いていないと言うところだ。ポイントカードには年齢、性別、職業とかのデータが紐づいているけど、そのデータが登録時から更新されることはまれである。なんで素のデータをそのままAIに渡して処理するのは危険だったりする。
例を上げると、全国的に30代独身女性がアンパンマンのおもちゃ付きのお菓子を好んで買うというデータがあったとして、それは実態を表していない可能性が高いと言うことがあったりする。
人間の目でデータを分析して見ると彼女たちがポイントカードを作ったのは20代の独身の時で、今アンパンマンのおもちゃ付きのお菓子を買っているのは結婚して子供ができてその子供にねだられて買っている(=商品が刺さる層は小さい子供で母親が買っている)という仮説を容易に立てられるわけだけど、機械はそうじゃない。
なんで、こういうデータを扱うときは人力で生データを加工して使えるデータに補正しないといけないわけだけど、補正の手間って思っている以上に大変なのだ。例えばアンパンマンならまだ判別ルールを組み込みやすいが、実際に30代独身女性が自分用に買っている可能性が考えられる、すみっこぐらしのおまけ付きお菓子とかならどうするかとか悩ましい問題があって、人手と現場のノウハウが要求される泥臭い要素が結構あったりする。
だけど、口の回るコンサルやSIerに乗せられた偉い人は完全に自動でできると思ってるし、システムが稼働したら運用コストはサーバー管理費用程度だろうくらいに考えているんで、理想と現場の現実との板挟みでマジで辛い。実際にシステム構築する側からすれば、常に人力でのデータ加工が必要な筋が悪いシステムで、そんなシステム作ってもまともに運用できないと思ってるんだけど、俺の考え間違ってるかな？
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
客が大企業で古いシステムのサポートが切れるから新しいものを入れる、みたいなやつ。
なんか新しいシステムを入れるのに、古いシステムのどれだけ満たすか、独自開発がどれぐらいいるか、みたいな調査をするのだけど、なんかアホだなって思ってた。
古いシステムはそもそも魔改造されてるわけで、サポートが切れるっていう意味もよくわからず、古いソースコードが急に消え去ったりするということなのだろうか、という疑問があった。例えばJavaのフレームワークが古く、アップデートできない状況ならば、なんとかしてリファクタリングするなりして解決したらいいのではって思ってたんよね。
具体的には、下請けの工数をうまく水増しして儲けにつなげるような、政商的なスキルが求められる。
「エンジニアリング」が本来は研究・開発という意味であることに立ち返ると、
「いかに自分は動かずに金を儲けるか」を研究する職ともいえるし、「トリックエンジニア」と言えるかもしれない。
根本は金を巻き上げる政商、いわゆる時代劇に出てくる越後屋のスキルである。
半数は真面目にエンジニアリングをしているが、半数はそのような人材なのが実情。
これを見て、自分がどちらに属しているかは、本人が一番わかるだろう。
どちらに行きたいか？という精神で人間が二分されるのも、フィルタのようで面白い。
究極はウイグル人を躊躇なくレイプして臓器を抜ける人間か、そうでないかの違いであろう。
まさに闇と光である。
おそらく前者のほうが少ないだろう。
人数比的に、SIerで上流を目指す人や、好んでSES業界で起業する人が少ないのに合致していて面白い。
闇を自ら選んで魂を生贄にする人は、なんだかんだで限られるということだろう。
多くの人は売った結果どうなるかを、無意識に知っているのかもしれない。
小遣い稼ぎでちょっとしたシステムを作ってたんだよね。DBのスキーマ定義とかマイグレーション履歴はgitにチェックインしてあったし、コード読めない人のためにそこからER図も自動出力するように設定していた。
ある日、おじさんが急に上にやってきて「DB定義はエクセルでやるのが業界の常識！そんなことも知らんのか！」と言ってきたんだよね。このおじさんの経歴を見てみるとまともな会社で働いたことが一度も無い。学生時代に受託のシステム会社を起業したようでその後は大した人間を雇うこともなく零細システムをほそぼそと作ってきたらしい。学歴も大したことがないんだけど何故か自信満々なんだよ。自分はコードを書けると思い込んでる。「昔はコード書いてたので分かるんですが」とかいちいち言ってくる。でもね、どうも言っていることが時代遅れでガラパゴスなんだよね。なんと英語が全然できないらしい。「英語はアウトプットはできないが読むことはできる」と強がっているけどどうも嘘くさいというか英語情報に全く触れていないことが分かるタイプというか。でもこういうタイプだと低学歴ITの世界では幅を利かせられるらしい。
そんな感じで自信満々で偉そうなガラパゴス男だから話が通じない。自分だけが正しいという態度。急に怒り出すし。DB定義はエクセルで管理して変更履歴もエクセルじゃないとダメだって言うの。それが業界()の常識なんだと。上位互換を既に全部セットアップしてあるのにそれを理解できないのか何なのか。低学歴ITの世界でしか通じない弱小零細SIerの常識を押し付けられても困る。
① 池ポチャ後、キャディーは元の位置から打つ選択肢も考えられるためにゴルフバッグを残して、池まで行った。
② まだ、どちらから打つか決めていないのに、同伴競技者のキャディーが気を利かせたつもりで大西選手のゴルフバッグを持ってきてしまった。
③ 大江キャディーは、元の位置から打つかもしれないのに、バッグを持ってきてしまった同伴競技者のキャディーに大声で注意した（「なんで持ってくるんだよ！」みたいに強めの口調だった？）
④ そのことに対して、大西選手は大江キャディーに注意した。（18Hの会話で「（バッグを）持ってきてくれてありがとうで終わりじゃん。」と大西選手は言っている
多くの職場でもこうしたことが起きていて、日本の職場の生産性を落としていることが多い
「手が空いたら他人の仕事のヘルプ」は、専門性の低い労働集約ジョブでは意味があるが、
専門性のある仕事であればあるほど余計な事であり、優秀な人間の足を引っ張ることになる
たとえば60分かかる仕事を10分で終わったら、50分を別のブルシットジョブに充てるというのは愚の骨頂である
（SIerの人月計算など、元来的に足を引っ張りあったほうが儲かるビジネスの場合を除く）
おそらくアメリカなどはこの余剰リソースの考えが優れているから大国なのだと思う
余剰リソースを作った＝優秀な人間、という評価が下されるのである
日本は逆で、余剰リソースを作らせない、全員が均等になるような方向で動く経営者が多い
根本論として「みんなで平均的でありましょう」という、「運動会みんなで一緒にゴール思想」があるためと思われる
この場合はキャディという専門的判断を要するプロの他人の仕事に、勝手に手を出したことが原因だろう
ただしこの場合バッグを持ってくるというのが戦略的に致命的とも思えないので、
