読者です 読者をやめる 読者になる 読者になる

ku-sukeのブログ

Just another hatena blog

ディレクターでもWindow関数が使えるようになる!ビッグデータ時代のSQLレシピ本

ぶっちゃけ、この本をみるまで、SQLにこんなにたくさんの関数があること知りませんでした・・Webアプリで使うSQLと分析でつかうSQLってこんなに違うんですね。

f:id:ku-suke:20170323153720j:image

献本いただいたのでレビューです。来週発売で予約開始してます!

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ分析・活用のためのSQLレシピ

 

 SQLレシピということで、500ページにもわたる本書のなかみはSQLだらけなのですが、目次を見るとワクワクしてきます。

たとえば8章

検索機能を評価する

1 NoMatch率とそのワードを集計する 

2 再検索率とそのワードを集計する 

3 再検索ワードを分類して集計する 

4 検索離脱率とそのワードを集計する

サイト内検索のエンジンがいけてない場合に、どうやって改善すればいいかを具体的な考え方でまず教えてくれて、さらに集計するにはどういうSQLを投げればいいかまで書かれています。

SQLの書き方はわかった。でもそれをどう活用すればいいの?ということが現場のプロだけあって実戦で即役立つ事例が集まっています。

他にもレコメンドエンジンを作るSQLも載っています・・・恐ろしい子

レコメンド 

1 レコメンドシステムを広義に捉える 

2 このアイテムに興味がある人はこんなアイテムも見ています 

3 あなたにオススメの商品 

4 レコメンドシステムを改善するポイント 

5 表示時におけるポイント

f:id:ku-suke:20170323153725j:image

もちろん、よくある Webサイトのユーザーの行動分析も非常に詳細にかかれています。SQLの本なのですが、分析のやり方から教えてくれるのでディレクターでも読める、あるいはデータ分析チームがある程度おぜん立てしてあげれば、「ここよんどいて」って渡すのにもいいですね。

もちろんSQL部分も充実!

とはいえ、本書はSQLの本なので、素晴らしいのはDBごとの書き方をすべて書いてくれていることです。

PostgreSQL Hive Redshift BigQuery SparkSQLに対応しており、

Hive Redshift BigQuery SparkSQLの場合、SELECT文とUNION ALLで 代用可能

のように、特定のデータ基盤ごとのクエリの書き方を用意されているので、ほとんどの現場で即使える本だと思います。

 

データの分析を行うすべての現場に必携の1冊です!うちの会社のメンバーにも紹介しましたが、「これはありがたい」といろんな部署から見せてと言われました笑

 

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ分析・活用のためのSQLレシピ

 

 

 

SFベイエリアいってきた雑記

PAAKという起業家支援のコミュニティ+場がありまして、そこが主催するワークショップにメンターとして参加してまいりました。期間中、人事発表(特に何もなかった)や大学院が無事終了するなどいろいろあったんですが、ハードすぎてわりとfacebookもほとんどできずという感じでした。

大きめの企業ではGoogleGithubAirBnBなどを訪問したり、いろんな立場のエンジニア、デザイナー、アクセラレーター、起業家の皆さんと深いお話をさせていただきましった。

techlabpaak.com

SFベイエリアいってきてどうだったの?

シリコンバレーとか最近言わなくて、サンフランシスコ市内とかも併せてベイエリアというんですよ。ちなみにシリコンバレーっていうけど、東京都の面積の3~4倍以上ある、おおざっぱな概念です。複数の市が集まってます。いっぽう、サンフランシスコ市の面積は練馬区くらいの小さな場所です。

大阪→東京と似た感覚

大阪から東京に出てきた時と似たような感覚で、やっぱり「こんな最先端のものにお金が出るから人も情報もあつまっとるなー」っていう感想と、「でも住むなら日本(大阪)が好きだなー」っていう感想につきます。

投資環境がケタ違いなので、よく分からないものにもお金出るし、すでに世の中にあるけどすこし領域特化だったりひねった感じのものにも投資が出る。もちろんユニコーン企業みたいなめっちゃすごいのはそうそうないけど。

 

