↓まだチャンネル登録をしていない人はこちらから！↓<a href="https://www.youtube.com/channel/UCytjAXJpeqzSotBHYJ7lMqQ" target="_blank" rel="noopener noreferrer">【click】YouTube エンジニアファースト</a>

今回は我々、グラントホープがなぜエンジニアの独立支援をしているのか？ なぜエンジニアファーストというチャンネルを立ち上げたのか？ そんな話をしています。15分だけ時間をください。

動画はこちらからご覧ください。 <a href="https://m.youtube.com/watch?v=48BimW3jTHs" target="_blank" rel="noopener noreferrer">https://m.youtube.com/watch?v=48BimW3jTHs</a>

【独立を迷っているエンジニアに伝えたいこと】

猫が大好き。食べることが大好き。寝ると嫌なことは忘れるタイプ。
いろんな人に出会い、いろんなものに触れて、思考を柔らかく、自分の世界を広げていきたい駆け出しライターもどき。


こんにちは！タカトです。 &nbsp; 2022年からちょくちょく話題に上がっていたインボイス制度。皆さんは具体的にどういった制度か把握してますか？会社員の方は特に意識する必要はありませんが、副業でそれなりに稼いでいたり、個人事業主・フリーランスの方は意識しないと今後の仕事に影響が出てきます。今回はそんなインボイス制度について解説していきます。 &nbsp; できるだけシンプルかつ分かりやすくお伝えしてきますので、インボイスが気になるぐらいの感じで読んで頂いて大丈夫です！時間にして3分ほどで読めるのでランチやお茶のお供にどうぞ！

インボイス制度はシンプルにいうと、消費税を払わせる制度です。 &nbsp; 消費税は物を購入した際に商品購入代金と一緒に払っていますが、その消費税とは別であなたが個人で請け負った仕事に対する消費税のことを指します。（詳細は後述で解説します） &nbsp; 消費税を払った人には適格請求書発行事業者として番号が発行されます。 適格請求書発行事業者になるためには課税事業者になる必要があり、課税事業者になる＝消費税をしっかり払いますということです。

消費税をなぜ今更払うのか？今まで免除されてた理由は？

ここで質問です。 &nbsp; あなたが物を購入し10%の消費税が掛かりました。お店には商品代＋消費税を支払いますが、この10%の消費税は誰が国に払っているか？ &nbsp; 答えはお店が代わりに国に払っています。 &nbsp; お店、または会社は毎年確定申告を行っており、その際に貰った消費税をまとめて国に支払っているワケです。 &nbsp; 次に、あなた自身が個人で仕事を受注し請求書が来ました。その請求書には売上の10%の消費税が加算され、振込の金額として提示されてます。（売上が10万だったら11万が振込対象額。1万は消費税。） &nbsp; ではこの消費税は誰が支払っているでしょうか？ &nbsp; 多分、この回答は言葉に詰まると思います。 &nbsp; 本来であればお店と同じであなたは消費税を受け取っているので、それを国に支払う必要があります。 &nbsp; これを払わなくて良いのには理由があって、売上が一千万以下の個人事業主は免税事業者と呼ばれて、消費税を支払わなくてよいとされているからです。 &nbsp; なので知らぬ間に脱税してた！？といったことにはなりません。 &nbsp; インボイス制度が施行されると、売上が一千万以下の個人事業主も課税対象者になり、毎年売上の10%を国に納める必要があります。

インボイス制度の施行は2023年10月1日からになります。 &nbsp; なので2024年に行う確定申告ではインボイス制度を考慮した申告が必要になります。 &nbsp; 各種会計ソフトもそれに向けて対応を実施中です。

適格請求書発行者って何なのか？番号は無いとダメなの？

適格請求書発行者になると番号が発行されます。番号を発行しない（適格請求書発行者にならない）選択も可能です。 &nbsp; では番号あり／なしでどういった違いがあるのでしょうか？ &nbsp; あなたに仕事を依頼する会社からすると、番号あり／なしでの違いは国に納める消費税分を全額免除できるか、できないかの違いがあります。 <img src="https://images.microcms-assets.io/assets/03df7942ab184c4fb92ae2a6d548e115/f466d12227d94fe2a6d56a13bbff7eca/image2.jpeg" alt=""> 会社からしたら、番号がない人と取引するのはデメリットしかないんです。 &nbsp; こうなると個人は仕事の受注にモロに影響が出るので、実質番号あり（自身で消費税を納める）を選択せざるを得ないのが実状です。

適格請求書発行者になると収入はどれだけ下がるのか

適格請求書発行者になるということは消費税を新たに納めるということです。 &nbsp; 2023年現在、消費税は10%なので、自身の年間売上が300万の人なら年30万、500万なら50万の税金が新たに発生します。 &nbsp; 消費税が上がれば、この税金もどんどん上がっていきます。 &nbsp; ただでさえ多くの税を払っているのに、更にまた税金が重くのしかかる。中々厳しい現実ではあります。

インボイス制度が反対される理由

インボイス制度は今まで対象外だった免税者（売上が一千万以下）から消費税を徴収する制度というのはお分かり頂けたかと思います。 &nbsp; 売上が100万円の人も10万という額を追加の税として納める必要が出てくるので、売上が少ない人にとっては死活問題で、反対されるのは当然の結果です。 &nbsp; 実際、エンタメ業界へのダメージがかなり大きいと言われています。 <a style="color:#1155cc" href="https://maidonanews.jp/article/14719374" target="_blank" rel="noopener noreferrer">「インボイス制度は日本のエンタメ業界を破壊する」　声優の甲斐田裕子が反対の声を上げる理由</a> &nbsp; これで徴収しても300億程度にしかならないので、反対されるのも無理はありません。

インボイス制度施行に向けて出来ること

正直この制度は個人事業主にとってはかなり痛い制度です。 &nbsp; とはいえ決まってしまったのは仕方ないので、出来ることとして売上額を上げるのが一番だと筆者は感じます。結局10%もっていかれるなら売上額を上げて少しでも税の負担を減らすのが今できる最善の策です。 &nbsp; もう1つはインボイス制度に対しての対応は会社によって様々なので、そこをお世話になってる会社に確認し、より良い対応をしている会社を選びなおすという手段です。 &nbsp; 例えば適格請求書発行者にならなくても良いや、その税の分を上乗せして支払ってくれるなど対応は様々かと思います。 &nbsp; グラントホープは業界的にレアな対応をしており、適格請求書発行者になることを止む無しと感じているエンジニアや個人事業主の人はグラントホープなら心配ない対応を取っています。 &nbsp; 話を聞くだけでも全然良いと思うので、興味のある方は聞いてみてはいかがでしょうか。

まとめ：しっかり理解した上で施行されるまでに準備をしよう！

いかがだったでしょうか？2023年から年収の10%が減るのは目に見えたので、そこをどう補填するか事前に考えて準備すること、もしくはお世話になってる会社を見直すことが今できる策なのかなと思います。 &nbsp; もちろん、適格請求書発行者にならなくても問題はないです。 &nbsp; 実際、施行された時にどれだけの人がなるかは未知で、下手したら適格請求書発行者にならない人が多い可能性もあります。 &nbsp; 自分の将来に関わることなので、しっかり理解した上で自身が望む選択をしていきましょう！ &nbsp; 本日も読んでいただきありがとうございました。

インボイス制度とは？施行される前に抑えておきたいポイントを解説！

タカト

2児に父でフリーランス歴8年目、主にPMO・サポート業務をメインに案件をこなしています。Webライターとしても活動中。

PythonのWebフレームワークにはDjango、Flaskが良く使用されますが、今回はFastAPIというフレームワークを紹介したいと思います。 FastAPI は、Pythonの標準である型ヒントに基づいてPython 3.6 以降でAPI を構築するための、モダンで、高速(高パフォーマンス)な、Web フレームワークです。

FastAPIの特徴とDjangoとの比較について

・パフォーマスが高く、処理が早い

FastAPIはPythonの有名なWebフレームワークのDjangoパフォーマンスを比較しても、NodeJSやGoと同じくらいにパフォーマンスが高いと言われており、Djangoよりも処理が早いとされています。

・コードが書きやすく、バグ等も見つけやすい

コーディングもDjangoに比べて書きやすい特徴もあり、コードによる重複も最小限にしていることから、ヒューマンエラーよるバグも削減と開発速度の向上が見込まれています。

・習得にそれほど時間がかからない

FastAPIはDjangoに比較して簡単に習得できるようにデザインもされていることから、ドキュメントに読む時間やその他調査にかかる時間も短縮されます。

必要条件:Python 3.6以上 ※開発環境(動作はMac環境を使用しています。) OS: MacOS Big Sur 11.4 Python: 3.9.7 Django: 3.1.7 IDE: PyCharm &nbsp; Pycharmを起動して、左下の「terminal」をクリック

(Macのデスクトップの右上の虫眼鏡マークから「ターミナル」起動→指定した階層に移動でも構いません)

ターミナル上で以下のコマンドを入力してください。 pip install fastapi 以下のように「Successfully〜」と表示されれば問題なくFastAPIはインストールされています。

次に以下のコマンドを入力後、エンターキーを押してください。 pip install uvicorn こちらも問題なく、エラーメッセージが表示されなければ正常にインストールされています。

任意のディレクトリ配下にmain.pyを作成して、以下のコードを入力します。 main.py &nbsp;

&nbsp;以下のコマンドを実行します。 uvicorn main:app --reload &nbsp; ブラウザのURLバーに <a href="http://localhost:8000/" target="_blank" rel="noopener noreferrer">http://localhost:8000/</a> を入力してください。

{"Hello":"World"}と表示されていますね。 &nbsp; 先程作成した、main.pyの5行目から7行目にて @app.get("/") def read_root():　 　&nbsp; &nbsp;&nbsp;return {"Hello": "World"} @app.get("/") →@app.get("/")と書くことで、localhost:8000以降のURLを指定するパスになります。 ("/")と書くことにより、localhost:8000で動く関数ということになります。 def read_root(): return {"Hello": "World"} →@app.get("/")と書いてありますので、 uvicorn main:app –reload Webサーバーを起動した際にWebブラウザにて localhost:8000と入力した時に動く関数ということになります。 &nbsp; こちらのサンプルではread_rootという関数名にしていますが、任意の関数名に変えていただいても構いません。 returnも{"Hello": "World"}とありますが、こちらも任意の文字列に変えてもよいです。

