SpaceXがStarshipプロトタイプの高度150メートル飛行試験に成功

SpaceX(スペースエックス)は、テキサス州ボカチカの同社打ち上げサイトで、次世代宇宙船Starship(スターシップ)を開発している。今日まで、同社はいくつものStarshipのプロトタイプを建造してきたが、Starhopper(スターホッパー)と呼ばれる1つ前のバージョンは、基本的にロケットの下の部分だけだった。米国時間8月4日、SpaceXは実物大のプロトタイプ(ただし最終バージョンに取り付けられる予定の先端のドームと下部の操縦翼面を除く)の初飛行を行い、同機はおよそ150メートルの高度に達した。

これは、この試験段階で建造されたプロタイプの中で、最も高く飛行したものとなった。Starship SN5と呼ばれるこの機体は、このシリーズでは5番目のプロトタイプとなる。しかしSpaceXは、現在の命名法則に切り替える前にStarship Mk1(マークワン)という名の実物大プロトタイプを建造しているので、今回のものが実際には6番目だ。これまでのバージョンは、タンクの加圧テストやエンジンの地上燃焼試験など、準備段階のさまざまな時点で失敗に見舞われている。

SN5は、実物大の機体として実際に飛行した初めてのものとなった。今週初めにエンジンの地上燃焼試験をパスしたことで、今回の短距離飛行試験への道が開かれた。このプロトタイプにはRaptor(ラプター)エンジンが1基だけ搭載されているが、完成形では6基のRaptorエンジンを搭載して、大きな推進力を発揮することになっている。同機は垂直に跳び上がり、垂直に着陸を果たした。こうした目に見える結果から、すべてが予定通りに進行したものと推測される。

画像クレジット:NASA Spaceflight

Starhopperが同様の短距離飛行試験を成功させたのは、2019年8月のことだった。SpaceXでは、早ければ2021年中に軌道に載せる実際の宇宙船を使って、ペイロードを搭載した打ち上げという意欲的なゴールに向けて、Starshipの実用化を目指したプロトタイプ開発計画を積極的に進めている。Starshipは、将来のFalcon Heavy(ファルコン・ヘビー)ブースターを装着できるように設計されており、これを使って大きなペイロードを地球軌道、月軌道、そしていずれは火星軌道にまで運ぶことが予定されている。

画像クレジット:NASA Spaceflight Forums

原文へ
(翻訳:金井哲夫)

YouTubeが今やってるベータは新機能ではなくアプリの安定性をテストする

Googleはときどき、Google Play上のさまざまなAndroidアプリのベータバージョンで、新しい機能を実験する。でも、最近見つかったYouTubeのベータは残念ながら、このビデオ共有サービスに近く加わる何かのテストではない。Googleによるとそれはむしろ、将来ではなく現時点のYouTubeの安定性をテストしているだけだ。

同社は先週秘かに、YouTubeのベータプログラムをGoogle Playで開始した。それはすぐに、Android Policeの連中に見つかった。

最初それは、YouTubeの今後の新しい機能をそのベータで試しているのだ、と思われていた。そのベータに関するGoogle自身のドキュメンテーションも、そう言っていた:

それだけでなく、そのドキュメンテーションはテスターたちに、そのアプリで見た新しい機能に関しては、それが正式にローンチするまでは情報を共有しないよう促していた。

新しいものなら何でも、人より先に試してみたくなる私たちアーリーアダプターにとってそれは、とってもそそる話だよね。

でも、詳しい話を聞こうと思ってGoogleに問い合わせると、同社はそのドキュメンテーションをアップデートして、“実験的機能”という言葉を削除した。今それは、テスターはYouTubeアプリの安定化を助ける、とだけ言っている:

確かにYouTubeも、頻繁にベータをやっている。唯一の変化は、先週からもっと多くの人がそれらにアクセスできるようになったことだ。

今やっているYouTubeアプリの安定性テストも、誰もが参加して、いつでも脱(ぬ)けることができる。ただし現時点ではまだ。新しい機能のベータの予定はない。しかし今後は、新しい機能のベータも、このように一般参加でやるようになるかもしれない。そして、誰よりも早くそのことを知りたかったら、今やってるベータに参加した方がよいかもしれない。

