谷本 心 in せろ部屋

はてなダイアリーから引っ越してきました

Macに出戻りました。

去年の3月頃に、MacBookからThinkPad X1 Yogaに乗り換えたという話を書きました。

MacBookからThinkpad X1 Yogaに乗り換えます。 - 谷本 心 in せろ部屋

その8ヶ月後、Surface Bookに乗り換えました。

ThinkpadからSurface Book with Performance Baseに乗り換えました - 谷本 心 in せろ部屋

MacからWindowsにした理由は、USB Type-AとかHDMIもまだ欲しかったことと、WindowsでもDockerとかWSLとかBabunとか使えばで割とふつうに開発できるんじゃないかと期待したことでした。その点については概ね期待通りであり、何ら問題ありませんでした。 そしてThinkPad X1 YogaにしろSurface Bookにしろ、ペンで手書きできることは予想以上に良くて、設計や執筆の初期段階でアイデアを練る時には、常にペンを使っていました。

手描きしたいなら紙で良いじゃんみたいな話もありますが、紙だとふつうになくすんですよ!

Windowsのココが辛い

そうやって1年以上はWindowsを使いながらも、細かな不満はありました。

  • キーボードの取りこぼしが起きる
  • Chromeの起動とか、IntelliJの起動が、なぜか遅い
  • スリープから復帰した時の挙動が微妙
  • タッチパッドMacBookほど最高じゃない
キーボードの取りこぼしが起きる

一番の不満は、OSの問題ではなく、ハードウェアの問題なんですが、キーボードの取りこぼしが起きることでした。

ThinkPadだと「ryu」の3つ同時押しで「u」が認識されません。Surface Bookだと「esu」の3つ同時押しで「u」が認識されません。別に同時押しがしたいわけではなく、普通に打鍵してる中でこのような取りこぼしがちょくちょく起きることが、凄くストレスになります。

これ、逆に聞きたいんですが、皆さんってこの現象あまり起きないのですか? おそらく僕の打鍵の癖として、前のキーから指を離す前に次のキーを打ってるせいでこの現象に遭うんでしょうけど、高速に打鍵してるとだいたいそんな感じになりませんか?

ゲーミングノートであればだいたいNキーロールオーバー対応されているため、このような問題は起きないのですが、ゲーミングノートはだいたい熱くてうるさいので、なかなか常用しようという気にはなれないのですよね。

Chromeの起動とか、IntelliJの起動が、なぜか遅い

なんかアプリの起動や操作にイチイチ引っかかるように感じていて、Chromeの起動になぜか数秒待たされたり、IntelliJの起動にずいぶん待たされたりしてしまって。性能的にはSurface Book(Core i7 6600U) の方が、MacBook Pro(Core i5 4258U) を完全に上回っているにも関わらず、ブラウザやIntelliJの起動はなぜかMacBook Proの方が早かったりして、何かおかしいんですよね。

検証はしてないのですが、Windows標準のセキュリティソフトであるWindows Defenderのせいかも知れません。Eclipseなんかも起動すると数分ぐらいWindows DefenderがCPUを使いっぱなしになったりするので。ノートンみたいなサードパーティ製のセキュリティソフトに変えれば解決する可能性はありますね。

