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

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

こんにちわ！&nbsp;&nbsp;&nbsp;&nbsp;タカトです。 &nbsp; 今回はPMとは違うPMOというポジションの仕事について解説していこうと思います。 エンジニアとはまったく違う、けど具体的に何をしているかよく分からないのが正直なところ・・・なので実際にそのポジションに入って何をしてきたかも踏まえてお話していきます。 &nbsp; 当記事では ・PMOについて ・PMと具体的に何が違うの ・スキルってどんなのが要るの ・過去、どんなことをしてきたのか &nbsp; をお話していきます。記事の信頼性として &nbsp; ・PMO歴は8年目 ・銀行、証券、不動産、コンビニなど多岐に渡って従事してきた &nbsp; では行きましょう！

PMOは「Project Management Office」の略称になります。 世の中の定義としては、「組織内における個々のプロジェクトマネジメントの支援を横断的に行う部門や構造システム」を指します。（日本PMO協会より抜粋） &nbsp; 何のこっちゃ・・・?となりますよね。 &nbsp; シンプルにいうと「プロジェクトを円滑にしていくためにマネジメント・業務支援を行ったり、会社や部署間のやり取りを窓口となって横断的に行う」になります。 &nbsp; プロジェクトは大規模になればなるほど、管理が大変になったり部署やシステムごとの連携がおろそかになったり、認識の齟齬が生まれたりします。そう言ったことにならないよう、横断的に動いていくことでプロジェクトがスムーズに進むよう支援を行うのがPMOです。

プロジェクトを成功に導く上で絶対的に必要な存在は「PM（プロジェクト・マネージャー）」です。PMOは頭文字だけ見ると似てるんですが、全然役割は違ってきます。

大きく分類すると上記の表のようになります。PMは意思決定を行い、PMOはそのサポートをするイメージです。

求められる役割は現場によりけりだが、大事なことは決まっている

正直、参画するプロジェクトでやることは様々で、入ってみないと分からないことが多いです。 &nbsp; 総合テストプランからテスト実施までやることもあれば、ユーザ向けの要件定義資料の作成を行ったり、私が経験してきたことを振り返ってもかなり多岐に渡って様々なことをやってきました。 &nbsp; なので人によってはPMOは「事務局的な役割、便利屋」と思ってる人も多くいます。 &nbsp; 本来の役割とは違うと思われてしまうのが残念ですが、大事なのは「PMをしっかりサポート・見えないところを補い、プロジェクトがスムーズに遂行できるよう支援する」、ここが大事になります。

習得、得意としておくと良いスキル

PMOとして仕事をしていく上で、このスキルが欠かせない！もしくは得意だと非常に仕事がしやすい、というものがあります。 それは「コミュニケーション力」「ロジカルシンキング・論理的思考」「資料作成スキル」「相手の立場になって物事を考えられる思考」「前のめりな姿勢」です。

横断業務をするということは他社や他部署とのやり取りがメインになってきます。メールやチャットツール、電話、打ち合わせなど人と関わることがとにかく多くなります。 絶対自信がある！まではいかなくても良いですが、普通にコミュニケーションが取れるぐらいは必須です。逆にこれが苦手な人は厳しいです。

ロジカルシンキング・論理的思考

IT業界だと論理的思考が必要とよく言われますが、PMOも同様です。システムに携わる以上は筋の通った思考が必須になります。特に説明が必要な場面が多く出てくるので、そこは何故そうなるのかを明確に説明しないと相手も「なるほど」とはならないので、論理的思考は必要です。

PMが意思決定するにあたり、そのネタとなる資料を作ることが多々あります。 アプリケーションは主にエクセル・ワード・パワーポイントです。これは一通り使いこなせないと資料作成は厳しいのでしっかり習得しておきましょう。 「どのぐらいできると良いのか？」と良く聞かれますが、エクセルは最低限の関数が使えること、ワードやパワポは現場の過去の資料を見て「これぐらいなら出来るぞ」というレベルで良いと思います。最悪、調べながらでもできるという覚悟があれば良いです。

相手の立場になって物事を考えられる思考

相手とやり取りをして行く中で、スケジュール遅延が発生したら頭ごなしに「期限守ってください」というのはナンセンスです。 守れなかったことに対する引け目は相手は感じているはずなので、そこを「どうやったら期限内に資料が出てくるか？」を考えてやり取りをする必要があります。 その中で自分に出来ることがあれば支援をしていくのが良いPMOだと思います。

