えぬ億までの道

アラサープログラマが一発当ててn億を得るまでの記録

速さか質か&速さの本当の効用

速さか質か

プロダクトのフェーズにもよるが、普通一発当てる活動では、既にマーケットに最適化しているものをカリカリチューニングするというより、狙いを定め軌道修正し続ける事が多い。

このフェーズにおいては圧倒的に速さが重要である。

プログラマーは往々にしてHowや解決法の質に思考が偏る傾向があるので、そもそもやる必要あるんだっけ?もっと手を抜く方法は?と常に考えて速さを追求したいものである。 

わかっていても最近疎かになっていた観点だったので猛省。

管理画面なくてもDB直接いじればいい。

メール配信は最初はマニュアルでいい。

など。

関連Twitterなど。

 

速さの本当の効用

速さの本当の効用はこれかもしれない。と気づいた事がある。

速さを優先してリリースしてしまったら、もうやらないわけにはいかない。強制力が生まれる。

これが一番の効用なんじゃないか。

ユーザー登録来たから対応せざるを得ない。改善待った無し。

そういうモチベーションどうこう言っていられない強制的に動き続けざるを得ない状況となるのは生産性に大きく貢献する。

改善に時間をかけて精神が淀みモチベーションが落ちる前に、クリティカルな不具合がないのならばテンポよくサクサク進めていく。

意思決定の際はプロダクトについてだけじゃなく自分やチームメンバーへの精神的効用も考えると良いかもしれない。

プログラミングはやっぱり料理に似ている

プログラミングが料理に例えられる話がある。

マイクロソフトのアーキテクト中島聡氏のブログにも、プログラミングを料理に例えた過去記事があり、多くのプログラマーの共感を得ていた。

Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている

 ちなみに、この話を書いていて思ったのだが、プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューするのは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。もちろん、レストランに行く側の立場になってみれば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。 

 

プログラミングと料理が似ている、と考えると他にも多くの共通点を見つける。

素人でも意見を言えるという空気

「もうちょっと塩足した方が良いんじゃない?」

「ちょっとこのボタン分かりにくくない?」

なかなかこの素人でも意見を言えるという空気がイラッとするところでもあり、実際あまり馬鹿にも出来ないフィードバックだったりするのである。

現場での一個一個の判断が全体のクオリティを大きく左右する

コーディングの一行一行が経営判断だ、という話がある位プログラミングの現場での判断がプロダクトの運命を左右することは少なくない。料理においても、現場の一個一個の判断が大きく全体のクオリティを左右するだろう。この点で両者は似ている。

一個のプロダクトが解決出来る課題は一つ

当たり前だが、アイスクリームはアイスクリームであり焼肉にはならない。ソフトウェアも同じく、一つのプロダクトが解決出来る課題は一つである。

にもかかわらず、ソフトウェアにおいては、これはラーメンであり、同時に寿司でもあり、実は焼肉でもあるすごいプロダクトなのである!という意味不明なことを言う人がいるのが料理とプログラミングの違うところ。

冷凍食品やレトルト食品も意外といける

素人や凡夫が一から作ったものより、冷凍食品やレトルトの加工食品を盛り付けるだけで意外といけるという話は、OSSなどのライブラリやらテンプレやらを使ってちゃっちゃと済ませてしまうので実は十分だった、という話に似ている。

 

といったように、プログラミングを料理に例えると面白い。

メタファーを用いることで、俯瞰視点でプログラミングを捉えることができる。

ちなみに私が今まで友人のプログラマに話して一番共感を得たエピソードは、仕様変更についての例えである。

 

カツ丼を作るぞとなってついに完成間近になり「やっぱ親子丼食べたいな、カツを鶏肉に変えるだけでしょ?」ということがプログラミングではままある。

仕様変更である。

「今回はカツ丼にしたからカツ丼食べようね、次の機会に親子丼にしようね」

と捻じ伏せる(ねじ伏せられる関係性を普段から構築しておく)のが重要、という話。

人工知能の勉強より、怪しい石を売りつける能力を身につける

最近ちょいちょいオンラインの人工知能プログラミング講座の広告を見る。