あと、ゲーミングノート側はChromeの起動が早かったんですが、ゲーミングノートはだいたい熱くてうるさ(略

スリープから復帰した時の挙動が微妙

Surface BookにしろThinkPad Yogaにしろ、スリープ(スタンバイ)から復帰した時に、Bluetoothキーボードが効かなくなったり、サブディスプレイが映らなくなったり、あとそもそも画面を閉じてもきちんとスリープしてなくて、カバンの中でホッカホカになることも多かったです。

そもそもスリープとかせず、電源を切れみたいな話もあるかも知れませんけど、ノートPCをパカッと開いたらすぐに使い始めたいじゃないですか、やっぱり。

まぁゲーミングノートなら、電源を切ったとしてもすぐに起動するのでまだ良いのですが、ゲーミングノートはだいたい熱(略

タッチパッドMacBookほど最高じゃない

これもOS関係なく、ハードウェアの問題なんですが、やっぱりタッチパッドが今ひとつなんですよね。Surface BookタッチパッドWindowsの中では群を抜いた使いやすさではありますが、それでもMacBookには少し劣るため、どうしてもマウスを併用する感じになります。

この辺は本当に単純にハードウェアの問題なので、言ってみればMacBookWindowsを入れて運用しても良いわけですが、別にそこまでするほどWindowsのことを愛しているわけじゃないという感じです。

あとまぁ別にマウスを持ち歩いちゃえば良いじゃんと思いますし、Windows中心だった時は確かにマウスを持ち歩いていました。

MacBook Proに戻ったきっかけは、働く会社が増えたこと

そうやって細かい不満を抱えながらも、Windowsノートとは上手く付き合ってきたのですが、4月から新しい会社で働くようになり、そこで皆がMacBookで開発環境を作っていたので、自分も古いMacBook Pro (Late 2013) を引っ張り出してきて仕事をするようになりました。

そうするとね、快適なんですよね。

MacBookは別にNキーロールオーバー対応しているわけではない(たとえばKOIの3つを同時押しするとIを認識しない)のですが、両手でローマ字打ちしている限りは問題になる組み合わせは経験していないですし、アプリは変な引っかかりがなくきちんと動きますし、スリープからもきちんと復帰します。

2台持ちしていた時代もありました

MacBook Proを改めて使うようになってからも、しばらくはSurface BookMacBook Proの2台持ちをしていました。なんだかんだ言ってSurface Bookのほうが性能は良いですし、手描きメモとしても活用していたので、役割を分けて使っていました。あわせて3kg以上で、ACアダプタやキーボードを含めるともっと重いのですが、リュックで背負って歩く分にはさほど気になりませんでした。

ただ、前述の細かな不満のせいで徐々にWindowsを使う機会が減っていき、最終的に、iPadApple Pencilを買ったところで手描きメモとしての座も奪われたSurface Bookは、我が家の棚で余生を送ることとなりました。

もちろんMacにも不満がありますけどね

もちろんMacだと、Androidからファイルをコピーするのが果てしなく面倒だとか、Office系アプリの起動が異常に遅いだとか、特にOne Noteあたりの挙動が微妙だったりという不満もあります。それに最近のMacBookって、バタフライキーボードが酷評されてますし、タッチバーも微妙だし、Type-Cしかないしで、なかなか買い換える気にもなりません。

ただ、ペンを使うタブレットとしてiPadシリーズはやっぱり最高だし、iPhoneとPixel 3の2台持ちをしてるけどiPhoneの方が(Felicaの使い勝手を除き)使いやすいと感じるし、iPad / iPhoneとの連携を考えると明らかにMacの方が便利だし、という感じで今のところはAppleにロックインされている方が幸せかなという感じではあります。

とは言え、ゲームをする時とか、動画配信する時とか、Android端末からファイルコピーする時とかは、Windowsのゲーミングノートを使ってますけどね。総じてWindowsのほうが高性能のPCを低価格で購入しやすいですよね。

そんなわけで、MacWindowsを行ったりきたりして、最終的には両方とも使う感じにはなっていますが、次に買う一台は、MacBookかなぁと思っています。

16インチMacBook Pro、早く出ないかな・・・。

GraalVM + Javaで作ったバイナリをAWS Lambdaで動かす時にハマった所

仕事でAWS Lambdaを使う機会が増えてきたのですが、やはり書き慣れたJavaでLambdaを書きたいなと思うことが少なくありません。ただAWS LambdaでJavaアプリを動かすと、初回アクセスに十秒近く掛かるし、メモリ消費量も大きいしで、パフォーマンス的にも運用コスト的にも嬉しくありません。そう思ってるところで、JavaのアプリをGraalVMでネイティブビルドをすれば初回起動時間もメモリ消費量も抑えられると聞いたので、これに取り組んでみました。

ただ実際にやってみると、わりとエラーが頻発してしまって、トライ&エラーを繰り返しながら先に進むという感じになりました。せっかく色々と試したので、起きた問題とその解決策・回避策なんかをここにメモしておきます。

やったこととか参考にしたサイトとか

やったこと

まずJava8(1.8.0_202)と、Micronaut(1.1.3)のライブラリを使って、AWS LambdaのJavaランタイム向けのjarを作って動作確認をしました。Micronautはフレームワークとしては利用せず、あくまでMicronautのライブラリとプラグインだけを部分的に使う形で利用しています。

Javaランタイムできちんと動くことが確認できたら、次にGraalVM(19.0.2)を使ってnative-imageコマンドでバイナリを作り、AWS Lambdaのカスタムランタイムとして動作させました。

この辺りまでのやった内容は、GitHubに置いてあります。

https://github.com/cero-t/lambda-graal

さらにこれをベースにして、JavaのImageIOを使った画像のリサイズを行う処理を書こうとしているのですが、そこでハマってしまっているというのが、いまの状況です。

参考サイト

ひとつ目が @kencharos さんのQiita記事。今回GraalVMを使ってみようと思ったきっかけであり、よりどころであり、この記事なしでは何事も進みませんでした。感謝。

qiita.com

もうひとつが、Micronautで作ったファンクションをAWS Lambdaで動かす辺りのことを記述してあるドキュメント。若干、メンテナンス不足だったのでプルリクしたりしてました。

https://micronaut-projects.github.io/micronaut-aws/latest/guide/#customRuntimes

起きた問題と解決策・回避策

繰り返しの説明になりますが、AWS LambdaのJavaランタイムできちんと動作確認を行なってから、それをGraalVMでバイナリ化してAWS Lambdaのカスタムランタイムで動作させました。そこでエラーが起きた問題について、まとめています。

NullPointerExceptionが発生 / 戻り値がnullになる

現象

リフレクションを伴う処理の戻り値がnullになる。たとえば次のようなコードで問題が起きる。

HttpResponse<MyEntity> response = httpClient.exchange(URI, MyEntity.class);
MyEntity entity = response.body();

これで取得した entity の値がnullになる。他にも、Jacksonを使った処理などでも同じことが起きる。

原因

GraalVMでネイティブイメージを作成すると、リフレクションに必要な情報がなくなってしまうため。上の処理ではリフレクションを使ってMyEntityのインスタンス作成や値の設定を行なうが、リフレクションが使えないためMyEntityのインスタンスが作れない、のだと思う。

対策

リフレクション定義ファイルを作る。

まず src/main/graal フォルダに reflect.json を作成する。JSONのサンプルはこんな感じ。

lambda-graal/reflect.json at master · cero-t/lambda-graal · GitHub

次に build.gradle にannotationProcessorを追加する。

dependencies {
    annotationProcessor "io.micronaut:micronaut-graal:1.1.3"
    annotationProcessor "io.micronaut:micronaut-inject-java:1.1.3"
}

これでビルドを行うと、できあがったjarにリフレクション定義ファイルが含まれるようになる。リフレクション定義ファイルが正しく含まれてたかどうかの確認は、jarファイルを解凍して META-INF/native-image/io/micronaut/reflection-config.jsonnative-image.properties があることを確認すると良い。

所感

リフレクション対象になるクラスの列挙はわりと面倒なので、案件の規模が大きくなるとちょっとしんどいかも。ルールを決めて運用すれば、何とかなるのかな。

② Unsupported method java.lang.ClassLoader.findLoadedClass(String) is reachable が発生

現象

Jacksonを使った処理で次のエラーが発生する。

com.oracle.svm.core.jdk.UnsupportedFeatureError: Unsupported method java.lang.ClassLoader.findLoadedClass(String) is reachable: The declaring class of this element has been substituted, but this element is not present in the substitution class

原因

jackson-module-afterburner というモジュールが、実行時に動的にバイトコードを生成しようとするが、GraalVMで作成したバイナリではバイトコード生成ができないためエラーが発生する。

対策

jackson-module-afterburner を依存から除外する。このモジュールを使っているつもりはなくとも、たとえば aws-serverless-java-container-core などがこのモジュールを利用しているため、次のように記述して依存から除外する。

implementation('com.amazonaws.serverless:aws-serverless-java-container-core:1.3.1') {
    exclude group: "com.fasterxml.jackson.module", module: "jackson-module-afterburner"
}

所感

実行時にバイトコードをエンハンスするようなツールは、軒並み動かなそう。アノテーションプロセッサーで、コンパイル時にエンハンスするようにしなきゃいけないね。

java.lang.NoClassDefFoundError: org.apache.commons.logging.LogFactory が発生

現象

commons-logging を使ったライブラリの初期化時にエラーが発生する。たとえば aws-sdk-java などを使おうとするとこの問題が起きる。

Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons.logging.LogFactory
    at org.apache.commons.logging.LogFactory.class$(LogFactory.java:1021)
    at org.apache.commons.logging.LogFactory.<clinit>(LogFactory.java:1674)
    at com.oracle.svm.core.hub.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:347)
    at com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:267)
    at java.lang.Class.ensureInitialized(DynamicHub.java:437)
    at com.amazonaws.regions.AwsRegionProviderChain.<clinit>(AwsRegionProviderChain.java:33)

