↓まだチャンネル登録をしていない人はこちらから！↓<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; 拙い文章でしたが、最後まで読んでいただきありがとうございました。

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

インフラエンジニアとして業務をしているとGUI（Graphical User Interface）とCUI（Character-based User Interface）どちらで作業するかというところが人や開発現場によって違う場合があります。当方もそのような経験があります。今回はそんなGUIとCUIの違いと使い分け方を説明します。

ユーザインタフェースと読み、機器やソフトウェア、システムなどと利用者間で情報をやり取りする仕組みのことです。システムから利用者への情報の提示・表示の仕方と、利用者がシステムを操作したり情報を入力したりする手段や方式、機器、使い勝手などのことを指します。簡単に言えば画面・見た目・使い勝手のことを指します。

GUIとは「Graphical User Interface」の略でwindowsやMacのマウスでの操作や銀行のATMなどの画面のように直感的な操作ができます。 &nbsp; CUIとは「Character-based User Interface」の略でLinuxのターミナル画面やWindowsのコマンドプロンプト、ネットワーク機器のコマンド操作などのようなイメージです。 &nbsp; コンピュータは元々すべてCUIのコマンドベースで利用されていました。より利用者にとって利便性のある画面が必要となりGUIが開発されました。 &nbsp; &nbsp; 次に同じ作業をする場合にGUIとCUIで行うと具体的にどう変わるのかwindowsとYAMAHAのルータで見ていきましょう。 &nbsp; ・windowsでのファイルコピーの例 GUI（マウス操作）の場合

CUI（コマンドプロンプト）の場合 コマンドを「copy test.txt test_back.txt」と入力して完了

※コマンドプロンプトの場合、同じファイル名は指定できないので意図的にコピー後のファイル名は「test_back.txt」としています。 ・YAMAHAのルータで初期設定を設定する例 GUI（マウス操作）の場合 ルータにLANケーブルを接続してPCからweb画面にアクセスして設定したい箇所をクリック or 値を入力

CUI（ターミナル画面）の場合 下記の画像のようなコンソールケーブルにて接続 or ネットワーク機器の管理ポートより接続後、設定したいコンフィグ例のように設定したいコンフィグをテキストベースで用意しておき、「Tera Term」にてコピー・貼り付けで設定 &nbsp; ※ネットワーク機器をCUIで設定する場合は「Tera Term」というターミナルソフトを事前にダウンロード・インストールしておく必要があるので注意してください。

windowsとYAMAHAのルータで説明しましたが、このように同じ作業をしていてもGUIで行う場合とCUIで行う場合では手順が異なります。

GUIとCUIのメリット・デメリット

◆メリット 視覚的に操作が可能なため簡単に設定ができる コマンドを覚える必要がない 設定内容や統計情報の確認がしやすい &nbsp; ◆デメリット 画面のクリック・タッチが必要なため操作ミスが起きやすい 一度に複数個所の設定変更をすることができない

◆メリット コマンドベースで作業ができるためコマンドをテキストベースであらかじめ用意しておけば、それをコピー・貼り付けするだけで設定が可能 コマンドを打つだけで設定が即時反映されているか確認が可能 一度に複数個所の設定変更が可能 &nbsp; ◆デメリット コマンドを覚える必要がある

ネットワーク機器の場合 当方の経験上は設定確認も含めほぼ全てCUIで設定していました。ですがクラウド管理型のネットワーク機器の場合はGUIしか利用できない機器もあります。クラウド管理型はファームウェアのバグなどで設定変更したのに設定が反映されなかったこともありました。クラウド管理型は設定変更もGUIで行うので設定の確認自体は容易ですが、設定が反映されたかの確認についてもGUIでしか確認する手段がなく、実際に変更されているかは機器を設定変更後に動作させないと設定変更が完了したとは言い切れない点に注意が必要です。CUIが利用できる機器については設定の即時反映は必ずCUIで確認することをお勧めします。またネットワーク機器の中でもファイアウォールやUTMは用途によって使い分ける 事が多いです。当方の経験で例を挙げるとファイアウォールのテストの際、ログの確認はCUIだと見えづらいのでGUIで視覚的に確認していましたがVRRPの冗長化の確認は切り替わりをすぐに確認したいのタイムラグの少ないCUIで確認していました。 &nbsp; サーバの場合 windowsサーバの場合はGUIが発達しているため一部のファイルの中身の確認やプロパティの確認ではGUIで確認していました。ファイルの移動などはクリックミスが発生するためCUIで行っていました。Linuxの場合は複数のファイルを同時に作成したり、自動でプログラムを走らせたりするのでCUIで作業することがほぼ100％でした。

