セキュリティインシデントのニュースを見るたびに思うこと

また大きな情報漏えいのニュースが流れてきた。この手のニュースを見るたびに、他人事ではないという緊張感と、どこか慣れてしまった自分への違和感が同時に湧いてくる。

報道されるインシデントの多くは、原因を辿ると特別高度な攻撃というより、地味な設定ミスや古いシステムの放置であることが多いという印象がある。自分たちのシステムでも、レガシーな部分の棚卸しをするたびに、似たような火種がいくつも見つかる。派手な脆弱性より、こういう地味な穴のほうがよほど怖い。

攻撃側の分業化

ここ数年で気になっているのは、攻撃する側が明確に分業化・産業化してきていることだ。脆弱性を見つける役割、侵入する役割、身代金交渉をする役割が分かれているという話を聞くと、もはや個人のいたずらというレベルではなく、一つの経済圏として成立しているのだと感じる。

防御する側としては、完璧な防御は不可能だという前提で、被害を最小化する設計に頭を切り替える必要があると思っている。侵入されないことを目指すだけでなく、侵入された後にどれだけ早く気づき、どれだけ被害を限定できるかという発想の方が、今の時代には現実的だ。

社内向けの啓発活動にも変化があった。以前は「怪しいメールを開くな」という注意喚起が中心だったが、今は生成AIを悪用した巧妙な詐欺メールや、音声を模倣した詐欺電話への注意喚起も加わった。技術の進歩が、防御側だけでなく攻撃側の表現力も底上げしているのだと痛感する。

個人的に気をつけているのは、パスワードの使い回しをやめることと、重要なアカウントには多要素認証を必ず設定することくらいの、地味な基本動作だ。派手な対策より、基本を徹底することのほうが結局は効くというのは、セキュリティに限らず仕事全般に通じる教訓のような気がしている。

インシデント対応の訓練にも参加している。実際に手を動かして初めて気づく手順の抜けや、連絡系統の混乱は多い。頭で分かっているつもりのことと、実際にできることの間には、思っている以上の差があるというのを、訓練のたびに痛感させられる。次の訓練までにマニュアルを見直そうと毎回思うのだが、日々の業務に追われて後回しにしがちなのが正直な悩みだ。

セキュリティのニュースは、正直あまり気持ちの良いものではない。それでも目を逸らさずに追い続けることが、自分たちのシステムを守る第一歩なのだと思って、今日もいくつかの記事に目を通した。

データセンターと電力問題、AIが突きつける現実

AIモデルの学習や推論に必要な電力が急増しているというニュースを、ここ最近よく目にする。データセンター建設のたびに、周辺地域の電力インフラへの影響が話題になる場面も増えてきた。エンジニアとしてクラウドリソースをポチポチ確保している立場からすると、その裏側にある電力の話は普段あまり意識してこなかった。

自分のチームでも、モデルを使った機能を検討する際に「精度は上がるが計算コストも跳ね上がる」という選択を迫られることが増えた。以前ならコストといえばクラウド利用料の話で完結していたが、今はその先にある電力供給や環境負荷まで視野に入れて説明を求められる場面が出てきている。

効率化と需要増のいたちごっこ

チップやモデルの効率は年々上がっていると言われるが、それを上回るペースで需要が増えているようにも見える。効率化によって浮いたはずの電力が、結局はより多くの計算に使われてしまうというのは、他の産業でも見た構図に近い。

データセンターの新設をめぐって、地域住民との摩擦が報じられることも増えた。雇用や税収を歓迎する声がある一方で、電力や水の使用量への懸念も根強い。テクノロジー業界の内側にいると忘れがちだが、これは紛れもなく地域社会の生活に直結する話だ。

冷却方式や立地の工夫によって効率を上げる取り組みも進んでいるようだ。寒冷地にデータセンターを置いたり、排熱を近隣の施設で再利用したりする事例をニュースで見るたびに、地味だが重要な工夫だと感じる。派手なモデルの性能競争の裏で、こうした泥臭い最適化が積み重なっているのだと思う。

自分の仕事に引き寄せて考えると、機能を作る前に「これは本当に必要な計算か」を一度立ち止まって考える癖がついた。以前なら精度が上がるならとりあえず使ってみようという発想になりがちだったが、今はコストと環境負荷の両方を天秤にかけるようになった。

