業務でコードを書く際、似たような処理を別の業務で実装した経験がある方も多いのではないでしょうか。中には、それを自作のライブラリとして作成して、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; フリーランスは会社員と比べて税制面でメリットが大きいということを実感いただけたかと思います。 賢く節税をして自分の資産を守っていきましょう。

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

第1章では、『リサーチ・分析編』として解説させていただきました。 記事は<a href="https://engineer-first.net/a5mwnclegd" target="_blank" rel="noopener noreferrer">こちら</a>。 。 第2章の今回は、問題発掘とテーマ化を題材にした内容です！ &nbsp; ビジネスにおける問題の原因は1つとは限りません。 複数の原因が複雑に絡まり合っている場合もあります。問題解決を効率的に行うためには、真の原因を追究し、適切な解決策を導き出すためにテンプレを利用しましょう。

★例：ビジネスで起こりえる問題 &nbsp;社内ミーティングで「業務の改善につなげるために、現状の問題点を洗い出せ」と指示を出すが、社員が出す問題点はどれも同一性が無く、業務改善につながらない・・ &nbsp; ★使い方 「ムダ・ムラ・ムリ」の3つの視点で問題点を洗い出す法則」 &nbsp; 「ダラリの法則」とは「ムダ・ムラ・ムリ」の3つの視点から、日常の業務や身の周りで起きている問題点を探し出す法則です。 &nbsp; 「ムダ」とは ・チェック表の作成の無駄 ・チェックの手間のムダ　 等 &nbsp; 「ムラ」とは ・気分のムラ ・成果のムラ 等 &nbsp; 「ムリ」とは ・スケジュールのムリ ・ムリなお願い 等 &nbsp; その他にも、肉体的に負担のかかる業務や行為、姿勢なども含まれます。 &nbsp; 社員のそれぞれが同じ3つの視点で問題点を洗い出すことができれば、問題意識の共有にもつながり、結果として会社全体の業務改善ができます。

効率的な業務改善を立てるためには、会社や社員が抱えるもんだ点を同じ視点で集めると効果的です。 同じ視点とは「ムダ・ムラ・ムリ」の3つ。 この3視点で問題点を整理するために便利なのが、付箋を使った方法です。 まず、社員全員が匿名で「ムダ・ムラ・ムリ」の視点から、問題点をどんどん付箋に書き出します。 次に書いたものを集めて、3つの視点に分類します。 &nbsp; 分類された問題点には、重要度の高い順に5段階で点数をつけて評価します。 評価の高い、もしくは重複した中でも特に重要な問題点を中心に絞りこんで議論を行えば効率的な業務改善策を立てられるようになります。 &nbsp;

★例：ビジネスで起こりえる問題 来月開催される音楽祭の会場を訪れたが、その規模を見て愕然とした。 「この広さでは、すべての来場者を収容できない！」と激怒している。 企画チームは、どうやらインターネットの情報のみで会場を決定した様子だ。 &nbsp; &nbsp; ★使い方 「仕事や問題解決には「現地・現物・現実」を基に進める」 &nbsp; 「三現主義」とは、「現地・現物・現実」のことで、仕事や問題解決に取り組む際に思い込みにとらわれずに、正しい意思決定をするために欠かせないセオリーです。 &nbsp; 「現地」とは 実際にその場に足を運ぶこと。 五感と直感をフル活用し現場を確かめます。 &nbsp; 「現物」とは 実際の物を観察すること。 実際に見て触れたうえで正当な評価をくださいます。 &nbsp; 「現実」とは 机上の空論で終わらせず、現実的な判断を下すこと。 &nbsp; これらの情報を得るにはフットワークの軽さが大事になります。

三現主義は「現地」「現物」「現実」のこと。 インターネットは手軽に情報が入手できる便利なツールですが、最終的な意思決定を下す際には、実際に現地に赴いて現物を確認し、物事を現実的に考える三現主義を実行しなければなりません。 イベント会場の選定を例に挙げるなら、まずは会場へ足を運び、インターネットで得られた情報と照らし合わせる必要があるでしょう。 たとえインターネット上の情報に記載されていた収容人数と予定来場者数が合致していたとしても、自身の目で実際に会場の規模を観察し、予測や机上の空論だけで済ませることなく、 企画チームでは三現主義の現地・現物・現実に基づいた事実を踏まえて正しく判断するとよかったでしょう。

2－1．ドメイン（自分の領域）

★例：ビジネスで起こりえる問題 会社が大規模な先行投資を行った。 巷で人気のドリンクの製造販売事業を開始したが、売り上げが一向に伸びない。 「売れない理由はないはずだ！」と激を飛ばすが、具体的な解決法は考えられていない・・ &nbsp; ★使い方 「得意分野で優位に立つためにドメインを重視する。」 &nbsp; 企業が経済活動を行う領域のことを「ドメイン」と呼びます。 &nbsp; ドメインには。 顧客層・ニーズ・コアコンピタンス（強みとなる商品やサービスのこと）の3つの定義があり、本業を強化したり新規事業を考えたりするときには、これらの定義を明確にして事業を進めることが重要です。 どのような顧客層のどのようなニーズに向けて、どのような商品やサービスの開発が必要かを見極めることが大切です。