ここまでGUIとCUIついて説明してきましたが、どちらにもメリットとデメリットはあります。 どちらを利用するかについては現場ごとに分かれることもありますので作業手順書を作成する際などは必ず確認するようにしましょう。 CUIで作業すれば作業手順書のコマンドをそのままコピーして貼り付けするだけで作業は完了しますし、前述したような「Tera Term」というターミナルソフトを使えば作業したログをテキストベースで保存できるので安全に作業できるので圧倒的にCUIを使うことが多いと思います。 またCUIであればネットワーク機器にはコンソールケーブルで接続でき、作業PC自体の設定も不要になりますのでこういった点でもCUIの方に利点があると言えます。

【初心者のインフラエンジニア必読】GUIとCUIの違いと使い分け方を解説

安部　真浩

ネットワーク系エンジニアとして案件をこなしつつ、ライターとして執筆活動にもチェレンジ中。株式会社グラントホープ所属のフリーランスエンジニア。趣味は貯金でFIREを目指しています！

頭の中で現在問題と課題、それと課題解決に向けての順序など整理整頓は得意でしょうか？ それらの情報が複雑に絡み合ってしまいほどくことができない状態になってしまっていないでしょうか。 頭の中の情報の整理が得意なひとは、考え方に一貫性があり思考の整理が短時間でまとめることができます。 それ以外にも、多方面からの視点で考えることができ問題の漏れを防ぎ、そこから解決までのプロセスが容易に思いつくことができます。 そういう志向の整理が得意な人の話にはなぜか説得力がある話かたができます。 一方、情報の整理が苦手な人は思い付きの断片的な思考に偏りがちになり、思考の漏れが多くなってしまいます。 そのため、何かを考えるときに混乱をしてしまい、説得力がない話になりがちです。 一見、うまい提案ができたように見えても現実味のない提案だったりします。 では。 頭の中が整理整頓されている人は、どうやって情報をまとめているのでしょうか？ そのような人は、テンプレートのような決まった思考処理を複数持ち合わせており、それらを駆使して考える習慣を持っています。 そのテンプレートとはなにか？ テンプレートの使い方とは？ どういった場面でどういうテンプレートが効果発揮するのか？ というのを、全7章でお伝えしていきたいとおもいます。 種類はたくさんありますが、時と場合と状況ごとにテンプレは決まっていますので 自分がクリアしたい問題箇所だけでもピックアップして参考にしてください！

■問題解決は大きく分けて7つの状況に当てはまる

一言で問題解決と言っても様々な問題が世の中には溢れかえっています。 それぞれの問題には大きく分けて7つの状況に当てはめることができると考えています。 それが以下の通り！

ここでは大雑把に7つそれぞれの状況の解説をします。 もっと細かな説明については別の章で説明したいとおもいます。

市場の分析・販売戦略の策定、新規顧客の開拓など。 マーケティング戦略に関する正確な調査分析が可能になります。 また、漏れやダブりをなくし、リサーチと分析を行うためのものとなります。 第1章の記事は<a href="https://engineer-first.net/a5mwnclegd" target="_blank" rel="noopener noreferrer">こちら</a>から。

問題の原因は１つとは限りません。複数の原因が複雑に絡み合ってまるで原因が一つのように見せているだけかもしれません。 そんな問題を効率的に見つけ、真の原因を追究し、適切な解決策を導き出す為に使用するものになります。

アイデアを出し続けることは決して容易ではありません。場当たり的にアイデアはでますがすぐに枯渇してしまい行き詰ってしまいます。 ここで紹介するテンプレを使用することでだれでも簡単にアイデアを出すことができものとなります。

新たな市場を獲得するためには、どの報告にビジネスの舵を切るかが一番大事です。 ターゲットにする年齢はどこなのか、投資の優先順位はどのようにつけるのかなど、重要な思考をもち決定をしなければいけません。 その際に役立つテンプレートとなっています。

プロジェクトを進めるには、事前の計画が重要になります。 全体像の把握・作業の漏れ・作業のダブりを洗い出し、優先順をつけたうえで計画を立案します。 その後、やりっぱなしではなく検証し評価を出すためのものになります

ビジネスの強化をするためには「人・物・金・情報」の適切な投入とその強化が必要になってきます。 それと同時に「撤退・新規」を繰り返すことで新陳代謝を図っていく必要もあります。 そのための速やかな判断のためのものとなっています。

