IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

なぜ10年以上エンジニアをやった私が「分からないことだらけ」なのか?

アプリなんてちょっとしたものなら初学者でもリリースしてるし、15人月規模のアプリでも2年目の新人3人でリリースすることができました。
でも10年以上iOSエンジニアをやってる私でも「分からないことだらけ」と思うことが多いです。これはどういうことなんでしょうか?という話。このロジックは若手のうちには気づきにくいんです。

大きく3つあります。

 

1.書き方がたくさんあって、プロジェクトによって書き方が違うから

特にフリーランスになったりするとこれにぶち当たります。1つの機能を作るのにも、やりかたが何通りかありますよね。あれのうち1つだけあればとりあえず動かせるのですが、メンテナンスしようとすると他人のコードを読まなければなりません。他人はいろんな方法のコードを書くので、全部読める必要があります。

機能だけではなく設計方針もそうです。たくさんの思想があるため、それを引き継ぐには設計方法をたくさん知り、そのコードから思想を読み取る必要があります。

この点だけでも「10年あっても足りない」くらいです。

 

2.書き方がどんどん変わっていく上に、昔のコードも残っているから

初学者は、今ならiOS14,iOS15、Swift5の書き方を覚えればいいかもしれません。しかしいろんなプロジェクトではiOS7の時から使用しているコードが合ったり、Objective-Cがあったりと、地層のようなコードになっていることがあります。
成功しているプロジェクトほど昔からやっているのでその傾向が強いです。
それらを読めるためには、{1の複数の書き方}×{時代ごとの仕様}分の知識が必要になります。

 

3.頭良い人が難しいコードを書くから

難解な設計、難解な主張、コメントのないコードによって、素人目(?)に見たらスパゲティコードにしか見えないものを頭いい人は生成します。
それを理解するにはやはり10年でも足りないです。

 

あとは自分の得意な分野以外の知識が必要になるケースもあったりしますし、それらも上記1〜3が発生していることがあるので、分からないことは雪だるま式に増えていくわけです。

たぶん30年かけても無理でしょうから、全てを理解しようとするのはどこかで諦めなければならないでしょう。しかし界隈的には「そういうのを勉強していくべき」という風潮もあるので、バランスを上手く取らないと挟まれて苦しくなってしまうので気をつけたいところです。

プロジェクトの難易度を上げすぎると窒息死する話(エンジニア採用)

最近何社からか「良い人材がいない」とか「みんなすぐ辞めてしまう」みたいな相談を受けたのですが、「そりゃこんな難易度のプロジェクトできる人材なんてそうそう居ないよ」みたいなのばっかだったのでそう言う話をします。

 

モバイルアプリの人材を5段階で考えてみる

 

以下のように5段階で考えてみます。
私はiOSばっかりやってるのでiOSです。Androidも似たりよったりだと思いますが。

 

Aランク 頭がいい上に10年前後の経験がある
Bランク Aよりは劣るがベテランの域である、リーダー経験もある
Cランク フリーランスとしてでもやっていけるレベル、有名企業の若手とか
Dランク 慣れてきたかなーというくらいのレベル
Eランク 初級者


私はBランクです。たぶん一生Aにはなれない。
地方旧帝大卒くらいの頭だとB止まりな気がしてます。才能如何もありますけど。周りでも似た感じなので。

 

金を積んでも見つからないのがAランク

AまたはBでいいなら頑張れば見つかります。ただし金は積む必要があります。
Aランクは大抵どっかの重要ポジションに居るので中々出てきません。
Cランクは結構居ます。フリーランスで適当に月80万くらいで雇えばCかDランクが来ます。

 

A,Bランクは人数が限られる

育つのに時間がかかりますし、重要なポジションには既にA,Bの人がついていたりするので、Cが今後A,Bになるには数年の時間がかかります。
とにかく2022年時点でもA,Bが不足しています。

あと、A,Bランクにいるような地頭のいい人は他の技術に移動することも多いので、常にこの層は不足します。下手するとその技術においてA,Bの人材が居ないということもありえます。
例えばiOS(swift)から10年選手が出ていくことはあっても戻ってくることって稀じゃないですか?

 

