どうも7noteです。画像の上に文字を表示させたい時の方法

こんな感じに写真の上に文字が乗ったデザインを作ります。

作り方

作り方は、画像と文字をくくる親要素を作り、position指定で好きな位置に文字をもってきます。

index.html

<div class="onimg">
  <img src="sample.jpg" alt="画像名">
  <p>画像の名前が入るよ</p>
</div>

style.css

.onimg {
  width: 300px;        /* 画像の横幅（自由に指定） */
  position: relative;  /* 帯の表示位置の基準とする */
}

.onimg img {
  width: 100%;
}

.onimg p {
  color: #fff;
  text-align: center;
  width: 100%;         /* 画像の幅に合わせるため */
  padding: 10px 0;
  position: absolute;  /* relativeの要素を基準にする */
  left: 0;             /* 基準からみて左寄せ */
  bottom: 0;           /* 基準からみて下寄せ */
  background: rgba(0,0,0,0.5);  /* 半透明の背景。 */
}

解説

親要素の.onimgに対してposition: relative;を指定します。
そのうえで子要素のpに対してposition: absolute;を指定することで、画像の上に半透明の背景付きで文字を表示することができます。

また、半透明にする時にopacityを使ってしまうと文字も半透明になってしまうので、rgba()で半透明の背景を指定します。
rgba()は左からrgba(赤色,緑色,青色,透明度)の順番で指定します。今回は黒の透明度50%にしたのでrgba(0,0,0,0.5)となります。

おそまつ！

~ Qiitaで毎日投稿中!! ~
【初心者向け】HTML・CSSのちょいテク詰め合わせ

自己紹介

私は、平日は会社に勤務している２３歳のサラリーマンです。
自動車のエンジン関係の仕事に従事しており、
仕事では、会社既存のソフトを扱ったりエクセルで資料作ったりする程度。
当時、キーボードは人差し指と中指のみで入力していたくらいで
パソコンはあまり得意ではありませんでした。

そんな男性のWEBアプリ制作までの記録です。

.
当記事は、WEBアプリを初めて作成される方に向けて参考になればと思い書きました。
技術的なことは、ほとんど載せていません。
「へー、こんな感じで取り組んだんだー」　程度に見ていただければ幸いです。

なんでTECH:CAMPに入ったの？

１度、プログラミングの独学に挑戦したのですが、１週間で挫折してしまったからです。

2019年の8月に、あるプログラミングに関する動画を何気なく見たときに、
「あれ、これ俺にも出来そうじゃね」
とか動画を見ただけで「できそう」と勝手に思ったのが始まりです。

書店にあったJavaScriptの参考書を購入し、
最初のページからちまちまと取り組んでいきました。
学習1、2日目は、今までで知らなかったことを手を動かしながらできる感覚が
面白いと感じていたのですが、3、４日目からだんだんとやる気がなくなっていきます。

結局、人生初のプログラミング独学は、１週間で幕を閉じてしまいました。

.
それから2020年3月、マコなり社長の動画を何本か見た時に
「プログラミング学習、再開してみようかな」と思っていたのですが、
なかなか思い切ってやってみよう！と言う気にはなれませんでした。

しかし、この動画が決め手となり、入会を決意します。
人生おもしろくない人が「今すぐ」やるべきこと

動画の中で「ポチる」と言う言葉の矢が胸に刺さり、
刺さった勢いでTECH:CAMPのスクールまで飛んで行きました。

.
ちなみに私が入会したのは
プログラミング教養コース です。
エンジニア転職コース とは別なので
ガチで転職を考えている方は下記の記事を参考にしていただければと思います。

テックキャンプに通ってエンジニア転職した人の感想

WEBアプリ制作までにやったこと（基礎〜応用）

基礎カリキュラム

TECH:CAMPのWEBコースにあるカリキュラムを順番に取り組んでいきました。
やってきた言語は大きく以下の３つです。

• HTML
• CSS
• Ruby(Ruby on Rails)

