はてなブログで学ぶマーケティング ~キャズムについて~

はてなブログで記事を書いて広まるということがキャズムの関係と似てるなと思ったので考えてみようと思います。

キャズムに関してはまんまタイトルでその本があるので、詳しくはそちらを参考に。

キャズム

簡単に説明すると
1. マーケットを大きくするにはマジョリティに使ってもらわなければならない
2. マジョリティにはアーリーマジョリティとレイトマジョリティがいる
3. アーリーマジョリティに使われる前にイノベーター、アーリーアダプターに使われる
4. アーリーアダプターとアーリーマジョリティの間に深い溝(キャズム)がある
そこでキャズムを超えるにはどうすればいいかを考えます。
ブログに置き換えるとマーケットはPV数とし、使われるということは読まれるということにします。
つまりブログを大多数の人に読んでもらえるためにはどうすればいいか。それをキャズム理論に当てはめ考えていこうと思います。

考えなければいけないのはブログにおいて、
誰(どんな人)がマジョリティになるのか、イノベーターになるのか、アーリーアダプターになるのかをまず考えてみます。

ちなみにはてなブログに限らずブログをやってる人ならもうわかるかもしれませんが。

それを考えるために、このnigoblogでマジョリティに読まれ、PV数を高めたケースの情報を元に考えていきます。
測定ツールにはGoogle Analyticsを用いているのでそこから取れる情報だけで考えていきます。

前提条件は最大で読まれた
これからWeb系のベンチャーで起業しようと思っている人へ考慮しなければいけないリストを作成した ~技術編~ - nigoblog
こちらの記事の10/17 ~ 10/18までの情報を元に考えていきます。

まず最初に誰に読まれているかを考えるために、今回はリファラー(参照元)を調べます。
10/17 ~ 10/18で各リファラーのPV数を以下に示します。

このようなグラフとなりました。
なれない方にはわかりにくいと思いますので上から順に見ていくと

リファラー	タイトル
(direct)	直接URLを叩く(アプリからが多い)
gunosy.com	グノシー
b.hatena.ne.jp	はてなブックマーク
t.co	twitter短縮URL
facebook.com	facebook
hatena.ne.jp	はてなトップ
m.facebook.com	facebook モバイル

このような感じとなっております。
ボリュームだけを見ると
マジョリティ
> はてなブックマーク、グノシー
アーリーアダプター、イノベーター
> ツイッター、フェイスブック
となります。(direct)は不確定な部分が多いので今回は省きます。
果たして本当にそうなのか。今度は時間別に見ていきます。

ちなみにこの記事が公開されたのは17日15時頃です。

時間帯別にPV数を見ると下記のようなりました。

上が絶対値で下が普段の時間帯のPVで正規化したものです。
時間帯によって結果が違うだろということも踏まえ正規化しました。
上のグラフの縦軸はPV数で
下のグラフの縦軸は普段のPV数に対する割合(%)です。

考察の前に結果を説明すると、最初に17時の時点で普段の5倍のアクセスがはてブから流入しております。
翌8時には普段の10倍のアクセスがGunosyから流入しております。

ということで、時間帯とPV数の関係から
はてブ、Twitter、Facebookはイノベーター、アーリーアダプター
Gunosyはマジョリティということになります。

先ほどのキャズムの例になぞらえると
1. PV数を増やすにはGunosyユーザーに読んでもらわなければいけない
2. Gunosyユーザーには8時前後に読むユーザーと12時前後に読むユーザーがいる
3. 8時前後に読むGunosyユーザーの前にはてブ、Twitter、Facebookのユーザーに読まれている
4. 8時前後に読むGunosyユーザーとはてブ、Twitter、Facebookのユーザーの間にはキャズムがある

というわけでGunosyで配信されるというキャズムを越える戦略によってPV数が増えるという結論になりました。

わかっていることを伝えると、Gunosyで配信されなかった場合マジョリティには届きません。
なのでマジョリティに届かない、キャズムを越えられなかった例と比較すると
はてブユーザーのPV数に圧倒的な違いがあります。
キャズムを越える -> はてブユーザーに読まれている
キャズムを越えない -> はてブユーザーに読まれていない

というわけでPV数を伸ばすためにははてブユーザーに読まれる記事という結論になりました。
じゃあどうすればはてブユーザーに読まれるかということに関してはまたこんどということで。

