見出し画像

現役年商1000万越えエンジニアが駆け出しや未経験に伝えたい成長術【実例6例5名分】

ITアビス

こんにちは。ITアビスと申します。

このNoteでは現在未経験で転職を考えている方やエンジニアとして転職に成功し、これから実務に着く新人エンジニアの方向けに、私のように年間で1000万稼げるエンジニアに共通する働き方、成長術をお伝えします。

私が実際に参加したプロジェクトや、そこで出会った人々を紹介しながら話を進めますので、実際の現場の感覚をイメージしながら読み進めてもらえると嬉しいです。

誇張表現や嘘は一切ありません。全て実体験で、本気でエンジニアとして成長したい方向けの内容となります。

気がついたら1万字を超えてしまいました。

読みにくい箇所があれば気軽にTwitterから連絡ください。定期的に情報も発信していますので、フォロー頂けますと幸いです。


楽して稼ぐことは現実的ではない


早速ですが、楽して稼ぐことができたらいいなと思ったことありますか？

ありますよね？

実際にネットには

・１日５分で月収１０万円

・完全自動で簡単に稼げる

・月収１０００万円を稼ぐ簡単な方法

このようにインターネット上には簡単に楽して稼ぐことができるかのように謳っているサイトや人が多くいます。


しかし、実際に楽をして稼ぐことは私の経験から言わせてもらうと絶対にできません。


Twitterでも、数億と稼いでいて情報発信をしているインフルエンサーの多くが駆け出しのころに圧倒的な作業量をこなしていると発信しています。

しかし多くの方がその事実に目を背けがちです。

会社員でも実は同じことが言えるのです。


継続すれば成功するのは当たり前


私は在籍中に社員数を10名から30名ほど増やした会社を２社ほど経験しました。

どちらの企業でも共通していることは多かったです。


・組織の体制図を作りたがる（縦割りにしようとして我先にと上に立ちたがる）
・エンジニアは技術力を社外に発信しようと試みる(Qiita Teamなど)
・HPやFacebook,SNSへの情報発信を行う


等々色々あるのですが、

社員で私がやりますと宣言して継続している人は2割に満たず、その中で実績を出せた人は１人くらいしか知りません。


なぜこのようなことが起こるのか？


それは自分が受け取る対価が見えていないからです。


・ブログを1ヶ月頑張っても収益にならない。
・技術力の情報発信を1ヶ月続けても給与が上がらない。

この事は最初の内容に密接に結びついています。

「実例1: 副業ブログを始めたアビス」
私は数年前にメインの案件をやりながら副業的にブログを始めたことがありますが、本業の稼働に押されて長続きせず、ブログのために借りたレンタルサーバ代と平日夜、休日を時間の無駄にしました。

自分の技術力を過信していた時でした。

どれも簡単にできるのだから時間なんていくらでも取れるだろうと。
正直甘かったです。
「実例2: 会社員としてQiita Teamsで技術情報を量産したアビス」
社内の評価になるからということで技術責任者がQiita Teamsを作りました。

若手エンジニアが多く、給与も少ないため私たちは必死に書き込みます。

私は責任者に続いて2番目くらいにいいねをもらえるような記事を沢山書いたのですが、給与は全く上がりませんでした。

そのうち炎上案件の対応でほぼ全員が忙しくなり、誰も更新しなくなってしまいました。


稼げるようになるという観点でこれらを見ると、どれも全く的外れの努力をしています。

どれも自分のメインの仕事の時間を削って行うことですので、メインの仕事がどれだけ安定しているかに引っ張られてしまうのです。


まずはメインの事業、業務で稼ぐことに集中しよう


エンジニアとしてのスキルで稼げるようになるまではエンジニアリングの習得に集中しましょう。

ブログ、SNSでのアウトプットなどは最小限にとどめ、繋がりを増やす目的にとどめた方が良いです。

個人なら年間1000万、会社員なら企業の社員としてメインで受注し開発まで行なった金額が1000万/1案件を超えるくらいが目安かと思います。

ここで疑問が出てくると思います。

稼げるようになるエンジニアとはなんなのか？

それを説明するために、手始めに労働の種類についてお話します。


そこから実際にエンジニアとして稼げるようになるための成長術について説明しましょう。

労働の種類には時給と成果による労働の２種類があります。

時給労働


世の中の大半の人が時給労働をしている人が多いのではないでしょうか。時給労働の中にはアルバイトや派遣社員などの人が当てはまります。