プロジェクトが安定するのは「C以上で運用可能な難易度」

Cくらいならすっと育つんです。これは体感ですが。
DでもOKになるとより安定しますが、今度はやりがいが薄めになるのでエンジニアは不満かもしれません。

A,Bは、A,Bにしか理解できない難易度のプロジェクトを作ってしまいがち

コードの難易度がどんどん上がって、Cお断りやBお断りのプロジェクトが作られてしまいます。
そうするとまあ詰みはしませんがスケールはしません。

 

そんなに難易度を上げる必要があるかというのはやや疑問です。研究職というわけでもないので。ただ職人気質な人は得てしてそういう局所最適な動きをする生き物なので諦めましょう。事業最適な行動を取るような人はやはりB止まりなんだと思います。戦闘狂じゃないと。

 

難易度Aのプロジェクトを作らないようにしよう

とはいいますが、Aの人に任せればどうやってもAになります。
それで人事部が頭を抱えてしまうみたいな会社をいくつもも見たことがあります。
というかBランクになると難易度Aのプロジェクトに誘われることが多いので、最近はそういうのばっかりです。


Bランクの人ですら読み解くのに時間がかかるコードが生成されてしまう感じです。

 

Aの人に期待するのは難しいので、プロジェクトマネージャー観点でどうするべきか考えるとすると、Aの人を投入するタイミングの調整だと思います。
大体上場前後がベターかなと思っています。その際にプロジェクトにDの人材を入れましょう。Cではだめです。Dが理解できるレベルで設計するとうまくいくと思います。

 

一度上がった難易度を落とすのは不可能です。

 

まあ私はフリーランスなのでどっちでもいいいですけど。
どうあがいても難易度Aのプロジェクトに行くことになるので・・・

 

エンジニアは難易度Aの案件に気をつけましょう

気をつけると言うか、付き合い方を考えないと病むと思います。
でも正社員で入ったらどうすればいいんでしょうね?わかりませんね。

 

そうそう、最近気づいたんですが

Aの人は複数の会社で関わってたりするからAの人が居ない会社で難易度Aを錬成してることもあります。天才だけど人災。

 

連番のボタン名がなぜ良くないかを言語化する

これ

b.hatena.ne.jp

元:

https://twitter.com/ohbashunsuke/status/1495900842389610498

 

何か凄い燃えそうだし斧投げすぎるの良くないかなと思ったんですが、テーマとして面白そうだったのでブログ書きます。

とりあえずコメントを見るに「どうやら皆良くないと思っているらしい」というのはわかるんですが、「なぜ良くないか」を言語化しようとすると難しいですよね。
案外きちんと反論できない人も多いのでは?

 

問題・テーマの一般化

問題の一般化からちょっと手こずるんですが。トライしてみます。

仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的な名前をオススメ。後の参画メンバーの混乱は避けるべき。

「OKボタン」などの用途名はやめよう、「ボタン1」とかにしよう。という話です。
動機は仕様変更であり、「後で変わるかもしれないから」です。

 

あと、おそらくこれは共有パーツの話だと思います。
流石に特定画面内の1パーツを連番にしようという話ではないと思うんです。合ってるかな・・・?

 

なのでテーマとしては

テーマ:共通クラス名は、ある初期仕様における用途名で作るべきであなく、連番のような機械的な名前にするべき。は正しいか?

で合ってると思います。

 

具体的に課題に感じているのは

例えば「OKButton」と名付けたのに後々別の用途でも使う事になった。
名前変更がコストかつリスクである。

だと思います。

 

ちなみに前提として「最近のゲーム開発である」があります。

 

たぶん誤解されているテーマ

誤解というか、似た別の例として捉えている方が多い印象です。

・特定画面のパーツの名前を用途名にするか、機械的にするか?

・そもそも命名機械的であるべきか?

・データ側の命名規則機械的であるべきか?

・OK/Cancelを混同していいかという問題

 

これは汎用性の話

エンジニアという生き物は少ないルールで多くのことを表現したがります。
昨今の仕様が動くことを前提にした開発においては、たしかに汎用的に作った方が楽なように思えます。
さもないと、代わりに例外が増えます。例外が増加すると状態数が増えて訳がわからなくなります。

 

