ナカザンドットネット

Android Developer's memo

モバイルアプリ開発フレームワークのレイアウトの計算、描画方式の違い

レイアウト計算のエンジンの派閥みたいなのがたまに気になるので、いま認識している範囲で雑に書いておきます。

「俺の愛する○○が入ってないじゃないか」は、僕が知らないかたまたま思いつかなかっただけで、特に意図的に排除したものはありません。

公式のレイアウト計算+公式の描画

Androidでいえば、Androidを支える技術<I>で解説されているような、プラットフォームネイティブなレイアウト計算(measure)と描画(draw)が行われている方式です。

  • Android SDK
  • iOS SDK
  • Xamarin Native

公式のSDKがここに入っているのは当然のこととして、Xamarin Native*1も、普通にLayout XMLやStoryboardでUIを組んだりするので、こちらに入ります。

独自のレイアウト計算+公式の描画

レイアウト計算は独自の方式で実施しつつ、描画はネイティブ側におまかせする方式です。

  • Yoga (React Native / Litho / ComponentKit)
  • Xamarin.Forms

このジャンルだと、広く使われていそうなのはFacebookのYogaでしょうか。Flexboxを中心とした、Webの方法論でUIを構築するためのレイアウトエンジンです。

今回調べてみて初めて知ったのですが、Xamarin.Formsも独自のレイアウトエンジンで動いてるっぽいですね。↓の記事を流し読んだだけなので、もしかしたら違うのかもしれませんが。

xamarinhelp.com

独自のレイアウト計算+独自の描画

レイアウト計算も描画も自前で頑張ってる方式です。

  • Flutter Engine
  • Unity
  • Jetpack Compose?

公式と言えば公式のJetpack Composeを独自と呼ぶのもアレですが、Canvasにゴリゴリ書いてるみたいです。レイアウト計算について明言しているところは見つかりませんでしたが、ひとまずここに置いてみました。

FlutterやUnityは、独自方式をとっているおかげで、プラットフォーム間やバージョン間での表示差異が出づらいのがいいところです。

まとめ

クロスプラットフォーム方面は、言語やUIキットの違いが取り沙汰されることが多い感じですが、こうして中を見るとレイアウト計算や描画の方式にも違った特徴があります。

言語やパラダイムが似ているように見えても、プラットフォーム差異やバージョン差異の起こりやすさ、ネイティブUIの取り込みやすさなどで違いがあるので、意識しておくとよさそうです。

追記

エンジンがモバイル向けとして作られているわけではないのであえて書きませんでしたが、CordovaのレンダリングエンジンをWebViewであるとした場合は、「独自のレイアウト計算+独自の描画」枠です。

*1:Xamarin.Formsを使わない開発方式をこう呼ぶと聞いたことがあるので、この名称を使わせてください

React Native for Windowsを斜め読みした感想

jp.techcrunch.com

はい、なんか出てきました。「react-native-windowsなら前からあったじゃん」と思ったのですが、どうやら大幅にリライトしたみたいなので、本家とどのくらい違うのか、簡単に流し読みしてみました。雑に読んだだけなので、たぶん勘違いを多分に含んでます。眉に唾をつけて読んでください。ちゃんと知りたい人はコード読んでください。

三行で

  • VC++使った結果、言語をブリッジするレイヤーがひとつ減ったのは面白い
  • フォルダ構成は大きく変わったけど、たぶん妥当
  • 開発者が使うときのAPIだけ本家と共通なら、内部実装の方針は多少本家と違ってても大丈夫なはず(ほんとか?)

前提

React Native製のアプリは、ざっくり分けると、次の3つのレイヤーで構成されます。

  • 開発者が作成したJavaScript製Reactアプリケーション
  • JavaScriptライブラリとしてのReact Native('react-native'モジュール)
  • 「JavaScript実行環境+ネイティブブリッジ」によるミドルウェアとしてのReact Native

「ミドルウェアとしてのReact Native」がWebViewのような役割を果たしつつ、DOM APIの代わりとなるReact Native Rendererにアクセスできる「JavaScriptライブラリとしてのReact Native」を私たちが利用することで、アプリを組み上げていく形です。

「ミドルウェアとしてのReact Native」には、C++ライブラリであるJavaScriptCoreが含まれており、この中でJavaScriptが動いています。さらにC++とObjective-C/Javaをつなぐコードも用意されているので、全体としては次のような構成になっています。

JavaScript
↕️ (JavaScriptCore)
C++
↕️ (Objective-C++ / Android NDK)
Objective-C / Java

このへんを軸に話をしていきます。

今までのreact-native-windows

まずは従来のreact-native-windows*1がどうなっていたのかを確認しておきましょう。現在のmasterである 4798c610 では、currentフォルダに旧実装が格納されています。

github.com

f:id:Nkzn:20190507111541p:plain
currentフォルダ

割とReact Native本家に近い構成になっています。ミドルウェアのiOS実装である React フォルダや、Android実装である ReactAndroid フォルダの代わりに、 ReactWindows フォルダが用意されている形です。中身は次のような感じ。

f:id:Nkzn:20190507111803p:plain
ReactWindowsフォルダ

ChakraBridge フォルダがあるので、JavaScriptCoreの代わりにChakraを使ってるんですかね(未確認)。ChakraBridgeの中はC++ですが、他のフォルダはだいたいC#で書いてあるようです。

f:id:Nkzn:20190507112142p:plain
ReactNative.Sharedフォルダ

ここまで来ると、だいぶC#プロジェクトっぽい見た目になってますね。

ざっくりとは次のような構成になっていると思われます。

JavaScript
↕️ (Chakra?)
C++
↕️ (Visual C++?)
Visual C#

ぶっちゃけWindows文化圏の開発環境に詳しくないので間違っていそうな気もする・・・

新しいreact-native-windows

それでは今回発表された、新しいReact Native for Windowsのほうを見てみましょう。 4798c610 のvnextフォルダに新しい実装が格納されています。

github.com

f:id:Nkzn:20190507112837p:plain:h640
vnextフォルダ

ごそっと増えました。ざっくり見た感じでは、次の点が変わっています。

  • ReactWindowsフォルダの中身をトップレベルに移した
  • ReactWindowsフォルダにまとめられていたネイティブ実装をUWP実装とWindows Desktop実装に分けた
  • C#製のネイティブ実装を(おそらくすべて)C++で再実装した

たぶん他にも色々あると思うのですが、私のWindows力が足りない……

C++版をmasterにマージした際のコメントに細かいコミットコメントがまとめられてるっぽいので、興味がある方はどうぞ。

この変更で、「ミドルウェアとしてのReact Native」は次のような構成になったのかなと想像しています。

JavaScript
↕️ (Chakra?)
Visual C++

これもWindows素人の想像なので、違うっぽかったらご指摘ください!

