SQLiteの生みの親リチャード・ヒップと語る Turso、AI、そして26年にわたるコードの物語 [YouTube]

 (youtube.com)
7 ポイント 投稿者 baeba 3 시간 전 | 4件のコメント | WhatsAppで共有

SQLiteの生みの親が明かす26年の成功の秘訣は、自分に必要なツールを自ら作り、外部からの貢献を最小限に抑え、徹底したテストによってコード品質を維持することにある。
それは、複雑なオープンソースのエコシステムで見過ごされがちな 「自由」の本質 を示している。

目次

  1. SQLiteの生みの親、リチャード・ヒップの26年にわたるコードの旅

1. SQLiteの生みの親、リチャード・ヒップの26年にわたるコードの旅

SQLiteの生みの親である リチャード・ヒップ(Richard Hipp) は、26年にわたるコード開発の旅を通じて、次のような哲学を実践してきた。

  • 自分に必要なツールは自分で開発する。
  • 外部からのコード貢献は最小限に抑える。
  • 徹底したテストによってコード品質を維持する。
  • 外部依存を減らし、開発の自由を確保する。

1.1. SQLiteの誕生：軍艦から始まった問題解決

軍艦プロジェクトから始まったSQLite

  • SQLiteは軍艦 USS Oscar Austin に関する契約業務から始まった。
  • 当時リチャード・ヒップはGeneral Dynamicsの契約技術者として、Bath Iron Worksの DDG-79 艦建造プロジェクト に参加していた。
  • 艦船のダメージコントロール情報システム開発で問題が発生した。
  • 別の会社が数百万ドルを投じていたが、満足のいく成果物を出せていなかった。

既存データベースシステムの限界

  • リチャード・ヒップはダメージコントロールシステムの問題を解決するため、高速なヒューリスティックベースのソフトウェアを開発した。
  • しかし、データ保存に使っていた Informix データベースエンジン が停止すると、ソフトウェアも一緒に動かなくなる問題があった。
  • システム管理者がデータベースエンジンを停止した状態でも、ソフトウェアは動き続ける必要があった。
  • そのため、別個のデータベースプロセスなしに、アプリケーションがディスク上のデータを直接読む方式を考えるようになった。
  • 当時はこの要件を満たすSQLデータベースエンジンを見つけるのが難しかったため、自ら開発する必要があった。

独学で始めたリレーショナルデータベース研究

  • 当時はインターネット検索が今ほど一般的ではなかった。
  • リチャード・ヒップは地元の大学図書館で関連資料を探し、リレーショナルデータベース技術を研究した。
  • 当時、MIT、ハーバード、バークレーなどではリレーショナルデータベース研究が活発に進んでいた。
  • しかし地理的な制約のため、最新の研究情報を容易には得られなかった。
  • 結局、必要なデータベース技術を自分で研究し、実装することになった。

1.2. SQLiteの成長と商業的成功

収益目的ではなく始まったプロジェクト

  • SQLiteは最初から収益化を目的に開発されたソフトウェアではなかった。
  • 初期バージョンはフリーソフトウェアとして公開された。
  • 開発当時、それで事業化したり収益を得たりする計画はなかった。

Motorolaとの最初の商用契約

  • SQLite公開から数年後、携帯電話メーカー Motorola から連絡を受けた。
  • MotorolaはSQLiteを自社の携帯電話に搭載したいと考えていた。
  • これをきっかけにSQLite初の商用契約が締結された。
  • 契約は利用量に応じたライセンス方式ではなく、固定価格方式で進められた。

AOLとの協業

  • その後 America Online(AOL) も、CD-ROMパッケージにSQLiteを含めるための契約を結んだ。
  • この契約も固定価格方式で行われた。
  • リチャード・ヒップは、当時の契約金額はSQLiteの価値に比べると比較的安かったと評価している。

Symbian OSによるSQLite採用

  • Nokiaなどの携帯電話で使われていた Symbian OS は、データベースエンジン選定のためにブラインドテストを実施した。
  • 合計10個のデータベースエンジンが評価対象に含まれていた。
  • テストの結果、SQLiteが最終的に選ばれた。
  • この過程で、SQLiteが1人の中核開発者に過度に依存しているという問題が提起された。
  • いわゆる バス係数(bus factor) を高めるため、コンソーシアムを組成するよう提案を受けた。