ボタンを汎用的に作りたいという要求→機械的な名前

例えば序盤の仕様では緑のOKボタンがあったとします。
それをOKButtonとしたら、次の仕様では「次へボタン」も同じ緑のボタンでした。
そこでOKButtonをPositiveButtonとリネームしました。
すると次の使用では「戻るボタン」も緑でした。
そこでPositiveButtonをGreenButtonとリネームしました。
すると「戻るボタン」は特定条件でオレンジに変化することがわかりました。

 

というようなことがあって、「じゃあ最初からButton_1でいいじゃん」という主張担ったんだと思います。
こういうの、皆さんはどうしていますか?

 

Button_1の致命的な問題

何のボタンかがわかりません。
これは本当に致命的です。
こうなると、いつどのボタンがButton_1になるのか、Button_1の正しい仕様は何で、正しくない動きは何かなどが分からなくなっていきます。
凝集度とかそういうレベルじゃなく、スパゲティコード(神クラス)になっていきます。

 

凝集度 - Wikipedia

God object - Wikipedia

 

後任者はButton_1を「どのように使われているか」でしか判断できなくなります。
(きちんとした外部ドキュメントがあれば別ですけど、まあ大体ないですよね)

 

※神クラスの厳密な定義からすると私の意図しているものとちょっとずれるかもしれません。支配的なクラスと言うより、何でも詰め込まれたFatなクラスというイメージで使っています。

 

どのように使われているかしか判断できない可読性最悪なクソClassが神クラスになる

これって何か名前ついてないんですかね?
私は過去十数年でこういうClassに何度も何度も何度も何度も出会ってきました。こいつに出会うと数日、下手したら数週間苦しみます。
今回の例では「青いボタン」のような共通した見た目のデザインがあるからいいですが、そうではない場合は本当にわかりません。

例えば、OKボタン、進むボタン、戻るボタン、で使用されていたButton_1があったとして、「同意するボタン」にはButton_1を適用するべきでしょうか?例えば、「同意するボタン」にButton_1を適用する場合、Button_1を少しカスタマイズしなければならないとしたらどうでしょうか?Button_1をカスタマイズしますか?ほら、神クラスの誕生です。

 

汎用的な名前をつけるとFatな神クラスができる

例えばiOSの界隈では数年前に「BaseViewController作るのやめよう」って流れあったんですが、あれです。
全ViewControllerがBaseViewControllerを継承しているという神クラス状態なのがまずいのと、あとは「Base」という汎用的な名前が危険というのが一点。

もっと端的に言うなら「単一責任の原則の逸脱を誘発する」からダメだと思います。

 

抽象度を上げると可読性が下がる

そもそもなんですけど、プログラミング全般において汎用性を上げるということは抽象度を上げるということであり、結果的に可読性は下がります。汎用性というのは色んなパターンに対応するということであり、読み手はそのクラスが取りうる全空間を理解しなければきちんと使いこなしたり改修することができません。

どういうわけか、最近周囲では抽象度を上げることに躍起になっており、可読性がかなり犠牲になっているんですが何故なんでしょうか?
すいません脇道でした。

機械的な名前というのは「抽象度を最大限取った」ということですよね。可読性は死にます。後任者はこちらの方が混乱すると思います。というか地獄。

 

結論

テーマ:共通クラス名は、ある初期仕様における用途名で作るべきであなく、連番のような機械的な名前にするべき。は正しいか?

正しくない。

・スパゲティコード化(神クラス化)を誘発するからよくない

・可読性がゼロだからよくない

 

対策

結論では具体的な課題は解決されていません。

 

例えば「OKButton」と名付けたのに後々別の用途でも使う事になった。
名前変更がコストかつリスクである。

 

これについて、ブコメでは命名の工夫などが挙げられました。
私も概ね賛成というか、ハードウェアレベルのコストでないのであれば随時名前変更した方が良いと思います。また、積極的に「似た異なるクラス」を作ってもいいと思います。1個で全てまかなおうとしないでください。

