技術広報ブログ

技術広報のためブログです。

技術カンファレンスへ多くスポンサーをした起業ランキング2022

こんにちは@techfavoです。

先日、同業他社の人から下記の話を聞きました。

「カンファレンスで一番高いプランのスポンサーをしたら、それを見たエンジニアの方が応募してきてくれたんです」

 

上記の話の詳細は省きますが「見ている人は見ているんだな」と言うのがその時の印象で、今年の技術カンファレンスのスポンサー企業の様子が少し気になりました。お金を出した企業が偉いというわけではありませんが、2022年の振り返りとしてスポンサープランのカウントをしてみました。よろしければご確認ください。

 

カウント方法

カウントした技術カンファレンスは下記を参考にしました。言語被りの技術カンファレンスは申し訳ないのですが一旦抜かさせていただきます。またFlutterKaigiやiOSDC japanなどの規模が大きい技術カンファレンスは追加させていただいています。

 

anti-pattern.co.jp

 

カウント方法としては、一番下のスポンサープランを1点とし、プランが上がるたびに1点加算します。例をあげると以下のような形です。

  • ダイヤモンドプラン:4点
  • プラチナプラン:3点
  • ゴールドプラン:2点
  • シルバープラン:1点

プランの差の価値が単純に4倍ということはないのですが、便宜上このようにしています。なので、かなりガバなランキングです。

またロゴスポンサーやwifiスポンサーなどの特殊スポンサーもどこにカウントするか不明なので、今回はカウントしていません。

 

スポンサープランが掲載されていない技術カンファレンスも除きました。

それではランキングどうぞ。

 

スポンサープラン起業ランキング2022

1位:23点 株式会社ゆめみ

2位:19点 株式会社ディー・エヌ・エー

3位:15点
New Relic株式会社
STORES 株式会社

5位:14点
株式会社ココナラ
株式会社メルカリ
メドピア株式会社
LINE株式会社

9位:13点
ウォンテッドリー株式会社
株式会社サイバーエージェント
株式会社MIXI
サイボウズ株式会社

13位:12点
エムスリー株式会社
株式会社スリーシェイク
ヤフー株式会社

16位:10点
株式会社はてな
株式会社カオナビ
日本マイクロソフト株式会社
Rakuten Group, Inc.

19位:9点
株式会社アンドパッド
note株式会社

 

ランキング詳細

1位は皆さん予想されていたのではないでしょうか? 総点数23点のゆめみさんです。2位はディー・エヌ・エーさんで、最多の9つの技術カンファレンスにスポンサーをしていました。

参加されたスポンサーは下記の通りです。

1位:株式会社ゆめみ

  • Developers Summit 2022
  • 技育祭 2022 春
  • PHPerKaigi 2022
  • DroidKaigi 2022
  • Vue Fes Japan Online 2022
  • FlutterKaigi 2022
  • iOSDC Japan 2022

2位:株式会社ディー・エヌ・エー

  • YAPC::Japan::Online 2022
  • 技育祭 2022 春
  • Go Conference 2022 Spring
  • SRE NEXT 2022 ONLINE
  • ISUCON12
  • RubyKaigi 2022
  • DroidKaigi 2022
  • FlutterKaigi 2022
  • iOSDC Japan 2022

3位:New Relic株式会社

  • Developers Summit 2022
  • Observability Conference 2022
  • Day One - CTO/VPoE Conference 2022 Spring
  • Cloud Operator Days Tokyo 2022
  • ISUCON12

4位:STORES 株式会社

  • Go Conference 2022 Spring
  • SRE NEXT 2022 ONLINE
  • ISUCON12
  • RubyKaigi 2022
  • Vue Fes Japan Online 2022
  • iOSDC Japan 2022

その他の詳細はこちらからご確認ください。

protective-sweatshirt-2a0.notion.site

 

はじめてのコムウェイの法則と逆コムウェイの法則

だいぶ前になってしまいましたが、9月30日にFindyさんが開催してくださった『【エムスリー×MonotaRO】急成長メガベンチャーのエンジニア組織づくり最前線』というイベントに参加していました。

 

findy.connpass.com

 

その中でふと話にでてきたのが『コムウェイの法則』でした。今回のイベントでは特に主題ではなかったので「コムウェイの法則を知らない人はググってください」と、いった形で終わってしまったのですが、個人的には気になったので調べてみました。

 

## コムウェイの法則とは

コムウェイの法則とは、1968年にメルヴィン・コンウェイという人が『Datamation』という雑誌に発表した論文で紹介された経験則の法則です。その内容は以下の通りです。

 

「システム(ここでは単なる情報システムよりも広く定義されたシステム)を設計する組織は、必ずその組織のコミュニケーション構造を倣った構造を持つ設計を生み出す」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")

 

論文の原文はこちらにあります。

www.melconway.com

 

具体的な例を用いた言い方をすると「密結合組織の場合は、システムも自然に密結合に(モジュール性が低く)なる」という感じです。図にすると下記のようなものになると思われます。

なぜこのようなことが起こるのかというと、密結合された大きい組織でシステムを開発すると、誰が何の機能を開発しているのかがわかりにくく、多くの人たちに役割が割り振られます。そうするとたくさんの機能に触れることになるので、マイクロサービス化する意識が生まれず、モジュール性の低いシステムができあがるそうです。

反対に疎結合組織の場合(ちなみに、疎結合とは細分化された個々のコンポーネント同士の結びつきが比較的緩やかで、独立性が強い状態のことです)は、小さなチームが独立して、それぞれのチームが担当するサービスを開発していきます。こうすることによって意思決定が早く勧められるうえ、モジュール性の高いシステムを作ることができるようです。

 

## コムウェイの法則の何が重要なのか?

上記のように組織のコミュニケーション構造が、システムのアーキテクチャーにまで影響するというのがコムウェイの法則です。しかし、この法則の何が重要なのでしょうか?

 

現在のソフトウェア業界ではサービスのリリース速度は他社との差別化をはかるうえでとても大切です。しかし、密結合の大きい組織で巨大なモノリシックなコードを相手にしていると、依存関係のエラーが起こってしまったり、活躍できない人材がでてきてしまったりするなどでリリース速度が落ちてしまいます。

 

疎結合の組織でモジュール性が高いシステムの場合、チームが開発のライフサイクルを管理し、スコープの調整やデブロイ速度の向上などができるので、結果的にリリース速度を早めることが可能となります。

