業務でコードを書く際、似たような処理を別の業務で実装した経験がある方も多いのではないでしょうか。中には、それを自作のライブラリとして作成して、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

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

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

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

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


ここ数年でノーコード・ローコード開発という言葉を耳にする機会が多くなりました。 &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月β版ローンチ。弱小ブログ運営中。暇だったので当メディアのライターにもチャレンジ。人間の思考に興味関心がありそういう系の本を読むのが好き。

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>のように、振る舞いを定義するという前提の単語が使用されるようになっています。 機能として両者は等しく、用語のみが入れ替わっています。

TDDなのでテストは完璧、ではない

リリースのために必要なテストは、 以下の軸に沿って4象限に分類できます。 <ul><li>技術面 &lt;-&gt; ビジネス面</li><li>チームの支援 &lt;-&gt; 製品の批評</li></ul> TDDで記述するテストは、技術面でチームを支援するものと言えそうです。 要するに、まだ3種類のテストが残っているのです。 具体的には、以下のようなテストが残されています。 <ul><li>セキュリティ検査</li><li>負荷検証</li><li>顧客による手動受け入れテスト</li><li>自動化されたストーリーテスト</li></ul>

フィボナッチ数の例で記述したようなユニットテストだけでなく、受け入れ条件のような大きい単位に対してもTDDは可能であるとされています。 アジャイルにおけるユーザーストーリーをテストとして記述するのです。 この場合、ユーザーストーリーを表す 「外側」のテストと、コーディング時に並行して記述する「内側」のテストの2つが存在することになります。 外側テストをパスするために、内側テストと実装の両輪でコードを書き進めるというイメージですね。 この「外側」テスト向けフレームワークとして、cucumberなどが挙げられます。 <a href="https://cucumber.io/" target="_blank" rel="noopener noreferrer">https://cucumber.io/</a>

今となっては随分浸透したTDDですが、今回本を読んでみて、簡単に習得できるものではないなという感想でした。 感覚や経験の占める割合が多いと思います。 フィボナッチ数の例にしても、以下のような事柄について決まった方法がなく、コーダーの経験に委ねられているのです。 <ul><li>一歩の大きさはどれぐらいが適切か？</li><li>そもそもその一歩として何を選ぶべきか？</li><li>どのタイミングでリファクタを始めるのか？</li></ul> この感覚を掴んでTDDの恩恵を真に受けるためには、いくらか経験が必要そうです。

本書にも記載がありましたが、重要なのは自分やPJにとっての最適解を見つけることです。 TDDでないからイケてない、ではありませんし、足し算のメソッドに100個のテストを書くのが適切とも思えません。 みんなが言ってるからではなく、自身の置かれた現状に最適な使い方を模索できると良いですね。 その結果、TDDは今回は不要ということもあり得るでしょう。 重要なのは、一つのスキルとして持っておくことです。

やはりお前らの言うテスト駆動開発は間違っている　

oskn259

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

フリーランスは毎年確定申告をすることで税金が確定します。 &nbsp; フリーランスと会社員の大きな違いは、事業にかかったお金を「経費」として売上から控除できる点です。 フリーランスはその年の経費を計上することで、税金を抑えることができます。 &nbsp; しかし確定申告をしたことがないと、「何が経費になるのか？」がわからない方も多いと思います。 当然ですが使ったお金がすべて経費になることはありません。線引きがあります。 &nbsp; 今回はフリーランスが経費として計上できるものについて解説します。

まずあらためて経費とは何かを確認しましょう。 &nbsp; 「経費」とは事業を行う上でかかった費用のことです。必要経費とも言います。 「経費で落とす」というのは「経費として計上する」という意味で捉えて問題ありません。 &nbsp; 経費を計上すると結果的に所得税や住民税が安くなります。 なぜなら、これらの税金は下記の計算式から算出される「課税所得金額」で決まるからです。 &nbsp; 売上 - 経費 - 控除 = 課税所得金額 &nbsp; つまり、経費が大きくなるほど課税所得金額は低くなるので、税金が安くなる。ということです。 &nbsp; 一般的に、会社員よりもフリーランスの方が税制面で有利とされている背景には「経費」があるからでしょう。 &nbsp; 会社員は一部例外はありますが、基本的に経費の計上は認められていません。 その代わりに「給与所得控除」というものが一定の計算式に基づき所得から控除されています。 &nbsp; しかし、所得に応じて控除額が決まる会社員よりも、 自分の意志で所得をある程度コントロールできるフリーランスの方が税制面では有利となるわけです。

続いて経費として認められている代表的な項目について解説します。

自宅で事業を行っている方が対象です。 &nbsp; 賃貸に住んでいる場合、「按分」といって家賃のいくらかの割合分を経費に出来ます。 按分をする理由は、自宅には事業用とプライベート用の両面があり、100%の経費の計上ができないからです。 &nbsp; 良く用いられる計算は「床面積」で仕事をしている空間の割合を出す方式です。 他にも仕事の実働時間分を経費にするという、時間の割合で計算するやり方もあります。 &nbsp; もし自宅が持ち家の場合は減価償却費、管理費、利息などが経費の対象になります。