...いやいやいやって感じですよね。
なんか自分も本来書きたい結論とは違って、
はてブユーザーとGunosyユーザーがマジョリティで
はてブ新着ユーザーがアーリーマジョリティ、はてブ人気ユーザー、Gunosyユーザーがレイトマジョリティ。
TwitterとFacebookがイノベーター、アーリーアダプターで
キャズムを越えるにははてブの新着に出るのが必要。
はてブの新着に出るためには…!?
っていう内容を書きたかったんですけどね。

まぁなんとなくキャズムがわかっていただけたら幸いです。
では。

関連記事

物理とマーケティング、4つの関係 - nigoblog
マーケティング関連の記事

キャズム

あとキャズムを書いた人の本。これも参考になります。

ライフサイクル イノベーション 成熟市場+コモディティ化に効く 14のイノベーション

AWS ELB配下にあるインスタンスに対しserverspecでテスト・管理する方法

serverspecはよく使っているのですが、ある状態をチェックしたいとき、その自動化に役立ちます。

例としてcrondやnginxのステータス確認などがそれにあたるかと思います。
これまでは

ssh '対象ホスト'
/etc/init.d/crond status

のようにやっていました。
これもサーバーが1台であったり、確認することが1つであればそこまでめんどくさくはないのですが、複数台で、複数のことがらをチェックするのは結構大変です。

なので自動化したい!っていうことなのですが、単純な使い方ならこちらの記事を参考に
一番参考になるのはなんだかんだで公式ドキュメント!DevOpsのためにチェックすべきドキュメント3選! - nigoblog
serverspec - Home

serverspecは基本的に

~/.ssh/config

の内容を参考に動きます。
その際、ELB配下で固定IPをつけていない場合、いちいちIPを見に行かなければなりません。

今回そのめんどくさい部分を解決したserverspecの使い方をしているのでその紹介をします。

流れとしては

1. aws-sdkで動的にインスタンスのIPを取得
2. ssh/configで各インスタンス共通のログイン情報を作成
3. 各インスタンスのspecを作成
4. serverspecでELBの場合どうするか記述する

このような流れとなります。

aws-sdkで動的にインスタンスのIPを取得

これはよくcapistranoでELB配下のインスタンスにデプロイをする際によく使われます。
これの使い方は簡単で
Ruby - CapistranoでELB配下のEC2インスタンスを取得してデプロイ - Qiita [キータ]
こちらの記事を参考にしました。
serverspecで使う場合、

cd serverspec
bundle init

でserverspecディレクトリにGemfileを作成
Gemfileには

gem 'aws-sdk'

と追加し

bundle install

を行う。
次にspec/spec_helper.rbを開いて

require 'serverspec'
require 'pathname'
require 'net/ssh'
require 'aws-sdk'

これでaws-sdkを読み込み、

RSpec.configure do |c| 
  AWS.config({
    :access_key_id => '<アクセスキー>',
    :secret_access_key => '<シークレットキー>',
    :ec2_endpoint => 'ec2.ap-northeast-1.amazonaws.com',
    :elb_endpoint =>'elasticloadbalancing.ap-northeast-1.amazonaws.com'
  })  
  elb       = AWS::ELB.new.load_balancers['<ELBの名前>']
  instances = elb.instances.select {|i| i.exists? && i.status == :running}.map(&:dns_name)

するとinstancesにELB配下インスタンスのIPが配列として代入されます。
まず第一段階のELB配下インスタンスのIPを動的に取得しました。

ssh/configで各インスタンス共通のログイン情報を作成

次のステップは一旦serverspecとは離れ、ssh/configの設定を行います。

vim ~/.ssh/config

を次のように編集します。

Host ELBの名前
    User <sshで入るユーザー名>
    IdentityFile <鍵のパス>

一応ELBの名前としておりますが、実際はなんでも構いません。
第二段階もこれでオッケー

各インスタンスのspecを作成

ここはまずひとつはベタで作成し、それをコピーしていく形が理想です。
最終的にはspecディレクトリが

spec/
    spec_helper.rb
    ELBの名前_0/
    ELBの名前_1/
    ...
    ELBの名前_N-1/

のようになっていると良いでしょう。(Nはインスタンスの数)
まずELBの名前_0というディレクトリに基本のspecを書きます。
次にどんどんコピーしていきます。(ここだけ手動でイケてないので改善していこうかと)

cp -r ELBの名前_0 ELBの名前_1
...
cp -r ELBの名前_0 ELBの名前_N-1

