私が尊敬するエンジニアの一人に、雷霄驊（Lei Xiaohua / 雷霄骅）さんがいます。
雷さんは映像・音声技術を専門に研究しながら、FFmpegを使った大量のサンプルコードと解説を公開した人物です。1990年生まれで、中国伝媒大学で放送テレビ工学、デジタルテレビ技術を学び、2014年からデジタル映像技術を研究する博士課程へ進みました。2016年7月17日、25歳で亡くなっています。
若くして高い技術力を持っていたことだけでも印象に残ります。しかし、私が雷さんを尊敬している理由は、肩書や受賞歴の多さだけではありません。自分が苦労して理解した難しい技術を、次に学ぶ人が使える形へ変えて残したこと。 ここに、雷さんの功績の本質があるように思います。
https://leixiaohua1020.github.io/
「FFmpeg開発者」という言葉だけでは伝わりにくい功績
雷さんを紹介するとき、「FFmpeg開発者」と表現されることがあります。ただし、この言葉からFFmpeg本体の中心的なメンテナやコア開発者を想像すると、少し違う理解になりやすいでしょう。
本人の公開サイトを見ると、活動の中心として並んでいるのは、FFmpegや映像・音声処理を理解するためのサンプルプロジェクトです。たとえば「Simplest FFmpeg」シリーズには、次のような実装があります。
- 動画・音声プレーヤー
- 動画・音声エンコーダー、デコーダー
- mux / demux / remux
- ストリーミング、メモリ上のデータ処理
libavfilter、libswscale、libavdevice- Android / iOS向けの例
- SDLやDirectShowなどを使った映像・音声処理
一つの完成された大きなアプリケーションを公開したのではなく、映像処理の各要素を小さな単位へ分解しています。本人も、自分のサイトでこれらを初心者の助けにするためのデモとして公開していました。
leixiaohua1020 - Overview
leixiaohua1020 has 30 repositories available. Follow their code on GitHub.
https://github.com/leixiaohua1020
GitHub - leixiaohua1020/simplest_ffmpeg_player: the simplest video player based on FFmpeg
the simplest video player based on FFmpeg. Contribute to leixiaohua1020/simplest_ffmpeg_player development by creating an account on GitHub.
https://github.com/leixiaohua1020/simplest_ffmpeg_player
FFmpegは非常に強力ですが、初めてソースコードやAPIへ入ると簡単なライブラリではありません。AVFormatContext、AVCodecContext、AVPacket、AVFrameといった構造体があり、コンテナ、コーデック、デコード、フレーム、出力処理の関係を理解する必要があります。現在と当時ではAPIも異なりますが、「どこから読めばよいのか分からない」という難しさは今でもあります。
その複雑な対象を、プレーヤーならプレーヤー、デコーダーならデコーダーという単位まで小さくして見せたことに大きな価値があります。
難しいものを「最小の理解可能な形」にする力
技術に詳しくなることと、その技術を他人へ説明できることは別の能力です。さらに、説明できることと、学習に適した最小実装を作れることの間にも距離があります。
複雑なライブラリのコードをそのまま示せば情報量は増えますが、初心者にとって必要なのは、最初からすべての機能を見ることではありません。たとえば「動画を1枚デコードするには何が必要なのか」「コンテナから映像ストリームを取り出す処理はどこなのか」「SDLへ渡すまでに何が起きているのか」といった、一つの疑問へ対応する範囲までコードを削る必要があります。
削りすぎれば実際の仕組みが分からなくなり、残しすぎれば教材として読めません。必要なものを残し、不要なものを外し、それでも本質が壊れない形へ整理するには、その対象をかなり深く理解している必要があります。
「Simplest」という名前は控えめですが、私はこの名前に雷さんの技術力がよく表れていると思います。
研究・実装・文章化を同時に続けていた
雷さんは大学で映像・音声技術を研究していました。本人のプロフィールでは、学部で放送テレビ工学、修士でデジタルテレビ技術、博士課程でデジタル映像技術を専攻したことが確認できます。
当時の報道では、国際会議での論文発表や学術交流に取り組む一方、2014年と2015年にCSDNの「ブログ之星」に選ばれ、2015年にはMicrosoft MVPにも選出されたとされています。技術ブログは450万アクセスを超えていたとも報じられています。
https://news.sciencenet.cn/htmlnews/2016/8/352939.shtm
ここで私がすごいと思うのは、単純な作業量だけではありません。研究で理解したことを実際にコードへ落とし込み、動く形にしたうえで、他人が理解できる文章へ変え、さらに公開物として残しています。
研究者として論文を書くこと、エンジニアとして実装すること、初心者向けの教材を書くことは、それぞれ違う技能を必要とします。雷さんの残したものを見ると、この三つが分離していません。調べたことを実装し、実装したことを説明し、説明したものを次の人が試せるコードとして残す。 その一連の流れによって、知識が循環する形になっています。
25歳という年齢を考えると、やはり簡単なことではない
雷さんは1990年生まれです。自分と同世代の人物だと知ったとき、私は自然に「同じ年齢のとき、自分に同じことができただろうか」と考えました。難しかったと思いますし、今から同じ規模のものを作ろうとしても簡単ではありません。
比較する対象を「25歳でFFmpegを使えたか」だけにすると、本当の難しさが見えにくくなります。同じような功績を残すには、一つの専門領域を深く学び、実際のコードを読み、自分でも実装できるようになったうえで、初心者がどこで止まるかを理解し、問題を小さな単位へ分解しなければなりません。さらに、それを動くサンプルと文章の両方で公開し、一度ではなく継続して積み上げる必要があります。
現在は、検索、GitHub、動画教材、生成AIなど、学習を助ける道具が当時より増えています。コードの雛形を作る速度だけなら大きく上がりました。しかし、何を残せば他人の理解が進むのかを判断する難しさは、それほど下がっていないように思います。
AIに「FFmpegのサンプルを作って」と依頼すればコードは出せます。しかし、どのコードが学習に必要で、どこが重要で、どの説明が誤解を生み、どのAPIが古く、どこまでを一つの教材として扱うべきかは、理解している人が判断しなければなりません。
私が最も尊敬しているのは「知識を公共財にしたこと」
技術を深く理解できれば、それだけでも大きな能力です。仕事で成果を出し、自分の専門性として使うこともできます。それでも雷さんは、自分が理解した内容を自分の中だけに置きませんでした。サンプルコードにして公開し、記事を書き、後から学ぶ人が同じ場所から始めなくて済むようにしています。
これはオープンソースの重要な価値の一つだと思います。オープンソースへの貢献というと、本体コードへのコミット数を想像しやすいものですが、エコシステムを支えるのはコード本体だけではありません。入門者が最初に動かせるサンプル、複雑な概念を整理した解説、最小再現コード、デバッグ方法、失敗した理由の記録、ソースコードを読むための道筋、古い資料と現在の仕様の違いを示す更新も、後から参加する人の学習コストを下げます。
一人が数日かけて整理した情報によって、その後の100人がそれぞれ数時間ずつ短縮できるなら、その価値は本人の作業時間を大きく超えます。雷さんが残したものは、まさにその種類の資産です。
真似したいのは過重な働き方ではなく、知識の残し方
雷さんの死については、家族が過労との関係を疑ったと報じられています。一方で、解剖が行われておらず、具体的な死因は確認できないと学校側が説明していました。そのため、「過労死だった」と断定することはできません。
ここは、尊敬する人物を語るときに分けて考えたいところです。大きな成果を残したからといって、長時間働くことや身体へ負担をかけることまで美化する必要はありません。私たちが真似できる、そして真似したいのはそこではなく、学び方と残し方です。
雷さんから学んで、私たちにできること
雷さんと同じ専門性や成果量を目指さなくても、この姿勢は日々の仕事へ取り入れられます。
自分が詰まった場所を記録する
技術記事の題材は、大きな発見である必要はありません。一時間調べても分からなかったエラー、公式ドキュメントだけでは理解しにくかった設定、ライブラリを更新したときの差分など、自分が時間を使った場所には、次の人も時間を使う可能性があります。
解決した瞬間に忘れるのではなく、発生条件、原因、確認したこと、解決方法を残しておけば、それだけで次の人にとって価値のある資料になります。
完成品だけでなく最小例を残す
実務のコードには、認証、ログ、エラー処理、UI、設定など多くの要素が混ざります。そのまま公開しても、何が本質なのか分かりにくいことがあります。
そこで一度、問題だけを再現する最小コードへ削ってみる。これは雷さんの「Simplest」シリーズから特に学べる部分です。最小例は教材としてだけでなく、質問、バグ報告、後から自分が理解し直す場面でも役立ちます。
「動いた」だけで終わらせず、なぜ動くかを書く
コマンドやコードだけを残しても、その時点では役立ちます。しかし、バージョンが変わると使えなくなることがあります。
なぜその設定が必要なのか、何を省略しているのか、どの条件で使えるのかまで書けば、サンプルコードそのものが古くなっても考え方は残ります。技術記事では「このコードで動いた」だけでなく、「なぜこの形なのか」まで説明することに意味があります。
一次情報へつなぐ
自分の記事だけで完結させず、公式ドキュメント、仕様、ソースコード、Issue、論文などへリンクすることも重要です。読者は必要に応じて、説明の根拠を確認したり、さらに深いところへ進んだりできます。
雷さん自身の公開サイトも、個々のプロジェクトへ直接たどれる索引として機能しています。自分の説明を入口にしつつ、一次情報へ戻れる道を残すことは、長く使われる技術資料に必要な要素だと思います。
自分より後に来る人の時間を減らす
この考え方は、公開記事だけでなく日々の仕事でも使えます。READMEを整える、セットアップ手順を書く、障害対応のRunbookを残す、レビューで繰り返し説明している内容をドキュメントにする、AIへ渡すプロジェクト固有のルールを整理するといった仕事です。
どれも派手な成果ではありません。しかし、一度整理したものが何度も再利用されれば、チーム全体では長く効き続けます。「自分が分かっているからよい」で終わらせず、自分より後に来る人の時間を減らすことも、エンジニアリングの一部です。
AI時代だからこそ「何を残すか」の価値が上がる
生成AIによって、文章やコードを作ること自体のコストは下がりました。だからこそ今後は、単純な情報量ではなく、その情報がどこまで確認されているかがより重要になると思います。
対象バージョンは何か、実際に動作確認したのか、何を省略したのか、どこからが推測なのか、どの一次情報を根拠にしたのか、最小例で再現できるのか。そして、その資料は誰が何を理解するためのものなのか。こうした情報がそろっていれば、読者は生成された大量の情報の中から、安心して出発点にできる資料を選べます。
大量に生成できる時代ほど、「初心者がここから始めればよい」と信頼できる小さな教材の価値は、むしろ高くなるはずです。雷さんが行っていたことは、現在の技術発信にもそのまま通じます。
到達点ではなく、姿勢なら受け継げる
雷さんと同じ年齢で同じ実績を残せなかったとしても、それを理由に自分の仕事を小さく見る必要はないと思っています。同じ専門分野、同じ環境、同じ人生ではありませんし、功績の量だけを比較しても、私たちが次に何をするかにはつながりません。
重要なのは、彼が残した行動の中から、自分でも続けられるものを見つけることです。今日理解したことを一つ記録する。複雑なコードを最小例へする。自分だけが知っている手順をREADMEへ書く。失敗した理由を隠さず残す。誰かの質問に、自分が分かる範囲で答える。一つひとつは小さくても、積み重なれば誰かが技術を理解するための道になります。
私が雷霄驊さんから最も学びたいのは、そこです。到達した肩書や成果の量以上に、「学んだものを自分の中だけで終わらせず、他人が使える形にして残す」姿勢が一番再現可能で、同時に一番価値のある部分ではないかと思います。
自分が知識を得たとき、その知識を自分だけのものにするのか。それとも、次の人が少し楽に進める形へ変えて残すのか。その選択は、今日からでもできます。