自宅のインターネットの使用量などは通信費として計上できます。（在宅で仕事をしている場合） 他にはスマホで仕事関係の人とのやり取りによって発生した費用も計上が可能です。 &nbsp; しかし先ほど書いたようにこちらも按分が必要です。スマホを仕事だけに使用しているとは考えづらいからです。 使用している時間等で按分するのが良いでしょう。

水道、電気、ガス代については、事業に必要な費用なら経費に計上できます。 ITエンジニアの方であれば電気代が関わってくるかもしれません。 &nbsp; もし経費に計上する場合はここでも按分が必要なケースがほとんどです。 地代家賃で計算した割合で電気代も同様に考えると良いでしょう。

事業に関する交通費、宿泊費は経費として計上できます。 &nbsp; たとえば取引先との打ち合わせで出張したときのガソリン代・電車代・飛行機代や、ホテル代などです。 電車移動の場合は都度領収書を発行できないときもあるので、私は使用履歴を出力して領収書代わりにしています。

取引先等の接待や、飲み会などについては接待交際費として計上できます。 &nbsp; 時々迷われる方もいるのですが、「仕事のため」と明確な理由があれば、たとえキャバクラで支払ったお金でも経費にできます。 ですからこの場合は、自信を持って計上して問題ありません。 &nbsp; しかしこの接待交際費ですが、不正が多いとされる項目なので税務署側もしっかり見てくるでしょう。 もちろん接待交際費に限らずですが、くれぐれもプライベートな交際費の経費計上はやめましょう。

文房具や封筒などの消耗品は経費で計上ができます。 私は文房具は使いませんが、業務用PCを清掃する用のエアーダスター等はこちらの経費で計上しています。

減価償却という概念があります。長期にわたり使用するものは単年の経費で計上せず、耐用年数に応じて計上するという考え方です。 10万円を超えるものは減価償却となります。 &nbsp; たとえば業務用に20万円のPCを購入したとします。基本的にPCは長期にわたって使用するものですから、減価償却となります。 PCの耐用年数は4年です。購入金額を耐用年数で割った金額を経費として、4年間毎年申告していくことになります。 &nbsp; 例：20万円のPCの場合 20 ÷ 4 = 5万円　を4年間経費として計上する。 &nbsp; ちなみに「耐用年数」は品目により異なります。詳しくは<a style="color:#1155cc" href="https://www.keisan.nta.go.jp/h29yokuaru/aoiroshinkoku/hitsuyokeihi/genkashokyakuhi/taiyonensuhyo.html" target="_blank" rel="noopener noreferrer">こちら</a>を参考にしてください。 &nbsp; なお、青色申告の場合は30万円以下のものなら全額を経費に計上できます。

名称通り仕事を外注した場合は、外注工賃として経費に計上することができます。

こちらも名称通り、広告宣伝にかかった費用を計上することができます。 &nbsp; といってもITエンジニアの場合はあまり広告宣伝費は計上しないと思いますが、 今の時代でしたら事業用のSNSアカウントのアイコンイラストを描いてもらった場合は広告宣伝費となるでしょう。 &nbsp; 他にも一般的なところで言えば、名刺やポートフォリオ作成にかかったお金も経費になりますね。

既存の項目のいずれにも属さないけど、事業に必要な出費があった場合には雑費として計上できます。 &nbsp; あまり雑費を計上することはないかと思いますが、一応覚えておいて損はないです。

事業と関係ないプライベートな出費はもちろん経費としては認められていません。 &nbsp; 自分の食費や趣味、事業と関わりのない友人との飲み会などを経費として計上するのはNGです。

所得税や住民税は経費として認められていません。 これらは所得を計算した結果確定する税金だからです。 &nbsp; しかしすべての税金が経費計上できないということはありません。 &nbsp; 印紙税や、個人事業税などは経費として認められています。 事業を行うにあたって必要な税金だからですね。 &nbsp; 他にも税金の種目はたくさんあるので、どの税金が経費になるのか・ならないのかよく調べてみると良いでしょう。 自分が思わず払っていた税金が必要経費に含まれているかもしれません。

いかがでしたか？ 今回は経費についての基本を解説しました。 &nbsp; 初めて見ると項目が多すぎて大変に思えますが、1つ1つを分割して考えるとそこまで難しいことではありませんので安心してください。 &nbsp; フリーランスは会社員と比べて税制面でメリットが大きいということを実感いただけたかと思います。 賢く節税をして自分の資産を守っていきましょう。

これは経費になる？フリーランスになるなら知っておきたい経費のコト

IT業界は人手不足？4つの原因とエンジニアが今やるべきことを解説