実際に私も大学を中退した後はホテルで派遣社員として働いていました。

この時は、派遣社員で時給で働いていたので自分が長く働くことでその分のお金をもらうことができました。

しかし、私は当然ではあるものの、とても大事なことに気がついてしまいました。


「時給労働は最大でも365日24時間の限りがある」

当たり前じゃん。と思ったあなたに私のケースを紹介しましょう。

実例3：「ホテルマン時代のアビス」

時給も安い中、若かった私は試しに１年間毎日ホテルに泊まり込みで働くことにしました。

幸いスポーツもしており、体力にはかなり自信がありました。

泊まり込みの宿直は固定給ですが、途中仮眠の時間もあるため楽勝だろうと。

簡単な計算です。
680/h * 12 + 5,000/d * 365 = 4,803,400
時給は当時の沖縄の最低賃金でしたが、沖縄で20くらいの若者にしてはかなりの額が入る計算です。

頑張った結果結果どうなったかというと。

年間で2,200,000円の稼ぎにしかなりませんでした。

1,2ヶ月は予定通りでしたが3ヶ月目から変化が訪れます。

・まず体を壊し欠勤、中抜けが増えました。
・栄養剤や医療費が増えました。
・作業ミスが増えさらに仕事は増えました。
・睡眠不足でイライラすることも多くなりタバコの本数もかなり増えました。
・家に帰ってもいく場所がないのでホテルで意味なく過ごすことも増えました。

まるで一人ブラック企業です笑

周囲の方々は上司含めとても優しいかたが多かったためなんとかなっていましたが、社員でもない私は普通なら即クビです。


時給での労働は決まったルーチンの仕事が多いこともあり、
体を壊してまでして手に入れたお金では自分のことを成長させることはできないことも認識しました。


これも私がエンジニアを志すようになったきっかけでもあります。
エンジニアになれなければ料理人か、車の整備士になろうと思っていました。


とにかく手に職をつけなければという思いでいっぱいだったのです。


成果報酬労働


時給労働の真逆の働き方が成果報酬でお金を得る労働方式になります。

正直、私が最初にエンジニアになった時にはエンジニアも時給労働のように働けば働くほどお金をもらうことができるものであると考えていました。


しかし、この考え方はエンジニアにおいてはほぼ当てはまりませんでした。

確かにエンジニアである前に会社員ですので、時給での仕事になってしまうことは否めません。

しかしエンジニアの場合、長時間働くことのみを望む現場は多くありません。

・成果を出していれば短時間の勤務で良い

・成果を出していればいくらでも働いて良い

のどちらかであり、必ず成果は必要なものとなります。

そのため、優秀なエンジニアとして認められるために必要なスキルはいかに効率的にシステムを作ることができるかになります。


逆に技術力が高くても効率を考えてシステムを組むことができない場合は周りに人に認めてもらうことが難しくなるのです。

これには納期から逆算して自分のスケジュールを決定していく自己管理能力も必須です。


納期（顧客の希望）に間に合わないといくら技術が高く効率的に仕事をしていても評価されることはないのです。


はじめのうちはこれに気がつかず、時間をかけて頑張れば認めてもらえるとばかり思っていました。


でもそれは未経験で転職したため周囲が気を使ってくれているだけだと気がつきました。


成果が出せないのは上司の責任であり、社員に責任はないと多くの経営者は考えます。(最後に在籍した会社は違いましたが笑)


そしてそれは成長したい未経験エンジニアにとっては有難迷惑になることもあるのでした。

私は気がつかず、努力しているのが認められていると思っていましたが、結局のところ実績で見たら上司のエンジニアの1/1000以下でした。

その時の話をしましょう。

実例4：「未経験エンジニアとしてAさんとの初案件」
Aさんは専門学校を出て別業界を経験した後30代前半で組み込みエンジニアになりました。

そこから会社を渡り歩き、Webやネットワークなど様々な技術を身につけ、フリーランスも経験した後、当時私が入社した会社で役職付きで採用されました。

Aさんと私の年の差は20くらいあり40前半でしたが、新しいものが大好きな人でしたので、若い人と打ち解けるのも早かったです。

転職して初めての案件で私はAさんがPMのチームに配属されました。

任された仕事はWindowsのアプリケーション開発です。
私は必死にアプリケーションを仕上げました。