「新しいアイデアをβ作ってみました」→「いいじゃん!投資するよ」→「ちょっと顧客もついてきました!」→「いいじゃん、投資お代わりするよ」→「XXに会社買ってもらいましたーやったー!」

みたいなパターンが多いみたいです。件数でいうとIPOはそこまでおおくなくて、IT系の大企業に買われていく模様。

街はやっぱり地元が好き

SFはやっぱ局所的にデザインが美しい建築物とかあるんだけど、工事中や荒廃している部分も多く、総じて子供を住まわせたいと思わなかったです。ホームレスたくさんいておしっこ臭い場所とかマリファナのにおいもたくさん漂ってたし。

じゃあ田舎であるシリコンバレーのどこかに住むかっていうと、夫婦ともに車の運転が上手じゃないと厳しいなっていう感想で(行ったことないけど)つくばとか、山奥の先端都市って感じで生活の楽しみが少ない感じ。SVの気候はよくて、緑の中で太陽浴びてたらもういろいろ最高だなっていうのはわかります。

 

あと物価が東京のだいたい2倍なのもつらい。だからこそ年収も2,3倍なんだけど、ランチ2000円、家賃50万円とかほんと年収2000万くらいないとつらいなって思いました。

こっちの社員ってすきにクビにできるから、日本における業務委託として常駐するのに近い感覚でした。もちろん福利厚生はありますが。

日本のマーケットと世界のマーケット

あとは、単にベイエリアでなんでみんなビジネスするかっていうと、グローバル相手のビジネスをするのに情報が集まっているからで、べつに住まなくてもいいけど大阪本社の会社が東京に営業拠点を置くように、こっちのマーケット感覚をちゃんと身に着けるために足しげく通って、現地コミュニティのなかで関係性をきずくのはとても大切なことだと思いました。

ただ、それもここ以外にも世界でいくつかあって、シンガポールとか深センとか、自分がやりたいことにフィットしたお金と情報が集まる場所に身を置くことは大事なんだなーと。

あとはどうなんですかね、向こうに法人あったほうが会社売りやすいのかな。国をまたぐと買収スキームとかめんどくさそう。

社会を構成するモジュールとお前なにやりたいの?という会話

ベイエリアの人々は、自分の考えを持っているし、ふつうに前面に出してくる。日本人だって自分の考えを持っていないわけでは決してないけど、10時間とかあったときにそれを発露している時間の割合のが10倍くらい違うイメージ。

だから、社会全体がすごくRole&Responsibilityというか、役割ががちがちに定義されていて交換可能なモジュールで構成することで多様な人々をマネジメントしているように感じました。

なので、あなたは何者なのか、という社会を構成するパーツとしての明示と、その反対に人間としてどうしたいのか?という2つの問いが常に交わされているように感じました。

若者すごい

おまけだけど、つれてきた若者がすごいいい感じの子たちだったので、おじさんとしては彼らになにかしてあげられるようにしたいなとおもいました。まる。

もうね、メンターだからできるだけ若者優先に意識したけど、本当に自分たちもまじって交流する場をいくつも持てたので最高でした。

というわけで、1週間見聞きした観測範囲なのですが、レポートでした。明日帰路につきます。

プロダクトマネージャーと呼ばれる何かになるまで(メモ)

まとめる時間はないのでメモ。自分で見返すようなので読みにくいです。

 

今日は、こちらのイベントをやってきました。

pmjp.connpass.com

第2回ということで、第1回もあったのですが。

 

Slackのpmjpという集まりがあって、そこの皆さんに「育成とか評価とかどうしてますかー?ちょっとオフ会前に壁打ちやってくれませんかー」と呼びかけたところ大勢集まってしまったという会です。

 

第1回、第2回を通して、人はどうやってPMになっていくのかの入り口が見えてきた気がしました。

第1回での学びは、事前にもっていったスキルがあって、だいたいプロダクトマネジメントトライアングルと同じなんですが、これができる人ですかね?という問いかけでした。

ninjinkun.hatenablog.com

