ナカザンドットネット

Android Developer's memo

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

「たった1日で基本が身に付く! Androidアプリ開発超入門」という本が出版されます

来る9月21日(金)に「たった1日で基本が身に付く! Androidアプリ開発超入門」という本が技術評論社さんから出ることになりました。電子書籍版もあります。

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

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

人生初の商業向け単著です! しんどかった。世の中の単著erの皆さんすごい。

いろいろ思い出があるので、出版にあたってのあれこれを書いてみようと思います。

どんな本なの?

プログラミング未経験者やAndroid未経験者の方が、本の内容で手を動かしながら(いわゆる「写経」をしながら)Java言語やAndroid Studioの使い方を学んでいく本です。

初学者向けの本にするにあたって、次の3点を工夫しています。

  • Android Studioを日本語化して、できるだけ解説に英語が出てこないようにする
  • Java言語についての解説は最低限にする
  • レイアウトはGUIエディターのみで行う

余計な前提知識を求めると、躓いてしまう方もいそうだったので、できるだけ前提知識を求めずに、学びたいことをストレートに学べるようにした形になります。

Android Studioの日本語化

Android Studioを日本語化したおかげで、解説の中で出てくる文言の多くを日本語にすることができました。

見慣れないアルファベットの単語が入り混じった文章はコンテキストスイッチが多くなりそうなので、良い取り組みだったと思います。だからといってカタカナが大量に出てくるようになったのが良かったのかというと怪しいですし、ScrollViewのようなクラス名はそのまま表記しているので、どのくらい読みやすさに寄与したのかは、読者の感想を待ちたいところです。

Javaを説明しすぎない

本書はプログラミング未経験者を対象にしているため、Java言語についての解説も行いました。写経していく中で登場する、変数やメソッドといった最低限の要素だけを解説しています。

思い切った点として、クラスについての解説をほとんどしていません。クラスの書き方を解説し始めると際限なく話題が膨らんでいくためです。

自作のクラスを活用せずにAndroidアプリを作っていくと、自然とFat Activityになります。それ自体は後々に問題を引き起こす可能性はあります。ただ、それが問題になるくらいにコードをたくさん書けるようになった人なら、本書ではなくもっと別の本がフィットするようになっているはずです。

この「たった1日で」シリーズの良さは薄さや手軽さです。「Android Javaの正しさ」を語り過ぎないようにしたつもりなので、読者がサクサク読み進められたらいいなと思います。

レイアウトエディターはデザインモードのみ

レイアウト作成の解説は、レイアウトエディターのデザインモードのみで行いました。レイアウトの解説にXMLは登場しません。ここは筆者のこだわりです。

XMLを書きながらプレビューを見るスタイルも筆者は好きですが、初学者時代を思い出して見ると、JavaとXMLを行ったり来たりするのは地味に心が折れそうになるポイントだった記憶があります。

現代のAndroid Studioには、ConstraintLayoutを用いた、そこそこ実用的といえるWYSIWYGなレイアウトエディターがあります。これならば心理的な障壁が幾分か低くなるのではないかと考え、全編で採用しました。ドラッグ&ドロップで制約を付けていく作業については、限られた紙面の中で、できるだけ丁寧に解説したつもりです。アプリ開発の醍醐味のひとつ、レイアウト作成を楽しく体験してもらえればと思います。

余談として……本書はAndroid Studio 3.1.4向けに書いたので、Android Studio 3.2で導入されたナビゲーションエディターを用いた画面遷移の定義は盛り込めませんでした(そもそも画面遷移を取り扱う紙面の余裕もなかったのですが:-p)。2019年に似たような本が出てくるときには、是非ナビゲーションエディターの解説も含まれていてほしいなあと思います。

執筆の経緯

技術評論社さんで刊行しているたった1日で基本が身に付く!シリーズのAndroid Studio版を作ろう、という企画が先にあり、1月に知人を通じて声がかかりました。まさに降って湧いたようなチャンスだったので、最低限の調整だけを行って、ほぼ二つ返事でOKしました。

それまでに書いたことがあった中で最も長い本は、88Pの技術書典4本でした。

blog.nkzn.info

200ページ超の執筆は初めてだったので、かなり不安もありました。とはいえ、ここまで大きいチャンスは滅多に来ません。多少自信がない程度で逃すわけにもいかなかったのでした。

