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

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

どうも、oskn259です。 みなさんは、APIを構築するときどの言語を使っていますでしょうか？ 例えばPHPでLaravel、JavaでSpringFrameworkというのは一般的かと思います。 PHPはわかる人が多くて人的リソースを活用しやすいですし、Javaは動作の高速さや充実のドキュメントがいいですよね。 ただ、webサイトを作るときにはどうしてもjavascriptというものを避けて通れず、二種類の言語を使わざるを得ない状況となっています。 最近ではフロントとバックエンドを完全に分担する形が多いですが、コミュニケーションコストが増大しますし、個人的にはできれば避けたい形と思っています。 そこで今回紹介するのはこちらです。 <a href="https://hapi.dev/" target="_blank" rel="noopener noreferrer">https://hapi.dev/</a> javascriptで書けるwebフレームワークで、元々はExpressの開発者の一人がシンプルさを求めて新たに始めたプロジェクトのようです（確かそう、違ったらすいません）。 これが本当にシンプルで、最低限のコア部分に、自分が必要だと思う機能のみを付け足していく感覚がは触っていて楽しいですね。 僕が現在担当している案件では、<code>hapi.js</code>をapiのコードベースに使用しています。 つまり、フロントもバックエンドもTypescriptで記述しています。 これによって、参加エンジニアがフロントとバック両方を変更できる状態に近づけようとしています。 今回はhapi.jsセットアップのさわりの部分を解説していきます。 今回の内容はこちらで書いた記事の修正版でもあります。 <a href="https://blog.oskn259.com/article/lets_hapi_js" target="_blank" rel="noopener noreferrer">https://blog.oskn259.com/article/lets_hapi_js</a>

sh $ mkdir hapi_hapi_nyowa $ cd hapi_hapi_nyowa $ yarn init $ yarn add @hapi/hapi $ yarn add -D typescript @types/node 以上のようにnodeプロジェクトをセットアップしたら、以下のファイルをその場に配置します。 json // package.jsonへ追記 { &nbsp;"scripts": { &nbsp;&nbsp;"build": "tsc", &nbsp;&nbsp;"start": "node index.js" &nbsp;}, } json // tsconfig.json { &nbsp;"compilerOptions": { &nbsp;&nbsp;"esModuleInterop": true, &nbsp;&nbsp;"rootDir": "." &nbsp;} } ts // index.ts import { Server } from '@hapi/hapi'; const server = new Server({ &nbsp;port: 5000, &nbsp;host: '127.0.0.1' }); server.start(); 実行します。 sh $ yarn build $ yarn start sh $ curl http://localhost:5000 {"statusCode":404,"error":"Not Found","message":"Not Found"} APIサーバーが完成しました！！！ お仕事終わり！！帰宅！！

hapi.jsでいかにシンプルにapiサーバーを構築できるかがお分かりいただけたかと思います。 404を返すサイトでお金を取るのは難しそうなので、何かしらのコンテンツを返すように拡張してみましょう。 ts // index.ts import { Server, Request, Response } from '@hapi/hapi'; // ... server.route({ &nbsp;method: 'GET', &nbsp;path: '/', &nbsp;handler: function (req: Request, res: Response) { &nbsp;&nbsp;return { msg: '開けろ！デトロイト市警だ！' }; &nbsp;} }); server.start(); sh $ yarn build $ yarn start sh $ curl http://localhost:5000/&nbsp; {"msg":"開けろ！デトロイト市警だ！"} いかがでしょうか？ ここまで、APIサーバーを起動するという目的以外の余計な記述をほぼしていません。 hapi.jsに限らず、このように目的に集中できるフレームワークは僕は好きですね。

ページの追加もとても簡単に完了しました。 これだけで終わるのも寂しいので、個人的に便利だと思っている機能を一つ紹介しましょう。 sh $ yarn add joi ts // index.ts import Joi from 'joi'; // ... server.route({ &nbsp;method: 'GET', &nbsp;path: '/', &nbsp;handler: function (req: Request, res: Response) { &nbsp;&nbsp;// @ts-ignore &nbsp;&nbsp;const speaker = req.query.speaker; &nbsp;&nbsp;return { msg: `${speaker}: 開けろ！デトロイト市警だ！` }; &nbsp;}, &nbsp;options: { &nbsp;&nbsp;validate: { &nbsp;&nbsp;&nbsp;query: Joi.object({ &nbsp;&nbsp;&nbsp;&nbsp;speaker: Joi.string().required(), &nbsp;&nbsp;&nbsp;}), &nbsp;&nbsp;}, &nbsp;&nbsp;response: { &nbsp;&nbsp;&nbsp;schema: Joi.object({ &nbsp;&nbsp;&nbsp;&nbsp;msg: Joi.string().required(), &nbsp;&nbsp;&nbsp;}), &nbsp;&nbsp;&nbsp;sample: 100, &nbsp;&nbsp;} &nbsp;} }); server.start(); sh $ yarn build $ yarn start sh $ curl http://localhost:5000/&nbsp; {"statusCode":400,"error":"Bad Request","message":"Invalid request query input"} はい、弾かれましたね。 上記の<code>options</code>部分の追記だけでクエリのバリデーションが行われるようになり、クエリが空のリクエストを弾いています。 クエリを正しく付与して再度アクセスしてみましょう。 sh $ curl http://localhost:5000/?speaker=Cona {"msg":"Cona: 開けろ！デトロイト市警だ！"} ちなみにお察しの方も居るかもしれませんが、 リクエストだけでなく、レスポンスにもバリデーションをかけることができます。 意図的にレスポンスをおかしな値にして試してみましょう。 ts // index.ts // ... &nbsp;&nbsp;// @ts-ignore &nbsp;&nbsp;const speaker = req.query.speaker; &nbsp;&nbsp;return { msg: { 'open_up': 'Detroit_Police' } }; // ... sh $ yarn build $ yarn start sh $ curl http://localhost:5000/?speaker=Cona {"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"} このように、期待するスキーマと実際のレスポンスが異なる場合は500を返す、という動作をとります。 バリデーション機能は、以下のような面で僕の開発にとても役立っています。 <ul><li> ロジックの設計ミスで思わぬ情報を返してしまうおそれがない</li><li>外部からの攻撃によって意図しない情報を返却してしまうリスクを減らせる</li><li>バグの早期発見に役立つ</li></ul>&nbsp;- 特にこれは頻繁に体感します &nbsp;- DevOpsの一環とも言えますね

