退屈な技術を選ぶことについて

2020/12/11 07:17

Panelbear
Webサイトのグロースに欠かせない強力でプライバシーに優しい分析ツール「Panelbear」を提供
この記事は、著者の許可を得て配信しています。
https://panelbear.com/blog/boring-tech/

注:この記事で書かれている考え方は、過去に何度も取り上げられています。長年にわたって私の視点に大きな影響を与えてきた記事の一つに、McKinley氏の「Choose Boring Technology(退屈な技術を選ぶ)」というものがあります。以下では、私自身の経験からこのトピックを探り、最近のプロジェクトでKubernetesを使うことになった経緯を紹介します。

長年にわたり、私は多くのエンジニアが会社の成功や失敗の多くを技術的な選択が原因であると主張する傾向があるところを見てきました。私にももちろんそういう時もあります。それはしばしば正当化されますが、大多数のスタートアップ企業にとって、プログラミング言語、フレームワーク、あるいはデータベースの選択はそれほど重要ではないと私は考えています。これは特に初期の段階ではそうだと思います。

エンジニアという色眼鏡を通して見てみると

私たちエンジニアが特定の色眼鏡を通して世界を見る傾向があるというのは、とても納得がいく話です。エンジニアは自分たちが一番よく知っていることに偏っていることが多いからです。私たちの日々の活動には、CI パイプラインのデバッグ、新機能の実装、同僚とのチーム作業、常に存在するレガシーコードベースの移行などが含まれます。私たちを取り巻く環境は、私たちが目で見て理解していることにすべてが集約されていると簡単に信じてしまいます。それは、製品を作ったり壊したりするものを自分たちが完全にコントロールしているように感じさせる錯覚です。

誤解しないでくださいね。多くの企業にとって、競合他社の3倍の効率性を実現したり、エレガントで構成可能なコードを持ったりすることは大きな利点になり得ます。しかし、あなたが実際に作っている製品に誰も関心を示さない場合、あなたは間違った問題に焦点を当てているかもしれませんし、遅かれ早かれあなたのビジネスはこの壁にぶつかるでしょう。

ソフトウェアが重要でないと言っているわけではありません。スタートアップ企業のための強固な基盤は、これからの長い道のりの基礎となります。そこに投資することで、競合他社よりも優れた機能をより早く構築できるのであれば、より大きな力を発揮することができます。しかし、正しいバランスを見つけるかどうかは、何を解決しようとしているのかや、また手元にあるリソースによって大きく変わります。正しい方法や間違った方法はありませんし、いつものように、主にトレードオフの問題になります。

退屈なことには、驚きはない

技術的な選択をする際には、リスクとリターンの健全なバランスを目指すことが大切だと思います。そうすることによって、将来的に間違った問題で行き詰まる可能性を減らすことができるのであれば、そうしたいものですよね。

「退屈である」というのは、「新しい技術よりも古い技術を選ぶ」と解釈されることが多いですが、必ずしもそうとは限りません。私にとって「退屈である」ということは、失敗する可能性のある方法がほとんど知られていて、実証済みの技術を採用することを意味します。しかし、時折、目の前で起こっている問題に適した別の、より新しく、可能性のあるツールを使って実験することでもあります。

最新のフレームワークやプログラミング言語を使って経験を積みたいという方もいると思いますし、何か楽しいことがしたいだけだという方もいるかもしれません。とにかくあなたが幸せになることをすればいいのです。しかし、自分の製品やビジネスが成功する確率を上げるための決断をしようとしているのであれば、一歩下がって冷静になって選択肢を検討する価値はあります。

私が、常に長く続いているソフトを選んでいるのは、つまらないとか古いとかではなく、失敗するやり方がよく分かっているからです。未知のことが少ない分、プロジェクトを実際に出荷する可能性を最大限に高めることができます。

例えば、先日 Django アプリに問題が発生しましたが、ささっと素早く検索すると、様々なフォーラムやウェブサイトでこの問題に対する回答が何十件も見つかりました。10分ほどかかりましたが、それでこの問題は解決しました。

