orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

もしIT未経験者/30代だとして、IT業界に入るとしたらどんな戦略で臨むか

 

この前30代の方からご相談を受けた。

「IT業界に入りたいです。でも未経験です。」

と。なるほど、私は確かに業界経験も長く、採用サイドにもいるので詳しい。特に最近。

ただ、あれ?となった。私はこれ自身に答えを持っているのか、と。

何らかのバイアスがあって、30代/未経験に対して、すぐにフィルターをかけてしまい、採用外としていなかったか、という疑念も浮かぶ。

これではいけないな、と。優秀な人というのはどのゾーンにもいらっしゃるものだ。みすみす見逃しているような気がする。もっと、思い込みを排除して、ただしく世界を見られるようにならないと、これでは自分で自分の首を絞めるようなものだ。

 

ということで、書いた。

 

note.com

 

この情報は価値がある気がしたので、有料記事にした。

 

この記事がたくさん読まれるのか、それともそうでないのかはわからないけど、私として答えを一つ、言語化しておきたかった。

最近思うのは、特に40代以降だが、「これってどう思いますか?」の解像度が求められる。答えに窮したとする。考えて考えて答えが出たとする。でももう答える機会はないのだ。あのときに、そう答えておかなければ二度目はないのだ。

だから、あらゆる関心事に対して言語化を事前にしておくこと。このブログによって私が得られた最大のメリットはこれだ。世の中、いろんな場面がある。重要人物から、重要な問いをされることがある。「Yes, or No, or what?」と。そのときに何らかの言語化がされていれば、それを話せばいい。しかしアドリブで話すのはだいたい、考えが浅い。そして、この問いによって、その後の運命が大きく変わる瞬間が訪れやすいのだ。40代は。これからは、もっとそうだろう。

最近、多くのアウトプットを重ねるのは、コミュニティーを持ったり会社の出来事であったり、いろんなことが起きて、言語化しなきゃと思う場面が激増したから。

普通なら、考え事をして終わりなのだが、私には言語化する手段が与えられているのだから、これを活かさない手はない、とたくさんの記事を書くようになったという経緯である。

そして、問われたときに、アドリブのように話す。相手は「すごいな」となる。でも、実は事前に下書きがあるのよ、とは言わない。

これからも、次々と言語化を重ねたいな、と思う。

 

話が壮大にずれたが、未経験者でも道はある。

言語化の結果が誰かの参考になればうれしい。

 

解決を金で買う炎上プロジェクトを見た

 

何十億というお金が動く開発プロジェクトが暗礁に乗り上げたときどうするか。開発規模が大きいだけに、スケジュールが遅延しだすといろんなことがうまくいかなくなる。ある作業が出来ない原因が、別の作業の遅延であり、遅延している要因が別の部門の手続き不備、コミュニケーション不足。そうやっていろんな要素が絡んでいって全体として遅延する。遅延しているときに特徴的なのが、暇な人がいること。そして帰れない。前提条件が揃わないので仕事が開始できず、でもその仕事のスケジュールはタイトである。途方にくれたってサラリーマンだし、座ってればお金はくれるので誰も何も言わないけど、そういうときにプロジェクトマネージャーは焦る。そしてプロジェクトマネージャーは客先に缶詰になりがちとなる。なぜ遅延するのか、対策は。いろいろ立ち振る舞うけれども、現場にいられないからこそ、統制も取れなくなる。帰社して、各チームのメンバーに状況を聴くけれども、表情は冴えない。

ここまではよくある話で、昔はこういう問題プロジェクトが放置され、プロジェクトが頓挫したりしてユーザーとベンダーで裁判するみたいな話がよくあった。最近ないのは、炎上しないための構築技術が純粋に高くなったのと、炎上の初期で問題を検出し、全社的に火消しに取り組むタイミングが早くなったことだ。ボヤの時点で火を消すのは大切なことで、ピンポイントでエース級を送り込み正常化させたりもする。そのほうが断然お金がかからない。

