正規化されてないテーブルには意味があるはず！
アプリケーション開発するにあたって、データベースの利用は必須になる。
特に、リレーショナルデータベースの利用頻度は半端ない。
使ってないアプリはない！と言ってもいいほど。
リレーショナルデータベースを利用するにあたり、正規化することが正義であり、絶対である！というのが、エンジニア界隈では常識として扱われる。
正規化すると、かぶったデータを管理しなくてよくなるため、メンテナンス性が良い。
僕は、基本はこの方針に賛成ではあるのだが、絶対ではないよな！と考えてる。
正規化することのデメリットはテーブル数の増加により、selectでデータ取得する際、joinするテーブル数が増える。
大量データを扱う場合、こいつが速度のボトルネックになることがたまにある。
アプリケーションを利用する最大の目的は効率化であるはず。
例えば、家計簿の合計支出を計算するのには、電卓叩くよりもアプリ使った方が早いから使う。
何にどのくらい使っているのかを把握して、来月の節約ポイントを把握したりするために使うはずだ。
一瞬で、グラフや計算をしてくれるから、ノートに家計簿をつけていくよりも早くて効率化されている。
このグラフ化や計算がノートでやるよりも遅かったら、アプリを使う理由はなくなる。どっちでやっても同じ時間だからだ。
これを考えると、速度は正義！という理論が出来上がる。
エンジニアの常識なんてどーでもよくなるわけである。
この場合、正規化を捨てて、非正規化に踏み切る。出来るだけjoin数を減らすのだ。
Index貼って早くすることもできるけれど、それでもデータ量次第では厳しいケースは、こっから改善していく。
これで速度改善できるなら、それはそれでいいと考える。だって、エンジニアのためにアプリ作ってるわけじゃないからね。
他のパターンも考えられる。
いきなり仕様変わって、正規化し直してたら納期に間に合わないから仕方なくやっているパターン。
まぁ、これもなんとなくわかるが、納期の交渉したのか？ってのが最初に思い浮かぶ。
そして、こいつが厄介で、担当者が辞めたりした場合、単なる謎になる。
こうなった経緯を書いたドキュメントやコメントがあればいいのだが、だいたいそんなものは存在しない。
つまり、迷宮入りだ。
もし、納期的な問題だった場合、そんなものはその当時に担当してなかったらわからない個人に依存する出来事。
後任にはわからないのだ。
本当は意味のある構成なのではないか？
引き継いだソースコードが汚かったりすると、まさか、こいつは、正規化という概念を知らない奴が作ったのか？
それとも、使わなくなったカラムなのか？
ということを、ひたすら考えることになり、頭が痛くなる。
理由がわかるように、データベースのバージョン管理も導入してほしいものだ。
フリーランスは死なないことが最優先
フリーランスエンジニアの @nabeemichi です。
フリーランスエンジニアをやっていると、知り合いからお仕事の話が来ることがあります。
来月からうちで働いてくれないか？
みたいな感じで話をされます。そこそこあることです。 仕事に誘われたることは嬉しいことです。でも、契約をするまでは仕事があるかはわからない！ という体験をしたので、フリーランスは高単価を狙うんじゃなくて、死なないことが最優先だな！という結論に至りました。
契約する直前でポシャった案件のお話
元同僚から仕事のお誘いを頂いた。 一緒に働くであろう人たちと面談したり、元同僚の上司とも面談し、仕事を手伝ってほしいとの依頼をもらった。 うれしいことである。
この時点で僕は他の案件をやっていたため、元同僚と働く時期についてチャットで調整していた。 案件を掛け持ちするつもりはなかったので、現時点での仕事の区切りがつくタイミングなどを考慮して、２ヶ月後から働こうとなったわけだ。
特に問題はない。
契約手続きは、働く１ヶ月前にすること、契約内容の大まかなことも元同僚とチャットで合意した。 あとは、現時点ので仕事を終わらせる手続きをして粛々と仕事をするだけである。
働く１ヶ月前、契約書の草案を元同僚の会社に要求。 しかし、なかなか提出してくれない。 どうやら社内で調整してるとのこと。
さらに二週間が過ぎたころに、契約書をいただけた。 契約内容を確認して、事前に合意してる内容とズレがなければハンコを押して、無事にお仕事を一緒にすることになる。
はずだったが、、、
契約内容が事前に合意していたのと、全くちがうじゃないですか。
まぁ、私はフリーランスですから、所詮個人事業主ですから、立場的には弱いわけです。企業にくらべて。 企業が言うなら仕方ない！と思ってハンコを押すほど、勇気も根性もない私は、契約内容の間違いを一つずつ企業の担当者に突っ込むわけです。 働き始めるまで２週間もないけれど、相手はそれなりの規模の企業ですが、事前に約束していたことと違う内容はとことん突っ込みます。
つっこんだ結果、相手の企業は契約書の内容は変えれなかった模様です。法務部とかいろいろあるのでしょう。 契約内容変更できないけど、一緒に働いてと言われましたが、やめました。 契約内容が最初と違うから。そして、僕に対してものすごいリスキーな内容だったから。 ハイリスク、ローリターン！と判断。契約をする直前でポシャってしまいました。
でも、もっとリスキーなことがあります。 １週間後から収入を得られる仕事がゼロになったことです。 死活問題です。お金を得る手段がなくなってしまいました。
フリーランスはどれだけ廃業しているのか？
ちょっと古いですが、以下の中小企業庁の調査で廃業率のデータがあります。
http://www.chusho.meti.go.jp/pamflet/hakusyo/H29/PDF/chusho/08Hakusyo_fuzokutoukei_web.pdf#page=29
この調査では個人事業主だけのデータではないですが、企業と個人企業をあわせた2012〜14年の廃業率は6.1％。開業率は4.6％。 個人事業主のみのデータを見つけれなかったが開業も廃業も個人事業主と企業の割合が同じだとして考えてみると、廃業率のほうが高い。 ここ数年はフリーランスだ！働き方改革だ！とか流行ってるから開業率はもう少し高くなってるのかもしれないが、とりあえず廃業率のほうが高いので、フリーランスになるやつよりも、フリーランスやめるやつのほうが多いはず。
廃業率なんかみてても、なんでやめたのかデータがないので、今回のケースみたいに仕事がなくなって廃業したかどうかはわからない。後継者不足でやめた自営業もたくさんいるだろうに。
死なないための対策を考える
死なない方法も考えてみるのだが、今回ケースはまず、契約書を先に見せてもらって書面ベースで初期の合意を取らなかったことが第一の原因だろう。 初期の合意で書面ベースで契約書の草案をもらっていれば、どっちにころんだとしても収入がなくなるまでの時間を2ヶ月確保できた。 2ヶ月あったら新規の案件を探すこともできるし、リカバリー案を実行することができた。
第二の要因だが、収入源を分散していないこと。もしも、複数社と仕事をしていれば収入源を分散できて、1案件が急にだめになっても収入は少なくなるが途切れない。
第三の要因は、自分のプロダクトを持っていないことだ。もし、自分のプロダクトから収入を得ることができる状態を確保していたら、今回のケースでも収入が途切れない。
まとめると、とにかく収入源を複数確保できる状態を早く確率することだな。
確定申告について勉強し直した。使った本は→お金のこと何もわからないままフリーランスになっちゃいましたが税金で損しない方法を教えてください!
フリーランスエンジニアの @nabeemichi です。
フリーランスとして活動しているので、確定申告をしなければならない時期になりました。 確定申告自体はすでに経験済みですので、去年と同じことをすればいいのですが、 どうせやるなら勉強し直してみよう！ということで、確定申告に関する本を一冊読んで勉強しました。 （というか、年に一回しかやらないからほとんど忘れてるので勉強し直しました）
本日の教本はこちらです。
名前がやたらと長い本ですが、こちらをチョイスした理由はといいますと、
マンガであるため、読むのに時間がかからなさそう
Amazonのランキングで上位
発売日2018/11/8のため、最新情報が得られそう
ということで、購入。
購入にあたって、重視したポイントは1番目の理由でして、確定申告にあまり時間かけたくなかったため、読むのに時間がかからなそうなのが重要でした。
感想
私は、確定申告は昨年もやっているため、確定申告の流れ等は知っていましたが、本では確定申告書類を造るまでの流れにそって書かれていて、確定申告の全体像がつかみやすい内容でした。
200ページ程度の量がありますが、だいたい2時間くらいで読むことができ、確定申告について思い出す事もできたし、必要書類についても把握。 私の場合、読んだ勢いで普段利用しているマネーフォワードで確定申告書類を作成するところまで終了。 書類作成中もなんどか本を見直しながら作成。という感じで、無事に確定申告書類は出来上がりました。
本の中では、副業が会社にバレない申告の仕方も記載されていて、副業している会社員の方にも有用な情報もあったりするので、サラリーマンの方も読んで損はなさそう。
新規に得た知識
青色申告していると、30万以下を経費にすることも可能
小規模企業共済の威力
iDeCoの威力
本当に何もわからないままフリーランスになっちゃった人は、今の時期（確定申告の時期）にこれ読んでも、どうにもならないかも。
なぜなら、本当に何もわからない状態だったら、青色確定申告の申請だしてないでしょ？ 基本的に青色確定申告をベースに話がすすむからね。 フリーランスになってすぐか、なる前に読んで、確定申告のときにもう一度見直すくらいがいい感じかもしれない。
チームのプログラミングの課題点を見つけたら、現状と特徴を考えた対策をしよう
フリーランスエンジニアの @nabeemichi です。
アプリケーション開発はチームで行うことがほとんどですが、 メンバーによってプログラミング力が異なるので、品質や実装方法が異なってきます。 違う人が作ってるのだから違ってとうぜんではあります。
この現象を防ぐために、ペアプロやモブプロをしたりして全員のレベルアップを図ったりするのは一般的にはいいことだと思います。 しかし、それって本当に理想の状態へ近づいているのでしょうか？
例として長期的なプロジェクトについて考える
例えば、長期的に開発しなければならない大きなプロジェクトだったとします。
とある機能は作った人も理解不能なくらいぐちゃぐちゃになっているが、なんとか動作する状態になっていたとします。 一方で他の機能は仕様変更にも不具合にも強い状態でつくられていたとします。
ここでKPTのような、問題点の棚卸しをするような機会があったとき、 問題としてでてくるのは、ぐちゃぐちゃになっている機能についてです。 ぐちゃぐちゃの機能は、メンテナンスもし辛いし不具合も多く、修正も困難を極めます。 そして比較対象として出されるのは後者の仕様変更、不具合に強い状態の機能です。 課題点としては、ぐちゃぐちゃの機能を作らない方法はないか？ということになります。
ここで、あなたならどうゆう対策を取るでしょう？
モブプロやペアプロをしてレベルの底上げ
と、流行りごと大好きエンジニアは言うかもしれません。 一般的には新しいことを取り入れてみるのはいいことだと思いますが、 これで課題が解決されるでしょうか？
僕の見解とすると、こいつは何も考えてないで知識だけ使おうとしてるな！って思ってしまいますね。
自分たちの置かれてる状況を把握しているか？
長期プロジェクトということを考えると、人の入れ替わりが発生する可能性が高いです。 なんならどんどん新しい人が入ってくるでしょう。実際にエンジニアは出入りが激しいですし。
ペアプロやモブプロで解決を試みた場合、現在のメンバーに対しては有効ですが、後々参加するであろう未来のメンバーに対しては有効ではありません。
え！？新しいメンバーが入ってきたら、またやればいいじゃないか！だって？
別にそれでもいいですが、その頃には別の問題が話題になっていて、今解決しようとしてる問題は忘れ去られているでしょう。 だから、今解決しようとしてる問題を新規メンバーが繰り返す可能性があります。 ここはをどうにかしないと、同じ問題の繰り返しで生産性もチームとしての進化もありません。 同じ課題を繰り返さない仕組みを考えないと意味がないのです。
ではどうするか？ということなんですけれども、僕だったらアンチパターン集として失敗例集を作成すると思います。なぜ失敗なのか？を解説して。 でも作っただけでは誰も見てくれないので、ソースコードレビュー時にアンチパターンだと気づかせることができる方法を考えます。 簡単にアンチパターンだとわかるチェックリストを作成でしょうかね。このチェックリストからアンチパターン集へリンクしましょう。 なぜ失敗なのかの理由へいつでもたどり着ける経路を用意して、確認できる状況をまずは作ります。 調べて出てかないと、また同じ発明するやつ多発するからな。
もちろん、モブプロやペアプロは個人のレベルアップとかにはすごい役に立つとは思いますよ。何を解決したいかによります。
開発案件もらっても、作らなくていい方法があるなら提案します。
フリーランスエンジニアの @nabeemichi です。
最近は個別に小さな開発案件をいただくことが出てきた。 例えば、日々の業務の自動化をするアプリ開発について相談される。
アプリの開発を依頼されたときに、作らなくていい方法があるならつくらない方法を提案してます。
依頼されたら、まずググる
目的とボトルネックの洗い出しをしたあとは、基本的にググります。 目的を達成できるサービスがすでに存在する可能性が高いからです。 すでにあるのならば、そちらを提案します。
それでも、僕に頼んだほうがいい！ってことになったら初めて作ることを考え始める。
こんなプロセスで個別でいただく案件を受けてます。
なんで作らないの？
ってことなんですが、すでにあるのならばそれに合わせていったほうが効率的なんではないかと思うのですが、 もうあるなら作らなくてもいいじゃん！って気持ちが実は大きかったりします。 車輪の再発明するのは依頼主にとっても、僕にとってもあまりいいことではないのではと考えてます。
なんで、いいことないのか？というと、最近はSaaSで提供されてるサービスが多いです。 しかもすでに存在してる場合は、すでにユーザーがいるってことで、同じような悩みを持ってる人がもう使っているということは、 ある程度適正に目的を達成できていると考えられます。 つまり、一から課題を洗い出してトライアンドエラーを今からしようとしていることが、すでにどこかでやられていて、 はたまたSaaSとして続いているということは、ブラッシュアップもされていて、僕が今から目的を達成させるという地点よりもはるか先のもっと快適空間へ進化している可能性が高いためです。
もう一つは、開発する費用なんかよりも、安い費用でSaaSを利用できる！ということです。 アプリは開発にもお金がかかるし、保守にもコストがかかります。 それを、もしも月々数千円程度で利用できるSaaSがあったなら、作る理由はどんどんなくなっていくと思います。 SaaSは常に進化するものだと考えてますので、勝手にアップデートされていくのもメリットなのではないでしょうか？
つくってもいいけど、アップデートされなくなったらアプリは終了
だと思っているので、開発しっぱなしでは、そのうち使われないものになります。 負の遺産となっていくのです。 だって、業務や目的は常に変化していきます。 変化してないとしたら、それは自動化できる可能性が秘めているので、ぜひとも自動化して、次のステップへ行きましょう。 ですので、開発しっぱなしで終了するアプリは基本的にはないと思います。
ということで、先人がすでに作っていて目的達成できるものがあるなら、そっちを教えてあげたほうが依頼主はハッピーなのではないでしょうか？ そんなんじゃあ、僕にメリットがないじゃないか？ということなんですが、無駄なものを作らなくていいというメリットがあります。
ということで、お仕事の依頼がある方は以下のTwitterにDMいただければと
プログラミングは工業製品をまねして設計、実装する。
フリーランスエンジニアの @nabeemichi です。
エンジニアはアプリケーション作成やインフラ管理などをすることがお仕事なわけですが、 大規模なアプリを作ると、作り方やアプリとしてどの役割までを担保するかを考えながら設計やら実装を行うわけです。
そんなとき、僕がよく参考にするのは、工業製品です。 自動車とかもそうですが眼の前にあるMacBookとかも参考にします。 というか、観察します。
そして、自分のつくるアプリケーションと比べて、作り方を真似します。
工業製品を真似たプログラミングとは？
「僕はアプリ作るときは、工業製品を参考につくるよ」
と、そこらへんのエンジニアに話すと、だいたいの人の反応は、
「この人アホなんじゃないの？」
みたいな顔をした反応をします。 まぁそうでしょうね。工業製品はハードで物理的に触ることができるのに対して、アプリケーションはソフトでMacBookなどの工業製品を通して利用するものです。 違う次元のものです。
だから、大体の人は、次元が違うのだから真似するものなんてないでしょ！？という反応なのだと思います。
でも、僕は真似します。
どのように真似をするかというと、
このアプリのこの機能は、メインで心臓部の役割をするから自動車でいうエンジン。
でも、実際に作りたいのは自動車なんだから、エンジンは車体に載せないといけない。
車体に乗せるためには、車体とエンジンをつなぎ合わせる必要があって、それを担ってるのはネジ。
ネジも用途によって大きさや長さがたくさんあるけど、工業製品では規格が決まってる。 利用するネジの規格を揃えないと、車体とエンジンはつながらない。 だから規格が決まったネジを作って、車体作成部隊とエンジン作成部隊にネジが通る穴を計算して作ってもらわないといけない。
みたいな感じで、どの役割単位のパーツを作っていって、それらをどのようにくっつけるのか？を参考にアプリケーションを作っていく。
オブジェクト指向プログラミングで言ったら、クラスが保つ役割はエンジンで、これを車体クラスにくっつけるためのインターフェース（ネジ）を受け入れるようにしておかないといけなくて、だから実装するのは、エンジンクラス、車体クラス、ネジクラスで車体クラスとエンジンクラスはネジクラスを持ってる。
みたいな感じで考えると、役割も明確化されるし、結合するのにも部品が必要なのも納得できる。なんなら、部品と部品をくっつけて、一つの部品として扱うパターンも出てくる。
なんで工業製品を真似をするのか？
それは工業製品のほうがプログラミングの歴史よりも長いから。
例えば、自動車なんかは１７６９年頃に初めて蒸気自動車が誕生したとされてるので、コンピュータができるよりもずっと前のはず。 その自動車が今の形になるまでに、多くの改良や多くの作り直しをされてきている。 設計の仕方や作り方のトライアンドエラーを長い歴史の中で、汎用性や拡張性、保守性や開発効率なんかも考えられてるはずと考えることができる。 アプリケーション開発だって、同じようなことに悩んでいる。 だったら、先人に学ぶのが近道のはずだし、同じ失敗をする必要もないので、歴史の長いものから転用するのは同じ失敗をする確率が低いと考えられる。
これに近しいのが、アトミックデザインなのでは？と先週初めて聞いた単語をググって調べて思った。 自動車とか、ある程度のパーツを組み合わせて、組み合わせたパーツをさらに組み合わせて作っていくよね？
だから僕は、困ったら工業製品を観察してヒントをもらってます。 自動車の製造ラインとか見に行くともっと参考になること発見できるかも。
エンジニアだけど、僕の好きなエディタは紙とペンです。
フリーランスエンジニアの @nabeemichi です。
エンジニアだと、エディタの話題がしばしばでます。 世の中にはいろんなエディタがありまして、vimやemacsとか最近ではatomとかです。 エンジニアってのは、何をやっているかというと、所詮パソコンに向かって文字を打ってるだけです。 いや、文字打つ前にいろいろ考えたりするんですが、 プログラミングなんて所詮文字列です。みなさんが画像ファイルとかをFacebookとかでアップロードしてるのだって、所詮は文字列に変換されて文字列を送信してるだけですからね。
そのため、文字列を打つためにはエディタをよく使います。だからか、好きなエディタ何？とかいう話がたまに起こります。 エンジニアはデジタルの世界のエディタの好みを話すのですが、僕の好きなエディタは紙とペンです。
紙とペンは人類が発明した最大の武器です。 考え事するときや、プロダクトについて考えるときはA4ノートとペンで書きまくります。
どんなことでも書きまくります。 同じことも何回もかいたりします。 同じことを何度も思いついてしまったりするので。
紙とペンのメリット
PCのエディタやスマホのメモ帳を使うこともあるのですが、基本は紙とペンを使っていました。 （ここ半年ほど全然使わなくなってしまったので、また紙とペン使うことにする） デジタルのエディタと比べて、紙とペンが勝っている部分があります。
起動が早い
携帯していればの話に限定されますが、起動が早いです。 気づきを見つけたときにスマホのメモ帳を起動するには、
ポケットまたはカバンのから出す → スマホのパスワード解除 → メモアプリを探す → メモアプリ起動
と意外とやることが多いです。そして、メモするまでに結構時間がかかってます。１秒くらいはかかってるはず となると、メモしたいことを忘れちゃうことがたまに起きます。
でも、紙とペンなら
ポケットまたはカバンのから出す
の１ステップのみです。起動までの時間もそうですが、何よりステップが少ない。 ステップが少ないということは、メモしたいことに集中していられるので、メモしたいことを忘れる確率が減ります。
簡単な図を素早く描ける
気づきなどは文字だけで表すと、
なんだっけこれ？
みたいに、あとで見たときに思い出せないパターンもあります。 こんなことをしないように、図で補足を簡単にかけます。
思いついた単語同士を線で結んで理解しやすいようにしたり、思考を深めたりすることができます。
一方で、スマホやPCでは簡単な絵や線を描くことは、なかなか時間がかかります。 お絵かきソフト起動したり、線を描くモードに切り替えたり。 正直絵を描くことが目的になってしまって、何をメモしようか忘れるレベルです。
何より頭が動く
これは僕だけかもしれませんが、明らかに頭の回転が変わります。 紙とペンのほうが頭の回転が早くなりますし、 気づきが増えます。
あ、このパターンあるなら、これと似てるからこの可能性もある？
みたいな。 さらに、A4のノートを使ってる場合などは、ノートPCやスマホよりも見える範囲が大きいので、一気に捉えられる情報量が変わってきます。 これが原因かは研究したことがないのでわからないですが、確実に頭の動きが変わってるのがわかります。
紙とペンのデメリット
メリットがあれば同じだけデメリットがあります。これは物理の法則だと僕は思ってます。作用反作用の法則的な。
コピーできない
PCつかってるとコピペで同じ図などを使いまわしながら作業ができますが、紙とペンでは同じ図を一から書かなくてはいけません。 めんどくさいし時間がかかります。
検索できない
PCなら command + F で検索モードになり、文字列を検索することができますが、 紙とペンでは、１ページ１ページ自分の目を信じるしかありません。目薬がひつよなくらい目がシュパシュパしてくるでしょう。
共有ができない。
PCならgoogle driveとかでサクッとメモを共有できますが、紙とペンの場合はわざわざスマホで写メとってからチャットで流さないといけません。 しかも誰かに見せるように書いてないので、ほとんどの場合は共有しても誰も理解できません。 時間がたつと自分でも理解できない場合があるくらいですから。実質共有なんてできないのと同じです。
まとめ
まとめると、考えて思考を深めたいならメモがいい。 共有やスケールなどを考えるならデジタルなメモがいい。
そんなことをメモの魔力を読んで再確認しました。
明日A4ノートを購入しようっと。
