今回は、システムエンジニアやプロジェクトマネージャーなど、クライアントと直接会話する立場のエンジニアであれば、一度は耳にしたことがある、“クライアントからの迷惑な一言”とその対処法について、まとめてみました。 現在、直接的にはクライアントと関わることはない立場の方も、今後、キャリアップ・スキルアップに伴って、クライアントと直接かかわることも出てくるので、知識として知っておいていただきたい内容になっています。 テクフリでフリーランス案件を探してみる いい感じで 『いい感じで』という言葉は、本当に取り扱い注意です。 なぜか？ それは単純に、「なにを持って“いい感じ”とするか、クライアントとエンジニアの間で認識があっているか、保証がない」という点です。もっと言ってしまえば、エンジニアの感覚で、『いい感じで』作ったシステムがクライアントにとっての『いい感じ』のシステムなのか、誰にもわからない、ということです。 そして、『いい感じで』の基準が明確に共有されていなかった結果、本当にクライアントが求めていたものと異なる機能を開発してしまったために、再開発(手戻り)になったり、納品拒否されるなど、“失敗プロジェクト”になってしまうことも少なくありません。 クライアント担当者から『いい感じで』という言葉が飛び出したら、なにをもって『いい感じ』とするか、しっかりとヒアリングして“要件定義”をしましょう。また、要件定義ができた後は、ちょっとしたことでも、メールや議事録などで良いので、後から「クライアント・エンジニア双方が、どのような内容で合意したか？」を確認できる形で記録を残しておきましょう。 なぜ、そこまでするかというと、『いい感じで』という言葉を発するクライアント担当者は“システム開発がわかっていない人”であることが多いからです。 実際、私が相対した、『いい感じで』をやたらと使うクライアント担当者さんは、機能要件・非機能要件という言葉も知りませんでした。知識がないために、うまく要求事項をまとめられず、『いい感じで』を連呼していたというわけです。 そして、『いい感じで』を多用するシステム開発が分かっていないクライアント担当者は、この後紹介する、『なるはやで』、『思ったより工数かかるんだね』『頼んだじゃん！』もよく使う傾向にあるため、慎重に扱った方が良いことが多いのです。 なるはやで 日本では『なるはやで』という言葉が好きな人が多い気がします。「そちらの予定次第で良いですよ」というニュアンスが含まれていて、一見、親切な言葉に見えます。しかし、ビジネスの世界では使ってはいけない言葉です。 なぜならば、『なるはやで』では、いつまでにやってほしいのかが分からないからです。仕事である以上、納期や、ターゲットとなる時期があるはずなのに、それが隠されてしまいます。 私自身、『なるはやで』という言葉で、痛い目に合いかけたことがあります。 「急いでいる訳ではないんですけど、なるはやでネットワーク作業をお願いします」とクライアントから月次会議で伝えられて、“今期中のどこか手隙のタイミングで対応すれば良いか”と考えていたのですが、翌月「健史郎さんのネットワーク作業待ちなんですけど、まだですか？」と催促されたのです。 よくよく聞いていくと、私の対応は、クライアント会社内部で行われた監査に関連したものであり、クライアント社内で「何月何日までに対応完了予定」と会社の上層部にも情宣されている、ということでした。そして、その期限が、催促を受けた月の月末最終営業日だったのです。 このときは催促がきっかけになって納期の確認ができて、問題が起きませんでしたが、危うく「ネットワーク担当の健史郎というエンジニアがスケジュールを守っていない」という話になるところでした。 そのような事態にならないためにも『なるはやで』と言われた場合は、クライアントの担当者と相談して、「いつまでに行うべきか？」を明確にしましょう。 なお、「いつまでに行うべきか？」を相談すると、システム開発が分かっていないクライアント担当者は、その作業の手間や準備期間、さらには後続作業との関連性が見えておらず、非現実的なスケジュールを提示してくることも少なくありません。 こうしたクライアント担当者を逆にコントロールして、現実的なスケジュールをくみ上げていく手腕も上流工程を行うエンジニアには重要です。 思ったより工数かかるんだね 『なるはやで』と同じで、作業の手間や準備期間、さらには後続作業との関連性が見えてないこともあり、思った以上にお金やスケジュールがかかる、という不満を漏らすクライアントも多いです。 結局、クライアント担当者はシステム開発を発注する側、つまり買う側です。より安く、より早く納品してもらった方が嬉しいですし、その観点でしか見積書や請求書を見ない、あいは、その観点でしか評価する能力がないクライアント担当者も多いのです。 さらに言えば、日本ではIT投資はコストという風潮が強く、安ければ安いほど良い、と考える経営者が多いです。そして、IT企業側も人件費(つまりエンジニアの報酬)を圧縮するなどしながら、価格競争をしている状況です。 “適正価格”というか“相場”があってないような状況にあるのが、ITビジネスの現実です。 私の場合、『思ったより工数かかるんだね』と言われたときは、工数の見積もり根拠を説明するようにしています。「このリンクをクリックしたら、この画面が立ち上がるようにしたい、というお話ですが、これを実現するためには、この画面を作るだけではなく、DBにも手を加えます。なぜならば……」といった風に。 そもそもシステム開発が分かっておらず『思ったより工数かかるんだね』と言ったクライアントは、たいていの場合、これで納得してくれます。 たまに、どこぞかで知識を仕入れてきて「もっと安くできるはずだ」とおっしゃるクライアント担当者もいます。そういう方に対しては、管理工数や実績などを絡めながら「安かろう、悪かろうですよ」という趣旨のお話をすることもあります。 頼んだじゃん！（ 完成したものを見せたら、頼んでいた機能がないとか、思っていたのと違うものが出てきた、と文句を言うクライアント、やっぱりいます。 こういう事態になるのは、『いい感じで』としか言われなかったせいで、ボタンを掛け違ったまま開発を進めていた、というのもありますが、「クライアントが開発スコープを分かっていない」というのもあります。 開発スコープ、つまり、どんなものをいつまでに開発するかは、要件定義で検討され、実装することが確定した機能についてのみ、要件定義書などで明文化されるのが通常です。逆に言えば、検討されたものの、要件定義書などのドキュメントに記載のないものは開発する必要はありません。もっと正確に言えば、開発してはなりません。 ところが、検討した記憶が残っているクライアント担当者の上席にあたる方などから「あれも欲しかったのに」と言われるパターンが一番多いです。 その場合の対応法は、要件定義書などのドキュメントを再確認するようにしています。そして、「スコープ外となったため開発していないんですよ」と説明し、納得してもらうようにしています。 まとめ：クライアント担当者は基本的にはエンジニアではない 結局のところ、クライアント担当者はエンジニアではないため、システム開発やシステム作業について、正しい知識を身に着けている、という期待は持ってはいけません。 分かっていない人、あるいは分かっている風だけど変な知識を持っている扱いが難しいクライアント担当者をうまくコントロールする技術も、ある意味、エンジニアが出世するのに必須となるスキルです。 テクフリでフリーランス案件を探してみる