PMによっては何も言ってこない方もいます。自分でキャッチアップして仕事を探してくれと。割と酷と思うかもしれませんが、そういう人もいるんです。 なので、出来る限り自分から情報を取りにいくことが大事です。 受身の状態になってしまうと「何のためにいるの？」と思われてしまうので、自分から動いていくよう心がけるとPMも仕事がしやすく喜ばれます。

実際に入った現場でしてきたこと

PMOとしては約8年、案件としては10案件ほど参画してきました。その中で実際にやってきた内容の一部を紹介します。

<h4 id="he45b4f7aad">案件1：</h4>WBS、課題の管理 定例会の準備、司会進行、議事録作成 会議の資料作成 システム導入に向けた運用ルールの策定、各部へのヒアリング・調査・資料作成

<h4 id="hf5ce9dc1a1">案件2：</h4>要件定義作成 工程移行判定会資料作成 会議の司会進行、議事録作成 会議の資料作成 総合テスト、ユーザテストの仕様書・テストプラン作成、テストの実施、報告資料作成 定例会準備、会議の司会進行、議事録作成 WBS、課題の管理

<h4 id="h62a927b0a5">案件3：</h4>システムの移行計画書の作成 定例会準備、会議の司会進行、議事録作成 WBS、課題の管理 各部へのヒアリング、調査・資料作成

<h4 id="hf8c38908b4">案件4：</h4>総合テスト仕様書の作成 総合テストの実施、報告資料作成 定例会準備、会議の司会進行、議事録作成 WBS、課題の管理

主にこういったことをやってきました。 &nbsp; 案件によって本当にバラバラで、正直エンジニアちっくなこともやってきました。 （昔エンジニアだったので、その経験があったから参画できたからかなと） &nbsp; 共通してやっているのは ・会議資料の作成、司会進行、議事録作成 ・WBS、課題の管理 になります。 &nbsp; スケジュールが遅延しないよう管理したり、課題についても分からないなら自分なりに調べて落とし込む必要があります。 &nbsp; 会議については最初は前任者がどういった進行をしているのか教えてくれるはずなので、それに沿って行い、場数を踏んでいけば慣れてきます。 &nbsp; 議事録は現場によって粒度が違いますが、自分の中でテンプレート的なものがあると非常に楽です。これについては別の記事で解説していこうと思います。

まとめ：PMOはお金を出して雇うだけの価値を自分で見出していくことが大事

会社によってはPMOの存在を疑問視するところもあり、正直、PMがやれという現場もあります。 &nbsp; ですが、それでは円滑に回らないため、お金を出してでも欲しいというのがあります。 &nbsp; なのでそれに見合った働きをすることが大事です。 &nbsp; やることは様々ですが、主とする業務はイメージがついてきたかと思います。 &nbsp; あとはしっかり場数を踏み、経験と共にスキルと自信を上げていき、PMOという役割の価値を自分なりに見出していきましょう！

意外にちゃんとは知らないPMOとは？PMOの実務経験8年のエンジニアが解説します！

タカト

2児に父でフリーランス歴8年目、主にPMO・サポート業務をメインに案件をこなしています。Webライターとしても活動中。

こんにちわ！&nbsp;&nbsp;&nbsp;&nbsp;タカトです。 &nbsp; 最近、よく聞く「NFT」、ご存じでしょうか？普通に生活してたら触れることすらないと思います。今回はそんなNFTについて解説していこうと思います。この記事で解説するのは ・NFTって結局何なのか ・NFTの強み ・始めることのメリット、デメリット &nbsp; になります。本記事は3分ほどでサクッと読めますのでランチ時などに是非！ &nbsp; では早速行きましょう。

NFTとは？唯一無二のデジタルデータ！

NFTとは「Non-Fungible Token」の略で、日本語にすると「非代替性トークン」と言います。 非代替性とは「替えが効かない」という意味です。 &nbsp; 簡単に言うと「シリアル番号が振ってある唯一無二のデジタルデータ」というものになります。 &nbsp; シリアル番号が振ってあることで、同じものが存在しない（＝替えが効かない）ものになります。 &nbsp; よく限定品などでもシリアル番号入りなんてものがありますよね。それのデジタル版と思って貰えると、イメージが湧くかと思います。