私は数年前に、私のチームがしばらくの間使っていた人気のある、しかしあまり実績のないScalaライブラリで正反対のことを経験しました。おそらく私たちは、自分たちが直面していた問題に最初に遭遇した人たちであり、誰もこういった経験をしたことがないようでした。それは、わくわくして面白そうな課題のように聞こえるかもしれませんし、OSSに貢献する絶好のチャンスのように聞こえるかもしれませんが(私としては、これは喜ばしいことです)、一度解決したとしても、顧客は本当にそれを気にしているのでしょうか?あなたは、そのような課題に何日も、何週間も、何ヶ月も費やす気があるのでしょうか?私の場合は、その時間を新機能の出荷や既存機能の改善に充てたいと思っています。

活用と探索

私は、ツールの選択に関しては、80/20の配分に従うようにしています。つまり、私のスタックは約80%が私がよく知っているソフトウェアで構成されていますが、あえて残りの20%は私の知らない技術を使っています。それは探索するためです。ここで重要なのは正確な比率ではなく、実績のある技術をより積極的に使うべきだということです。

これはまた、多腕バンディットが機能する方法と同じです。時には、これから儲けるための金鉱をキープしつつ新しいものを探索している間、過去に上手く機能したものを利用して、得られる利益を最大化しようとします。

私の最近の例では、チャートのないシンプルなDjangoアプリの情けない例があります。すべてのメトリクスはプレーンな HTML テーブルにレンダリングされ、すべてのデータは SQLite データベースに保存されていました。5ドル/月のVMへの手動デプロイを含めて、文字通り週末を費やして稼働させました。その時の私のニーズにとって、ローリスクでハイリターンなものでした。

早速、機能を追加したのですが、様々なウェブサイトのページビューを扱うようになると、コードベースにリファクタリングが必要であることに気付き始めました。また、新しいインスタンスへのデプロイやSSL証明書の発行、インスタンスのIPアドレスが変わったときのためのDNSレコードの更新などの作業もどんどん繰り返しになってきました。

2回目のイテレーションとして、私はdocker-composeのセットアップとたくさんのグルーコードにアップグレードしました。しかし、すぐに他のツールがすでにうまくやっていることを新たに作成していることに気がつきました。それぞれの問題点を解決する方法は複数ありますが、私の場合は、フルタイムの仕事で慣れ親しんだツールを使うことにしました。そのツールがKubernetesです。

そうなんです。多くのプロジェクトに対してはやり過ぎであることは十分承知していますし、従来のソリューションでも良かったのですが、とてもうまく機能しています。すでに数年前から本番のワークロードをこれで実行してきました。むやみやたらに考えなく、私のやり方に従うことはやめてくださいね。あなたが最もよく知っていて、使い慣れているものを使ってください。

Kubernetesのおかげで運用面を驚くほどシンプルにすることができたし、何年にもわたって雇用主のために何度も本番環境での問題を解決してきた経験をしてきたので、問題をデバッグするのにも安心感があります。また、これは数年前から存在しており、多くのドキュメンもあり、困ったときに助けてくれる巨大なコミュニティもあります。自作のデプロイメントシステムやEC2/Lambda/DigitalOceanよりも多くのドキュメントがあります。

他のメリットとして、DigitalOceanからLinodeへの移行、そして最近ではAWSへの移行(それぞれの移行には、Terraformファイルの変更とデプロイに一晩かかっていました。本当です。)もとても簡単になったことも挙げられます。しかし、それはまた別の記事で書きますね。

複雑さは時間の経過とともにやってくる

私の場合、新しい技術を扱うよりも、以前のソリューションの方が苦痛が大きかったので、これらの技術に移行したのです。しかし、それ以上に重要なのは、私にとっては運用上のオーバーヘッドを削減しながら、顧客への機能の出荷をさらに迅速に行うことができたことです。

もし、初日からより高度なセットアップから始めていたら、Panelbear の最初のバージョンを手にする前に、すべてのモチベーションを失っていたかもしれません。重要なのは、いつか自分のものになると思っている潜在的な問題ではなく、目標との間に存在する問題を解決することです。

appstore
googleplay
会員登録
URLからPICKする

会員登録して、もっと便利に利用しよう

  • 1.

    記事をストックできる
    気になる記事をPickして、いつでも読み返すことができます。
  • 2.

    新着ニュースをカスタマイズできます
    好きなニュースフィードをフォローすると、新着ニュースが受け取れます。