SQL(エスキューエル)とは？ SQL(エスキューエル)とはデータベースを操作・定義するためのプログラミング言語です。SQL(エスキューエル)を使えると、データの取得・更新・削除・追加などをすることができ、データベースにあるデータを簡単に処理できるようになります。 他のプログラミング言語と併用して使う場面が多く、ほとんどのアプリケーションがデータベースとやり取りをすることでデータを表示しているので、皆さんがお使いのスマートフォンアプリやWebサービスの裏ではSQL(エスキューエル)が利用されています。 例えば、何かECサイトで物を買うときに氏名や住所などを入力すると思いますが、そういった情報が企業のデータベースに保存され、企業側は個人情報としてそのデータを取り扱います。このようにSQL(エスキューエル)は日々皆さんが使っているシステムの裏で使われています。 SQL(エスキューエル)の中で一番使われているものがMYSQLです。様々なSQL(エスキューエル)アプリケーションの中でも高速で大量のデータを処理してくれ、オープンソースなので皆さん無料で使えるため多くの企業・個人が利用しています。最近ではビッグデータ処理に適しているNoSQLが流行るなどSQL(エスキューエル)は日々進化しています。 SQLの案件を探す SQL(エスキューエル)が誕生したきっかけは？ SQL(エスキューエル)が誕生したきっかけについて見ていきましょう。SQL(エスキューエル)のきっかけとなった出来事が1970年代にあります。 この頃に、IBMのSanJose 研究所 （現 Almaden 研究所）がSystem Rという世界初となるRDBMS（リレーショナルデータベース管理システム）を開発しました。そこで、リレーショナルデータベースを管理するためのプログラミング言語SEQUEL（Structured English Query Language）が登場しました。 SQL(エスキューエル)の前身となったSEQUEL（Structured English Query Language）はSQL(エスキューエル)と同じくデータベースを操作・定義するためのプログラミング言語ですが、この後改良が何度もされ、今のSQL(エスキューエル)になっています。 SQL(エスキューエル)はシークェルと呼びますが、この呼び方もSEQUEL（Structured English Query Language）の呼び方から来ています。名前自体は何度も変わり、最終的にSQLになりましたが、呼び方は変わっていません。SQL(エスキューエル)という名前が何の略なのか気になる方もいらっしゃると思いますが、国際基準ではSQL(エスキューエル)が何かの略語ではないとされています。 SEQUEL（Structured English Query Language）という名前からコードを書いてQuery（問い合わせ）をリレーショナルデータベースにできる言語だとわかります。実際のQuery（問い合わせ）の結果はモニターに表示され、ここはSQL(エスキューエル)と変わりません。 この画期的なSEQUEL（Structured English Query Language）の登場からSQL(エスキューエル)が黎明期・成長期となり有名になっていきます。 SQL(エスキューエル)の黎明期・成長期について 続いてSQL(エスキューエル)の黎明期・成長期についてです。画期的なSEQUEL（Structured English Query Language）の登場からその後どのようにして多くの人々に使われるようになったのか見ていきます。 SEQUEL（Structured English Query Language）は1976年にSEQUEL2として新しいバージョンがリリースされることになりますが、SEQUEL2で商標登録をしている企業が他にあったため、SQL(エスキューエル)と改名されました。これが現在のSQL(エスキューエル)と同じものです。 このリレーショナルデータベースの操作・定義ができるSQL(エスキューエル)は操作性が非常に優れていると評価を受け、リレーショナルデータベースを操作するための言語として標準になりました。実際にSQL(エスキューエル)の仕様に合わせた製品が様々な企業から発売されることになりました。 その後にISO（International Organization for Standardization）やJIS（Japanese Industrial Standards）に規格化され、その後からSQL(エスキューエル)はかなり普及することになります。実際に、リレーショナルデータベースが使われている製品が多く登場することになりました。 SQL87,SQL89, SQL92, SQL99といったように1980年代から90年代にかけてバージョンアップしたSQL(エスキューエル)が次々とリリースされました。 SQL87は既に製品化されていた多くのリレーショナルデータベースを操作するためのSQL(エスキューエル)の中でも共通する最小限の部分を取り出したシンプルなSQL(エスキューエル)となっています。その後のSQL89では外部のキーリレーションシップを適用するためのメカニズムが実装されました。 SQL92では動的SQL(エスキューエル)や埋め込みSQL(エスキューエル)などの機能がリリースされ、より柔軟性と機能性が増しました。SQL99ではオブジェクト指向やJavaを取り入れたものとなり、SQL(エスキューエル)でのプログラミングがより拡張されました。 2000年代に入ると、SQL2003,SQL2008,SQL2011,SQL2016が新しくリリースされ、日々SQL(エスキューエル)の改善とバージョンアップがなされています。現在もデータベースとのやり取りと言えばSQL(エスキューエル)というように、SQL(エスキューエル)はリレーショナルデータベースとの’やり取りができるプログラミング言語と不動の地位を築いています。 SQL(エスキューエル)は現在どのように使われている？ SQL(エスキューエル)についてとSQL(エスキューエル)の歴史について見てきました。現在もSQL(エスキューエル)は不動の地位を築いているとのことですが、具体的にどのように使われているか見ていきます。 SQL(エスキューエル)は今までと変わらずにデータベースとのやり取りに使えますが、近年ビッグデータというキーワードがトレンドとなっているようにビジネスにおいてデータを使う機会が多くなっています。そこで、SQL(エスキューエル)を用いてデータの分析や加工を行う企業が増えています。 また、転職に関して言うとSQL(エスキューエル)の募集はデータベースエンジニアとしての募集が多く、データ分析基盤開発の案件が多くあります。SQL(エスキューエル)のみできれば採用するという求人は少なく、ほとんどがSQL(エスキューエル)以外にも他のプログラミング言語ができる必要があるとしています。 また、データサイエンティストとしての募集も多く、この場合に関してもPythonやRを触れるエンジニアでないと採用がされない場合がほとんどです。 データベースエンジニアやデータサイエンティストは今のトレンドとしてはホットなので多くの企業が募集しており、転職を一度考えて見ても良いかもしれません。 まとめ：比較的歴史の古い言語 今回はプログラミング言語であるSQL(エスキューエル)の歴史について見てきました。 SQL(エスキューエル)が誕生した背景やその後の歴史についてなかなか興味深い話が多かったでしょう。 今回の内容をまとめると SQL(エスキューエル)はデータベースの操作・定義などのやり取りができるプログラミング言語SQL(エスキューエル)は1970年代からある比較的歴史の古い言語であり、今もバージョンアップが続いているSQL(エスキューエル)はデータベースエンジニアの求人が多い となります。 プログラミング言語の歴史については様々な話があり、常に人々の手によって進化しています。SQL(エスキューエル)もその言語の一つで変化をしながらも従来の信頼度の高さは変わらずに、不動の地位になっています。 今回でSQL(エスキューエル)に興味を持った方はまずSQL(エスキューエル)を使ってみてください！ SQLについてよくある質問 SQLについて良くある質問を3つまとめました。 SQL(エスキューエル)とは？ SQL(エスキューエル)とはデータベースを操作・定義するためのプログラミング言語です。SQL(エスキューエル)を使えると、データの取得・更新・削除・追加などをすることができ、データベースにあるデータを簡単に処理できるようになります。 他のプログラミング言語と併用して使う場面が多く、ほとんどのアプリケーションがデータベースとやり取りをすることでデータを表示しているので、皆さんがお使いのスマートフォンアプリやWebサービスの裏ではSQL(エスキューエル)が利用されています。 SQL(エスキューエル)は現在どのように使われている？ SQL(エスキューエル)は今までと変わらずにデータベースとのやり取りに使われていますが、近年ではSQL(エスキューエル)を用いてビッグデータのようなデータの分析や加工を行う企業が増えています。 SQL(エスキューエル)の転職状況は？ SQL(エスキューエル)の募集はデータベースエンジニアとしての募集が多く、データ分析基盤開発の案件が多くあります。SQL(エスキューエル)のみできれば採用するという求人は少なく、他のプログラミング言語ができる必要があるとされています。 また、データサイエンティストとしての募集も多く、この場合に関してもPythonやRを触れるエンジニアでないと採用がされない場合がほとんどです。 フリーランス案件を探す 今だけ！登録で最大1,500円相当もらえるお仕事探しサービス「テクスカ」 「テクスカ」は、報酬をもらいながらお仕事探しができる新体験のスカウトサービスです。 【テクスカの4つの特徴】 1.面談するだけで、3,500円相当のAmazonギフトカードを獲得できます 2.優秀な貴方に仲間になってほしいと真に願うとっておきのスカウトが企業から届きます 3.貴方の経歴・スキルを見て正社員のオファーだけでなく副業オファーも届きます 4.転職意欲がなくとも自分のスキルが通用するか各社のCTOに評価してもらうチャンスがあります 忙しさのあまり、企業との新たな出会いを逃している… スパムのように届くスカウトメールにうんざりしている… 自分の市場価値がわからない… 社外の人からの評価が気になる… 副業の仕事が見つからない… そんなあなたにおすすめです！

Objective-C(オブジェクティブシー)とは Objective-CとはApple社のiOSアプリを開発するために使用するプログラミング言語です。ブラッド・コックスとトム・ラブらによって1983年にリリースされました。 Objective-Cは名前の通りオブジェクト指向言語で、C言語がベースとなっています。C言語はObjective-Cが誕生する10年前から存在しており、Objective-Cが誕生した同年にはC++も誕生しています。 また、C言語をベースにしながらも、Smalltalkというオブジェクトにメッセージを送るというアイデアを元に作られたプログラミング言語も取り入れています。Smalltalkは元祖オブジェクト指向言語と言われており、Objective-C以外にも様々な言語・環境のベースになっている大きな影響を与えた言語です。 Objective-C開発者によると、C言語のメモリ安全性と SmallTalk のスピードを混合した言語がObjective-Cと説いています。 またGithubではどの言語でプルリクエストがどれくらい行われているかということを公開しており、Objective-Cがどれくらい使われているのかがわかりますが、Objective-Cは15位となっており、トレンドとしても下がっています。 なぜObjective-Cの比率が下がっているかというと、Swiftの台頭が大きな理由として挙げられます。 SwiftとはObjective-Cと同じくApple社のiOSアプリを開発するために使用されるプログラミング言語です。2014のWWDC（Worldwide Developers Conference）で発表され、その後は進化を遂げてバージョンアップが続いています。 Apple社は「モダン」「安全」「高速」「インタラクティブ」をSwiftの大きな特徴として発表しました。Objective-CよりもSwiftの方が開発しやすいという理由でSwiftは多くの方に支持されています。 ただ、人によってはSwiftよりもObjective-Cの方が開発しやすいという方もおり、ここは好みが分かれるところです。 Swiftはマルチパラダイム、Objective-Cはオブジェクト指向とパラダイムを見ても大きく異なっており、構文の書き方も異なります。Swiftの方が柔軟に書ける・素早く開発ができる、Objective-Cの方が更新が少なく新たに覚えることが少ないなどそれぞれ使うメリットが異なります。 iOSアプリ開発において完全にObjective-CからSwiftに移行したというわけではなく、Objective-Cにも未だ強い人気は残っています。自分の好みでどちらかを選択すると良いでしょう。 Objective-Cの案件を探す Objective-C(オブジェクティブシー)が誕生したきっかけは？ Objective-Cはブラッド・コックスとトム・ラブらによって1983年にリリースされました。 当初はC言語をベースにしながらも、Smalltalk（オブジェクトにメッセージを送るというアイデアを元に作られたプログラミング言語）を取り入れることで、SmalltalkのスピードとC言語のメモリの安全性を取り入れる目的で開発されました。 Objective-Cという名前の通り、C言語とオブジェクトを混在させられるという意味で、かなり使いまわしが良い言語となっています。なぜ、このObjective-CとC言語の組み合わせなのかというと、当時はC言語の開発が進んでおり、またSmalltalkという世界初のオブジェクト指向言語が登場したからです。 その当時の流れを組んで、当時人気だったC言語とオブジェクト指向言語であるSmalltalkを組み合わせたプログラミング言語であるObjective-Cが登場しました。 この誕生した当時のObjective-Cは認知度も低く、多くのプログラミング言語の中にある埋もれてしまっている状態でした。 Objective-C(オブジェクティブシー)の黎明期・成長期について 続いてObjective-Cの黎明期・成長期についてです。Objective-Cは誕生した当時の認知度の低い状態からいったいなぜ有名になれたのでしょうか。 この背景には皆さんがお使いのiPhoneやMacbookを販売しているAppleの存在があります。スティーブ・ジョブズがAppleを追いやられた後にNeXT社というコンピューターの製造販売を行う会社を立ち上げました。ジョブズはこの際に開発言語としてObjective-Cを選定しました。 具体的にはNeXTSTEPというObjective-CをベースにしたオペレーションシステムをNeXT社は開発したのですが、当時のオペレーションシステムでオブジェクト指向言語を採用することは非常に珍しく、ディズニー等の大企業にそのシステムが使われることになりました。 このNeXT社の成功はジョブズを追いやったApple社には無視できないものとなり、その後にNeXT社はAppleに買収されることになり、NeXT社のNeXTSTEPを元にしたオペレーションシステムであるMac OS Xが誕生しました。 この誕生はObjective-Cが誕生してから約20年後の出来事となり、このタイミングでObjective-Cは世間から注目されることになり、Macアプリの開発として開発者に使われることになり、その後の2007年にはObjective-C2.0の登場、2008年にはiOSアプリ開発言語に採用され、多くの開発者に愛される言語になりました。 Objective-C(オブジェクティブシー)はアプリ開発に使用されている 現在、Objective-Cは主にMac OSのアプリ開発、iOSアプリ開発に使われています。皆さんも身近なところでObjective-Cで作られたアプリに触れているはずです。 最近だと、Swiftを用いたiOSアプリ開発が多いですが、依然Objective-Cで作られているiOSアプリもあります。 2017年では日本人スマホユーザーの68.6％がiPhoneを使っています。日本のApp Store利用は世界3位となっており、iOSアプリはかなり多くの人々に使われています。 転職で見ると、Webサービスをリリースしている企業もサービスのアプリ版を開発し始めるといった事例も多く、企業はこぞってiOSアプリを開発できるエンジニアを募集しています。また、既にリリースしているiOSアプリの改修や更新作業ができるエンジニアを募集している企業も多いです。 iOSアプリ開発では、基本的にSwiftとObjective-Cのどちらかが使われますが、求人比率としてはおおよそSwift：Objective-C＝1：2となっており、Objective-Cの求人は多いことがわかります。 まとめ 今回はプログラミング言語であるObjective-Cの歴史について見てきました。 Objective-Cが誕生した背景やその後の歴史についてなかなか興味深い話が多かったでしょう。 今回の内容をまとめると Objective-CはiOSアプリを開発するためのプログラミング言語 Objective-CはApple社に使われてから爆発的に伸びた Objective-Cはトレンドとして下がっているものの、求人は多い となります。 プログラミング言語の歴史については様々な話があり、常に人々の手によって進化しています。Objective-Cもその言語の一つで、変化をしながらも従来の信頼度の高さは変わらずに、不動の地位になっています。 今回でObjective-Cに興味を持った方はまずObjective-Cを使ってみてください！ フリーランス案件を探す

