AIを仕事でどう使えばいい？エンジニアの業務効率化アイデア
生成AIを仕事で使ってみたい。
でも、
「具体的に何に使えばいいのか分からない」
という人は、まだ多いと思います。
AI活用というと、
メールを書く。
文章を要約する。
議事録を作る。
そんな使い方が紹介されることも多いですが、
エンジニアの仕事では、
もっと広く使えます。
私は実際に仕事で生成AIを使っていますが、
開発で考えると、
要件定義から設計、コーディング、レビュー、テスト、ドキュメント作成、バグ調査まで、ほぼ全工程で使える
と感じています。
ただし、
AIに全部任せればよい、
という話ではありません。
私が大切だと思っているのは、
AIは仕事を大きく支援してくれる。
でも、判断と責任は人間が持つ。
ということです。
AIを使うことで、
人間だけでは難しかった量の作業をこなせるようになります。
一方で、
AIが作った成果物を採用するか。
その内容で本当に問題ないか。
どこまでAIに情報を渡してよいか。
最後に決めるのは人間です。
今回は、
私が実際に仕事でAIを使って感じていることをもとに、
エンジニアの仕事で、
どこにAIを使えるのかを考えてみます。
まず初心者は「検索の代わり」にAIを使ってみる
生成AIを初めて使う人には、
私はまず、
検索の代わりに使ってみる
ことをすすめたいです。
AI初心者の人と話していると、
「検索と何が違うの？」
と聞かれることがあります。
確かに、
知りたいことを調べるという意味では、
目的は似ています。
でも、
使い方はかなり違います。
検索では、
まず検索キーワードを考えます。
検索結果を開きます。
いくつものページを読みます。
それぞれの情報を比較します。
そして、
自分で答えを組み立てます。
一方、
Web検索に対応したAIであれば、
自然な言葉で質問し、
複数の情報を整理した形で回答を得られる場合があります。
さらに、
「もう少し詳しく」
「初心者向けに説明して」
「この2つの違いは？」
と、
そのまま会話を続けられます。
検索キーワードを何度も変える必要もありません。
私は、
まずこのスピード感を体験してもらうのがよいと思っています。
ただし、
AIの回答をそのまま信じるのは危険です。
元の情報を見る。
公式情報を確認する。
重要な内容は一次情報で裏取りする。
最後は人間が確認する。
ここまで含めて、
AIを使った調査だと思っています。
要件定義・仕様設計では「議論相手」として使う
AIは、
要件定義や仕様設計でも使えます。
私はこの段階では、
AIを議論相手として使う
ことが多いです。
たとえば、
考えている要件を整理してもらう。
仕様の要点をまとめてもらう。
別の視点から意見をもらう。
抜け漏れがないか確認してもらう。
一般的な設計観点を出してもらう。
こうした使い方です。
自分一人で考えていると、
どうしても思考が偏ります。
「これでいいだろう」
と思ったところに、
AIから別の観点を出してもらう。
それだけでも、
考える材料が増えます。
ただし、
ここで注意したいことがあります。
AIは、
その会社特有の事情を、
最初から知っているわけではありません。
社内ルール。
過去の経緯。
顧客との関係。
製品固有の制約。
暗黙知。
こうしたものは、
人間側で補足する必要があります。
だから、
AIの一般論をそのまま正解として使うのではなく、
一般論を材料にして、自分たちの事情に合わせて考える。
この使い方が大切だと思っています。
コーディングは、AI活用の中心になっている
コーディングは、
生成AIの恩恵を感じやすい分野だと思います。
コードを書いてもらう。
補完してもらう。
既存コードを説明してもらう。
リファクタリング案を出してもらう。
実装方針を相談する。
利用できる範囲で、
まとまったコードを読み込ませて、
構造を整理してもらう。
以前なら、
人間が一行ずつ確認していた作業の一部を、
AIがかなり支援してくれます。
もちろん、
生成されたコードを、
そのまま採用するわけではありません。
なぜこのコードなのか。
既存仕様と合っているか。
例外処理は十分か。
セキュリティ上問題ないか。
保守できるか。
こうした確認は必要です。
それでも、
AIが下書きを作ることで、
人間はゼロから書くよりも、
確認や改善に多くの時間を使える
ようになります。
私は、
ここが大きな変化だと感じています。
ChatGPTやClaudeなど、どの生成AIを仕事で使うか迷っている方は、「仕事で使える生成AIサービス比較｜社会人エンジニア向け」も参考にしてください。
レビューとテストは、人間だけでは難しい量をAIで補う
AIを使っていて、
大きな可能性を感じるのが、
レビューとテストです。
コード量が増えれば、
人間が確認できる量には限界があります。
テストも同じです。
考えられるケースを増やすほど、
時間がかかります。
そこでAIを使うと、
コードレビューの補助。
テスト観点の抽出。
テストケース作成。
テストコード生成。
実行結果の整理。
といった作業を支援できます。
AIを使うことで、
人間だけでは難しい量の確認やテストを実施しやすくなり、確認範囲を広げられる
と感じています。
ただし、
AIが生成したコードやテストが、
必ず正しいわけではありません。
テストそのものに抜けがあるかもしれません。
コードに問題があるかもしれません。
だから、
AIを使えば品質が自動的に保証される、
とは考えない方がいい。
AIで確認範囲を広げる。
そのうえで、
最終的な妥当性を人間が確認する。
この役割分担が大切だと思っています。
ドキュメント作成は、AIとかなり相性がいい
開発現場でよくあるのが、
コードはある。でもドキュメントが追いついていない。
という状態です。
私自身、
引き継ぎの場面で、
必要なドキュメントがきれいに残っていた経験は、
ほとんどありませんでした。
開発は進めなければならない。
納期もある。
不具合対応もある。
すると、
どうしてもドキュメントは後回しになりがちです。
でも、
後になって困ります。
なぜこの実装にしたのか。
どこに注意すればいいのか。
何を変更したのか。
次の担当者が、
またコードを読み解くところから始める。
ここでも、
AIはかなり役立ちます。
コードから説明文を作る。
READMEを作る。
仕様のたたき台を作る。
変更内容を整理する。
引き継ぎ資料を作る。
FAQを作る。
もちろん、
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に答えを出してもらう。
生成されたコードを、
理解せずに使う。
AIが作った資料を、
中身を読まずに提出する。
AIの回答を、
裏取りせず採用する。
こうなると、
効率化ではなく、
判断そのものを手放してしまいます。
特に、
経験の浅い人ほど、
AIを使いながら、
なぜその答えになるのか
まで確認することが大切だと思います。
AIを使わないのではなく、
AIを使いながら基礎も理解する。
分からないコードが出てきたら、
説明してもらう。
知らない考え方があれば、
理由まで聞く。
そうすれば、
AIは答えを代わりに出すだけではなく、
学ぶための相手にもなります。
AIは、
考えなくてよくなる道具ではなく、
考える範囲を広げたり、作業を加速したりする道具
として使った方がいいと思っています。
自分で考える。
AIにも考えてもらう。
比べる。
確認する。
最後は自分で決める。
この使い方が大切です。
AIに任せられることが増えるほど、人間が何を学ぶべきかも変わってきます。「AI時代にエンジニアは何を学ぶべきか？」では、私自身が今後必要だと考えている学びを整理しています。
エンジニアの仕事を5つに分けるとAIを使いやすい
「AIを何に使えばいいのか分からない」
という場合は、
自分の仕事を5つに分けてみると分かりやすいです。
調べる
情報収集。
検索。
比較。
技術調査。
ここは、
AI初心者でも始めやすい領域です。
考える
要件整理。
壁打ち。
抜け漏れ確認。
客観的な意見。
AIを、
考える材料を増やす相手として使います。
作る
コード。
資料。
ドキュメント。
テストコード。
ゼロから作るだけでなく、
たたき台を作ってもらうだけでも効果があります。
確認する
コードレビュー。
資料レビュー。
テスト観点。
抜け漏れ確認。
自分一人の視点だけでは気づけないことを、
AIに確認してもらいます。
分析する
バグ調査。
ログ解析。
コード解析。
原因候補の整理。
多くの情報を整理する仕事は、
AIの力を感じやすいところです。
この5つに分けて、
自分の仕事を見直すと、
「ここならAIを使えそう」
という場所が見つかると思います。
まとめ｜AIは全工程で使える。でも、判断するのは人間
私は、
生成AIは、
エンジニアの一部の仕事だけで使うものではないと考えています。
要件定義。
仕様設計。
コーディング。
レビュー。
テスト。
ドキュメント。
バグ調査。
ほぼ全工程で使えます。
そして、
AIが使える範囲は、
これからさらに広がっていくと思います。
ただし、
AIが仕事をしてくれるからといって、
人間の責任がなくなるわけではありません。
何を依頼するか。
どんな情報を渡すか。
成果物を採用するか。
本当に問題ないか。
最終的に判断するのは、
人間です。
だからこそ、
AI時代のエンジニアには、
技術だけでなく、
伝える力。
任せる力。
確認する力。
判断する力。
そうした力も、
ますます重要になると思っています。
私は、
AIを使いこなすというのは、
単にプロンプトを書くことではなく、
AIという新しい仕事相手を、うまくマネジメントすること
だと考えています。
仕事で少し使ってみて、「もっと体系的に学びたい」と思った方は、「エンジニア向け生成AI・IT学習サービス比較」も参考にしてください。
今日の一歩
AIをまだ仕事であまり使っていないなら、
今日は、
普段なら検索することを1つだけ、AIに聞いてみてください。
難しいテーマでなくて構いません。
いつも検索エンジンで調べていることを、
自然な言葉で質問する。
返ってきた答えに、
追加で質問する。
最後に、
公式情報や一次情報を確認する。
まずは、
このスピード感を体験してみてください。
そして余裕があれば、
次は、
自分で作った資料をAIに見せて、
こう聞いてみてください。
「この資料を読む人の立場で、分かりにくいところを教えてください」
AIに仕事を丸投げする前に、
AIと一緒に仕事をする。
まずは、
そこから始めてみてください。