これらをカリキュラムの順番通りに進めていきました。

TECH:CAMPでは「学習進捗表」という、
1日の学習時間の記録やカリキュラムの進捗を「見える化」したシートが用意されています。
大体どのくらい取り組んだか振り返ってみると以下の通りです。

• HTML/CSS 　　　　:15+10　=　25時間
• Ruby(Ruby on Rails) :28+49　=　77時間

足算になっているのは、カリキュラムを２周したからです。

１周目は「プログラミングはこんな感じなんだー」
という感じで、さらっと流す程度に取り組んでいきました。

と、言いたかったのですが、これは１周目 後半の話し。
実は、１周目の前半は一言一句覚えようとなかなかクレイジーなことをしていました。

何をしていたかというと、
「これは覚えられそうにないな…」と思ったことをメモ帳に書き込んでいたのです。

画像をよくみると、左上のスクロールバーが豆粒になるくらい
書き込んでいました。

「え、別に何の問題もないんじゃ・・・」
.

断言します。

『メモ、ちょーいらん』

メモと言うより、「覚え書き」と言う方が適切ですかね。
義務教育でやってきた、先生が黒板に書いたことを
そのまま書き写すような行為は、無駄だと言うことに気付きました。
考えてみれば、昔書いたノートを見返すのは、テスト前くらいで
毎回、見返すことって全くなかったです。
このメモは５ヶ月ぶりに開きました。（ﾅﾝﾃｺｯﾀー）

書いてあることを写すやり方は、
「あー勉強したー」と学習の充実感を味わえるのですが、
記憶の定着が少ししかできないことに加え、
見返さないので、意味がない行動だったと言えます。

.
では、どのようにして覚えていたか？

私の場合は、コードを書きながら覚えていきました。
例えばこんな感じです。

「スクレイピング」を覚えようとした時…
（ウェブサイトから情報を取得し、その情報を加工して新たな情報を生成すること）

このように、ある機能や仕組みについて覚えようとするときは、
実際にやってみて、それがどういうものなのか「やりながら、覚える」ようにしてきました。
実装して「できた」という感覚に、できたことの概要をリンクさせるイメージです。

１周目の後半からは、カリキュラムに書いてあることを２〜３割程度わかればいいや　
と言う感覚で進めました。

.
２周目は、
１周目で理解できていなかったところを復習していきました。
２周目はざっくりとしたことは覚えているから、スムーズにいけるだろう
と思っていたのですが、そうはいきませんでした。

「わからないところありすぎて、全然理解できでないじゃん…」

前、覚えたところを、もう忘れてる。
そんな自分を情けなく思う時がありました。

このようにネガティブに思っていた時は、
学習の意欲が沸きにくくなり、思うように進まない日も…

TECH:CAMPには、メンターと呼ばれる、学習のコーチが学習のサポートだけでなく、
進捗のサポートや学習の悩みを解決する手助けをしていただけます。

そのメンターに相談をして、自分なりに導き出した解決策は、

「わからないところ多くてもいいじゃん、人間だもの」
と考えることです。

わからない「もやもや感」から生まれるストレスは、これもまた義務教育でやってきた
「テスト対策の暗記学習」が根付いていたからです。
覚えていないと点数が取れない　のと似たように、
覚えていないと学習が進まない　と思っていたことが原因でした。

プログラミングはわからないことがあっても
「カンニングOK」なのです。

わからないことは頭を抱えてうーんって悩むよりも
Googleでカンニングをして解決する方が時間の効率化と悩む時間の削減に繋がります。

もっと気楽に学習してもいいと言うことを学びました。

応用カリキュラム

ここでは、カリキュラムで用意されたWEBアプリのお手本を参考にしながら
なるべく自分の力で実装する学習をやってきました。

学習時間は、復習も兼ねて約１３５時間かけてカリキュラムを終えました。
応用という言葉通り、基礎よりも内容が難しくなり、
出来た時の嬉しさ２倍に対して、悩む時間２倍といった感覚です。