原因

きちんと原因を追っていないけど、slf4jやcommons-loggingのような実行時にロギングライブラリを選べるような仕組みは、なんとなくGraalVMと相性が良くなさそう。

回避策

commons-logging を使っているようなライブラリの利用を避ける。aws-sdk-javaの代わりに、micronaut-http-client を使うなど。

所感

--initialize-at-build-time とか reflect.json とかをきちんと設定すれば、commons-loggingを使えるようになるかも知れないのだけど、この辺りの挙動がまだ理解できてなくて、ちょっと先延ばしにしてる。

④ IOException: javax.imageio.IIOException: Can't create cache file! が発生

現象

ImageIO.read(in) メソッドを呼び出して画像をロードしようとすると、エラーが発生する。

IOException: javax.imageio.IIOException: Can't create cache file!
javax.imageio.IIOException: Can't create cache file!
    at javax.imageio.ImageIO.createImageInputStream(ImageIO.java:361)
    at javax.imageio.ImageIO.read(ImageIO.java:1397)

原因

ImageIOは、staticイニシャライザでキャッシュファイル(一時ファイル)のパスを環境変数から取得している。staticイニシャライザの処理はネイティブイメージのビルド時に行われて、実行時に環境変数が再評価されることはないない。そのため、ビルド時に決定したキャッシュファイルのパスが、実行時には利用できない、という問題が起きてしまう。

回避策

一時ファイルを使わない、つまりImageIOのキャッシュファイルを使わないようにする。自分の作ったFunctionに、次のようなコードを入れておく。

static {
    ImageIO.setUseCache(false);
}

所感

ImageIOを --initialize-at-run-time の対象にすれば、環境変数の参照を実行時に行えるようにできそうなのだけど、このオプションを指定したところ、他のクラスの初期化をコンパイル時に行うためか、エラーが起きてしまった。

ビルド時評価や、実行時評価の設定を、上手くできるようにならなきゃ。。。

java.lang.UnsatisfiedLinkError が発生

現象

ImageIOでJPEG画像を読み込もうとすると、次のようなエラーが発生する。

java.lang.UnsatisfiedLinkError: com.sun.imageio.plugins.jpeg.JPEGImageReader.initJPEGImageReader()J [symbol: Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_initJPEGImageReader or Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_initJPEGImageReader__]

原因

JPEGをロードするためのプラグインが、実行時には取得できないため。

回避策

いったん、JPEG画像を扱わないことにした。

所感

JPEGを扱わないわけにはいかないので、あとでまた向き合わなくてはいけない問題。

com.sunパッケージのライブラリはうまく扱えないのか? それとも、プラグイン構造のように、動的にクラスローディングを試みるような処理がいけないのか?

--initialize-at-build-time とかが上手く使えるようになったら、また戻ってくる。

java.lang.Error: Could not find class: null が発生

現象

BufferedImage.createGraphics() メソッドの呼び出し時に次のエラーが発生する。

Exception in thread "main" java.lang.Error: Could not find class: null
    at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:117)
    at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)
    at java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1181)

原因

次のコードがnullを返すため。

AccessController.doPrivileged(new GetPropertyAction("java.awt.graphicsenv", null));

doPrivileged はnativeメソッドなので詳細までは確認していないけど、動的なクラスローディングができない件と同じだと推測している。この辺はハマったまま、まだ回避策も解決策も見つけられていない。また進展があったらアップデートする。

全体的な所感とか

GraalVMで作ったネイティブイメージは、起動時間が早く、メモリの消費量も少ないので、その点は完全に期待通りです。AWS Lambdaみたいな、いわゆるサーバレスというか、ファンクション実行する環境との相性がとても良いという手応えがあります。

ただその一方で、Javaの世界で古来より用いられているテクニックである、リフレクションや、動的なクラスローディング、動的なバイトコードエンハンスメントなどが、問題を生んでしまっている面があります。この辺りはGraalVM自体の設定やバージョンアップで解決できる部分もあるでしょうけど、いくつかの問題は、ライブラリやフレームワークが実行時解決をするのではなく、コンパイル時解決できるようになっていかないと、根本解決しないのではないかと推測しています。

つまり、既存のライブラリやフレームワークなどが「GraalVM Ready」になっていくというムーブメントが起きるどうかが、GraalVMが使い物になっていくかどうかの分水嶺なのかなぁ、と思って注視しています。SpringもGraalVM対応することをロードマップに入れたりもしていますし、今後もぼちぼちウォッチしていきます。

【ネタバレあり】コンフィデンスマンJPの運勢編とロマンス編があまりにも良くできてたので長文で感想を書く。

普段あまりドラマとか見ないのだけど、ここ数年で久々にグッと来たのが、コンフィデンスマンJPだった。あまり視聴率は芳しくないし、自分のタイムラインでもあまり視聴者を見かけない作品なのだけど、自分の中ではここ数年で最高のドラマだと思っている。僕はこういう「人の心理をミスリードして、どんでん返しをする」みたいな作品が大好きだ。

こういう騙し合いの作品は、視聴者も一緒に騙されるというのがよくあるパターンで、コンフィデンスマンJPもその例外ではない。つまり作品中で騙す相手は、作中に出てくる敵役だけではなく、むしろ視聴者の方なのだ。

ドラマ本編のでは、だいたいにおいて仲間である「ボクちゃん」を騙すという流れで視聴者をミスリードをして、そこからどんでん返しを起こしている。彼が最良の行動ができるようダー子が仕掛けたトリックに、視聴者も一緒にハマってしまい、最後にボクちゃんが「味方を騙すなんてひどい! 僕はもう抜ける!」なんて怒ることが一つの様式美となっている。

こういう視聴者を騙す作品では、必ず守らなければならない当たり前の不文律があって、それは「視聴者を騙すための演技を役者がしてはならない」ということだ。これを守らなければ、「あれ、なんでこの時、こんなセリフを言った??」「いや、これはセリフの切り取りとしても作為的すぎない?」となり、途端に話が白けてしまうのだ。