サラッと通過しましたが、リクエストやレスポンスのスキーマをチェックするために`Joi`というライブラリを使用しています。 これがとても表現力の高いバリデーターで、表現できなくて困るという事態に僕はまだなっていません。 例えばこんな感じで値やオブジェクトの型をチェックすることができます。 非常に便利で、DBやネットワーク経由で取得した値のバリデーションにも使用しています。 ts cosnt validator = Joi.object({ &nbsp;greeting: Joi.string().valid('やぁダニエル', '君を助けにきたんだ').require(), &nbsp;isHaveGun: Joi.boolean().require(), &nbsp;stressLevel: Joi.number().min(0).max(100).require(), }); const result = validator.validate(android); if (result.error === underined) { &nbsp;console.log('コナーです'); }

今回はhapi.jsの簡単な導入と、Joiを使ったバリデーションを紹介しました。 hapi.jsのこうした点を感じてもらえれば嬉しいです。 <ul><li>とにかくシンプル</li><li>Joiと連携した強力なバリデーション機能</li></ul> こうしたシンプルなコアをベースに、オプショナルに記述できる機能や多数のプラグインが存在しており、実際のサービス構築にも十分耐えうる機能を有しています。 モノリシックなフレームワークの、体系化された集合知をそのまま活かせる雰囲気も良いですが、自分になじむようカスタマイズされたコードベースでの開発もなかなか良いものですね。

hapi.jsと出会って10分でAPI起動

oskn259

WEBフルスタックエンジニアとして、新規開発、保守全般業務を並行して請け負う。
経験を活かし、WEB開発進行のコンサル業も行う。
直近のメイン業務は金融系サービスのPdM。
重要なのはトンカチを使えることではなく、頑丈な家が建つこと。

皆さんは、システムエンジニアとしてどの工程を担当していますか？ 上流工程を担当していますか？それとも下流工程を担当していますか？ &nbsp; フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。 &nbsp; そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けできたらと思います。 &nbsp; 今回はver2として、「上流工程」と「要件定義」についてお届けします。 &nbsp; ぜひ、上流工程や要件定義の仕事に従事されている方、上流工程や、要件定義の仕事をされたい方は、ぜひご覧ください。

まず、上流工程についてです。こちらの図をご覧ください。

これは、ウォーターフォールモデルと呼ばれるシステム開発の流れです。 この図の１～３の工程が上流工程と言われています。 まずは、上流工程について、振り返ってみましょう。

システム開発は、要件定義という工程から始まります。 システム開発を依頼する側と開発する側が打ち合わせを行い、システムの性能・機能や運用方法などの「要件」を決定します。 システム開発を依頼する際、希望の機能や性能があるかと思います。その要求と開発会社側の認識にズレがある場合、結果的に希望とは異なるシステムになる恐れがありますので、認識のすり合わせが非常に重要です。

外部設計の工程では、システム使用者(ユーザー)の視点からシステムに必要な機能を洗い出し、それを基に大枠となるシステム設計を行います。 その際システムの仕様などが記された基本設計書を、ユーザー側が確認するケースもあります。

次に外部設計で決定した事項を基に、コンピュータでの実装を想定した上で、より詳細にシステムを設計します。 外部設計がユーザー視点からの設計である一方で、内部設計の工程ではコードやプログラムの設計など、開発者側からの視点でシステムを設計します。

いかがでしょうか？ 上流工程の主な作業としては、実際にシステムを使用されるユーザさんから、実現したい要望をお聞きし、実現方法の検討や、対応時期、対応工数などを調整するのが仕事になります。 また、実際にプログラミングを行うプログラマーに、プログラムを作るための設計書を作成し、説明する仕事もあります。 なので、上流工程は、実際にシステムを利用するユーザさんと、実際にシステムを開発するプログラマーの架け橋となる仕事であると私は思っています。

要件定義の仕事・仕事をこなす上でのコツ

次に、システム開発の最上流である「要件定義」の仕事と、仕事を行う上でのコツを私の経験談からお話します。

