Page 10 of 29

以前、耐久カート大会に誘って頂いた、エンジニアのお友達である長谷川さんが、「TECHNICAL MASTER はじめてのiOSアプリ開発 第2版 Xcode 8+Swift 3対応」という本を出したらしい。

というわけで、エンジニアと技術書執筆というテーマについて書きたいんだけど、周りでもエンジニアの人が技術書を出したという話は結構よくあることです。

しかし、「本を出すのは本当に大変だった。。」とか、「執筆に集中するため、その間は他の仕事全然できなかった。。」とか、「特に儲からないので、お金目的だったら絶対割に合わない。。」とか、とにかく技術書書くのは大変だという話をよく聞く。

では、ただでさえ仕様が変わると対応するのが大変な技術書を、そこまでして書くモチベーションはなんだろうか。これに関しては、「名前が売れて自分のキャリアに繋がる」という意見が一般的です。

やっぱ、ブログで書くのと書籍を出すのとは違うので、本を書いているっていうのはそれだけでブランドアップなのは間違いない。あと、最近、僕が電話サポート始めて実感したんだけど、ブログでリーチできる読者と、本でリーチできる読者は違うことが多いので、まったく別の層の人たちに届けられるってのがあると思う。

それ以外には、自分が学習した知識を本という形で発表したいとか、僕がブログ書いている理由のように、本を出すことによって偶発的なよいことが起こる可能性は高まりそう。

ブログを書いていると、たまに突発的ないいことが起こる

ここまでは僕の想像の話なんだけど、長谷川さんはすでに会社のCTOだし、iOSDCっていう国内最大規模なんじゃないかっていうiOSのカンファレンスを成功させたりと、いろいろやってるんですよね。

だから、僕の想像もつかない崇高な理由だったり、コミュニティに貢献する気持ちが高すぎるとか、隠された世界征服計画みたいなのがあるのかもしれない。なので、このへんをのらりくらりと誤魔化されないよう、ビシッと聞いてみました。

本を書くことで自信がつく？

FBでサラッと聞いてみただけなんだけど、結構自分が予想してた答えと違った部分が多々ありました。

＠長谷川さん
僕は今回の本は4冊目なのだけど、動機はどれも違っていて。

1冊目はFacebookアプリの本だったのだけど、ずっと「1回本を書いてみたい」って思ってたところに、出版社の方から「Facebookアプリの本を書ける人を探しているのだけどどうですか？」って連絡頂いて、それなら、という形でした。

2冊目（CakePHPの本）と3冊目（iOSの本）は同じ動機で、会社の新メンバーに「これだけ読めば良いから」という本が、その当時に無くて、内部的なマニュアルを書くぐらいなら本にした方が良いな、ということで出版社の方に企画を持ち込んでいます。

4冊目（今回のやつ）は3冊目のアップデートで、「3冊目、内容自体はまだ有用だと思うのだけど、Swiftのバージョンが上がってしまって使えなくなってしまって勿体ない！アップデートしたい！」という動機でした。

で、効果として、本って思った以上にフィードバックがなくて、「名前が売れる」という実感はないんですよね。考えてみたら自分も本を読んで感想エントリを書くことはほとんど無いし、ましてや著者に何かフィードバックしたことないし、まあ、そりゃそうか、とは思いますが。

長谷川が書く技術書の初版発行部数から考えると、たくさんの人に届けるだけならBlogの方が多くの人に届く感じですねー。

本を書く効果として、最初から狙っていた訳じゃないのだけど、あとから気付いた効果は、自分への自信が付くというところですね。
特に僕は本を書かなかったら勉強会デビューしなかったと思うし。
「本を書いたから勉強会に行っても恥ずかしくないな」みたいに当時は思って勉強会デビューした。（そしたらすごい人が沢山居て自分の程を知ったのだけど。）

あとは、当然だけど、その書いた範囲で正しい知識が付きますね。嘘は書けないのでちゃんと調べるから。

そう言う意味で、「こんど本を書かないか？って誘われているのだけど」と相談されたら「ツライし儲からないけど、良いと思うよ。おすすめです。」って答えると思います。

なるほど、本を書いても意外と名前が売れる感覚はないらしい。

しかし、本を出してから勉強会デビューというのは相当ハードルが高い(笑)。僕なんて、iPhoneアプリ始めたばっかりの頃なんて、さっぱりわからない状態で参加して、登壇者の発表の10%も理解できてなかった気がします。

しかし、まだまだ本音を引き出しきれていない気がするので、さらに質問をブッこんでみました。

僕を褒めて！みたいな理由はないんですか？

＠梅本
なるほど、これはすごい面白いですね。。自分への自信がつくと。

そういえば、僕が勉強会で自分が最近得た知識とかを発表する時って、例えば、iOSMeetUpでかなり周りに褒めてもらった、Mixpanel使ったリーンアナリティクスの話なんかは、「このサービスのこんな便利な使い方と、ハマりポイントをみんなに教えてあげる俺をみんな褒めて！」みたいなモチベーションでやったんです。

Lean Analytics 虚構の数字と改善に繋がる数字

あまりそういう、みんな僕を褒めて！みたいな欲求はないんですかね。ブログだと波及効果高いけど、勉強会で発表するって本よりネットワーク効果は薄い。ただ、僕の場合、勉強会の発表にはまたそういう違うモチベーションがありまして。

＠長谷川さん
本を書くにあたっては、「褒めて！」というモチベーションは自分は無いかなあ。Blogを書く時はまさに自分も「良いでしょ！褒めて！」のモチベーションなので、不思議ですね。相手の顔が見える度合いという意味では、「勉強会 >> Blog >> 本」って感じだろうから、それとモチベーションのベクトルが関係しているのかなー。

確かに、そう考えると本を出すって、自分の作品を世の中に出すという感覚で、勉強会やブログとはまた違う満足感がありそうですね。言われてみるとそうかもしれない。

でも、そうは言っても技術書を書くってすごい大変だろうし、周りのできるエンジニアの方達の中でも、「僕は無理ですわ。。」っていう意見もよく聞くんですよ。なので、もっと深掘りするべく、質問を続けてみました。

自分の作品を出すという感覚

＠梅本
３冊目の本、Swift本を最初に書こうと思ったモチベーションは、まずSwiftについて調べたかった、そして、調べていくと詳しくなったからどうせなら本にしたかったってのもあるんでしょうか？