悩む時間が２倍と言うことは、メンターに質問することも２倍になった？
かと言うと、逆に1/2に減りました。

応用カリキュラムに入ってからは、エラーの原因が大体これかなーと
「仮説」をたてて解決できるようになるからです。

エラーの解決をどのようにしてきたか　に関しては、
この後のWEBアプリ制作過程の中でお伝えします。

基礎、応用学習を終えて

ここから、いつか実現させたかったWEBアプリの制作に取り組みました。

私が制作したオリジナルWEBアプリはコチラです。
Unsung:hero

どんなWEBアプリかというと、「企業を簡単に紹介する」WEBアプリです。
Wikipediaのページから指定した物だけをスクレイピングしてデータベース（以下DBと省略）
に保存、一覧に表示させたり、編集、検索したりできます。

WEBアプリを作る前に

WEBアプリをつくる前に、
そもそもの目標（この学習を通してどうなりたいか）を振り返ってみます。

私の目標は２つありました。

1つは、「自分の手でプログラミングをして何か作ってみたい。」
もう1つは、「学んだスキルを仕事に活かしたい。」

この2つの目標が、プログラミングに取り組む「原動力」でもありました。
パソコンに向かった時にいつも「目標」を思い出していました。

私の場合、
「このスクレイピングってやつを使いこなしたら、めっちゃいいもの出来そう！」
「このアプリ制作で学んだスキルが、きっと誰かの役に立つアプリやツールが作れる！」
と言った感じですかね。

実を言うと、目標ではないのですが、
目的に「モテたい」という思いがちょっとあったのも事実です。（←おい）

（心の声）
.
「プログラミングできる俺、超イケてる。」
「スタバでMac広げて、ブラインドタッチしてる俺、まじかっこうぃぃ」

あれ、なんでWEBアプリなんか作っているんだっけ？
とやっていることの目的を見失ってしまうことがあります。
主に解決できないエラーにつまづいたり、明確なビジョンが浮かばなかったり
した時がそうだと思います。

私は、行き詰まったとき、自分のなりたい姿を思いだしていました。

目標のイメージは、創作活動の「原動力」に繋がります。

どんなWEBアプリを作るか

ここからは、どのような制作過程で取り組んだかまとめました。
.

最初から、これを作りたい！とアイデアがあればこのステップは問題ないですが、
０から作ろうとするといろいろなことを考えてしまいます。

「途中で挫折しないように、自分が製作できる程度のWEBアプリにしよう！」
「でも、自分ができる程度ってどんな程度？　これなら？　あれなら？」

頭がガッチガチに固まってたので、メンターに助けを求めた時に
このような回答が返ってきました。

『作りたいもののアイデアがない時は、身近な問題解決に着目するのがよいと思います。』

例えば、
「近くのキャンプ場は行きつくしたから、穴場のキャンプ場とかないかな…」
→と思っている方向けに、キャンパー同士で情報交換ができる掲示板のサービス

「明日は彼女とドライブデート！　でも、俺って流行りの音楽とか良くわからないからな…
流石に俺の好きなオペラとか流したら引かれるよな…　どうしよう…」
→と困っている方には、Youtubeから流行りの音楽を自動で取り込み、
　シャッフルして再生するサービス

と、日常の中で起こりうる問題や困りごとを解決するものに着目します。　

.
.
なるほど…

私の場合は、「あれ、この企業って何してる会社だっけ？　知りたーい」
と思うことがあったので、簡単に企業を紹介、閲覧できるWEBアプリの制作に着手しました。

もし、アイデア出しの段階で躓いている方は、
『困っている人の役に立ちそうなもの』を作ってみてはいかがでしょうか？

私の作ったWEBアプリは正直、人の役には立っていません。
ですが、もしこれを使ってくれる人がいて、何かの役に立っているところを想像しながら
取り組むことで、モチベーションの維持、向上に繋げてきました。

設計

どのようなアプリにするか考えがまとまったら、画面の設計に移りました。

まずは、お手本を探す

