理解することとスピードを意識することのバランス
プログラムを作るとき、ネット上からコピーしたコードを使ったり、AIにテキトーな指示で書かせたコードを使うと、「中身はよく分からないけどとりあえず動く」みたいな状態がよく起きる。
自分しか使わないプログラムや、使用用途が限定的なプログラムであればそのようなつくり方でも良いけれど、長期にわたってメンテナンスされる可能性のあるプログラムや、他社に納品するようなプログラムなど、一定以上の責任を伴うようなプログラムの場合、「中身は理解していないがとりあえず動く」状態のものをリリースするのはリスクが高い。そのようなプログラムは、仮に不具合があった場合に修正することが難しく、成果物に対して責任を持つことができなくなってしまう。
そもそも、中身をほとんど理解していないプログラムや、自分でコントロールできないプログラムをリリースまで持ち込んでしまうのは、エンジニアとして成果物に責任を持つという観点では、望ましい状態とは言い難い。
一方で、仕事には納期がある。納期が迫っているにもかかわらず、「プログラムの内容をちゃんと理解していないので納品できません」というのは、エンジニアの心構えとしては素晴らしいけれど、社会人としては問題だと思われるかもしれない。
仕事としてソフトウェア開発を行う場合、「開発物の中身を理解してコントロールできる状態にすること」と「納期を意識したスピード」のバランスが求められる。
学習対象の見極め
分からないことを理解しようとするのは大事だけれど、全てを100%理解しようとすると、時間はいくらあっても足りない。特にスケジュールにあまり余裕がない案件であればあるほど、学習に対してあまり時間は取れなくなる。
知識のない技術が使われていたり、業務領域に知識がない状態である程度スピード感を持って開発するためには、何に学習コストをかけるべきかの取捨選択が必要になってくる。
- （自身の好奇心から）理解したい知識
- 理解しておかないと後々困りそうな知識
- 理解しなくても支障なさそうな知識
- 他のチームメンバーに頼れそうな知識
などを整理して、学習コストをかけるべき領域を見極める。このような、学習対象を見極めるスキルは、エンジニアにとって結構重要なスキルであると思う。
レガシーシステムの課題
DXがなかなか進まないまま2025年の崖に突入した日本は、これからレガシーなシステムと向き合わなければいけない機会が多くなってくると思う。
- レガシーシステムを使い続けながら機能追加を続けていく
- レガシーシステムを新しい技術でリプレイスする
- レガシーシステムの言語やフレームワーク・ライブラリを最新にアップデートする
- レガシーシステムを全く新しいシステムとして作り直す
といったケースが、今後増えていくんじゃないかと予想している。
実際、私自身が最近になってこのような案件に関わる機会が増えた。
既存のシステムに対して改修を入れたりする場合、既存のシステムで使用している技術や全体構成、仕様などをできるだけ把握しておくことが望ましい。そのためには、早い段階である程度の学習コストをかけて理解することに力を入れる必要がある。
しかし、レガシーなシステムは、使われている技術も当然レガシーである。
時代とともに廃れていった技術や、長年の改修で複雑化したシステムの仕様は、時代と共に詳細を知っているエンジニアが少なくなっていく。しかし、そのような技術やシステムの仕様を今から新しく学んだところで、今後の開発経験に活きる可能性はかなり低い。そのような技術を、モチベーション高く学ぶことができるかというと、正直かなり厳しい。
それでも、様々な要因からレガシーシステムに対して手を入れなければいけない場面や、中身を解析しなければいけない場面もある。
使用技術や内部の仕様に詳しい人はいない。しかし、学習コストをかけたくもない。でも、改修はしなければならない。
そんな状況に、一体どう立ち向かえば良いのか。
分からないものを分からないまま開発することはできるのか
こういう状況においては、分からないものを分からないままに開発する能力が必要になるのではないかと思った。
おそらく、今の時代においては、AIを使うことで大抵のものはそれっぽく作ることができる。分からないものを分からないまま開発するには、AIの利用は欠かせない。しかし、冒頭で述べたように、コントロールできない状態のプログラムをリリースするのは、責任という観点であまり望ましくない。
分からないものは分からないまま。しかし、仕様変更や設計変更、認識の齟齬があった場合に、軌道修正ができるレベルにはコントロールできる状態を保ちたい。そういう状態をどうすれば作れるのか。
仕様をタスクに分解し、タスクに沿って実装させる
私自身、今色々と試行錯誤している段階ではあるけれど、実装内容を具体的なタスクに落とし込み、それを人間が読んでなんとなく分かる状態にしておけば、ある程度コントロールができる状態になると感じている。
例えば、AIエージェントを使って、以下のような流れで開発を進める。
- AIとの対話で使用技術の概念や、システムの全体像を簡単に把握する
- 要件・設計方針をAIが読みやすいドキュメントに整形する
- ドキュメントとコードベースから、要件に対する実装計画を作成する
- 実装計画から、より具体的なタスクリストを作成する
- タスクリストにそって実装を進める
ここでいうタスクとは、例えば「どのファイルの何行目に、この処理の記述を追加する。」とか、「このコマンドを実行する」のような、具体的な作業内容。そのレベルの作業がリスト化されていて、そのリストに沿って必要な確認を行えば、開発を進められる、という状態を上記の手順で作成する。
そのような状態であれば、理解を深めずともある程度コントロールが効く状態を保てるような気がしている。
やっぱり理解は必要
分からないものを分からないままに、それでいてコントロール可能な状態で開発ができないものかと試行錯誤してみたけれど、結局のところ、何も理解しない状態で開発するのはやはり無理だと思った。
何も知らない状態では、まともなプロンプトを作ることができない。まともなプロンプトが作れなければ、AIを使ったところで精度の高いアウトプットは得られない。
まともなプロンプトを作れる状態にするには、使用されている技術の概要や、システムのなんとなくの全体像、要件のポイント、くらいは押さえておく必要がある。
また、AIが作成した実装計画やタスクリストを評価するためには、自分自身が要件をある程度は把握していなければいけない。
やはり、何も理解していない状態で、分からないままに精度高く開発をすることは、現時点では難しいと思った。
しかし、AIをうまく活用できれば、学習コストそのものを大きく削減できる。
そもそも、生成AIが登場したことで、新しいことを学ぶ際の学習コストは大幅に低下した。公式ドキュメントやチュートリアル、入門書などを読まなくとも、AIとの対話を繰り返していけばある程度の知識を得ることができる。レガシーな技術でも、AIに知識があれば、AIとの対話によってある程度の知識は簡単に身につけることができる。
さらに、AIに読ませるためのドキュメントの整形や、AIによる既存コードベースの解析をさせている中で、自然と知識が増えていく。AIによるアウトプットの精度を上げるための取り組みに力を注いでいれば、その過程で自然と自分の中の知識も増えていく。
AIとの対話を繰り返し、AIのアウトプットの精度を上げる工夫をすること自体が、そのまま自分にとっての学習になる。
学習コストをかけたくない部分の把握をAIに任せる
さらにAIエージェントが登場したことで、システムの仕様の把握や、技術的な内容の理解をAIに委託できるようになった。
そもそも、ソフトウェア開発のプロジェクトにおいて、マネージャーが技術面でシステム全体を把握していることはあまりいない。技術的な部分はエンジニアが把握していれば良く、マネージャーは必要に応じてエンジニアから情報を得て意思決定をする。
エンジニアにとってのAIも、今後はそのような位置付けになっていくような気がする。
AIがシステムの全体像や技術的な側面を理解している状態を作り、人間はAIから情報を引き出しながら、必要な意思決定やコントロールができる状態を作っていく。そのようなAIの使い方をすることで、人間側の学習コストを大きく圧縮することができる。
プログラマーやエンジニアは今後AIマネージャーになる、とAIエージェントの本に書いてあるのを読んだことがあるけれど、最近すごくそのことを実感している。
今後はエンジニアとマネージャーの垣根もなくなっていくのではないだろうか。
不確実性をどう減らしていくか
エンジニアリングの本質は、不確実性をいかに減らしていくかにあると思う。
技術や仕様をどこまで理解しているかは重要だが、全てを人間が把握しなければならないわけではない。AIにコードベースの調査やドキュメント整理、実装計画の作成を任せることで、人間が最初から細部まで学習するためのコストは大きく下げられる。
ただし、AIに任せれば理解が不要になるわけではない。AIの出力が要件に沿っているか、重要な仕様を取りこぼしていないか、修正によって別の箇所に影響が出ていないかを判断するためには、人間側にも一定の理解が必要になる。
これから重要になるのは、全てを知っていることではなく、不確実性の高い部分、そして何に学習コストをかけるべきかを見極めることなのかもしれない。
人間が深く理解すべき部分はどこか。AIに調査や整理を任せられる部分はどこか。その境界を適切に判断し、限られた時間の中で学習コストを配分できることが、AI時代のエンジニアに求められるスキルの一つになると思う。