【毎週日曜更新】本の要約・考察第47回~『プロセスエコノミー』~
今回の記事では、SNS上で数多くの著名人が取り上げている名著『プロセスエコノミー』についてざっくり解説します。
本書の要旨
本書の要旨を簡潔にまとめると、以下のようになります。
良いものをつくるだけではモノが売れない時代に突入した。完成形だけで差別化を図るのは非常に難しい
人もモノも埋もれる時代の新しい稼ぎ方―「プロセス」で稼ぐこと。プロセスはコピーできないから。
プロセスに価値を乗せるためには、造り手がそこにストーリーを込めたり、なぜやるか(Why)の哲学を示すことが非常に大事。さらに作り手単独では限界があるので、ユーザをファンにしてセカンドクリエイターとして巻き込んで熱量を上げていく必要がある。
ファンがコミュニティになっていけば、ファン一人一人が新しい物語を生み出し、さらに熱量も上がり、新しい人を引きつける。そしてその決あ、多様な物語が生まれ、さらに新しい人を引きつける。そしてその結果、多様な物語が生まれ、さらに新しい人を引きつける...。仕組みとして価値が貯まるので、他の企業やサービスと埋めようのない探し台に生まれてくる。
なぜプロセスに価値があるのか
どうしてアウトプットと同じようにプロセスに価値が出てくるのでしょうか？
現在は多種多様な情報がネットでものすごい勢いでシェアされていて、商品の質だけでは差別化するのは難しい時代です。そのため、今の消費者は「役に立つ」ものよりも「意味のある」ものにより価値を感じるようになりました。
数多くものが存在する中で、「プロセス」で稼ぐことが今後の新しい稼ぎ方になります。なぜなら、プロセスはコピーできないからです。
プロセスエコノミーの重要性
プロセスエコノミーの実践方法を解説する前に、プロセスエコノミーの重要性を詳細に解説します。
まずはプロセスエコノミーの理屈を単に理解するのではなく、感覚としてプロセスエコノミーを捉えていきましょう。
誰だって長年かけて染み付いた価値観をなかなか拭えません。「プロセスで稼ぐなんて邪道」「プロセスを他人に見せるなんておかしい」という反発にあうこともあります。これには日本の学校教育が大きく関係しています。
日本の学校教育は、たった一つの正解に向かって突き進む正解主義にとらわれています。しかし、「これが正解だ」と定義した所で、変化が激しい時代ではその定義自体が変化することもありえます。ならば、修正することを前提にしたほうがいいです。正解を出すことにとらわれずに、β版でもいいからとりあえず出して、数多くの人からフィードバックを受けながら柔軟に修正すればいいです。
途中で方針を変更することを前提とした修正主義こそが、決められた正解のない時代の生き方です。
プロセスエコノミーの実践方法
次に、プロセスエコノミーの実践方法について説明します。
ただ単に商品の制作プロセスをオープンにするだけでは、なかなか人は魅力を感じてくれません。プロセスエコノミーを実践するうえで最も大事なことは、あなたの中にある「Why」(理由)を共有することです。
例えば、誰もが「インフルエンサーになりたい」とYouTubeやInstagramで発信を継続する中、もはや平凡なインフルエンサーは生き残れません。たとえ一時的にフォロワーやチャンネル登録者数が増えても、他の人気者が登場した瞬間たちまち淘汰されていきます。インフルエンサー市場は倍率が非常に高い競争です。そのため、既存のインフルエンサーも一夜にして無価値化してしまう可能性があります。
何千万人がTwitter等のSNSで発信する中、「What」(発信内容)だけでは差別化できません。「What」だけで勝負をする時、YouTubeで言えば中田敦彦さんやマコなり社長などのような知名度の高いプレイヤーとコンテンツの面白さで勝負しなければなりません。これはまだ実績もアウトプットもない私たちにとっては非常に無謀な挑戦だと言えるでしょう。
そのような状態でファンを獲得するには、「What」一本だけで勝負しないほうが賢明です。最も大事なことは、なぜやるかという「Why」の共有です。
プロセスエコノミーの弊害
しかし、本書で挙げられている「プロセスエコノミー」には弊害があります。簡単に言えば、プロセスだけで稼げてしまうと本来の「Why(なぜやるのか・こだわり・哲学)」を逆に見失ってしまうというケースがあります。
例えば、注目を集めるのがとにかく上手な人がプロセスを上手に開示することで実力以上に資金やファンを集めてしまう。すると、どんどんプロセスの刺激を増やしていかないと次第に続かなくなってしまいます。そうすると、より大きなチャレンジを掲げるしかありません。
もちろん、まだ実績がない人が挑戦をする際に、その様子を発信して応援してくれる人を増やしたり、資金を集めたりすることは問題ありません。Twitter等のSNSのフォロワー数や注目が多いと、明らかに集客や資金調達や採用の面で有利なのも事実です。
しかし、「大きなビジョンや夢だけを語り続ける」状態が続くと取り返しのつかないことになります。
実例
実例として、登山家の栗城史多(くりきのぶかず)さんが挙げられます。彼はポーターを雇わず一人きりで行動し、酸素ボンベを携帯せずに単独で登山を行うのが売りの登山家でした。彼は自分の登山スタイルをネット中継で積極的に公開し、数多くのファンを獲得しました。
しかし、彼はエベレスト登山の最中に凍傷で9本の指を失ってしまい、最終的には雪山で遭難して死亡するという悲劇的な最期を遂げました。自己演出に拍車がかかりすぎた結果、ほとんど自殺に等しいような非業の最期を遂げました。
実例からわかること
先程は栗城さんの実例を述べました。周りの人から注目を集める中、外から求められる無謀なチャレンジを継続しなければいけないというプレッシャーに押しつぶされ、そのプロセスが過激化することがあります。その結果、プロセスそのものに自分の人生がコントロールされることになってしまいます。
自分の意志で能動的に行きてきたはずなのに、プロセスエコノミーの中で観客の期待に応えることこそが目的になってしまう。いつの間にか観客が主体になって自分の人生のハンドルを握られた状態に陥ってしまう。
このような状態になってしまうと、自分の行動が他者の目で縛られてしまいます。
具体的なアクションプラン
栗城さんのような悲劇をくり返さないように、私たちにできることは次の2つです。
- 自分の「Why」(なぜそれをやるのか)に立ち返る
- 自分のものさし(価値観)を明確にする
プロセスエコノミーにおいては、他者に自分の人生をコントロールされることが最も恐ろしい弊害になります。自分は何のためにやっているのか、自分の一番大事にしたいものは何なのかを自問自答し、振り返り続けることは非常に大事です。
まとめ：SNSを捨てろ
今回の記事では、SNS時代の必読書『プロセスエコノミー』について軽く解説しました。本書を一言でまとめると、「今の時代はWhyを共有してプロセスで稼ぐ時代である」ということになります。
最後に個人的な補足を入れて今回の記事を締めくくります。それは、「SNSを捨てろ」です。
これを簡単に言えば、SNS単体でプロセスエコノミーを駆使していくのは非常に難しいことを意味します。今の時代は誰もがSNSで情報を発信できます。数千万以上もある競合の中でコンテンツの面白さを競い合って自分をフォローさせるのは非常に困難です。
そのためには、まず「SNSだけでプロセスを駆使して戦わないこと」が非常に重要です。とは言っても何もしないというわけではありません。せめてライティング等の自己表現の練習に使いましょう。
実績もアウトプットもない私たちが最初にやるべきことは、次の2つしかないと思っています。
- 身近な人(生活で最も関わることが多い人)にアプローチ
- アウトプットを積み上げる
私はGitHubやブログ、noteで情報発信していてアウトプットはあります。これからもアウトプットを継続していこうと思います。そして、あるアウトプットが注目されるようになればプロセスを駆使して影響力を高めていこうと思います。
今回の記事はこれで終了です。
参考図書
【経験談】始めて2ヶ月以内に知っておけばよかったプログラミング学習法
おはようございます。Shotaです。
今回の記事では、私がプログラミングの独学を始めてから2ヶ月以内に知っておけばよかった勉強法を5つ紹介します。今回紹介する勉強法は、当時の私がどれもできなかった勉強法になります。
これはあくまで一個人の経験談に過ぎませんが、私の経験談が読者の今後のプログラミング学習の参考になれば非常に幸いです。それでは早速、本題に入りましょう。
知っておけばよかった勉強法5選
公式ドキュメントを読む
1つ目は、公式ドキュメントを読むことです。
公式ドキュメントとは、プログラミング言語、フレームワークやライブラリについてその公式組織が出している文書です。言い換えれば、公式ドキュメントはプログラマー向けに書かれた説明書兼チュートリアルです。
私の場合、プログラミング学習を始めた際は公式ドキュメントをまったく読まずにQiitaやブログ記事を中心に情報をあさっていました。「公式ドキュメントを読まなくても別に苦労しないし大丈夫じゃね？」と思っていました。しかし、それは今考えてみれば間違いでした。
前提として、日本語で書かれている記事の大半は公式ドキュメントのす二次情報になります。そのため、間違った情報や古くなった情報が書かれている可能性が高いです。公式ドキュメントには必ず正しい情報が記載されています。プログラミング学習の質を高めるためには、公式ドキュメントを読むことは必要不可欠です。
ブログやQiitaなどの二次情報に頼らず、自分の力で必要な情報にたどり着けるように公式ドキュメントを読む必要があります。
基本的な文法や概念、専門用語を暗記する
2つ目は、基本的な文法や概念、専門用語を暗記することです。
プログラミングはどうしても専門用語が頻出する分野です。「インジェクション」や「アーキテクチャ」など、初見では意味がわからない用語に遭遇することも珍しくありません。なにかネット記事でわからない専門用語を発見したときには必ず調べる癖を付けましょう。そして、できればその専門用語を暗記してしまいましょう。
あと、アプリやWebサービスに使われているプログラムには基本的な文法や概念に従って書かれています。これらを調べながらプログラムを書くのは手間がかかります。手間を省くためには、プログラミング言語の文法や概念は暗記するようにしましょう。
少しでも調べるコストや手間を省くため、プログラミングにおける基本的な内容を暗記しましょう。
ちなみに私の場合は、都度調べながらプログラムを書いていました。しかも、文法や概念などの基本的な内容をまったく覚えずにプログラムを書いていたので、一つの機能を実装するのに6時間以上もかかってしまいました。
複数の言語やフレームワークに手を出す
3つ目は、複数の言語やフレームワークに手を出すことです。
大前提として、アプリやWebサービスは複数の言語やフレームワークで成り立っています。一つの言語、あるいはフレームワークだけではなくいろんなものに手を出しましょう。
例えば、掲示板アプリを作る際には、HTML/CSSやJavaScriptだけではなくPHPなどのバックエンドの言語を扱えるようにする必要があります。自分が開発したいものに応じて複数の言語やフレームワークに手を出しましょう。
YouTubeでコーディングの動画を見る
4つ目は、YouTubeでコーディングの動画を見ることです。この勉強方法は独学を始めてから2ヶ月以内に最も知りたかった勉強方法です。
YouTubeには数多くの有益なコンテンツが無料でアップロードされています。あと、動画で説明されているので、テキストよりも内容を理解しやすくなります。英語の情報が転がっていることが大半ですが、動画で説明されるプログラムを見様見真似で書いても問題なく動きます。
ちなみに本記事でおすすめするプログラミング解説チャンネルを以下に貼っておきます。プログラミング学習の質を上げるためにはチャンネル登録しておくことを推奨します。
GitHubを活用する
5つ目は、GitHubを活用することです。これを具体的に言えば、GitHubのコミット数で自分のプログラミングの勉強量を把握することになります。
私の場合、自分で作成したプロジェクトを全てGitHubにアップロードしてコミット数で自分の学習量を把握しています。
このように自分の学習量を可視化することで、自分の開発量を数値で把握できます。コミット数が多ければ多いほど、プログラミング学習に注力した証拠になります。毎日自分のGitHubを確認して、「今日はけっこうコミットしたな～」とか「ここ最近コミットしていない...」などということを確認して学習進捗を管理しています。
この方法は自分の学習量を数値で認識できるので、非常におすすめな学習方法です。実装の方法は以下のプロジェクトをご参照ください。
まとめ
今回の記事では、私はプログラミング独学を始めて2ヶ月以内に知りたかった勉強法を詳細に解説しました。
今回の記事はこれで終了です。
これだけは覚えておきたい、重要IT用語10個を詳細に徹底解説
おはようございます。Shotaです。
今回の記事では、主にプログラミング学習やWeb開発をメインに、これだけは覚えておきたい重要なIT用語を10個解説していきます。
絶対に覚えておきたい用語5選
フロントエンド(frontend)
フロントエンドとは、Webサービスやシステムのうち、利用者に対する表示や操作の受付、他のシステムとの入出力など、外部と直接やり取りを行う要素のことを指します。わかりやすく言えば、UIなどユーザが目に見える部分がフロントエンドになります。
主にHTMLやCSS、JavaScriptを組み合わせてフロントエンドを実装していきます。この部分を運用・開発する技術者を「フロントエンドエンジニア」と呼びます。
バックエンド(backend)
バックエンドとは、Webサービスやシステムのうち、ユーザからは見えない所でデータの操作や保存などを行う要素を指します。バックエンドはフロントエンドからデータや指示を受け付け、計算や返還などの処理を行ったり、ストレージやデータベースなどでデータの保存を行います。
Webアプリでは、サーバやその背後で動作するデータベースなどがバックエンドに当てはまります。
バックエンドを担当する言語には、主にPHP、RubyやPythonが挙げられます。特にPHPはWeb開発に特化していて、HTMLとの相性が抜群です。
サーバ(server)
サーバとは、コンピュータネットワークで他のコンピュータに対し自分の持っている機能やサービス、データなどを提供するコンピュータのことです。
原則、個々のサーバ機やサーバソフトには外部に提供する機能やサービス、対応しているデータ形式や通信のルールが決まっています。「Webサーバ」「ファイルサーバ」のように、提供する機能などの種類を指して「〇〇サーバ」と呼ばれます。
レスポンシブデザイン(responsive design)
レスポンシブデザインとは、様々な種類の機器や画面サイズに画一のファイルで対応するデザインを意味します。
Webサイトをパソコンやスマートフォン、タブレット端末など複数の機器や画面サイズに対応させる際に、単一のHTMLファイルを用意してすべてのデバイスに同時に送信します。複数のファイルを用意するときと比べてデザインや機能の自由度は大きく下がりますが、すべての機器に同じ内容を表示できるのが最大の特徴です。
データベース(database)
データベースとは、複数の主体で共有、利用したり、用途に応じて加工や再利用がしやすいように一定の形式で作成・管理されたデータの集合のことです。広い意味で考えると、辞書や電話帳など、人が紙に書いてまとめたものなどもデータベースに該当します。
IT業界におけるデータベースは、主にコンピュータ上で作成、保管されて専用のソフトウェア(データベース管理システム)によって管理されるものを指すことが多いです。
重要度はそこまで高くないが、覚えておいて損はない用語5選
フレームワーク(framework)
フレームワークとは、骨組み、骨格などの意味を持つ英単語です。IT業界におけるフレームワークには主に以下のような意味で用いられます。
- 問題解決のための概念や方法を体系化した枠組み
- ソフトウェアを開発する際に土台となるプログラムの部品
2.の場合、以下のように分類されます。
規約に従ってフレームワークの一部を改変したり、自分が必要とする機能や処理を記述して追加することで、少ないコード量で効率的にソフトウェアを開発できます。
デバッグ(debug)
デバッグとは、コンピュータプログラムにある欠陥を修正することです。
プログラムが開発者の糸に反して誤った動作をする際に、そのような動作を引き起こすプログラム上の欠陥をバグ(bug)と呼びます。テストで発見された誤作動や不具合について、その原因やプログラム上での位置を探索・特定し、意図したとおりに動作するように修正する作業をデバッグと呼びます。
デバッグでは、最初にバグがプログラムのどこに潜んでいるのか探索が行われます。
原因が特定されると修正されますが、外部のシステムやプログラムの別の箇所がすでにそのバグが発生する前提で作られてしまっている場合もあるので、修正をあえてしないという選択肢もあります。
ソースコード(source code)
ソースコードとは、プログラミング言語などの人間が理解・記述しやすい言語やデータ形式を用いて書き記されたプログラムです。プログラムに限らず、人工言語や一定の規約・形式に基づいて記述された複雑なデータ構造の定義や宣言などのことをソースコードと呼びます。
ソースコードは多くの場合、人間がコンピュータを操作して文字を入力し記述していきます。この作業や工程をコーディング(coding)と呼びます。しかし、必ずしも人間が記述するとは限らず、ソフトウェアが自動で生成することもあります。
市場で出回っている商用のソフトウェアでは、ソースコードを企業秘密として非公開に設定し、人間が読めない中間コードやオブジェクトコードによるプログラムのみを利用者に提供することが多いです。
しかし、誰でも自由に入手、利用、改変、再配布などができるようにしているものもあります。そのようなソフトウェアはオープンソースと呼ばれています。
SQL(Structured Query Language)
SQLはデータベースを操作するための言語です。業界標準として幅広く活用されており、様々なデータベース管理システムで活用されています。
原則、データベースを操作するにはSQLを習得する必要があります。
チャットボット(chatbot)
チャットボットとは、短い文字メッセージをリアルタイムに交換するチャットシステム上で、人間の発言に対して適切な応答を返し、擬似的に会話できるソフトウェアです。
2010年代後半から実用化が進み始め、企業のWebサイトでユーザの質問に回答したり、顧客のサポート窓口として問い合わせや要求を取り次いだりするシステムが導入されています。あと、メッセンジャーやSNSなどと連携して、人間のスタッフのように振る舞って情報やサービスを提供するシステムも開発されています。
まとめ
今回の記事では、以下の10個のIT用語を解説しました。
今回の記事を参考に、ITの専門用語に対する理解を深めていただければ幸いです。今回の記事はこれで終了です。
初心者向けにSQLiteを簡単に解説
おはようございます。Shotaです。
今回の記事では、プログラミング初心者向けにSQLiteについて簡単に解説します。
重要な予備知識
本題に入る前に、次の言葉について軽く説明を入れます。
SQL(Structured Query Language)
SQLとは、データベースを管理、操作するために使用されるデータベース言語を意味します。プログラミング言語とはまた別なので注意しましょう。
SQLは国際標準化機構で規格化されているので、MySQLやPostgreSQLなどの世界的に有名なデータベースで利用できます。
RDBMS(Relational DataBase Management System)
RDBMSとは、リレーショナルデータベースを管理するためのソフトウェアを意味します。リレーショナルデータベース(RDB)とは、データを表形式でまとめたデータベースを指します。あくまでデータベースの一種に過ぎません。
SQLiteとは
SQLiteはオープンソースでパブリックドメインの軽量なリレーショナルデータベースです。SQLと名前が似ているので、データベース言語だと思われる人も少なくないと思いますが、SQLiteはデータベースソフトウェアの一つです。
SQLiteはサーバにインストールするのではなく、既存のアプリケーションに組み込んで使います。
データベースとは、集めたデータに対して検索・挿入・更新・削除などを効率良くできるように整理されたものです。データベースは大規模なシステムで利用されるというイメージを持つ人も少なくありませんが、SQLiteはインストール不要で簡単にデータベースを作成できます。
SQLiteの特徴
パブリックドメイン
SQLiteはパブリックドメインなので、誰でもソースコードを自由に改変したり再利用したりできます。
軽量
SQLiteは軽量です。さらに、消費メモリも少ないので処理性能が低いデバイスでも使用できます。
マルチプラットフォーム
SQLiteはマルチプラットフォームという特徴があります。SQLiteは外部ライブラリへの依存性が低く、パソコンやサーバだけではなくスマホなど様々なOSに対応できます。
設定が不要
SQLiteは設定いらずで使えます。他のデータベースの場合、設定ファイルを準備したり、プロセスの起動や停止、データベースインスタンスの設定を操作する前に行う必要があります。
しかし、SQLiteはサーバのライブラリとして使えるので面倒な設定を行う必要はありません。
データ型を指定しない
SQLiteはデータ型を指定しないので、一つのColumn(列)に様々なデータ型の値を格納できます。
SQLiteのメリット・デメリット
メリット
SQLiteは無償で利用でき、かつ高速で動作するのが最大のメリットです。また、データを一つのファイルに格納できるので、バックアップを簡単に行うことができます。あと、SQLのデータベース言語を利用できるのもメリットと言えるでしょう。
それだけではありません。SQLiteで作られたデータベースは単一のファイルにまとめられ、利用者がメンテナンスを行う必要がないのもメリットです。
デメリット
しかし、SQLiteにもデメリットがあります。主に以下のようなものが挙げられます。
- パスワードがない
- 複数の同時書き込みがない
- 大規模開発に向いていない
これらの機能はSQLiteとは別でプログラムを書いて実装しなければなりません。
あと、SQLiteはサーバとしてではなくアプリケーションに組み込んで利用される軽量のデータベースです。個人開発や小規模の開発には向いていますが、大規模開発には適さないので注意しましょう。
SQLiteの基本的なコマンド
▼インストール
sudo port install sqlite3
▼接続
sqlite3 test.sqlite3
▼終了
sqlite> .exit
▼データベース一覧の表示
sqlite> .databases
まとめ
今回の記事では、SQLiteについて詳細に徹底解説しました。
今回の記事を参考に、SQLiteについてより理解を深めていただければ幸いです。今回の記事はこれで終了です。
参考サイト
「バックエンドがきつい...」と言われる理由5選｜向いている人の特徴も同時に解説
おはようございます。Shotaです。
「バックエンドはきついって本当？」
「バックエンドに向いている人はどんな人なんだろう？」
このように考えている人も少なくないでしょう。
今回の記事では、そこでバックエンドがきつい理由を5個解説していこうと思います。ただきつい理由を解説するだけにとどまらず、それに合わせて向いている人の特徴を4つ紹介していこうと思います。
それでは早速、本題に入りましょう。
バックエンドがきついと言われる理由
ミスが許されない仕事
バックエンドの役割は、ユーザの目に見えないシステムの開発です。バックエンドを担当するプログラマーが間違ったプログラムを書いてしまうとシステム障害になるので正確なコーディングが求められます。
間違ったデータの処理をすればシステム障害になるので、バックエンドはミスが許されません。
プログラミング言語やデータベースの知識など覚えることが多い
バックエンドは業務範囲がフロントエンドよりも多いので、プログラミング言語だけではなくデータベース等の幅広い知識が要求されます。
技術の変化が激しい
バックエンドを必要とする技術は数多くあります。その技術は進歩しており、バックエンドをメインで活動する際には常に最新技術を身に着けておく必要があります。
バックエンドはシステムを構築する上では非常に重要な部分です。持っている知識が古ければシステム全体の質に影響を及ぼすことがあります。
バックエンドの仕事内容は技術の変化が激しいので、スキルを常にアップデートしておく必要があります。
慢性的な人手不足
経済産業省が2019年3月に公開した「IT人材需給に関する調査」によれば、バックエンドを含むIT人材が不足していることを示唆しています。
今後はIT企業だけではなく、あらゆる企業がテクノロジーを活用する傾向が強まるのでさらなるプログラマーの不足が予想できます。
プログラマーの中でも、バックエンドの領域はネットワーク、サーバやデータベースに関する知識やスキルが必要になるので人材が育ちにくい傾向があります。そのため、慢性的な人手不足の状態に陥っているのです。
単価が高い分、プレッシャーがある
バックエンドは需要が高い仕事なので、もともと単価が非常に高いです。これは最大の魅力ですが、単価が高いということはその分求められている質も高いことが予想されます。
そのため、納期までに仕事を終了させるプレッシャーが常につきまといます。その結果、夜遅くまで仕事が終わらないなどということはよくあります。
バックエンドに向いている人
バックエンドの領域は非常に地道で、向いているのかどうか悩んでいる人も少なくないでしょう。
そこで、本章ではバックエンドに向いている人の特徴を5個紹介します。ただし、これはあくまで一個人の見解だということはご理解ください。
ミスなく作業を進められる
大規模開発の場合は、一つのエラーやミスがプロジェクト全体に大きな影響を与えることは少なくありません。
そのため、バックエンドに向いている人は慎重な性格でミスなく仕事を進められる能力がある人になります。
作業に没頭できる
バックエンドの領域の仕事はサーバシステムを構築したり、長時間PCと向かい合う作業が多いです。そのため、作業に打ち込める集中力が必要になります。
これはあくまで私の見解に過ぎませんが、作業に没頭できる人はプログラマーに向いている人の特徴だと考えます。
バックエンドは仕事の構造上、長時間パソコンの画面に向き合う作業が必要になるので、作業に没頭できることは必要なのかもしれません。
IT技術の勉強が好き
バックエンドがシステム構築で関係する分野は一つではありません。対応範囲がサーバやデータシステムなど幅広いので、習得しなければならない技術も多岐にわたります。
そのため、IT技術の勉強が好きな人は向いているかもしれません。より具体的に言えば、YouTubeでプログラミングに関する海外の動画を見たり、新しく習得した技術を使いこなせる人が向いているかもしれません。
ちなみに、私の場合は最新技術をキャッチアップしたりバックエンドに関する技術を学んだりするために次のことをやっています。
- YouTubeでfreeCodeCampの動画を見ながらコーディングする
- 自分が学びたい言語に関する技術書を買う(主にPython、TypeScriptやフロントエンドフレームワーク中心)
- CodeZineで最新の技術に関するニュースを毎日チェックする
こちらのやり方は参考になれば非常に嬉しいです。
裏方の仕事が好き
バックエンドの仕事内容は、サービスを利用する側からは直接には見えづらい仕事です。そのため、目立たない所で社会を変えていく裏方の仕事が好きな人にとってはうってつけの仕事と言えるでしょう。
バックエンドはひたすらコードを書くだけという地道な作業がメインです。ユーザの目に見えない部分を構築する仕事が多いので、裏方の仕事が好きな人には向いている分野だと思います。
WEBサービスのシステムに興味がある
バックエンドエンジニアは、システムのバックエンド領域を担当します。そのため、次のような点に興味がある人のほうが、バックエンド開発の知識やスキルを習得しやすいと思います。
- コンピュータが動く仕組み
- システムがどのように動くのか
- サーバはどのように動くのか
システムの裏側に興味があると、日常生活の中でもバックエンドに関するアンテナが高くなるので、最新情報などもキャッチアップしやすいです。
まとめ
今回の記事では、「バックエンドがきつい」と言われる理由を5個紹介しました。それと同時に、個人の見解ではありますがバックエンドに向いている人の特徴を5個紹介しました。
長くなりましたが、今回の記事はこれで終了です。
