2026年2月16日月曜日

これからの時代に備える

2026年は失業の年か跳躍の年か

アメリカではブルーカラーへの雇用が増加しており、ソフトウェア産業をはじめとしてホワイトカラーの就職が困難になっている。
データで分かるのは、若手、中間管理職層がリストラ対象というもの。アメリカでは『ジョブ型雇用』であるのに対して日本は『メンバーシップ雇用』のため、アメリカほど失業が進むということはない。
AIで代替の筆頭となっているのが『ソフトウェアエンジニア』。プロジェクト管理者というのも次点では高いため、実はマネジメントもそのうち置き換えられると予想されている。

第四次産業革命(AI革命)

第一次産業革命~第三次産業革命で電話交換手やタイプライター、手工業職人などは消失し、その間にラッダイト運動なども数年続いて機械が壊されるなどという反対運動が起きた。
しかし、失った職の代わりに生まれた職もある。
自動車整備士、ITエンジニア、Webライター、人事などである。
そして、第四次産業革命が2026年から始まるかもしれないという予兆が出ていて、アメリカを中心として失業者や雇用難が生まれている。

生まれる職

先ほど、ソフトウェア産業は失業すると言う予測がたてられていると言った。
生まれる職としてはどういうものがあるか。
第三次産業革命で生まれた職から類推できることとしては、その工場や自動車、コンピュータなどを通じて自動車整備士、工場勤務者、ITエンジニアというのが生まれたのを考えるに、AIを中心として生まれる職がある。
例えば、AIモデル評価人というのは面白そうだ。AIの出した回答を評価する高度判断人。AIによるセキュリティ監査人。AIへプロンプト設計者。データ調整人。
意外とAIで出される文章を査定する人が必要で、高度な読解力を持つ人や評価できる専門家、判断人が出てくるというのは面白い。

今からでも職業や得意を名乗っちゃえばいいんじゃね?

アメリカでは非技術者がAIで出したコードがめちゃくちゃでそれを再度修理してくれるプログラマーが欲しいということで新しい雇用、というか仕事をしている人がいた。(なんて言ってたっけ?)
なので、出したコードを評価してくれる専門家はAIに頼ることなく更なるプログラミング力を必要としていたということで、今の時代を逆行しているようでなんか興味深いよねという。
今は経済産業省が出している需要のあるAI人材としてデータエンジニア、データサイエンティスト、AI開発者などを挙げていたけど、それもいつかはなくなりそう。
今からでもリスキリングなどと言わず、AIをこよなく愛して、使い倒して、AIの良しあしや得手不得手を理解して評価する側になってしまってもいいと思う。
そして、AIが出している回答を深く読解し、判断をする。
という今は仕事ではないけどめちゃくちゃやっておいて、言っちゃえばいいんじゃね?って思っている。AIめっちゃ使ってて、AIの良しあし分かりますとか。AIが出したコードをセキュリティチェックして正しいコードにしますとか。読みやすくしますとか。
人っぽいスキルというか能力がどんどん必要になりそうだなと思う。
読解力は自分も得意なので、NotebookLMで要約できるから要らないと言わず、こよなく読解力を向上させて自分の人生を豊かにしていきたいと思っている。

一応AIの時代に先んじて必要といわれる力

  • 批判的思考
    • AIの出した答えをそのまま使うってめっちゃ怖いし責任だれ取ってくれるの?っていう話。
    • AIはそれっぽい回答をするだけ。誰がハルシネーションを判断して戻すのか?
  • 問いを出し続ける力
    • これが一番言われている。
    • 要は思考体力が大切で、AIに何かを書いてもらうときに問いがないと意味がないよねっていう。
    • 仮説を出して、意味を問うというのはこれからはもっと大切。
  • 人間関係構築
    • まあAIにはできないでしょっていうもの。
    • 営業とかは多分文章やメールを出すというのはAIで書くけど、顧客と関係性を保つ力とか人間関係を築いて信頼してもらうのは大切だろう。
    • それは他の人も一緒
要は、人間っぽいこと、人間らしいものを再定義するというのが今はやった方が良さそうだねっていう話でした。

2026年2月6日金曜日

ITエンジニアの今の市場感

  •  自社開発
    • SaaS
      • 採用条件・・・軒並み厳しい
      • 要件・・・基本シニアエンジニア、テックリード、EMのみの採用
        • 具体的には年収600万円以上のバリューを発揮する人のみ
        • 600万円以上のエンジニアに求められている技能
          • 技術的意思決定をしてきた経験
          • 技術選定をしてきた経験・・・選定理由などが合理的かどうか。それを判断できるテックリードが面接を行う。
          • 技術リード経験・・・技術的にリードをしていると分かるエピソードがあれば、実質他のエンジニアよりも技術力があるということがわかり、システム構築においての技術力を担保できる。
          • ビジネス理解力・・・リードする人がビジネスを理解していないととんでもない負債になる可能性があるため。あるいは話し合いにならないため。
          • AIの使い方・・・AIを使って価値を最大に出せる人が欲しい。どういう風に使っているかまで聞く。
      • 分析結果
        • SaaSの中でもドメイン特化領域を持つバーティカルSaaSは採用条件がちょっとだけ緩め。
        • 幅広い企業にサービス提供をするホリゾンタルSaaSは採用がとても厳しい。ジュニアの採用は一切しないという気概を感じ取った。
      • 結論:ビジネス的素養と技術的素養が高い人が欲しい。
    • Web
      • 採用条件・・・まあまあ厳しい
      • 要件・・・他責思考じゃないことが一番大事
        • 年収帯は550万円~
      • 分析結果
        • その人の思考の癖を知りたい会社が多い。
    • 結論:SaaSよりは厳しくはないけどビジネス的に変化が大きい分野でもあるため、結論、変化についていける人や他責ではない人を求めている。
  • SI・受託企業
    • 採用条件・・・案件が増えている分野では人が欲しい
    • 要件・・・データ分析基盤の人気が上がっている。AI基盤構築も人気が高い。トレンドはDX。
    • 分析結果
      • クラウド移行の案件が多かった時代から次第にDXの案件が多い。
      • DXにおいて大切になるのはAIとデータ。
      • データ分析基盤構築の受託企業(例えばDATUM STUDIOやデータエンジニアを採用したい会社)は割と積極的に採用をしている。
      • 業界特化型のSIerは生き残っている様子。業界理解で顧客のDXを推進できるという強みを活かしている。
      • AIで大手での開発が内製化するような流れがあるからか、技術が強いエンジニアを採用したい大手子会社や今までベンダー依存だった企業が内製化に進めるため、今後はなるべく技術決定に強い組織にする流れがあるのだろうか。
    • 結論:大手SI、技術特化受託、SESでエンジニアが流動している。ベンダー依存をなくしたいので先に技術要員を取り入れている大手もある。
  • まとめ