当初の予定では5月くらいまでに書き上げて、7月刊行くらいのスケジュールを引いていた気がしますが、筆者の遅筆が原因でずるずると延びて、8月入稿となりました。関係者の皆さんにはご迷惑をおかけしました。

執筆の体制

執筆の体制については、ざっくりと次のような感じです。

  • 編集プロダクションとのやり取り
    • GitHubとSlackでIssue管理と連絡を行う
  • 執筆環境(メンタル)
    • 集中できるようにネットカフェに入り浸る
  • 執筆環境(システム)
    • VivlioStyleでMarkdown+CSS組版で書いた
    • Macで書きたいがためだけにVPNを張ってリモートデスクトップを設定した
    • 初稿の差分管理はGitで行う
    • 以降の校正作業はPDFベースでコメントを付ける

日本語の文章の差分管理にもGitを使うのが有用なのは、プログラマーの間では認知されてきていることですね。

個人的に面白い取り組みだった、CSS組版とリモートデスクトップについて掘り下げます。

CSS組版

今回の本は編集プロダクションのリブロワークスさんと一緒に作ったのですが、リブロワークスさんではVivlioStyleというCSS組版のツールにMarkdownを組み合わせた執筆環境を用意してくれています。

f:id:Nkzn:20180906232000p:plain

libroworks.co.jp

Atomにプラグインを入れておけば、実際の本と同じような見た目でプレビューしながら、執筆を行うことができます。

ReVIEWにもリアルタイムプレビューを行うツールはあったので、執筆体験としては既知の(素晴らしい)ものでしたが、こちらのほうがより実物に近い形で実現されていたので、楽しく執筆できました。

リモートデスクトップ

今回の本はWindows向けなので、Android Studioの動作確認やスクリーンショットの撮影はWindows上で行う必要がありました。一方で、私は普段Macを使っており、指が最もスムーズに動くのはMacです。Emacsキーバインドに指が汚染されているし、XKeymacsは好みじゃないので仕方ないですね。

Android Studioの操作がWindowsに準じたものになるのは問題なかったのですが、Atomで日本語を入力していくときにWindowsのお作法に縛られるのは嫌でしたし、Windows上に快適な環境を作り上げる労力を払うのも嫌でした。

仕方がないので、MacからWindowsマシンにリモートデスクトップでアクセスし、Android Studioを触ることにしました。Windows側で撮影したスクリーンショットは自動でDropboxのフォルダに入るようにして、ほぼリアルタイムでMac側に共有されるようにしました。

また、前述のとおり、ネットカフェでの作業が多かったため、自宅の外からでもWindowsマシンに繋がるよう、VPNを設定しました。これで快適な執筆環境の完成です。

f:id:Nkzn:20180906233450p:plain

この環境ができるまで、なかなか文章を書き始められなかったので、担当さんをやきもきさせてしまって非常に申し訳なかったです……

グランドスラム達成

ここは本の内容と関係ないです。

今回の出版のおかげで、これまで本の形で執筆してきたものリストが次のようになりました。

タイトル 出版年月 出版 形態
はじめる! Corona SDK 2011年7月 達人出版会(商業) 電子書籍(単著)
TechBoosterの同人誌 随時 TechBooster(同人) 紙・電子書籍(共著)
Effective Android 2013年8月 達人出版会(商業) 電子書籍(共著)
Effective Android 2014年1月 インプレス(商業) 紙(共著)
Cheap Dive into React Native 2018年4月 越後屋(同人) 紙・電子書籍(単著)
たった1日で基本が身に付く!
Androidアプリ開発超入門
2018年9月 技術評論社(商業) 紙・電子書籍(単著)

この表を読み換えてみると、なんと、(商業|同人)、(電子|紙)、(単著|共著)の組み合わせを全パターン網羅しているのです。

  • 商業・電子・単著(Corona SDK)
  • 商業・電子・共著(Effective Android)
  • 商業・紙・単著(たった1日で)
  • 商業・紙・共著(Effective Android)
  • 同人・電子・単著(Cheap Dive)
  • 同人・電子・共著(てくぶ)
  • 同人・紙・単著(Cheap Dive)
  • 同人・紙・共著(てくぶ)

グランドスラム達成は言い過ぎかも*1ですが、ちょっとした達成感があります。