そして最後に。 論理的に相手を説得するために物事を体系的に整理して順序だてて話を進めるのに役に立つテンプレになります。 またはレポートをまとめたり、日常的な会話においても広く使えるものとなっています。

と、それぞれの状況に分けて使用できるテンプレを説明していきたいと思いますので、 自身がおかれている状況と抱えている問題から気になる章だけでも見てもらえればと思います！

■そもそも、ビジネスにおける”問題”とはなに？

・「求める姿」と「現在の姿」とのギャップ。それが”問題” ・ギャップを埋める為にも一つ一つ登っていく階段。それが”課題” ・階段を一段ずつ登っていくこと、それが”対策”

そもそも、問題とは今ある状況とのギャップのことをいいます。 そのギャップを埋めていくために実施していくものが課題です。 そして、それらの課題をひとつずつクリアしてくことが対策になっていきます。 &nbsp; 例えば、ラーメン屋さんの売り上げを月に100万円にしたいという求める姿があったとして、実際の売り上げが45万円だとした場合。 そこには55万円のギャップ（問題）が生まれていることになります。 &nbsp; では、それらのギャップを埋めるために必要な課題を何かと考える必要があります。 例えばこんな感じ・・ ・客一人当たりの売り上げ単価を上げる ・客の回転率をあげる ・ちらしを配って新規客を増やす ・曜日ごとにラーメンの種類を変える といった、課題があるとします。 &nbsp; これらの課題を実行に移し行動していくことが対策となるわけです。 &nbsp; &nbsp; 上記はあくまで例ではありますが、 ビジネスでは様々な問題が起こっており、事業活動の脅威となるようなマイナスの「現象」のことを問題といいます。 よく、問題と課題をごっちゃにする場合がありますがこれは似て非なるものです。 &nbsp; ビジネスには必ず指針となる目標があります。 目標とはなりたい姿であり、期待される結果でもあります。 &nbsp; 「現状」と「目標」にはギャップがあり、そのギャップを埋める行為が対策となるのです。

★問題とは大きく3つに分けられる では、問題そのものについて考えてみます。 ビジネスにおける問題は主に以下の3つにわけることができます。

①すでに発生している問題 ②これから発生する問題 ③気づいていない問題

先ほどのラーメン屋を例にしますとこんな感じ。 例えば「客足が遠のいている」「新規顧客が減っている」「近くにライバル店が立った」などです。 これらはすでに発生してしまっている問題になるので早急な対応が求められます。

例えば「食中毒が発生する」「食品が値上がりする」「店の周りの人口が減っている」などです。 初めの①と比べるとかなり優先順位は下がりますが、早めに手を打つことで影響を最小限にしたり、回避することもできます。

例えば「従業員のスキルにムラがある」「食品ロスに偏りがある」「お客さんへの反応が遅い」などです。 これらは潜在的な問題として、内部の人間には気づきにくい問題だったりします。 どこかで慣れがでてしまいそれが当たり前に感じてしまうことで起こる問題です。

★ビジネスにおける課題と対策

課題とは前述のとおり、問題を解決するために起こす行動の一つです。 例えば、ラーメン屋さんの例では「売上の低迷」という問題があるとします。 その問題に対しては「売上の向」を課題として掲げたとします。 その課題の手段として「チラシの配布」や「クーポン券の配布」などの具体的な行動が考えられ、これらが対策となるわけです。 繰り返しになりますが、 「現状」と「あるべき姿」とのギャップ＝「問題」 ギャップを埋めるためにすべきことを「課題」 課題を実行することが「対策」となることを覚えてください。

■問題を解決するにはどうしたらいいの？

・物事を俯瞰（ふかん）して現状と目標を明確にする ・仕事を個で見ないで、全体をみる ・仕事全体の流れを理解する

問題を解決するには、何が問題なのかを明確にする必要があります。 問題とは現状と目標のギャップのわけですから、そのギャップを見つけるためには、物事を俯瞰して全体を把握したうえで「現状把握と目標を明確にする」ことが大事になります。 それによって問題が発見されれば、ギャップを埋めるためにすべきことを洗い出し、具体にてきに何をすればいいのかを考えるといった流れになります。