人工知能時代が来る、AIプログラミングするしかねぇ!という時代の潮流を読んでのことと思われる。

これは馬車の時代に自動車の時代が来るからエンジン勉強する!と言っているようなものであり、馬車から自動車への転換が起きた時にフォードやトヨタが根こそぎ持ってったのと同じく本流では、Google,Apple,Facebook,Amazonが全て持っていくと私は考えている。

超一流の研究者と暴力的な計算資源の前に凡夫が太刀打ち出来るわけがない。

結局の所、凡夫の仕事はエンジン設計ではなく組み立て作業員になる。

凡夫はどうすればいいのか?

Google,Apple,Facebook,Amazonの残りカスをチューチューするしかない。

その残りカスをもぎ取るのに必要なのは、机の上のお勉強より対人スキル、ポジショニングなどといったペテン師のようなスキルであり、怪しい石を売りつける能力、占い師のような能力の重要性が更に増していく。

人工知能勉強するしかねぇ!とホッとしていると大局を見失い一生組み立て作業員である。

「先進的プログラマが微妙技術を勧める」のに吐き気を催さない具体的な方法

「先進的プログラマが微妙技術を勧めるという吐き気を催す邪悪」という記事がはてぶホットエントリーに出てきていた。

この記事では、はてぶテクノロジー分野でバズる最新技術に関する記事について、それに飛びつきその技術を学習するリスクについて以下のように語っている。

意識高いのをこじらせてどこで採用されているか知らないような技術に手を出すとあっという間に時間ロスを起こす。

 

ただはてブのテクノロジー記事でバズるようなトピックを書くプログラマというのは、能力が高いので技術が廃れてもさっさと次に移って、新しい技術もサクッと身につけるスキルを持ったりするので、デファクトを取れなかった技術を使った経験も懐かしい思い出のように語れたりするから腹立たしい。

 

僕のように平凡な能力しかないプログラマや、勉強する時間のなくなったエンジニアが選択を間違えると人生が左右されると思う。

www.byosoku100.com

 

耳の痛い話で、私も過去にはChefやAngularなど、今は全く使っていない技術の学習に時間を費やしてきた。本当に無駄だったと思う。

この問題に関しての対策は2つしかない。

  1. 無闇に飛びつかず出来るだけ選択を最適化する
  2. 「僕のように平凡な能力しかないプログラマ」を脱するように努力する

1.無闇に飛びつかず出来るだけ選択を最適にすること 

私はあまり”最新”過ぎる技術は避けるようにしている。むしろ世の中の”先進的プログラマ”が地雷原を踏み倒したあとについていくタイプである。多少枯れつつある技術しか追わない。

そもそも最新技術に早くキャッチアップすることのメリットは

  1. その分野の最前線で活躍出来る(発信側になれる、デファクトになった時に他人より既に先を行っている状態になれる、など)
  2. エンジニア的な「新しいもの大好き欲求」を満たせる

などであるが、私の場合どちら1はそもそも個人的な趣向に合わないし、この利益を享受出来る人は本当に一握りだと思う。また、2についてはそういう欲求もあるが、時間コストが無視できないので意図的に抑制している。あくまで私がプログラムを学ぶのはえぬ億を得るためである。こういう軸があるとブレない。ただし、その最新技術で明確なメリットがある(実装コストが大幅に削減できる)などの場合、枯れる前に早めにキャッチアップを試みることもある。

あとは禅問答的な分野も非常に危険である。MVC/MVVM系の話は大体、それはMVVMではない!MV○ではない!と言った禅問答に行き着く。シンプルかつ一貫した思想、枯れたプログラミングパラダイスで書かれていればある程度のリスクは下げられる。たまに箸休め程度に調べて「うんうん、やっとるな」と高みの見物である。

したがって、総じて「最新技術」は大きな流れ、大枠だけ追っておき、時折つまみ食いをする位にしている。つまみ食いの基準は、定量的にはGithubのスターの数、Googleの検索数、採用している企業の数などである。

基準、目的を明確にしておくことが非常に重要。

「あ、新しい!触るぞ!」は危険。凡人がこれをやっても後に何も残らない。

 

2.「僕のように平凡な能力しかないプログラマ」を脱するように努力すること