バス係数
プロジェクトの中核人材の何人かが突然業務を遂行できなくなったとき、そのプロジェクトを維持できるかを示す指標。
バス係数が1というのは、中核開発者が1人抜けるだけでプロジェクトの維持が難しくなり得ることを意味する。

コンソーシアム設立と専業開発

  • Mozillaの ミッチェル・ベイカー(Mitchell Baker) がコンソーシアム設立について助言した。
  • それをもとにSQLiteコンソーシアムが設立された。
  • コンソーシアム設立後、リチャード・ヒップはSQLite開発を専業で行うようになった。
  • 複数の社員を雇い、小規模ながら持続可能な開発組織を運営するようになった。

2050年までの長期サポート計画

  • 2010年、Airbusは A350航空機プロジェクト のアビオニクスにSQLiteを使いたいと考えていた。
  • AirbusはSQLiteが長期にわたって維持・サポートされるかを問い合わせた。
  • 航空機の機体寿命が約40年であることを考慮し、長期サポートを約束した。
  • この約束は法的義務というより、SQLiteプロジェクトが追求する長期的目標に近かった。
  • 現在リチャード・ヒップは、SQLiteに対する個人的なサポート終了目標を 2050年 に設定している。
  • これは、想定されるデータ寿命よりもコードを長く維持するという、いわば 「データ優先コード」にさらに50年を足す方式 で定めた目標だ。

1.3. ライセンス、オープンソース哲学、そして自前ツール開発

「祈り」ライセンスの誕生

  • SQLite バージョン1は GDBM ライブラリ に依存していた。
  • GDBMがGPLライセンスを採用していたため、SQLiteもGPLの影響を受けざるを得なかった。
  • その後、範囲クエリをサポートするため、B-treeベースの自前のストレージバックエンドを開発した。
  • 外部ライブラリ依存が取り除かれ、ライセンスを自由に選べるようになった。

パブリックドメインの選択

  • 当時広く知られていたライセンスはMITとBerkeleyライセンス程度だった。
  • リチャード・ヒップは、複雑な法的条項を含むライセンスを使う代わりに、SQLiteを パブリックドメイン(Public Domain) として公開した。
  • その後、パブリックドメインという概念がすべての国で同じように認められているわけではないと知った。
  • それでもSQLiteの公開方針は、結果としてオープンソースライセンスに近い形で受け入れられている。

「祈りの文言」

SQLiteのソースコードヘッダーには、一般的な法的文言の代わりに、祝福あるいは祈りに近い文言が含まれた。

May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.

SQLiteが世界で最も広く使われるソフトウェアライブラリの1つとなるにつれ、この文言もまたSQLiteの独特なライセンス哲学を象徴するものになった。

外部貢献を最小限に抑える開発方式

  • SQLiteは一般的なオープンソースプロジェクトのようにプルリクエストを積極的には受け入れていない。
  • 外部貢献を最小限に抑え、中核開発チームが自らコードを書き、管理する方式を維持している。
  • リチャード・ヒップはプルリクエストを 「無料の子犬(free puppy)」 にたとえる。
  • 子犬を無料でもらっても、その後に世話と管理の責任が発生するのと同じように、外部コードを受け入れると次のような長期的責任が伴うからだ。
    • コード保守
    • テスト
    • ドキュメント整備
    • バグ修正
    • 他プラットフォームとの互換性管理
    • 長期的な技術責任
  • 外部貢献を制限する方式は、SQLiteが26年以上にわたって一貫した品質と方向性を維持できた要因の1つである。

自前ツール開発の事例

Fossil
  • Fossil はSQLiteプロジェクトを管理するために作った自前のバージョン管理システムである。
  • Gitとほぼ同時期に開発された。
  • ソースコード管理だけでなく、次の機能を統合的に提供する。
    • バージョン管理
    • 課題追跡
    • Wiki
    • フォーラム
    • Webインターフェース
  • Fossil自体がSQLiteを基盤に作られている。
  • したがってFossilは、SQLiteの実質的なベータテストプラットフォームの役割も果たす。
  • Fossilを開発・運用する過程で、アプリケーション開発者の視点からSQLiteの問題点を発見し、改善できた。
  • リチャード・ヒップは、GitはLinuxカーネルのような大規模分散プロジェクトに適している一方、SQLiteのような小規模プロジェクトにはFossilの方が適していると評価している。