音楽鑑賞が趣味だと言うと意外がられるが、電力の話とは無縁ではない。ハイレゾ音源のストリーミングも、突き詰めればどこかのサーバーとネットワークの電力を使っている。趣味の楽しみ方一つとっても、見えないインフラの上に成り立っているのだと、改めて意識するようになった。

便利な機能の裏には、誰かが確保しなければならない電力があるという当たり前の事実を、意識して忘れないようにしたいと思っている。少なくとも自分が設計に関わる部分では、無駄な計算資源の消費には敏感でありたい。

半導体不足から学んだサプライチェーンの脆さ

数年前の半導体不足で、開発機材の調達が数ヶ月単位で遅れたことがあった。新しいサーバーを増強したくても部材が届かず、既存機材をやりくりして凌いだ記憶は今でも生々しい。あの一件で、自分の中の「モノは注文すればすぐ届く」という感覚がだいぶ崩れた。

半導体は特定の地域や企業に製造が集中しているとよく言われる。一部の工程は世界でもごく限られた場所でしか担えないという話も聞く。効率だけを追い求めれば集中は合理的だが、何か一つ止まるだけで世界中の供給網が影響を受けるという脆さと隣り合わせなのだと実感した。

分散という選択のコスト

その反省からか、各国で製造拠点を自国や友好国に分散させようという動きが進んでいるようだ。ニュースで大規模な工場建設の話を見るたびに、これは経済合理性というより安全保障の色合いが強い投資なのだろうと感じる。

ただ、分散にはコストがかかる。集中させたほうが安く作れるものを、あえて複数箇所に分けて作るのだから、その分の価格は最終的にどこかで吸収されるはずだ。自分たちが使っているサーバーやデバイスの価格にも、いずれ形を変えて跳ね返ってくるのだろうと想像している。

あの頃の教訓として、社内では調達リードタイムを長めに見積もる文化が根付いた。以前は「必要になったら発注すればいい」という感覚だったが、今は半年先の計画段階から機材の見込みを立てるようになった。急な変化に振り回されない体制づくりという意味では、悪いことばかりではなかったのかもしれない。

個人としても、身の回りの電子機器を無闇に買い替えず、長く使う方向に意識が変わった気がする。壊れるまで使うというより、次の調達が読みにくい時代だからこそ、手元にあるものを大事にするという感覚に近い。大げさに言えば、サプライチェーンの脆さを知ったことで、自分の消費行動まで少し変わったということになる。

料理でも似たようなことを考える。旬の食材が手に入りにくくなったときのために、いくつか代替できる食材の組み合わせを覚えておくと、献立が立てやすくなる。システムの冗長設計と発想は同じで、単一のルートに頼りきらないという習慣は、どうやら仕事と生活の垣根を越えて自分の中に染み付いているらしい。

効率と安定のどちらを取るかという問いに、絶対の正解はないと思う。ただ、あの数ヶ月の調達難を経験した身としては、多少コストがかかっても供給が安定している方を選びたくなる気持ちは、今もどこかに残っている。

サブスクリプション疲れとSaaS業界の岐路

先日、個人で契約しているサブスクリプションを見直したら、動画配信、音楽配信、クラウドストレージ、開発ツールまで含めて想像以上の数になっていて驚いた。仕事でSaaSを売る側にいながら、自分がまさに「サブスク疲れ」の当事者だったことに苦笑いした。

法人向けのSaaSでも似た空気を感じる。導入時は便利さに惹かれて契約したツールが、気づけば使われなくなり、それでも解約の手間を惜しんで契約が惰性で続いているという話をあちこちで耳にする。ツールが増えすぎて、どれが何のために入っているのか誰も把握していない組織も珍しくない。

値上げラッシュへの反応

ここ数年、多くのSaaSが値上げに踏み切っている。円安の影響もあって、海外製ツールのドル建て価格が日本の顧客には重く感じられる場面も増えた。値上げのたびに解約を検討する企業が増え、営業側としても以前より価格説明に時間を割くようになった実感がある。

一方で、統合型のプラットフォームに機能を集約させて、乱立したツールを整理する動きも出てきている。単機能のSaaSにとっては厳しい局面だが、利用者側からすると歓迎できる流れでもある。

