対談内容について、下記の図解にまとめてます。 セイト先生の運営する、AIプログラミングスクールSiiDはこちら↓ <a href="https://bug-fix.org/siid" target="_blank" rel="noopener noreferrer">https://bug-fix.org/siid</a>

丸山・セイト先生コラボ対談【2026年最新・AIとフリーランスエンジニアの最前線】

グラントホープ

グラントホープのライターです

↓まだチャンネル登録をしていない人はこちらから！↓<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技術だけでなく、英語や株式投資など学習中。


皆さん、こんにちは。 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; 拙い文章でしたが、最後まで読んでいただきありがとうございました。

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

フリーランスエンジニアがクライアントに対して提供する価値は、フリーランスエンジニアひとりひとりが持つさまざまな特徴から生み出される、ということは以前に<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の理解に応用できます。また、その基礎はバージョンアップ等による変更でも変わらないことがほとんどですので、それによる学び直しも発生しません。 このような基礎が理解できていれば、個別の具体的な「使い方」は必要になったときに調べる程度で十分対応できるでしょう。このような学習方法は、脳のキャパシティや学習時間の節約にもつながり、限られた時間で幅広い技術をおさえることが可能になります。

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

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

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

中條 剛（ちゅーやん）

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

Bilbase株式会社代表の佐藤です。 <a style="color:#1155cc" href="https://engineer-first.net/fat-model-workarounds" target="_blank" rel="noopener noreferrer">前回</a>の記事ではファットモデルに陥るサイクルとその回避方法について書かせていただきましたが、今回は続編として、ファットコントローラーについてふれていきたいと思います。初学者の方にもわかりやすいように書いていきます！ 皆さんはプロジェクトでファットコントローラーを経験したことがあるでしょうか？ 多言語で経験を積んでいる方は割と回避しやすいものですが、Railsからプログラミングを始める方はハマりやすいポイントかも知れませんね。

・とりあえずビジネスロジックをモデルに移すことを意識する。 ・同時進行でリファクタリングするのは諦めて、コントローラーを綺麗にすることに集中する。 初学者の方にありがちな失敗として、目の前にある問題以外のことにも気を取られすぎてしまい、結局どこから手をつければいいかわからなくなるということが挙げられます。慣れていない方は、まず目の前の課題から解決して、コンパクトに学習とリファクタリングを進めていきましょう！ <a style="color:#1155cc" href="https://engineer-first.net/fat-model-workarounds" target="_blank" rel="noopener noreferrer">前回のファットモデル解消法</a>でもお話しましたが、エンジニアリングをする中で、最初に抑えておくべき部分を見落としがちな方は一定数いらっしゃると思います。 「もうわかってるから問題ないよ〜」という方はこの記事をスキップしてもらって大丈夫です。 見直しを含めて、もう一度さらっておきたい方々はどうぞご一読ください。 では早速中身を見ていきましょう！

めっちゃそもそもの話をしていきます。 Ruby on RailsはMVCアーキテクチャに基づいて3つの要素で構成されています。 「MVC」の「C」が今回登場するコントローラーです。 ここではコントローラーの役割についてサクッと見ていきましょう。

ご覧の通りコントローラーは全体の処理の中で中間地点に位置しています。 つまりコントローラーの役割は「仲介役」ということです。 【もう少し詳細なコントローラーの役割】<ul><li>ブラウザからのリクエストを受け取る</li><li>データをモデルに要求する</li><li>データの追加、変更をモデルに指示する</li><li>適切なViewを選ぶ</li><li>データをViewに渡す</li></ul>

なぜファットコントローラーに陥るのか

ファットコントローラーに陥る原因はただひとつだけ。 実は前項で書かせていただいた「仲介役」という役割を忘れてしまったときに起こるケースです。 一度理解してしまえばファットコントローラーは簡単に攻略できるので、気張らずに頑張りましょう。 まずは下記の図で「Railsがファットモデルに辿り着くまで」をご覧ください。 こちらは前回書かせていただいた、「<a style="color:#1155cc" href="https://engineer-first.net/fat-model-workarounds" target="_blank" rel="noopener noreferrer">Railsのファットモデル3つの対処法</a>」でも使用した図です。今回の対象はステージ2のコントローラーですね。 RailsではSkinny Controller, Fat Modelという方針が推奨されていますが、初学者にとっては「なんのこっちゃ」だと思います。

解説 1,まず、ほかのフレームワークをさわったことがない初心者にとって陥りやすい問題がファットビュー。最終的に画面に表示される内容に関するコードが書き込まれるためビューにロジックを書き込んでしまうケースも見られます。 2,問題はここ、Railsに慣れ始めたエンジニアが陥るファットコントローラー。モデルに書くべき処理とコントローラーで必要な処理の使い分けがうまくできずに、コントローラーにロジックが集中するケース。ビューをスリムにすることはできたが、モデルやモジュールをうまく使いこなせていない、コントローラーのコードに無駄が多い場合に陥りやすいです。 3,しっかりModelにロジックを寄せていった結果、待ち構えているのがファットモデルです。Viewとコントローラーをスッキリできた分Modelにロジックが集まるのは当然ですよね。 コントローラーで何をどこまでやればいいのかわからない、ファットコントローラーの状況になってしまいます。

今すぐ使える【3つのファットコントローラー解消方法】

ここでは紹介できる数も限られてきますので、基本的な考え方の手順を3つだけ紹介していければと思います。

