「最も価値のあるコードは、書くべきでないコードです」

「最も価値のあるコードは、書くべきでないコードですか？」

前回の記事では、人間のソフトウェア開発者とAIの侵入に対抗するために、競争力を最大限に活かす方法について書いてきました。機械の支援を受けた場合でも、有用なソフトウェアを作成することは常に困難であることを説明しました。ただ、これによってコードを書く楽しさを奪われてしまう可能性については取り扱っていませんでした。私が指摘したいのは、あなたが心を込めて作り上げたオープンソースのプロジェクトではありません。それには続けて取り組んでください。私が言及したいのは、給与をもらって書いたりメンテナンスをしたりする企業の巨大プロジェクトです。効率と効果に関する議論を振り返ると、AIが同様に優れたコードを書ける場合（現時点ではまだ「もし」の話ですが）、あなたを雇うよりも安く、休まずに信頼性の高い、柔軟性のある労働力になるでしょう（病気休暇がない、無制限の残業、オンボーディング不要）。その点については申し訳ありません。

機械化によって、過酷、危険、または汚れた作業から解放されます。中世の農民は馬や他の動物を使用して、荷車を引くことが好きではありませんでした。道具や機械を発明し、筋肉だけでなく、他の作業も置き換えるために使用しました。確かに、一部の知的労働は退屈であることがあるかもしれませんが、それほど危険や汚れたものではありません。ソーシャルメディアのモデレーションのような不快な例外はありますが、それらの多くは挑戦的で、脳に良いです。ですから、なぜ人間が既に好きで上手にできること、例えば脚本を書いたり、歌を書いたりすることをAIに任せるべきなのでしょうか？冷酷な計算屋は、機械が受け入れ可能な品質で何でもできるのであれば、手作業で何かをする意味はないと主張するでしょう。手編みの洋服のニッチ市場は存在しますが、世界中の人々に十分なほどの編み手はいません。

もし良い雇用主を持っているならば、彼らはあなたの健康や幸福を気にしますが、彼らの主たる関心事は、AIが将来的には格段に低コストで同じ価値をもたらすことができるという点で、連続的なコーディング体験の喜びを保証することではありません。コードは価値を創造する手段ですが、同時に負担でもあります。同じ価値を少ない（またはゼロの）コードで実現できれば、それに越したことはありませんし、コードの作成と保守は費用がかかります。

従来のコーディング言語のスキル（クラス、型、変数、制御構造を伴うもの）が時代遅れになる時期は分かりませんが、私が退職する前にはそうなると予測しています。そのシンギュラリティがやってくるまで、伝統的なコーディングの腕前（Advent of codeのような脳トレ）は、ますますコンピュータによるものよりも優れた課題になるでしょう。私たちはそれを楽しみや他の人々との競争のために練習しています。チェスや囲碁のようなものです。

• 美しいAIアート：Dalle-2を促して、特徴的なテックストーリーイメージを作成する
• 「ヒュメインが革命的なAIパワードウェアラブル「AI Pin」を発売」
• 小売業の革新：AIが顧客体験、在庫管理、マーケティングに与える影響

一方、技術面接ではこのような話題は避けてください。もはや重要ではなく、実際には何の意味もありません。白板上で配列リストやマージソートの粗雑な実装を書く方法を知っていることが、具体的にどのようなことを伝えるのでしょうか？車輪を再発明できるということです。おめでとうございますが、シニア開発者にとってもっと価値のあるスキルは、コードを書かない判断をできることだと私は信じています。だからこそ、私はノーコード面接を紹介しています。課題に基づくコーディングのチャレンジで、最も賢明な決定は手を出さないことです。

以下のように進行する可能性があります。

ノーコード面接

面接官：「Java 6で書かれたスタンドアロンアプリケーションがあると仮定しましょう。非常に基本的なSwing GUIでXMLファイルを読み取り、データを変換し豊かにし、いくつかのデータベース検索を行い、Excelレポートを生成します。それは1年前に私たちを去った開発者によって構築および保守されました。私たちのシニアアーキテクトはコードを見て、品質が著しく低いと判断しました。典型的なスパゲッティであり、ほとんどユニットテストもありません。それを改善して良好な水準に引き上げるためには、どのように対応しますか？」

応募者：「コードベースを見る前に、リファクタリングがどれだけ緊急であり、重要であるかを感じたいと思います。それは異なる問題ですから。」

インタビュアー：「どうして？」