でもYouTubeはこれまで長年、新しい機能のテストはサーバー側でやってきた。しかしそれも今年から変わり、それらのテストも一般公開されるようになった。実験に参加したい人はYouTubeのCreator Insiderチャネルに@TeamYouTubeのハンドルでアクセスするとよい。

数か月前にiPhone上のExploreタブのテストを発表したときも、そうだった。また最近の発表では、ビデオに広告を入れる新しいやり方をテストするらしい。それは、一回の広告挿入で複数の広告を出すことにより、“広告による中断”の回数を減らす、という試みだ。

YouTubeのベータプログラムのメンバーがその実験にオプトインになるのか、ならないのか、それはまだ分からない。そのときベータのターゲットとして選ばれるか否かで、それは決まるのだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GoogleとNetflixがオープンソースのカナリア分析ツールを共同開発、プロダクションレベルの問題発掘を目指す

【抄訳】
GoogleとNetflixが今日(米国時間4/10)、Netflixが内製したカナリア分析ツールを一般公開することになるオープンソースのプロジェクトKayentaのローンチを発表した。Kayentaは、Netflixで育った継続的デリバリのプラットホームSpinnakerに統合されており、それはパブリックかプライベートかを問わずほとんどすべてのクラウドで使える。今回のリリースはSpinnakerにフォーカスがあるが、しかしKayentaはそのほかの環境にも適応させられる。

カナリア分析は、概念としては単純明快である。その名前が示しているように、サービスやインフラストラクチャを展開またはアップデートしたときの大きな問題を防ぐための早期警戒システムだ。展開やアップデートの対象をユーザーやサーバーやネットワークの一部に絞って行うテスト的実施で、カナリア分析は新しいシステムの振る舞いが正しいこと、あるいは前と変わらないことをチェックする。各ステップでシステムはチェックを実行し、その展開やアップデートが、通常のテストでは問題ないが、もっと複雑なプロダクションシステムに投じられたときにも問題が生じないことを、それら各ステップで確証していく。

GoogleのプロダクトマネージャーAndrew Phillipsによると、すでにそれをやっているデベロッパーは多いけれども、しかしそれはしばしば、非公式に行われている。チームがアプリケーションをビルドすると、いくつかのサーバーにデプロイしてみて数分動かし、ダッシュボードに異状が出ていないかチェックする。そんなやり方は人的エラーにつながりやすいし、偏りもありうる。それに対してカナリア分析ツールは、いくつかの測度の値を求めて、そのコードの完成度を客観的に判定する。コードのテストは多くの企業が自動化しているが、その種のテストではコードをプロダクションに投じたときに起きる問題を捉えられないことが多い。とくにそのプロダクション環境がマイクロサービスの集合から成り、それらが予期せざる対話をし始めたような場合には、お手上げとなる。

【後略】
〔以下、技術的な話題よりも、G社N社共同開発の経緯が中心。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

スタートアップのプロダクトのコンテンツではなく機能の違いとその効果をテストするAirship

Facebookのアプリが友だちのとちょっと違う、と不思議に思ったことがある人は、Facebookがとてもユニークな、的を絞ったやり方で機能をテストしていることを、自分の体験として知ったのだ。

Airshipは、FacebookやDropboxなどがやってるそんな機能テストを、小さなスタートアップでもできるようにする。しかも、ごく簡単に、苦労なく。Y Combinatorのこの前のクラスを卒業したAirshipは、自分のプロダクトをユーザーのコードに直接統合し、テストしたい機能を、ねらったターゲットグループだけにonできるようにする。

いわゆるA/Bテストをやるツールはすでにいろいろあるが、それらはほとんど、コンテンツのテストに限られている(たとえば色や形の違い、文章の言い回しなど)。Airshipは、プロダクトとその機能のレベルで、まったく異なる体験を対象ユーザーに提供し、顧客とプロダクトとの対話的関係の、根本的な違いをユーザーであるスタートアップに教える。

“スタートアップが自力でこれをやるのは、とても難しい”、とAirshipの協同ファウンダーAlvin Yapは言う。“うちは、いろいろとコントロールできるようにした機能を、ユーザーがさまざまなターゲットグループに提供して、それらをテストできるようにする”。

異なる機能をテストできることにより、ユーザーであるスタートアップにはプロダクトの正しい方向性が分かり、どの機能がどのグループに否定的に受け止められたかも分かる。Yapによると、SnapやDiggのデザイン変更が失敗したのも、機能のレベルの判断(どんな機能をどんなターゲットグループへ)が欠けていたからだ、という。複数の機能候補があるときは、ターゲットを絞ることが正しい判断のために重要である。