唯一無二を実現しているのがブロックチェーン技術

現実のものだと、番号を刻印すればそれで済みます。デジタルデータの場合は、「ブロックチェーン技術」というのが用いられます。 &nbsp; このブロックチェーン技術によって、デジタルデータにシリアル番号が振られ、番号の偽証などが出来ず唯一無二のものになるわけです。 &nbsp; 今まではデジタルデータを簡単にコピーすることが可能でした。 &nbsp; ですがNFTは、ブロックチェーンの技術を使い「世界にひとつしかないデジタルデータ」を実現することを可能にしました。 &nbsp; 今までコピーが可能だったのが出来なくなる、これは結構凄いことなんです。 &nbsp; Twitter社の創業者、ジャック＝ドーシーは自身が投稿した最初のツイートをNFTにし売買したところ3億円で落札されました。 &nbsp; <a style="color:#333333" href="https://v.cent.co/tweet/20" target="_blank" rel="noopener noreferrer">https://v.cent.co/tweet/20</a> &nbsp; 正直、「え？何故ツイートのデジタルデータに3億？」って思いますよね。 &nbsp; でも、現実に起こっていることで、欲しいと思う人たちが競り合い落札された額なので、それだけ価値があるということになります。 &nbsp;

デジタルデータを「所有物」として使うことが可能

3億で購入したのに驚きを隠せないと思いますが、これが「物」として扱う前提で考えて下さい。 &nbsp; NFTは、これを売買できるんです。 &nbsp; もちろん、自身でコレクションの一環として所持することも可能ですが、他に欲しい人がいたら、その人に売ることができるのです。 &nbsp; これは自分で絵を買って、欲しい人がいたら売却するのとまったく同じです。 デジタルデータが実際の物かの違いです。 &nbsp; ただ、デジタルデータには強みがあります。 &nbsp; それは誰が売り、誰が買ったか分かるように履歴になっているんです。 &nbsp; これにより、一番最初の出品者が誰で、どの価格から始まり、誰の手に渡ってきたか、購入者・値段が全てわかることになります。 &nbsp; その購入者の中に有名な人の名前があったら「この人が買うということはそれぐらい価値があるのか！？」となり、値段が跳ね上がることもあります。 &nbsp; 実際の物では履歴は管理してないので、それが出来るのがNFT（デジタルデータ）の強みになります。

NFTは投資用のデジタルデータなのか？

答えは「NO」です。 &nbsp; 先にも述べましたが、コレクション用で購入する人も多々います。 好きなイラストレーターさんのイラストがあったら欲しくなりますよね。 それが唯一無二なら尚更。 &nbsp; コレクションしたNFTを用いてギャラリーを開く人もいますし、メタバース内にそういった場を設けて展示会を開いたりする人もいます。 &nbsp; なので決して投資のためだけのものではないということです。

NFTは購入することも自身で作ることも可能

NFTは自身が作ることも可能です。 &nbsp; 2021年、こんなのが話題になりました。 &nbsp; 「小学3年生のイラストに380万の価値がついた！」 <a style="color:#1155cc" href="https://www.businessinsider.jp/post-241969" target="_blank" rel="noopener noreferrer">https://www.businessinsider.jp/post-241969</a> &nbsp; この時、一気にイラストを描く人が増えたそうです。 &nbsp; そりゃそうですよね。まさか小学生の書いたイラストにこんな価値がつくなら、もしかしたら自分にもワンチャンあるかも・・・と思ってしまいます。 &nbsp; 実際、本人も夏休みの自由研究と話してます。 &nbsp; それがまさかの380万、きっかけはアメリカの人気DJの方が購入し拡散したことで落札数が一気に増え値段が跳ね上がったそうです。本当に何が起こるかわからないですよね。

その1：購入・売買することで投資用として利用が可能

これは上記でも述べましたね。 &nbsp; ただ投資用としての利用は結構なハイリスクです。アートの価値を見極めるのは精通してないと難しいですし、それを大量にある中から探すとなるとかなり上級者向けのテクニックが必要になります。 &nbsp; 予算がある場合は、有名なイラストレターさんなどに的を絞って購入→売却すれば金銭的なリターンを得られるかなと思います。

その2：改ざん出来ないデータにすることで無価値なものを価値あるものに変えることが可能