得意分野から遠くかけ離れた事業の推進は、勝算の見えない競争によって限りある経営資源が確実に浪費されていくだけです。 自社のドメインが「顧客層」「ニーズ」「コアコンピタンス」の3つの定義を満たしていたければすでに業をリードする競合他社には太刀打ちできません。 &nbsp; 市場での競争優位性を獲得するには、自社の得意分野であるドメインを基盤にした本業重視の戦略を立てるのがセオリーです。 したがって、事業の拡大を目指して新規事業を展開するのであれば、本業や本業の強化につながる周辺事業など、自社のドメインに適した分野から選択するのがよいでしょう。 不慣れな分野へ安易に新規参入するのは得策ではないといえます。

★例：ビジネスで起こりえる問題 ゲームやアニメの人気に伴い、メディア事業部を立ち上げたおもちゃメーカー。 一次は業績も好調であったが、この数年は赤字続きで、社員の多くは「特化型の他社にかなうはずがない」とあきらめムード。 &nbsp; &nbsp; ★使い方 「市場に合わせて「撤退」か「新規」かを選択する。」 &nbsp; &nbsp; 企業の成長には、成長戦略が必須。 成長戦略とは「撤退」と「新規（拡大）」を繰り返し、事業の新陳代謝を図ること。 外部環境の変化にも適応するとともに、経営資源の有効活用にもつながります。 &nbsp; 撤退と新規の判断基準は2つあります。 &nbsp; 「外部要因」 市場規模に縮小があれば撤退、始業の創造や既存市場の拡大があれば新規を選択します。 &nbsp; 「内部要因」 不採算部門や衰退部門があれば撤退、経営資源のシナジー（相乗効果）を期待できれば新規が有効です。 &nbsp;

企業を取り巻く環境は、2～3年で変化します。 そのような状況下で業績を伸ばすには「撤退」と「新規」のサイクルを回すことで、事業を新陳代謝させなければなりません。 撤退と新規の判断基準は、外部要因と内部要因の2つに分けられます。 &nbsp; たとば、おもちゃメーカーであれば、内部要因である事業部門の不採算とシェアの縮小が問題です。 今後3年以内の黒字化が見込めないのであれば、早期に縮小か撤退の意思決定をすべきでしょう。 不採算事業からの撤退により回収した経営資源は、例えば、近年ニーズが高まっている赤ちゃん向けのおもちゃ事業を立ち上げるなど、成長分野に投入することができます。

★例：ビジネスで起こりえる問題 電化製品に定評がある会社だが、最近はマイナーチェンジを繰り返すだけで、売り上げも下降気味。 開発部はこの状況から抜け出す方法を模索するが、よい策が見つからない。 &nbsp; &nbsp; ★使い方 「製品がたどるプロセスの段階を知り、新商品投入の機会を見出す。」 &nbsp; 「製品ライフサイクル」とは、製品が誕生してから消えるまでのプロセス。 &nbsp; 「導入期⇒成長期⇒成熟期⇒衰退期」の4段階があり、最も利益が上がるのは成長期。導入期は、新しい物好きのイノベーター（すぐに興味を示す顧客層）が飛びつき、 次にアーリーアダプター（前者の反応を見る顧客層）が追随。 成長期でフォロワー（他社の意見を気にする顧客層）が広がり一気に売り上げが拡大します。 &nbsp; 「導入期⇒成長期」の製品をふやすには、新製品の投入が不可欠です。 &nbsp;

製品ライフサイクルには、「導入期」「成長期」「成熟期」「衰退期」の4段階があります。 売り上げや利益を向上させるには、製品ライフサイクルの若返りが欠かせません。 &nbsp; 製品の若返り策は「新しい技術の導入」「新しい用途の開発」「イメージの若返り」「復刻版」「海外進出」の5つ。 例えば冷蔵庫ならAIを搭載し食材の食べごろを知らせる（新技術）、災害時の備蓄に特化した製品の開発（新用途）など、さまざまな可能性が考えられます。 この会社では、各製品がライフサイクルのどの段階にあるのかを把握して、成長期の製品をいかに増やすかを考えることが、売り上げ拡大のポイントになります。

★例：ビジネスで起こりえる問題 製品の卸先であるマーケットは、正当な理由もなく、無理な値下げを要求。 営業担当は「長く良好な関係を続けてきたのだから仕方ない」と思いつつ、このまま取引を続けるべきか悩んでいる。 &nbsp; &nbsp; ★使い方 「WinとLoseの視点で互いの関係を評価し、改善を図る」 &nbsp; 自分にとってメリットがある関係であればWin、デメリットがあればLoseと表す「Win/Lose」は、個人間でも企業間でも使える視点です。 &nbsp; 例えば自分にメリットがあり、相手にデメリットがあるならWin-Lose、逆であればLose-Winのように、WinとLoseを組み合わせることで互いの関係を客観的に評価できます。 もし、一方あるは双方にデメリットがあるなら、互いにメリットがあるWin-Winを目指すか、取引を終了するなど、関係の見直しを検討します。 &nbsp;

どちから一方がLoseである以上、両社の関係は平等とは言えません。 そればかりか「Win-Lose」や「Lose—Win」の関係が続けば、Lose側が不満を募らせ、そのしわ寄せによって相手のWinを消滅させる可能性もあり、結果的に「Lose-Lose」の関係に陥る恐れがあります。 したがって、長く良好な関係を維持できるように、互いにメリットを分かち合える「Win-Win」の関係を目指したいところです。 このマーケットでは、まずは相手が要求する値下げの理由を確認したうえで、双方に大きなデメリットが生じないように、希望額の半値を提示するなどの妥協案を模索しましょう。 相手があくまでも自社のWinのみを求めるようであれば、取引を終了するNo Dealも視野に入れなければなりません。