結論としては、そんなの全部できるやついねーよ!とか、プレイヤーとしては各スキルが一流でなくとも、焼き肉力とかで成功するPMもいるよね。ミニCEOなんだから、事業を成功させる力だよねPMって。みたいな学びがありました。

しかしながら、組織としてPMをどう育てていくかみたいな部分で、初めの第一歩をどう踏み出すのがいいかまだ納得いく言語化ができておらず、第2回でエンジニアスペシャルをやり、エンジニアからなぜPMになったのかみたいな話を深堀しました。

 

そこで無理やり出したまとめとしては、エンジニアが顧客に興味を持ちだしたらそれはPMの第一歩ではないかというふうになってきました。「正しいものを正しく作る」という言葉がありますが、まずは後半の正しく作る部分のエンジニアリング力を上げていき、そこから顧客が本当に必要だったものを知ろうとするスキルを付けていくのではないか(僕の解釈です)

そのために組織としては、エンジニアが顧客と触れ合って、プロダクトが必要になる場面を観察させる場を設けるのは大事だと。全エンジニアに強制しなくてもよく、興味ある何人かが参加できるようになっていればよいのではないか。

 

逆にグロースハックに進むのはどう?という問いかけにはなんか違う気がする・・な反応でした。まぁA/Bテスト一つとってもエンジニアだけではやりにくいですし、顧客に興味がない状態でKPI至上主義になるのも健全じゃないですね。

 