もう12年くらい前になるか、炎上まっさかりのプロジェクトにSESで参加したことがある。構築フェーズとしては設計は完了し実装中。この実装が遅々として進まなかった。その技術的原因は置いといても、そのプロジェクトのために借りられたオフィスは雑然としていた。たくさんの人がいた。でも私の会社の社員はいなかった。私の会社経由で再委託していた人はいたけど3日でいなくなった。仕事ができなかったためだろう。一方で、私は席があって座ったけれど、3日間仕事が振られなかった。仕方ないので、現場のドキュメントフォルダを探し当て、ずっと読んでいた。

普通の雰囲気じゃなかったし、周りのプロパー社員も家に帰らないので、なんとなく残ってたのだけど、それでも仕事がなかったので20時ごろに帰ったんだけど、誰も私を制御していなかった。残っていいのやら何なのやら。わからず。

その後、やっと仕事っぽいものが振ってきた。ジョブスケジューラーまわりの実装らしい。とはいえそのソフトウェアを実装したことは私もなかったけど、「わかりましたー」なんて言いながらそのソフトウェアのオンラインマニュアルを読み、ふむふむ、と言った具合で実装していった。誰もレビューしてくれなかった。でも「できた」と言われた。そしたら、ジョブスケジューラーまわりの責任者に仕立て上げられた。知らんがな。

どうもその後も、いろんな協力会社の人がどんどんやってきた。目まぐるしく増える登場人物。何をしてるのかしらないけど、この炎上プロジェクトを鎮火させるために「とりあえず人」と言う状態だったと記憶している。仕事の内容なんて来てから決める。人数を増やせ。100人日遅れてるなら、100人突っ込めば1日で終わるよね、みたいな世界をリアルに見られたのは今となっては財産である。

あれは、解決を金で買ったのだなと。高度な技術で顧客の課題を解決するのが我々の仕事なんだけど、煮詰まってくると、大量の金で自分たちの課題を解決しちゃうんだな、と。

そうやって、結構なことがお金で解決されてきた世の中だけど、ここ最近はお金があっても人がいないみたいなこともあり、さあこの手法が今でも有効かは知らない。今後、少子化の動向なんて見てると、お金はあるのに解決できないみたいなことも考えられ、「昔はよかったね、お金があれば解決できて」となるかもしれない。もしくは、お金の価値がだんだんと目減りしてきているのかもしれないが。

 

ECサイトから個人情報漏洩が起こるルートについて

 

たま~に、〇〇ECサイトにてxx万件の情報漏洩、というニュースが起こるわけですが、なんでこんなことが起こるか、一般の方は不思議でたまらないと思います。

もし、第三者のアカウントを知ったからといって、それでログインしたとしても、マイページを見て情報取得。それでも1件にしか過ぎないわけですよね。

それが何万件って、どうやって入手するんだろうって。

方法は、何といってもECサイトが持つデータベースへのアクセスです。ユーザー一覧テーブルを持たないサイトなんてないわけですから。

でも、どうやってアクセスするんだと。そんなアクセスが成り立つならECサイトとして破綻してるじゃないか。そう、破綻してるんです。

一つは、システムが動いているサーバー自体に、リモートでログインし操作するケース。サーバー自体はデータベースへのアクセス権限を持ちます。rootやadministratorのような、管理者権限を入手しないとサーバーの中身は見れないとおっしゃいますが、たいていのサーバーが、読み取り権限はつけているケースが多く、データベースの接続情報が読めちゃうことは多いです。どうやってリモートで入り込むか。それは運営会社のLANに、ランサムウェア経由で入り込み、そこから運用管理者のPCをのぞかれ、データを抜き去るパターンはよく聞きますよ。

もしくは、ECサイトを構成するWebアプリケーションに、脆弱なコードが存在するケース。WEBブラウザから受け取った情報からSQLに翻訳し、データを受け取る仕組みなのが、そのWEBブラウザの情報を攻撃者がわざと変更し、他人のデータを大量に受け取るような攻撃パターン。