この疎結合組織として有名なのがAmazonです。Amazonでは『ピザ2枚ルール』というルールがあり、これはピザ2枚で足りないような人数のチームを作らないというルールです。

docs.aws.amazon.com

 

このようにシステム改善を行うのにアーキテクチャーばかりを見るだけでなく、組織の状況をよく調べることが重要という理解につながることがコンウェイの法則の重要な点のようです。組織は大きくなるほど、システムの柔軟性が低下し、リリース速度が遅くなるので、コンウェイの法則を意識することが重要になるとのことです。

 

コンウェイの法則の付き合い方として、Youtube動画で良いまとめがありましたので、こちらに引用いたします。

  • コードがすべてではない(It’s not all about the code!)
  • 小さなチームは大きなことができる(Small teams can do big things.)
  • フルスタックのチームはアーキテクチャーの柔軟性をキープする(Full Stack teams keeps your architecture flexible.)
  • コムウェイの法則と戦わず、一緒に働く意識を持つ(Don’t fight Conway’s Law, work with it.)

www.youtube.com

 

## 逆コンウェイの法則

上記のようなことから、アーキテクチャーをマイクロサービス化し、システムを改善していくには、組織を疎結合組織にし、まずは組織を変えていくことが勧められています。近年では「アーキテクチャーが組織を変えることができるのではないか」という、別の見方もでてきました。まずアーキテクチャーを改善し、その後、プロダクトにそって組織を改善することを逆コンウェイの法則と言うそうです。

 

図にすると、矢印を逆にするだけなので、こんな感じですね。

少し調べただけなので、間違った認識のところもあるかと思いますが、参考にしたのは下記の書籍です。今度第2版がでるそうですね。

 

参考:

マイクロサービスアーキテクチャ

 

コンウェイの法則と逆コンウェイの法則から組織構造を考える

medium.com

 

参考にした動画

コンウェイの法則を忘れないでください」 - サラ・ノボトニー基調講演

www.youtube.com

なぜ締め切りは意味がないのか? そして代わりにすべきこと

技術広報をしているとテックブログに携わることが多いと思いますが、記事の管理のために締め切りを設けている方も多いと思います。最近、この「締め切り」というものの必要性に違和感をもっていたところ、海外で参考になりそうな記事がありましたので、簡単に翻訳してご紹介します。

 

元の記事はこちらでコピーレフトです。

lucasfcosta.com

 

なぜ締め切りは意味がないのか? そして代わりにすべきこと

締め切りはソフトウェアエンジニアにとって悩みの種です。2週間後に納期が迫っているのに全然終わらない……。なので、徹夜したり、いい加減なテストをしたり、手抜きをしたりして何とかやり遂げようとします。すると何が起こるのでしょうか? プロジェクトはバグだらけになり、顧客は不満を抱き、エンジニアたちは疲れ果ててしまいます。

 

時にはバグが多すぎてソフトウェアエンジニアリングの基準に達していないこともあります。そのような場合、マネージャーは新しい期限を設定し、最初の期限はそもそも存在すべきではなかったことを明らかにします。さて、想像してみてください。2回目の締め切りを逃したらどうなると思いますか? その通り、新しい締め切りが設定されるのです。締め切りが好きでしょう?

 

そろそろ「締め切り」を「プレッシャー」という本当の名前で呼ぶべきです。

 

締め切りがあるからといって、エンジニアのコーディングが速くなるわけではありません。ただ、労働時間が長くなるだけです。機能不全に陥っていないチームの場合は、締め切りの役割として、実装する機能の範囲を決められ、クライアントへ納品するための強制機能となり、早くクライアントへ納品でき早くフィードバックに対応することができます。

 

この記事では、なぜ締め切りがよくないことにも関わらず必要とされているのか、そして締め切りが生産性やモラル、ソフトウェアの品質にどのような害を及ぼすのかを説明します。

 

そして、より生産的でストレスの少ない代替案として「プリエンプションポイント」を提案します。プリエンプションポイントとは何か、なぜそれが有効なのか、そして締め切りと比較した場合の利点について説明します。

 

また、プリエンプションポイントについて説明した後、そのポイントの取出しポリシーがどのように価値を早期に提供し、締め切りを無意味なものにするかについても解説します。

 

この記事の最後には、チームを説得して締め切りを捨てさせ、これまで締め切りが役に立つと思っていた人たちを含め、すべての人がより快適に仕事ができるようにするためのちょっとしたまとめがあります。

 

なぜ締め切りは無意味なのか

締め切りの無意味さの根底にあるのは「結果をコントロールできない」という事実です。あなたがコントロールできるのはその結果を生み出すプロセスだけです。

 

たとえば今日からトレーニングを始めて、明日にハーフマラソンに出場することはできません。しかし、走る距離をコンスタントに増やしていくシステムを作ることはできます。

 

ベッドから出たくない日もあるでしょう。そのような日は、あまり走らないようにします。また、朝起きてから命がけで走る日もあるでしょう。バラツキがあるのです。それでも毎週コンスタントに走る距離を向上していけば、いずれマラソンを走れるようになります。

 

安定したペースで上達すれば、来年のマラソンを走れるかどうかの見通しがつくかもしれません。それまではどんな期限も無知な推測に過ぎないのです。

 

確かに、マラソンの時期がわかれば、その日に走れるように炭水化物の摂取量を調整したり、トレーニング方法を微調整したりすることができます。しかし、あなたが常に向上心を持ち、マラソン大会のかなり前の時期に走ることができなければ、期限を設定することは怪我やオーバートレーニングの元です。マラソンが開催させる日に走ることができない場合、参加することもできないのです。

 

長期的な目標には、一貫した短期行動と予測可能なパフォーマンスの向上が必要であり、無謀な一押しは必要ないのです。

 

また、締め切りは無意味であることに加え、次のような弊害もあります。

 

  1. 締め切りはチームのパフォーマンスを向上させません。締め切り目標を設定しても、納品が早くなるわけではありません。結果として、チームは実装する機能を減らすか、より長く働くようになります。
  2. 締め切りはインセンティブをずらし長期的な思考を妨げます。締め切りは長期的に予測可能で持続可能なパフォーマンスではなく、期限を守るために短期的な利益を優先させるインセンティブをチームに与えます。
  3. 締め切りは実行可能なものではありません。チームが期限に間に合わなかったとき、その後に生産的なことをするには遅すぎるのです。

 

