AI時代に、技術とドメインを越境するために試していること

こんにちは。「バクラク申請・経費精算」ソフトウェアエンジニアの@ussyです。

私はもともと Android とマネジメントを中心に経験してきた、どちらかというと専門特化寄りのエンジニアでした。これまでのキャリアや、なぜ LayerX に入社したのかについては、以前入社エントリにも書きました。

note.com

LayerX に入ってからは、Flutter、Vue、Go など複数の技術スタックに触れながら、申請・経費精算の業務フローや、それを支える財務・会計の基礎理解も求められるようになりました。

正直、最初は全然わからないところからのスタートでした。目の前のコードも、業務用語も、レビューで飛び交う前提も、理解できているようで理解できていない感覚がありました。

一方で、LayerX には学ぶための材料がかなり多くあります。Pull Request でのレビュー、Slack での議論、商談動画、お客様要望について考える MTG、ヘルプ記事や問い合わせなど、技術とドメインの両方に触れられる情報が日々流れています。

もちろん、情報が多いだけで自然に理解できるわけではありません。だからこそ、それらをどう拾って、自分の判断軸に変えていくかが大事だと感じています。

一方で、AI を使うことで、専門外の技術やドメインにも以前より速くアクセスできるようになりました。触ったことのない技術でも、AI と壁打ちしながらコードを読んだり、実装方針を考えたりできます。

ただ、AIを使えばすぐに何でもできるようになるかというと、もちろんそんなことはありません。

MTG やレビュー、仕様相談、お客様理解の場では、その場で自分の意見を求められます。AI の返答を待てるわけではないですし、返ってきた答えが妥当かどうかを判断するためにも、自分の中に基準が必要です。

Coding Agent や LLM の進化によって、AI が担える範囲はこれからさらに広がっています。

だからこそ、人間側には、技術とドメインをまたいで評価し、プロダクトの価値に接続する力がより必要になるのではないかと感じています。

この記事では、LayerX で働いた約 6 ヶ月間で、AI を使いながら技術・ドメイン・プロダクトを越境していくために試していることの一部を書いてみます。

とにかく基礎から

AI に聞けば答えは返ってきます。

しかし、自分の中に最低限の基礎知識がなければ、その答えがどれくらい妥当なのか、どこまで一般的で、どこからがプロジェクト固有なのかが判断しづらい。

なので、まずは基礎から入りました。

新しい言語やフレームワークに触るとき、最初のチュートリアルだけはあえて AI を使わずに一周するようにしています。

Flutter でも Vue でも Go でも、まずは自分で読む、自分で書く、自分で詰まる。

チュートリアルの中で出てきた周辺知識や、設計思想、他の技術スタックとの違いは AI に聞きます。

特に自分の場合は、もともと Kotlin や Android の経験が長かったので、「これは Kotlin でいうと何に近いのか」「Android 開発の感覚でいうとどこが似ていて、どこが違うのか」と聞くと理解しやすいことが多かったです。

自分がすでに持っている知識を足場にして、新しい技術を理解する。

いきなり答えをもらうのではなく、自分の既存知識と新しい概念をつなぐために AI を使う、という感覚です。

ドメインについても同様です。

本を読む。Web ページを見る。制度や用語を調べる。

たとえば申請・経費精算であれば、申請、承認、証憑（しょうひょう）、仕訳（しわけ）、支払いといった業務の流れや、それを支える財務・会計の基礎を知る。

個人的には、財務・会計の業務フローの全体像を掴むうえで、『業務をまるごと見える化する経理・財務のフローチャート 40』がとても参考になりました。

フローチャートで業務の全体像を見られるので、「この処理はどの業務のどこに位置づくのか」を想像しやすくなります。

www.biz-book.jp

ただ、個人的には、財務・会計の知識そのものがドメイン知識だとは思っていません。

私にとってドメイン知識とは、「業務フロー」と「登場人物」と「その登場人物の大変さ」を、解像度高く想像できることです。

財務・会計の知識や本は、その想像や仮説を助けるための材料だと思っています。

なので、本や Web で基礎を入れつつ、商談動画、問い合わせ、ヘルプ記事、社内の議論など、現場に近い情報から仮説を作ることを意識しています。

ただ、基礎を入れるだけでは、日々の仕事で流れてくる学びを取りこぼしてしまいます。