フリーランスの消費税とは？ フリーランスエンジニアにとっての消費税は、2023年2月現在では課税売上高が1,000万円以上になると支払いが義務づけられています。 そして、フリーランスに業務を依頼する企業も、フリーランスへの支払いに発生した消費税は、消費税の支払いから差し引いて計算することができます。 そのためフリーランスエンジニアとして課税売上高が1,000万円を越えない限り、消費税は特別意識する必要性がない税金でした。 実際に消費税が上がれば、企業による支払いに消費税も含まれるため、受け取る金額が増える案件も珍しくありません。 フリーランスエンジニアとして活動していて、消費税が上がったことによる痛みはあまり感じていない人の方が多いのではないでしょうか。 参考として、国税庁のホームページでは「納税義務の免除」として消費税の納税義務が免除される条件が提示されています。 フリーランスエンジニアなどの個人事業主の場合は、前年度ではなく前々年度の課税売上高が関係してくるところが注意点です。 参考：国税庁「納税義務の免除」 インボイス制度とは 前述の通り、これまで消費税はフリーランスエンジニアなどの個人事業主にとっては、課税売上高が1,000万円を超えた場合に限り関係してくるものでした。 しかしインボイス制度が開始すればその状況は一変します。 インボイス制度が開始されたら、仕入税額控除の要件を満たすための要件がこれまでとは大きく変わるからです。 インボイス制度の開始は「2023年10月1日」となっています。 ではインボイス制度が始まることによって具体的に何が変わるのでしょうか。 その内容について見ていきましょう。 免税事業者への消費税の支払いが仕入税額控除の要件外となる インボイス制度がスタートしていない2023年2月時点では、企業はフリーランスエンジニアなど個人事業主へ支払った消費税も法人に支払った消費税も、そのどちらも仕入税額控除として計上することができます。 そのため企業は、企業への発注もフリーランスへの発注も同じように仕入税額控除をすることができました。 ところがインボイス制度がスタートすれば、企業が仕入税額控除として計上できるのは企業など課税事業者との取引のみとなります。 企業が免税事業者であるフリーランスに支払いを行った場合、消費税が仕入税額控除として計上できなくなるのです。 そうなった時に影響が考えられるのが、企業によるフリーランスへの仕事依頼の躊躇です。 企業は利益を確保するため、消費税を仕入税額控除できる課税事業者との取引を優先することが予想できます。 免税事業者としてフリーランスで活動している場合、受注できる仕事が減る可能性が出てくるといえるでしょう。 もちろん抜きん出た才能があれば、免税事業者でも良質な案件を受注できる可能性はあります。 しかしフリーランスエンジニアとして案件の受注のしやすさを考えるなら、消費税の課税事業者になることへの検討も大切です。 課税事業者になるために必要な手続き では、免税事業者であるフリーランスが課税事業者になるためには、何をする必要があるのでしょうか。 それは「適格請求書発行事業者の登録申請書」と「消費税課税事業者申告届出書」を提出することです。 「適格請求書発行事業者の登録申請書」とは、課税事業者になるための申請書です。 そして「消費税課税事業者申告届出書」とは、免税事業者が消費税の課税事業者になるための届出書です。 フリーランスであり免税事業者である場合は、適格請求書発行事業者の登録申請書と消費税課税事業者申告届出書、それぞれの提出が必要となります。 ［手続名］適格請求書発行事業者の登録申請手続（国内事業者用）｜国税庁 ［手続名］消費税課税事業者届出手続（基準期間用）｜国税庁 適格請求書発行事業者の申請時期について 適格請求書発行事業者の登録申請は、すでに開始しています。 フリーランスとして2023年以降も活動の継続を考えているなら、制度がはじまる2023年10月よりも前に適格請求書発行事業者としての登録を検討しましょう。 インボイス制度によって予想される負担と問題 インボイス制度が始まった時に、フリーランスエンジニアに予想される負担と問題は二つあります。 一つ目の問題は、先に述べた通り免税事業者であるフリーランスエンジニアに発注した取引先企業が、仕入税額控除を適用できないことです。 仕入税額控除ができなければ、その金額は企業にとって損失となります。 そうなると他の仕入税額控除ができる企業や、フリーランスエンジニアに仕事を依頼する企業が増えることが予想できます。 企業は仕入税額控除ができないフリーランスに業務を依頼するよりも、企業に依頼した方が有利になるからです。 これはつまり免税事業者のフリーランスエンジニアはインボイス制度がはじまることで、受注できる仕事量が減る可能性が考えられます。 二つ目の問題は、元々の免税事業者がフリーランスとしてインボイス制度対応のために消費税課税事業者となった場合、課税売上高が1,000万円以下でも消費税の納税義務が発生することです。 仕入税額控除が適用される事業者となって、企業との取引がある程度確保できたとしても消費税課税事業者となれば、消費税の支払いが義務化されます。 仮に年間課税売上が600万円程度でも、消費税の支払いが発生することになります。 免税事業者であればこれまでは消費税も売上とすることができたわけですが、消費税の支払いが必要となった場合は消費税分の売上が下がるのです。 また、消費税支払いのために経費計算も煩雑になるという負担も発生します。 このような問題があることから、フリーランスとして免税事業者である場合、消費税課税事業者になるのかどうかは慎重に判断すべきだといえるでしょう。 参考：国税庁「適格請求書等保存方式の導入について」 インボイス制度のために今から準備できること フリーランスとしてインボイス制度のために今からできることの一つは、ある程度売上を確保できる状況をつくることです。 課税売上高が1,000万円を超える状況をつくることができれば消費税課税事業者となるため、インボイス制度対応における「消費税課税事業者申告届出書」の提出が不要となり、必要な手続きが少なくなります。 また一定の売上が確保できるなら一人社長として法人化してしまうという選択肢もあります。 そして消費税課税事業者となった場合は経費計算が煩雑になるため、経費管理が簡単になるツールや会計ソフトの導入も検討することが大切です。 もしくは、自分で取り組んでいる経費の管理を税理士に任せるという判断も有用です。 フリーランスは経理担当が常駐する企業とは異なり、経費管理も自分自身で取組むことが一般的だからです。 会計ソフトの操作についても今から慣れておけば、インボイス制度開始後の経理業務の負担を減らせることが期待できます。 インボイス制度開始前にエージェントの利用を検討してみる ここまでインボイス制度について解説してきましたが、それでも免税事業者・課税事業者どちらを選ぶべきか決めきれない……という方もいるでしょう。 そんな時は、フリーランスエージェントの利用を検討してみるのもひとつの手段です。 エージェントによっては、インボイス制度が始まる際に補助制度の導入や、キャンペーンの実施をすることが予想されます。 インボイス制度開始に伴ってテクフリでは、以下の対応を実施します。 課税事業者になる方：2割特例の消費税額の一部等を単価アップ 免税事業者を継続する方：今までの報酬を維持 参考：【PRTIMES】インボイス制度による収入減少分の「テクフリ」対応について まとめ ここまで紹介してきたようにインボイス制度がスタートするのは2023年10月ですが、その時期を迎えるまでにどのように活動するのかを決めておくことが大切です。 免税事業者からインボイス制度対応として消費税課税事業者になるためには、書類の申請など前もって準備することが必要になるからです。 また2023年10月が近くなれば既存の取引先からはフリーランスとして課税事業者になるのかどうか、確認が入ることが予想できます。 免税事業者だったとしても引き続き依頼を継続してもらえるのかどうか、既存の取引先とコミュニケーションをとっておくことも大切です。 こういった納税制度への対応を示すことはフリーランス・個人事業主としての信頼にもつながるからです。 免税事業者のままの方がいいのか、消費税課税事業者になった方がいいのかは取引先の意向や年間売上高など個々の状況によって異なります。 また、テクフリアンバサダーのくるみさんと、税理士の脇田弥輝先生による対談形式で、さらに詳しくインボイス制度について解説した記事もございます。もっと正しく理解したい！という方は動画もございますので、是非ご覧ください。 テクフリがインボイス制度を徹底解説-テクフリアンバサダーくるみ＆脇田弥輝税理士対談- インボイス制度への対応はできるだけ早い段階から検討して、最適な判断ができるように準備することをおすすめします。