★例：ビジネスで起こりえる問題 マーケティング担当は、大胆な低価格路線を打ち出し、一時は売り上げを好転させたが、ここ数年は低迷が続いている。 顧客が低価格に不満を持つはずはないと確信しているが、打開策を見いだせない。 &nbsp; &nbsp; ★使い方 「マーケティングに欠かせない、顧客が求めている4つの価値」 &nbsp; 「マーケティンの4C 」とは、顧客にとっての価値（Customer value）、顧客の負担（Cost to the Customer）、入手の容易性（Convenience）、コミュニケーション（Communication）のことで、 マーケティングを考える上での重要な指標となります。 顧客は商品の購入にあたって、4つの価値のいずれか1つ以上を求めます。 すべての顧客価値を高めるのは自社の利益圧迫につながるため、どのCを強化したら自社の弱みが改善され、競争力が高まるのかを考えます。 &nbsp;

マーケティングを考えるうえで重要となるのは、顧客の視点です。 顧客はより価値の高いものやサービスを選ぶため、マーケティング成功のカギは4Cの強化にあります。 4Cとは、「顧客にとっての価値」「顧客の負担」「入手の容易性」「コミュ二ケーション」のことです。 自社がどのCを強化すれば顧客価値を高められるかを分析しなければなりません。 低価格の商品は顧客の負担を軽減させるため、リピート率の向上に期待できるかもしれませんが、ブランド力を重視する顧客にとっては魅力が伝わりにくく、結果的には顧客価値を低下させる可能性があります。 例えば、「顧客にとっての価値」を強化する場合は、高品質化やデザイン性の向上などによってブランド力を高め、既存の商品との差別化を図る、「コミュニケーション」を許可する場合は、ファンサイトを作ってお客様の生の声を集めるなどの、不足しているCを補う方法を考えましょう。

★例：ビジネスで起こりえる問題 健康食品事業を展開する会社は、流通コストの削減と顧客層の拡大を目的に、店舗販売を取りやめた。 今後は全商品をネット上で販売するが、既存客層の多くはネットになじみのない高齢者で「買い方がわからない」という苦情が多発している。 &nbsp; &nbsp; ★使い方 「戦略立案時の見落としを防ぐ4つの視点」 &nbsp; 戦略を考える際のフレームワークの「3C分析」は、社内を自社（Company）、社外を競合（Competitor）と顧客（Customer）の3つの視点に分けて定義し、自社だけではなく社外にもしっかりと意識を向けます。 マーケティングの強化を図る場合は、ここに販売網や流通網を意味するチャネル（Channel）を加えて「4C分析」とします。 &nbsp; 4つの視点で現状を分析し、いかに成功要因を導き出すかが戦略の成功を左右します。 &nbsp;

自社の利益と顧客の価値を共有し合い、互いが満足できるマーケティング戦略を立てるには、3C分析「自社」「競合」「顧客」に、「チャネル」を加えた4C分析が必要です。 &nbsp; 例えば健康食品業界であれば、商品を実際に購入する顧客と、商品が手元に渡るまでのチャネルの視点を欠くわけには行きません。 店舗販売の中止の理由が、顧客の拡大と流通コストの削減のためなら、それは既存顧客をすてて時代の流れに則っただけの自社よがりな戦略と言わざるを得ません。 現状のチャネルは縮小にとどめて、既存の顧客と新規顧客層にやさしいチャネルを両立することも視野にいれ、4Cの視点で自社の方針がどのような影響を与えるのかを認識しましょう。 &nbsp;

★例：ビジネスで起こりえる問題 社長は、自分が思いついた経営施策を手当たり次第に遂行しないと気が済まない。 当然、すべてが高い成果につながるわけではなく、収益もさほど上がらないため、社員は無駄な努力を強いられていると感じている。 &nbsp; ★使い方 「インプットとアウトプットで投資対効果を評価する」 &nbsp; 手間と成果の関係は「インプット」と「アウトプット」を考えることで明確化できます。 &nbsp; つまり、インプットを手間、アウトプットを成果としてとらえれば、投資の効果やパフォーマンスの評価ができるため、どうすれば手間を減らして高い成果につながるかを考えることになります。 &nbsp; また、インプットを「遂行の難易度」、アウトプットを「収益の大小」で評価すると、会社の経営施策や課題の順付けにも応用できます。

経営施策や課題の遂行にあたっては、無駄な努力により収益が下がることを避けるためにも、投資対効果を重視して、いかに少ない手間で高い成果につなげるかを考えます。 この投資対効果を考える上で役立つのが、「インプット」と「アウトプット」の「ペイオフマトリックス」です。 ペイオフマトリックスとは「インプットの遂行」の難易度を横時に、「アウトプットの収益」の大小を縦軸に配したマトリックスで、施策や課題を落とし込んでいくことで、それぞれの位置関係によって投資対効果を検証できます。 &nbsp; 例えば会社は「遂行が困難でも収益も小さい」しさくであれば「時間の無駄」になるため控えたほうがいいと判断できますし、逆に「遂行が容易で収益も多いの」のであれば、ボーナスチャンスととらえ、優先的に進めていくべきで結果として高い成果につながります。

★例：ビジネスで起こりえる問題 Ａさんは、どんな業務にも全力を注ぎ、それほど重要でもない案件に忙殺されることが多々ある。 上司からは次々と仕事を振られるが、Aさんは仕事をこなす時間的な余裕がない。 &nbsp; &nbsp; ★使い方 「重要性と緊急性を掛け合わせて仕事の優先順位を明確にする」 &nbsp; 仕事は、重要性と緊急性の大小によって分類することができます。 緊急性の高い仕事には最優先で取り組まなければなりません。 しかし、重要性の大小を軽視して計画をたてると、時間にゆとりが持てず、新しい仕事を受け入れる余地もなくってしまいます。 仕事で、重要性と緊急性の掛け合わせにより、優先順を明確にします。時間的な負担が大きい「重要性大×緊急性小」の仕事をふやすことでゆとりと成果の両立につながります。 &nbsp;

