プログラミング

React Nativeという生き方

4/19でとうとうエンジニア二年目が終わってしまうので、
区切りとして、今後どうやって生きていくのかを考えたのでまとめておく。

前提として、僕はプログラミングスキルを持っているし、
今後もスキルを使い伸ばし続けるにも関わらず、「エンジニアをやめた」。

続きを読む

初めて受託開発をして学んだこと

めちゃくちゃ久しぶりの更新になってしまった。

近況は改めて記事にしようと思うが、簡単にいうと、今起業とフリーランスの二足のわらじ状態になっている。

自社はちょうど登記の準備中だが、僕が大変お世話になっている先輩と一緒に勢いで作ることになった。

僕の人生はいつもこんな感じで、計画性は特になく、思いつきとノリと勢いでやってきたので、まあ、会社もそんな感じで作っちゃって丁度よかったのかもしれない。

未来のことなんて分からないし、計画なんて立てようがないのだから、今面白いと思うことだけを一生懸命やるしかないのだ。

今回は人生初の受託開発案件を通して、案件の難易度の割に予想に反していろいろと学びがあったので、書き残そうと思う。

これからフリーランスになるとか、受託開発やろうという人に少しでも参考になれば幸いだ。

概要

受託開発をする目的

  • 受託開発の実績を積むこと

  • 技術的には簡単なフロントだけのページを作ることで、受託開発の体感難易度を計測すること

案件の内容

  • 某企業様のプロダクトのLP作成

  • フロントだけで完結するページ

  • PC版とモバイル版の両方

振り返り(技術面)

よかったこと

  • 構造化が得意なことがコーディング内容に表れ、結果としてメンテナンスがしやすいコードが書けた。

  • cssで理解が曖昧だったもの(positionやアニメーション)について理解を深めることができた

  • 印刷機能やメディアクエリ、フェイスブックタグなど、新しい技術を獲得することができた

悪かったこと

  • 作っていく中で、運用が簡単になるhtmlの構成ルールが自分の中で出来ていったので、最初にコードを書いた部分の手戻りが結構発生した。

振り返り(ビジネス面)

よかったこと

  • 納期を守れた

  • 改善案の提案がいくつか出来た

  • 受託開発の流れを理解することができた

悪かったこと

  • 納期が迫るまで手がつけられず、直前に猛烈に焦って作ることになった→学生のときからの悪い癖だが、自分でやると決めたことであれば、なんだかんだ毎回なんとか出来ているので、あんまり直す必要はないかも

  • 印刷機能などの触れたことのない部分の工数の見積が甘く、スケジュールを圧迫した

    →今後、触れたことのない部分は簡単に調べて工数を把握する

  • psdファイルからコーディングへの落とし込みの部分で、仕様の確認を怠り手戻りが発生した

    →今後は丁寧に確認する

学び

技術面

  • ヘッダーやフッターなどの修正が入った時、ページすべてに修正をかけるのがしんどい。Viewを扱うフレームワークがいかに便利か分かった。

  • cssなどを生のコードで管理するのが面倒だということに気づき、タスクランナーの重要性が分かった(今回はgulpを簡単に導入)

ビジネス面

  • 今回のような誰でもできる仕事は付加価値が小さく、とても収益性が悪い。今後は自分の高度な思考力が活かされる付加価値の高い仕事をする。

  • フリーランスは会社の仕事と違って、一度やってみてできるようになったら、それはもう二度とやらないで次に進むという選択ができるので、新しいスキルを身につける効率がよい。(ただし、それはスキルが足りずに炎上するというリスクと引き換えのメリットでもある)

総括

受託をやっていると、世の中に対して思考する時間が減ってしまいが
ち。

足元のキャッシュを稼ぐことも必要だが、自分のビジネスの優先順位を下げずにコントロールしていきたい。

あと、もはやこれは確信だが、昔から疑問に思っていた、企業が採用広報なんかでよく言う「成長」というやつ。

もしビジネスパーソンとしての成長がしたいなら、自分でやることに勝る成長方法はないと思う。

そんなに人を成長させたいのなら、起業しろって言うべきじゃないだろうか。

【G’s Academy LABコース体験記】180112