AIにより、全体的にコーダーやプログラマー志向の人は一切採用されなくなっていると感じる。ジュニアレベルまたは適性がないと判断されるような場合は一切許容しないというレベル。
それでも開発者としてまだ欲しい企業もあり、そういう会社は今までベンダーコントロールや外注依存をしていた会社で、逆にSIerや自社開発でコードを書いてて、ある程度コミュ力ありそうだったら欲しいっていう感じ。AI利用が進んでいない企業は先に内製化のための開発人材を採用しているような印象。
AI利用を既に深く進めているSaaS企業や技術理解が高いベンチャー企業はビジネス理解や技術リードの経験を求めていて、年収もそれなりに高い。
SIerが外注しない傾向にあるので、SESはもしかしたら今後案件がないのでは?と思うような場面がままある。

2025年12月7日日曜日

モノリス状態遷移からイベント駆動型アーキテクチャへの移行

 キューイングシステムを深堀りたい

背景:

SidekiqワーカーがWebサーバーが入っているEC2に同居している状態。Railsモノリスから脱却し、疏結合化を進めることで、スケーラビリティを向上させたい。

現状分析:

  • Railsモノリスの巨大な泥団子システム。
  • 調べるとapp/model/concerns/hoge_enum.rbにワーカー呼び出しが集結
    • app/worker配下にsidekiqのワーカー処理たちが書かれている
  • gemのstateful_enumを使用してイベント駆動で状態遷移をするようになっている。
  • イベントが発火したafterで色々なことをしていて、もしかしたら死んでるキューがあるかもしれない
問題:
  • EC2にSidekiqが同居しているため、リソース競合が発生して、CPU負荷が高い
    • メモリもジリジリと上昇していてサーバーダウン発生
  • 結合度が高いため変更する時バグが入る可能性
解決方法
  • SidekiqワーカーをWebサーバーから切り分けて独立したサーバーに設置
    • メッセージキューを使用して非同期のイベント駆動型アーキテクチャを実現する
    • CPU負荷特化のインスタンスファミリータイプを選び、最低限のリソース選択でコスト最適化
  • 信頼性向上のためにDBで冪等性を確立する
    • イベント記録をして二重実行を防止することで信頼性向上
移行時の注意
  • 冪等性確保のための状態管理テーブル作成
    • イベントが記録されてトランザクション追跡が可能
    • 処理前、キューイング、処理後のステータスを管理
    • 一意にレコードを特定できるよう、複合ユニーク制約などの設計
  • DLQ(デッドレターキュー)・・・何度も失敗しているキューの処理
    • リトライ処理5回以上のキューをDLQとして管理
    • 手動で再実行
      • 何かしらの失敗であれば良いが、永続的な失敗の場合はダッシュボードなどからの対処が必要だったりする
    • 自動で再実行
      • 永続的な失敗
        • 自動で削除または処理ができるように設計
      • 一時的な失敗
        • ネットワーク障害などの一時的な失敗であれば、再度実行する仕組みでリトライ
  • CI/CDの二重デプロイ
    • Webサーバーとワーカーを分離
  • 出品者商品情報のDB書き込みとメッセージキューの送信の整合性
    • Outboxパターンを適用
      • Outboxテーブルを個別用意。出品者のDB書き込みが発生したとき同一トランザクションでOutboxテーブルに書き込む。
      • メッセージキューはOutboxテーブルを見て送信。
      • 実質、「商品の状態=Outboxの状態」となり、冪等性を担保することでメッセージキューはDBとの整合性が保証される。
移行手順
  • ストラングラーフィグパターンを実行
    • ツルが木を巻きつけるようにして徐々に入れ替わる様からそう言われている
      • 段階的に進めるにあたり、一部の処理からスタートしていき徐々に全体へと進める
    • よくSIerはビッグバンリプレイスをするけど、DevOpsをしている会社はこちらを採用する方式になると思う
  • フィーチャートグルスイッチ
    • 外部コンフィグからON/OFFをして失敗時の復旧を外部から瞬時に戻すことができる
    • ブランチバイアブストラクト
    • カナリアリリース
      • 何パーセントのユーザーにだけ新しいリリースの実行結果が行われるようインフラを構成
技術選定
  • メッセージキュー
    • Amazon SQS・・・フルマネージドで運用の負荷は軽い
    • RabbitMQなどOSS
      • オンプレミスとかではこっちだけどクラウドで選ぶなら理由は自分たちで色々と実装をしたいとか?
    • Kafka、Amazon Kinesisなどのイベントストリーム系
      • シャーディングの仕組みなどでSQSよりも大幅なスループットが可能
      • パーティションで区切り、処理を分けることが可能
      • FIFOの先入先出し削除でデータ処理後に削除するのではなく、データの永続化が可能
  • サーバー
    • Webサーバーは継続してEC2だろうね。常時つけるから
    • 問題はワーカーサーバー
      • こっちはコンテナ化してみて部分的にECSを実現してみるとかいいんじゃないかな?

2025年12月6日土曜日

強みねーな・・・っていうとき

👥「naohiroさんの強みって何ですか?」

👦「(やっべ...全部必要だと思ってたし強みとかないな)設計です!」

👥「では、何をされていましたか?」

👦「実装とかDB設計とかAWS触ったりとか運用とか...」

👥「...(なさそうや)不採用」

👦「ああああなんでいつもこうなんや」

今までフルスタック(全部やれ)をやっていたから全然強みとかないな。。どうしよ。と将来大人になったときが心配になってしまったので強みを探していく実際の流れを書いてみたいと思います。

背景:そもそも前職では技術力というより、リーダーシップの発揮がとても大切な会社でした。そうするとエンジニアとしての強みというのは技術的にはあまり主張できないことになってしまいます。

テーマ:T字型人材を目指す

幅広い強みがあることはいいことですが、何か専門的なスペシャリティを持っていた方がよいというのが最近のトレンドなんじゃないかな?と最近面接していて思いました。(される方です)

なので、T字型人材を目指すために振り返りをしたことや分析してみたことを実際にステップごとに書いていきます。

前提

  • 今まで強みとかないし何でもかんでもやっていた人
  • 選ぶ=他を捨てる

自分の好き・得意を掘り下げる

  • 今まで自分がやっていてこれは得意そうだとか好きだなって思ったこと
  • 気づいたらなんか情報収集してるやつ
  • こういうことをやっていた時結構集中して熱中してたなと思うこと
経験が多いこと
  • 何だかんだ経験が多いことは?
相手を見る
  • 市場に幅広く求められている
  • スペシャリティ
    • ニッチな分野
    • 他の人が見てなさ過ぎて競合がいないため枯渇している部分
  • インパクトの大きさ
    • ビジネス的なインパクト
    • 開発チームへのインパクト
      • 会社へのインパクトが大きい
テーマで区切る
  • 自動化
    • IaC
    • テスト自動化
  • 信頼性
  • セキュリティ
  • クラウド
    • クラウドアーキテクチャ設計・構築
    • マルチクラウド対応
    • AWS特化、GCP特化、Azure特化
  • パフォーマンスチューニング
    • 性能調査
    • オブザーバビリティ
  • データ設計
    • データ構造→非構造、半構造、構造化データ
  • コーディング
    • 言語別
  • アジリティ・デリバリー
  • アーキテクチャ
    • ドメイン駆動設計
    • 分散型アーキテクチャ
  • コスト最適化
  • マネジメント
  • 顧客折衝
  • 品質保証
  • ...etc
