Flatt Security、ソフトウェアサプライチェーン向けセキュリティプラットフォームShisho Cloud事前登録を受付開始

Flatt Security、ソフトウェアサプライチェーン向けセキュリティプラットフォームShisho Cloud事前登録を受付開始

ソフトウェア開発者向けのサイバーセキュリティ事業を展開するFlatt Securityは3月9日、ソフトウェアサプライチェーンのためのセキュリティプラットフォーム「Shisho Cloud」(シショウクラウド)のサービス公開に先立ち、事前登録を同日より開始することを発表した。事前登録したユーザーには、4月上旬より優先的に案内する予定。

Shisho Cloudの事前登録は、公式サイトより行える。3月末日までに登録すると、初期費用が無料になる特典も用意されている(適用条件あり)。

Shisho Cloudは、開発したソフトウェアを顧客に届けるまでの一連の過程(ソフトウェアサプライチェーン)に関連するセキュリティ上の問題発見から修正までを、半自動的に支援するセキュリティプラットフォーム。GitHubなどのソースコード管理システムと連携することで、運用状態やその上で管理されているソフトウェアの依存関係・設定ファイルなどを継続的かつ自動的にレビューする。

これにより、自社組織がソフトウェアサプライチェーンに関するリスクをどの程度抱えているか、どのように改善できるかを、セキュリティフレームワークに沿って評価・モニタリングすることが可能という。Flatt Securityが提供するセキュリティチェックの他にも、自社固有のポリシーを定義・利用することも可能。この際、ポリシー記述言語Rego、WebAssemblyにコンパイル可能な複数のプログラミング言語を利用できる。

また、複数の開発チームが組織内に存在している場合や、複数のソースコード管理システムが利用されている場合など、開発組織全体を横断してリスク管理を行なうユースケースにも対応しており、全チームの状況を俯瞰してリスクを把握することもできる。

サービスの開始にあたり、直近では、ソフトウェアサプライチェーンに存在する重要なリスクの発見と修正の半自動的なサポートを目的とした下記の機能が提供される。Flatt Security、ソフトウェアサプライチェーン向けセキュリティプラットフォームShisho Cloud事前登録を受付開始

  • GitHubなど、各種ソースコード管理システムの安全な運用や監査を補助する機能
  • IaC (Infrastructure as Code) コードを継続的かつ自動的にレビューし、その中の設定不備の検出・具体的な修正方法の提案を行う機能
  • クラウドサービスのAPIキー・アクセスキーなどのシークレットや、個人情報などが、ソースコード内に不適切にハードコードされていないかを継続的に検査する機能
  • ソフトウェアパッケージの依存関係を解析・管理することで、既知の脆弱性が存在する依存先や知らぬ間に変更されうるような依存先、悪意のある依存先を検出し、更新を提案する機能
  • CI/CDワークフローの外部スクリプト・ワークフローへのリスクのある依存や、外部からのスクリプト注入を許すようなワークフローを検出する機能

 

長期的には、SLSAin-totoのようなソフトウェアサプライチェーンに関するフレームワークや、OpenSSFのような同領域に関するコミュニティの各種プロジェクトの展開を踏まえ、開発環境から実際のアプリケーション運用環境まで一貫したサポートの提供を予定しているという。

デザイントークンやアセットを自動的に収集、保存、配布することでVIの統一を支援する「Specify」

Figma(フィグマ)とGitHub(ギットハブ)の共通言語を作るスタートアップ、Specify(スペシファイ)をご紹介しよう。Specifyは、あなたのデザイントークンとアセットのためのセントラルリポジトリとAPIとして機能する。言い換えれば、デザイナーは標準的なFigmaファイルを更新することができ、変更はGitHubリポジトリに反映される。

このスタートアップは、Eurazeoが主導する400万ユーロ(約5億1600万円)のシードラウンドを調達した。BpifranceのDigital Ventureファンド、360 Capital、Seedcampも同ラウンドに参加した。EurazeoのClément Vouillon(クレマン・ヴイヨン)氏やeFounderのDidier Forest(ディディエ・フォレスト)氏など、ビジネスエンジェルも出資している。

組織がデザインに本腰を入れ始めると、ボタン、アイコン、フォント、ロゴ、色など、統一したスタイルでデザインシステムを作りたくなるものだ。例えばログインページは、Facebook(フェイスブック)、Twitter(ツイッター)、Gmail、Pinterest(ピンタレスト)ではそれぞれまったく異なる印象を与える。

とはいうものの、デザイナーと開発者の双方がこれを手作業で行っていることが多いのが現状だ。デザイナーはConfluenceやNotionでデザイントークンやアセットを使ってドキュメントページを作成する。そして開発者は、手作業でドキュメントをチェックし、最新のエレメントを使用しているかどうか確認しなければならない。

画像クレジット:Specify

Specifyは、デザイントークンやアセットを保存するセントラルリポジトリとして機能する。ユーザーはまず、1つまたは複数のソースと1つまたは複数のデスティネーションでSpecifyを接続する。

例えばSpecifyを使い、Figmaファイルから情報やデータを直接取得することが可能だ。そしてデザイナーはFigmaで何かを更新することができ、その変更はSpecifyのリポジトリに反映される。Specifyは単一の真実のソースとして機能するわけだ。

だが、変更はアプリケーション内でより速く反映されることもある。何かが更新されると、Specifyは自動的にGitHub上でプルリクエストを作成することができ、コマンドラインインターフェイスもある。開発者はワンクリックで変更を受け入れることができる。このようにして、色、ロゴ、フォントなどが、手動で作業することなく更新される。

Specifyは、自社製品の対象をFigmaとGitHubに限定するつもりはないようだ。この先、Dropbox(ドロップボックス)やGoogleドライブなど、さらに多くのデータソースを導入する予定だ。そしてNotionなど、より多くのアップデート先に対応する予定もあるという。特に、1つのデザイン変更を複数の更新先にプッシュできる機能があれば便利だろう。

製品ビジョンは明確だ。Specifyは、デザインチームを一元化する接着剤になりたいと考えている。「当社のアプローチは、Segment(セグメント)とよく似ていますが、デザインのための製品だと考えています」と、共同創業者兼CEOのValentin Chrétien(ヴァランタン・クレティアン)氏は筆者に語った。

画像クレジット:Specify

画像クレジット:Balázs Kétyi / Unsplash (Image has been modified)

原文へ

(文:Romain Dillet、翻訳:Den Nakano)

GitHubがスポンサー専用リポジトリを発表

数年前、GitHub(ギットハブ)はスポンサーシップを導入し、それによって誰もがオープンソース開発者に直接資金的援助を行えるようになった。米国時間2月2日、GitHubはこのコンセプトをさらに推し進め、スポンサー専用のリポジトリ、つまりスポンサーだけがアクセスできるプライベートなリポジトリを立ち上げた

これはある意味、現在のトレンドに沿ったものだ。Twitch(ツイッチ)やSubStack(サブスタック)などのプラットフォームも、結局はスポンサーに何か特別なものを提供することで、サブスクリプションのインセンティブを得ている。だがオープンソースの世界ではそのようなことはあまり例がなく、これはオープンソースの精神に反するものだと考える人もいるかもしれない。

GitHubによると、ここでのアイデアは、資金提供者に対してプロジェクトが構築されていく過程への早期アクセスを提供すること、あるいは、同社が「スポンサーウェア」と呼ぶ、スポンサーのためだけのプロジェクトへのアクセスを提供することだという。開発者はこのリポジトリを利用して、スポンサーとのディスカッションを行うこともできるとのこと。また、開発者が柔軟に対応できるように、特定のリポジトリを異なるスポンサーシップレベルに紐づけることも可能だ。

画像クレジット:GitHub

スポンサー専用リポジトリに加えて、GitHubでは他にもいくつかの細かい変更を行った。例えば、開発者はカスタムスポンサーシップの最低金額を設定できるようになり、スポンサーシップの階層ごとにカスタムウェルカムメッセージを書けるようになる。また、スポンサーシップ対応のリポジトリに新しいコールトゥアクション(CTA)を追加し、プログラムの可視性を高めている。

GitHubのスポンサープロダクトリードであるJessica Lord(ジェシカ・ロード)氏は、2日の発表でこう述べている。「GitHubでのディスカバリー体験を向上させ、コミュニティが依存関係を調べたり、誰をサポートするか決めたりするのを容易にし、スポンサーを利用するメンテナーがオーディエンスやコミュニティ、全体的な資金調達を拡大できるように支援するための今後の取り組みにご期待ください」。

画像クレジット:Michael Short/Bloomberg via Getty Images

原文へ

(文:Frederic Lardinois、翻訳:Aya Nakazato)

ハードウェア開発者のための「GitHub」を目指すコラボハブAllSpice

AllSpiceの創業者、カイル・デュモン氏とヴァレンティナ・ラトナー氏(画像クレジット:Harvard Innovation Labs)

AllSpice(オールスパイス)はハードウェア開発のためのコラボレーションハブだ。GitHub(ギットハブ)に触発され、DevOpsエコシステムを構築することを使命として、プライベートベータ版から登場した。

