まず、コードを書かない
あまり人から賛同されないかもしれないが、自分が信じていることがいくつかあることに気づいた。
なので、そのうちのいくつかを書いてみようと思う。第一弾は、コードは書かない方がよい、だ。
コードを書くのは最終手段
僕はコードを書かないで済ませられることはコードを書かない方がよいという信念を持っている。
事業の企画段階なら、コードを書かずに実証実験をする方が良い。プロトタイプなんぞオリジナルで作っている暇があったらノーコードツールとかGoogleスプレッドシートとかで実証実験をした方がいい。大事ことは提供しようとしているコアバリューに本当に価値があるかどうかを判断することだからだ。そこでオリジナリティを出す必要はない。
業務効率化をするのにコードを書く人もいるだろう。しかし、普通はとりあえずSaaSなり既存のノーコードツールがあればそれを使う方がいい。Slack Botを自分で作りたくなった時は、そもそもその業務が必要かどうかを問い直した方がいい。
コードを書くのは常に最終手段である。大事なことなので繰り返す、常に最終手段である。コードを書かないと課題が解決できないことがわかったとき、事業が進展しないとわかったとき、初めて書かれるべきものだ。コードを書くという手段を考えなしに用いるのは間違っている。コードを書きたいと思った瞬間、まず自分は間違っているかもしれないと疑わなければならない。
これはプロダクト開発においてもそうだ。ユーザーは機能の拡張を求めるが、当然ながら機能を拡張したあとのコードのメンテナンスには気を払わない。
一度使われ出したプロダクトであれば、ユーザーは無制限に機能の拡張を求める。ところが、コードを安易に書いてメンテナンスするべきものを無制限に抱え込むのは却って機能の拡張を遅らせる（俗に言う技術的負債のひとつの表れである）。それは結局、ユーザーのためにもならないし、ユーザーのためにならないことは事業のためにもならない。このことは見逃されがちだが、重要な事実である。
また、ユーザーは既存の秩序を疑うことは基本的にない。ユーザーは自社の業務に合わせて、あるいは自分に合わせて機能を使いやすくしてほしいと望む。しかし、その機能を使わなければならない業務が実はなんの利益にもつながらない、仕事のための仕事であるとは気づいていないこともある。
それを気づかせるのはプロダクトやSaaS提供事業者の仕事ではないかもしれない。しかし、本質的にユーザーのためにならない要望に応える義理は提供者側にもないはずだ。そうした要望にNoを言えるPdMが理想だし、価値をもたらさないコードを唯々諾々と書く作業員になりたい人はいるのだろうか。少なくとも僕はなりたくない。
考えなしにコードを書くのは早すぎる最適化
僕はひとりのソフトウェアエンジニアであるが、自分の知る限り「コードを書くな」と大っぴらに言っているエンジニアはあまり見たことがない。
みんなコードを書くのが好きだと言う。コードを書いていると幸せだという発言さえ聞いたことある。
しかし、ビジネスの現場においてはコードは書きたいから書かれるべきものではない。そして経験上、ほとんどの場合は書きたいから書いているときは早すぎる最適化になっている。
よく知られているように、「早すぎる最適化は諸悪の根源」なのだ。
そもそもそのコードは誰に、どのような便益をもたらすのか？
いま自動化しようとしているその処理はそもそも本当に必要なのか？
既存のツールで同等のことを実現できないか？
このような基本的な質問に答えることさえなくコードを書き始める人がいたりする。
どのような目的であれ、コードを書くと意思決定するのはプロダクトを作るという意思決定をするようなものだ。
プロダクトマネジメントの本を読めば上記のような質問に答えられない状況でプロダクトを作ってはいけないことはすぐにわかる。
しかし、プロダクトと同じように上記の質問に答えることなく生まれていくコードがこの世には普通にある。それも過剰に自動化されたりして。
本当に必要なのはシェルのワンライナーなのにWebサーバーのAPIを作るような人がこの世には多すぎる。はっきり言って時間と金の無駄だ。
いまのご時世、エンジニアの人件費は安くない。エンジニアの人件費はソフトウェア開発における原価の大部分を占めている。
であれば、その原価の大部分を占めるエンジニアが早すぎる最適化に邁進するのは事業にとってもよくない。原価が高いのに、利益やコストカットにつながりにくいコードを書いてばかりいるのは、文字通り遊ばせていることになってしまう。
コードを書くときは徹底せよ
ただ、常にコードを書くなと言っているわけでもない。
まず技術研鑽はした方が良い。フレームワークもツールも、実際に使ってみないとわからないことはたくさんある。そういう意味で遊ぶのは大事だ。
僕は昔、フォームに入力すると当時の会社の経費精算の様式に合わせて経費精算の書類Excelを作る、というアプリを作ったことがある。Excelに直接入力した方が早いためなんの役にも立たない自覚があったので社内には広めなかった。それが案外PythonでExcelファイルをはき出す自動化の機会が多くてなんだかんだそのとき調べたことが役に立った。
次に課題解決の場合だ。本当に解決しなければならない課題があるとき、まずはコードを書かずに実現する方法を考える。
その結果、コードを書かなければならないという結論になることもあるだろう。その時に心すべきなのは、中途半端なものを作ってはいけないということだ。言い換えれば、すぐに終わらないと思えということである。
課題を正確に特定して、実際に使われ役に立つものを作るのは簡単ではない。難しい課題であればあるほどコードを書くまでの期間が長くなるはずだ。
中途半端に作ると、そこまで便利でもないくせにメンテナンスコストが発生する。バージョンアップ、クラウドサービス側の提供やメンテナンス終了などといったインフラ面や、なぜか機能追加の依頼が唐突にきたりする。
私見だが、中途半端に作るくらいならその業務をなくせないかを議論した方がいい。実は誰も求めていないかもしれない。また、なくせないかと提案すると業務を考え直すきっかけになったりする。
いま話題のPlatform Engineeringはたぶんそういう話をしていると思う。知らんけど。
終わりに
まずはコードを書かないで考える。コードを書く前に、コードを書く上で障害となっているものを全て取り除く。もしくはコードを書かずに済む代替案を探す。
この原則が僕を何度も救ってきたし、逆にこの原則を破った時は十中八九、手痛い失敗を経験した。
あと、個人的にはコードを書いて解決するエンジニアよりコードを書かないで解決するエンジニアのほうがかっこいいと思う。なので僕はかっこいいエンジニアを目指したい。
よろしければサポートをお願いします。