ママのフリーランス!でも気をつけよう
Woker Mother(働くママ)について、Yahooトップで記事を見つけました。
■月収は平均60万円 初期投資分を3カ月で回収 会社員時代は毎月の手取りが20万円を切っていましたが、フリーランスのウェブデザイナーになってからは約3倍に上がりました。今年度は二人目の出産前、つわりのため仕事量を調整して収入が減った期間を含めても、平均して60万円程度にはなると思います。
もともとの出所はnikkei WOMAN Online 2018年11月22日付記事のようです。
最近は、↓みたいなのも増えてきましたね。
・フリーランスIT/Webエンジニア専門の案件情報なら【エミリーエンジニア】
・初めてプログラミングを学ぶなら「tech boostオンライン」
どう思いました?
引用していませんが、自宅勤務で、出社はほぼゼロ。こどもの病気などで、大変な時もあるけれど、独立仲間と助け合っている、ということも書いてありました。 この記事を見て、どう思いましたが? 私は、最初「すごいなぁ。いいなぁ」と思いました。こういうのが増えて行けばいいなぁと。 しかし、冷静に考えると、危険では?と思い、調べました。
リスクを適切に考える。
仕事がもらえないリスク
最初に浮かぶのは、「仕事がもらえなくなったら、どうするの?」。これは、普通の会社にいても「倒産したらどうするの?」よりは高いリスクとはいえ、さすがにフリーランスになる時点で考えてはいるでしょうから、割愛します。金額換算もとても難しいですからね。
所得のリスク
月収は平均60万円と聞いて、すごいなぁと感じた人は多いと思います。日本人の平均給与はだいたい400万円なので、月収に換算すると30万円ちょい。倍くらいもらっていますね。
しかし、とても気をつけなければいけないのは、この60万円が、可処分所得なのかどうかということです。 記事には詳しく書かれていないのですが、これがもし依頼主からの支払い額が、60万円 なら、おそらく会社員時代の20万円と金額では大差ない可能性があります。その理由を説明しましょう。
フリーランスということは、個人事業主だと思われます。個人事業主の場合、保険証や各種税金、経費も自分で払う必要があります(経費に関しては、電気代やネット代なども経費として落とせるので、税金対策になる面もあります)。 一般に、サラリーマンの手取りとだいたい同等の額を、会社は保険や税金やらで収めています。つまり、年収400万円の社員一人を雇うのに、給与の400万円だけでなく、さらに400万円を経費で払うので、計800万円くらいかかるということです。 あと、退職金もないです(もともとない企業の方も結構ありますが)。
月収60万円を手取りで稼ぐにはどのくらい必要か?
ローンや保険、控除各種でことなるので、正確には税理士などに相談した方がかなりいいと思いますが、ざっくり年間1,200万円、つまり月間100万円くらいの売上高が必要そうです。可不可はわかりませんが、「これくらい稼ぐぞ」の意気込みは必要かもしれません。 会社員時代と同額なら、そこまで頑張る必要ないですが、それだとリスクに見合わないです。
参考: https://www.private-business.jp/tax/jiturei.html
対策は?
会社設立ですかね。会社に売上を全部吸収させて、報酬を役員報酬として、ゼロにすれば、給与関連の税金はなくなります。あとは、生活費全般を経費にして、黒字を限りなく少なくすることで、会社にかかる法人税も抑えることができます。 ここまでくると、素人ではなかなか手に負えないので、税理士や行政書士の力が必要になりますね。
会社に退職金なかった
会社で、退職金の話が最近上がっている。 なるほど??というか、退職金なかったんですね。また感覚のズレを認識。 退職金って、会社の義務じゃないんですね。
まぁ、特に給料からも天引きされていないので、良いんですが。
ベンチャーなんて、そんなものか。
あ、私は退職してないですよ笑。
Pythonエンジニアなら絶対受けるべきUdemy講座の紹介
今回は、Pythonエンジニアならば知っておいて損はない講座のご紹介です。というか、絶対に受講しておくべきだと私は思います。下記リンク・画像より、飛ぶことができます。
Python 3 入門 + 応用 +アメリカのシリコンバレー流コードスタイルを学び、実践的なアプリ開発の準備をする
これは、シリコンバレーでITエンジニアとして働く酒井氏がUdemyで公開している講座です。総時間が30時間近い講座であり、前半はPythonの初心者向け、後半から個別のトピックを扱って中上級者向けに作られています。知っておくべきことが盛りだくさんです!
酒井さんありがとうございます m(__)m
他言語から、Pythonをやるという方、新しくPythonをやる方、もっと詳しくPythonを学びたい方など、幅広くカバーしています。
後半では、データ解析、データーベース、ネットワーク、暗号化、並列化、テスト、インフラ自動化、キューイングシステム、非同期処理などをカバーしています。
私は一通り受講したのですが、とても満足いく内容であり、辞書的に見直したりしています。
ぜひ、受講してください!
Python 3 入門 + 応用 +アメリカのシリコンバレー流コードスタイルを学び、実践的なアプリ開発の準備をする
MySQLをチューニングしてみた
ITエンジニアをやっていて、避けられないことの1つは、DB(DataBase)との闘いかもしれない。そう、いかに高速化するかである。
果てしない死闘の末に、勝利を手にするか、敗北の苦渋を舐めるか・・・
今日は、勝利の美酒を少しでも手に入れるために、こんな方法をやっています。
①EXPLAIN & Session STATUSを見る
EXPLAIN 実際のクエリー ; とやると、利用するインデックスや、どのくらいの行数をスキャンしているかなど、実に様々な情報が得られます。すばらしい。
しかし、気をつけたいのは、EXPLAINは「サンプリングによる結果を表示している」という点です。このサンプリング(sampling)は、統計用語です。つまり、「全部を試すのは時間かかるしコストだから、n回やったものの平均とかをとって、結果としよう」ということです。
別に間違ったわけでもないですし、素早く結果を出すの非常に便利ですが、サンプリングにより導き出した結果と、実行結果が異なると異なります。
さて、ということは、「実行結果」が知りたいのです。実行結果とは、実際に「利用したインデックスや、どのくらいの行数をスキャンしたか」です。
それが、次のコマンドです。
FLUSH STATUS; 実際のクエリー ; SHOW SESSION STATUS LIKE 'Handler\_%';
Flush Statusはセッションスコープのステータス変数をクリアします。余計な値が混じらないように、念のため実行しています。
SHOW SESSION STATUS LIKE 'Handler\_%';で出てくるHandler_ read_ next は、実際にどのくらいの行を読み込んだかを表示します。
実際にどのインデックスを利用したかどうか、また本当に最適なインデックスを使用したかどうかは、残念ながら都度USE INDEXを加えたりしながら、様子を見るしかありません。みんないろんなインデックスを作っては試し、また破棄し、作り直す、、、みたいなことをやっています。
ALTER TABLE `table1` ADD INDEX `id_ix`(`id`); (idを`id_ixというインデックスとして、table1のインデックスに追加する) ALTER TABLE `table1` ADD INDEX `multi_ix`(`id`, `id2`); (idとid2による複合インデックスをmulti_ixとして、table1のインデックスに追加する) ALTER TABLE `table1` DROP INDEX `id_ix`; (table1の`id_ix`というインデックスを削除する)
②Logに書く
こっちの方が簡単ですね。long_query_time=0にすることで、全てのクエリー を保存します。mysqlは、restartしてください。
[mysqld] slow_query_log = 1 slow_query_log_file = /Users/var/log/mysql_log/slow_query.log long_query_time = 0
すると、ファイルパスに指定されている/Users/var/log/mysql_log/slow_query.logには、次のような情報が書き込まれます。
Query_time(クエリー にかかった時間), Rows_sent(抽出された行数), Rows_examined(抽出するためにスキャンした行数)
Rows_sentと Rows_examinedの差異が少ないほど、より効率的なクエリー になります。ですが、これを縮めるのはかなり骨が折れることも事実です。
もっと効率的にslow queryを調べる方法は、またの機会に。
レビュー -世界史とつなげて学べ 超日本史 日本人を覚醒させる教科書が教えない歴史-
最初は、遺伝子の話から始まって、?だったが、遺伝子によって日本人がどこから来たかを明らかにする視点は斬新だと感じた。遺伝子が完全に解明される以前は、かなり混沌とした議論がなされていたようである。
また神話を現実の話に引き寄せる辺りがとても面白かった。
例えば 『古事記』における、高天原から降りてきた天上人は、主に大陸からの移民であり、土着民との政権交代の様子を描いているという解釈。これは、天上人と土着民が平和的に政権交代をした様子を記しており、その結果、天上人を祀る伊勢神宮と、土着の神を祀る出雲大社が並存することになった。そして、それは現在も続いている。神話や伝承は、事実を何かしらになぞらえて作られたもので、それを逆に変換してやると、とても面白いのだと思った。この手の話が、いくつか述べられている。
近代史と昔の歴史を類似点で支度しているでも面白いと思った。
例えば隋(中国)が滅びた原因として、厳格な租税制度・官僚制度を徹底して、いわば古代社会主義を敷いたことが原因であるという話がある。つまり、
1) 民は重税によって勤労意欲を失い、税から逃れるために逃亡する。
2) 中央政府は財力がなくなり、疲弊し、地方を支配する力がなくなる。
3) 節度使という制度を用い、地方に権限をすべて委任してしまう
4) 最終的に権力を得た地方が反乱を起こして、中央政府を滅ぼす
このループは、中国で何度も繰り返されている。日本の平安時代も、同様で、結果的に武士が台頭してくる背景となる。
江戸時代以前に日本人傭兵がアジア各国で活躍していたというのは面白かった。全く知らなかった。
確かに江戸になるにつれて時代が泰平の時代になり、武士は失業して浪人になった。
浪人がたくさんいるのは危険なので、海外に傭兵として派遣することで、食い扶持も確保し、治安も維持する。海外の戦闘で活躍し、戦闘経験が豊富な彼らが帰国するのは危険なため、次第に日本への帰国を禁じる。
一方で、アジアの植民地支配をしていたポルトガル、スペイン、イギリスは、日本人傭兵を喜んで雇い、戦争を繰り広げる。場合によっては、日本人同士の戦いもあった。
聞いたことはあるが、日本の鉄砲数は欧州のと引けを取らないくらい数があり、当時はかなりの軍事国家であった。そのため、植民地支配も不可能と断定され、むしろ中国制服のために同盟を結ぶ運びであったのは、面白い。
鎖国というのも、圧倒的軍事力があってこそできる。
ただし全体として、教養としてとても面白い。しかし、事実を確認することが難しいので、「こういう視点もあるのかぁ」くらいに思っておいた方が無難だと思う。大学入試などは、国が公認した事実に基づくもの、つまり教科書に従わないものは、不合格になるので。
まぁ、歴史というのは、いろいろな説があるものである。
最後に、歴史は繰り返す。
日本は
①先進国の技術を取り入れ、先進国を追い抜かしていく。
②その後自国の殻に閉じこもり、周回遅れになる。
③他国に圧倒され、自国が劣っていることに気づくと、また必死で技術を吸収していく。
この繰り返しである。平安時代、中世(主に鉄砲・軍事)、そして近代(文明開化)。というのが締めくくり。
今は、②かな。次も③できると良いけど。
レビュー11章 推薦システム―統計的機械学習の理論と実践 -
前回の続き
レビュー10章 推薦システム―統計的機械学習の理論と実践 - - tiruka’s blog
最終章です。今回で終わりなので、最後に全体所感もつけています。
11章多目的最適化
今までは、基本的にクリック率(CTR)を最大化することだけを考えていましたが、
実際には他の指標も最大化したいことがありますよね。
ある例えばページ滞在時間や、クリックによる広告収入額とか。
つまり、対象の目的関数が増え、複雑な連立方程式が、さらに複雑になる感じである。あっちを立てれば、こっちが立たず、みたいな状況です。
例えば、Web広告を考えてみる。Web広告は、クリックされると収入が入る仕組みであり、また媒体によって一度のクリックにより入る収入金額は異なります。例えば、不動産なら10円、ソーシャルゲームなら1円とか。
ソーシャルゲームは、みんな関心があるので、よくクリックされる。不動産は、関心がある人は少ないので、クリック数は少ない、とします。
この場合、薄利多売で、ソーシャルゲームのWeb広告をたくさん出すのか、それとも単価が高い不動産のWeb広告をたくさん出すのが良いかは、一概には言えません。その最適な割合を、求めようとするのが、この章の趣旨です。
レビューの初めの方に述べていましたが、CTRを最大化するスコアを予測するだけで難しいのに、それを複数のスコアを予測するのは、神の領域に入って来ている感じがします。
全体の所感としてはこれは本よりは論文だと感じました。つまり(?)前提知識がたくさん必要です。
主に、基本的な統計知識、周辺確率、ベイズ統計学、ベクトル、EMアルゴリズム、など、ぱっと思い浮かんだだけでもこんなものが必要でした。
データだけで理論的に求めると、こういう計算になるのだという感じ。いくつかマニュアルで済むなら、マニュアルでも良いと思います。例えば、10章のコンテキスト依存などは、記事の例で言うと、現在表示している記事と、同じカテゴリーの記事を推薦するようにフィルタリングするだけでも、結果は改善すると思う。わざわざ、「次にカテゴリーAを見る確率は30%で、カテゴリーBは17%で、、、その上でランダム性を入れてMCEMをやると、、」とかまでは必要ないと、経験的には思います。
というのも、説明をしても理解できる人って、少ないと思うんですよね。実際にサービスとして稼働させるには、自社でも他社でも、合意や納得が必要なケースがほとんどです。
「あなた方が理解できなくても、大丈夫です。だって、こんなすごい理論を元に作っているんです。だから導入しましょう」で、説得される人はなかなかいないでしょう。
難しい理論を平易に説明しつつ、マニュアル手法で大丈夫なところは、マニュアル手法を採用した方が、全体的にメリットがあると思います。
レビュー10章 推薦システム―統計的機械学習の理論と実践 -
前回の続き
レビュー9章 推薦システム―統計的機械学習の理論と実践 - - tiruka’s blog
10章コンテキスト依存推薦
ここではコンテキスト依存を説明する。
コンテキスト依存推薦とは ユーザーが例えばどのページにいるか、スマホから見ているの、 PC から見ているのか、今現在どこにいるのか、どのページから来たのか、などの材料を盛り込んだ上で推薦することである。
今までは、ユーザーとアイテムだけの関係だったがさらにコンテキストが加わるため3次元の計算になる。
三次元になった場合はテンソルを用いた計算を用いる。ここでも計算をいかに効率化・最適化するかを主眼において説明している
簡単に言えば学習するためのモデルがもう一つ増えるのである。また結果を見るためのサンプリングも非常に難しいらしく、半分でのページぐらいが割かれていた。