「ミドルウェアとしてのReact Native」の大変革については、後述の「感想 > 全面C++リライト」で感想を述べます。

「JavaScriptライブラリとしてのReact Native」はまだポーティングを進めている最中という感じでした。このへんはおいおい実装されていくと思います。ミドルウェアに合わせてJavaScript側の実装も最適化*2されていますが、コンポーネント名とPropsの型は本家に準拠してるっぽいので、普通に使っている分にはそんなに問題にはならないでしょう(たぶん)。JavaScriptCoreとChakraの差異とかのほうがよっぽどやばそう。

感想

というわけで本題です。疲れたので簡潔にいきます。

全面C++リライト

React Nativeは「ミドルウェアとしてのReact Native」が必ず持っている C++で書かれた処理そのプラットフォームで本来使われているGUI開発言語 に繋げないといけない性質上、「他言語とのブリッジ」という複雑な機構を持たざるをえませんでした。C++とJavaを繋ぐためにAndroid NDKのJNI機構が使われていますし、C++とObjecitve-Cを繋ぐためにObjective-C++が使われています。

さて、Java/KotlinやObjective-C/Swiftを使わずに画面を作ることはできるでしょうか。Android NDKでUIを書くことは可能ですが、あまり一般的ではありません。Objective-C++からUIKitを触るのは……できたっけ?(うろ覚え)もできます*3が、煩雑になりやすいため、やはり一般的ではないようです。

では、Windowsアプリケーションの開発ではどうかというと、Visual C++で画面を開発するのは、そこそこ一般的だったと記憶しています。POSレジのアプリがVC++ランタイムで動いているのを見たことがありますし。古い記憶なので今では廃れつつあるのかもしれませんが。そのへんよくしらない。

Windows向けの実装として考えた場合に、ブリッジを1段階廃して、最初からC++で書くというのは、パフォーマンスの面では良い選択であるように思えました。

C#でネイティブモジュールを作っていた人達からすると「何してくれてんのォ!?」という感じかもしれない……どうなんだろう……C++からC#を呼び出すブリッジコードみたいなのを足せば既存のモジュールも動くのかな……そこだけ心配……

フォルダ構成の変更

本家とこんなにフォルダ構成変えちゃって大丈夫なの?というのは思いますが、これはこれでありなのかなーと思えてきました。

本家は「AndroidとiOSの両方に対応する」という制約があるので、iOS向け実装とAndroid向け実装を別々に管理する必要がありましたし、各プラットフォーム向けのファイルがトップレベルに漏れ出すのは可能な限り避けられていました。しかし、react-native-windowsはWindowsのことだけ考えていればいいので、トップレベルにWindows向けの都合が漏れ出しても、そんなにまずくはありません。それどころか、UWP版とWinDesktop版の実装を分けるにあたっては、このくらいのフォルダ構成にしておいたほうが見通しが良くなるくらいかもしれないです。

本家との挙動の違いについて

本家側の修正に追従しようとしたときにしんどそうじゃない?という疑問は湧いてきますよね。

まあそもそも、本家側もiOSとAndroidで挙動が同じなのかという話がありまして、コントリビューターたちが頑張って似たような挙動になるようにしているだけで、別に挙動を同じにする仕組みがあるわけではないのです。

なので、Windows版の挙動も頑張って合わせていく感じになるんだろうなあと思います。

ひとまず「JavaScriptライブラリとしてのReact Native」を私たちが触るときのAPIさえ本家と同じ型なら、割り切って使うことはできそうです。本家のAPIについてはOpen Source Roadmapで語られたとおり、React Native 1.0を目指してStableなAPIにしていくそうなので、react-native-windowsもそこに追従してくれれば、多少内部実装が違っても使う側としては「これはこれで」になるのかなと。

まとめ

Windows素人の雑な感想でした。

たぶんこれからOfficeやSkypeなどで実用しながらブラッシュアップされていくと思うので、見守っていきたいと思います。

*1:たぶんWindows版のSkypeとかOfficeがこれを使ってる

*2:Android向けワークアラウンドを消したり

*3:https://twitter.com/omochimetaru/status/1125698058337964032

GUIアプリケーションのバージョニングどうする問題(あるいはメジャーバージョン上げられない問題)

皆さん、リリースしてますか! いいですよね、リリース。(雑な導入)

GUIアプリケーション(Webアプリやモバイルアプリ)のバージョン番号をどうやって決めるか(バージョニング)を迷ってしまったので、考えていることを一度吐き出してみることにしました。

結論

結論からいうと、GUIアプリケーションのバージョニングはSemVerにこだわる必要はないです。サービスを提供する主体として、開発するチームとして、そのバージョン表記によって誰に何を伝えたいのかがハッキリしていて、それが伝えたい人々に伝われば、何だっていいです。

SemVer

現代のWeb界隈でデファクトスタンダードなバージョン記法といえば、セマンティックバージョニング(通称SemVer)ですよね。

semver.org

バージョンを X.Y.Z (ex. 2.25.3)のような、ドットで区切られた3つの数値によって表現する方法です。それぞれの桁のバージョンアップは、次のような意味を持ちます。

  • Z (パッチバージョン)の数字を上げるのは、外部とのAPIを変えずに(後方互換を保ったままに)不具合を修正した場合です。旧バージョンの間違った振る舞いを正しくするために使います。
  • Y (マイナーバージョン)の数字を上げるのは、従来のAPIの後方互換を保ったままに外部とのAPIを追加した場合です。
  • X (メジャーバージョン)の数字を上げるのは、従来のAPIと後方互換がない(互換性が破壊された)変更がある場合です。

細かいところは前述の原典のサイトを見ていただいたほうがいいのですが、私はざっくりとこのように理解しています、ということで。

SemVerは、ライブラリの利用者がライブラリのバージョン表記を見て、自分のプロダクトに更新を取り込むべきかどうかを判断する際に、よい指針となります。ライブラリの作者と利用者にとって、素晴らしいコミュニケーションツールです。言い出しっぺのNPMでは遵守されていますし、他のパッケージ管理ツールも緩やかに似たようなルールを取り込んでいっている気がします*1

GUIアプリケーションとSemVer

さて、これをGUIアプリケーションのバージョンに適用するとどうなるでしょうか。実際にストアを見てみると、SemVer的なバージョニングを実施しているプロダクトは少なくないように思えます。私も会社で作っているAndroidアプリやiOSアプリやWebアプリに、SemVer準拠なバージョンを与えることが多いです。

SemVerなアプリが多い

SemVerはライブラリ/パッケージのために生まれました。では、GUIアプリケーションにとっても適したバージョニングなのでしょうか。前述した、それぞれの桁の意味について、GUIでの在り方を再考してみましょう。

  • Z の数字を上げるのは、ユーザーからの見た目や使いかたを変えずに、間違った挙動を正しくするためです。
  • Y の数字を上げるのは、従来の使い勝手を崩さずに、機能を追加した場合です。
  • X の数字を上げるのは、従来の使い方ができない部分が出てくるくらいにUIの更新があった場合です。