要件定義は、開発工程の中で、一番ユーザさんと接する機会が多い工程のため、一日中、打ち合わせとなることが日常茶飯事です。 ユーザさんと打ち合わせを重ねながら、「要件定義書」と呼ばれる成果物を作成することがこの工程での主となる仕事になります。 この要件定義書がないと、ユーザさんがどのような目的でシステムを構築したいのか。や、どのようなシステムを作成したら良いのか。がわからなくなりますので、非常に重要な成果物です。 また、打ち合わせばかりのため、要件定義書を作成する時間をいかに確保するか。と、ユーザ要望をいかに具体的に聞けるか。がこの工程での一番大変な作業だと思います。<h4 id="h056a0d1538"> ●コツ</h4>私が思うこの要件定義を行う上でのコツですが、以下４点だと考えています。 　①システム改修の場合は、改修を行うシステムについて、概要を知る 　②新規システム構築の場合は、IT技術について、幅広い見解を身に付ける 　③要望を全て実現する目標ではなく、より良いシステムを構築する視点を持つ 　④後続工程（設計・開発・テストなど）のことも意識する。

①システム改修の場合は、改修を行うシステムについて概要を知る

システム改修の場合は、システム内の一機能の改修を行う要件定義が多いです。 そのため、改修を行う機能の知識がないと、どのように改修すればユーザ要望を満たせるのか。や、どのようにシステム改修すれば良いのか。を考えることができません。 ただ、機能の細部まで知る必要はなく、概要を抑えていれば要件定義としては考えることができるので、概要を知るだけで良いとも言えます。

②新規システム構築の場合は、IT技術について、幅広い見解を身に付ける

新規システムの構築の場合は、元になるシステムがなく、ユーザ要望だけが存在する状態になります。 そのため、どのようなＩＴ技術を利用すれば、ユーザ要望を実現することができるのか。という考え方が非常に重要になってきます。 そのＩＴ技術の見解を持っていないと、ユーザ要望を実現する方法を考えることもできないため、幅広いＩＴ技術の知識が必要になります。

③要望を全て実現するを目標ではなく、より良いシステムを構築する視点を持つ

結構、システム利用されるユーザは、システム開発やＩＴ技術を知らない人が多く、システムでは実現が難しい要望を言ってくることがあります。 また、出てきた要望がちぐはぐになっていることや、単に実現すると矛盾点がが残ることもあります。 そのため、ユーザ要望を全て実現する。という考え方も大切ではあるものの、やはりシステム開発するプロである以上、より良いシステムを開発するために、矛盾を減らすことや、代替案を提示するなどの、ＮＯと言える、かつ 提案できる力と、ユーザ要望を具体的に聞く力が必要となります。

④後続工程（設計・開発・テストなど）のことも意識する。

要件定義とは、開発工程の一番初めの工程です。そのため、要件定義の内容を元に、後続工程が進んでいきます。 そのため、後続工程をいかに効率よく作業させるか。や、後続工程の品質を向上させるか。などの考え方も重要になってきます。 この考え方を持ち合わせてないと、後続工程が進むにつれ、手戻りが発生することや、バグが多発するなどが多くありますので、単に要件定義を終わらせるという目線ではなく、開発工程全体を俯瞰した考え方が非常に重要です。

いかがでしたでしょうか？ こちらが上流工程と、要件定義の仕事となります。 プログラム開発とはまた違った視点や考え方が必要とされる工程になりますので、プログラミングをされている方からすると、難しく敬遠する方も居られるかもしれません。 ただ、今後のAIなどのIT技術の進展を考えると、上流工程になればなるほど、AIに代替される仕事ではないため、仕事がなくならない。と言えます。 今後もIT業界で仕事をされていきたい方はぜひ、一度興味を持っても良いかもしれません。

システム開発工程ver2

土谷　貴志（つちたに　たかし）

システムエンジニアとして案件をこなしつつ、ライターとして執筆活動にもチャレンジ中。株式会社グラントホープ所属のフリーランスエンジニア。
システムエンジニアの他に、キャリアコンサルタントとして若者のキャリア支援や、LifeTime-Smileというコミュニティ運営など幅広く事業を展開中。
ごく稀に、コミュニティメンバーの記事を投稿するかも。お楽しみに！
LifeTime-Smile：https://www.lifetime-smile.com/


ここ数年でノーコード・ローコード開発という言葉を耳にする機会が多くなりました。 &nbsp; そしてこれらの開発手法の進歩によって、将来的に「ITエンジニアの大半は不要になる」とまで一部界隈では言われているようです。 &nbsp; 今回はノーコード開発とローコード開発の特徴を説明したうえで、ITエンジニアの将来性を考えたいと思います。

ノーコード開発とは、プログラミング言語を用いずにシステム開発を行うことです。 &nbsp; 時代は進みとうとうノンコーディングでシステム開発ができるようになりました。

ノーコード開発の場合はあらかじめ提供されたテンプレートを組み合わせて開発をします。 &nbsp; これにより誰でもシステム開発に取り組めるようになるため、開発者の間口が大きく広がりますね。 &nbsp; 簡易的な業務用のシステム開発などでは、エンジニアの手を借りずとも開発できることもあるかもしれません。 &nbsp; また、既存の開発手法と異なりノンコーディングで行われるため実装工数の削減に繋がります。 &nbsp; ここまでノーコード開発のメリットを解説しましたが、ノーコード開発にはデメリットもあります。