Lemon
  • Lemon はSQLiteのSQLパーサーを生成するために開発したツールである。
  • 既存のYaccやBisonを使う代わりに自作した。
  • 自前ツールであるため、SQLiteの要件に合わせてパーサー生成方式を自由に改善できた。

自前ツールと自由の哲学

  • リチャード・ヒップにとって、自前ツール開発は単なる技術的な好みではない。
  • 自分に必要なツールを自分で作ることは、自分自身の面倒を見る行為だと考えている。
  • 外部依存を減らせば、他のプロジェクトや企業の決定に左右されにくくなる。
  • その独立性こそが、開発者の自由を広げると判断している。
  • ただし、SQLiteが世界中の多くのシステムで中核依存として使われている現状については、負担や懸念も抱いている。

1.4. 徹底したテストとAI時代のソフトウェア開発

SQLite成功の核心であるテスト

  • SQLiteが長年にわたり安定性を維持できた核心要因の1つは、極めて徹底したテストである。
  • SQLite開発チームは、単に機能が動くかを確認するだけでなく、さまざまな例外状況やプラットフォームを検証する。
  • 実際の製品コードよりテストコードの量がはるかに多いほど、テストを重視している。

DO-178B標準の適用

  • SQLite開発チームは、航空機ソフトウェア開発標準である DO-178B の手法をテストに適用した。
  • これによりテストカバレッジを体系的に高めた。
  • Android開発初期段階でDO-178Bレベルのテストカバレッジを達成して以降、バグ報告がほとんどなくなるという結果を経験した。
  • この経験を通じて、徹底したテストが実際のソフトウェア安定性向上に直接影響することを確認した。

ファジングによる新たなバグ発見

  • その後 プロファイルベースド・ファジング(profile-guided fuzzing) 技術が登場した。
  • ファジングは、ランダムまたは変形したデータをプログラムに入力し、予期しないエラーを見つける手法である。
  • 既存のDO-178Cレベルのテストでも見つけにくい新しい種類のバグが、ファジングによって発見された。
  • これは、高いテストカバレッジだけではすべてのエラーを見つけられるわけではないことを示している。

AIが見つけるバグ

  • 最近では、AIを活用してバグを探索したり、バグレポートを書いたりする事例も現れている。
  • SQLiteプロジェクトにも、AIが生成したと疑われるバグ報告が届いたことがある。
  • AIは既存のテストやファジングを補完する、新たなソフトウェア検証ツールになる可能性がある。

AIに対するリチャード・ヒップの評価

  • リチャード・ヒップは、AIに対する考えが毎日変わり得ると語る。
  • 現在はAIを非常に有用なツールとして活用している。
  • ChatGPTにSQLiteコードについて質問した際、AIが自分に次のように答えた経験を紹介した。

「もちろんあなたもご存じでしょうが…」

  • 自分が書いたコードについて、AIがまるで自分以上に知っているかのように語る様子に、少しぞっとする感覚を覚えたと説明した。
  • AIは情報を探したり、アイデアを得たりするのに有用だ。
  • しかし常に正確とは限らず、非常に説得力のある表現で誤った情報を提示することがある。
  • AIが生成したコードは、あるOSでは動いても別のOSでは動かないなど、互換性の問題が生じることもあった。
  • したがって、AIが作った成果物も人間が直接レビューし、修正しなければならない。

若い開発者への助言

  • リチャード・ヒップは、SQLiteをフォークしてより良いデータベースを作ろうとする試みを歓迎している。
  • ただし、SQLiteと同じ水準に到達するには次の要素が必要だと強調する。
    • 25年以上にわたる継続的な開発
    • 1つのテーマへの執拗な献身
    • 長期間のテストと改善
    • ユーザー要件への継続的な観察
    • 失敗を繰り返しながら蓄積した経験
  • 優れたソフトウェアは短期間では作れない。
  • AIによってソフトウェア開発のあり方が大きく変わる可能性はあるが、未来がどのような姿になるかを容易に予測するのは難しいと評価している。

1.5. SQLiteの持続可能性と人間的な側面