では次にブラウザのURLバーにて <a href="http://localhost:8000/items/10?q=sample_fastapi" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/10?q=sample_fastapi</a> を入力してください。

このように表示されていれば成功です。

解説をしていきます。 main.pyに記載をした@app.get("/")と@app.get("/items/{item_id}")の2つ関数がありますが、WebブラウザのURLにて、localhost:8000以降の/&nbsp;と&nbsp;/items/{item_id}のパスで HTTP リクエストを受けます。 /items/{item_id}&nbsp;パスのパスパラメータ&nbsp;item_id&nbsp;は&nbsp;int&nbsp;でなければなりません。 <a href="http://localhost:8000/items/10?q=sample_fastapi" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/10?q=sample_fastapi</a> →こちらの10という数値がint型指定です。 パス&nbsp;/items/{item_id}&nbsp;はオプションの&nbsp;str&nbsp;クエリパラメータ&nbsp;q&nbsp;を持ちます。 <a href="http://localhost:8000/items/10?q=sample_fastapi" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/10?q=sample_fastapi</a> →sample_fastapiの箇所がstr型となります。 @app.get("/items/{item_id}") def readitem(itemid: int, q: str = None): 　　&nbsp;return{"item_id": item_id,&nbsp;&nbsp;"q": q} 今回使用したURLですと、 http://localhost:8000/items/10 →10がread_item_idの第一引数の、item_id: intの箇所で <a href="http://localhost:8000/items/10?q=sample_fastapi" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/10?q=sample_fastapi</a> →sample_fastapiがread_item_idの第二引数のq: str = Noneの箇所になります。 &nbsp; 試しに<a style="color:black" href="http://localhost:8000/items/%7bitem_id%7d" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/{item_id}</a>の{item_id}の箇所にて、int(数値)以外の値を入れてみましょう。 WebブラウザでURLバーにて以下を入力してみてください。 <a href="http://localhost:8000/items/sample?q=sample" target="_blank" rel="noopener noreferrer">http://localhost:8000/items/sample?q=sample</a>

value is not a valid integer〜とエラーメッセージが出力されましたね。 &nbsp; では次に行きましょう。 WebブラウザのURLバーで以下を入力してください。 http://localhost:8000/docs &nbsp;

こちらの画面が表示されましたと思います。 こちらは自動対話型APIドキュメントです。 &nbsp; 次は以下のURLをWebブラウザで表示させてください。 http://localhost:8000/redoc

代替の自動ドキュメントが表示されます。

アップグレードの実装(PUTリクエスト)

PUTリクエストからボディを受け取る実装を進めます。 main.pyを修正しますので、黄色の部分を追加してください。 &nbsp; &nbsp; &nbsp; &nbsp; main.py &nbsp; from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class Item(BaseModel): &nbsp;&nbsp;&nbsp; name: str &nbsp;&nbsp;&nbsp; price: float &nbsp;&nbsp;&nbsp; is_offer: bool = None @apgep.t("/") def read_root(): &nbsp;&nbsp;&nbsp; return {"Hello": "World"} @app.get("/items/{item_id}") def read_item(item_id: int, q: str = None): &nbsp;&nbsp;&nbsp; return {"item_id": item_id, "q": q} @app.put("/items/{item_id}") def update_item(item_id: int, item: Item): &nbsp;&nbsp;&nbsp; return {"item_name": item.name, "item_id": item_id}

次は以下のURLをWebブラウザで表示させてください。 http://localhost:8000/docs

item_idに任意の数値を入力し ※画面の例の10以外の数値でも可

ユーザインターフェースはAPIと通信をして、パラメータを送信し、結果を取得して、画面下部に表示されます。 &nbsp; 次は以下のURLをクリックしてください。 <a href="http://localhost:8000/redoc" target="_blank" rel="noopener noreferrer">http://localhost:8000/redoc</a>

代替のAPIにも新しいクエリパラメータやボディが反映されています

このようにFastAPIは関数のパラメータとして、パラメータやボディ の型を宣言して、簡単にAPIエンドポイント定義と実装が可能になります。 &nbsp; &nbsp; 参考URL <a href="https://fastapi.tiangolo.com/ja" target="_blank" rel="noopener noreferrer">https://fastapi.tiangolo.com/ja</a>

PythonのWebフレームワークFastAPIの紹介

中川　彰吾

フリーランスSEで色々なWeb系の案件に参画中。言語はPythonやRuby
自宅でもパフォーマンスが落ちない様、リモートワーク中心の生活を過ごしながら、
IT技術だけでなく、英語や株式投資など学習中。


こんにちは！&nbsp;&nbsp;&nbsp;&nbsp;タカトです。 &nbsp; 今回は数多くSES事業を主とする会社が存在する中で、私がお世話になっているグラントホープをオススメする理由について解説します。 私自身、フリーランス歴は8年ですがグラントホープでお世話になってるのは2年目と実は短かったりします。 5年間は全く違うところで案件を紹介頂いており、正直行こうかどうか悩んだ背景もあります。今回はそんな悩みも踏まえてオススメの理由についてお話していきます！

グラントホープってどういう会社？

2016年設立の新しい会社でSES事業・キャリアアドバイザー事業を主としている会社です。設立して6年目ですが売上高は年々更新されており、2021年は24億。在籍しているフリーランスも数多く、年齢層も20〜40代と若々しい会社です。

私自身、グラントホープを選ぶまでは正直悩んだ

私は無料査定（詳細は事項で）を行ってから半年ほど保留にしてました。 &nbsp; 理由として、年収は上がったのですが色々な事情を考慮して案件を紹介して貰えるか不安だったからです。（私の場合は、高稼働は不可だったので） &nbsp; また、スキルに対する自信もそこまでなかったので「その額を貰うだけの活躍ができるのか？」という変にネガティブな状態になり、保留にしてました。 &nbsp; 今思うと、転職に似てるのかなと感じました。

結果的に半年悩んだ後、「入ってから色々考えよう！」という結論に至り、グラントホープさんにお世話になることを決めました。

実際グラントホープに入ってみて、どうだったか

5年間お世話になった会社以上に融通も利き、働きやすいです。 &nbsp; 年収もアップしましたし、サポートも手厚いので、早く会社を変えておけばよかったなぁと後悔したぐらい。 &nbsp; また、フリーランスと思えない福利厚生がしっかりしてるのでこの点は他社に負けないと思います。

グラントホープを選んだ6つの理由

私がグラントホープを選んだ理由は大きく6つあります。

グラントホープに入るにあたって、事前にスキルシートを提出して年収の査定ができます。 &nbsp; これで自分の年収が事前に分かるというワケです。 &nbsp; しかも今だとLINEで無料査定できるのが有難いですね。 &nbsp; 手順は本当に簡単で、経歴書を送るだけ。 &nbsp; 私の頃は対面でやっていた部分もあり、今も場合によっては対面になることもあるかもしれません。

2.査定結果が想像以上に良かった

私の場合ですが、年収が300万ほど上がりました。 &nbsp; 前の会社も安いワケではなかったのですが、想像以上の上がり幅だったのでかなり驚きました。 &nbsp; これだけ上がるのにも理由があって、グラントホープの場合、中間マージンの割合がかなり低いと思います。 &nbsp; とにかくエンジニアに還元するというのを大前提にしているため、結構な割合で年収アップできます。 &nbsp; しかもちゃんと経験値を積んで、単価の高い案件に参画することも出来て、更に年収アップが狙えるのもポイントです。

3.査定したからといって無理な勧誘・催促が一切ない

査定は正直、気軽にできます。 &nbsp; その後、入るかどうかは完全にゆだねてくれますし、無理な勧誘がありません。 &nbsp; ほとんどの会社は査定後「早めに動いた方が…」と言ったりしますが、グラントホープはちゃんと考える時間を頂けます。 &nbsp; 査定結果が良くても色々考えてしまうのが本音です。 &nbsp; 環境面、人間関係など、一旦冷静になって判断した方が良いのでそれが出来るのがいいですね。

4.キャリアも踏まえて案件を紹介してくれる

フリーランスとはいえ、ちゃんとキャリアを積むことが大事です。 &nbsp; 出来ることの幅が広がりますし、自分が「こういうことがやりたい、こういう方向に進んでいきたい」というのがあれば、それに合った案件に参画が可能です。 &nbsp; それだけの案件数がありますし、何よりこちらのことを考えて動いて貰えます。 &nbsp; キャリアプランを立てながら年収アップも狙えるので、普通の会社員の昇給と同じ感覚で給料アップが可能です。

フリーランスでは珍しく、国保ではなく社保に加入可能です。（任意） &nbsp; この二つの違いは、国民健康保険は加入者本人が保険料を全額負担します。 一方社会保険は、保険料の半分を加入先の会社・事業主が負担してくれます。 &nbsp; また、社会保険には、国民健康保険にはない扶養制度が設けられており、所得額の少ない家族を自分の扶養者として健康保険に加入させることができます。 &nbsp; これで家族の保険料が抑えられます。 &nbsp; それ以外でも最近は美容脱毛、エステを安価で受けられたり、今後は飲食・娯楽・レジャー・eラーニング・健康面など活用できる福利厚生が充実していく予定です。 &nbsp; フリーランスに欠かせない確定申告のサポートもありますし、最近ではライター業向けのSEO講座というのもあります。（2022年3月現在、無料） &nbsp; 正直、これだけ充実している会社は正社員の会社でも中々ないと思います。 &nbsp; それだけフリーランスにとってもメリットを考えてくれている会社というわけです。

6.案件参画後もサポートが手厚い

案件に参画したら、お終い！というワケではありません。 &nbsp; 一週間後、参画後の状況確認。何か問題があればすぐ連絡くださいなど、割と手厚いです。 &nbsp; 相談してもちゃんと向き合って話を聞いてくれますし、すぐに動いてくれるので私自身、現場で何があればすぐに連絡して相談したりしてます。

メリットばかり言ってしまうと疑いたくなるのが人間です。 &nbsp; なので、私が入った時に戸惑ったことを解説していきます。

1.案件紹介が複数の営業さんから来る