創業者のValentina Ratner(ヴァレンティナ・ラトナー)氏とKyle Dumont(カイル・デュモン)氏は、2019年にハーバード大学で出会い、2人とも工学修士とMBAの両方を取得した。2人は、物事を進めるのにPDFや電子メールに頼るという、ソフトウェア開発に比べて遅れているハードウェア業界でのそれぞれの仕事に対するフラストレーションで意気投合した。

「ソフトウェア業界は強力なコラボレーションと自動化を備えている優れた開発者ツールで一斉にスタートしているように感じていました」とデュモン氏はTechCrunchに語った。「私がヴァレンティナに会ったとき、私たちはどのようにこの業界を修正することができるか、市場の規模にどのような影響を与えることができるか、アイデアを出し始めました」。

未だに手作業で行われているタスクが多く、エンジニアは書類作成やスプレッドシートにかなりの時間を費やしているため、エンジニアがハードウェア製品の設計や構築に大半の時間を割けるようにすることが、AllSpiceの背景にある考え方だとラトナー氏は話した。

AllSpiceのデザインレビュー機能(画像クレジット:AllSpice)

リモートワークや近年のチップ不足を背景に、AllSpiceや他の企業は「ハードウェアのためのGitHub」が必要だと考えている。リモートでほとんど何でも作ることを可能にするコラボレーションツールを作っているWikifactory(ウィキファクトリー)は、2020年末に300万ドル(約3億5000万円)の資金調達を発表した。2021年10月に1200万ドル(約13億8000万円)を調達したFlux(フラックス)は、ブラウザベースのハードウェア設計ツールを開発中だ。

関連記事
どんなものでもリモートで作る自称「ハードウェアのGitHub」Wikifactoryが4.7億円を調達
リモートでのコラボで活躍するブラウザベースのハードウェア設計ツールFlux、約13.6億円調達

AllSpiceのツールで、エンジニアリング専門の人は自分のプロジェクトを管理し、チーム内の関係者と共同作業ができるようになる、とデュモン氏は話す。AllSpiceは、GitHub、GitLab(ギットラボ)、Bitbucket(ビットバケット)などのツールと互換性があり、ハードウェアチームが修正、レビュー、リリースを1カ所で管理するための一種のホームベースとして機能する。

AllSpiceは2020年にプレシードラウンドを調達した。そして、Bowery CapitalとRoot Venturesが共同でリードし、Flybridgeとエンジェル投資家が参加した320万ドル(約3億7000万円)のシードラウンドをこのほどクローズした。累計調達額は380万ドル(約4億4000万円)となった。

2021年は、数百の企業向けユーザーコメント、30以上のプロジェクト、数百のプロジェクトリポジトリが作成され「信じられないような採用」があったとラトナー氏は述べた。この勢いを維持するために、新しい資本は継続的なインテグレーションとデリバリーのためのエンジニアリングとマーケティングの新規雇用に投入される予定だ。

「私たちは、開発者主導のアプローチをとっています。これは、ソフトウェア業界ではしばらく前からしっかりと確立されていることですが、ハードウェア業界では、まだかなり営業が強いのです。業界に追いついていない販売手法もあるため、私たちはまずエンジニアに役立つ製品を提供することを心がけています」。

AllSpiceはツールに依存しない。幅広い企業にアピールできるよう、統合のための別のCADツールをもたらし、そしてより多くのものがデジタルで非同期であることから、環境の変化にハードウェアチームが迅速に対応できるようにする、というのがAllSpiceの計画だとラトナー氏とデュモン氏は話す。

一方、Bowery CapitalのゼネラルパートナーであるLoren Straub(ローレン・ストラアブ)氏は、AllSpiceを紹介されたとき、同社は製品主導の成長アプローチに注目していたと述べた。ストラアブ氏が最もよく目にしたものは、サプライチェーン、製造、オートメーションと関係があり、ハードウェアも含まれていた。

ストラアブ氏は、創業者たちがソフトウェアとハードウェアのエンジニアリングの経験を持ち、ハードウェア開発がいかに困難で時代に遅れを取っているかを目の当たりにし、それを経験していたことに魅力を感じたという。

「事前調査を進めていくなかで、今まで見たこともないようなフラストレーションが溜まっているのを目にしました。人々は、そのエクスペリエンスがいかにクリエイティブな体験であるかを聞いて、いくつかのソフトウェアツールに自分達のワークフローを無理やり取り込もうとしたが、うまくいかなかった、とさえ言っていました」と付け加えた。「ヴァレンティーナとカイルは、ハードウェアのために適切なツールが作られれば、どれだけ良くなるかを深く理解していたのです」。

「VCになる前、私は10年以上ハードウェアエンジニアリングに携わっていました」と、Root Venturesのパートナー、Chrissy Meyer(クリッシー・メイヤー)氏は電子メールで述べた。「Appleのような大企業がスタートアップと共通していたのは、スクリーンショットを使ってデザインレビューをまだ行っていたことです。ハードウェアエンジニアがGitHubやJIRAのようなソフトウェアツールを寄せ集めるのを見たことがありますが、それらのツールはコードのために作られたもので、CADのためのものではありません。ヴァレンティーナとカイルに初めて会ったとき、私はすぐさま興奮しました。というのも、あったらいいなと私がいつも思っていたツール を彼らが説明してくれたからです」。

原文へ

