定量化できない判断に必要なのが「ビジョン」
昨日ぐらいに、ひろゆき氏と安野たかひろ氏の対談記事が一部のエンジニア界隈でちょっと話題になっていた。
要は、スキルの高いエンジニアだったらコードが汚くても文句言わないし、頭が良いからコードが読める。それ故に、スピード重視を考えて、コードの読めない人向けに、コードのきれいさを強いられるのってちょっと違うよね、という話（僕の感覚での要約）
まぁ個人的感覚としても言ってることはわからんくない。頭の悪い人にレベルを下げるために時間を使うなら、スピード重視で行こうぜって、いかにもひろゆき氏の言説にありそうな流れだし、僕もどっちかというとそっちのタイプだし、記事全体としても、安野氏がバランスを取っているから、ひろゆき氏的な極論で終わっていないという意味でも好印象。後半は読み飛ばした。
ただ、管理者という視点と、業務委託を含む中途入社の方々に速やかにご活躍いただくことが我々にとってのスピードになるというベンチャー企業っぽい都合から見させてもらうと、きたないコードや、直感的でない変数名、なんならスペルミスしてる変数名などで、毎回オンボーディングで説明しなくてはいけない、地雷を踏でバグを誘発する可能性を内包しているソースコードよりは、立て板に水のように読めるソースコードの方が、都度都度の地雷を踏むリスクが減るという意味で、品質とスピードに寄与すると考えるのが妥当。
安野氏が以下のコメントを仰っていた。
ただ、リファクタリング工数を経営的なロジックで正当化するのは本当にしんどいと思います。
例えば、
1）短期的に売上を産まない
2）長期的にもどれくらいペイするのかよく分からない
3）何をどれだけ整理すべきかエンジニアごとに色々な意見がある
4）決して終わらないし、成果も定量的に測定できない
と、やりづらさが勢ぞろいです。
定量化できない判断基準において、ジャッジメントを入れるのに必要なのは「誰が言ったか」である。通常は、コードの品質に対する判断基準を定性的でも設定できるのはCTOのような技術トップの役割だ。
定量的に示さないといけないのは、一般社員が通したい企画で上司を説得するときに求められるやつで、それを省略できるのは、ビジョンが信頼され、かつ、その言動に対してダイレクトに責任が取れる人の仕事。
ソースコードをわかりやすくするためには時間というコストがかかる。つまり、トータルのコード量に対して、その後のメンテナンス性を維持するためにわざわざ時間をかけるジャッジメントを入れるということは、それが必要だからと意思決定をしていることとなる。
確かに、それをやらないと辞めてしまうようなエンジニア対してのご機嫌取りという側面もあるのかもしれないが、地雷をなくすことで、今後入ってくるであろう誰か、また３ヶ月以上先にコードのことをすっかり忘れている自分にとっての脳の無駄な稼働コストを下げるという意味でも「今のうちに直す」というのは、後から直すよりも圧倒的にお得な作業ではないだろうか。
もちろん、そのソースコードに対するリテンション可能性があるか？ってのはありますよ。使い捨てコードはChatGPTに置き換えられますし。ソースコードがWebサービスだったら、絶対にメンテ性やアップグレード、作り直しのためのわかりやすさを意識しておいたほうがいいと思います。
例えばセキュリティとかパフォーマンス問題を引き起こすコードとかって、その先の挙動に問題があったりもするわけで、コードの読みにくさ如きに足を引っ張られる場合じゃないとかもあるんでね。
こちらもどうぞ
それはともかく、もっと生成AIの活用コストが下がって、noteで記事を書いていると、右側に同じ文体でわかりやすく書き直してくれる文章がリアルタイムに表示されるようにならないかなぁ。英文メール書く時って、日本語を英語に変換したものを、もう一度、日本語に戻して言いたいことが正しく翻訳できてるか？ってのを何度か繰り返すことで英文を作ったりしてるけど、ラウンドトリップで回せるってことが結構重要なんだよなぁ。生成AIでプログラミングコードが生成できますって言説も、プロンプトとソースコードをラウンドトリップ（リバースエンジニアリング?）できないと継続的開発に使えないってことは意識しておいてほしいです。いずれは必要なくなるとは思いますが。まだ早い。
この記事が気に入ったらサポートをしてみませんか？