こんなところでどうでしょうか。SemVerでいうAPIを「ユーザーの使い勝手」という定性的なものに置き換えた形になります。

Z の数字を上げるのは、ユーザーからの見た目や使いかたを変えずに、間違った挙動を正しくするためです。

これは問題なさそうです。UIを変えずに内部処理の修正だけをしていた場合や、レイアウト崩れを修正した場合などに適用できそうです。

Y の数字を上げるのは、従来の使い勝手を崩さずに、機能を追加した場合です。

……ちょっと苦しくなってきました。どのくらいまでならUIを変えても「従来の使い勝手が崩れていない」と判断できるのでしょうか。機能要件は変わってないしコンポーネントの配置もほとんど変わっていないけれど、カラーリングやアイコンのリニューアルを行ったら、それは「従来の使い勝手が崩れていない」のでしょうか。

X の数字を上げるのは、従来の使い方ができない部分が出てくるくらいにUIの更新があった場合です。

これだと Yとの境目がわからない んですよね……従来のUIとの地続きと呼べる範囲ならYでよくて、そうでない場合がXなのかな……

しっかりYと差別化しようとすると、 驚き最小の原則に反するケースじゃないと上げられなさそう なんだけど、流石にそれはまずいんじゃないかな……

メジャーバージョン上げられない問題

SemVerを愚直にGUIアプリケーションに適用しようとすると、Xであるメジャーバージョンを上げるのは、めちゃくちゃ勇気のいる破壊的な変更であるような気がしてきました。

実際、「市場検証の意味合いも強かったv1」や「v1をもっとちゃんとしたやつ版のv2」を作った後、v3にするタイミングを逸しているところとか、あるんじゃないでしょうか*2

やってるところは「これはマイナーバージョンアップ(Y)でもいいと思うんだけど、大きな変更だから、記念も込めてメジャーバージョン(X)あげちゃえ! えいや!」と上げてるのでしょうか。うちはこうしてるぜ!的なのがあれば、Qiitaとかブログに思想をつらつらと書いて教えていただけるとめちゃくちゃ助かります。

SemVerではない運用

SemVerではないバージョン記法を採用しているプロダクトもあります。

TwitterはX.Y

Twitterは X.Y のバージョン記法を採用しています。Xが上がったときは実際にそこそこびっくりする程度にUIが変わった気がするので、おそらくこれはメジャーバージョンとして運用されているのでしょう。一方、Yは機能追加や不具合修正の両方でカジュアルに上げているのだと思われます。

f:id:Nkzn:20190422172140p:plain:w320
ChromeはMAJOR.MINOR.BUILD.PATCH

Chromeは数値が4つ並んでいます。Chromeとしてのバージョニングのルールは見つかりませんでしたが、Chromiumプロジェクトにそれっぽい記載がありました。

www.chromium.org

BUILDやPATCHはRC版のリリースを重ねるために用意されているようです。そして、MAJORとMINORはChromeとしてリリースされるようなちゃんとしたバージョン付けに利用されるとのこと。MAJORはやはり、後方非互換の変更を表すために利用されるようです。 ドキュメント上は。

WikipediaにあるChromeのリリース履歴の読み方が間違っていなければ、 1.0以降から今日の73.0に至るまで、マイナーバージョンが運用された実績がv4.1.249の1回しかない ように見えます。機能追加しかないように見えるアップデートでもメジャーバージョンを上げ続けてここまで来ています。まあ、ChromeはGUIアプリケーションというよりは仮想マシンに近いですし、JavaScript処理系の細かいところまで見ていけば全てのメジャーバージョンアップがちゃんと後方互換のない変更なのかもしれませんが……

そんなわけで、Chromeは事実上、メジャーバージョンとマイナーバージョンを統合している(ように見える)運用をしています。

バージョニングは誰のために

そもそもバージョニングは誰のために行うのでしょうか。私は バージョン番号から何かを読み取りたい人 のためにバージョンを運用するべきだと思っています。ライブラリやパッケージの場合は、後方互換性の程度を利用者に読み取ってほしくて、X.Y.Zという3つの数字を運用する、SemVerが重宝されることになりました。

では、GUIアプリケーションのバージョンは誰に何を伝えたいのでしょうか。

Webアプリやストアアプリに関しては、エンドユーザーには基本的に最新版を使ってもらうことを想定していて、ユーザー側で昔のバージョンを細かく使い分けることもないので、サポートの面から考えても「最新なのか、そうでなければどのくらい古いか」だけがわかればよさそうです。数値がひとつだけあれば、バージョニングは事足りてしまうかもしれません。 Chrome 73 といった表記も、それに近い部分がありますね。

一方で、それを提供する会社の社内ではどうでしょうか。広報担当と一緒にリリース内容をどう宣伝するか考えるときに「新機能や機能改善を含むリリース」なのか「不具合修正のみのリリース」なのかがバージョンを見ただけでひと目でわかるのは、とても便利そうです。 FEATURE.PATCH のようなふたつの数値で表すことにして、前者と後者のどちらが上がったのかを見ることで、社内のコミュニケーションを円滑にするのは、良い方法かも知れません。

もし、ユーザーに一定以上の負担を強いるタイプの大幅なUIリニューアルを、それなりの頻度で行う社風があるのであれば、後方非互換性を表すメジャーバージョンの運用も、視野に入れてもいいのかもしれません。メジャーバージョンを上げるようなリニューアルをするたびにユーザーに怒られているTwitterを見ていると、それがいいことなのか、少し疑問ではありますが。

まとめ

バージョニングは、プロダクトの作り手と、プロダクトを利用したり運用したりする人々との、コミュニケーションツールです。伝えたいことが必要十分に伝わるならば、必ずしもSemVerにこだわる必要はないと、筆者は考えています*3

プロダクトの特性や、開発組織の特性によって、どのようなバージョニングを採用するかは工夫してもよさそうです。皆さんの組織では、どんなバージョニングをしてみたいですか?

*1:まだmaven central repositoryなんかはやんちゃなバージョニングをしているなあと思いますが

*2:弊社です

*3:NPMにリリースするようなライブラリは、^とか~が動かなくなるかもしれないのでちゃんとSemVerにしましょうね

増刷が決まりました!(たった1日で基本が身に付く!Androidアプリ開発超入門)

昨年9月に、Androidアプリ開発の入門書を発売しました。

blog.nkzn.info

たった1日で基本が身に付く!  Androidアプリ開発超入門

たった1日で基本が身に付く! Androidアプリ開発超入門

 

発売から約7ヶ月が経ち、amazonでレビューをいただいたり、Twitterで抜け漏れを指摘していただくようになり、多くの方に読んでいただいていることを実感しています。

