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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なっしー（岩瀬　勝義）

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

Wi-Fi6とは2019年9月からスタートした第6世代のWi-Fi規格のことを指します。以前の規格であるWi-Fi5は2014年にスタートしたものなので実に5年ぶりに登場した新たな規格です。規格が新しくなるにつれて利用する側にとっては通信速度が高速になり、より便利になったといえるでしょう。 &nbsp; Wi-Fi6の開発は2013年から始まりました。 スマートフォン、家電製品、IoTデバイスなどWi-Fiに接続する機器が増加したことで干渉やパフォーマンスの低下が起きていました。旧規格の機器と最新の機器を効率的にWi-Fiに接続できるようにすることが目的で開発されました。

Wi-Fi6は今までのWi-Fiと比べて「高速」「混雑に強い」「省エネ」という3つの特長が挙げられます。 &nbsp; 次にそれぞれの特長を見ていきます。

Wi-Fi 6は旧規格のWi-Fi5を超えるパフォーマンスで理論上の最大通信速度が9.6Gbpsとなっており、Wi-Fi5の6.9Gbpsと比べると大幅に速度が上がっています。Wi-Fiは2.4GHz・5GHz、2つの周波数帯を利用していますが旧規格のWi-Fi5まではどちらか一方の周波数帯でしか通信の処理ができませんでした。Wi-Fi6では両方の周波数帯を利用できるので2.4GHz・5GHzの電波を状況に応じて使い分けることが可能となり高速化が可能になっています。また両方の周波数帯を利用することで高速化だけでなく通信の安定性が向上しています。

旧規格のWi-Fi5までは同時に多くの機器を接続していると速度が遅いと感じたり、つながりにくいといった問題が起こっていました。これは直交周波数分割多重方式（OFDM）と呼ばれる技術の仕様上、通信処理の順番待ちが発生し、複数機器の接続を同時に処理できないことが原因でした。Wi-Fi6では直交周波数分割多元接続（OFDMA）という技術が使われており、複数機器の接続を同時に処理できるようになりました。 &nbsp; Wi-Fi 6は、直交周波数分割多重方式（OFDM）と直交周波数分割多元接続（OFDMA）の2つの変調方式を組み合わせて使用​​します。これはデータの転送用としてOFDMAを利用し、OFDMはレガシーデバイスとの下位互換性を維持するためと管理および制御フレームとしてWi-Fi6で引き続き使用されています。下記のイメージのようにWi-Fiの通信はサブキャリアまたはトーンと呼ばれる小さなチャネルで構成されています。 &nbsp; OFDMのイメージ

引用元：<a href="https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wi-Fi_6_(802.11ax)_Technical_Guide" target="_blank" rel="noopener noreferrer">https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wi-Fi_6_(802.11ax)_Technical_Guide</a> &nbsp; OFDMAのイメージ

引用元：<a href="https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wi-Fi_6_(802.11ax)_Technical_Guide" target="_blank" rel="noopener noreferrer">https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wi-Fi_6_(802.11ax)_Technical_Guide</a>

Wi-Fi6には「Target Wake Time」（TWT）という機能が搭載されており以前に比べると省エネ化が可能になりました。アクセスポイントと端末がネゴシエーションをすることで通信を行うタイミングをあらかじめ決めておきそのタイミングで通信します。そうすることで端末はアクセスポイントからの信号を常に受信する必要がなくなり必要な時間だけ通信機能をONにすることで帯域幅の消費と端末のバッテリー消費を抑えることできます。

Wi-Fi6では上記に加え高密度環境での利用を可能にするために「MU-MIMO（Multi User MIMO）」や「BSSカラーリング」という技術が使われています。 以下それぞれについて説明していきます。

・MU-MIMO（Multi User MIMO） 一つのチャネル内で1対多数の通信を実現する技術です。通信時に利用するアンテナの数を「ストリーム」と呼びます。例えば、「4×4」や「3×3」などの数字が書かれていることが多いです。この数字が、ストリーム数（アンテナ数）を表しています。Wi-Fi6ではWi-Fi5の4 x 4 MIMOから8 x 8 MIMOにMU-MIMO技術が拡張されています。下図のようにストリームの数だけアクセスポイントと端末間をアップリンクとダウンリンクで通信できるようになります。