問題解決には2つの力が必要です。 ①物事を俯瞰してみる力 ②仕事全体の流れを把握する力 物事を俯瞰して見るということは、今現在何が起こっているのかをまるで鳥になったつもりで遥か遠くから眺めるようなイメージです。 言い方を変えれば、第三者の当事者とは全く関係のない目線に立つことで「全体を客観的」に見る力とも言えます。 また、物事を俯瞰してみることができる人は「問題の本質がどこにあるのか見極めることができ、近い将来の問題なども予測できる」ことができます。 ですので、いざ問題が起こったときにも冷静に対処がすることができます。 仕事全体の流れを把握することは、自分だけの範囲の仕事だけではなく「ビジネス全体の流れをみる」ことが必要になります。

■解決までに必要なプロセスってなに？

・根本原因を見つける ・問題解決のプロセスを意識する ・やっぱり俯瞰した目線が必要

★まずはやっぱり全体を見る。そして根本的な原因を探る

色々な問題が発生したときに、場当たり的な対策を講じても根本的な解決にはなりません。 例えば、あかちゃんがティッシュをちぎっては投げちぎってはなげをしていた場合 場当たり的な対策しかできない人は、散らかったティッシュをかたづけて満足してしまうでしょう。 もっと根本的に解決しなくてはいけないのは、赤ちゃんとティッシュを離すことです。 そうすればティッシュが散らからなくなりますから。 むしら、もっと事前にこの問題を発生させないために、あかちゃんの手の届かないところにティッシュを行いようにするといった対策もとれたはずです。 このように俯瞰して問題をみることができることで、根本的な問題を探れるようになります。 これをビズネスの現場に落とし込むのであれば、問題解決のプロセスは次の通りになっています。

１テーマ設定 ２目標設定 ３現状分析 ４ギャップの認識 ５改革方針の明確化 ６対策の立案 ７実施

例えば、「売上向上」を例にすると 何のために（目的）、いつまでに達成するか（納期）を設定します。

何を達成したいのか、テーマ達成後（ゴール後）の姿を明確にします。 なるべく明確に、現実的な目標ではなくてはなりません。

ヒアリングした結果やデータ等によって現状を把握します。 客観的な視点で問題を認識するには、様々な情報を収集しインプットする必要があります。

あるべき姿と現状のギャップ（問題）を明確にします。 原因は一つとは限りません。 複数ある場合もありますので、何が足りないのか、何がボトルネックになっているかなどを探っていきます。

現状の打開のための方針（コンセプト）を明確にし、メンバーと認識を合わせます。 実施段階に入ってからも、何度もコンセプトを振り返ることで方針のブレをなくし最短で問題解決を遂行することができます。

具体的に、より詳細に何を実施するのかを明確にします。 実行計画を作成するにあたって、内容の粒度は細かいほうがいいです。 例えば、必要な人員や予算など考えながら、現実的な範囲でプランを立てます。

「６対策の立案」で立てたプランに沿って対策を実施します。 これはやりっぱなしではなく、実施した結果どうなったのか評価も行います。 成果が上がっていないのであれば軌道の修正を行い、また、実行をする。 この繰り返しをすることで問題の解決を目指します。

■問題解決できない！その理由は！？

・目標設定が間違っている ・現状把握が適切ではない ・計画自体に無理がある

★問題が解決できない理由は３つ！

①設定した目標を見失っている ②現所を正しく把握・理解していない ③そもそも、計確認無理がある 立てたプランをもとに問題解決を実施していても、なぜか問題が解決できないといった場合は、これらの3つの理由が起因していることがほとんどです。 ①設定した目標を見失っている まずは、どこで間違ったのかを見定める必要があります。 それには、問題解決のプロセスを見てみましょう。 「テーマ設定」や「目標設定」が間違っていたとしたら、その後のプロセス全てでうまくいきません。 「今、何を解決しようとしているのか、目標は間違っていないか、改めに見直し」をしましょう。 ②現所を正しく把握・理解していない 問題解決のプロセスの中で、もっとも間違える原因となりがちなのが「現状分析」です。 現状が正しく分析されていなければ、現状が正しく分析されていなければ対策も的外れなものとなってしまいます。 「情報収集は十分だったか？客観的な分析はできているか」を再度チェックしましょう。 ③そもそも、計確認無理がある 目標設定や現状分析は正しくできているにも関わらず、問題解決がうまくいかない場合は、対策の立案に無理がある場合があります。 スケジュールは適切であったか。 人員や予算は足りているか。 それらは実現可能なものだったか。 「実際の行動に移せるだけの具体性はあったのかを改めてみなおします」

■問題解決するために必要なものはテンプレート！？

・問題の種類ごとにテンプレートがある ・漏れやダブりなくなる ・最速で解決できる！