まずは膨れ上がったコントローラーのロジックをすべてモデルへ移行する気持ちで進めましょう。最初から細かいことを考えるよりも構造が整理されている方が大切です。 ❏ポイント ・publicメソッドはアクション（APIモードの場合はAPI）だけにして、それ以外のメソッドはモデルへ移す ・モデルへの移行とリファクタリングは切り分けて考える ❏メリット モデルに処理を集めることで、結果的にそのモデルの規模感がわかるので、モデル自体の改修が必要か、今後の方針も検討することができるようになる点でいいと思います。

条件に応じてコントローラーで処理を分けたいこともあると思いますが、そのためにメソッドが膨らむと、とんでもなく見通しが悪くなるので注意が必要です。 この内容はモデルでもモジュールでもいえることですので、早めに意識しておくことをおすすめします。 ❏ポイント ・before_actionを使う ・繰り返し使う処理はメソッド化してモデルへ ❏メリット before_actionを使用することによって、コードの行数を減らすことにつなげられます。それだけでなく「DRY」の原則に従ってソフトウェア開発を進めることにもつながると思います。 DRYは「Don’t Repeat Yourself」の略で、ただ「繰り返さない」という受け取り方よりも「開発全体において情報を重複させない」という認識でいてもらったほうがいいかと思います。（この辺りもまた別記事で書いていきます） コントローラーでbefore_actionを定義することによって、アクションの前に処理を差し込むとができます。一般的には、複数のアクションで共通している処理に関してはbefore_actionで定義するようにしましょう。 before_actionに関しての使用例は以下に記載させていただきました。

Railsにはコードを最適化するためのrubocopというgemが存在します。

こちらコマンドで.rbファイルを解析して、修正するべきコードを表示してくれます。

とすることでそのファイルだけの解析もしてくれます。

-aオプションを付けることで自動的にコードを修正してくれるという便利な使い方もあるので覚えておくといいかもしれません！ ❏ポイント ・実装中やプルリク作成前に必ずrubocopでエラーが出ないことを確認する ❏メリット rubocopで同じようなことを注意されることがありますが、何回か注意されるとどのように修正するべきか自然にわかるようになるため、スキルアップにもつながりやすく、読みやすいコードを書くことができるようになります。 ❏導入手順 1. 以下をGemfileに記載

2.&nbsp; bundle install後、ターミナルで以下のコマンドを叩いて修正箇所を確認

記事を読んでいただきありがとうございました！ 今回の内容の中で「自分のプロジェクトで課題がありそうだな」と思う方は、「モデルを太らせること」を念頭においてコードを書き進めてみてください！ また、その際には前回の記事<a style="color:#5d639e" href="https://engineer-first.net/fat-model-workarounds" target="_blank" rel="noopener noreferrer">「Railsのファットモデル 3つの対処法」</a>を読んで、参考にしていただくといいと思います。

今回はRails初学者がつまづきやすい、ファットコントローラーに陥るサイクルと、その回避方法についてお話していきます。

Railsのファットコントローラー 3つの対処法

佐藤元典（Bilbase株式会社）

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

業務でコードを書く際、似たような処理を別の業務で実装した経験がある方も多いのではないでしょうか。中には、それを自作のライブラリとして作成して、GitHubで管理するという形を取っている方もおられるでしょう。 では、実際にそれを複数のプロジェクトで使用する際はどのように行っているでしょうか。 今やほとんどのエンジニアが使っているGitHubですが、その機能のひとつにGitHub Packagesと呼ばれるパッケージホスティングサービスがあります。 今回はこちらを利用して、自作のJavaScript関数をnpmライブラリとして管理する手順をご紹介します。

以前はGitHub Package Registryと呼ばれていたこのホスティングサービスですが、ひとことで言ってしまえば「作成したソフトウェアをGitHub上でパッケージとして管理することで、さまざまなプロジェクトで使えるようにしたよ」というものです。 プライベートリポジトリではプランによって料金が異なりますが、フリープランであってもストレージ容量500MBかつ月間データ転送量1GBまでであれば無料で使えます。 パブリックリポジトリに至っては完全に無料。太っ腹です。

GitHub Packagesに自作関数をデプロイする

今回はTypeScriptを使って簡単な関数を実装し、それを自分専用のライブラリとして作ってみましょう。

まずはPackage.jsonに以下の内容を記述していきます。 ついでにnpm installもやっておきましょう。

@{GitHubのユーザーネーム}/{リポジトリ名}

ここで、いくつか重要なフィールドをピックアップして解説します。 name @{GitHubのユーザーネーム}/{リポジトリ名}の形で入力します。 実際にライブラリをインストールする際も$ npm install @{GitHubのユーザーネーム}/{リポジトリ名}という形式になります。 version ライブラリ自体のバージョンを管理します。今回はとりあえず0.0.1としておきました。 main ライブラリが別のモジュールから呼び出された際に、どのファイルを参照するかを設定します。 今回はトランスパイルされた後のJSファイルを参照するので、dist/main.jsを指定しました。 typesフィールド ライブラリの型定義ファイルを指定します。 publishConfig npmで扱えるようにするため、registryに<a style="color:#1155cc" href="https://npm.pkg.github.com" target="_blank" rel="noopener noreferrer">https://npm.pkg.github.com</a>を指定します。 また、今回は自分専用＝プライベートなライブラリなので、accessにはrestrictedを指定しておきます。 ちなみに複数のレジストリで公開したい場合は、publishConfigフィールドではなく.npmrcに記述する形になります。