それぞれのステートメントについてより詳しく説明します。

 

締め切りはパフォーマンスを向上させない

コンピュータの性能を上げるために「もっと頑張れ」「もっと危機感を持て」と応援する人はいないでしょう。コンピュータはいつもと同じ速度で数字を計算します。

 

確かにオーバークロックはできるかもしれませんが、マザーボードが石炭に変わり、電気代が破産宣告を受けるのは時間の問題でしょう。

 

コンピュータに特定の速度でプログラムを実行させたいなら、新しいハードウェアを買うか、より良いコードを書くべきです。目標を設定しても、システムの結果には影響しないのです。

 

ゴールを立てようが立てまいが、システムは出せるものを出す。

 

同様に、締め切りを設けたからといって、エンジニアリングチームのパフォーマンスが向上するわけではありません。

 

チームのパフォーマンスを向上させるには、マネージャーがシステムを改善する必要があります。たとえば、より多くの人を雇う、デプロイメントを摩擦のないものにする、自動テストを導入して手作業による検査の必要性を減らすなどの方法が必要です。

 

納期を早める唯一の方法は、プレッシャーによってチームを「過重労働」させ、メンバーの労働時間を長くすることです。一度や二度はうまくいくかもしれませんが、長期的に見れば過重労働は人を辞めさせることになり持続不可能な行為です。

 

一貫した体系的な改善によってのみ、チームはパフォーマンスの基準値を作成し、レバレッジを効かせ、継続的に成果を向上させることができるのです。

 

## 期限を区切ると、インセンティブがずれて長期的な思考ができなくなる

2つの営業チームがあるとします。一方は再現性のない予測不可能な収益の急増をもたらし、もう一方は一貫した継続的な成果を生み出しています。

 

期限に間に合わせ人に5万ドルのボーナスを支給するシステムでは、不安定なチームが運良く期限に間に合ったのか、過重労働をしたのかに関係なく報酬を受け取ることになります。

 

図1:5万ドルの期限を守る不規則なチーム

 

そのチームは、パフォーマンスの一貫した基準を設定していないため、四半期ごとに売上目標を単純に増加させることはできません。それは失敗のもとです。この場合、予測可能な収益がないため目標達成を運に頼ることになります。

 

さらにそのチームがすでに納期を守るために長時間労働をしていた場合、辞めてしまう人も出てくるかもしれません。

 

この矛盾は締切を設定することで生じることが多いです。そのせいでチームは長期的な一貫性や継続的な改善よりも、短期的な利益を優先するようになるのです。

 

W.E.デミングならこう言うだろう。

『短期的な利益は、経営のパフォーマンスを示す信頼できる指標ではありません。メンテナンスを先延ばしにしたり、研究を手抜きにしたり、他の会社を買収したりすれば、誰でも配当金を支払うことができます。- Deming, W. Edwards. Out of the Crisis, reissue (p.19). MIT Press. Kindle版』

 

では、その不安定なチームと、継続的にパフォーマンスを向上させながらも5万ドル達成の期限を逃してしまう予測可能なチームとを比べてみましょう。

 

図2:5万ドルの期限を守らない、一貫性のある予測可能なチーム

 

どちらのチームに所属したいですか?

 

私は間違いなく2番目がいいと思います。そのチームは、締め切りに間に合わなかったものの、常にパフォーマンスを向上させることができることを実証してくれたので、私は運に頼ることなく、より正確に売上を予測することができるようになりました。そうすれば、私は確かな根拠に基づいて意思決定ができるようになります。

 

さらに、長期的に見て継続的改善の原則を適用し続ければ、安定したチームはやがて不安定なチームのパフォーマンスを上回るようになるのです。

 