問題解決能力そのものを高めるために必要なツールが「テンプレート」です。 あらゆるもの毎を漏れやダブりが無い状態で分類するためのもので、1980年第にマッキンゼー・アンド・カンパニーをはじめとするコンサルティング会社や学者が考えだした分析ツールです。 現代でも企業やコンサルタントが戦略の決定などを行う際に利用されて続けているとても便利なツールです。 いわば「数学で言う公式」のようなものです。 これらを上手に活用することで様々な問題がスムーズに解決でき、仕事のスピードをアップします。 何度も使用しているうちに身につき、自然とフレームワーク思考になっていきます。

なにより「意思の決定や企画立案の速度が格段にアップします。」 ビジネスの現場では常に様々な問題が発生します。 原因は複雑に絡み合い解決に時間を要することがあります。 そこを短時間で解決する方法を知っておくと問題の山積みをなくし、次々解決することができるようになります。

★テンプレにはどのようなものがあるのか？

目的によって数多くありますがおおよそ次の３つに分類されます。 ①要素を分析する 「要素を分析する」テンプレは「問題や課題を分析して体系的にします。」 ②流れを見る 「流れを見る」テンプレは「仕事の流れや物事の流れの順を追って表すものになります。」 ③対比をする 「対比をする」テンプレは「2軸のマトリックスを作り物事の位置図家を明確にします。」

■テンプレをどのように使いこなせばいい？

・適当にテンプレを使えばよいわけではない。 ・すべてのテンプレを覚えなくOK ・状況に合わせてテンプレを使用できればOK

★目的に合わせて使用するテンプレを選ぶ

&nbsp; ばらばらの情報をすっきりと整理したり複雑な問題を体系化したりして、問題点や方向性を明らかにするために効果てきなツールです。 ただ闇雲に使えばいいというわけではありません。まずは、目的に合ったものを使うことが大事です。 先にも述べてはいますが目的は大きく分けて次の通り。 第１章　リサーチ・分析 第２章　問題の洗い出し・テーマ化 第３章　アイデアの出し 第４章　方針の決定 第５章　計画の立案と承認 第６章　計画の推進 第７章　問題の検証と報告と終結 7つの分類に分けることができます。 それぞれの「目的を達成するために最適なテンプレを見極めましょう。」 初めはどの問題をどのテンプレに当てはめればいいのかわからないかもしれませんが、少しずつ利用していくことで自分の身につけていきましょう。 一度にあれもこれもと手を付けず、自分が使いやすいものを一つ見つけて何度も使うことで慣れていくことから始めるとよいと思います。

今回は第0章ということでテンプレートを使用することでどのような利便性があるかを記載しました。 ここまで、読んでいただいた方はもう理解されたかと思いますが、問題解決への最短はこれらを理解することにあります。 現状を俯瞰して分析をし、ゴールに向かって段階的に解決策を実行する。 ただこれだけのことではあるのですが、これだけのことがいざ仕事となるとできなくなってしまうのが実情です。 ですので、その時はこの記事を思い出していただいて振り返っていただければと思います。 次回からは実際にテンプレを使用する方法についてお知らせしたいとおもいます。 どうぞお楽しみに！

上流業務の必須パッシブスキル【問題解決】を身につける　　～第0章～

なっしー（岩瀬　勝義）

インフラエンジニアとして働きながら、趣味でプログラムやネットワークを勉強し、
収入の三本の矢を目指して、仮想通貨や不動産やブログなども勉強中。
一旦の目標としてどこに住んでいても生きていいける基盤つくりを目指しています。

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

フリーランスエンジニアはその仕事の性質上、初めて会うクライアントに対して自身のスキルを正確に理解してもらい、それを踏まえて労働条件や報酬などの交渉をする必要があります。 その際、「自身のスキル」を伝えるために最もよく使われる指標が、「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に登壇することは、発表内容から技術的なスキルを見せるだけでなく、コミュニケーションのとりかたや興味関心といった人間的な要素も同時にクライアントに見せられるのが最大のメリットといえるでしょう。

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

タグ:【技術力】の記事一覧

【初心者のインフラエンジニア必読】GUIとCUIの違いと使い分け方を解説

上流業務の必須パッシブスキル【問題解決】を身につける　　～第0章～

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

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

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

おすすめ記事

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

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

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

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

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

【初心者のインフラエンジニア必読】GUIとCUIの違いと使い分け方を解説

上流業務の必須パッシブスキル【問題解決】を身につける ～第0章～

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

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

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

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

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

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

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

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

上流業務の必須パッシブスキル【問題解決】を身につける　　～第0章～

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

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