＠長谷川さん
これは、環境がSwift化したことで、今まででも「これ1冊でOK」というのがなかったのに拍車がかかって困るなー、今が一番書くタイミングだな、と思った感じでした。あとはまあ、Swift化して本が減るタイミングなので労力に対するリターン（注目・実売数）大きそうだな！というスケベ心もありましたw

その過程で勉強できて嬉しかったけど、自分の場合は「勉強になるから書こう」という感じでは無かったですね。

なるほど。聞いていくと、世の中に求められているタイミングで、そのニーズを満たすものを本という形で出したいというのが執筆のモチベーションになっているのかな？と思った。

聞いてると気がついたんだけど、勉強会やブログと違って、本を出すって、自分の作品を世の中に出すって感覚があるんじゃないかなあと。自信がついたというのは、結果的にそうなっただけで、最初から意図してたわけではないだろうし。

僕の経験で想像すると、自信がついたっていうのも、自分が気合い入れてやったことだからこそなんではないかと。

例えば、どんなに周りから評価されても、自分がどれだけ努力したかってのは自分がわかってるので、「実は、あれ大して俺力いれてないんだよね。。」てなモノだったら本当の自信にはつながらないだろうし。

てなことを聞いてみると、さらに突っ込んだお話が聞けました。

＠長谷川さん
確かにそうかも。 > 求められているタイミングでそのニーズを満たすモノを本という形で出したい

自信が付いたのは、まさに結果的に、ですね。

そして、「自分の作品を出す」というのは確かにあると思う。
書き始めに、少なくとも、出版社がお金を掛けて（投資して）出す、ということで、最初から一定の評価を受けている状態、というのも良いのかもしれない。（声をかけられたり、企画が通った時にはやっぱりアガるし。）

「自分の作品」というのは本当にその通りで、今回、実は、ちょっと自分の不本意な形で本が出そうになって、普通だったら人に言わない様なハードな交渉を編集者にして、不本意な形を回避したんだよね。

具体的には、最後の校正のタイミングで、1週間かけて校正して提出したら「もう印刷所に回しました」「その校正結果は反映できません」「なんでもっと速く校正してくれなかったの」と言われて、一度は怒りつつも「そうですか」と言ったのだけど、夜、妻に話したら「それはおかしい」と言ってくれて、一転、「これじゃ出せません」「これは僕の名前で出すものです」という話をしたんです。
そして、「1）スケジュールを引き直して、長谷川の校正を反映して頂く。 2）今回は出さない、9月のタイミングでiOS11を反映した版として、あなた以外の編集と出す 3）この本は出さない。この話は無かったことにする 4）このまま出す。長谷川の名前だけでこれを出すのはフェアでないので、長谷川が校正で見つけた誤植を、あなた（編集者）の実名入りの経緯とともにBlogに書く」という提案をしました。

結果、撤回してもらえて、自分の100%のモノが出せたのだけど、この怒りはやっぱり「自分の作品」感から来てると思う。

本は常に「100%完璧！」とはならなくて、「もっとこうしたかった！」というのはあるけど、それでも、納得の1冊にはなっていて、それが自信につながるというのは仰るとおりですねー。

これは妻以外には初めて話しましたw

ただ、彼にも彼の立場があり、長谷川が当初想定して、彼に話していた内容から彼が想像していた納期よりかなり伸びていたのは確かなので、100:0の責任じゃないのだけどね。ただ、それにしても最後の最後の印刷所受け渡しのところで長谷川確認が入らないのはマズいですね。

おおお、僕はこういう深い話が聞きたかったんですよ！！こういう魂を込めている感じはいいですね。自分の作品だという意識があると、短期的な目の前の利益とか関係なくいいものを出したいという気持ちになるのはアプリ開発やその他の創作活動でも同じだと思う。

でも、書籍やハードウェアってデジタルなものと違って簡単に変更できないから、やっぱり大変ですね。そのぶん、デジタルなものはプラットフォーム上のサービスが終了したらすぐ使えなくなる可能性が高いんですが。

今回はなるほどなあと思う部分がいろいろありました。いろいろと掘り下げて聞いてみると、自分の想像を超えた新しい発見があって面白いですね。

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

僕は個人でアプリを出してるんですが、以前から試してみたいなと思いながらもビビっていた電話サポートを最近始めてみた。

以前から、アプリ内にHelpshiftでヘルプチャットいれて、そこからのフィードバックは多いに参考にしながらアプリをアップデートしてるんだけど、さすがに電話サポートまでは面倒だなというか、開発中に突然電話かかってきたら集中力が途切れないかなとか、そういう懸念からやってませんでした。

しかし、チャットに比べて電話で対応できたらユーザがどこで詰まるかの情報量も圧倒的に多くて改善に役立つだろうし、その場でこちらから質問もできるから解決も速いはず。

さらに、問題がわかった順にアプリを改善していったり、ヘルプの書き方を変えていけば、同じ質問は何度もこなくなるというのは以前からの経験でわかっている。Airbnbの創業者も創業当時はずっとヘッドセットつけながら、ユーザーサポートを自分でやってたらしい。

といっても、自分はスタートアップじゃないしなあとか、こっちの時間で返信できるサポートメッセージとは違うだろうしなあと思ってたわけです。

しかし、時は確定申告シーズン真っ只中。Taxnoteで試してみてもいいかなと先日ふと思った。電話に取れなかったら掛け直せばいいし。どうせたいしてかかってこないだろう。

なんでも試しにやってみて上手くいかなければ中止すればいいかという軽い気持ちでやることに。Taxnoteのヘルプページに電話サポートも始めたよと書いて、サブで持ってた050の電話番号を記載しておいた。050って解約するのが面倒で放置してたけど、こんな時に役に立つとは。

Helpshiftのヘルプページがこんな感じなので、一番上に電話対応の項目を追加。これは、Web側から自由に消したりできるので楽チン。

電話がかかってきました

今から二週間前ぐらいから始めたんだけど、さっそく電話がかかってきてた。その時は自分がiPhoneをお休みモードかなんかにしてて気づかなかったので、こちらからかけ直した。

電話してみると、僕と同じ関西出身の若い感じの人でした。質問は、「このアプリってどうやって確定申告に使うの？」っていう話だったかと思う。なので、「このアプリは帳簿をサクサク入力できるアプリで、申告時は損益表画面の集計を書き写してもらって〜」というような話をした。

次の日もかかってきた。次の日もなぜか電話に気づかなかったのでこっちからかけ直した。次は落ち着いた感じのお店を経営してる人だった。「このアプリを数年前に買って有料版で使ってるんだけど、またお金払ったりしないといけないの？」といった質問だった。