仕事の優先順位を決める「重要性」と「緊急性」の大小を組み合わせたマトリックスを活用します。横軸を「緊急性」の大小、縦軸を「重要性」の大小として、現状の仕事を4つに分類してみましょう。 Aさんは、下段左に配された「重要性小✖緊急性大」の仕事は、隙間時間に短時間で済ませるのが理想です。 一方下段右の「重要性小×緊急性小」の仕事は、急いで片づけても大きな成果を生む可能性が低く状況によっては保留にします。 反対に優先すべきなのは、上断右の「重要性大×緊急性小」の仕事です。 この仕事を前倒しで進めて緊急性を上げないようにすれば、時間的なゆとりと高い成果の両立が可能になります。 仕事の重要性に応じて時間的なメリハリをつけ、日々の忙殺から解放されましょう。

問題の洗い出しは問題解決に向けた最も重要で、重きの大半を置いてもいいというくらい大事なことです。 それくらい重要なものであるにもかかわらず、なかなか本当の問題に気づくことができないのもまた事実です。 ぜひ、これらのテンプレを使用して問題解決の初めの一歩を大きく踏み出しましょう。

上流業務の必須パッシブスキル【問題解決】を身につける『問題の洗い出し・テーマ化編』

なっしー（岩瀬　勝義）

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

皆さんは、フリーランスのエンジニアとして働くことが多いと思いますが、残業時間はどうでしょうか？ 残業ばかりでしょうか？それとも定時で退社できているでしょうか？ &nbsp; 仕事場によって、残業時間はまちまちだと思います。 &nbsp; そこで、会社員時代の残業と、フリーランス時代の残業両方を、私の経験談を含めて、ご説明いたします。

まずみなさんに質問です。 &nbsp; 世間的に残業ってどれぐらいしていると思いますか？ &nbsp; 下の図をご覧ください。 こちらは、2020年度の職種別の残業時間になります。

全体平均は、「20.6時間」です。 &nbsp; これは多いと思いますか？ 自分的には、こんなに職種全体で、残業が多いのか！と思いました。 &nbsp; ここで、IT業界にフォーカスを当ててみましょう。 21.8時間となっています。 結果だけ見ると、他の職種とさほど変わらない結果になっていますね。 &nbsp; では、なぜ、IT業界は、残業が多いと言われることが多いのでしょうか？

私は、東証一部上場のIT企業の正社員として、某銀行のシステム開発するＰＪに在籍していました。 今は、フリーランスとして、某通信業界のシステム開発するＰＪに在籍しています。 &nbsp; 昔在籍していた会社では、毎年、平均残業時間の周知がありましたが、 平均すると「20時間前後」となっていました。 そのため、東証一部上場のIT企業でも職種全体の平均に近い時間になっています。 &nbsp; が、この残業時間は、以下２点によって、左右されると私は思います。 ・ＰＪの炎上有無 ・仕事内容／役割 &nbsp; 私自身、正社員で働いていたとき、残業時間を平均すると、「40時間」前後になっていました。 なぜ、平均よりも多い残業時間になったかですが、それが前段の２点のためだと思っています。

残業が多いＰＪは、「炎上」しているということです。 この炎上する。ですが、いろんな要因があります。 ・仕事分担がきちんとできず、誰かに作業が偏っている。 ・お客様の締め切りが極端に短い。 ・作業計画が失敗した。 ・システム障害が多発した。 などです。 &nbsp; 私が在籍したＰＪも炎上していたのですが、この要因のどれかに当てはまっていました。 そのため、炎上してしまい、自ずと、残業時間があがってしまいました。 &nbsp; 逆に、炎上していないＰＪにいる社員は、ほとんど残業しておらず、定時退社している状況でした。 &nbsp; そのため、炎上しないように、計画立てて作業することや、体制の検討、顧客折衝は、IT業界にとって欠かせないことだと、私は思っています。

仕事内容はなんなのか。というのも、大事な要素になってきます。 私が、新人の頃は、残業もなく、定時退社を続けていました。 その当時は、プログラムを作成する仕事しかなかったために、定時に帰ることができていました。 &nbsp; ただ、年次が上がると同時に、仕事内容が極端に増えていきます。 そこがＩＴ業界が専門職と言われることにつながってきます。 &nbsp; ＩＴ業界の仕事は、何をするにしても、「スキル」が大切になってきます。 「プログラミングスキル」、「システム設計のスキル」など、他の仕事では身に付けることができないスキルが必要です。 &nbsp; そのため、このスキルがある人に、仕事が集まります。 そして、年次が上がれば上がるほど、後輩育成や、社内会議が増えていきます。 &nbsp; こうなると、プログラミング、システム設計、後輩育成、社内会議など、やることが多くなり、その人の残業時間が極端に増えることがよくあります。 &nbsp; ただ、この仕事が一人に偏ることなく、作業分担ができているＰＪは、作業時間も均等できるので、残業時間が多くなることはなかったです。 &nbsp; そのため、後輩を育てる。ことと、作業分担がＩＴ業界にとっては欠かせないものではないか。と私は思っています。

前段で、会社員時代の残業時間について、お話しました。 では、フリーランスの場合はどうでしょうか？