「画面の設計かー。とりあえず、雰囲気を掴むためにいろんなウェブサイト見て回ろう！」

…うん
.
.
…なるほど、

「たくさんアリスギィ！！」

初心者だった私には、参考にするものが多過ぎて
何を参考にしたらいいかわかりませんでした。

ここで、問題だったのが『複雑なサイト』ばかりを参考にしていたことです。
取りあえず、超シンプルなサイトを参考にすることにしました。

ちなみに、私が参考にしたサイトはコチラです

• シングルページレイアウト(構成がシンプル　復習用)
• Webの基本レイアウトまとめとサンプルコード（どんなレイアウトにしたいか）
• SANKOU!（レイアウトの構想が決まったので、お手本にしたサイト）

.
私は、設計のお手本探しの段階では、

• 自分が制作できそうなシンプルなサイトを調べまくる。
• 作れそうなのレイアウトのイメージが決まったら、参考にするサイトを１個に絞る。

という流れで取り組みました。

参考にするサイトを１個に絞った理由としては、
「あ、このサイトお洒落だしここを取り入れたいな！」
「うわ、この写真が動くやつかっこいいやん！　これもいいなー」

とお手本にする候補が定まらなくて、めちゃくちゃ時間が掛かったからです。
決めるのはあくまで「大まかなレイアウト」です。

…細かい機能は後から追加できることに、途中で気づきました。

レイアウトを紙に書き出す

レイアウトのイメージが思い浮かんだら、整理しやすくするためにアウトプットが重要です。
デザインツールやワイヤフレームを作るアプリを活用してみようと思ったのですが、
すぐに取り掛かりたかったので、紙に書き出すことにしました。

写真のように、紙1枚につき、1つの画面を書いて整理していきました。

データベースの設計

まず、アプリを制作する前にどんなデータが必要か整理しました。

1度廃案にしたWEBアプリのデータベース設計時につくった
　必要になりそうな情報リストです。
（紹介したWEBアプリの設計図はほとんど描いていなかったので、これで勘弁してください）

これは、キャンプ道具のレビューアプリの構想なのですが、
どんな情報が必要になるかまとめると以下の通りです。

• アプリに登録したユーザーの情報
• キャンプ道具の情報
• キャンプ道具に対する各ユーザーからのレビュー（評価☆）情報
• キャンプ道具に対する各ユーザーからのコメント情報

このように、どんな情報が必要になってくるか、どんな情報があったらユーザーは嬉しいか
紙やPCのメモ帳になどに「言語化」して書き出していきました。

必要な情報を整理

ここでは、グループ分けをして

例のキャンプ道具レビューアプリには大きく「キャンプ道具」「ユーザー」「レビュー」
でまとめられます。

それぞれのテーブルにどんなカラムが必要になるか考えていきました。


今まで上げてきた情報の関係性を紐付けしていきます。

テーブル同士の関係性をまとめて、テーブル設計を完成させました。

プログラミング（HTML、Ruby篇）

いよいよ、ぽちぽちタイムがやってきました。
振り返ってみれば一番問題に遭遇したのはこの時だったと思います。

「これはうまくいったな」と実装、テストしては”エラー”
「これで解決したな」と修正しては”エラー”
エラーエラーエラー…

まるで、ジャイアンに殴られるかのように「ボッコボコ」にされました。

綺麗なジャイアンが言っている通り、エラーの連発で辛かった日は指の数じゃ収まりきらず、
心が折れかけることがありました。

そんな中でどのようにエラーの解決に立ち向かったか、
.

いろいろやった結果、大きくこの3つの方法で解決していきました。
やっていった手順は以下の順番通りです。

１、エラーメッセージの解読、検索方法を工夫し原因を探る
２、teratail、Twitterを活用して助けを求める
３、直接人に会って助けを求める

１、エラーメッセージの解読、検索方法を工夫し原因を探る

エラーメッセージに遭遇した時は、ラッキーです！
なぜなら、どこが間違っているのか、ちゃんとヒントを教えてくれるからです。

