直近１年くらい、AIが激動すぎて要件定義・設計・実装・テスト・運用から諸々の開発フローまで色々揺るがしている感がありますね。 ということでざっくばらんにAI所感みたいなのを書いてみます。
要件定義・設計
- 自然言語で指示したら良い感じに設計してくれるようになった
- pros/consとかも書いてくれる
- 自分では思いつかなかった良い設計を考えてくれることもわりとある
- 良くも悪くもオーバースペック気味の設計も考えてくれる
- 図解もしてくれるので、自分でイチからdraw.ioとかで図を書いたり説明することが本当になくなってきた
- 設計したドキュメントはちゃんと書かせようとすると冗長になりがちで、誰もレビューしないみたいなことになりがち。ということでフォーマットは大事。ADR書きましょうとかDesign Doc書きましょうとかは大事ではあるものの運用に乗らなかったら無意味というか悪影響が大きいので、多少抜けがあったとしてもほどほどにするのが良いのでは？と思ってる。
実装
- 設計と同じく自然言語で良い感じに実装してくれる
- テストコードも一瞬で書いてくれるし、ちゃんと指示すればちゃんと書いてくれる
- 設計と同じく正しく動くものの良い実装も悪い実装もやってくれるので、ちゃんと実装したものに対してレビューするのは今も必要そう
- 中身をたいして理解しなくても正しく動くコードができちゃう。これは良し悪しありそう。
- 現段階では少なくともPRを出す人は、そのコード内容をある程度理解すべき。70-80%くらいは理解しておく。理解しないと仕様変更が発生したときにわりと効率悪い解を出してしまって急速に負債が溜まる。中身を理解しておけば、構造的な負債リスクを下げれる上、不具合発生時もAIがメインでやるとはいえ勘所をつかんでおくことで予期せぬ不整合を防げるのでは？と思ってる。
- 冗長なコードも書きがちなので適宜共通化する。冗長な呼び出しもあるので注意。
- 実装時も図解は有効。特にシーケンス図やER図はスキル化するくらいには毎回書かせている。スキル化も「シーケンス図やER図をHTMLで書いてわかりやすく説明して」レベルの内容。
レビュー
- 書かれていることが整合性取れていそうか（局所的整合性）、不具合っぽいのが無いか、規約に違反していないか、などはAIの方が高速で正確なのでちゃんとAIを使ってレビューする
- 人間の役割としては「60-80%程度で良いからちゃんとPRの内容を理解する」「不必要なものを作っていないか」「考慮漏れがないか」「全体的な整合性が取れているか」あたりのレビューに徹するのが良いのではないかと思ってる。とくに最初の２つ。
- 例えば Metabase / Redash などのBIツール使えば良いじゃんっていうコードは依然として発生しがちなのでそこはちゃんと見る、みたいな。１ヶ月くらいで終わる施策ならそもそも運用でカバーできない？とか、ここを頑張るより全体的な体験上げない？とか
- あとハーネス不足？なところであんまり良いコードじゃないときもあるのでそこはちゃんとレビューしながら仕組みを作ると良さそう
テスト / QA
- テストコードはルールをちゃんと作ってガンガン書く。0%のカバレッジを80%くらいにするのはわりと簡単にできるので、どんどん自動テスト書こう。
- E2E的なテストも書きやすくなっている。自動で流さなくてもCDP使ったりして手元で流すだけでもだいぶ安心。探索的テストもやってくれる。
- YAMLやCSVで適当にフォーマットしたテストケースを食わせる、とかでもわりと簡単にできちゃうので開発で並行してテストすると心強い。
- とはいえユーザ体験的なところはもうちょい人間が必要な気もしており、そのあたりも含めて検証中
運用 / インシデント
- インシデントや実装中の不具合に関してはログをコピペするだけで良い感じに解析してくれる
- というかAWSなどの認証が通っている状態であれば、aws cliなどのコマンドを直接叩いてCloudWatch LogsやDatadog APMのデータを抽出して不具合を調査してくれる。なので自然言語で適当に指示すれば簡単に不具合を調査・解消できるようになった。
- 単純にツールを入れてAIから可視化できている状態であれば、人間が運用できなくても良くなってしまった感じがある。ログも多少AIフレンドリーに情報量多めに出した方が良いかも？とか
- データ是正するときも人間が書けないようなちゃんとしたSQL文を一瞬書けてしまう。開発環境でもこれは結構役立つ。
分析
- CloudWatch LogsやAthenaやDatadog APM、BigQueryなどの権限を渡してしまえば簡単に正確に分析してくれるようになった
- もちろん人間が判断するためにBIツールも必要だと思うが、アドホックな分析は圧倒的にやりやすくなった。
- 前述のように分析用のSQL文も一瞬で書いてくれる。
思ってること
実装のスピードと質、要件定義〜運用・分析まで一貫して技術領域も幅広く抑えて案件を進めていく強力な推進力を売りにしてきた私ですが、そのどの強みもAIに奪われてしまいましたｗ
転職活動するときもPR数とかを上げてたり自分のベンチマークとして使っていたものが本当に意味がなくなりましたね。
そうすると今の自分に残ったものは何だろうか、AIだけに実現できないものは何だろうか、これから磨くべきは何だろうか、というものを考える毎日です。
で、どうやら残りそうなのは
- コーディングだけではない推進力
- ステークホルダー調整力、要件定義力、実装したものをリリースまで繋げる力、リリースしてから良い感じにする力
- 設計・実装の判断力
- プロダクトが必要とし、それでいてオーバースペック過ぎず、理解や運用がしやすい設計。全体最適をちゃんと考えられる力。それを裏付ける知識と経験。
- 実際作るのはAIができるが、作る判断は人間にしかできない。例えばCI/CD、AIコーディング基盤、不具合検知、分析基盤などなど。無いとジリ貧になるような仕組みづくり。
- コミュニケーションや組織におけるソフトスキル全般
- 知見の共有。Slackなどのテキストコミュニケーション力。育成力。それらの仕組み化。
あたり。
１人あたりの保守できる領域やサービス数は認知の壁はあれど、AIの発達により増えていく傾向だと思ってます。 とはいえエンジニアも含めたステークホルダーコミュニケーションは絶対にゼロにはなりません。 人の判断を介在する以上は意思決定を促すための適切なコミュニケーションがあり、それがビジネスの質とスピードになるような気もしています。 コミュニケーションはSlackやMTGだけではなく設計・実装や仕組みのレビュー・開発プロセスも含まれます。 とすると、やはり上記３つの観点が大事そうだなぁと思いました。 あとは「設計・実装の判断力」を磨くために、リリースした後にプロダクトや運用などをよく観察して考察するような力もエンジニアにはより求められているのかも、とか。