それ以前に、Mixinの仕組みが備わっているのであればClassを作成せずそれを活用するのが良いと思います。iOSで言えばextensionやprotocolです。

Mixin - Wikipedia
Swiftのprotocol extensionでmixin的なものを実現する - Qiita

 

それでも連番のような抽象的な名前が発生するケース

門外漢ですが。

例えばそもそも汎用的なハードウェアであれば、ボタン1、ボタン2、ボタン3、のような命名は致し方ないシーンがあると思います。
あとは公開APIのパラメータやデータベースのような、後で命名変更するコストが甚大なケースはしょうがないのかもしれません。
ただその場合もできるだけ具体名にすることを諦めるべきではないと思いますし、そもそもアジャイルな開発手法は向いていないと思います。

今回は「最近のゲーム開発」という文脈ですので、おそらく仕様変更に対応しやすい仕組みが導入されているのではないかと思いました。知らんけど。

 

おわりに

でも少し昔は普通にそういう実装多かったし今でもありますよね。
たぶん今回はみんなのトラウマを呼び起こしたんだと思います。
もうコードリーディングしたくない・・・

Delivery(納期)とQuality(品質)を柔軟に入れ替えられる人は少ない

QCDはトレードオフする。という話があります。
Quality、Cost、Deliveryは一つ上げると他が下がるみたいな話。
エンジニアにとって特に重要な要素としてはQとDなわけですが、世の中に案外QとDを調節できる人は少ないです。
私もぶっちゃけ得意じゃないです。

 

なぜかと言うとどこらへんまでQを重視/軽視していいのか、どこらへんまでDを重視/軽視していいのかという温度感を学ぶのが非常に難しいからです。
一番良いのは新規立ち上げのベンチャー企業でバグだらけでも構わないシステムを最速で出す経験と、大企業で人名に関わるようなクリティカルなシステムを開発したり、その中間のいくつかのパターンのプロジェクトを経験しないとわからないからです。

 

例えばそういったQとDの組み合わせパターンがナレッジとしてまとめられていたとしても、各々が受けいれること自体が非常に難しいのです。
なぜならある組織においては固定のQとDの組み合わせさえあれば十分だからです。ベンチャーならベンチャーのQとD、大企業なら大企業のQとDさえあればよく、それ以外を唱える者を異端者として糾弾したほうが手っ取り早いのです。

 

特定のQとDがあり、それを元に「どのようにそれ(より重視する方)を実現するか」という点に重きをおいてキャリア構築をするとなると、別パターンのQとDの存在は否定したくなります。ひょっとしたら自分のやり方は間違っているのではないか?と思いなから仕事するのは精神的にかなりきついです。

 

自分の中の相場(品質はこのくらい、速度はこのくらいが普通)というのを信じて、それ以上もそれ以下も「おかしい」と糾弾するのは、その組織で生きるために戦略として間違ってはいないと思います。

 

気をつけなければならないのは採用者です。
今の事業にとって、どのQとDの相場感覚を持った人が必要なのかよく考えなければなりません。間違うと非常に厄介なことになります。

 

特に品質過剰においてそれが顕著ですから、採用者のやるべきことは「納期に対するモチベーション」だと思います。

 

あるいはフリーランスであれば複数のQとDの組み合わせを駆使しないと行けないシーンが有るのかもしれません。
とはいえそんな器用に組み合わせて仕事をしている人なんてほとんど見たことがないですけどね。
私はそうなりたいですが、やはり億劫なので、「自分がベンチャー寄りに偏っている」というあたりを認識する程度に留めています。
しかしそれだけでも採用者には非常に喜ばれる事が多いです(そして仕事につながる)

 

 

もっと基礎を疎かにしろ!

プログラマーに数学が必要かどうかの論争って定期的におこりますよね。
Twitterでバズってましたね。

note.com

 

私は「大学を出たような人が改めて数学を勉強し直すほどのことは必要ないんじゃない?」と思ってます。さすがにセンター試験レベルの数学は理解できていてほしいですし、嫌いだからって逃げてたらいつか痛い目見るとは思いますけど。