応募者：「まあ、私の年次税申告書は非常に重要ですが、次に提出するまであと6か月ですので、緊急性はありません。一方、今夜の劇場のチケットを手に入れたいと思ったら、それは緊急ですが、あまり重要ではありません。では、このツールは組織にとってどれくらい重要ですか？どれくらいの利益をもたらし、どれくらいの損害をもたらす可能性がありますか？ユーザーがツールにアクセスできなくなったとしたらどうなりますか？一時間、一日、一週間ならどうですか？ツールが間違ったデータを生成するとしたらどうでしょうか？何人のユーザーがこのツールに依存していますか？ツールはどのくらい頻繁に実行されますか？そして、緊急性とは、作業を延期できる期間の長さを指します。エンドユーザーは現在問題を抱えていますか？本番環境でのパフォーマンスは確実ですか？最近、何らかの事故がありましたか？変更の要求はどれくらい頻繁ですか？入力と出力の仕様はどれくらい安定していますか？旧式の技術に依存しており、近々アップグレードが必要になる可能性があるのですか？または、会社の方針でそれが必要ですか？」

インタビュアー：「非常に良い質問ですね。まとめますと、このアプリケーションは年に2回、社内アンケートのための入力データを生成するために使用されます。入力ファイルは給与明細のダンプであり、非常に安定しています。機能のリクエストは年に3〜4回あります。おそらくJava 6で書かれていて、開発者のマシンで実行されています。」

応募者：「これらの機能要求について、変更するのはどれくらい不便ですか？」

インタビュアー：「明らかに大変です。最近、2人の別々の開発者が細かい変更を行いましたが、コードが読みやすければ、その作業時間はずっと短くなったと不満を述べていました。」

応募者：「これらの機能要求は類似していましたか？」

インタビュアー：「そうですね。主に出力に列を追加したり削除したりすることが多いです。」

応募者：「それでも、2番目の開発者はまだ時間がかかりすぎると不満を述べていますね。もしかして、1番目の開発者はプロセスを文書化せず、リファクタリングも行っていなかったということですか？

インタビュアー：タッシェ

応募者：「それは既に最初の小さな成功です。しかし、全面的な改修が重要で緊急ではないという印象を受けますので、お勧めしないでしょう。努力は、少なくとも進歩的な変更が痛みを伴わないようにすることに向けられるべきです。その焦点でリファクタリングを行いましょう。」

インタビュアー：「あなたの回答はとても良いですね。では、もしもこのツールが非常に頻繁に使用され、エラーが許容できないとしたらどうしますか？銀行であり、ローンオファーのパーセンテージを計算するツールです。エラーがあれば何百万ドルもの過大請求または誤請求につながる可能性があります。機能のリクエストは頻繁かつ多様であり、会社は標準に合わせることを要求しています。どのような手順を取りますか？」

応募者：「単体テストのカバレッジはどうですか？」

インタビュアー：「20％未満です」

応募者：「もし雇用主がそんなに軽率なビジネスクリティカルなコンポーネントに対してそんな態度を取るなら、私は彼らのために働きたくないと思います。ですので、それがただの仮定であることを祈ります。ソースに手を加える前にテストカバレッジに取り組まなければなりません。リファクタリングを開始する前にリグレッションのリスクが非常に大きいからです。詳細な単体テストを作成するのはおそらく不可能です。すべてが密結合されている場合は、シングルブラックボックスのコンポーネントテストから始めましょう。コードベースは脆弱ですので、変更ごとに何も壊れていないことを確認する必要があります。

代表的なXML入力ファイルとコンテナ化されたデータベースを作成します。アプリケーションを一度実行し、生成されたExcelファイルをベースラインとします。こうすることで、コンポーネントテストが同じ入力とデータベースの状態でアプリケーションを実行した場合、出力が参照ファイルと一致しているはずです（ただし、現在の日付/時刻をどこかで利用している場合は除く）。ここから、ファイルのI/Oとデータベースアクセスをビジネスロジックから切り離し、何も壊れるリスクがない状態で適切なユニットテストを作成することができます。ただし、テストをおまけとして追加するので、TDDの教義を忘れてください。プロダクションコードと同時にテストを書くという利益は既に失われています。おそらく、シングルコンポーネントテストでカバレッジが30ポイント向上したことに気付くでしょう。」

インタビュアー：「最後の質問です。あなたは良いコードが好きではありませんか？」

応募者：「もちろん好きです。ただ、有用なソフトウェアの方が好きです。私たちの職人芸のセンスを傷つけるかもしれないコードでも、問題がない限りは壊れていません。そして、それは良意のある改善の後に起こることがあります。本当の機能要求に応じてのみこれらの改善を行ってください。その場合は、取り組みを時間制限にすることです。FをAにまで引き上げることは魅力的ですが、それは稀なビジネスセンスではありません。」

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!