大学生向けのセミナーで、テキストとして導入いただいている事例もありました。

さて、そんな拙著ですが、この度、

増刷されることが決まりました!

🎉🎉🎉🎉やったぜ🎉🎉🎉🎉

技評さんとしても予想外の売れ行きだったらしく、嬉しい限りです。

 

第2刷での変更点

改版ではないので大きい変更はありませんが、主に次の点を修正しています。

  • 図の指示の誤りを修正
  • プロジェクトセットアップ手順のAS3.3対応
  • 用意したのに何故か使われなかったアイコンについて言及
  • 日本語化zipファイルのダウンロード方法について追記

特に最初の図の誤りはサポートページにも載っているやばいやつなので、最優先で修正になりました。

また、Androidプロジェクトのセットアップウィザードが、Android Studio 3.2のときに大幅に変更されまして、初心者殺しになっていたので、こちらも修正しました。手順が減ったので、ページ数が減りかねない事態だったのですが、編集さんが腕力でなんとかしてくれました。ページ数に変更はありません。

他にも、読者の方からTwitterでご質問いただいた内容を元に、修正することができました。ありがたい限りです。

今後ともよろしくお願いします

(序盤だけですが)AS3.3対応で、また最新の現場でも使いやすい入門書になったと思います。

未経験から最初の一歩を踏み出すのには、とても適した本らしいことが、amazonのレビューで分かってきました。皆さんの身近にも、Androidアプリ開発に興味のある方がいれば、オススメしていただけると幸いです。

前書きにも書きましたが、これは僕が10年前にAndroidをやり始めた頃に読みたかった本です。この本でAndroidアプリ開発への第一歩を踏み出した方と、何年後かにお会いできることを、楽しみにしています。

 

余談

読者の方から相談を受けるトップの話題が、「この本の次に何を読んだらいいですか?」です。

この本でどのレベルに到達できたかもよるのですが、ある程度しっくり来た方には、重村さんのポケットリファレンスをオススメしてもいいかなと思っています。

[改訂新版]Android SDKポケットリファレンス (POCKET REFERENCE)

[改訂新版]Android SDKポケットリファレンス (POCKET REFERENCE)

 

「こういうことをしたい場合はこうするといい」がたくさん詰まっており、目次を読むだけでも楽しいです。サンプルも豊富なので、写経してみるだけでもいいかもしれません。

私も新人の頃には初版にお世話になったので、効果は折り紙つきです。よろしければいかがでしょうか。

経験者の方、他にも「この本がいいんじゃないか」というのがあれば、教えてください。

「ネイティブアプリ開発者は絶滅危惧種なのか?」への感想文

jp.techcrunch.com

こちらの記事への雑な感想です。感想は私の主観であり、ポジショントークであり、所属する組織の意見とは無関係であることを先に述べておきます。

