コーディングのあるべき形

» 2021/12/28

インフラエンジニアをやっていると、「これはどうしてもできないな」という事案にぶつかることが多々ある。インフラ系の技術は、誰かの作ったソフトウェアを使いこなすことで成り立っています。なので、そのソフトができないこと、想定していないことを無理やり実現しようとすると、後から大変なことになり易い。ただ、これがコーディングになると、多少の無理をすれば大体のことができてしまったりする。ただ、無理が利く分、後からやり直そうと思うと大変だったりします。

そもそも、プログラミング言語というのは何でもできるように作られている。例えば、VBAであっても、ごちゃごちゃ弄ることでブラウザの制御だってできてしまいます。多少スキルが低くても、やり方さえ知っていれば、強引にでも機能が実装できてしまいます。そこにプログラミングの怖さがあると感じます。プログラムをやる上で「できる」「できない」で物事を判断するのでなく、それを実現したらどうなるかを基準にすると、幸せになれる気がします。

コーディングをしていると、どうしても「〇〇できればスキルが高い」のような感覚になりがちです。特に、スキルの低い人、例えばVBAを好んで使う人にこの傾向は強いです。標準機能でできる機能をわざわざ独自にコーディングしてしまったり、矛盾するような要件を強引にコーディングしてしまうような事例を見ることがあります。プログラミングは、バカでもコードを書けば動きます。バカが「〇〇できればスキルが高い」と勘違いして頑張られるのが一番怖いです。

個人的には、「プログラミングができれば何でもできるよ！」というノリの人を見ると、殴りたくなります。確かに何でもできますが、考えずに作るとゴミしか生み出せません。大事なのは、プログラミングが組めることではなく、バックボーンの仕組みです。まともな仕組みの上にプログラミングをしていかないと、後から技術負債になります。勢いに任せてコーディングするより、仕組みを整理する方が大事だと考えます。

仕組みを整理すると、何をどうやれば上手くいくか、あるべき形が見えてきます。ただ、人に言われるがまま機能を追加していくようなやり方では、いつまでもあるべき形がみえません。この、あるべき形が見えないままで頑張っても、スキルは伸びません。当たり前だが、仕組みを整理しなければ設計書も仕様書も書けません。コーディングと違って、仕組みの整理は地味な作業です。ただ、真面目に取り組めば、確実にスキルの向上に繋がっていきます。