営業の現場では、複数の単機能ツールをまとめて置き換える提案がしやすくなったという声も聞く。以前は「うちはこれ専用のツールを使っているから」と断られていたところが、コスト削減の文脈で話を聞いてもらえるようになった。景気の良し悪しに関わらず、コスト意識そのものは業界全体で底上げされている感覚がある。

個人の契約整理をした結果、結局解約したのは半分ほどで、残りは意外と使っていることに気づいて継続を選んだ。契約数を減らすことそのものが目的ではなく、何にお金を払っているかを自覚することが大事なのだと、当たり前のことを再認識した。

解約の手続きが意図的に分かりにくく作られているサービスに出くわすと、正直うんざりする。自分が開発に関わるプロダクトでは、少なくとも解約導線だけは誠実に作りたいと思っている。目先の継続率より、長期的な信頼のほうが結局は資産になるはずだ。地味な機能ほど、実は顧客からの評価に直結しているのだと、この仕事を続けていて何度も実感してきた。

作る側としても使う側としても、これからのSaaSは「便利だから増やす」段階を終えて、「本当に必要なものだけ残す」段階に入っていくのだろうと感じている。自分の財布と向き合いながら、そんなことを考えた週末だった。

リモートワークとオフィス回帰、揺れる働き方

週何日出社すべきか、という話題はもう何年も業界を賑わせている。うちの会社も例に漏れず、フルリモート推奨だった時期から、今は週2〜3日の出社を求める方向に振れた。周りの会社を見ても似たような揺り戻しを経験しているところが多いようだ。

個人的には、リモートワークそのものには恩恵を感じている。通勤に使っていた時間を料理や読書に充てられるのは正直ありがたい。集中して設計に取り組みたい日は、家で作業したほうが捗ることも多い。

失われたのは何だったのか

それでも、完全リモートの時期を経てから振り返ると、雑談の中で生まれるちょっとした気づきや、隣の席の会話から拾える情報が減っていたのは事実だと思う。会議の議題には上がらないが、後から効いてくる類の情報共有は、オンラインの仕組みだけでは代替しきれなかった。

オフィス回帰を進める会社の説明を見ていると、生産性データを根拠に挙げているところもあれば、単に不動産投資を回収したいだけに見えるところもある。理由が透明でない出社方針ほど、現場の納得感を得にくいのではないかと感じる。

もう一つ見過ごせないのが、住む場所の選択肢との関係だ。フルリモートが前提だった時期に地方へ移住した知人が、出社方針の変更で通勤圏内への引っ越しを迫られたという話を聞いた。会社の制度変更が、個人の生活基盤にまで影響を及ぼすというのは、あらためて重い話だと感じる。制度を決める側は、この種の副作用まで含めて考えているのだろうか。

マネジメントの立場からすると、評価の難しさもよく話題に上る。出社していれば頑張っている様子が見えるという単純な話ではないはずだが、無意識のうちに「見えている時間」を評価に反映させてしまう管理職は少なくない。この評価の歪みをどう補正するかは、出社方針そのものより根深い課題だと思っている。

子育て中の同僚にとっては、出社日数の増減がそのまま生活設計に直結する切実な問題だという話も聞く。独身の自分には見えにくい負担があることを、意識して想像するようにしている。制度の議論をするときは、自分とは違う生活状況の人の視点を欠かさないようにしたい。

結局、働き方の正解は業種やチームの性質によって違うのだろう。自分としては、集中作業はリモートで、議論や意思決定が絡む場面は対面で、という使い分けが今のところしっくりきている。制度がどちらに振れても、この線引きだけは自分の中で持っておきたいと思っている。

エンジニアにとって「読書」が武器になる理由

月に4〜5冊は本を読む。技術書は半分もなくて、大半はSFかノンフィクションだ。仕事の役に立つかと聞かれると、直接的にはあまり立たない。それでも読書をやめる気にはならないし、むしろエンジニアという仕事にとって本を読む習慣は地味に効いていると感じている。

SFを読んでいて得るものは、突飛な発想そのものよりも「前提を疑う」訓練だと思う。設計のレビューをしていると、誰も疑問に思わずに積み上がった前提が後から足かせになるケースをよく見る。当たり前を当たり前と思わない癖は、フィクションの世界を何度も歩き回ることで少しずつ養われる気がしている。