これで第三段階も終了

serverspecでELBの場合どうするか記述する

というわけで最後にもう一回spec_helper.rbを編集します。

    host  = File.basename(Pathname.new(file).dirname)
    if c.host != host
      c.ssh.close if c.ssh
      c.host  = host
      options = Net::SSH::Config.for(c.host)
      user    = options[:user] || Etc.getlogin
      c.ssh   = Net::SSH.start(c.host, user, options)
    end 

まずデフォルトのserverspecはこのようになっております。
ここに先ほど取得したインスタンス情報を反映させます。

    host  = File.basename(Pathname.new(file).dirname)
    if c.host != host
      c.ssh.close if c.ssh
      # ELB対応
      if host =~ /<ELBの名前>*/
        host_num = File.basename(Pathname.new(file).dirname)[-1].to_i
        c.host = "<ELBの名前>"
        options = Net::SSH::Config.for(c.host)
        options[:host_name] = instances[host_num]
      else
        c.host  = host
        options = Net::SSH::Config.for(c.host)
      end 
      c.ssh   = Net::SSH.start(c.host, user, options)
  end

すると自動でELB配下のインスタンスIPが取得され、serverspecのテストを実行することができます。

というわけで以上ELB配下のインスタンスにserverspecを適用する方法でした!
いろいろ改善点はありますが、ひとまず動くところまで!

物理とマーケティング、4つの関係

今回は物理とマーケティングについて4つの関係を考えてみます。

ダン・コブリー：マーケティングについて物理が教えてくれたこと | Video on TED.com
ちなみに参考はこちらのTED
ここでは4つの物理のテーマからマーケティングに結びつけています。
動画の方はマーケティングを仕事にしていますが、元々は物理屋だったそうで、自分と境遇が似てるなと思いました。
このような流れで説明します。

• F=maから考えるポジショニング
• ハイゼンベルクの不確定性原理から考えるデータ分析
• エントロピーは常に増加するから考えるブランドイメージの変化
• 波動方程式から考える時間に対する動き ← オリジナル!

TEDの動画で紹介されたもののうち3つと、1つのオリジナルで物理とマーケティング、4つの関係について考察してみます。

F=ma

これはニュートン力学で、一番有名な式ですね。
これを変形すると
a = F/m
となります。
これは質量が大きくなるほどに物体の動くベクトルを変えるには大きな力が必要ということを表しています。
言い換えると質量が大きい物は動かしにくいといったほうがしっくりくるでしょうか。
ここでマーケティングに当てはめると
加速度をポジショニング
質量をブランド力
とします。
つまりブランド力が大きい物ほど、そのポジショニングを変えるのが難しいということです。
もうちょい具体化させると
あの会社は~をしている会社だ。というイメージ(ブランド)がついてしまえば、その後別のことをやるには大きな力が必要だということを示します。
動画ではアーサーアンダーセンがアクセンチュアを設立した例を出していました。

ここから考えられることはポジショニングを一度決めたらそこでなんとしてでも勝たなければいけないということがあります。
仮にそこで敗れたとして新しいことを始めるには多大なパワーが必要です。
最近だとC to C系のアプリが流行っていますが、まさにどこのポジションを狙ってブランドを確立していくかが重要なとこだと思います。他にもカメラアプリなんかもこの例でブランドの確立は重要だと感じます。

ハイゼンベルクの不確定性原理

これは素粒子の位置と運動量を正確に決定するのは不可能ということを表しています。
その理由としては測定の影響により、その素粒子を動かしてしまうため元々の位置をつかめない。
つまり測定結果自体が計測に影響をおよぼすということを表しています。
専門的にいうと素粒子の位置と運動量は一意には決まりません。
マーケティングに当てはめると、
素粒子はターゲットユーザー、測定行為は直接ヒアリングするという行為です。
動画ではインターネットユーザーに何を検索しますかと訪ねてもポルノと答える人はいない。
しかし、検索結果を見ると一番検索されているのはポルノという事実。

結局、ユーザーが何を考えているかどうかはユーザーに聞くよりもデータを見たほうが確実ということを表しています。
近年のデータサイエンティストブームはハイゼンベルクの不確定性原理から来てるわけです。