未経験にしてはよく動くものができたと当時は思い、レビューを依頼したところ、昔ながらの紙に書くタイプの赤ペンレビューで3000行ほどのソースは真っ赤に染まりました。。

全て直してと言われました。

フリーの経験もあり、かなりのエンジニア気質だったため、未経験エンジニアかつ若手社員に対しても確実な実績を求めるタイプでした。

PMとしてAさんは私を１人月で計算していると言いました。つまりレビューはするがサポートは期待するなということです。

今見れば自分でもとんでもないソースを書いていたと思えます。

当時は知る由もなく、何でこんな実装しなくちゃいけないんだと若干不満に思いましたが、実際指定の操作をすると動作がおかしくなることも確認できたため、私はしぶしぶ修正を行います。

しかしすでにあるソースコードが頭に残っているため混乱し全くうまくいきません。

さらにAさんの弱点はエンジニア気質すぎて何かを伝えるのが苦手なところです。

操作上のうまくいくように見えても、Aさんはソースコードから起こりうるバグをほぼ把握していました。

今ならわかりますが、Aさんの指定した修正方法はOSSとしても使用できるくらい汎用化、分割された仕組みとして実装することだったのです。

当時は何を聞いて良いかも分からなくなり、時間だけが過ぎていきます。

2,3週間ほど経っても進捗が上がらず、3日に一回は徹夜し、F5(デバッグ)を意味もなく連打するくらい精神的にも追い詰められていました。


期日ギリギリ、計1ヶ月になってAさんは動きました。

1.5日ほどでプログラムを書き上げたのです。

ソースの量は1/3の1000行ちょっとに減り、バグも無くなっていました。



実際にはあの規模でそこまで汎用化された仕組みは求められませんが、私への教育も兼ねて、そこらへんにいるようなエンジニアになって欲しくなかったとAさんは後で教えてくれました。


能力の差を直近で見せつけられたときから、私は最速でこの上司に追いついてやると心に決め、努力をはじめました。

現在の私の月商は月100万ほどですが、Aさんは再びフリーとして140万ほど稼いでいるそうです。もうちょっとで追いつける。こうやって記事を書いていても慢心することなく努力しなければいけません。


さて、いよいよ本題です。


これからお伝えするのが私がエンジニアとして実力をつけるために実際行なった内容です。

成長のためには努力→経験→思考のループ

この言葉を覚えておいてください。


努力を習慣化する

楽して稼ぐことができると言う文言について行ってしまう方は、努力をすることが苦手な傾向があります。


努力をすることが苦手な人には以下のような人です。

・大学受験の際に努力をすることなく自分のレベルでいける大学に行く
・練習をすることなく試合だけに出ようとする
・嫌なことがあったらすぐに逃げて他の選択肢を取ろうとする
・すぐに結果がでないと続けることをやめてしまう

私は努力をしない人間のことを否定するつもりは全くありません。
むしろ私もAさんだって同じタイプです。

私たちに共通していたのは、お金を稼げる人間になりたい（≒エンジニアとして技術力を身につける）ということであり、そのためには努力が必要不可欠な要素です。

私は、ホテルマンからエンジニアになりました。

ホテルマン時代の知識などエンジニアとしてはほとんど役にはたちません。

本来エンジニアは大学で情報工学を学んだ人がなるものです。
だからこそアメリカでは新卒で1000万を超える給与が支払われるのです。


私はエンジニアになってからほとんど遊んだ記憶がありません。私のような人間にとって一番重要なのが努力を怠らないことでした

努力は苦手な私ですが、一つこれは確実だろうという勉強方法はわかっていました。

「その環境に身を置く」ことです。

よく英語の学習で何が一番効率的かという議論になった時、「英語圏の国で生活すること」という話がありますよね。


稼げるエンジニアになるなら自分に入ってくる情報を全てIT関連の話題にしてしまおうということです。

これは正解でした。

私はエンジニアになってからは仕事をしていない時は全て勉強の時間に当てていました。


ニュースのレコメンドもIT関連の話題ばかりに設定しました。

当時の私の仕事はSIerでしたが業務に直接関係ない知識も選ばずに取り込みました。


・Webサーバ
・DBサーバ
・メールサーバ
・プログラミング言語の歴史
・ネットワーク
・HTML/CSS/javascript
・自宅サーバ運用
・最新の有力技術
・プロジェクトマネジメント
・パソコンの分解、組み立て
・プログラミングのベストプラクティス
・OSSライブラリのソースリード
他にもたくさんあります。


