Life is Really Short, Have Your Life!!

ござ先輩の主に技術的なメモ

自分で敷いたレールを歩みたいよねっていう話

この記述、すごくわかる。僕もそう。だから独立した。同じような考えの人っているもんだ。

「自分たちのサービスで勝負したい」という想いがどうしても強く、既に誰かが成功させたビジネスに乗っかって、更に成功を拡大するためにプログラマーとして働くという選択肢を取ることができなかったという理由です。

東京の会社を退職して山形に移住することにしました - セカイノカタチ

わかる・・・わかるよ・・・ 多分同じ感覚だ。商売がしたいんだよね、仕事がしたいのではなく。仮にGoogleから年俸で1000万のオファーがあっても、給料の1000万にはさしたる興味がない。でも、自分で作ったサービスなりシステムなりで100万円売り上げることに、やりがいを覚えてしまう。10分の1しかなくてもね。そういうものなのだ。

僕の場合は自分のサービスで勝負したいの他に、独立を志した理由があった。顧客を作る努力をしようと思ったから。今36歳になっちゃったんだけど、アラフォーになったら転職は当然難しくなる(一般的にね)。独立したって同じように厳しい。質は違えど、どっちの道を選んでも厳しいわけ。どちらかがえらい簡単なことはない。職につく努力をするか、自分の顧客を作る努力をするか。どっちがしたいと考えて、後者を選びました。顧客を作る努力のほうが楽しいもん。

ご武運をお祈りします。お互い頑張りましょう!

おっさんの説教という最凶のバズ

レールに乗った人生は嫌だの石田さんの炎上っぷりをみて、改めて感じたこと。おっさんが説教したくなる内容ってはてブを中心に火がついてバズる。すごく。

イケハヤさんも燃え上がったのは若くてソコソコ頭が回るのに全く明後日の方向を向いたコンテンツを量産していたから、というのが自分の中で腑に落ちる。「いやその理屈はおかしいけど、若気の至り臭すごい。まだ間に合う、まだ引き返せる。言わずにはいられない。」というギリギリのバランスがあった気がする。今は単なるおっさんになってしまったから、誰も説教しようともしなくなった。石田さんは今が旬だけど、1年後には燃料が切れる。ろうそくのようなもので、どんどんすり減っていく。継ぎ足すことはできない。

高知のおっさん、ほんまにどうするんだろ。サロンとnoteは急上昇のあと急降下、ブログは適当に書き散らかすのみ。謎の農地を購入して公園の砂場遊びに明け暮れている。彼の言うことに耳を貸す人が減ったから商品価値も減っている。思いつきで生きているから仕事を請けることの意味もわかっていない。打つ手が無いので遠目には四面楚歌に見える。老害として再ブレイクするしか無いんじゃないかな。キャラしかコンテンツに出来ないのなら時間の問題だ。

ラーメンが苦手

どうしても食べ飽きてしまう。サッポロ一番塩ラーメンだけは好き。

温かいうどんや、リンガーハットのちゃんぽんとかは好きなのに。ラーメンだけが苦手。

恐らく脂が原因だと思う。ズドーンと脂が前に来るのが苦手。二郎系はもう色々無理。スープも味付けが濃いラーメンが多い。薄味で整えるのは難しいし食った気がしない人が多いだろうから、薄味のスープのラーメンって作ってもリピーター来ないんだろうな。

あと、麺。ラーメンって麺の種類がすごく豊富だけど、麺がうまくないと食べ飽きるんじゃないかなぁ。醤油ラーメンも醤油の味を感じてしまうと飽きてしまう。

ラーメン苦手だけど、実はラーメンってすげー作るのが難しい一品なんじゃないでしょうか。

筋書きを書くこと

どうもこれが一番好きみたいだ。ストーリーを書くといってもいいか。

プログラミングが好きなのも、プログラミングで1つの筋書きを書くから。

文章の読み書きが好きなのも、筋書きを考えるのが好きだから。

やきうが好きなのは、そこに筋書きがないから。これだ。

おれが野球を愛する理由はここにあったな。

仕様書策定の良いツールはないものか

やっぱりOfficeソフトを使っている会社さんが多く、画面設計書なんかはPowerPointで書かれていたりします。

当然のことなんですけど、「この画面項目はDBのどのテーブルのどのカラムに該当するか」がわからないとプログラムを書くことが出来ません。そういう情報をパワポに盛り込んでしまうと、DB側で変更があった時に差分が取れなくなります。取れなくなるというか、手で修正する必要があります。逆も然りで、ER図に変更があった場合は設計書に反映しないといけない。

例えばだけど、ERに変更があったらそこからテーブル作っちゃって、画面設計書の項目をマッピングする時に作ったテーブルのカラムをプルダウン(オートコンプリート)で選んでいくみたいなレベルまで徹底している現場って…あるんでしょうか?

こういう不整合が重なると、仕様書が死ぬと思うんだけど...

Markdownで書けばいいじゃんっていう説もあるようですが、Markdownって複数の文書間の整合性を取れるもんじゃないですよねぇ...

古いiPhone/iPad に対応する時はビットコードに気をつけよう

小ネタです。

Deployment Targetを8.0にしているにもかかわらず、iPhoneだと5s以上でないとApp Storeでインストール出来ないとお客さんから連絡がありました。調べてみると、ビットコードが有効になっているとそのような現象が起きるとのこと。64bitに不対応なプロセッサのせいだよ、と。

ja.stackoverflow.com

というわけで、下記の2つを注意して再アーカイブ

  • Build Phaseの Enable bit codeをFalseに。
  • Archiveをサブミットする時に、include bit code のチェックを外す。

これでApp Storeに出した所、iPhone5s以上の縛りが無くなりましたー

ヒットの延長線上がホームランと思った話

ひとり社長の経営の話です。

ある程度は前職でわかっていたことなのですが、自分以外誰もいない状況で仕事をとってくる立場になると、改めて感じることがいろいろあります。自分なりにある程度手応えがあるお仕事の引き合いがあったとして、自分にとってベストな状態をホームランとすると、実際は諸事情があってヒットに落ち着くことが多い。これは僕が不定形な成果物を仕事にしているからだと思う。

例えばECの売上を伸ばしたいという課題に対して、自分が描いているシナリオ通りに行くと200万の仕事になるとする。でも、実際にはそんな規模にならない。尾ひれはひれがついちゃうんだよね。自分にとって都合の良い展開をどうしても期待してしまう。ホームランになると、相手が100%こっちの都合で動いてくれる前提のシナリオになってしまう。相手から頼みたいということになれば、話は違ってくるけど。

時には犠牲バントもするし、見逃しの三振になることもあるけど、打席にたつと色んなことが経験できて面白いです。最悪は見逃しの三振。バットを振って見ないと何もわからない。

広角にヒットが打てる(仕事の守備範囲が広い)のが僕の最大の強みなので、IT業界のスピードスター目指して日夜修業の日々であります。