今回は最小限の設定だけ記述しました。

リポジトリを作成する際、Node.jsのgitignoreテンプレートを選択している場合は不要ですが、もしそうでなければ.gitignoreにdistディレクトリを追加しておきましょう。 こちらはトランスパイル後のJSファイルと型定義ファイルが格納される予定ですが、トランスパイル自体は後述するGitHub Actionsで行います。

今回は「引数として与えられた文字列の奇数番目だけを抽出した文字列を返す」という関数を作ってみます。

こんな感じでしょうか。 すごく簡単な内容ですが、これならビルドの時間も短いので練習にはもってこいです。

GitHub ActionsでPublishの設定を行い、Packageとして公開する

最後に、プッシュされたら自動でトランスパイル＆Packageとして公開するGitHub Actionsを設定します。 .github/workflows/publish.ymlとして以下の内容を記述した設定ファイルを追加しましょう。

この際、secrets.GITHUB_TOKENという値を利用していますが、これは各リポジトリにデフォルトで備わっているトークンなので個別に設定する必要はありません。 ここまでの内容でプッシュしてみましょう。 リポジトリのActionタブを開くと、すでに先ほど設定したアクションが終了していました。

Codeタブに戻ってみるとPackagesの欄が追加されており、先ほどプッシュした内容がv0.0.1として正常にデプロイされたことがわかります。

デプロイされたライブラリを使う

次にデプロイされたライブラリを実際のプロジェクトに導入して利用する手順をご紹介します。

今回はプライベートなパッケージを対象としているので、それにアクセスするためのトークンを発行する必要があります。 <a style="color:#1155cc" href="https://docs.github.com/ja/github/authenticating-to-github/creating-a-personal-access-token" target="_blank" rel="noopener noreferrer">公式の解説</a>に従って設定ページを開きましょう。

パッケージの読み取りを行うだけなので、スコープはread:packagesにのみチェックを入れます。 NoteはわかりやすいようにREAD_PACKAGESとしてみました。

Personal Access Tokenを発行したら、適当なプロジェクトを作成し、プロジェクトルートに.npmrcを作成して以下の内容を記述します。

これでプライベートなパッケージにアクセスできるようになりました。 あとは通常のNPMモジュールインストールと同様にnpm installすれば、node_modulesディレクトリにインストールされます。

それでは実際に使ってみます。 以下のスクリプトを実行し、AAAAと表示されれば成功です。

期待通りに動きました。 関数名にマウスオーバーすると型の情報も見られるので、型定義ファイルもきちんと参照できているようです。

ここで先ほど実装したライブラリに、「奇数番目or偶数番目の文字列を引数によって選択できる」という新機能を実装したくなりました。 早速実装してみましょう。

新機能を追加したのでマイナーアップデートという扱いにしましょう。 手動で書き換えることもできますが、npmにはパッケージのバージョンを管理するコマンドがあるのでそれを利用します。

gitのログを確認してみましょう。 package.jsonのバージョンが更新され、v0.1.0として新たにタグが作成されていると思います。この状態でプッシュしましょう。

Releaseの欄が2 tagsになり、Packages欄のバージョンも0.1.0になっています。 どうやらきちんとアップデートできたようです。

昨今はnpmライブラリが充実しており、欲しい機能は探せば見つかることが多いと思います。 しかし、公開されているライブラリでは機能が不足していたり、不要な機能が多すぎたりする場合、自作のライブラリで解決するという手段は選択肢として大いにあると思います。 そんなときには、ぜひGitHub Packagesを利用して便利に使いまわしていきましょう。

GitHubの機能である「GitHub Packages」を利用し、自作のJavaScript関数をnpmライブラリとして管理する手順をご紹介します。

GitHub Packagesを使って自作ライブラリを管理しよう

Takumi.K

サービス開発にも携わるフリーランスフロントエンドエンジニア。

会社員からフリーランスエンジニアへの転向を考える上で、最も大きな心配ごとのひとつに クライアントとの人間関係 が挙げられると思います。 「上司がクライアントに変わっただけ」という言葉を耳にすることもあるように、いくらフリーランスエンジニアになって上司のいない自由な立場を手に入れたとしても、結局はクライアントの顔色をうかがいながら仕事をしなければならず、状況はさほど変わらないのではないか、という不安を持っている方が少なからずいるのではないでしょうか。 しかし、会社員にとっての上司と、フリーランスエンジニアにとってのクライアントでは決定的に違う点がひとつ存在します。それが、「フリーランスエンジニアとクライアントは対等である」という点です。 この記事では、クライアントとの適切な接し方について考えることで、フリーランスエンジニアとして楽しく仕事を続けられる方法について考えてみたいと思います。

組織における「一貫性」の重要性