こんにちは！タカトです。 &nbsp; 数年前からIT業界の人材不足が囁かれていますが、その理由や背景をご存じでしょうか？ 現場にいる人間からするとあまり実感がないかもしれませんが、この話は経済産業省が上げているほど、割と深刻な話だったります。今回はIT業界の人材不足の4つの原因とエンジニアがやっておくべきことについて解説します。 &nbsp; 当記事の信頼性として ・筆者がIT業界18年目 ・業種は様々で自動車関係、カード、保険、銀行、不動産など多数 ・酸いも甘いも色々な現場を見てきた &nbsp; では早速いきましょう！

【最大で79万人不足】人材不足と言われる理由

この資料は経済産業省が出している「IT人材白書」で、IT人材需要に関する調査報告になります。 2010年代の労働生産性（0.7％）とIT需要の伸びを高位・中位・低位のシナリオでそれぞれIT人材の需給ギャップを試算しています。 このIT人材の需給ギャップは、IT需要の伸び、IT人材の生産性の上昇率に依存しています。 &nbsp; 各シナリオは伸び率に応じて不足人数に影響があり、低位のシナリオでも16万人、中位で45万人、上位では79万人不足するとうたわれています。 &nbsp; 79万人というと山梨県の総人口が丸々不足するというイメージです。 &nbsp; 人材不足の大本になっているのが少子高齢化です。今や人口の30%以上が65歳以上に達しており、若い人材不足が顕著に表れています。 &nbsp; ただ、IT業界に限って何故こんなに不足しているのでしょうか？

ここ最近のIT業界の技術進化のスピードはとにかく早いです。 &nbsp; 仮想通貨、ブロックチェーン技術、NFT、メタバースなどたった一年で大きく変わっていきます。 &nbsp; こういった技術が進化していく中で会社での教育体制はすぐには整いません。 かといって個人で習得するとなると、好きな人は好んでやりますが、そうでない人は中々習得することはしないでしょう。 &nbsp; こうなると新しい技術の習得は遅れていくのは目に見えてます。技術は進化していくけど人がそれに追いついていない現状が一つの原因です。

あまり浮き彫りになっていませんが、日本の技術者は数多く海外への引き抜きをされています。数年前、シャープや東芝の社員が海外へ引き抜かれたり、サムスンへもかなり多くの日本技術者が転職したと言われています。 &nbsp; この原因は日本の技術者の低賃金です。 日本の場合、長く勤務すれば給料が上がる（年功序列）制度はありますが、新しい技術を習得しても給料はさほど上がりません。 &nbsp; ですが、そのスキルをもって海外へ行くと年収が3割ほど上がるぐらい重宝されます。 &nbsp; それぐらい日本のエンジニアのスキルは高いということなんです。 &nbsp; 会社はそれに見合った報酬を出していないため、スキルの高い技術者は海外に流れていっている現状があります。

3つ目の理由として、IT技術者の高齢化があげられます。 &nbsp; 団塊世代の定年退職により人が減り、逆に若い人たちが入らず不足する。 &nbsp; 減る一方で増えないとなると、人材不足になるのは当然です。 &nbsp; これは少子高齢化ともリンクしており、IT業界にでは顕著にその影響が出ます。

４．IT業界なネガティブなイメージ

IT業界は未だに3Kのイメージが残ったままです。 &nbsp; 3Kとは &nbsp; ①キツい &nbsp; ②汚い &nbsp; ③給料安い &nbsp; 「キツい」はとにかく残業が多いイメージから来てます。 &nbsp; 残業が多く終電帰りが続くと身体が持たず、キツいですよね。 &nbsp; IT業界は残業が多いイメージが未だに残ってます。私が始めてIT業界に入った18年前からこれは変わっておらず、残業自慢や残業している人ほど評価されるといったのが残っているところもあります。 &nbsp; こういった文化が残っているとプライベートの時間がなくなり、仕事がキツくてイヤになります。 &nbsp; 「汚い」は仕事が忙しく身だしなみに気を使わない人が多いからです。 &nbsp; デスクワークでパソコンとしか向き合わないと、自分の身だしなみは二の次になります。 &nbsp; 忙しいとそれどころではないので、髪もぼさぼさ、髭も伸ばしっぱなし、シャツはよれよれ、これだと汚いイメージがつきますよね。 &nbsp; 「給料安い」は海外の人材流出でも述べましたが、とにかく給料が安いんです。 &nbsp; 人によっては生活費を稼ぐため残業してる人も数多くいます。 &nbsp; 技術に見合った給料だったら良いんですが、資格や技術習得しても上がる給料は微増。 &nbsp; 結果的に税金を引かれると貰える額は変わってない・・・なんてこともザラです。 &nbsp; この3つのイメージが根強く残っているため、IT業界へ人が入ってこなくなり人材不足となるワケです。

エンジニアでない人は人材不足を逆手に取る

人材不足ということは、需要があっても供給が追いついていないということなのでそれを逆手に取って、IT業界に入れば仕事に困らなくなります。 &nbsp; 現にITの求人は常に溢れているので、条件さえ満たせれば仕事は見つかります。 &nbsp; 条件のほとんどがスキルがあるかどうかです。 &nbsp; ご自身で勉強しスキルを習得して業界に入れば、引く手あまたなんてこともあるので、勉強する価値はアリです。 &nbsp; ただ、自分で勉強するにも難しいことが多いので、プログラミングスクールなどお金を出して勉強すると、より効率的に勉強ができます。プロから教えて貰うとすんなり理解できるので一つの選択肢として考えておきましょう。