１つめの「PJの炎上有無」ですが、こちらは、所属するPJに左右されてしまいます。 ただ、フリーランスSEというのは、現場を選べる立場にいますので、きちんと炎上していないPJに参画できれば、残業は少なくできます。 &nbsp; その為、残業を少なくしたいのであれば、案件を斡旋していただける会社に協力を仰ぎ、炎上していないＰＪを紹介していただくことが大切です。

２つめの「仕事内容／役割」ですが、確かにフリーランスＳＥの方はスキルが高く、様々な仕事を任せられると思います。ただ、一度考えてみてください。会社員だからこそある作業はなんでしょうか？ &nbsp; そう。後輩育成や、社内会議です。 &nbsp; フリーランスSEになれば、後輩育成や、社内会議などがなくなります。 ということは、自分自身の仕事のみになるため、会社員と比べると、仕事量が減るのがイメージできませんか？ &nbsp; なので、フリーランスSEになると、 ①炎上していないPJを選べる。 ②自分の仕事をすれば良い。 ので、会社員時代から比べると、確実に残業時間が低減できると考えられます。

いかがでしたでしょうか？ 私の経験談から、残業について纏めてみました。 &nbsp; ＩＴ業界が残業多いと言われる理由は、残業時間が多い人、少ない人の残業時間が極端だからだと思います。 残業時間が月80時間の人も居れば、月0時間の人も居ます。 &nbsp; そして、この多い時間にフォーカスが当たってしまうので、ＩＴ業界は残業が多いという印象がついてしまっているのだと考えられます。 &nbsp; &nbsp; &nbsp; また、私自身、１日中バタバタしている日ばかりで残業ばかりの時や、１日中暇で定時退社をするの両方とも経験したことがあります。 &nbsp; ただ、会社員の時代よりは、フリーランスになった方が残業時間のコントロールができるようになり、世間で言うライフタイムバランスが良くなったと思っています。 &nbsp; 残業時間や、１日中忙しすぎると感じる方は、一度、フリーランスとして働いてみるのも良いのではないでしょうか？ また、フリーランスSEの方は、ライフタイムバランスが良くなったと思いませんか？ &nbsp; 是非一度、考えてみてくださいね。

残業が多いイメージのIT業界にてフリーランスになってどう変わった！？

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

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


「好きな時に好きな場所で仕事をする」数年前は夢のまた夢だったフリーランスという道も、ITの進化やワークスタイルの多様化により、挑戦しやすい世の中となりました。 とは言え、一体”何から手をつけて良いのかわからない”という人も多いでしょう。 一見、ハードルが高く見えるフリーランスですが、しっかりと準備をして行動すれば、問題なくスタートすることが可能です。 &nbsp; 今回はフリーランスを目指したい方向けに、「会社を辞める前に準備しておくこと」、「移行期間」、「実際にフリーランスになった後」の３場面を分けて、準備するべき事柄をまとめてみました。

会社を辞める前に準備しておきたいこと

フリーランスになると決めてから、 事前準備なしに挑戦することは危険です。 まずはしっかりと準備をして、一歩踏み出しましょう。 &nbsp; &nbsp; 資金・信用を貯めておく ・生活資金を貯めておく ・事業資金を貯めておく ・クレジットカードを準備する ・銀行口座を開設する

フリーランスの収入は不安定になりがちです。 特に事業をスタートした時点は収入がほぼゼロに近い状態がしばらく続くこともあります。 収入がゼロになった時を仮定して、半年間収入がなくとも最低限の生活ができるよう、ある程度、生活資金を貯めておきましょう。 お金(貯蓄)は日々の安心を生みます。 安心があれば精神面も安定して事業を進めることに繋がります。

生活資金に加えて、こちらも必須項目です。 SEなど商品に形がない場合でも、後に紹介する事務所家賃や備品、通信環境を整えるためのランニングコストは必ずかかります。 今後必要となる項目と金額をリストアップしておいて、必要となる事業資金を計算し、生活資金とは別で貯めておきましょう。 もちろん融資という方法もありますが、返済の必要に加えて、フリーランスの場合、会社員と比較して信用が下がりやすい傾向にあるため、ある程度、自己資金を貯めておくことをおすすめします。

オフラインでの決済に加え、オンラインでの取引でクレジットカードは必ず必要となります。 フリーランスになれば、審査が厳しくなる場合もありますので、会社員の間に審査を通しておきましょう。

自分の生活口座とは別に事業専門の口座を作りましょう。 プライベートと通帳を分けることで売上管理や顧客管理が容易になります。 &nbsp; &nbsp; お客様とのやりとり ・ポートフォリオ作成 ・SNSアカウント作成 ・問い合わせ先の準備

すぐに実績を提示できるよう、ポートフォリオを準備しておきましょう。 また、ポートフォリオはSNSなどの集客でも活用することができるので、整理しておくことがポイントです。

SEなどの仕事は実績が顕著に現れるため、SNSを活用した集客もおすすめです。 そのためには、3大SNSと呼ばれるフェイスブック、ツイッター、インスタグラムは最低限駆使しておきましょう。

仕事を受注する上で問い合わせ項目は必ず必要です。 メールアドレスや電話番号などを準備をしてきましょう。

会社に勤めながらできる準備が整えば、 次はいよいよ会社を辞めてから移行期間に入ります。 ここで準備不足や大きなミスがあると、今後のスケジュールにも大きな影響となります。 移行期間もミスなくもれなく準備を進めましょう。 &nbsp; 年金の切り替え ・健康保険から国民健康保険へ ・厚生年金から国民年金へ