2022年3月現在、案件紹介について複数の営業さんから連絡が来ます。 &nbsp; しかも嬉しいことに結構な頻度で案件紹介の連絡がきます。 &nbsp; 私が最初いた会社は一人の営業さんから紹介頂いていました。 &nbsp; 紹介頂いて面談→ダメだったら次という流れだったため、複数から案件紹介があった時は驚きました。 &nbsp; ただ、この複数の方から紹介頂くやり方の方が平行で面談もできますし、早々と参画案件が決まります。（早ければ案件紹介頂いてから一週間で決まることもしばしば） &nbsp; 慣れればなんて事はないですが、慣れるまではちょっと大変に感じるかもしれません。

2.自分の中の優先順位をしっかり決めておくこと

案件を選んでいくにあたって必ず優先順を決める必要があります。 &nbsp; ・稼働を低くしたい ・高単価の案件に参画したい ・通勤時間を短くしたい ・キャリアアップをしたいので成長できそうな案件に参画したい &nbsp; などなど、全部を満たすというよりは何を優先してそれに合う案件を見つけるかが大事になるので優先順位はしっかり決めておきましょう。

まとめ：迷うぐらいなら年収査定して貰った方が良い→だって無料だもん

いかがだったでしょうか？まだまだ迷っていたり、とは言っても・・・というのが正直あると思います。 &nbsp; ですが査定自体は無料です。 &nbsp; ある意味、自分の市場価値がタダで分かるということなので、これ自体はやっておいて損はないと思います。 &nbsp; やった結果、微妙だったなら今の会社を継続すれば良いですしね。 &nbsp; 一度きりの人生、自分の価値をより高められる環境でキャリアと年収を伸ばしてみてはいかがでしょうか。

忖度なし！グラントホープをオススメする6つの理由！

皆さん、こんにちは。 Sgiです。 今回はエンジニアに是非活用していただきたいサービスがありますので、この記事を執筆致します。 最後まで読んでいただけると嬉しいです。

年収査定ってやったことありますか？

筆者がおすすめしたいサービスとは「年収無料査定」です。 これ、あまり見かけないですよね？ 正社員SEはまた話が別ですが、フリーランスSEは一般的に &nbsp; エージェントへ登録 ↓ 面談（ヒアリング） ↓ 案件紹介 ↓ お客さんと面談 ↓ 合格 ↓ 契約 &nbsp; という流れでお仕事が決定します。 &nbsp;

しかし今回ご紹介する年収無料査定の違いは図の通りです。

こちらの図を見ていただければ分かりやすいですが、 エージェントでのヒアリングの時点で自分の報酬額がおおよそ分かる仕組みとなっています。

どうやって査定してもらえる？

そもそもどうやって査定額をだしているのか。 気になったので色々聞いてきました。 &nbsp; &nbsp; この年収無料査定をするには、事前に &nbsp; ①&nbsp;&nbsp;&nbsp;技術経歴書 ②&nbsp;&nbsp;&nbsp;プロフィール &nbsp; を作成する必要があります。 エンジニアなら誰もが作成したことがあるはずです。 それをこちらの会社フォーマットに書き直すだけで完了となります。 &nbsp; 年収無料査定をヒアリング前にすることで、より具体的な希望条件の話ができる、という仕組みのようです。 &nbsp; &nbsp; どうやって査定額を出しているのか、謎ですよね。 どんどん解説していきます。

こちらの会社で実際にご成約されたエンジニアのスキル感・契約単価をもとに査定額をだしているそうです。 &nbsp; 査定額と契約時に決定した単価の誤差は月額換算で「約2万円前後」だとか。 これは正確すぎる…。 &nbsp; 会社の実績に基づいた査定額ということでした。 &nbsp;

実際にご成約された方の年収アップ事例

これは一般論ですが、IT業界の場合 正社員からフリーランスに転身した場合、年収は約1,5～2倍以上になります。 &nbsp; 理由は割愛していきます。 &nbsp; 今からお見せする事例も、査定額と契約時の単価（月額）の誤差はやはり2万円前後のようです。 それでは一気にお見せいたします！！ &nbsp; 今回はスキル感も教えていただけましたので、ご参考までに見ていただければと思います。

こうみると、皆さん年収が確実にUPしているのがわかります。 &nbsp; &nbsp; 他エージェントは契約が確定するまで自分の報酬額が不明瞭ですが、 こちらの会社は案件を選ぶ前に自分のスキル感ではどれくらい報酬が貰えるのかが分かるため、収入が不安定と思われがちなフリーランスですが 先の見通しがつくことがメリットになりますね。

査定後にヒアリング→案件紹介をしてもらうメリット

こちらは私が思うことですが、以下4点です。 &nbsp; ①&nbsp;&nbsp;&nbsp;&nbsp;金額が分かることで収入の見通しがつく ②&nbsp;&nbsp;&nbsp;&nbsp;単価をあげるために何をするべきなのか、ヒアリングに相談できる ③&nbsp;&nbsp;&nbsp;&nbsp;具体的な希望が言える ④&nbsp;&nbsp;&nbsp;&nbsp;希望に沿った案件を紹介してもらえる＝ミスマッチが少ない &nbsp; 順にお話させていただきます。

①	金額が分かることで収入の見通しがつく

先ほども少し触れましたが、フリーランスは収入が不安定、と世間一般的には思われています。 しかし、実際にはエージェントを利用することで大半のエンジニアは安定した収入を得ることが出来ます。なぜならエージェントの営業マンが案件を探してくれるからです。 &nbsp; その案件も、事前に報酬額がわかることで収入の見通しがつくため大半の不安は払拭されるはずです。

②	単価をあげるために何をするべきなのか、ヒアリング時に相談できる

査定をすると、おおよその自分の単価がわかります。 査定の金額をふまえて、もしくは将来的にもっと稼ぎたい！というエンジニアは多くいるはずです。 単価を上げるためには、当然スキルアップする必要があります。 スキルアップし、上流工程に参画したり、リーダー業務を行ったり、色々なチャンスがある案件を紹介してもらうことが可能になるはずです。

単価が明瞭になることで、自分のスキル感や立ち位置など、市場価値が見えてくるはずです。 その中で、 「単価を上げたいのでスキルアップできる案件にアサインしてほしい」 「今までリーダー業務ばかり任されてきたけど、本当はプログラマーがいい」 など、より自分のやりたいことを優先させた希望が言えるはずです。 &nbsp; 実際にアサインされるかはエージェントの営業力や個人の面談力にもよりますが、どこのエージェントでも自分の希望はしっかりと伝えるべきです。

④	希望に沿った案件を紹介してもらえる＝ミスマッチが少ない

これに関しては少し論点がずれますが、ヒアリングの時点で自分の希望をエージェントに伝えきれない場合にミスマッチが起こってしまいます。 &nbsp; 案件のミスマッチはエンジニアにとって結構な痛手となります。 「せっかくフリーランスになったのに、希望していた案件にアサインされない・・・」 &nbsp; なんて、そんなもったいないことしてはいけません。 やりたくないことに時間も労力を費やすのはナンセンスですから、しっかり自分の希望を伝えましょう。 ミスマッチが起こらず、やりたい案件にアサインされ、単価もアップ、スキルも習得出来たら最高ですよね。

・・・この会社、一体どちら様？

お待たせいたしました。 今までお話してきたサービスを展開しているのは このメディアサイトを運営している<a href="https://www.granthope.jp/" target="_blank" rel="noopener noreferrer">株式会社グラントホープ</a>さんです。 <img src="https://images.microcms-assets.io/assets/03df7942ab184c4fb92ae2a6d548e115/398019c5b09d483c82b4f1aaaf3d0c72/image.png" alt="">

グラントホープさんの特徴は、まず今回ご紹介させていただいた、年収無料査定。 そしてヒアリングには結構力をいれているようで、まさにエンジニアファースト。 &nbsp; しっかりヒアリングをするからこそ、やりたい案件がどんどん紹介される営業力。 &nbsp; 年収無料査定から最短3日でご成約された方もいらっしゃるそうです。 &nbsp; &nbsp; この年収無料査定は、誰でも実施できるようですよ。 &nbsp; ※フリーランスなので、未経験者は対象外のようです。 	ご実績が２年ある方が対象です。

いろんなフリーランスのエージェント会社がありますが、 それぞれの特徴をふまえて活用していきましょう。 &nbsp; 私個人的な意見としては、無料年収査定はおすすめです。 正社員の方は、フリーランスに転身した場合、今の自分のスキルではどれくらい貰えるのか。 フリーランスの方は、単純にエージェントによって単価が異なりますので比較対象として活用していただけばと思います。 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; これは豆知識？かもしれませんが グラントホープさんは役員の皆さんは、全員元フリーランスエンジニアのようです。 元フリーランスエンジニアによる、フリーランスエンジニアのための会社でありたい。 &nbsp; そんな強い思いがあるそうです。 &nbsp; 拙い文章でしたが、最後まで読んでいただきありがとうございました。

エンジニア必見！一度は全員試すべき年収無料査定？！

フリーランスエンジニアが仕事をする上で、クライアントからの信頼を得ることが重要であることはいうまでもありません。 もちろんフリーランスエンジニアに限らず、すべての人にとって仕事をする上での信頼関係は重要なのですが、特にフリーランスエンジニアは信頼関係に気を遣わなければならない事情があります。それは、クライアントやプロジェクトを転々とすることの多いフリーランスエンジニアにとって、少しずつじっくりと信頼関係を育てていく時間がないからです。 入社したあと、長年同じメンバーと一緒に仕事をするような正社員エンジニアであれば、自身の成長を年単位で見てもらったり、長期的な取り組みの上で成果を出したりと、「長い付き合い」の中でゆっくりと確実に信頼関係を構築することが可能です。 一方でフリーランスエンジニアは、プロジェクトにジョインした次の日からクライアントに信頼され、大切な仕事を任されるくらいでなければ、自分の求める条件の下で長期的な付き合いを続けることは難しいといっても過言ではありません。フリーランスエンジニアは正社員と違って「ゆっくりじっくり信頼してもらえるようになる」頃には、契約期間が満了となってしまうことも珍しくないからです。 このような「ジョインした次の日には信頼されている」状態を実現するための方法はとして、自分の書いたソースコードや技術記事などのアウトプットをWeb上に公開しておいたり、参加したプロジェクトの成功を見据えた提案を積極的に行なっていったり、といったものが考えられます。 それらとはまた別の手法として、この記事では「公式ドキュメントを根拠に発言する」ことの重要性について考えていきたいと思います。