ノンフィクションが教えてくれる時間感覚

ノンフィクションからは、技術や産業が思ったより長い時間軸で動いているという感覚を教わる。今話題になっている技術トレンドも、たいていは十年単位の助走があって今の形になっている。目先のニュースに一喜一憂しがちな業界にいるからこそ、長い時間軸で物事を見る視点は意識して持ち続けたい。

もちろん、読書量が多ければ良いエンジニアになれるという単純な話ではない。実装力や設計力は、結局のところ手を動かした量に比例する部分が大きい。ただ、手を動かすだけでは磨かれない判断力のようなものがあって、それを補ってくれるのが読書なのだと思う。

音楽を聴くこととも少し似ていると思う。ジャズを聴いていると、決まったコード進行の中で演奏者がどう解釈を変えるかに耳が向くようになる。同じ「正解」がない中で、自分なりの筋を通す訓練という意味では、読書も演奏も設計レビューも根っこは同じ感覚を使っている気がする。

職場の若手にも、時間があれば技術書以外も読んでみてほしいと伝えている。押し付けるつもりはないが、技術書だけを読んでいると、どうしても「正しいやり方」を探す発想に偏りがちになる。小説やノンフィクションは、答えのない問いに付き合う体力をつけてくれる、数少ない訓練場だと思っている。

読んだ本の感想を短くメモに残す習慣も続けている。数行程度の簡単なものだが、後から見返すと、その時々の自分が何に引っかかっていたかが見えてきて面白い。技術的な学びをドキュメントに残すのと同じ感覚で、読書の記録も自分なりの資産になっている気がしている。

忙しい時期ほど本から遠ざかりがちだが、そういうときこそ数ページでもいいから開くようにしている。積読が増えていくのは少し気が重いが、それも含めて自分にとっては悪くない習慣だと思っている。

生成AIコーディング支援ツールと一年付き合って思うこと

去年の今ごろ、チームで生成AIのコーディング支援ツールを本格的に導入した。最初は半信半疑だった。定型的なテストコードやボイラープレートを書かせるくらいならまだしも、設計判断が絡む部分まで任せるのは怖いという空気がチームにもあった。

一年経って振り返ると、使い方の勘所がだいぶ変わった。最初の数ヶ月は「とりあえず全部書かせてみる」フェーズで、出てきたコードを丸呑みしては後から痛い目に遭うことが何度かあった。存在しないライブラリの関数を平然と呼び出すコードが出てきたときは、さすがに全体をレビューし直す羽目になった。

道具として手に馴染んできた

今は違う。骨格の設計は自分で決め、退屈な実装の肉付けをAIに任せるという分担が、ようやく自分の中で定着した気がする。特にログやエラーハンドリングのような「書けば書くほど時間を食うが本質的ではない」部分を任せられるようになったのは大きい。体感として、実装にかかる時間は以前より短くなったと思う。

一方で、若手の学び方には少し気を配るようになった。自分で手を動かして詰まる経験を飛ばしてしまうと、後々のデバッグ力に響くのではないかという懸念は、今でも拭いきれていない。実際、レビューの場で「なぜこの実装にしたのか」を聞いても答えられないことが増えた気がする。

チームの運用ルールも少しずつ変わってきた。AIが生成したコードには必ず生成者本人がテストを書き、なぜその実装にしたかをPRの説明欄に一言添えるというルールを作った。些細なことだが、これだけでレビューの質が目に見えて上がった。丸投げではなく、間に人の判断を挟むという当たり前の工程を、改めて仕組みとして明文化する必要があったのだと思う。

導入コストの話もしておきたい。ライセンス費用自体はさほど高くないが、使いこなすまでのプロンプトの工夫や、社内のガイドライン整備には想像以上に時間がかかった。効果が数字で見えるようになるまで、半年近くかかったというのが正直な感想だ。短期的な費用対効果だけで判断していたら、途中で見切りをつけていたかもしれない。

結局のところ、道具そのものの是非というより、道具にどう向き合うかという話に帰着するのだろう。読書と同じで、要約だけ読んで分かった気になるか、原典に当たって自分の頭で咀嚼するかの違いに近いのかもしれない。自分はもうしばらく、後者のやり方にこだわっていきたいと思っている。