コンフィデンスマンJPはその不文律をしっかりと守り抜き、心地よいどんでん返しと爽快感を視聴者に与えてくれる、非常によくできた作品なのだ。

さて、そろそろドラマスペシャルや映画のネタバレの話をしたいので、少し余白をあける。

 

👑

 

はごろもフーズ

 

この視聴者をミスリードする様式は、ドラマ本編の最終回や、スペシャル版(運勢編)、映画版(ロマンス編)でもしっかり受け継がれている。

ドラマ本編の最終回では、最初から最後までターゲット(鉢巻秀男/佐藤隆太)と一緒におり、ターゲットを騙すためのトリックに視聴者も一緒にハマるという展開だ。話の中でトリックを仕掛けるのではなく、トリックは既に「物語が始まる前に仕掛けられていた」という場外技で、どんでん返しが始まるのだ。

そして、5月に公開された映画版のロマンス編と、その翌日に放送されたテレビのスペシャル版の運勢編。

スペシャル版の運勢編は、非常によくできていたし、ある意味では反則スレスレの技を使ったとも言える。主人公の3人がいずれもやることなすことうまく行かないという展開から、最後の最後で話が一気に繋がってどんでん返しになるのだけど、この運勢編の中核は「神様を騙す」という目的に尽きる。

物語の序盤で、ダー子から渡された手紙を、ボクちゃんとリチャードが無視するというくだりがあるのだが、コンフィデンスマンを初めて見る視聴者ならまだしも、コンフィデンスマンの世界に頻繁に訪れていた視聴者であれば、ここで「手紙を読んだということは、無視しているように見せかけて、実際は仕掛けに入ったんじゃないか?」と疑いを持ってもおかしくない。

しかしその後の展開は、どうにも仕掛けに入ったように見えない。敵(阿久津晃/北村一輝)を騙すための作戦と、ボクちゃんやリチャードの取っている行動がまるで紐付かないし、もし遺品整理会社の社長(渡辺若葉/中山美穂)や、ラーメン屋のおかみ(韮山波子/広末涼子)を騙すのが目的であれば、何もこんな回りくどい手段を取る必要もない。ボクちゃんがボコボコにされる必要もない。

であればこれは本当にダー子の指示とは無関係な、ただの不幸話なのか? コンフィデンスマン慣れしている人でも、そんな疑いを持つことになる。そして、種は最後に明かされる。

神様を騙し、自分たちが不運であると見せるために、ダー子がトリックを仕掛けたのだ。

「神様を騙す」という表現は、あくまでも作中では「占いの結果が悪かったから、神様を騙す必要があった」という説明になっているが、ある意味では、神の視点でこのドラマを見ている視聴者を騙すため、というメタ発言とも受け取れる。

神というこれ以上ない相手を騙したとも言えるし、「視聴者を騙すための演技を役者がしてはならない」という不文律に抵触しそうな反則技ギリギリとも言える。ただどうあれ、どんでん返しにあっけに取られ、ものすごい爽快感に包まれたのは確かだ。神を騙すなんて、メチャクチャなことをしてきたな、と思って笑ってしまった。

ただ同時に、一つの不安がよぎった。映画はどうやってこれを超えるのか? 神以上に騙す相手はいないぞ? ということだ。

さて、ここからは、映画版のネタバレになるので、また余白をあける。

 

 

いや、別に2回目はやんないから。

 

映画版のロマンス編は、最大の鍵は「モナコ」の存在に尽きる。ドラマ本編のボクちゃん、ドラマ最終回の鉢巻秀男、スペシャル版の神に相当するのが、モナコである。

今回のターゲット(ランリウ/竹内結子)が、実は仲間であることは、僕は中盤くらいで確信した。そもそも顔が不明だという時点で怪しく思い始めるのだが、なかなか仲間であるという確信が持てない。もしかしたら本当にターゲットなのかも知れないと思うような描写がたくさんある。

ただ、ダー子とランリウ(竹内結子)が2人だけで話すシーンは一度もなく、ランリウが一人で物思いに耽るような描写もないため、少なくとも仲間であることを否定する材料がない。それに対して、ジェシー三浦春馬)はダー子と2人で話す機会が何度となくあり、視聴者の裏をかくような言動もないため、仲間である可能性は極端に低かった。

そして、ランリウ(竹内結子)とジェシー三浦春馬)が仲を深めていく描写を見た時に、なるほど、今回のターゲットはジェシーであって、ランリウは仲間なのだとの疑いが強まっていった。

しかし、それでも説明がつかない。仲間同士の作戦会議は、あくまでもランリウをターゲットにしている。「視聴者を騙すための演技を役者がしてはならない」という不文律がある以上、もし仮にターゲットがジェシーであるなら、ジェシーを騙すような話をしなくてはならない。

なぜだ。みんな本気なのか? であれば、ランリウは仲間ではなく、ジェシーが仲間なのか? また混乱していく。中盤はそうやってずっと顔をしかめながら考え続けた。

そして気づいた。分かった、モナコがターゲットなんだ。

そうこうしているうちに、作中でジェシーがダー子に撃たれるが、コンフィデンスマンJP慣れしてる人はこれが演技であることを確信する。そしてジェシーはダー子と2人で皆を裏切ったと告白するが、やはり慣れてる人はここでもダー子が騙していると思うだろう。であれば、ランリウは仲間であることにも薄々気づく。

その後、実はモナコジェシーの仲間だと明かされる。そう、種明かしはあくまでこの順番なのだ。ジェシーは敵だった、実はモナコも敵だった、という順番であり、このモナコの存在こそが、映画版の最大の鍵なのだ。

モナコが作戦会議にいるからこそ、ダー子たちはあくまでもターゲットがランリウであるとして話を進めなくてはならないし、それに視聴者も騙される。最初にランリウの別れた夫に会いに行ったのも、ボクちゃんとモナコだからこそ、夫は偽物だったし、視聴者はそれに騙される。ダー子がランリウから恋の話を聞いた時にそばに居たのもモナコ

とにかくモナコがそばにいるからこそ、騙し続けるのだ、モナコと視聴者を。

ところで、ドラマのスペシャル版は、映画の後日譚であるため、モナコが既に仲間になっている。スペシャル版は映画公開翌日であったが、僕も含め、多くのファンは映画よりも先にスペシャル版を観ており、モナコが仲間に加わったことを知っている。だからこそ、モナコは敵ではないと思いこんでしまうのだ。