ノーコード開発のデメリットは「実装できる機能はツールで提供されたテンプレートのみ」という点です。 この制約があるため、技術面においてはノーコード開発ツールがITエンジニアを超えるということはないでしょう。 &nbsp; 実際のシステム開発の現場では、イレギュラーな対応が多発します。 ですから提供されるテンプレートだけで機能を賄うことはまず不可能でしょう。 &nbsp; 上記のようなケースが発生すると結局最後にはエンジニアの力が必要になります。 つまりノーコード開発ツールを導入したところで、「エンジニアは全員必要ない」という結論にはならないということです。

ローコード開発は最低限プログラミングを行いつつ、一部のテンプレートを組み合わせながらシステム開発をしていくことです。

ノーコード開発と同様に、実装工数の削減が期待できます。 &nbsp; プログラミングの知識がない方でも多少は導入しやすくなっているため、 簡易的なシステム開発の場合はエンジニアの力を借りなくても開発ができるようになります。 &nbsp; また、ノーコード開発と比較すると拡張性は高いです。ローコードの場合は多少のプログラミングを想定して開発することができるからです。

こちらもノーコード開発と同様に、従来の開発手法と比べるとできることに限りがあります。 &nbsp; もしローコード開発で実現できない場合は、従来手法で開発することになるのでその時は今まで通りエンジニア頼みとなります。 &nbsp; またローコード開発といえど専門的な知識が必要になる場面は出てくる可能性が高いので、 ノーコード開発同様に、「エンジニアは必要ない」ということにはならないでしょう。

さて、ここまでノーコード・ローコード開発の特徴を説明しました。 &nbsp; 続いて今までの情報を踏まえてITエンジニアの将来性を考えてみたいと思います。 &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; しかしIT業界全体としても要求されるレベルがますます上がっていく中で、 ローコード開発のみで対応していくのは現実的ではないと私は考えています。 &nbsp; そう考えると、今のところはあらゆる局面で柔軟に対応できるITエンジニアが不要になるというのは考えづらいです。

今の売り手市場は少し落ち着く

一方、今のエンジニアの売り手市場は少し落ち着くのではないかと思います。 &nbsp; 昨年から「DX」という言葉が認知されてきたり、 新たにデジタル庁が発足しマイナンバーカードを利用した大規模システムを構築したりと、 ようやく日本もIT化を推し進める空気になりましたよね。 &nbsp; しかし年々増加し続けるエンジニアの需要に対して、供給がまったく追いついていないのが現状です。 &nbsp; 私も現場で「なんでこの人がエンジニアとして活動できているのだろうか？」というような、 他人頼みの精神で活動しているエンジニアを見かけることがあります。 （バックエンドエンジニアを名乗っているのにDBの基礎すら理解していないとか） そんな人が月単価60万円（おそらく）で活動しているのを見た時に、非常に複雑な気持ちになりました。 &nbsp; もちろんそのような人と契約を結ぶ企業に問題がある。というのはごもっともなのですが… 根本はエンジニアの供給不足からくる問題だと考えています。 エンジニアが不足している企業としては「とりあえずやってくれるなら細かいことは良いや」の精神で契約を結んでいても不思議ではありません。 &nbsp; ここまでが、エンジニアの供給不足の現状なのですが、 それも下記のような理由から少しずつ改善されて需給バランスは今より整ってくると考えています。 ●&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ローコード・ノーコード市場規模は拡大を続けている ●&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IT業界に勤務する外国人労働者は毎年増加傾向 ●&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2020年よりプログラミングが必修科目になったことで、10数年後から新卒エンジニアの供給が増える可能性が高い ●&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;日本企業の絶対数は減少傾向（もちろん人口も然りではあるが） &nbsp; そしてここからが大切です。 エンジニアの売り手市場が落ち着くということは、エンジニアの競争が激しくなるということです。 &nbsp; もし今エンジニアとして活動できている理由が「市場の人材不足の恩恵を受けているから」という場合は、将来的には少し危うくなっていきそうです。 &nbsp; 仮にこの先需給バランスが整ったとしても、自分の市場価値を落とすことがないように、付加価値を提供できるエンジニアである必要があります。 &nbsp; 技術のスペシャリストを目指したり、上流工程などを経験して幅広く活躍できる自分になる。 など戦略を考えておいた方が良いかもしれません。

いかがでしたか？ 本日はローコード市場の拡大から考えるITエンジニアの将来性について解説しました。 &nbsp; ITエンジニアに求められるレベルは年々上がっていきます。 私たちは常に学び変化を受け入れ続ける柔軟さが大切です。 &nbsp; ローコード開発がどれだけ進歩しても必要とされるエンジニアでいられるように、今から対策しておきたいですね。

ローコード市場の拡大から考えるITエンジニアの将来性

Souta

Web系エンジニアとして活動。共同で開発した音声型ナレッジ共有ツール「decci」を2021年9月β版ローンチ。弱小ブログ運営中。暇だったので当メディアのライターにもチャレンジ。人間の思考に興味関心がありそういう系の本を読むのが好き。

今回の記事のWebフレームワークの紹介_2では、テンプレートを利用してブラウザ上に表示させる内容を紹介しました。 この記事ではもう少し詳しい解説をしていきたいと思います。

テンプレートの配置場所について