フリーランスになると会社員として受けていた今までの健康保険を受けることはできません。 フリーランスとして活動する場合は、国民健康保険への加入を検討しなければなりません。 ほとんどの場合、国民健康保険加入しますが、保険料が割高になる場合も多く、別で任意継続など、別の方法を取る方もいらっしゃいます。 自分の保険料を算出して、良い選択をしましょう。

会社を退職し、フリーランスになる場合、厚生年金の対象外となるため、国民年金への切り替え手続きが必要となります。 国民年金は「基礎年金」と呼ばれ、国民年金に上乗せして支払う厚生年金と比べると、受給額が減少する特徴があります。 老後に手厚い年金を希望する方は追加で付加年金や国民年金基金に加入することも可能です。 &nbsp; 書類関係の準備 ・開業届を提出する ・青色申告書を作成する ・帳簿作成 ・印鑑を作成する

会社員を退職してフリーランスになる場合、開業届を出しましょう。 必須ではありませんが、開業届を出すことで税制上優遇される場合もあるので、前向きに検討しましょう。

開業届とセットで検討していただきたいのが、確定申告の際に必要となる青色申告書。 「白色申告」または「青色申告」から選ぶことが可能ですが、青色申告の場合、最大65万円の控除を受けることが可能となるので、おすすめです。

売上を計上するにあたって必要となるのが帳簿。 帳簿は確定申告の際にも提出が必須です。 税理士にお願いするパターンもありますが、”運用資金を抑えたい”と考える方がほとんどでしょう。 また、品目と金額を入力するだけで自動で帳簿を作成できる会計ソフトも業務の効率化と費用を抑える面でおすすめです。

通常、印鑑登録など用に所持しますが、フリーランスとして活動する場合は通常の印鑑に加えて屋号がついた印鑑が必要です。 また、住所が記載された住所印があると、書類作成時に便利です。 &nbsp; &nbsp; 設備環境を整える ・事務所を契約する ・通信環境を整える ・備品を準備する

フリーランスとして活動するにあたって事務所を構えたい方もいらっしゃるでしょう。 SEなどネット環境があれば、自宅でも仕事が可能な場合もありますが、オンオフをつけたい場合や、自宅住所など個人情報を極力控えたい場合、打ち合わせでお客様に来ていただく場合など、利便性を考えると事務所を構えている方がメリットは多いでしょう。

フリーランスのSEになるにあたって、通信環境が整っていることは必須項目です。 最近はポケットWi-Fiなどの選択肢もありますが、電波が不安定だったり、速度制限がかかったりする場合があるので、月額利用料金が安くともおすすめしません。 固定タイプのWi-FiルーターはポケットWi-Fiと比較して割高ではありますが、通信速度が安定しているため、おすすめです。

印鑑と合わせて準備しておきたいのが、封筒や切手など書類配送に関する備品。 また、机や椅子、プリンター、ホワイトボード、文房具など、必要なものは一通り揃えておきましょう。 &nbsp; 仕事に直結する準備 ・名刺 ・エージェント登録 ・見積書・請求書

先方に挨拶する際、自分の身を明かすためにも名刺は必須です。 名前に屋号、住所、連絡、SNSなど、お客様に覚えていただく大切なツールですので、手を抜かず作りましょう。

フリーランスとして活動するにあたって、どうやって仕事を取れば良いかわからない人もいるでしょう。 そういった方々におすすめなのが、エージェントに登録すること。 案件紹介や事務・経理などフリーで活動するにあたっての相談にも乗ってくれます。

仕事を受けるにあたって必要となるのが、見積書と請求書。 今までは会社の経理が処理してくれていたことも、フリーランスとなれば自分で準備しなければなりません。 あらかじめフォーマットを準備しておけばスムーズに契約を進めることができますよ。

ここからは会社員を辞めてから継続的に行うことをご紹介します。 &nbsp; 仕事を取るために ・コミュニテイに入る ・スキルアップ ・お客さんへ連絡 ・クラウドソーシングサイト

フリーランスとして活動するにあたって、今まで想像もつかなかったトラブルや悩みを抱える方も多いでしょう。 そういった場合、コミュニティに参加することをおすすめします。 仕事の受注方法、進め方に加えて、不安の解消にも繋がるでしょう。

フリーランスとして活動するにあたって、あとまわしにしがちだけれど、重要なのがスキルアップに努めること。 会社員の時とは違い、ほとんどの業務をひとりでこなす必要のあるフリーランスは日々のスキルアップをあとまわしにしがちです。 ただ、長い目でみて大きな差がつくスキルアップはコツコツと長期的に続けることが重要です。

友人や知人、以前お仕事をさせていただいた方々にフリーランスとして活動すると連絡をいれましょう。 周囲の人々に再度、認識してもらい、関係性を構築することが重要です。

冒頭に述べたように生き方の多様化やテレワークなど、環境の変化により、フリーランスも身近に感じるようになりました。 それに伴い、近年「クラウドワークス」をはじめ、クラウドソーシングサイトが増えています。 登録してまめにチェックしましょう。 初めは単価に見合わない仕事が多いかもしれませんが、継続的に受けることで単価アップやスキルアップにも繋がります。

今回はフリーランスとして活動するにあたって、必要となる準備を3つの段階別に紹介しました！ 今回紹介した内容が全てが必須というわけではありませんが、準備しておいて損はありません。 ぜひ参考にしてみてください。

【フリーランス志望者必見！】フリーランスになる前に準備しておきたいこと

