[レポート]OSSエンジニアのBetter than Nothingという生き方 〜 全力で5%を目指せ! #AWSDevDay

2022.11.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

11月8日から11日にかけて開発を牽引する Developer のためのテクニカルカンファレンス「AWS Dev Day 2022 Japan」が開催中です。

そのDay 0のセッション「OSS エンジニアの Better than Nothing という生き方」についてレポートします。

スピーカーはAqua Security Softwareのオープンソースエンジニアの福田鉄平氏です。

OSSのコンテナイメージの脆弱性スキャンツールTrivyをGitHubに公開した翌日にはAquaからコンタクトを受け、わずか数カ月後にはTrivyをAquaに売却・入社し、Aquaの本社があるイスラエルに引っ越した経歴の持ち主です。

そんな福田氏がイスラエルで最も感銘を受けた考え方が"Better than Nothing"です。 慎重で完璧主義に陥りやすい日本人気質とは真逆な"Better than Nothing"

このマインドセットはイスラエルで盛んなスタートアップを支える大事なマインドセットでもあります。

セッション情報

動画

概要

G-0-2 | 11 月 8 日(火)19:00 - 19:45

OSS エンジニアの Better than Nothing という生き方

趣味で開発したOSSが海外企業に買収されイスラエルで働くようになってから大きく感銘を受けた考え方に、"better than nothing"というものがあります。全くないよりは良いという意味ですが、何度も聞いているうちに自分は完璧にこだわりすぎていることに気付きました。かつてほぼ開発経験のなかった自分が OSS を公開するということや、英語も全然話せないのに海外で働くということに大きな抵抗がありましたが、今思えばこれはどちらも完成度へのこだわりから来ていたのだと思います。本セッションでは同様に「自分にはまだまだ実力が足りない」と考えてしまう人に向けて、"better than nothing"という考え方を通してどのように一歩を踏み出せるかについてお話しします。

<福田 鉄平 氏 プロフィール>

セキュリティツールであるOSS「Trivy」の開発者。2019年にAqua Security社に買収を受け、現在はイスラエルにある同社でセキュリティ系OSS開発に従事。温水洗浄便座という最高の発明を世界に広めたいと思っている。

Better than Nothing をビジネスに活かす

例1:Better Than Nothing な ECサイト

ECサイトをローンチする時の完成度を考えます。

  1. 40% : ログインオンライン決済のみ実装して1ヶ月でリリース
  2. 80% : ショッピングカート・在庫管理を実装して2ヶ月でリリース
  3. 100% : レコメンド機能・クーポン機能などオンラインショピングに必要な機能が揃えて4ヶ月でリリース

伝統的な日本企業は#3 を求めるだろうし、IT系エンジニアなら、#1 や #2 で始めるかもしれない。

イスラエル人の場合、ただの商品カタログのような5%の完成度のECサイトを1週間でリリースします。

この考え方がまさに "Better Than Nothing"

Better Than Nothingとは

文字通り、無いよりはマシ。

完成度は 5%で十分かもしれない。 作り込むのは無駄であり、足りなければ、あとから付け足せば良いという考え方。

イスラエルでは、この考え方が日常レベルで浸透していて、これがスタートアップ大国である所以。 人口比でイスラエルのスタートアップは日本の25倍もある。

スタートアップにつとめている人は、この"Better Than Nothing"で考えているかもしれないが、イスラエルの5%は日本人が想像するよりもずっと低い完成度。

イスラエルの完成度

新築賃貸であっても、設備はすぐ壊れ、機能するレベルの修繕しかしない。 一部の設備はそもそも機能しておらず、半年たっても同じ状態。

新規開店したレストランが、1ヶ月たっても、看板すらないこともある。

例2:話者の少ないレアな言語の翻訳機能を実装したい

話者が世界でひとりしないいないセルクナム語の翻訳機能を実装するケースを考えます。

データセットが少ないため、機械学習的アプローチはうまくいきそうにありません。

うまくいくかわからないなら、いい方法が見つかるまで保留する人が多いでしょう。

このような結論に至るのは、日本人が All Or Nothing な思考に陥っているのが原因です。