エンジニアのテクニカル・スキルとは “カッツの3能力”、“カッツ理論”というものをご存知でしょうか？ マネージャーに必要なスキルを三つに大別したもので、ハーバード大学のロバート・カッツ教授が1955年に提唱しました。 非常に有名な理論のため、その紹介サイトや解説書には事欠かないですが、有名であるが故に、どうしても一般論的になりがちです。 もっといえば、エンジニアは“カッツの3能力”をどのように理解し、どう活かせば良いのかが、具体的に紹介されている資料は少ない、と感じていました。 そこで今回は、エンジニアに重点を置いて、“カッツの3能力”を具体的に見ていきたいと思います。 ということで、“カッツの3能力”で指摘されている能力を1つづつ見ていきたいと思います。 まず1つ目の能力は“テクニカル・スキル”になります。 “テクニカル・スキル”とはカッツ理論によると、“特定業務を遂行するために必要なスキル”と紹介されていますが、エンジニアにとっての“テクニカル・スキル”とは、文字通り、エンジニアとしてのテクニカル・スキルです。 具体的に言えば、プログラミング・スキルであったり、デザインパターンやフレームワークの知識、基盤設計能力やシステムテストの計画能力などもあります。 もう少し乱暴な言い方をすれば、担当者として仕事を任せてもらうために必要なスキルと言えるのかもしれません。 独立を考えているのであれば、最低限、自分のコアスキルといえる分野においては、上位者の指示がなくても単独で仕事を進められる程度のスキルは必要でしょう。 また、今まで日本のエンジニアはどちらかというと、“ある分野に特化したスペシャリスト”タイプが多かったですが、近年は、フルスタックエンジニアという言葉が話題になるように、コア分野以外においても活躍できる“ジェネラリスト型のエンジニア”が好まれる風潮があります。 コアスキルはコアスキルとして知識を深めるのも大事ですが、コアスキル以外の周辺スキルにおいても、知識を深める必要性が増しています。 フリーランス案件を探す エンジニアのヒューマン・スキルとは “ヒューマン・スキル”とはいわゆる対人能力です。 もう少し具体的に言えば、コミュニケーション能力や交渉力、プレゼン力、働き掛けるスキル、それからリーダーシップ力などになっています。 システム開発においては、プロジェクトマネージャーを筆頭とした開発に携わる要員だけでなく、発注者(クライアント)やシステムの利用者(ユーザー)など、さまざまな関係者が登場します。 その様々な関係者と上手くやっていくためには、それ相応のコミュニケーション能力が必要です。 エンジニアの中には「コミュ障(コミュニケーション障害)だからエンジニアになった」と、自嘲半分で口にする方がたまにいますが、私に言わせればコミュ障はエンジニアになれません。 独立を考えるエンジニアであれば、チームリーダーとしてメンバーをまとめたり、あるいは上流工程にアサインされて、クライアントの担当者との打ち合わせに参加するなどの経験を持っている方も多いでしょう。 もちろん、それら現場での“ヒューマン・スキル”も重要ですが、独立を考えているのであれば、現場で使う“ヒューマン・スキル”だけにしか意識が向いていないと、少々、辛いことになるでしょう。 なぜならば、独立してフリーランスとなると、自分で仕事を取ってくる必要が出てくるからです。 仕事を得るために必要な“ヒューマン・スキルスキル”は営業的なものであり、エンジニアが案件の最前線で使われる“ヒューマン・スキルスキル”は、重なる部分も一部あるでしょうけれど、おそらく異なったものとなるはずです。 どうやれば現場に入れるか、もっといえば案件にアサインしてもらえるか、という観点に立った時、もっとも必要となる“ヒューマン・スキルスキル”は人脈を広げるためのスキルでしょう。 あるいは、仕事を紹介してもらったり、面接で有利に立てるように資格を取得するなどのセルフブランディングを行うスキルも大切になります。 エンジニアのコンセプチュアル・スキルとは “コンセプチュアル・スキル”とは、概念化能力とも言いますが、抽象的に物事を考えることができる能力です。 あまり、ピンとこない方が多いと思うので、さらにかみ砕いていえば「物事の本質を見抜き、似た事例で得た知見を応用して活用できる能力」とでも説明すれば良いでしょうか。 ロジカルシンキング（論理的思考）、クリティカルシンキング（批判的思考）、多面的視野、知的好奇心、俯瞰力、先見性などが“コンセプチュアル・スキル”の具体的な発揮例となっています。 ロジカルシンキングや知的好奇心、先見性などは、システム案件の現場でも必要と良く言われるスキルですが、“ヒューマン・スキルスキル”のときと同じで、やはり、待ちの姿勢でも仕事を得られるサラリーマンと、積極的に仕事を取っていく必要があるフリーランスでは、スコープが異なります。 案件内でエンジニアとしての“コンセプチュアル・スキル”はもちろん必要ですが、案件以外のところ、どうすれば仕事を得られるか、案件にアサインしてもらえるか、という部分についても、“コンセプチュアル・スキル”を発揮させる必要があります。 独立エンジニアにとっての各スキルの必要比率について考察 すでにご紹介した通り、 “テクニカル・スキル”、“ヒューマン・スキル”、“コンセプチュアル・スキル”という3つのスキルはいずれも重要なスキルです。 しかし、敢えて、独立したエンジニア向けに3つのスキルを重み付けすると、 “ヒューマン・スキル”が一番重要で、“コンセプチュアル・スキル”、“テクニカル・スキル”の順に重要度が下がるように感じています。 “テクニカル・スキル”が一番じゃないの？ と言われそうですが、いくらエンジニアとしてのスキルが高くても、“ヒューマン・スキル”が低くてうまく人間関係を築けず、有り体にいえば嫌われ者になっていた人に対して、契約改定時に「つぎも来て欲しいので、ぜひ、契約を更改しましょう！」と声をかけるクライアントはいるでしょうか？ また、“テクニカル・スキル”というのは、3つのスキルの中で、もっとも向上させやすいスキルになります。 プログラミング能力などのITスキルの多くは、基本的には学校の勉強と同じで、知っているか、知らないかの問題であることがほとんどです。 ウィザードと呼ばれるような天才エンジニアの仲間入りを目指すためにはセンスが絶対に必要ですが、普通に業務で使う分には、センスはあまり重要ではありません。 もちろん、知らないよりも知っている方が良いに決まっていますが、その気になれば、未経験のプログラミング言語を使うことになっても(“コンセプチュアル・スキル”を駆使して、他の言語の経験を生かしながら)、現場で知識を習得して、活躍することだって可能なのです。 そのため、“ヒューマン・スキル”、“コンセプチュアル・スキル”、“テクニカル・スキル”の順にしています。 さらに敢えて、この三つのスキルの重要度を数値で表すとすれば“ヒューマン・スキル”50％、“コンセプチュアル・スキル”30％、“テクニカル・スキル”20％といったところでしょうか。 まとめ：実体験に基づくナレッジへ 今回は独立を目指すエンジニアの方を主なターゲットとして、“カッツの3能力”についてみていきました。 カッツ理論は素晴らしいものですが、あくまで理論でしかありません。 実際の生活や業務に役立てるためには、カッツ理論について理解を深めつつ、実体験に基づくナレッジへと昇華していく必要があります。 この記事が、そのきっかけになると幸いです。 フリーランス案件を探す

システム開発の手法・アプローチについて、いくつかの分類方法があります。 今回は、「パッケージソフトを使うのか？使わないのか？」という基準で分類した、スクラッチ開発とパッケージ開発の違い、特にスクラッチ開発のメリット・デメリットについて見ていきたいと思います。 フリーランス案件を探す スクラッチ開発とは？ まず、スクラッチ開発と、その対義語と言える、パッケージ開発について、それぞれ、どういう開発方法なのかを説明いたします。 簡単に言うと、「パッケージソフトを使わないシステム開発方法」がスクラッチ開発で、その逆に「パッケージソフトを開発するシステム開発手法」がパッケージ開発です。 もっと具体的に言えば、「市販の電話帳ソフトの中に、良いソフトがないから、自分で作ってしまおう！」ということで、オリジナルの電話帳ソフトを開発するのが、スクラッチ開発。対して、「この電話帳アプリ、結構良いね。でも、この機能があると、もっと良いよね」と、市販の電話帳アプリを改良するのがパッケージ開発です。 スクラッチ開発のメリット、デメリットについて、詳細は後から見ていきますが、「一点モノ」のシステム開発を作る際は、スクラッチ開発、ある程度、「汎用性のあるシステム」を開発する際は、パッケージ開発を選択することが多いです。 スクラッチ開発の難易度は？ スクラッチ開発を成功させるためには、いわゆる上流工程が重要になってきます。 上流工程とは、要件定義や設計のことを言います。分かりやすく言えば、クライアントの「こんなシステムが欲しい」という希望・要求を正しく理解し、どうやって、その要求を実現するのかを考え、実現可能な設計に落とし込むスキルです。 パッケージ開発の場合、パッケージソフトというベースがあるので、そもそも、致命的な認識のずれというものは、よっぽどのことがなければ起きません。しかし、スクラッチ開発の場合、よくよく気を付けておかないと、ある程度、形になったところで、クライアントから「思っていたのと違う」とクレームが入り、そこで認識があってなかったことに気が付く、という事も、ままあります。 もちろん、パッケージ開発でも「余計な機能を足しやがって」という話になることもあるので、パッケージ開発は絶対に失敗しない、という話ではありません。ただ、エンジニアの上流工程の力量がより試されるという意味で、スクラッチ開発はパッケージ開発より難易度が高いです。 スクラッチ開発のメリットは？ スクラッチ開発について、おおむね理解できてきたところで、スクラッチ開発のメリット、デメリットについて見ていきましょう。 スクラッチ開発の一番のメリットは、ベースとなるパッケージソフトの制限を受けないということです。 基礎となるパッケージソフトがあると、どうしても、そのソフトの仕様上「特定の機能は追加できない」や「特定の動作は制限される」という事態になりがちです。 また、ライセンス料が高いパッケージソフトも中にはありますが、オリジナルのソフトを開発するスクラッチ開発であれば、基本的には、ライセンス料を気にする必要はありません。 ライセンス料だけでなく、保守面にも気を付けた方が良い場合もあります。パッケージ開発のベースになったパッケージソフトの修正パッチが配布されたので、深く考えず適用した結果、せっかく、カスタマイズして追加した機能が使えなくなった、という残念なケースを見たことがあります。 そして、上でも触れましたが、パッケージソフトが存在しない一点モノの特別なシステムを開発する際は、スクラッチ開発しかあり得ません。 筆者のITエンジニアとしてのキャリアは金融機関系のいわゆるユーザー系SIerでスタートしましたが、そこで見たシステムのいくらか（すべてではない）は「その金融機関」や「そのサービス・運営」のために開発された特注品のシステムでした。 当然、そうした特注品のシステムはスクラッチ開発されたものです。 スクラッチ開発のデメリットは？ 続いて、スクラッチ開発のデメリットについて、見ていきましょう。 スクラッチ開発のデメリットは、二つあります。 まず一つ目ですが、一般的にパッケージ開発より開発コストが高くなってしまう点です。 そもそも論として、パッケージ開発を選択する理由の一つは、すでにある程度まで完成しているパッケージソフトをベースにすることで、開発期間を短くし、開発コストを下げることです。 もっとも、パッケージ開発を選んだあと「ああいう機能も欲しい。この機能も欲しい」と仕様が拡大した結果、魔改造状態になり、「スクラッチ開発で一からオリジナルで開発した方が、早く開発ができたし、開発期間が短くなった分、安く開発できたのでは？」という、“限りなく開発失敗に近い案件”も散見されるので、あくまで一般論ではありますが。 そして、二つ目のデメリットは、パッケージ開発より失敗しやすい、という点です。理由は、『スクラッチ開発の難易度は？』で見た通り、パッケージ開発よりも、はるかに、上流工程スキルが求められるためです。 もちろん、上流工程スキルが高いエンジニアや開発チームで開発した場合、クライアントにとって、パッケージ開発では実現できなかった“良い意味で期待を裏切る”素晴らしいシステムになることもあります。ただ、どちらに転ぶのか保証がありません。 つまり、スクラッチ開発には、パッケージ開発に比べて、「コストが高い上に、失敗するリスクが高い」というのが一般的な評価なのです。 そのため、昨今のシステムインテグレーション（SIer）業界のトレンドとして、「パッケージ開発ができるのであれば、パッケージ開発。パッケージ開発ができない場合は、やむなくスクラッチ開発」というスタンスをとるのが主流となっています。 どの企業でも必要かつ、業種や会社で大きく仕様が異なることのない統合業務（ERP）システムは、ほとんどの場合パッケージ開発です。ベースとなるパッケージソフトの例としては、OBIC７や勘定奉行などがあります。みなさんも、TVCMなどで、一度は耳にしたことがあるかもしれませんね。 エンジニアの副業ならスクラッチ開発？ メリットとデメリット さて、ITエンジニアのみなさんが、副業でシステム開発を始めるとしましょう。その場合は、スクラッチ開発が良いのか、パッケージ開発が良いのか、ですが、そのクライアントとはどこで出会い、どういうニーズを持っているか次第です。 一つ言えるのは、クラウドワークスやランサーズなどの、クラウドソーシングで出会ったクライアントさんの場合は、基本的にはスクラッチ開発です。理由としては、パッケージ開発の場合、そもそもパッケージの購入（ライセンス料の支払い含めて）が必要になってしまいますが、そうした費用を予算計上されていないクライアントさんも多いので、現実的に利用が難しいです。 「えー、スクラッチ開発は難しいみたいだから、いやだな」と思った方も多いかと思いますが、スクラッチ開発の場合、オーダーメイドになるため、“保守を他の会社に任せにくい”つまり、継続的にクライアントさんとお付き合いできる関係になれる、というメリットもあるので、副業の小規模開発案件では、スクラッチ開発の方が開発者にとって有利なことも多いです。 まとめ：主流はパッケージ開発になりつつあるが 繰り返しになりますが、現在は「パッケージ開発ができるのであれば、パッケージ開発。パッケージ開発ができない場合は、やむなくスクラッチ開発」というスタンスで取り組む開発会社が多いです。 しかし、スクラッチ開発の方が良い場面、そもそもパッケージソフトがないなどの理由で、スクラッチ開発しかできないケースも存在します。例えば、大企業や行政法人などが利用する特殊用途のオーダーメイドシステムの開発は、まずスクラッチ開発となります。これらの案件は 非常に予算規模が大きく、単価も高いです。 ですので、高単価を狙う場合はスクラッチ開発を避けては通れない、ということは覚えておいた方が良いでしょう。 フリーランス案件を探す