でも、エラーメッセージさんが「この列のここが間違っているよ」と教えてくれても、
「こんなに英語いっぱい表示されても、悪いかわからんわい！！」と最初はよく思っていました。

まあまあ、落ち着いて。
まずは、エラーの読み解き方や接し方に関する情報を参考にして向き合うことにしました。

下記のリンクに参考にさせていただいた、エラーの解決に役立つ記事を載せておきます。

• Ruby のエラーメッセージを読み解く（初心者向け）その 1
• [初学者]よく起きるエラー 〜syntax error, unexpected end-of-input, expecting keyword_end〜
• 【Ruby on Rails】 エラー 読み方 解決 〜4つのポイント〜
• エンジニアは検索力が大事。プログラミングスキル向上にググり力は必須です。

エラーの対処のほとんどは、これで解決していきました。

最初は、エラーに苦手意識があったのですが、
日々、原因探しをこなす内に、ある変化が起きてきます。

ある日、エラーが発生しました。
.

「よっしゃ！エラーが来たぜ！　今日はどんな子が悪さをしてるんだ〜？　うへへへぇ…」
「おらあああああああ！！　貴様だな！！　俺は見逃さないぞ！！　ううぃいいいいっ！！」

そうです。

エラーを見つけると興奮する変態になりました。

２、teratailを活用して助けを求める

しかし、自分の力ではどうしても解決できなかったこともありました。

何かいい解決方法がないか探していた時に、teratailに出会います。

.
teratailは本当に凄いんです！
脳味噌が沸騰するくらい考えて調べていたことを
1日も掛からない内に、的確な回答と問題解決方法が返ってくるのです。

人生で初めての投稿で緊張しながら、投稿内容に不備がないか何度も何度も確認し
1日分のエネルギーを込めて押した「投稿ボタン」

数時間後、teratailから通知が来て、回答欄のコメントが目に入った時、
「こんなに優しい世界があったんだな…」
と天にも昇る気持ちになったのを今でも覚えています。

この経験から、「自分で解決できないことは人に頼ってもいい」
と言うことを学びました。

正直、投稿する前は恥ずかしい、怖いと言う気持ちがあり、投稿をためらっていました。
過去に投稿されていた、ある質問の回答を目にした時、
「調べてください。」「理解していますか？」という回答もあったからです。

私は、思い切って投稿することを決心をしました。
解決しなければ、前進しないと思いました。

.
(心の声)
「ああ　神よ、この無知なわたくしに御慈悲を…」
「ggrksとか　どんな冷たい言葉もご褒美として受け止めます。」
（↑ちょっとこれは考えすぎ）

実際に、質問をしてみると指摘を受けることもありましたが、
問題の解決に必要な情報を、もう少し詳しく教えてほしいということがほとんどでした。

質問に答える側の立場になって
「こんな質問だったらスムーズに回答できそうかな」と
考えて質問することを、普段の仕事でもこの気持ちは常に持っておこうと思いました。

もし、悩み事があったら１度teratailを使ってみてください。

私は人に何かを伝えることは得意な方ではありませんが、
参考に私の投稿一覧を載せておきます。
goffee555

３、直接人に会って助けを求める

この解決方法は、本当にいきづまった時の最終手段としていました。
私の人脈だと、プログラミングをやっている友人や先輩が近くに居なかったため、
メンターに頼るしかありませんでした。

初めから、メンターに質問することも最初の頃は考えていましたが、
「相手の立場になってこんな質問だったら回答しやすくなるかな」と一度思考します。

思考する際にも、紙に書き出して考えをまとめていきました。

紙に書き出すことは、以下のようなことです。

• 何をやっていた時にエラーが出たか
• どんなエラーコードが出力されていたか
• エラーの内容に基づき、どんなことを調べたか
• 調べたことを実施した結果
• 「もしかしたらAを操作したから、影響をうけるBが問題なのでは」というような仮説

このように、とりあえず考えつくことを言語化することで、思考を整理させていきました。