考察してもそのままなのでなんともいえませんが、ハイゼンベルクの不確定性原理により、ユーザーにヒアリングするためのソリューションよりもデータを提供するソリューションのほうが効果が正確であることを表します。
最近ではIVSに出ていたplanBCDやUSERDIVEが評価されていましたが、今後ますます需要は高まるでしょう。

エントロピーは常に増加する

物理学でいうエントロピーは一言で言うと無秩序さということです。
熱力学第二法則ではこのエントロピーが増大するということを示します。
(ちなみに情報工学においてエントロピーは情報量の不確実さで、何が起こるかわからない状態において最大になります)

そんなエントロピー、マーケティングにおいても同様のことがいえます。
マーケティングにおいてブランドは常に拡散していきます。
以前はある人がブランドについてメッセージ一つでブランドイメージを決めていく。
しかし、現在は各々がどう考えていくかによってブランドのイメージはどんどん変化していきます。

例えば、あるアプリを開発した時、開発者や企業は自分が使ってほしいというイメージによってブランドを決定します。
しかし世に流れ使われていくうちに、別の影響力のある方や、大多数のユーザーによってそのブランドイメージがどんどん変化していきます。
そしてこれは自然の物理現象であるため止めることは出来ません。

最近の例でいうとツイキャスなんかは現在中高生がメインのユーザーとなっております。
はたして、元々は本当にそのターゲットを狙っていたのでしょうか。

仮に狙っていたターゲットが同じだとしたらものすごいことですが、違っていたとしても熱力学第二法則によりそれは当然のことです。
大事なのはブランドイメージが変わったとして今度はそのブランドのままいかにそのユーザーを満足させるかが大事なのではないでしょうか。

元々考えていたユーザーと違った!だからその層により使ってもらうように広告を打つ!
よりも
元々考えていたユーザーと違った!けどそのユーザーに対して満足の行くように努力しよう。
のほうが結果たくさんの方に支持されると思います。
ツイキャスはそこをうまくやっているなと本当に感じます。

波動方程式

波動方程式は波の状態を空間と時間で記述する方程式です。
マクスウェルの方程式により導くことができます。

波動方程式は時間によってその空間の状態を表すことができます。
言い方を変えるとある地点での状態が時間によって変化するということを表します。

マーケティングに置き換えると、あるメッセージを発信した時、そのメッセージを受け取る人は時間によって変化するということです。

マーケティングにおいてキャズムという考え方があります。
これはアーリーアダプターとアーリーマジョリティの間に溝があり、それを超える戦略が必要ということです。
最初に面白がって使う人と、そこから一般的に使っていく人の間には深い溝(キャズム)があります。

最初はアーリーアダプターに対してメッセージが届きますが、アーリーマジョリティに対してメッセージが届くのは波動方程式上で考えると時間的な要素がどうしてもかかってしまうということを表します。
諦めずに発信し続けることが大事なのではないでしょうか。

キャズム理論はバンドギャップの理論にも例えられそうな気がするのでいずれ言及したいと思います。

まとめ

いろいろ物理現象とマーケティングについて考えてみました。
ほとんどは動画の受け売りですが、その具体例は自分の身近なところに置き換えられたかと思います。
自分で考えた波動方程式の部分はやはり浅くなっていますが。。。

最初に紹介した動画はこれまで自分が勉強してきた物理を今後マーケティングにも活かしてみようと思うきっかけになりました。
何度も見返して、自分なりにも何かしら結びつけてみようかと思います。

参考図書

大人のための高校物理復習帳 (ブルーバックス)

F=maなら高校物理でも

量子力学〈1〉 (基礎物理学選書5A)

ハイゼンベルクの不確定性原理は量子力学を。
大学時代はこの教科書を使っていました。

熱力学は基本レジュメだったので何がよいやら。。。

電気磁気学 (電気学会大学講座)

マクスウェル方程式は電気磁気学から。
未だにマクスウェル方程式は全部言える気がします。

今年も残り1ヶ月!少し早いけど2013年ってこんな年だったよねと振り返ってみる。~Web系編~

タイトル通り、今年はどんな年だったか振り返ってみたいと思います。
web系編とありますが、それ以外やらないと思います。

では時系列順に振り返ってみます

ビッグデータ・データサイエンティスト

今年最初はこの話題一色でしたね。
はてなブックマークを見に行けば大抵この話題だったんじゃないかと。
これに派生して、

• R
• hadoop

の2つがバズワードでしたね。
理系の研究室だったので割と基本的なことはわかっていたんですが、改めて統計学を学び直すきっかけにもなりました。