スペシャル版では、敵であったなんて微塵も感じさせない、あくまでも健気に働く仲間のモナコ。映画版でもその健気さは変わらず、しっかり働くモナコ。それが実は敵だった、という話である。

そのミスリードのためだけに、2時間ドラマに仲間としてモナコを登場させるという、とんでもないトリックを仕掛けているのだ。

逆に映画版を先に観ていたら、モナコが突然仲間になることに少し違和感があっただろう。何だったらモナコを先に疑うかも知れない。しかしモナコを疑ってばかりいると、今度はメインのターゲットであるランリウが仲間であることに気づきにくくなってしまう。これは単純に、1本の映画としてよくできている。

映画を先に観た人は、モナコがどこか怪しいと疑って、ランリウが仲間であることには気づかない。スペシャル版を先に観た人は、モナコを信じきってしまって、ランリウが仲間ではないかと疑っても確信が持てない。

要するに、敵だと思った人が仲間、仲間だと思った人が敵、という二正面作戦で視聴者を騙しに来ているのだ。

特に「2作品を、スペシャル→映画の順に観た人ほど騙される」というミスリードは、何だったら「コンフィデンスマンJPの世界によく訪れ、ランリウが味方だと気づいてしまう人を騙す」ための策だったのかも知れないと思うと、この計算し尽くされた脚本、、いや、公開日や放送日まで巻き込んだ罠には、本当に頭が上がらない。

「もう、さすがにこれ以上はない」

ドラマのスペシャル版を観た時と同じ感想を、映画版のこのミスリードに気づいた時に抱いた。

正味の話、今回の映画ですら、終わったあとに「難しかった」という感想を声に出していた人たちがいた。誰が味方で誰が敵なのか、予想できるかどうかではなく、そもそも種明かしされても着いていけない人たちもいるのが、二正面作戦の難しさだ。そんな中で、これ以上に複雑な罠を仕掛けることができるだろうか?

コンフィデンスマンJPは、これでおしまい。これ以上、複雑な話にはできないし、かと言って、同じレベルではコンフィデンスマンの世界の住人はもう騙されない。

そんな思い込みを覆してくれる続編を、僕は期待している。

2社で正社員を始めます。

転職する人って4月1日から新しい勤務先で稼働することが少なくないと思うんですけど、その日がエイプリルフールっていうのも、何だか嘘か本当か分からなくて面白いですよね。
ということで僕もそんな、真偽のハッキリしない話を書きたいと思います。

本日より、株式会社Everforthにて正社員として働き始めます。
そして、Acroquest Technology株式会社の正社員としても継続します。

2つの会社で正社員をやります。

f:id:cero-t:20190401222252j:plain
2社の名刺です

ちょっと何を言ってるのか分からないかも知れませんが、両方の会社でふつうに正社員として働くということです。

別に日本には「2つの会社に正社員として働いてはいけない」という法律はなく、むしろ「法律上は正社員などの身分はない」という感じなのです。なので、2つの会社で正社員として働くことは可能です。
今回、Everforth社を知る機会があって、とても面白そうだなと思った一方で、まだAcroquestの仕事も続けたいと思い、「だったら両方で働けば良いんじゃないかな?」と閃いて、諸々の調整の結果、両方で働くこととなりました。

他の会社も何社かお話を聞きました

Everforth社は、LinkedInで見知らぬエージェントから来る「ご紹介したい案件がございます」的なオポメッセージがきっかけで知りました。あんなメッセージに誰が答えるんだよってずーっと思い続けてたんですが、普通にいましたね、ここに。

とは言えそれだけでEverforth社に決めたわけではなく、せっかくなので何社かを比較しようと思って、JJUGのスポンサー企業を中心にお話を聞いたりしました。自分が趣味でやっているコミュニティ活動にお金を出して支援してくれる企業には、やっぱり恩も義もあるわけで、そこから打診するのは当たり前なわけですね。僕はそういう性格なんです。

それで外資系をいくつか打診しました。きっと多様性ある働き方は外資系の方が柔軟で、「2社で半々で働きたいだと? HAHAHA、いいぜ、いつから働くんだい?」、、、みたいなテンションになるだろうと予想していたのですが、残念ながら門前払いに近い印象を受けました。
中には「ボスは面白そうだと言ってる」とか「日本では例がないけど海外では例があるし、聞いてみる」と言ってくれた会社もあったのですが、結果的には、空いてるポストがパートタイムではNGだったりして、見送りとなりました。結局、1社たりとも面談までたどり着きませんでした。
念のために言うと、Java Championの肩書を失ってもアレなので、JJUGが一番お世話になってる会社には打診してないです。

一方、日本の企業の方は、柔軟な働き方に対して前向きな印象でした。結果的には辞退となったのですが、何社かの日本の企業では「今後、せろさんのように少ない日数で働きたい人が出てくるだろうから、それに先駆けてルールを検討したい」と言って、働き方の検討や調整をしてくださいました。とてもありがたいですね。意外と「働き方改革」っていう政策が効いている?のかも?
ただ、ザ・純国産大企業みたいなところには一社も行ってないので、そういう所では門前払いだったかも知れませんけどね。

働き方の既成概念に捉われない

そんな背景はさておき、2社で働く話です。

要するに2社でパートタイムの正社員になるわけですから、それが簡単かと言うと、そうではないと思います。大前提として、所属する両方の会社がそういう働き方を認めてくれることが必要になります。その点は、Everforth社もAcroquest社も柔軟すぎる会社なので、クリアできました。あとは保険や年金、税金、労働時間をどうするかという話などもあってちょいちょい面倒くさいです。

面倒くさいとなると、そこまでして正社員になる必要はあるのか? フリーランスで業務委託なり何なりすれば良いんじゃないのか? って思われるかも知れません。 ただ、フリーランスとか事務手続きがクソ面倒くさそうじゃないですか 僕の労働観が「労働を提供して対価をもらう」ではなくて、「社のポリシーに共感して、その実現のために労働を提供する」という感じなので、社員という形にこだわったんですね。自分でも意識高すぎ高杉君かな? と思いますけども。仕方ないです。

ともあれ、2つの会社で正社員として働くという発想がアリなんだ、ということを皆さんに知ってもらいたいなと思ってこのエントリーを書きました。