そもそも、なぜ会社では上司の意思決定に従わなければならないかを考えてみましょう。 大前提として、会社は組織です。会社という組織が、ビジネスにおいて成果を最大化するために最も重要な要素のひとつが「一貫性」であると私は考えています。 ビジネスには絶対的な「正解」は存在しません。何をどうすれば成功するのか、どんな商品を提供すれば顧客はお金を出してくれるのか、どんな戦略をたてれば事業は成長できるのか——。組織のトップは、どれが正解なのか誰もわからない中で、意思決定をして組織を動かさなければなりません。 例えば「うちの会社は利益の上がらない案件でも受注する。数をこなすことで蓄積するノウハウで、他社との差別化を図る」というのもひとつの戦略です。組織のトップがひとたびこのような戦略をたてたら、組織に所属するすべてのメンバーがこの方針を尊重し、その効果を最大化するように行動することが求められます。 「利益の上がらない案件でも受注する」ということは、その組織に所属するエンジニアとしては、赤字を抑えるためになるべく低コストで案件をこなす工夫（例えば作業の自動化や仕様の調整など）が必要になります。 営業部門のメンバーは、他社が敬遠するような利益率が低い案件を狙って受注するような戦術も求められるでしょう。将来的に「ノウハウの蓄積」を武器とする方針であれば、ひとつひとつの案件で得られたノウハウを、ドキュメントとしてまとめることも意識的に行う必要があります。 ここで誰かが「いや、利益率の低い案件を受注したって現場が疲弊するだけだ。自分は利益率の高い案件だけを受注する」と、独自の考えで動いてしまうとどうなるでしょうか。 当然のことですが、利益率の低い案件を数多く受注するためのノウハウと、少数の利益率の高い案件に絞って確実に受注するためのノウハウは異なるはずです。やり方の違うメンバー同士ではノウハウの共有もできず、業務の共通化もできません。また、それぞれ方針の異なる案件に付き合わなければならないエンジニアや、ほかの部署のメンバーにも混乱を生じさせてしまいます。 このような状況は、非効率と混乱により、ビジネスにおける失敗のリスクを高めます。 会社が組織である以上、そのトップが決めた戦略を大前提として、各部門、各部署、各プロジェクト、各メンバーが自分の目標に落とし込んで行動することで「一貫性」が生まれ、組織としての成功が実現します。まさにそれこそが、組織において「上司の意思決定に従わなければならない」理由であると言えるでしょう。

個人事業主における「一貫性」

では個人事業主であるフリーランスエンジニアの場合はどうでしょうか。 事業の成功のためには行動の「一貫性」が大事であるという点は、会社の場合と同じと考えられるものの、会社という「組織」と違い、フリーランスエンジニアは「個人」です。つまり、自分が立てた戦略を実行するのは自分です。 どのような戦略を立て、どのように実行し、どのような言動をとるのかはすべて自分次第です。それによる成功も失敗も、すべての責任をとるのは「事業主」である自分自身です。組織のトップという「自分ではない誰か」が考えた方針に従うのではなく、「自分」が考えた方針に従って行動できる、という点でフリーランスエンジニアは「自由」であるといえます。 これはクライアントとの接し方においても同様です。クライアントの要求に対し、自分はどのように言動するのかを決めるのは自分の戦略次第です。 例えば理不尽な要求に対して毅然と拒否するのもひとつの戦略です。すべての要求を受け入れ、自分のできる最大限の仕事をするのもまたひとつの戦略です。無理せず常に余裕を残した仕事をするのもまた戦略でしょう。 自分の望む人生を実現するための戦略を考え、実行し、それを自らの手で現実にする選択肢がフリーランスエンジニアにはあるといっても過言ではありません。

「クライアント」は「上司」？

さて、ここまでの話を踏まえると、最初の疑問の答えは明確なのではないでしょうか。 フリーランスにとってのクライアントと、会社員にとっての上司は同じなのか——。答えは当然「ノー」です。 戦略を同じくするひとつの組織に所属し、明確な指示系統や上下関係のある上司・部下の関係とは異なり、フリーランスエンジニアにとってのクライアントとは、身も蓋もない表現をすると「利害関係の一致した商売相手」以外の何者でもありません。 フリーランスエンジニアは、技術を提供することでクライアントから報酬を得ることができ、クライアントは報酬を支払うことで自分のビジネスを実現できます。技術とお金を交換するこのようなシンプルな関係には上も下もありません。 クライアントの意向だからといって、すべてに従う必要はないのです。 クライアントに従えなければ、契約を解消して考え方の一致する別のクライアントを探す自由があります。※1

対等な会話がプロダクトをよりよいものにする

フリーランスエンジニアとクライアントの関係において、意見が合わなかった場合の選択肢は、契約を解消するだけではありません。 先ほど説明した通り、フリーランスエンジニアは「社員」ではありませんので、クライアントの組織としての方針に従う必要はありません。むしろ「外部の専門家」として、組織の戦略をよりよいものにするための意見を期待される立場でもあります。 フリーランスエンジニアに仕事を依頼するということは、クライアントの組織内の人員だけではそのシステムを完成させられない、またはビジネスを実現することができないリスクがある、ということです。だからこそ、クライアントは不足する戦力を外部の専門知識や経験を持った人材に求めます。 そのことを考えると、フリーランスエンジニアの「専門知識や経験を持った人材」としての意見は、クライアントにとってプラスになることも少なくありません。 プロダクトをよりよい形で実現することで、ビジネスの成功率は高まります。ビジネスが成功すれば、当然クライアントが得られる利益は大きくなり、それによってフリーランスエンジニアに支払える報酬や条件もよりよいものになります。このことは前の記事でも少しふれていますので、興味があればぜひ読んでみてください。 <a style="color:#0186ab" href="https://engineer-first.net/value-of-freelance-engineer" target="_blank" rel="noopener noreferrer">1杯1000円のコーヒーから考えるフリーランスエンジニアの価値</a> システム開発の知識を持ったフリーランスエンジニアと、ビジネスのアイデアを持ったクライアントが対等に意見を交換しながら、プロダクトをより高い品質で実現する。これが両者の利益につながるということを理解していれば、「どちらが上か」を考えることが、いかに無意味であることがわかるのではないでしょうか。 「クライアントの意見に従わなければならない」、「クライアントは上司と変わらない」という内向きの発想ではなく、「自分の意見を発信することでユーザーによりよい商品を提供し、ビジネスの成功に貢献する」という外向きの発想で対等に議論をすることが、お互いのためになると考えています。