こういう論争でよくあるのは「若手プログラマーは今のうちに数学を沢山勉強しておけ」という論に対するカウンターですよね。私もこういう論調にはイラッとします。そういうので語られる数学って実務で出てきませんし。

もちろん数学が必要になる分野の人も居ますけど、その人が別の分野で必要になる知識を基礎から覚える必要は必ずしもないわけです。

いわゆる「教養は必要かどうか」という話ですね。

 

教養は必要かどうか、というテーマに終止するのであれば多分世の中は平和なんです。
「実務では使わないけど、教養として知っておくと良いことあるかもしれない」くらいの論調であれば波風は立ちません。
問題なのはプチインフルエンサーみたいな技術者が新人に対して「実務で使うからこれらの数学の基礎を叩き込んでおくように」と言うと炎上するわけです。
まあそういう数学の知識をフルで使うのはかなり特殊な人でしょう。これはWeb系だの組み込み系だのSIだの全部ひっくるめてもそうです。疑うなら情報処理試験の内容を見てほしいです、ほぼ数学は出てきません。

 

面倒くさいのは、かなり特殊な人に限ってインフルエンサーなんですよね。彼らも人間なので、自分の状況が世間の状況とイコールであると信じてしまうんですよね。バカですよね。
あとは新人って「これ勉強しとけ!!」って言われると信じちゃいますから、そうやってバズらせるのを狙ってる人も居ますよね。あるいは天然で勉強家な人が「俺が勉強してよかった本」とかまとめちゃって、それが新人に拡散されまくった結果バズって、「バズってるからこれらは必要な知識なんだろう」と誤解されるケース。バカですよね。

 

ところで私は基礎勉強に対する過剰な信仰が嫌いです。
勉強する=良いことみたいな。こういうの真面目な人ほど学生時代に叩き込まれますよね。知識の積み重ねみたいなやつです。
これと対象的な考え方に「研究」があると思います。テーマを探し、課題化し、解いて目的を達するみたいな。
両者は似ていますが、勉強は誰かが作って体系化したものを頭の中にコピーする作業です。研究はまず目的や課題があって、それを満たすために色々行動するみたいな感じです。必要ならば勉強もするみたいな。
私はプログラミングにおいては研究の力の方が重要だと信じています。

 

ITの業界は過去の天才たちが非常にうまいことやっていて、基礎知識がなくても、途中から始められるようにできています。途中から階段を登り始めて目的を達することができる。よく「巨人の肩に乗る」って言いますよね。
基礎部分が隠蔽されている場合は、時には基礎を知らないほうがノイズがなく思考がうまく進むケースもあります。
もちろん基礎を知っていたら、巨人の肩が揺らいだ時にそこを補強することもできます。しかし巨人の足元から肩まで勉強するとなると相当な秀才でもない限り難しいと思います。更に悪いことに巨人自体が毎年更新されていくので追いつくのが大変です。

 

ちなみに数学の基礎というのはその巨人で言ったら脚くらいの位置にあたるんじゃないでしょうか?

 

その巨人の部分をどうにかするというのは世の極一部の天才プログラマーに任せて、世の大多数のプログラマーは肩に乗ったあとの応用研究に勤しむべきです。
目的や課題を探し、プログラムが動くように考え、必要になったらより低レベルの基礎を学んでいくという、下から積み上げるのではなく必要に応じて上から順に探査していく方が効率的ですしプログラマー的な思考だと思っています。

 

というか積み上げ式の勉強を信仰してる人を見ると大丈夫だろうかと不安になります。
本を10冊読んだ人より、アプリを1つリリースした人のほうが私は信用できます。
もちろん優秀な人はどっちもやっちゃうんですが、大多数はそれを自分ができると思わないほうがいいです。

 

それにしても前から思ってましたが知識体系化の作業って非常に難しいですね。
なぜ難しいかと言えば、例えばQiitaやSNSみたいなシステムだと評価者が分かってない人ばかりですから(私含め)、いいね数やバズ具合で正しいかどうか判断できませんし。
ブログみたいなのも書き手の事情や出世ゲームや好みや優秀さに依存していますから、果たして自分の事情と合うかどうかは判断が難しいところです。
結局どこまでいっても自分の頭で考えていくしかないというのがプログラマーという職業だと思います。いつか業界の新陳代謝がゆっくりになればそれも終わる日が来るかもしれませんけど、我々が現役の間はたぶん無理そうです。