イスラエル人なら、挨拶など最低限の会話だけの辞書を人力で用意します。 汎用的ではないけれども、無いよりは確実に便利です。

日本人は完璧主義の人が多い

日本人の完璧主義な気質は良いところもあるが悪いところもある。

失敗を恐れたり、難しそうだと分かるとやめてしまったり、妥協を許さないという姿勢があるので、All or Nothingになりがち。

福田氏の場合、エンジニアとして少しずつ良くしていくことに慣れていたので、完璧主義ではないと思っていたが、自分も完璧主義だったと気づかされます。

一方で、イスラエル人は美しくなくて、泥臭い現実的な方法も選択します。

All or Nothing な考え方から Better Than Nothing へのシフトは容易ではありません。

例3:pom.xmlパーサの実体験

ビルドツールMavenの設定ファイル pom.xml パーサを Go で実装する必要があった。

Mavenは歴史あるツールなので、全てを実装するのは大変。 そのため、主要な機能を実装していて、リリース間近までこぎつけていた。 一方で、競合は pom.xml をデコードするだけの完成度1−2%の状態でリリースした。

競合のプロダクトはあまりにも機能が少ないので使われないと思っていたが、ユーザーは競合のツールに飛びついた。

理由は、リリースしていなかったから。リリースしていないのは0%と同じ。

0と5で比較したら、5のほうが良いのは当たり前。

職人気質なところがあり、60%の完成度を目指してリリースを渋っていたのが原因。

Better Than Nothingな考え方をできていたら、ぜんぜん違う結果になっていたはずで、非常に悔しい思いをした。 この実体験のあと、All or Nothingのマインドから抜け出せるようになった。

Better than Nothingが向かないことも

いつでも Better than Nothing が正しいわけではない。

運用業者が荷物を粗末に扱うと、物は壊れてしまう。壊れたあとでは、改善する余地はない。

事故が起きやすい車や耐震性のない建築物などはリスクが大きすぎるので、All or Nothing的な考え方が向いている。

Better than Nothing を日常に活かす

世間一般は Better Than Nothing な OSS だらけ

All or Nothing的な考え方に取り憑かれていると、革新的でないOSSを公開しても仕方がない、完璧な状態でなければOSSとして出さない方がマシと思ってしまいがち。

Better Than Nothing的な考え方では、数行であっても、誰かの役に立つのであればOSSとして公開すべし。

OSSとして公開したところで何らリスクはない。

OSSエンジニアになってわかったことは、世の中には「動くから良いじゃん」の Better Than Nothingな OSS で溢れている。 有名なOSSであっても然り。

完璧でなくても、ちゃんと動いているから利用されているOSSが大量にある。

完成度が低くても OSS として出してほしい

英語

英語からずっと逃げてきたが、社内では唯一の日本人のため、会話は必然的に英語。

英語と向き合うことで世界が広がった。

All or Nothing な考え方では、ネイティブレベルが求められる。

流石にそこまで要求する人はいないが、ミーティングで意見言えないとだめというように、ハードルを上げている人が多い。 完璧主義的な考え方が抜けきっていないのではないか?

Better than Nothingでは、挨拶ができたり、自己紹介ができれば十分。

できるようになるまで待っても、そんなタイミングはいつまでたっても来ない。

英語は完璧じゃなくても、なんとかやれている。

物怖じしないほうが良い

登壇

  • イスラエル版情熱大陸
  • AWS Dev Day

など、すごい人が一般登壇する中で、自分が登壇してよいのか思うところがある。 漠然とした不安はあるけれども、リスクがあるわけではない。

誰かのプラスになるのであれば、やらないより、やったほうが良いと思うようになった。

Better than Nothing とは?

完璧でなくても、無いよりはいい。 完成度は5%で十分かもしれない。 ただし、手を抜くのではなくて、全力で5%のものを目指すこと。

所感

ソフトウェア開発やイスラエル生活での体験を元にした、イスラエルのスタートアップ文化を支える "Better than Nothing" のススメ。

"Worse is Better" も近い考え方です。 完璧主義で the right thing にこだわってしまう Architecture Astronaut には耳の痛い話です。

一歩踏み出すことへの心理的障壁が大きく下がり、勇気付けられた人は多いのではないでしょうか。

それでは。

参考