フリーランスエンジニアは組織に所属する会社員と違い、自分の戦略に基づいて、意思決定ができる、という点で「自由」であるといえます。クライアントと意見が食い違った場合でも、それに従う必要はないわけです。 むしろ、「システム開発の専門家」としての自分の意見やアイデアをクライアントに共有することで、クライアントのビジネスの成功に貢献し、お互いにとってよりよい状況を作り出すことにつながるでしょう。 一方で、そのような「お互いにとってよりよい状況」が見込めなければ、契約を終了しほかのクライアントを探すのもやはり自分の意思決定次第です。 ただし、フリーランスに転向したばかりのエンジニアにとって仕事のツテが多くあるわけでもなく、世の中にはどのようなクライアントがどのような考え方を持っているのか、どのようなビジネスが存在するのか、などを把握することは困難です。 そのような場合は、<a style="color:#0186ab" href="https://engineer-first.net/" target="_blank" rel="noopener noreferrer">エンジニアファースト</a>などの案件紹介サービスを利用し、エージェントを通じてさまざまなクライアントと「対等に」会話する機会を増やしてみてはいかがでしょうか。自分の視野を広げ、自分ならではの戦略の確立につなげられるはずです。 まずは「クライアントは上司のようなもの」というイメージを取り払い、対等なビジネスパートナーとして、お互いにとってよい結果になるコミュニーケーションを心がけてみることで、より楽しいフリーランスエンジニア生活に近づけるでしょう。 ※1 当然、契約を解消した結果「考え方の一致する」新しいクライアントがすぐに見つかるとは限りません。その辺りの見切りも含めて自分の意思決定と責任であると言えるでしょう。

フリーランスエンジニアにとって、クライアントの要求は「絶対」なのでしょうか。会社員における部下と上司の関係と比較しながら、フリーランスエンジニアとクライアントの理想的な関係について考えます。

クライアントは上司？フリーランスエンジニアの「自由」な意思決定とは

はじめまして、Bilbase株式会社代表の佐藤です。 皆さんはファットモデルについて聞いたことはあるでしょうか？ 最近個人的に質問を頂くことがあるのですが、その中でいくつか共通している質問があります。それは、「ファットモデルの回避方法」についてです。 今回は、そんなファットモデルの回避方法の一部についてお話ししようと思います。 本記事では以下の内容をお話していきます。

・ファットモデル自体は問題でなく、モデルに書くべきではない処理が多いことが問題。 ・モデルに書くべき処理が多く、コード量が多いのは問題ではない。 最終的には上記の結論に至ったわけですが、「割と当たり前の結論になったな〜」と言うのが私の感想です（笑）。 しかし、今回この内容で書く機会が得られてよかったとも思っています。 なぜなら当たり前の中にこそ、落とし穴は潜んでいるものだからです。 この言葉に思い当たることがあるエンジニアの方は一定数いらっしゃると思います。 だからこそ、自分をほんの少しだけ疑いつつ、当記事を読み進めていただけるとうれしいです。 では早速中身を見ていきましょう！

ファットモデルに陥るサイクル

ファットモデルに陥るパターンを理解していただくと、ファットモデルの根本的な解決方法がわかりやすくなると思いますので、はじめに書いていきたいと思います！ まずは下記の図「Railsがファットモデルに辿り着くまで」をご覧ください。 図をご覧いただくと「確かに」と思われる方も多いと思います。 RailsではSkinny Controller、Fat Modelという方針が推奨されていますので、MVCモデルで考えていただくと、おそらく以下の順序でファットモデルができあがって行くのだと思います。

解説<ol><li>まず、ほかのフレームワークもさわったことがない初心者の方が陥るのがファットビュー。ここは説明不要でしょう。APIモードで動かしている場合は関係ないですね。</li><li>Railsに慣れ始めたエンジニアが陥るファットコントローラー。モデルに書くべき処理とコントローラで必要な処理の使い分けがうまくできずに、Controllerにロジックが集中するケース。このケースは割とススっと抜け出せると思います。</li><li>問題はここ。しっかりModelにロジックを寄せていった結果待ち構えているのがファットモデルです。ViewとControllerをスッキリできた分Modelにロジックが集まるのは当然ですよね。</li></ol> どこに何が書いてあるのかわからない、とてもつらいファットモデルの状況になってしまいます。

今すぐ使える【3つのファットモデル解消方法】

ここでは紹介できる数も限られてきますので、導入・実装までの手順を3つだけ紹介していければと思います。