ご存知の方も多いと思いますが、IT分野における公式ドキュメントとは、その技術の開発者自身が利用者に向けて書いたドキュメントのことです。公式ドキュメントには、「その技術が何であるか」「なぜそれを開発したのか」「どのように使うのか」などの情報が開発者自身によって網羅的に、常に最新の内容で整備されています。 公式ドキュメントはひとりでも多くのエンジニアがその技術に興味を持ち、正しく利用できることを目的に作られている場合が多いため、その内容についても少なからぬ工数と熱量が注ぎ込まれていることも少なくありません。 例えば私が仕事でよく使っているFlutterというフレームワークは、公式ドキュメントを開けば初心者でもわかりやすいチュートリアルやフレームワークの提供するAPIが網羅されたAPIリファレンス、またFlutterの内部的な仕組みを詳しく説明するドキュメントまで、さまざまな情報が用意されています。 <a style="color:#1155cc" href="https://flutter.dev/" target="_blank" rel="noopener noreferrer">https://flutter.dev/</a> これらを順番に読んでいくことで、Hello Worldからスタートして、ちょっとしたアプリを開発し、さらにはフレームワークの特性を理解した適切な設計ができるようになるところまで、幅広いレベルのエンジニアに重宝されています。

公式ドキュメント vs 技術ブログ

エンジニアが調べ物をする際、公式ドキュメントとはまた違った切り口で有用な情報を得られるのが技術ブログです。 技術ブログは、さまざまなエンジニアが、思い思いの目的、粒度、レベル感で自身の知見や知識を文章にまとめたもので、ちょっとした調べ物や技術への入門の際に便利であることはエンジニアであれば誰もが知るところでしょう。 公式ドキュメントと技術ブログの詳しい比較については以前にQiitaに記事としてまとめてありますので、一度そちらを読んでからこの記事を読むことで、より効果的にこの問題について考えられるようになるでしょう。 【新人プログラマ応援】公式ドキュメントも読もう | Qiita <a style="color:#1155cc" href="https://qiita.com/chooyan_eng/items/cd0d3174b77ff1e02c3f" target="_blank" rel="noopener noreferrer">https://qiita.com/chooyan_eng/items/cd0d3174b77ff1e02c3f</a> なお、この記事は公式ドキュメントを根拠に話すことの重要性について議論するものの、技術ブログが公式ドキュメントよりも劣っているということでも、技術ブログは参照しない方がいいということでもありません。 むしろ、それぞれの特性を理解した上で、適切なタイミングで適切な方を活用できるようになる必要があります。そして「クライアントの信頼を得る」ためには、公式ドキュメントを利用するのが効果的であることを、その理由を中心にここから説明していきます。

意思決定の材料には「正確さ」が不可欠

仕事をしていると、技術的、ビジネス的に何らかの意思決定をしなければならない場面に少なからず直面します。 新しく開発するシステムの言語やフレームワークはどれにするのか、Appleの審査を通過するためにどのような仕様にすべきか、目の前の機能を実現するためにどのAPIを利用すればよいのか——など、サービス開発は意思決定の連続です。 それらの意思決定に必要な情報のすべてを最初から知っているということは不可能ですので、通常は「調査」を行なった上で、そこで得られた情報を基に最適な判断をしていくことになります。 ここで必ず意識しなければならないのが、判断材料となる情報の「正確さ」です。誤った情報を基にした判断は、思わぬ結果を引き起こし、それは往々にして望まない結果であることが多いからです。そしてその「正確さ」という点で公式ドキュメントと技術ブログでは大きな差があります。

フリーランスエンジニアは公式ドキュメントを根拠に会話しよう

確かに技術ブログはさまざまなエンジニアが、さまざまな切り口で書いているために、うまく検索すれば自分の求める内容が自分の理解しやすいレベル感で書かれているものを見つけることができ、調べ物をする際に気軽に利用しやすいことがメリットです。 しかし一方で、技術ブログは公式ドキュメントに比べて「正確さ」が保証されないという点に注意が必要です。 詳しくは先ほどのQiitaの記事で言及していますが、技術ブログの書き手はその記事の正確さを追求するインセンティブが公式ドキュメントに比べて低いと考えられます。書いた内容に誤りが含まれていたとしてもせいぜいコメントとして訂正の指摘がくる程度で、それが原因で仕事上の不利益が発生することも考えにくいでしょう。 また同じ理由で、記事の内容が最新の状態に保たれている保証もありません。一度書いた内容が技術のバージョンアップなどによって古い情報となってしまったとしても、書き手に不利益がないからです。 一方で公式ドキュメントは、そのような誤りが含まれることは「利用者の減少」という不利益に直結します。 公式ドキュメントの通りに動作しない、公式ドキュメントの記述とソースコードの現状が乖離している、などの問題はその技術の利用者への不信感や開発の非効率化、さらにはシステムの不具合に直結し、最終的には「その技術自体を使わない」という判断をさせてしまうリスクにつながるためです。 構造的に「正確さ」を保証することへのインセンティブが高い公式ドキュメントを根拠に意思決定をすることで、その意思決定の精度を高めることができ、またそのような信頼できる情報をクライアントに提供することはそのクライアントからの信頼関係を構築するための大切な行動であることが理解できるのではないでしょうか。

公式ドキュメントに「書かれていない」ことも重要な判断材料

ちなみに公式ドキュメントだからといって、そこにすべてが書かれているわけではありません。求める情報が公式ドキュメントに載っていないというパターンもよくあります。そして、その求める情報が他のエンジニアの知見として技術ブログにまとまっている場合もあるでしょう。 しかしここで考えるべきは、「やっぱり技術ブログの方が情報量が多くて便利だ」ということではなく、「公式ドキュメントに載っていない」こと自体が重要な判断材料になるという点です。 公式ドキュメントで言及されていないことは、時と場合によって変わりうる「不確実」な要素だと判断できます。 たとえば公式ドキュメントで名言されていない仕様は「実行環境やバージョンアップによって予期せず変わり得るリスクがある」ということを開発や検証の段階で考慮すべき部分だと判断できますし、また別の例としてアプリの審査のガイドラインで曖昧に書かれている部分などは、審査の担当者の解釈ひとつで結果が変わる部分であり、常にリジェクトと申請し直しのために余裕を持ったスケジュールを組むべきと判断できるでしょう。 不明な部分や不確実な要因に対してリスクヘッジをするのも重要なビジネス判断です。そのリスクヘッジを促すための「不確実な要素」を洗い出す材料として適切なのもやはり公式ドキュメントであるといえるでしょう。

クライアントとの信頼関係を築く上で、正確な情報を提供することは何よりも大切です。正確な情報はより精度の高い（そして間違いの少ない）意思決定を促すことができ、またその意思決定によってビジネスが成長すれば、そのクライアントとの長期的でよりよい条件での契約に結びつくことが期待できます。 そのための正確な情報源として、公式ドキュメントを提示することはとても効果的です。その技術の開発者自身が作成する公式ドキュメントには、正確で最新の情報が書かれている状態に保つインセンティブが働くからです。 わかりやすいという一点で、正確性も情報量も保証されない技術ブログに頼るのではなく、多少の時間と労力を割いてでも、公式ドキュメントから必要な情報を見つけ出すことが大切です。そうすることで正確性のある成果物をクライアントに提供することができ、結果、クライアントとの強い信頼関係を短期間で構築できるでしょう。

フリーランスエンジニアがプロジェクトに入った次の日に信頼を得て、仕事を任されるためには「公式ドキュメントを根拠に会話をする」という方法が挙げられます。この記事では、なぜ公式ドキュメントを読むことが信頼関係の構築につながるのか、なぜ技術ブログではいけないのかを考えてみます。

フリーランスエンジニアは「公式ドキュメント」で信頼を得よう

中條 剛（ちゅーやん）

フリーランスのアプリ開発者。Flutter によるアプリ開発を中心に、企業向け研修の講師、教材作成、メンターなどをしています。技術記事は "how to use" よりも "how it works" を意識して書いています。

フロントエンドエンジニアとしてフリーランスで活動している久米と申します。 IaaS型クラウドにおけるシェア1位のAWS。かくいう私も<a style="color:#1155cc" href="https://engineer-first.net/history-of-web-frontend-2021" target="_blank" rel="noopener noreferrer">以前執筆した記事</a>で紹介しているように、本サイト「エンジニアファースト」の実装でもAWSを用いています。また他の業務では、フロントエンドエンジニアと名乗っておきながら、API GatewayやAppSyncを用いたAPI実行時の処理などを中心に、バックエンド開発などさまざまな場面でAWSを活用しています。 昨年末（2020年12月）にAWSが提供する「AWS SDK for JavaScript」のバージョン3が公開され、ある程度実際の開発でも使用してみたので、今回はその概要やバージョン2からの書き換え方法などを紹介していきます。

まず最初にバージョンについての注意事項です。 本記事では「AWS SDK for JavaScript」のバージョン3についての記事となりますが、既存のAWS SDKをアップデートして使用するわけではありません。npmパッケージ自体が既存のものとは別のものになっています。 v2

v3（本記事で扱うものはこちら）

使用方法などは後ほどご紹介いたしますが、詳しくは下記の各種バージョンのGitHubリポジトリをご参照ください。 <a style="color:#1155cc" href="https://github.com/aws/aws-sdk-js" target="_blank" rel="noopener noreferrer">AWS SDK for JavaScript v2</a> <a style="color:#1155cc" href="https://github.com/aws/aws-sdk-js-v3" target="_blank" rel="noopener noreferrer">AWS SDK for JavaScript v3</a> バージョン3から新たに追加された主な機能は下記になります。 <blockquote>・ 新しいミドルウェアスタック ・TypeScriptに対する充実したサポート ・必要なパッケージのみの分割インポート対応 引用元：<a style="color:#1155cc" href="https://aws.amazon.com/jp/about-aws/whats-new/2020/12/aws-sdk-javascript-version-3-generally-available/" target="_blank" rel="noopener noreferrer">AWS SDK for JavaScript バージョン 3 が一般公開を開始</a></blockquote> 具体的な内容をひとつずつ見ていきましょう。