何が欲しいか
  • 年収
  • 将来性
    • 安定性
    • ワークライフバランス
  • 自由さ・責任の境界
  • 会社のブランド
    • 会社規模
    • 社名
  • 活躍度・楽しさ
  • 0→1
  • 知名度
  • ...etc

自分は?
  • 年収欲しい
  • 将来性欲しい
  • 責任感からか、より根本を直したいと思う性格からか結構事業リスクとか考えてやっていたかもしれない
    • 開発プロセスとか
    • サーバーの障害リスクとか
    • 技術負債とか
    • やべー誰も分からねぇっていう状況をゼロにしたいと思った
      • ドメインをいの一番で理解しておいて人に教える
      • リファクタリングとかコメントとかめっちゃ書いてた
      • ていう割にはテストはあまり書いてなかった
    • ドキュメンテーションみんなやらなすぎじゃね・・?って思った
      • 逆に言うと割と書きたいかもしれない
  • だから逆にいうと新規機能開発ってあんまりやってなかったかも
    • ていうかやりたい人多すぎてた
    • そういえばSIerの時にやってたのってほぼほぼ拡張か構成管理かリプレイスだった
      • 新規機能の耐性ついてないな
      • カオス好きじゃないな。不確実性はめっちゃ減らしたい
  • 設計とか楽しい
    • DB設計とかは楽しいんじゃないかな
      • 一番負債になるのここだったし
    • DDDとかも結構勉強はしてた
      • でもRailsではやらない方がよいっぽい
    • システム移行とかリアーキテクチャには興味がある
      • でかいことやりたいな
    • AWS
      • めっちゃコストかかってね?って思ってからは最適化したいと思った
      • 運用大変じゃね?って思ってからは自動化したいって思った
      • これ構築とか楽しくね?って思った
      • サーバーの冗長化とかDRとかマルチAZとかレプリケーションとかDBの移行とか楽しくね?って思った
  • 実装
    • 楽しくはなかったかもしれない
    • AIでよくね
    • 実装めんどくせって思っちゃう
  • 勉強してて楽しいのは?
    • スケーラビリティ
      • オートスケーリング
        • 垂直スケール、水平スケール
      • キューイングメッセージ
      • ロードバランサー
        • リクエスト負荷分散
      • データベース
        • レプリケーション
        • パーティショニング
        • シャーディング
    • パフォーマンスチューニング
      • 可観測性
      • クエリ分析
結論:お前、それWebエンジニアか?
総括:共通してるのは分析して解決かなぁ。今の問題点ってなんだろう?っていうところから考えて解決するまでの調査と分析をして解決策を考えて実装。


会社が動かない問題のなぜなぜ分析

テーマ:全然会社が動かない

開発者の意見が通らない

数字に目がいきすぎて全然ユーザー価値考えていない

  • やることが多いと錯覚をしていて、動いていない
  • 負債が溜まっていてなかなか動けない。
  • 改善が進められていない
    • 社内の業務の生産性が悪い
    • 人材が定着していない
    • 改善を進める前に成果を求めてしまう
      • 元いた社員の重圧が大きい
      • 覚えてから成果へ繋げる前に辞めさせちゃう
      • 成果を評価するため、それ以外の成果を出す場を作る下地が作れずに少量の成果しか出せていない
        • 社長からの人材への期待値が高い
        • 一人のスーパースターを求めている
        • 少数の社員で成り立たせたいと思ってリソースを節約している
          • その他がその人を支えるという仕組みを作る
          • イメージが先行して、どういう人材がよいかという固定観念が強い
            • 短期的な投資と成果を求めている
              • 資金がショートするかもしれないという焦り
              • 事業が投資家にとって魅力ではない

総括

資金難と人材の確保ができていない、業務効率が悪い、成果も出せない

というループができてしまっていて、成長していない

これの改善方法

  • 開発部は開発部で仕切り、一人が開発部を責任を持って生産する
  • 痛みを伴う変化というのを間違って解釈しているので修正をしてもらう
    • 人を変えるんじゃなくて、システムを変える
    • こだわりが変化を遠ざけているため、自分の意識だというのを理解してもらう

定期購読プランの設計

 主要テーブルは2つ

  •  ポイント
    • 冪等性を確保する
      • 状態管理テーブル
    • 会社保有のチケット
      • チケットの失効の仕様策定
    • 契約テーブル
  • 実装計画
    • 第一phase
      • 定期購読契約テーブルとバッチ状態管理テーブルを作成
      • 過去のデータで不整合が生じるため削除orデータ変更
    • 第二phase
      • Railsアプリケーション側開発
      • バッチを実装(Lambda、EventBridgeのクラウドネイティブなバッチ)
    • 第三phase
      • チケット失効仕様のためチケットテーブルを追加設計
      • チケット失効バッチを実装
  • 制約
    • 定期購読停止申請は契約更新月の前月末までにしないと次回更新時になる
      • 参考にしたのはNintendo Switchオンライン契約の定期購読の仕組み(ちょっと違うけど、人と会話する時に参考になりやすい)
      • https://support.nintendo.com/jp/nso/automatic-purchase-extension/index.html
    • チケット効力失効が新たに追加
      • 定期購読停止とはまた違い、チケット自体の効力である
        • Amazonポイントとかわかりやすい
  • 定期購読契約テーブル
    • 契約開始
    • 契約終了
    • 次期契約開始
    • 次期契約終了
    • 次回停止申請期限
    • 次回更新停止申請日
    • ステータス
      • 契約中、契約更新停止申請中、契約解除、契約更新処理中
  • バッチ状態管理テーブル
    • バッチの二重実行の防止
    • 冪等性の確保のための設計
      • 複合ユニーク制約の作成バッチ実行日時+ID
      • ステータス管理
        • 失敗、成功、保留、実行中
  • バッチ設計
    • 契約更新バッチ
      • 次回更新停止申請日がNULLでない
        • 次回更新停止申請日が次回更新停止申請期限より前である
        • ステータスを契約更新処理中に
        • ステータスを契約解除に
      • 次回更新停止申請期限を次期契約終了日の一ヶ月前に更新
      • 次期契約開始日を契約開始日にコピー etc
    • チケット補充バッチ
      • 契約している分のチケットを追加する


2025年11月24日月曜日

最近のソフトウェアエンジニアの転職難しくなってます?

概要

転職活動をしているがソフトウェアエンジニアとして体感難しくなってる気がする(ワイの問題?)。なので、ちょっと備忘録を書いておく。

  • 技術面接の通過基準が厳しい

まあ会社にはよるし自分次第なところもあると思う。会社によってはとりあえず最終面接で技術面接をしてみてCTOが判断するっていう会社もある。大体は一次面接とかでエンジニアやEMが候補者の技術スキルを測る。その時の基準っぽいことはこれ。

    • ちゃんとAIを使っているか。
    • どういう技術を選定してきたか。
    • どういう問題を解決してきたか。

今はAIがあるから選定基準は厳しい。だって技術的なことは聞けちゃうからあとはどういう思考で進める人かが重要なんじゃないかなと思う。

皆リードエンジニア、テックリードとしての素養を求められているんだと思う。ジュニアは厳しい。。

  • スキルの測り方は多種多様