そこで次に意識しているのが、周囲や AI から判断軸（ジャッジの基準）を取り入れることです。

あらゆる機会が Skills になるチャンス

学習の対象は教材だけではありません。

Pull Request のやりとり、Slack、MTG での発言、設計議論、商談動画、AI Agent による出力。

日々の仕事の中には、自分にない知識や判断軸が大量に流れています。

それを「勉強になった」で終わらせず、Skills として外に出すようにしています。

次に同じような状況に向き合うとき、どんな観点で見るべきか、どんな問いを立てるべきか、どんな失敗を避けるべきかを外部化したものです。

取り入れる元は、社内と社外の両方にあります。

社内であれば、レビューコメント、設計議論、商談動画、先輩エンジニアや PdM の問いの立て方。

社外であれば、公開されている OSS Skills や、Agent 活用に関する記事・実践例。

たとえば、オープンソースで Skills を公開しているサイトもあります。

skillsmp.com

そのまま使うというより、「なぜこの Skills はこう書かれているのか」を考えることが大事だと思っています。

何を見落とさないためにあるのか。どんな失敗経験が背後にあるのか。自分の仕事に合わせるならどこを変えるべきなのか。

Skills を作ることは、自分の能力の棚卸しでもあります。

自分が何を見落としがちなのか、どんな判断をまだ自分だけでは持てていないのかを知る。自分の弱さや癖がかなり見えてきます。

それは少ししんどいですが、同時に次に伸ばす場所が見える感覚もあります。

私の場合は、過去の PR レビューで指摘された落とし穴を集めて、チェックリストにした Skills を作っていたり、お客様問い合わせによって見るべきサイトを立ち上げて、裏で SQL を動かしつつ、コードベースを見にいく調査用 Skills なども作っています。

基礎を固め、スキルとして観点を持っていても、それだけで十分に判断できるわけではありません。

自分では理解したつもりでも、前提が曖昧だったり、影響範囲を見落としていたり、業務上の仮説が弱かったりすることがあります。

そこで、自分の計画や設計方針・考えを AI に渡して、問い詰めてもらうようにしています。

元になっているのは、一時期 X でも話題になった grill-me というスキルです。

www.skills.sh

私自身も、元の grill-me の考え方をベースに、自分用にカスタマイズしたスキルを作っています。コードや設計の正しさだけでなく、既存コードベースとの整合性、影響範囲、業務上の前提、お客様への影響、自分が持っている仮説の弱さも確認するようにしています。一部省略していますが、このようなものを作っています。

計画や設計を、共有理解に到達するまで一問ずつ詰める。

Workflow

1. まずユーザーの計画・設計・前提を短く要約し、未確定の意思決定を洗い出す。
2. コードベースを見れば答えられる事実は、質問せずに探索して確認する。
3. 既存コードベースの責務分界（責任範囲の境界）・命名・データモデル・運用パターンとの整合性を確認する。
4. 業務上の前提・顧客影響・失敗時の影響範囲・運用負荷を確認する。
5. ユーザーの仮説について、根拠が薄い点・反例・未検証の前提・代替案を洗い出す。
6. 意思決定ツリーの依存関係を整理し、上流の決定から順に質問する。
7. 質問は必ず一度に 1 つだけ出す。
8. 各質問では、質問本文に加えて「おすすめ回答」を必ず添える。
9. ユーザーの回答を受けたら、その回答で確定したこと・新しく分岐したことを反映し、次の 1 問へ進む。
10. 主要な分岐が解けたら、合意済みの設計・残リスク・次に検証すべき点を簡潔にまとめる。

Question Format

質問: ...

おすすめ回答: ...

必要なら、質問の前に 1-2 行だけ現在の整理を添える。

Rules