<a style="color:#1155cc" href="https://github.com/amatsuda/active_decorator" target="_blank" rel="noopener noreferrer">https://github.com/amatsuda/active_decorator</a> ❏ActiveDecoratorとは Modelに対応するViewのためにDecoratorを利用しやすくするgem。 Viewに表示する情報量が多くなるとコールバックが増えがちになってしまいます。 また、インスタンス変数が増えすぎてしまう等、最終的に何が実行されているのかわかりづらくなってきたりした場合は、別の手段を考えるいい機会かもしれません。 ここではひとつの対策として、Decoratorを使って対応する方法をお伝えしていきます。 Decoratorの特徴としては、Viewでの見せ方なども任せることができる点です。 View、Controllerをスリムにするために、Modelにより過ぎてしまったコードをDecoratorに移してあげることで、それぞれのファイルの役割を明確にすることもできます。 また、保守性の観点からもDecoratorクラスを変更するだけで共通化して変更が可能になる点でも便利だと思います。 ※注意点 変更時の影響範囲を考えながらDecoratorを作っていきましょう。 保守性を高められるからといって、あまりViewに依存した作りになってしまうと、逆に汎用性が下がり、メンテナンス工数が増大してしまうこともあります。 APIを作る際にもdecorateしてからレスポンスしたいかもしれませんし、ほかのページでも使い回すことがあるかもしれません。 ユースケースが限定されないように設計していくのも、エンジニアのお仕事のひとつですので注意しましょう。 HTMLなども含めてdecorateするのは、UI層（ViewやHelper）の責任範囲になるべきものだと思います。UI層の使い分けも意識した方が、よりメンテナンス性の高いアーキテクチャになると思います。 ❏Userモデルでの利用シーン full_name（姓名）を作りたいときに、first_name（姓）last_name（名）を組み合わせてレスポンスしたい場面があると思います。

プロジェクトが大きくなるにつれて、このようなメソッドがModelに多数発生し、Modelが膨大するかと思います。 そのような状況を解消する手段としてActiveDecoratorというGemを利用できます。 ❏使い方 ステップ1. Gemfileに以下を追記し、bundleを実行します。

ステップ2. ターミナルで以下のコマンドを実行して、既存モデルに対してDecoratorを作成します。 app/decorators/user_decorator.rb ファイルが生成されることを確認してください。 ※ここではuserモデルの場合を想定して実行します。 ターミナル

ステップ3. app/decorators/user_decorator.rbに今までModelに集まっていたView向けのロジックを移動してあげましょう。

このようにDecoratorに任せることで、ファットモデルを回避しつつ、メンテナンス性を高めることができると思います。

<a style="color:#1155cc" href="https://github.com/rails-api/active_model_serializers" target="_blank" rel="noopener noreferrer">https://github.com/rails-api/active_model_serializers</a> ❏ActiveModelSerializersとは Railsで素早く簡単にjsonを作れるgem。 APIモードで利用される際は、json形式でレスポンスすることが多いと思います。ただし、その制御に細かな設定をすると、ControllerやModelが汚れて肥大化してしまいます。 そんなときに使えるのがActiveModelSerializersです。 APIだけで使うメソッドであれば、Serializerへ移動させましょう。 ❏使い方 ステップ1. Gemfileに以下を追記し、bundleを実行します。

ステップ2. ターミナルで以下のコマンドを実行して、既存モデルに対してSerializersを作成します。 app/serializers/user_serializers.rb ファイルが生成されることを確認してください。 ※ここではuserモデルの場合を想定して実行します。 ターミナル

ステップ3. app/serializers/user_serializers.rbに今までModelやControllerに集まっていたロジックを移動してあげましょう。

レスポンスされるjson

このようにSerializerを使うことによってControllerやModelが綺麗になると思います。

◆別オブジェクトとして切り出す

ActiveModelと切り離して考えられる処理は別オブジェクトに移動させられます。 ❏例 外部APIへの問い合わせはapp/clients配下にクラスを作って行う。 Redis関連の処理をapp/cachesに別オブジェクトとして切り出す。 このようにActiveModelと切り離して考えられる処理は、切り離して個別でメンテナンスできるようにすることができます。

記事を読んでいただきありがとうございました！ 今回は「ファットモデルの回避方法」ということで記事を書かせていただきましたが、開発チームの方針、開発の優先度によって、課題に対してのアプローチ方法はもちろん異なってきます。 どちらかというと、最初に結論でも述べたとおり「ファットモデル自体は問題でなく、モデルに書くべきではない処理が多いことが問題」なわけです。 もっと抽象化すると「これってここにあるべきなのか？」という問いに対して思考できているかということになりそうですね。

今回は1~2年経験を積んだRailsエンジニアがつまづきやすい、ファットモデルに陥るサイクルとその回避方法についてお話していきます。フリーランスを目指す方は、ぜひご一読下さい。

Railsのファットモデル 3つの対処法

世の中には1杯1,000円でコーヒーを提供するカフェが存在します。 これは街中でよく見る一般的なカフェと比べて2倍も3倍もする値段設定ですが、なぜそれだけのお金を出してまで「お高い」カフェを利用する人がいるのでしょうか。 この記事では、そんな1杯1,000円のコーヒーが生み出す価値について考えることで、フリーランスエンジニアがより良い条件で働けるようになるためのアイデアについて考えていきたいと思います。

1杯1,000円のコーヒーが生み出す価値