これは、Taxnoteクラウドという月額課金のオプションを今年から追加したのだけど、これをみて、「以前アップグレードしてるんだけど、課金しないと使えなくなるのか？」といった質問だったと思う。

そこで、「いや、これはさらに便利になるオプション機能だから、特に必要なかれば今まで通り使えますよ」というようなことを説明した。

それ以外にもだいたい二日に一回ぐらい電話がかかってくるけど、よくあるのはやっぱり有料版に関する質問。お金を払う部分になるとみんな慎重になるから、ここはしつこいぐらい丁寧にアプリ内で説明しておいて、誤解のないようにする必要があるなあと再認識できた。

課金の質問と同じぐらい多いのが、やっぱり確定申告さっぱりわからんのだけど、どうすればいいんでしょうかといった具合の質問だった。

ここは、アプリ内で、初めて確定申告する人からのよくある質問とか、確定申告を楽にする合理的な方法のまとめとかのリンクを張っているけど、それ以前にわからない部分とかいろいろあるようで、ここも初めて申告する人がまずどこで詰まるのかというのがすごく参考になる。

初めて申告する人がどういう疑問を持ちやすいかがわかれば、どういうアプリのデザインをしていって、どういう順番で適切なヘルプに誘導すればよいのかも想像しやすくなるので、ここもかなり参考になる。

電話だとITに疎い人の状況がよくわかる

予想してたことなんだけど、メッセージベースのサポートと電話サポートの大きな違いは、ITにあまり詳しくないユーザの話が聞けたり、その人の状況が詳しくわかるということである。

例えば、メッセージでのサポートは、IT系に慣れている人に向いている。というのも、PCやアプリを使い慣れている人は、自分のエラー状況とか、困っている状況を適切に説明することに慣れているわけです。

「こういう状況で、こういう操作をするとアプリがクラッシュします。これこれこういうことを試したんだけど、上手くいかない。自分はiOS9だけど、それが原因ですかね？」

結構詳しい人だとこんな感じです。もっとわかりやすくするため、スクリーンショットまで貼り付けてくれたりする。こういう場合、メッセージから相手の状況がわかりやすいし、適切に解決方法がわかって対処できたりする。

しかし、ほとんどのユーザはアプリにそこまで詳しくないし、PC操作も慣れていない人が多い。そういう場合、メッセージ打ち込むのも時間がかかるからやらないだろうし、そもそもメッセージしても短文でこんな感じです。

「弥生会計に移せない」

この場合、Taxnoteのデータ出力機能を使った時に問題があるのか、それとも、TaxnoteのデータをPCに移す過程がわからないのか、それとも弥生会計にTaxnoteファイルを取り込む部分がわからないのか、こちらとしては情報量が少なくてわからないわけです。

なので、「今はこういう状況ですか？もしかして、こういう状況ですか？」とこっちで詰まっているところをいろいろ想像して質問を返して、相手に状況を説明してもらうよう促すのだけど、たいていの人は問題の状況を説明するのが面倒だろうし、どう説明したらいいのかも慣れていないから諦めてしまう。

こんな時、電話サポートだと、その場で直接相手の状況をこちらから質問できるので、ITに疎い人でも、言い方を変えたり、相手にわかりやすいような質問の仕方を工夫することによって、問題の状況が圧倒的に理解しやすい。

こんなふうに、情報量が圧倒的に豊富になるというのと、こちらから質問しやすいというのが電話サポートの大きなメリット。

さらにいうと、メッセージでのサポートとは違った種類の質問がくるというのもわかった。例えば、メッセージだと、「こんな機能ありますか？」というようなものが多いけど、電話だと、「そもそもこのアプリはなにができるんですか？」という、もっとはじめのの段階の話が多い。

つまり、電話サポートというのは、メッセージでのサポートとはまた違うセグメントのユーザに対応できるというのがやってみてハッキリわかりました。

ちなみに、いろいろサポートをしていると、「この操作をすると、ホーム画面が表示される」という表現はアプリが落ちるという意味であることが多いとか、どういった表現を使えば分かりやすいかというのが学習できて、アプリ内にわかりやすいテキストを書く力が向上しやすい。

どこで離脱しているかの想像力が格段に高まる

電話サポートをしてみると、全国各地のいろんな人が使ってくれてるんだなとか、問題を解決した後に直接喜んでくれるとか、最後になにか要望とかありますか？とか聞けるとか、いろいろよいことはあるんだけど、なんといっても一番の価値は、ユーザがどこで離脱するかの想像力が高まるということです。

ユーザをグループ分けしてみると以下のようになると思う。

1.少し使ってよくわからないから離脱した人。
2.少し使ってわからないからヘルプ探した人。
3.少し使ってわからないからヘルプ見て質問送った人。
4.少し使って自力で使い方を習得した人。

今までは、1と2で離脱していた人のレベル感とか、どのへんで離脱するかはブラックボックスだったわけです。3以降の人はメッセージが来るから、その内容から「ああ、このへんがわかりづらいんだなあ。」とか想像することができた。

しかし、電話サポートしてみたことで、2の段階の人の声を少しでも聞くことができて、「ああ、こういうところでわからなかったらもうお手上げだったのかー」とか、もう一つ前の段階のレベルで改善すべき点がたくさんわかった。

これは、別に新しい機能をつけるとかたいそうなことが必要じゃない場合も多くて、ちょっとヘルプの書き方を変えたり、ヘルプにスクリーンショットをつけたり、アプリのメッセージの文言を改善したりで解決する場合が多い。

ようは、気づくか気づかないかの違いだったということが多くて、この情報が大きな差になるというのが、小さな改善の積み重ねの繰り返しでは重要になってくる。

というわけで、サポートに力をいれてもいいかなと思うアプリだったら、新しい気づきがあるので興味のある人はぜひ試してみてください。

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

最近はTaxnoteのAndroid版を作ってるんだけど、僕はAndroid開発に慣れてなくて一人でやると亀のようにノロイ。ということで、できる方にお願いしてSkypeペアプロで教えてもらったり、ここの作業をお願いしますといった形で、リモートで開発を手伝ってもらいはじめた。

このサイトでも、エンジニアをゆるく募集というページを最近作りました。

去年からRailsやらAndroidやらと、Skypeで画面共有しながら教えてもらうことを始めたんだけど、完全にコーディングをお任せするというのは初体験だったのでどうしたら上手くいくか日々考えてるところ。