Twitter創業者のように一見何の価値がないように見えるものも、価値を付けることが出来ます。 &nbsp; Axie InfinityというゲームではキャラクターをNFT化して売買がされています。高額なものでは1000万以上のものもあります。 ゲーム内とは言え、欲しい人はそれだけのお金を出しますし、そのキャラを持ってるだけで周りとの差別化を図れるので間違いなく価値あるものになります。 &nbsp; こうしてデジタルで価値をつけずらかったものにも価値がつけられるようになります。

その3：今後多種多様な分野・業界に影響を与える可能性がある

NFTの市場規模は数兆円になっているので、今度どの業界にどう影響を与えるか未知のところがあります。2022年も市場規模は拡大していきますし、メタバースとの兼ね合いで、よりデジタルデータの価値は上がっていくでしょう。下手したら1人1個、NFTを所持する時代も来るかもしれません。

その1：作ったとしても現状膨大な数なので売れるとは限らない

作った方が儲けるじゃん！と思うかもしれませんが、同じように考える人は沢山います。その中で自分のイラストが売れるのは確率としては低いかもしれません。なので、イラストを描いて売って儲けるぞ！と思っている場合は売れない可能性や時間がかかることを視野に入れておきましょう。

その2：まだ知らない人も多く、購入してもその価値を理解できない人が多い

仮にNFTを購入して友達に見せてみましょう。分かる人が見たら「おっ！」と思いますが、まだまだ認知度が低いので、その価値を分かる人が少ないのが現状です。（日本での認知度は3割ほど） とは言え、メリットでもお話ししたNFT市場は拡大する一方なので持つことで損はないと思います。理解できな人がいてもへこまないようにしましょう。

その3：偽物を買う可能性もある

NFTは偽物の見極め方が非常に難しく、詐欺も横行していると言います。 &nbsp; 例えば有名な方のイラストをコピーして売るといったのがあったり、海外のNFTマーケットをみたら偽サイトだったなど、まだまだ法整備がされてないが故にこういったリスクもあります。購入する際は、出品者が本当に当人か確認することやサイトについてはしっかりググって本物か確かめるなど、慎重になった方が良いと思います。 &nbsp; ただ、サイトについては今後解説していきますが海外の場合は「opensea」が一番シェア率も高く間違いないです。

まとめ：発展途上ではあるけど参入する価値のある市場！

いかがだったでしょうか。 &nbsp; 正直、日本での認知度が低いので持っても「何それ？」となりやすいですが世界規模でみると市場規模は数兆円でまだまだ伸びしろがある業界なので興味本位で触れてみる価値はあります。何気なく買ったイラストに価値がつくことや、自分の作ったイラストに価値がつくこともあり得るので興味本位で触れてみるのも良いと思います！ &nbsp; そして何よりNFTを楽しんでみてください！

今まさに！トレンドのNFTって何？三分で解説！！

皆さんは、プロジェクトでなんのプログラミング言語を使用していますか？ &nbsp; 最近では、Flutterと呼ばれる言語が出てきていたり、Rubyを使用されることが多くなってきたりと、色々な言語で溢れていますね。 &nbsp; そこで、何の言語を勉強したら良いだろう？と思われる方も多いと思いますので、この企画では、プログラミング言語の紹介や、業界毎に利用頻度が高い言語のご紹介をさせていただきます。 &nbsp; まずは、ver1として、私が一番長い間経験した「金融業界」で利用頻度が高い言語になります。 &nbsp; ぜひ、プログラミングについて理解を深めたい方は、ぜひご覧ください。

金融業界で利用頻度が高い言語

さて、皆さんは金融業界ではどんな言語が利用されていると思いますか？ 最先端の言語が利用されている？ それとも、古い言語が利用されている？ &nbsp; 金融業界では、「古い言語」が利用されています！ 金融業界は、お金を管理するシステムが多いため、リスクになることを避ける傾向にあります。 逆を言えば、リスクを避けるために、今まで経験したことを好む傾向にあります。 &nbsp; その為、昔から利用している言語を利用してプログラミングされています。 &nbsp; では、金融業界は、昔から何の言語を利用していたのでしょうか？ &nbsp; 代表的なものは、 ①&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ＣＯＢＯＬ ②&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ＰＬ１ ③&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ＪＡＶＡ ④&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ｆｌｅｘ（Ａｃｔｉｏｎ　Ｓｃｒｉｐｔ） ⑤&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ＪＰ１ ⑥&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ｓｈｅｌｌ ⑦&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ＭＳ－ＤＯＳ（バッチスクリプト） です。 &nbsp; そして、近年では、金融業界としては珍しく新しい言語を利用され始めています。 それが「ＲＰＡ」です。 &nbsp; 代表的な言語から最近利用され始めた言語まで、一つ一つ順番に説明していきます。