参考：<a style="color:#1155cc" href="https://aws.amazon.com/jp/blogs/developer/middleware-stack-modular-aws-sdk-js/" target="_blank" rel="noopener noreferrer">Introducing Middleware Stack in Modular AWS SDK for JavaScript | Amazon Web Services</a> データの送信時などに動作するミドルウェアに、任意のアクションの追加などができるようになりました。 具体的な活用方法としては、通信が行われる際にカスタムヘッダーにメタデータを追加する方法などが紹介されています。

このような処理のように、SDKの動作をカスタマイズすることによって、リクエストのデバッグなどが容易になるとのことです。

TypeScriptに対する充実したサポート

参考：<a style="color:#1155cc" href="https://aws.amazon.com/jp/blogs/developer/first-class-typescript-support-in-modular-aws-sdk-for-javascript/" target="_blank" rel="noopener noreferrer">First-class TypeScript support in modular AWS SDK for JavaScript | Amazon Web Services</a> 以前のバージョン2でも型定義自体は提供していましたが、それらは開発後に利用者の要望を元に追加で定義したものであり、SDK自体がTypeScriptによって記述されたものではありませんでした。そのため、型定義がコードの記述と正確に紐づけられたものではなく、型定義との齟齬（そご）が生じる可能性を捨て切れませんでした。 また、「<a style="color:#1155cc" href="https://engineer-first.net/history-of-web-frontend-2021#index-3" target="_blank" rel="noopener noreferrer">技術遷移から見る現代のWebアプリケーションに求められるフロントエンド</a>」の記事でも紹介したように、近年ではバックエンドでTypeScriptを採用するケースも増え、開発の現場ではよりいっそう、型定義の重要性が高まっています。 今回のバージョンから上記のような問題や、昨今のトレンド、各企業のTypeScript採用の流れを加味した上で、TypeScriptによる開発を行ったことで、SDKの品質向上を図ったとのことです。 下記のように各種IDEでより正確なコード補完が行われ、開発体験の向上にもつながっています。 例）Visual Studio Code

SDKの開発をTypeScriptで行ったことにより、APIドキュメントの正確性も担保されました。 ドキュメントの生成には<a style="color:#1155cc" href="https://typedoc.org/" target="_blank" rel="noopener noreferrer">TypeDoc</a>を使用することでコードの変更を元に反映することが可能になっているとのことです。

必要なパッケージのみの分割インポート対応

参考：<a style="color:#1155cc" href="https://aws.amazon.com/jp/blogs/developer/modular-packages-in-aws-sdk-for-javascript/" target="_blank" rel="noopener noreferrer">Modular packages in AWS SDK for JavaScript | AWS Developer Tools Blog</a> バージョン2では単一のAWSサービス、例えばS3のみを操作する場合でもAWS SDK全体をインストールする必要がありました。 バージョン3からは下記のように使用するAWSのサービスごとにインストールすることができ、プロジェクトファイルの軽量化に大きく貢献します。 v2

v3

その他にも高レベルの操作を行う関数、ユーティリティ関数などの使用がより簡潔になっています。 前述のような各サービスのクライアントに加え、<code>@aws-sdk/lib-〇〇</code>、<code>@aws-sdk/util-〇〇</code>のようなプレフィックス付きのモジュールをそれぞれの機能ごとに使用することができ、必要な機能だけを扱うことで軽量化が図れます。

本記事公開時点ではAWS SDKのバージョン3はリリースしてから日が浅いため、AWS SDKを使用したネット上で散見される多くの記述例では、バージョン2を用いた記述が多く見受けられます。 今回はそれらの知見を活用するためにも、バージョン3への書き換えを実際に行っていきます。 本記事ではS3からデータを取得する際の記述を例に見てみましょう。 v2

上記をご覧いただければわかる通り、関数の使用方法が変更されただけで基本的なデータの流れはバージョン2と遜色ないものが多いです。 <a style="color:#1155cc" href="https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/index.html" target="_blank" rel="noopener noreferrer">AWS SDK for JavaScript V3 API リファレンスガイド</a>で各サービスや関数ごとに情報が記載されているので、詳しくはそちらをご参照ください。 個人的にうれしい変更点が非同期処理を行う場合の記述です。 上記のようなasync/awaitの記述を行う際、バージョン2では<code>getObject</code>の処理結果から明示的に<code>promise()</code>を実行する必要があったのが、<code>client.send(new Command())</code>の形で記述することで、より簡潔に行えるようになりました。 上記のような処理ではリクエストの結果を元に任意の処理を行うことも多いので、非常にありがたいですね。

前項のようにバージョン2の記述と互換性のあるものであれば問題はありませんが、処理によってはそうでないものも存在します。 前項同様、S3での処理を見てみましょう。

バージョン2では<code>maxRetries</code>という値を指定することで処理の再試行回数の指定ができました。 しかし、バージョン3では上記の<code>maxRetries</code>は<code>maxAttempts</code>に名前が変更されています。

上記のように単純に名称変更のみで対応できるもの以外にも、非推奨となり使用できなくなった機能や型定義が変更されているものもあるので、書き換えを行う際には注意が必要です。 <a style="color:#1155cc" href="https://github.com/aws/aws-sdk-js-v3/blob/main/UPGRADING.md" target="_blank" rel="noopener noreferrer">AWS SDKのリポジトリに変更点をまとめて</a>あるので、<a style="color:#1155cc" href="https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/index.html" target="_blank" rel="noopener noreferrer">AWS SDK for JavaScript V3 API リファレンスガイド</a>と合わせて使用する機能をしっかり確認した上で書き換えを行ってください。

AWSは<a style="color:#1155cc" href="https://engineer-first.net/jobs/tag/aws" target="_blank" rel="noopener noreferrer">本サイトで掲載している案件</a>でも非常に多くの企業が採用しているように、今後もそれらを扱える人材の価値は高まっていくと思います。 今回ご紹介した「AWS SDK for JavaScript」バージョン3を始め、AWSは新たなサービスのリリースや機能のアップデートを繰り返しているので、日々キャッチアップを行って扱える技術の幅を広げていきましょう。

2020年12月にAWS SDK for JavaScriptのバージョン3が公開されました。今回はその変更内容の紹介と、バージョン2からの書き換えを実際に行っていきます。

AWS SDK for JavaScript v3のアップデート概要と、旧バージョンからの書き換え

久米大輔/Mei（Crogic）

Web・音楽を中心としたデジタルコンテンツ制作を行うCrogicの代表。
フリーランスのフロントエンドエンジニア・作編曲家として活動している。
Mei名義でVocalとしても活動中。

Bilbase株式会社代表の佐藤です。建設業への人材不足・属人化を解消するプロダクト提供を軸に、Webサービス・システム開発を行う会社を経営しており、フリーランスエンジニアのみなさまに仕事を依頼しています。会社を立ち上げる前は、私自身フリーランスエンジニアとして働いていました。 依頼側と受注側、双方の経験から、フリーランスエンジニアを目指す人が意識すべきポイントについて、「フリーランスエンジニアになるための考え方」についてお話していきましょう。 まず、はじめに会社員エンジニアのみなさまは、フリーランスエンジニアにどんな印象をお持ちですか？　「どうやったらフリーランスエンジニアになれるのだろう」とか、「フリーランスエンジニアになっても生活は安定するのだろうか」など、不安に思う方もいるのではないでしょうか。 そこでまずは「フリーランスエンジニアの構造」を整理してお伝えしていこうと思います。

タイトルにもあるように、フリーランスエンジニアになるために必要なスキルは「納期を守ること」です。これだけでは、「では、どうやってフリーランスエンジニアになるんだ？」ということになってしまうので、これからその流れについて解説していきましょう。

納期が守れればそれでいいのかといったら、それは嘘になってしまいます。もちろん、エンジニアとしての経験値も重要です。会社員エンジニアの方とお話することも多く、その中で一番多かった相談としては、「どれくらいキャリアを積めばフリーランスになれますか？」でした。 答えとしては「実務経験が2年もあれば問題ない」ということになります。この辺は主観でもありますが、2年程度業務に従事すれば、ある程度エンジニアとしてのノウハウも身につけられ、「求められたものを期日までに仕上げる力」が身につくものだと思っています。 この「求められたものを期日までに仕上げられる能力」こそが、発注側の求める最も重要な項目といえます。 期日を守ることは簡単そうで実は難しいことでもあります。そのため、実務経験がまったくないとなると、なかなか難しいでしょう。そういう意味も含めて実務経験は最低でも2年はしておきたいのです。

フリーランスになる最良のタイミングとは

経験を積んで「さあ、フリーランスエンジニアになるぞ」と考えた時に気になることは以下のふたつではないでしょうか。 <ul><li>フリーランスになるタイミングはいつか</li><li>どうやって仕事を取ってくるのか</li></ul> フリーランスを名乗るのは簡単ですが、仕事が来なければフリーランスになる意味はありません。そこでフリーランスエンジニアがどのように仕事を受注しているのか、図で解説していきましょう。

多くの会社員エンジニアの方にとって、フリーランスエンジニアのイメージは②請負契約に多いケースではないでしょうか？　そして下記のような不安を感じてはいませんか？ <ul><li>自分で営業に行かなければ食べていけない</li><li>エンジニアリング以外のことをやる自信がない</li></ul> 確かに、いきなり請負契約を受注するのは難しいです。よほどのコネクションがない限りはまず無理でしょう。ですので、まずは①準委託契約からフリーランスエンジニアとしてのキャリアを積んでいくといいでしょう。

エージェントを活用して経験を積む

フリーランスエンジニアになって、準委託契約でキャリアを積むにあたり、最も効果的なのが「エージェントを活用」することです。「エージェント」とは、言わばフリーランスエンジニア向けに案件を紹介してくれる会社。

駆け出しフリーランスエンジニアの方はこうした「エージェント」を利用するケースが多いので、これからフリーランスエンジニアとして走り出そうという方も、エージェントと連携しておいたほうがいいでしょう。 そうすれば、「今すぐにフリーランスとして動き出せる！」という気持ちになっていると思います。それくらいエージェントはフリーランスエンジニアとしての「働き方」や「キャリアの入口」を導いてくれる存在なのです。