エンジニアは自分の市場価値を確認しよう

ここが最も重要です。 &nbsp; 既にエンジニアの人で様々なスキルを習得している人や、それなりの現場経験がある人は世の中的に見た自分の市場価値を確認してみましょう。 &nbsp; 今いる会社で貰っているお給料は会社の中でのあなたのスキルに見合う報酬です。 &nbsp; 会社を出て、世の中からみたあなたのスキル・経験はどれぐらいの報酬が貰えるのか把握してますか？ &nbsp; 実際、会社で30万ぐらいのお給料だった人が他の会社やフリーランスで査定して貰ったら100万の見積もりが出たなんてことはザラにあります。 &nbsp; これは全然おかしなことではなくて、IT技術者が不足しているということは稀少価値が高いという意味になりますよね。であれば、支払われるべき報酬が高くなるのは当然ということです。 &nbsp; なので、是非ご自身の市場価値を把握しておくことをオススメします。 &nbsp; グランドホープでは簡単に査定して貰えるので興味のある方は査定して見てください。 ◆関連記事 <a href="https://engineer-first.net/uyy3fyt_vv" target="_blank" rel="noopener noreferrer">忖度なし！グラントホープをオススメする6つの理由！｜エンジニアファースト (engineer-first.net)</a>

まとめ：人材不足は深刻な問題だが自身でやれることは決まっている

結論です。 &nbsp; 人材不足問題は解決することは難しいです。全員が「エンジニアになるぞー！」とはなりませんし、合う合わないもあります。 &nbsp; なので、これはこれとして自分自身で何ができるかを考えるのが最も最良の選択です。 &nbsp; 私自身は、今の自分の市場価値が知りたいと思い査定をして貰いました。 &nbsp; 正直、ビックリしました。こんなに自分自身に価値があったんだと分かり、自信もつきましたし、よりスキルを高めていこうと思いました。 &nbsp; スキルを上げるも良し、価値を知るもよし、自身のキャリアと相談しながら最善の選択をしてこの人材不足の荒波を乗り越えていきましょう！

タカト

フリーランス歴8年目、主にPMO・サポート業務をメインに案件をこなしています。
Webライターとして案件受注できるようブログも執筆中。


エンジニアはクライアントからの要望を汲み取り、さまざまな開発手法でシステム開発を行っています。従来の代表的な開発手法としては、ウォーターフォール開発が挙げられます。 &nbsp; その一方で、近年主流な開発手法としてなりつつあるのが、『アジャイル開発』です。 &nbsp; この記事では、アジャイル開発の開発手法、ウォーターフォール開発との違い、アジャイル開発を導入する上でのメリットとデメリットについて紹介していきます。

アジャイル開発とは、「要件定義→設計→実装→テスト→リリース」を小単位で繰り返し行い、システム開発を進めていく手法です。小単位でシステム開発を進めていくことで、開発期間を短縮させることができ、突発的な仕様変更にも柔軟に対応することができます。 &nbsp; アジャイル開発は、従来のソフトウェア開発とは異なる手法を実践していた17名のソフトウェア開発者が、それぞれの手法や考えを議論し「マニュフェスト」として2001年に公開しました（アジャイルソフトウェア開発宣言）。

この公開された「マニュフェスト」が、世界中のソフトウェア開発者たちに支持され、“アジャイルソフトウェア開発（アジャイル開発）”という名で世に広まりました。

アジャイル開発とウォーターフォール開発の違い

ウォーターフォール開発は、決められた開発期間内で各工程を一つずつ確認しながら進めていく手法です。「要件定義」「設計」「実装」「テスト」を各工程に分割して開発を進めていきます。

ウォーターフォール開発は要件定義の段階で、システム開発の要件や必要な開発要員や開発期間などを検討し、開発計画を立てます。計画を立てたら各工程を進めていき、全ての工程が完了すると、ようやくリリースできる仕組みです。 &nbsp; &nbsp; アジャイル開発は、機能単位で小さくすばやく開発を繰り返していく手法です。ウォーターフォール開発と違い、開発計画を立てる段階では細かい仕様は決めずに、大まかな仕様のみを決めます。 次のステップとして、「イテレーション」と呼ばれるサイクルを用いて開発を進めていきます。開発は小さな機能単位に分け、「計画」「設計」「実装」「テスト」「リリース」という流れを何度も繰り返します。

ウォーターフォール開発とは違い、全体の計画を大まかに決めているため、開発途中での仕様変更にも柔軟に対応することができます。開発途中に仕様や設計に変更があることを前提とした開発プロセスとなっている点は、ウォーターフォール開発と大きく違う点だと言えます。