1959年に事務処理用に開発されたプログラミング言語です。 名称は「Common Business Oriented Language」（共通事務処理用言語）の頭文字をとっています。 当時は、アセンブラ（機械語）以外の方法でコンピュータを動かすという意味で高級言語と呼ばれていたこともありましたが、現在のように多種多様なプログラミング言語が存在している状況下では、それらモダンなプログラミング言語と比較すると、高級とは言い難くなってきています。 COBOLでは、Javaでは当たり前のように、コンパイルを行い、エラーを検知することができますが、COBOLではこのコンパイルでエラーにできるような機能は備えていないです。 では、一体どのようにコーディングするか見てみましょう。

では、まずはどのプログラミング言語でもコーディングする「変数」定義の仕方を見てみましょう

これは、６バイトを使用して６桁の正の整数を定義したことになります。 これのどこがデータ型を表すかわかりますか？ 見方としては、「ICOUNT」が変数名で、「９（６）」がデータ型です。 ＜データ型の一覧＞ 数値項目は↓の表を参照ください

文字列項目は↓の表を参照ください。

COBOLではいくつかの変数を１つのグループにまとめて扱うことができます。 以下のコードでは２つの集団項目を定義しています。

GROUP01は２つの文字列型変数（STR1,STR2）を内包し、GROUP02は２つの数値型変数（NUM1,NUM2）を内包しています。 ２つの集団項目間でデータの転記（転写）を行うこともでき、以下がそのコード例です。

このコーディングをすることで、GROUP01→GROUP02への転記を行うことができます。 ここで一つ気づくことはないでしょうか？ これに気づくことができた人は、プログラミングの才能があります！ そうなんです。GROUP01、GROUP02でデータ型が異なっています。 前段でご説明した通り、GROUP01は文字列型で、GROUP02は数値型です。 このように、COBOLでは、データ型が異なる変数同士で転記ができてしまい、コンパイルがないため、このデータ型の考慮は、プログラマーが気にする必要があります。

COBOLでは、変数を複製する際には、COPY文を使用します。

これは、指定されたファイルをこの行に展開することを表しています。 このコーディングをすることで、同じファイルや、変数が利用できるようになります。

COBOLでは、他のプログラムを呼び出す際には、CALL文を使用します。 呼び出し側と、呼び出される側の間でデータの受け渡し行う場合、それらの構造は同じでなければなりません。COBOLでデータ受け渡し用の集団項目を定義する場合、以下のようになります。 呼び出し側

この場合DATE1は型を宣言していると同時に、変数も宣言していることになります。 呼び出される側

COBOLのプログラム呼び出しは、型安全な機構によりサポートされている訳ではなく、あくまでも、アドレス渡しで呼び出しが行われています。

いかがでしたでしょうか？ まずは金融業界の基幹部分で利用されているCOBOLの説明でした。 ＪＡＶＡなどの言語を普段から利用されている人にとっては、なじみのないコーディングの仕方だったと思うので、少し新鮮だったのではないでしょうか？ &nbsp; ただ、ご紹介はしましたが、昔からあるシステムでしか利用していないので、これからこの言語の勉強を始めるのは、あまりお勧めはしていません。 昔はこういう言語を利用していたんだ。というイメージでいていただければなと。 &nbsp; さて、次回からは、２～３つの言語を一気に紹介していこうと思います。 &nbsp; 金融業界にお勤めの方や、金融業界のシステムを構築してみたい方は、ぜひこの企画を見て勉強してみてくださいね。 &nbsp; では、また次の記事でお会いしましょう！

長く金融業界の案件を経験したエンジニアが説く！！金融業界で利用されるプログラミング言語Ⅰ

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

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


今回は、2018年12月にGoogleが発表したモバイルアプリ専用のフレームワークである、flutterをご紹介します。