思考の整理ができたら、メンターに質問をしていきます。
私はこのような流れで質問をしていきました。

▷ホニャララさん、今〇〇を実装しているところでエラーが発生して困っています。
（やっていることの認識を一致させる）

▷××をインストールした後に、サーバーを起動をしました。
（エラーが起きる前と後の状態を伝える）

▷そしたら、このようなエラー文が出力しました。
（エラー文の内容を認識してもらう）

▷エラー文から〇〇を検索して、〇〇を操作しましたが解決できませんでした。
（やったことを報告する）

▷今日1日中、解決できずに困ってて、辛いです。どうか、みてもらえないでしょうか？
（本当に困っている顔で伝えると効果抜群！）

この質問の仕方だと、まだまだ甘いところもあると思いますが、
「相手の理解が追いつかない状態をつくらない」
ことを質問する前に意識していました。

これを意識するのには、
物覚えが良くなく、人の話を最後まで理解できない私だからこそ、
「理解に徹してもらえるコミュニケーション」をしないといけないと思っていたからです。

例えば、Siriに
「ヘイ、Siri！　天気。」と聞いたら、
「キョウノテンキハ、ハレ　トキドキクモリ。サイコウキオン２８ド…」と返ってきますが、

人に聞く場合は
「太郎！　天気。」と聞いたら、
「は？」って返ってくること間違い無いですよね。

今日の天気という質問の中に、いつの？　どこの？　なんで？と
いろいろ情報が不足していていることが問題ですよね。
または、天気を聞き間違えて　元気？　と聞きとれられて
「うん、元気！」と返ってくることもあると思います。（Siriも例外でない）

このような日常的なコミュニケーションでも認識のズレを少しでも減らすためにも
「理解に徹してもらえるコミュニケーション」は今後も続けていきます。

プログラミング（CSS篇）

CSSの実装に関しては、モヤモヤを乗り越えるまでが結構大変でした。
そのモヤモヤというのは、
「正しい実装の方法がわからない」ことです。

例えば、usersテーブルにskillという名前のカラムを追加する場合は、

$ rails g migration AddSkiliToUsers skili:データ型（stringやtextなど）
$ rails db:migrate

というように、決まったやり方があるので、なんとかできるのですが、

CSSは「これが正解」というものがないので最初はあたまピヨピヨ状態でした。
例えば、要素を横並びにさせたい時の例です。

下記の方法で実現できます。

• float
• inline-block
• table-cell
• flexbox

「いや、どれ使ったらいいんですか！？」
とにかく、やってみないことには進まないので、適当にやってみました。

.
.
.

すごい、嫌がらせをするメニューバーができました。

試行錯誤しているうちに、CSSの実装は何とか完成させることはできたのですが、
「この実装が正解」と言うものは今でもわかりません。

この、わからないだらけの状況のなかを　どのように乗り越えたのか？

それは、
「レイアウト崩れてもいいから、とにかく完成させよう」
という気持ちでやり切りました。

そうです。問題は解決していないのです。（なんてこった）

作ったWEBアプリはブラウザの画面を全部広げて、かつズームが100％の状態でなければ
成立しない仕様になっているのです。
拡大（ズーム100％以上）、縮小（100％以下）にするとレイアウトが崩れてしまします。

でも、よいのです。
このWEBアプリ制作は収入をもらって、完璧なものを納品しているわけではなく、
自分の目標の達成に向けた１手段だからです。

もし、CSSの実装で、
「ブラウザの表示範囲によってレイアウトが切り替わるレスポンシブなのを作りたい」
「でも、難しくてうまくできない…」
と2つの理想と現実に板挟みになることがあれば、

「とりあえずできる所からやっちゃえ」

と気楽にやっていきましょう。

デプロイ、修正

ローカルで開発したWEBアプリを完成させたあとは、全世界に公開します。
アプリの公開はHerokuという無料で使えるクラウドサーバーを使用しました。
カリキュラム内で、デプロイ（作ったプログラムを使える状態にする）の方法が
載っているので、手順通りにやっていきました。