ウォーターフォール開発は、要件定義や全体の機能設計を計画してから開発に着手するため、開発が長期化する傾向にあります。また、開発途中での仕様変更や追加対応が困難であるため、開発途中で要件に変更があった場合は、１つ前の工程から見直すことになり、開発期間が延びてしまう懸念があります。 &nbsp; &nbsp; アジャイル開発は、計画段階で詳細な仕様は決めずに開発に着手するため、ウォーターフォール開発に比べると早く開発に着手することができます。また、小さな機能単位に分けて開発を行うため、開発途中での仕様変更にも柔軟に対応することができ、開発期間が延びてしまうリスクを軽減することができます。

ウォーターフォール開発は、業務システムや大規模なシステム開発で使われることが多い開発手法とされています。 &nbsp; アジャイル開発は、チーム人数が10人以下の小規模な開発向けの手法とされています。ただし、アジャイル開発でも大規模なシステム開発に適用できない訳ではなく、小規模なチームに分割していくことで、大規模なシステム開発にも対応していくことが可能です。

アジャイル開発のメリットとデメリット

仕様変更などに柔軟に対応できる

小さな機能単位で開発を行っているため、突発的な仕様変更や機能追加が発生しても、柔軟に対応することができます。また、手戻りの工数を減らすことができるため、プロジェクトへのリスクを軽減させることができます。

前述で述べているように、仕様変更に強い開発手法であるため、顧客が求める要望を実現することが可能です。その結果、顧客の満足感を得ることができ、システムもより良いものにしていくことができます。

1〜4週間程度の短い期間を設けてイテレーション開発を行うため、素早くリリースを行うことができます。１〜4週間程度の短い期間で開発を行ない、その期間で実現できる機能を開発していくため、早期リリースを行うことができます。

ウォーターフォール開発のような綿密な計画をせずに開発を行うため、機能リリースまでの全体スケジュールを把握しづらいです。 &nbsp; また、チーム全体の進捗状況や個々の作業進捗も把握しづらいため、想定しているリリース期間に間に合わない可能性が懸念されます。そのため、チームメンバーとのコミュニケーションを密にとり、日々の進捗を把握してスケジュールを調整する必要があります。

メリットに挙げた「顧客要望に応じやすい」が逆にデメリットに変わってしまうことがあります。 あれもこれもと詰め込みすぎて、本来何をリリースしなければならないのか見失ってしまう可能性が懸念されます。そのため、リリースすべきものは何なのかを再度把握した上で、開発期間の中で要望のどの範囲までを対応するかを調整します。範囲から外れてしまう要望は、次の開発期間で対応していくなどの工夫が必要となります。

アジャイル開発の手法の中で代表的な開発手法です。 少人数のチームを作り、チーム内でそれぞれ役割を決めて、チーム一丸となってプロジェクトの計画・進捗管理・システム開発を行なっていきます。 &nbsp; また、スクラムでは「スプリント」という固定された期間で開発期間を区切って、繰り返し開発を行います。スプリントの中で、決められたリリース日へ向けて、プロダクトの計画・設計・実装・テストを行なっていきます。

エクストリーム・プログラミング（XP）

アジャイル開発の根幹とも言える、柔軟性・スピード・変化への対応を重要とした開発手法。 &nbsp; 開発を行うにあたり、「コミュニケーション」「シンプル」「フィードバック」「勇気」「尊重」という５つの価値を定義し、重視すべき点としています。 また、開発していく際のリスク軽減の活動（プラクティス）も多く、より品質の良いプロダクトを提供できるだけでなく、チームメンバーの能力向上も狙うことができる手法と言えます。

ユーザー目線での機能価値に焦点を当てた開発手法。 機能開発の前提として、ユーザーのビジネスモデルを正確に理解し、各機能単位で設計・開発・テストを行なっていきます。そのため、上記二つの開発手法の中でも、最もコミュニケーション力が重要となってくる手法と言えます。

少人数のプロジェクトで円滑にプロダクトを作っていきたい、チームで一致団結して開発できる環境を作っていきたいと思った方は、一度アジャイル開発を検討してみても良いのではないでしょうか。

アジャイル開発とは？開発プロセスの基本やメリットを現役アジャイル開発者が解説！

タカナシ ジュン

Web系フリーランスエンジニア。アジャイル開発案件3年目（現在も稼働中）。エンジニアの枠を超えて、Webライター・動画制作などマルチに活動。趣味はキャンプとボディメイク。

こんにちは！&nbsp;&nbsp;&nbsp;&nbsp;タカトです。 &nbsp; 今回はフリーランスとして現場で働く上で大事な5つのポイントについて解説していきます。フリーランスになった後、面談をして現場に入ることは決まっても、イマイチ入ってからの立ち回りについては分からないのが正直なところです。今回はそこに焦点をあてて解説していきます！ &nbsp; 本記事はこんな方にオススメです。 &nbsp; ・フリーランスになって現場が決まったけど、どう立ち回ってよいか分からない人 ・フリーランスではないけど、興味はあるので知りたい人 &nbsp; では早速いきましょう！

会社員とフリーランスの大きな違い