・BSSカラーリング Wi-Fi5までは隣接するアクセスポイント同士で利用チャネルが重複している場合に隣のアクセスポイントで通信があった場合に混雑と判断され通信速度の遅延が発生していました。 これを解決した技術がBSSカラーリングです。下図のようにBSSカラーリングの技術によって利用チャネルが重複していても通信の管理フレームに色付けがされ、色ごとの通信と判断されるようになります。

Wi-Fi6はこれまで説明してきたように様々な機能の実装によってより良い無線環境の構築が可能になりました。しかしアクセスポイントとアクセスポイントに接続する端末がWi-Fi6に対応していないとその恩恵を受けることができませんので注意してください。利用する際は端末側の仕様についても必ず確認するようにすべきです。

2017年から2022年までのインターネットトラフィックの合計量は、過去32年間よりも多くなると予想されており、Wi-Fiはそのトラフィックの半分以上で利用されています。 またスマートフォン1台あたりのデータトラフィックは、2016年から2022年にかけて10倍になると予想されています。Wi-Fiに接続する端末の数、高いスループット値が要件のアプリケーションなどが増加傾向にあります。 帯域幅を大量に消費する4Kビデオは、2017年の全IPトラフィックの3％から2022年には22％に増加すると予想されます。4Kビデオの場合、15〜18 Mbpsの高いスループットを使用します。8Kストリーミングビデオは約1Gbpsのスループットを使用します。 拡張VRアプリケーションの使用も増加しており、600Mbpsから1Gbps使用します。 これらの新しい帯域幅の課題には、世界中のWi-Fi接続の速度改善が更に必要になります。 このような経緯があるので今後Wi-Fiの重要性はますます高まることでしょう。 またWi-Fi6EというWi-Fi6の拡張版のような規格も登場し今後、日本でも承認される見通しは大いにあると思います。Wi-Fiは今後も私たちの生活に関わってくる重要な技術だと思うので最新の情報には常に知っておく必要があるでしょう。

【専門家が解説】知っておきたいWi-Fi６の特徴・メリット3選

安部　真浩

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

Webの開発において、Webフレームワークは必要不可欠となってきていると思います。 新規でプロジェクトを立ち上げる際、技術選定として、数多くのプログラム言語もあり、多くのWebアプリケーションフレームワークも存在しています。 今回はPythonのWebフレームワークのDjangoを紹介したいと思います。

DjangoというWebフレームワークに関して

DjangoはPythonのWebアプリケーションフレームワークであり「ジャンゴ」と読みます。 最初の文字の「D」は発音しません。 PythonにはDjangoの他にもFlask(フラスク)があります。 DjangoとFlaskの違いについてですが Django → フルスタックで多くの機能が備わっている(大規模な開発向け) Flask&nbsp;&nbsp;→ 最小限の機能を備えている(小規模な開発向け) &nbsp; Djangoは多くの機能が備わっており、ライブラリも豊富です。 また拡張するライブラリもありますので、Djangoを取り入れれば大人数の開発でもスムーズに進むことができるのではないでしょうか。 &nbsp; YoutubeやGoogle、Instagramなど有名なWebサービスも実はDjangoから作成されているものになります。

では簡単にはなりますが、Djangoの新規プロジェクト作成を行います。 ※開発環境(動作はMac環境を使用しています。)

OS: MacOS Big Sur 11.4 Python: 3.9.7 Django: 3.1.7 IDE: PyCharm

Pycharmを起動して、左下の「terminal」をクリック(Macのデスクトップの右上の虫眼鏡マークから「ターミナル」起動→指定した階層に移動でも構いません) Djangoのバージョン確認のため、以下のコマンドを入力 python -m django --version

画面のように、「3.1.7」のようにバージョンが表示されれば、Djangoの環境はインストール済みです。 もし「No module named django」などエラーが表示される場合は、環境設定を見直してください。 &nbsp; 問題なければプロジェクトを作成します。以下のコマンドをターミナルに入力して下さい。 django-admin startproject sample_django &nbsp;

その後「ls」コマンドにて、作成したプロジェクト名のディレクトリが存在することを確認します。