ここ一年で一番びっくりした質問が、あるプログラミング初学者から、ぶつけられた「JavaScriptとjQueryの違いって、なんですか？」です。 自分の感覚だと、“プログラミング言語のJavaScript”と“ライブラリーのjQuery”は、“自転車”と“自転車のサドル”くらいの違いがあるため、そのような質問が出てくることを、まったく想定していませんでした。 しかし、jQueryがあまりに流行しているため、JavaScriptとjQueryの違いが曖昧になっている初学者さんも多いのかもしれません。この両者の違いを理解していないまま、学習を進めるのは、大変、危険なことです。 そこで、今回は、JavaScriptとjQueryの違いについて、見ていきたいと思います。 JavaScriptとは まず、JavaScriptについて見ていきましょう。 上でも触れましたが、JavaScriptはプログラミング言語です。人間が使う言葉にも、日本語、英語、ドイツ語、フランス語、中国語と様々な言語があるように、システム開発に使われるプログラミング言語にも様々な種類があります。その一つが、JavaScriptです。 プログラミング言語である、JavaScriptの特徴は、JavaScriptが生まれた歴史的背景を知れば、理解できます。 JavaScriptは1995年に登場したのですが、当時、多くのWebサイトがHTMLとCSSのみで構成されており、Webサーバーから一方的に送り付けられたデータが、Webブラウザ上に表示するだけでした。 今のように、ECサイトで、買い物をしていて、「この商品をショッピングカードに入れる」ボタンを押すと、右上のショッピングカードマークのところに、商品が入ったことを知らせるアイコンが表示されるような仕組みを持っているサイトは、まずありませんでした。 このような、Webブラウザを見ている人の操作に合わせて、Webブラウザ上の表示を変える仕組みを持つページのことを動的ページと言いますが、動的ページを作るために生み出されたのがJavaScriptなのです。 JavaScriptの実装例として有名なのが、Googleマップです。 ところで、Googleマップで「地図」を表示したあと、経路情報を検索して、そのルートを地図上に表示させる、という使い方を行う人も多いと思いますが、その過程でページの更新は起きないですよね？ これ、実はすごいことで、本来、Webブラウザ上の表示を変える際は、サーバーとクライアント（Webブラウザ）は同期通信、つまりページの更新が必要です。 なぜ、Googleマップではページの更新が起きないかというと、ページの更新が不要になる特別な技術が取り入れられているからです。その技術の名前をAjax（Asynchronous JavaScript + XML）と言い、JavaScriptの利用が前提になっています。 このAjaxの技術が大変に注目を集め、JavaScript はWebコンテンツ開発で主要なプログラミング言語となりました。さらに、Webコンテンツ開発の技術を応用した、スマートフォン向けアプリ開発でもJavaScriptを利用することが多いです。 また、JavaScriptを扱えるエンジニアが増えたことで、本来の得意領域である、Webコンテンツ開発以外のところでも、JavaScriptを使いたい、というニーズも生まれました。その結果、サーバーで動くJavaScript開発環境のNode.jsが登場しました。あるいは、JavaScriptで人工知能開発を行いたい人向けのライブラリーTensorFlow.jsも登場しています。 もともとは、動的なWebコンテンツを作りためのプログラミング言語でしたが、利用シーンは多岐に渡るようになっています。 JavaScriptの案件を見る ＞ jQueryとは JavaScriptについて、理解できたところで、続いてjQueryについて見ていきましょう。 jQueryはライブラリーです。ライブラリーというのは“あるプログラミング言語でシステム開発するのに、役立つプログラム（メソッド）を集めたツール”です。つまり、「JavaScriptというプログラミング言語で開発作業を進める際に用いられる便利ツールがjQueryというライブラリー」なのです。 JavaScriptはプログラミング言語で、jQueryはライブラリーと、まったくの別物であることは、ご理解できたでしょうか？ ではなぜ、JavaScriptとjQueryを混乱する方が多いかというと、jQueryには「write less, do more」というスローガンがあります。和訳すると、「書くのは少なく、できることは多く」といったくらいの意味でしょうか。 このスローガンの通り、jQueryを使うと、jQueryを使わないで記述するより、はるかに少ないソースコードで同じか、それ以上のことができることもあります。そのため、JavaScriptプログラマー側も「jQueryを使って開発」するのと「jQueryを使わずに開発」するのでは、“別のプログラミング言語を扱っている”ように感じている方が、少なからず存在します。 そして、“別のプログラミング言語を扱っている”ように捉えている方たちは、ついつい、jQueryを“一つのプログラミング言語”のように扱って、正確には「jQueryライブラリーを使って、JavaScriptで開発しましょう！」と表現するべきところを、「jQueryで開発しましょう！」と表現しがちです。 ある程度、プログラミング経験のある方であれば、「jQueryで開発しましょう！」だけでも、“ああ、プログラミング言語としてはJavaScriptを使うのね”と分かるのですが、初学者の方が、そこまで思い至るのは難しいでしょう。結果、「JavaScriptとjQueryって、なにが違うの？」という疑問になってしまっていると感じます。 jQueryの案件を見る ＞ jQuery のメリットとデメリット さて、JavaScriptとjQueryの違いについて分かってきたところで、ライブラリーjQueryについて、今から学ぶ、メリット・デメリットをご紹介いたします。 「jQueryで開発しましょう！」と書いただけで、“プログラミング言語はJavaScriptを使うのか” と、ある程度のプログラミング経験者であれば誰でも分かる、というのは、“ITエンジニアたちの間で、jQueryがどれだけ有名なJavaScriptライブラリーなのか”を証明している、とも言えます。 jQueryにはJavaScriptを用いてWebコンテンツ開発するのに非常に便利なメソッドが収録されており、JavaScriptの標準ツールではないのですが、高い確率でJavaScript開発でjQueryが利用されてきました。 日本はやはり保守的で、IT業界においても、既存の信頼性が高い技術から新しい技術への乗り換えを躊躇する傾向が強く、jQueryの利用率が高くなっています。 デメリットとしては、メリットの書き方で気が付いた方もいらっしゃるかと思いますが、世界的にはjQueryの採用率が緩やかですが、確実に低下している、という点です。 jQueryは2006年にリリースされて以来、ほぼ毎年、バージョンアップを重ねているのですが、最新のモダンなWebコンテンツ環境開発には時代遅れという評価を下す方も多く、新規開発時に、敢えて採用しないという状況がみられるようになってきました。 世界的には2018年頃に、Facebookが作ったJavaScriptライブラリーである、React（React.jsまたはReactJSとも）に利用率1位の座を譲ったという資料もインターネット上で出回っており、今後も、じわじわとシェアを低下させていくと見られています。 まとめ：プログラミング言語？ ライブラリー？ 正しく理解しよう！ 繰り返しになりますが、JavaScriptはプログラミング言語であり、jQueryはライブラリーとまったく別物です。関連性が深いので、分かりにくいかもしれませんが、それぞれの本質を、しっかりと理解しましょう。 また、jQueryは利用率を減らし、他のライブラリーに注目度が高まっていることをお伝えしましたが、盛者必衰という言葉もある通り、また数年すれば、別のライブラリーが人気を集める、ということも十分に考えられます。 これは、ライブラリーだけでなく、プログラミング言語にも言えることです。現在、様々な分野で使われているJavaScriptも、数年後には、他の言語にとって代わられている可能性は、あまり考えられないけれど、否定もできません。 IT業界で戦い続けるには、技術動向にも興味・関心を持ってウォッチし、自分のスキルをブラシュアップしていく姿勢が重要です。