『余談ですが、私が「スナップショット測定法」を好まないのはそのためです。その代わりに、私はこの別の投稿で概説したように(https://lucasfcosta.com/2022/08/31/engineering-metrics.html)、一貫性と継続的改善のためにチームの勢いとコントロールを見る測定基準を好みます』

 

締め切りは実行可能なものではない

チームが締め切りに間に合わなかった場合、生産的な行動を起こすには遅すぎます。

締め切りに間に合わなくなったら、どのような行動をとればよいか考えてみましょう。

  1. 新しい期限を設定する
  2. 誰かを解雇する
  3. 機能をカットする

 

1つ目の新しい締め切りを設定することは、最初の締め切りがすでに無駄であり不要であったことを明らかにします。最初の締め切りがそうであったなら、2回目以降の締め切りもそうである可能性があります。

 

2番目の行動、つまり誰かを解雇することは、チームがすでに遅れているソフトウェアを提供する助けにはなりません。むしろコードを書く人が少なくなるため、ソフトウェアの完成が遅くなるのです。

 

3つ目の行動である機能をカットすることは、不要な作業をしていたこと、もっと早く納品できたことを明らかにするものです。機能をカットすることは有益ですが、締め切りのせいでそれを行うのは遅すぎるのです。

 

その他の行動には好きな名をつけてください。これらはすべて、行動が遅すぎたために非生産的なのです。

 

ルーカス、締め切りがないと何も納品できないぞ。パーキンソンの法則を知らないのか?

もし、あなたのチームが締切なしに納品できないのであれば、締切がないことが問題なのではありません。あなたのチームの顧客フィードバックに対する無頓着な態度が問題なのです。

 

顧客からのフィードバックにこだわるチームは、できるだけ早く納品し、顧客の声に耳を傾けることができます。

 

顧客中心主義のチームにとって、人為的な納期は無意味です。なぜなら、唯一の重要な「納期」はすでに存在しているからです。「価値あるものである限り、できるだけ早く」です。

 

さてここで「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」というパーキンソンの法則について触れておこう。

 

この法則が正しいかどうかは問題ではありません。なぜなら、締め切りを設けない場合、仕事は無限に拡大するとは言えないからだ。

 

さらに、パーキンソンの法則によれば、締め切りに安全バッファを加えると、仕事が膨張することになる。したがって、遅延の可能性と遅延の確実性を交換することになる。もしかしたら、仕事がわずかに膨張しただけで当初より遅れることになるかもしれない。

 

それは、パーキンソンの法則の当然の結果であることは言うまでもない。

"ギリギリまで待てば、1分でできること"

 

そして、たった1分でできることなら、どんなに素晴らしい結果が得られるか想像できるはずです。良いソフトウェアには時間がかかる。

 

締め切りでないとしたら、何でしょうか?

締め切りなしで活動するためには、チームはプリエンプションポイントを採用し、取り出しポリシーに注意する必要があります。

 

これでチームが短期間で同期的に実行可能なフィードバックを作成し、早期に軌道修正できるようにします。またチームが最も価値のある仕事を早期に、低コストで提供することを可能にします。

 

このセクションでは、これらの戦略についてそれぞれ詳しく説明します。

 

プリエンプションポイント

OSは特定のプログラムがいつ終了するかは知りません。実際、前もってそれを決定することはできません。したがって、プログラムが実行される時間のクォータを確立します。つまり、他のプログラムがCPU時間を確保できるように、そのプログラムの実行を停止するのです。さらに、OSは挙動不審なプログラムやメモリを過剰に消費するプログラムを終了させます。

 

製品開発ではOSの手法を模倣して、より良い結果を得ることができる。開発者が特定のタスクに取り組むとき、範囲を狭めるべきか、損失を減らすべきかを評価する一定の時間が存在することがあります。これがプリエンプションポイントです。

 

プリエンプションポイントは、同期的で一様なものであるため、締め切りとは異なります。

 

各タスクに任意に期限を設定するのではなく、タスクの状態を定期的にチェックすることで、同期的な決定論的フィードバックを実現するのです。

 

例えば、3日、5日、10日を超えたら、タスクマネージャーでタスクを色分けして表示させるのも一つの方法です。その都度、そのタスクを早く納品するための改善点はないか、機能を削減することはできないか、あるいは完全に破棄することはできないかなどを検討します。

 

朝会は、この同期的なプリエンプションフィードバックを導入する一つの方法です。朝会では、前述のようなアプローチについてチームと話し合うことができます。

 

プリエンプションポイントがうまく機能するのは、変動を蓄積させるのではなく、定期的にベースライン(望ましい最終状態)に戻すことで、望ましい最終状態からの逸脱を修正するのに役立つからです。

 

定期的なチェックと介入がない限り、このような小さな逸脱は蓄積していきます。そうなると、機能は当初意図したものとは全く異なるものになってしまいます。従って間違った機能を納品するか、その修正に余分な時間を費やすことになります。

 

図3:プリエンプションポイントにより、定期的に変動をベースラインに戻す

 

こうしたわずかなズレが時間とともに蓄積されていく様子を説明する方法のひとつに、ドナルド・ライナーセン氏が著書『製品開発フローの原則』で行っているコイントスの実験があります。この実験では、コインを何度もひっくり返します。コインを1回投げるごとに、表が出るたびに1加算し、裏が出るたびに1減算していきます。

 

下のシミュレーションでは、投げる回数が多いほど、合計がゼロ軸の上下に移動することがわかりますが、これは多くの人が予想するのとは異なるものです。

 

図4:トスの回数が増えるにつれて、合計が基準値からどんどん離れていく

 

プリエンプションポイントは、あたかもコイントスの回数を細かく分割してシリーズ化していくように作用します。その都度、蓄積された偏差を強引に基準値に戻す作業を行うのです。

 

それに比べて締め切りは、バラツキが蓄積されすぎてしまうことが多い。それは、タスクの状況を確認するのが遅すぎるか、不定期すぎるため、現状を基準値に戻すのが難しく、時間がかかってしまうからです。

 

先取特権は、変動要因の処理に有効であることに加え、次のような点でも締め切りより優れています。

 

  1. 実行可能で予測可能である。
  2. 見積もりが不要になる。
  3. 短期的な利益よりも継続的な改善を奨励する。

 

タスクの状態を定期的にチェックすることで、問題を早期に発見し、軌道修正することができるからです。もし、毎日タスクの状況をチェックしていたとしても、対策を講じるのがせいぜい1日遅れるだけでしょう。

 

また、プリエンプションポイントを使うと、特定の日に何かを完了させることから、「できるだけ早く」というタイミングに関係なく、小さな価値の積み重ねをできるだけ早く提供することに焦点が移るため、見積もりも不要になります。

 

プリエンプションポイントを使えば、3時間のミーティングを開いて物事がうまくいかない可能性のあるシナリオをすべて明らかにする必要はありません。その代わり、新しい情報には素早く対応することができます。

 

また、どんなに綿密な計画を立てても、すべてのエッジケースを予測することはできないため、プリエンプションポイントを使えば、本当の意味でアジャイルになる可能性が高くなります。

 

最後に、プリエンプションポイントは、短期的な利益よりも継続的な改善のインセンティブになります。なぜなら、締め切りが近づくと、開発者は、後で何が起ころうとも、締め切りに間に合うように手を抜かなければならないというプレッシャーを感じるようになるからです。

 

開発者が手を抜くと、バグが発生し、ソフトウェアのメンテナンスが難しくなり、さらにタスクが長引き、予測可能性が損なわれてしまいます。

 

締め切りとは異なり、先取りポイントでは、特定の期日までに納品する必要がないため、他のチームと協力しながら段階的に解決策を設計するスペースが自然に生まれます。

 

したがって、開発者とプロダクトマネージャーは、手を抜くのではなく、スコープを削減することに同意し、長期的な予測可能性とパフォーマンスを損なわないような代替戦略を考案するのです。

 

待ち行列のポリシー

あらゆるソフトウェア開発プロセス待ち行列システムとしてモデル化することができます。このようなシステムでは、タスクが一方の端からソフトウェアに入ってきて、もう一方の端から結果が出てきます。

 

このシステムの性能は、時間に対する価値の関数で決まります。より多くの価値を提供し、その価値を提供するまでの時間が短ければ短いほど良いのです。

 

このシステムが提供する価値を高めるには、2つの方法があります。

 

1つ目は、システムの処理速度を上げてソフトウェアが結果を出す速度を速めること。

 

2つ目は、その時に最も短く最も価値のあるタスクをシステムに投入することです。そうすれば、処理速度に関係なく、常に最も価値のあるものを処理することができます。

 

この2つのアプローチの違いとして、1つ目の「処理速度を上げる」には、エンジニアの増員やプロセスの改善が必要なため、コストがかかることが多いです。

 

しかし、2つ目の方法はほとんど費用がかかりません。定期的にキューを見直し、タスクの優先順位付けを徹底することです。

 

病院が患者の健康状態に応じて治療を行うのと同じように、私たちはタスクの到着順ではなく、それぞれのタスクがどれだけ価値があるかによって処理を行う必要があるのです。

 

FIFO先入れ先出し)は、エンジニアリングシステムにとって最適な待ち行列の規律であることはほとんどありません。つまり、作成された順番にタスクを処理しても、満足のいく結果が得られることはほとんどないのです。

 

