機能追加しかないように見えるアップデートでもメジャーバージョンを上げ続けてここまで来ています。ChromeはGUIアプリケーションというよりは仮想マシンに近いですし、JavaScript処理系の細かいところまで見ていけば全てのメジャーバージョンアップがちゃんと後方互換のない変更なのかもしれませんが......そんなわけで、Chromeは事実上、メジャーバージョンとマイナーバージョンを統合している(ように見える)運用をしています。バージョニングは誰のためにそもそもバージョニングは誰のために行うのでしょうか。ためにバージョンを運用するべきだと思っています。ライブラリやパッケージの場合は、後方互換性の程度を利用者に読み取ってほしくて、X.Y.Zという3つの数字を運用する、SemVerが重宝されることになりました。GUIアプリケーションのバージョンは誰に何を伝えたいのでしょうか。Webアプリやストアアプリに関しては、エンドユーザーには基本的に最新版を使ってもらうことを想定していて、ユーザー側で昔のバージョンを細かく使い分けることもないので、サポートの面から考えても「最新なのか、そうでなければどのくらい古いか」だけがわかればよさそうです。数値がひとつだけあれば、バージョニングは事足りてしまうかもしれません。いった表記も、それに近い部分がありますね。一方で、それを提供する会社の社内ではどうでしょうか。広報担当と一緒にリリース内容をどう宣伝するか考えるときに「新機能や機能改善を含むリリース」なのか「不具合修正のみのリリース」なのかがバージョンを見ただけでひと目でわかるのは、とても便利そうです。ようなふたつの数値で表すことにして、前者と後者のどちらが上がったのかを見ることで、社内のコミュニケーションを円滑にするのは、良い方法かも知れません。ユーザーに一定以上の負担を強いるタイプの大幅なUIリニューアルを、それなりの頻度で行う社風があるのであれば、後方非互換性を表すメジャーバージョンの運用も、視野に入れてもいいのかもしれません。メジャーバージョンを上げるようなリニューアルをするたびにユーザーに怒られているTwitterを見ていると、それがいいことなのか、少し疑問ではありますが。まとめバージョニングは、プロダクトの作り手と、プロダクトを利用したり運用したりする人々との、コミュニケーションツールです。伝えたいことが必要十分に伝わるならば、必ずしもSemVerにこだわる必要はないと、筆者は考えています*3。プロダクトの特性や、開発組織の特性によって、どのようなバージョニングを採用するかは工夫してもよさそうです。21:20GUIアプリケーションのバージョニングどうする問題(あるいはメジャーバージョン上げられない問題)Tweetもっと読むコメントを書く2019-04-17増刷が決まりました!(たった1日で基本が身に付く!Androidアプリ開発超入門)昨年9月に、Androidアプリ開発の入門書を発売しました。単行本(ソフトカバー)この商品を含むブログを見る発売から約7ヶ月が経ち、amazonでレビューをいただいたり、Twitterで抜け漏れを指摘していただくようになり、多くの方に読んでいただいていることを実感しています。大学生向けのセミナーで、テキストとして導入いただいている事例もありました。技評さんとしても予想外の売れ行きだったらしく、嬉しい限りです。改版ではないので大きい変更はありませんが、主に次の点を修正しています。最初の図の誤りはサポートページにも載っているやばいやつなので、最優先で修正になりました。3.2のときに大幅に変更されまして、初心者殺しになっていたので、こちらも修正しました。手順が減ったので、ページ数が減りかねない事態だったのですが、編集さんが腕力でなんとかしてくれました。ページ数に変更はありません。他にも、読者の方からTwitterでご質問いただいた内容を元に、修正することができました。今後ともよろしくお願いします(序盤だけですが)AS3.3対応で、また最新の現場でも使いやすい入門書になったと思います。未経験から最初の一歩を踏み出すのには、とても適した本らしいことが、amazonのレビューで分かってきました。皆さんの身近にも、Androidアプリ開発に興味のある方がいれば、オススメしていただけると幸いです。前書きにも書きましたが、これは僕が10年前にAndroidをやり始めた頃に読みたかった本です。この本でAndroidアプリ開発への第一歩を踏み出した方と、何年後かにお会いできることを、楽しみにしています。読者の方から相談を受けるトップの話題が、「この本の次に何を読んだらいいですか?」です。この本でどのレベルに到達できたかもよるのですが、ある程度しっくり来た方には、重村さんのポケットリファレンスをオススメしてもいいかなと思っています。単行本(ソフトカバー)この商品を含むブログを見る「こういうことをしたい場合はこうするといい」がたくさん詰まっており、目次を読むだけでも楽しいです。サンプルも豊富なので、写経してみるだけでもいいかもしれません。私も新人の頃には初版にお世話になったので、効果は折り紙つきです。よろしければいかがでしょうか。経験者の方、他にも「この本がいいんじゃないか」というのがあれば、教えてください。NativeポジションMSがRNめっちゃ使ってるという話についてBrownfield事例は実質的にネイティブの事例Skypeの事例ならどうなのかネイティブアプリ開発者の仕事は減るのかまとめみんなの反応Xamarin勢の反応Cordova勢の反応iOSネイティブアプリ開発者の反応jp.techcrunch.comこちらの記事への雑な感想です。感想は私の主観であり、ポジショントークであり、所属する組織の意見とは無関係であることを先に述べておきます。iOSのObj-C)や標準開発ツールである」というニュアンスを含めることをご容赦ください。ポジションこんな感じのポジションの人です。Nativeやってるもっと最近はPWAやってるどんなテクノロジがイケてるかよりも、目の前の事業を前に進めるにはどんなテクノロジが適切かを考えるのが好きですMSがRNめっちゃ使ってるという話についてまずはこちら。「マイクロソフトのiOSおよびAndroidアプリの中身をスキャンしてみた。昨年の6月に中の人がツイートした、開発中の話題が、実際にリリースされるようになったことを受けての話題ですね。2018年6月13日Twitterだと話題の発散がしんどいということでRedditに移動したのがこちら。JavaScript/TypeScript.という説明です。Nativeやreact-native-windowsで組まれている」のは確かです。「APIやサービスは各チームにとって最適な言語であるC++やC#や他の言語で書かれており、アプリケーションのすべてをJavaScriptやTypeScriptで記述したものはない」とも言っています。PDSの用語で分けるなら、「UI」というのはいわゆるプレゼンテーション層でしょうし、「APIやサービス」というのはドメイン層*1にあたるでしょうか。NativeとJS/TSで書いてるところが多いけど、ビジネスロジックは各チームにとって適切な言語で書いてるよ」ということになりそうです。Nativeを活用する」ことをBrownfield、「ネイティブ側はできるだけinit時のままにしつつ、アプリケーションとしてのすべてのロジックをJS側に書く」ことをGreenfieldと呼びます。Greenfieldの場合は必要なAndroid/iOS開発の知識が少なめになるので、JavaScript出身者にはオススメです。365の事例は典型的なBrownfieldです。本来ならネイティブUIで開発を行ってもやれるくらいの玄人集団が、ReactというUI状態管理パラダイムによる開発の効率化や、UI人材の効率的な運用のために実施した施策であると感じました。Anywhere)ので、プラットフォームごとにパーツを作り直していても別に不思議ではないかなと思っています。NativeとかいうUI管理DSLライブラリを使って、ネイティブアプリのUI実装を効率化したよ」とか「UI実装をWebチームの人に手伝ってもらえるようになったよ」みたいな話であり、開発スタイルとしては依然としてネイティブアプリ開発者の力が多大に必要であるはずです。XAMLやUIKitやStorybookやレイアウトXMLやDataBindingといった、ネイティブUIのツールキットを使う機会が減っている可能性は高いですが、GUIアプリケーションはそれらだけでできているわけではありません。複雑なアプリケーションであれば、PDSのPよりDのほうが大きくなることもあるでしょう。Officeの開発では、ネイティブアプリ開発者が、めちゃくちゃ活躍しているはずなのです。いった観点から、Officeの事例を理由にしてネイティブアプリ開発者の需要を語る切り口は、少し的を外しているように筆者は思いました。Nativeラッパーを開発しており、おそらく今でもこれを運用しています。Anywhere」寄りの思想で作られているように筆者には見えており、比較的にGreenfield寄りの運用をしているのかなと想像しています(想像です)。Skype内での活用事例の記事を見ても、JavaScriptランタイムでの話ばかりが出てきます。NativeをWebやWindowsにも拡張して運用するためのラッパーなので、特殊といえば特殊なのですが、こちらの運用ではネイティブアプリ開発者が登場する場面は少ないのかもしれません(想像です)。Android専用モジュール(hoge.android.tsx)や、Web専用モジュール(hoge.web.tsx)みたいなものを作るケースはありそうなので、ゼロ人ということはありえませんが、Officeチームよりはネイティブアプリ開発者の割合を減らせそうな気がします。(中の人!違ってたらごめん!違ってたらマサカリ投げてくれ!!すぐ直す!!!)こっちを根拠にして記事を書いてくれてたら、ちょっとだけ納得感上がったのになあ、と思ってます。ネイティブアプリ開発者の仕事は減るのかここからは筆者の極めて個人的な意見です。筆者は自分のキャリアを考えていく上で、現在の業界をこういう観点で見ているよ、という文章なので、違った考え方を持っている人はいっぱいいると思いますし、それらはすべて素晴らしい観点です。この記事のブコメに短く書いたりせずに、ご自身のブログ等で持論を展開してください。Workerなどの進化(いわゆるPWA)によって解決されつつある分野も多くなってきました。サーバーからもらったデータを画面に表示して、ユーザーの入力をサーバーに投げるだけ*2の要件にネイティブアプリを作る必要があるのかというと、筆者の中では少しずつ疑問符が付くようになってきています。BtoBでお客さんが「アプリが欲しい」と言った場合に、実はそれは素朴なWebアプリでいい要件だったり、少し込み入ってもPWAの範囲でなんとかなるものは、意外と多いのではないでしょうか(肌感覚です)。ネイティブアプリで作るべき要件も世の中に多くありますが、それはすべてではありません。工数や時間やお金をかけて、AndroidとiOSのネイティブアプリをそれぞれ作るコストをかけたいほどの要件を持った顧客は、実はそこまで多くないのではないでしょうか(完全に肌感覚です)。2010年ごろ、Ajaxの流行とともに、.NET製のデスクトップアプリケーションの一部を、Webアプリケーションに置き換える案件が多くあったように思います。それと同じように、モバイルアプリの世界もブラウザ技術に置き換わっていく部分が出てくると、筆者は考えています。当時とはブラウザ技術の雰囲気も随分と違うので、形は違うことになるかもしれませんが、プラットフォームネイティブな開発一辺倒だった業界が、現実的な別の選択肢を得て、多様化していく、という点では似たようなことになるのかなと。いう観点では、相対的に、モバイル向けのサービス提供という分野におけるネイティブアプリの比率は、下がっていくのかもしれません。いう意味では、ネイティブアプリ開発者の仕事が減るという話も、わからなくはないです。いまネイティブアプリ開発者である人は、これからシェアが広がっていく(かもしれない)ブラウザ向けの開発を覚えるのもいいのかもしれませんし、よりネイティブアプリ開発者としての力を付けて仕事を取っていくのもいいのかもしれません。「モバイルアプリ開発者」という肩書きで、AndroidネイティブもiOSネイティブもブラウザも全部いけるぜ!というポジションを取っていくのもいいかもしれません。まとめここから先は君の目で確かめてくれ!という無責任な締めになってしまうのですが、僕もまだAndroidアプリエンジニアを自称している立場であり、今後こういった時代の渦中に放り込まれる立場なので、ご勘弁ください。これからどうなるのかは僕だって知りたい。冒頭の記事については、ちょっと飛ばし過ぎだけど示唆に富んでいるので、話半分で読んでおこうね、くらいの気持ちです。ポジショントークは以上です。この記事のブコメに短く書いたりせずに、ご自身のブログ等で持論を展開してください。ブログを書いてくださった方々を見かけたので、この記事の次に読む記事としてオススメしておきます。「なんでそこでXamarinじゃねーんだよ!」に対するアンサーです。昔のイメージでCordovaをdisんないでくれ頼む、というお話。note.muiOSネイティブアプリ開発者の反応ハイブリッドアプリ的な技術とどう向き合うか、どう見なすか、というお話。僕らは何度も失敗してきた家計簿の管理に失敗してきたパソコンやスマホに家計簿アプリを入れたけどレシートを撮影できるようになったけどクレジットカードは怖い悪循環は続く資産管理に失敗してきたオンライントレードの口座なんて滅多に開かないオンラインバンキングを開くのは振込のときだけどこにどんな口座があったかなんて、とうに忘れてしまったなぜ失敗したのかそうだ、僕らは楽がしたい本書の目指すところ最後に余談:かんたん後払いアプリのメンテナしてます技術書典6にサークル参加します4/14に開催される技術書典6にサークル参加することになりました。Nativeの本を出してきましたが、今回は少し毛色を変えて、お金の本を出すことにしました。ITエンジニアが実践するキャッシュレス時代の資産管理」です。いう、プログラムが1行も出てこない読み物です。興味を持った方はサークルチェックをお願いします。techbookfest.org配置け76にいます。周りに知り合いがいなさそうでビクビクしています。Readerが間に合えば)キャッシュレスと名のつく本で現金決済を中心にするわけには行かないということに、初稿を書き終えてから気が付いてしまった俺たちは。本当はCoineyでタッチ決済までサポートしたかったのですが、審査に時間がかかりそうなのでパスしました。表紙について今回も妻に作ってもらいました。各種キャッシュレス決済サービスが、マネーフォワードに集約されていくイメージです。鉄道網っぽくしました。「情報の流れ」は東京メトロっぽく、「お金の流れ」はJRっぽくしてあります。今回は、社内でいつも資産管理の相談に乗ってもらっている、同僚であり友人のフロントエンドエンジニア、@_yukikayukiさんに声をかけて、紙面の8割方を書いてもらいました。僕らは何度も失敗してきた」でエモ散らかす部分だけを担当して、あとは編集に徹しています。自分が読みたい記事を書けそうな人に声をかけて書いてもらうムーブを、試験的に実施してみた形です。私のハンドリングがド下手だったので、@_yukikayukiさんにはめちゃくちゃ迷惑をかけた気がします(ごめんね)。「はじめに」と「第1章」を公開しますそんなわけで、私が書いた部分は特に新しい情報もなく、単に対象読者と心を1つにするためにエモ散らかした儀式的なものでしかないので、この場を借りて事前公開します。これで興味を持ってくれた方は、技術書典当日にお会いしましょう。150部刷っていくので、まあ売り切れることはないでしょう(フラグ)。当日来れない方は、後日このブログでアナウンスするはずのBOOTH/Kindle版電子書籍をご覧ください。はじめに本書は、いかに最小限の努力で、自分の家計や資産を可視化するか、という課題についての知見を共有するための本です。2010年代の日本では、インターネットやアプリを活用した資産管理であったり、現金を必要としない決済手段(いわゆるキャッシュレス決済)が広く普及しました。これらは金融のためのテクノロジー=フィンテック(FinTech)と呼ばれ、ITエンジニアに人気の事業領域のひとつになっています。お金は現代社会で生きるために必要なものです。それを扱うフィンテック分野のサービスは、やはり、市井の人々のために作られています。特別なスキルや地位を持った人のためのものではなく、普通の人のためのものです。使用者を限定しないとしても、インターネットサービスは、あくまでも道具です。道具とは、その道具が解決できる課題を解決するために使ったときだけ、私たちに恩恵を与えてくれます。まな板で肉を切っても、包丁を肉の下に敷いても、十分な機能が発揮できないのは想像できますね。道具の恩恵を受けるためには、道具の使い方を学ばなくてはいけません。フィンテックはITエンジニアのためのものではありませんが、ITエンジニアは「インターネットサービスがどのような使い方を想定して生み出されたのか」を察する能力には、ある程度長けています。裏側で使われている技術に察しがつけば、フィンテックの各種インターネットサービスを「詐欺かもしれない怪しいアプリ」ではなく、「現代の高度な技術によって実現された便利な道具」として、迷いなく導入する精神性も持っています。加えて資産管理やキャッシュレス決済への関心が高ければ、フィンテックを使いこなすための素養は高いといえるでしょう。彼は家計簿レベルの管理だけではなく、金融方面の資産についても、無理なく可視化して管理できるようにしています。彼も(筆者も)会計や資産運用のプロフェッショナルではないので、そういった分野におけるベストプラクティスをご紹介することはできません。それでも、現代の多様な道具たちを、どんな目的で扱い、どう組み合わせるかという知見は、そこに打つ手が思いつかない人にとっては一定の価値があると考え、筆を取ってもらった次第です。それでは、現代のITを駆使した資産管理について見ていきましょう。本書に記載された内容は、情報の提供のみを目的としています。ご自身の責任と判断によって行ってください。著者はいかなる責任も負いません。僕らは何度も失敗してきたエンジニアが改善の話をするのは、そこに課題があるからです。本書ではどんなことを課題として扱うのか、一緒に見ていきましょう。本章では、キャッシュレス導入以前の筆者が、どんな挫折をしてきたのかをお話しします。家計簿を付けるのが上手な読者の方には、やる気のないやつの泣き言にしか見えないと思います。残念ながら、この本は「やる気のないやつがやる気のないまま家計管理ができるようになる」本なので、ご容赦ください。家計簿の管理に失敗してきた挫折の歴史の一丁目は、家計簿の管理です。進学や就職を理由に人生初の一人暮らしを始めたとき、家計簿を付けることにチャレンジした人は多いのではないでしょうか。結果はどうでしたか?そのまま習慣を身につけることができた皆さん、おめでとうございます。習慣を身に付けられなかった皆さん、筆者のお仲間です。本項では皆さんと一緒に古傷をえぐりながら、課題をみつけていきましょう。パソコンやスマホに家計簿アプリを入れたけど流石に21世紀にもなって、若者がキャンパスノートで電卓を叩きながら家計簿を付けるという話もないですよね。元々がズボラな筆者ですから、実行するまでもなく挫折することが目に見えていました。家計管理の最低ラインがExcelやGoogleスプレッドシート、もう少し便利にするなら、食費や水道光熱費といった費目が入力できるアプリを導入したいところです。筆者は2005年に大学生になったとき、最初のチャレンジを始めました。当時はWindowsパソコンに家計簿アプリを入れていたと記憶しています。実際に管理を始めてみた筆者の前に立ちふさがったのはレシートの管理です。買い物をしたら、レシートを財布にしまっておいて、あとでアプリに手ずから入力します。......筆者のようなズボラ野郎に、そんな作業が習慣化できるわけなかったんですね。うちに財布の中はレシートで溢れかえり、レシートを処理する気力が加速度的に減っていく悪循環が始まりました。溢れ出すレシートもうレシートを処理することは諦めているのに、データを捨てるわけにもいかず、ただただレシートを限界まで財布に溜め込んでは、あるタイミングで諦めて分厚いレシートを捨てる。そんな生活を、10年くらい続けました。レシートを撮影できるようになったけど社会人になってから、家計簿の管理をZaimに写した筆者は、素晴らしいソリューションに出会いました。写真でレシートを撮影すると、レシートに記載された項目が自動で入力される機能は、入力を面倒くさがる筆者にとって、福音であるように思えました。項目名の精度はなかなか難しいようでしたが、金額の読み取りについてはそんなに悪い精度でもなく、筆者は再びレシートとの戦いを志したのです。......筆者のようなズボラ野郎に、そんな作業が習慣化できるわけなかったんですね(1項ぶり、2度目)。確かに、レシートからデータを入力する作業は、手入力するよりは圧倒的に効率化されました。アプリに組み込まれたOCR技術を扱ってくださった方々には頭が上がりません。それでも、筆者は習慣化できなかったのです。これは筋金入りのズボラであり、もうこの類のアプローチを習慣化するのは難しいな*1、と感じつつも、財布にレシートを溜め込む生活はやめられませんでした。クレジットカードは怖い家計簿の失敗は、決済手段にも波及します。通帳や財布の中にあるお金は、どのくらい有って、どのくらい足りないのか把握しやすくなっています。一方で、クレジットカード決済は、単独ではどのくらい使ったのかを把握する方法が、あまり便利ではありません。Webサイトでログインすれば、クレジットカードの利用履歴を見ることは可能ですが、わざわざログインしてまで見に行きませんよね。クレジットカード決済でもレシートはもらえるので、本当はそれを使って家計簿をつければよいのですが、それができないのは前項で述べたとおりです。クレジットカードは持っているし、ネット通販ではとても便利に使えます。家計簿の管理が伴っていない状況での利用は、単に家計のブラックボックスを増やすだけです。クレジットカードこわい利用状況をリアルタイムで把握しづらいまま、クレジットカードを乱用するのは恐怖でしかないので、日常的な生活費の買い物に使うのは憚られます。そんな具合で、クレジットカードとは距離を置きがちになっていました。悪循環は続く唯一購買履歴がデータ化されているクレジットカードは、履歴が見づらいせいで使う気にならない。現金のデータはレシートにしかないけれど、レシートをデータ化するモチベーションはない。それでも諦めきれなくてレシートは溜まる。家計簿の管理が、どんどん遠ざかっていきます。資産管理に失敗してきた少し視点を広げて、家計の重要なファクターのひとつである、資産管理にも目を向けてみましょう。FXなど、資産形成に取り組むのは大事なことです。インターネットの普及によって、個人が気軽に資産形成を始めるためのハードルは、極めて下がりました。筆者も、オンラインバンキングやオンライントレードの概念が現れてから早い段階で、アカウントを作成しています。そんな中で、筆者はいくつかの失敗をしました。オンライントレードの口座なんて滅多に開かないまずは、オンライントレードの話をしましょう。2000年代(いわゆるゼロ年代)に、デイトレード*2やスイングトレード*3が流行ったことがありました。この頃にオンライントレードのサービスにアカウントを開設した方は、多いのではないでしょうか。やってみると分かるのが、そこそこマメな人でないと、デイトレードはおろか、スイングトレードも難しいということです。筆者は、だんだん飽きてきたのもあって、株を長期保有するスタイルに切り替えることになりました。ここで問題になるのが、オンライントレードの口座を開かなくなるということです。株(や、2019年現在であれば仮想通貨など)は、値動きがあります。おいくら万円の資産をそのとき持っているのか、という情報は、家計簿にとって意味のあるものです。それをいちいちWebサイトやアプリで確認して、家計簿につける習慣をもつことは、やっぱりこのズボラ野郎である筆者には、何よりも難しいことなのでした。オンラインバンキングを開くのは振込のときだけオンラインバンキングは、私たちから記帳の手間を奪い去ってくれました。ズボラな人間には最高のツールです。オンラインバンキングと同じく、残高を確認するモチベーションが少ないという問題が起きました。口座がひとつしかないのであれば、ある程度頑張れるかもしれません。実際には、給与受け取り用の口座とは別に、実家との現金授受を行う口座があったり、さまざまな理由でいくつかの口座に資金が分散することがあります。家計簿にデータを反映させるためだけに、すべてのオンラインバンキングの口座を確認する手間はかけられません。唯一のモチベーションとして、振り込みをするときだけは積極的にログインしますが、あまり頻度の多い作業ではありません。どの口座に、どのくらい残高があるのか、どのくらい貯蓄があるのかは、本当は知っているべきなのです。どこにどんな口座があったかなんて、とうに忘れてしまった資産形成をする上での管理作業は、オンライントレードやオンラインバンキングのおかげで、1990年代に比べて、格段に便利になったはずです。筆者はズボラなので、どこにどんな口座があったのかを、自分で覚えておくことができないのです。失敗したのかさて、ここまで失敗談というか、筆者のズボラっぷりをご覧いただきました。考えても筆者に資産管理は向いていないのですが、ここまでチャレンジするのは、次の理念があるからです。子供の学費や自身の老後のために、資産形成をするべきである資産をはじめ、家計の状況は管理されるべきであるこれらふたつのルールは、独り立ちした大人として、譲るわけにはいかないものです。同時に、認めなければならないことがあります。私たちは資産管理のために手を動かしたくない!!!!!このことから目を背けるべきではないのです。レシートの撮影なんかしたくないのです。家計簿アプリの現金残高と、財布の中身を照らし合わせるなんて、もう嫌です。いろんな口座に散らばった資産や負債を取りまとめて、バランスシートを作るのはいいことですが、それを自分で作りたいとは言っていません。家計は管理されるべきです。意思決定は筆者自身が行うべきです。それは、データを集めて見やすくする作業を自分でやらなければならない、ということを意味しないのです。そこから目を背けてしまっていたから、無為に失敗を続けてしまっていたのです。僕らは楽がしたい筆者が本当にやりたかったことを整理してみると、次のふたつだけだったことがわかりました。負債解消の優先順位調整など)前者は把握したいだけなので、それに付随するすべての事務作業は余計なものだ、と言い切ってしまいましょう。後者に必要なやる気やコストについては、今も昔も大きくは変わりません。ここはやるべきこととやりたいことが一致しているので、問題ありません。やる気でカバーできます。ただでも慣れない資産管理という分野を扱うのですから、瑣末な事務作業に時間を使わず、意思決定に時間を使うべきです。本書は、そんなふうに考えたITエンジニアたちが実践した、資産管理の方法の本です。特別なスキルは必要ありません。なんなら、過分なやる気も必要ありません。2019年現在に存在する便利なツールを、本来の目的のままに組み合わせるだけです。さあ、楽をしましょう。MEという株式会社マネーフォワードが提供する家計簿・資産管理サービスを利用し、キャッシュレス生活を行いながら、自動で家計簿を作成できる環境を作るまでを扱います。最後に第1章で書いたとおり、私は家計簿に関して、そこそこ悔しい思いをしてきました。近年のフィンテックの高まりや、良き友人を得たことにより、その悔しさはだいぶ報われてきています。今でも悔しい思いをしている人がいれば、この本を読んで、何かの道しるべにしてもらえれば幸いです。Enjoy!余談:かんたん後払いアプリのメンテナしてます今回もかんたん後払いのアプリを担当しました。MEに連携されないのが残念だけど、頑張ってメンテしたから、みんな使ってくれよな!blog.techbookfest.org*1:のちに個人事業主を始めてみたところ、経費の月締めやレシートの管理がある程度習慣化できている自分に気が付いたので、明確に義務として与えられている作業ならやれることに気がつきました。モチベーションの置き方次第ではあるようです。技術書典5が終わりました。techbookfest.orgサークル参加の皆様、お疲れ様でした。来場者の皆様、ありがとうございました。おかげさまで、総来場者数が1万人を超える、大きなイベントとなったようです。ご来場、誠にありがとうございました。のべ10341人、うちサークル・スタッフ等関係者は889人でした。2018弊サークル「越後屋」も、新刊2冊を引っさげてお邪魔いたしました。Webの薄い本と、Android入門本です。単行本(ソフトカバー)この商品を含むブログを見るさて、イベント自体は大成功だったと思いますが、弊サークルとしては大成功とは言い難い状況になったので、反省会を開きたいと思います。前回よりかなり売れなかった技術書典4では開会90分で、100部用意した紙の本が完売、という快挙でした(その後もダウンロードカードが100部ほど出たので、実質200部出ています)。今回は100部+50部で用意した紙の本が、70部+32部ほど売れただけに留まりました。赤字ラインギリギリくらいなので、失敗というほどではないのですが、可もなく不可もなくくらいの成果です。できたら同人活動はキャッシュフローを確保しながらやっていきたいので、改善していきたいところです。今回の失速の要因となった点を考えていきたいと思います。宣伝不足といっても、要因の1つは火を見るよりも明らかだったりします。前回に比べて、全然宣伝をしていないのです。前回は割とやれてた技術書典4の際には、2度ほど宣伝のブログを打っていました。技術書典4本番2度目のブログは本番の4日前なので、入稿直後くらいです。本番の数日前に宣伝をしたというのは効果があったと思われます。4月の宣伝ブログを書く2日前の時点では、被チェック数が72程度でした。最後の最後で日和って100部で発注かけてあるんだけど、足りないかなあ。被チェック数72なんだよなあ。2018これが、ブログを書いた翌日に、109まで伸びています。2018ブログの内容が激エモだったのは実際あると思うのですが、宣伝の効果が適切に現れた部分もあるのだろうなと考えています。当日には最終的に、249まで伸びていました。被チェック数は249でfixっぽい。DL版も合わせると210部くらい捌けてるので、最終値の84%くらいの方にはお買い上げいただけた模様。2018今回は本当にダメさて、それでは今回はどうだったでしょうか。技術書典5に出るよという記事:書いてない本の内容の宣伝の記事:書いてないブログではまったく技術書典5や新刊について触れていません。ここで死ぬほどもったいない点としまして、技術書典5の5日前の被チェック数は、技術書典4の6日前の被チェック数と同水準だったのです。今これなら100〜150部くらいで妥当そうだし、100部で大丈夫だなー。2018この頃の私は完売しないとも知らずに呑気なものです。この時点で宣伝をババーンとやっておけば、もうちょっと伸びが見込めたのかもしれません......実際にはまったく宣伝もしなかったため、緩やかに伸びていくばかりでした。当日時点でも159となりました。今回は被チェック数159でfixのようです。2018サークルチェックを付けたからといって来る人は意外と多くないので、やはり200とか300とかの数字がないと、前回ほどの集客は見込めなかったということだと思います。地道な宣伝、普通に大事だよねというお話でした。内容がニッチだったこれはまあ、反省点ではなくて世の摂理なのですが、ニッチなものはマスほどには人を呼び集められませんよねということで。Webというニッチ・オブ・ニッチを攻めてしまった以上、集客につながらないのは当然でした。Nativeは、ニッチながらもCRNA記事などが広く門戸を開いてくれていたので、そこまでニッチ感は強くなかったのですが、今回はもうレベル設定がめちゃくちゃです。わかるやつだけわかれ!の世界です。前述のとおり、これについては反省していません。Webの話が書きたかったんです。