「いまの会社も好きだけど、声を掛けてくれた会社でも働きたい」とか、「転職したいけど、すぐには辞められないから、両方で働きたい」とか、「自分のスキルの幅を広げるため、複数社に所属したい」とか、2社で働きたいと思うきっかけは様々だと思います。
そういう時に、無理だと諦めてしまうのではなく、2社できちんと働くという選択肢だってある、働き方なんて自由だ、と考えることができると思うんですよね。そういう発想の人が増え、それに対応する会社が増え、そして皆の働き方の柔軟さがより増していけば、このエントリーを書いた意義もあったのかなと思います。

おしまい

これ以上の話を書くと長くなるので、ここで終わりますね。

今日はエイプリルフールですが、残念ながらこのエントリーに嘘はありません。嘘みたいな本当の話をお送りしました。
エイプリルフール企画は、ツイッターのほうでやっていますので、そちらにお越しください。

あ、

こういうエントリーには、欲しいものリストが必要なんでしたっけ?

https://www.amazon.jp/hz/wishlist/ls/328E4YL1SIRH0

なんてね。それでは!

XPS 15 2-in-1 レビュー最終回 2-in-1ノートのある生活 #デルアンバサダー

本日、XPS 15 2-in-1のモニターが終了しました。最後のまとめとして、1ヵ月ほど使ってきた感想を書きたいと思います。

発想を広げる時には、手書きがいいぞ

ちょうど1年ほど前に「ThinkPad X1 Yoga」を購入し、その半年後ぐらいに友人から「Surface Book with PB」を譲ってもらい、そしてこの1ヵ月ぐらいは「XPS 15 2-in-1」と併せて使ってきました。この3台は、いずれも2-in-1タイプのPCです。短期間に3台も使っているのはたまたまですが、ただ僕が2-in-1タイプのPCが好きなことには違いありません。

その一番の理由は、手書きができることです。

仕事でアプリケーションの設計を始める時や、プレゼンの内容を考え始める時は、手書きしたくなります。これらをする時には、まず発想を広げることが大切なのですが、発想を広げている途中で「考えながらキーボードを打って文字にする」のってすごく窮屈で、発想が広がりにくくなります。
それよりもフリーハンドで書き、文字だけでなく絵を交えたり、部分的にマインドマップ的にしてみたりすれば、発想を広げたまま記録できる、という感覚があります。

もちろん紙とペンで描いても良いのですが、それだとどうしてもPCに取り込むのが面倒くさくなります。スキャナを使おうがスマホで撮影しようがどうしても面倒で、しかし取り込まなければ確実に失ってしまいます。

だから、手書きのメモができるノートPCが欲しくなりました。

自分の発想を広げるためのツールとしての手書き、そして、それをなくさずに保存しておくための2-in-1タイプのノートPC、という位置づけです。
別に手書きはタブレットでも構わないのですが、僕はふだんノートPCを持ち歩いていて、それとは別にタブレットを持ち歩くのは面倒なので、2-in-1の方が好みなのです。ふだんノートPCを持ち歩かない人は、タブレットでも構わないと思います。

どうあれ、発想を広げる時には、手書きはいいぞ、ということです。

XPS 15 2-in-1は、何でもできるビジネスシューズか

先月、広島でプレゼンをする機会がありました。

行きの電車の中で、手書きでプレゼン内容を考え、たまにNetflixを観て息抜きをし、ホテルに着いたらプレゼン資料を作成し、だいたい出来たところで対戦格闘ゲームで遊んで。
・・・という一連の流れ、すべてXPS 15 2-in-1で行っていました。

もしも持っていたノートPCが、タッチパネルもなく、dGPUも積んでいないようなものだったとしたら、ノートPCとは別に「手書き用のタブレット」と「ゲーム機」も一緒に持っていかなければなりませんでした。
XPS 15 2-in-1は(重さが2.0kg前後なので)ノートPCとしては軽い方ではありませんが、それでもタブレットやゲームを一緒に持ち歩くよりは荷物が軽くなります。

もちろん、ゲーミング性能で言えばゲーミングノートにはかないませんし、またデジタイザペンの性能もiPad Proほど高速には追従しませんし、ソニーのデジタルペーパーみたいな紙に近い書き味でもありません。ただ、1台で色々できるという点は間違いなく大きなメリットだと思います。

そういう点で、XPS 15 2-in-1を靴にたとえると、「サッカーボールを蹴ることも、ボルダリングもできる、ビジネスシューズ」みたいなノートPCだな、という気がします。
ふつうの革靴では、ボールを蹴ってしまえば痛みますし、もちろん壁なんて登れません。XPS 15 2-in-1はそれができるPCなのです。ただし、サッカーのスパイクやボルダリングシューズほど、それぞれに特化した性能でもありません。

あれもしたい、これもしたい、でも荷物は増やしたくない、というニーズに合ったPCだなと思います。

今後のXPSに望むこと

XPS 15 2-in-1の体験そのものは良かったのですが、いくつか細かいところで不満がありました。

1つ目は、Radeon独自の機能であるRadeon ReLiveなどが使えなかったこと。Core i7-8705Gに搭載したRadeonの扱いがどことなく中途半端ですし、後継CPUのアナウンスもありませんし、なんだかこのCPUは失敗作だったのかなと推測したくなります。もし新モデルが出るのであれば、普通にGeForceにしてくれればと思います。

もう1つ目は、インタフェースがUSB Type-Cしかないこと。積極的にレガシーインタフェースを排除するMacBookならまだしも、WindowsノートでUSB Type-Cのみにするのは、チャレンジング過ぎると思うのですよね。今はまだType-Aは標準搭載、できればHDMIも欲しいなと思いました。

そういう意味では、XPS 15 2-in-1は、Dellとして敢えて攻めた製品という位置づけだということでしょうか。
このチャレンジのフィードバックを踏まえて、今後も良い新モデルを作って欲しいなと思います。1ヵ月間の体験モニターをさせていただき、ありがとうございました!

XPS 15 2-in-1 レビューその3 対戦格闘ゲームの性能 #デルアンバサダー

XPS 15 2-in-1のレビュー、第3回目はゲーミング性能のお話です。

XPS 15 2-in-1(以降、XPS)はCPUが「Core i7-8705G」というもので、AMDGPURadeon」と一体になったCPUです。一昨年末にこのニュースを見たとき、ワクワクした人もいるんじゃないでしょうか。

pc.watch.impress.co.jp

