エンジニアのテクニカル・スキルとは “カッツの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/レインボーテーブル