セキュリティー研修を受けるといつも思うこと - orangeitems’s diary
まず初めに、セキュリティー事件や事故が社会で深刻化し、その被害が急拡大していて、未然に防ぐためには利用者も気を付けなければいけない、というくだり。 ・・・これはわかる。使い方を間違えると危険なプログラムを社内に引き込んでしまい、大被害につながる。それはそうだろう。 次にランサムウェアを含むセキュリティー事件の仕組みの話。過去は、目立つために有名な企業が狙われたが、今はお金目的が大半。攻撃が成功すればいいので、むしろ有名な企業より、目立たない小さな企業や個人が狙われるようになった。 ・・・これもわかる。その通りだろう。今は完全にビジネスで攻撃者もやっている節がある。お金の話が必ず出てくる。 そして、どういうルートでランサムウェアが入り込むかという話になる。そこで、電子メールの話が強調される。電子メールの中に細工がしてあって、色んな経路で怪しげなプログラムを端末で実行させようと攻撃者は試みる。
内部監査の限界 - orangeitems’s diary
先日発表された「株式会社日本カストディ銀行 ガバナンス検証第三者委員会の調査・検証報告書」に考えさせられた。 ・調査・検証報告書 https://www.custody.jp/news/pdf/news_cbj/20240419_report1.pdf ・調査・検証報告書（要約版） https://www.custody.jp/news/pdf/news_cbj/20240419_report2.pdf 要約版だけ見ても理解できるだろう。 ガバナンス機能が欠落していた、と一言で言えば簡単だが、これらの件は誰が止めることができたのだろうか。 社内で自浄作用を働かせるとして、役員レベルで「こうしなさい」と内部監査人含め現場に命令が飛んだら、何も言えなくなるんじゃないかな。 内部監査人の指摘は役員レベル以上の重みを持つのなら発言ができるが、それこそ権限がおかしいことになる。内部監査の結果を役員が
技術記事の中身がどんどん古くなっている - orangeitems’s diary
わからないことがあったら、ネットでググる、なんて言うけれど、この検索した結果がえらく古いことがある。2010年代の話は普通に出てくるのだけど、バージョンがかなり古かったりして今使えるかわからない。じゃあ使った情報が今のバージョンであるかというとない。そんなことが最近増えている気がしている。 昔にぶち当たった問題を社会に、ブログや技術SNSで共有したとして、その情報をあてにしてたくさんの人がアクセスし問題が解決されたと思う。私もその一人だ。私の技術などネット情報の塊であり、全部オンラインマニュアルで知ろうと思っても無理だ。 そこで知りえた技術をじゃあ現代化して私がまたアウトプットして社会と共有するかと言えば、しない。たくさんの人がインターネットで情報共有することを最近しないのではないか。過去は情報共有してたくさんのアクセスがあるとアフィリエイトでお金が入り、みたいな循環があったと思うが、誰も
クラウドはもう伸びない - orangeitems’s diary
これまでクラウドが伸びてきた理由って、オンプレに多大なリソースがまずあって、それがクラウドへ順調に移ってきたからだよね。 で、もうそろそろ飽和状態じゃないかと思う。クラウドにあるべきものはもうクラウドにある。 オンプレからクラウドへの移行をクラウドジャーニーと呼んで盛り上げてきたけど、クラウドの成長がもう10年。移行の話だけで成長するのはもう限界だと思う。 クラウドの上のワークロードだって、大分古いソフトウェアも目立ってきてリプレースも必要になってくる。このリプレース作業に大量に人手を取られるのは、オンプレだろうがクラウドだろうが同じこと。過去はクラウドにおいてはそれがなかったけれど、クラウド自体でも発生するようになるから、結局クラウドもお金かかるやん、みたいなことは各社感じると思う。 クラウドが今後成長するためには、クラウドならではの利用方法を醸成していく必要があるが、どうにもこうにも新
実装できる人がいない？大丈夫かこの業界 - orangeitems’s diary
最近、何件かの仕事を請けて共通していることがある。頂くドキュメントが非常に良くできているということだ。なぜ作ったか。どのように作ったか。そしてどう運用するべきか。一気通貫に述べられていて読むと非常に勉強になる。 ・・・それなら、このドキュメントを作った人が作ればいいじゃないか、なぜ私の手に次の仕事が来る？。しかもこんな素晴らしいドキュメント付きで。 一つには、このドキュメントとそれを実装することの価値について、読み解ける人がいなくなっている可能性を感じた。どうもベテランと呼ばれていた人たちが定年退職したり、別の仕事をし出している。かといって次世代が育っていない。ドキュメントを読みながら思うのは、書いた人は随分下の方のレイヤーのことをわかっているということだ。クラウドであればオンプレやネットワークのことまで熟知しているということ。 ところが、最近はカタログスペックというか、このサービスを使え
パワーポイントの時代は終わったのではないか - orangeitems’s diary
最近見ていないものと言えば、スライドだ。パワーポイントなどで作るような資料。ここ数年コロナ禍でイベントがかなり少なくなったから、というのもある。また、SlideShareに大量にスライドが出回っていたのが5年くらい前だったが、SlideShareが広告を強制表示するようになって、無料利用が減ったというのもあるだろう。 ともかく、技術的な情報がスライドで出てくることが体感で減少した。逆に、ブログ記事のようなテキストで表される情報の方が増えて来たような気がする。 技術的な情報は結構込み入った話が多い。パワーポイントで表現しようものなら、字ばっかりになって読みにくい。それならテキストでざっくり羅列したほうがいいんじゃないか、そんな理解が広がったのかもしれない。 特に、スライドにしたものをインターネットに更改するのはSlideShareの件もあってハードルが高くなった。PDFファイルにするという手
IaaSに戻るのを待ってました - orangeitems’s diary
インフラエンジニアをやってると、IT関連についてニュースが出る前に世間のトレンドがわかります。 ここ数年はマイクロサービスに人々は熱心でしたが、結局は局所的な流行で終わりそうです。コンテナまでは皆便利さはわかるのですが、それを本番環境に置く時に、結局はどこやらのベンダーが場所代を取るビジネスになっているのに気が付いています。マイクロサービスだろうと、過去の作り、いわゆるモノリシックであっても、動いてるものは同じ。金かかるならなぜわざわざ、慣れている技術者の少ないマイクロサービスにするのみたいな風潮は数年前より今の方がかえって強いような気がします。 Kubernetesはオープンソースですが、これ自体を無料で構築し自社オンプレで動かす、みたいなことをやって疲弊してパブリッククラウドのマネージドサービスに載せ替えた会社はたくさんあり、それを横目で見て、それだったら普通に仮想サーバーにミドルウェ
そりゃスパゲティーコードにもなるよな - orangeitems’s diary
お気の毒に・・。 www.nikkei.com スパゲティコードになるプロセスはよーくわかる。 仕様変更に次ぐ仕様変更、当初の想定が間違っていたことのフォローアップ、一つ一つ丁寧に進めていきつつ、当初の見積工数を超えないようにこれまでの成果物をできるだけ活かしたら、最終的にできるのはスパゲティーになる。 スパゲティーを作る人が悪いんじゃなくて、オーダーした人がスパゲティーを望んだからだとしか言いようがない。スパゲティーを作って欲しいと言っている人に、スパゲティー以外を料理する方法が思いつかない。麺類なら許されるのか？。 大企業のプロジェクト運用体制に、１つ起因する問題もある。長期に運用するシステムの場合、同じ担当者がずっと担当し続けることが難しいことだ。人が入れ替わる前提だと、毎回引き継ぎのタイミングで過去の情報を振り返らないといけない。この時ほぼ情報は抜け漏れる。どんなに優秀な人が担当し
技術レベルが低い、低過ぎる。 - orangeitems’s diary
ほんとにどうしようもない話だがここに書いておく。 明らかにメンバーの技術力が低い。低いがためにいろいろな不具合が出てしまい、それが表に出る前にいろいろ刈り取る仕事を今している。 しているのだが、私が刈り取っている時点で表に出ているようなもんだろうとも思う。私が気づかなければ、後々大変なことになっているなという確信がある。それぐらいのレベルだ。どうしてこれに気が付けない。 この半年くらい、相当忙しくて、メンバーに手取り足取り指導できていなかったのは認めるとして、それでも自立して欲しい、技術レベルを自ら上げていって欲しいと願っていたが、どうにもそれは叶わなかったようだ。やけに仕事が遅い割に品質も悪いとは。 きっとこの半年の間で、いろいろと私が見ていない部分で、雑な作り込みがどこかにあるような気がしていて、しばらくは総点検である。あの、総点検という言葉は、他人から言われるとムシャクシャしかしない
システム運用はお金で解決したい、ができなくなってきている - orangeitems’s diary
ビジネスは基本的に成長していくものだし、拡大していくことが前提で、しかも最近だと「システム」が付いてくる。全部人力で作り上げるビジネスなんてあるのか。いや、ない。あるとしても小規模だろう。人だけで成り立つなんてビジネスを放置しても、きっともはや、人が集まらない。コンピューターによる自動化はない。全部人力だ。さあ仕事しなさいって、それは原始的だろう。あらゆる仕事場で自動化ありきの人間の仕事が増産されているのであり、人々もそういう職場を狙っている。時代遅れの職場で、かつそういう人力の仕事は生産性も低く給料も安いので、どんどん敬遠されるようになる。 さて、じゃあシステム化しました、と。システム化するための要員はまだいるようだ。各社ベテランが腕を奮っている。DXの掛け声でクラウドもあって生産性は上がり、システムと名の付くものが量産されている。わかっている、システム構築のスピードは10年前と比べると
インフラエンジニアになるのは簡単か - orangeitems’s diary
Q. インフラエンジニアになるのは簡単か？ A. 簡単です。 インフラエンジニアでベテランの私でもこう答える。 ただし、なることと、上を目指すのは全く別のお話だ。インフラエンジニアを名乗ること自体は簡単でも、何を仕事にするかは恐ろしく幅が広い。 幅が広いから、スキルの表現が標準化されていない。何でもできるをフルスタックというのは簡単だけど、何がフルなのかを表現できる人は誰もいない。 自分はフルスタックだ、と言う人がいれば、それはあなたが働く現場の全ての業務、という意味でのフルであって、世の中の全ては捉えきれてはいない。 もはや、全てを知っているというよりは、未知なことがきてもなんとかできる、という意味合いの方がインフラエンジニアについては当てはまる。どんな要件が来ても基盤となる知識があるので、資料を読み解けば何とかできる、ぐらいの胆力が求められる。 未経験からのインフラエンジニア、という意
仕事ができる人が、マネジメントで苦労することを回避するために - orangeitems’s diary
仕事ができるってのはいいことなはずなんだけど、誰かに仕事をお任せすると、「遅いな・・」って思う。自分がやったらもっと速くて、正確なのに。 だから自分でやっちゃったほうが楽だし、プロセスが見られるので結果も想定できる。しかも自分の実力にもなるし、他人の仕事も減るし、自分ができるというアピールにもなる。だから、ついやっちゃう。 しかも、その仕事ができる人に、組織も甘えちゃって、難しい仕事は全部、できる人にまわっちゃう。というより、何も言わなきゃあの人がやってくれるだろうとなり、リスクの少ない、安全な仕事ばかり周りがやるようになる。 マネジメントに、仕事ができる人が就くと必ずこの状況が現れる。全ての現場仕事をシャットアウトして管理にまわるのではなく、一番できる人だから、ということでポジションにアサインされる。だから、組織で仕事をやってそれでもあふれた、難易度の高い仕事をマネージャーが受け持つとい
クラウドサービスと長年お付き合いして感じること - orangeitems’s diary
インフラ基盤をクラウドサービスに載せて管理することに、かれこれ10年近く携わっている。10年は長いので感想を書いてみたくなった。 とにかく強調したいのは、クラウドサービス自体の仕様が日々変わり続けるということだ。サービス開始当初はかなり雑な変更もあったが、ここ最近ではかなり慎重になりつつある。1年前にアナウンスするとか、変更後も過去の構成を許すなど。ただ、これも全ての現在を保証してくれることはない。場合によっては逃げの手も許さずサービス廃止してくることもある。 管理者が行うべきことは、毎日、お知らせを見逃さないことに尽きる。 クラウドベンダーは、変更を通知さえすれば全て許容されると思っている。どんな変更も顧客に取って前向きな書き方をしてくるが、本来前向きな変更など、１つもないのである。一度構築して安定して動いているのに、変更なんて加えるな、機能追加などいらない、なのである。「ビジネス上の理
IT業界未経験者がいかに経験者になるかという観点 - orangeitems’s diary
システムエンジニアがいかに未経験から経験者になるか、については様々な意見がある。以前のエントリーでは私が思う所を書いてみたが、これはモチベーションが高くて自分で自分をなんとかしたい人向けの話であった。 企業に所属して、未経験者を受け入れていると、この人たちどうするかい、という課題を突き付けられることがある。懇切丁寧に教えてやっと戦力になったかと思ったら転職されるみたいなことは日常茶飯事なので、私はもう直接手取り足取りの指導なんてことをするモチベーションは毛頭ない。たまに、有名企業が新人研修のコンテンツを外部公開し、自社の教育環境を誇っている記事を見かけるが、有名企業ぐらいたくさん毎年人を集めるならば、教育プロセスそのものを内製化するのはメリットがある。どうせ毎年やらねばならないのなら教材から、教育環境までそろえておけば使いまわしできるからである。しかし、自分の部下に一人、二人、と言うレベル
ドキュメントの限界 - orangeitems’s diary
インフラの環境構築を行ったときに、はい、環境です、と接続情報だけ顧客に提供したところで、そのまま受け取ってくれることはない。 ドキュメントはないんですか？。 何を作ったかを示すドキュメントとセットで初めて、プロにお金を払って仕事をしてもらった気持ちになる。今でも、ドキュメントを残せ、ドキュメントがないと今どうなっているかがわからなくなる、常に更新して最新にしよう、そんな掛け声は健在である。 このドキュメント、年々複雑さが増していると思う。というのも、IT関連のソフトウェアにしろクラウドにしろ、機能は増えるばかりだからだ。かつ、設定自体は年々洗練されており、デフォルト値で動くことも多い。たくさんの設定項目があるが、設定するのはほんの一部分である。 ドキュメントに何を残すべきか。設定値全てをドキュメントに書き込もうものなら莫大な量になる。一方で変更したものは少ししかない。このギャップが激しくな
システム運用とシステム構築、どちらが先か - orangeitems’s diary
インフラエンジニアっぽい記事をたまには。 システムには、構築の時期があって、そして運用の時期が訪れる。 構築時期をあらかじめ顧客と決め、ある時期から顧客が使い続ける。使い続けている中でいろいろと変更対応は必要になるので、これを運用と言う。 構築、運用。 あまりにも相対している概念なので、システムに携わる人々は、必ず構築部門か、運用部門の二つに分けられる。 ちなみに、私は構築から運用まで全部やってきた。区切りなく全部。ただ、業務が増えていくに従い全部自分でやるのはかえって無責任ということになった。なぜなら、私がいなくなったら誰もできなくなるからだ。会社ならば、誰かが欠けても支え合えるようにしておかないと存亡の危機となる。だから、私は最近、運用を少し離れ気味になりつつある。 さて、あまり経験のない若手が、さて構築を先にやったほうがいいか。それとも運用から入った方がいいか。この議論は私が若い頃・
休日にシステムエンジニアは勉強するべきかどうか - orangeitems’s diary
たまにSNSで論争になるので、意見を言っておこう。 日進月歩のIT業界でお勉強するべきかって話。 そりゃ、しないと置いて行かれるでしょうね。特にソフトウェア周りって、気を抜いているとどんどんバージョンアップして、操作方法も変わる。基本的なことさえ押さえていれば、あとは便利になっていくだけだから新しく勉強することなんてないよね勢がいるのもわかるが、それでも時間的に限界はある。7.0と8.0は大きな違いが感じられなくても、7.0と15.0はもう全然別のソフトウェアになっている。 どんなソフトウェアも、情報処理技術者試験で出てくるような基本から成り立っている。その上に応用としての技術があるので、基本をしっかり身に付けていれば、ある程度の技術の変化にはついていける。それは間違いない。 問題は、この基本の部分をどの程度習熟しているか。それこそ年齢が若い時に、仕事「以外」の時間も使って学ぶことをお勧め
表層的なAIにだまされている気がするという話 - orangeitems’s diary
ChatGPTがすごく、社会から過大評価を受けているような気がしてならない。 ということをうまく言語化している記事を見つけた。 www.businessinsider.jp しかし、筆者の感想は実は真逆だ。 むしろ、ChatGPTの成果によって｢会話AIが人間を超える存在になれないことは、ますます色濃くなった｣と感じている。 2020年ごろにParlAIを知った時は、筆者にも｢この先、会話AIはどう進化していくのか｣というワクワク感があった。ParlAIは短い返答しかしなかったから、長文で会話する未来に想像力を広げる余地があったのだ。 ChatGPTは、ある意味でParlAIの｢この先｣を全部やった。 その結果、ChatGPTのアプローチでは極めてつまらない人間、つまり“それっぽいことを、それっぽく話せるだけの人間”と、同じような振る舞いしかできないのだとわかった。 Google検索の時代
常駐している協力会社社員の気持ち - orangeitems’s diary
昔のことなので、思い出して書くけれど。西暦2000年になる少し前のこと。 大きな大きな会社に、おそらくSESとして常駐した。入館証も与えられたし自分の席もあった。専用のパソコンも与えられたが、ものすごくスペックが低く、業務用のアプリケーションを開くのに時間がかかった。そもそもスリープ機能なんてなかったので、OSは毎度電源オンしOS起動から始まったが、それも時間がかかった。あらゆることで時間がかかった。一緒に来ていた先輩から「パソコンが遅いってことはそれだけ遅く仕事していいってことだから気にするな」と言われてなるほどなと思ったこともあった。昔の生産性の低さはその辺りから来ている。何しろパソコンはまだまだ性能が低かった。 技術的な問い合わせに回答する仕事だったけれど、なんとも残念なことに検証環境が不十分だった。聴かれたことを実機で試せないのは本当に困る。ただ、今と違ってコンピューター資源が豊富
ダメな内製化もあるという話 - orangeitems’s diary
内製化すればいいというものじゃない、ということを考える。 japan.zdnet.com ガートナージャパンは1月18日、日本でのソフトウェア開発の内製化に関する調査結果を発表した。方針が内製化の方向にある企業が54.4％に上り、IT部門の人手不足が開発内製化の最大の障壁になっていることが分かった。 最近はデジタルそのものが商行為になることが多く、それ全体を外部ベンダーに乗っ取られたら、会社からノウハウが流出してしまうというのは正しいと思う。 だからといって、それを自社で全部賄うというのは、デジタル自体の仕組みから言ってかなり無理のある思想に思う。 デジタル自体、外部ベンダーが基盤を作っている。ハードウェアからネットワーク、ソフトウェアまで全部自社にあるものは何もない。 その上で書くコードだけは内製化、としても、かなり小さな面積だなと率直に思う。デジタルにかけるお金のうちかなりの額がすでに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