または、アプリケーションには脆弱性がなくても、ミドルウェアに脆弱性があるパターン。ミドルウェアの脆弱性をついて、コマンドをサーバー上で実行させるような攻撃は今もって主流です。

あと、社内によからぬ人がいて、データを抜いて売っちゃうってパターンも過去ありましたね。

インフラにもアプリケーションにも、そして社内情報システムにも、そして人間にも攻撃ポイントはあり全方向で気を付けてないと、あっという間にデータを抜かれてしまうのが怖いところです。

自社ECなんて表現のときに、これも2つの運営ケースがあります。

①完全内製で自社構築、運用

②ECサイト構築・運営代行にお任せするケース

昔は①もあったんですが、あまりにも運営に高度な知識が必要なので、②を利用するケースが大半になりました。

攻撃を受けず、平和に運用するってのは、大変ですからねえ。

ただ、DXに目覚めた、キャッシュが大量にある企業は、①を目指し会社を作ってシステムエンジニアを募集し、内製するぞーと息巻いているところもあります。

ってな感じで、なかなかECサイト、ちゃんと運営するのってめちゃくちゃ大変で、お金もかかります。覚悟がないうちは、自社ECより、モール型EC(Amazonとか楽天とかBASEとかあのあたり)を使う方が無難だと思いますがね・・。

 

再委託まみれの仲良し現場、よくある風景

 

経験あるんですよねぇ。商流がぐっちゃぐっちゃの仲良し現場。

 

www.yomiuri.co.jp

ビプロジーはコロナ禍に伴う「臨時特別給付金」の業務を市から受託。個人情報を扱う業務であり、再委託する場合は市に許可を得る契約になっていたが、無断で2社に委託、うち1社がさらに別の会社に委託していた。

 

いい図が載ってるんですが、これ元請から下請二社に分岐して、そこからまた孫請にさらに商流が伸びてますよね。

でも現場は仲良しで、この4名、作業後に飲みに行ってます。

 

www.yomiuri.co.jp

 

USBメモリーを持っていたC社の方は、きっと一番操作に慣れていた方だったんじゃないかな、っていうのは憶測ですが。さすがに入ってるデータのヤバさに認識はあったんじゃなかろうか。

協力会社超えて飲みに行く現場って、相当仲がいいというか、チームワークの意識が強かったと思います。そういう現場に数年いたことがあるので。

一緒の仕事をしているわけで、そしたら指揮系統も何も飛び越えて、コミュニティー的なものが発生するのは当然なことです。

分業しているうちに、こっちは彼が詳しい、こっちは誰、みたいな話になるので、契約書通りに人間関係はできないのは当然ですね。

で、大きな会社の場合、現場の技術者は人事権ないことが多いです。人が足りないとなるや動くのは営業部門だったりします。で、懇意にしている協力会社に相談して、任せてくださいよ、人集めますよ。そして、こんな現場が形成されていく。

十中八九だけど、技術者レベルになると指揮系統なんてめちゃ曖昧になって、一緒に作業していくうちに仲良くなるのは間違いないですよ。

だって、会社に行ってコミュニティーがないとしたら、常駐SEとかってやってられなくないですか?。一緒に仕事するのに、みんな他人、って状態が長く続いたら、それはそれで仕事的にも支障が出るって話じゃないですかね。

だからこの業界、結果的に人が集まったね、でそれを成り立たせるために、営業があれこれ手を尽くして会社間のコネクションを作るってのが、普通なんです。

しかも、一応元請と下請の関係はできるんですが、元請の社員も人事異動もある。そのときに若手になっていくんです。長い現場だと。ベテランはだんだん、燃えそうなリスクのある現場に移され安定してそうな現場に若手がアサインされる。そしたら、下請のほうが現場よく知ってるなんてことが普通におきる。そうなると、飲み会ってもっと大事になるわけですね。そして、下請のほうが現場を握るケースもよくある。