HTML/CSSのうち、HTMLはWebサイトのレイアウトをするための言語です。CSSはWebサイトのスタイルを指定する言語で、HTMLと一緒に使うことでホームページのクオリティがさらに向上します。 HTML/CSSエンジニアには、Webサイトの「見た目」にこだわることが求められます。他言語エンジニアが「機能」にこだわるのとは対照的です。しかし、見た目に特化した仕事だからといって、HTML/CSSエンジニアを他言語エンジニアより「下」とみなすことは間違っています。 なぜならWebサイトはいま、見た目がとても重視されているからです。世の中にこれだけWebサイトがあふれると、まずは見た目で選別されます。つまりHTML/CSSの技術を駆使して美しくしたWebサイトしか人々に見向きされなくなるのです。 Webサイトは中身が勝負ですが、しかし見た目が悪いWebサイトは勝負に参加させてもらえないのです。見た目が悪いWebサイトは怪しいサイトというレッテルを貼られかねず、デザイン性に劣るホームページを持っている企業は業績がかんばしくないようにみえます。 いまやWebサイトのデザインとレイアウトとスタイルは、Webサイトのオーナーの信用力に関わる重大事なのです。 そのためフリーランスのHTML/CSSエンジニアには、たくさんの仕事が用意されています。そのような魅力あふれるHTML/CSSの歴史を振り返りながら、HTML/CSSエンジニアの立ち位置や業務案件などを紹介していきます。 フリーランス案件を探す HTML/CSSの特徴とは HTML/CSSの歴史と特徴をみていきましょう。 HTMLの歴史について ティム・バーナーズ・リー氏が開発 HTMLはハイパー・テキスト・マークアップ・ランゲージの頭文字を取ったものです。つまり、ハイパーテキストをマークアップする言語、ということです。 ハイパーテキストは「テキストを超える」という意味で、多くの機能を備えたテキスト（文書）のことです。本や雑誌などの紙に書かれたテキストは、文書が持つ意味以上の情報は含まれません。しかしコンピュータの画面上のHTML化されたテキストは、コンピュータやインターネットと連動させることでより多くの情報を盛り込むことができます。 例えばWebサイト上の「日経平均株価」という文字をハイパーテキスト化すれば、「日経平均株価」という文字の上にカーソルを置くだけで「日本を代表する225銘柄（225社）の上場株式の平均株価」と表示させることができます。 マークアップとは「マークをつけること」という意味です。HTMLの場合のマークアップとは「テキストにタグをつけること」です。HTMLでは、テキストにタグをつけると文字が修飾（デザイン）されます。 例えば 「<p> ～ </p>」という囲まれたテキストは1つの段落としてデザインされますし、「<b> ～ </b>」で囲まれたテキストは太文字になります。 HTMLは1989年に、ティム・バーナーズ・リー氏という人が開発しました。リー氏はHTMLだけでなく、 文書や画像や動画を公開・閲覧する仕組みであるWWW（ウェブのこと） 転送プロトコルのHTTP リソースを識別するURL も同時に開発し「Webの父」と呼ばれています。 リー氏はスイスの欧州原子核研究機構（CERN）という組織に属していて、何千人もの科学者の論文や資料を探すのに苦労していました。そこでリー氏は、WWW、HTTP、URL、HTMLといった技術を搭載したサーバーとブラウザというツールを開発し、論文や資料の検索と閲覧をシステム化したのです。 CSSの歴史 1996年に登場 一方のCSSは、カスケーディング・スタイル・シートの頭文字を取ったもので、HTMLで構造を整えたテキストをさらにスタイリッシュにする機能を持ちます。 CSSが登場したのは1996年です。機能はHTMLと似ているのですが、次第に両者は役割分担されるようになりました。 いまでは、 ・HTMLはWebサイトのテキストなどの構造を重視する ・CSSはWebサイトのテキストなど装飾を重視する というすみわけがなされています。 CSSは発表当初はほとんど注目されませんでした。ところがInternetExplorerやFirefox、OperaなどのブラウザがCSSをサポートするようになりエンジニアたちに使われるようになったことでメジャーになりました。 CSSを使うと、テキストの構造を変更せずに文字装飾などを行えます。またCSSはテキストのスタイルを一括管理できるので、変更も容易です。 この作業をHTMLだけで行おうとすると、デザイン方針が大きく変わったときに装飾した箇所をすべて手作業で修正していかなければなりません。 HTMLとCSSの両方を使いこなすことで、サイトのメンテナンス性が格段に向上するのです。 HTML/CSSの強みとニーズ HTML/CSSエンジニアの最大の強みは、Webサイトの閲覧数を増やせることです。閲覧数はサイトの実力を測るうえで重要な指標であり、広告収入にも直結します。つまり閲覧数はWebビジネスを展開する企業や個人が最も求める「数字」であり、テレビ業界の視聴率のようなものです。 閲覧数を最も効率よく増やすには、グーグルやヤフーなどの検索サイトで上位に表示されなければなりません。検索サイトは検索ワードに関係が深いサイトを表示しますが、その表示順は、価値が高い情報を掲載しているサイトが優先されます。 グーグルなどは、ロボットを使って世界中のサイトを閲覧し、価値判断しています。 ロボットはサイトの内容だけでなく、体裁にも注目します。つまりHTML/CSSで作成されて美しい体裁のサイトは、グーグルのロボットによって「価値がある」と判断されるのです。HTML/CSSのルールで書かれていないサイトは、価値が低いとみなされてしまうのです。 もちろんグーグルのロボットはキーワードなどもチェックするので、コンテンツの製作者たちはサイトに掲載する記事や写真や動画を磨き上げる必要があります。しかしそれと同じくらいの労力をかけてサイトの見た目をよくしないと、せっかくの良コンテンツが見向きされない結果になってしまうのです。 こうしたことから、Webビジネスを展開する企業はHTML/CSSエンジニアにサイトの「仕上げ」を依頼します。だからフリーランスのHTML/CSSエンジニアは、IT界、Web界で一定の存在感を示すことができているのです。 HTML/CSSで気を付けること HTML/CSSのスキルだけでこなせる案件もありますが、あまり単価は高くないでしょう。 というのもHTML/CSSスキルの獲得はそれほど難しくないからです。例えば企業が事務職社員にHTML/CSSを覚えさせ、自社サイトの更新をさせることも不可能ではありません。 したがってフリーランスエンジニアを目指す人は、HTML/CSSだけでなく「+アルファ」を身につけておいたほうがいいでしょう。 例えば、アドビ社製のグラフィックソフト「Photoshop」のスキルがあると、サイトのデザインとHTML/CSSによるテキスト加工の2つの仕事を請け負うことができます。 もしこれからエンジニアの道に進もうと考えている若い人なら、理想は、C＃やJavaScriptなどのコンピュータ言語を先に身につけてから、後からHTML/CSSを学ぶことです。 HTML/CSSエンジニアの募集要項のトレンドとは HTML/CSSエンジニアは、どのようなポジションで働くことが求められているのでしょうか。案件票の募集要項などを参考に、HTML/CSSエンジニアの働き方のトレンドを探っていきます。 フロントエンドエンジニアというポジション スキルが高いHTML/CSSエンジニアは、フロントエンドのポジションで働くことができます。Web製作のプロジェクトでは、フロントエンドエンジニアはディレクションやデザイン、インターフェースに関わります。ユーザーと直接やり取りすることもあります。 フロントエンドエンジニアは、サーバーサイドエンジニアやバックエンドエンジニアなどと異なり、システムの要件定義や設計、開発業務にはあまり関わりません。 フロントエンドエンジニアは、サーバーサイドエンジニアと比べると新しい職種です。情報が美しく載っているWebサイトへのニーズが高まったことで、フロントエンドエンジニアが誕生したのです。 競争力のあるHTML/CSSエンジニアになるには、PCだけでなくスマホやタブレットに関する知識が必要です。さらに、 ・レスポンシブWebデザイン ・サイトの軽量化 ・表示速度の高速化などの知識が加わるとさらに高単価案件を獲得できるでしょう。 レスポンシブWebデザインとは、どの大きさの画面でも見やすくする技術です。レスポンシブWebデザインでWebサイトをつくるとパソコン、スマホ、タブレットのすべてに対応できるので修正や更新が容易です。 またサイトを軽量化して表示速度を高速化できると、Webサイトの閲覧ストレスが減り、離脱を防止できます。 他のHTML/CSSエンジニアとの差別化を図るには、上記の3つのスキルの獲得はマスト事項といえるでしょう。 HTML/CSSエンジニアが活躍している業界、分野 HTML/CSSエンジニアが活躍できる分野は、幅広いのですが、ここではスマホ向けアプリ製作に注目してみます。 家電業界 HTML/CSSエンジニアは、家電関連の業務で活躍できるでしょう。パナソニックもソニーもシャープも、家電製品とネットをつなぐIoT化に力を入れています。家電をネットにつなぐと遠隔操作ができたり、家電を賢くするスマート化を進めたりできます。 家電のIoT化で重用されるのがスマホです。スマホはIoT家電のコントローラーのような役割を果たします。IoT家電のユーザー（消費者）は、専用アプリをスマホにダウンロードしてスマホで家電を操作します。 IoT家電も家電である以上、老若男女がITやIoTの知識がなくても使えるようにしなければなりません。そのためスマホアプリは、直感で操作できるインター フェイスにしなければなりません。 そこでHTML/CSSエンジニアの力が求められます。家電メーカーが求める操作性とデザイン性を実現できるフリーランスのHTML/CSSエンジニアは仕事の幅が格段に広がるでしょう。 フィンテック フィンテックとは、金融（フィナンシャル）とIT技術（テクノロジー）を合わせた造語です。金融サービスを次々IT化、AI（人工知能）化していこうという取り組みで、メガバンク、クレジット会社、携帯キャリア、IT企業などが進出し、その市場は世界規模となっています。 スキルが高いHTML/CSSエンジニアは、フィンテック関連の案件に関わることもできます。 フィンテックには、何千億円規模のマネーを扱う仮想通貨システムのような超高度なものだけでなく、スマホ決済のようにすでに身近になっているサービスも含まれます。 またフリーランス向けの会計サービスや主婦向け家計簿サービスも、クラウドを使ってフィンテック化しています。 このような市民生活に密着したフィンテックサービスは、ユーザーフレンドリーなインターフェイスが必須となるので、HTML/CSSエンジニアが活躍できるのです。 HTML/CSSのフレームワーク事情 HTML/CSSのフレームワークを紹介します。HTML/CSSだけではスキルに付加価値をつけることは難しいのですが、HTML/CSSエンジニアがフレームワークを多用して「できること」を増やすとライバルエンジニアに差をつけることができます。 GroundworkCSSとは GroundworkCSSの魅力はレスポンシブなところです。パソコン、スマホ、タブレットなど各種デバイス向けにWebサイトを製作するときにGroundworkCSSを使えば、文字の大きさが常に最適なサイズに維持されます。 またアイコンフォントやアニメーションが標準装備されているので表現豊かなサイトに仕上げることができます。 Renaissance.cssとは Renaissance.cssは、まだ高度なスキルを獲得できていないHTML/CSSエンジニアの強力な武器になるでしょう。 Renaissance.cssのコンセプトは「黄金比」です。サイトをデザインするとき、文字やリンクボタンのサイズ決めに苦労するのではないでしょうか。 Renaissance.cssはそれらの最適なサイズを簡単に選択できます。 またRenaissance.cssのユーザーのなかには「レゴブロック感覚でサイトを構築できる」という人もいます。 これはRenaissance.cssがBEMの概念を取り入れているからです。BEMにより作業が簡素化され、製作時間を短縮できます。 micronとは マイクロインタラクションを組み込んだWebサイトはすっかり一般的になりました。マイクロインタラクションが搭載されていないWebサイトのほうが珍しいくらいです。 micronは簡単にマイクロインタラクションを導入できるフレームワークです。JavaScriptのコードを書かずに使えるアニメーションが12個用意されているので、「HTML/CSSのみのエンジニア」も使うことができます。 もちろんJavaScriptスキルがあるとmicronをさらに使いこなすことができます。 マイクロインタラクションとは、ボタン操作したときに正しく実行されたことを示す仕組みです。例えばスマホ画面上をタップしたときにボタンがアニメーションで動く仕組みはマイクロインタラクションです。 Simpleとは HTML/CSSのスキルが身についたら、Simpleを使ってみましょう。簡単な関数を使うことで全体を一括操作できます。 またSimpleには便利なコンポーネント（各種の機能を持つパーツ）が収録されているので、サイトのデザイン性を簡単に向上させることができます。 HTML/CSS案件単価事情 フリーランスのHTML/CSSエンジニアにはどのような業務が発注されるのでしょうか。案件の単価などを紹介します。 大手製薬会社のメルマガ作成、月40万～50万円 広告の企画・製作会社が大手製薬会社のメルマガ作成を請け負ってくれるフリーランスのHTML/CSSエンジニアを探しています。 ギャランティは月40万～50万円となっています。 この案件の応募に求められる技術的なスキルはHTML/CSSだけですが、社会人としてのビジネスマナーやコミュニケーション能力が求められます。 動画配信アプリの開発、月80万円 こちらの案件はHTML/CSSスキルだけでなくJavaScriptの業務経験も必要です。月額80万円とかなり高い報酬となっています。 業務内容は動画配信アプリの開発で、ポジションはフロントエンドエンジニアです。マークアップをしながら、サーバーサイドエンジニアとの調整業務も担当します。 フリーランス向け案件ですが、平日10時～19時の間、常駐する必要があります。 HTML/CSS案件の具体的な業務 HTML/CSSのスキルしかないとどうしても仕事の幅を狭めてしまうので、できればJavaScriptやフォトショップのスキルを身につけておいたほうがよいでしょう。 しかし「HTML/CSSのみのエンジニア」に仕事がないかというとそのようなことはありません。 オペレーターとして働くのであれば、HTML/CSSスキルだけで仕事を獲得することは可能です。 フロントエンドエンジニアのほうがオペレーターより格上のポジションで、報酬も高いのですが、フロントエンジニアはプロジェクトによっては「泊まり込みの日々」が続きます。 一方、HTML/CSSのコーディングだけに専念できるオペレーターは定められた業務を定められた時間内に仕上げれば仕事を終わらせることができます。 つまり「長時間働くことができない」といった事情があったり、「高報酬よりワークライフバランスを重視したい」と希望したりする方は、オペレーターというポジションがおすすめです。 だからといってHTML/CSSオペレーターの仕事は単純作業ではありません。きっとディレクターは、よりよいアイデアをオペレーターに求めるでしょう。サイトのデザイン性を向上させたり、テキストを読みやすくしたりなど、オペレーターが工夫できることは少なくありません。 創意工夫が得意なオペレーターと、単なる作業員のオペレーターでは、次の仕事につながる確率が違ってきます。 ただオペレーター業務は、高額報酬は期待できません。 HTML/CSS案件の案件票をみてみよう フリーランスのエンジニアも、企業の正社員エンジニアの働き方や待遇、福利厚生などを知っておくことは大切です。フリーランスがクライアントと報酬交渉をするときの材料になるからです。 そこでHTML/CSSエンジニアを正社員で採用する企業の案件票をみてみましょう。 愛媛県松山市のHTML/CSSコーダー、月18万～25万円 地方の正社員案件を紹介します。 愛媛県松山市の企業が、自社サイトのコーディングと更新業務ができる正社員のHTML/CSSエンジニアを募集しています。 月給は、基本給14.4万～20万円＋固定時間外手当3.6万～5万円（計18万～25万円）となっています。 HTML/CSSとフォトショップの知識が必須で、イラストレーターやPHPなどの知識がある人を優遇します。 「HTML/CSS＋アルファ」のスキルがあれば憧れの地方移住ができるのです。 飲食店向けWeb予約システムの開発、年収250万～650万円 東京のITベンチャーが、飲食店やリラクゼーション施設向けのWeb予約システムを開発する正社員HTML/CSSエンジニアを募集しています。 この案件に応募するにはHTML/CSSスキルだけでは足りず、JavaScriptの知識と半年以上のプログラミング経験も必要です。 ただ同社は未経験者も積極的に採用していて、さらに年収の下限が250万円となっていることからそれほど高いスキルを持っていない人でも応募できそうです。 エンジニアの労働市場は慢性的に人手不足のため、IT企業には「採用してから育てる」というマインドがあります。 まとめ～HTML/CSS需要の今後と未来 HTML/CSSの需要は今後、増えることはあっても減ることはないでしょう。HTML/CSSエンジニアの将来は有望といえます。 またフリーランスのHTML/CSSエンジニアは「＋アルファ」のスキルを身につけることで確実に収入を増やすことができます。 IT未経験者も、コンピュータ言語になかでも習得が易しいHTML/CSSを身につけておけば、安定した仕事を確保できるIT業界で働くことができます。 HTML/CSSは非常にコスパがよいスキルといえるでしょう。 フリーランス案件を探す