ニュースアプリ

GunosyとSmart Newsが出てきたのも今年だったかなと。アプリ自体は去年からリリースされていましたが、今年前半にブレイクした印象。4月くらいには批判記事も出るなど(批判記事が出るのは人気が出た証拠だと思ってる)。
個人的にもGunosyは自分に「友達がいない人のしゃべり方」のような記事を推薦されて、友達がいないことが完全にばれているなと感じました。
最近はなぜか野球ネタと料理ネタが多いです。
他にはハフィントンポスト日本上陸やAntennaの調達などが大きなトピックかなと。

C to C

だいたい春くらいから徐々に上がってきたワードですね。
メルカリを筆頭にパシャオクやFrilなど。
そうそう最近引っ越しの際にものを色々処分しようと思って漫画全巻セットをメルカリに出したんですね。
でしばらく放っておいたらあっという間にタイムラインが流れてしまって誰からもいいねされることなく深くまでいってしまいました。
というわけで、出品する側の方が多い印象を受けました。買い手と売り手のバランスを取るための施策はどうしているのだろうか?

DevOps

このワードもめちゃくちゃ流行ったなと。
DevelopmentもやるしOperationもやる人という意味合いで始まったような気がしますが、
最近はOpsをコーダブルにやるという意味合いに変わった気がします。
実際はChefの影響からで、そこからserverspecなどサーバーのテストコードなんかも出てきました。
Chef自体は前からあったと思うのですが、今年ブレイクした印象があります。

クラウドソーシング

個人的にはweb流行語大賞1位のワードです。
言葉自体はもうずっと昔からありますが、今年ようやくブレイクしたのではないかと思います。
フリーランスの方に発注するみたいな意味合いが多い気がしますが、個人的にはcrowdsolving
https://crowdsolving.jp/というサービスが一番クラウドソーシングっぽいなと感じております。
マイクロタスク型、コンペ型、プロジェクト型等々
クラウドソーシングはまだまだ色々な形があると思うので注目していきたいと思います!

bitcoin

これは今年の11月くらいからグワーッと上がってきました。
markethackの記事がきっかけとなったのではないでしょうか。
国内ではまだまだどう使っていくかが手探りな状況です。
これからの動向が楽しみですね。

immutable infrastructure

これも先月後半から一気に来ましたね。
内容としてはサーバーはコードベースで管理、
何かを追加するときはサーバーを破棄して、新しく立て直す。その際全てコードで構築するので冪等性がある。
こんな概要でしょうか。
確実に前半紹介したDevOpsに引っ張られている印象がありますが、
これからどうなっていくのやら。
あとこのワードが流行った経緯にクラウドサービスが流行っているというのもありますね。
(クラウドソーシングはCrowd、クラウドサービスはcloudです)

その他

インバウンドマーケティングやクラウド会計なんかも流行った気がします。

今年初めの予想記事

WEBアプリxネイティブアプリ徹底比較! - nigoblog
「今年はWebアプリが来る!」といっていましたが結果は上記の通り。
というわけでWebアプリの活躍は来年に持ち越されそうです。

2014年の予想

1月1日に記事を書こうと思っていますが予告だけ

• HTML5(リベンジ)
• リッチメディア広告 (モバイル含む)
• A/Bテストツール
• クラウドソーシング2.0
• ウェアラブルデバイス
• えっこんなものまでECで?

という感じかなと思っております。

期待して待っててください!

数学とプログラミングについて考察 ~ペアノの公理~

数学ガールって本が好きなんですけど、現在5作出ていて第三弾目の「ゲーデルの不完全性定理」っていう本を読み直しました。

数学ガール ゲーデルの不完全性定理 (数学ガールシリーズ 3)

これの2章にペアノの公理の話があるんですが、今回その章を読んだ感想と、プログラミングにその考えを応用してみるとどうなのかって話を考察したので書いていきたいと思います。

1. ペアノの公理とは
2. TDDとテストケースについて
3. ペアノの公理とテストケースの関係
4. まとめ

このような流れで書いていきます。

ペアノの公理とは

先に示した数学ガールを読んでいただくのが一番手っ取り早いのですが、
Webだと普通にwikipediaがいいですかね。
ペアノの公理 - Wikipedia

数学ガールの文をどこまで引用していいかわからないので簡単にペアノの公理について説明すると、
「自然数を定義する公理」
っていう表現が一番正しいかと。
1 + 1 = 2を証明するための公理です。