今回はフリーランスエンジニアとして新しいキャリアを踏み出す人の後押しができればと思い、キャリアや働き方についてまとめました。 そして「フリーランスエンジニアになりたいけど通用するか心配……」という方へ、私から言えることは「フリーランスとして働くために必要なのは、一日でも早く小さな一歩を踏み出すこと」です。 さまざまな会社員エンジニアの方の相談を受けた経験上、「フリーランスエンジニアとして通用するのかどうかを実証せずに立ち止まっている」そんな方が多くいらっしゃいました。 日々、進歩する技術とともに学び続けなければならないエンジニアですが、フリーランスエンジニアに興味があるならば、ポイントを押さえ、一歩踏み出してみることをおすすめします。 先日エンジニアファーストのキャリアアドバイザーの方とお話させていただく機会がありましたが、ひとりひとりに対する本気度が伝わってきて、非常に信頼できるサービスだと感じました。 今後フリーランスエンジニアとして頑張りたい方や、案件を探されている方は相談してみてはいかがでしょうか？ この記事が皆さんのキャリアアップに繋がるキッカケになったら幸いです。 ではまた！

フリーランスエンジニアとして独立し、その後起業した経験から、「フリーランスエンジニアになるための考え方」についてお話いたします。現在会社員エンジニアでフリーランスエンジニアに転向を考えている方は、ぜひご一読ください。

フリーランスエンジニアの必須スキルとキャリアの入り口

佐藤元典（Bilbase株式会社）

Web開発を通じて建設企業の課題解決を行うBilbase株式会社 代表。バックエンドエンジニアを経て現在はプロジェクト統括も行っています。グラントホープさんを通してエンジニアメンバーも募集予定！

コロナ禍において急速に普及したテレワーク。今の現場でテレワークが始まったが、うまくいっていない、これから初めてテレワークをすることになったが不安、という方もいらっしゃるのではないでしょうか。私自身、第1回目の緊急事態宣言が発令された2020年4月より、システム開発プロジェクトの1メンバーとして、初めてテレワークで作業することになりました。 現在はリーダーとしてテレワークのフリーランスエンジニアを含むメンバーに指示する立場で働いているのですが、リーダー・メンバー双方の経験からテレワークの中で成果を上げるフリーランスエンジニアの特徴について気付いたことがあるので、それについてお話ししていきます。

テレワークで求められるフリーランスエンジニアのスキル

さて、テレワーク下に限らず、信頼される優秀なフリーランスエンジニアとはどういう人物でしょうか。すべてを定義するのは難しいですが、ぱっと思いつく限りでも以下があげられます。 ・技術に深い造詣があり、周りをサポートしてくれる ・合意した期日を守り、危うくなったら報告する ・期日までに適切な途中報告がある これはフリーランスエンジニアに限った話でも、テレワークに限った話でもなく、全ビジネスマン共通かもしれません。長年の経験が蓄積されて、第一線で活躍し続けているフリーランスエンジニアは大抵これができており、出社かテレワークかで個人の生産性が大きく落ちるようなことはありません。 一方で出社時は頑張っていたのに、テレワークでは活躍できていない、という方もいます。社会人2年程度といった経験の浅い方がこのような状況に陥りやすいのではないでしょうか。 これは元々単独での遂行が難しい作業でも、出社時は必要に応じて周りのサポートを受けられていたのが、テレワークになって気軽に聞けなくなり、手が止まる時間が増えてしまった、というのが原因です。テレワークではどうしても周りの状況が見えにくいため、順調に進んでいるか問題があるのかは、黙っていると誰にも伝わりません。やはりテレワークで成果を上げられるのは、技術的にも、社会人の働き方としても、自立・自律ができる方であり、他人からのサポートが前提で、働き方も受け身な態度では難しい、ということになります。 とはいえ、自分ではテレワークはまだ早いと思っていても、昨今の社会情勢下では望む・望まないに関わらず、突然テレワークが始まるということもあり得ます。そんなときのために、私がテレワークを行った経験の中で、やっておいて良かったことについてお話しましょう。

テレワークでやっておいて良かったこと

ボード、マウス、リストレスト、ノートPCスタンド、タブレットスタンド、ヘッドセットは新調しました。 また自宅以外で作業を行う場合は、安定したネットワーク環境を整えることが重要です。 例として以下のような対策が考えられます。<ul><li>回線の混雑などを考慮しモバイルWiFiを2台持つ</li><li>通信容量制限に備え通信量の多いプランに変更する</li><li>移動中などでも対応できるようテレワークスポットを事前に調べておく</li></ul>

自宅で作業を行う場合は、特にオンとオフの境目が曖昧になります。私自身も朝の定例ミーティングの直前に起床し、寝る直前までPCで作業を行っていることもありました。しかし、長時間効率を落とさずに集中し続けることは不可能であり、一時的にでも無理をすると、その後で疲れて効率が落ちますので、適切に休憩をはさむことはテレワークに限らず重要です。以下は私が実践していた休憩法ですが、仕事から完全に離れて気分転換になるものや、考え事はしながらも目や肩・腰は休められる方法がおすすめです。 <ul><li>軽く運動をする</li><li>シャワーを浴びる</li><li>おやつを食べる</li></ul> 夜遅くまで長時間労働が必要になる際は、夕食も休憩として取りましょう。ただし、休憩ばかりで成果が上がっていないと本末転倒で周りからの信頼も失いますので、あくまで休憩も効率的に成果を上げるための手段であることは忘れないでください。

コミュニケーションツールの使い方を覚える

これは特に社会人としての経験が浅い方向けになります。ひとりでの業務遂行が難しい以上、周りからのサポートが必須になるので、これをスムーズに受けるための準備をします。作業の不明点は誰に聞けばいいのか、その際どうやって連絡するのか、自分が困っている状況を伝えるにはどうするのが効率的か、を想定します。 多くの場合、チャットやビデオ会議などのコミュニケーションツールを使いますので、TeamsやSlack、Zoomなど、その現場で使っているツールの使い方を調べ、特定のメンバーに連絡を取ったり、開発環境の画面を共有して説明したりということは、最低限できるようにしておきましょう。

リーダーがメンバーに求めるテレワークのスキル

さて、視点を変えてリーダーの立場からテレワークを考えます。リーダーの使命はチームの目標を明確にし、チームとして成果を上げることです。チームとしての目標を達成するために、各メンバーに作業を割り振っていますので、管理として着目すべきは「皆の成果が日々適切に上がってきているか」ということになります。 例えば、3人日の仕事をメンバーひとりに任せた場合に、（工数見積は正しいという前提で）2日でできればその方が優秀ですし、5日かかれば単純にスキルが足りないか、もしくはコミュニケーションなど別の課題があったかが考えられます。 最初の3日間さぼっていた、という可能性もあるのですが、これを疑ってPC付属のカメラを常にオンにさせる、各自のPCのログオン状態を取得する、などの監視を始めるのは私に言わせれば管理者側の怠慢です。3日でできる作業であれば、1日目、2日目の目標（マイルストン）を決めて途中経過を報告してもらえば監視する必要はありません。 私の場合、作業指示や進め方のすり合わせなど直接話した方がいい事柄は、ビデオ会議で行っていましたが、報告はひとりひとりから定例の場や個別に受けていると時間がかかるため、OneNoteなどのメンバー全員で共有するデジタルノートブックに書き込んで貰っていました。 作業の進め方がリーダーとメンバーで共有できていれば、報告はテキストで十分伝わります。つまり、リーダーの立場から各メンバーに求めるスキルは、事前にすり合わせた作業の進め方に沿って自身の成果を説明し、完了予定日はすり合わせ時の見通しから変更がないか、その他困っている課題はないかを言語化して発信することになります。 当たり前のことのようですが、皆が一カ所に集まっていれば表情などを見て声を掛けることもできますが、お互いの姿が見えず状況を察することができないテレワークでは、より効率的に自身の状況を伝えるスキルがより強く求められます。よく言われることですがフリーランスエンジニアの仕事はプログラミングだけではなく、会社には所属していなくとも複数人で仕事をする以上、「報告」も重要な仕事です。

何かとコミュニケーションの難しさが注目されるテレワークですが、私はコミュニケーションはあくまで手段であり、成果をどう評価・達成するかが最も重要だと考えています。フリーランスエンジニアとしての働きぶりも、出社していれば真面目な勤務態度や献身的な長時間労働を「頑張っている」と評価されることもあったかもしれませんが、テレワーク下では成果で証明するしかありません。 そのためには毎日の作業時間に対して、この時間でこれをやり遂げた、という成果を胸をはって報告できるようにしておきましょう。その際、ひとりよがりの成果にならないために、作業の進め方をリーダーとすり合わせ、それに沿った形で報告を行うことを意識します。 東京都がテレワークマスターの認定制度を打ち出し、原則テレワークを掲げる会社も増える中で、ゴールドマンサックスのようにテレワークから従来の出社形式に戻す会社もあり、都市部の通勤ラッシュも改善されていません。テレワークの普及は未だ先行きが見えませんが、多様な働き方が認められる流れは止まることはないでしょう。自身にあった働き方を見つけるためにも、エンジニアファーストの案件情報からテレワーク案件を探してみるか、ページ内のチャットボットから登録・相談してみるのはいかがでしょうか。

私自身がシステム開発プロジェクトの1メンバーとしてテレワークで作業した経験と、リーダーとしてテレワークのメンバーに指示した経験を通して気付いた「テレワークで成果を上げるエンジニアの特徴」について記していきます。

リーダー・メンバー双方の立場から見た、テレワークで成果を上げるエンジニアの特徴

児玉亮

プラント建設業界のIT子会社でシステムエンジニアとして14年勤務後フリーランスとして独立。
PMO、要件定義から運用までシステム開発プロジェクトの幅広い工程で支援可能。
得意分野はBIやデータウェアハウスなどデータ分析基盤の構築。

