エンジニアの「やってる感」を生む日常行動とその解体
エンジニアの「やってる感」を生む日常行動とその解体
エンジニアとして、日々の仕事で 「本当に価値を生み出せている」 と胸を張って言えるでしょうか？
技術の世界では、新しいツールや情報が溢れる中、表面的には「やっている感」を得やすい行動がいくつも存在します。重要な点は、それらツールがが実際にはどれだけ価値を生んでいるかにフォーカスすることであって、ツールを使っていることやフレームワークを使っていることに満足するべきではないのは言うまでもないでしょう。
本稿では、エンジニアが陥りがちな「やってる感」に浸れる日常行動を取り上げ、その背後にある心理や構造を冷静に解体しつつ、真に価値を生むエンジニアリングとは何かを探っていきたいと思います。
理解なきAIコード利用の危うさ
近年、ChatGPTに代表される生成AIがエンジニアの強力なアシスタントになっています。一瞬で回答やコードの提案をしてくれるその便利さは、開発効率を飛躍的に高めているといっても過言では無いでしょう。しかしながら、同時に、「出力されたコードをそのままコピペして動けばOK」という安直な使い方 も散見されるようになってきました。以前、他の記事でも述べましたが、このような使い方には、大きなリスクと落とし穴が潜んでいます。
実際、生成AIが吐き出すコードは一見正しく有用に見えても、以下のような問題を含んでいる場合があります。
-
内容の誤り – AIは訓練データに基づいて答えるため、時に的外れなコードやバグを含むコードを生成することがある。
-
コード品質の問題 – 古い非推奨の書き方や非効率なアルゴリズムなど、現在のベストプラクティスに反するコードが出力されるケースもある。
-
プロジェクト方針との不整合 – プロジェクト固有のコーディング規約や設計思想にそぐわない実装が提示されることもあり、文脈を無視したコードはチーム開発で混乱を招く。
こうしたリスクにもかかわらず、特に経験の浅いエンジニアほどAIに頼り切ってしまう危険性があります。実際、基礎を十分理解していない初心者でも、生成AIの力を借りれば一見それらしいコードを書けてしまい、場当たり的に“それらしい”機能を実装できてしまっています。
しかし、そうした基礎なき力に頼れば保守不能なコードや深刻なセキュリティ問題を招いたり、本人の成長も妨げられてしまうでしょう。AIが吐き出す答えに安易に飛びつけば、一時的には仕事が片付いたような達成感を得られるのでしょうが、それは幻想に過ぎません。
ChatGPT頼みの誤った実装
実際に私の身近でも、AI任せの実装が問題を引き起こした例がありました。
あるプロジェクトではPythonのライブラリSQLAlchemyを使う方針でしたが、後輩エンジニアはChatGPTから得た生SQLのコードをコピペしてプルリクに出してきました。ライブラリを使えば数行で済む処理を、直書きのSQLで実装しており、一見動作はしたものの接続管理やインジェクション対策などが抜け落ちた非常に危ういコードになっていました。
本人に「DBやSQLの方が使い慣れているの？」と尋ねたのですが、「いいえ、今回のPJで触るのが初めてです。」と非常に面白い回答をもらいました。
なぜこんなことが起きたのでしょうか？後輩はSQLAlchemyの使い方を理解しないまま、ChatGPTの答え＝正解と思い込んでしまった のです。
自分の中で「どのようなライブラリを使うか？」「どういう実装方針にするか？」の分別がついておらず、盲目的にAIに聞いた結果、たまたま出力されたSQLコードをそのまま利用してしまったのです。これがひと昔前であれば、自分でネットを巡ったり、ドキュメントを調べたりして、様々な方法があることを認識する筈です。その上で、周囲に相談して、「このPJにはSQLAlchemyを使うのが良い」との結論に至ったと思います。
（蛇足ですが、この後輩には、以前に「勉強しておいて」とSQLAlchemyで実装されたプロジェクトのリポジトリを共有していました。しかしながら、本人はそのことも忘れ、安直に生成AIを使うという指針をとってしまったのです。）
この事例は実に象徴的であると思います。
エンジニアにとって、コードが「とりあえず動く」ことと「価値を生む」ことは全く同義ではないです。結局、必死に（AIで生成したものなので、必死だったかどうかは実際には分かりませんが）作成したコードがその場で却下され、作業的には完全に巻き戻しになりました。「仕事した」と後輩本人としては思ったのでしょうが、実際にはPJに対して全く貢献していなかったのです。
「調べものだけ」で一日が終わる非生産性
「今日は色々と調べものをして勉強になった」と感じつつ、振り返ればコードも書かず成果物もないまま一日が過ぎてしまった ──そんな経験はないでしょうか？エンジニアは日々学習が必要な職種です。新しい技術や解決策をウェブで検索し、情報収集に時間を費やすのは決して悪いことではなく、むしろ必要なスキルとも言えます。しかし、明確な目的やアウトプットがないまま闇雲に検索を続けたり、調べた気になって満足してしまったりする状態は危険です。
とくに業務の場では、時間を無制限に浪費するわけにはいきません。私の身近な新人エンジニアの例では、「gitのresetとrevertの違いを勉強しろ」と言われ、本来、必要に応じて深めれば良いだけのgit全体の知識を1ヶ月半かけて勉強に費やしてしまったことがありました。業務時間においては、わからないことを延々一人で抱え込んで手を止めるのは、チームにとっても本人にとっても損失になります。
自力で調べたり、経験不足を内省する姿勢自体は非常に尊いですが、職場では時間を意識し効率的に学ぶ義務があります。遠回りして悩んでいる時間にも給料は発生し、その分納期が延びてくれるわけでもないのです。
では、どうすればこのような非生産的な一日を避けられるでしょうか。鍵は目的意識にあると思います。まず調査のゴールを明確に定め、漫然とネットを彷徨わないこと、必要な情報を絞って集めたら、早速コードに手を動かして試してみることです。
手を動かせば具体的な課題が見え、追加調査のポイントも明確になります。また、長く足踏みしそうなら早めに周囲に相談するのがベストです。先輩や同僚に聞くのは決して怠慢ではなく、問題解決を加速する有効な手段だと言えます。
さらに調査には時間制限を設ける習慣も重要です。Googleには 「15分調べて進展しなければ相談する。調べないのは他の人の時間を無駄にしているし、15分以上調べるのは自分の時間を無駄にしている」 という格言があります。
「動けばOK」の落とし穴――リーダブルコード軽視の代償
エンジニアにとってコードが正しく動作することは最低条件です。しかし、「とにかく動けばいい」「バグが出なければそれで十分」 という姿勢で品質を顧みないコードを書いてしまうのは、プロフェッショナルとして避けるべきです。確かに締切に追われていたりトラブルに緊急対応したりする中で、「ひとまず動くものを」と考える場面はあるでしょう。しかしながら、動くコードが常に価値あるコードとは限りません。
コードの価値は単に動作するか否かだけでなく、読みやすさ（リーダビリティ）や保守のしやすさにこそ現れます。他人や未来の自分がそのコードを読んだとき、理解しやすく変更しやすいか ——そこが二流の仕事と一流の仕事を分ける大きなポイントと言えるでしょう。
にもかかわらず、「とりあえず今動けばいいや」と寄せ集めの実装で乗り切ってしまうと、後からコードを読む人（それが自分自身であっても）は大いに苦労します。場当たり的にコピペを繋ぎ合わせただけでもなんとなく動いてしまうコードは、一見仕事をやり遂げた錯覚を与えるかもしれないが、そのツケは必ず後で回ってくることでしょう。
リーダブルコードを軽視したまま蓄積されたシステムは、いわゆる 「技術的負債」 の塊となります。可読性・保守性の低いコードはバグ修正や機能追加のたびに余計な工数を生み、最悪の場合「触るくらいなら作り直した方が早い」と放棄される事態すら招きかねません。つまり、「動けばOK」で済ませたツケは、後になってプロダクトの成長スピードや開発者の生産性を確実に蝕むものとなり得るのです。
では、どうすれば「動けばOK」の罠から抜け出せるのでしょうか。
この対策は非常にシンプルで、常に自分や他人が後で読んでも理解できるコードを書くことを心がける ことです。そのために「なぜこの実装にしたのか」を説明できるか自問し、可読性を意識するだけでもコードの質は向上します。動くものを書いて終わりにせず、可能であればリファクタリングで洗練させる習慣も持つようにしましょう。チームでコードレビューを徹底し、安易な実装に疑問を投げかけ合う文化を築ければなお良いと思います。
以下のような書籍も参考になるでしょう。
おわりに：価値ある「やっている」を求めて
ここまで、エンジニアが陥りがちな「やってる感」の罠を見てきました。
生成AIから得たコードを安易にコピペすること、調べものだけで満足して手を動かさないこと、「動けばOK」と品質を後回しにすること ——これらはいずれも、一時的には自分に“仕事をしている”という安心感や達成感を与えてくれるものです。しかし、その影で本来生み出せたはずの価値を奪っている可能性を忘れてはなりません。
エンジニアリングの本質は、動くコードを書くこと自体ではなく、価値のある問題解決を提供することにあると思います。自らの行動を振り返り、日々のタスクにおいて、単に「やってる感」を満たそうとしていないか？ それとも、腹を括って価値創出に向き合っているか？ここが大事なポイントだと思います。
真のプロフェッショナルであるなら、どうあるべきか——常に自問することを胸に刻みたいものです。
Discussion