序文：純粋関数型プログラミング言語 Haskell(ハスケル) Haskell(ハスケル)は純粋関数型プログラミング言語です。Haskell(ハスケル)は数学者であり論理学者でもあるハスケル・カリー氏の名前が由来となっているプログラミング言語です。Haskell(ハスケル)を知るにあたって、純粋関数型プログラミング言語とは何かを知ることが重要となってきます。 純粋関数型プログラミング言語は関数型プログラミング言語の一部であり、命令形プログラミング言語と対比されることが多いプログラミング言語です。関数型プログラミング言語は変数の初期化や代入がないことが大きな特徴となっています。 同じ処理を繰り返すことを繰り返し処理と言いますが、これを実行するために通常はループというものを使います。例えば、商品計算のシステムがあったときに、商品によって価格は異なるため、商品の情報をデータベースから取ってきて、それを足し合わせる処理を繰り返しやる必要があります。 その際に、命令形プログラミング言語だとループによって合計額として定義した変数にそれぞれの商品の価格が代入され、最終的な合計額が変数として見える形になります。一方で、関数型プログラミング言語では繰り返し処理をメソッドとして再帰的に呼び出すことで、それぞれの商品の価格を合計し、最終的に合計額を出します。 命令形プログラミング言語で触れた変数の再代入と入出力によってプログラムの状態を副作用と言い、この副作用を持たないプログラミング言語を純粋関数型プログラミング言語と言います。このような副作用があると、テストやデバッグを困難にさせたり、プログラムの動作が複雑で分かりづらいという恐れがあります。 命令形プログラミング言語はコンピューターによって理解しやすいプログラミング言語ですが、純粋関数型プログラミング言語は人間にとって読みやすいプログラミング言語となっています。この純粋関数型プログラミング言語の中でも、副作用のような機能を持つモナドという機能があるのがHaskell(ハスケル)です。 Haskell(ハスケル)の誕生：前身となった言語、Miranda Haskell(ハスケル)の誕生に大きく関わっているのはHaskell(ハスケル)の前身となったプログラミング言語であるMirandaが1985年にリサーチソフトウェア社から発表されました。このMirandaは当時に数多くあった純粋関数型プログラミング言語の中でも、一番多くの人に使われていたプログラミング言語です。 ただ、Mirandaはリサーチソフトウェア社が開発したこともあり、著作権が発生していたので、オープンソースとして皆さんが使えるものではありませんでした。そこで、1987年にFunctional Programming Languages and Computer Architectureという会議によってオープンソースであるプログラミング言語が開発されるべきという意見が多数あり、Haskell(ハスケル)開発のための委員会が発足し、実際に開発に至りました。 一番最初にリリースがされたHaskell(ハスケル)はHaskell1.0という名称でリリースがされました。ここからHaskell(ハスケル)というプログラミング言語が進化をしていきます。 Haskell(ハスケル)の黎明期：非公式に進むプロジェクト 実際に、Haskell1.0が誕生し、その後にHaskell(ハスケル)は黎明期を迎えます。Haskell1.0のバージョンアップのための開発は進み、1997年後半には挙動がより安定し、機能を拡張するためにライブラリーが搭載されたHaskell98がリリースされました。 その後に、Haskell98を更に進化させるHaskell′（Haskell Prime）というプロジェクトが非公式に進みました。 続いて、Haskell2010が2010年に発表されました。これは他のプログラミング言語とのバインディングを可能にするもので、それを可能にする機能であるForeign Function Interface（FFI）が追加されました。 Haskell(ハスケル)の成長期：エンジニアにとって実用的で使いやすい言語に Haskell(ハスケル)はHaskell2010の発表以降に、バージョンアップを繰り返し、更に実用的で使いやすい言語に成長を遂げています。 また、Haskell(ハスケル)を参考に開発がなされたプログラミング言語もあります。その一つがCleanです。Cleanは純粋関数型プログラミング言語で、Haskell(ハスケル)と仕様が非常に似ています。Haskell(ハスケル)は変数の再代入と入出力によってプログラムの状態である副作用をモナドという機能を使うことで扱いますが、Cleanは一意型という一貫性のある表現を使います。 このようにHaskell(ハスケル)だけではなく、Cleanといった純粋関数型プログラミング言語全体で成長を遂げています。 Haskell(ハスケル)の現在：セキュリティ対策のために利用される言語に 現在、Haskell(ハスケル)はその使いやすさや汎用性から多くの企業に支持されており、国内外問わず使用されています。 Haskell(ハスケル)の良さは開発における信頼感とスピード感です。早く開発しなければならないが、複雑なシステムを開発しなければならないといった難易度の高いシステムを開発するときに重宝されるのがこのHaskell(ハスケル)です。ただ、JavaやRubyなどの有名な言語に比べると、使用している企業は少ないです。 海外だと、皆さんご存知のFacebook社がHaskell(ハスケル)を利用しています。マルウェア対策やスパム対策といったセキュリティ対策のために利用されているようです。国内ですと、業務パッケージの開発・販売をしているワークスアプリケーションズ社が使用していたり、金融の高頻度取引で有名なTsuru Capital社が使用をしています。 Haskell(ハスケル)は優秀なプログラミング言語であるものの、他のプログラミング言語に比べて開発に大きな費用がかかる・習得難易度が高いという特徴があります。そのため、小さなベンチャー企業やフリーランスに用いられることはあまり多くはありません。 Haskell(ハスケル)を使用している企業は優秀なエンジニアと潤沢な資金がある企業ばかりです。実際にHaskell(ハスケル)を使えるエンジニアを募集している転職の求人数を調べてみても、他のプログラミング言語とは大きな開きがあります。ただ、導入企業は昔よりも増えているので、今後の将来性には期待できるでしょう。 まとめ：Haskell(ハスケル)は有名企業も採用する言語 プログラム言語の歴史 ＜Haskell(ハスケル)編＞ というテーマで今回はお伝えしました。いかがだったでしょうか？ 今回お伝えしたかったことは以下のとおりです。 Haskell(ハスケル)は関変数の初期化や代入がないことが大きな特徴である関数型プログラミング言語であるHaskell(ハスケル)はオープンソースである純粋関数型プログラミング言語を開発すべきという意見から開発がなされたHaskell(ハスケル)はHaskell(ハスケル)はその使いやすさや汎用性から多くの企業に支持されており、国内外問わず使用されている 今回はプログラミング言語であるHaskell(ハスケル)を見てきましたが、Haskell(ハスケル)の知名度はそこまで無く、一部の方しかご存知ないプログラミング言語だと思います。現在、求人数が少なく、仕事で使うという観点で他のプログラミング言語と比べるとやや劣るプログラミング言語ですが、成長を遂げて将来性もあると言われています。 そのため、Haskell(ハスケル)を学ぶことはプラスになると言えるでしょう。また、Haskell(ハスケル)は純粋関数型プログラミング言語という珍しい分類に入るプログラミング言語であり、有名企業も採用しているプログラミング言語であるので、趣味程度でも是非触ってみることをオススメします。 フリーランス案件を探す