フリーランスエンジニアの単価と「安すぎる」というコメントの謎

この記事が目についたんですが。

qiita.com

 

良いか悪いかで言ったらQiitaでそういうのは見たくないというのは個人的な感想なんですが。それは置いといて、毎度恒例、はてブでは「安すぎる」というコメントが多く見られました。

[B! エンジニア] エンジニア200人に聞いて、業務委託単価表を作りました - Qiita

 

こういう「単価出してみました」に対する「安すぎる」というブコメは何年も前から大量に見つかります。果たしてこのQiitaは安いんでしょうか?

 

 

私は「妥当」派です


2年前に書いた記事で私が同じような単価感で書いています。

 

otihateten.hatenablog.com

otihateten.hatenablog.com

 

壁の存在も大体似ていますね。6000円あたりから急に難易度が上がっています。

 

じゃあこの「安い」と言ってる人達は何者なんでしょうか?


「私の周りのエンジニアはこんな安くない」と言うようなブコメも何件も見たことがあります。
彼らの意見を総合すると

  • ジュニアクラスでも最低80万
  • 100万はもらわないときつい
  • 140万以下は安い
  • 時給というのがまず意味わからない

彼らのコメントを観察するとどうやらSIerであることがわかります。ではSIerフリーランスはそのくらいもらっているんでしょうか?
月150万円だとすると、年間1800万円です。弁護士や医者の最近の平均が年収1500万円なので、これは夢がありますね。SIのフリーランスエンジニアはひょっとしたらすごい儲かるのではないでしょうか??

 

昔、そう思って頑張って調べたんですが、そんな案件は一つも見つかりませんでした。エージェントにも何人か聞きましたが私の体感の方があってました。
SIerの業界の案件も扱ってるレバテックフリーランスの最高単価が160万円です。普通に検索すると高くて100万円前後です。
PMOレベルになると150万円単価もあるらしいですが、そこまでいくとエンジニアの枠を超えてしまいます。「一般的なフリーランスエンジニア」ではなくなるのでQiitaの記事を「安すぎる」とは言えなくなってしまいます。

 

仮説:会社間の人月単価と混同している?

例えば受託企業で働く時、1人月の案件を幾らで相手の会社に提示するかという、会社間の単価が存在します。
これは当然フリーランスエンジニアの単価よりも高くなります。
例えば昔居た受託企業では、1人月を120万円で相手の会社に請求し、それを1人月80万円のフリーランスエンジニアに作業させて、その利ざやを儲けとしていました。
このような商売になっているので、当然会社間の単価とフリーランスエンジニアの報酬は変わってきます。

彼らはこの会社間の単価とフリーランスの報酬を混同しているのではないでしょうか??

つまり彼らはフリーランスエアプなのではないかと。
SIerというのはほとんどが受託ビジネスなので、人月単価と言うと会社間のソレを指してしまうのではないかという予想です。もちろんWeb系も受託は多いですが、声がでかい人は自社サービスであることが多いので人月単価と言えばフリーランスの報酬のイメージが強いと思います。

 

会社間の単価、フリーランスの単価、正社員の給料の差

妥当性ではなく相場として、大体こういうふうになっていると思います。

 

正社員の給料10万円に対して、会社間の単価が24万円くらいで、フリーランスの単価が16万円。

よりリアルにすると

正社員の給料50万円に対して、会社間の単価が120万円くらいで、フリーランスの単価が80万円くらい。
正社員の給料600万円に対して、会社間の単価が1440万円くらいで、フリーランスの単価が960万円くらい。

正社員は大企業と中小企業でまた違うんですが、ざっくりこのような感じだと思います。
売上1000万円稼ぐ正社員の給料が大体420万円くらいになるので、感覚としてあってるのではないでしょうか?

※この計算は労働分配率の高い中小企業に限られます。大企業だと労働分配率が非常に低いことがあります。

 