10社ほどにまとめると、コーディング試験 : DB設計 : 口頭質問が体感2 : 2 : 6の感覚。

  • 2割はコーディング試験(Codilityやハイヤールーなど)
  • 2割はデータモデリング、DB設計の技術課題を提出させて、面接で聞くタイプ
  • 6割は技術課題を出さず、面接で問うスタイル

データモデリングの問題については自社のシステムに近い製品を仮定してテーブルを設計させてみたり、オンタイムでデータモデリングをさせ、その場で説明をさせてみるみたいなのもあった。

  • 特殊なケースではケース面接っていうのもあった

例えば

    • システムのフロントエンドをSPAにする場合に出てくる問題やその場合を想定したときの進め方
    • マルチテナントSaaSのDBの設計の問題点

などのリードエンジニアとしての思考を問うところもあって、なかなか厳しかったところもあった。

事前にAIに聞いていれば要点はこれなんだろうなぁっていうのはもしかしたらわかる人は分かるかもしれないけど、ハイレベルだなって思った。

  • やっておくといいと思うこと
    • 今までの自分のやってきたことはとにかく、振り返った方がいい。
    • AIに聞いて、AIと一緒に自分がどういう選定をしてきたか。もっといい方法はなかったか。
    • そもそも面接をすると振り返った時に結構勉強になる
      • 例えばコーディング試験だったらデータ構造とかアルゴリズムの勉強になってる
      • 面接で聞かれたことは意図を紐解いてみると会社が欲しい強みみたいなところを聞いている
      • 再現性を自分で考えて整理できる


2025年9月12日金曜日

システム現状分析と再構築プラン

現状分析

  • 古いシステムがありそちらはクローズをしたい
  • 何かしらの追加をしたい時に時間がかかりすぎる
  • サーバーダウンする

組織的な問題

  • 経営者が開発に関与しすぎ
  • システムの裏側の負債の問題について無視しすぎ
  • 社員の業務生産性について目を背けすぎ

システム上の設計問題

  • 運用効率の悪さ
  • 自動化の未完成
  • データモデリング
  • Rubyパフォーマンスの悪さ
  • AWSの設計の可用性の低さ
  • コストの悪さ

SIerの方法だと

  • ビッグバンリプレイス
    • Rails→他言語へのリプレイスして全部置き換え
  • 言語の総置き換え

捨てた選択肢

  • 細かい要望を止める
    • 窓口を減らし
    • 開発者の窓口をPMにしてもらう
      • PMから開発者へ相談をしてもらう
      • 営業やサポートはPMに介して開発者への要望をしてもらう
        • その間開発者は業務を効率化させる
        • システムの直し

実践するべきと判断したこと

  • システム開発の主導
  • 負債の返済
  • 業務生産性を上げるための業務自動化

やること

  • AWSサーバーを冗長化して可用性を上げる
    • EC2インスタンスを冗長化
      • オートスケーリンググループを作成してオートスケールする
      • 障害に備えてDR対策
        • フェイルオーバーの仕組み
          • アクティブ-パッシブの構成
          • 最小構成で置いておく
            • 稼働したら自動スケール
    • DBをレプリケーション
      • 読み取り専用と書き込み専用で分ける
      • マルチAZにする
    • サーバーをコンテナ化
      • EC2インスタンスからECSへの移行
      • デプロイはECRへDockerイメージを置く
    • コスト最適化のためのサーバーレス化
      • 管理者操作のDBはAuroraServerlessで局所的な使用方法にする
      • リザーブドインスタンスで1〜3年のEC2インスタンスの契約をする
        • コアドメインはEC2インスタンス
      • 送客ロジックをコンテナ化
        • Lambdaで運用15分稼働とコールドスタート
        • 分離したロジックの言語は自由にしてよい
          • Python ? Go ?
        • API化してAPI通信+メッセージキュー
          • SQS,  RabbitMQ
      • キューイングシステムを再構築
      • 冪等性を確保
        • 状態管理テーブル
        • Gemでsidekiq-unique-jobs
    • 運用を効率化
      • サーバーのフルマネージド化
        • Aurora、ECS/Fargate、Lambda、DynamoDB
      • 可観測性
        • フルマネージドにするためEC2ストレージに直接吐いていたログを集約
          • Fluentd、CloudWatch
      • デプロイの自動化
        • CodePipeline?
        • Github Actions?
      • 日々の作業で非効率的な手動の作業を減らす
        • トイルの削減
        • バッチ化
          • スケジュールではなく分離していく
  • パフォーマンスを測定してボトルネックを解消する
    • DataDogを使用して、クエリを特定
      • Explainなどでスロークエリを分析
    • gem BulletでN+1の発生しているActiveRecordを抽出
      • ActiveRecordが作るクエリを分析し、ボトルネックを探す
        • N+1修正をしてボトルネックを解消
  • DB設計をしてデータモデルを再構築する
    • 負債によって一番開発効率が下がっている部分を特定
      • コアドメインのデータモデルを再構築する時間を取る

開発プロセスにこだわってしまう罠。それよりも組織を変える必要性

 開発プロセスにこだわりすぎて開発がうまく進まなかったという経験があり、一方でその後きたCTOによりCEOを開発会議から外し、開発チーム+PdM(ビジネス層代表)と開発チームオンリーの会議の2つに分けて会議体を作ったことで見事ビジネスと開発を分けて疎結合にしたということがあり、なるほどと思ったことがある。

それまでは私が開発プロセスを何とかして上手く動かしたかったのだが、全然上手くいかず困ったので記録を残しておきたい。

開発プロセスは大きく分けるとアジャイルとウォーターフォールがある。

ウォーターフォールはSIerなどベンダー企業がユーザー企業から依頼を受けてシステム開発をする際にソフトウェアを工業製品に見立てて、製造業のプロセスをそのまま当てたことで始まったとされている(確かではない)。

それだと上手くいかないよねということで2000年代からアジャイル開発が考案されて、以降、シリコンバレーやWeb業界ではアジャイル開発が主流となっていた。その中でもXP開発やスクラム開発などあり、私が前いたベンチャーではスクラム開発を基に開発を進めていた。

スクラム開発はガチガチにやろうとすると開発が遅くなる。このスクラム開発をガチガチにやろうとし過ぎて、開発者たちからは反感をくらい、経営層の要望を上手く開発に落とし込むこともあまりうまくいかずにとても四苦八苦したと思っている。

ビジネスの要望ばかりを叶えようとしてシステムの重要な要件を満たせていないということがあり、ずっとその会社ではシステムの要件を満たせていなかった。そのため、技術的負債が溜まりに溜まっていた。

システムの重要な要件というのは、運用の自動化やしやすさ、パフォーマンス性、変更容易性、セキュリティ、コスト最適化、スケーラビリティ、信頼性など。

参考:AWS Well-Architected

ベンチャーの経営者はわがままである(『経済評論家の父から息子への手紙』著 山崎元)。

どこのベンチャーも多分そうで、相当ソフトウェア開発に力を入れている企業でなければ(個人的には、例えばLayerX、カミナシなど)、多分どんなベンチャーだって経営者は必死で企業を利益を立たせるために開発者にベンチャー精神を要求し、システムは崩壊している。

参考:開発者体験が良いイメージの企業

