去年ですがmediumで話題になっていた記事にHype(誇大宣伝) Driven Development(HDD)というものがあります。
国内でもこれで失敗している例をよくみかけますし、とても共感したので紹介できればと思います。
翻訳ではなく、自分なりに噛み砕いて個人的な考えなども入れています。
概要
HDDとは一言でいえば、技術選定という重要なプロセスを他人任せにしてはならないという啓蒙です。
誰かが良いと言っているという理由で技術選定をしてはいけません。
例えば以下を理由に技術選定するのは Hype Driven Development(HDD)です。
・すごく偉い人がおすすめしていた
・カンファレンスですばらしい技術だと紹介されていた
・新しい技術だ
・人気が急上昇している
・超有名企業のA社が導入した
その技術は自分たちのどんな問題を解決してくれるのか。
開発の規模に、自分たちのスキルに、プロジェクトの特性にあっているのか。
そういったことを自分たちで考え、使う技術を決定しなくてはなりません。
Hype Driven Development の具体例
記事では下記をHDDの例としてとりあげています。
これらを使うことが即HDDというわけではありません。
HDDによって技術選定されがちな技術だということです。
フロントエンドフレームワーク(React.js/Angular/Vue etc.)
これらはSPAを作るための素晴らしいフレームワークであることは確かです。しかし、これらを適用する必要があるほど自分たちが作ろうとしているものが複雑なのかは判断する必要があります。導入によって発生する学習コストやワークフローの構築コストに見合うだけのメリットが本当にあるでしょうか。
関連するものとして、最近ではjQueryを排除しようとする流れが強くなってきていますが、シンプルなアプリケーションではjQueryで十分なはずで、学習コストや情報量の観点からもjQueryは今後もひとつのオプションとしてあり続けるはずです。
TDD is dead by DHH
Ruby on Railsの開発者として有名な DHH が TDD is dead とブログ記事に書きました。
これをうけてTDDを止めようというのならHDDです。
これまでTDDをしていて、たしかに恩恵を受けていたなら止める理由はないはずです。
マイクロサービス
Netflixが採用したことで人気が急上昇している技術のひとつです。しかし、マイクロサービスが有効に機能するプロジェクトは限られています。
個人的には相当に規模が大きいソフトウェアとチームでなければメリットがデメリットを上回ることはないと考えています。
設計の難しさや、失敗した場合の後戻りの難しさも考えるとかなり慎重に選択すべき技術です。
国内でも何度か失敗したという事例を見聞きしました。
NoSQL
いまでは多くの企業がNoSQLを有効に利用していますが、大量に選択肢があるがゆえにいまだに誤ってNoSQLを導入してしまう事例はあるかと思います。
NoSQLの多くはスケーラビリティやハイパフォーマンスが売りです。でも自分たちのプロジェクトに本当にそれは必要でしょうか。そしてそのNoSQLプロダクトを選択することで何を捨てることになるのか理解できているでしょうか。
特に、キャッシュや一時的なデータストアとして使うのではなく、RDBの置き換えとしてNoSQLを選択する場合は多くの試練が待っています。
Etc.
元記事にはElixir、Phoenixも例として記載されています。あと個人的にはServerlessもここに含めたい技術の一つです。有効なケースはかなり限られるわりに過大に宣伝・適用されているように感じます。
HDDにしないために
ブログからではなく経験から学べ
記事では技術を決定する前に、数日かけてプロトタイプを作ったりハッカソンをして実際に技術を試すことを推奨しています。
たしかにこれは良い方法だと思います。ただ、どれだけ時間をかけるべきかは内容によって変わると考えています。
例えばちょっとしたライブラリの選定などであればそれで十分かもしれませんが、フレームワークやインフラの基盤となるようなツール(仮想化ソフトウェアなど)はもっと長い時間をかけるべきだと思います。
また本番に採用する場合であっても、できればリスクが少ないプロジェクトから徐々に適用するのが理想的です。
元記事にはない話。捨てるものと規模。
HDDをしてしまう人たちが特に見過ごしがちだと思うのは「捨てるもの」と「規模」です。
捨てるもの
得られるものばかり考えてしまい、自分たちがその技術を使うことによって何を捨てているのかを理解しないまま技術を決定しているように感じます。
NoSQLにすればRDBの堅牢性や培ってきたノウハウを失います。マイクロサービスにすればWebAPIのコールが増えパフォーマンスが劣化します。それぞれ捨てているものはもっとあるでしょう。
規模
マイクロサービスやサーバーレスはどんな規模のソフトウェアでもメリットがデメリットを上回るでしょうか？マイクロサービスを小規模なソフトウェアに使えばパフォーマンスと開発速度を落としデプロイフローを複雑化するだけです。
サーバーレスを大規模な開発に適用すればソフトウェアの可読性を落とし、デバッグはかなり難しくなるでしょう。
何を捨てているのか、その技術が適用できる規模なのか、慎重に考えて技術選定すべきだと思います。
#補足
元記事にはもうちょっと色々書かれていますので、お時間があれば見てみてください。
選定のときに何を考えるべきかも書かれています("When to go?")が、いまいち賛同できない部分もあるのでここには書きません。
ちょいちょい見聞きする技術・アーキテクチャ選定に関する失敗の多くがHDD的な失敗であると感じます。
得られるものと捨てるもの、自分たちが本当に欲しいものを見極め正しく技術選定できるようにしなければなりません。