正社員の給料と、フリーランスの報酬はなぜ差があるのか

ここらへんです。たぶん。自信薄。

 

フリーランスの報酬と、会社間の単価はなぜ差があるのか

  • 契約形態(準委任、請負)
  • 信用度
  • 作業の広範さやサービスの違い
  • 相場

ここらへんだと思います。これも専門ではないので自信薄。

 

正社員とフリーランス、額面で何倍の差があるか?

フリーランス/大企業 だと1.55倍くらい
フリーランス/中小企業 だと1.35倍くらい

の差があります。
差が大きいほど福利厚生の差があるということになります。

福利厚生が大きい大企業で600万円もらってる人は、中小企業では680万円、フリーランスでは930万円稼がなければ下がった事になります。

 

あと、CTOってそんな稼いでなくない?

ググれば大量に出てきますけど、平均すればだいたい784万円らしいですよ。何でそれがフリーランスになって年2000万円に化けるんですかね?

 

時給にしっくり来ていない人ら

最近Web系では人手不足やら働き方の改革やらなんやらで時短での労働が増えてきたと思います(体感)
そのため副業や複業が増えてきていて、時給という概念が強めに前に出てきています。
あとは準委任契約をすれば140〜180時間など、時間のレンジで契約してそれをはみ出したら精算という形になるので、その時に時給というのが登場します。
最近のWeb系におけるフリーランスエンジニアには時給は馴染みがあるのですが、それにしっくりきていないということは労働形態や契約形態からして別物ということになります。前提を履き違えた上で安いだと高いだの言うのはエンジニアとしてどうなんでしょうか。

 

おまけ:他の業種・職種の単価など

頑張ってググればSIer方面の会社間の単価が出てきますが、上級SEで大体160万円とかそこらへんらしいです。IBMとか日立とか富士通とかそういうところのSEです。いわゆる元請けや1次請け(門外漢なのでググった情報でしかないですが)
Webの受託企業だと会社間で120万円は中々いかないと思います。120万円いくと大企業からも「高いね」と言われるらしいです。昔居た会社でPMが言ってました。
上でも書きましたが、PMOになるとフリーランスの単価が150万超えることもあるそうです。フリーのコンサルの単価はググれば200万とか出てきますけど、案件の難易度が「これ誰ができるの?」というレベルで、個人的には200万でも安いと感じる物が多い印象です。
Web系におけるフリーランスエンジニアの単価は大体65万くらいが平均になってきます。50万切ると安い印象があります。Qiitaの元記事では1,2年目のエンジニアについて言及が有りましたが、ここらへんはそもそも相場形成がされていないと思います。フリーランスって基本的にベテラン前提ですから。
ていうかここらへんってエージェントに複数登録すればすぐわかりますよね。

あと注意したいのがWeb系副業の単価で、副業になると相場がかなり落ちると思います。大体2500円〜3500円/時の案件が結構多いです。商流によってはそうではないケースも増えてきていますが。副業は案件数がまず少ない上に、やりたい人が非常に多いので需要と供給で買い手市場なんです。例えば大企業の福利厚生をある状態で副業をすればフリーランスほどの単価がなくても皆やりたがるんですよね。

 

追記:PMO案件の単価のグラフ発見、中央値で120万くらい?

案件実績 | PMOコンサルティングプロジェクトならPMO案件.jp

 

追記:総合して考えると、大企業の年収800万を超えるようなエンジニアは正直フリーランスエンジニアになってもメリット薄いと思うんですよね。もちろんそれを修行と捉えてその後でまた正社員に戻るなら別ですけど。あとは時短でヌルく生きたい人とかも別ですが。

 

おまけ:120万円の単価を超えるにはどうすればいいか?

前に書いた記事を元にすると、最近の私はここらへんです。

 

f:id:otihateten3510:20210930004954p:plain