また「ネイティブ」という言葉に「C/C++などから作られた機械語」という本来の意味に加えて、「プラットフォームの標準言語(WindowsのC#, AndroidのJava, iOSのObj-C)や標準開発ツールである」というニュアンスを含めることをご容赦ください。

ポジション

こんな感じのポジションの人です。

  • 中小企業向けにBtoBでアプリを作ることが多い中小企業の人です
  • エンジニアとしてのキャリアの大半がAndroidアプリ
  • 最近はReact Nativeやってる
  • もっと最近はPWAやってる
  • どんなテクノロジがイケてるかよりも、目の前の事業を前に進めるにはどんなテクノロジが適切かを考えるのが好きです

MSがRNめっちゃ使ってるという話について

まずはこちら。

「マイクロソフトのiOSおよびAndroidアプリの中身をスキャンしてみた。その中で、Word、Excel、Xbox、その他もろもろ38本ものアプリが、最近のアップデートでReact Nativeを利用するようになったことを発見した」

昨年の6月に中の人がツイートした、開発中の話題が、実際にリリースされるようになったことを受けての話題ですね。

ツイートはこちら。

Twitterだと話題の発散がしんどいということでRedditに移動したのがこちら。

www.reddit.com

ここで注目しておきたいのは、

Office 365's UI, a lot of it, but definitely not all of it, are pieces that are built using React Native (Windows). API's and Services are still going to be powered by C++, C#, or whatever is the most appropriate for that team. Nothing is converting to "all/completely" JavaScript/TypeScript.

という説明です。「Office 365のUIの多くがReact Nativeやreact-native-windowsで組まれている」のは確かです。しかし、「APIやサービスは各チームにとって最適な言語であるC++やC#や他の言語で書かれており、アプリケーションのすべてをJavaScriptやTypeScriptで記述したものはない」とも言っています。

あえてPDSの用語で分けるなら、「UI」というのはいわゆるプレゼンテーション層でしょうし、「APIやサービス」というのはドメイン層*1にあたるでしょうか。ざっくり言いかえると「画面はReact NativeとJS/TSで書いてるところが多いけど、ビジネスロジックは各チームにとって適切な言語で書いてるよ」ということになりそうです。

Brownfield事例は実質的にネイティブの事例

React Nativeの運用としてはBrownfieldとGreenfieldという言葉があり、「大部分をネイティブアプリとして運用しつつUI付近でReact Nativeを活用する」ことをBrownfield、「ネイティブ側はできるだけinit時のままにしつつ、アプリケーションとしてのすべてのロジックをJS側に書く」ことをGreenfieldと呼びます。Greenfieldの場合は必要なAndroid/iOS開発の知識が少なめになるので、JavaScript出身者にはオススメです。

さて、Office 365の事例は典型的なBrownfieldです。本来ならネイティブUIで開発を行ってもやれるくらいの玄人集団が、ReactというUI状態管理パラダイムによる開発の効率化や、UI人材の効率的な運用のために実施した施策であると感じました。UIの共通化という目的も入っている可能性は否めませんが、「作り方がだいたい同じである」という時点で人材運用上の価値が高い(Learn Once, Write Anywhere)ので、プラットフォームごとにパーツを作り直していても別に不思議ではないかなと思っています。

これは「React NativeとかいうUI管理DSLライブラリを使って、ネイティブアプリのUI実装を効率化したよ」とか「UI実装をWebチームの人に手伝ってもらえるようになったよ」みたいな話であり、開発スタイルとしては依然としてネイティブアプリ開発者の力が多大に必要であるはずです。

XAMLやUIKitやStorybookやレイアウトXMLやDataBindingといった、ネイティブUIのツールキットを使う機会が減っている可能性は高いですが、GUIアプリケーションはそれらだけでできているわけではありません。むしろ複雑なアプリケーションであれば、PDSのPよりDのほうが大きくなることもあるでしょう。Officeの開発では、ネイティブアプリ開発者が、めちゃくちゃ活躍しているはずなのです。たぶん。

そういった観点から、Officeの事例を理由にしてネイティブアプリ開発者の需要を語る切り口は、少し的を外しているように筆者は思いました。

Skypeの事例ならどうなのか

記事内では触れられていませんが、SkypeチームはReact XPという自作のReact Nativeラッパーを開発しており、おそらく今でもこれを運用しています。

microsoft.github.io

これは「Write Once, Run Anywhere」寄りの思想で作られているように筆者には見えており、比較的にGreenfield寄りの運用をしているのかなと想像しています(想像です)。Skype内での活用事例の記事を見ても、JavaScriptランタイムでの話ばかりが出てきます。

React XPはReact NativeをWebやWindowsにも拡張して運用するためのラッパーなので、特殊といえば特殊なのですが、こちらの運用ではネイティブアプリ開発者が登場する場面は少ないのかもしれません(想像です)。Android専用モジュール(hoge.android.tsx)や、Web専用モジュール(hoge.web.tsx)みたいなものを作るケースはありそうなので、ゼロ人ということはありえませんが、Officeチームよりはネイティブアプリ開発者の割合を減らせそうな気がします。(中の人!違ってたらごめん!違ってたらマサカリ投げてくれ!!すぐ直す!!!)

こっちを根拠にして記事を書いてくれてたら、ちょっとだけ納得感上がったのになあ、と思ってます。

ネイティブアプリ開発者の仕事は減るのか

ここからは筆者の極めて個人的な意見です。筆者は自分のキャリアを考えていく上で、現在の業界をこういう観点で見ているよ、という文章なので、違った考え方を持っている人はいっぱいいると思いますし、それらはすべて素晴らしい観点です。是非この記事のブコメに短く書いたりせずに、ご自身のブログ等で持論を展開してください。読みたいです。

ハードウェア利用とかバックグラウンド動作の要件が強いものはネイティブアプリとして作るしかないものもありますが、オフライン時の動作くらいであれば、Service Workerなどの進化(いわゆるPWA)によって解決されつつある分野も多くなってきました。サーバーからもらったデータを画面に表示して、ユーザーの入力をサーバーに投げるだけ*2の要件にネイティブアプリを作る必要があるのかというと、筆者の中では少しずつ疑問符が付くようになってきています。

BtoBでお客さんが「アプリが欲しい」と言った場合に、実はそれは素朴なWebアプリでいい要件だったり、少し込み入ってもPWAの範囲でなんとかなるものは、意外と多いのではないでしょうか(肌感覚です)。もちろん、ネイティブアプリで作るべき要件も世の中に多くありますが、それはすべてではありません。工数や時間やお金をかけて、AndroidとiOSのネイティブアプリをそれぞれ作るコストをかけたいほどの要件を持った顧客は、実はそこまで多くないのではないでしょうか(完全に肌感覚です)。

2010年ごろ、Ajaxの流行とともに、.NET製のデスクトップアプリケーションの一部を、Webアプリケーションに置き換える案件が多くあったように思います。それと同じように、モバイルアプリの世界もブラウザ技術に置き換わっていく部分が出てくると、筆者は考えています。当時とはブラウザ技術の雰囲気も随分と違うので、形は違うことになるかもしれませんが、プラットフォームネイティブな開発一辺倒だった業界が、現実的な別の選択肢を得て、多様化していく、という点では似たようなことになるのかなと。

そういう観点では、相対的に、モバイル向けのサービス提供という分野におけるネイティブアプリの比率は、下がっていくのかもしれません。そういう意味では、ネイティブアプリ開発者の仕事が減るという話も、わからなくはないです。

いまネイティブアプリ開発者である人は、これからシェアが広がっていく(かもしれない)ブラウザ向けの開発を覚えるのもいいのかもしれませんし、よりネイティブアプリ開発者としての力を付けて仕事を取っていくのもいいのかもしれません。「モバイルアプリ開発者」という肩書きで、AndroidネイティブもiOSネイティブもブラウザも全部いけるぜ!というポジションを取っていくのもいいかもしれません。

まとめ

ここから先は君の目で確かめてくれ!という無責任な締めになってしまうのですが、僕もまだAndroidアプリエンジニアを自称している立場であり、今後こういった時代の渦中に放り込まれる立場なので、ご勘弁ください。これからどうなるのかは僕だって知りたい。

冒頭の記事については、ちょっと飛ばし過ぎだけど示唆に富んでいるので、話半分で読んでおこうね、くらいの気持ちです。

ポジショントークは以上です。

みんなの反応

是非この記事のブコメに短く書いたりせずに、ご自身のブログ等で持論を展開してください。読みたいです。

ちゃんとブログを書いてくださった方々を見かけたので、この記事の次に読む記事としてオススメしておきます。

Xamarin勢の反応

「なんでそこでXamarinじゃねーんだよ!」に対するアンサーです。

qiita.com

Cordova勢の反応

昔のイメージでCordovaをdisんないでくれ頼む、というお話。

note.mu

iOSネイティブアプリ開発者の反応

ハイブリッドアプリ的な技術とどう向き合うか、どう見なすか、というお話。(すごくよかった)

otihateten.hatenablog.com

*1:DDDのやつじゃないです

*2:この「だけ」がでかいんですが

#技術書典 #技術書典6 で資産管理本を頒布します(第1章無料公開あり)

技術書典6にサークル参加します

4/14に開催される技術書典6にサークル参加することになりました。

techbookfest.org

前回、前々回とReact Nativeの本を出してきましたが、今回は少し毛色を変えて、お金の本を出すことにしました。タイトルは「これでカンタン! ITエンジニアが実践するキャッシュレス時代の資産管理」です。

フィンテック関連ということで技術の本を謳っていますが、中身は ユーザーとしてマネーフォワードをがっつり使った人間の事例を紹介するぜ! という、プログラムが1行も出てこない読み物です。

f:id:Nkzn:20190409003532j:plain:w320
表紙

興味を持った方はサークルチェックをお願いします。

techbookfest.org

配置

け76にいます。周りに知り合いがいなさそうでビクビクしています。

f:id:Nkzn:20190409004521p:plain
け76

配布形態

あれ これ
サイズ B5
ページ数 52ページ
頒布価格 1000円(おつりオペレーションを極限まで軽くしたかった)
発行部数 150部(後日BOOTHとKindleで電子版を販売予定)
決済手段 現金、公式かんたん後払い、Kyash、Pixiv Pay、クレジットカード(Square Readerが間に合えば)

キャッシュレスと名のつく本で現金決済を中心にするわけには行かないということに、初稿を書き終えてから気が付いてしまった俺たちは。本当はCoineyでタッチ決済までサポートしたかったのですが、審査に時間がかかりそうなのでパスしました。

表紙について

今回も妻に作ってもらいました。各種キャッシュレス決済サービスが、マネーフォワードに集約されていくイメージです。鉄道網っぽくしました。

「情報の流れ」は東京メトロっぽく、「お金の流れ」はJRっぽくしてあります。伝われ。

執筆体制

今回は、社内でいつも資産管理の相談に乗ってもらっている、同僚であり友人のフロントエンドエンジニア、@_yukikayukiさんに声をかけて、紙面の8割方を書いてもらいました。なかざんは「はじめに」と「第1章 僕らは何度も失敗してきた」でエモ散らかす部分だけを担当して、あとは編集に徹しています。

自分が読みたい記事を書けそうな人に声をかけて書いてもらうムーブを、試験的に実施してみた形です。私のハンドリングがド下手だったので、@_yukikayukiさんにはめちゃくちゃ迷惑をかけた気がします(ごめんね)。

「はじめに」と「第1章」を公開します

そんなわけで、私が書いた部分は特に新しい情報もなく、単に対象読者と心を1つにするためにエモ散らかした儀式的なものでしかないので、この場を借りて事前公開します。

これで興味を持ってくれた方は、技術書典当日にお会いしましょう。150部刷っていくので、まあ売り切れることはないでしょう(フラグ)。当日来れない方は、後日このブログでアナウンスするはずのBOOTH/Kindle版電子書籍をご覧ください。


はじめに

本書は、いかに最小限の努力で、自分の家計や資産を可視化するか、という課題についての知見を共有するための本です。

2010年代の日本では、インターネットやアプリを活用した資産管理であったり、現金を必要としない決済手段(いわゆるキャッシュレス決済)が広く普及しました。これらは金融のためのテクノロジー=フィンテック(FinTech)と呼ばれ、ITエンジニアに人気の事業領域のひとつになっています。 お金は現代社会で生きるために必要なものです。それを扱うフィンテック分野のサービスは、やはり、市井の人々のために作られています。特別なスキルや地位を持った人のためのものではなく、普通の人のためのものです。

しかし、いくら使用者を限定しないとしても、インターネットサービスは、あくまでも道具です。道具とは、その道具が解決できる課題を解決するために使ったときだけ、私たちに恩恵を与えてくれます。まな板で肉を切っても、包丁を肉の下に敷いても、十分な機能が発揮できないのは想像できますね。道具の恩恵を受けるためには、道具の使い方を学ばなくてはいけません。

さて、フィンテックはITエンジニアのためのものではありませんが、ITエンジニアは「インターネットサービスがどのような使い方を想定して生み出されたのか」を察する能力には、ある程度長けています。また、裏側で使われている技術に察しがつけば、フィンテックの各種インターネットサービスを「詐欺かもしれない怪しいアプリ」ではなく、「現代の高度な技術によって実現された便利な道具」として、迷いなく導入する精神性も持っています。加えて資産管理やキャッシュレス決済への関心が高ければ、フィンテックを使いこなすための素養は高いといえるでしょう。

本書では、ITエンジニアである友人の@_yukikayukiが実践している、資産管理やキャッシュレス決済の活用手法について、 書かれたものです。彼は家計簿レベルの管理だけではなく、金融方面の資産についても、無理なく可視化して管理できるようにしています。もちろん、彼も(筆者も)会計や資産運用のプロフェッショナルではないので、そういった分野におけるベストプラクティスをご紹介することはできません。それでも、現代の多様な道具たちを、どんな目的で扱い、どう組み合わせるかという知見は、そこに打つ手が思いつかない人にとっては一定の価値があると考え、筆を取ってもらった次第です。

それでは、現代のITを駆使した資産管理について見ていきましょう。

本書が想定する読者

  • 現在家計簿をつけていないが、お金の流れが見えるようになりたい方
  • 現在家計簿をつけているが、他の人がどうやっているのか知りたい方
  • 過去に家計簿をつけていたことがあるが、日々増えていくレシートを記入・入力していくのが面倒になって諦めてしまった方

免責事項

本書に記載された内容は、情報の提供のみを目的としています。 したがって、本書を用いた家計管理、資産運用は、 必ずご自身の責任と判断によって行ってください。 これらの情報による家計管理、資産運用の結果について、 著者はいかなる責任も負いません。

第1章 僕らは何度も失敗してきた

エンジニアが改善の話をするのは、そこに課題があるからです。本書ではどんなことを課題として扱うのか、一緒に見ていきましょう。

まず、本章では、キャッシュレス導入以前の筆者が、どんな挫折をしてきたのかをお話しします。家計簿を付けるのが上手な読者の方には、やる気のないやつの泣き言にしか見えないと思います。残念ながら、この本は「やる気のないやつがやる気のないまま家計管理ができるようになる」本なので、ご容赦ください。

家計簿の管理に失敗してきた

挫折の歴史の一丁目は、家計簿の管理です。進学や就職を理由に人生初の一人暮らしを始めたとき、家計簿を付けることにチャレンジした人は多いのではないでしょうか。結果はどうでしたか?

そのまま習慣を身につけることができた皆さん、おめでとうございます。

習慣を身に付けられなかった皆さん、筆者のお仲間です。よろしくお願いします。本項では皆さんと一緒に古傷をえぐりながら、課題をみつけていきましょう。

パソコンやスマホに家計簿アプリを入れたけど

流石に21世紀にもなって、若者がキャンパスノートで電卓を叩きながら家計簿を付けるという話もないですよね。元々がズボラな筆者ですから、実行するまでもなく挫折することが目に見えていました。

家計管理の最低ラインがExcelやGoogleスプレッドシート、もう少し便利にするなら、食費や水道光熱費といった費目が入力できるアプリを導入したいところです。

筆者は2005年に大学生になったとき、最初のチャレンジを始めました。当時はWindowsパソコンに家計簿アプリを入れていたと記憶しています。

さて、実際に管理を始めてみた筆者の前に立ちふさがったのはレシートの管理です。買い物をしたら、レシートを財布にしまっておいて、あとでアプリに手ずから入力します。

……筆者のようなズボラ野郎に、そんな作業が習慣化できるわけなかったんですね。みるみるうちに財布の中はレシートで溢れかえり、レシートを処理する気力が加速度的に減っていく悪循環が始まりました。

f:id:Nkzn:20190409002018p:plain:w320
溢れ出すレシート

もうレシートを処理することは諦めているのに、データを捨てるわけにもいかず、ただただレシートを限界まで財布に溜め込んでは、あるタイミングで諦めて分厚いレシートを捨てる。そんな生活を、10年くらい続けました。

レシートを撮影できるようになったけど

社会人になってから、家計簿の管理をZaimに写した筆者は、素晴らしいソリューションに出会いました。レシートの撮影です。

写真でレシートを撮影すると、レシートに記載された項目が自動で入力される機能は、入力を面倒くさがる筆者にとって、福音であるように思えました。項目名の精度はなかなか難しいようでしたが、金額の読み取りについてはそんなに悪い精度でもなく、筆者は再びレシートとの戦いを志したのです。

……筆者のようなズボラ野郎に、そんな作業が習慣化できるわけなかったんですね(1項ぶり、2度目)。

確かに、レシートからデータを入力する作業は、手入力するよりは圧倒的に効率化されました。アプリに組み込まれたOCR技術を扱ってくださった方々には頭が上がりません。それでも、筆者は習慣化できなかったのです。

これは筋金入りのズボラであり、もうこの類のアプローチを習慣化するのは難しいな*1、と感じつつも、財布にレシートを溜め込む生活はやめられませんでした。

クレジットカードは怖い

家計簿の失敗は、決済手段にも波及します。通帳や財布の中にあるお金は、どのくらい有って、どのくらい足りないのか把握しやすくなっています。

一方で、クレジットカード決済は、単独ではどのくらい使ったのかを把握する方法が、あまり便利ではありません。Webサイトでログインすれば、クレジットカードの利用履歴を見ることは可能ですが、わざわざログインしてまで見に行きませんよね。

クレジットカード決済でもレシートはもらえるので、本当はそれを使って家計簿をつければよいのですが、それができないのは前項で述べたとおりです。

クレジットカードは持っているし、ネット通販ではとても便利に使えます。しかし、家計簿の管理が伴っていない状況での利用は、単に家計のブラックボックスを増やすだけです。

f:id:Nkzn:20190409002015p:plain:w320
クレジットカードこわい

利用状況をリアルタイムで把握しづらいまま、クレジットカードを乱用するのは恐怖でしかないので、日常的な生活費の買い物に使うのは憚られます。

そんな具合で、クレジットカードとは距離を置きがちになっていました。

悪循環は続く

唯一購買履歴がデータ化されているクレジットカードは、履歴が見づらいせいで使う気にならない。

現金のデータはレシートにしかないけれど、レシートをデータ化するモチベーションはない。

それでも諦めきれなくてレシートは溜まる。溜まり続ける。

家計簿の管理が、どんどん遠ざかっていきます。

資産管理に失敗してきた

少し視点を広げて、家計の重要なファクターのひとつである、資産管理にも目を向けてみましょう。

人生を詰みづらくする上で、貯金、投資信託、株、FXなど、資産形成に取り組むのは大事なことです。インターネットの普及によって、個人が気軽に資産形成を始めるためのハードルは、極めて下がりました。筆者も、オンラインバンキングやオンライントレードの概念が現れてから早い段階で、アカウントを作成しています。

そんな中で、筆者はいくつかの失敗をしました。

オンライントレードの口座なんて滅多に開かない

まずは、オンライントレードの話をしましょう。

2000年代(いわゆるゼロ年代)に、デイトレード*2やスイングトレード*3が流行ったことがありました。この頃にオンライントレードのサービスにアカウントを開設した方は、多いのではないでしょうか。

しばらくやってみると分かるのが、そこそこマメな人でないと、デイトレードはおろか、スイングトレードも難しいということです。筆者は、だんだん飽きてきたのもあって、株を長期保有するスタイルに切り替えることになりました。

ここで問題になるのが、オンライントレードの口座を開かなくなるということです。株(や、2019年現在であれば仮想通貨など)は、値動きがあります。

おいくら万円の資産をそのとき持っているのか、という情報は、家計簿にとって意味のあるものです。しかし、それをいちいちWebサイトやアプリで確認して、家計簿につける習慣をもつことは、やっぱりこのズボラ野郎である筆者には、何よりも難しいことなのでした。

オンラインバンキングを開くのは振込のときだけ

オンラインバンキングは、私たちから記帳の手間を奪い去ってくれました。ズボラな人間には最高のツールです。

しかしながら、オンラインバンキングと同じく、残高を確認するモチベーションが少ないという問題が起きました。

口座がひとつしかないのであれば、ある程度頑張れるかもしれません。しかし、実際には、給与受け取り用の口座とは別に、実家との現金授受を行う口座があったり、さまざまな理由でいくつかの口座に資金が分散することがあります。

わざわざ家計簿にデータを反映させるためだけに、すべてのオンラインバンキングの口座を確認する手間はかけられません。

唯一のモチベーションとして、振り込みをするときだけは積極的にログインしますが、あまり頻度の多い作業ではありません。

でも、どの口座に、どのくらい残高があるのか、どのくらい貯蓄があるのかは、本当は知っているべきなのです。

どこにどんな口座があったかなんて、とうに忘れてしまった

資産形成をする上での管理作業は、オンライントレードやオンラインバンキングのおかげで、1990年代に比べて、格段に便利になったはずです。

しかし、やはり筆者はズボラなので、どこにどんな口座があったのかを、自分で覚えておくことができないのです。

なぜ失敗したのか

さて、ここまで失敗談というか、筆者のズボラっぷりをご覧いただきました。

どう考えても筆者に資産管理は向いていないのですが、ここまでチャレンジするのは、次の理念があるからです。

  • 子供の学費や自身の老後のために、資産形成をするべきである
  • 資産をはじめ、家計の状況は管理されるべきである

これらふたつのルールは、独り立ちした大人として、譲るわけにはいかないものです。しかしながら、同時に、認めなければならないことがあります。

私たちは資産管理のために手を動かしたくない!!!!!

このことから目を背けるべきではないのです。レシートの撮影なんかしたくないのです。家計簿アプリの現金残高と、財布の中身を照らし合わせるなんて、もう嫌です。いろんな口座に散らばった資産や負債を取りまとめて、バランスシートを作るのはいいことですが、それを自分で作りたいとは言っていません。

家計は管理されるべきです。意思決定は筆者自身が行うべきです。ですがそれは、データを集めて見やすくする作業を自分でやらなければならない、ということを意味しないのです。

そこから目を背けてしまっていたから、無為に失敗を続けてしまっていたのです。

そうだ、僕らは楽がしたい

筆者が本当にやりたかったことを整理してみると、次のふたつだけだったことがわかりました。

  • 資産状況の把握
  • 資産状況に対するアクション(投資, 節約, 資産売買, 負債解消の優先順位調整など)

前者は把握したいだけなので、それに付随するすべての事務作業は余計なものだ、と言い切ってしまいましょう。後者に必要なやる気やコストについては、今も昔も大きくは変わりません。ここはやるべきこととやりたいことが一致しているので、問題ありません。やる気でカバーできます。

ただでも慣れない資産管理という分野を扱うのですから、瑣末な事務作業に時間を使わず、意思決定に時間を使うべきです。

本書は、そんなふうに考えたITエンジニアたちが実践した、資産管理の方法の本です。

特別なスキルは必要ありません。なんなら、過分なやる気も必要ありません。2019年現在に存在する便利なツールを、本来の目的のままに組み合わせるだけです。

さあ、楽をしましょう。

本書の目指すところ

今回はマネーフォワード MEという株式会社マネーフォワードが提供する家計簿・資産管理サービスを利用し、キャッシュレス生活を行いながら、自動で家計簿を作成できる環境を作るまでを扱います。


最後に

第1章で書いたとおり、私は家計簿に関して、そこそこ悔しい思いをしてきました。近年のフィンテックの高まりや、良き友人を得たことにより、その悔しさはだいぶ報われてきています。

もし、今でも悔しい思いをしている人がいれば、この本を読んで、何かの道しるべにしてもらえれば幸いです。

今回も最高の技術書典にしような! Enjoy!

余談:かんたん後払いアプリのメンテナしてます

今回もかんたん後払いのアプリを担当しました。これはマネーフォワード MEに連携されないのが残念だけど、頑張ってメンテしたから、みんな使ってくれよな!

blog.techbookfest.org

*1:のちに個人事業主を始めてみたところ、経費の月締めやレシートの管理がある程度習慣化できている自分に気が付いたので、明確に義務として与えられている作業ならやれることに気がつきました。モチベーションの置き方次第ではあるようです。

*2:1日の間に株を売り買いする手法

*3:1日よりは長いものの比較的短期で株を売買する手法

ニッチな本で宣伝を怠ると売れないという当たり前の話+α #技術書典

技術書典5が終わりました。

techbookfest.org

サークル参加の皆様、お疲れ様でした。楽しかったね。

来場者の皆様、ありがとうございました。楽しかったね。

おかげさまで、総来場者数が1万人を超える、大きなイベントとなったようです。

弊サークル「越後屋」も、新刊2冊を引っさげてお邪魔いたしました。 React Native for Webの薄い本と、Android入門本です。

echigo-ya.booth.pm

たった1日で基本が身に付く!  Androidアプリ開発超入門

たった1日で基本が身に付く! Androidアプリ開発超入門

さて、イベント自体は大成功だったと思いますが、弊サークルとしては大成功とは言い難い状況になったので、反省会を開きたいと思います。

前回よりかなり売れなかった

技術書典4では開会90分で、100部用意した紙の本が完売、という快挙でした(その後もダウンロードカードが100部ほど出たので、実質200部出ています)。

しかし、今回は100部+50部で用意した紙の本が、70部+32部ほど売れただけに留まりました。赤字ラインギリギリくらいなので、失敗というほどではないのですが、可もなく不可もなくくらいの成果です。

できたら同人活動はキャッシュフローを確保しながらやっていきたいので、改善していきたいところです。

今回の失速の要因となった点を考えていきたいと思います。

宣伝不足

といっても、要因の1つは火を見るよりも明らかだったりします。前回に比べて、全然宣伝をしていないのです。

前回は割とやれてた

技術書典4の際には、2度ほど宣伝のブログを打っていました。

日付 記事
2018-02-04 技術書典4にReact Nativeの薄い本を出します - ナカザンドットネット
2018-04-18 #技術書典 #技術書典4 で「Cheap Dive into React Native」を頒布します - ナカザンドットネット
2018-04-22 技術書典4本番

2度目のブログは本番の4日前なので、入稿直後くらいです。ちゃんと本番の数日前に宣伝をしたというのは効果があったと思われます。

4月の宣伝ブログを書く2日前の時点では、被チェック数が72程度でした。

これが、ブログを書いた翌日に、109まで伸びています。

ブログの内容が激エモだったのは実際あると思うのですが、宣伝の効果が適切に現れた部分もあるのだろうなと考えています。

当日には最終的に、249まで伸びていました。

今回は本当にダメ

さて、それでは今回はどうだったでしょうか。

  • 技術書典5に出るよという記事:書いてない
  • 本の内容の宣伝の記事:書いてない

ブログではまったく技術書典5や新刊について触れていません。

ここで死ぬほどもったいない点としまして、技術書典5の5日前の被チェック数は、技術書典4の6日前の被チェック数と同水準だったのです。

この頃の私は完売しないとも知らずに呑気なものです。

この時点で宣伝をババーンとやっておけば、もうちょっと伸びが見込めたのかもしれません……

実際にはまったく宣伝もしなかったため、緩やかに伸びていくばかりでした。

当日時点でも159となりました。

サークルチェックを付けたからといって来る人は意外と多くないので、やはり200とか300とかの数字がないと、前回ほどの集客は見込めなかったということだと思います。

地道な宣伝、普通に大事だよねというお話でした。

内容がニッチだった

これはまあ、反省点ではなくて世の摂理なのですが、ニッチなものはマスほどには人を呼び集められませんよねということで。

React Nativeというテーマ自体がそもそもニッチなのに、React Native for Webというニッチ・オブ・ニッチを攻めてしまった以上、集客につながらないのは当然でした。

技術書典4のCheap Dive into React Nativeは、ニッチながらもCRNA記事などが広く門戸を開いてくれていたので、そこまでニッチ感は強くなかったのですが、今回はもうレベル設定がめちゃくちゃです。わかるやつだけわかれ!の世界です。

前述のとおり、これについては反省していません。だって、書きたかったんです。私はReact Native for Webの話が書きたかったんです。だから良いんです。これで良いんです。

同人誌は書きたいものを書かなきゃ意味がないんです。入門書を書いた人は入門書が書きたかったから書いたんです。そうじゃないものを書いた人はそれが書きたかったから書いたんです。「好きなものを書く」。こればっかりは同人活動の根幹を支える概念なので、誰にも文句は言わせません。

これに関しては反省する気がないので、次回はしれっと『Anatomy of React Native DOM』みたいな、今回以上のどニッチを攻めていく可能性があります。ご期待下さい。

反省会おわりです。

技術書典5でやったこと

それでは最後に明るい話題として、技術書典5に対して私が貢献したことについて並べておきたいと思います。

  • 朝から会場設営のスタッフやってました
  • 開会ギリギリまで技術季報をトートバッグに詰める作業をやってました
  • 閉会後は会場撤収のスタッフやってました
  • 公式後払いアプリのAndroid版も担当しました

サークル参加しながらスタッフするの、当日の充実感が半端ないです。体力的に翌日に死ぬので、オススメはしません。

あとね、後払いアプリのAndroid版ね。

blog.techbookfest.org

ふと気づいたらAndroid版もReact Native(というかExpo)で私がやることになってました。2ヶ所ほど軽微な改修を入れるだけでAndroid対応ができたので、そこのところはやっぱりExpoよくできてんな、という気持ちでした。

もともとTypeScriptで作ってあったので、何回かあった仕様変更にも比較的容易に応えられたのはとてもよかったと思います。

まとめ

技術書典6はもっとちゃんと宣伝しようと思いました。

今更ながら宣伝ですが、今回の新刊をBOOTHで出してあるので、技術書典に来れなかった皆さん購入を頼みます〜!!🙏

echigo-ya.booth.pm