私は、FIFOのキューイング規律を採用する代わりに、マネージャーには「重み付けされた最短の仕事」という手法を採用することを管理者に強く勧めます。

 

この手法は、最も短く最も価値のある仕事を次の仕事として選択するものです。

 

この手法を採用すると、マネージャーは特定の日付に価値を提供することにこだわらなくなります。その代わり、システムの処理能力が限られていることを認識し、その能力を最も価値のあるタスク処理に充てることに集中します。

 

つまり、システムがゴールの有無にかかわらずできる限りの出力をするのであれば、システムの処理能力を最大限に活用するためには最も価値のある仕事を投入する必要があります。

 

まとめ

私たちは締め切りを本当の名前「プレッシャー」と呼ぶようにしなければなりません。

 

締め切りがあるからといって、エンジニアが早く納品できるわけではありません。エンジニアを長時間働かせたり、不完全でバグだらけの機能を納品したりするだけです。

 

締め切りが無意味なのは、結果をコントロールできないという事実に起因します。コントロールできるのは、その結果を生み出すプロセスだけです。

 

結果をコントロールすることはできず、結果を生み出すプロセスしかコントロールできないという事実のほかに、締め切りの無意味さを示す理由が3つあります。

 

  1. 締め切りは、チームのパフォーマンスを向上させない。
  2. 締め切りは、継続的かつ一貫した改善よりも、短期的な利益を優先させる。
  3. 締め切りは、実行可能なものではありません。チームが期限に間に合わなかったときには、それについて生産的なことをするには遅すぎるのです。

 

「仕事は割り当てられた時間を満たすために拡張する」というパーキンソンの法則でさえ、締め切りが無意味であることは変わりません。

 

なぜなら、この法則は、締め切りが存在しない場合、仕事が無限に伸びるとは言っていないからです。むしろ、締め切りを設定すると、どんなに大きな安全バッファーを追加しても、その締め切りまで仕事が延びることを認めているのです。

 

それは、プロセスにプリエンプションポイントを導入することと、取出しポリシーに留意し冷酷かつ定期的に優先順位をつけることです。

 

プリエンプションポイントとは、チームがタスクの進捗状況を確認し、スコープを縮小するか、戦略を変更するか、タスクを中止して損失を完全に削減するかを決定するための一定の時間間隔のことです。

 

プリエンプションポイントは、実行可能で、予測可能で、ばらつきに強く、長期的な継続的改善のインセンティブを与えるので、締切よりも優れています。

 

最後に、待ち行列の規律に関して言えば、FIFO先入れ先出し)がエンジニアリングシステムで使用するのに最適な待ち行列の規律であることはほとんどありません。それよりも、システムが常に最も短く、最も価値のあるものを処理していることを確認する必要があります。

 

そうすれば、システムの処理速度を向上させることはできなくても、その時点で可能な限り最高のものを供給することによって、システムが提供する価値を高めることができるのです。

30代ではじめてブリーチをした話

はじまり

リモートワークを推進している企業が多くなっていますが、リモートワークならではの悩みも多くなってきたと思います。個人的な悩みの一つに「社員の顔がわからない」というのがあります。これは入社したての方なら誰でも思い当たると思いますが、リモートワークだとそもそも挨拶できる機会もないのでなかなか解決が難しい問題です。しかし、これは新入社員だけでなく、既存社員も新入社員がだれだかわからない、という問題につながると思います。

 

そのようなことを金曜日に上司に相談したら、帰ってきた言葉がこちらです。

「金髪にしたら?」

え?

「髪染めるのは誰にでもできるし、セルフブランディングは大事だよ」

とのことでした。

今まで髪を染める理由を理解できていなかったのですが、この言葉を受けて、人生ではじめて髪を染めてみようかと思います。

 

店選び

さっそく土日に利用できるお店を探します。知り合いに聞いたら「少なくとも1万円は出してちゃんとした美容室行った方がいいよ」とのこと。[カラー うまい 美容室 メンズ]で検索をし、近い順にクチコミを見ながら決めていきました。それでも膨大なお店の数がありますので、男性もよく利用している所を探していきます。

メニューはブリーチとカラーが必要なので、ツーカラーで1万6千円という価格です。

 

施術中

施術中は特にこれといった話はしていないのですが、人生で始めて髪を染めると言うことで、経緯は結構聞かれました。「会社愛半端ないですねw」というノリでしたが、丁寧にカラーリングしてもらいました。

ブリーチをしてもらった結果がこんな感じ。



こんなに綺麗に金髪になるんだ、とわりと感動していましたが、完全にヤンキーですね。

 

美容師からも「ブリーチすると一人東京リベンジャーズになるのは避けられないのですが、もう一色塗っても東京リベンジャーズが追ってきますね」そこから2色目を塗るにつれて、テンションが上がってきたのか、「これって実はタイムリープしてます?」「握手するとトリガーになったりしますか?」と東京リベンジャーズネタでいじられつつも完成した色がこんな感じ。



「もう少し赤くなったら一人SEKAI NO OWARIですね」という仕上がりになりました。

最終的にはセックスピストルズジョニー・ロットンみたいな髪になり、社会人として色々なものを置き去りにしてしまいましたが、職場ではどんな反応されるのだろう? もう完全にセルフブランディングという言葉は置き去りになってしまっていますが、顔を覚えられたらいいな、と思います。

Rust勉強メモ1

7月16日に開催されたRustのもくもく会に参加したので、勉強したことをメモしておきます。 基本的にはソシムさんから刊行された『手を動かして考えればよくわかる 高効率言語 Rust 書きかた・作りかた』を動かしながら読み進めています。

インストール

curl -- proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

パス

export PATH="$PATH:$HOME/.cargo/bin"

バージョンの確認

rustc --version

バージョンのアップデート

rustup update

VSCodeをインストール。拡張機能でRustが非推奨になっており、代わりにrust-analyzerをインストール。

Hello Worldのコード

fn main(){
    println!("Hello World")
}

コンパイル

rustc hello.rs

実行

./hello

Rustは必ずmain関数を記述する必要がある。このmain関数をエントリーポイントという。 Rustには末尾に「!」をつけることがある。これはマクロであることを示している。