デプロイが完了した後、バグの修正や検索機能の追加など
しこしこやって、なんとか完成させることができました。

いやー、アプリが完成した時の達成感はもちろんあったのですが、
それ以上に、使ってくれた人がいたことが何よりもうれしかったです。

ここまでたどり着くのに、支えて下さったメンターの方々、teratailの回答者、
同じスクールの受講生に助けられたからだと思っています。

本当にありがとうございました。

今後どうするか

私は、「プログラミング講師になる」という夢ができました。
新しい技術を学び、活かしていくことも楽しいのですが、
多くの人に、「できた」という成功体験を味わって欲しいからです。

私の欠点は、「物覚えが良くなく、人の話を最後まで理解できない」ことですが、
この欠点は最大の武器だと思っています。

「物覚えが良くなく、人の話を最後まで理解できない」からこそ
理解できるまで、相手の困っていることに耳を傾けることができる、
理解できるまで、深く調べ解決することができる自信があります。

現在、転職活動に向けて活動をしていくところです。

WEBアプリ制作完了というゴールを迎え、新たなスタートラインに立ちます。
次回は、転職活動の記録を載せていこうと思います。

それでは、私の夢が叶う日まで…

.
.
P.S.　約9400文字書きました。疲れたー

BEMとSMACSSを組み合わせる
※Sassを覚えたらSassも取り入れる

【BEM】

{Block}__{Element}
{Block}-{Modifier}
{Block}__{Element}-{Modifier}

----- 例 -----

.archiveItem {
  margin-bottom: 20px;
}
.archiveItem__inner {
  display: flex;
  padding: 10px;
}
.archiveItem__thumb {
  margin-right: 20px;
}

【SMACSS】

– Base
– Layout
– Module
– State
– Theme

----- 例 -----

body {}
html {}

/*---------- Layout ----------*/

.l-header {}
.l-footer {}
.l-main {}
.l-sidebar {}

/*---------- Module ----------*/

.button {}
.is-button-warning {} 
.label {}
.is-label-hidden {} 
.is-label-error {}
.heading {}

/*---------- Theme ----------*/

.dark-mode {}
.light-mode {}

※BEMが使えるものはレイアウトに入れ、BEMを使わないものはモジュールに入れる

この記事はConverting My WordPress Solution into a $500/Month Side ProjectのIgor Benićさんのご本人の許可を得て翻訳をしたものです。

簡単に内容をまとめると

• wordpressのpluginを開発して毎月5万円弱の収益を得ている。
• 開発のきっかけはちいさな不満から
• 低コストでもプロダクトを売り込める方法はたくさんある
• もしプロダクトを始めたばかりなら、諦めないことが一番重要

自分の小さな不満から始まったプロダクトで、この収益を得るまでに挫折しそうになったことも多々垣間見える内容だったので似たような個人開発者の方（自分含め）だととても共感できるような内容になっているかと思います。
是非最後まで読んでみてください。

(補足)どういうプロダクト？

メールアドレスで応募できるプレゼント企画をwordpress上で簡単に始められるプラグインです。
無料だと複数の景品タイプを選べたり、メール通知やフォームを編集出来たりします。
また有料では、デザインの変更や他サービスとの連携（MailChimpとか）のカスタマイズ要素が多いですね。

はじめに

Simple Giveawaysは、私の最初の取り組みです。これは、メールアドレスを収集しアルゴリズムを使用してプレゼントの勝者を選択するかなりシンプルな製品で幅広く色んなところで使われています。

またSimple Giveawaysはサイドプロジェクトで、ゆっくりと成長していますが、しっかりと伸びています。

作ろうと思ったきっかけ

ブログを始めたときに、トラフィックを増やす方法をググりまくっていたら、プレゼントのアイデアについての記事をたくさん見つけました。
しかし、$99でプレゼントのシステムを使えましたがそんな余裕はありませんでした。
なので、自分で作ろうとおもったのが最初のきっかけです。