※ちなみに数学ガールの場合 1, 2, 3, ...をwikipediaの場合 0, 1, 2, ... を自然数としております。

1 + 1 = 2を証明するという言い方はやや語弊がありますが、ペアノの公理を使うと自然数全体の演算が説明つきます。
wikipediaの公理から
公理1では
0 は自然数であるといえ、
公理2では
0 に続きがあるということがいえる。これを後続数といい 0' と表す。
公理3では
0 の続きになるものは0にはならない。つまり0が一番先頭の自然数であると示す。
公理4では
自然数の2つA, Bがあったとき Aの後続数A'とBの後続数B'は一致しない。
つまり異なる自然数の後続数が同じ数ではあってはいけない。ある自然数とその自然数の後続数はそのペアでしか存在しないことを示している。
違う言い方をすると自然数 A, Bがあったとき、A=Bならば A'=B'である。
公理5では
数学的帰納法の話。プログラマ的にいうと関数 f(x) があったとき、x = 0の時にxに対応するリターンがあるならばx = n(自然数)になっても正しい結果が出る事を示している。(この場合はx = 1の方がわかりやすいと思うが。)

ポイントは0の後続数をいきなり1と言わない事。0以外の自然数はまだわかっていないこととしている。

というわけでざっくりペアノの公理についての説明でした。

TDDとテストケースについて

いきなりプログラミングの話になりますが、開発手法の一つにTDDという方法があります。
なんども書いているのでもう一度解説することはありませんが。
TDD(テスト駆動開発)でハノイの塔の実装をしてみる~TDD超入門~ - nigoblog
このとき重要なのはテストケースです。
厳しすぎても意味がないし、浅すぎてもテストに合格したとは言えません。

というわけでここでペアノの公理とテストケースの関係について考えることで最適なテストケースの洗い出しを考えてみましょう!

ペアノの公理とテストケースの関係

ここでfizzbuzzをTDDで開発することを考えます。
fizzbuzzについてはこちらを参考に
テスト駆動開発でFizzBuzz問題を解く - nigoblog
テストケースを考える前にfizzbuzzをもう一度掘り下げてみます。
1. 3の倍数でfizz
2. 5の倍数でbuzz
3. 3の倍数であり5の倍数であるときはfizzbuzz
をそれぞれ返し、具体的には

1, 2, fizz, 4, buzz, fizz, 7, 8, fizz, ... , 13, 14, fizzbuzz, ...

というような数列を作ります。この定義では明示しておりませんが、入力は全て自然数を前提とします。
これをもう少し数学チックに考えてみます。
1. 3nかつ¬5nならばfizzを返す
2. 5nかつ¬3nならばbuzzを返す
3. 15nならばfizzbuzzを返す
4. nは自然数である (n>0)
というわけで入力は自然数であることも明示しました。(¬は否定)
3n, 5n, 15nはそれぞれの係数をスタートとし、その倍数の自然数の集合と見なし、ペアノの公理が満たされているとします。
ここでペアノの公理を利用したテストケースは以下のようになります。
まずは4の自然数以外で例外を出すかどうかのチェック

• 入力 0 ならば例外
• 入力値の符号がマイナスならば例外
• 入力の型がint以外ならば例外

まずはこれで自然数以外をカットすることができました。
つまり入力は自然数限定ということを表しています。
なので数学的帰納法により、

• 1の時1を返す

これが成り立つということは全ての後続数でも成り立ちます。
また、3nの集合、5nの集合、15nの集合でも同様にテストするので

• 3, 6でfizzが返る
• 5, 10でbuzzが返る
• 15, 30でfizzbuzzが返る

これでペアノの定理5より、全てのケースがテスト出来ている状態と言えます。

まとめ

今回、初めての試みとして数学とプログラミングについての関係を書いてみました。
正直考察がやや甘いところもあるとは思いますが概ね考えたことはかけたかなと思います。

内容の方は、このように数学的帰納法や集合を意識するとテストケースに漏れがなく無駄のないテストケースが書けるのかなと感じております。
もともと集合について読み直すきっかけはデータベースの設計部分だったので、
それに関しても考察できたら書いていこうと思います。

というわけで数学とプログラミングについての考察でした。

参考図書

数学ガール ゲーデルの不完全性定理 (数学ガールシリーズ 3)

是非読んでみてください。