うめのんブログ

Page 2 of 21

リモートのエンジニアが働きやすくなるにはどうしたらええやろか

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ゆるくお願いする

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

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

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

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

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

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

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

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

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

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

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

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

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


*確定申告を楽にするTaxnoteなど作ってます。自己紹介はこちら。プログラマもゆる募



弥生会計・freee・MFクラウド対応、確定申告を楽にするTaxnoteのAndroid版をリリース

こんにちは。去年から作ってた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など作ってます。自己紹介はこちら。プログラマもゆる募



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

フリーランサーになった人、飲食店を開業した人、起業した人など、いろいろな人がTaxnoteを使ってくれてますが、確定申告を初めてする人からのよくある質問をまとめてみます。

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

赤字だったらしなくていいけど、青色申告したら赤字を3年繰り越せるからお得だよ!赤字の時こそちゃんと経費をつけておかないと損です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

確かに最初は謎だらけだし、さっさと本業に集中したいところ。。とりあえず青色(簡易簿記)か白色で申告するのが楽チンでオススメです。Taxnoteはアプリ内にお問い合わせボタンがあるので、分からない部分はメッセージしてもらえれば。

関連記事

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


*確定申告を楽にするTaxnoteなど作ってます。自己紹介はこちら。プログラマもゆる募



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

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

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

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

表面的な2つのメリット

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

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

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

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

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

なんで書いてるのかと

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

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

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

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

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

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

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

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

楽しい=自己満足

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

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

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

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

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

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

深めの自己紹介ができる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


*確定申告を楽にするTaxnoteなど作ってます。自己紹介はこちら。プログラマもゆる募



小さなことを後回しにするのは意外と難しい

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

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

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

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

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

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

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

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

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

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

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

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

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

判断を保留する理由

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

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

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

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

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

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

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

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


この記事に関連する話

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


*確定申告を楽にするTaxnoteなど作ってます。自己紹介はこちら。プログラマもゆる募



データを並べる奴らに気をつけろ

先日、タレブの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.

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

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

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

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

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

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


*確定申告を楽にするTaxnoteなど作ってます。自己紹介はこちら。プログラマもゆる募



うんち記録アプリ・ウンログのテキストライティングが素晴らしくて勉強になる

先日、「ウンログ」という、うんちを記録していくアプリを教えてもらったんだけど、このアプリに出てくるテキストライティングのレベルが死ぬほど高くて、めちゃくちゃ勉強になりました。

以前から、テキストライティングこそ最も重要なUIであると考えてたんだけど、ここまで出来のいいアプリには出会ったことがなかった。出来のよいアプリを触ってみるのは、どんな参考書を読むよりも短時間でたくさんのことが学べる。

以前、愛着のわくプロダクトを作るにはという記事を書いたけど、その当時は特にアプリで例になるものがなかった。でも、今なら、迷わずウンログを紹介すると思う。

ウンログってどんなアプリ?

ウンログは自分のうんちの記録をつけていくアプリです。え、うんちの写真とか記録すんの?イヤすぎると思ったかたが間違いなくいると思うけど、ここはよく考えられていて、かわいいうんちのイラストを選んでタップするだけで記録できるように作られている。

うんちの形は、かちかち、ぶりぶり、ほそほそなどから選べて、色も、カレー色、かつおぶし色、チョコレート色などから選択、大きさは、並盛り、大盛り、チョモランマなどを選択する。

この選択画面を選ぶ時に、自動的にかわいいうんちのキャラの形や色が変わるわけです。このネーミングセンスが抜群にいいし、イラストもかわいい!うんちを記録するアプリなのに、かわいいというアンビバレントな体験!

そして、記録した後は、その大きさとか、調子によってポイントがもらえる。このポイントの単位はボトンです。今日は70ボトン!とか。ここでも、ネーミングセンスが光る。

しばらくうんちの記録つけてなかったら、「大丈夫?溜め込んでない?(スライドでうん!)」とか通知が届くんだけど、この時のメッセージも、ウンログが私のこと心配してくれてる!と胸きゅんらしいです。

使ってて楽しいアプリのお手本

実際、前回のうんちから何時間出てないとか、タイムラインでうんちが出た時間を時系列で表示してくれたりと実用的で素晴らしいアプリではあるんですが、この使ってて楽しい、気持ちいい、かわいいという要素がここまで洗練されているアプリは本当に見たことがない。

とにかく、このアプリは全てのテキストライティングにおいてセンスが光りまくっている。うんちの記録をつけた後は、「すっきり〜」というメッセージとともに、すっきりした顔のうんちのイラストが出てくるし、しばらく記録してないでアプリを開くと、「そろそろ出る?」というドヤ顔のうんちのイラストが出てくる。

TapbotというTweetBotとか作っている有名なアプリ制作会社も、使ってて楽しいフィーリングを追求するアプリ制作で有名なんだけど、正直ウンログは今まで見てきたアプリの中でもダントツで衝撃を受けた。

あまりに感動したので、ウンログの公式サイトに飛んだのだけど、公式サイトで書かれているテキストライティングもいちいちセンスが光って面白い。ミッションは「いいうんちを増やす」。ランディングページのキャッチコピーは「いいうんち、いい人生。」です。秀逸すぎる。

今までアプリ作る時は、ビジュアルデザイン、UIデザイン、テキストライティング、と3つのインターフェイスの要素を意識してはいたんだけど、まだまだ修行が足りませんでした。これ作ってる人たちはタダモノじゃないと思う。

ビジネスモデルは腸内フローラ検査との提携とか、ビッグデータを集計しての関連商品レコメンド、健康関連の研究データに活用など、いろいろあるみたいだけど、めちゃくちゃ応援したい。