文字列に埋め込むには、{}の中に変数を置き換えて表示する Rustでは変数への代入を「値を変数に束縛する」というらしい。

fn main(){
    let price = 300;
    println!("ガムの値段は{}円", price)
}

四則演算の問題。答えを見ずになんとなくで書いたコード

fn main(){
    let bike = 80.0;
    let train = 300.0;
    let moon = 384400.0;

    println!("バイクの場合は{}日です", moon / bike / 24.0);
}

適当に書いた割には合っていたようですが、「train変数が使われていないよ」という警告が出る(おもしろ)。

warning: unused variable: `train`
 --> q1.rs:3:9
  |
3 |     let train = 300.0;
  |         ^^^^^ help: if this is intentional, prefix it with an underscore: `_train`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

実行結果

バイクの場合は200.20833333333334日です

Rustは型に厳しい言語なので、整数と実数は明確に区別される。

■for文の書き方

for 変数 in 開始地 .. 終値 +1 {
    処理
}

■if文の書き方

if 条件1 {
    処理1
} else if 条件2 {
    処理2
} else {
    処理3
}

■print!とprintln!の違い

print! = 改行がない

println! = 改行がある

■変数

letで宣言した値はイミュータブルな変数になる

let 変数名 = 値;

ミュータブルな変数にするにはmutをつける

let mut 変数名 = 値;

Rustでは不変な変数が基本となっている。 余計にmutをつけると、以下のように警告が帰ってくる

fn main(){
let pc = 98000.0;
println!("A社は{}円です", pc * 0.8 +1200.0);
println!("B社は{}円です", pc * 0.9);
}
warning: variable does not need to be mutable

Rust勉強メモ1

7月16日に開催されたRustのもくもく会に参加したので、勉強したことをメモしておきます。 基本的にはソシムさんから刊行された『手を動かして考えればよくわかる 高効率言語 Rust 書きかた・作りかた』を動かしながら読み進めています。

インストール

curl -- proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

パス

export PATH="$PATH:$HOME/.cargo/bin"

バージョンの確認

rustc --version

バージョンのアップデート

rustup update

VSCodeをインストール。拡張機能でRustが非推奨になっており、代わりにrust-analyzerをインストール。

Hello Worldのコード

fn main(){
    println!("Hello World")
}

コンパイル

rustc hello.rs

実行

./hello

Rustは必ずmain関数を記述する必要がある。このmain関数をエントリーポイントという。 Rustには末尾に「!」をつけることがある。これはマクロであることを示している。

文字列に埋め込むには、{}の中に変数を置き換えて表示する Rustでは変数への代入を「値を変数に束縛する」というらしい。

fn main(){
    let price = 300;
    println!("ガムの値段は{}円", price)
}

四則演算の問題。答えを見ずになんとなくで書いたコード

fn main(){
    let bike = 80.0;
    let train = 300.0;
    let moon = 384400.0;

    println!("バイクの場合は{}日です", moon / bike / 24.0);
}

適当に書いた割には合っていたようですが、「train変数が使われていないよ」という警告が出る(おもしろ)。

warning: unused variable: `train`
 --> q1.rs:3:9
  |
3 |     let train = 300.0;
  |         ^^^^^ help: if this is intentional, prefix it with an underscore: `_train`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

実行結果

バイクの場合は200.20833333333334日です

Rustは型に厳しい言語なので、整数と実数は明確に区別される。

■for文の書き方

for 変数 in 開始地 .. 終値 +1 {
    処理
}

■if文の書き方

if 条件1 {
    処理1
} else if 条件2 {
    処理2
} else {
    処理3
}

■print!とprintln!の違い

print! = 改行がない

println! = 改行がある

■変数

letで宣言した値はイミュータブルな変数になる

let 変数名 = 値;

ミュータブルな変数にするにはmutをつける

let mut 変数名 = 値;

Rustでは不変な変数が基本となっている。 余計にmutをつけると、以下のように警告が帰ってくる

fn main(){
let pc = 98000.0;
println!("A社は{}円です", pc * 0.8 +1200.0);
println!("B社は{}円です", pc * 0.9);
}
warning: variable does not need to be mutable

NFT Summit Tokyoに行ってきた感想

2022713-14日に蒲田でNFT Summit Tokyoというカンファレンスが開催されたのですが、せっかくの休み期間なので参加してきました。

 

NFT Summit Tokyo 第2弾

https://www.nft.pivot-tokyo.com/

印象に残ったセッションを簡単にメモしてきましたので、こちらに公開します。

全体の感想としましては、やはりWeb3に対してどのように対応していけば良いのか答えがまだはっきりとわからない手探りの状態なのだな、と思いました。登壇者の皆様が強調していたのは、いまが乗り遅れないためのチャンスで、いま動けるかどうかで23年後に大きく変わるとのことでした。

今回のカンファレンスを受けた感想として重要なこととして、まず自分がしっかり勉強をする(Rust勉強しないとな)ことと、Web3を構成するもの(暗号通貨、NFTDAO)を構造化し、自分たちができることを見つけ、まずはそこから初めていくことだと思いました(まずはNFTのマーケットを作るのが良いそうです)。

 

以下、メモです。

[M-2] NFTブロックチェーンの未来アジアWeb3企業のグローバル戦略とは

データは企業のサーバーに保存される所有することはなかったが、これからは見る、書く、所有する、といった強力なパラダイムに望む望まないにかかわらず、全てのWebWeb3に移動する。

今後は518ヶ月で5%10%の人がブロックチェーンのゲームに移動してくる。ただし、期待されるほど高品質なものは出てこない。

 

西洋とアジアではプロックチェーンポリティックス(仕組み)の理解が違い。アジアにおいて民主主義はまだ若く、資産の所有権や投票といった合意主義の歴史は西洋のほうが長い。Web3自由形のオープンシンキングを理解するためには哲学、社会学、政治、金融などを理解する必要がある。単純に技術の話だけではなく、そして明確なものではない。人間の扱っているものすべてに関わる。

 

中国は自由に参入できていないインターネット初期にも起こった。最終的にはオープンなインターネットを諦めなければならなかった。

 

——

[M-3] シリコンバレーから見たWeb3の「今」

日本は働き方が変わっていない。

今は暗号通貨の価格がすごい下がっているけど、前の冬ほどは下がらない。ここ23年は加熱しすぎており、詐欺みたいなプロジェクトにもお金が集まっていたので自然淘汰されている段階。2024年にむけてコツコツと技術革新をしていくのが重要。

 