どのようなものであれ、人が何かにお金を出すということは、そこに何かしらの「価値」を見いだしているということです。 では、先ほどの「1杯1,000円のコーヒー」を買う人は、そこにどのような価値を見いだしているのでしょうか。それを考える前に、まずはそのコーヒーを提供するカフェの「特徴」をざっと考えてみましょう。 <ul><li>味がいい</li><li>落ち着いている雰囲気がいい</li><li>高級感が感じられる</li></ul> といったところでしょうか。 ではもう一歩深堀りをして、これらの特徴から生み出される「価値」について考えてみましょう。 「落ち着いている雰囲気がいい」という特徴からは、以下のような価値が生まれます。 <ul><li>仕事や勉強などの作業がはかどる</li><li>周りに邪魔されずに会話を楽しめる</li><li>ほかのことを忘れてリラックスできる</li></ul> さらに深く考えを進めてみると、「作業がはかどる」ことによって時間あたりの成果を増やすことができ、それが評価や報酬などの結果につながるかもしれません。 「会話が楽しめる」ことは、相手との関係性をより良いものにしてくれるでしょう。リラックスは健康と次の活動への活力を与えます。 これらは、入れ替わり立ち替わりコーヒーを頼んでいく1杯数百円程度の賑やかなカフェでは得られない価値です。（※1）

フリーランスエンジニアが提供する価値

では視点を変えて、フリーランスエンジニアが契約先の企業に対して提供できる「価値」について考えてみましょう。 フリーランスエンジニアに求められるものとして、一般的によく言われるのが「高い技術力」だと思います。しかし、この「高い技術力」は、カフェの「落ち着いている雰囲気がいい」と同じで、単なる「特徴」に過ぎないのです。その特徴から生み出される価値は別のところにあります。それを考えてみましょう。 高い技術力によって生み出される価値にはどのようなものがあるでしょうか。私は以下のように考えます。 <ul><li>バグが少なく、動作が軽快で高品質なソフトウェアが提供できる</li><li>素早い開発によってスピーディにビジネスアイデアを実現できる</li><li>適切な技術選定により、変化に強くメンテナンス性の高いシステムが構築できる</li></ul> などなど、どれもソフトウェアでビジネスを続ける上では欠かせない価値です。 ただし、すべてのフリーランスエンジニアが、「高い技術力」という特徴を持っていなければならないのかというと、そうではないと考えています。 繰り返しですが、「高い技術力」はあくまで「特徴」のひとつです。ほかにもフリーランスエンジニアが持ちうる特徴は、さまざまなものがあります。例えば、 <ul><li>非エンジニアに対しても円滑に意思疎通ができるコミュニケーション力</li><li>勉強会やインターネットで、ビジネスの価値や技術的な優位性を発信できる力</li><li>正確な工数見積もりができ、進捗や課題について適切な報告ができる管理能力</li></ul> など、「ソフトウェア開発技術に精通している」という意味での「技術力」とはまた別の特徴が、さまざまな価値を生み出します。 高いコミュニケーション力があれば、ビジネスサイドとエンジニアサイドの認識齟齬を減らし、予期せぬトラブルや対立を回避できるでしょう。発信力があれば、新たなエンジニアを引き入れたり、顧客への説明がスムーズになったりするかもしれません。また、正確な見積もりや報告は、プロジェクトマネージャーにとって現状を正確に把握し、必要に応じて軌道修正をするためのとても重要な検討材料になります。 これらの特徴すべてをひとりで持つことは現実的にとても難しいことです。だからこそプロジェクトは「チーム」としてさまざまな特徴を持ったメンバーを集め、それぞれのメンバーから「価値」が生み出されることを期待します。言い換えると、全員が全員「高い技術力」を持っているからといってプロジェクトが成功するとは限らないのです。

フリーランスエンジニアがより良い条件で働くためのアイデア