ウンログのイラストがかわいすぎるのでLineスタンプも購入させていただきました。
ウンログのホームページはこちら。

*参考記事
「リジェクトしないでくれ!」Apple米国本社に乗り込んだ。うんちに人生をかけた男が挑戦するアプリ「ウンログ」


*確定申告を楽にするTaxnoteなど作ってます。自己紹介はこちら。プログラマもゆる募



昔から有名な本が現代でも読む価値あるかはどう見極めたらいいんでしょうね

以前から聞いてるエンジニア向けのPodcast Rebuildfmの169回が神回だった。

なんと、このPodcastでは、ゲストの@omoさんが「達人プログラマー」やら「リファクタリング」やら「デザインパターン」など、エンジニア向けの有名な本をことごとくディスるという、とても勇気あるテーマに挑戦していまして、それがかなり納得のいく話でめちゃくちゃ面白かった。

*リファクタリングに関して指摘を受けたので修正させてもらいます。僕の曖昧な記憶で重要な部分をさらっと書いてしまったのを反省。。

ちなみに、僕もプログラミング二年目ぐらいの時に、これらの本をざっと読んだ気がするんだけど、もう内容はほとんど忘れてました。

ポッドキャストの内容としては、当時は有効だった手法も、現代のスタンダードからすると時代遅れの手法が多かったり、現代では当たり前になってることをドヤ顔で書かれているだけなので、そういうエンジニア向けの古い古典本を有難がって新人に勧めるのはいかがなものか。という内容です。

もちろん、omoさんは頭からこれらの有名な本をけなしているわけではなく、執筆当時の時代性も説明し、なぜこれが当時は有効だったかも具体的に解説しながらも、現代ではあまり意味のない内容になっている部分をビシバシと切っていって面白い。

これこれこういう理由で、この内容はすでに古くなっているから現代ではあまり意味ないですねと説明しながら、最後に付け加えるのが、「まあ、いい本なんですけどね。」とか、「まあ、(技術が進んだということで)いい話なんですけどね。」というフォローが笑った。

このPodcastは単純に内容が面白かったんだけど、個人的にツボだったのは、今でも評価の高い昔の本(いわゆる古典)の中から、現代でも読む価値のあるものと、ないものとを見極める方法はなんだろうかと考えるきっかけになったからです。

でも、これって簡単なようで難しいからどうしたらいいんでしょうね。

読み続けられたものは生き残ってきたもの

基本的な考え方として、時間がたっても評価が落ちていない本は内容の質が高い可能性が高い。ずっと生き残ってきたという意味で。

ノンフィクションなら、いろいろな人の反証に耐えてこないとダメだし、フィクションなら、現代の人にも読み続けられないといけない。

今読むと、内容が古くなっているもの

変化の早いエンジニア業界の本だと、先進的なノウハウがどんどん陳腐化するのは常に下克上の世の中を作りだしているので、面白くもあり、厳しい部分でもあります。

科学とか技術の分野では、技術革新がどんどん起こるから、以前の常識が今では当てはまらないことが多い。

例えば、最近の車の塗装技術は昔と比べて圧倒的に優れているから、ワックスなんて半年に一回で十分すぎるらしい。毎月かけてたら、元の塗装にダメージがいって逆効果だとか。この意味では、「こまめにワックスかけて車を大切にしよう」っていう、一般的に伝えられてきている昔の常識と現実が乖離している。

これは、ワックスのメーカーと自動車雑誌のパワーバランスとかの関係で、真実が浸透しない理由もあるらしいが。この場合、昔の通説が現代でも当たり前だとまだ信じられているけれど、現実には違うというケースで、事情を知っている人じゃないと見極めにくい。

現代でも通用しているケース

「風の谷のナウシカ」なんて、何年もテレビで再放送され続けていて、なおかつ視聴率も高い。これは、明らかに時代を超えて楽しまれていつつ、現代でも通用している証拠になると思う。

正直、僕もナウシカは何回も楽しめる。今見たとしても、「ああ、当時はこのシーン画期的だったけど、今見るとたいしたことないなあ」とかはあまり思わず、普通に楽しめる。

映画が面白いかどうかというのは、その人が見て判断することだからあまり専門知識もいらず、未だに視聴率がとれているということは、現代でも十分通用しているというハッキリとして証明にもなる。

明確な尺度がハッキリしていて判断も簡単であれば、昔から人気あるもので現代にも通用するというものは判断しやすい。そういう意味で、小説、漫画、音楽などはわかりやすいのかも。

歴史本となった割合

当時は賞賛された内容でも、現代になって読んでみると70%は内容が古くて実践では使えないという本があったとする。この場合、この本は、70%の内容が当時の時代背景を知ることができる歴史的価値を持っていて、30%は現代でも役に立つ知識ということになる。

難しいのが、この割合は時間がたつごとに常に変化していくだろうから、この昔から有名で崇められている本の、それぞれの割合はどれぐらいかっていうのがなかなか分かりにくい。最近読んで、詳しく説明してくれる人が出てこない限り、よく分からない。

ちなみに、時がたっても陳腐化しないことにこそ価値があると言っているわけでもないのです。僕自身、アプリ開発で役立つサービスTOP10とかは、数年後には参考にはならないだろうけど、今は価値があるから書こうと思って書いたわけだし。

この話は特にオチがあるわけでもないんだけど、最低限できることといえば、昔自分が読んでよかったお気に入りの本でも、誰かに薦める時は、今読んでその人に役立つかとか、その人が楽しめるかとか、ちょっとだけ考えてから勧めたほうがいいなってことぐらいですかね。


*確定申告を楽にするTaxnoteなど作ってます。自己紹介はこちら。プログラマもゆる募



« Older posts Newer posts »

Copyright © 2017 うめのんブログ

Theme by Anders NorenUp ↑