🪛 動くけど、読まれない。じゃ、それって意味ある？
エンジニアの現場でありがちなのが、
「動いてるからOKでしょ？」という“自分基準の満足”。
でも実際には、書いたコードは自分だけのものじゃない。
設計者が異動すれば、メンテするのは別チーム。
検証するのは非エンジニアの現場担当者。
運用にまわる頃には、仕様を知らないシステム部門が面倒を見る──
つまり、
「動くだけのコード」は、“読まれなければ使われない”んです。
特に製造業や組織内の技術開発では、
“技術そのもの”よりも、“どう伝えるか”が評価に直結することもある。
可読性は“品質”じゃなく、“伝達手段”。
──そう思うようになったのは、ひとつの失敗がきっかけでした。
🔍「動けばいい」は、現場じゃ通用しない
プログラミングを始めたばかりの頃、私は特性値を予測するモデルを開発していました。
Pythonで書いた処理を、意気揚々と本番システムの管理者に提出。
中身は──関数も使えず、ひたすら直列に書き連ねた“数千行の一本道コード”。
そして返ってきたコメントが、これ。
「正直、読めないです……」
え、動いてるんですけど……？
当時の私は、本気で「どこが悪いのか分からない」状態でした。
「他人が読む」ことなんて、想像すらしてなかった。
でも今ならわかります。
動くだけのコードは──運用されず、引き継がれず、信頼されない。
そこから私は、少しずつ意識を変えていきました。
“通じるコードを書こう”と。
📌 この記事で得られること
この記事は、「動くけど読みにくいコード」に悩んだことのあるエンジニアに向けた実体験ベースの内容です。
✅ ChatGPTを使ってコードレビューを依頼した際のリアルなやりとり
✅ なぜ可読性が“技術力”ではなく“伝達力”なのか？その本質
✅ コードの整頓が開発スピードやチーム連携にどう影響したか
✅ ChatGPTとの壁打ちで見えてきた「自分の思考のクセ」と改善プロセス
ChatGPTにレビューをお願いしてみた
ある日、いつものようにPythonで自動処理を組んでいたときのこと。
「動くには動くんだけど……なんか見た目がカオス。」
printだらけ、無駄にネスト、命名ルールはその場の気分。
ちょっと前の自分なら「とりあえずOK」で流してたけど、
このときは、**「誰かに見せたくないコード」**になってる自覚があったんです。
そこで試してみたのが、ChatGPTにレビューをお願いするという使い方。
いつもは調べ物や軽い添削に使っていたけれど、ふとこう投げてみました。
返ってきたのは、まるで淡々と冷静な上司からのフィードバック。
──全部、なんとなくは自覚してました…
でも不思議と腹は立たず、むしろこう思ったんです。
「そうそう、そこなんだよな…」と。
なぜかAIに言われると素直に受け入れられる。
他人に言われたくないけど、AIなら聞ける。
そんな“絶妙な距離感”が、地味にありがたいんです。
ChatGPTとの壁打ちで「なぜそう書いたか？」が浮き彫りに
そして、ここからが本番でした。
レビューをもらったあと、内容を見ながら自分の中で整理していると、
ふと、別の疑問が浮かんできたんです。
「これ順番変えたら読みやすいけど、他の処理に影響ないかな……？」
そこで追加の質問をしてみると──
……というふうに、“一方的なレビュー”じゃなく、“対話”が始まったんです。
中でも印象的だったのが、ChatGPTから返ってきたこの逆質問。
「この処理、なぜこの順番で書いているのですか？」
……え、いや、なんとなく…（汗）
そこで改めて説明しようとすると、
・処理の依存関係が実はあいまいだった
・本来は分けるべきロジックが混ざっていた
・書いたときの意図が、自分の中でもぼやけていた
という、“思ってた以上に整理されていなかった現実”が浮き彫りに。
でも逆に言えば、説明しようとすることで、初めて自分の設計意図を言語化できたんです。
そしてこのやり取りを通して、だんだんこう思うようになりました。
ChatGPTって、コードにツッコミを入れてくれるだけじゃない。
「設計の理由」まで一緒に深掘りしてくれる、もう一人のエンジニアみたいな存在。
ChatGPTは“コードの整理整頓アシスタント”だった
正直、それまでは「あとで直せばいいでしょ」って軽く考えてました。
開発中のコードなんて、動けばとりあえずOK。
処理の見通し？変数名？再利用？──全部“後回し”のリスト行き。
でも、ChatGPTにレビューしてもらいながら可読性を意識して書き直していくと、
意外なほど自分の開発スタイルそのものが変わっていくのを感じました。
💡 再利用性の向上 → 結果的に開発スピードも爆上がり
たとえば──
初期化処理、設定パラメータ、読み込む元データの切り替え。
最初は毎回ベタ書きだったけど、それらを関数に整理しただけで、
後から別条件で試すときの“切り替えのしやすさ”が段違い。
正直、それまでは「可読性って“人のため”でしょ」と思ってたけど、
実は“未来の自分のため”でもあったんだと痛感しました。
- ロジックを関数化し、目的が明確に
- 閾値変更も簡単、再利用しやすい
- 変数名とファイル名で内容が一目でわかる
ChatGPTは“リファクタのスタートスイッチ”
もちろん、ChatGPTの提案が常に正解ってわけじゃありません。
でも──
- 「雑に書いた部分」を的確に拾い上げてくれる
- 自分の“思考のクセ”や“作業の雑さ”を冷静に見せてくれる
- 質問される中で、自分の中の意図が整理されていく
まさに、“最初の整理スイッチ”として最高の相棒なんです。
実際に、ChatGPTと壁打ちしたあとのコードって、
- 自分でも読みやすい
- 他人にも説明しやすい
- そして、「ちゃんと考えて書いた感」がにじみ出るんですよね。
それだけで、チームでの信頼感も、レビュー時の安心感も変わってくる。
“読みやすいコード”は、自信になる。
これは、実際にChatGPTと向き合ってみて初めて気づいたことでした。
可読性は“技術力”じゃない、“伝える力”
多くの人が誤解しがちですが、可読性の高いコード＝技術力の高さではありません。
本質は、**「誰かに意図を伝える力」**にあります。
- 変数名に意味を込めるのは、「この値が何なのか」を伝えるため
- 関数を分けるのは、「この処理はひとまとまりですよ」と教えるため
- コメントを書くのは、「ここで何をしているか」を共有するため
つまり、コードとは“伝える文章”であり、読み手と対話する手段です。
だからこそ、可読性は“技術の言語化力”とも言えます。
私がChatGPTと壁打ちする中で気づいたのも、「技術を翻訳して届ける力」こそが、現場で求められているということでした。
ChatGPTレビュー活用ルーティン（私の場合）
ChatGPTとのやりとりは、単なる「レビュー依頼」で終わらせない方が面白い。
私が実際にやっているのは、こんなルーティンです：
- まずコードをそのまま貼って、レビューを依頼
→「可読性・処理構造・改善点」をざっくり見てもらう - 返ってきた指摘に対して、自分の“書いた理由”を考える
→「なぜこの順番に？」「なんでこの変数名？」と自問タイム - さらにChatGPTに追加の質問をぶつける
→ 例：「じゃあこの修正で他の処理に影響しない？」「この関数の意図はこうだけど、どう思う？」 - 改善案を参考にしつつ、自分の手でリファクタ
→ 丸写しじゃなく、「考え直して組み立て直す」時間にする
このプロセスを踏むことで、コードは整うし、自分の頭の中も整理されていく。
もはやレビューというより「設計の壁打ち」。
ChatGPTが、**“技術の筋トレ相手”**みたいな存在になってきました。
まとめ：ChatGPTは“伝わるコード”への道しるべ
ChatGPTを使ったレビューで気づいたのは、
「動くコードを書くこと」と「伝わるコードを書くこと」はまったく別のスキルだということ。
- 意図が伝わるように書く
- 処理の意味が読み取れるように整理する
- 「なぜそう書いたのか」を説明できる状態にする
これって、仕事としてコードを書く上でめちゃくちゃ重要なんですよね。
🔧 実際、どう変わったのか？製造業エンジニアとしての実感
それまでの私のコードは、“開発としては動いているけど、他人から見たら意味が分からない”状態。
- モデルの切り替え条件がハードコーディング
- 入力ファイルのパスや閾値が埋め込み式
- 処理順が暗黙的で、途中から読んでも全体像がつかめない
当然、システム運用担当者からも「これってどうなっているの？」とたびたび聞かれる始末。
でもChatGPTにレビューを依頼し、「読み手目線で設計し直す」ことを繰り返すうちに──
- 設定値を1か所にまとめて変更しやすく（yaml, py ファイル）
- 処理ごとに関数分割して再利用可能に（工程ごとのpyファイルを作成 → mainと分ける）
- コメントを“手順のガイド”として使えるレベルに整理
こうした修正を経て、現場とのコミュニケーションが劇的にスムーズになりました。
「見れば分かるコード」があるだけで、
資料や打ち合わせの負担が減り、開発スピードも上がる──これは実感としてあります。
今では私は、コードを書くときにこう思うようになりました。
「ChatGPTに見せたらどう言われるかな？」
「ちゃんと読みやすくなってるか？」
「そもそも自分で読み返したときにわかるか？」
コードの質は、自分の中の「もう一人のレビュワー」が育ててくれる。
その最初の一歩として、ChatGPTは**思った以上に優秀な“技術の鏡”**です。
コメント