会社員とフリーランスには大きな違いがあります。 それは雇用されているか、されていないかです。 雇用されている場合、現場でのサポートや教育をして貰うのは当たり前ですが、フリーランスはそうも行きません。酷な言い方ですが、雇用されていない分、何かをして貰うのは当たり前ではないんです。その為、自分から掴みに行く必要があります。 &nbsp; また、現場には同じ会社の人・先輩はいないので割と孤独を感じやすいです。 日常的な相談や愚痴もはける場がないので、自分で処理ができないとちょっと大変なのが事実としてあります。

現場で働く上で大事な【5つ】のポイント

今回は8年間現場に出て、私自身が感じたポイントを5つに分けて解説します。 &nbsp; これができると、どの現場も仕事がしやすくなり、現場からの評価も良くなると自負しています。

大事なポイント①正直、愛想は良い方が得

愛想とは「にこやかで人付き合いの良いこと」をさします。 &nbsp; あなた自身が現場で一緒に仕事をする人が来たとして、こんな人が来たらどうでしょうか？ ・いつも眉間にしわが寄ってて怖い ・声が小さく何を言ってるか分からない ・挨拶も全然してくれない &nbsp; 一緒に仕事をしたいと思えますか？答えは「No」ですよね。では、その逆はどうでしょうか？ ・話す時は表情もにこやかで、話しかけやすい ・声もハキハキして聞き取りやすい ・挨拶も元気にしっかりしてくれる &nbsp; 「こういう人と一緒に働きたい！」と感じるはずです。それぐらい愛想というのは大事になります。なので、愛想は悪いよりか良い方が、客先に与える印象も良く、働きやすいです。

大事なポイント②ほう・れん・そう（報連相）

報連相とは「報告・連絡・相談」の略です。 正直、会社員・フリーランス関係なく大事です。 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; まずは「報告」。意外と出来てない人が多かったりします。 報告はマメなほど良いです。事後報告や何も報告がない時に、何かトラブルが起きると対処のしようがないため、こまめにやっていきましょう。 相手から「ちょっと抑えて貰っていいかな？」と言われたらセーブするぐらいで丁度よいです。 「連絡」も同様です。事後にならず「これ連絡した方が良いかな？」と思うぐらいなら連絡しておきましょう。 「相談」は成果物を仕上げる際、やるだけやって見せた時に相手との認識齟齬があると掛けた労力が無駄になります。なので、少し作ったら頭出しとして相談ベースで確認すると無駄なく成果物が仕上げられます。もちろん、成果物以外でも「相談」は大事です。相談を受ける側も、ちゃんと理解に努めながら進めていると受け取るからです。

大事なポイント③受身は危険！自発的に動くこと

フリーランスの場合、現場に入った後のフォローは正直ないところが多いです。 引継ぎや現場での基本的な所作は教えて貰えますが、それ以外は自分でキャッチアップしていくイメージです。なので座って待ってると「何故動かないの？」となってしまうので、前のめりで業務のキャッチアップや作業の確認をしていくことをオススメします。 &nbsp; また、言われてないことをやるのも非常に良いポイントです。 例えば最初に参加した会議の議事録を言われてないけど、取るだけで印象は全然変わります。資料作成をしている中でも「こういった資料があると便利かなと思い作りました」など、＋αの行動は非常に喜ばれます。

大事なポイント④体調、メンタル管理は自分でやる

会社員の場合、月一の面談やメンタルチェックなど昨今は色々な手法で管理・チェックをするところが増えています。それだけ現場に出ると色々あるという意味にもなるんですが、フリーランスはそういったケアは正直ありません。 あるとしたら現場に入って一週間ぐらいして営業さんから「参入してから問題等ありますでしょうか？」といった確認が来るぐらいです。それ以降は自分から声を上げないと、誰もあなたの状態を汲み取れないのが正直なところ。 &nbsp; なので、そのあたりの管理を自分でしっかりしていき、何か問題がありそうであれば営業さんに相談するなど自分でやっていきましょう。特にメンタルに関しては非常に難しいので、「何かおかしい・・・」と思ったら早めに相談することをオススメします。

大事なポイント⑤遅刻、当日・無断欠勤は超危険

これは超大事です。希望条件にも「勤怠がしっかりしている人」と書かれるぐらい大事なポイントです。裏を返せばそれだけちゃんとしてない人がいるということです・・・ &nbsp; 遅刻は時間や納期を守れるかどうかに直結します。 また、自身の管理能力まで繋がってくるので遅刻は極力しないよう意識しましょう。 &nbsp; 無断欠勤や当日の欠勤は相手の信頼性を損ないます。 本当に体調不良で休むのは仕方ないですが、それがやたらと多かったりすると「ただサボりたいだけでは？」と相手も感じざるを得ません。 急に休むことで任せたい仕事を任せられなくなったりもするので、そうならないよう体調管理をしっかりしていきましょう。 また、こういったのが増えると間に入っている会社さんにも「こういう人を入れる会社なら次からの取引を考えようかな」となり、会社に迷惑を掛けてしまうので要注意です。