1の基準に照らし合わせた上でいい塩梅ならば、学習に取り組む。そしてそもそもの学習スピードを上げる必要がある。英語はどう考えても必須。Qiitaを読んでこの人は間違っている!などと言っているのは時間の無駄。公式ドキュメントを読みましょう。その他、効率を上げるには別の記事にまとめています。とにかく公式ドキュメントを読むこと、これが非常に重要。公式ドキュメントの出来が選択の基準にすらなる。公式ドキュメントの出来がいいライブラリ等は息が長くなる。

enubillion.hatenablog.com

 

副業ビジネスの生産性を上げるTipsまとめ

本業のあるなかでえぬ億活動をしているため、効率化は必須である。

効率化のために意識すべきリソースは

  1. 時間
  2. 体力(HP)
  3. 精神力(MP)

の3つである。

この3つを意識することが鉄則。そうすれば自ずとすべきことがわかる。

1.時間

これを捻り出さないと話にならない。

時間を増やすには

  • やるべきことを減らす
  • やらざるを得ないこと(食事、風呂、掃除、家事等)の効率を上げる

しか無い

具体的には

  • 無駄な残業をしない(不要な仕事は安請け合いしない。他人に投げる。断る。なんとなく請け負ってダラダラ残業するのは最悪である。)
  • 食事を効率化する(私は完全食COMPで朝食を1分で終わらせている)

    COMP 完全食

  • 服を選ばなくていいように同じ服を複数買い込む。靴下は全て同じものにする。
  • 乾燥まで全て終わらす洗濯機にする

     

    シャープ ドラム式洗濯乾燥機 10kg ホワイト系 ES-H10B-WR

    シャープ ドラム式洗濯乾燥機 10kg ホワイト系 ES-H10B-WR

     

     

  • 食器を洗わなくて済むように紙皿/割り箸/使い捨てスプーンを使う
  • 人を雇って金で解決する(私は今までアプリのアイコンや紹介動画などのクリエイティブ作成などをクラウドソーシングで作成したが、もっと他のタスクでも使うべきだと考えている)

2.体力(HP)

文字通り身体的な体力のこと。体力が無いと、えぬ億活動の効率やそもそもの作業時間が減る。

最大HPを上げておけば毎日の活動時間が上がる。体力をつけるべきである。これは、こちらの記事で紹介した「掛け算で効いてくるところを効率化する」と同じ考え方である。

enubillion.hatenablog.com

放っておいても体力は付かない。高強度インターバルトレーニング(HIIT)か筋トレがおすすめである。

HIITは高強度・短時間の運動(無酸素運動)を繰り返すトレーニング方法である。youtubeで解説動画を観ながらやろう。一日8分程で終わる。

www.youtube.com

筋トレも良い方法である。

こちらもYoutubeで動画を観るとイメージが湧きやすい。この人は科学的に証明されている効率の良いトレーニングの方法を丁寧に説明しており、非常におすすめである。

www.youtube.com 

筋トレは自分に合うメニューを組んでルーチン化しよう。自重かウエイトか?とこだわり始めるのは時間の無駄。とにかく始め、習慣化することが重要。

3.精神力(MP)

時間と体力が余っていても精神力=やる気が出ないことも多くある。MP自体を増やす方法は自分でも現在試行錯誤中。

「MPを増やす」とは異なるアプローチだが、そもそもやる気に頼らないような仕組みを取り入れるのも有効である。個人的にはルーチン化して粛々とこなすのが向いている。ルーチン化は

  • 作業をする時間を決める(何曜日なら何々)
  • 作業をする場所を決める(会社帰りにどこどこのカフェ閉店まで作業する)

といったやり方にしている。個人的には実装は頭を使うので腰が重くなることが多い。どうしても気が乗らない時は

  • とりあえず残りTODOを洗い出すだけやってみる
  • 実装ではない簡単な検討だけやってみる(例えば、ライブラリ選定や、ざっくりとした構成だけ考えるなど)
  • 昨日の実装のテスト、検証をやってみる。リファクタリングしてみる