ビジネスと開発はある意味グラデーションのように仲介を挟まないと直接ビジネス要件を満たそうとしてえらいめにあう。あるいは開発組織が飲まれているのが実際だと思う。

参考:Cultural Capital Theory in Software Engineering

ベンチャー企業に入り開発プロセスを固めようとしても上手くいかず、CTOが入り、社長が会議に入らないようになってから開発が上手く回り始めたことも目にして、開発のプロセスにはこだわらず、組織構造を変える必要があると思った。

開発プロセスをこだわろうとしても多分ほぼ何も整っていないカオスなベンチャーでは無意味で、経営層に対等に話せる立場が必要、もしくは開発者たちが強くビジネスの要望に対してPdM、PMの意識を持って接することが大切だと思った。

2025年8月26日火曜日

未熟だったと思う技術的解決方法

技術者としてとても浅い知識と解決方法だったと今思うと恥ずかしいことがとても多い。

勉強をすればするほど自分の無知の知が広がり、自分がまだまだだったということを思い知る。無知の無知をどれだけ減らせるかがこれからは重要だと思っている。

今思ったらこれはこういうふうに解決するべきだったと思うことはいっぱいあるので筆頭を書きたい。特に職務経歴書には良いことしか書いていないからなんか本当はもっといっぱい書くことあるんだけどなと思ってここに書いておく。

メモリリーク+長時間ジョブを保持しサーバーのリソース食われている問題

→これをEC2インスタンスのスケールアップで対処するという解決方法。

そもそもサーバーの性能を上げるというのは最終手段としてその前にやることはいっぱいあった。

原因はSidekiqのワーカープロセスのメモリリークと、Redisへの長期間ジョブ保持の設計が重なってリソースを食っていた。(Sidekiqというのはジョブキューのワーカープロセッサ。例えばAWS SQSと代替性がある。)

Sidekiqメモリリーク問題はそのコードの書き方や処理の仕方に問題がある。

加えて最大7日間Redisにスケジュールを保持して7日後にジョブを実行するというワーカーなど長時間Redisにジョブを保持させるような仕組みが数あった。

このような長期間スケジュールが必要なジョブは、Sidekiq ではなくバッチサーバーや専用のスケジューラーで実行する方が適切だった。ずっと使われているものに疑問を持ち、問題の原因を見極める目を持つのが本当の技術者だったと思う。

ユーザーがイベント操作をした後がやたら重い

メルカリでいう"出品ボタン"を押した後や"購入した後"、やたら待機時間があり裏で処理が完了するのを待たされるという問題。

社長やプロダクトオーナーはこういうところをよく見ていて、指摘されてすぐ解決しようとして開発者たちは浅い解決をしてしまうんじゃないかなと思う。

これはおそらく原因は出品イベントを実施した後に全ての大量の処理を同期的に処理していたから。(例えば商品のバックグラウンド配信処理やポイント計算など)

関心の分離がそもそもできておらず、"出品"という関心ごと以上のことを全て同期処理をしていたためにその処理たちが終了するまでユーザーが画面待機しているということが実際の問題だった。

それを『CDNを設置したら解決する』とか『一部リファクタリングをしたら解決する』などという間違えた方法で解決しようとしていた。(ていうか解決していない)

本質的には出品が完了したらさっさとユーザーは体感的にはすぐ終了し、その後の処理はイベント駆動型アーキテクチャでメッセージキューに非同期的に送るということで根本的には解決していたはずだ。(実はメール通知やその他些末な部分についてはSidekiqで最低限非同期化はされていた。)

パフォーマンス改善は何かツールを立てればいいと浅い経験者だと思いがちだけど、アーキテクチャにまで考えを巡らせることが大切だった。

冗長化、分散化検討の不十分さ

管理者画面からは大量のデータを参照したりCSVダウンロードしたりする。その際にアプリケーション全体の処理が重くなっているという問題を我々はWebサーバーを分けて解消した。

それ自体はまだ一歩前進だったなと思う。

これから管理者サービスとしてマイクロサービス化させるとかして好きに別言語で書き換えても良いだろう。

問題はそのあとで、すべての処理は単一のデータベースを見ており、DBのI/O処理は変わらずリソースを食い合っていたという問題がある。その辺りの問題を見ていなかった。

データベースはレプリケートし、管理者画面からの参照系のクエリはリードレプリカを読み取るように設計をしなければならなかった。

書き込み系トランザクションと読み込み系のトランザクションを分離することで、ユーザー向け処理のパフォーマンスを守ることができたはず。

なんだったら、管理者画面を操作するのは平日の昼(とか月曜日)にアクセスがバーストするのでEC2で常時動かすのではなくてコード上のモジュールを分離してコンテナ化した後、ECS+Fargateなどで使用量に応じた従量課金制の方が多分コストもより最適化されていただろう。

大層なツールを使うのはまだ早かった

要するにElasticsearchとかCloudFlareとかそこまでビジネスがスケールしていないうちからツールを使って解決しようとするもの。実はもっとビジネスがスケールしてから検討を開始するべきだっただろう。

最近のXで質問箱という単純なシステムなのにk8sを使っている形跡があったりして話題となっていた。

技術者の幼稚さというかなぜそれを使ったというような感じで、コストも嵩んでおり、履歴書駆動開発という揶揄があったりした。

ツールや最新技術を使うというのはそれが目的となってはいけないと思った。まあ検討材料として幅広く知る必要はあるが、大切なのは問題の本質を見極めるイシューだなと思っている。

サービス・関心事を分離していない

せめてBユーザーとCユーザーのログイン画面くらいは分離をしないといけなかったけど、そのログインが一緒だった。つまり、ユーザーのjobだかroleだかのカラムでBかCを判断しているというものだった。(まあ最初のスタートアップの立ち上げ期が過ぎてからここを変えようというのが最初の開発者たちの考えだったんだろうけど、、そのもうちょっと余裕ができるステージが全然来なかった。)

これはサブドメインでサービスを完全に区別するなどして内部のバックエンドやチームをうまく分担することが今思うと大切な取り組みだったなと思う。

ドキュメントを整備すれば良かったけど全然自分たちも整備していなかった

以前の担当者たちが全員辞めてしまって新しく入った開発者メンバーたちで担当をしたけどドキュメントが古いという問題があった。それは自分たちでまた最初から作り直すなどしてスタートは遅くなるがそうする時間は必要だったなと思った。

なぜならその後に入ってくる開発者たちにも同じように口頭で説明をしたり、自分たちでリバースエンジニアリングをして同じ道を辿ってもらわなければならないからだ。

ADR(Architecture Decision Record)→アーキテクチャがなぜそのようになっているかを知るした仕様書を書く。

ドメイン仕様書→主要な機能やドメインの仕様書は自分たちのリバースエンジニアリングをした結果としても記したい。

手順書→多分これはせめて書いている人やチームは多いと思う。気にせず、変わった部分があれば常に最新にしておくのがよい。

2025年8月23日土曜日

社員数が少ないベンチャー企業の疲弊とそれでも上場しようとした時の問題

ビジネス側がやりたいこと

・組織が充分に成熟していない状態であろうとも上場をするという目標を達成したい