危険！逆にやってはいけないこと

大事なポイントについては解説しましたが、逆にやってはいけないこととは？ &nbsp; それは5つのポイントの逆のことです。 ①愛想が悪い ②報・連・相を全然しない ③基本、受身で言われたことしかやらない ④いつも体調不良 ⑤遅刻はしょっちゅう、当日・無断欠勤も多い &nbsp; あなた自身と一緒に仕事をする人がこういった人だったらどうでしょうか？ &nbsp; 仕事をしたいとはならないですよね。 &nbsp; 結局、仕事をする上で相手は絶対いるので「人としてこれはどうなのだろうか」といった行動が印象を下げることに直結するので要注意です。

まとめ：この5つができるとフリーランスとして「武器」になる

まとめです。 &nbsp; この5つのポイントはフリーランスとしても「武器」になります。 それだけ出来てない人が多いという証拠なんです。 また、フリーランスに限らず最終的にはあなたという人間の価値にも繋がるので是非フリーランスで現場が決まった際は、5つのことを念頭に入れて現場で暴れまわって貰えればと思います。 &nbsp; 興味本位で見た方も、仕事をする上で出来て損はないので実践して頂けると幸いです。

フリーランスとして現場で働く上で大事な５つのポイント

こんにちは！&nbsp;&nbsp;&nbsp;&nbsp;タカトです。 &nbsp; 最近では当たり前のように聞く「フリーランス」という働き方。 つい数年前までは聞くこともなかったですし、働き方として「不安定じゃない？大丈夫？」と言われました。ですが、現状フリーランス人口は増え続ける一方で、2020年5月の段階で462万人と言われています。(2021年フリーランス白書より) 芸能人や芸人、テレビのプロデューサーまでもが会社を離れてフリーランスになることが増えており、フリーラス白書曰く「誰でもフリーランスになり得る時代」とまで言われています。 参考：<a style="color:#1155cc" href="https://blog.freelance-jp.org/wp-content/uploads/2021/03/%E3%80%90%E3%83%95%E3%83%AA%E3%83%BC%E3%83%A9%E3%83%B3%E3%82%B9%E7%99%BD%E6%9B%B82021%E3%80%91%E3%83%97%E3%83%AD%E3%83%95%E3%82%A7%E3%83%83%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%AB%EF%BC%86%E3%83%91%E3%83%A9%E3%83%AC%E3%83%AB%E3%82%AD%E3%83%A3%E3%83%AA%E3%82%A2%E3%83%BB%E3%83%95%E3%83%AA%E3%83%BC%E3%83%A9%E3%83%B3%E3%82%B9%E5%8D%94%E4%BC%9A.pdf" target="_blank" rel="noopener noreferrer">フリーランス白書2021</a>

今回はそんなフリーランスの中でも「フリーランスエンジニアに20代前半でもなれるのか？」をテーマにお話ししていきます。 &nbsp; この記事は以下の人にお勧めです。 &nbsp; ・20代前半でもフリーランスエンジニアを目指したい人 ・フリーランスエンジニアになりたけど不安がある人、その不安を払拭したい人 ・興味本位で知りたい &nbsp; では早速行きましょう！

20代前半でフリーランスになれるの？

結論です。 20代前半でも全然なれます。 現に私の友人で1年目は正社員、2年目からフリーランスエンジニアとしてバリバリ活躍しています。正直驚きましたが、今の時代的には全然普通なのかもしれません。 私自身は29歳（実際は30歳になる年）にフリーランスになりました。 それまでは会社員として10年働いており、転職自体は3回ほどしています。 フリーランスになるつもりは正直なかったのですが、会社員としての働き方に疑問を持ち始め、フリーランスの道を選びました。 &nbsp; 私の友人も疑問を持ち始めたことと、自分の力を試してみたいという気持ちでフリーランスになることを選んだと言っていました。

フリーランスになることに不安しかなかった

フリーランスになる前は、とにかく不安がありました。 ・自分に仕事があるのか ・年収は本当に上がるのか ・自分で探すとしたら大変なのでは &nbsp; こんな不安があり、私は先輩に勧められましたが1年は動かずにいたタイプです。 &nbsp; とはいえ29歳でいざフリーランスになってみたら、意外と不安に思ってたことは気にならず今で8年目になります。 正直、不安は動いてくことで払拭していけるのかなと思います。 &nbsp;

人出が足りない？現在のIT業界の状況

現在のIT業界は「IT技術者の不足」という大きな課題を抱えています。 &nbsp; 「2020年問題」という名前で大々的に問題になっているぐらいで、技術者不足の大きな理由は以下が挙げられます。 &nbsp; ・既存技術者の定年 ・IT業界のネガティブなイメージ ・IT技術の進歩の速さ &nbsp; これらのことから、フリーランスになっても需要があるのが現状です。

20代は圧倒的に需要がある理由

