ある程度大きな会社で開発をしているエンジニアであれば、始業から終業までコードを書くことだけが仕事で、顧客と話したことなどない人も少なくないでしょう。そういう人にとっては、そのコードに「いくらの価値があるか」関心がないのが当たり前です。それよりもエッジファンクションの使いみちとか、CSSのスタイルが競合しない方法とか、ペアプログラミングのほうがずっと興味があるものです。ところがさあ自分でコードを書いて、それを製品として売ることを商売にしようと考えたとすると、ちょっと考え方のシフトが必要になるかもしれません。

変わらない仕様はない

会社に雇われてコードを書くのであれば、メールアドレスはやっぱり100文字必要だからデータベースの構成を変えてくれといわれたとき、50文字で十分だといったチームリーダーを非難する権利がプログラマーにはあります。でも自分で事業を立ち上げて、新しいサービスを提供するとなるとそんなことはいってられません。仕様は毎日変わります。というか仕様を決めているのはプログラマーであるわたしなので、わたし自身が勇気を持って変えないといけないです。

画期的だと思って実装した3Dダッシュボード機能も、いざリリースしてみたら誰にも使ってもらえない。顧客からはボタンの文字が気に入らないから買わないといわれる。そんなのは日常です。場合によってはピボットといって、想定する利用者やコンセプトを変えないといけないこともあります。ターゲットが変われば機能も見せ方もぜんぜん違います。なので不確実な要素の多い立ち上げ初期においては、ある程度の変化を見越して機能の設計を行う必要があります。コードを10万行書いたあとでやっぱりRubyじゃなくてRustにしたい（ここまで売上はゼロ）とかは負担が大きすぎるので、基幹となる技術の選定も重要です。もちろん、どうせあとで変わるのだから適当に決めれば良いやというわけではなくて、その時その時は常にこれがベストだと確信を持って、仕様やアーキテクチャを決めています。クローバ PAGEでも、最初はフォームに表示されるボタンの文言は固定で、そこには強いこだわりがありましたが、今はユーザーが変更できるようになっています。これはある意味、開発者の敗北かもしれませんが、そんなことにこだわって使ってもらえないのは本末転倒なので、ある程度は割り切るようにしています（声の大きい顧客の意見を聞くわけではありません）。たいてい、ユーザーはこちらがこう使って欲しいと思うようには使ってくれません。それは設計が間違っているのかもしれないし、ユーザーへの伝え方が不十分なこともあるでしょう。明らかに顧客が不満を感じているものを、プログラマーの自己満足でそのままにするわけにはいきません。つまり変化に強いとは、アーキテクチャーや設計の話だけでなく、開発者のマインドの問題でもあります。

機能は作らないほどいい

サービスを開始して間もないころは、機能が不足しているので、顧客からやれあれはできないのかとか、よそはあんなこともできるぞとかいわれて、ついつい言われるがままに新しい機能を搭載したい誘惑にかられることが多いと思います。でもちょっと立ち止まって思い出してみてください。一度作ったものは、機能を廃止するかサービスが終わるまでメンテし続けないといけないのです。特にこれはこのブログで想定しているような、ひとりや小さいチームで開発する人にとって大事なことです。大きい会社の開発部門であれば、専任のメンテナンス担当チームがあってリリースした製品は彼らにお任せできるかもしれませんが、我々はそうではありません。しかも時間は有限です。あなたが作って世に放ったものは、多かれ少なかれなんらかの富をもたらしてくれるでしょうが、同時にあなたにはそれをおもりする義務が生じます。機能を追加するたびに考慮すべき条件とサーバーの台数が増え、テストに要する時間は膨れ上がり、その機能を実現するために興味本位で手を出したフレームワークやライブラリはアップデートするたびに動かなくなります。顧客が本当に気に入ってそれを使い続けてくれるのであれば、機能は少なければ少ないほどよいです。特にモバイルアプリは変化が激しく、iOSなど古いSDKではビルドすらできないので、手を出すならよほど覚悟を持って取り組む必要があります。以前iOSの開発言語であるSwiftのバージョンが３になったときは、変更が大きすぎて対応の時間が取れず、人を雇わないといけないほどでした。Swiftのバージョンが上がったところでユーザーには何の価値もありません。他人のプラットフォームで商売をするとはそういうことです。

