【エンジニアはアフィリエイターへのオーバーライドが死ぬほど簡単な件について】V字モデルで相関を解説

ANOくんの思想

はい、どうもこんにちは、ANOくんです。

今日会社で「システム開発モデルの再理解」みたいなテーマで
昼過ぎくらいから1時間くらい研修があって
「めんどくせーなー」と思いながらウトウトと話を聞いていたんですが
改めて開発プロセスを学んだ時に

「いやエンジニアとアフィリエイターのやってること完全に一緒やん、、、!
「親クラスエンジニアで子クラスアフィリへのオーバーライド、継承そのまんまやん、、、!!
「いやこれはマジでブログ行きや、知らんと損する人おるわ、書こう、、、!!!

みたいなカイジ的な閃きがあって研修の中盤からずっとこのブログの
記事構成を考えて、残りの内容全然頭に入ってこない、みたいなことがありました。
社会人失格ですね。(笑)

結構最近副業ブームで
「仕事も慣れてきたし、なんかお小遣い稼ぎでもしよっかなー」
って思ってるエンジニアの方って結構多いんじゃないかと思います。

なので今日は
「エンジニアはアフィリエイターへのオーバーライドが死ぬほど簡単な件について」
と言うテーマで、どれほどエンジニアとアフィリエイターの業務工程の相関が強いかについて
みなさんにお伝えしていこうと思います。



エンジニアとアフィリエイターの業務工程の”本質的一致”について

本質的一致

開発のV字モデル

まずはまあみなさんもちろんご存知で聞き飽きてる話からになって申し訳ないんですが
システム開発の際によく用いられる
V字モデルを使って、改めてシステム開発のプロセスを見ていこうと思います。
(※ここでは前提、ウォーターフォールで開発進めてるってことにしますんで
アジャイルだとどうこうみたいな細かいところは無視します。)

 

V字モデル

(引用:発注ラウンジ , システム開発におけるV字モデルとは?W字についても解説 より)

大なり小なり現場や案件種別によってプロセスの踏み方や内容が異なると思うんですが
概ねこのモデルの通りに開発が進んでいる現場が多いんじゃないでしょうか。
そんでもって基本的にシステム開発って

①要件定義

②外部設計(概要設計)

③内部設計(詳細設計)

④開発(コードレビューもあるかな)

⑤単体テスト

⑥結合テスト

⑦システムテスト

⑧受け入れテスト

ていうプロセス踏みながら(たまに地雷バグ踏みながら)
開発って進んでいくんじゃないんかなあと思います。

とりあえずおさらいも兼ねてって感じで
開発プロセスのV字モデルについて見ておきました。

アフィリエイターのメディア開発モデル

んでは早速本題です。じゃあエンジニアとアフィリエイターって
何がそんなに一致してんのかって部分を詳しく見ていこうと思います。

結論からになるんですがシステム開発もアフィリで稼いでいくことも
「日々行なっている業務ってほぼ一致」してます。

先ほど見たV字モデルの各工程を用いて

『アフィリ業務をV字モデルにて定義した場合どのようになるのか』

を各工程ずつでお伝えしていきます。

要件定義

ここってシステム開発の場合
「お客さんの要望をきっちり満たすためにどんな仕様にするのか」
てのが大きなテーマじゃないですか。
そのために何回もお客さんにヒヤリングを重ねたり
実装機能の決定をしたり
ここからできてここまではできないみたいな境界を決めたり
てことを詰めてやってると思います。

そう、この要件定義って
お客さんの要望をきっちり満たすためにやってるんです。
んでそう言えば、アフィリってどうすれば収益って上がるでしたっけ?

そう
「お客さんの要望を満たすコンテンツを作成し、そこでお客さんの反応が得られること」
で収益って発生しますよね。

例えば女性にモテなくて困っている人に
モテるためのおしゃれな服の紹介をする、みたいな感じで
問題解決を図り、その服を購入してくれるから
広告料としてアフィリエイト収益が発生します。

システム開発の要件定義って
アフィリの場合「コンセプト設計・メディアの構成設計」とほぼ同じです。
どんなお客さんのどんな問題にどんな実装を行なって要望を満たすか
この部分がアフィもまずは初めに来るんです。

外部設計(概要設計)

んで次が外部設計。システム開発の場合だと
フロントからバックエンドまで大きくどんなシステムにするのかを
考えていきますよね。
もうエンジニアの皆さんだったらある程度理解がついてるかもしれませんが
これがアフィの場合だと「メディアのデザイン決定や市場選定」だったりします。

要件定義で決めた特定のお客さんに対して
「その人はどんなブログのデザインだったら好きそうかな」とか
「その人の年齢ってどのくらいでどんな生活スタイルで何が好きで何が嫌いでどんなことに悩んでるんだろう」と
次の内部設計につながるようなことをあれこれと考えながら
ブログやメディアの全体像のイメージを決めていきます。

さー、なんだかだんだん似てる気がしてきたんじゃないでしょうか。

内部設計(詳細設計)

お次は内部設計。
開発の場合は「論理チェック」ですね。
セキュリティの観点からインジェクションやXSSなどの対策決定したり
条件分岐文をMECEに処理通せるよう考えたりと
ロジカルに仕様を考えていくフェーズですね。

そう、ここもアフィの場合でいうと
収益発生までの変数を分解して考えるロジカルな部分になります。
アフィの収益って基本的に公式が決まってて
「PV × CTR × CVR」の3つの変数で成り立ってます。

