プロローグ 前世ニートの俺、異世界転生してエンジニアになる
前世の俺は、ニートだった。
朝起きて、動画を見て、気づけば夜。何かを作った記憶より、「明日から本気を出す」と言った回数のほうが多い。
そんな俺が、ある日突然、異世界に転生した。
目を覚ますと、そこには見たことのない開発ギルドの部屋があった。壁には魔法陣。机の上には、見た目だけはノートパソコンに似ている設計魔導具。そして目の前には、ギルド長が立っていた。
「今日からお前は、エンジニアだ」
「……え？」
前世でまともに働いた経験すらない俺が、いきなりエンジニアに任命された。
ただし、この世界では普通の会話は通じても、エンジニア語だけは通じなかった。
俺が最初のPRを見て、胸を張って言った。
「LGTMです！」
ギルド長は首をかしげた。
「それは承認なのか？ 感想なのか？」
「……たぶん、いい感じという意味です」
「たぶんでレビューするな」
さらに、先輩が設計図を見ながら言った。
「この実装、DRYにできそうですね」
俺は当然のようにうなずいた。
「なるほど。DRYですね」
「何を、どこまで、なぜDRYにする？」
答えられなかった。
AIという設計魔導具に条件を伝えれば、それらしい設計図は出てくる。言われた通りに実装すれば、テストも通る。けれど、上司に「なぜこの構成にした？」と聞かれた瞬間、俺の口は動かなくなった。
「AIにそう設計させました」
それだけしか言えなかった。
「お前は、魔導具を使えているだけだ。エンジニアとして設計の理由を説明できていない」
こうして俺は、王都の設計班から追放された。
行き先は、辺境の小さな開発ギルド。
そこで俺は、LGTM、Approve、Draft PR、DRY、KISS、YAGNIという、異世界では誰にも通じなかった言葉の意味を、一つずつ学び直すことになった。
これは、前世ニートの俺が、AIに作らせるだけの人間から、設計の理由を説明できるエンジニアへ変わっていく物語だ。
異世界の開発ギルドで覚えるスキル
辺境ギルドで、俺が最初に渡されたスキル一覧はこれだった。
- LGTM：見た範囲では問題なさそう、というコメント
- Approve：GitHub上の正式なレビュー結果
- Draft PR：完成前の状態で相談するためのPR
- DRY：同じ知識を重複させない考え方
- KISS：必要以上に複雑にしない考え方
- YAGNI：今必要ないものを先回りして作らない考え方
- 設計意図の説明：なぜその構成を選んだか、自分の言葉で話す力
AIに指示を出せば、設計案や実装案はすぐに作れる。
しかし、AIが出した案を採用するか判断し、上司やチームに理由を説明するのは自分だ。
この記事では、異世界の物語として用語を学びながら、最後にAIへの具体的な指示と、上司へ説明するための整理方法までまとめる。
なお、舞台は異世界だが、GitHubのレビュー状態やDraft PRの仕様については公式ドキュメントを参照している。DRY・KISS・YAGNIの定義についても、本文中と末尾に出典を載せた。
第一話 異世界で最初に通じなかった言葉「LGTM」
辺境ギルドに着いた翌日、俺は最初のレビューを任された。
PRの変更内容を確認し、問題がなさそうだったので、俺は反射的にコメントを書いた。
LGTMです！
「よし、これでレビュー完了だ」
そう思った直後、先輩が俺の画面をのぞき込んだ。
「それはコメントか？ 承認か？」
LGTMは、Looks Good To Meの略だ。
「自分が見た範囲では問題なさそう」という、肯定的なコメントとして使われる。
しかし、これは承認の魔法ではなかった。
GitHub公式ドキュメントでレビュー状態として説明されているのは、Comment、Approve、Request changesの3つだ。GitHub Docs：プルリクエストのレビュー
つまり、この記事ではLGTMを「コメントとしての、見た範囲では問題なさそう」という表現として扱う。
チームによってはLGTMをApproveと同じ意味で使うこともある。
だからこそ、最終的にはチームのルールを確認したほうが安全だ。
ギルドでの使用例
一通り確認しました。LGTMです！
AIに使うなら
俺は、AIに「LGTMと言わせる」のではなく、根拠を出してもらうことにした。
このPRをレビューしてください。
LGTMと言い切る前に、以下を分けて出してください。
- 問題がなさそうな点
- 修正が必要な点
- まだ確認できていない点
- テストで不足しているケース
LGTMという言葉を使うなら、何を確認したうえで問題なさそうと判断したのかまで残す。
それが、異世界で最初に手に入れたスキルだった。
第二話 Approveの紋章――コメントと承認は別物だった
次に俺が向き合ったのは、Approveの紋章だった。
「LGTMと書いたので、承認も終わったはずです」
そう報告すると、ギルド長は静かに首を振った。
Approveは、PRの変更内容を承認するレビュー結果だ。
GitHubのレビューには、次の3つの状態がある。
- Comment：承認も修正要求もしないフィードバック
- Approve：変更を承認する
- Request changes：マージ前に対応すべき修正を依頼する
詳しい定義は、GitHub Docs：プルリクエストのレビューで確認できる。
俺は、LGTMとApproveを同じ呪文だと思っていた。
でも実際には、
- LGTM：コメントとしての「よさそう」
- Approve：GitHub上の正式な承認
という違いがあった。
Approveしたからといって、必ず自動的にマージされるわけではない。
必要なチェック、ブランチ保護、競合、チームのルールなどは別に確認する必要がある。
ギルドでの使用例
内容に問題なさそうなのでApproveします。
AIに使うなら
AIに直接Approveさせるのではなく、Approveしてよいか判断する材料を出してもらう。
このPRをApproveしてよいか確認してください。
以下を分けて説明してください。
- マージを止めるべき問題
- できれば直したい問題
- 今回は対応不要な提案
- テストで確認できていない範囲
結論だけを出させるのではなく、判断の材料を先に出させる。
これで俺は、レビューの入口に立つための二つ目のスキルを覚えた。
第三話 Draft PR――完成前の相談クエスト
「まだDraftなので、方針だけ見てもらえますか？」
辺境ギルドの先輩にそう言われたとき、俺は以前なら「レビューしなくていいPR」と受け取っていた。
正しくは、Draft PRはまだレビューの準備ができていないPRだ。
GitHubではDraftの間はマージできず、コードオーナーへのレビュー依頼も自動では行われない。途中経過の共有や、実装方針の相談に使える。GitHub Docs：プルリクエスト
完成したものを見せるのではなく、
「この方向で進めて大丈夫ですか？」
と相談するための状態だ。
WIPという言葉も、同じように「作業中」という意味で使われる。
AIに使うなら
このPRはDraftです。
完成コードを一気に書くのではなく、
まず以下を整理してください。
- 実装方針
- 変更予定のファイル
- 想定されるリスク
- 必要なテスト
- 判断が必要な点
Draftという状態を伝えるだけで、AIにも「いきなり完成させるのではなく、まず相談する」という役割を与えられる。
設計をAIに任せるときも、いきなり完成形を求めず、Draftのように方針・選択肢・リスクを先に出させると、上司へ説明する材料が増える。
第四話 三つの設計スキルを習得する
DRY――重複をなくす。ただし、何でも共通化するわけではない
AIに「DRYで設計して」と頼めば、似た処理を共通化した設計案を返してくれる。
だが、俺はそこで初めて気づいた。
DRYにする対象を決めるのは、AIではなく依頼する側だ。
DRYは、Don't Repeat Yourselfの略だ。
同じ処理や知識を複数の場所に重複させない、という考え方である。単なるコピペ禁止よりも広く、同じ知識を複数箇所で管理しないことを指す。DRY—Don't Repeat Yourself - Pragmatic Programmer Tips
ただし、「似たコードを見つけたら、何でも共通化する」という意味ではない。
共通化によって可読性が下がるなら、無理にまとめない判断も必要だ。
既存の共通関数を確認し、
同じ処理を新しく重複実装しないでください。
共通化によって可読性が下がる場合は無理にまとめず、
共通化しなかった理由も説明してください。
KISS――一番賢いコードより、説明しやすいコード
KISSは、一般に「Keep It Simple, Stupid」の略として知られている。
できるだけシンプルな設計や実装にしよう、という考え方だ。
ソフトウェアでは、要件を満たす範囲で複雑さを増やさず、理解・検証・保守しやすい構造を選ぶ指針として使える。A Review of the New AVIRIS Data Processing System - JPL
KISSという言葉の背景は、航空機設計者Kelly Johnsonの格言として公式資料に記録されている。Kelly Johnson: Architect of Air - Lockheed Martin
既存の構成を大きく変更せず、
不要な抽象化や新しいライブラリを追加しないでください。
今回の要件を満たす、最もシンプルな実装を提案してください。
YAGNI――今必要ないものは作らない
YAGNIは、You Aren't Gonna Need Itの略だ。
「将来使うかもしれないから」という理由だけで、今必要のない機能を作らない考え方である。
必要になった時に実装するという考え方は、Ron Jeffries本人の解説でも確認できる。You're NOT gonna need it! - Ron Jeffries
Martin Fowlerも、YAGNIをXPのSimple Designに関係する考え方として説明している。Yagni - Martin Fowler
今回の要件にない機能や、
「将来使うかもしれない」という理由だけの拡張は追加しないでください。
今必要な範囲に集中し、
将来必要になったときに変更しやすい構造にしてください。
三つのスキルを覚えて、俺はようやく「DRYで」「KISSで」「YAGNIで」という言葉の裏側を説明できるようになった。
ただし、言葉を知っただけでは足りない。
「なぜDRYにしたのか」「なぜKISSを優先したのか」「なぜ今はYAGNIなのか」を話せて、初めて設計スキルになる。
第五話 AIという設計魔導具に五つの条件を渡す
AIに指示すれば、その通りに設計してくれる。
少なくとも、指示が具体的であれば、AIはかなり速く設計案を組み立ててくれる。
でも、
「DRYで」
「KISSで」
「YAGNIで」
この一言だけでは、AIにも人間にも意図は伝わりにくい。
そこで俺は、AIへの指示を次の5項目に分解した。
原則 ：何を意識するか
対象 ：どのコード・機能・設計か
条件 ：どうしてほしいか
避ける：やってほしくないこと
確認 ：最後に説明してほしいこと
AIへの指示を5項目に分解するテンプレート
たとえば、俺が最初に言っていた「DRYで」を、設計の指示に変えるとこうなる。
原則：DRYとKISSを優先
対象：ユーザー入力のバリデーション処理と、その周辺の設計
条件：既存の共通関数を再利用し、現在の挙動を変えない
避ける：新しい重複実装、過剰な抽象化、不要なライブラリ追加
確認：採用した構成、代替案、共通化しなかった箇所とその理由を説明する
この条件で設計案を作成し、最後にテスト方針と未確認の点も説明してください。
AIは、条件に沿った設計を返してくれる。
しかし、それを採用するかどうか、そして上司にどう説明するかは俺の仕事だ。
それでも全部まとめてレビューしてほしいとき
実際には、毎回5項目を手入力するのが面倒なこともある。
そんなときは、まず総合レビューを頼めばよい。
ただし、PRの目的と確認してほしい観点は添える。
このPRと設計を総合的にレビューしてください。
PRの目的：
[何を実現する変更か]
以下の観点をすべて確認してください。
- 要件どおりに動くか
- 設計が目的に合っているか
- バグや考慮漏れがないか
- セキュリティ上の問題がないか
- テストが不足していないか
- DRYの観点で重複がないか
- KISSの観点で複雑すぎないか
- YAGNIの観点で不要な機能を追加していないか
- 可読性・保守性に問題がないか
- パフォーマンスに問題がないか
問題を見つけたら、重要度を付けてください。
- Blocking：マージ前に必ず直す
- Major：できればマージ前に直す
- Minor：改善候補
- Nit：細かい提案
最後に、以下の形式で結論を出してください。
- Approve相当か
- 修正が必要か
- 追加情報が必要か
- まだ確認できていない点
- LGTMと判断できる場合、その理由
「全部レビューして」と言うだけでも始められる。
でも、PRの目的・見てほしい観点・避けたい変更を添えるほど、AIの返答は使いやすくなる。
上司に説明するための練習
設計を作って終わりにせず、AIに説明の練習相手になってもらうこともできる。
以下の設計を、上司に3分で説明できるように整理してください。
必ず次の順番で出してください。
1. 何を解決する設計か
2. なぜこの構成を選んだか
3. 代替案と、採用しなかった理由
4. DRY・KISS・YAGNIをどこで使ったか
5. 想定されるリスクと対策
6. まだ自分が確認できていない点
専門用語だけで説明せず、非エンジニアにも伝わる言葉にしてください。
最後に、上司から聞かれそうな質問を3つ出してください。
AIに答えを作ってもらうだけではなく、自分が説明できるかを確認する。
それが、異世界で最後に覚えるべきスキルだった。
エピローグ 「AIにそう設計させました」は、説明にならない
王都からの通信を受け取った翌朝、俺は久しぶりに王都の開発ギルドへ戻った。
会議室の中央には、俺がAIに作らせた設計図が映し出されている。
ギルド長が、静かに口を開いた。
「この構成を選んだ理由は？」
以前の俺なら、すぐにこう答えていた。
「AIにそう設計させました」
でも、それは理由ではない。
俺は一度、深呼吸をした。
「今回の目的は、ユーザー入力の検証処理を安全に共通化することです。既存の共通関数を使うことで、同じ知識を複数箇所に持たずに済みます。DRYの考え方です」
ギルド長は黙って聞いている。
「ただし、すべてを一つにまとめると、処理の違いが見えにくくなります。だから、共通化する範囲はここまでにしました。KISSを優先し、今回必要のない拡張は入れていません。YAGNIです」
言葉にするたび、手のひらに汗がにじんだ。
完璧な説明ではなかった。
それでも、以前のようにAIの名前を出して終わりにはしなかった。
ギルド長は、設計図から俺へ視線を移した。
「まだ説明に詰まるところはある。だが、ようやく自分の設計として話しているな」
その言葉を聞いて、俺は初めて気づいた。
AIは、指示どおりに設計してくれる。
しかし、どの案を採用するのか、何を捨てるのか、どんなリスクを受け入れるのかを決めるのは自分だ。
そして、その判断を上司やチームに伝えることも、自分の仕事だ。
だから俺は、設計図を受け取ったあと、AIに答えだけを作らせるのではなく、説明の練習を頼むことにした。
この設計を、上司に説明できるように整理してください。
- 何を解決する設計か
- なぜこの構成を選んだか
- 代替案と採用しなかった理由
- DRY・KISS・YAGNIをどこで使ったか
- 想定されるリスクと対策
- まだ確認できていない点
最後に、上司から聞かれそうな質問を3つ出してください。
AIは、説明の材料を整理してくれる。
でも、会議室で自分の言葉に変えるのは俺だ。
俺はまだ、すべてをすぐに説明できるわけではない。
だが、これからはできるようになる。
「AIにそう設計させました」だけで終わるのではなく、「なぜこの設計を選んだのか」を一つずつ話せるようになる。
それが、前世ニートだった俺が異世界で手に入れたい、本当のエンジニアスキルだ。
仕事に慣れてきた人へ。
後輩から、
「LGTMとApproveって何が違うんですか？」
「Draft PRは、いつレビューすればいいんですか？」
「DRYって、何を共通化するんですか？」
「AIが作った設計を、どう説明すればいいんですか？」
と聞かれたとき、あなたは自分の言葉で答えられるだろうか。
AIに、
「この要件をDRYで、KISSで設計して」
と指示したあと、上司から、
「なぜその設計にしたの？」
と聞かれたら、理由まで説明できるだろうか。
AIを使わないことが答えではない。
AIに設計してもらい、その設計を理解し、必要なら直し、最後は自分の言葉で説明できることが大切なのだと思う。
俺はまだ、説明できないことがある。
だが、これからはできるようになる。
前世ニートの異世界エンジニア、俺のスキル習得は、ここから始まったばかりだ。
この記事が、AIに任せるだけの自分から、AIと一緒に考えて説明できる自分へ進むための助けになっていたらいいな。
みなさんの現場で使われている、説明するのが難しいエンジニア語や、上司に聞かれて答えに困った設計判断があれば、ぜひコメントで教えてほしいです。