ニュースで流れてきた情報は端からチェックし読み込むことを続け、実際に自分で構築、実装まで行うことでより具体的に理解ができるようになります。

勉強なので周りから認められることや勉強に対してお金が発生することはありません。


しかし、仕事をしていない時間を全て勉強に時間に当てたことでエンジニアに関する知識のみではなくIT全般の知識を吸収することができました。


死に物狂いで学習することで「学習をする」が「生活の一部」に変換され、その後も学習することに対して苦を感じなくなりました。


もし私が本気でライターになりたいなら、出版社やメディア運営をしている会社に転職することから始めるでしょう。

あなたが本気でエンジニアになりたいなら、スクールに通いながらでも転職活動を最優先させましょう。

私は転職相談も受け付けていますので、連絡いただければ相談乗りますよ^^


経験とコミュニケーション能力

稼ぐためには努力をし、知識を取り込むことが必要なことは理解いただけたと思います。


しかし、知識の蓄積だけでは稼ぐことができません。

同じくらい重要なのが経験とコミュケーション能力です。


この業界で働いているとソース量数10万行に上る膨大なプログラミングで動いているシステムの改修を行うこともあります。


そんなレガシーな仕組みには興味ないと思われる方もいるかもしれませんが、稼ぐことに重きを置いた場合にはそんなこと言っていられません。


10年20年と稼働しているシステムがある理由について考えてみてください。

それだけの保守費用、人件費をつぎ込んでも存続させなければ経営的にダメージがあるからです。


つまりそれだけ大きな金額のお金が動いているという裏側を意識しましょう。


実際にそのような大規模システムのエンジニアは非常に高単価で、保守で月120万という案件もあるほどです。


このような大規模システムにはほぼ間違いなく長年関わっているエンジニアが存在します。
彼らは新人の時からそのシステムしか知らないまま5年10年と過ごすことも珍しくありません。


実際に経験したプロジェクトについてお話ししましょう。


実例5：「古参エンジニアBさんのコミュニケーション能力」

エンジニア4年目くらいに上でお話しした大規模プロジェクトの保守に応援として呼ばれたことがありました。

そこで古参メンバーのBさんと出会います。

Bさんは私と同じく外部の会社から派遣されているエンジニアでしたが、そのシステムに携わって10年以上経ち社内の誰よりも精通しているとのことでした。

年齢は私と比べて10くらい上の30台後半、人柄も温厚で、敵を作らないタイプの方でした。

プロジェクトに参加した私は早速担当チケットをみて、既存のソースコード、現行システムの動きを確認しました。

その時は前述の努力の甲斐あって、大抵のシステムであればすぐ動きを把握できるくらいの実力を私は身につけていました。

パッとみた感じ、数万行の共通のソースコードとそれを使用し実装された30ほどのシステムが稼働しています。

まずは相談します。どのあたりが原因と考えられるのか？

すぐ回答をもらうことができました。

よくあることで後から実装した関数に変更すれば直るはずとのことです。これです。
と送られたリンクにあった関数に書き換えて早速実行してみました。

一発でバグは解消され、チケットは完了になりました。

今度は同じような（Bさんが同程度の優先度、規模感をつけている）別チケットを担当し、学習したいと申し出て自分でソースを追ってみました。

丸1日かかりましたが原因はつかめたので、疲れた顔でBさんにこれで良いですか？と確認をとりました。

ものすごい喜んでいます。

なかなかその部分の実装を追える人はいないと言われました。

Bさんにとっては初めてのことらしくかなりテンションが上がっていたのが印象的でした。

しばらくするとわかったのですが、プロジェクトメンバーのほぼ全員がまずBさんに聞きにくるのです。

Bさんは丁寧にそれに答え、定時をすぎて質問にくる人がいなくなってから自らの作業に取りかかるという日常を送っているようでした。

問題のソースコードも確かにソースが古すぎてIDEの参照ではリンクができず、スペックの低い作業用PCで全文テキスト検索で関連しそうな関数を探すところからはじめています。


検索した後も同じような名前の関数が10ほど点在し、微妙に内部の処理やインターフェースが異なっています。

それぞれが2000行ほどの関数ということもあり、細部を追うよりはBさんに聞こうという思考にみんな行き着くのでしょう。

時間がある時を見計らって詳しくヒアリングすると、基礎となる仕組みに合わせてどうしても分けなければならず、歴史や政治的な背景から泣く泣くそうしていると説明を受けました。