完全に「現実的に不可能」の更に外にいってますね。
2年でもう昔考えたラインをぶっ壊しています。
なんか、120万円とか150万円とかそこらへんを超えるには天才でない限りそこそこ無茶をする必要がある気がします。あと「こうすれば超える」というのが無いと感じます。パターン化が難しい。むしろそういう替えの効かない経歴になってくると超えるんじゃないですかね?
超える兆候はあると思います。営業せずに勝手に仕事が入ってくるとか。前に参考にしたmizchiさんも似たこと書いてた気がします。
あとやっぱり法人化はでかいんじゃないですかね。ぶっちゃけよくわからないですけど。
請負にすれば上がるのかどうか、というのは私はまだ知見がありません。請負にすれば上がるのか法人だから上がるのか、最近はラボ契約というのもありますし。あれってたぶん準委任ですよね??

 

まとめ

推測の域を脱さないですけど、勘違いしてる奴らが多いのでは?というのが結論です。

 

こういうコメント見る度に昔から腹を立てていまいた。
例えば自分が妥当だと思ってる報酬があって「安すぎる」というコメントがあったら、それを見た人にとって精神衛生上良いことは一つもないですよね。しかもそれが真実ならともかく勘違いなら尚更です。私はまだそういうのかなり調べるので良いんですけど、若手とかが「月120万円くらいもらえるんだ!」とか「今の会社は不当に安い報酬なんだ!」とか勘違いしたり、「こんな安い単価を受けちゃダメだぞ」を真に受けたりしたら可愛そうだなと思いながらいつもそういったコメントを見ていました。
こいつらただの世間知らずでは?そういうのに限って経営者だったりするから余計腹が立つんですよね。200人に聞きましたというアンケートなのだから、自分の感覚と合わなかった時には前提を疑うべきだと思うんですが。

 

Web系の人は「会社間の単価」というものに対する馴染みが薄めなのでそういうふうな声が出てこないんですけどね(Twitterとかでは安いというコメントは少ない・・・と思ったらバズってきて徐々に出てきました。やはり普段Qiita見てない層に届いてるんですかねこれ?QiitaってかなりWeb系寄りの情報多いのに、そこへ来て定義がどうの言ってるのもクレーマー感すごいです)

 

 

追記:「フリーランスの」と限定していなかったから?

この記事のブコメにもあった、「Qiitaの記事のタイトルに『フリーランスの』がついてない」という話。確かにさっき私も見て私も気づきました。あのタイトルだと会社間だと誤解するかもと。
なるほどこれは「業務委託単価」と言った時に想定するものに個人差があるという、名前空間の問題だったのかもしれません。
(つっても記事内の本文見れば書いてますけどね)
「業務委託単価」と言った時に人によって前提が異なるというのは教訓なのかも?

 

追記:イキリ勢?

なんか不必要にバズってしまいましたが。
この記事に対する反応を見ても、あくまで相場に対する話をしているのに
「150万以上の案件は有る。お前らが見つけられないだけ」だの
「このような安い金額で請けるべきではない」だの
「俺の周りでは皆高い」だの
「弊社はそんな安くやってない」だの
頭の悪いイキリコメントが頭の良い界隈で散見されたので、多分そういう人らも混ざってるんだと思いました。

それって例えるなら「サラリーマン200人に聞いたら平均年収が436万円でした」という話題に対して「1000万円超えの仕事はある」だの「そのような仕事はするべきではない」だの「俺の周りでは皆高い」だの「弊社の給料は~」だの言ってることになるんですが分かってるんですかね?皆知ってますし今そういう話してないです。

 

百歩譲って「こんなに安いとは嘆かわしい。皆もっと上げていこう」とか「具体的な金額を出すと相場が硬直化するから良くない」とか「もっとこうすると単価は上げられる」などは筋が通ってると思います。

 

追記:発注価格で考えてたから?

フリーランスが受け取る価格じゃなくて、発注側の価格で考えると非常に安く感じる説。これもあるかもしれませんね。
私は最近ほとんど直接契約なんですが、世の中の多くはエージェント経由です。
エージェントは噂ベースですが5%〜20%は抜くでしょうから、80万円は、発注側からは84〜96万円に見えるわけです。時給ベースで考えれば5000円が5250円〜6000円に見える感じですね。ただ、その程度の差なら「安すぎる」という感想より「やや安い」くらいの感想が出てきそうですけど。