それぞれ

$PV = ”記事を読んでくれた数”;
$CTR = “記事の中の広告をクリックしてくれる率”;
$CVR = “クリックした広告の中で購入や登録などをしてくれた率”;

ていう変数が宣言されてたりします。

だからアフィの場合ここでは
「想定しているお客さんはこのくらい可処分所得ありそうだから、このくらいの価格設定にしよう」とか
「このキーワードだと月の検索ボリュームが○件くらいはあるから上位表示したら月に△人は来てくれるだろう。そのうちの□人が購入するとしたらだいたい☆記事くらい書けば目標の収益に達するな」とかって感じで
収益というのを数学的に考え対策決めていくってフェーズなんですよ。

いやーここまで同じだとなんだかすごいですね(語彙力皆無)。

開発

ここはわかりやすいですね。開発環境だとまさしくプログラミングフェーズ。
仕様書に沿ってバグと戦いながら実装を完了させていくところです。
ここはアフィだとすごくわかりやすくて「コンテンツ投入のフェーズ」ですね。
記事を書いたり、外設で決めた仕様になるようHTML,CSS,JSあたりをいじってデザイン変えたりみたいな実装のフェーズです。

単体テスト・結合テスト・システムテスト・受け入れテスト

んでテスト。ここからアフィの場合でも
開発入ってからはテストと行ったり来たりをしながら
外設・内設の要望に合うような実装にしていけるよう改善を繰り返します。

ブログ記事をあげては検索順位を確認してさらに上位に行けるようリライトしたり
記事の中でのCTRやCVRが悪ければ
それを改善できるような施作を打ち続けたりといったことをし続けながら
仕様書通りにメディアが機能するようPDCAを回し続けます。

開発の現場では単体テスト・結合テスト・システムテストで
内容が違いますし、システムテストはそりゃ肝冷やすフェーズだと思うんですが
ちょっと話がややこしくなるんで、ここではざっくり「テスト」として
考えてもらえたらと思います。

あー、書いた書いた。いやーこれで
エンジニアとアフィリがどれだけ似ているかが結構わかったんじゃないでしょうか?

システム開発もアフィも、キモは”要件定義”

ここまでエンジニアとアフィの相関について
各工程を1つずつ見ながら解説して来ました。

各工程がかなりの相関を見せてるんで(まあアフィもシステム組むようなもんなので似て当然)
今のエンジニアリングスキルを生かせるんじゃないかなあと
希望を胸に抱けた方もいらっしゃるんじゃないかと思います。

んで最後になりましたが重要なことをお伝えします。
さっきまでエンジニアとアフィが似てるってことをお伝えして来ましたが
似てるってことは「重要な箇所」ももちろん似ています。

そして題名にもありますが
アフィも「要件定義」がキモです。

エンジニアの皆さんなら馴染み深いかと思いますが
要件定義ミスってるとまあデスるの確定ですよね。

進捗がいつまでも「だいたい完成」の俗にいう、「90%シンドローム」にハマり
PGやテスターは何に取り組めばゴールなのか分からず
どんどんとモチベーションは下がり作業効率は落ち
納期だけが迫って来ても一向に解決の兆しが見えないっていう
まああのおぞましい惨状が待ち構えてますよね。

これアフィも一緒なんすよ。

そもそものコンセプト設計ミスると
どれだけそこから開発頑張ろうとPDCA回して質を上げようとしても
ゴール設計ミスってるんでいつまでも結果でないんですね。

これ実証例は世にめっちゃあるんですね。
例えばやまもとりゅうけんさんとかがいい例なんですけど
最初に結果出してる人にめちゃめちゃレビューしてもろて
要件定義しっかり決めきってるから
メディア立ち上げた2016年くらいから発信の軸がブレてないんすね。

https://twitter.com/ryukke/status/1154318213699657728
(こんなツイートしてました)

ロジックが正しいから最初は結果が出なくても
数年経つと爆発的な結果出してるんですよ。

これ他の成功してるアフィリエイターやブロガーの方にも
もれなく当てはまることで、逆に言えば結果出てない人って
この部分の描き方をもれなくミスってます。

だからこそ要件定義。もうここが間違いなくアフィにおいても最重要事項。
ここミスらずきっちり抑えてその要件に沿って実装していき続ければ
アフィでも結果出ます。

二十四時間稼働の自動収益生成バッチをプログラムしよう

自動収益生成バッチ

ここまでアフィとエンジニアの共通点について見て来たんですけど
「結構相関高いなー」と思われた方も多いんじゃないでしょうか。

んでこれは職業的な気質の問題かもしれないんですけど
エンジニアとして仕事やれてる人って基本仮説検証能力高い人多いじゃないすか。
僕すごくそれ感じるんですけど
アフィに向く気質に「結果出すまで仮説検証し続けること」ってあると思うんですよね。

だから十重二十重の思考を常に張り巡らしているエンジニアの方は
アフィにも向いてると思いますし副業するなら本当にぴったり。

「本業で守って副業で攻める」
これが令和時代の生き方の基礎基本だと僕は思っています。

本業では日々の生活を担保しつつ
副業では攻めに攻めて自身の収益源を増やしていく、
エンジニアの皆さんならそんな理想もすぐに実現できると思います。

さあ今日から、自分オリジナルの自動収益生成バッチを、世界にプログラムしていこう。

echo “Hello World!!!”;