リップル12年目でかなり老舗。リップルの目標としては以下の通り。

  • 価値があるインターネットを実現する
  • 日本円やドルといった通過に限らず価値のあるものを財産にする
  • 今まで価値として見られなかったものを見つめ直す
  • 国際送金にブロックチェーンを活用していく
  • ブリッジ通過として活用していく
  • 全ての価値あるものをトークン化していく

リップルは国際送金に強いが、価値の交換ができるプラットフォームを目指している。

アメリカも薔薇色ではない。アメリカでは暗号通貨の存在が法的にははっきりしていない。日本では2017年に資金決算法で整っているのでそれほど遅れてはいない。

 

これから盛り上がる領域

2020DeFi

2021NFT

2022DAO

 

DAOにはトークンを持ってないと入れない、投資系のDAOとかソーシャル系のDAOとか実際に入ってみて、トークンをもらうのがおすすめ。「日本で広めるから!」とか言う。

 

試行錯誤の段階だけど、トークンを持っている量によって意思決定をするのは金融主義になってしまう。なので譲与できないトークンを配布する。中央集権とDAOはケーズバイケースで使っていかれると思う。FacebookTwitterでも良いサービスを作るにはどうしてもデータを集めて機械学習の分野に行かないといけなかった。

DAOは今までなかったチョイスを選べる。破壊的なイノベーションが来た時の選択肢として、今までできなかったことを取り入れて、独自に進化していく。

 

日本のコンテンツはすごい。日本大好きって人は多い。NFTは最初から世界に販売していく、ファンコミュニティの運営は日本が強い。新しい日本にもDAOが生まれるといい。

 

——

[M-15]ゲーム x メタバース

メタバースにおけるブロックチェーンゲームの可能性

 

メタバースは定義が様々だけど、これから10年間にかけて大きくなっていくと思われる。コミュニティをどう作っていくのかが重要。

Daoコミュニティをどう作っていくか?

 

MyCriptヒーロー ずっと世界ナンバーワンのブロックチェーンゲーム。Opensea9割がマイクリの取引で2万イーサを売り上げた。企業に頼らないネットワークを作る。

ガバナンス好きな人が好きな世界を作っていくのがメタバース(同人誌)、ユーザーがゲームを作っていくのがDAOWeb3というのはファンベースで作られていく。完全独立法人からDaoへの移行が難しい。

 

DAOを回していく。専門性が低い人たちが集まるとうまく行かないけど、それは多数決や民主制の問題。必要なこととしてコミュニティの質を高めていく。ゲームの場合はどうしても中央集権で立ち上げるしかない。一部分だけコミュニティに譲渡していくのが定石。DAOは手段なので、全部をDAOにする必要はない。一部のキャラクターの名前をDAOで決めるとか(メタバースは多用性)。企業が何かを変更すると炎上することが多いが、ユーザの投票で決めれるのは責任の共有ができる点がある。51%あったら、それは正。

 

レディ・プレイヤー1という映画はコミュニティベース。

 

NFTは暗号資産ではない。株と違ってインサイダー取引の規制ができていないので、自分たちで規制していくしかない。

 

トークンの発行が日本だと難しい。シンガポール法人で作っている。

 

日本は今ガイドラインを作っている。主に賭博罪とマネロン。3Dは日本が優先して作っていって欲しい。メタバースNFTもグローバルが作っている。仮想通貨はダウントレードだけど、今は仕込みの時期。若い人たちシンガポールに来ている。すごい重要な産業になるので日本国内で作っていく。冬の時代だからこそチャンス。ここから12年がチャンス。

 

——

[M-4] Web3の本質と未来「イーサリアムの原則」

イーサリアム財団の中に日本人は6人しかいない。

ビジョンがないのは生き残られない。イーサリアムは分散型、公共性、誰にでも平等なアクセスなどに拘っている。主要者がいなくなった後でも生き続けるようにするにはどうすれば良いのかを考えている。

イーサリアムが生き残れたのはビジョンがあってプロダクトではないから

  • 長期思考
  • 引き算の美学
  • 価値観を守る(継続する)

 

キーワードはDegen to Regen

Daoのコミュニティを作っていくのは日本はすでにやってきていた。ツールは人間がどう使っていくかが重要で、日本人はガバナンスが自分たちでできる。資本主義も共産主義も政府が誘導してというのはうまく行かなかった。

 

——

医療とWeb3

シリコンバレーから最新報告

薬の開発時にDAOを使用する。メディカル危機の管理や薬局の開発に使用している。BiotechDAO。例えば不老不死の研究をしてください!などに票が集まる。

どこの国からどこの人でも入っていける。リサーチファンディングによく使われている。メリットとして薬局のコスト削減につながる(薬一個の開発に10億ドルから20億ドルかかる、開発だけに年間900億ドルかかっている)

 

——

クリエイター vs 政治家 日本のweb3 推進政策と課題

Web3を国家戦略にした

