2024.06.24
2004年の設立以来、バルテスは品質向上のトータルサポート企業として、ソフトウェアテストを始めとした様々な品質向上支援サービスを提供してきました。日本を代表するテスト専門企業として、安心安全なICT社会を実現する提供サービス・ツールのアップデートをしていく使命があります。
2024年4月より、世界中のプログラマー達に利用されているプログラミング言語Ruby（ルビー）の創始者、まつもとゆきひろ氏が、当社グループ技術顧問として就任しました。
そこで今回はまつもとゆきひろ氏にRuby開発時の品質への取り組みや、バルテスグループの技術顧問に就任された背景、今後の展望について話を伺いました。
今回インタビューを受けてくださった方
- まつもと ゆきひろ
バルテス・ホールディングス株式会社 技術顧問
プログラミング言語Rubyの創始者。一般財団法人Rubyアソシエーション理事長。ほか複数社のフェロー、技術顧問を務める。島根県松江市在住で、Ruby開発の功績から2009年に同市の名誉市民にも選ばれ、2012年には内閣府より「世界で活躍し『日本』を発信する日本人」の一人に選ばれている。
- もくじ
1. Rubyの開発者として知られる「まつもとゆきひろ」氏
ーーまつもとさんといえば、プログラミング言語「Ruby」の開発者として知られていますが、「まつもとゆきひろ」と平仮名表記にされた理由はなんだったのでしょうか？
ご存知のように、「松本」はごくありふれた名字で日本では61万人以上もいるんですね。そこで、学生時代に「差別化しよう！」と思ったのが平仮名表記のきっかけです。
小学校の頃、私はちょっとひねくれた子どもでして。学校でそろばんを購入する際、注文書の名前を平仮名で記入したんです。そうしたら、届いたそろばんには平仮名で名前が書いてあって、「自分の名前は平仮名がいいな」と結構気に入ってしまいました。
それ以来、学生時代からずっと平仮名で「まつもとゆきひろ」と名乗っていますね。ネットでは平仮名ばかりで活動しているので、たまに漢字の名前で登場すると「君は誰だ？」と言われてしまいます。
ーー海外での通称は「Matz（マッツ）」ですね。
海外の人は親しくなるとファーストネームで呼び合いますよね。ただし、私のことを「ゆきひろ」と名前で呼ぶ人は日本でうちの母親しかいないのでドキドキするんですよ。
あとは海外で「ゆきひろまつもと」だと聞き慣れないので覚えてもらえない。この辺の文化的軋轢を解消しつつ、名前を差別化するためにはどうしたらいいか？と悩んでニックネームをつければいいんだと思い、海外では「Matz（マッツ）」にしました。
ただし、Matzと名乗る人は他にもいるみたいなので、そんなに珍しいものでもなかったようです。
ーーRubyコミュニティでは「MINASWAN」と標語にもなっています。
これは、アメリカのソフトウェア技術者であるマーチン・ファウラーさんという業界の有名人の方が作ったものです。"Matz is nice so we are nice"の略で、もめごとがあっても「Matzがniceだから俺らもniceでいよう」というスローガンになっているそうです。
2. よいモノづくりを目指す「品質」にフォーカスする
ーー今回、バルデスの技術顧問に就任されたきっかけは何だったのでしょうか。
正直なところ、バルテスの方から「まつもとさん、うちの技術顧問どうでしょうか」と問い合わせがあったので「ありがとうございます」と受け入れたのがきっかけです。
現在、私は株式会社ZOZOやLinkers株式会社、株式会社LIGなど10社ほどの技術顧問を勤めています。技術顧問のお誘いいただいた際に「同じ業界の競合企業でないこと」「自社サービスを提供していること」の2点を基準に検討してきました。
競合企業での技術顧問は情報漏洩のようなことがあってもいけませんし、受託開発をしている企業を私がお手伝いしても知見がその会社に残りませんよね。
過去に品質保証の分野でお手伝いしたことがなかったので、そういう意味でバルテスとはお互いに知見を共有して、Win-Winの関係を築けるのではないかと期待しています。
ーーまつもとさんにとって「よい品質」とはどのような状態だとお考えでしょうか。
言葉の定義にもよりますが、私の定義でいうと品質は2種類あると思っています。
1つ目は「よいサービスであるか」「ユーザー満足度の高いサービスであるか」という設計の問題によって得られる品質。
2つ目は、非機能要件などが満たされているかという機能面以外の品質ですね。例えば、機能上は満たしているものの、動きが遅いとかバグがあるか、なども品質といえるでしょう。
ちなみに、私自身がフォーカスしているのは前者の品質で、どんな設計のどんなソフトウェアを作るか、という時に、「より良いソフトウェアをつくる」という点に非常に気を遣ってきました。
一方で、後者の品質について、いわゆる「バグがない」「パフォーマンスが高い」というような部分について、私自身がタッチすることは滅多にありません。Rubyの開発は私が基本的な方針を決めた後に個別の人が開発する体制になっているので、後者の品質については個別の開発者にお願いしている状態です。
3. オープンソースのRubyにテスト文化が定着した理由
ーーRubyを開発される際、品質に関してどのような点を意識されていましたか。
オープンソースのライセンス上は「保証しないよ」と書いてあるので、バグがあっても知りませんよというのが公式な立場ではあります。とはいえ、実際にRubyを使っているユーザーが、バクによって使えないというときに、「オープンソースだから仕方がないよね」と言ってもらえるかというとそうはいきません。
また、Rubyではいわゆるテストドリブンアプローチみたいなものをコミュニティ全体として推進してきたこともあります。そういう意味でいうと、Rubyにはテスト文化というものが非常に定着してきていますし、Rubyの開発をするときも必ず新機能とテストを同時に入れていく形にしてきました。
商用ソフトウェアとオープンソースの違いがあるとすれば、商用ソフトウェアの場合は直すことができるのはその会社の中の人だけで、オープンソースソフトの場合は問題に直面したとき「こうやったら直りますよ」とさらに一歩踏み込んだアクションをユーザーとできることです。
それ以外の部分では、実はそんなに大きな違いはないんじゃないかなと私は思いますね。
ーー実際にどのような取り組みをされていましたか。
「良いモノが作りたい」という思いがあったので、良いプロダクトとしての品質はずっと目指してきました。
たとえば、バグを見つけたら直してバグが起きないようにコードを書くことについては割とこだわりがあります。
初期のRubyでは、ユーザーが増えるにつれてバグがたくさん見つかるようになり、それをどんどん潰していって品質が上がってきました。初期はバグの発見をユーザーに任せてきた負い目も少しありますが......。それ以外の部分では、品質を改善するために努力を継続した点においては、商用ソフトともあまり変わらないのではと思います。
4. Rubyの品質保証の中で苦労したこと
ーーRubyのコミュニティが広がる中で品質を維持する苦労はあったのでしょうか。
バグレポートが来たときに、バグレポートが何を意味しているかを理解することが難しいケースがあります。たとえばユーザーのところではバグが発生しているものの、レポートが要領を得ず、こちらでは再現できない、といったケースです。
我々は俗語で「エスパー」と言っているのですが、超能力並みの行動を発揮して現象を把握しないと直せません。特にRubyで作ったソフトウェアがトラブルを起こしてソフトがうまく動かせない場合「そのソフトはうちの会社の財産なので見せることはできません」みたいなケースが稀にあります。
そういう場合は可能であれば、再現する最小ケースみたいなものを出して送ってくださるのが一番助かりますし、そうしてくださるユーザーもたくさんいらっしゃいます。なかには「切り出したら発生しなくなりました」みたいなケースもありました。
ーーこちらがテレパシーで相手の意図を読まなきゃいけない。
そうなんですよ。Rubyのようにいろいろな使われ方をすることが多いソフトウェアに関しては、エスパーが起きることは多いですね。
下のレイヤーになればなるほどその傾向があり、ライブラリであるとかフレームワークであるとか言語もそう。その辺は、使われ方を事前に予測することが難しいソフトウェアですよね。
ーーそのほか、品質を維持するために工夫したことがあればお教えください。
CI（継続的インテグレーション）はやっていますね。たとえば、パッチを書いてプルリクエストを送ったら、それが必ず各プラットフォームでのビルドやフィールドテストをやってみて通らないのであればマージしません、みたいなことは当然行っています。
5. Quality Assuranceのエンパワーメントに期待
ーーまつもとさんが技術顧問として就任されたことで、若手のQAエンジニアにポジティブな影響もあると思います。
そうですね。今後、バルテスの技術部門の方々と対話も予定していますので、私のこれまでの経験などをお伝えして、QAに携わっているエンジニアの方に少しでも良い影響を与えられればいいなと思っています。
ソフトウェアを作る側の立場からするとバグは再現性のある状態で見つけられるとそんなに大変ではないものがほとんどです。そういう意味でいうと、潜在的なバグを見つけていただくのは非常にありがたいことだなと常々思っています。
オープンソースの場合はユーザーからバグレポートが来ることが多いのですが、会社でソフトウェア開発をするとユーザーにバグ見つけていただくわけにもいきません。そうなるとバルテスで開発しているようなツールを使ったり、QAエンジニアの働きによってバグを見つけたりしていくことが非常に重要です。
また、個人的にテストは重要度が高いわりには退屈といいますか、QAエンジニアは辛いことが多いと思うので、何らかのツール支援があると非常にいいなと感じています。
その点はバルテスのサービスでQAの効率向上や、仕事が楽しくなるのであれば良いことだと思いますね。
ーー最後に、開発プロジェクトに関わる方に向けて一言エールをお願いいたします。
ソフトウェア品質はソフトの出来がいいかどうか、仕様がいいかどうか、その成すべきものとしての着眼点が良いかみたいなところが大事です。
それに加えて、よくいわれる品質としてバグがないかどうかの両方が揃っていないと、そのソフトウェアはおそらく使われません。
そうしたことがきっかけで、エンジニアが頑張って作ってきたモノが頓挫したり広まらなかったりするのは 非常にもったいないなと思うので、テストはもちろん重要です。
その一方で、ソフトウェア開発する純粋なソフトウェア会社、エンジニアとしてはテストをあまり書きたくないんですよね。
この辺の折り合いをつけるのが難しいところではありますが、それこそツールなり何なりの支援で省力化をしてQuality Assuranceのエンパワーメントみたいなものがあることは非常に望ましい状態です。
私としても、テスト自動化ツール「T-DASH」やテスト管理ツール「QuaityTracker」などを自社開発し、そういうところに果敢に挑戦してらっしゃるバルテスには期待する立場ではあります。
ーー本日はお時間いただきありがとうございました。