・上場審査を通過するためにメインの収益を安定、向上したい

開発者はビジネスがスケールするかどうか中身が見えている状態。だからビジネスサイドが見えていることと開発者が見えていることは根本的に異なり疲弊が生じる。

相手側に「これくらいやれるだろ」という意見や不満が生じる。

開発部の疲弊問題

→ビジネスサイドと開発部との接合点が近いことで組織の力関係が偏っている

こういう会社に入ったら

ドキュメント整備してシステム全体像を図式化、構造化して問題点を洗い出しする

政治(メンバーとして入ると良くないかもしれない)

開発者がやることは

・業務効率化

・アーキテクチャ再構築

・要件再定義・再設計・再実装

業務効率化

例:

カスタマーサポートが疲弊→プロダクト根本的問題を解決する、チャットボットを作る、Q&Aページを再編、構造化して問い合わせ前の解決を促進する、ビジネス問い合わせとカスタマー問い合わせを分離する。

開発者のシステム運用の手間を減らす。インフラ運用を減らす。手動でのデータ転記を自動に。

アーキテクチャ再構築

モノリスから責務が重そうなコアドメインを特定、分散化。データベースのレプリケーション。CQRSを適用、最適なアーキテクチャのトレードオフを考慮して選定し移行。

要件再定義・再設計・再実装

ビジネスサイドがプロダクト価値を向上させる観点やどうやればいいかがわからない場合は開発がヒアリングを主導しぐちゃぐちゃな要件定義を再定義し再編する。ドメイン知識が必要そうな部分をドメインエキスパート(一番詳しそうな人)にヒアリングしドキュメント化。

改善不能になる要因

アーキテクチャの問題と組織構造の問題とマインドの問題

コンウェイの法則→組織構造がアーキテクチャやシステム設計に反映される法則。

コンウェイの法則に加えてその場を支配しているマインドも力学に関与している。

例:

生産性とか言う前にまずやれ思考→業務を効率化したり生産性を上げるように仕組みを変えるなどという思考に至らず疲弊した社員で構成される。

残業をしていた方が評価される→効率化させたり、仕組みが変わったりすることは考えない方が得。仕事がいっぱいある方が得。効率が悪い方がお得。

上司に従順じゃない人は幼稚→マイクロマネジメントでメンバーが他責化・受け身思考化。どうしても社長やトップが幅を利かせてしまい、誰も提案がなされない組織になる。思考することは無駄っていうことになり、アーキテクチャ改善や業務効率をするための思考ができない。

部署ごとの力関係→選択肢を考慮できる部署が偏っている場合、その部署の先導でシステムがどうしても作られてしまう。営業優先だと営業の御用聞になり、システムは手続型の構造になり深い思考が反映されている抽象構造化されず、スケールしない。

上場をする際にベンチャーがぶち当たったシステム観点

セキュリティ監査

→認証・認可問題(管理者画面、画像の永久URL表示)、会計経理不整合

売上で大事なドメインがスケールしていない

2025年8月21日木曜日

AIの時代は今までの凝り固まった思考を壊すことからスタートしたい

 先日、ウェブデベロッパーが消えるみたいなことを投稿したけどそれは間違いだと考えた。

色々とカンファレンスやさまざまな分野で活躍をしている方の登壇資料、意見に触れて考えを改めた。

このブログはひっそりと書いて自分に興味を持った人だけが読めばいいと思って軽く書いていたけど、(これからもそうするけど)なるべく間違ったことは訂正して自分をアップデートしていきたいと思っている。たまたま読んだ人も自分もいい記事を読んだと思えるようなブログにしたい。

特にTably株式会社代表の及川拓也さんの登壇やさまざまな文章を読み漁り、改めて今後のソフトウェア開発について考えを更新した。

1. 時代の変化を楽しむ

2. どんなところでも一定の成果を出せる人に共通する『抽象化・構造化能力』

3. AIと共創する『問い』と『制御』

4. AIと人間の違いは今までの延長線上ではなくて逸脱をすること

5. 『やったことがないからできない』はもう終わりにしよう

AIにより時代はチェンジするが、大切なことはそのまま残り続け、形として変わる。

プログラマーは失職をするのではなくてAIにコンテキストやプロンプトを書き設計をする人になる。

プロダクトマネージャーは不要になるのではない。ずっとプロダクトマネジメントという本質は必要。AIで検証が簡単にできるようになるんだったらPdMもAIに書かせてPoCを回すソフトウェアエンジニアみたいなことをするようになるのかもしれない。

『SaaS is dead』はSaaSが終わるのではない。SaaSは形が変わるよっていう話。SaaSはデータベース化し、AIエージェントにより対話型のインターフェースになり形が変わるよっていう話。

『やったことがないからできない』は抽象化・構造化ができていないから他の分野や仕事に応用することができていないだけ。前例主義な管理職もそう。結局必要以上にデータを集めてやることを遅らせているというだけで一緒。マイクロフト社が解雇した"管理者層"というのはそういう人たちなのかも。

AIは推論能力が発達した、する。ということは、絵画を描かせてみても今までの画風やスタイルの延長線上で描くだけ、人が突然画風や創造的な作品を生み出すのは人間が今までの延長線上で描くんじゃなくて、創造的文脈破壊、でたらめなことをするから。AIはそれはできない。

どうせ、AIで時代が変わるならそれを楽しめばいいし、仕事はタスクを時期までに終わらせるなどという働き方からそれをやる意味や背景、抽象化して構造化するように改める。生産性だけを求めて、浅い説明と表面的な仕事しかやらせないというのもそれはこの時代だと体罰に等しい。

2025年8月15日金曜日

今後のウェブデベロッパーの命運

Web DeveloperはほぼほぼAIで代替される。
Microsoft社が出したレポート『Working with AI: Measuring the Occupational Implications of Generative AI』(生成型AIの職業的影響の計測)が2025/7/22に発表されていた。
測定は2024年でCopilotが数ヵ月間に渡って集めたデータで行われていて、生成AIによるカバレッジやスコアが出されている。
・Coverage:  AIが対応できる範囲
・Completion: 業務完遂度
・Scope: 全体に占める割合
・Score: 総合評価
・Employment: 職業者数
などが出されている。
Web DeveloperはWebに関わる仕事全体だ。要するにWebアプリケーション開発全般。
それのカバレッジが7割で業務完遂度は8割5分となっている。
感覚としてもまあそれは正しそうだ。
先日、サム・アルトマン氏によってOpen AI社よりgpt-5が出て色々と評価はありそうだが、まず人間の認知をちょっと超えているという感想を抱いた。ますますAIは成長しそうだと思った。
ということはつまり、AIによってできることが増えていくということだ。今でさえAIは7割をカバーしている。8割、9割は範囲に入るだろう。
先日PHPとApacheのLAMP環境でできた懐かしいかつ古い環境でできた自分のプロダクトを試しに、claude codeでサーバーレス構成に移行した。
シンプルでそんな難しくない構成だけど、まる2日はかかった大変な作業だった。AIはまだシステム間の文脈やどういう意図でファイル間を跨ぐ参照がされているかというのは完璧にはできていないようだった。割と人間だったら分かりそうなCRUD処理が抜け漏れていたりアプリだったら普通はそうというような暗黙知をくみ取らなかったりと何回も試行を繰り返す必要がある。
なので最初のプロンプト設計とその後出てくるバグや考慮漏れなどで対応をしてとても時間がかかる作業だった。