そこで、リモートで働いてもらう時にどうしたら相手がやりやすいか考えてる。周りのフリーの人の話を聞いたり、自分だったらこういうやり方が働きやすいかなと想像しながら実行してるアイデア。

1.時給でお願いして時間は自己申告してもらう
2.コミュニケーションをめちゃ大事にする
3.ゆるくお願いする
4.こちらから提供出来る事も考える

時給でお願いして時間は自己申告してもらう

まず、プログラミングなんてものは修正の繰り返しだし、機能を実装するのにどれだけ時間かかるか見積もるなんてミッション・インポッシブル。というわけで、働いた時間だけお金を払う時給計算が無難だと思う。

プログラミングはどれだけ時間かかるか事前にはわからないし、こだわればこだわるほど時間がかかる。アプリって何度もやり直しながら作るもんだから、時給じゃないと修正依頼も言いにくいし、やるほうもいやだろうと思う。

そして、作業時間は自分で測ってもらう。そのさい、調べ物する時間や、作業中にハマった時間も含めて、仕事に関する作業をしている時間はすべて計測して申告してくださいとしている。プログラミングって頭の中で考えたり、調べ物したり、ハマったりすることは当たり前なので。

もちろん、Skypeで作業の打ち合わせをする時間も、作業報告のメール書く時間も含め、すべて計測してもらって。

こうすることで、お願いする自分のほうも、相手が効率良く仕事できるようにいろいろ考えるので結構いい。例えば、相手が作業中に悩まないように必要な情報を漏れなく完結に伝えるとか。疑問点や聞きたいことがあれば速攻で聞いてもらうようにするとか。

これ、お願いする側からすると、どれだけお金がかかるかわからないから不安だとか、ダラダラ仕事されたら不安とか思うかもしれない。でも、優秀なエンジニアはそんなケチなことしないので大丈夫。

まだお互い付き合い短い間は、これ以上時間かかりそうだったら一旦止めて相談してくださいと先に言っておいてもいい。

ちなみに、世界最大のリモートワーク斡旋サイトUpworkでは、時給計算のお仕事用に作業者のPC画面のスクショを定期的に記録する機能があるけど、あんなのは絶対にやめたほうがいいと思う。

僕だったら、自分のPCを定期的にスクショ取られる時点でプライベートなものが写ったらどうしようと気になって集中できない。作業でハマった時には頭をクリーンインストールするため、エッチな動画でも見てスッキリするのはエンジニアでは誰もがやっている当然のことだろうし。

コミュニケーションをめちゃ大事にする

こうすればやりやすいかなと思った事を実行してるんだけど、自分の想像と相手とのズレがあったらまずいので、出来るだけ定期的にこちらから相手にいろいろ聞くようにしてる。聞かれないと自分から言いにくい事ってたくさんあるし。

「もっと働きやすいようにするにはどうしたらいいですかね？」とか、「どういう時が一番困りますかね？」とか。

すると、「やっぱり、コミュニケーションを密にとってもらうのが一番重要だと思います。」と教えてもらった。

確かに、依頼側の要求がよくわからないままやる作業ほどストレス溜まるだろうし、作業中に「これどうしたらいいかな？」とか、「ここどうしてほしいかな？」とかいろいろ疑問に思う事は無数に出てくると思う。

なので、聞きたいことがあったらすぐ聞いてもらえるよう、Skypeにできる限り常駐することにした。あと、電話で聞いてもらってもいいし。

さらに、やってほしい作業の説明も誤解がないよう出来る限り詳しく説明するように。特に、アプリ開発って何度もやりなおしたり、後からUIが変わったり、今は後回しにするけど将来的にはこういう設計にしたいとかいろいろある。

特に僕は、小さくリリースしてユーザの反応や要望を聞きながら開発するポイントの優先順位を決めていくので、最初は本当に重要な部分から順番に開発する。だから、新しい実装をお願いする時も、変更や修正が多そうなところは、まずはザックリとだけ作ってもらうようにお願いしてる。

せっかくやってもらった作業が無駄にならないよう、「ここはいろいろ変わったり、違う方法に変更するかもしれないので、まずはざっくりとラフな感じでお願いできますかね」といった感じ。

ほんと、コミュニケーションを取るってのはこまめに相談する機会を増やすにつきるだろうし、言いやすい空気もあるだろうし、お互いのイメージに誤解があるとやりにくいだろうし、本当に難しいと思う。

反対に、何度も無駄な打ち合わせがあってもウンザリするだろうし、簡潔に大事なことを短く伝えるというのは意識し続けないと難しそうだ。相手だって要点がわかりにくい長い文章を読みたくないだろし。

フリーでやってる友達に聞いたところ、Skypeの打ち合わせはお互いに時間を合わせないといけないのがダルいらしい。だから、機能追加していく場合、詳細な説明が書かれている実装リストを細かく定義してくれるのがやりやすいとか。

今まで基本的に一人で作ってきたので、こういうところは本当に新しい領域。

ゆるくお願いする

先週、ペアプロで教えてもらってるエンジニアの方に「ゆるくできるのはメリット」だとも教えてもらった。どういうゆるさがよかったのかは聞いてないのだが、自分がどっかで働くなら、労働時間が短くて、いつでも気軽に辞められて、スケジュール調整に融通がきくのが嬉しい。

まず、キツイ納期だといいプログラミングが書けないので、1日３時間ぐらいまでのペースでやってもらって、あまり作業は急かさないようにするのがよいと思う。もちろん、もっと長くやりたい場合はやってもらってもいいんだけど。

あと、ちょっと仕事したくなくなってきたら、いつでも気軽に辞めれる、またはしばらく休める、気乗りしないプロジェクトや作業は断れるっていうのが気軽でいいと思う。僕もコードを書くので完全に開発がストップするということはない。

ゆるい感じだと、「ちょっと興味あるけど、始めてみてなんか微妙だったら嫌だな」と思った優秀なエンジニアが軽い気持ちでちょろっと手伝ってくれるかもしれない。飽きたり、他のことをしたくなったりもすると思うので、暇な時だけ手伝ってもらうぐらいがいいかも。

こうなってくると、ワークシェアみたいな考え方で同時に複数人の人に手伝ってもらう体制になるので、メリットもデメリットもありそう。

まず、エンジニアとしては他の人が書いたコードを引き継ぐというのは基本的に苦痛である。だから、作業人数が多くなればなるほどやりにくい。とはいえ、フリーランスの人もいろいろな仕事をかけもちしてるだろうから、毎日手伝ってもらうことも難しい。このへんはジレンマ。