※開発環境(動作はMac環境を使用しています。) OS: MacOS Big Sur 11.4 Python: 3.9.7 Django: 3.1.7 IDE: PyCharm &nbsp; 前回の記事では sample_django/sample_dango/の配下のsettings.pyの54行目付近のTEMPLATESの環境変数にて、以下の記述をしました。 settings.py os.path.join(BASE_DIR, 'templates') &nbsp;

プロジェクト配下のtemplatesというディレクトリの下に、テンプレートのファイル(htmlファイル)を配置しました。 しかし、今後プロジェクト配下にアプリケーションが増えることを想定して、templatesの配下をアプリケーションごとに分けてhtmlファイルを設置したいという場面が出てくるかもしれません。 templatesの直下でなく、templatesの配下にさらにディレクトリを作成して、画面上に表示してみようと思います。 &nbsp; sample_djangoの配下のtemplatesディレクトリの配下に以下のディレクトリを新規作成してください。 その後、既存で置いてある、hello_world.htmlのファイルを新規で作成したディレクトリのhello_world_1とhello_world_2の配下に設置してください。 sample_djangoのプロジェクト配下 templates/hello_world_1/hello_world.html &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/hello_world_2/hello_world.html &nbsp; &nbsp; 新規ディレクトリ

作成したディレクトリ配下にhtmlファイルを設置

この状態でWebサーバを起動してみましょう。 起動後、Webブラウザでlocalhost:8000にアクセスしてください。

当然ながらエラーが出ます。 TemplateDoesNotExist at/でテンプレートファイルが見つからないことでエラーが出ております。 &nbsp; settings.pyのTEMPLATEの環境変数にて、 os.path.join(BASE_DIR, 'templates') と記載をしています。 現状のsetting.pyの書き方では、templatesの配下にhtmlファイルを設置してあると想定しているからです。 templatesの配下に新規でディレクトリを作成して、元々あったhtmlファイルを作成したディレクトリ配下に設置しているため、読み込めるファイルが見つからないということが起こっています。 &nbsp; setting.pyのTEMPLATEの中身を以下のように修正すれば表示はされるのですが、 setting.py os.path.join(BASE_DIR, 'hello_world_1/templates') アプリケーションが増えることを想定するとこれでは意味がないです。 ですので、呼び出し側のviews.pyを編集してtemplatesの配下にあるディレクトリを指定して呼び出す実装をしたいと思います。

テンプレート配下にあるディレクトリを指定して呼び出す実装について

ではhello_worldの配下のview.pyを開いてください。 一度以下のように実装をしてみてください。 import os from django.shortcuts import render def index(request): &nbsp;&nbsp;&nbsp;sample_data = {'sample': 'サンプル'} &nbsp;&nbsp;&nbsp;#return render(request, 'hello_world.html', sample_data) &nbsp;&nbsp;&nbsp;return render(request, os.path.join('hello_world_1', 'hello_world.html'), sample_data) 変更場所としては、 1行目のimport&nbsp; osの追加 6行目のコメントアウト 7行目のreturn&nbsp; render(request, os.path.join('hello_world_1', 'hello_world.html', sample_data) の追加 &nbsp; こちらでWebサーバーを起動して、ブラウザでlocalhost:8000と入力してください。

今度は問題なく表示されていると思います。 今回は7行目にrenderの第二引数にos.path.join('hello_world_1', 'hello_world.html') と入力しました。 こちらについて解説をしたいと思います。

os.path.joinというのはパスの要素を結合するものというものです。 setting.pyの環境変数にも記載がありますが、 setting.py os.path.join(BASE_DIR, 'templates') この書き方は第一引数にBASE_DIR、第二引数にtemplatesを指定しております。 つまり/BASE_DIR(プロジェクト配下)/templatesディレクトリ を指していることになります。 view.pyの7行目に戻ってみましょう。 return render(request, os.path.join('hello_world_1', 'hello_world.html'), sample_data) &nbsp; この例ですと、op.path.joinの第一引数にhello_world、第二引数にhello_world.htmlを指定しています。 &nbsp; setting.pyのos.path.joinに(BASE_DIR, 'templetes')となりますので、 /BASE_DIR(プロジェクト配下)/templates/hello_world_1/hello_world.html を指定していることになります。 &nbsp; ではviews.pyの7行目をコメントアウトしてください。 8行目に以下を入れてください。 return render(request, os.path.join('hello_world_2', 'hello_world.html'), sample_data) &nbsp; ブラウザでlocalhost:8000を入れて表示させてください。

同じように表示されていると思います。 この書き方で、views.py側でos.path.joinを指定することにより、templates配下にディレクトリを分けたとしても呼び出せる方法を記載しました。

