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

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

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

分散という選択のコスト

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

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

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

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

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

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

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

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

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

値上げラッシュへの反応

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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