年末から年始にかけてチーム開発を行っていたが、
その間一切の更新をサボってしまったため、
もはや何日目か分からない。

一旦、日付対応することにした。

今日はアルゴリズム論最終回。
改めて講師は株式会社キカガクの吉崎さん。

以下は今回Pythonやりながら学んだこと。
箇条書きにて。

コメントの書き方

関数の機能ではなく、引数が何か、アウトプットが何か

# add(a, b)
# input:
# a <- list
# b <- list
# output:
# c <- list
# -----
# example
# a = [1, 2, 3]
# b = [4, 5, 6]
# c = add(a, b)
# c -> [5, 7, 9]

機械学習実装の難しいこと

  • コツは、精度が見えなくても一旦リリースしてしまうこと。
  • 組めるものと使うものは別である
  • 実装でpythonを使ってしまうと、人件費が高くなる
  • (一方Railsは若くて安いエンジニアが雇える)
  • 引き継ぎのコスト
  • 対応策で、Web API部分だけPythonを噛ませたりして、他はRailsを使うとか。
  • 環境構築なんかでスキルセットが必要になるので、大変であることは覚えておくこと。

関数化するタイミング

  • パッと見て分かるときはしない
  • 可読性を失っているときに行う

【G’s Academy LABコース体験記】34日目

先週金曜日の分。

今回もアルゴリズム。
先週金曜日の続きで、引き続き講師は吉崎さん。
Pythonで簡単な関数の復習をいくつかやった後、
ファイル圧縮のアルゴリズムを考える課題をやった。
00000111001111
みたいな0と1の羅列がコンピュータの扱えるファイルの形になるが、
これの規則性を見抜けばもう少し短く書けるよね、という話。
例えば前述の例だと、
0が5つ、1が3つ、0が2つ、1が4つなので、仮に0をa、1をzとすると、
a5z3a2z4
と書けば短くなる。
これを一番短くする方法を考えようというのが今回のお題。
こういうパズル的なのは小学校の算数とかで好きでよくやっていたので、
個人的にはかなり楽しかった。
ちなみに先生の解答がやはり最短で、
自分のコードには普段から気づいてないだけで改善の余地がたくさんあることを思い知らされた。
最近、あまりプログラムの問題を解いていないことに問題を感じているので、
毎日30分でcode warsかpaizaなんかの問題を解いていこうと思う。

【G’s Academy LABコース体験記】32・33日目

今日、PHP選手権(開発の総合コンテスト)の発表だった。

昨日は流石にブログを書く余裕がなかったため、
今日にまとめておく。
結果から言うと、
純粋な入賞こそできなかったものの、
主席講師の山崎先生の賞を獲ることができた。
正直言って、かなり嬉しかった。
前回フロントエンドのみのJS選手権のときは、
企画に時間を掛け過ぎて自滅してしまった。
結果的に、技術力が伸びないという悲劇が起きた。
だが、今回は同じ轍を踏まないように、
企画は前のままで、とにかく作ることにした。
それが功を奏して、
PHPフレームワークのLaravelは使うことに抵抗がないぐらいにはなれた。
フレームワークは早めに使えという先輩の助言は正しかったように思う。
今日からはチーム開発だ。
僕は協調性がないので、
正直不安しかないが、
これから起業するならそれは避けて通れない。
チーム開発のイロハと技術と、
両方学んでいきたい。

【G’s Academy LABコース体験記】31日目

先週すっぽり抜けてしまっていたので一つ近況をお伝えすると、
実は、現在個人開発の総仕上げとも言える、PHP選手権の真っ最中だ。

プロダクトの発表は明後日。

前回のJS選手権のときは、
ビジネスとしての企画にこだわりすぎた結果、
時間がなくなってしまうという問題があった。

今回はその反省を踏まえ、
・企画にこだわらないこと
・プロダクトをひと通り作ること
の二点に重点を置くことにした。

プロダクトとしては、前回と同じ、
書籍のシェアサービスを作る。

ぶっちゃけ、実際のサービスのフローとは、
結構整合性の取れていないものになりそうだが、
ものとしてはよくありそうな構造になるため、
技術的な勉強にはなると踏んでいる。

ちなみに、LaravelというPHPのフレームワークを導入している。