こちらから提供出来る事も考える

世の中には無料ランチとか、技術書読み放題とか、成長できる！とかいろいろ働く場所によっていいことがあります。

残念ながら僕の開発を手伝うのはあまり成長できるわけでもなさそうだし、セクシーなスタートアップ環境でもない。このへんも厳しいところなんだけど、このブログで書けないように自分の個人アプリ開発での経験やらノウハウやらに興味ある人には、雑談タイムに好きなだけ話したい。

あとは、Taxnote作るにあたって確定申告に詳しくなったので、初めて申告する人の相談にはのれそう。

こう書いてみたけど、正直どちらもエンジニアの人にとってはあまりメリットなさそうなのが困る。やっぱ、エンジニアなら優秀な人が集まってて、成長できて、新しいことに挑戦できる職場がいいもんですよね。悩ましい。

僕の経験でいうと、仲の良い友達と一緒にやるバイトってのは楽しかった思い出があるんで、一番重要なのは少しでも楽しく仕事ができる雰囲気を作ることなんですかね。このへんは人間力が問われる難しいところだ。

実際いろんな意見を聞くとハッとすることが多いので、TwitterでもFacebookでも、こういうのよくなくて、こういうのがやりやすいというのを教えてもらえれば喜びます。

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

こんにちは。去年から作ってたTaxnoteのAndroid版をついにリリースしました。

Taxnote Androidのダウンロードはこちら。

Taxnoteは2014年2月にiOSアプリとして始めてリリースしたんですが、自分が想像してた以上に好評で、これに気を良くしてコツコツ改良をしていった結果、おかげ様でAppStoreでも人気の会計・確定申告アプリとなりました。

こうなったらAndroid版も出すかと前から考えてたのだけど、Androidを覚えるのが面倒だなあ、しんどそうだなという思いから二の足を踏んでたんですが、iOS版で念願のグラフ・チャート機能とクラウド同期ができたのもあり、そろそろやるかと思い腰をあげて作り始めました。

Taxnoteってなにがいいの？

Taxnoteを作ったきっかけは、2014年に書いた開発秘話に詳しいのですが、簡単に言うと、PCの会計ソフトで帳簿入力をするのが面倒すぎたので、最高に入力しやすいアプリを作ったるという思いからでした。

なにより、スマホならなにかを購入した直後に経費入力することができる。この、その場で速攻で入力できるというのには一番こだわっていて、Taxnoteは片手で、最低限のタップ数で、ボタンも押しやすい操作性というのを追求してます。

あと、PCのキーボードで帳簿を入力するのって結構面倒で、さらにパソコンで起動するまで時間かかるし、ITに疎い人のPCって起動まで平気で数分かかって、会計ソフトも激重になってるんですよ。このへんもTaxnote使いやすいと言ってくれる人の理由らしい。

TaxnoteのAndroid版では、帳簿を爆速で入力する、簡単に編集する、データを会計ソフトに出力するということが楽チンに出来ます。

まだまだiOS版に比べて本当にシンプルな状態だけど、これから精力的にアップデートしていきたいと思っております。iOS版でもそうだったけど、初期のほうで有料版を購入してくれた方は得するように、最初は価格も低めに。

アプリ内のボタンから要望・質問が送れます

なにげに、一番Taxnoteで好評なのは、アプリ内の「要望・質問を送る」ボタンです。ここにメッセージしてもらえると、24時間以内に僕が返信して、ユーザはアプリを開いた時に返信があったらメッセージを読めるという仕組み。

ここでは、確定申告が始めてでなんもわからん！といった人からの質問や、アプリの使い方がわからないところ、要望など、僕が答えられる範囲のことは出来るだけ早く返信するようにしている。

最近は、実験的に電話対応も始めてみた。アプリ操作の質問から、確定申告のことから、電話だと圧倒的に詳しく説明できるので、こちらとしても、「ああ、こういうところで引っかかるのかー」とか発見がめちゃくちゃ多い。

なので、Taxnoteをダウンロードした方は遠慮なくお願いします。

最近、いろいろな質問をもらった経験をもとに、下記の記事も書いた。あと、みんなが詰まるクレジットカードの仕分け方法とか、すべてを楽チンにする簡易簿記の話とかも書いてる。

初めて確定申告する人からのよくある質問とその答え

開発を手伝ってくれてる方

プログラミングって難しいし設計とかは得意な人に聞くのが一番なので、今回はAndroidが得意なエンジニアの人にいろいろ手伝ってもらってます。

岡野さん(@operandoOS)には、新規プロジェクトを作成の段階から、設計、画面の作り方などAndroidのイロハを毎週Skypeで教えてもらいました。Android版の骨組みはほぼ作ってもらったようなもので、そのコードを見ながら僕は覚えていった感じです。まだ若いのに経験豊富で将来が末恐ろしい。

野崎さん(softcommu.com/)には、今年に入ってから機能追加をリモートで手伝ってもらっている。企業で偉いところまでいった後独立したベテランの方なので、いろいろ仕事がやりやすいよう取り計らってくれるのがすごい勉強になる。

Taxnoteって地味なアプリだけど、出来る限りたくさんの人に使ってもらえるよう、これから頑張ってよいものにしていきたい。

Taxnote Androidのダウンロードはこちら。

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

フリーランサーになった人、飲食店を開業した人、起業した人など、いろいろな人がTaxnoteを使ってくれてますが、確定申告を初めてした時の自分にあった素朴な疑問をまとめてみました。

赤字でも申告しないといけないの？

赤字なら必要ないけど、経費記録しないと諦めて就職した時にも損です。
（個人事業主として独立するなら、将来、結果的に儲からなくて就職したとしても、帳簿つけて赤字の確定申告しないと損する）

確定申告っていつやるの？

窓口受付は2月16日〜3月15日です。

事業届け出してないけど経費記録したほうがいい？

はい。事業になるかわからない時期でもコツコツ経費は記録しましょう。最初の申告時に開業費として経費にできます。

会計ソフト使えば素人でも簡単なの？

青色(複式簿記)なら結構難しいです。青色(簡易簿記)か白色ならメチャ簡単で会計ソフトもいりません。Taxnoteだけで十分です。所得が低い時は複式簿記の意味はありません。
(複式簿記に苦労して、白色申告や青色/簡易簿記に比べていくらお得？)

税務署に相談行く時間ないんだけど？

