新年あけまして2022
2021年の雑感
結局新型コロナは落ち着かず、withコロナにシフトして、在宅勤務がデフォになりました。
世の中的には、お出かけできるようになっただけでもマシって感じです。
お仕事的には、客先常駐が嫌いなので、「世の中在宅当たり前、客先にも入れない、だから全部リモートでよろしく」くらいが丁度いいですね。
短期案件だと、開始から終了まで、一度もお客さんの顔を見ない/こちらも見せない、というケースもありますが、慣れました。
これもよく言われている話ですが、各種イベントがオンライン化されて、自分も在宅勤務になって、リアルタイム参加/視聴率が激減しました。
「家族の時間」とかぶるんですよね。
これまで、どれだけ「仕事」と称して好き勝手イベント参加してたかを思い知らされる結果にも。
リアルタイムならではの臨場感、その場でのQ&Aなどには触れられない一方、Youtubeでのアーカイブ公開だと倍速再生で時短できるのは、正直かなり助かります。
リアルタイムだと2時間くらいあっという間なんですけど、いざアーカイブ視聴しようとすると、「2時間」って視聴開始すること自体をためらってしまう数字。
セッションごとのアーカイブが別だったり単一でもチャプター区切りが入っていると「神!」ってなります。
アーカイブ公開してくれているだけでも神なんですけど。
仕事面でわりと深刻な話としては、業界としてのいわゆる「需給バランス」が崩れててて、人手不足感がすごいですね。
ITエンジニアの需要が異様に高まってて、もともと足りてない人手がさらに足りてない感じ。
需要の高まりの悪い側面として、雑な案件、雑な受発注が増えてるように思います。
要件定義の甘さ、担当者の遂行能力、対外折衝能力、技術的会話の理解力、論理的思考能力とか、そのへん。
平たく言うと、求められるレベルは上がっているのに、技術レベルも、マネジメントレベルも、下がってる。
発注する側も、受注する側も、そこが一定水準に満たないままでも人が足りてなくて表に出てきてるひとが増えているような。案件が燃えやすくなってきてる気がしました。
優秀な人が外資ベンダーや勢いのある事業会社に吸い上げられていく傾向が、新型コロナ下での企業姿勢の差をより明確にしてしまって、格差がより拡大している気がします。
昨年の目標の振り返り。
AWS以外のクラウドの知識を増やす
OracleCloudはなかなか実案件が回ってこなくて、Solution Architect試験の年次更新だけ頑張っている感じでした。
年末にようやく関与することになって、進行中の案件でしたがかなりスムーズに入れた感じなので、それまで試験のためだけであっても勉強しておいたことが無駄じゃなかったなー、という実感を得られました。
それ以外のクラウドについては、まだ私のところにはそんなに降ってきてないです。
別の人が担当してたりするし、世の中的にはかなり増えてるので、そのうち回ってくるでしょうから、粛々と情報収集続けてます。
AWSの方は、Database Specialtyを取得。実務に直結している問題が結構多くて、やってよかったなと。
今年更新を迎えるSAP落としても「オレDB屋さんだしDBS持ってればいいっしょ」という言い訳ができるようになりました。
MySQL
ソースコードを読めるようになりたい(何度目?)
ソース読むどころか、MySQLをお仕事で触る機会が激減した1年でした。
7年前にこっちの業界に戻ってきて最初にガッツリ関わったのがMySQL案件だったということもあり、どちらかというとMySQLが自分のホームグラウンドのつもりだったんですけどね。。。
ただ、後輩にMySQLを自分より詳しくわかる人が加わってほとんどお任せにできるようになったし、同じレベルの細かい話ができるので、それはそれで良かったんじゃないかと。
マイナーバージョンアップごとの内容の追いかけすら、やや疎かになってしまったので、そこは戻さなきゃかなと。
MySQL8.0自体がだんだんこなれてきて、びっくりするような機能追加/修正が出てこなくなったことの裏返しのような気もする。
(自分があの文化に慣れ過ぎただけ?)
PostgreSQL
お仕事はPostgreSQL案件が非常に多かったです。
先日の記事で反響をたくさん頂いた「Oracleからの移行案件」のようなものも含め、私の周りではPostgreSQLの需要が高いです。
案件としてこなしていくと、その都度しっかり調査検証して取り組むネタに囲まれるので、だいぶ理解が進んだ気がします。
2022年は
AWS Solution Architect Professionalの更新
仕事的にはDBSあれば十分でしょ、と思いつつ、やはり一度取ったものを手放すのは惜しいですね。
この3年でえげつない量の機能更新があり、日々ニュースは追いかけているものの、AWS SAP認定対象者に求めるレベルでの理解度にはなっていないので、こりゃ大変だろうな、と。
AWS以外にも手を伸ばすつもりだけど、今年はこの大物がいるので、それを優先に。
MySQL、PostgreSQL
今年もデータベースはこの2つが軸になると思います。
そして、移行(移行診断)元としてのOracle。
お仕事上、乗り換え相談/診断を結構な数やっているのですが、「これなら乗り換えずに、残ったほうがいいよ」という診断結果も自信を持って提示するためには、ちゃんとOracleのこともキャッチアップしていかないとね。
MySQLもPostgreSQLも、なんとなく、「普通に使う分には十分な機能を備えてる」レベルになっていて、「あと何が必要?」って段階に入っている気がします。
なんとなくOracleの9i/10gから11g出るか出ないかみたいな頃の雰囲気。
Oracleに関して言うと、複数DB立てる予定のない人にとってのPDB/CDBとか、RAC組む予定のない人にとってのGrid Infrastructureとか、思うところあるわけですよ。
そういう方向に機能(覚えなきゃいけないこと)が膨らんでいくのか、踏みとどまるのか、斬新な機能が突如現れるのか。
AWRみたいなのが強化されるのは大歓迎です。
MySQLに関しては、OracleCloud上での利用(OCI MDS)のための機能追加が増えるトレンドは続きそう。
PostgreSQLは、機能追加についてはExtensionの方で進むと思うので、主要クラウドベンダーが何をいつ取り込むか、が専らの関心事です。
RDBMS on k8sが、昨年初に比べるとかなり話が進んできている感じがあるので、そろそろ手を出さなきゃかな。。。
これも、未だに「覚えること(レイヤ)が増えただけ」感が非常に強いのが正直なところ。
オンプレ従来構成で間に合っているところ、クラウドベンダーのマネージドサービスで間に合っているところ、にとって、k8s上に立てるメリットはあんまりなさそうで、RDBMS on k8sによってメリットを得られるような組織/システムととそうでないところとで開きが大きく進むんじゃないかな。
マネージドサービスなDBのウラがk8s上で構築されてて知らないうちに使ってました、は出てくるだろうけど。
どのへんの層をお客さんとしてお仕事していくかによって変わってきそう。
普段Twitterで目にしている人たちとは、かなりレベル感の違うところの人/組織を相手にすることが多いので、そのへんのバランス感覚は重要だと思ってます。
そして、年に数件、NoSQLなDBの仕事や、そもそもDBじゃねえよってところのフォローのお仕事(DB本体は社内の他のメンバーをアサイン済)が回ってくるのがいつものパターン。
そんな感じで
ブログ更新が少なかったので、もう少し増やしたいなとは思うけど、これについては数を目標にするつもりはないです。
書きたいと思ったこと、書くべきと思ったことを書く、それだけです。
今年も飄々とやっていきます。