Linux Foundation Japan | 2024年07月01日
本ブログは Insights and Lessons From a Linux Foundation Fellow: MyOpen Source Story, as Told by Mr. Yoshiya Eto の参考訳です。
注 : この記事は、The Linux Foundation FellowのMr.Yoshiya Etoとのメール インタビューに基づいています。以下の文中の「私」はMr.Etoの一人称です。物語はMr.Etoの大学生活から始まります。
大学時代、私の研究テーマは物体の画像を撮影し画像を認識することでした。今では人工知能と呼ばれる技術分野だと思います。この研究には膨大な計算能力が必要でしたが、当時は16ビットの80286プロセッサとCP/M-86オペレーティング システムしかありませんでした。私が卒業する頃には、研究室にMC68020ベースの32ビットUNIXマシンが導入されました。同時に、大学にもBSD4.2が走るVAX-11/382(382!!です)が設置されました。早速、学生や助手が集まって、夜な夜なコードを読み理解するワークショップが始まりました。これが私にとってBSD4.2カーネル コードを読む最初の機会であり、BSD ライセンスのオープンソース ソフトウェアに初めて触れた機会でした。その瞬間から、オペレーティング システムを理解することに興味を持つようになりました。
卒業後はFujitsuに就職しました。初めての仕事で、新たなOSをゼロから開発することができたことは、とても幸運でした。
私は15年間、このオペレーティング システムの開発とサポートを続けました。その間、私はいくつかのプロセッサ アーキテクチャを理解する機会があり、NetBSDをSPARCプロセッサ ベースのワークステーションに移植しました。当時、SPARCを搭載したワークステーションが身の回りにたくさんあり、懐かしのBSDを走らせてみたかったのです。さらに、特定のSPARCプロセッサをNetBSDでイネーブルするため、NetBSDメーリング リストに小さなパッチを送りました。これが、私が初めてオープンソース ソフトウェアに貢献した事です。そして、もちろん、そのパッチはすぐにメインラインのNetBSDカーネルに組み込まれました。
Fujitsuは2000年に基幹系システム向け次世代OSとしてLinuxを採用することと共に、Linuxの強化に必要なソフトウェアのIP(知的財産)を公開していくことを決断し公表しました。さらに、2001年、Fujitsu、IBM、Hitachi、NECの4社が連携し、エンタープライズシステム向けにLinux OSの機能強化を進めて行くことを発表しました（関連記事：https://pr.fujitsu.com/ja/news/2001/05/30-1.html ）。
私は、オペレーティング システムの開発・設計に特別な経験のあるエンジニアのチームを率いており、2002年には、このプロジェクトに深く関わり始めました。オペレーティング システム開発で十分な経験があり、チームには優秀なエンジニアがいたため、新しい機能開発はそれほど難しく無いだろうと考えていました。エンタープライズ/ミッション クリティカルなシステムに欠けている機能を明確に把握し、Linuxシステムで開発する必要があることを理解でき、比較的簡単に実装できると思っていました。しかし、Linuxコミュニティがいかに協力的であるか、新しい開発がどのように行われ、それがコミュニティ全体に広がっているかは理解していませんでしたし、理解するのに長い時間がかかりました。
このプロセスを通じて、私たち全員 (会社の役員から新入社員まで) が協力し、Linux Foundationとそのコミュニティについてより深く理解していったのです。
この期間中に次のことを達成できました。
- コミュニティとして機能開発を支援するためにOSDL/Linux Foundationを設立
- すべてのコミュニティの主要開発者が直接コミュニケーションできるイベントを開催・支援
- アップストリーム化のためにIBM/Intelのエンジニアたちと協力
これらの機会を活用するために、私のチームはこれらのテクノロジーについて英語でコミュニケーションする必要がありました。必要な機能を実装する上で、主要な開発者と効果的にコミュニケーションをとることが私たちにとって最も重要なことでした。
写真1：Mr.Etoの最大の功績は、2010年に稼働開始した東京証券取引所のシステム更改に取り組んだことです。メインフレーム ベースの取引システムからRed Hat Enterprise Linuxベースのシステムに変更しました。応答時間は1,000倍高速化（2秒から2ミリ秒へ）できました。2015年からは応答時間は、0.5ミリ秒まで更に高速化されました。
Linuxに関するもう1つの大きな議論は、すべてのコードをアップストリーム化するのか、社内で修正コードを維持するのかという点でした。GPLライセンスなので、ソースコードを公開するという意味では同じなのですが、ビジネスを考えた場合に大きな違いがあったからです。
歴史的にFujitsuは、巨大な UNIXサーバーを開発し、ライセンスされたSYSV UNIXコードを修正してそれらの大規模サーバーを動作させていました。この場合、修正はハードウェア出荷に合わせた開発のスケジュール管理が可能ですが、修正されたUNIXコード毎にISV認証を取得する必要がありました。一見楽そうな道ですが、ISV認証にはお金も時間も費やす必要があり、かつハードウェア出荷までに認証を取得できる保証はありません。
最終的にすべてのコードをアップストリームし、Red Hatと協力して新機能を含むグローバルスタンダードなLinuxオペレーティング システムを配布することにしました。
ちょうどこの頃Red Hat社は、製品をEnterprise Linuxに切り替えた直後で、私たちとビジネス・技術の協業を始めるのに絶好のタイミングだったのです。その後、私たちの技術・開発力を信頼の基盤とした協業が広がっていきました。
https://www.redhat.com/en/about/press-releases/press-jointdevelopment
https://www.redhat.com/en/about/press-releases/press-fujitsu-ecosystem
https://www.fujitsu.com/global/about/resources/news/press-releases/2008/1118-01.html
この方法により、ISV認証はグローバルなビジネスエコシステムの中で自動取得されるようになりましたが、コミュニティですべての機能を開発するには、依然として大きなコスト(時間と費用)が発生しました。
開発開始当時、我々のコードは全くと言ってよいほどアップストリームに取り入れてもらえなかった記憶があります。当時、コミュニティとはどういうところなのか、どういう議論がなされているのか、なぜ私のチームのコードが取り込まれないのかなど、私の上司への報告は、何時も言い訳ばかりに見えるレポートでした。2年ほど経って、私のチームは少量のコードがアップストリームできるようになりました。たった十行ほどの機能追加を取り込んでもらうのに2年もかかりました。辛抱強く待ってくれた当時の役員を始めとした上司の方々に、今でも感謝しています。
写真2：2006年、Mr.Etoのチームから初めてLinuxカーネル サミットにエンジニアが招待されました。チームが多くのコードをアップストリームできるようになってからは、より多くのエンジニアがこのイベントに参加できるようになりました。
この頃、従来のソフトウェア開発の状況報告方法が我々の開発進捗を上手に反映できていなかったため、開発成果を測定する新しい方法を確立する必要がありました。従来の報告方法を変更するためにいくつかの測定方法を試しましたが、どれも現在の状況を説明するだけで、どこに向かっているのかを説明するものではありませんでした。
2005年にLinusのソースコード管理システムがgitに移行しました。gitの機能を使ってシェルスクリプトで自分のアイデアを展開しようとしましたが、スクリプトが非常に複雑になってしまいました。gitの開発者は日本人で、日本でのグローバル イベントでいくつかのgitの機能の必要性について直接話をしました。いくつかの機能はgitに徐々に取り込まれ、スクリプトはのちに簡素化できました。その後、私のチームのマネージャーにスクリプトのメンテナンスを依頼しました。彼から、スクリプトと結果を公開しても良いか聞かれましたが、誰でも調査すれば分かるので公開しようと決めたのです。
いくつかのイベントで、誰かが私のWebサイトについて言及している声が聞こえ、彼の上司がチームにリストのトップ10に入れるようにと行ってきたという話を耳にしました。その会話を耳にして、思わず笑ってしまいました。このLinuxコミュニティの開発状況見える化は、下記サイトで公開されています。
https://www.remword.com/kps_result/
写真3：これは10年以上前のオープンソース イベントでの写真です。Mr.Etoは最前列の一番左で、とても嬉しそうにしています。
これらの挑戦を通じて私は多くのことを学びました。また、いくつかの人生の教訓も得ました。
- 常に完璧を求めてはいけない
- 時には「完璧であること」よりも「なしとげられたこと」の方が大切である
- コミュニケーションにおける「誤解」を許容する
- 私たちの生活の一部は誤解によって作られ、何かを完璧に理解していた場合よりも良い結果になることがある
- 時には誤解がより良い仕事関係を生み出す
- 開発要件の矛盾がイノベーションを生み出す
- コミュニティでは、異なる目標に取り組む開発者が共同実装について話し合うことができる
- コミュニケーションは対立を解決する唯一の方法ですが、誤解は常に残ります
- 経験不足により挑戦は失敗することがありますが、失敗を恐れてはならず、失敗こそが学びの方法です
『徒然草』は1300年代に書かれた随筆集です。第150段では、新しい能力を得るためにどのように挑戦すべきかについて論じています。是非読んでみてください。
写真4: Open Source Summit Japan 2023でのLinux Foundation FellowのGreg、Linus、Mr.Eto
最後に、私の破天荒な夢の実現を支えてくれたコミュニティやチームの多くのエンジニア、Andrew Morton/Greg Kroah-Hartmanを始めとしたメンテナーの方々、Jim Zemlin氏を始めとした友人に心から感謝したいと思います。
著者について
Mr.EtoはLinux Foundationフェローであり、元Fujitsuの従業員・事業部長でした。2010年からLinux Foundation取締役会のFujitsu代表を務め、FujitsuおよびLinuxの独自OSの開発と管理を含むOS開発に携わりました。2013年からLinux Foundation取締役会の副議長を務めました。
10年以上にわたり、FujitsuのLinuxコミュニティ エンジニアを率いてLinuxコミュニティ全体と連携してきました。彼のリーダーシップのもと、チームはLinuxカーネルへの最大の貢献者の1つとなり、エンタープライズ規模で利用されるLinux OSの機能と安定性を向上させるパッチを継続的に提供してきました。さらに、ディストリビューターやLinuxコミュニティの他の人々とのコラボレーションを通じて、エンタープライズ顧客サポートのコア エンジニアリング チームを率いてきました。同チームは、ミッションクリティカルな顧客に対して信頼性の高い顧客サポートを提供し続けています。
日本語版翻訳協力：鯨井貴博、監修：江藤 圭也