中川　里美（ナカガワ　サトミ）

20歳の時にアメリカで出会った経営者に誘われてライターの道へ。
自分の事業と並行して趣味レベルでライター業に取り組んでいたが、
その後のリモートワークやネットビジネス業界の普及により、
ネット環境があれば、どこでも仕事ができるライター業の魅了を再認識する。
現在、リサイドのライターとして、記事を執筆中。
好きなことは、旅と美味しいものを食べること。
今年の目標であったバンジージャンプと滝行と富士登頂を達成し、来年の目標を思考中。

昨年から大きく普及した「リモートワーク」は、会社に通勤せず自宅やカフェなどで仕事を行うことを言います。 &nbsp; リモートワークをすると通勤時間の削減など、ワークライフバランスをしっかりとれるということでリモートワークをしたい方は多いと思います。 &nbsp; しかしリモートワークは通常出社とは違って、必要とされる能力があります。 この能力を身に付けておかないとせっかくリモートワークができたのに、仕事の効率が下がる事にも繋がります。 &nbsp; 今回は実際にリモートワークをしている私から見て、リモートワークで活躍するために必要な能力についてお話しします。

リモートワークをするために必要な能力

クライアントの期待を超える結果を出すスキル

リモートワークは出社と違いコミュニケーションが不足しがちになるので、クライアントの要件を正確に把握できるかが大切です。 &nbsp; 要件を把握する力がないと、自分としては100点の成果物でも実際には80点レベルだったということがあります。 &nbsp; ですから、クライアントの要件を正確に把握した上で作業に取り組もうという話なのですが、 残念ながらクライアントのコミュニケーション能力の問題もあり、要求をお互いに100%理解しあえているか？という細かいところはリモートワークだとどうしても分かり辛いんですね。 &nbsp; それならばクライアントの要求を超える力、つまり100点を望まれた時に120点を出せる力が大切だと思っています。 &nbsp; 「なぜこっちがわざわざ、要求されていない+20点分の力を出さないといけないんだ！」となるのは理解できますが、少し考えてみましょう。 &nbsp; ビジネスの基本は「価値の先出し」です。「価値」を提供できるから「対価」をいただくことができます。 余談ですが、価値と対価のバランスが崩れると、「ブラック企業」だとか「やりがい搾取」と言った不平不満が出てきますね。 &nbsp; また120点を出すということは、とことん顧客目線に立てるということでもあります。 とくにITエンジニアの場合は相手目線に立てるか？という点が非常に重要かつ、付加価値を提供できる点です。 基本的に合理的な人の集まりで（もちろん長所でもあります）必要以上のことをしないので、このポジションはだいたいどのチームでも空いています（笑） &nbsp; その他、自分のスキルの向上に繋がるので、実は悪いことはありません。 &nbsp; ビジネス面から考えても、顧客目線、自分目線で考えても実はみんな得をするんですね。

私がリモートワークを始めた時に一番戸惑った部分はここでした。何気ない質問や相談が基本的にやり辛くなります。 &nbsp; 「何気ない質問なら大丈夫じゃない？」と思うかもしれませんが、これがあるのとないのとではかなり状況は違いました。 &nbsp; たとえば環境構築1つとっても、とくにドキュメントも無くディレクターもエンジニアほぼ未経験の方で誰に聞いたら良いかもわからない状態でした。（もちろんチームの人の顔も名前もわからない） 最終的に「現場のエンジニアが今使っているツール一覧」だけを見せられて、「じゃ、後はお願いします」と言われた時の衝撃は忘れられないです（笑） &nbsp; 上記の事態に遭遇した場合どういう対処をするでしょうか？もちろんこういう場合一方的にクライアントが悪いからと責め立てることもできます。 しかし、結局のところ1人で問題解決できる人間が重宝されます。当然、手間がかからない人間の方が使いやすいですからね。 &nbsp; 何か想定外のことが発生したときに相談できる人が身近にいないということは、精神的なストレスを生みます。 &nbsp; しかしこのストレスを突破できる力を持っているからこそ、リモートワークでものびのびと仕事ができるのだと私は思っています。 &nbsp;

リモートワークだと誰かからの監視の目がありません。 &nbsp; 自分を管理する人がいないということは、仕事をサボっても「その時は」誰にも注意されないしバレません。 だからこそ自己管理能力が試されます。 ●&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業務を進捗通り行っているのか？ ●&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;チャットのレスポンスは早いか？ ●&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;サボっていないか？ &nbsp; こういうことはクライアントも注意深く見ています。 とくにチャットのレスポンススピードなどの細かいところを徹底できるかどうかは大切です。 &nbsp; また、労働面のほかに健康面も気を付ける必要があります。 通勤の場合、平日は外に出て歩いたり誰かとコミュニケーションを取ったりすることが当たり前でした。 &nbsp; しかしリモートワークの場合はこれらの要素がすべてなくなるため、日々の健康管理もすべて自分で行っていく必要があります。 &nbsp; とくに若い世代だと健康管理していなくても若さで乗り切れる場面は多々ありますが、 そのたびに健康寿命をすり減らしているということも頭に入れて、健康管理をしていきましょう。

リモートワークで求められる力はスキル以外にもたくさんあるということがわかりました。 &nbsp; これからリモートワークをする予定の人、将来したいと思っている方はぜひ参考にしてみてください。 &nbsp;

リモートワークでも活躍できるエンジニアになるために必要な能力とは？