国税局の電話相談センターを使おう！僕もわからないところがある時はいつも使ってます。

どの勘定科目を使えばいいか分からないっス

勘定科目に厳密な決まりはないので、悩んだら家計簿みたいに自分で決めたらOK。例えば、本の購入費は「新聞図書費」でもいいし、「書籍代」でもいいんです。あまり深く考えずに分かりやすければよいです。（売掛金、買掛金などだいたい決まってるものもあります）

レシートや領収書はどう保存すればよい？

レシートやカード明細は封筒にまとめてぶち込んでおけばOK。7年間保存する必要があります。2017年からスマホで撮って記録できるようになりますが、撮影後に税理士などの監査が必要なので小規模事業者にとっては逆に面倒だと思います。封筒で保存するのが簡単です。
(参考:領収書をスマホ撮影可能になるけど、撮影後すぐに破棄できない)

確定申告する時に保存してた領収書を提出するの？

しません。確定申告時は紙に売上や経費など必要事項を記入するだけ。領収書は税務署から税務調査があった時に証拠としてみせるために保存する必要があるんです。統計では個人事業主が3%、会社が5%ぐらいの確率で税務調査を受けるらしいですが、もちろん規模によって確率も変わると思います。
(参考:個人事業主にも税務調査は来る！)

事業専用のクレジットカード、銀行口座が必要？

事業規模が小さい時は、会社専用のカードや口座がなかなか作れないし逆に面倒だったりします。その場合、個人で使っているカードや銀行口座を事業と共有してもOK。カードの明細は個人の支出が混ざっててもよいから保存しときましょう。僕はネットで落としてPCに保存してます。

青色申告(複式簿記)65万円控除って65万お得なの？

違います。65万円お得なんじゃなくて、簡単にいうと65万円分の経費を無条件でつけてよいよという意味です。だから、65万円もお得にはなりません。赤字の時や所得が低い時にやっても特に意味はありません。面倒な時間を使いたくない人は青色(簡易簿記)が手間とメリット考えるとオススメです。これがわかると専門家や会計ソフトの需要が減るので、青色申告の本にはあまり書いてないのです。

青色申告(複式簿記)でやりたい！

その場合は会計ソフトで貸借対照表、損益計算書などを作成するのがオススメです。僕はTaxnote使ってアプリで帳簿を入力した後、アプリから弥生会計に取り込める形式で仕訳帳データを出力し、そのデータを青色申告会の人にメールで送っています。個人的にカード明細から自動仕訳するクラウド会計は修正が面倒で断念しましたが、MFクラウドとか最近デザインがリニューアルされて使いやすそうでした。（Taxnoteで入力した帳簿は弥生、freee、MFクラウドに出力可能。）

まだまだわからないことが多すぎる！

確かに最初は謎だらけだし、さっさと本業に集中したいところ。。とりあえず青色(簡易簿記)か白色で申告するのが楽チンでオススメです。

関連記事

確定申告を楽にする合理的な方法のまとめ
フリーランスの確定申告をぶっちゃける １ – 青色と白色、本当の費用対効果
ぶっちゃける ２ – 青色申告/複式簿記の鬼門、カードの仕分け問題
ぶっちゃける ３ – 青色申告/複式簿記の鬼門、個人と事業のカードが同じ場合
ぶっちゃける ４ – 青色申告/複式簿記は簡易簿記に比べていくらお得？
クラウド会計(freee・MFクラウド)とTaxnoteアプリを併用するかどうかの基準

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

最近、「どういうモチベーションでブログ書いているの？」と聞かれたので、そのことについて書いてみる。

まず、僕にとってブログは仕事でもないし、時給いくらでお金がもらえることでもないんです。世の中、人気ブログの人は一握りで、99.9%のブログは毎日ほんのちょびっとの人に読まれるぐらいに落ち着くと思います。もちろん、このブログに広告つけてもお金にならない。

じゃあ、あまり深く考えたことがなかったけど、自分の場合はなんでブログなんて書いているんだろうか。

表面的な２つのメリット

僕は自分の作っているアプリの話をするから、そこからアプリを知ってもらって宣伝になればいいなという淡い期待はあります。ただ、そもそも作っているアプリとブログ読者層がかぶっているわけでもないので、これを第一の理由としてやるには費用対効果が低すぎて、ただのおバカさんとなってしまう。

これを真面目にやろうとしたら、Taxnoteのユーザに関係するようなフリーランス向けの確定申告関連記事を毎日書きまくるのが正解となると思う。freeeとかMFクラウドとかはちゃんとそういう記事を作っている。

もうひとつは、食いっぱぐれた時のセーフティネットとして、こつこつブログ書いとけば、お金に困った時に就職しやすくなるかもというメリットもあります。

しかし、これも当然ながら費用対効果が低すぎます。プログラマとして就職しやすい状態を作りたいなら、プログラミングのことを書きまくるべきだし、Githubで名前を売るとかもっとよい方法がいっぱいある。

なので、上記の２つは一見立派なモチベーションに思えるけど、ブログを続ける理由としては弱い。弱すぎる。自分でもなんとなく、こういうメリットがあるよと今まで周りに言ってたけど、よくよく考えてみると、ブログという面倒な作業を続ける理由としてはまったく真実を語ってないことに気づいた。

なんで書いてるのかと

じゃあ、なんでブログを書いているのかと。

自分の考えを文章にまとめることで整理できるとかよく言われるけど、自分の場合、これも違う気がする。

だって、自分で今後の計画とか今やるべきことを頭の中で整理する時は、テキストエディタ開いて箇条書きに並べながら考えるので十分です。計画とか、ロードマップ的なことを考える時はいつもそうしてます。

わざわざブログで発表するような文章を書いていくのは圧倒的に時間がかかるので、頭を整理したいからブログを書くなんてことは、一見そうなのかなと思った時もあったけど、僕の場合は当てはまらないことに気づいた。

その他に考えたのは、承認欲求を満たせるからというもの。あの記事面白かった！とか言われると嬉しいというもの。これもよく言われているし、そうなのかなと最初は思った。しかし、じっくり考えてみるに、どうも弱い。

なぜかというと、ブログを書いても別にそこまで褒められることはそこまでないし、逆に叩かれるリスクもあるし、みんなの役にたった時に褒められて嬉しいのは間違いないけど、これが一番の理由かというとそうでもない気がする。褒められて嬉しいことをしたいというなら、もっといい方法がある気がする。