さて、ここまでを踏まえて、この記事の本題であるフリーランスエンジニアがより良い条件で働けるようになるためのアイデアについて考えていきましょう。 ここまで考えてきた通り、フリーランスエンジニアに必要なのは「高い技術力」に限りません。「コミュニケーション能力」にも限りませんし、「人脈の広さ」にも限りません。あらゆる特徴が企業にとっての価値になり得るもので、「コレさえあれば大丈夫！」も「コレがないとダメ」もありません。 大切なのは、「自分がどのような特徴を持っているか、それによってどのような価値を企業に与えることができるかを理解すること」だと考えています。就職活動用語でいう「自己分析」といったところでしょうか。 技術力やコミュニケーション力だけでなく、人柄、性格、趣味嗜好、興味関心、時には年齢や血液型まで、あらゆる特徴から価値は生まれます。ひとつひとつの特徴に対して「コレは開発には関係ないな」と切り捨てるのではなく、「どんな特徴からも価値が生まれる」ことを前提に、自分が持つあらゆる特徴について、それがどのような価値を生み出すのかを考えてみましょう。 ここで忘れてはならないのが、「その価値を必要とするのは、どのような企業のどのようなプロジェクトなのか」も一緒に考えることです。 例えば、すでにサービスがリリースされていて、ビジネスの拡大を目指すフェーズにいるプロジェクトと、まだアイデアが頭にあるのみで、エンジニアがひとりもいないフェーズのプロジェクトでは、フリーランスエンジニアに求められる価値は異なります。 そのサービスのユーザーが企業なのか、一般消費者なのか、もしくはほかのエンジニアなのかによっても変わるでしょう。 世の中にどのようなプロジェクトが存在するのか、それぞれのプロジェクトがどのような価値を必要としているのかを、自己分析とセットで考えておく必要があります。これはフリーランスになった後も継続的に考え続けるといいでしょう。 最後にもうひとつ重要なのが、「その価値にいくらの値段がつくか」という点です。 最初のコーヒーの例では、落ち着いた空間で提供される1杯のコーヒーと、そこから生み出されるさまざまな価値に「1,000円」という値段がついていました。フリーランスエンジニアにとっては、このような価値に対して支払われるお金が「報酬」になります。 報酬というと、「PHP歴何年でいくら」といった技術と経験年数で自動的に決まるもののようなイメージを持っている方もいるかもしれませんが、実際はまったくそのようなことはありません。 現実問題として、各フリーランスエンジニアがどのような価値を提供してくれるかを見極めるには、時間的にも金銭的にもコストがかかります。そのため、分かりやすい指標に、分かりやすい値段をつけてそれを「相場」と呼ぶことも多いです。ただし、その相場にどれだけ依存するかは企業の考え方次第なのです。 ひとりひとりじっくりと特徴と価値を見極めたい企業にとっては、相場は参考程度に、その価値にいくらの値段を支払えるかを基準に報酬金額を決定します。 そして、この「いくらの値段で支払えるか」を決める要因は、どれだけ緊急で人材を必要としているか、ほかにアテはあるのか、予算に余裕はあるのか、などの状況によってさまざまであることも忘れてはいけません。 1杯1,000円のコーヒーも、周辺にカフェがなければ利用されやすく、逆に同じような場がほかにあれば検討の末に利用されないことも増えるでしょう。 言い換えれば、提供する価値は同じでも、その適正な値段は受け手次第なのです。 このことはコンビニや飲食店での消費活動が多い一般消費者の目線では忘れられがちなのですが、「適正な価格」は一定ではありません。 例えば企業間の売買において、最終的な金額はお互いの話し合い次第です。売り手は要件に応じた見積もりを出し、買い手はその内容を見て削れる部分は削ったり、相見積もりをとって比較したりして金額を調整し、最終的に合意に至った値段で契約します。最初から商品に値札がついて並んでいるわけではありません。 フリーランスエンジニアにとっての報酬額も同じです。報酬額や条件は相場や工数から機械的に算出するものではなく、常にお互いの合意によって決定します。その際、より良い条件で合意を得るために「自分はどのような価値を提供できるか」、「相手はどのような価値をどれだけ必要としているか」を把握するのが大事になる、というわけです。「己を知り敵を知れば百戦危うからず」のことわざの通りですね。 もし自分の価値と相手の求める価値が合致しなければ、話を白紙に戻して別の案件を探せばいいでしょう。無理に譲歩して契約しても、参加したときに思うような成果が出せずお互いに損をするリスクが高まることを考えれば、白紙撤回を「悪い」ことと思う必要はありません。何よりそのような判断を自分でしていけるのがフリーランスエンジニアの面白いところだと思います。

繰り返しですが、企業が必要としているフリーランスエンジニアの「価値」とは「高い技術力」そのものではなく、それを含むさまざまな特徴から生み出される「価値」です。そして、どのような特徴からも「価値」が生み出される可能性があること、どの価値にどれだけの値段がつくかは相手の企業次第であることも忘れてはいけません。 報酬額をはじめとしたさまざまな条件は、機械的に決めたり誰かに決められたりするものではありません。フリーランスエンジニアと企業が、お互いにとってより良い条件で契約できることを目標に、自己分析をしたり、身の回りのサービスが生み出す価値を観察したりしてみるといいでしょう。（※2）その積み重ねこそが、自分のフリーランスエンジニア生活をより良いものにしてくれるはずです。 ------ ※1: 間違えてはいけないのは、このような「1杯数百円のコーヒーを提供するお店」も同じように「1杯1,000円のコーヒー」にはない価値を生み出しているという点です。それは何か、考えてみるといいでしょう。 ※2: 例えば多くのフリーランスエンジニアが利用する案件紹介サービスが生み出す価値はなんでしょうか。その価値に対していくらの値段がつけられているでしょうか。考えてみましょう。

なぜ人はコーヒー1杯に1,000円という大金を支払うのでしょうか？　1杯1,000円のコーヒーが生み出す価値について考えながら、フリーランスエンジニアが企業に提供できる価値と、フリーランス生活をより良い条件で実現するためのアイデアについて考えてみましょう。

新着の記事一覧

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

Railsのファットコントローラー 3つの対処法

GitHub Packagesを使って自作ライブラリを管理しよう

クライアントは上司？フリーランスエンジニアの「自由」な意思決定とは

Railsのファットモデル 3つの対処法

1杯1000円のコーヒーから考えるフリーランスエンジニアの価値

おすすめ記事

丸山・セイト先生コラボ対談【2026年最新・AIとフリーランスエンジニアの最前線】

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

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

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

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

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

Railsのファットコントローラー 3つの対処法

GitHub Packagesを使って自作ライブラリを管理しよう

クライアントは上司？フリーランスエンジニアの「自由」な意思決定とは

Railsのファットモデル 3つの対処法

1杯1000円のコーヒーから考えるフリーランスエンジニアの価値

丸山・セイト先生コラボ対談【2026年最新・AIとフリーランスエンジニアの最前線】

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

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

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

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

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