そして、顧客がほしがるものをある程度作れるようになったらミニPMで、そこからは苦難を乗り越えながら&社内の専門家と協働して成長していく感じでしょうか。

  • 顧客が喜んだのにたくさんの人には届かない
  • 顧客が喜んだのにチームが険悪で退職者が
  • 顧客が喜んだのに売り上げ規模が足りない。あるいは大赤字
  • 顧客が喜んだプロダクトに営業部門がごり押しで変な機能を増やす
  • 顧客が喜んだのに主力プロダクトに人をとられて(ry

みたいな。正しいプロダクトを作れたとしても、それがビジネスとして成功するかはもっと乗り越える壁があると思います。

そうやって、マーケを学んだり、全社の事業戦略、事業ポートフォリオを学んだり、営業部門が普段どんなことで悩んでいるのかを知ったり、契約ごとに詳しくなったり、ある程度社内政治にも耐えうる振る舞いを知ったりして「ミニCEO」になっていくのかなーと思いました。

 

 

 

あと余談メモ

 

・東京においては、人材を確保する力っていうのも、ベテランPMに求められそうです。金と案件くそほどあるのに適材適所にばちっとはまる人がいなくて動かないプロダクトが結構ある気がします。まぁスモールチームが多いから、わりとフルスタックXXを求めちゃうせいかもしれない。チケット単位とか明確な業務なら比較的リモートとかで仕事ふれる時代にはなりましたしね。

 

・エンジニアとのコミュニケーションは現場ごとの文化がありますが、エンジニアが納得感があるってのが大事だと。なんでこの機能をこの時期に作らなきゃいけないの??とか。あと職場でヘッドフォンしている場合話しかけてよいかとかw

 

以上メモなので読みにくいですが寝ると忘れる性格なので書き残し。

サービス運営時の料金設定に関する5つのポイント

先日、こんなtweetをしたらおもったよりRTされてしまったので、他にも過去の経験で値付けについて学んだことを書いてみたいと思います。多くは行動経済学の本とかに出てくると思うのですが、実例ベースで。

サービス設計で値付けに迷ったり、そもそも課金モデルにするか広告モデルにするか悩んでるときの一助となればと思います。

1.周囲の値段との「差」を意識して引きずられてしまう。

f:id:ku-suke:20170108005814p:plain

アンカリング効果というやつですね。ぼくがマーケティングの世界に興味を持ち始めたiPhoneアプリ黎明期に社内で話が出ていました。AppStoreで、有料アプリランキングに100円アプリが並んでいると、300円がすごく高く見えてしまう。

しかし、300円で買い切りで何年も使えるって普通に安いですよね。スタバのカフェラテより安いじゃないですか。

逆に、3千円の上コース、1500円のセット、900円の単品とか松竹梅で並べられると、1500円と900円の2択の時より1500円を選ぶ人が増えるようです。

なので、ユーザーがその製品カテゴリの価格にどのようなものを期待しているかどうかで、値付けは変えないといけません。

価格の方を動かせない(コスト構造上無理!)となると、サービス側の建付け、見せ方を変えて製品カテゴリの方をずらす必要があります。他のサービスと比較表に入れられないように逃げるのです。

2.ソシャゲは富の分配か?極端な客単価の差を生み出す時代

こちらが先のツイートになります。他の例では海外の月額系サービスで、数年前から「結構いい値段するな・・」「ちょっと高いな」と感じるようになったのですが、自身でも法人向けのASPサービスを何年か前に運営してみて、その理由に気づきました。

無料プランのユーザーを養うには、有料ユーザーに10人分は最低払ってもらわないと困るんです。無料ユーザだって最低限のサーバリソースと、問い合わせ対応などの人的コストがかかります。更に人数だって多いし、、、。そのコストは有料ユーザに払ってもらうしかありません。

なので、フリープランがない(○日間フリートライアルは別)サービスは、意外と価格の段階が緩やかなのですが、フリープランがあるサービスは、オトクな売れ筋プランを一歩超えると急激にボッタクリ感が出る気がします。

もちろん、それらの背景に対しては、ごく一部の大企業しか利用しない機能をわざわざ作ってあげてるんだからコレくらいは払ってね、というコストから逆算した設計ももちろんあると思いますが。

3.原価率は素人の肌感より低く押さえる。値付けには宣伝費を考慮しておくこと。

こちらは自身の運営ではないのですが、とある企業では月額3000円の商品の購入者を得るために、無料またはほぼ赤字の価格でまずはトライアル購入を獲得します。が、その獲得コストが1人あたり1万円弱とか広告費使っていたりします。

つまり、予測されるLTV1万円の場合に、それを少し下回る広告費でトライアル獲得できれば良いという考えです。LTVとは簡単にいうと課金額×継続率で、50%の確率で12か月毎月買ってくれるので、利益2万円として×50%の1万円という式になります。

この場合、12ヶ月3万6000円の売り上げで利益が2万円なので、原価は約1万6000円、44%です。製造以外にかかる費用が50%とすると純粋な原価は22%ですね。素人考えではぼったくりな気もしますが、業界によっては流通コストなどにより純粋な原価に22%もかけたら大赤字というところもあるでしょう。

広告費をどれくらい使うかと、単発ではなく継続した売り上げがどの程度入ってくるかも逆算して値付けをしないといけないのです。

4.割引ではなく追加でプレゼントする

売値1万円、原価5000円の商品を15%引きで売るのと、1万円に20%ポイントをつけるのはどちらがサービス運営側にとってお得でしょうか。

なお、資金決済法があるのでポイントは半年で消滅する、あるいは市価で20%相当の品でも構いません(ポイントを行使すると考えれば同じですね)。

  • 1万円の商品を15%割引にすると、売り上げ=8500円、利益3500円です。
  • 20%のポイントを提供すると、まず売り上げ1万円、利益5000円、会計上の負債が2000円になります。
    • その後、半年たって失効すると、負債が消えます。
    • ポイントではなくおまけを提供すると、2000円の商品の原価が利益から消えます。ここで原価が1000円の商品の場合利益が(5000-1000で)4000円になり、15%より提供側がお得になります。

 ここで重要なのは、見かけ上15%引きより20%プレゼントのほうが買う側からみて何となくお得そうに見えるのに、提供側からすると割り引くよりプレゼントしたほうがお得ということになります。

 しかも、ポイントの場合は会員囲い込みで再来訪の可能性が上がりますし、Dropboxみたいなデジタルサービスは、上限容量をひきあげても、上限いっぱいまで使うユーザは少ないので実際の原価負担は大幅に少ないと考えられます。

5.本質的な価値とお金を払う価値は違う事もある

以前、1万円の価値(と企業規模と業務システム)のはなし というエントリを書いたのですが、使いたいサービスがあっても企業でクレジットカードが使えないからちょっと、、という話です。

ここではサービスの価値(使いたいクラウド)と、お金を払う価値(日本の商習慣にマッチしている)が微妙に異なってるといえます。

また、個人的にシステムのコンサルをしていた時も、自分が楽勝だけど利益率が高い部分(たとえば簡単なプログラミング)と、自分がめっちゃ頑張るし価値があると考えてる部分(戦略立案と調査とか)に難色を示されて結局サービスでやったりといったことがありました。

顧客に理解してもらえないけど大事なポイントを無償あるいは安く提供するために、顧客が理解してお金を気持ちよく払ってくれる部分で多めに利益を確保するということが双方にとって幸せなのだなと感じました。

 

以上、商品のプライシングは難しいとよく言われますが、自分で感じたことを整理してみました。

2016年の振り返りと今年の抱負

あけましておめでとうございます。ことしは帰省せず家族でゆっくりと正月を過ごしています。昨日は東京観光しようとお台場行きました。空いていてよかったです。

2016年の振り返り

転職~東京に引っ越し

2016年1月から現職でお仕事を始めました、それに合わせて忙しい年始に引っ越しを強行しました。子供は小学1年生なので、昔住んでいた練馬区に着地しました。

最初に住んだ家の管理会社がとても残念な感じで、引っ越し搬入時にもらったカギでドアが開かない(交換忘れ)、掃除も微妙ということで波乱のスタートでした。

また、会社のほうも入社即インフルで、実質2月からのお仕事開始でした。

家を買った

前述のとおり管理会社の不信感MAXだったのと、東京の賃貸たけええええってなったのと、同一学区内に中古のマンションが出ていたこともあり、東京に引っ越しして1か月くらいで家を買いました。マイナス金利のおかげで勤続1か月でもローン通りました。

通勤は大阪時代よりかなり遠くなりましたが、1-2時間くらい早く退社できているのでトントンというところです。

久しぶりに新規事業チャレンジ

仕事内容は教育系の事業部の新規事業で、いわゆるβリリースが終わったフェーズのプロダクトのプロダクトオーナーを担当することになりました。人数構成としてプロデューサーというか企画側が多いなぁという印象で、前職だとプロデューサーが1人なんだけど、こちらは兼務も含み実質2人半くらいいる感じでした。

プログラムは外部パートナーさん製で、えいやで突貫工事したものだったので、それを内製巻取りするところからでした。よくプロダクトのフェーズで、0-1、1-10、10-100みたいな分け方があると思いますが、そういう意味では今のプロダクトは1-10のところで、1年間かけて1→7くらいまで持ってこれたと思います。割と一番得意なフェーズです。

チーム作りの変遷

新規事業ですが内製エンジニアの数も、3人くらいだったのが兼務などこみで15人くらいになりました。最初は属人化MAXで、最近はチームの安定化、自走化をめざしてそちらにリソースを割いています。アジャイルコーチにも来てもらってます。チーム作り自体はやる気のあるエンジニア勢に丸投げしてただけですが、彼らがやりたいといってきたときに、いいよと答えるbotとなっています。

基本的に新規事業というのは、コアメンバーが突如異動しちゃうリスクに常にさらされているので、スローガンは「(自分を含む)誰かがいなくなっても生き延びられるチームにしよう」ということを言い続けていました。

プロダクトマネージャとしての活動

プロダクトオーナーというのはスクラムの概念で、もう少し広いプロダクトマネージャというものにも領域を広げていて、pmjpのSlackでPMになるためのスキルセット勉強会というのをさせていただいたりしました。あとはこういうまじめな内容で100ブクマ超えてご機嫌な先日のエントリとか↓

blog.ku-suke.jp

本を出した

関係各位に根気強く付き合ってもらったアプリマーケティング本をリリースしました。これ関係で講師やコンサルのお仕事もいただきありがたい限りです。

 

スマートフォンアプリマーケティング 現場の教科書

スマートフォンアプリマーケティング 現場の教科書

 

 

2017年の抱負

わたしいま通信の大学院に通ってるのですが、なんとか卒業したいなということで冬休みも卒業研究の資料作りに追われています。

あとは本業のほうもいよいよ次のフェーズに進むので、しっかり定量目標にコミットすることと、引き続き限られたリソースの中でユーザーにとって良いものをお届けしたいです。

副業のほうも東京来てからコンサル、講師、システム系のご相談を中心にいくつかご依頼いただきましたが、ご協力できる範囲で引き続きお受けしていこうと思います。現職はやっぱり法人持ってるよー、つくったよーっていう人がちらほらいて、やっぱりすごいなーと思います。

総括としては、ことしは今まで学んだことを生かして、成果を上げる刈り取りの年にして、来年からまた種をまく、しっかりしゃがむための体力をつけたいと思います。

最後に、今年は慣れない環境の中、公私ともにたくさんの方に助けてもらいっぱなしでした。お礼を申し上げるとともに、今年もどうぞよろしくお願いいたします。

「基礎から学ぶ チーム開発の成功法則」を読んだ

 こちらの本を献本いただいたのでさっそく読んでみました。

基礎から学ぶ チーム開発の成功法則 (開発現場の教科書)

基礎から学ぶ チーム開発の成功法則 (開発現場の教科書)

 

 こんなんじゃだめだ!スクラム(or XXX)やらなきゃ!の前に

今年は会社にスクラムのPO研修受けさせてもらって無事POになったんですが、本業のほうはいま10人くらいの制作チームにまで成長して、Qごとにチーム運営方法を整備したり変えて行ったりと非常に大変な1年だったなと思っております。

また、いくつかの開発現場にコンサル的な形でおじゃまさせていただいて、特に東京だからかもしれませんが、いわゆる本書のような「チーム開発の運営」ができる人材というのはほとんどいないなと。

まだまだCIだったり、デザイナーとエンジニアとコラボしたりっていうのを「経験」として持っていて、かつ言語化できるひとというのは希少だと感じています。

そういう人がいない現場では何が起こるかというと「なんかわからんけどおかしい!!」という風になるわけです。その矛先は、無差別に新しい要件を持ってくる上の人だったり、逆に○○しかやりません!みたいに硬直化するメンバーだったり様々ですが、解決策がわからないと「この状況を打破するにはスクラムしかない」といった銀の弾丸思考になりがちです。

開発手法だけでなく、ツール、コミュニケーションまで踏み込んだ一冊

その点で本書は、チーム開発を取り巻く「やるべきこと」にどのようなものがあればいいのか、幅広い観点で書かれています。

Chapter 1 チーム開発の概要
チーム開発手法の概略と、開発手法を利用する上で何が重要であるかを解説します。
Chapter 2 チームの役割
チームに必要とされる人材とそれぞれの役割を説明し、チームの全体像を描けるように解説します。
Chapter 3 チーム開発に使うツール
数多く公開されている開発ツールから最低限必要なツールを紹介し、チーム開発への導入を解説します。
Chapter 4 チームでのデザイン制作
チームデザインで発生する各種作業の内容や、制作する成果物を解説します。
Chapter 5 コーディング
効率よく実装し品質を向上させる、コーディング方法やコードレビュー、ユニットテストの重要性などを解説します。
Chapter 6 自動化とリリース
ビルドからサービスのリリースに至るまで、継続的インテグレーションとデリバリー、プロモーションなどを解説します。
Chapter 7 チームのライフサイクル
チームのライフサイクルを解説し、高い生産性を誇る安定したチームを作成する術を解説します。
Chapter 8 チーム開発のフロー
サービスがリリースされるまでのフローを、自社開発と受託開発それぞれの視点から解説します。

 「コードレビューしたほうがいいよね」「Jenkins立てて自動化したほうがいいよね」「振り返りやったほうがいいよね」という一度は聞いたことがある、そしてやったほうがよさそう系の事が網羅されています。

さらにはツールにも言及されていて、Backlogを使うのか、Confluenceを使うのか、GithubWikiを使うのかといった点も、経験が少ないチームにはその入口として役に立つと思います。どうしてもツール導入には学習コストが伴うので、疑心暗鬼のまま進むと身につきにくいし。

プロデューサー・エンジニア・デザイナーがどうコラボするか

本書は幅広い内容を網羅した内容となっていますが、最後のChapter08を最初に読むのもいいかもしれないです。自社企画を進める場合や受託の場合など一通りの流れが書いてあって、それぞれの場合にどこを読めばいいかが示されています。

本書に興味を持つのは、現場に課題感を持つエンジニアだったりすることが多いと思うので、まずは視野を広げて、別の職種がどういう仕事をやっているかも俯瞰することが、ボトルネック改善の第一歩になるのではないでしょうか。

どうしても、強い危機感・課題感とぱっと目についた開発手法が組み合わさって、非常に狭い範囲での部分最適に陥ってしまうことが往々にあるので、本書のような全体を網羅した本を何度もパラパラとめくる、あるいはチームで輪読することで、自分たちがまずやるべきことが見えてくるのではないかと思います。

冬休みの読書にお勧めの一冊です!

 

基礎から学ぶ チーム開発の成功法則 (開発現場の教科書)

基礎から学ぶ チーム開発の成功法則 (開発現場の教科書)

 

 

 

HP Spectre x360(USモデル)買ったぞ、これはいいぞレビュー

 ついに届きました!HPのSpectre x360のUSモデル。最高です。

f:id:ku-suke:20161211184035j:plain f:id:ku-suke:20161211184047j:plain

開封の儀をしようと思ったけど、さっさと使ってしました。hpロゴが主張しなくてよい感じです。

重さは、個人的にはやや重いです。MacBook Air 2011からの乗り換えなので、約200g重くなりました。会社で使ってるVaio Pro 13 mk2と比べると体感でかなり重くなったイメージです。

スペックをおさらいすると

  • CPU Intel Core i7 7500U(Kaby Lake)
  • メモリ 16GB
  • SSD 512GB NVMe
  • USB Type-C x 2 / USB-3.0 x 1
  • 重量 1.29kg
 

f:id:ku-suke:20161211184102j:plain

ついにUSキーボードデビューしました。打鍵感はめちゃくちゃ良いです。シルバーで統一されているので、なんか一昔前のMacみたいなかんじです。PowerBook12インチってこんな感じでしたねw

トラックパッドもガラス製で、これがWindowsか・・というくらいなめらかです。上下だけでなく左右スクロールもなめらかです。キーボードレイアウトの右端にいろいろついているのはまだ慣れないですが、USキーボードはすぐになれました。ブラインドタッチもこれを機に習得してみようと思います。

f:id:ku-suke:20161211184122j:plain

なんか革製のスリーブもついています。まぁいいんじゃないでしょうか。

外で使ってみた

f:id:ku-suke:20161211184138j:plain

子供を英語の習い事に送って待っている間、マクドで時間を過ごします。左側に従来のUSB-3.0ポートがついているので、ちょっとしたiPhoneの充電など従来のケーブルが利用できてよいです。しばらくはまだケーブル買い替えずに済みそうなのと、ちょっと人に借りるときにも便利そうです。(右側はUSB Type-C×2、Thunderbolt 3対応)

f:id:ku-suke:20161211184148j:plain

せっかくなので2 in 1のフォームで使ってみました。完全にひっくり返して閉じてしまうタブレットモードは意外と重たく、画面の端を誤タップしてしまうので、そこまで使うかわかりませんが、気に入ったのがこのモードです。

画面が手前に表示されるので、最近視力の落ちてきたおじさんがKindleのコンテンツを読むのに適しています。だらだらできます。タブレットをスタンドに立てかける感じですね。13インチなので画面も文字サイズも大きいです。

意外とましになったWindowsの高解像度・フォント対応

前回の記事で、あと3年くらいはかかりそうと書いたWindowsの高解像度およびフォントが汚い問題ですが、ヒラギノが好きという要望が満たせない以外はわりと良好でした。

日常利用のアプリはほぼネイティブ化されており、フォントのレンダリングRetina対応されています。ChromeについてもデフォルトフォントをMSゴシックからメイリオに変えることで快適に使えます。(がしかしせっかくなのでEdgeつかってみてる)