26年間続けられた理由

  • リチャード・ヒップは、SQLiteの成功を自分の能力よりも 神の摂理と幸運 によって説明する。
  • 自分が特別に優れたプログラマーだとは思っていないと語る。
  • ただし、次のような性向がSQLiteの発展に役立ったと分析している。
    • 頑固に自分のやり方を貫く姿勢
    • 既存の通念に疑問を投げかける姿勢
    • 必要なツールを自分で作る習慣
    • 長期間にわたって1つの問題に集中する性向
    • 開発プロセスそのものを楽しむ姿勢
  • SQLiteを開発しながら、どうすればもっと良くできるかを絶えず考える過程そのものが重要だったと語る。

小さなチームの利点

  • リチャード・ヒップは、自分は多くの人と付き合ったり、組織内の政治的関係を管理したりするのが得意ではないと語る。
  • そうした性格のため、SQLite開発チームを小規模に保ってきた。
  • 結果として、小さなチーム構造がSQLiteの一貫した方向性と迅速な意思決定に役立ったと評価している。
  • Linuxのリーナス・トーバルズのように、多くの開発者との関係を調整する能力は自分にはないと認めている。

妻Gingerとの会社運営

  • リチャード・ヒップは、妻である Ginger とともに会社を運営している。
  • 2人は状況に応じて互いの役職を入れ替えるなど、柔軟なチームワークを維持している。
  • Gingerは音楽家であり、コンピュータの問題で困っている他の音楽家を助けるのが得意だ。
  • リチャード・ヒップは、地域社会ではGingerの方が自分より有名だと話している。

ソフトウェア開発の人間的側面

  • リチャード・ヒップは、ソフトウェアを単なるコードや技術の集合としてだけ見てはいない。
  • 開発者の感情、協業関係、執着、失敗、達成感といった人間的要素が、ソフトウェア開発では重要だと強調する。
  • ソフトウェアは複雑で抽象的な成果物だが、その裏側にはそれを作った人々の物語がある。

推薦書籍: 《The Soul of a New Machine》

  • リチャード・ヒップは、ソフトウェアとコンピュータ開発の人間的側面を理解できる本として 《The Soul of a New Machine》 を薦める。
  • この本は単にコンピュータ技術だけを説明するものではない。
  • 新しいコンピュータを開発する過程で現れる、次のような要素を扱う。
    • 開発者たちの情熱
    • 組織内部の葛藤
    • 技術的挑戦
    • 失敗と挫折
    • 協業と競争
    • 創造過程における感情
  • 複雑な技術を深く理解しつつ、それを人間的な物語として伝えられる能力が重要だと強調する。

結論

SQLiteが26年以上にわたって成功裏に維持されてきた理由は、単に優れた技術力だけではない。

中核となる成功要因は、次のように整理できる。

  1. 現実の問題を解決するために必要な技術を自ら開発した。
  2. 外部依存を減らし、プロジェクトのコントロールを維持した。
  3. 外部貢献より長期的な保守責任を重視した。
  4. FossilやLemonなど、自分に必要なツールを自分で作った。
  5. 航空ソフトウェア水準の徹底したテストを適用した。
  6. AIや新しい開発技術を活用しつつ、成果物を盲信しなかった。
  7. 小さなチームと人間的な関係を基盤にプロジェクトを運営した。
  8. 1つのテーマに長期間、執拗に没頭した。

SQLiteの事例が示す核心は、自由とは何の制約もない状態ではなく、自分が使うツールやコードについて自ら責任を持ち、コントロールできる状態だ という点にある。

外部依存を減らし、必要なツールを自分で作り、徹底的に検証するSQLiteの開発方式は、急速に変化するAI時代においても、持続可能なソフトウェア開発とは何かを示す重要な事例である。

関連記事

4件のコメント

 
regentag 1 시간 전

RTCAのDo-178は、実際に読んで適用してみることが可能なくらい短いガイドラインです。航空業界で広く適用されています。

https://studylib.net/doc/27132454/rtca-do-178b
 
hmmhmmhm 2 시간 전

「25年以上にわたる継続的な開発」、本当にすごいですね……
 
cnaa97 2 시간 전

すごいですね.. 映画みたいでもあります
 
toida 3 시간 전

考え方がすごく素敵ですね