ちなみにBさんはそのシステム以外の技術、ついてはそのシステムが組まれている言語についてでさえも興味がないようで詳しくありません。

Java以外書いたこともないしlamda(Java8からの機能)が使えるようになったのも知らない。あのシステムでは今後も使わないだろうと言っていました。


それでもBさんは定年まで20年ほど安泰でしょう。


聞いたところ給与も十分とのことでした。

10年という経験が技術に興味のないBさんをベテランのエンジニアにし、大規模システムに欠かせない存在にしたのです。


Web系の企業に入社した際に、私は最大で5つくらいのプロジェクトを同時に掛け持ちしていました。


前任者が退職することになり一挙に引き継ぎを行ったのです。
顧客の業種は
・教育
・人材派遣
・情報通信
・化学
・社会福祉
と多種に渡りました。

顧客と話をする際に必要になるのが業務に関する知識です。
それがないとシステムができても現場の業務に則さない無駄なものになってしまいます。

様々な業種で働く方のリアルな声を聞き、一緒に業務改善方法を考え、既存のソースを読み込んだ経験がBさんのプロジェクトで成果を出すことにつながったと考えています。


おそらく予備知識なしに参加したら他の方同様にBさんに質問を投げて回答を待つ日々だったでしょう。

何にも得られません。

このコミュニケーション能力に関してはホテルマン時代の様々なお客様との会話から得られたとも思うので、あの薄給激務も決して無駄ではなかったと実感しました。


逆にBさんは定年まで安泰ですが、仮に別のプロジェクトへ移動になった時技術面で苦労することになります。


10年稼働した全く汎用的でないシステムに関しては一流ですが、その他の技術は持ち合わせていません。

一方で色々な方が気軽に話しかけにくるBさんを見て不思議にも思いました。

先ほどお話ししたAさんは必要なこと以外で話しかけにくる人はほぼ決まっていました。


むしろそれまで経験してきたプロジェクトでもエンジニアは周囲と孤立したり、すでに決まった仲間内で盛り上がることがとても多かったのです。

一方でBさんにはプロジェクトに関係ない人（総務や営業）でも雑談にきます。その中には社長や副社長もいるのです。

Aさんとは逆の存在に出会い、私は業務知識の必要性を裏付けすることができ、経験とコミュニケーション能力の重要性に気がつくことができました。


私はAさんの技術に対する姿勢を真似て努力を継続しましたが、コミュニケーション能力についてはBさんの人柄を見習おうと決めました。


チームでの開発ではAさんのような技術に尖った人材よりもBさんのように周囲と調整ができる人材の方が重宝されることに気が付いたのです。


自ら思考し行動できるエンジニア

技術力の身につけ方や多様な業務への適応力、人間関係構築の重要性をお伝えしましたがいかがでしょうか？


これからエンジニアとしての成長をさらに加速させる要素についてお伝えします。

これは最初に事例から紹介しましょう。

事例6：「新卒、未経験エンジニアCさんとDさん」1/2

私が企業に在籍したいた時、未経験で入社した2名の新人がいました。
CさんとDさんとしましょう。

Cさんは大学卒業後新卒で入社しエンジニアになりました。
Dさんは高校卒業後営業の仕事をし、転職して未経験からエンジニアになるために入社しました。

どちらもコンピュータサイエンスとは全く関係のない分野でしたのでスタートは一緒です。

当時在籍していた会社では、未経験で入社した社員には同じ研修を受けてもらった後にプロジェクトに配属される流れとなっていました。

CさんとDさんも例に漏れず研修を受けることになりました。

実はこの研修未経験組に受けさせようとなった時、すでに在籍していた私たちのようなエンジニアの社員にはかなり評判が悪かったのです。

なぜなら内容が

・朝から晩まで全てが集団行動で無意味な声出しや30kmの徒歩移動（個人のペナルティはチームの責任として評価ダウン）
・2時ごろまで睡眠は取れずにダンスの練習（判断力の低下）
・教官からの圧迫的な指導（上に従うことの強要）

であり、まさにブラック企業が自分たちに都合の良い社員を作るための研修だったからです。

3日ほど合宿形式で行われる合宿を経て飲み会でCさんとDさんに会う機会がありました。

Cさんはガラッと雰囲気が変わっていました。
かなり低姿勢になり、社長にあからさまなおべっかを使うようになっていました。
聞くと研修のおかげで自分がどれだけ至らなかったかを自覚したと言っていました。

