フリーランス4年目、年収と成長率。あと反省
去年
12月に入ると今年の分確定しちゃいますね。
- 年収・年商と成長率
- 2019年、変わったこと
- 年収・年商、平均時間単価、労働時間
- 通勤時間の圧縮
- 去年のコメントを振り返る
- 年商1500万円は目指すべきなのか？（一般論）
- 複業は有りか無しか
- 来年どうしよう？
- 注意事項
年収・年商と成長率
1495万円
前年比34％増
所感：
1500万円あたりいったのは良かったけど、税金と家賃が高すぎて上がった感じがしない。
諸々反省や抱負はまた別途書きたいです。年末年始の暇な時（あるのか？？）
2019年、変わったこと
サービス開発を一旦止めて、複業化しました。
今年のテーマは複業化でした。どこまで単価上げられるかとか、リモート案件をどう探すかとか。
記事まとめようかと思いましたが、今年は半分以上それっぽい話だったのでやめました。2019年の過去の記事がそれです。
年収・年商、平均時間単価、労働時間
働きすぎ問題
所感：3300時間とかいうわけのわからない数字。これ下半期はもっと稼働高いです。280時間〜400時間。ちょっと無理だなって感じがしました。いや分かってたんですが、一応試してみようかと思って。
この時より働いています。
実録・年1000時間残業するとどうなるか - IT業界で気づいたことをこっそり書くブログ
平均単価上がったのは良かったです。平均4300円（税込）くらい。今は4830円（税込）です。ここ1年の単価は飛び値を除けば税別2500円〜6000円です。ブレ過ぎ。
リモート案件が安いですね、3割位やすい。リモートOKで高くしてくれる優しい会社を探しましょう（希少すぎる） 半リモートだと割と単価維持できます。地方民には厳しい。
エージェント3社使いました。リモート案件は意外なことに「減少気味」だそうです。リモートが上手くいっていないそうです。オフショアと同じですね多分。
今年携わった案件は10案件です（意味不明）
通勤時間の圧縮
なぜここまで働けているかといえば、通勤時間を圧縮したからです。代わりに家賃に跳ね返ってきています。辛い。
365日で割って9.4時間働いているって言うことはつまり・・・？？？
年中無休コンビニ人間ですね。
ﾋｬｯﾊｰ
実際年休は30日くらいだと思います（主に疲れで脳死してぼーっとしてた日）
去年のコメントを振り返る
2019年は、とりあえず現状維持で1200万円はいくので、それプラス個人でサービス開発を継続していきたいです。
個人・・・サービス・・・開発・・・うっ、頭が！！
いや、上半期はネタ考えて結構途中まで作ったんですよ。下半期で死にました。
時間を捻出しなければと思います。
まあどちみちマネタイズを考えてないネタなので、来年もガリガリ働く必要があります。
年商1500万円は目指すべきなのか？（一般論）
無いですね案外。1500万円は。
体壊すほどに無茶するか、相当優秀かじゃないと無茶です。
今年ピークが190万円だったので、12ヶ月続ければ2200万円なんですが、1年持たずに命が危ないと思います。
あとやっぱり複数案件やると、炎上遭遇確率は上がるので、常にアレです。辞めたほうが良いです。
もし目指すなら、とにかく１案件は超安定状態を維持する必要があると思います。
複業は有りか無しか
技術的には少し安定してくるので有りだと思います。
遭遇する課題が非常に網羅的になってきます。
Firestoreも触ったし、ローカルキャッシュも触ったし、RxSwiftも触ったし、一人案件から上場企業までやったし、新人に教えたりもしたし、経験値はかなり得られます。
それでも見積もりミスするからもう嫌だ・・・
来年どうしよう？
もう1年同じ稼働を続ければ1700万円まではいける気がするんですが、それより個人サービスに切り替えていきたいんですよ。
でも税金怖いので結局稼働増やしちゃいそうな。
年明けまでに考えよう思います。
注意事項
なお金に余裕はありません
「わからない」を「わかる」にする方法の話
こちらによく書く話に近いんですが、今回はQiitaに書きました。
13000字・・・・・・
言語化して、色々気づきが合ったので良かったと思います。
わからないことをわかるようにするプロセスは案外ルーチンワーク化できるかもしれません。
- エンジニアリングにおける「わかる」ためのフロー
- 「わかる」とはどういう状態か
- 目的が生じたときの解決プロセス
- プログラム、開発で考えると理解しやすい
- 新人はどのようにしてプログラミング的思考に到達するのか？
エンジニアリングにおける「わかる」ためのフロー
はこういう感じだと思います。
よくもまあこういうフローを無意識で普段やってますよね。人間って不思議。
「わかる」とはどういう状態か
は下図のようなんですが
似たことはずっと考えてました。
ここらへん子供の頃から考えてる気がします。
目的が生じたときの解決プロセス
も言語化できてよかったです。
案外シンプルなんですが、ここに気づくのに結構時間がかかる気がします。
ちなみに現実の業務だと要素が増えます。例えば納期とか予算とか。
プログラム、開発で考えると理解しやすい
面白いのは、現実の複雑な振る舞いやプロセスを、プログラムという仮想上で再構築しているので、現実の複雑な振る舞いやプロセスを理解するのに、プログラムで考えると理解しやすいということです。
プログラムもそうだし、開発業務そのものもそうです。
科学的手法というのは残った理想と現実とのギャップを埋めるための最後の武器という感じがします。
プログラミング的思考って多分ここらへんの話ですよね？これを誰かに教えるというのは非常に骨が折れそうです。
例
新人はどのようにしてプログラミング的思考に到達するのか？
こういう技術は高校生までは「小賢しさ」として認識されると思います。
既に体系化された知識を学ぶ勉強・暗記が是ですから。その思想に誰であれ多かれ少なかれ毒されます。
それでもあまり毒されず、科学的手法・実験的手法が好きな小賢しい奴らがプログラマーになってるのではないかと思います。つまりプログラマーになってから覚えてる人は少ないのでは？という疑いがあります。
でもそういう曖昧な部分ってプログラミングという文脈では悪ですよね。詳らかにしていけたほうが良いと思うんですが、如何せんここの領域に興味を持ってる人が少ない感じがします。たぶん新人はまだまだ苦しむのではないでしょうか？
まずこれらを体系化できたとして、新人がマスターできるのかはよくわかりません。どうなんでしょうか。
NoCodeはさほど伸びないし関わらない方が良いと思う理由
ノーコードがバズってるみたいですね。何度か複数の記事を見ました。
ノーコード系の記事を読むとすごく良さそうに見えてきますが、個人的にこれ系がユーザー企業以外には上手くワークしないのではいうのは数年前から思ってました。私の認識を書いておきます。
・・・
とやる気を出してみたは良いものの、ちょっとこの話だるいですねこれ。
「SaaSもそろそろ頭打ちだしエンジニアが絡んでもしょうがないでしょ、PaaSならともかく」で全部済むと思うんですがどうでしょうか？（投げやり）
- サービス界隈はどうなっているのか？
- SaaS文脈のNoCodeはエンジニアの介在する余地がない
- そもそもSaaS規模が大きいわけでもない
- 新しい◯◯業界は見つかるか？
- EC業界はそもそも特殊
- PaaS文脈でのNoCodeはどうか？
- 誰にとってNoCodeは有益か
- ユーザー事業者にとってNoCodeは有りなのか？
- 新ジャンルのNoCodeをモックや価値検証に使うのは良いのでは？
- NoCode+マイクロサービスがこれからの流行りだろ？
- 使いみちをもっと考えてみる
- まとめ
サービス界隈はどうなっているのか？
大体１個のサービスの形を想像してください。例えばEC、SNS、出会い系、ブログ、人材系、もしくはツールだと写真加工とか、メモ帳なんかでもそうです。
それらをカオスマップにすると大体は以下のようになっています。
少し分かりづらいですが、該当サービスを使いたいユーザー企業が10万あったとして、どこにぶら下がるかという話です。完全フルスクラッチは自分たちで運営するパターン。生成系サービスは自分たちで運営するけど、フルスクラッチではないパターンです。完全フルスクラッチと、生成系サービスの間に実はCMSのようなものがあります（WordPressとかEC-CUBEがわかりやすい）
EC業界が非常に分かりやすいです。
昔はこの「完全フルスクラッチ」が多かったのですが、徐々に汎用の方に流れていきました。要は戦国時代で淘汰された感じです。
歴史的に見ると、ITバブルが専用全盛期、2010年前後が半自動生成の全盛期（CMSのような、数十万円で導入するもの）です。
アプリが登場してからは一気にALLジャンルが増えて、その後徐々にニッチジャンルが増えてきて（というか、規模的に会社が成立するくらいに市場が成長してきて）という感じです。生成系は2010年頃から徐々にという感じですね。スマホ登場後くらいからです。
なので「え、今更NoCodeの領域がバズるの？」という感じで困惑します。なんか遅くない？
って、よく考えたらNoCodeってSaaSみたいなもんですよね、名前を変えただけかもしれません。
SaaS文脈のNoCodeはエンジニアの介在する余地がない
敷いて言えばデザイナーなら介在余地があるかもしれませんが、エンジニアを排除して安く早くあげようって時にエンジニアの存在は邪魔です。
もしやるとすると導入コンサルという立場になります。
そもそもSaaS規模が大きいわけでもない
ここが分かりやすいです
楽天３兆円、Amazon２兆円、ヤフオク１兆円、メルカリ4000億円
みたいな状態で、SaaSであるMakeShopが1600億円、BASEが210億円です。
大体ニッチジャンルの１社２社と流通規模が同じくらいじゃないでしょうか。minneは１つのニッチジャンルですが120億円です。
これらは流通総額なので、手数料ビジネスだと売上はその2％〜10％というところです。規模感的にわかりますか？ 流通総額100億円だと、スタッフ数40人とかそのくらいですし、1000億円だとスタッフ数は数百人だと思います。
海外を見ると大きいように見えますが、やはり他の会社と比較するとさほどでもないです。
新しい◯◯業界は見つかるか？
あるとすればEC業界ではない、未成熟な新ジャンルのサービスのNoCode（SaaS）領域に乗っかることですが、未成熟な新ジャンルが無いんです。
そんな物ないというのは、もう投資家や起業家が何年も頭を悩ませていることです。新しいサービスは出せるかもれませんが、新しいジャンルはおそらく数十年に一度の革命的な出来事なのだと思います。
EC業界はそもそも特殊
いやいや、いろんなサービスが色々出ているじゃないか、と思われるかもしれません。それはそうなんですが、違うんです。「大量のサービスが存在していて良いジャンル」が無いんです。
例えば、ECサイト、メディア、ブログ、コーポレートサイト、くらいですかね？ツール系を除けばだいたいそのくらいです。大体のジャンルは勝者総取りで、すぐに淘汰されてしまうのです。
するとエンジニア的にはその会社しか無いので困りますし、SaaSなんて要らないわけです。位置づけ的にはSaaSとその1社が同じ立場ですね。ユーザー企業相手の商売です。
パターン化できなければNoCode（SaaS）にもできません。
パターン化できるサービスが有るなら、アプリ開発の仕事はもっと多かったと思います。ECサイト構築とかHP制作と同じ文脈でアプリ開発を何となくやって火傷した人の何と多いことか。
PaaS文脈でのNoCodeはどうか？
もっと引いて俯瞰で見ると、サービス界隈はこうなっています。
各ジャンルを全部束ねているのがAppleやGoogleで、支援している会社や、開発のためのツールを提供しているような会社があります。
ここにNoCodeの介在する余地は確かにあるんですが、それってAWSとかGCPみたいな話で、ちょっと今話題になってる文脈とずれますよね。
こっちはもちろんそこそこに伸びると思いますが、お手軽とは程遠いですよね。あれ、めっちゃむずい・・・
もちろんもう少しSaaS寄りで、お手軽に問い合わせフォームを作るとか、ビデオチャットを作るとか、そういうのは増えてる感じがしますがそれもうコーディングしてます。
誰にとってNoCodeは有益か
投資家
確かに収益の増加率は良いんです。そういう時代ですから、あと5年くらいは伸びるんじゃないかと思います。
投資家なら注目していいと思います。
ですがNoCodeの提供側にならない限りエンジニアとしては旨味がありません。
NoCode提供側
これはわかりますよね。
今の時代、会社選びをする時に、選択肢としては
- Allジャンルの会社（大抵大企業、吸収合併が多い）
- ニッチジャンルの会社（小粒だが安定してたりする）
- NoCode（SaaS）提供会社（少ない）
- PaaS, laaSの会社（もっと少ない）
のどれかです。
デザイナー・コンサル
開発以外に強みがある人は、導入支援を仕事にするのもありかもしれません。
でも予想以上に覚えることとか多い印象があります。
あとEC-CUBEとかWordPressのように、わかりやすい一個の市場として確立されていない感じがします。かといって全部覚えるのは無理です。
ユーザー事業者にとってNoCodeは有りなのか？
価値検証するならまずはAllジャンルかニッチジャンルで試した方がいいと思います。ユーザーを連れてくるのが本当に大変です。
例えば物販なら楽天とAmazonとメルカリに出して、売れるようなら独自で出店するで良いと思います。その後でより拡大しようといった際に、NoCodeなのか、ニッチジャンルなのか、となってくるでしょう。
ちなみにオールジャンルで目立つと、ニッチジャンルサービスから直接アプローチがあると思います。「うちでも販売しませんか？」みたいに。
他のサービスでも似た感じです。
新ジャンルのNoCodeをモックや価値検証に使うのは良いのでは？
まず、新ジャンルをNoCodeで作れない可能性が高いと思いますし、ジャンルとして確立された頃には既に市場における価値検証は終わって淘汰が始まっていることが多いのではないでしょうか？
NoCodeで機能作成ができるということはそういうことなんですよね。
たとえば、ある種のトリガーがあって、ヨーイドン！でいち早くサービスを作った人が勝ち、みたいな状況で、たまたまNoCodeで適合するものがあればいいですが、あるんですかね？
また、これがすごく難しいんですが。NoCodeでサービスを作って上手くユーザーが付かなかった時、ちゃんと価値検証できてる自信あるでしょうか。機能追加してまた試したくなりませんか？これまで色んなプロジェクトで色んな起業家を見てきましたが、とてもじゃないですがやめそうになりです。価値検証のパラドックスと言うか、「試し」は大抵の場合その人にとって9割確信があるんですよね。じゃあ二度手間にしかならないのではないでしょうか。
どうにも、上手く使い所がありそうで、本当に使える人は一握りなのではないかと疑っています。
NoCode+マイクロサービスがこれからの流行りだろ？
そこまで行くと設計が必要なので専門性が必要なのではないでしょうか？
NoCodeのPaaSですよね。
使いみちをもっと考えてみる
自分の不得意なデバイスでなにか作りたいときに使うのはどうか？
色々考えましたが、これは有りかもしれません。
例えば私はiOSアプリ開発者ですが「このサービスを作るなら先にWebがあって、その後にアプリだな」というときに「よし両方作ろう」は無理です。
Webの方は凡庸だけど、アプリだと自身がある。でもWebのランディングページが必要！みたいなシーンだと使えるかもしれません。どうなんでしょうか？レア過ぎます？
Laravel覚えるかNoCode覚えるかで迷うことになるんですね・・・うーん。
ファウンダーが動くレベルのモックを作る
これも有りかもしれません。
起業家志望の方がたまにWebを勉強するためにスクールに通っていたりしますが、それよりなら動くレベルのモックアップを作って、「これに機能追加したものを作ってくれ」と依頼を出せば非常にスムーズです。α版として公開してしまうのも有りですね。そんなことできるのかわかりませんが。
企業が超低予算でとりあえず動くものを作る
自社に強みが有り、そのサービスを出せば結構行けると思うけど、稟議が通らない！じゃあ一旦出して反響が多いことを証明しよう、そして稟議通して予算もらってフルスクラッチしよう。
みたいな話では有りかもしれませんね。
社内向けツールとして活用する
あっ、これ結局SaaSの利点一覧だ！
要は
- 採算がさほど見込めない
- 技術者が居ない
- とりあえず作りたい
こんな状況ですか？
まとめ
誤解されそうなので念の為に書くと、もちろんこの領域は適切なユーザー企業が適切な事業ステージで使うには素晴らしいモノだと思っています。
別に新しい概念ではない＋エンジニアが介在できないってだけです。
「新しい概念でない」っていうのは、いつものやつです。
１．既存の上手くいってる概念をグルーピングして、新しい名前をつける
２．それに属するモノだから上手くいきますよ！と喧伝する
１で取り上げられるのは古くからあるサービスだし「今これから来る」と言う説得材料にはなりません。利用するのはいいですけど、技術者的にはニッチの細道に突入する感じになるので、死なないように程々に。
これは一見すると非常によく見えるので、これからどんどん持ち上げ記事が出ると思います。おっさん連中は面倒くさいから見て見ぬ振りするんですよね。
＿＿＿＿＿＿＿＿＿＿
蛇足追記：
SaaSカオスマップを見てみよう
https://thebridge.jp/2019/09/smartcamp-saas-market-report-2019
ガチのNo-Code Developmentの例 kissflow
https://kissflow.com/no-code-platform/
こういうのはもはや「お手軽」「技術者以外が」って文脈は消えて、新言語に近いですね。これは純粋に宗教戦争になりそう。
もう少し中間のNo-Codeの例
https://techcrunch.com/2019/11/04/microsoft-launches-power-virtual-agents-its-no-code-bot-builder/
あ、何で流行ってるか少しわかりました。
これはRPAとかワークフローオートメーションが流行ったから、それをひっくるめてNo-Codeという概念が作られ、案の定言葉の定義が曖昧だから妙なバズワードになってる感じかもしれませんね？
ってなると、やはり基本は業務効率化の方に使うことを意識したほうが良いんじゃないでしょうか？？
まあそっちは伸びるかもしれないですよね。
サービス開発に使うっていうのは応用なのでは？
ちなみにLow-Codeという概念もあるそうです。
フリーランスエンジニアの私が面談のときに確認することリスト
何か最近パターン化が著しいので、せっかくなのでまとめてみます。
何のために面談をするか
- 自分を売り込むため（アピール）
- 採用された際に参加するか見極めるため（判断）
アピール
- 実績（ポートフォリオを作っていく）
- できること、できないことを伝える
- 経緯（ストーリー立てる。これは好みかな？）
- 現在の自分の状況（マッチするか相手に判断を委ねる）
- プロジェクトに関係ありそうな話題がアレばそれも話しておく
判断するための材料
- 自分にとって可能なミッションか？
- 業界、プロジェクトのジャンル
- 会社の状況◎
- プロジェクトの目的◎
- 採用の目的◎
- プロジェクトの状況
- フェーズ◎
- いつからやってるか
- 言語は何か、設計は何か◎
- どういう人がやってるか、チーム体制◎
- 開発部署の立ち位置◎
- 事業のフェーズ◎
- やりたいか
- 自分のためになるか
- 面白そうか
- その他旨味があるか
- 条件
- 金額
- 働き方（週何時間、何曜日）◎
- 立地など
- 環境など
アピールよりこちらのほうが多いです。
フリーランスくらいになると、自分が使い物になるかどうかを採用者より理解している事が多いと思います。
以下補足
会社の状況、フェーズ
これを聞く目的はいくつかあります。
- フェーズによって体制や課題が大体予想できるため
- フェーズによって予算がどの程度あるか予想できるため
- フェーズによって働きやすさが予想できるため
具体的には・・・長くなるので気が向いたら今度書きます。
最近は会社の状況聞くだけでもう大体わかるようになってきました。とても楽です。
目的
大体採用者は直近の目的しか教えてくれませんが、その後どうなるかを知っておくことができます。また、設計に関わります。
言語は何か、設計は何か
採用者の理解がふんわりしていることが結構あります。つっこんで聞かないと蓋を開けたら・・ということが結構あります（5敗）
どういう人がやってるか、チーム体制
例えばiOSアプリだと
- iOSアプリを今開発中の人は何人にてどのくらいのレベル感か
- APIは誰が作っているか
- デザイナーはいるか
- PMはいるか
- POはいるか
- Androidエンジニアはいるか
- その他のステークホルダーは誰かいるか
- テストは誰が行っているか
事業会社の体制は非常に千差万別です。まるで設計のよう。
ヒアリングしたあとでもう一回アピールする
似たような案件の経験があれば伝えます。
あと、大抵フリーランスのほうが経験案件数が多いので、次にどういう問題が起きるか予想がつくかもしれません。次に何が起きるか理解できるなら伝えます。
もしくはできなさそうなら「できない」とか「難しい」と伝えます。
逆に伝えられることも多いです。
面談は共同作業
いつもこういうイメージをしています。
共同作業であり、要件定義に近いです。
「私というXはプロジェクトに対して効果があるかどうか」という文脈は仕事でいつもやっていることです。
おわりに
もちろんこの情報の半分くらいはネットの情報で大体わかるので、わからない部分をすり合わせします。
面接って言うより営業ですねこれ
営業も面接も言葉として強すぎるのでこの界隈では「面談」ってよく言いますが、良いと思います。
イケてる事業が儲かるとは限らないって話
ニコニコの事業が黒字化だそうです。
色んな界隈で終わりだ何だとか言われていましたが、黒字化しようと思えば黒字化できてしまうんですよね。
色んなサービスやイベントをクローズして「ニコニコやべーなもう終わるわ」みたいな声もありましたが、そりゃ赤字事業を辞めれば黒字化するのは当たり前です。
ユーザーが感じる企業価値 ≠ 儲かる
こういう、キラキラ度と実際儲かってるか・売れてるかという数字の間には若干ずれがあります。
これはベンチャー企業だとかなり顕著です。
ベンチャーが一番儲かるのは、キラキラをやめて陳腐化した後です。もちろん一回キラキラしなければなりませんが。
何が起きているのかと言えば、キラキラするために多少無理して赤字を垂れ流してキラキラさせているわけです。もしくは単純に規模が足りていません。
私達は企業やサービスの価値をはかる時に、ユーザーの規模は考慮に入れません。
でも企業にとってはユーザーの規模で全然結果が変わってくるのです。
あと、案外勝ちがあるからと言って勝手に規模は増えてくれないんですよね。
キラキラしたいのか、儲けたいのか
会社選択のときも、キラキラしたいのか、堅実に儲けたいのかは選ぶべきだと思います。
案外世の中の人はキラキラ＝儲かるだと思っているようですが、キラキラ≠儲かるなので、4象限にわかれます。
もちろん僅かに花形の会社は存在します。これがトップに来るのは間違いないでしょう。
よくある選択肢としては、③道楽的事業 ⑥仕事的事業 ②一般的事業です。
これらは一次元上にありません。
簡単にどういうことかと言うと、
評価が高いけど儲かってない事業 vs 儲かってるのに評価が低い会社 vs 可もなく不可もなく
です。
事業はどの方向を目指すべきか
ニコニコは完全に③の事業が多かったですね。税金対策とも言われてました。
①に行けたら良かったですが、今回は②に向かいました。
②から①へ向かうルートもあります。仕組みづくりを頑張って、楽しい世界を構築するんです。私はこれが結構好きです。
ベンチャーは大体③→②が多いと思います。
⑥の仕事的な利益追求事業は、儲かりますが①へ上がるのは至難の業でしょう（②に行くこともない）
今の仕事のフェーズを見極めて、ある程度妥協するのも必要
良い会社、良い事業と言った時に、どうにも一次元で語られがちですが、私は二次元だと思います。
なので、事業の方向がどっちを向いているのかを見極めないと不幸になると思います。
両方取りに行くのは至難の業です。
また、会社はこのフェーズを時にガラッと変えることがあります。
特に上場前後では変わりがちです。今会社はどういう方にいこうとしてるか、その結果自分にとって良いのか悪いのかは確認していくべきでしょう。それが理解できれば進退もハッキリ決められるでしょうけど、理解できないままだと何かよくわからないまま嫌な気分になって辞める羽目になるかもしれません。
フリーランスとかいうイレギュラーな存在
ちなみに③の道楽フェーズでは社員より外注のほうが関わるのに美味しい印象です。
もちろん皆それを知ってるから外注が殺到して結果業務が苦しくなったりもするんですけど。
私がよく言う事業の状態ワード
あの会社、キラキラしてんね → ③道楽
あの会社、イケイケだね → ③から①花形への過渡期か、①花形
普通の会社になったね → ③から②への遷移
うまくやったね → ②から①への遷移
Bだね、toBだね → ⑥仕事的 （※語弊がある）
必要だよあそこは → ④社会に必要
これあかんでしょ → ⑤クソ
（これいる？？）
近況 2019/11/04
＊＊＊
8月9月10月、特に10月の高稼働は歴代最高タイくらいでした。
エグい。
おかげで月商も歴代最高でしたが（そのうちまたグラフにします）
１ヶ月以上高稼働を続けると、１週間くらいはダウンしてしまうんですよね。
丁度今は切り替え時期であまり稼働がないのでぼーっとしています。
＊＊＊
2年9ヶ月勤めた会社を退場しました。
長かった。
3回くらい辞めようかと思いましたが、結局複業に切り替えて継続しました。良かったと思います。
フリーランスとしては長いと皆言いますが、でも最長で30年くらいフリーランスすると考えれば、1年1社くらいのペースだと30社くらい必要なわけで、そのうち消化してしまうのでは？という懸念もあります。そんなことないか。
ちなみに今年関わった会社はもう10社です。マジで声を掛けていない会社が減ってきました。。。
＊＊＊
最近、ありがたいことに会社の方から声がかかることが多くなりました。
もうここまで来ると仕事にこだわりも無いので割と受け付けています。複業化したのがかなり大きい。
それにしても何で会社から来ることが増えたんでしょうか？
Wantedly、Codeal、あと他のサービスにも稼働状況を書いたからですかね？（１１月から空いてます、とか）
＊＊＊
それにしてもせっかく休めているのに元気がゼロで何も手が付きません。
やばい。
Qiita書こうと思ったんですが、200字くらいで飽きました。休んでるときのダメダメっぷりがダメすぎてダメ。
エンジニアタイプ 傾向と対策１
エンジニアをタイプ別に分類しようとした記事が妙にバズりました。「レーダーチャートが良いのでは？」というコメントが有り、なるほど確かにと思いました。
昔考えたネタでさほど気に入ってるわけでもなかったんですが、「試みは良い」みたいな反応もいただきました。そう言えば、あまりこういう話見ないような？「エンジニアの特徴」はよく見かけますけど。エンジニアの中にも色んな人が居てかなり多様ですよね。じっくり話してみないと分からないケースが多いですが。
こんな分け方もできますね（いや、やっぱ見づらいな。しっくりこないし）
今回は、このタイプ別分類について少し掘り下げたいと思います。
面倒くさい話します。
- タイプに分けて考える意義
- 興味欠落エンジニアは問題なのか？（解決思考タイプの苦悩）
- とは言え、モチベーション分析は有益
- モチベーションと興味を知る方法
- 興味の種類を沢山知る必要がある
- 意見の不一致から興味の軸を発見する
- 仕事に必要な興味と、自分の興味を比較する
- おわりに
タイプに分けて考える意義
タイプってレッテル貼りっぽくてあまり良いイメージがありません。血液型とか、◯◯系男子とか、偏見の温床だしあまり好きじゃないです。
それでもタイプに分けようと思ったのは、どうにも話が通じない人が多いと感じたからでした。
私は強めの解決思考タイプなんですが、仕事において「解決すべき問題」は「プロジェクトの問題」になりがちです。しかしプロジェクトの成功に意識が向いていない人は結構多いと気づきました。
話をする時、その人の興味フィルタによって、話がぜんぜん通じなかったり、別の意味に変換されて通じたりするということがよくあります。
これらのタイプ分類は、主にモチベーションにおける分類です。その人が最終的に何をしたいかをベースで分けました。
でもそれは、見方を変えれば「どの興味が欠落しがちか」という興味フィルターの分類にもなると思います。
（もちろん明確に別れることは稀で、人によって少しずつ混ざっていると思います。興味のモチベーションも異なりますし、完璧に分けるのは不可能でしょう）
興味欠落エンジニアは問題なのか？（解決思考タイプの苦悩）
技術、作り方、プロジェクト、チーム、事業、意義、ユーザー、デザイン、働き方、などなど。本来は全ての要素に対して程度の興味を持って仕事に取り組むべきだ。さもなくばプロジェクトが失敗する。興味が足りていないのは良くない状態だ！
・・・というのが4,5年前くらいの私の考えでした。
ですが、よくよく考えてみると、その発想はあくまで解決思考タイプの目的から生じた話でしかなく、結局エゴでしかないのでは？ と思うようになりました。
「でも、みんなが全方位バランス良く興味を持たないと事業は潰れるし回らなくなる！！」と当初は正当化も試みましたが、よくよく社会を観察すると、そうじゃなくても割とどうにかなってるらしいというのがわかりました。
最近似た話を書いています。
「皆ちゃんとやらなきゃヤバいことになる！」というのが正しくないとしたら、もはや「誰もが全てに興味を持つべき」というのも嘘で、「プロジェクトを上手く解決したい奴が解決すればいい」程度の話でしかないのかもしれません。
補足：チームプレイ問題
分かりづらいのでもう少し。
RPGゲームに喩えると、私の発想は「皆が全属性魔法使えるべき」でしたが、「そうじゃなくても割とどうにかなってる」あるいは「皆が全属性持っててもダメな時はダメ」になってきた感じです。
とは言え、モチベーション分析は有益
誰であっても自己の目的のために、チームで足並みを揃えていくことが必要になると思います。
しかし誰かと話をする時、自分と相手の興味フィルタがずれてると、もう１ミリも話が通じない！みたいなことが起こります。
モチベーション毎にタイプに分けたり分析するのは、そう言う点では有益です。
自分の持ってるモチベーションや興味、そして自分が持っていないモチベーションや興味が分かれば、相手と話がずれていることを発見できたり、コミュニケーションしやすくなると思います。
モチベーションと興味を知る方法
何かを評価すると、興味の対象とモチベーションが見えてきます。
例
このプロジェクトは最悪だ、なぜなら最新から3世代も遅れている開発手法を用いているからだ。
ここから更に掘り下げます。
例
「なぜ世間から遅れている開発手法を用いたらまずいの？」
→ 技術的な問題が有るから
→ 人が採用できなくなるから
→ 上手く回っていない証左だから
→ 使えない機能があるから
→ 自分のスキルが伸ばせないから
色んな答えがあって、その根源的な原因が興味の対象やモチベーションになってきます。
これは自分でもできますし、他人にも使えます。
興味の種類を沢山知る必要がある
例えば「りんご」という事象を用いて自分のモチベーションを分析した時
- 見た目
- 味
という評価で分けるかもしれません。
でも、色んな人にりんごについて意見を聞いていったら
- 色
- ツヤ
- 形
- 産地
- 糖度
- 渋み
- 大きさ
- 柔らかさ
と出てくるかもしれません。
この細かな興味の種類を見つけるには、色んな意見を聞いてみて、発見していく必要があります。
意見の不一致から興味の軸を発見する
同じりんごに対して
Aさん「このりんごはダメだ」
Bさん「このりんごは最高だ」
こういう意見が見つかった場合、原因は主に3つです
- 観測が異なっている（別のりんごだと思った。見たときの条件が違った）
- 度合いが異なっている（AさんはBさんより及第点が高く、厳しい）
- 興味のポイントが違う
上2つを棄却できる状況では、興味のポイントの差だと思います。
「じゃあ何でそのりんごは良いと思うの？悪いと思うの？」と掘り下げれば、新たな興味の軸が発見できるかもしれません。
（大抵は既出ですが）
仕事に必要な興味と、自分の興味を比較する
実は、会社・事業自体も人のように興味の特徴があります。
法人格なんてよくいったものです。
「誰かと話が合わない」はまだ致命傷にならないかもしれませんが、「会社と話が合わない」は割と致命的です。
それを回避するために２つの戦略があると思います。
１つは、不足している興味を補い、不必要な興味を抑制する方法（バランス型）
もう１つは、共通している興味を伸ばし、不必要な興味を抑制する方法（特化型）です。
可能なら両方できればいいと思いますが、どちらか一方でも十分だと思います。
どちらにしても、会社（事業）の興味と自分の興味を知らないと始まらないんですが。
おわりに
あ、傾向と対策まで話せていない。
書き始めたら難解になってしまいました。その２は・・・書ける自信がないです。
書けていないことメモ（後で消す）
・バランス型か、特化型か
解決とか、職業とか、事業とかはバランス型、ものづくりとか技術とかは特化型
・真面目に戦略をしている組織であっても、必要になるのが通訳者
通訳者になるべきか？
メリット：プロジェクトをコントロールする立場になりがち
デメリット：プロジェクトをコントロールする立場になりがち、イラつく
特化型社長
特化型 ー バランス型（通訳者） ー 従業員
価値観の存在を理解してくれる特化型は神
価値観の存在を理解してくれない特化型は通訳者泣かせ
バランス型が一人も居ないと崩壊する
→と言っても採用リセマラになるだけなので、案外どうにかなる
・会社に必要な興味はどうやって割り出す？ → 難度高い
・完全一致する会社はすばらしい、でも他のスタッフがあってるとは限らない
・傾向と対策