フリーランスエンジニアはその仕事の性質上、初めて会うクライアントに対して自身のスキルを正確に理解してもらい、それを踏まえて労働条件や報酬などの交渉をする必要があります。 その際、「自身のスキル」を伝えるために最もよく使われる指標が、「PHP3年以上」、「Ruby on Rails3年以上」などの「経験年数」なのではないかと思います。これはフリーランスエンジニアが職務経歴を伝える手段としても、クライアントがフリーランスエンジニアを募集する際の条件としても利用されます。 しかし、ソフトウェア開発のスキルというのは必ずしも年数で決まるものではありません。より品質の高いソフトウェアを目指して、常にスキルアップを実践した人の3年間と、どこかで見つけたコードのコピペでとりあえず動かして満足してきた人の3年間が同じはずがないことは言うまでもありません。 しかしここで難しいのは、そのスキルの差を面接や面談で正確に伝えるのは極めて難しいということです。数十分や数時間という限られた時間の中で、自身がどの程度の知見と経験を持っていて、どの程度の深い考察ができて、どれだけの成果をあげられるかを言葉で説明することは、コミュニケーションに自身のある人でも難しいでしょう。 そこでこの記事では、フリーランスエンジニアがクライアントに対して「自身のスキルを正確に理解してもらう」ための方法について考えます。それによって、自分を正当に評価し、適切な信頼関係の中で一緒に働けるクライアントを見つける方法を考えてみましょう。

自分のスキルを見せる3つの方法

初対面のクライアントに対してフリーランスエンジニアが自身のスキルを伝える方法として、最も効果的なのが以下の3つだと考えています。 <ul><li>GitHubで自分の成果を可視化する</li><li>知見やアイデアを技術ブログとして公開する</li><li>勉強会で登壇する</li></ul> これらはどれも事前の設備投資を必要とせず、自分の意思と行動ひとつで実現できることも特徴です。 ここからは、この3つの方法をひとつひとつ詳しく見ていきましょう。

GitHubで自分の成果を可視化する

フリーランスエンジニアが自身のスキルを最も効果的に伝える手段が「自分が書いたソースコードを見せる」ことです。ソースコードを見れば、その人がどのような技術に興味があって、どの程度の知識や経験を持っていて、どのような思想で何を優先して開発しているのかが具体的に見えてくるためです。 しかしここで問題になるのが守秘義務です。フリーランスエンジニアが「仕事で」書いてきたソースコードは、たいていの場合において他者に見せることができません。そのため、仕事で出した成果を次のクライアントに直接見せることは通常不可能といっても過言ではありません。 そこで、「ソースコードを見せる」ためのソフトウェアを個人的に開発する方法が現実的といえます。 こういうと、「いやー、とはいってもアイデアもないし、自分だけのアプリなんて作れないよ」と思われる方もいらっしゃるかもしれませんが、ここで開発するものは何も「独自のアイデアで作ったまったく新しいアプリ」である必要はありません。すでにリリースされている何かのサービスと同じ見た目、同じ機能を持ったサービスを自分なりに実装してみて、そのソースコードを公開するだけでも十分効果があるでしょう。 あくまで目的は「自分の書いたソースコードを見せる」ことです。ここではサービスそのものの質や事業性などは二の次です。実際にそのアプリを流行らそうと思う必要もありません。 ソフトウェアは外見が同じでも、中のソースコードまで同じにすることは不可能です。同じものを作っても、そこには開発者のプログラミングのスキルがはっきりと反映されるのがソフトウェア開発。題材はなんでもよく、「自分で作る」ことが大事であると認識するとよいでしょう。 また、GitHubを活用したスキルのアピール方法は上記のソフトウェア開発だけではありません。 「OSS活動」の呼び方で知られている通り、世界にはソースコードごと公開されたフレームワークやライブラリが無数に存在します。それらは多くの場合、機能追加や不具合修正のために、世界中の開発者が参加できるようになっています。 基本的にOSSとして公開されているプロダクトは片手間で、かつ無償で開発やメンテナンスがされている場合が多く、開発者自身にとっても最優先で対応することが難しい場合がほとんどです。そのため、常に誰かの助けを必要としています。それを利用してみましょう。 OSSにコミットするためには、もちろんいくつものハードルが存在します。 そのプロダクトのソースコードを読んで、設計や仕組みを理解し、開発者とコミュニケーションをとって必要な機能や修正点を整理。それを自分がコーディングして実現しなければなりません。その一連の流れは、実際に仕事でソフトウェア開発をする場合と同じであるといっても過言ではないでしょう。 言い方を変えると、その一連の行動ができることを見せられれば、「ソフトウェア開発者として、仕事でも活躍ができる」ことが十分に証明できるといえるでしょう。 しかるべき人とコミュニケーションをとって要件を整理し、実際に手を動かしてそれを実現するプロセスはほとんどの現場に存在し、それができるフリーランスエンジニアをクライアントは探しています。 自分ひとりで好きなようにソフトウェア開発するやり方も「0からソフトウェアを作り上げる力がある」アピールにはなりますが、一方でOSSにコミットする行為は「ユーザーの要求や開発者の意図を理解して、一緒にプロダクトを作り上げる」ことができるアピールになり得ます。ぜひやってみるといいでしょう。

知見やアイデアを技術ブログとして公開する

自分が書いたソースコードを見せるのは、スキルを証明する一番効果的な方法ではありますが、一方でソースコードからエンジニアのスキルを見抜くには相応の時間的、人的なコストが発生するのも事実です。 そのため、もっと短時間で効率的に自身のスキルを見せるための手段として、「文章にまとめる」という手段も有効です。具体的には、QiitaやZennといった技術ブログサイトや自分のブログに知見を書いて公開する、という手法です。 自分の知見や意見を文章にまとめることで、それを読んだクライアントは、フリーランスエンジニア本人と直接会話する場を設ける前に、またソースコードを読み解くための前提知識として、その人の考え方や理解度、趣向や思想などを理解できるようになります。 Web上ですぐに読める形でまとめておけば、興味を持ってくれたクライアントに対して「私のスキルについて、詳しくはこちらを参照してください」とそのURLを共有するだけで話を進められるようになります。逆にこのようなアウトプットがなければ、同じ内容を面談や面接といった限られた時間の中で伝えなければならなくなります。しかし、自分の理解や考え方をそのような短時間で伝え切ることは難しいです。 技術ブログは、自身が興味を持ったこと、経験して得た知見、学習した内容を好きな構成で、好きな数だけ技術記事という形でアウトプットしておけば、必要なときにさっとそれをクライアントに共有して、自分のスキルを詳しく正確に把握してもらえるようになるでしょう。

エンジニアの勉強会には多くの場合、ひとりあたり5分~10分間で自分の知見や経験を発表できる「LT」(Lightning Talks)の場が用意されます。勉強会によっては、LTが主目的の場合もあるでしょう。これに登壇することも、自身のスキルを見せるためのとてもよい手段になり得ます。 前述のソースコードやブログと違って、LTはリアルタイムで直接のコミュニケーションが発生します。自分が作ったスライドで自分の言葉で発表し、質疑応答で参加者とコミュニケーションをとり、またその後の懇親会ではLTに登壇した人のところに参加者が集まる傾向が見られます。 ソースコードやブログなどの一方通行になりがちなアウトプットと違い、相手に対して自分のキャラクターやコミュニケーションの特徴、相性の良し悪しなどを伝えられるのもリアルな場に出るメリットのひとつです。 <a style="color:#1155cc" href="https://engineer-first.net/value-of-freelance-engineer" target="_blank" rel="noopener noreferrer">1杯1000円のコーヒーから考えるフリーランスエンジニアの価値</a> でも説明した通り、フリーランスエンジニアがクライアントに対して与える価値を生み出すものは、技術力だけではなくキャラクターや趣味、考え方などさまざまだからです。 IT業界とはいっても、人と人が協力してプロダクト開発を進める仕事である以上、一緒に働く人との相性や信頼関係は重要です。それらはソースコードや文章で伝えるよりも直接のやりとりを通して伝えるのが最も効果的だと私は考えています。 LTに登壇することは、発表内容から技術的なスキルを見せるだけでなく、コミュニケーションのとりかたや興味関心といった人間的な要素も同時にクライアントに見せられるのが最大のメリットといえるでしょう。

フリーランスエンジニアに対してクライアントがスキルを証明する指標として「年数」が使われることが多いのは事実です。 それはフリーランスエンジニアのスキルが年数に比例すると本気で信じている場合もあれば、ほかに扱いやすい指標がないために仕方なく年数で足切りしている場合もあるでしょう。 しかし、クライアントが本当にほしいのは「PHP経験3年」のエンジニアではなく、「PHPを使って高品質なシステムを作り上げてくれる」エンジニアです。そして「自分こそがそのスキルを持つエンジニアである」ことを証明する手段は、この記事に書いた通りいくつも存在します。 「とりあえず」年数を条件のひとつに挙げている企業でも、本当にスキルのあるフリーランスエンジニアと仕事がしたいと思っているのであれば、適切に自身のスキルを見せることで、「年数」の条件に当てはまらなくても、一緒に仕事がしたいと思わせることは可能なはずです。 ソースコード、文章、そしてコミュニケーションで、ひとりでも多くのクライアントに自分がどのような人材なのかを見せることは、ひとつでも多くのチャンスを呼び込むことになります。その結果、フリーランスエンジニアとしてクライアントから頼られ、やりがいのあるプロジェクトを見つけることができると考えています。

初めて会うクライアントにフリーランスエンジニアが自身のスキルを説明する方法として、最もよく使われる指標が「PHP3年以上」、「Ruby on Rails3年以上」などの「経験年数」なのではないかと思います。しかしソフトウェア開発者ひとりひとりのスキルは、必ずしも年数で決まるものではありません。フリーランスエンジニアが年数以外の指標で適切に評価されるための方法を探り、より活躍できる案件の見つけ方を考えてみましょう。

「年数」だけじゃない フリーランスエンジニアにおけるスキルの見せ方

フリーランスエンジニアがクライアントに対して提供する価値は、フリーランスエンジニアひとりひとりが持つさまざまな特徴から生み出される、ということは以前に<a style="color:#1155cc" href="https://engineer-first.net/value-of-freelance-engineer" target="_blank" rel="noopener noreferrer">1杯1000円のコーヒーから考えるフリーランスエンジニアの価値</a>で説明した通りです。 一方で、「高い技術力」という特徴さえ持っていれば、ほとんどのプロジェクトで高い価値を生み出せるようになるのも事実です。 この記事では、そのような高い技術力を手に入れるために、フリーランスエンジニアならではの事情を考慮した勉強方法について考えてみたいと思います。

フリーランスエンジニアと会社員の違い