しかし、それも時間の問題だとも思った。
---飛ばして良い---
インフラ構成はIaCでコード化が可能なのでAIはインフラを構築可能。Apacheとアプリ側とのやりとりは人間が大体を理解してそれを共有したらAIは理解はしてくれる(逆に言うとApachやNginxみたいなプロキシサーバーとアプリとの超面倒くさい繋がりは人が把握している必要がある。)フロントエンドのデザインはもうお茶の子さいさいであった。
ちょっとばかしデバッグが必要な場面があり、そのデバッグ方法をAIが示してくれたりもした。それがちょっと面倒臭い。
AIエージェントが替わると担当したモデルが吐いたコードの意図を理解して続きをやるということはできていなかった。何回もローカルでAPIサーバーの起動に躓いて無駄なコードを吐いた。
------
要は、意図をくみ取ることはまだあまり正確性はないようだったが、それもあと数年でできるというのは分かった。
つまり、システム開発全般、プロンプトの入力さえちゃんとしていれば行える。
面倒くさいことをする必要がない反面、怖い。
カバレッジは今後近い将来100%になるだろう。
それまでは価値が一気に高くなる部分がでる。
システムアーキテクチャ、設計方針、プロンプト設計、ドメイン知識だ。つまりシステム開発の一つ抽象度が高い部分と要件定義に必要なビジネス層との橋渡し、翻訳者が重要になる。
要するにプログラミング言語を覚えて関数を書くのではなく、書かれた関数が集まったクラスやモジュールの間のやり取りを意識して設計をする。まるでレゴを組み立てるかのように中の関数は意識せずともコンポーネントを組み立てることを考えられれば良い。
レゴで建物を建てるつまり、アーキテクチャ:建築をするかのようにちょっと楽しい部分が残る。
だがしかし、それは人数はあまり要らない。
人数がいらないということは、一つあたりのプロダクトやサービス、企業で必要とされるエンジニアは少なくなる。
ジャパンは終身雇用なのでクビはないだろうが、入り口は絞るだろう。

そのうち人間が理解できなくてもよいからAIエージェント同士が理解する言語でやり取りをしそうである。
あと、そうなるとAIはプログラミング言語じゃなくてもいい。プログラミング言語は人が理解するための言語なので、新しい言語を作りそうではある。(先日新しい自然言語を発明した。)
じゃあ今から違う分野へ行くしかないだろうか。
結構人間は争いが好きなので、マウントをし始める未来が見えるが。ディストピアが近い将来にあるなと思った。

2025年8月11日月曜日

プロダクト志向と言うのは開発者としてはちょっと違った

 私は以前自分をプロダクト志向だと言っていた。確かにUI/UXデザインとかサービスの一貫した価値観、UXに留まらずサービスを一貫して感じ取ることができるユーザー体験の良さを持って色々なサービスを触ると楽しい。

ごちゃごちゃしたサービスを作ってしまっているプロダクトはやはり色々な情報を載せてしまっていて全然一貫していない。そうやって比較して自分の血肉とし、自分が担当しているプロダクトに現わして良いプロダクトができるならとても嬉しいだろう。

私の将来的にやりたいこととしてPdM(プロダクトマネージャー)がある。しかし、今は開発者であり、ソフトウェアエンジニアなのだ。

将来的に何がしたいのかは自分の中に秘めておいて、今自分が真価を発揮するべきなのは

"システム開発の専門家としてシステムを構築する"

こと。

だが、私は思う。

サービスの開発とシステム構築は表裏一体のもの。

プロダクトをマネジメントするために開発も横断的に理解ができてなんぼだと私は思う。

なぜタイミーはモバイルアプリだけなのだろう?

似たサービスでネクストステージとどう違うんだろう?

そのプロダクトが出したい価値とは何だろう。その裏にある想いはプロダクトとなって物理的に表出し、システム構築もされ実現する。

2025年8月10日日曜日

BtoCオークションサイトの理想的なアーキテクチャを構想する

モノリスで構築した際、パフォーマンスとスケーラビリティに問題が出るパターンを目にしたため、理想的なアーキテクチャを考える。

Cの出品者が出品というイベントにより、Bの査定事業者に非同期ストリーミングされる設計が理想。

事業者と出品者は根本的な操作が違うため、ログイン画面、ドメインURLが違っても構わない。(ドメイン駆動設計で言えば境界的コンテキストだろうか)

規模が大きくなれば、マイクロサービス化し、査定サービスと出品サービスでコンテナを分けると将来的には良い。

大きく分けてシステム管理者(入出金処理、申請処理、チャット閲覧機能、ユーザー情報検索機能など)、査定事業者、出品者で分けることができるため、サービスは3つに分ける。

こうするとイベント駆動型アーキテクチャとマイクロサービス化を組み合わせた分散型のアーキテクチャにすることができる。


Ruby/RailsのWebアプリケーションはドメイン駆動設計を当てはめることができないのでmastodonのような設計方針にする

Ruby/Railsはinterfaceキーワードがないため、JavaやC#のようなinterfaceクラスを定義することができないが、Duck Typingという概念により楽しいを優先した実装が可能になっている。

かといってRuby/Railsのフレームワークに全てを託してMVCを構築して密結合なソースコード、ディレクトリ構成になると後々きつい。

ドメイン駆動設計の実践的ソースコードとしてはそれを実践している企業のソースコードをみたらめちゃくちゃ勉強になるけど、できない場合はCargo Trackerを読むと良い。

エリック・エヴァンスのドメイン駆動設計を読んでいると途中でCargo Trackerのドメインを例に説明している箇所が出てくるのでJavaで実装されているCargo Trackerのソースコードを読んで、概念を具象に置き換えて読むことができる。

Railsをドメイン駆動設計で設計をするとなぜRailsを選択したのかがわからない設計方針になってしまうため、Railsでドメイン駆動設計を実践している企業はあまりないはずだ。

mastodonはMVCを基本構成としていながらModelには基本メソッドを用意し、Serviceに業務ロジックを書いている。Serviceに書かれたロジックをModelが呼び出しているため、Modelがファットにならない。

Railsのようなフレームワークと結婚をする場合はクリーンアーキテクチャやドメイン駆動設計を当てはめることはほぼないだろうが、MVCをService、Policy、Form、Query、Concernsで上手くバラす。

ドメイン駆動設計でいうエンティティとリポジトリはModel、複雑なクエリはQueryオブジェクトに分離される。

Policyは権限制御。Formは複数モデルを使用する場合のPORO。Concernsは複数モデルで共有してもよい小さい処理などを入れる。


2025年8月8日金曜日

これからのエンジニアに求められていること

『エンジニアやコーポレート部門を中心に200人いた従業員のうち40人ほどを退職勧奨をした。』

という企業が先日社長ブログで明らかとなり炎上したり話題になった。

日本は終身雇用制度というものがありアメリカで大量解雇があったようには行かない。レイオフではない。勧奨である。