人材不足もさることながら、20代は伸びしろがあります。 &nbsp; 飲み込みも早いですし、体力もあります。 &nbsp; 学ぶ意欲もあるはずなので、企業はここぞとばかりに喜んで採用します。 &nbsp; 20代はスキルもそうですが、その先の可能性を見てくれる所が多いのです。 &nbsp; 逆に成長意欲がない人は、需要が下がってしまうので要注意です。

仕事はエージェントを使って紹介して貰うのも手

仕事を探す方法は２つあります。 ・完全個人としてやるなら自分で受託案件を探す（クラウドソーシングなど） ・エージェント会社に登録して仕事を紹介して貰う &nbsp; 自分で探すのは手間ですが、エージェント会社に登録すれば自分のスキルに見合った案件を紹介して貰えます。

実際どれくらい年収があがるのか

社会人1年目の20代だと給料は20万〜25万ぐらいが相場かと思います。 フリーランスエンジニアになると大体40万、上手くいけば50〜60万になります。年収でいうと600万〜700万ですね。 金額はエージェント会社によりけりなので、この金額と断言はできませんが相場はそれぐらいです。 ちなみに先ほど話した私の知り合いは社会人2年目で手取り50万以上と言っていました。 正社員で働いてた時と約2倍違うので、年収も実質2倍。そう考えると凄いですよね。

理由は簡単で中間マージンが大きく引かれてないからです。 IT業界はSIer（ITシステムの受託開発会社）といった業態が中心で、上流から下流に向けて仕事を発注する構造になってます。 下流になればなるほど、間に会社が入って中間マージンを抜いていくので最下流になると利益はかなり薄くなります。 業界自体はそういった傾向が薄くなりつつありますが、フリーランスエンジニアの場合は間にそこまで会社も入らないのと、正社員と比べて会社の取り分も圧倒的に少ないので、その分エンジニアの手取りは増えて行きます。

20代前半でフリーランスエンジニアになるためには

スキルも大事だけどコミュニケーション能力も磨く

スキルも大事ですがそれと同じぐらいコミュニケーション能力も大事です。 IT業界はコミュニケーションが苦手な人が多い傾向にあります。 技術力は確かに大事なのですが、結局コミュニケーションはどこに行っても必要になるので技術という武器とコミュニケーションという武器を持っておく感じです。 チームで仕事をするなら、ある程度コミュニケーションが取れる人の方が現場の人もやりやすいので磨いておくことをオススメします。

必要な情報は自分で取りにいく

20代前半だと、もしかしたら受け身になってしまうことが多いかもしれません。 フリーランスエンジニアになった場合は、それは非常にリスクです。 困った時に誰かが教えてくれるワケではないので、しっかり自分から動く癖をつけましょう。 最初は質問するのも億劫ですが、それも経験すればすぐに慣れます。 正直、いっぱい経験して慣れた方が後々メンタルも強くなるので経験値をいっぱい積みましょう。

20代前半のフリーランスエンジニアとして大事なこと

多少のことではブレないメンタル

20代前半は社会人の経験も少ないので、色々と驚くことが多いです。 そのたびに感情やメンタルが揺れてると大変なので「こんなこともあるのね」ぐらいの感覚の方が楽です。 正直、十年以上やってる私でも「マジかよ」ってことが多々あります。その度に気持ちが揺れるとキリがないのでメンタルは強くしておきましょう。

新しい環境にいち早く適用できること

フリーランスエンジニアになると現場の移動が多くなります。 最短で3か月、長いと3年ぐらいですが思ってるより環境はコロコロ変わります。 慣れるのは大変かもしれませんが、すぐ慣れると圧倒的に楽になるのでやりながら慣れるクセもつけておきましょう。

人間関係は無理に構築することはありません。 「この人と繋がりたいな」と思った人が現場にいたら、積極的にコミュニケーションを取ったり離れた後でも連絡を取り合うと非常に良いです。 離れた後、前の現場から「また仕事がしたいな」となれば再度声がかかり、長く居れる可能性が高いからです。 前にいた現場だったら、慣れてるのもあって自分にとってもメリットがあるのでしっかり繋がりたい人とは繋がっておきましょう。

まとめ：20代はチャレンジし放題。まずやってみよう！

フリーランスエンジニアになって「向いてない」「やっぱ大変だな」と思ったら正社員に戻れます。 正直、悩むぐらいだったらチャレンジして合わなかったら戻るぐらいの感覚で良いと思います。 一度きりの人生、経験できるものは沢山経験して何が自分に合ってるか模索し、より良い環境で仕事ができるようにしていきましょう！

新着の記事一覧

IT業界は人手不足？4つの原因とエンジニアが今やるべきことを解説

アジャイル開発とは？開発プロセスの基本やメリットを現役アジャイル開発者が解説！

フリーランスとして現場で働く上で大事な５つのポイント

20代前半でもフリーランスエンジニアになれるのか？

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

Datadogトレーサを追加したら永遠にLiveness Probeが成功しなくなった話。

おすすめ記事

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

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

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

やはりお前らの言うテスト駆動開発は間違っている

これは経費になる？フリーランスになるなら知っておきたい経費のコト