ある程度会社員としてキャリアを積んできた方や、自由な働き方に憧れる方だと、フリーランスになるかどうか悩むこともあると思います。 &nbsp; 「フリーランスと会社員どちらが良いの？」といった話をよく聞きますが正解はありません。 もし正解があるならみんな正解の方を選択していますからね。 結局のところ両者の特徴を理解して自分に向いている方を探すのが良いでしょう。 &nbsp; そこで今回はフリーランスと会社員を比較して自分に合った働き方を見つけるとともに、もしフリーランスになる場合にやっておいた方がよいことをご紹介します。

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

会社員はまじめに働いていれば基本的に安定的な収入を得ることができます。 &nbsp; 一方フリーランスの場合安定性はありません。契約が取れなかったり、売れなければ収入は0円という世界です。 逆を言えば必要とされる分に応じて青天井で収入が上がっていくので、会社員以上に稼ぎたいと思っている人には魅力的でしょう。 &nbsp; 少し話が逸れますが、近年は国としても会社員の副業を認める流れができています。 なので会社員＋副業のハイブリッドで安定を取りつつ稼ぎにいくというやり方も賢いかもしれません。

会社員の場合は、所得税・住民税等の税金を自分から納付する必要はなく、基本的にほぼすべて会社側で所得を計算し天引きしてくれます。 &nbsp; 一方フリーランスの場合は、毎年「確定申告」という作業を行い税務署にその年の所得を報告し税金を納めるという流れになります。 &nbsp; また納める税金の計算方法も少し変わってきます。会社員の場合は「給与所得」ですが、フリーランスエンジニアの場合は「事業所得」。 &nbsp; 会社員は経費計上ができない代わりに「給与所得控除」があり、フリーランスの場合は事業にかかった経費分は売上から控除できます。 &nbsp; 他にも、フリーランスだと事業所得の額が一定額を超えると、個人事業税がかかってきたりと、 会社員と比較するとかかってくる税金も納め方も異なります。 &nbsp; 最初は混乱すると思いますが、しかし1つ1つを調べていくとそこまで難しいことではありません。 &nbsp; 今は「<a style="color:#1155cc" href="https://www.freee.co.jp/lp/brand/01/" target="_blank" rel="noopener noreferrer">freee</a>」や「<a style="color:#1155cc" href="https://www.yayoi-kk.co.jp/products/index.html#online-app" target="_blank" rel="noopener noreferrer">やよいの青色申告 オンライン</a>」などクラウド会計ソフトが充実していて、昔に比べると困ることは多くないはずです。

会社員の場合は厚生年金に加入していますが、フリーランスのみの場合は加入していません。 &nbsp; 現状の国民年金の支給額だと将来的に月6万円程度の支給となるはずなので、ここから足りない分は今のうちに資産や貯金を作っておく必要があります。

基本的に会社員の方が信用度は高いです。 とくにフリーランスを始めたばかりの時は信用が低いのでローンを組んだりクレジットカードを作成するときは不便です。 &nbsp; しかしフリーランスとして長期的に安定した売上を上げたり、会社員と比べて大きく売上を上げると信用も回復します。

フリーランスになるまでにやっておいた方が良いこと

先ほど述べたように、フリーランスになると一般的には会社員より信用度が低下します。 &nbsp; クレジットカードは要するに「借金」なので、本人の信用度が低いと作り辛くなってしまいます。 &nbsp; クレジットカードを作成したことがある方ならわかると思いますが、作成の際には職業を記入する必要があります。 ここで「自営業」と書くか「会社員」と書くかで、信用度が大きく変わってきます。 &nbsp; ただ、自営業だからといってクレジットカードが以降まったく作れなくなるというわけではないので、 現状持っていなくても落ち込むことはありません。

自分がフリーランスとして通用するかどうか？は事前に確認しておきましょう。 &nbsp; もし今のスキルでは物足りない場合、会社を辞めることはハイリスクです。個人的にはオススメできません。 &nbsp; このあたりの相談は無料でやってくれるエージェントが多いので、一度問い合わせてみることをオススメします。 &nbsp; 大体のエージェントは2~3年くらいの業界経験があれば面談してくれるはずです。 &nbsp; 「自分なんかが相談しても良いのかな」と不安に思ってしまう方もいるかもしれませんが、 &nbsp;エージェント側もビジネスとして（＝自社経由で契約してもらうために）、相談に乗ってくれているので遠慮する必要はありません。（とはいえ感謝はしましょう）

要するに貯金をしておこうということです。フリーランスになったからといってすぐに報酬が支払われる保証はありません。 そのときもし貯金が0円だったとしたら、借金をしないといけなくなります。 &nbsp; そんな時に役立つのが生活防衛資金です。若い方でしたら、最低の目安で月の生活費の3ヵ月分くらいは欲しいところです。 &nbsp; でもこの生活防衛資金がないからといって、フリーランスになってはいけないということでもないです。 このあたりはどの程度自分がリスクを許容できるのか（配偶者の有無など）でも変わってくるので、あくまで目安として捉えておきましょう。 &nbsp; ちなみに私は「最悪バイトすれば良いや」と思っていたので、生活防衛資金は全然なかったです（笑）

タグ:【キャリア】の記事一覧

上流業務の必須パッシブスキル【問題解決】を身につける『問題の洗い出し・テーマ化編』

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

残業が多いイメージのIT業界にてフリーランスになってどう変わった！？

【フリーランス志望者必見！】フリーランスになる前に準備しておきたいこと

リモートワークでも活躍できるエンジニアになるために必要な能力とは？

フリーランスと会社員を比較！自分にあった働き方を選ぼう

おすすめ記事

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

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

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

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

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