今回は、このCPUで実際どれぐらい快適にゲームができるかをレビューします。

きちんと動かなかったので、ドライバーを入れ直し

早速、手元にあったSteam版のStreet Fighter V: Arcade Edition(以降、ストV)を起動してみた、、、のですが、なんか全体的にスローモーションで、ゲームになりませんでした。これはGPU搭載PCあるあるで、使われて欲しいRadeonが全く使われず、Intelの標準GPUのみが使われてしまったためです。

原因や対策はこのレビューの本題ではないので簡単に触れるだけにしておきますが、IntelのサイトからRadeon用の最新ドライバーをダウンロードしてインストール(その過程で、元のドライバーはアンインストール)すると、デスクトップの右クリックでRadeonの設定ツールが開けるようになります。

f:id:cero-t:20190309004313p:plain
AMD独自の設定ツール「Radeon Settings」

この設定ツールで、ストVは必ずRadeonを使うよう設定すれば準備は完了です。

ストVで試してみる。

それでは、気を取り直してストVを動かしてみます。
以前、XPS 15とThinkPad X1 YogaでもストVを使って性能を比較したので、今回も同じ条件にします。

cero-t.hatenadiary.jp

標準画質では問題なく安定動作したので、最高画質を試してみます。解像度は1920 * 1080、画質は最高です。左上にごく小さく表示されているフレームレートに注目してください。

www.youtube.com

キャラクターセレクト画面で50fps程度、対戦開始後は60fpsになりますが、真空波動拳を撃った際に56fps程度まで落ちました。何度か試している時には、53fpsぐらいまで落ちたこともありました。
前回の調査時では、XPS 15(Core i7-7700HQ / GTX 1050)でキャラクターセレクト画面で53fps前後、真空波動拳を撃った際に57fps程度でしたので、XPS 15 2-in-1はそれをやや下回る性能だということが分かります。
またSurface Book with Performance Base(Core i7-6600U / GTX 965M)で最高画質を試すと、平常時から52fpsぐらい、真空波動拳を撃つと46fpsぐらいまで落ちるので、それよりは間違いなく良い性能だが言えます。

ストVについては、最高画質からほんの少しだけ画質を落とせば十分に遊べるスペックだと言えますね。

FIGHTING EX LAYERでも試してみる

ここ最近ずっと話題にし続けているFIGHTING EX LAYER(以降、FEXL)についても試してみます。これもいきなり最高画質で試します。

解像度は1920 * 1080、画質は最高です。

www.youtube.com

ブロックノイズが出まくってて見づらいですが、対戦中は58~60fpsぐらい、スーパーコンボフィニッシュの辺りで48fpsぐらいまで低下しています。この画質では、少し厳しいようです。
そのため少し画質を落として試してみます。解像度は1920 * 1080、画質は高です。

www.youtube.com

この設定であれば、60fpsで安定するようになりました。また、画質を中まで落とすと、メニュー画面やキャラクターセレクト画面でも60fpsで安定します。

ちなみにこのゲームは4K対応をしていて、解像度を3840 * 2160まで上げられます。XPSも4K液晶ですから、せっかくなので試してみたところ、20fps前後までしか出ませんでした。さすがに4Kで遊ぶには、もう少し上位のゲーミングPCが必要になりますね。

液晶の遅延は?

続いて、ディスプレイ遅延についても調べてみました。前回の調査と同じく、HORIのモニターをHDMI接続してセカンダリディスプレイ(複製表示)として利用し、LCD Delay Checker - Tari Lari Run を動作させている画面をスロー撮影します。

左がXPS 15 2-in-1、右がHORI Portable Gaming Monitorです

www.youtube.com

動画を一時停止して . (ドット) でコマ送り , (カンマ) でコマ戻しができます。今回は撮影にGoogleのPixel 3 XLを使って480fpsで撮影したので、8コマで1フレームになります。
比べてみると、XPS側の方が表示が遅れており、2コマ~4コマ分、つまり0.25~0.5Fほどの描画の遅延があることが見て取れます。ちなみに体感では、G-Sync搭載のゲーミングPCに比べて1~2Fほどの遅延があるように感じたので、液晶だけでなくHDMI出力にも少し遅延が乗っている可能性があります(※あくまでも個人の感覚です)

ところで、動画の中で、時々30fpsに低下してしまう所があります。

www.youtube.com

この現象は、デュアルディスプレイでゲームを続けている時にも発生しました。長時間のプレイをしてCPU/GPU温度が高くなると発生しやすいようでしたが、どうあれシングルディスプレイの時には発生しませんでした。原因ははっきりしていません。

また、残像も少し気になるかも知れません。右側のHORIのモニターでは残像がほとんどなく白いカーソルが動いていますが、左側のXPSのディスプレイでは残像がしっかり残っていて、白いカーソルが2~3枠にまたがっていることがあります。この残像はゲームをプレイしていても感じます。
と言ってもこれは決してXPSが悪いわけではなく、ゲーミングモニターと比べるから差が分かるのです。過去に、Surface BookThinkPadでも同じ検証をしていますが、同じように残像が見えています。

Surface Book with Performance Base

www.youtube.com

ThinkPad X1 Yoga

www.youtube.com

先ほど、体感でゲーミングPCに比べて1~2Fの遅延があるように感じたと書きましたが、もしかすると残像のせいでそう感じたのかも知れません。いずれにせよ、遅延や残像を少しでも減らすためには、外付けのゲーミングモニターを使うと良いでしょうね。

ゲームのストリーミング配信は・・・諦めた!

せっかくゲームも上手く動いたので、そのままtwitchかmixerでストリーミング配信を行おうと思いました。・・・が、結果的には断念しました。

Radeonには、Radeon ReLiveという動画の録画やストリーミング配信を行うためのツールがあるのですが、Radeonの設定画面にこのツールが出てくるはずが、出てこないのです。

f:id:cero-t:20190309004313p:plain
「ゲーム」と「システム」のみで、動画関係のメニューがない

この件について調べている時、同系統のCPUを使ったPCでRadeon ReLiveを動作させている記事を見つけました。

Intelロゴ入りのRadeon RX Vega M設定。ReLiveの利用は要BIOS設定変更 【Hothotレビュー】Kaby Lake-GはCore i5でも侮れない性能。Chuwiの小型PC「HiGame」 - PC Watch

これを読む限り、少なくともCore i7-8705Gのハードウェア制限で使えないということはなさそうです。この辺りは今後、XPS側のアップデートで対応されると嬉しいのですが。