Dさん、お願いしますよ~、なんて、元請のAさんがお願いすることなんて、普通。

 

この件を見てね、よくネットで、再委託が悪者になるんですけど、そもそも、USBメモリーやノートPC持って飲みにいっちゃ、ダメですよね。それは再委託は関係ないです。

再委託のことを行政は知らず、行政が損賠賠償を元請にする、って話はまた別の話だと思います。だって、現場は、別のロジックで仲良くなっちゃうものだから。

むしろ、元請は、末端までセキュリティー教育をちゃんとしなきゃダメだよね、っていう普通の話にまとまるんです。で、発注先にはちゃんと許可を得る。

委託がなくなっちゃったら、ほんと人が集まらなくなって、いろんな現場がまわらなくなるし、仲良し現場を作ってる他の現場の方は気の毒だなと思います。

 

マニュアルの日本語化は機械翻訳で十分だよ

 

ITの世界はほとんどが海外のハードウェアやソフトウェアで成り立っている。これをどう日本国内で料理するかが、長いことこの業界での課題だった。

日本が円高で購買力があるときは、日本の市場に合わせたローカライズは結構まともにやってた。どこぞの商社が日本〇〇株式会社みたいなものを立ち上げて、まるで日本の製品のように仕上げて売る。そういう時代もあった。

しかし、だいたいは売れるとわかった途端に、本国が口を出し、そして日本〇〇株式会社自体を買い戻す。

インターネットで情報のスピードが速くなり、アメリカで流行ってるけど日本人は知らん、みたいなことが少なくなった。20世紀の日本の文化なんてアメリカの物まね的な成果物が多かった。何か商売するときに海外に手本があるという状態は日本人が好むところで留学した人が日本に持ち込むパターンは、それこそ明治時代からあった。今は、日本にいながらにして動画レベルで伝わるので、日本に持ち込むことを目的に海外に行くのは今ではコスパが悪すぎる話になってしまった。

機械翻訳のない時代にどうやって日本語にしてたかというと、翻訳専門の仕事があった。この方たちは外国語には堪能なんだけど、ITはよく知らない。だから昔の日本語マニュアルは意味不明な表現が多かった。日本人だって、ITを知らない人が日本語でITの説明を聴いても理解できないだろう。英語だって同様である。おそらく過去の翻訳家たちは、心を無にして機械的に意味を日本語に橋渡ししただろうけど、その意味が自分にもわからないというのはなかなか辛い作業だったのではないだろうか。

当時の私は、日本語マニュアルがわけわからん、となったときはその原著となる英語マニュアルをわざわざ探して眺めていた。無理やりな和訳をいくら眺めて推測を重ねても意味までたどり着けぬ、と英語をみたらそういうことか、そんな体験が多かった。日本語マニュアルなんて目次であって、そこから英語をたどるというのが当時の学び方だった。

今ではマニュアルはほぼオンライン化されている。基本は英語であり、それが機械翻訳で日本語化されている。機械翻訳は前段のような、無理解者による意味の行方不明がない。機械翻訳は、こなれた翻訳をたくさん知っているので、日本語マニュアルの制度はやけに上がったように思う。

ただ、今でも困るのが、機械翻訳をするベースの英語の原文が修正・加筆されるペースが昔より上がっていること。最近は修正パッチをかなり早いペースで出すようになったので、どんどんドキュメントが更新されるのだが、それに日本語の機械翻訳が間に合ってない。日本語のマニュアルを見ながら作業していたら結果が合わないので原文を見に行ったら、ちゃっかり修正されていてだまされたことが数度。

もはや、世界と同じスピードで仕事をしたければ、日本語マニュアルなんて不要なのかもなという感想である。最終的に消費者に渡るときに日本語になっていればいいわけで、それだけが日本人の仕事なんだろうな、そういう感覚でいる。別に、経済力うんぬんじゃなくてね。日本語マニュアルがないって言って憤るのは、もはや昔の話だと思うわけです。