この7年間、いろいろ書いてきたんだなあ、としみじみしてしまいますね。本を書く楽しさを教えてくれた皆さんには感謝するばかりです。

今後も、機会を見つけて本を書いていきたいと思いますので、よろしくお願いします。

まとめ

妻や編集さんに助けてもらいながら、何とか本を書き上げることができました。この規模になってくると、とてもじゃないですが自分の力だけでやりましたとは言えません。本づくりって色んな人の力で成り立ってるんだなーと思いました。

筆者がAndroidをやり始めたときにも、多くの書籍に助けられました。私の本が、現代の初学者の助けになれば、望外の喜びです。この本で入門した読者が5年後くらいにDroidKaigiで登壇してたりしたら泣くので、そういう方がいれば5年後にお声がけください。

書店にPOPとか持ち込んだら置いてもらえるのかな……

*1:紙媒体の雑誌連載とかはしたことないですしね

React Nativeの光と闇について喋ってきました #上越TechMeetup

f:id:Nkzn:20180723164831j:plain

7月21日(土)に新潟県上越市で行われた、上越TechMeetup#2に参加してきました。

jtm.connpass.com

町家を改装したイベントスペース「高田小町」で、総勢15名での、和やかな雰囲気での開催となりました。

なんでいったの

主催の五十川さんがRNの話を聞きたいということでお呼ばれしました。上越は地元なので、地元で行われるIT勉強会にお呼ばれなんて、テンションがダダ上がりになる事案です。

個人的なところとして、2010年ごろに上越である程度の規模のIT勉強会を開催することを諦めて新潟市で開催していたという事情がありまして、自分が諦めたことを実現した勉強会を是非応援したいという気持ちもありました。

なにしたの

React Nativeの光と闇というタイトルで講演してきました。スライドは次のとおりです。

www.slideshare.net

細かい内容は後述します。

他の方の発表

印象に残ったお話だけ。

writer.appの話

f:id:Nkzn:20180723163347p:plain

https://writer-app.com/

自動文字起こしのWebアプリです。実用上のニーズから生まれているので、使いやすさはピカイチとのこと。

FirebaseやGCPをモリモリ使っているのは楽しそうだなあと思いました。

EventEmitterの話

@さんから。ブラウザの文脈にEventEmitterを持ち込むと、Reactで小さいアプリを作るときにpropsのたらい回しとかしないで済むことがあって良いよ、というお話でした。

序盤は「えー、いうてEventEmitter氏、大規模に乱用するとプロジェクトが崩壊するじゃないですかー」と思いながら聞いていました。途中で当人から「まあ、規模が大きくなってくるとReduxとかのほうが管理しやすくなるんですけどね」という話があったので、安心して聞いていられました。

SOC2の話

クラスメソッドの植木さんから。↓の裏話について。

classmethod.jp

ISMSなんかも「面倒くさそうだなあ」と思いながら傍から見ていたのですが、これは輪をかけて面倒くさいやつのようです。

「おおお、そこまで監査するんだ偉い」みたいな気持ちで聞いていましたが、自分たちではあんまりやりたくないですね・・・。

React Nativeの光と闇

ざっくりとした内容としてはこんな感じです。

光パート

  • Reactはレイアウトツリーの差分更新が得意なライブラリだよ
  • React NativeはReactの得意分野をネイティブビューの更新に持ち込んだやつだよ
  • AndroidとiOSの同時開発ができるのは嬉しいね
  • react-native initで作ったプロジェクトはXcode/Android Studio経由でビルドすることが多いよ
  • デモ:ハロワとちょっとしたLive Reload
  • React NativeはC++処理系の上で動くJavaScriptCoreの上で、バベったJSを動かしてるよ
  • JSとC++の間の通信方式はWebKitが担保してるので素性がいいね
  • C++とObj-C/Javaの間の通信もそれぞれのOSで普通のやり方があるので素性がいいね
  • デモ:create-react-native-app(Expo)でQRコードリーダーを作る
    • デバッグ時に突如コンソールに現れるQRコード
    • カメラパーミッションの請求も、カメラプレビューの配置も、読み込んだQRコードのデータ受け取りも、Expoならサクサクやれちゃう
    • JANやIMEIのバーコードも読めちゃう
    • ねっ、簡単でしょ?
  • Expoクライアントアプリが色々隠蔽してくれてます
  • 活用事例