(文:Christine Hall、翻訳:Nariko Mizoguchi

コードとその変更を視覚化可視化するCodeSeeがセカンダリーシードで約8億円調達

CodeSeeは、コードベースのすべてのパーツがどのように組み合わされているかを開発者が理解するのを助ける一連のツールを構築している、その名にふさわしいスタートアップだ。米国時間1月20日、同社は2020年に受け取った300万ドル(約3億4000万円)に加え、700万ドル(約8億円)のセカンダリーシードを発表した。このラウンドは、新たな投資家である Wellington Access Ventures、Plexo Capital、Menlo Ventures に加え、最初のシード投資に参加した複数の業界エンジェルも加わっている。

同社のCEOで共同創業者のShanea Leven(シャネア・リーベン)氏によると、同社はコードベース全体を理解するという、どの開発者もその経験レベルに関係なく、特に新しいコードベースに出会ったときに苦労する問題を解決しようとしているという。

「初めて見るコードベースに対して、誰でも一種の恐れを感じ、圧倒されてしまいます。自分がこのコードベースに貢献できるという自信が持てるのは、かなり後になってからです。どんなに経験を積んでいても、そうです。誰にでもひるむ時があり、またコードベースは毎日変化するため、理解が追いつかないこともあります」とリーベン氏はいう。

リーベン氏によると、同社は2021年9月に同社のオープンソースのOSS Portプロジェクトを取材してからも成長が続いており、現在、数社と一緒にテストしている有料バージョンももうすぐリリースできるという。

関連記事:CodeSeeが開発者によるコードベースの可視化を支援するオープンソースプロジェクト「OSS Port」を開始

「これまで作ってきたチームやエンタープライズ向けのバージョンは完成間近です」とリーベン氏はいう。またReview Mapsという新しいツールも開発中で、これはGitHub上でコードベースに変化が生じたらそれらを視覚化するというものだ。変更されたファイルをアルファベット順にリストにする従来の方法では、どこがどう変わったのか、それが全体にどのように影響するのかわかりづらい。そこでReview Mapsは、その名のとおりリストではなく変化のマップを提供する。

「あなたがコードベースに有意義な貢献を提供できるようになり、最初のプルリクエストを書けるようになったら、それはあなたが行なうコードの最初の変更であるため、コードベース全体のコンテキストの中でその変化を視覚化できることが重要です」。大規模で複雑なプロジェクトでは、何百件もの変更が毎日のようにプッシュされているため、これはなお一層重要だ。

「600ものファイルが変更されたコードレビューを見ると、非常に気が遠くなってしまいます……。なので、コードレビューがこれほど大きくなると、ほとんどの人はレビューしないようになります。しかし、私たちなら、自分の変更点を確認することができます。ズームアウトして全体像を見ることもできます。自分の変更がコードベースにどのような影響を及ぼすのか、全体像を把握することができるのです。これは、開発者にとって非常に嬉しいことです」とリーベン氏はいう。

現在、同社の従業員数は13名で、2022年中に5〜6名の増員を予定している。

画像クレジット:Yumi mini/Getty Images

原文へ

(文:Ron Miller、翻訳:Hiroshi Iwatani)

5カ月でGitHubスター2000獲得、LiveKitはメタバースにはオープンなインフラが必要だと考える

世界的なパンデミックが発生したとき、Medium(ミディアム)でプロダクト部門を担当していたRussell d’Sa(ラッセル・ダサ)氏は、全員が自宅で仕事をしているため、企業カルチャーがインパクトを受け、社員間の交流にも大きな影響を与えていることに早くから気づいていた。

「なくなったのは、同僚同士の会話や、金曜日の夜に飲むこと、一緒にコーヒーを淹れて飲むことなどでした」とTechCrunchに彼は語った。「職場で友人になるということは、最終的にどのようにコラボレーションするかを下支えします」。

2020年、Clubhouse(クラブハウス)がアルファ版で公開されたとき「すべてを変える新しい参加型メディア」として話題になったが、ダサ氏は仕事仲間のためにもそのようなものを求めていたという。

関連記事:隔離生活で求められる自然発生的なコミュニケーションを生むソーシャルアプリ

彼は、ClubhouseアプリがAgora(声網)を利用していることを知り、自分のアイデアを実現するためのデスクトップアプリの開発を始めた。ダサ氏がこのアプリをリリースすると、すぐに1300社がウェイティングリストに登録した。同氏は最終的にこのアプリを棚上げにしたが、企業は「この新しい環境では何でも試してみたい」と考えていることがわかった。

実際、ある大手ソーシャルメディア企業からは、傘下の1000人規模の企業でそのアプリを使ってみないかと持ちかけられたが、Agoraのセキュリティが心配だったという。ダサ氏は代替手段を検討し始めたが、多くは会議に特化したもので、ネイティブモバイルに対応する柔軟性を備えていなかった。

そこで生まれたのがLiveKitだ。共同設立者のDavid Zhao(デビッド・ザオ)氏を含むダサ氏のチームは、WebRTCと呼ばれるリアルタイムのオーディオ・ビデオ体験をアプリケーションで構築しスケーリングするための、無料でオープンソースのインフラを開発した。

7月にこのツールをリリースした同社は、米国時間12月13日、Redpoint Venturesと、Justin Kan(ジャスティン・カン)氏、Robin Chan(ロビン・チャン)氏、Elad Gil(エラッド・ギル)氏などの個人投資家からの支援を得てシードラウンド700万ドル(約7億9000万円)を調達したと発表した。

公開からわずか5カ月の間に、同社のツールはGitHubでトレンドを生み出し、ゼロから始まって約2000スターを獲得したとダサ氏は述べている。また、メタバースの話題が増えている中で、製品の市場適合性も証明された。

「新型コロナは私たちの世界を、オンラインで生活し、ネット上で結婚式を挙げるような世界に変えました」と彼は語る。「私たちはすでにメタバースの中で生活しており、それは2年以上前から続いています」。

同氏は、会議通話は未来のものではなく、仮想現実(VR)や拡張現実(AR)によってより現実のように感じるものになると考えている。しかし、課題は、インターネット上でいかにすばやくデータを移動させ、カメラやマイク、3Dオブジェクトに対応したインフラを持つかということだ。

LiveKitによるライブオーディオ・ビデオ体験の初期のユースケースはイベント会場のカメラだったが、あるドローン会社もこの技術を使っている。LiveKitを利用したプロジェクトが100件を超えるなど、採用が進むにつれ、ダサ氏は、ベンチャーキャピタルの支援を受けてチームの規模を拡大することを決意した。立ち上げ当初は3人だったチームが今では15人に増えたという。

現在、同社は収益を上げていないが、分析、遠隔測定、スパムや不正使用の監視、音声転写、翻訳、音声や顔の機能など、基本的な機能以外にも提供されるサービス、新しいツールが登場すれば収益を上げることができるだろう。

目下、LiveKitチームは、ツールの信頼性と柔軟性を高め、デベロッパーや彼らが構築するユースケースへのアクセシビリティを改善するための技術開発に注力していきたいと考えている。

「目標は、ネットワークの状態が悪くても動作する方法を見つけることです」とダサ氏はいう。「当社は大小さまざまな企業と話をしていますが、最大手の企業は、100万人規模のイベントをすべてインタラクティブに行うための大規模なスケールを求めています」。

画像クレジット:NurPhoto / Contributor / Getty Images

原文へ

(文:Christine Hall、翻訳:Aya Nakazato)

東京都主催のOSS共創プログラム「地域課題をハックする」がハッカソン形式で開催、東京都OSS公開ガイドラインも発表

東京都主催のOSS共創プログラム第1弾「地域課題をハックする」がハッカソン形式で開催、「東京都OSS公開ガイドライン」も発表

Tokyo OSS Party!!は10月27日、東京都と共に「テクノロジーを活用して」「オープンに」「楽しく」様々な地域課題を解決するためのイベント「Tokyo OSS Party!! 2021」の開催を発表した。開催期間は、11月20日から12月4日(オンライン開催)。参加応募は、「“地域課題をハックする” 共創プログラム〜Tokyo OSS Party!! 2021」、または「Tokyo OSS Party!! “地域課題をハックする” 共創プログラム 参加お申し込み」から行える。

同イベント内で作成したソフトウェアなど成果物は、オープンソースソフトウェア(OSS)として公開をすることを前提としており、「Tokyo OSS Party!! 2021 参加同意書」の内容を確認・同意した上で応募するよう呼びかけている。

また同イベントでは、地域課題をハックするサービスの開発を行う共創プログラム「地域課題をハックする」をハッカソン形式で実施する。募集人数は50名程度(応募者多数の場合は主催者側で選考)。年齢・居住地・国籍不問。個人エントリーの場合は、参加フォームで「個人参加(チームビルディング希望)」を選択する。

同プログラムでは、各自治体が実際の地域課題と開発に役立つオープンデータが提供される。これを元に、エンジニアやデザイナー・プランナーなどサービス開発やウェブデザインのスキルを持つ人がチームを作り、アプリケーションを開発する中で、新たな地域課題解決に向けた可能性を探るとしている。提供予定課題は「防災ハザードマップに関する課題」で、その他順次調整中。

表彰チームのプロトタイプは、OSSとしてGithub上で公開しにすることを条件としており、社会全体に広がるムーブメントの火付け役となるプログラムでありたいと考えているという。東京都主催のOSS共創プログラム第1弾「地域課題をハックする」がハッカソン形式で開催、「東京都OSS公開ガイドライン」も発表

「東京都OSS公開ガイドライン」

東京都は、「東京都新型コロナウイルス感染症対策サイト」制作の経験から、OSS化の利点を「都が保有する知的資産(ソースコード)を共有し、幅広く意見を聞くことで、OSS自体の自律的発展が可能」「また、この動きを全国に波及させることで、行政などが類似するシステムを構築する際の開発時間とコストの縮減に寄与」として捉えているという。

そのため、都全体でOSS化を推進していくべく「東京都OSS公開ガイドライン」を策定し、β版(0.1.0版。2021年11月1日現在)をGitHub上で公開した。Issue や Pull Request も受け付けているとのこと。

ヤフー主催の学生ハッカソン「HACK U 2021」の最優秀作品2点発表、傾向の変化も解説

ヤフー主催の学生ハッカソン「HACK U 2021」の最優秀作品2点発表、傾向の変化も解説

2021年8月、ヤフー主催学生ハッカソン「Hack U 2021」が2回に分けて開催された。いずれもオンライン開催で、合計54チームがエントリーしたが、チームのメンバー同士も集まることが禁止された完全オンラインの状況での参加となった。ヤフーは10月5日、その最優秀作品2点を紹介するとともに、2020年と2021年の参加者の傾向を分析し、ブログ記事「学生たちがハッカソンで使う技術トレンドは半年で変わったか?」で発表した。

ヤフーは、Hack Uを「夏の風物詩のようなものにしたい」と考えつつ毎年開催を続けているとのことだが、今回は両日とも1日で申し込みが埋まってしまうほどの人気だったという。小学生以上の学生なら誰でも参加でき、サポート役としてヤフーのエンジニアが付くという親切なイベントになっている。審査基準は、新規性(オリジナリティー)、技術性(技術の高度さ)、発展性(将来性や波及効果が期待できるか)、再現性(実現可能なアイデアか)の4つ。ブログでは、最優秀賞を獲得した2つの作品が紹介された。

「スローターム」(チーム名:この素晴らしいコードに祝福を!)

開発時に発生するプログラミングのエラーをワンタップで共有してくれるVisual Studio Codeのプラグインと、共有先のSNS両方を作り上げた作品。コード制作中にエラーをハイライトするだけで、GitHubでの質問文が簡単に作れる。さらに、その質問にうまく答えてくれそうな人を自動的に選んでつなげてくれる。コロナ禍で人に質問がしにくくなった問題を改善してくれる。

3pt Manager(チーム名:OAO)

バスケットボールの3ポイントシュートをiPhoneで練習できるアプリ。シュートするごとにiPhoneがボールの軌跡を取得し、角度のデータを蓄積する。毎日の練習結果がグラフ化されるので、効率的に練習ができるというものだ。

参加者が使用しているプログラミング言語と開発環境の傾向

同ブログでは、2020年と2021年のHACK Uで、参加者が使用しているプログラミング言語と開発環境に違いがあるかを分析している。使用言語は、どちらもJavaScriptとPythonがトップと変わらないが、2021年はRubyが上位に入ってきた。2020年はRubyを使うチームは1割に満たなかったのに対して、20201年はPythonに次いで3位に上がってる。その理由は、大学の年次に関係があると、筆者であるヤフーCTO室Developer Relations Hack Uプロデューサー中村友一氏は書いている。参加学生は大学3年生が中心だが、去年2年生だった学生は、授業などで手軽に始められるRubyを使う機会が多くなったからだとの分析が面白い。

  1. ヤフー主催の学生ハッカソン「HACK U 2021」の最優秀作品2点発表、傾向の変化も解説

開発環境については、Flutter、React Native、Xamarinなど多くのOSに対応できるクロスプラットフォームフレームワークを利用するチームが増えたのこと。iOS、Android、ウェブのすべてに対応するソフトウェアの開発を目指すということは、チームが継続開発やサービスの公開を考えているためだと中村氏は分析した。

また同氏は、Dockerの浸透を挙げている。今回、Dockerを使いサービスのデプロイまで考えて作ってきたチームが大幅に増えたという。Dockerが学生にも浸透し始めていることがうかがえ、今後ハッカソンにおいても環境構築におけるメインストリームになるかもしれないと指摘している。

この2年間はオンライン開催のため、参加者同士の交流が制限されたが、「今後ハイブリッド開催になった時にどのように変化するかが楽しみです」と中村氏は話している。

rinnaが日本語に特化したGPT-2とBERTの事前学習モデルを開発しオープンソース化

rinnaが日本語に特化したGPT-2とBERTの事前学習モデルを開発しオープンソース化

rinnaは8月25日、日本語に特化したGPT-2とBERTの事前学習モデルとその学習を再現するためのソースコードを、GitHubおよびNLPモデルライブラリーHuggingFaceにオープンソースソフトウェア(OSS)として公開したと発表した。ライセンスはMIT。製品開発のための実験過程で開発したもので、日本語の自然言語処理(NLP)の研究・開発コミュニティに貢献するためという。

rinnaは、2021年4月に日本語に特化した中規模サイズのGPT-2(GPT2-medium)をOSS化しており、今回はモデルサイズが異なる2つのGPT-2(GPT2-small、GPT2-xsmall)を公開したことになる。モデルサイズの違いはパフォーマンスとコストのトレードオフとしており、研究者や開発者は最善のモデル選択可能となるという。また、GPT2-mediumも、学習データと学習時間を増やし、より高性能なモデルへとアップデートしているそうだ。

またGPT-2に加え、BERTを改良したモデルであるRoBERTaも公開した。 GPT-2とBERTの公開により利用者は目的に合わせたモデル選択や、追加学習により多様なタスクへの応用が可能となる。

GPT-2は、予測したい単語より前の単語を考慮して次の単語を予測する言語モデルとなっており、BERTについては、予測したい単語の前の単語だけでなく後の単語も考慮して予測を行う。例えばGPT-2では以下図のように「吾輩」「は」を考慮して「猫」を予測するが、BERTでは前の単語「吾輩」「は」と後ろの単語「で」「ある」を考慮して「猫」を予測する。

rinnaが日本語に特化したGPT-2とBERTの事前学習モデルを開発しオープンソース化

また、今回公開のRoBERTaはBERTを改良したモデルにあたり、BERTより高い性能が報告されているという。RoBERTaを用いて、「4年に1度、[MASK]は開催される。」の[MASK]部分を予測すると、オリンピックやワールドカップといった4年に1度開催されるイベントが上位に予測される。

rinnaが日本語に特化したGPT-2とBERTの事前学習モデルを開発しオープンソース化

文章生成タスクにおいては、文章を1単語ずつ順次予測するGPT-2が用いられるものの、文章分類タスクなどの文章全体を考慮したタスクにおいては、BERTが利用される。文章分類タスクの他にも、質問応答タスクや固有表現認識タスクなど多様なタスクに適用することが可能という。

rinnaの研究チームが開発する大規模な事前学習モデルは、すでに同社製品で広く利用しているという。同社は今後も、AIに関する研究を続け、高性能な製品を開発するとともに、研究・開発コミュニティに貢献するために、研究成果を公開していく予定としている。他社との協業も進めることで、AIの社会実装の拡大を目指す。

rinnaの日本語事前学習モデルの特徴

    • 学習データとして、日本語CC-100と日本語Wikipediaの計75GBのオープンソースデータを使用
    • 8つのNVIDIA Tesla V100 GPUを用いて、75GBの日本語テキストを最大45日間かけ学習。その結果、すべてのモデルにおいて、十分に学習された汎用性があるモデルとなっているという。学習された事前学習モデルはHuggingFaceにおいてMITライセンスで公開
    • 事前学習モデルの学習に用いたソースコードはGitHubにMITライセンスで公開。利用者は、日本語CC-100とWikipediaのオープンソースデータを用いることで、自分のマシンでrinnaによる結果を再現可能
    • GPT-2ではモデルサイズが異なるGPT2-medium(3.36億パラメータ)、GPT2-small (1.10億パラメータ)、GPT2-xsmall (0.37億パラメータ)の3つのモデルを公開。またBERTを改良したRoBERTa (1.10億パラメータ)も公開
    • 利用者の目的に沿った多様なタスク(ドメインに特化した文章生成、文章分類、質問応答など)について、rinnaが公開した事前学習モデルを用いた追加学習により実現できる

GitHubがコーディングの提案を行う新しいAIツールをプレビュー

GitHub(ギットハブ)が、人工知能を活用してコードをより効率的に書けるようにする新製品を発表した。「GitHub Copilot(ギットハブ・コパイロット)」と名付けられたこの新製品は、コードの一部や、ときには関数全体さえも提案することができる。

GitHubはOpenAI(オープンAI)と提携してこのツールを開発した。これは開発者に取って代わるようなものではなく、生産性を向上させ、コードの書き方を簡単に学べるようにするためのツールに過ぎない。GitHubはこの新しいツールを「AIペアプログラマー」と位置づけている。

GitHub Copilotのモデルは、何十億行ものコードを使って訓練を受けた。その多くはGitHub自身によってホストされ公開されているものだ。コードを書き進めていくと、その途中でGitHub Copilotがコードを提案してくる。プログラマーはそうした提案を眺めながら、受け入れたり、拒否したりすることができる。

GitHub Copilot は、プログラマーが現在何をコーディングしているのかを理解するために、コメントの意味や書いている関数の名前、そこまでの数行のコードの解析を試みる。そのウェブサイトでは、いくつかのデモが紹介されている。

画像クレジット:GitHub

特に、コメントに平易な英語で機能を記述することで、それを実際のコードに変換することができる。新しい言語を始めようとしている人や、これまでノーコードやローコードのツールを使っていた人には、この機能は便利だろう。

毎日コードを書いているなら、新しいフレームワークやライブラリに、GitHub Copilotを使って取り組むことができる。GitHub Copilot は、現在使用しているフレームワークの特定の関数や機能をすでに知っているので、プログラマーはドキュメントを最初から最後まで読む必要はない。また、Stack Overflowに対する質問の多くを置き換えることができるだろう。

GitHub Copilotは、Visual Studio Codeと直接統合される。拡張機能としてインストールすることも、GitHub Codespaces(GitHubコードスペース)を使ってクラウド内で利用することもできる。GitHub Copilotとの対話履歴に基づいて、徐々にサービスは改善されていくだろう。提案を受け入れたり拒否したりを繰り返すうちに、その提案は良くなっていくはずだ。

現在はテクニカルプレビューとして提供されているが、GitHubはGitHub Copilotをベースにした商用製品の発売を予定している。現在は、Python、JavaScript、TypeScript、Ruby、Goとの相性が抜群だ。

画像クレジット:GitHub

カテゴリー:人工知能・AI
タグ:GitHubOpenAIコーディング

画像クレジット:James Harrison / Unsplash

原文へ

(文: Romain Dillet、翻訳:sako)

ファーウェイ独自OS「HarmonyOS 2.0」のオープンソース版がIoT機器向けに公開、Linuxか独自カーネルを選択可能

  1. ファーウェイ独自OS「HarmonyOS 2.0」のオープンソース版が開発者向けに公開、Linuxと独自カーネルを選択可能

中国初のオープンソース財団OpenAtom Foundationは6月1日、「OpenHarmony 2.0 Canary」(カナリア版)をリリースした。ライセンスはApache License 2.0(アパッチ・ライセンス 2.0)。Huawei(ファーウェイ)の独自OS「HarmonyOS 2.0」のオープンソースソフトフェア(OSS)版最新バージョンにあたる。中国のソースコードホスティングサービス「Gitee」上で公開している

また6月2日、開発者向けドキュメントをまとめた「Develop devices – HUAWEI HarmonyOS Device」に関連ドキュメントも公開された。

Huaweiは、2020年9月開催の開発者向けイベント「HUAWEI DEVELOPER CONFERENCE 2020」においてOpenAtom Foundationに対してソースコードを寄贈することを発表しており、以来公開が続けられている。

新たにリリースされたOpenHarmony 2.0のライセンスは、Apache License 2.0。すべての機器がネットワーク接続された世界における、あらゆるスマートデバイスに適用可能なOSSのOSとして、IoE(Internet of Everything)を促進するとうたっている。

カーネルとしてはLinux、HarmonyOSマイクロカーネル、Huawei LiteOSを利用できるマルチカーネルデザインを採用。ターゲットとするハードウェア環境によって開発者がカーネルを選択できるようにしており、カーネル抽象化層(KAL。Kernel Abstraction Layer)を設けることで実装の違いを隠し、基本的なカーネル機能を上位層に提供するという。

Linuxについては、LTS版カーネルを基にCVEパッチやOpenHarmonyの上位層に適合させるための機能をマージさせたものを利用するという(記事執筆時点では、バージョン4.19を基にしている)。

HarmonyOSマイクロカーネルについては、記事執筆時点ではソースコードおよびドキュメントとも公開されていない。Huawei LiteOSは、記事執筆時点ではOpenHarmony LiteOS Cortex-AおよびLiteOS Cortex-Mとしてソースコードが公開済みで、ライセンスはBSDライセンス(2条項BSDライセンス)を採用。LiteOS Cortex-Aは、Arm Cortex-A7ベースSoCの中国HiSilicon Technology製Hi3518E V300またはHi3516D V300搭載ボードをサポートしている。LiteOS Cortex-MをCortex-M3(STM32F103)/M4(STM32F429IG)/M7(STM32F767ZI)、RISC-Vに対応しているという。

ファーウェイ独自OS「HarmonyOS 2.0」のオープンソース版が開発者向けに公開、Linuxと独自カーネルを選択可能

OpenHarmony LiteOS Cortex-Aのアーキテクチャ

ファーウェイ独自OS「HarmonyOS 2.0」のオープンソース版が開発者向けに公開、Linuxと独自カーネルを選択可能

LiteOS Cortex-Mのアーキテクチャ

関連記事
ファーウェイがAndroidに代わるスマホ向けHarmonyOSを正式発表
Googleの新OS「Fuchsia」が第1世代「Nest Hub」向けに配信開始
Linuxカーネル5.13のリリース候補版RC1がAppleシリコン「M1」搭載Macを正式サポート
GoogleがAndroid、Chromeに続くOS「Fuchsia」プロジェクトを一般開放へ
ファーウェイスマホは2021年にHarmonyOSを搭載へ、HarmonyOS 2.0ベータを年内配布
中国が国内用のGitHubとして代替サービス「Gitee」を構築中

カテゴリー:ソフトウェア
タグ:IoT(用語)Android(製品・サービス)OS / オペレーティングシステム(用語)OpenAtom Foundation(組織)オープンソース / Open Source(用語)OpenHarmony(製品・サービス)Gitee(企業・サービス)GitHub(企業)Google / グーグル(企業)HarmonyOS(製品・サービス)Fuchsia(製品・サービス)

GitHubを解雇された社員が復職を断り「友好的解決」を達成

GitHibは、2021年1月に起きた米議会議事堂の襲撃事件の後に同社が解雇した社員との「友好的な解決」に至った、と当の元社員がTechCrunchに語った。

その元社員の以前の話では、トランプ支持者の暴徒たちが議事堂を襲ったその日、心配したGitHub社員すなわち彼がD.C.地区に住む同僚に、気をつけるよう警告した。彼はそのときSlackで「家にいても気をつけろよ。ナチスがそこらにいるぞ」と述べると、ある社員が気分を害して、そんな言葉は職場にふさわしくないと言った。その2日後に彼は解雇され、人事の代表者は彼の行為が「会社のポリシーに合わない」と解雇の理由を告げた。

関連記事:GitHubで暴動の際「ナチス」について警告し解雇されたユダヤ系社員が弁護士を募集(更新:GitHubが解雇を撤回)

同じ月に、GitHubのCOOであるErica Bresica(エリカ・ブレシア)氏は、同社の人事部長が今回起きたことの全責任をとって辞任したと発表している。GitHubは辞任した者の名前を公表しなかったが、GitHubの人事最高責任者がCarrie Olesen(キャリー・オレセン)氏であったことは誰でも知っている。当時GitHubは「社員を解雇する決定を取り消した」と発表し、彼の代理人にも告げた。

関連記事:GitHub人事部長が「ナチス」という言葉を使ったユダヤ人社員が解雇された問題の責任で辞任

しかしながら解雇された社員は、復職しなかった。

GitHubの広報担当者は「調査結果を検討した直後に社員に復職を告げたが、彼は断った」と述べている。

「私と会社は友好的な解決に至った。会社が白人至上主義と、それがもたらす危険を非難したことを高く評価する」と元社員はいう。

彼は、その解決の具体的な内容を明かさなかったが、以前の話では損害賠償または何らかのかたちでの和解を彼は求めていた。

以下は彼の声明の全文だ。彼は、全文の掲載を要求した。

私と会社は友好的な解決に達した。彼らが白人至上主義とそれが万人にもたらす危険を非難したことを高く評価する。

1月6日に私たち全員が、米国における最大の脅威がイスラムでも、Black Livesでも、警察の予算不足でもないことを知った。

白人至上主義は私たち全員を、もっともらしい正しさ、不誠実な議論と交渉、そして嘘っぽい公用語(Amtssprache、注記)を散りばめた主張の虜にし、私たち全員が死ぬか屈服するまで止めようとしない。ナチスのクーデターが失敗したことはうれしいし、この前は国会議事堂の放火を防いだが、ナチスは簡単にはあきらめない。

家族とコミュニティの安全を守ろう。隣人たちや地元の商店と結束しよう。ファシズムとナチズムは私たちが分断しているときに成功する。彼らは、あなたが理性を放棄し、権力とその階層に黙従し、愛他主義を避けることを要求する。自分を、愛しましょう。各地の団結を支持し、参加し、創り出そう。コミュニティを築こう。ナチスを歓迎しないために。

私と私の家族を支援してくださった方々に感謝申し上げます。みなさんの安全と幸福をお祈りします。

Black Lives Matter & Black Power ✊

*Amtssprache
https://heartlesshypocrisy.com/what-is-amtssprache/

参考資料とお楽しみ:

小説:
「Maus(マウス)」
「Y the Last Man(Y:ザ・ラストマン)」
「Pulp(パルプ)」
「Sweet Tooth」

歌:
「Algorhythm」Childish Gambino(チャイルデイッシュ・ガンビーノ)
「Plegaria a un Labrador」Victor Jara(ビクトル・ハラ)
「Tweakin」Vince Staples(ヴィンス・ステイプルズ)
「Operation:Mindcrime」Queensrÿche(クイーンズライク)

番組:
「Avatar Last Airbender & Legend of Korra」
「Attack on Titan(進撃の巨人)」
「Atlanta(アトランタ)」
「The Wire(ザ・ワイヤー)」

本:
「Gang Leader for a Day」Sudhir Venkatesh(スディール・ベンカテッシュ)
「People & Permaculture」Looby Macnamara(ルービー・マクナマラ)
「The Ways of White Folks」Langston Hughes(ラングストン・ヒューズ)
「Post Traumatic Slave Syndrome」Joy DeGruy(ジョイ・デグルイ)

映画:
「Persepolis(ペルセポリス)」
「Inglorious Basterds(イングロリアス・バスターズ)」
「Attack the Block(アタック・ザ・ブロック)」
「Shawshank Redemption(ショーシャンクの空に)」

カテゴリー:ネットサービス
タグ:GitHub

画像クレジット:GitHub

原文へ

(文:Megan Rose Dickey、翻訳:Hiroshi Iwatani)

Human Capital:Instacartが約2000人を解雇へ、GitHubの人事責任者が辞任

1週間の労働、多様性、インクルージョンに関する最新情報をお伝えするHuman Capitalへようこそ。先週は議会議事堂暴動の日にワシントンD.C.の社員にナチスに関する警告を発した社員を解雇したGitHubの公開謝罪で始まった。

その後Google(グーグル)は、AI倫理研究者であるMargaret Mitchell(マーガレット・ミッチェル)氏の会社情報アクセスを停止し、Timnit Gebru(ティムニット・ゲブル)博士に対する扱いを彷彿とさせると一部でささやかれた。一方、Instacart(インスタカート)はプラットフォームの改訂を行い、その結果雇用の喪失が発生した。

GitHubの人事責任者が辞任、会社は解雇したユダヤ系社員に復職を提示

GitHubは内部調査の結果、米国議会議事堂暴動の日にワシントンD.C.地区にナチスがいると同僚に警告を与えたユダヤ系社員を解雇したことについて「判断と手続きに重大な過失」があったことを認めた。

GitHub COO(最高執行責任者)のErica Breascia(エリカ・ブレシア)氏は公式ブログで、同社の人事責任者が事態の全責任を負って前日辞任したことを明らかにした。GitHubは退社した人物の名前を公表しなかったが、GitHubの人事部門の長がCarrie Olesen(キャリー・オレセン)氏であることは広く知られている。

GitHubは、「当該社員を退社させた決定」を覆し、そのこと代理人に伝えると語った。

「ご本人には公の場で、私たちが心よりお詫びしたい気持ちを伝えたく思います」とブレシア氏はブログに書いた。しかし、解雇された社員は以前私に、復職ではなく別のかたちの和解を望んでいると語っていた。

GoogleのAI倫理学者が取り調べを受ける

GoogleはAI倫理研究者であるマーガレット・ミッチェル氏が、ティムニット・ゲブル博士虐待の事例を見つけるために自動化スクリプトを使っていたことについて調査している、とAxiosが報じた。ゲブル氏は、自分はGoogleに解雇されたが会社は彼女が辞職したと主張していると語った。Axiosに向けた声明で、Googleはミッチェル氏のアカウントをロックしたと述べている。

当社のセキュリティシステムは、従業員の社内アカウントが認証問題のために危険に曝されていることを発見した場合、および機密データに関する自動化されたルールが発動された場合、自動的にアカウントをロックします。今般の件で、当社システムは昨日、あるアカウントが数千件のファイルを不当に持ち出し複数の外部アカウントと共有したことを検知しました。本日これを当事者に説明しました。

最近結成されたAlphabet Workers Union(AWU、アルファベット労働組合)は、ミッチェル氏のアカウント停止を憂慮する声明を発表した。

「会社の調査結果に関わらず、本組織のリーダーに対する現在進行中の措置は、GoogleのAIおよびビジネス慣行における倫理に対する姿勢に疑問を投げかけるものです。倫理AIチームのメンバーの多くはAWUのメンバーであり、当組合は彼らの職務の重要性を認識し、彼らのために連帯して立ち上がります」。

Googleのサンダー・ピチャイ氏がHBCUのリーダーらと面会

HBCU(歴史的黒人大学)の代表者5名以上が、Google CEOであるSundar Pichai(サンダー・ピチャイ)氏および多様化最高責任者のMelonie Parker(メロニー・パーカー)氏と2021年1月中に面会し、最近起きた同社における人種などの差別問題について意見を交わす。CNNによる。この会談の目的は、HBCUがGoogleと良好な関係をもち、同社がHBCUの学生や卒業生に対して良い環境を提供することだ。

Amazonがアンチ組合ウェブサイトを立ち上げ

Amazon(アマゾン)のアラバマ州倉庫労働者が組合結成の是非を問う投票を行うのに先立ち、同社はアンチ組合ウェブサイトを立ち上げた。Do It Without Duesと呼ばれるそのサイトは、社員が組合結成に賛成投票しないよう説得することを目的としている。

Instacartが2000人近くを解雇する計画

Instacartは2000近くの従業員を解雇する計画で、その中には2020年に労働組合を結成したKroger傘下のスーパーマーケットMariano’sの社員10名も含まれている。Viceが報じた。対象の従業員は店舗内の接客と商品梱包を担当している。

Viceの記事によると、影響を受ける社員10名が、イリノイ州ストーキーのUnited Food and Commercial Workers(全米商業食品労働組合)Local 1546を結成した。しかし、彼らはまだInstacartとの契約交渉をしていない、とViceは伝えている。Instacartは同組合に対して変更計画を通知した。Instacartは書簡で、Kroger傘下の店舗(ストーキーのMariano’sストアを含む)で販売員の雇用を中止する計画であり、時期は2021年の第1四半期および第2四半期だが、3月中旬以降であると述べている。

カテゴリー: パブリック / ダイバーシティ
タグ:GithubInstacartAmazonGoogle

原文へ

(翻訳:Nob Takahashi / facebook

GitHub人事部長が「ナチス」という言葉を使ったユダヤ人社員が解雇された問題の責任で辞任

米連邦議会議事堂で暴動が起きた日に、GitHub(ギットハブ)のユダヤ人社員が「ナチス」という言葉を使って同僚に注意を促したために解雇された問題について、同社が「判断と手続きの重大な誤り」を犯したことが、内部調査で明らかになった。

GitHubのCOO(最高執行責任者)であるErica Brescia(エリカ・ブレシア)氏は、米国時間1月17日のブログ記事で、今回起きたことについて同社の人事部長が全責任を取り、16日に同社を辞職したと述べた。GitHubは辞任した人物の名前を公表していないが、同社ではCarrie Olesen(キャリー・オルセン)氏が最高人事責任者を務めていたことは広く知られている。

16日夜のツイートの中で、GitHubのグローバル人事サービス担当シニアディレクターであるGia Colosi(ジア・コロシ)氏が、会社や人事について発言していた。そのツイートはその後削除されているが、スクリーンショットを以下に掲載する。

画像クレジット:Screenshot/Twitter

GitHubは私の永遠の仕事でしたが、今は違います。私は人事部に酷使されて終わり。

だから人事は大変。私たちは、バックアップを見つけない限り、魔法のように人を解雇したりはしません。そして幹部が命じない限り。はっきりさせたいのは、なぜ人事部が責めを負わなきゃならないの?

その後のツイートで、コロシ氏は「女性は男性の尻拭いをするために人事部にいる。疲れたわ」と述べている。

一方、GitHubは「件の従業員と別離する決定を覆した」と述べ、その人物の代理人と話し合っていることを明らかにした。

「その従業員へ私たちは公にいいたい。私たちは心からお詫びします」と、ブレシア氏はブログ記事の中で述べている。

解雇されたこの従業員は、Slack(スラック)で「気をつけろ、ナチスがいるらしい」とコメントした後、仲間の従業員が怒って、そのような言葉は職場に相応しくないといったと、その元従業員は以前私に語った。その2日後に彼は解雇され、人事担当者は解雇の理由として「会社の方針に資するものではない行動パターン」を挙げたという。

先週初めのTechCrunchによるインタビューで、その元従業員は、自分のユダヤ人の家族に加え、この地域にいる仕事仲間のことを純粋に心配していると話していた。そのインタビューの中で、彼は仕事を取り戻すことに興味がないが、他のかたちでの和解なら興味を持つだろうと語った。

関連記事:GitHubで暴動の際「ナチス」について警告し解雇されたユダヤ系社員が弁護士を募集(更新:GitHubが解雇を撤回)

カテゴリー:パブリック / ダイバーシティ
タグ:GitHub

画像クレジット:Michael Short/Bloomberg / Getty Images

原文へ

(翻訳:TechCrunch Japan)

GitHubで暴動の際「ナチス」について警告し解雇されたユダヤ系社員が弁護士を募集(更新:GitHubが解雇を撤回)

親トランプ派の暴徒が米議会議事堂を襲撃した日、心配したひとりのGitHubの社員がワシントンD.C.エリアの同僚に気をつけるよう警告した。

社内のSlack上で「みんな気をつけてくれ、ナチスが動き回ってるぞ」というコメントをした後、同僚のひとりが不愉快に感じ、そのような暴言は仕事場にそぐわない、と言ってきたという。2日後、彼は解雇され、人事担当者は解雇の理由として「会社の方針を助長しない行動パターン」を挙げた、と彼はTechCrunchに話した。

TechCrunchのインタビューに対し、「元」従業員となった彼は、ユダヤ人の家族に加えて、地域の同僚たちのことを純粋に心配していたと語った。

TechCrunchは、解雇された従業員の身元については、彼とその家族の安全を懸念して明かさないことに同意した。

Business Insiderが最初に報じたように、彼の解雇は、他の従業員たちがGitHubに白人至上主義とナチスを糾弾するよう求める社内文書を回覧することにつながった。従業員たちはまた、彼の解雇についての説明を求めた。その結果、GitHubのCEOであるNat Friedman(ナット・フリードマン)氏は、それらの従業員に対して、同社は問題になっている解雇について調査していくと述べた。

解雇された従業員は現在、彼の家族の安全を守るために弁護士を探しているところだといい、損害賠償や和解の方法を模索しているという。解雇された従業員によると、GitHubは内部調査のために彼に協力を求めているが、弁護人を得るまでは会社との交渉を待っているとのこと。

それでも、調査については楽観視していないという。

「誠実ではないと90%確信している」と、解雇された従業員はフリードマン氏の対応について語った。「この手の話は以前にもありました。ICE(米移民税関捜査局)の件でも、会社は『大いに意見交換をしましょう』と言ったのに、ICEのことを発言すると解雇されてしまうのです。以前はこの会社を信じていましたが、今は信じていません」。

一部の従業員が求めていることと同様に、解雇されたこの従業員は、これをGitHubが白人至上主義に対してスタンスを取るチャンスだと捉えている。

彼は、「これはGitHubが本当に(過激派を)一掃して、『この会社には白人至上主義者が必要なのか、どうすれば黒人のリーダーを経営陣に入れることができるのか』と言う機会になり得ると思います」と述べている。

後者の点は、彼がGitHubに入社したときから求めていたことだという。しかし、リーダーシップレベルでの多様性の欠如について発言し続けているうちに、彼は自分の仕事が危険にさらされていることに気づいたという。

「そのことを話し続けていたら、10月にはクビになると脅されました」と彼は語る。「私がセールスチームに有色人種が2人しかいないことを指摘したときには、上司の2人とも完全に私を弁護してくれ、彼らが会社に対し私を解雇しないよう懇願しなければなりませんでした」。

【米国時間1月16日更新】解雇されたGitHubberはその後、彼が意味していたのはセールスチーム全体ではなく、セールスリーダーシップチームであることを明確にした。

この記事の内容についてのTechCrunchの取材に対し、GitHubの広報担当者は次のように述べている。

「当社はこの種の苦情はすべて真摯に受け止めます。現在、積極的に調査を行っています」。

元従業員によると、会社は2給与期間分の報酬を彼に渡し、解雇したとのこと。彼は、損害賠償や医療費の補償など、何らかの形での和解に応じると言っている。彼は復職を望んでいるわけではないが、GitHub従業員の権限が増すのを願っているという。

「もし魔法のつえがあるとしたら、GitHubの従業員が組合を持ち、周縁化されたコミュニティの人々を代弁してくれるようになるといいですね」と彼は語った。

【米国時間1月17日更新】GitHubは1月17日朝、新たにTwitterと同社ブログ上で声明を発表し、次のように述べて「離職」を取り消すとともに、人事部長が辞任した。

「先日の従業員の離職で、判断や手続きに重大な誤りが見つかりました。離職を取り消すとともに、人事部長が個人的な責任を取り、GitHub を辞任しました。従業員の皆様に心からお詫び申し上げます」。

関連記事:Zoom疲れ対策を目指す元GitHubエンジニアのビデオ会議データベース化サービス「Rewatch」

カテゴリー:ネットサービス
タグ:GitHub

[原文へ]

(翻訳:Nakazato)

Zoom疲れ対策を目指す元GitHubエンジニアのビデオ会議データベース化サービス「Rewatch」

パンデミックによってリモートワークが増加した。オフィスが閉鎖、準閉鎖状態のため企業は業務を分散作業に切り替えている。我々は以前よるはるかに多くの時間をビデオ会議に費やすようになり、ZoomやGoogleハングアウトを使ってコミュニケーションを図っている。企業は事業部署やタイムゾーンを超えて、世界に広く拡散したチームが緊密にコミュニケーションを図る方法を考え出す必要が生じている。

Rewatchは、会議を効率化(できれば短縮化)したいと考えている。共同ファウンダーのConnor Sears(コナー・シアーズ)氏、Scott Goldman(スコット・ゴールドマン)氏は 企業が会議を保存してプライベートなビデオチャンネルを作り、社員が自分の都合がいい時間に再生するサービスを提供しようとしている。

Rewatchは本質的な部分でZoomなどと反対の非同期的体験だ。共同ファウンダーたちはビデオ会議を視聴する新しい方法を提供することで、「Zoom疲れ」と戦うことができると期待している。

仕組みはこうだ。Rewatchを導入した企業はZoomまたはGoogleハングアウトによる会議を記録し、データベースにアーカイブする。この際、タグとメモを書き込んで動画検索を効果的にすることができる。たとえば参加者は自分が取り組んでいるプロジェクトが話題になった時間を記録しておくことができる。また同僚が突然なにか大声で主張した時間もタグ付けしておけば後からの検索に便利だ。

Rewatchでは企業独自のビデオライブラリを「ミニYouTubeチャンネル」と呼んでいる。サービスには会議音声の文字起こしも含まれている。つまり現在のビデオ会議は、リアルタイムでしか参加できない同期体験をRewatchはこれを非同期の動画掲示板とドキュメントに変換する。

「これまでビデオ会議の利用範囲を拡大する唯一の方法は、会議時間を長くするか会議の数を増やすしかありませんでした」とシアーズ氏は説明する。Rewatchを使えば「会議は終了しました」というそっけない無音の表示をどんなタイムゾーンにいるユーザーでもタグとテキストで検索できる対話的なビデオ情報源に変えることができる。

シアーズ氏は有名なデベロッパー向けサービスであるGitHubの元社員で、そこでRewatchのアイデアを得たという。オープン分散サービスであるGitHubは、タイムゾーンを超えて世界のデベロッパーが協力できるよう部内にYouTubeチャンネルを作成した。現在、共同ファウンダーたちは、GitHub内で人気を得ているこの機能を利用し、さらに拡充してメインストリームのサービスとしようと試みている。


RewatchはすでにGitHub自身を含め多くの顧客を獲得できたという。ただしその数は明らかにされていない。料金は未定だがサブスクリプションモデルを考えており一般公開の際には課金することになる。

当然GoogleドライブがRewatchのライバルとなる。しかしGoogleドライブはビデオコンテンツの保存と構造化に関して相当に遅れをとっている。Rewatchは、ライブ文字起こしやタグ付加などビデオを検索しやすい機能を追加してライバルに対する優位性を得ようとしている。他のライバルとしてはベルリンのスタートアップで非同期会議に取り組んでいるAcapela(未訳記事)や、ポッドキャストサービスのStoryboard(Business Wire記事)などが含まれる。後者は、ポッドキャストの作成者がオーディオコンテンツをオンデマンドで関係者に公開するのを支援する機能が含まれる。最近、両社とも数百万ドル(数億円)クラスの資金調達を実施した。

ビデオ会議開催体験の改良は確かに重要だ。しかしRewatchやそのライバルは企業の社員が会議コンテンツのデータベースをかなり頻繁に利用し、大きな意義を認めることにビジネスを賭けている。このビジネスはユーザー行動に大きく左右される。ただ正直なところ、現在の我々は休暇中に開催されて見逃した会議をわざわざ後から再生することは滅多にないだろう。

テクノロジー上のイノベーションが無意味だというという意味ではまったくないが、非同期ビデオ会議再生のようなビジネスが成功するためには、ユーザーの習慣に大きな変化が起こること必要になる。一方、冷笑主義を否定する投資家はすでに何百万ドルもこうした事業に投資している事実も考えねばならない。

実際、Rewatchのビジョンに納得した投資家は数多い。このスタートアップはTechCrunchの取材に対し、今回のプレシードラウンドはSemil Shah(セミル・シャー)氏のHaystackがリードし、Kent Goldman(ケント・ゴールドマン)氏のUpside Partnershipが参加し200万ドル(約2億1000万円)の資金の調達に成功したことを確認した。投資家にはこの他、GumroadのCEOであるSahil Lavingia(サヒル・ラビンギア)氏、GitHubのCTOであるJason Warner(ジェイソン・ワーナー)氏、ZendeskのシニアバイスプレジデントであるJason Smeale(ジェイソン・スミール)氏らが含まれる。

関連記事:シリコンバレーに広がる冷笑主義に対抗する方法はSubstack、Clubhouseそしてマイアミ脱出だ

カテゴリー:ネットサービス
タグ:RewatchGitHubZoomリモートワーク

画像クレジット:Bryce Durbin

原文へ

(翻訳:滑川海彦@Facebook

GitHubがCookie追放を発表、わずらわしいCookieバナーも消える

Microsoft(マイクロソフト)傘下のGitHubは12月17日、必須ではないCookieをプラットフォームからすべて追放すると発表した。これにより、GitHub.comとそのサブドメインにCookie配置への同意を求めるバナーが表示されなくなる。仕事に取りかかる前のわずらわしいクリックが1つ少なくなるわけだ。

GitHubのCEOであるNat Friedman(ナット・フリードマン)氏は声明に「Cookieバナーが好きな人間は誰もいない。しかしCookieは至るところにある!」と書いている。

わずらわしいバナーを表示しなければならない理由はEUのGDPR(一般データ保護規則)やこれに相当する米国での規制によるものだ。Cookieの使用がオンラインにおけるプライバシーを低下させるおそれがあるため、ユーザーにCookieを拒否する権利を与えるために、デベロッパーはCookieバナーを表示する義務を課せられている。なるほどこうした規制はユーザー保護を最大の狙いとしているが、その結果はどんなサイトを見るにもまずCookieバナーをクリックしなければならないという状態だ。

フリードマン氏は「GitHubは開発者のプライバシー保護を追求している。しかしCookieバナーはいらだたしい。そこで解決策を探すことにした。その方法はすぐ判明した。必須ではないCookieを使用しなければいいのだ。まったく簡単なことだった」と書いている。

公平を期すためにいえば、GitHubのようなデベロッパー向けサービスの場合、通常のコンテンツサイトよりCookie廃止は簡単だったはずだ。実際、このTechCrunchサイトを開くときにCookieバナーが表示される読者は多いはずだ(もちろ私はこれに気づいているが、大勢の読者がコメントで指摘してくるに違いない)。結局のところGitHubは有料サービスを提供しているし、オーディエンスの大半は十分に知識があるので拡張機能を使用して不要なCookieやトラッカーをブロックしているに違いない。そのためCookieでは、さほど意味あるデータは収集できないのかもしれない。とはいえGitHubはCookie追放を決めた最初の大規模サイトの1つであり、多少でもトレンドを動かす可能性がある。

関連記事:グーグルはChromeでのサードパーティCookieのサポートを2年以内に段階的に廃止

カテゴリー:ネットサービス
タグ:GitHubCookieプライバシー

画像クレジット:mrs / Getty Images

原文へ

(翻訳:滑川海彦@Facebook

GitHubにダークモードが加わる

今週のGitHub Universeでは当然ながら、ユビキタスなコード管理サービスに関する多数のアップデートが発表された。企業はGitHubのスポンサーになり、開発者に直接支払うことでオープンソースプロジェクトに投資することができ、プルリクエストの自動マージ(希望すれば)、すべての公開リポジトリのディスカッション、依存性レビューのベータが用意される。またGitHubは継続的デリバリ機能についてもいくつかのアップデートを行っている。

アップデートはそれだけではない。GitHubに新しくダークモードが登場した。

画像クレジット:GitHub

「ダークモードでは明るい画面の視覚的な刺激から解放される場合もあれば、テキストエディタ、IDE、ターミナル全体で一貫した開発エクスペリエンスが得られる場合があります。画面を明るくしたい場合でも、ダークモードでMr.Robotのように感じたい場合でも、GitHubをどのように使うかはあなた次第です。設定からダークモードを有効にするか、システムの環境設定を反映するように設定してください」と、同社は述べている。一見したところ、なかなか良い出来だ。

カテゴリー:ネットサービス
タグ:GitHub

画像クレジット:Dean Mitchell / Getty Images

原文へ

(翻訳:塚本直樹 / Twitter)

Alphabet Xはうつ病発見のための単一バイオマーカーを探求するも達成できず、Project Amberをオープンソースとして公開

Alphabet X(Googleのいわゆる「ムーンショットファクトリー」)が、Project Amber(プロジェクト・アンバー)に関する新しいブログ記事(Alphabet Xブログ)を、米国時間11月2日投稿した。同プロジェクトは過去3年間にわたって取り組みが行われていたが、その成果が今回オープンソースとして世界のメンタルヘルスの研究コミュニティに公開された。この先その上でさらなる開発が進むことが期待されている。Xプロジェクトは、うつ病のための特定のバイオマーカーを特定しようとしたが、その目的を達成することはできなかった(現在研究者たちは、うつ病や不安症を特定できる単一のバイオマーカーは存在しない可能性が高いと考えている)、それでもXは、脳波(EEG)と機械学習を組み合わせたその研究成果が、他の研究者たちの役の立つことを期待している。

Xの研究者たちは、うつ病が他の病気や障害と同様に、医療従事者がいm以上に簡単かつ客観的にうつ病を診断するのに役立つ、明瞭なバイオマーカーを持っているのではと期待していた。それは、目的のために特別にデザインされたゲームを使用して、実験室で行われた研究の中で脳波を見た際に、いくつかの前例となるケースが発見されたからだ。そこでは、うつ病の人びとには、実質的にゲームの「勝利」に対応する脳波活動の低下が一貫して観察された。

これらの研究は、バイオマーカーの可能性への道筋を示しているように見えた。それを(クリニックや公衆衛生ラボのような)実際の診断環境で有用なものにするために、Xのチームは脳波収集やその解釈プロセスを改善して、ユーザーや技術者たちにとって使いやすいものにしようとした。

この探求についておそらく最も注目すべき点は、Alphabetがその過程を詳細に発表した米国時間11月2日の投稿は、基本的にうまくいくことがなかった長年の調査についてのストーリーであり、大規模テック企業から一般的に聞こえてくる典型的なムーンショットストーリーとは異なっている。

実際、これはおそらく、大規模テック企業の多くのアプローチを、批評家が理解し損なう例を示す最良のものの1つだ。ソフトウェアやエンジニアリングの世界でよく見られるソリューションに類似したアプローチでは解決できない問題もあるのだ。

Xのチームは、長年にわたったユーザー研究プロジェクトからの学びを、3つの要点としてまとめている。そしてそれぞれの要点が、純粋なバイオマーカー検出手段の(たとえ機能していたとしても)不十分さに何らかのかたちで触れている。それは特にメンタルの病に対する場合に顕著なものとして示されている。

1.メンタルヘルスの測定はまだ未解決の問題です。多くのメンタルヘルスの調査や評価基準が利用可能であるにもかかわらず、それらは特にプライマリケアやカウンセリングの現場では、広く使用されていません。その理由は、作業負荷(「私はこれを行うための時間がありません」)から、懐疑主義(「評価基準を使用しても、私の臨床判断よりも優れていることはない」)、信頼の欠如(「私は患者がこれに正直に答えているとは思わない」「私はカウンセラーにこれほどまでに多くを明らかにしたくない」)まで、多岐にわたっています。これらの知見は、測定に基づくメンタルヘルスケアに関する文献の中に現れているものです。いかなる新しい測定ツールであっても、生きた経験を持つ人と臨床医の両方に対して明確な価値を創出することで、こうした障壁を克服する必要があります。

2.主観的データと客観的データを組み合わせることには価値があります。生きた経験を持つ人と臨床医は、どちらも客観的な指標の導入を歓迎しましたが、主観的な評価や、相手に経験や感情について質問する行為を置き換えるものではありませんでした。主観的指標と客観的指標の組み合わせは、特に強力であると見なされていました。客観的な指標は、主観的な体験を裏付ける場合もあれば、両者の相違そのものが、会話を始めるきっかけを与えてくれる、興味深い洞察となったりする場合もあります。

3.新しい測定技法には、複数のユースケースがあります。私たちの最初の仮説は、臨床医が診断補助として「脳波検査」を使用できるかもしれないということでした。しかし、このコンセプトは熱心に歓迎はされませんでした。精神科医や臨床心理学者などのメンタルヘルスの専門家は、臨床面談を介しての診断能力に自信を感じています。プライマリケアの医師は、脳波検査が有用だろうと考えましたが、それは血圧検査などと同様に、患者との面談前に医療スタップによって実施された場合に限るのです。一方カウンセラーやソーシャルワーカーは実践の場で診断を下さないため、脳波診断とは無関係でした。生きた経験を持つ人の中には、機械によって「うつ」だとラベル付けされるというアイデアを好まない人もいました。

対照的に、テクノロジーを継続的に観察するためのツールとして使用することには、特に強い関心が示されました。面談と面談の間に何が起きたかを知るために、メンタルヘルスの状態の変化を経時的に捉えるのです。多くの臨床医が、患者や顧客が自分で検査を繰り返せるように、脳波システムを自宅に送っても良いかと尋ねてきました。また彼らは、脳波が持つ予測能力への可能性にも強い関心を示しました。例えば将来より「うつ」が深刻になるのは誰かを予測するといったことです。脳波などのツールが、臨床およびカウンセリング環境においてどのように導入されることが最適なのかを決めるためには、さらなる研究が必要です。例えば、デジタル表現型(digital phenotype、個人のデバイスから収集される行動データ)などの他の測定技術と組み合わせる方法も含まれます。

XはProject AmberのハードウェアとソフトウェアをGitHub上でオープンソース化する。そして同時に、オープンソース素材を通して使われる、Amberに関わる脳波特許の利用者に対して、いかなる法的措置も講じないことを宣言する「特許誓約」も発行する。

Amberが「うつ病」のための単一バイオマーカーを発見できたのかどうかははっきりしないが(おそらく発見できていないだろう)、専門的な試験施設以外でも脳波をより使いやすくするためにチームが行った作業の成果は、より広いコミュニティの手に渡ることで、おそらく他の興味深い発見につながることだろう。

カテゴリー:バイオテック
タグ:Alphabetうつ病GitHub

画像クレジット:X, the moonshot factory

原文へ

(翻訳:sako)

ZenHubの新しい自動化ツールはGitHub上での開発者間の連携を改善する

GitHubユーザーに人気のプロジェクト管理ソリューションを提供するZenHubが、米国時間9月15日、チーム間の連携を自動化するための新機能の発表を行った。このAutomated Workflowsという名の新機能の背後にある考えは、例えば新しいパッチのテスト準備が整った際に(あるいはそのテストが失敗して開発チームがそれを修正しなければならないときに)、チームにまたがる複数のボードを更新してくれるといったものだ。

ZenHubの創業者でCEOのAaron Upright(アーロン・アップライト)氏が私に語ったところでは、今回のAutomated Workflowsは、同社がGitHubで最も統合されたサービスから、最も自動化されたサービスにたどり着く旅の最初のステップに過ぎない。

画像クレジット:ZenHub

彼が指摘したのは、開発チームたちは今でも、アジャイルプロジェクトの管理に苦労しているということだ。「どんなフレームワークを選ぶべきか、どのようにプロジェクトを構成すべきか。小さな会社やチームと話しても、大きな会社と話しても、スクラムとカンバンのどちらを採用するばいいのか、もしくはスプリント計画会議をどのように組織すれば良いのかがわからない人たちにとって、それは共通した問題なのです」。ZenHubが狙っているのは、こうした摩擦点をできるだけ多く取り除き、チームのためにそれらを自動化することだ。

それは、チーム間の連携を行うことから始まる。なぜなら、それが顧客が常に苦労している問題の1つだからだ。チームはそれぞれ独自のプロジェクトとワークスペースを持つことが多いので、ZenHubチームは、企業のさまざまなボードを横断して機能するソリューションを開発する必要があった。

その結果生まれたのは、ドラッグ&ドロップサービスを中心としたツールだ。例えばこれを使うことで、QAから本番に移行する際に、自動的に通知を作成しワークスペース間でのアイテム移動を行うことができる。

「これは、異なるワークスペース間での作業を自動化する方法の1つです」とアップライト氏は説明する。「そして、これが私たちの自動化へ向かう旅の、最初のステップであることに本当に興奮しています」。

アップライト氏は時間の経過とともに、ユーザーがチーム間に構築している関係を機械学習を使用して理解できるようになることを期待している。そのデータを使用すれば、システムはワークフローを提案することもできるようになるかもしれない。

ZenHubによる自動化へ向かう次の焦点は、スプリント計画プロセスを管理するためのツールになる。

「現在でもすでに、ZenHubは開発速度などを収集しています。そうした測定はチームごとに集計されています。私たちは、ワークフローの中での課題の優先順位を理解しています。私たちができるようにしたいのは、例えば2週間ごとに、チームがスプリントのスケジュールを自動的に設定できるようにすることです。そうすれば、チームについてわかっている開発速度データに基いて、チームは2週間ごとに50ストーリーポイントを達成できるようになるかもしれません。私たちはそのSprintを自動構成したいと考えています」。

カテゴリー:ソフトウェア

タグ:ZenHub GitHub

画像クレジット:U.Ozel.Images / Getty Images

原文へ

(翻訳:sako)