フレームワークの仕組みに慣れるのに時間がかかっていて、
カスタマイズに手間取っているが、早期にフレームワークに触れたのは正解だったと感じている。

それではまた明日。

【G’s Academy LABコース体験記】30日目

前回の更新から随分と期間が空いてしまった。
この一週間ぐらいはPHPとの格闘で、結構忙しかった。

とりあえず最新分を更新する。

今日はアルゴリズム入門ということで、
前からずっと触ってみたかったPythonを使ってアルゴリズムを考える回だった。
講師は吉崎さんという方。

講義内容

Pythonの基本的な文法をひと通りやって、
幾つかの簡単な問題を解くということをやった。

Pythonの感想

pythonを使ってみて感じたことだが、
やはりコードがキレイになることと、
値操作のライブラリが充実していることだ。

まだ基本的な操作しかしていないのに、
配列の抜き出しやソートがJSよりも更に簡単にできて、
かなり好きになった。

個人的に一番面白かったのは、
素数判定でエラトステネスの篩を実装して、
その実行速度が愚直な実装に比べて数百倍以上違ったことだ。

学生の頃に数値解析なんかで勉強したアルゴリズムは、
全てプログラムを使わずにやっていて、
何の役に立つのか全くわからなかったけれど、
こうやって実践で使ってみるとその良さが分かる。

多分、そのうち二分木探索とかバブルソートとか、
基本的なアルゴリズムをやるのだろうけれど、
実行速度の比較が楽しみだ。

Pythonこれからやろうかな

スキマ時間にプラスアルファで
ここの問題をいくつかピックアップしてやってみた。

Pythonの特性からか、
ユークリッドの互除法とか、円周率とか、
中学校で習うちょっと応用寄りの内容が多い。

僕はやっぱりパズルっぽいことが好きみたいで、
この辺の問題を解いているだけで楽しい。

数学が好きな人には分かるだろうが、
応用問題をうんうん唸って考えている感じだ。

今はPHPのフレームワークをやるって決めたのに、
あまりに魅力的な学習コンテンツが目の前に現れてちょっと困った。

【G’s Academy LABコース体験記】24日目

一昨日水曜日の分。

例によって水曜日はもくもく会の日だ。
(自分でやることを決めてひたすらそれを黙々と進める)

今日は前日に引き続き、PHPの欠席分を勉強し、
木曜日提出の課題をやった。

課題はサーバーサイドをちゃんと動かしたフォームを用いた登録。

僕は基本的なコードを、理解した上で何も見ないで書けるようになることに時間を使うことにした。

授業の説明では、コードの使い回しをするときにコピペをしていて、
先生もそれでいいと言っているのだが、
僕はそれはある程度書けるレベルの人がやっていいことだと思う。

クラスメートとも話した事があるが、
新しい技術を学んだときに、
「どうやって動いているか分からないけれど、
とりあえず動いているからOK」
ということはやりたくないし、
やるべきじゃないと思っている。

何の技術も身につかないからだ。

ものごとを深く理解するとは、
その対象物の存在意義や原理原則から理解することが不可欠だ。

じゃないと、対象物の相対的な位置関係がわからず、
他の選択肢との比較が出来ない。

より適切な選択肢を選ぶためには、
こうしたプロセスが必要だ。

PHPを始めてまだ時間が浅い。

目の前の課題の成果で見栄を張ることに囚われず、
ちゃんと自分のゴールに向かって進めていきたい。

【G’s Academy LABコース体験記】23日目

昨日火曜日の分。

今回は久しぶりに、
あんまりプログラミングが関係のない、
ちょっと個人的な内容になる。

午前中は、とあるITベンチャーの社長・役員の方と、
事業提携的な話をしていたため欠席。

午後は午前中の講義の内容を自習していた。
内容はMySQLの基本的な操作だった。

午前中のアポイントでの出来事について今日は書く。

とってもありがたいことに、
なぜか何の実績もスキルもない僕のことを面白いと買ってくださり、
僕が事業を起こすのを、色んな形でサポートしてくださるとのことが決まった。

詳細は全く詰まっていないが、
基本的には僕達にとっては非常にありがたい話だ。

今後は、事業アイディアと、細かい体制を詰めていく予定。
(無論、共同創業者の友人と相談しながら進める)