闇パート

  • 万人にオススメできるわけではない
  • 無理を通した帳尻合わせを、腕力で何とかしている部分がある
  • 腕力の例
    • エラーメッセージを読む力
      • JSC, Android, iOSのエラーメッセージが混在するので、メンバーの誰かはそれを読めないとしんどい
    • ビルドする力
      • リリースビルドするときは、JS文化圏、Android文化圏、iOS文化圏のそれぞれのお作法を押さえておく必要がある
      • なお、Expoは知らないままビルドしても何とかなる部分が多い
      • Expoは楽なんだけど、本来のやり方を知らないままでいくとトラブったときに身動きが取れなくなるので、やはり本来のお作法を知っている人間はいたほうがよい
    • ストアにリリースする力
      • Google Play ConsoleとかAppStore Connectを使うのは同じ
      • 何にせよAppleの審査員とは闘う
    • バージョンアップする力
      • RN自体のバージョンアップが結構しんどい
      • アップグレードコマンドも失敗することがある
      • マジiOSお前
      • 困ったらreact-native initから環境構築をやり直したほうが早いというのが現状

光と闇のはざまで

  • 技術選択は組織と事業に見合ったものを選ぶべき
  • 普段使っている、責務が小さいライブラリなら、組織や事業との相性を深く考えなくてもリスク少なめで採用できたりする(失敗しづらい)
  • RNはメリットもデメリットも大きいので、よく考えないと採用しづらい
  • Airbnbは結果的に去ってしまったけれど、どんな組織と事業にマッチしそうなものなのかを僕らに考えさせてくれた
  • メリットは最大限享受して、デメリットを可能な限り回避したり打倒したりできる、そんな組織や事業で採用したいですね
  • もしあなたが目指す組織・事業の途上でRNが役立てられそうなところがあったら、使ってみてください

感想

「光と闇」なんて大風呂敷を広げてしまったせいで、自分の中での意見のバランス調整が大変でした。闇パートを先に仕上げたのですが、気持ちがネガティブになってしまい、なかなか光パートを書き始められないという事故があったり。

僕はRNの話をするときに一番怖いのは、オーディエンスが「React Nativeは銀の弾丸である」と思って、誤ったワクワクを持って帰ることです。そのため、普段から闇の話を多めにすることにしていますが、おかげで「お前はRNが嫌いなのか?」と言われることもあります。そうじゃないのです。闇って言っちゃってますが、実際には解決すべき課題たちなのです。課題を解決するためのコストがメリットに対してめちゃくちゃ軽いならば、限られた条件において銀の弾丸っぽいものになることはあると思います。結局は組織と事業にマッチするかどうかです。

とはいえ心配ばかりしていてもReact Nativeの良いところが世の中に伝わらないんだよなあ、とも思っていたので、今回は思い切って光の話もしてみました。Webの人がブラウザ上ではどうやっても獲得できないQRコード読み込みを、超サクッとやってみせるというデモをしただけですが、刺さる人には刺さったんじゃないでしょうか。

また、ノージャンルのIT勉強会だったので、オーディエンスにどの程度の知識を要求したらいいのかという点でもかなり迷いました。ざっくりとReactという概念を先に説明することで、なんとかJSに普段触れ合っていない人向けにも理解度を上げられたのではないかと思います。

今までRNの話は東京でコンテキストの近い人たち向けに喋ることが多かったわけですが、今回の資料作りで新潟向けの難易度調整みたいなところが分かってきた気がするので、今後はもうちょっと県内でも喋ってみたいです。

懇親会

写真を取り忘れましたが、ビアバッシュでした。おしゃべりしてたらほとんど食べてない(いつものこと)。

うちこういう仕事すること多いんだけど、RNマッチすると思う?みたいな話をちらほらもらいました。

総括

f:id:Nkzn:20180723164930j:plain

主に現地の上越や、新潟県内からの参加者が多い感じでしたが、長野や石川からの参加者もおり、上越地方ならではの顔ぶれという感じの特色あるイベントになっていたと思います。

10年前にこのイベントがあれば私は新潟市に移住しなかったかもしれないもしもの話をしても詮無いことなのですが、是非育ってほしいイベントです。

今後とも発表を中心に、応援していけたらと思います。