パラダイムシフトとエンジニアリング
Cloud FirestoreについてTwitterで盛り上がりを見せていたので、久しぶりに記事を書くことにしました。
2022年GWの真っ只中に開発しまくる。Stamp Incの村本です。
Twitterの中ではどうも、ガラケー vs スマホのような構図に見えてしまったので、古い技術 vs 新しい技術という構図で記事を書いていこうと思います。
話の本筋に入る前に先に述べておきたいことがあります。技術は誰のためのモノかについてです。
1. パラダイムシフトと技術
技術は誰のためのモノか？
ITの世界では日々新しい技術が生まれ、新しい技術を使ってたくさんのサービスが生み出されています。
ではこの技術は一体誰のためのものでしょうか？
- 技術を生み出したベンダーのため
- 技術を使う開発者のため
- 技術を使うユーザーのため
僕はこの答えに、ユーザーのためと答えます。実際は巡り巡って三者全てのためになっていますが、どんな技術も利用されて初めて意味を成すと考えています。つまり技術者が独りよがりで生み出した技術には大した価値はないでしょう。
まずこの技術がユーザーのためであることを認識した上で、古い技術と新しい技術について考えてみようと思います。
古い技術とは? 新しい技術とは？
いきなりですが古い技術 新しい技術を定義することは不可能です。残念ながらそれを識別する定義もありません。この記事においての古い新しいはパラダイムという言葉を使って説明できればと思っています。
ここでは古いパラダイムに沿ったものを古い技術、新しいパラダイムに沿ったものを新しい技術と呼ばせてください。面白いことにパラダイムに沿うと古い技術と新しい技術の差がなんとなく見えてきます。
パラダイムシフト
古いパラダイムから新しいパラダイムに移ることをパラダイムシフトと呼びます。
幸運なことにインターネットが普及し始めてた1990年代以降、私たちの身の回りはあらゆる分野でパラダイムシフトに満ちていました。ガラケーがスマホになり、通貨は暗号になり、運転席のない車が登場したり、通信は3G、4G、5G進化しています。
パラダイムシフトはどのように起こるのか？
パラダイムシフトがどのように起こるのか考えてみましょう。
近年起こったパラダイムシフトを見てると、私たちにとっていいことばかりなので自然に起こっていってほしいものですが、残念ながらパラダイムシフトは自然発生しません。パラダイムシフトの裏には必ず多くの時間と人々の努力があります。パラダイムシフトと近い言葉にブレイクスルーと呼ばれる言葉があります。
ブレイクスルーはしばしば、パラダイムシフトを発生させます。ではそのブレイクスルーを発生させる要因はなんでしょうか？なぜ私たちはブレイクスルーに挑みたいのでしょうか？答えは簡単です。この答えこそが前述した技術は誰のためのモノか？ と等しいと思います。
ユーザーが求める限り技術は発展し、ブレイクスルーによってパラダイムシフトを起こします。
2. パラダイムシフトによって変化したサービス開発
IT革命といわれた2000年代
国内のIT企業のほとんどは2000年代初頭あたりに集中しています。
| 会社 | 創業 |
|---|---|
| 株式会社ライブドア | 1995年 |
| ヤフー株式会社 | 1996年 |
| クックパッド株式会社 | 1997年 |
| 株式会社サイバーエージェント | 1998年 |
| LINE株式会社 | 2000年 |
| 株式会社ミクシィ | 2004年 |
| グリー株式会社 | 2004年 |
日本のITをリードして今の日本とIT時代を築いて本当にありがとうございます。
IT革命以降のパラダイムシフト
2000年代と今ではどんなパラダイムシフトが起こったか少し例を挙げようと思います。
- PCからMobileへ
- プロセッサーの高速化
- 無線通信の高速化、無線通信エリアの拡大
- インターネットユーザーの増加
- 利用時間の増加
- 競合相手は世界
- サービスの増加
「何から何へ」という言い方では表しきれませんでしたご了承ください。
パラダイムシフトに裏に隠れているブレイクスルーを少し想像してみてください。
PCからMobileへを生み出したのは間違いなくAppleのiPhoneです。無線技術の発展には世界にも劣らないNTT、KDDIの研究があったからこそです。インターネットユーザーの増加は、サービスのインフラに大きな問題をもたらしました。特にデータベースはその代表です。インフラはスケールアップではなくスケールアウトを求められるようになりました。これも一つのパラダイムシフトですね。
当時と今ではユーザーが求めることも大きく違いますし、開発の要件も異なることが想像できると思います。
余談ですが、当時流行った言葉にLAMP（Linux/Apache/MySQL/PHP）があります。時代を感じます。
大きく変化したサービス開発
サービス開発は、昔と比べ大きく変化しました。エンジニアの方であればリーン開発という言葉を聞いたことがあるはずです。
リーン（lean）とは、「痩せた」「脂肪のない」といった意味があります。1980年代にアメリカ・マサチューセッツ工科大学で研究されたトヨタ生産方式をもとに、「リーン生産方式」もしくは「リーン開発」として提唱されました。
ビジネスはエンジニアリングにリーン開発を求めました。理由は簡単で、リスクヘッジができるからです。新規ビジネスには不確実性が多く存在します。その不確実性を取り除かないまま、大きなコストをかけることは賢明ではないですね。
リーン開発は、アジャイル開発を生み出しました。アジャイル開発は、リーン開発における不確実性を少しづつ解消しながら開発を進める方法です。不確実性に対して仮説を立て、仮説を絶え間なく検証していきます。仮説が間違っていれば要件が変わることもあります。
MVP
MVP（Minimum Viable Product） という言葉も聞いたことがあるでしょう。
MVPに少しづつ機能を追加していくことで不確実性を取り除き、ビジネスの成功率を上げることができます。
ユーザーの要求水準
MVPやアジャイル開発については多くの記事でも書かれてることですが、まさに今サービス開発は新しいパラダイムが誕生しています。MAP（Minimum Awesome Product） を紹介します。
簡単にいうと、ユーザーがちゃんと利用してくれるMVPと言えるかもしれません。ユーザーのプロダクトへの要求水準は年を追って高いものになっています。サービス提供者はそれに応える品質が求められています。
前述が長くなりましたが、パラダイムシフトとサービス開発とデータベースにはどのような関係があるのでしょうか。
3. 古い技術ではなく、新しい技術を使う理由
ここで、一度話を整理します。
- 技術はユーザーのためにあり
- サービス開発は不確定要素が多い
- サービス開発の要件は変わりやすい
- ユーザーは新サービスであっても高い水準を求めている
スキーマレスが生まれた背景
スキーマが存在する理由はおそらく、ストレージの効率的な利用とQueryの高速化でしょう。レコードサイズを規定することで得られる多くのメリットが得られます。そのメリットを捨ててまでスキーマレスが存在する理由は何でしょうか？
スキーマレスが生まれた理由はサービス開発の要件に合わせて容易にデータを容易に変更できることです。プロセッサが高速化したこと、ストレージが大容量化したこと、HDDからSSDが登場したことなどから先のメリットが薄まり、スキーマレスである方がデータベースに求められるようになりました。スキーマレスなんてバグの原因と思うかもしれませんが、そんなことはありません。スキーマレスデータベースのほとんどがスキーマのバリデーション機能を提供しています。
ネスト構造が生まれた背景
データベースはデータ数が増えればどんなデータベースであっても性能劣化します。これを避ける方法はありません。しかし、性能劣化を防ぐ方法は存在します。データベースを分散化することです。
100冊入った本棚から一人で一つの本を探すのと、10冊入った本棚から10人で一つの本を探すのでは後者の方が早いですよね。
Twitterのフォロー機能を例に挙げます。
Twitterのフォロー機能をRDBで設計にはUserIDをN:Nで関連づけるテーブルを想像する人が多いと思います。こうするとユーザーが増加して、フォローワーが増加するとテーブルには全てのユーザーの全てのフォロー情報を含むことになり見事に劣化します。
ネスト構造を持つデータベースでは次のような構造にデータを格納します。
/users/:user_a/followers/:user_b
/users/:user_b/followees/:user_a
ユーザーごとにフォロー情報が分散されシステム全体の性能劣化を防ぐことが可能です。それでも数億フォロワーを持つユーザーは劣化します。ただし劣化は大幅に低減されています。
ネスト構造が生まれた理由はデータベースを容易に分散させたいからです。
NoSQLが生まれた背景
NoSQLと言ってますが、実際はほとんどのデータベースにもSQLは存在します。ここでのNoSQLはリレーショナルデータベースではないと考えてください。
旧来のRDBはユーザー増加に伴い性能が劣化し、それを解決するための分散化も容易ではありませんでした。
そこに登場したのがNoSQLです。旧来のRDBはACID特性を忠実に追い求めるように設計されていることが原因です。NoSQLではACID特性の一部を犠牲にしてスケーラビリティ可能なDBになるよう設計されました。
まさにパラダイムシフトです。
新しい技術を使う意味
昨今のIT技術の進歩の速さでは、新しい技術に対応するのも大変ですし、その背景に隠れている事情を全て理解するのは難しいと思います。しかし、新しい技術が登場するのには必ず理由があります。僕は盲目的に新しい技術を触れること強く賛成します。「車に乗り前に、馬車に乗れと」言われても全く納得いかないですよね？
逆に古い技術を基礎として教えてるスクールなどには猛烈に反対しています。例えばHTML CSSをWebの基礎として教えてるようなところですね。基礎に見えがちですが実際は馬車です。
技術はユーザーのためにあります。 利用シーンから考えて、ユーザー目線で技術に触れる順番を決定していくのがいいのではと思います。
🥹バッジ待ってます🥹
サービスの開発/設計をサポートする技術顧問をやっています。
お困りごとがあればぜひ、ご連絡頂けますと幸いです。
拝読ありがとうございました！！
こちらの記事もおすすめです！
Discussion