その中で、社長の方とお話していて、
どうしても気になって聞いたことがあった。

それは、
「なぜ、実績もスキルも何もない僕に期待してくださるのですか?」
ということだった。

正直、理屈に合わない。

僕自身は、自分のことは、
特別駄目だとは思わないけれど、
別に何かに秀でているとも全く思わない。

僕は何事においても、
平均以上にはそこそこ出来るが、
そこから先には行けない。

人生で何をやっても、本当にずっとそうだった。

超平均型の人間なのだ。

強いて秀でている部分を挙げるなら、
何事にもある程度興味が持てることだろうか。

そんな僕は、少なくとも大企業では、
基本的にゴミみたいな評価しか受けたことがなかった。

そんな自分になぜ期待をするのか、分からない。

だが、彼は意外な答えを持っていた。

「リバースエンジニアくんみたいな、
ビジネスとテクノロジー両方に理解があるタイプは、全体を俯瞰できる。
だが、こういうタイプは少ない。」

なるほど。

確かに僕は世界を構造的に眺めることが人より出来る。

これは、浅くてもいろんな領域の知識を、
まんべんなく持っているから出来ることかもしれない。

それで、このタイプが少ない理由は、
「ビジネスが好きな人と、テクノロジーが好きな人の嗜好性が異なるからじゃないかな」
だそう。

確かに。

僕にとっては両方は「構造」という共通点から、
どっちも分析・実験対象として面白いもので、大きな違いは何もなかったが、
一般的には結構別モノなのかもしれない。

更に、最後にとても嬉しい一言をもらった。

「いろんな人を見てきたけれど、
リバースエンジニアくんは成功するタイプだ。
見れば分かる。」

こんな風に、自分が評価されたのは初めてだった。

成功するかどうかは当然これからの僕次第だから、
まだ分からないけれど、
少なくとも彼が僕に期待してくれていることは明確だ。

その一方、僕は今まで、
自分のこうした性質を評価されたことはなかった。

一社目では、僕は先輩にこんなことを言われた。

「お前何もスキルないでしょ?
他の人と比べて出来るのって、
ちょっとプログラミング分かるぐらいじゃん」

二社目でも、似たようなことを言われた。

「何もスキルないから、このままじゃどこにも行けないよ」

僕の平均的な性質は、今までこういう評価だった。

自分では、掛け算をすれば希少価値は高まるとは理屈では分かっていたけれど、
結局何かに秀でられない自分に強いコンプレックスを持っていたし、
どこか自信を持ちきれなかった部分がある。

その意味で、僕は今回の彼の発言で、予感は確信に変わった。

自分は平均的な資質と付き合いながらやっていける。

他人に言われて自信が持てるようでは、
セルフコントロールという意味では三流だが、
それでも、やはり自分がすごいと思った人から評価されるというのは自信につながる。

評価してもらえたことを素直に喜びつつも、
決して今の自分に満足することなく、
引き続きスキルを磨いていこうと思う。

【G’s Academy LABコース体験記】22日目

この前の金曜日の分。

インターネット概論というタイトルのもと、
Webがなぜ遅いのかという話と、
その問題解決としてのnode.jsの話を少し。
講師は、菅原のびすけさん。
まずは通信のざっくりとした性質から。
http通信にもバージョンがあり、現在2.0まで出ているが、
Facebookなどの一部のサービスでしか未だに使われていない。

1.1というよく使われている規格は、
もう15年以上も前に決まった規格であり、
随分時代遅れなのだそうだ。

2.0になって進化した部分は以下の通り。
・通信の基盤のようなものを繋ぎっぱなしにすることで、都度接続していた従来よりも早くなる。
・同時に複数の通信が行える。
・表示させるコンテンツの順序をコントロールできる。

(もしかしたら抜け漏れがあるかも。)

特に重要なのは、体感通信速度の向上。

複数の通信が出来るから早いのは当然だが、
それ以上に表示するコンテンツの順番を、
ユーザーにとって重要な順番に変えることで体感速度が大きく変わることだ。

なるほど。

後は、Node.jsの出現の簡単な背景。

この辺は長くなるし、来週(今週)もまた触れそうなので割愛。

フリーランスの仕事が落ち着いたので、そろそろ本気出す。