Radeon ReLiveが使えなかったため、代わりにWindows 10標準のゲームバー機能で配信をしてみたのですが、どうにも負荷が高かったようで、配信を見ている人からは動画がカクカクだったり音がこもっているとのコメントがありました。ということで、ゲームのストリーミング配信を行うのは諦めました。

まとめ

XPS 15 2-in-1が搭載しているCore i7-8705Gのゲーミング性能は、最近の対戦格闘ゲームをプレイするには十分なものでした。GTX 1050を搭載したXPS 15をわずかに少し下回る程度で、Surface Book with Performance Baseよりもかなり良いという結果でした。おおむねSurface Book 2と同等クラスの性能と言って良いと思います。
一方で、Radeon ReLiveが使えない辺りや、デュアルディスプレイで長時間使っていると30fpsに低下してしまう辺りは、ちょっぴり残念なところですね。
普通に遊ぶ分には何ら差し支えがないけど、全力のゲーミングノートに比べれば細かいところで少し問題が出る、というのが今回のレビューのまとめかな、と思います。

さて、あと数時間で返送しなくてはならないXPSですが、次のエントリーで全体のまとめと感想をお伝えしたいと思います。

XPS 15 2-in-1 レビューその2 ペンを使った手書き #デルアンバサダー

DELLアンバサダーの企画で、XPS 15 2-in-1(以下XPS)の体験モニターに当選したため、手持ちのSurface Book with Performance Base(以下Surface Book)といろいろ比べています。

さて、XPSSurface Bookは、いずれもノートPCとしてもタブレットとしても使えるタイプのいわゆる2-in-1 PCで、どちらもデジタイザペンが付属していて、手書きメモが簡単にできるようになっています。今回はこの手書きについて比較してみたいと思います。

手書き向きのモード

XPSSurface Bookのいずれも、ただのノートPCとしてのスタイルだけでなく、「スタンドモード」「テントモード」「タブレットモード」の3つの使い方ができます。

f:id:cero-t:20190307010617j:plain
通常のノートブックモード

f:id:cero-t:20190307010714j:plain
外付けキーボードや手書きと相性の良いスタンドモード
前回のエントリーでは「スタンドモード」で外付けキーボードを使う様子を紹介しましたが、このスタンドモードは手書きメモをするときにも使いやすいです。通常のノートブックモードでは、手前にあるキーボードが邪魔でうまく手書きができませんが、スタンドモードであれば手前に邪魔なものはなくなるためです。

タブレットモードも手書きに向いているのですが、傾斜が足りなくて困りやすいので、手書きをする時には低い台(本とか)で傾斜をつけると良いですね。

f:id:cero-t:20190307010849j:plain
手書きしやすいタブレットモード

一方、テントモードはスタンドモードよりも安定しやすいものの、ディスプレイが上下逆さになることに違和感があるため、あまり使いません。

f:id:cero-t:20190307010804j:plain
安定度は高いけど違和感のあるテントモード

ところで、Surface Bookをスタンドモードを使っている時にディスプレイの傾斜を変えようと思って触れると、(個体の問題かも知れませんが)タブレット部分とキーボード部分の接続が一時的に切断されてしまい、キーボード側に繋いでいるUSB機器が数秒間ぐらい使えなくなることがあります。ディスプレイを取り外しできるタイプのPCの宿命という気がしています。XPSではそういう問題は発生しませんでした。

書き味

ペンの書き味は、XPSに軍配があがります。まず優れているのは、ペンを動かした場合の追従の早さ。少し分かりづらいですがスローモーション動画で撮ってみました。

www.youtube.com

www.youtube.com

XPS(上の動画)の方が、Surface(下の動画)に比べて追従が早くなっているのが分かるでしょうか。ペンのようなアナログで慣れているデバイスでは、追従が遅いことが違和感に繋がるため、XPSのような追従の早さは重要です。

また、ディスプレイとペンの摩擦についても、XPSの方が滑りやすく、Surfaceの方が引っかかりやすいため、XPSの方が快適です。もちろん少しの引っかかりはあった方が良いのですが、Surfaceの引っかかりはゴムによる抵抗なので紙とペンで書く時のような摩擦による引っかかりとは違っています。そのため、むしろ滑りやすいXPSのほうが快適という評価です。

ペンの使い勝手

次はペンそのものの使い勝手なのですが、これは僕の場合、Surfaceの方が良かったです。

XPSのペンは、指で持つ辺りにボタンがついています。

f:id:cero-t:20190307005657j:plain
XPS 15 2-in-1に付属のペン
ボタンは1つに見えますが、実際は上下2つに分かれていて、下側を押しながらペンを走らせると消しゴムとなり、上側を押しながらペンを動かすと領域選択になります。

このボタンなのですが、軽く触れるだけでも反応してしまうため、僕のようにペンの持ち方がおかしい人が使うと、ボタンに誤って触ってしまって誤動作させてしまいやすいのです。どうも「ペンの持ち方が正しいことが前提」にデザインされているようです。ほんの少しペンをずらせば使えるようになりますし、実際にそうやって使っていましたが、やっぱり指元にボタンがあるタイプのペンは少し苦手です。これは、ThinkPad X1 Yogaのペンも同じでした。

一方、Surfaceのペンも、指で持つ辺りに領域選択ボタンがついているのですが、それなりにしっかりと押し込まなければ反応しないため、誤作動することはありませんでした。

f:id:cero-t:20190307005710j:plain
Surface Bookに付属のペン
また消しゴム機能はペンのお尻の部分についており、昔ながらの消しゴムつき鉛筆と同じデザインなので違和感はありません。
f:id:cero-t:20190307005727j:plain
ペンのお尻に消しゴム機能がついている
ということでペンそのものについてはSurface Bookの方が好みでした。

ちなみに、XPSのペンはSurfaceでも使えますが、SurfaceのペンをXPSで使うことはできませんでした。どういう仕組みなんでしょうね?

まとめ

ペンの書き味は、総じてXPS 15 2-in-1の方が良かったです。ただペンの持ち方がおかしい人にとっては、Surface Bookのような誤作動しないタイプのペンの方が良かったです。デジタイザペンは各社1種類しか用意されていないことが多いですが、太さやボタンの数、デザインなどで、いくつか選べるようになれば良いのにな、と思いました。

デルさん、よろしくお願いしまーす!