しかし、AIの進化によってますますエンジニアは変化をしていかないと生き残れない時代になった。これからエンジニアを目指していく人はSTEMを出身とした大学や大学院の出じゃないとあまり採用されないんじゃないだろうか。大量採用など言語道断で、採用を絞り、いかにAIネイティブで基礎が出来上がっているエンジニアが確保できるかが重要になるのではないだろうか。

そしてAIを使用していて思うのだが、作業者はまず要らない。会社にもCTOやテックリードが数名いればそれなりのシステムの価値が出せるのではないか。だからこれからは個人開発の時代か、CTOやテックリードなどアーキテクチャ視点を持ち、設計を行える人材の必要性が出てきていると思う。

あるいは個人開発でマネタイズをすれば全エンジニアは実はスタートアップの競合を作れるのではないか。

雇用がAIによって減るのであれば、いっそ一人ひとりの労働者は雇用から脱出し、一人ひとりが個人開発で1人社長になる時代なのかもしれない。

むしろエンジニアはAIの進歩により、一番恩恵を得るべきなのである。

AIは個人が持つ知識の増幅器であり、エンジニアがより原理原則やアーキテクチャ、幅広い知識とレビューができる点を考慮すれば、エンジニアはよりAIによって加速することができる。

2025年8月2日土曜日

ビジネスも分かっていないと結局何をしたらいいか分からない

 開発者は開発だけをしていたらいいのか?

私は1年前は開発だけできればいいと思っていた。開発、実装が早ければ、あとは勝手に要件定義ややるべきことを誰かが決めて、今やるべきことを振ってくれると思っていた。

だが、全然そんなことはない。ベンチャー企業に入ってRailsのシステムを保守・運用しながら再設計のフェーズになって分かったが、それじゃ意味がない。

システムはビジネスサイドが何をしたいかによって変わる。

サービスAを立ち上げていたけどサービスBが走り、メイン稼働はBである。Aをどうしたらよいか?システムAを移行するにあたって移行計画をする必要がある。

それは開発だけをしていたら良いという思考だと全然できない。

我々は要件定義や設計はもちろん、アーキテクチャを理解して自分が今やっているサービスはどういうアーキテクチャになれば最適なのかを知っていなければならない。

そうしなければ、今やるべきことが分からないし開発もできない。

なんだったらビジネスサイドは開発でどういうことができるのかさえ分からないのでこちらからアプローチして、どういうことをするべきなのか指針を示せるようにならないといけない。

私はこれからは最適なアーキテクチャの進化、システムの移行計画、要件定義、ドメインに沿ったアプリケーション設計ができるようにならなければならないと思った。

そのためには今まで参加したプロジェクトや開発をしたアプリケーションを再度自分だったらどのようにしたらいいか考えて表現することにした。

2025年8月1日金曜日

Ruby on Railsのモノリスをリアーキテクチャする

 Ruby on Railsはマイクロサービスやサーバーレスなどの分散型アーキテクチャとは相性が悪い。

モノリスでサービスを立ち上げ、高速でローンチするのには適切な言語、フレームワークだと思う。他にもPHP/Laravelなどの選定も良い。

インターネット上だとPHP/Laravel、Ruby/Railsのシステムはオワコンという内容の意見が溢れている。しかし、そうとは限らない。

最初からマイクロサービスを想定してGo、Pythonなどを選定してもエンジニアの採用が難しいしシステム構成も難しい。私も最初から学ぶ必要がある。

なので、最初はRuby/Rails、PHP/Laravelを選定するというベンチャー企業、スタートアップが多い。

しかし、事業が成長してサービスがスケールするとモノリスで作られたサービスはどんどん開発が遅くなる。ここで分散型へ移行する必要がある。

Ruby on Railsで作られたシステムはちょっとずつアプリケーション設計を疎結合にしていき、責務を分離しないといけない。その時にドメインの知識、サービスの流れを全て把握した上でどのコンポーネントが重いのかを把握する。

私が参加していたサービスは買取オークションというサービスで、出品者と事業者、システム管理者という明確な責務が分離できた。

なので、商品が出品された時に事業者に適切に配信されるためにモデルをドメイン事業になぞらえて再設計。その後、イベント駆動型に移行するといいだろう。

イベント駆動型とは出品というイベントが発火した時にメッセージブローカーが条件によって事業者に適切に配信する。

必ずしもマイクロサービス化が適切じゃないなら、イベント駆動型アーキテクチャ、サーバーレス化など少しずつアーキテクチャを進化させていくと良い。

AIを使うと思考停止してしまう

私はタイトルの通り、AIを使うと脳みそがどうも思考停止してしまうことで悩んでいた。これからもAIは必須で開発にも活用するべき存在になってきていたが、どうしてもAIの使い方がわからず、仕事が奪われて、思考停止してしまうような不快感に襲われていた。

それは、私はAIの使い方が下手なだけだと思っていた。だけどどうしても良い使い方が分からずにとても悶々としていた。

AIをどのようにして使えば自分が仕事を奪われたと感じず、思考も停止せずに開発ができるんだろう?

先日、このブログの筆者がAIでの開発方法でとてもいいことを書いていた。

『AIのお陰で最近辛かった個人開発がまた楽しくなった』

Takuya Matsuyamaさんという日本人の方でInkdropというMarkdownノートアプリを開発している方で、この記事のエッセンスは以下だと思った。

『自分を置き換えようとせず、自分を拡張せよ』

今世の中には、AIが役立つという人もいれば、そうでもないという人もいます。その分け目は、AIの特性を理解しているかどうかです。AIはコードを驚異的な速度で生成するため「もうコーディングがボトルネックではなくなった」と錯覚しレビューが新たなボトルネックだと誤解されることがちらほらあります。

(略)

つまりボトルネックは今も昔も変わっていません。あなた自身の創造性とクラフトマンシップです。

とてもありがたい。

なんとなくAIは最初から書かせたり、自分の創造性を奪わせるような書き方はしてほしくなかったので、これが正しい使い方なのかなと思えてからはほっとした。

AIで思考停止してしまい、創造性が奪われていると感じている人は是非自分のAIの使い方を見直してほしい。

Google検索が上手い人と下手な人がいるように、AIも使い方がある。

AIは万能ではなく、私たちの創造性を奪うものではない。

私はChatGPTと会話をしていて楽しいと思うときはいつも、自分の意見やアイデア、提案をして、AIにレビューをさせるときだ。

そうすると、私の考えを構造化して本質を見出してプラスアルファして出してくれる。

だが、楽しくないと感じるときはAIに考えを丸投げしているときに感じる。

例えば、「こういうときはどうしたらいい?」「案を出して」など解決方法やアイデアなどをAIに丸投げしているとき、私たちは創造性を発揮していない。

AIには創造性を任せずに自分の創造性や分かっていることを整理してプラスアルファしてくれる存在として使っていきたい。

これからの時代に備える

2026年は失業の年か跳躍の年か アメリカではブルーカラーへの雇用が増加しており、ソフトウェア産業をはじめとしてホワイトカラーの就職が困難になっている。 データで分かるのは、若手、中間管理職層がリストラ対象というもの。アメリカでは『ジョブ型雇用』であるのに対して日本は『メンバーシ...