そんじゃ、この世界の片隅で僕は生きてますよ的な、自分の存在を記録しておきたいという欲求でしょうか。確かに、自分の存在を後世まで残すには、文章を残すのが一番よいと聞いたことがあるし、そうだとも思う。

でも、ブログって媒体自体が記録メディアとして何十年も存続しやすいものではないし、そういう理由なら思想か哲学か自分の考えでも、そういうものを紙の本で出したほうがいい。なので、これも僕の場合は違う。

楽しい=自己満足

こうなると、楽しいからやってるという単純な結論に達するんだけど、もちろんそれは大前提としてある。自分の思ったことを適当にペチペチと書いて、ドヤ顔で発信して主張するという行為は結構楽しい。それを誰かが読んで感想をくれたら、さらに楽しい。

つまり、結局のところブログを続けているのは自分の経験やら考えたことを、これは世の中に発表する価値があるぜと勝手に思い込み、恥ずかしげもなくドヤ顔で発信するという行為が楽しいからという単純な結論に達してしまった。

「ブログは自分の思考を整理できるし、ビジネスにも役立つからいい！」とかなんとなく信じてたけど、実のところ、その効果は大したことなくてほとんどは自己満足だったという衝撃の事実。

いや、さすがにそれだけってことはないはずで、よく考えてみると、僕の場合はブログを書くのは単純に楽しいに加えて、「いいことがある」という重要な要素もあります。

で、そのいいことってなんだろうと考えると、不特定多数に「自己紹介ができる」というのがとても重要なのではと思った。それも、単純な自己紹介ではなくて、結構深めの自己紹介ができるのが大切なところ。

そして、これは仕事にも役立つし、単純に楽しいことがたくさん起こる可能性が高まる。

深めの自己紹介ができる

自己紹介なんて適当にAboutMeみたいなWebサイト作って、写真貼り付けて、プロフィール書いとればそれでええじゃろと思うかもしれないけど、ブログで自分の趣味やら、考えたことやらを書くのとは全然違う。

その人の経歴やスキルは履歴書で知ることができるけど、その人の考え方や、経験を通して思ったことは文章でしか伝えられない。

その人独自の経験やら、情熱のあることが書かれている文章を読むと、ある意味、その人と飲み会で横に座って１時間ほど喋るよりもわかることも多い。もちろん、直接会った時しか話せないようなことも多いけど、それは凄く時間がかかる。

勉強会で発表した人なら分かると思うけど、自分が発表していたら、そのあとの懇談会で他の人とコミュニケーションする時にすごく楽なんですよ。すでに自分の自己紹介や、やってることなどをある程度聞いてもらってるから、自分と同じ趣向の人があっちから話しかけにきてくれたりする。

とあるiOSの勉強会で発表した時の例でいうと、発表の最初に「どうも、こんにちは。個人でアプリ作ってる梅本と申します。こんなアプリ作ってます。ちなみに、僕は最近フットサルとカートにハマっています。」とこんな自己紹介をしたんですね。

そしたら、その後の懇談会で@tomzohさんと話す機会があって、その後に御殿場のカートの耐久レースに誘ってもらい、これがまた最高に面白かった。

この勉強会は50人以上はいたから、自分が発表してなかったら、この出会いのマッチング率は大きく下がっていたかと思う。

もちろんこんなよい偶然はたまにしかないんだけど、ブログを書いていると不特定多数にもっともっと深めの自己紹介を発信していることになります。そして、どこかの誰かがたまたま読んでくれたおかげでこの種のよい偶然が起こる発生率がすごく高まる。書いてなかったら０パーセントに近い。

その種を常にまいておくことになって、普段は別になにも起こらないんだけど、ある時、どかんと良いことが起きて、それを振り返ってみると相手が自分の書いたブログを読んでくれてたのがきっかけだったりする。

このブログがきっかけで、サンフランシスコを案内してもらったり、他のエンジニアの人と仲良くなれたり、面白いスタートアップのクローズドイベント読んでもらったり、アプリのユーザが僕の開発方針やらデザイン方針をやたら理解してくれたりと、いろいろとよいことが起きてきた。

たまにしか発生しないんだけど、そのたまにのイベントが物凄く大きい。よいブラックスワンってやつです。こう考えると、最終的にビジネスにも役立つことも多いかも。

こういうことがわかると、たまたま読んでくれた人にどれだけ刺さるかのほうが一時的なPV数よりも重要になってくる。読んでもらった人に、この考えは面白いなとか、この話は面白かったとか思ってもらうのが大事なので、カワイイ猫の動画をアップしてたくさん人が来てもあまり意味がない。

というわけで、自分の場合、こういう理由でやってたのかとわかれば、長期的な視点で、こつこつと、あまり焦らず、たまに誰かに刺さる記事が書けたらいいなぐらいで、適当に続けるのがよいなと思った。

自分の場合はこうなんじゃないかというのがなんとなくわかったけど、他の人がブログ書いている理由も千差万別だろうと思う。たまに、普段好きで続けていることを、なんでこれやってるんだろうと考えてみるのもなかなかいいかも。

なんでアプリ作ってるんだろうとか、なんでこういう漫画が好きなんだろうとか。人に説明できるぐらい考えてみると、自分の好みとか趣向がよくわかるかも。まあ、好きは好きなんだよっていう結論にすぐ達して進まない場合が多そうだけど。

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

僕はアプリを作っている時、小さなことは後回しにしながら作ることを意識しています。これは、数年前からずっと意識しているけど、常に頭の中で何回も自分に言い聞かせながら作らないと、ついつい忘れてしまう。

いや、忘れている感覚とは違うかもしれない。小さなことなのに、実際にやっている最中には、「これは細かい事だけどとても重要なことなんだ」と勝手に思い込む力が働いてくるんです。これは、人間たるもの、現在やっている作業は大切なんだというバイアスがかかるからだと思う。

でも、しばらく時間がたった後になると、「あれ、なんであんな小さなことにこだわろうとしていたんだろう。。今振り返ると、別にそこまで時間かけなくてもいいや。。」と振り返って思うことが多い。

しかし、これ難しいんですよ。しばらく時間がたって冷静になるとできるんだけど、その時は難しい。

しばらく時間がたつと、その時には考えてなかったいろいろな情報や視点を織り込んで、より客観的に判断ができるようになり、それは今、時間をかける価値があるかどうかの判断基準の精度が高くなる。でも、やっている最中は情報量も少ないし、視野も狭まっているから難しい。

じゃあ、どうすれば、小さな事を後回しにして、重要なことを優先しながら仕事を進めていけるんでしょうか。

