AIにコードを書かせるほど、SEの仕事は「実装」より「整理」と「検証」が重要になる
コードを書くこと自体は、たしかに速くなった
生成AIの話になると、どうしても「コードをどれだけ速く書けるか」に目が行きやすいです。
実際、それは間違っていないと思います。
簡単な処理の叩き台を作るとか、処理の流れを整理するとか、フローチャートやアーキテクチャの案を出すとか、そういうことは本当に速くなりました。
でも、仕事で使えば使うほど思うのは、SEの仕事で本当に差がつく場所は、もうコードを書く速さだけではないということです。
むしろAIにコードを書かせるほど、人間側に求められるのは別の力になってきています。
何を作るのかを整理すること。
要件や仕様を自分の言葉で説明できること。
設計方針や実装方針を決めること。
そして、出てきたコードや案が本当に正しいのかを検証すること。
今のSEは、実装そのものより、その前後の質で差がつきやすくなっている。
私はそう感じています。
AIは便利だけど、最後まではやってくれない
生成AIを触っていて便利だと思う場面はたくさんあります。
たとえば、
処理の流れの整理
設計案の比較
実装方針の壁打ち
テスト観点の洗い出し
説明文や仕様メモの叩き台づくり
このあたりは、本当に助かります。
頭の中にぼんやりあるものを言葉にして返してくれるので、考え始めのスピードはかなり上がりました。
ただ、そこで毎回思うことがあります。
AIは方向性を出すのはうまいけれど、最後の正しさまでは保証してくれない、ということです。
実際の仕事になると、
構文は言語ごとに違う
関数の使い方も細かく違う
ライブラリやフレームワークにも癖がある
環境差分もある
既存システムとの整合性もある
チームのルールや保守性もある
こういう現実があります。
だから、結局最後は人がやるしかないです。
この仕様理解で合っているか確認する
この実装で本当に問題ないか調べる
関数の使い方を確かめる
既存コードとのつながりを見る
例外ケースを考える
実際に動かして壊れ方を確かめる
ここは、今でも人間の仕事です。
そしてたぶん、これからもそう簡単にはなくならないと思っています。
だから大事になるのは「整理」と「検証」
この話をシンプルに言うと、生成AI時代のSEに必要なのは、実装力だけではないということです。
まず大事なのは、整理する力です。
要件を整理する
仕様を整理する
未確定な点を整理する
設計方針を整理する
実装方針を整理する
整理が甘いままAIに聞くと、返ってくる答えもどこかズレます。
要件が曖昧なら答えも曖昧になるし、前提条件が抜けていれば、もっともらしいけれど使えない答えが返ってきます。
しかも厄介なのは、生成AIの答えは一見かなりそれっぽく見えることです。
だから「なんとなく合っていそう」で進めたくなる。
でも、実務で必要なのはそこではありません。
本当に必要なのは、その答えを見抜くことです。
この答えは正しいのか
この実装は実務に耐えるのか
例外条件は漏れていないか
保守しやすいか
他の処理に悪影響は出ないか
この検証をサボると、AIを使っているのに逆に手戻りが増えます。
なので、これからのSEは「速く書ける人」だけでは足りない。
整理できる人、見抜ける人の価値が、かなり上がると思っています。
単純作業だけでは、だんだん厳しくなる
少し厳しめに書くと、これからきつくなるのは、手順化された作業だけに頼る仕事の進め方だと思います。
たとえば、
とりあえず手を動かし始める
毎回ゼロから作る
前にも車輪の再開発をする
何を作っているか自分で説明できない
曖昧なままAIに投げる
出てきたコードをそのまま使う
こういう進め方は、昔から危うかったです。
でも生成AIが入ることで、その危うさがさらに見えやすくなった感じがあります。
AIは、雑な問いにもそれっぽい答えを返してくれます。
だから、考えなくても前に進んでいるように見えます。
でも実際には、整理不足と検証不足が後ろで一気に噴き出します。
これから価値が上がるのは、単純に「書ける人」だけではなくて、
ちゃんと調べられる人
案の壁打ちができる人
深掘りできる人
横展開できる人
自分の言葉で説明できる人
こういう人だと思います。
※この記事にはAmazonアソシエイトリンクが含まれます。
生成AIによるソフトウェア開発
知識ゼロから学ぶソフトウェアテスト第3版
AIとソフトウェアテスト
この話は、新人育成ともかなり関係がある
ここで外せないのが、新人育成の話です。
私が見てきたIT現場でも、働き方はかなりホワイトな方向に変わってきました。
これは基本的には良いことだと思っています。
長時間労働や、無理を前提にした働き方は、やはり続かないです。
ただ、現場にいると感じることがあります。
昔に比べると、若手が初期に大量の試行錯誤を経験する時間は取りにくくなっていると感じます。
試して、失敗して、直して、また試す。
その回数を、長い時間の中で無理やり稼ぐやり方がしにくくなった。
その結果として、現場では「昔と同じ育て方だと伸びにくい」と感じる場面があります。
でも、私はこれを単純に「今の働き方が悪い」とは思っていません。
本質はそこではなくて、昔は長時間の試行錯誤が、育成の不足をある程度埋めていたということだと思っています。
言い換えると、育成の仕組みが多少弱くても、量で何とかしていた面があった。
でも今は、その前提が使えない。
だから昔と同じ育て方のままだと、伸びにくくなる。
それだけの話だと思います。
ホワイト化が悪いのではなく、育ち方の前提が変わった
最近は「ホワイトハラスメント」みたいな言葉を見かけることもあります。
この言葉にはいろいろなニュアンスがあるので、雑に使うとズレやすいとも思っています。
少なくとも私が言いたいのは、「ホワイト企業になったからダメだ」という話ではありません。
働き方を改善すること自体は必要です。
昔みたいに、長時間やれば育つ、無理したほうが早い、みたいなやり方は、もう前提にしないほうがいいと思います。
ただその代わりに必要になるのは、育成の設計です。
何を先に学ばせるのか
どの順番で考えさせるのか
どこをAIで壁打ちさせるのか
どこを自力で検証させるのか
ここをちゃんと作らないと、時間だけ減って、成長も遅く見えやすくなります。
なので必要なのは、昔に戻ることではなく、限られた時間の中で学習の密度を上げることだと思っています。
新人ほど、AIを「正解生成機」として使わないほうがいい
この流れでいうと、新人ほど生成AIを「正解を出してくれる道具」として使わないほうがいいです。
むしろ使い方としては、
要件整理の壁打ち相手
実装方針の比較相手
テスト観点の洗い出し相手
自分の説明を言語化する相手
くらいのほうがいいと思います。
新人のうちに身につけたほうがいいのは、全部を一人で速く書けることよりも、
何を作るのか説明できる
入力と出力を言える
制約条件を言える
未確定な点を言える
実装方針を言える
出てきた答えを鵜呑みにしない
このあたりです。
昔みたいに、ひたすら量をこなして伸びるのが難しいなら、先に整理と検証の型を身につけるほうがいい。
私はそう思っています。
これからのSEは、「書く人」より「定義して見抜く人」に近づく
もちろん、実装が不要になるわけではありません。
コードが読めなくていいわけでもないです。
構文や関数の理解がいらなくなるわけでもありません。
でも、それだけでは足りない。
これからのSEは、
問題を整理する
仕様を定義する
方針を比較する
AIにうまく壁打ちする
出てきた答えを見抜く
検証して現場で使える形に落とす
こういう力が、前より重要になると思います。
特に、昔のように「とにかく量をこなせば育つ」という前提が弱くなった今は、なおさらです。
AIがあるから楽になる、で終わる話ではないです。
AIがあるからこそ、人間側の整理と検証の質が、そのまま仕事の質になる。
私はもう、そういう時代に入っていると感じています。
まとめ
生成AI時代、SEの仕事で差がつく場所は、実装そのものだけではなくなってきました。
AIにコードを書かせるほど重要になるのは、
要件と仕様を整理すること
設計方針と実装方針を言語化すること
出てきた答えを検証すること
だと思います。
そしてこの変化は、AIだけが理由ではありません。
働き方が変わり、昔のように長時間の試行錯誤で育つ前提が弱くなったことも大きいです。
だから必要なのは、昔に戻ることではなく、育ち方を変えることです。
限られた時間の中で、整理し、壁打ちし、深掘りし、検証する。
そういう仕事の仕方と学び方が、これからのSEにはますます必要になると思っています。
『リーダブルコード』
コードを書く速さより、読みやすさ・保守性を考える流れに自然につながる1冊。
『プリンシプル オブ プログラミング』
実装テクニックより、設計や考え方の軸を補強しやすい。
用語集
生成AI
文章、コード、図、要約などの叩き台を生成できるAI。便利だが、常に正しいとは限らない。
要件
何を実現したいかという目的や必要条件。業務側・利用者側の期待も含む。
仕様
要件をどのような振る舞い・条件で実現するかを定めた内容。
設計方針
システムや機能を、どんな考え方で組み立てるかという方向性。
実装方針
実際にどんな構成・手順・技術選択でコードに落とすかという考え方。
検証
AIや人が出した案・コードが、本当に正しいか、使えるか、壊れにくいかを確かめること。
壁打ち
案を一度外に出し、対話しながら整理・改善していくこと。
生成AI、システム開発、仕事の進め方の変化について、単なる流行話ではなく、
それで仕事がどう変わるのか
まで言語化していきたいと思っています。
プロフィールはこちら
生成AI活用、記事構成の壁打ち、システム開発まわりの言語化、技術記事の整理などの相談はこちら