views.pyの作成した関数の戻り値でreturn render(〜)と記載をしています。 renderについて解説をしていきます。 renderのメソッドは指定したテンプレートにデータを反映し、レンダリングしたHttpResponseオブジェクトを返すということになります。 Renderを使用するにはviews.pyファイルにて、 from django.shortcuts import render &nbsp; の記載をしないと使用できません。 &nbsp; return render(request, os.path.join('hello_world_2', 'hello_world.html'), sample_data) こちらの例で行きますと、 第一引数にrequest 第二引数にos.path.join('hello_world_2', 'hello_world.html'), 第三引数にsample_data とあります。 &nbsp; 第一引数のrequestとありますが、views.pyでindexという関数を作成しています。 def index(request):と定義していて、index関数の引数はrequestとなっているので、 そのままindex関数の引数を入れれば良いです。 &nbsp; 第二引数は表示させたいテンプレートを入れます。 この書き方ですと、templetes/hello_world_2/hello_world.htmlをブラウザ上で表示します。 &nbsp; 第三引数のsample_dataですがこちらは5行目にsample_data = {'sample': 'サンプル} とありますので、sample_dataの変数を第二引数に入れたtempletes/hello_world_2/hello_world.htmlに表示させる処理になります。

redirectも紹介させていただきます。 views.pyのimport文にて from django.shortcuts import renderの右側に , redirect の追記をしてください。 from django.shortcuts import render, redirect index関数の中の5行目以降を全てコメントアウトしてください。 その後一番下に以下を入力してください。 return redirect("https://yahoo.co.jp") そして、Webブラウザ上でlocalhost:8000を入力してください。

Yahooのページにリダイレクトしましたよね。 redirect(リダイレクトしたいURL) かっこの中にリダイレクトしたいURLを入力することにより、関数が呼び出された際にリダイレクトするという機能です。

urls.pyのファイルの役割ですが、djangoの中で、ブラウザのHTTPリクエストに対してどの処理を行うか制御するものになります。 &nbsp; 4行目にurlpatternsがあります。 5行目に path('', views.index, name='index') とあります。こちらはurlpatternsの中に記載するもので、urlpatternsはルーティングを制御するものになります。 pathの使用方法ですが、 第一引数にURL 第二引数に関数(クラス) 第三引数にname=名称 という使い方です。 &nbsp; 第一引数はURLの指定で path('', views.index, name='index') こちらの例ですと''となっています。 localhost:8000以降のURLを指定します。 例えば第一引数に path('hello_world', views.index, name='index'), という書き方をすればブラウザ上で localhost:8000/hello_world と入れれば第二引数にのindexが呼び出されるということになります。 &nbsp; 第二引数は上でも書きましたが、第一引数のリクエストされたURLの関数が実行されるということです。 &nbsp; 第三引数はURLの名称で今回はやりませんでしたので、詳しくは別の記事で紹介させていただきたいです。 簡単に説明すると、こちらは必須ではないですが、テンプレート側のHTMLファイルの{% url name%}と記載して、URL先の指定が簡単になるメリットがあります。

前回の記事で実装した内容をもう少し細かく解説してみました。 template配下の複数のディレクトリのテンプレートの呼び出す実装 os.path.joinの説明 renderの説明 redirectの説明 urls.pyのurlpatternsとpathの説明 &nbsp; 参考URL <a href="https://docs.djangoproject.com/ja/3.2/intro/tutorial03/" target="_blank" rel="noopener noreferrer">https://docs.djangoproject.com/ja/3.2/intro/tutorial03/</a>

PythonのWebフレームワーク『Django』の紹介Ver.2【解説編】

oskn259と申します。 最近は開発プロジェクトの進行や、中長期のソフトウェア開発のアンチパターンに興味を持っているのですが、先日良い記事を見かけたのでそれを解説していこうと思います。 ソースの記事はこちらです。 <a href="https://www.swyx.io/optimize-for-change/ " target="_blank" rel="noopener noreferrer">How To Optimize for Change</a> 複雑さの回避について思うところが僕と近かったので、翻訳も兼ねて纏めていきます。 また、今回の内容はこちらで書いた記事の修正版でもあります。 <a href="https://blog.oskn259.com/article/optimize_for_requirement_change" target="_blank" rel="noopener noreferrer">https://blog.oskn259.com/article/optimize_for_requirement_change</a>

ソフトウェアは将来の変更も含めて仕様みたいなもの。 これに対応するためのポイントは以下の通り。 <ul><li> 通常の変更の想定に留める</li><li> 単純な値のみを扱う</li><li> 変更距離を最小化する</li><li>エラーを早期発見するDevOps</li></ul>

あなたがMagic Money Corpを運営していて、以下のコードが利益を生んでいるとします。 js let input = { step1: 'collect underpants' } doStuff(input)&nbsp; profit(input) // $$$!!! `doStuff`に問題が見つかり、一時的にロジックから削除しなくてはいけなくなりました。 しかし、これをコメントアウトした瞬間、`profit`内部がエラーまみれになって資金源が絶たれてしまいました！ 元々は`doStuff`内部で`input`に様々な更新が加えられており、`profit`ではその更新が前提となる処理をしていました。 そこで`doStuff`がコメントアウトされてしまったため、不整合が生じてしまったということです。 では、`input`をImmutableにすればどうでしょうか？ js let input = ImmutableMap({ step1: 'collect underpants' }) doStuff(input) profit(input) // $$$!!! これなら<code>doStuff</code>をコメントアウトしても、<code>profit</code>の動作には影響ありません！ これは一例ですが、このような、変更しやすい設計とはどういうものなのでしょうか？

なぜ「変更しやすい設計」なのか

改めて、変更しやすい設計は以下のような理由で求められます。 <ul><li> 削除しづらいコードは、削除しやすい他のコードを駆逐し続ける</li><li> 削除しづらいコードは、修正を重ねる過程で技術的負債になる</li></ul> この考えは、以下の概念から派生したものです。 <ul><li><a href="https://twitter.com/cramforce/status/1139925981051801600" target="_blank" rel="noopener noreferrer"> リプレースしやすいシステムは、リプレースしづらいシステムに置き換えられてゆく</a></li><li><a href="https://programmingisterrible.com/post/139222674273/how-to-write-disposable-code-in-large-systems" target="_blank" rel="noopener noreferrer">拡張しやすいコードではなく、削除しやすいコードを書く</a></li></ul> ソフトウェア開発において仕様が固まっていることがベストですが、現実の開発においてそうはいきません。 むしろ、要求が変化すること自体が仕様とも言えます。 開発者はこのことに気を配りながら、「削除しやすい」状態を保たねばなりません。&nbsp;&nbsp;

通常の変更(common change)に留めて想定する

もし、全てが変更されうる、としたら一体どうやってシステムを構成すれば良いでしょう？ 将来の変更に対する過剰な想定は、コード量を倍にも増やしてしまいます。

クライアント要求の微妙なブレに対応できる程度に収め、システムデザインやアーキテクチャを変更するような事態までは考えない、 というのは一つの方法として良さそうです。 ごく稀な変更に関しては、それは作り直すための理由となり得る、という点もあります。 また、根本からの変更を要求されるような場面は、そもそも予想しやすいという事もあります。 クライアント要求の微妙なブレに対応できる程度に収め、システムデザインやアーキテクチャを変更するような事態までは考えない、 というのは一つの方法として良さそうです。 ごく稀な変更に関しては、それは作り直すための理由となり得る、という点もあります。 また、根本からの変更を要求されるような場面は、そもそも予想しやすいという事もあります。

こうした想定のもと「変更しやすい設計」を実現するには、以下のような実装が求められます。 <ul><li>削除しやすい</li><li>切り貼りしやすい</li><li>抽象化を介して機能の作成、削除ができる</li></ul> <a href="https://www.infoq.com/presentations/Simple-Made-Easy/" target="_blank" rel="noopener noreferrer">https://www.infoq.com/presentations/Simple-Made-Easy/</a> Simplicityについて説いたこの資料によれば、オブジェクトやインスタンスを受け渡している箇所において、代わりにそれをimmutableでシンプルな値として渡すように変換できます。 このことであらゆる種類の潜在的なバグを回避できるということです。 このことを突き詰めると、イミュータブル化、関数型プログラミング、といった実践的な概念を得ることができます。 単純さを追求すると計算的なコストを支払うことになりますが、キャッシュ等の方法で軽減することはできます。

以下の図は、複雑さをよく表しています。

複雑さとは、要素が編み込まれてしまいほどくのが難しいことであって、単一の要素から複雑さが生まれることはありません。 言い変えれば、順番に依存している状態のことを複雑であると言います。 順番にはたとえば以下のようなものがあります。 <ul><li>命令の実行順</li></ul> &nbsp;- コードの行数を入れ替えることによって全体の動作が変化する<ul><li>プロセスの実行管理による順番</li></ul> &nbsp;- OSによるコンテキストスイッチで、どのプロセスが先に実行されるかが変わる<ul><li>ファイルの記述順</li></ul>&nbsp; - あるファイルのコードを変更した場合、他の数々のファイルが変更を要求される<ul><li>引数の順番</li></ul> &nbsp;- 与える引数の順番によって関数の動作が変化する また、複雑さは「変更距離(edit distance)」を用いて定量化できます。 <ul><li>もし引数の順番を変更したら、その関数を使用しているすべての箇所を書き直す必要がある</li><li>ステートレスなコンポーネントに新たに状態を追加し、全ての呼び出し元を精査せねばならない</li><li>非同期的なデータの取得が追加された際、いくつものコンポーネントやredux定義をまたいで変更しなくてはならない</li></ul> 複雑さの式が存在するわけではないにしろ、開発者は感覚としてこれを知っていて、現にプロジェクトの進行に影響を与えています。 また、見えないコストとして、コードの変更自体が苦痛なのでイノベーションが生まれなくなるという点もあります。 端的には、変更しやすいコードとは、要素を「編み込む」ことができない設計のことを言います。

複雑さを可能な限り排除したとして、本質的な機能に関わる複雑さは当然残ります。&nbsp;&nbsp; こうした排除できない複雑さへの対処として、短いスパンでフィードバックを得ることが有効です。&nbsp;&nbsp;

このことは<a href="https://devops.com/shift-left-can-you-be-left-out/" target="_blank" rel="noopener noreferrer">Shift Left</a>という単語で表されており、 具体的には以下のような要素を指します。&nbsp;&nbsp; <ul><li>リファクタ時にエラー箇所を指摘できるユニットテスト</li><li>型情報によるチェック</li><li>15分以下で完了するデプロイ</li><li>本番環境を再現できるローカル環境</li><li> <a href="https://www.replay.io/" target="_blank" rel="noopener noreferrer">replay.io</a>などの、リアルタイムに値を再現できるデバッグツール</li></ul>

ビジネスが成長したり世の中のニーズが変更すれば、求められる要件も変わっていきます。 ただし、コードの変更のしすぎはそれ自体が良くない結果を招きます。&nbsp;&nbsp; 変更のしすぎとは安定性よりも速度を重視した状態のことで、あらゆるものがすぐに変わっていく様子はユーザーに動揺を与えます。

いかがでしたでしょうか？ 筆者が元の記事の意図を拾いきれず散らかった部分もあるので、気になる方はぜひ元記事も読んでみてください。 複雑さとは要素が絡み合った状態であり、順番に依存しないことが複雑さ回避への道、という考えは色んなところで使えそうですね。 最近では宣言的、状態の記述、といった概念も現れていますが、まさにこうした考えに基づいているのかもしれません。

現役フルスタックWebエンジニアが解説！変更に強い設計をしましょうというお話

oskn259と申します。 昨今ではテスト駆動開発という言葉も浸透して、全くテストの無いシステムというのは減ってきているように思います。 筆者は最近、テスト駆動開発の名著である<a href="https://www.amazon.co.jp/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA-Kent-Beck/dp/4274217884" target="_blank" rel="noopener noreferrer">こちら</a>を読み終わったのですが、世にあるイメージと本に書かれている内容に差があるように感じました。 テストが書かれているからTDDなのでしょうか？ テストを先に書くからTDDなのでしょうか？ 正確にはそのどちらでもないようです。 今回はそのさわりの部分を解説していきます。 今回の記事は、こちらで書いた内容の修正版でもあります。 <a href="https://blog.oskn259.com/article/review_tdd" target="_blank" rel="noopener noreferrer">https://blog.oskn259.com/article/review_tdd</a>

イメージとして僕も知ってはいましたが、その時の僕のTDDに対する認識としてはこうでした。 <ul><li>テストを始めに全て書く</li><li>それをパスするようなコードを以って完成とする</li><li>仕様をテストという形で記載するので、開発者感での認識の齟齬を防止できる</li></ul> 実はこの認識こそ、TDDのごく一側面だけを切り取った代物だったのです。&nbsp;

フィボナッチ数列を生成するメソッドを作ってみましょう。 まずは、これぐらいなら即作れるだろう、というレベルのテストを書きます。

0を入力したら、そのフィボナッチ数である0が返るというテストです。 これを満たす実装は以下の通りです。

はい、簡単ですね。 言いたいことは分かります。 でもTDDではこれで良いんです。 常にテスト結果をグリーンに保ち、その後、すぐにグリーンにできる一歩を踏み出すのです。 はじめの一歩として<code>fib(0) === 0</code>を完成させたわけです。 では次なる一歩として<code>fib(1) === 1</code>となるテストを追加しましょう。

追加した部分のテストが落ちてしまうようです。 これが通るように実装を修正してみましょう。

・・・ 言いたいことは分かります。 でもTDDではこれで良いんです。 常にテスト結果をグリーンに保ち、その後、すぐにグリーンにできる一歩を踏み出すのです。 同じように進めていきます。&nbsp;&nbsp;

次なる一歩として、<code>fib(2), fib(3)</code>を追加しました。 テストが揃ってきたので、ここでリファクタを行います。 TDDにおけるリファクタとは、重複を排除することです。 このケースにおける重複とはなんでしょうか？ 例えば、テスト上の2という数字と実装での2という数字が重複しています。 このように、実装とテスト両方にわたって観察し、重複を探し出します。 では、重複を解消するにはどうするのでしょうか？ まず、実装上の<code>return 2</code>の2とは何でしょうか？ これはフィボナッチ数を計算する機能ですから、この2はそれ以前のフィボナッチ数である<code>1</code>と<code>1</code>を加算したものとなります。

このとき<code>return 1 + 1</code>の前者の1は、<code>expect(fib(1)).toBe(1);</code>としてテスト上に記載されている<code>fib(1)</code>の結果をベタ書きしたものです。 後者の2については<code>fib(2)</code>の結果です。 つまり、これらの<code>1</code>は重複しているのです！ 重複しない形に書き直しましょう。

より小さなステップでTDDを進めたければ、<code>return fib(2) - fib(1);</code>を挟んでも良いですが、ここでは少し大股に歩を進めました。 このようにして、フィボナッチ数を計算する機能がテストと共に完成します。

先のフィボナッチ数のケースが示す通り、TDDにおいてテストと実装はどちらが先ということはなく、両輪で進めていくものです。 これは僕が知っている「テストファースト」の概念を大きく修正してくれました。 要件全てをテストとして表現してそれをパスするコードを模索するというのは、（やり方としてアリだとは思いますが）それはTDDではないようです。 最初の一歩を踏み出すために小さなテストを書くことこそがテストファーストなのです。 またこれまで、完成したコードをより良いものにしていくという意味でリファクタという言葉を使っていましたが、TDDの文脈においてリファクタとは、重複を排除する開発過程のことを指しています。 言うなれば、TDDは単なる制約や手続きではなく思考のプロセスと言った方が近そうです。 こうした思考プロセスがなぜ有効なのかは100%解明されていませんし、本書でも明確にはされていませんが、TDDのサイクルを回すことで優れた設計に辿り着いたという例は多いようです。

振る舞い駆動開発(BDD) と テスト駆動開発(TDD)

そもそもテストとは、エラーになるであろう操作を意図的に行ってそうしたケースの存在を示すことですが、TDDにおけるテストでは現状の立ち位置を確認する役割と言えそうです。 それは本当にテストか？ 間違った理解を世に広めていないか？ という議論があり用語が一新されました。 その結果生まれたのがBDDで、<code>assertion</code> -&gt; <code>expect</code> や<code>test class</code> -&gt; <code>spec</code>のように、振る舞いを定義するという前提の単語が使用されるようになっています。 機能として両者は等しく、用語のみが入れ替わっています。

カテゴリー:【エンジニア】の記事一覧