古典的なテクニックとしては、時間制限を設けるというものがあります。時間がない状況に放り込まれると、重要な事はなにかを絶対に考えないといけない。津波が家に迫ってきたと考えてみるとわかりやすい。10時間後くるのか、1時間後にくるのか、10分後にくるのかで、どれを優先するかが変わってくる。

しかし、しかしですよ。これ、頭の中でわかっていても、実際の作業中はやっぱり、「いや、これは小さな事に見えるけど、とても大切なことなんだ。後からじゃダメなんだ！」とついつい考える力が働いてしまう。

最近、Taxnoteのアンドロイド版を作ってるんだけど、こういう場面が多々あります。後から考えると、なんでこんなことにこだわったり、悩んでたんだろうなという場面が。もっとパパッとすっ飛ばして進めていけばよかったと。

後回しでよいところはどんどん後回しにして、重要で外せない部分、今やっておいたほうがいいところからやるように常に意識しているのにそうなってしまう。わかっていても、人間の認知機能として、今やっていること、少しでも手を出したことは重要だと無意識に考えちゃう。

これは、一度でも自分が所持したものには愛着ができて、客観的な評価よりその価値を高くもってしまう心理と同じことが起きているのだと思う。認知心理学では所有効果というらしい。

そんじゃ、どうやってこの、人間本来が持っている認知心理の罠にかからないように、効率よく開発を進めていけばいいんでしょうか。これは自分の脳みそが騙されていると常に意識するしかないんだけど、それだけでは心もとないので補強する理屈を考えてみた。

この時、重要な考え方としては、「判断を保留する理由」という意識を忘れないことなんじゃないかと。

判断を保留する理由

これは後回しでいいなって明らかにわかるケースは簡単なんですよ。単純に飛ばして前に進むだけだから。

難しいのは、後回しにするべきかな、いや、これ今やるべきかな、うーんどうだろ、って悩むケースです。一つの考え方として、現在悩んでいる時点で後回しにしたほうがいいかもしれない。

なぜかというと、現在と、後からでは、判断を下す元になる情報量が圧倒的に違うからです。後からだと、今やってることは重要だというバイアスも消えているし、なにより、新しい情報や知識が追加されるので的確な判断がしやすい。

極端な例でいえば、Taxnoteをアンドロイドに移植する上で、タブバーという概念をどうするか悩んでたんですよ。iOSのようにタブバー作って、ナビゲーションしたいんだけど、アンドロイド公式にそういうライブラリがない。

だから、Githubのオープンソースを使うか悩んでいたんだけど、その一週間後に、Googleが公式サポートライブラリでタブバーのナビゲーションライブラリをリリースしてきた。その時は悩んでいたけど、公式ライブラリがリリースされた時点では、もうこれ使うに決まっているので悩むまでもない。

というわけで、悩んだ時やよくわからない時は判断を保留するメリットは結構でかい。現時点で見えている景色と後から見える景色は全然違うから。逆にいうと、ここは不変だろうとか、ここはまず実装が変わらないであろうというところを探して、まずはそこから手をつけていくのがよいことになる。

アマゾン創業者のジェフベゾスも、ビジネスをする時は10年後も変わらないだろうという基準を常に考えると言ってました。「人間は10年後も商品が速く届いて欲しいだろう」とか、そういう変わらない欲求にフォーカスするんだとか。

重要な部分から小さく始める。これはビジネスでもアプリ開発でも重要な考えなんですが、わかっていても実は実行しにくいというのも意識しておくとよいと思いました。

この記事に関連する話
一番リスクの高い部分から始める
アプリを一気に多言語へ翻訳・ローカライズしたのを若干後悔してる

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

先日、タレブのInequality and Skin in the Gameって記事を読んでた。

内容は不平等とスキンインザゲーム(自らがリスクをとること)についての話。なかなか面白かった。

許容される格差と許容されない格差

人々は、人気スポーツ選手、一流の科学者や芸術家、成功した起業家との格差については不平等だとは感じないが、その人の実力や努力、運などに起因しない格差については怒りを感じる。

つまり、個々人がリスクを取ったことによる格差はよいことで、リスクとリターンがマッチしていない構造での格差は正さないといけない。(親のおかげでリスク取らずに金持ちだとか、目一杯リスクとって成功したら大金稼げて、失敗したら政府に救済される投資銀行など)

健全な社会とは、社会的格差の逆転が許される社会であり、金持ちが貧乏に転落する可能性のある社会である。つまり、不確実性やランダム性が確保されていることが重要。

このへん、ポールグレアムも似たようなことを言ってたのを思い出した。Yコンビネーターは成功する起業家を生み出す組織だから、格差を生み出す組織とも考えられる。でも、起業家の成功はゼロサムゲームではなく、新しい富を生み出すから社会にとっていいことなんだと書いてた。

Economic Inequality

データをたくさん並べる奴らに気をつけろ

実は、この記事で個人的に面白かったのが、データをたくさん並べる奴らに気をつけろというアドバイスです。

Further, people mistake empiricism with flood of data. Just a little bit of significant data is needed when one is right, particularly when it is disconfirmatory empiricism, or counterexamples for rules: only one point is sufficient to show that Black Swans exist.

要約すると、自分の主張の根拠を証明したい時は、何か決定的なデータが少しだけあれば十分である。特に、何かが経験的に間違っていると反証したい時などは、一つの判例があればよい。ということを書いている。

これは元々ポパーの反証主義から来ている考え方。

この記事での一例をあげると、「例えば、ある人が金持ちだと証明するには、その人の預金通帳を見せればそれで十分である。そのあと、豪華な家具、絵画、車などを並び立てる必要はない。」と書いてます。（これを読んだ後に思い浮かんだのが、情報商材やマルチ商法。)

つまり、自分の主張の根拠を示す時は、説得力のあるデータが一つか二つあればよい。あれもこれもとデータをたくさん並び立てるということは、その主張に自信がないことの表れである可能性が高いと。大量のデータをあれもこれもと並びたててくる奴は注意必要しろと。

このアドバイスはなかなかタメになる。逆に考えると、自分の意見を主張する時、一番説得力のあるサポート材料を絞るべきだってことです。転職時の面接、サービスの宣伝、なんにでも応用できる。

ちなみに、ナニワ金融道作者である青木雄二先生は、のちに妻となる女性に、俺は金あるから結婚してくれと一億円の預金通帳を見せながら求婚して大顰蹙を買っていました。(笑)

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。