まずは「技術力を磨くための学び方」を考える上での、フリーランスエンジニアと会社員の違いについて整理してみましょう。 フリーランスエンジニアと会社員の違いは、大きく分けて下記の3つと考えられます。 <ul><li>一緒に学べる同僚の存在</li><li>将来的に必要になる技術領域</li><li>実践経験を積む機会</li></ul> これらの違いについて、ひとつずつ確認していきましょう。

会社員には多くの場合、業務中も気軽に雑談できる「同僚」が存在します。 同じプロダクトを同じ技術で、同じ立場で開発する同僚の存在は、新しい技術を学ぼうとした時、とても助けになります。背景知識を共有し、同じ目線で議論ができることでお互いの理解度に合わせた会話が成立するからです。 一方で、フリーランスエンジニアにとってそのような存在が常にいるとは限りません。毎日同じ場所で顔を合わせ、同じ立場で会話ができる——。そんな気心の知れた仲間は、数カ月単位で案件を転々とすることも多いフリーランスエンジニアという立場では、なかなか手に入らない存在です。 そのため、フリーランスエンジニアはひとりでも効率的に学べる工夫が必要になります。

学習すべき技術領域も会社員とフリーランスエンジニアでは異なります。 会社員の場合、開発するプロダクトや利用する技術はある程度固定されています。ひとつの会社で開発をする以上、必要とされる技術や業務知識が変わることは多くないためです。 一方で、フリーランスエンジニアは数カ月単位でプロジェクトやクライアントが変わり、それに伴って必要になる技術が変わることも珍しくありません。たとえ同じ言語、同じプラットフォームの開発であったとしても、実現する機能や利用するAPI、ライブラリまでまったく同じということはそうないでしょう。 なにより、次にどのような技術が必要になるかは「実際にプロジェクトに参加してみるまで具体的にはわからない」という場合も多いでしょう。そうなると「必要になったら入門する」という姿勢では間に合わない場合も出てきます。 そのため、フリーランスエンジニアは日頃からアンテナを高くして、今仕事で使っていない技術も、ある程度事前に学んでおく必要があるといえます。

会社員の場合、初めての技術であっても「投資」という考え方で会社が給料を出しながら学習・研究する時間を与えてくれる場合があります。 一方でフリーランスエンジニアは、基本的に「その場で価値が出せる」からこそ契約が成立することが多く、「じゃあ、この1カ月月間は成果が出なくてもいいから勉強していてよ」という話になることはほとんどありません。 少なくともその技術を学んだことがあって、スムーズに開発に参加できるレベルでの理解ができていないと、参加しても足手まといになってしまいます。場合によってはプロジェクト全体の価値を下げてしまうリスクもあるでしょう。 以上のことを踏まえると、フリーランスエンジニアが技術力で価値を出すには、「ひとりで」「幅広い技術を」「あらかじめ」学べるようになる必要がある、といえるでしょう。

フリーランスエンジニアの学び方

では、そんなフリーランスエンジニアの学び方について具体的に考えてみましょう。 大事なのは以下の2点だと考えています。 <ul><li>アウトプットする</li><li>公式ドキュメントとソースコードから学ぶ</li></ul> それぞれについて詳しく説明します。

前述の通り、フリーランスエンジニアにとって「なんでも相談や議論ができる同僚」の存在はあまり期待できません。そのため、代わりとなる存在をネット上に求めるとよいでしょう。 しかし、「ネット上で議論する」とはいっても、何の理由もなくいきなり話に乗ってくれる時間のある人なんて存在しません。そのため、議論を生むきっかけをアウトプットする のが手っ取り早い方法です。 ひとことにアウトプットといっても、その方法はいろいろあります。 <ul><li>技術記事を書く</li><li>開発専用のSNSアカウントを作って発信する</li><li>サービスやライブラリを開発し、公開する</li><li>勉強会でLTする</li></ul> アウトプットを続けていれば、必ずそれを目にした誰かがフィードバックをしてくれます。 例えば記事を書けばコメントが、SNSで発信すればリプライが、ライブラリをGitHubで公開すれば世界中の開発者によるフィードバックがissueとして返ってきます。それを元に議論して理解を深める、というわけです。 例えば私の場合は、 QiitaやZennに記事を投稿し、開発用のTwitterで技術的な発見を発信し、<a style="color:#1155cc" href="https://pub.dev/packages/crop_your_image" target="_blank" rel="noopener noreferrer">crop_your_image</a>というFlutterパッケージを公開しています。いずれもそこそこの数のコメントやissue がつき、そのたびに新しい発見や自分では出せなかったアイデアを得られています。 これらのことを実際にやっていて思うのは、このようなアクションを起こすのは特に難しいことではないということです。ほかの誰かが書いた記事と同じ内容の記事を書いてはいけないルールはありませんし、規模の小さいコードを公開してはいけないルールもありません。そして多くの勉強会ではLT初登壇の方を待っています。 つまり、自分が得た知見や作ったものをほかの人に見せるとき、「ほかの人が何をやっているか」は関係ないのです。あるのは自分が「やる」か「やらない」か、最初の一歩を踏み出すかどうかの違いだけです。 まずはひとつ、学んだことや作ったものを自分のやりやすい形でアウトプットしてみましょう。反応がなければもう一度試してみればいいだけです。それだけでも新しい学びが期待できます。

公式ドキュメントとソースコードを読む

ひとりで技術を学んでいて一番リスクになるのが、「間違った知識のまま定着してしまう」という点です。ひとりで学んでいて誰かにその知識をアウトプットする機会が少なければ、誤解や偏った解釈を訂正される機会も少なくなります。 そこで必要になるのが、信頼できる情報源、つまり公式ドキュメントやソースコードを読むということです。 公式ドキュメントには、その技術がなぜ現在の設計や実装になったのか、内部的にどのような仕組みで成り立っているのか、という「原理原則」が開発者の言葉で説明されている場合が多くあります。 そのような原理原則をおさえておくことは、正確で質の高い理解につながるだけでなく、学習の効率化にもつながります。 一般的にプログラミング学習において、「使い方」をひとつひとつ覚えることは効率の悪い学び方です。プログラミング言語にせよ、フレームワークにせよ、バージョンアップによって具体的な使い方は簡単に変わってしまうためです。また、ひとつひとつの機能や API の使い方まで覚えようとすると、情報量が膨大すぎて頭がパンクしてしまうでしょう。 一方で原理原則となる仕組みは、その技術で一貫している基礎的な部分と言えるため、それさえ理解してしまえば個別の機能やAPIの理解に応用できます。また、その基礎はバージョンアップ等による変更でも変わらないことがほとんどですので、それによる学び直しも発生しません。 このような基礎が理解できていれば、個別の具体的な「使い方」は必要になったときに調べる程度で十分対応できるでしょう。このような学習方法は、脳のキャパシティや学習時間の節約にもつながり、限られた時間で幅広い技術をおさえることが可能になります。

会社員とフリーランスエンジニアでは、技術の習得のための環境や必要になり得る技術範囲、経験する機会の有無という点で大きな違いがあります。 特に「一緒に試行錯誤ができる仲間がいるかどうか」という点は、学習効率を左右する大きな問題です。外に向けたアウトプットを意識的に行うことで、そのような仲間を見つけるのも、フリーランスエンジニアにとって大事な行動となるでしょう。 エンジニアファーストでは、フリーランスエンジニア同士のつながりを広げる取り組みも行っていますので、これを利用して一緒に新しい技術を学習できる仲間を見つけるのもよい選択肢です。 また開発だけでなく、営業や契約、お金の管理も自分でやらなければならないフリーランスエンジニアにとっては、限られた時間でより多くを学ぶための学習効率も重要です。 読みやすいからといって、誤った内容を含むリスクのある技術記事ばかりを読むことや、その技術の「使い方」ばかりを調べてサンプルコードが動いたら満足するのではなく、信頼できる公式ドキュメントからその技術の根幹となる仕組みや思想を理解することを意識してみてください。最初は難しいことも多く理解に時間と根気を必要とするかもしれませんが、そこで得た知見は必ずその後の効率的な学習につながるはずです。 どの現場でも技術力で価値が出せるフリーランスエンジニアを目指し、よりよい学習方法を探してみましょう。

フリーランスエンジニアにとって、どんな現場でも成果を出せる技術力を持つことは、よりよい仕事を得るための重要な課題です。しかし、フリーランスエンジニアが新しい技術を学ぶことを考えたとき、そこには会社員にはない悩みが存在するのも事実です。この記事では、そんなフリーランスエンジニアの状況を整理し、効率よく新しい技術を学ぶための方法を考えます。

新着の記事一覧

フリーランスエンジニアは「公式ドキュメント」で信頼を得よう

AWS SDK for JavaScript v3のアップデート概要と、旧バージョンからの書き換え

フリーランスエンジニアの必須スキルとキャリアの入り口

リーダー・メンバー双方の立場から見た、テレワークで成果を上げるエンジニアの特徴

「年数」だけじゃないフリーランスエンジニアにおけるスキルの見せ方

どこに行っても成果を出せるフリーランスエンジニアの学び方

おすすめ記事

【独立を迷っているエンジニアに伝えたいこと】

インボイス制度とは？施行される前に抑えておきたいポイントを解説！

PythonのWebフレームワークFastAPIの紹介

忖度なし！グラントホープをオススメする6つの理由！

エンジニア必見！一度は全員試すべき年収無料査定？！

フリーランスエンジニアは「公式ドキュメント」で信頼を得よう

AWS SDK for JavaScript v3のアップデート概要と、旧バージョンからの書き換え

フリーランスエンジニアの必須スキルとキャリアの入り口

リーダー・メンバー双方の立場から見た、テレワークで成果を上げるエンジニアの特徴

「年数」だけじゃない フリーランスエンジニアにおけるスキルの見せ方

どこに行っても成果を出せる フリーランスエンジニアの学び方

【独立を迷っているエンジニアに伝えたいこと】

インボイス制度とは？施行される前に抑えておきたいポイントを解説！

PythonのWebフレームワークFastAPIの紹介

忖度なし！グラントホープをオススメする6つの理由！

エンジニア必見！一度は全員試すべき年収無料査定？！

「年数」だけじゃないフリーランスエンジニアにおけるスキルの見せ方

どこに行っても成果を出せるフリーランスエンジニアの学び方