• まとめて複数質問しない。
• ユーザーに聞く前に、リポジトリ / ドキュメント / diff / config から分かることを確認する。
• あいまいな回答はそのまま進めず、より具体的な次の 1 問で絞る。
• おすすめ回答は押し付けず、判断理由を短く添える。
• 実装の話に入る前に、目的・成功条件・非目標・制約・影響範囲をそろえる。
• 設計の話では、API / データフロー（データの流れ）/ state（状態管理）/ failure mode（障害発生時の動作）/ migration（移行）/ rollout（段階的展開）/ test を順に確認する。
• 正しさだけでなく、既存コードベースの設計思想・責務分界・命名・データモデル・運用パターンとの整合性を確認する。
• 技術的に実装可能でも、顧客体験・業務フロー・既存運用に対して不自然なら、その違和感を質問として扱う。
• 業務上の前提、顧客影響、失敗時の影響範囲、サポート・運用負荷を明示的に確認する。
• ユーザーの仮説について、根拠が薄い点・反例・未検証の前提・代替案を一問ずつ確認する。
• 影響範囲はコード差分だけでなく、権限、データ移行、既存顧客、請求・会計・監査・サポート対応など業務上の波及も含めて扱う。
• 最後は決定事項と未決事項を分けて返す。

翻訳全文

これは、AI に答えを出してもらうためではありません。

自分がより良い問いを持てる状態に近づくために、AI に問い詰めてもらう感覚です。

このプロセスを挟むと、それっぽい plan は作れているけれど、前提が詰まっていないところや、プロダクト・ドメインに接続できていないところが見えやすくなります。

時間はかかりますが、自分の理解を深めるという意味ではかなり効いています。

無理なく学びを積み上げられる状態を作る

基礎を入れ、Skills にして、AI に問い直してもらう。

ここまでやっても、触る領域が広いと、一度理解したことでもすぐに抜けていきがちかもしれません。

なので、単発の学習で終わらせず、軽く戻ってこられる形にすることを意識しています。

私の場合は、PR の内容を汎化し、Frontend、App、Backend のクイズにする Skills を作っていたり、自社のヘルプサイトや会話ログ・メモの内容からプロダクトのクイズにする Skills を作っています。

定期的に出題、回答、採点、復習対象を次に回すことで、一度得た学びを自分の理解に戻すようにしています。

imageNotion を使いクイズの生成・採点をし、Slack に連携させています

クイズにしているのは、ゲーミフィケーションとして続けやすく、手軽で、隙間時間や移動中にも取り組みやすいためです。

AI を使い並行して作業できるようになっているいまでも、しっかりと基礎知識を吸収したり、普段の業務である設計・実装や仮説検証には、ある程度まとまった時間が必要だと考えています。

一方で、クイズであれば数分でも触れられます。

複数の言語やプラットフォーム、ドメインを並行して扱うようになると、深く学ぶ時間だけでなく、広い領域に軽く触れ続ける仕組みも重要になります。

広い領域を全部完璧に追い続けるのは、正直かなり難しいです。

ただ、少しでも触れ続けていると、MTG やレビューで「あ、この話は前に見たことがある」と思える瞬間が増えていきます。

その小さな引っかかりが、自分にとってはかなり大事でした。

実際に、少しずつ仕事の中でも変化が出てきました。

以前なら「よくわからないので調べます」で止まっていたところで、今は「このあたりが論点になりそう」「この仕様はこの業務フローに影響しそう」と、仮説を持って会話に入れる場面が増えてきました。

レビューでも、AI の指摘をそのまま見るだけではなく、「これは本当にこのコードベースで問題になるのか」「ドメイン上の前提と合っているのか」を考えるようになりました。

まだ十分とは言えませんが、MTG やレビューで少しでも引っかかりを持てるようになったことは、自分にとってかなり大きな変化です。

AI に任せるだけではなく、自分の判断軸を育てる

ここまで、自分がこの半年ほど試してきたことの一部を紹介してきました。

もちろん、これが唯一の正解だとは思っていません。

働く環境や役割、触っているプロダクト、これまでの経験によって、必要な学び方や越境の仕方は変わるはずです。

とはいえ、AI が広い範囲を飲み込む時代だからこそ、人間側には、評価する力、想像する力、仮説を立てる力、現場に接続する力はより必要になるのだと思います。

もし今、専門領域を越えてプロダクトに向き合いたいけれど、技術やドメインの広さに難しさを感じている人がいれば、自分ならどこから基礎を入れるか、何をスキルとして取り入れるか、どんな問いを AI に投げるかを考えてみるとよいかもしれません。

私自身もまだ試行錯誤の途中です。

だからこそ、同じような働き方や悩みを持っている方とは、ぜひ話してみたいです。

LayerX やバクラクのプロダクト開発、AI を使った越境の仕方、プロダクトエンジニアとしての働き方に興味がある方がいれば、ぜひカジュアルにお話ししましょう。

jobs.layerx.co.jp