新規でDjangoのプロジェクトを作成するコマンドは django-admin startproject {作成したいプロジェクト名} 今回の場合、sample_djangoという名前のプロジェクト名で作成をしました。 別名でプロジェクトを作成したい場合はsample_djangoの箇所を書き換えて下さい。 &nbsp; では今回作成したsample_djnagoの中身を見ていきたいと思います。 &nbsp; ターミナルにて以下のコマンドを入力して下さい。 cd sample_django ls sample_django &nbsp;

startprojectコマンドで以下の階層のファイルが作成されています。 sample_django/ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;manage.py &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sample_django/ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;__init__.py &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;asgi.py &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;settings.py &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;urls.py &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;wsgi.py

こちらのファイルについての簡単な解説ですが、 外側のsample_django/ 一番外側のsample_djangoはルートディレクトリのコンテナで任意の名前に変更できます。 &nbsp; manage.py プロジェクトに対して色々な操作を行うためのコマンドラインユーティリティです。 編集する機会はあまりないと思います。 &nbsp; 内側のsample_django/ プロジェクトの実際のPythonパッケージで他のディレクトリからimportで使用する名前になります。(import sample_django.urlsなど) &nbsp; sample_django/__init__.py ディレクトリがPythonであることを表すためのファイルです。こちらも編集することはないと思います。 &nbsp; sample_django/settings.py Djangoに対して設定ファイルです。環境変数やDBの設定、Vue.JSやReactの連携するために編集することがあります。 &nbsp; sample_django/urls.py ルーティングの設定のために編集します。 Djangoの初期設定ではWebサーバ起動後、localhost:8000でトップページに移動しますが、 こちらに記述することにより、「localhost:8000/」以降のHTTPリクエストに対して、どのページをブラウザに表示するか記述します。 &nbsp; sample_django/asgi.py ASGI互換Webサーバのエントリーポイントで編集する機会は少ないと思います。 &nbsp; sample_django/wsgi.py WSGI互換Webサーバーのエントリーポイントでこちらも編集する機会は少ないと思います。

では実際に外側のsample_djangoに移動して、Webサーバーを起動してみましょう。 以下のコマンドを実行して下さい。 python manage.py runserver &nbsp;

runserver起動時に、以下のマイグレーションのエラーが表示されていますが、画面表示の動作確認だけなので、一旦無視して進めます。 &nbsp; &nbsp; &nbsp; その後、Webブラウザ(chormeなど)で以下にアクセスして下さい。 http://127.0.0.1:8000/ ※PyCharmのターミナルからでもアクセス可能です。 &nbsp;

ブラウザにて、以下のようなロケットの画面が表示されていれば成功です。

では次はHello Worldを表示をさせてみましょう。 起動中のWebサーバーを一旦停止させて下さい。 ターミナル上でControl + Cで停止します。

manage.pyと同じ階層にアプリケーションの作成をします。 以下のコマンドを実行して下さい。 python manage.py startapp hello_world &nbsp;

コマンド入力したら、作成したアプリケーションが作成されているかlsコマンドで確認をします。

こちらのコマンドの説明ですが python manage.py startapp {作成したいアプリケーション名} 今回の場合は、hello_worldとしましたが、作成したいアプリケーション名に合わせて変更をして下さい。 &nbsp; PyCharmの左ペインからhello_world/views.pyを開いて以下の記載を入れて下さい。 views.py <pre><code>from django.http import HttpResponse



def index(request):

&nbsp;&nbsp;&nbsp; return HttpResponse("Hello_world")</code></pre>&nbsp; &nbsp;

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

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

【専門家が解説】知っておきたいWi-Fi６の特徴・メリット3選

PythonのWebフレームワーク『Django』の紹介

Rakuten Rapid APIのご紹介

AWS SDK for JavaScript v3のアップデート概要と、旧バージョンからの書き換え

Railsのファットコントローラー 3つの対処法

おすすめ記事

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

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

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

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

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

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

【専門家が解説】知っておきたいWi-Fi６の特徴・メリット3選

PythonのWebフレームワーク 『Django』 の紹介

Rakuten Rapid APIのご紹介

AWS SDK for JavaScript v3のアップデート概要と、旧バージョンからの書き換え

Railsのファットコントローラー 3つの対処法

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

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

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

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

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

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

PythonのWebフレームワーク『Django』の紹介

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