実際、自分のために開発をしていただけなので、このプラグインが収益化できるとも思っていなかったですし、どちらかといえばwordpressのテーマを販売したかったと思っていたのを覚えています。

初期バージョンはどんなものだったか

最初は本当にシンプルで、メールアドレスを入れたら保存されるくらいでテンプレートも1つだけでした。
開発期間は約1か月くらいで、フルタイムの仕事の合間にやっていました。

技術的にはHTML, PHP, CSS, jQueryのDateTimePickerを使っていました。

初期バージョンができた後、さらに4つのテンプレートや、勝者を自動で選択できるようなオプションを加え、4か月後くらいにプレミアバージョンを公開しました。

どのようにユーザーを集めましたか？

まずは公式のwordpressのプラグインリポジトリに登録をしました。
今でもトラフィックの大部分はここからきます。検索をすると私のプラグインが上位に表示されています。

他に新しいユーザーを引き付ける方法はたくさんありますが、ふつうは予算が必要で、自分はそれがなかったので無料や低コストでできることをしました。

• プラグインの使用方法を説明する記事を出した
• 自分のサイトでプラグインを使って、体験させてみる。
• wordpressのプラグイン紹介をしてくれるpodcastに売り込んだ
• facebook広告
• twitter活用
• 開発者インタビューに答える
• 活用方法などをまとめた動画のチュートリアルコースを作成した

facebook広告については、1日単位などで固定予算を設定できるので、$5の広告を打ったところCVは低く、18クリックしかされなかったです。しかし表示回数ははるかに多かったためプロダクトを周知できたと思っています。

結局、今でも口コミやtwitterや公式プラグインレポジトリのトラフィックに頼っています。
最近Google analyticsを入れたので、流入経路を探ったりしています。
SEOを伸ばしてみようと考えたりもしています。

どのように収益化しているのか

ビジネスモデルは、複数種類のサブスクプランを作っています。

• 1つのウェブサイトで使用可能:
  • 年間$49
  • 永久$149
• 2つのウェブサイトで使用可能
  • 年間$59、
  • 永久$179
• 無制限のウェブサイトで使用可能
  • 年間$99
  • 永久$189

決済はpaypalかStripeで行っているので、ほぼ管理はいりません。

実際の2019年の内訳はこのようになっていました

1月：年間92％、永久8％
2月：年間78％、永久22％
3月：100％年間
4月：年間83％、永久17％
5月：年間72％、永久28％

もし永久プランを用意する場合は、常に新しいユーザーが必要になることを覚えておくのが大切です。

一番難しかったこと

1つはトラクションを集めることで、最初の100インストールを達成するのがとても困難でした。達成してからは緩やかに成長しました。

もしあなたが、プロダクトを作るとき、辛抱強くがんばらないといけません。最初はあなたがそのプロダクトを紹介し、広めていかないとユーザーが勝手に見つけて、使ってくれることはほぼありません。また成長を維持する為に改善を怠らないのが重要です。

2つめに、適切なキャッチーで分かりやすいプロダクト名を付けたほうがいいです。最初の100インストールをもっと早く到達できてたかもしれないです。

個人開発者へのアドバイス

もし始めたばかりなら、諦めないことが一番重要です。
それで稼ごうと思うと1年以上かかるのが普通だと思います。（私は3年以上）

あとは最初からマーケティングに力を入れます。
WEBサイトを構築したり、ビデオを投稿したり、記事を書いたりしてユーザーを様々な方法で集めます。

また、最初のバージョンはユーザーが使い始められる最低限の製品を作成して、フィードバックをもらって改善をすればいいと思います。

良い開発者ライフを！

　最後に

最後までお読みくださりありがとうございました。Twitterでは、Qiitaに書かない海外のマーケティング事例や個人開発のアイデアなどもツイートしているので、よかったらフォローお願いします

きりしま@個人開発

こちらの記事もよければ

【翻訳】自動投稿ツールが300万で売れた話（契約内容も）