フリーランス単価の変遷を公開する｜shu223
先ほど「フリーランスエンジニアがコード書いて稼げる上限」という記事を書きました。で、その話をするにあたって、自分の今の単価はいくらか、その前はいくらだったのか、みたいな具体的な数字を書くと参考値になるかなと思ったので2013年〜現在の単価の変遷をこちらで公開してみます。「なぜその値段に設定したのか？」という理由つき。 購入者の皆様の声： 堤さんのようなトップエンジニアの方が具体的な単価を教えてくれることは滅多にない(僕も噂でしか聞いたことがないｗ)ので、このnoteは必読ですね！ 僕もYotuberとしてだけでなく、経験豊富なベテランDevOpsエンジニアとして名前を売っていかなきゃなと思ったですｗ(^.^;)https://t.co/JrkPFWSHrR — 勝又健太｜雑食系エンジニア｜参加者数ランキング日本第5位のオンラインサロン主催 (@poly_soft) February 16,
フリーランスエンジニアがコード書いて稼げる上限｜shu223
フリーランスエンジニアがコード書いて稼げる年収の上限は、だいたい3000万円ぐらいらしい。 この数字がどこから来ているのかというと、 masuidriveさんはCTOというエンジニアの相場観が見えやすそうなポジションを長くやってた方だし、きっとそんな感じなんだろうなと。 3000万を12ヶ月で割ると1ヶ月あたり250万。20人日として単価は12.5万円/日。なんとなくコード書くエンジニアの上限として妥当そうな感じはある。 だから何なのかフリーランスエンジニアは自分で自分に値付けしないといけないのだけど、これが結構難しい。技術力や経験は上がっていくものだし、しかしそれだけで値段が決まるというものでもない。あと基本的に自分の単価は公言しないものなので、参考値もあんまりない。 会社員からフリーランスになったとき、額面上は一気に大きくなるので、「うわーさすがにこれは高すぎでは」とビビっていたが、今
「ある企業がブラック企業かどうかは人それぞれ」という意見の危うさ - 脱社畜ブログ
以前、ある企業がブラック企業かどうかの判断は、結局のところ人それぞれだという意見を聞いたことがある。 たとえば、激務で残業が非常に多い会社があったとする。この会社は、早く家に帰ってプライベートを充実させたい人にとってはブラック企業に見えるかもしれないが、仕事を通じて成長をしたいと思っている人にとっては「よい環境」であるためブラック企業ではない。「人それぞれ」論者はこういった理由で「ある企業を一方的にブラック企業だと決めつけてしまうのはいかがなものか」と懸念を表明する。 言いたいことはわからないでもない。おっしゃる通り、激務だがそのかわり仕事によって能力が飛躍的に身につくという会社は存在する。外資系コンサルティングファームやスタートアップにそういった見返りを求めて就職する人はたくさんいるし、この手の会社をブラック企業だと言ってしまうのはたしかに違和感がある。 しかし一方で、「ブラック企業かど
エンジニア立ち居振舞い：自分のタスクよりメンバーのコードレビューを優先する - koogawa blog
お題「エンジニア立ち居振舞い」 ということで自分も書きます。 以前、Twitterにつぶやいたのですが 自分のタスクよりメンバーのコードレビューを優先するの、自分の作業は止まるけどトータルで見るとスピードが上がる、と信じたい— Og🌗エンジニア🏝宮崎 (@koogawa) 2016年7月25日 自分のタスクに着手する前に、チームメンバーのコードレビューをするように心掛けています。 コードレビューが滞ると、次のような悪影響があると思っています。 他のメンバーが次のタスクに着手できない プルリクエストが消化されないうちにもメインのブランチはどんどん進んでいるのでコンフリクトが起こる →コンフリクトを直す手間が増える 誰が何をしているか把握しにくくなる 当然、自分の作業は止まってしまいますが、それよりも上に書いた悪影響の方がまずいと思っていて、ここを解決することで全体的には開発スピードが上が
役立つコードレビュー 8つのヒント | POSTD
役立つコードレビュー（CR）のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。 コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。 前提 まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。 コードではないシナリオでフィ
株式会社メルカリを退職しました - PM memorandum
これはなにか いわゆる、退職エントリと言うやつである。 先日、約2年と6ヶ月の間勤めた株式会社メルカリの最終出社を終えた。 多大なる感謝と濃密すぎる2年半で、めっちゃ長文になったけど、ご勘弁を。 目次 なぜメルカリに入ったのか メルカリでなにをしたのか メルカリで得たもの 内側から見たメルカリ では、なぜ辞めるのか？ なぜそれをやるのか？ ぐちゃぐちゃした思いの中で、ひとつ明確に言えること 最後に なぜメルカリに入ったのか メルカリに入る前は、サイバーエージェントで一貫してゲーム畑のPMをやっていた。 SFでのアメリカ支社の立ち上げ→大型ソシャゲタイトルの運用→自社IPタイトルの新規リリースetc.と、いろいろと経験を積ませてもらった。 きっかけはBizDevのミートアップだった。「ちっちゃいベンチャーがヤマト運輸と提携、ってどんなマジック使ってんのよ？」くらいの、ほぼ冷やかしと言っても過
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