FlutterとはGoogleによって開発されたフリーかつ、オープンソースのUI(ユーザーインターフェース)ソフトウェア開発キットです。 通常、モバイルアプリ開発を行う際、Androidアプリ開発の場合は「Kotlin」、iOSアプリ開発の場合は「Swift」をそれぞれ使用する「ネイティブアプリ」が一般的ですが、flutterの場合、一度の開発工程であらゆるOSが対応可能となる「クロスプラットフォーム(別名：マルチプラットフォーム)」であることから、開発期間やコストを削減が可能となる点が注目されています。

まずはflutterで重要な役割を持つDartについて説明します。 Dartは2011年にGoogleが設計したプログラミング言語です。 Dartが注目される理由の一つとして、広く一般的に使われているプログラミング言語であるJavaScriptに似ていて、扱いやすい言語であることが挙げられます。 JavaScriptは、モバイルアプリケーションをはじめ、Webアプリケーション、サーバーサイドアプリケーション、デスクトップ開発に適応した、世界的に人気の高いプログラミング言語です。 そんなJavaScript を大替したDartは、JavaScriptよりさらにセキュリティ面が強化されたことや大規模な開発にも対応するなど、JavaScriptの問題点を改善し、開発されたことでJavaScriptに代わるプログラミング言語として注目されています。

React Native(リアクトネイティブ)

ここではflutterと度々比較されるReact Nativeについても説明しておきましょう。React Nativeはfacebookが開発を手がけたオープンソース型のモバイルアプリケーションフレームワークです。 React Nativeはflutterと開発環境が似ていることから、flutterに携わる人は耳にしたことがあるかもしれません。 理由の一つに、React NativeはJavaScript を開発言語とし、flutterと同様にiOS・Android問わず、実装可能であることが挙げられます。 開発アプリにはfacebookやUberEatsなど、日本でも広く普及しているアプリがあります。 ここで細かな違いは明記しませんが、実際に実働してみた違いなど、気になる人は調べてみると良いでしょう。

ここからはflutterを使用することでのメリットをお伝えします。

①	JavaScriptにコードが似ていて取得しやすい

先ほどもお伝えした通り、flutterのプログラミング言語にはDartを使用しています。Dartは世界的に人気の高いJavaScriptをベースに開発されており、JavaScriptよりもコードが簡単なことから、Dartをはじめて使用してプログラミングを行う際に取得しやすいというメリットが挙げられます。

②	ホットリロード機能が備わっている

Flutterにはプログラムの変更を瞬時に行う「ホットリロード」機能が備わっています。この機能によりJavaScript を用いた場合、時間がかかっていた確認作業がDartを用いたflutterなら、瞬時に行うことができるというメリットが挙げられます。 これにより、大幅な開発時間の短縮に繋がることが注目されています。

③	フリーかつオープンソースであること

Flutterはフリーかつオープンソースであるため、誰もが無料で使用することが可能です。 通常、開発には時間と費用がかかることが問題視されがちですが、こちらのflutterなら問題を一気に解決することができるので、開発側としては大きなメリットと言えます。

④	UIデザインをプラットフォームに依存することなく使用可能

FlutterはGoogleが提唱した「マテリアルデザイン」を採用していることから、ユーザーはスマートフォンやタブレットなどのデバイスを使用する際、デバイスが変わったとしても、統一感のあるデザイン上で、ストレスなく操作することが可能です。

⑤	iOS、AndroidなどOSを気にすることなく一気に開発が可能

最後にご紹介するメリットがflutterを活用する最大のメリットと言えるでしょう。通常、モバイルアプリを開発する際、OSごとに専門のアプリを開発する必要がありますが、flutterを活用すれば、そういった手間が省けるため、開発時間や費用の大幅な削減が期待されています。

ここからはflutterのデメリットもご紹介します。

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

意外にちゃんとは知らないPMOとは？PMOの実務経験8年のエンジニアが解説します！

今まさに！トレンドのNFTって何？三分で解説！！

長く金融業界の案件を経験したエンジニアが説く！！金融業界で利用されるプログラミング言語Ⅰ

Flutterって実際どうなの！？メリット・デメリット、導入事例も一挙公開！

Swiftって？iOSのアプリ開発で注目されているAppleのプログラミング言語を徹底解説！

Googleが公式サポート！！Kotlinって？サクッと解説！

おすすめ記事

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

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

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

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

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