Airshipは今、アナリティクスのSegmentと統合されているので、機能の受け取られ方の違いが数字で分かる。今後はもっとさまざまな統合に力を入れて、またコントロールの仕組みも、もっと細かく多様にしたい、と同社は言っている。

Airshipの利用料金は、月額80ドル(年払いなら月額64ドル)からだ。テストする機能の数が多いほど、料金は高くなる。また、14日間の無料トライアルもある。

ではAirshipを訪ねてみよう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

A/Bテストに飽き足らないOptimizelyの新しいプロダクトはコードの最適化を実験できるOptimizely X

optimizely-x-mobile

Optimizelyは、A/Bテストをはやらせた。WebサイトやモバイルアプリのAバージョンとBバージョン、どっちが良いかを消費者テスターたちの使い方から比較判断する方法だ。

でも協同ファウンダーでCEOのDan Sirokerによると、この方法はテキストやページのレイアウトなど、表層的なことをマーケターがテストすることにしか使われていない。そこで今日(米国時間9/15)、同社のユーザーカンファレンスOpticonで、同社はそのプラットホームのニューバージョンOptimizely Xを発表した。Sirokerによると、これなら“コードの実験”ができる、という。

Sirokerは語る、“コードの実験をマーケティング部門など、ふつうの人でもできるようにしたかった。デベロッパーがいつもやってることを、誰にでもできる‘グッドアイデア’にしたかったんだ”。

これからは、Optimizelyのユーザーは、検索の結果や、プロダクト〔サービスなど〕のリコメンデーション、価格/料金、プロダクトのさまざまな機能や特徴、などなどについて実験できる。従来のようにテキストをいじくるだけでなく、Webサイトやアプリの中核的な機能を実験にさらすのは危険ではないか、と私が問うとSirokerは、“うちの顧客はむしろ、実験をリスクを減らす方法として歓迎している。実験を経ずにいきなりサイトを公開したり、プロダクトを一般供用する方が、むしろ危険だ”、と言う。

ただし、彼は付け加える: “どこの企業も、‘うちはGoogleでもFacebookでもAmazonでもないからデータサイエンスの技術者なんて雇えないよ’、と言うね”。そこでOptimizely Xは、そんな人材がいないところでも、その種のテストができるようにしているのだ。

Optimizely Xによる実験は、Python, Java, Ruby, NodeJSをサポートする。テストは、複数の種類のデバイスに対してでき、tvOSやAndroid TVが動くスマートTVでもよい。

Optimizely Xの一般公開は10月4日の予定だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Webサイトやモバイルアプリのテストを全世界2万名のクラウドソースで行うTest IOが$5Mを調達、合衆国進出を目指す

test-io-dashboard-example-tout

モバイルアプリやWebアプリケーションのデベロッパに、セルフサービス型の‘クラウドテスト’プラットホームを提供しているベルリンのTest IO(元Testcloud)が、サンフランシスコのVC Turn/Riverが率いるシリーズAのラウンドで500万ドルを調達した。

この新たな資金は合衆国への進出(まずサンフランシスコから)など、会社の成長のために使われる予定で、またTest IOという新しい名前の周知のためにも使いたい、という。

同社は今、世界の78か国に計2万名あまりの、クラウドソースなソフトウェアテスターを抱えていて、彼らの協力により、アプリやWebサイトのテストをデベロッパや、企業の品質管理部門、プロダクトマネージャなどに提供する。バグなどの欠陥は、すぐに見つかるそうだ。

このTaaS(Test as a Service)業界で同社の決め手となる差別化要因は、プラットホームがセルフサービス型であることだ。つまり、同社のスタッフがあれこれ仕事をするのではなくて、ユーザ自身がいきなり、アプリやWebサイトのテストを自分でセットアップして開始できるのだ。

今やTest IOでもテストの70%はモバイルアプリだが、雑多なクラウドソース方式であることが、モバイルのOSやデバイスの多様化に、うまくマッチしている。

またテクノロジ企業はスピードが命だから、テストの結果もすぐに出ないと意味がない。Test IOが引用しているForresterの調査報告書も、競合に生き残るためにはスケールアップとWebを利用する迅速なテストがますます重要だ、と指摘している。クラウドソースなやり方は、迅速だけでなく、コストの面でも有利なようだ。