gemとは何か gemとはrubyのライブラリのことを指します。 gemの扱い方 gem list でインストール済みのgemの確認ができる $ gem list *** LOCAL GEMS *** actioncable (5.2.1, 5.2.0, 5.1.6, 5.1.4) actionmailer (5.2.1, 5.2.0, 5.1.6, 5.1.4) actionpack (5.2.1, 5.2.0, 5.1.6, 5.1.4) actionview (5.2.1, 5.2.0, 5.1.6, 5.1.4) activejob (5.2.1, 5.2.0, 5.1.6, 5.1.4) activemodel (5.2.1, 5.2.0, 5.1.6, 5.1.4) activerecord (5.2.1, 5.2.0, 5.1.6, 5.1.4) activestorage (5.2.1, 5.2.0) activesupport (5.2.1, 5.2.0, 5.1.6, 5.1.4) addressable (2.5.2) archive-zip (0.11.0) arel (9.0.0, 8.0.0) ast (2.4.0) bigdecimal (default: 1.3.4) bindex (0.5.0) bootsnap (1.3.1) builder (3.2.3) bundler (1.16.4, 1.16.3) byebug (10.0.2, 9.0.6) capybara (3.4.1) childprocess (0.9.0) chromedriver-helper (1.2.0) 〜省略〜 rails に関連するgemを探したい場合は gem search -r rails で探すことができる $ gem search -r rails *** REMOTE GEMS *** aa-rails4 (0.6.0) aaronchi-jrails (0.5.1) aavkontakte-rails3 (0.1.9) ab-experiments-rails (0.0.3) abcjs-rails (3.0.1) access-granted-rails (0.1.0) access-watch-rails (0.0.3) access_policy_rails (0.0.2) access_watch_rails (0.1.2) accessible-bootstrap3-rails (0.2.4) account_kit_rails (0.0.0) accountingjs-rails (0.0.4) ace-rails (0.0.2) ace-rails-ap (4.2) ace_editor-rails (0.0.1) ace_vimtura-rails (0.1.3) aced_rails (0.2.1) ack_favicon_maker_rails (1.0.2) ack_rails_admin_jcrop (0.2.0.2) ack_rails_admin_settings (1.2.3.3) act-fluent-logger-rails (0.5.0) 〜省略〜 なお、ブラウザで確認したい場合は下記を参照 ruby-toolbox RubyGems.org gem のインストールは gem install rails で可能だが、あまりお勧めできる方法ではない。 bundler で管理するのが常套 bundlerとは bundle inatall などで使われる bundler 。実はこれもgemの一つである。 用途はgemの管理。 gemを複数使っていると、依存関係が出てくる。 バージョンが？？だの、あのgemがないだの言われる。 それをbundlerで管理する。そのファイルがGemfileである。 source 'https://rubygems.org' git_source(:github) { |repo| "https://github.com/#{repo}.git" } ruby '2.5.3' gem 'mysql2', '>= 0.4.4', '< 0.6.0' gem 'puma', '~> 3.11' gem 'rails', '~> 5.2.2.1' gem 'sass-rails', '~> 5.0' gem 'uglifier', '>= 1.3.0' # gem 'mini_racer', platforms: :ruby gem 'coffee-rails', '~> 4.2' gem 'jbuilder', '~> 2.5' gem 'turbolinks', '~> 5' # gem 'redis', '~> 4.0' gem 'bootsnap', '>= 1.1.0', require: false gem 'mini_magick', '~> 4.8' gem 'aws-sdk' gem 'carrierwave', '~> 1.0' gem 'config' gem 'devise' gem 'devise-i18n' gem 'draper' gem 'exception_notification' gem 'fog-aws' gem 'font-awesome-rails' gem 'gretel' gem 'kaminari' gem 'ranked-model' gem 'ransack' gem 'slack-notifier' gem 'slim-rails' gem 'yaml_vault' group :development do gem 'listen', '>= 3.0.5', '< 3.2' gem 'spring' gem 'spring-watcher-listen', '~> 2.0.0' gem 'web-console', '>= 3.3.0' gem 'better_errors' gem 'bullet' gem 'capistrano' gem 'capistrano-bundler' gem 'capistrano-rails' gem 'capistrano-rbenv' gem 'capistrano-yarn' gem 'capistrano3-puma' gem 'guard-rspec', require: false gem 'rack-mini-profiler' gem 'rails-flog', require: 'flog' gem 'simplecov', require: false end 〜省略〜 source 'https://rubygems.org' でホスティングサーバーを指定。 gem 'rails', '~> 5.2.2.1' でrails のバージョンを指定。 group :development do gem 'listen', '>= 3.0.5', '< 3.2' gem 'spring' gem 'better_errors' gem 'bullet' end 本番環境で使うgemを指定。 こんな感じでgemを記載していく。 Gemfileを書き終えたら、bundle insrall でGemfileに記載された通りにインストールする。 その際に、Gemfile.lockを作成する。 このファイルがgemのバージョンをロックしバージョンが変わらない様にしてくれる。 つまり、gemが更新されても使用するgemのバージョンはそのままにしてくれる。 Gemfile.lockを更新したいときは bundle update を使う。 フリーランス案件を探す

はじめに Rails フレームワークを利用するアプリケーションでは登録とログインモジュールにDevise gem と bcryptがよく使っています。DeviseはRailsでおそらく最も人気な認証機能を実装できるgemです。 ユーザーのパスワードの暗号化とログイン確認に対してDeviseはデフォルトでbcryptを使用しています。 bcryptを利用しない例 下記はbcryptを利用しない認証フォローの１つ例です。 1. ユーザーが登録する時、パスワードはハッシュして、データベースに保存します。 2. ログインする時、入力したパスワードをハッシュして、データベースに保存したハッシュしたパスワードと比べて、一致したら、ログインできます。一致しなければ、「バイバイ」ですね。このアプローチには、暗号化アルゴリズムが常にパスワードが渡された固定文字列を返すという大きな欠点があります。例えば、SHA1アルゴリズムで使えば、”password” というストリングはハッシュした後いつも ”5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8”というストリングを返します。 これにより、ハッカーがデータベースを攻撃し、ユーザーのパスワードハッシュであるデータを取得すると、ハッカーは、Rainbow Tableを作成してユーザー全体のパスワードを取得するために、一度だけ総当たりする必要があります（パスワード「password」または「123456」を持つユーザーは同一のハッシュ文字列を持っているため）。 したがって、同じパスワード文字列が他のハッシュを生成するソリューションが必要ですが、ユーザーがログインすると、比較結果が一致する必要があります。 そのため、パスワードに「salt」を追加する必要があります。 Bcryptによる、salt はランダムストリングです。Saltのおかげで、毎回ハッシュする時、違うストリングを返します。 bcryptを利用する例 下記はbcryptを利用する認証フォローの１つ例です。 1. ユーザーが登録する時、ランダム saltを発行して、saltとパスワードをハッシュして、encrypted_passwordを取得して、データベースに保存します。encrypted_passwordはsalt を含みます。パスワード同じですが、saltはランダムから、毎回ハッシュするのは新しいencrypted_passwordを作ります。 2. ログインする時, データベースのencrypted_passwordのsaltを取って、入力したパスワードとsaltをハッシュして、ハッシュしたストリングを取得して、そのストリングとencrypted_passwordを比べて、一致したら、ログインできます。 例えば、”my password”というストリングをbcryptで使って下記の形の１つ例でencrypted_passwordと呼びます。 $2a$12$K0ByB.6YI2/OYrB4fQOYLe6Tv0datUVf6VZ/2Jzwm879BW5K1cHey 今encrypted_passwordを分析します。 2a (最初の$の２つの間): bcrypt暗号化アルゴリズムバージョン12 (次の$の２つの間)：costと呼ばれます。costの役割は何か後で分析します。K0ByB.6YI2/OYrB4fQOYLe(最後＄の後のキャラクターの22個): saltと呼ばれています。6Tv0datUVf6VZ/2Jzwm879BW5K1cHey（最後キャラクターの31個）: ctextと呼ばれます。ctextはsaltとパスワードからハッシュされます。 Costについて Costを説明いたします。 Costとは、ハッシュを何回実行するか、つまりどれだけ遅いかという尺度です。 あなたはそれを遅くしたい。 繰り返しますが、これはハッシュされたパスワードが盗まれた場合のセキュリティの冗長な層です。何でもブルートフォースするのは法外に高価になります。 Cost は4以上と31以下の数字です。Bcryptアルゴリズムでは例えばcostは12なら、繰り返し数は2^12=4096回。 Cost = log_2 (繰り返し数) なので、cost は高ければ、高くほどパスワードのハッシュは安全になります。 しかし、逆にcostが高ければ、高くほどハッシュの速度も遅くなります。 bcryptアルゴリズムです。 bcryptアルゴリズム 詳しくはhttps://ja.wikipedia.org/wiki/Bcryptで参考できます。 それだけパスワード保安方法は安全と思いますか？ ランダムsaltはRainbow Tableを作成するコストを増加させましたが、人生は不明ですが、攻撃者は常に自分が望むものを達成する想像を絶する動機を持っています。攻撃者がスーパーコンピューターを持っているとデータベースを攻撃し、データを手に入理とします。そのスーパーコンピュータには、データのencrypted_passwordとsaltから、Rainbow Tableを作って、パスワードを見つけられます。 それでは、このリスクを最小限に抑える方法は？原則は、すべての卵を1つのバスケットに入れるのではなく、pepperです。Pepperはsaltに似たランダム文字列ですが、違いは、pepperを秘密にして、データベース以外の場所に保存する必要があることです。また、ユーザーあたりのpepperは必要ありません。ユーザーの全ては1pepper十分です。 Deviseはpepperを使っているのを見えられます。 Bcryptでhash_sceret(password, salt)からbcryptでhash(password, salt, pepper)に使うのはもっと安全になります。 ハッカーはデータベースを手に入っても、pepperがないから、rainbow tableを作れない、パスワードを取れないです。 ノート：攻撃者が何らかの方法でdbユーザーを持っていると想定している記事では、実際にはこれは非常に困難です。インフラストラクチャの設計など、他のセキュリティレイヤーがあるためです。それらの問題について話しません。 参考 Gem devise https://github.com/plataformatec/devise bcryptアルゴリズム https://ja.wikipedia.org/wiki/Bcrypt Gem bcrypt-ruby https://github.com/codahale/bcrypt-ruby Rainbow table https://ja.wikipedia.org/wiki/レインボーテーブル