あらゆることに意味はあるらしい

プログラマーは無駄なことが嫌いなので、建前上の機能を実装するのを嫌がります。たとえば他社サービスとの機能比較表にマルをつけることだけが目的のような仕事はしたくありません。この機能が「ある」からなんだというのでしょう。テレビに空気清浄機能があったとしても、そんなものは実際は誰も欲しがっていない。MacBook Proのタッチバーみたいなものだ。そのとおりです。ではデータベースストレージの暗号化についてはどうでしょうか。ユーザーとサービスとのネットワークはSSLで暗号化されるのが当たり前として、データベースを暗号化したところで、アプリケーションからは当然復号できますから、効果があるとしたら、データベースサーバーに物理的に侵入して、ディスクを盗み出されたようなケースです。でもそんなハッカーならKMSの鍵くらいは盗み出せる気がします。しかもAWSのデータセンターに侵入できるのですからそれはもはやハッカーというより組織的な強盗でしょう。そんなケースに備えるためにデータベースの性能を10%劣化させるのは合理的でないと思うかもしれません。わたしは合理的でないと思います。ストレージを暗号化していようがしていまいが、アプリケーションサーバーに侵入された時点で、データベースのデータは盗み出されたとみるのが妥当だからです。

ところが企業向け、いわゆるBtoBの商売をしているとそうも言えなくなります。今はどこの企業にもセキュリティ規定があり、利用するサービスもその要件を満たすことが求められるからです。
例えば経済産業省の「クラウドサービス利用のための情報セキュリティマネジメントガイドライン」にはこうあります。

「利用する情報がシステム上で暗号化されている」とはどのような状態を指すのかいまいち明確でないですが、企業によってはデータはすべて暗号化されているべしと捉えるところが少なくないでしょう。その場合、データベースストレージが暗号化されていないならお前のとこのは使わんぞとなります。技術的に有効かどうかではなく、「ある」か「ない」かで判断される世界もあるということです。

「わかりやすさ」がすべてに優先する

食事のデリバリーサービスを使っていて、いきなり「デフォルトコンテキストを入力してください」とか表示されたらどう思うでしょうか。プログラマーにとっては注文の初期状態のことをそう呼んでいるので違和感がないかもしれませんが、多くの利用者はそこでアプリを閉じてしまうでしょう。わたしたちの作るサービスには知名度も権威もありません。こんないいものですよ、ぜひ使ってくださいといくら宣伝したところで、ユーザーが「わかりにくい」「難しい」と感じてしまったらそこでもうおしまいなのです。とにかく触ってもらえなければ、あなたの書いたコードの価値はゼロです。コンピューターのことをよく知っていたとしても、ひけらかすのはやめましょう。美しいコードと同じくらい、美しいボタンを用意しましょう。使い始めるまでにもう１クリック減らせないか考えましょう。たくさんのことができなくてもいいので、設定画面を極限までシンプルにしましょう。

創業者のクソコードには理由がある

そんなわけで、サービスがある程度大きくなってくると、創業者の書いた初期のコードはクソコードと呼ばれて新参のプログラマーから忌み嫌われます。不具合が多い、化石化した技術、つぎはぎだらけのコード、意味不明な仕様などがその理由です。でもそれはよく見れば立ち上げ当初の試行錯誤の証であったり、新しい技術へのチャレンジであったり、時間や予算とのトレードオフだったりします。最初の大型案件を取るために無理やり入れた機能もあるかもしれません。安易にとった解決策は必ず技術的な負債となります。時には負債ができるのを覚悟でその道を選ぶこともあるでしょうが、短期的にそれでしのげたとしても、長い間サービスを続けていくには、どこかでその負債を返す必要があります。できればそのコードが立派に動いていて事業に利益をもたらしているうちに少しずつやってしまいましょう。どうやって技術的負債を返していくかについては、また機会があれば書いてみたいと思います。