Dさんは何も変わりませんでした。
めっちゃキツかったんですよ！と笑いながら周囲に話題を振りまいていました。



二人の大きな違いは自ら思考することができないCさんと、自分の考えを持っているDさんという点です。

一つのバグ改修の流れをイメージしてください。
エンジニアとして与えられた情報を元に、バグの原因を発見し、ソースコードを修正する必要があります。


バグを発見する手法は様々あります。

・OSSのツールを使用する
・画面上で手作業で１件ずつ調べる
・APIのみをブラウザでアクセスし結果出力を調べる
・一連の流れを実行するツールを作る

ソースコードを修正する方法も色々です。

・バグ改修部分のみを修正する
・その他の機能の同様箇所も同時に修正する
・その他の箇所は現在稼働していないので対応不要

仕様通りだが業務要件を満たしていないように見えるため仕様自体の調整を行わなければならない場合もあります。


もらった仕様通りに組んだので仕事は終わりました。

としていると、調整になった場合に作り直しになるケースがほとんどです。
その指示が本当に正しい指示なのかは必ず意識する必要があるのです。


エンジニアとして知識や経験による感覚を身につけたあなたが次にするべきことは、与えられた課題を解決するための最適な手法を自ら考え試すことです。

Cさんのように他者の意見に流されてしまうのが一番良くありません。

事例6：「新卒、未経験エンジニアCさんとDさん」2/2
Cさんはその後どうなったかというと、実務で空回りします。

原因はソースコードの修正方法で、指摘した一番偉い人以外の意見をないがしろにするようになってしまったためです。

この処理を修正すれば大丈夫ですと現場のエンジニアがいうところ、マネージャーがここも調べてみて。と言えばそちらを優先してしまうような行動が目立つようになりました。

ただし、Cさんは社長や上層部に気に入られ、その後異例の出世をします。

一方でDさんはエンジニアとしては普通にスタートします。

驚いたのはその営業経験から顧客の中で自分の立場を作ってしまったのです。

プログラミング習得に四苦八苦する一方で、コミュニケーション能力を生かしてエンドユーザとの窓口の仕事をさりげなく現場の担当者から譲ってもらっていました。

先ほど少しお話しした通りエンジニアはどちらかというと人付き合いを好みません。

Dさんは現場の雰囲気から、エンジニアがエンドユーザと話すことがストレスになっているのを感じ取っていたようでした。

エンジニアの要望を理解し自分が使える手法で解決する方法を自ら考えることができていたのです。

さらに、その仕事を足がかりにエンジニアと話す機会を増やし、プログラミングスキル習得にも生かしているのをみたとき私はとても感心しました。


もしあなたがエンジニアにこだわらず、会社員として稼ぎたいのであればCさんのように、非効率だと思っても役職者に媚を売ることを忘れないでください。案外すんなり出世できたりしますよ。

Dさんに比べて私の方が知識も経験も圧倒的に上ですが、その対人関係における手際の良さを目の当たりにした時、改めて顧客の望むものを用意することの重要性を痛感しました。


ある程度システムが組めるようになってくると、顧客へはむしろコンサル的な提案の機会も増えます。


要は要望を聞くというよりは要望をシステムを用いて解決する方法を提案し、顧客のITリテラシーを高める教育を行ってしまった方がこちらの思惑通りになることが多いので、多くのベテランエンジニアやプロジェクトマネージャーはこの手法に走りがちです。

でも私はDさんをみてホテルマン時代を思い出し、顧客の望むものを汲み取ることをもっと重視しようと決めました。

まとめ

知識だけを持っていても現場では役に立ちません。
現場で経験を積むことで初めて知識を現場で生かすために思考を行うことになります。
この思考を通すことで自分で考えて実行するという行動力を養うこともできます。

これらのループを意識しながら行うことで自分でも驚くほどの成長ができますよ！

いかがでしたでしょうか？これが年間1000万稼げた私の成長のために意識していることです。

普段の仕事が格段に効率化されると思いますので、是非試してみてください。

まだまだ情報発信をし始めたばかりの駆け出しです。
文章がおかしかったり、よくわからないところがあれば気軽にご連絡お願いいたします。

これからもよろしくお願いいたします。

よろしければフォローRT、拡散をお願いいたします。



この記事が気に入ったらサポートをしてみませんか？