24の課題と提言をした(NFTホワイトペーパー(案):https://www.taira-m.jp/2022/03/nft.htmlWeb3は範囲が広く全体を変えないといけない。かなり大きな仕事。担当する省庁がない。ガバナンストークン課税問題とか、暗号資産に対する税金MAX55%とか。

 

日本は動きが遅いというのはその通りだけど、英米はまずはやってみる、問題があれば議論をするといったアジャイル的な運用が国単位でできている。今はどうやって成果を得るか絶望的な状態にはなっている。Web3は日本だとガラパコスではなく無人島になる。日本ってどれくらいの価値があるの?って話。

いま起業家に相談されたら、まずシンガポールでやったほうがいいよ、と言う。政府の理解に時間がかかる。

 

アーリーマジョリティの数が少なすぎる。クリプトは積み上げ式で知識を深めていく。

誰に聞いても正解がない。日本が有利なのは知財。アニメ、ゲームといったサブカル。中国に対抗するWeb3は西洋諸国の国家戦略としては正しい。

——

 

[S-1] クリエイターから見るNFTの戦略

楽しいからやっている。金儲けの話からではなく、何が楽しいか、から話さないと乗れない。

 

NFTは子どもが手を出せないのが一番きつい。ビックリマンシールみたいなコレクションができない。そうでないと文化的な広がりが持てない。

広げるにはストーリーが重要、報酬が分配される。

 

[M-7] Web3が可能にする世界のジャパン・クリエイティブ

初回から世界を目標としている。規模感から世界展開をするのが普通。ひたすらインディーズで行っていく。NFTはアートといった一つの視点からみると不可解になる。

 

パーティーに行くと多用性がなく白人の男性が多いけど、ギャルバースは女性も多く国も様々。コミュニティとしてバランスを取っていく。プロジェクトで回していくには、アーティストリスペクトが重要。アーティストを表に出してあげることとか。

 

大変なこととしては、NFTの価値観を共有していく。大変なことは予測しておく、サーバーがダウンしたら、こういうコメントを出すようにするとか。

——

[S-2] How to dive into web3

大企業がWeb3に入っていくために

Web2ではデータを所有しても、企業のサーバーに入っているので、企業が潰れたらなくなる。Web3はインターネットでいうとドットコムバブルが終わる時期。暗号資産にいきなり入るのは難しい。まずはNFTから始めるのが始めやすい。→だれにNFTを配るのかが問題。NFTを配るのに対象者が今はほぼいない。持続可能性の仕事をできるのかが考えなければならない。

 

だれでも参加できる企画をどうデザインしていけばよいか?

炎上しないためにはWeb3としての思想を

 

技術的検討項目

チェーンをどうするか?

イーサ。ポリゴン。ソラナ。ASTARLINE

処理スピード

保守性

安全性

 

支払い通過をどうするか?

ウォレットをどうするか?

マーケットプレイスをどうするか?

財務会計的視点

ガバナンス問題(ウォレットの管理とか)

 

BeReal1日に2回しか投稿できないSNS。希少化された帰属意思に再帰してきた。

 

ちゅらうみ水族館のジンベイザメの所有権を売るとか

——

2日目

Web3の未来

Web3は人々の生活をどのように変えるのか

ファンクラブをどうやって長く価値を持たせるか。

Web3の一番面白いところは透明性とか、決算手数料とかではなく、ロングターンで考えて直接参加者とアーティストがつながることができる。

マーケットをどう作っていくのかが日本のポイント。

本当は自分の人生は自分が経営者にならないとならない。

自分が表現するために勉強していく必要があり、それが3年後に差がでそう。まずは4割からスタートしていく。

Web3は前に行くしかないので、安心して突っ込んでください。

 

———

Web3で勝負をかける若き起業家が描く未来

Astar Networkはレイヤー1の日本発パブリックチェーン。チェーンとチェーンを繋ぐマルチブロックチェーン

Webがでてから日本は負け続けている、次の成長企業ってなに? Web3.0のプラットフォームを取りに行く。

Web3の事業は税制が一番厳しいけど、税制を変えるのは企業家の仕事ではない。

技術レイヤーで戦える技術者が出てくる必要がある。

Web3.0は現状ではインフラに問題がある。チェーンとチェーンをつなぐプロトコルがまだ整っていない。

 

日本人ってそもそもあまり0から1を作った経験が少ない。イノベイティブは欧米に任せてもよくて、日本人の強みは改善にある。

日本はマーケットが構造的に小さくなっていくので、外貨を稼いでいく人が増えていくといい。

 

開発言語はSolidityが主流だけど、イーサリアムを動かすものとしてできたので、スマートコントラストでの汎用性が高いとはいえない、またセキュリティがよろしくない。

Rustネイティブだと型が厳格なので、コンパイラエラーがわかりやすい。セキュリティも安定している。パフォーマンスもよい。Web3をやるならRustWebアセンブリーがよい。Polkadot100%Rust

——

独自のNFTプラットフォームを構築するには:技術からマーケティングまで

 

宣伝はWeb2がまだまだ強いので、Web2の人たちは拡散することに強みがある。

まだ1%イノベーションしかない。

DAZNは新規にNFT事業に入った。

真ん中のサブスクを軸に、スポーツを中心にいろいろな可能性に挑戦する

企画自体は2年ほど。→権利をどう獲得するかが問題にあった。

 

開発はMIXIさん、グルーバルでNFTマーケットプレイスDapper)を作っていた。

コンテンツとして動画をもとに選手をNFT化。選手、クラブ、Jリーグとの権利獲得が難航

 

まずは一人でも多くの人に買ってもらうので安価で販売している。

今度セカンダリマーケットプレイス(ユーザー同士で自由に取引ができる)を作る予定。平等にするために抽選販売をしている。

NFTを持っていたら、選手に会えるとかの特典を行うかも。

———

Web3プロダクトの刺さるUXの作り方

クチコミ大事!

UIとしてはハントの報酬がある。

安心安全を伝えるためにSNSの更新がある。

PMFPCMを意識する。Web2Web3はどうでも良くて、ユーザーが誰で、何を提供するか?が大事

 

———

アニメを中心としたコンテンツプロデュース会社が、なぜNFT事業にチャレンジするのか?

AnimapはジャパンコンテンツのNFT事業進出を支援している。

まずはイーサから始めて、秋にポリゴンを実装する。

イーサかクレジットカードで購入可能、エアドロップができる。

デジタルコンテンツ開発から、販売までを一気通貫でできる。

コンテンツ価値の最大化、コンテンツの価値を最大化させていく。

どうやってファンを繋ぎ止めていくのか?

成功したと言えるプロジェクトはまだない。

 

ファンサイドの課題感

- ウォレットをつくらないといけない(体験設計)

- 作品愛がある

- すでにあるもので満たされている

 

IPホルダーサイドの課題感

- 製作委員会の壁

- 作品ファンとNFTファンとの向き合い方

- リスクにつながる

 

どうやったらファンとのコミュニケーションを成功させられるか?

- IPの持続価値を理解する

- ファンの推しを知る

 

———

才能ある世界のWeb3プレーヤーを日本に惹きつけるためには

英語で情報を入手するとよい、もちろん考え方を変えるのも重要

まったく違う挑戦にチャレンジになる

 

10億人の人たちにアピールする必要があるが、日本の場合だとアニメ・漫画があるからIPとしてはとても強い。日本にはnftのマーケットリーダーになれるか可能性がある。日本が投資するにはそこだと思う。

クリプトを作る会社、教育、ローカリゼーション、エコシステムなど課題があるがまだ日本市場は重要だと思われる。

 

エンジニアを雇うにはどうすればいいのか

快適さや成功を手助けする必要がある。高い給料を払う、若い日本人が英語を話せるかが重要

日本のWeb3にお会社は10年もたっていない。Web3は世界で最も動きが早く、これからもっと早くなると思う。