“今の経済はモバイルのアプリとソフトウェアが牽引しており、スタートアップのデベロッパもFortune 500企業も、開発プロセスの中で、とくにソフトウェアのテストを速くかつ低コストにしたい、と考えている”、とTest IOの協同ファウンダThomas Gruderichが声明文の中で言っている。

“この二つの要求に応えるために弊社は、デベロッパが自分で容易に管理できるプラットホームを提供し、同時にクラウドテストのスピードと質と効率も十分に利用している。今回の資金と合衆国への進出によって、弊社がヨーロッパで培ってきた勢いがさらに大きくなり、大量のアプリとソフトウェア開発市場の中でマーケットシェアをさらに拡大できるものと信ずる”。

今現在、同社のサービスはVolkswagenやRed Bullをはじめ、500社あまりのデベロッパや品質管理部門、およびプロダクトマネージャに利用されている。

〔余計な訳注: ここでVolkswagenの名を出すのは、やばいかもしれない…。〕

[原文へ]。
(翻訳:iwatani(a.k.a. hiwa)。

売れるLPが作れる2つの法則


こんにちは。
LPOコンサルタント中村です。

先日とあるコピーライターさんとお話をしたのですが、
その中で、セールスレターの法則の話になりました。


世の中には、色んなセールスライターの方が残した様々な法則がありますが
実際どの商品に、どの法則をどう使っていいのかわからないですよね。

その点を整理して、使うべき商品に合わせて、この法則を当てはめていきましょう。

今回はそんなお話です。

まずはいくつかある法則の種類ですが
僕がよく使う2つがこちらです。

1、QUEST FORMULA
2、AIDAの法則

【QUEST FORMULA(クエスト フォーミュラ)】

①Qualify ⇒ 見込み客の選別
②Understand ⇒ 理解・共感
③Educate ⇒ 教育
④Stimulate ⇒ 興奮させる
⑤Transition ⇒ 転換・申し込み後押し
の頭文字をとったものです。

最も基本的な型です。
僕は、まずこの方をベース考えています。

最初の「Q」は見込み客の選別です。

そして次に「U」で、見込み客の悩み・心配・不安・痛みの共感を伝えます。
つまり「あなたのその悩み、私も理解できますよ」と伝える訳です。
人はわかってくれる人からものを買う傾向があります。

そして「E」では問題を明確にして解決策を提案します。
つまり、その商品の内容や買う事が最良の選択であることを伝えます。

続いて「S」で、見込み客の欲求をさらに高めます。
商品・サービスのメリットを列挙します。

そして最後の「T」はいわゆるクロージング部分です。
価格や限定性などをアピールして購買に繋げます。

この法則は、どちらかというと説明型の商品に向いてますね。

健康食品や化粧品など、説明をすればするほど商品の良さが伝わるものに向いています。

例えば、こんな感じの流れで使ってみてください。

2


【AIDAの法則(アイダの法則)】

①Attention ⇒ 見込み客の注意を引く
②Interest ⇒ 興味関心をもたせる
③Desire ⇒ 欲しくさせる
③Action ⇒ 行動
の頭文字です。

これも結構広く認知されている法則の一つです。
流れはとてもシンプルで分かりやすいですね。

「A」で、まずは注意を引き、「I」でそのサービスのメリットを伝えて興味関心を持たせ、「D」で特典や客声などそこで買うメリットを提示して欲しくさせ、「A」でアクションさせる。

これは、どちらかというと商品の認知がある商品やサービスに向いていますね。

iPhoneやプレイスステーション等、その商品の形状やスペックの認知度が高い商品にお薦めです。
例えば、iPhoneを検索してくる人は、既に商品のことを知っているから、
知りたい情報は商品のスペックや機能以外の話ですね。

どちらかというと納期や金額の方が気になると思います。
なので、ページではクドクドと説明せず、お客さんが知りたい情報のみにするのが
この法則を使う際の注意点です。

これも例えるならこんな感じですね。

2


僕は、詳細説明が購買につながる動機になりやすいものは【QUEST FORMULA】
商品詳細以外の魅力、たとえば値段や期日などによって購買につながるものは【AIDAの法則(アイダの法則)】をベースに考えています。

みなさんも作る際の参考にしてください。

それでは、また次回!