その他、

  • あえて途中までやって終わらす。こうすることで中途半端なので気持ち悪く次の日再開のモチベーションになる。
  • 友達相手に大風呂敷を広げる。やらざるを得なくなる。

 などなどを行っている。

 

なにかオススメの方法あればコメントで教えてください。

生産性の高いプログラマーの特徴

生産性の高いプログラマーの特徴

問題を言語化する

まず問題を言語化する。

思考は幅優先探索

先に大きな方針を決める。ダメそうなら深みにハマる前に他の代替案を考える。例えば、ライブラリの挙動が想定通りでない時、どうにかして動かそうとするよりそもそもそのライブラリを捨てて別のライブラリを使うことを検討するなど。

あまりにハマるようであれば、そもそもその機能は捨てる、という判断もありうる。

公式ドキュメント,GithubリポジトリのIssueを読む

公式ドキュメントを見るのがまず最初にやるべきこと。その際、バージョンをしっかり確認すること。公式ドキュメントが充実しているかどうかはライブラリ選定の判断基準の一つになる。

英語で検索する

日本語で検索し、訳のわからないブログの記事を理解もせずコピペするプログラマーがいるが、最悪である。量、それに伴う質の観点から、英語で検索する以外ない。

仮説と事実分ける

何を想定していて何が事実なのかはっきりさせておく。そもそもの前提から間違えている事がある。

検証はメモを取りながら一個の事だけをやる

原因の究明や挙動の確認に検証を行うことが多いと思うが、一気に複数のことはやらない。仮説検証のパラメータは1個にする。「で、なんだっけ?」とならないようにメモを取る。

掛け算で効いてくるプロセスを最速の環境にしておく

hot loading、AndroidならInstant Runなどを駆使して毎度のビルド等は高速化しておく。キーボードショートカット、ツール、IDEリファクタリング機能など、掛け算で効いてくるところには最初に学習/構築コストを払って整備しておく。

コードを読む時はhow/what/whyの観点に注意する

問題の解決には、どう実装されているか(how)より何をしているのか(what)のみで十分なことも多い。これは関数の実装ではなく関数の呼ばれ方でわかる。全体像を把握し、何をしているのかを把握し、最後に必要ならどう実装されてるかを読み解く。なぜこのような実装になっているのか(why)はコードではなくコメントやドキュメントを参照する。

一旦放置する

30分以上ハマっている場合、一旦放置する。戻ってくるor次の日にすぐに解決することが非常に多い。ハマっている状態だとなかなか出来ない行動だが、非常に有用なテクニック。

効率よく実装を行う方法

本業がある中、限られた時間でえぬ億を狙うには圧倒的に時間対効率を上げる必要がある。

効率をあげるには2つの方法しか存在しない

  1. やることを減らす
  2. やるスピードを上げる

常にこの2つを意識することが非常に重要。

各々気をつけるべきポイントは 

1.やることを減らす

そもそも外れそうなサービス/アプリは作らない。事前にマネタイズ出来るか検証しておく必要がある。その検証もとことん作業を削ぎ落とし最低限にする。LPを作り、広告を回しCPAを計測する。ダメなものはさっさと諦める。

機能を削ぎ落とす、実装せずに楽できる方法を考える(ライブラリ、そもそも作らない、サービスイン時は運用でカバー等)

検証の方法は『リーンスタートアップ』、CPAなどの考え方は『グロースハックの教本』が参考になる。

リーン・スタートアップ

リーン・スタートアップ

 

2.やるスピードを上げる

何の技術要素(プラットフォーム、フレームワーク、ライブラリ等)を選ぶかは生産性に大きく関わるので常に気をつける。

基本的には既に馴染んでいる、多く使われている枯れた技術で、一貫したアーキテクチャ思想で、シンプルに実装するのが良い。

エンジニアならば、触ってみたい新しい技術やプログラミングパラダイムがあるとは思うが、往々にして想定以上の学習コストを払うことになる。一方で今後スタンダードになると思われる新しい技術要素ならば、モチベーションが維持できる、今後のプロダクト開発に役立つ等のメリットが考えられる為トータルでプラスになり、選択肢になりうる。

技術要素の選択以外に、デバッグを高速化するテクニックがあるが、それは別途まとめる。