今回は少し本業の話をしてみようと思う。
「非機能要件を自分で設計できるエンジニアが、うちにはほぼいない」
グループ会社のシステムを横断的に管理しているプロジェクトディレクターとしての私が感じている昨年の所属している会社の現実だ。
そもそもAWS環境の設計はできない、運用保守もマニュアルがないとできない。
そして能動的に学ぶ、情報を取りに行くメンバーがいない。
協力会社のメンバーに頼むしかない状況となっており、会社として構造的に高コスト体質となっているのが現状である。
インフラはベンダに丸投げで環境を構築し、ベンダが提示した設計書、試験結果報告書を承認する。
そしてアプリは初期構築や移行はベンダ任せ、その後の運用保守を自社で担う、そういう形式が当たり前になっている。
現場ではこの状況を危機と感じている方もいるが、経営層や中間管理職は、理屈は理解していてもどうしたら現場が動くようになるのかが見えておらず、何も進展していない。それが現状だ。
私はそんな中、有志で非機能の教育カリキュラムを作成するメンバーに加えられた。
私はAWS以前の時代、まだ社内にサーバ室があった時代に物理サーバを手で触り、テープ交換、ログ確認、テープを遠隔地へ送付していた時代も知っている。
その後はオンプレを社内のサーバ室からデータセンターへの移行という波があり、今のクラウドへ移行までを経験してきた世代だ。オンプレ時代からクラウド時代への変化を、インフラ設計者として全身で受けてきた。
だからこそわかる。今のエンジニアたちが「なぜ」を学べていないのは、彼らの問題ではない。AWSが当たり前になった今「なぜ」を教える仕組みが、最初から存在しなかったのだ。
例えばAWSの以前はDNSはRoute53なんてなく、自前でBindを更新したり、サーバ証明書は自前で組み込んでいたし、CloudFrontの前は別のCDNサービスを使っていた。このような背景を知らないAWSだけ資格勉強で学習してきたクラウドネイティブ世代にはなかなか理解できないことであろう。
なぜ大企業のエンジニアは非機能要件を軽視するのか。
原因は個人の怠慢ではない。構造的な問題だ。
前職の上司にこう言われたことがある。
「お前たち、うちの会社はまだ障害が起きてもミスしても幸せだよ。なぜなら誰も痛い思いしないからな。これが石油会社のシステムだったら工場が爆発したり、最悪人が亡くなることもあるんだ」
これはかなり刺さった。情報システムの障害は「画面が見られない」「処理が止まる」で済む場合が多い。しかし制御システムや社会インフラでは、非機能要件の欠陥が直接、人命に関わる。私たちの業界は「誰も痛い思いをしない」から、非機能の重要性が実感として根付きにくい構造になっている。
だからといって無害ではない。非機能要件をしっかり定めずに設計したシステムは、障害時にサービスが止まる。止まった時間だけ、経済的損失が発生し続ける。ECサイトなら売上が消える。基幹業務なら業務が止まる。金融系なら取引機会を失う。「見えない」コストが、静かに積み上がっていく。
機能要件は「見える」。ボタンを押したら計算できた、データが保存された——成果がその場で確認できる。しかし非機能要件は「見えない」。正常に動いているときは誰も気づかない。
さらに残酷なのは評価の非対称性だ。非機能設計に投資して成功しても「当たり前でしょ」と言われる。軽視して障害が起きれば「なぜ備えなかった」と炎上する。
頑張っても褒められず、サボれば叩かれる構造の中で、人間が非機能を後回しにするのは、ある意味で合理的な行動とさえ言える。
大企業ではこの傾向がさらに強まる。ベンダに任せれば責任が分散される。設計の妥当性を判断できなくても、承認の判子は押せる。そうやって10年、20年が過ぎる。
気づいたときには、組織の中に「非機能を語れる人間」が誰もいなくなっている。
そしてその仕組みを今回は生成AI（Claude）を使って短期間で作れないかと思い活用することにした。
結果として、一人では数ヶ月かかったであろう骨格を、わずか2〜3週間で形にすることができた。ただし、AIが得意なことと、人間が判断しなければならないことは明確に分かれていた。その話を、これから書く。
ステップの全体設計とその根拠
カリキュラムの骨格を作るにあたって、最初に生成AI（Claude）に投げた問いはシンプルだった。
「非機能要件を知らないエンジニアを、ゼロから内製化できる水準まで育てるには、どんな段階が必要か」
返ってきた叩き台は想定より構造的だった。
知識習得、実環境での観察、障害対応の体験、設計への参加、要件定義の主導——この流れ自体は自分の直感とも一致していた。
しかし生成AI（Claude）が提示した順序には、自分では気づかなかった視点が一つ含まれていた。
「なぜ学ぶのかを理解させるステップが、技術習得より先に必要ではないか」
これは刺さった。技術を教える前に、動機を作らなければ何も始まらない。前職の上司の言葉が頭をよぎった。
結果として設計したのは以下の9ステップ
- ステップ0は基礎知識の習得。OS、ネットワーク、AWSの基本概念を座学とハンズオンで身につける段階。
- ステップ1で現行環境の理解に移る。実際に動いているシステムの構成を読み解き、なぜこの設計になっているのかを自分の言葉で説明できるようにする。
- ステップ2で運用保守の初歩
- ステップ3で障害対応の体験学習へと進む。サンドボックス環境で意図的に障害を起こし、復旧する経験を積む。
- ステップ4からは上流に入る。現行システムのAsIs分析から次期構想書の作成へ。
- ステップ5でRFP作成
- ステップ6で要件定義書の作成。
- ステップ7でIaCによる実装
- ステップ8で内製化の完成形——ベンダ非依存の体制構築を目指す。
最終ゴールは内製化により外部調整のリードタイムをゼロにし、思いついた改善をその日のうちに実装（IaC）する。
それを協力会社ではなく社員が自前で行う。この「自前」が生む圧倒的なスピードこそが、高コスト体質を打破する唯一の解だ。
この順序には理由がある。技術知識と実務経験を交互に積み上げる設計になっている。座学だけでは定着しない、しかし経験だけでは体系化されない。その両方を螺旋状に組み合わせることで、「なぜそうなっているのか」が血肉になっていく。
ここで一つ、重要な落とし穴に触れておく必要がある。
AWSの学習というと、多くのエンジニアは資格取得に走る。それ自体は否定しない。体系的な知識を得る手段として資格は有効だ。しかし資格を持っていても、実際の業務でAWS環境を設計・運用できないエンジニアが大量に存在する現実がある。
理由はシンプルだ。資格試験は「知っているか」を問う。業務は「判断できるか」を問う。この二つは全く別の能力だ。
「Multi-AZとは何か」を説明できるエンジニアは多い。しかし「このシステムにMulti-AZが本当に必要か、コストと可用性のトレードオフをどう判断するか」を自分の言葉で語れるエンジニアは極めて少ない。
だからこのカリキュラムでは、資格取得をゴールに置かなかった。
資格は通過点であり、本当のゴールは「現場の判断や業務が回せること」だ。
ステップ0で基礎知識を習得した後、すぐにステップ1で実環境に触れさせるのはそのためだ。知識を文脈の中に置いて初めて、それは使える能力になる。
では実務で何が必要か。資格の勉強では教えてくれないことがある。自社環境への適合という視点だ。
どれだけ優れたアーキテクチャも、自社のネットワーク構成、セキュリティポリシー、社内規約や規定類と整合していなければ採用できない。AWSのベストプラクティスと、自社の制約条件は必ずしも一致しない。そのgapを埋めるのが、現場のエンジニアの仕事だ。
さらにユーザーやシステムオーナーの利用スタイルと意向も無視できない。どれだけ技術的に正しい設計でも、使う人間の実態と乖離していれば機能しない。
そしてこれらを踏まえた上で、初めて構成の検討に入れる。ユーザー数、ライセンス、サーバ性能、拡張性、冗長化、災害対策、バックアップとリストア、ログ、監視——これらの一つひとつに「なぜこの選択か」という根拠が必要だ。
資格は「知識の地図」を与えてくれる。しかし地図を持っていても、自分が今どこにいるかを判断できなければ、目的地には辿り着けない。
このカリキュラムが本当に育てたいのは、複数案を比較検討し、「なぜこれが最適か」をオーナーに説明でき、ベンダに設計構築方針を正しく伝えられるエンジニアだ。それができて初めて、ベンダ依存から脱却できる。
最も難しかった問題：「なぜ学ぶのか」を教える設計
カリキュラムの骨格が固まった後、最初に直面した壁がこれだった。
「技術を教える前に、なぜ学ぶのかを理解させなければならない」
頭ではわかっていた。しかし実際に「どう教えるか」を設計しようとすると、途端に難しくなった。非機能要件の重要性を説明する資料はある。AWSのベストプラクティスも山ほどある。しかしそれらを並べても、受講者の心は動かない。
人間は「正しいこと」では動かない。「自分ごと」になったときに動く。
ここで生成AI（Claude）に問いを投げた。
「非機能要件の重要性を、技術知識のない受講者に理解させるには何が必要か」
返ってきた答えは「損失の可視化」だった。障害が起きたときのビジネスへの影響を具体的な数字で示せ、というアドバイスだ。理屈としては正しい。しかしこれだけでは足りないと感じた。
数字は頭に入る。しかし腹には落ちない。
腹に落とすには、体験か、強烈なエピソードが必要だ。そこで思い出したのが前職の上司の言葉だった。石油会社のシステムなら人が死ぬ、という話だ。あの一言が自分に刺さったのは、数字ではなく「命」という言葉だったからだ。
だからカリキュラムの導入部に、この構造を意図的に組み込んだ。最初に「命に関わるシステムでは非機能の欠陥が人を殺す」という極端な事例から入る。そこから「では私たちの業界では何が起きるか」という経済損失の話に降りてくる。抽象から具体へ、極端から身近へ、という順序だ。
しかしもう一つ、より根深い問題があった。
受講者の多くは「学ばなくても今の仕事は回っている」という現実の中にいる。ベンダに任せれば設計書は上がってくる。承認の判子を押せば案件は進む。その日常を壊す動機が、外から与えられない限り、人は動かない。
生成AI（Claude）にこの問いを投げたとき、返ってきた答えが興味深かった。
「外発的動機より内発的動機を引き出す設計が必要ではないか。受講者自身が『このままでは自分のキャリアが危うい』と感じる瞬間を作れるか」
これは鋭かった。非機能を学ぶ理由を「会社のため」ではなく「自分のキャリアのため」に接続する。ベンダに判断を丸投げし続けるエンジニアは、5年後10年後に何が残るのか。その問いを受講者自身に立てさせる設計だ。
技術の話をする前に、キャリアの話をする。これがこのカリキュラムの導入設計の核心になった。
生成AI（Claude）との実際のやり取り——うまくいった点と限界
2〜3週間、生成AI（Claude）と壁打ちしてカリキュラムを設計した。
その経験から言えることがある。AIは万能ではない。しかし使い方を知っていれば、一人では辿り着けない場所に連れて行ってくれる。
具体的に何がうまくいき、何が限界だったかを整理する。
うまくいったこと
最も効果的だったのは「構造の叩き台を作らせること」だ。
ゼロから9ステップの骨格を考えると、人間は自分の経験と組織の常識に引っ張られる。「うちの会社はこうだから」「これまでこうやってきたから」という慣性が、思考の射程を狭める。
生成AI（Claude）にはその慣性がない。「育成ステップの論理的な順序はどうあるべきか」という問いに対して、組織の事情を忖度せずに答えを出してくれる。その叩き台を人間が現実に合わせて修正する、という分業が機能した。
次に効果的だったのは「言語化の壁打ち」だ。
頭の中に漠然とある概念を言葉にするのは難しい。「非機能要件の重要性をどう説明するか」「受講者の動機付けをどう設計するか」——こういった抽象的な問いに対して、Claudeは複数の切り口を一度に提示してくれる。その中から「これだ」と感じるものを選び、自分の言葉に変換する作業が格段に速くなった。
ビジネス用語への翻訳も助かった。我々のような技術者が当たり前に使う専門用語は、経営層や非技術者にはなかなか伝わらない。
それをビジネスIT用語レベルで伝わる言葉に変換する作業は、地味に時間がかかる。生成AI（Claude）はこれを一瞬でやってくれる。「Multi-AZ」を「システムの二重化による障害時の継続稼働」と言い換える、といった作業だ。
限界だったこと
一方で、生成AI（Claude）が答えを出せない領域も明確にあった。
組織の政治と人間関係だ。
「このカリキュラムを誰が承認するか」「どの部門が抵抗するか」「組織の中で影響力を持つのは誰か」——こういった問いに対して、生成AI（Claude）は一般論しか返せない。自社の組織図も、派閥も、誰が何を恐れているかも知らないからだ。
大企業で教育施策を動かすには、技術的な正しさより、社内の合意形成の方が何倍も重要なことがある。なぜなら教育にはコストがかかる。そして教育のために業務時間を削る必要がある。現場のマネージャーにとって、それは「今期のプロジェクトへの影響」という極めて現実的な問題だ。「正しいことだからやろう」では動かない。「やらないことのリスクの方が大きい」と感じさせなければ、承認は取れない。ここは人間が判断するしかなかった。
受講者の「腹落ち」の判断も限界だった。
生成AI（Claude）は「論理的に正しい説明」は作れる。しかし「この説明で、この受講者が本当に納得するか」は判断できない。人間の感情と経験の蓄積が必要な部分だ。カリキュラムの導入設計で「命の話から入る」という判断は、前職の上司のエピソードという自分固有の体験から来ている。これは生成AI（Claude）には出せない。
そして最も重要な限界——「これで本当にいいのか」という最終判断だ。
生成AI（Claude）は問いに対して答えを出し続ける。しかし「この方向性で組織が本当に変わるのか」という問いの答えは、現場を知る人間にしか出せない。AIは思考を加速させるが、責任を取ることはできない。
結局のところ、生成AI（Claude）は「優秀な参謀」だと思っている。情報を整理し、論点を明確にし、選択肢を並べてくれる。しかし最後に「これでいく」と決めるのは、現場を知り、組織を知り、人間を知っている自分自身だ。
それはAIの限界ではなく、むしろ正しい役割分担だと今は感じている。
大企業でAIを使った教育設計をする際の、最大の壁
カリキュラムの設計そのものより、遥かに難しかったことがある。
経営層に届けることだ。
経営層は現場が見えていない。現場は経営層に伝える言葉を持っていない。大企業における教育施策の多くが、この断絶の中で止まる。技術的に正しいものを作っても、承認されなければ動かせない。承認を取るには、経営層が理解できる言葉に翻訳する必要がある。しかし現場のエンジニアが直接経営層に説明する機会は、多くの大企業では構造的に存在しない。
今回のカリキュラムはボトムアップで作った。現場の実態から課題を拾い上げ、必要なステップを設計し、具体的な育成計画に落とし込んだ。内容には自信があった。
しかし本来であれば、これらは私が検討・実施すべきことではない。むしろ越権行為でもある。教育施策の設計は人事や経営企画の領域であり、一介のプロジェクトディレクターが主導するものではない、という見方もできる。
それでも動いたのは、誰もやらないからだ。正しいと思うことが放置されている状況を、黙って見ていられなかった。大企業の中で何かを変えようとするとき、多くの場合「それはあなたの仕事ではない」という壁にぶつかる。その壁を越えるかどうかは、結局のところ個人の判断だ。
そして経営層への説明は、自分ではできなかった。
上司の口から説明してもらう必要があった。つまり上司に「腹落ち」させることが、経営層への承認を取る前提条件になった。技術の話を、ビジネスの言葉に変換し、上司が自分の言葉として語れる形にする——この作業が、カリキュラム設計と同じくらいの労力を要した。
ここでも生成AI（Claude）は使えた。「この内容を、現場を知らない経営層向けに説明するにはどう言い換えるか」という問いに対して、複数の表現を出してくれる。しかし最終的に「この言い方なら上司が使える」という判断は、上司の性格と経営層との関係を知っている自分にしかできなかった。
AIは言葉を作れる。しかし誰の口から、誰に向けて、どのタイミングで話すか——これは人間関係と組織の力学の問題だ。大企業でボトムアップの施策を動かすとは、そういうことだ。
技術的な正しさは必要条件に過ぎない。十分条件は、組織の中に「動かせる人間」を作ることだった。
結論：AIは教育設計パートナーになれるか
2〜3週間やってみて、答えは出た。
なれる。ただし条件がある。
条件とは「現場を知っている人間が使うこと」だ。
AIは構造を作るのが速い。言語化を助けるのが得意だ。複数の切り口を一瞬で並べてくれる。しかしAIが出せるのは「一般解」であって「固有解」ではない。自社の環境だったり、規定や規約などの守るべきルール、組織の癖、経営層が本当に恐れていること——これらを知っているのは現場の人間だけだ。
逆に言えば、現場を知っている人間がAIを使えば、一人では辿り着けない場所に確実に速く辿り着ける。
私の場合、一人では数ヶ月かかったであろう骨格を2〜3週間で形にできた。しかしその骨格に血を通わせたのは、オンプレの時代からインフラを触ってきた自分の経験であり、前職の上司の言葉であり、現場の課題感であった。
AIはその作業を代替しない。加速させるだけだ。
今回はここまで。
この続きは、同様に感じている方の反響があればまた書く予定だ。
