スクラムにおけるリリース計画

スクラム現場ガイドの第11章は全てを引用して載せたいぐらい良いことが書かれています。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

プロジェクトにおいて、よく聞かれる質問「いつ終わる？」「この日までにできる？」

どんなプロジェクトでも、一番よく聞かれる質問は「いつ終わる？」「この日までにできる？」じゃないだろうか。誰でも、プロジェクトが予想通りに進まずひどい目にあった経験があるはずだ。

スクラム現場ガイド 第11章より引用

確かに頻繁に聞かれます。そしてステークホルダー（お金を出す側）にとってみれば最大の関心事はこれです。

伝統的な開発手法の場合、わかりやすく回答しやすい

ウォーターフォールなどの開発プロセスだと、要件が全て決まっていると仮定して、長いガントチャートを書きます。
長いガントチャートを書くために要件から機能をリストし、各機能を見積もります。この見積もりは仮定です。
ガントチャートを書き上げたら、その計画どおりに事が進むと仮定され、プロジェクトは開始されます。
ガントチャートがありますから、いつ何が完成するかは、チャートを見ればわかります。わかりやすいです。
そして報告では、計画通り事が進んでいないことが問題とされ、その問題（遅れ）を取り戻すための施策を検討せよ、ということになり、さらにプロジェクトは遅れます。
「数値上は、あと4人メンバーを追加すれば、計画通り進みます。」
と報告され、メンバーが4人追加され、さらにプロジェクトは遅れます。もう挽回は不可能です。
ただの「数合わせゲーム」と化します。
要件を削るか、期間を延ばすかです。
でもそれは不可能で、さらに人を追加します・・・。デスマーチです。

frontline.fm 言いたいことをいってくれている感がある（笑

スクラムの場合、何の準備もしていないと回答しづらい

逆にスクラムだとどうなるのでしょうか。
スクラムガイドラインにはこの手の回答はありませんので、自ら考える必要があります。

スクラムではガントチャートは基本的には引かないです。引いてもいいですけど頻繁に変わることを前提とするため、メンテナンスコストが多くかかります。
ガントチャートを引かない代わりに、以下の３つのインプットからリリースプランニングをします。

• 見積もり、順序付け、優先順位付けができているプロダクト・バックログ
• チームのベロシティ（チームと相談した上での、予測値。）
• スプリントのタイムライン

プロダクト・バックログのストーリーポイントが合計で200だったとして、チームと相談した仮のベロシティが20だとしたら、単純計算で10スプリントあれば完了です。
ただ、ストーリーポイントはスプリント毎に常に見直され、チームのベロシティもだんだんと安定してくることをステークホルダーと共有しましょう。
プロダクト・バックログの上から順に何がいつごろ出来そうかをプランニングします。

リリースプランニングの成果物は、以下の様な図になります。これがリリース計画になります。


リリース計画はプロジェクトのロードマップになります。
おおよそどのようなストーリーがいつごろ出来上がるかを視覚的にわかりやすく表現できています。

上記の例では、チームのベロシティは１つだけでしたが、チームの自信や経験を踏まえ、
最低・最大のベロシティにて計算すると良いと思います。（最低水位・最高水位と呼ばれています。）

さきほどの図に最低ベロシティの場合と最高ベロシティの場合を付けます。

表現を変えるだけですが、ストーリーポイントのバーンダウンに最低ベロシティだった場合の着地点と最大ベロシティの着地点を表現しても良いと考えます。

そして、このリリース計画をスプリント毎に必ず見直しましょう。
プロダクト・バックログ・リファインメント時が一番適していると思います。

この手法にて、スクラムにおいても「いつ終わる？」「この日までにできる？」に回答することができます。

何度も言いますが、このアプローチの場合に重要なのは、
リリース計画は毎回変わるものだということをステークホルダーと共有することです。

「計画は変わらないもの」「計画は死守するもの」として受け取られてしまうと「何が何でもスプリント１ではこのベロシティを出さなくてはならない」ということに成りかねません。
持続可能性が保持できません。

アジャイルとは、常に改善し続ける状態であること、です。
継続ができないということは、アジャイルではありません。

箱モノであろうが何であろうが、現在は明らかにサービスの時代です。エンドユーザに寄り添って、常により良いものを作り続ける必要があります。
エンドユーザとともに成長ができる、本当のWin-Winの関係が築けるのがアジャイルです。

リリース計画は初期のロードマップとして有効です。 計画は計画に過ぎないと、関係者の皆様が理解していないといけません。計画は変わるのです。私たちは最善を尽くしてプロダクトバックログを見積もりまますが、それでもプロジェクト完了までの実際の距離が予想より増えたり、減ったりいたします。
スクラム現場ガイド 第11章より引用

スクラム スクラムガイドとスクラムの奴隷

スクラムは、理解は容易ですが、習得が困難です。
習得または実行と言い換えてもいいかも知れません。「きっちりした」スクラムを実行することはものすごいエネルギーが必要です。

スクラムガイドにも書いてあります。
「 スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。」

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf

これは非常に厳しい言葉です。
おそらくですが、完璧なスクラムを実践している職場は非常に少ないのではないでしょうか。
スクラムは企業文化や組織風土、メンバーのスキルに依存する部分も多々あるため、スクラムを自身の企業や組織に適用するために”一部変えてしまう”ことがあると思います。

一方で、「スクラムの奴隷になるな」という言葉もあります。
出典はわかりませんが、スクラムの実践者たちが講演しているセミナー等ではよく聞く言葉です。
この真意はわかりませんが、「スクラムをスクラムガイドのまま進めすぎようと躍起になると痛い目に会うよ」ということだと認識しています。（違ったらごめんなさい）
「ミイラ取りがミイラになる」、と似ているのかなと感じました。（違うか（汗

ガイドでは、スクラムというものをきっちりと定義し、それから逸脱してはスクラムとは言えないと謳い、
実践者たちは「スクラムの奴隷になるな」と謳っています。
どちらを信じれば良いのでしょうか？

私は、「どちらも信じる」だと思います。

スクラムガイドは非常に軽量です。もしスクラムを実践しようとするなら、すべてを暗記して、ソラで説明できるぐらい真剣にスクラムを理解するべきです。
スクラムには19の要素があると言われています。以下の19の要素が散りばめていないと、スクラムではないということになります。

要素	日本語	説明
Transparency	透明性	“経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。 例： プロセスの用語を参加者全員で共有している。 作業をする人とその作成物を受け取る人が「完成」の定義を共有している。RDBの世界にあるOne Fact In One Placeもこれに近いです。共有すべき情報は１箇所にあること。それが全員に周知できている状態であることが大切です。
Inspection	検査	スクラムのユーザーは、スクラムの作成物や進捗を頻繁に検査し、変化を検知する。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。熟練の検査人が念入りに行えば、検査は最大の効果をもたらす。
Adaptation	適応	プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査人が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
Prodcut Owner	プロダクトオーナー	プロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。
Development Team	開発チーム	開発チームは、各スプリントの終わりにリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。インクリメントを作成できるのは、開発チームのメンバーだけである。 開発チームは、自分たちの作業を構成・管理する。そのことは組織からも認められている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。
Scrum Maser	スクラムマスター	スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。 スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。
Sprint	スプリント	スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックスである。スプリントは、開発作業を行う連続した期間である。スプリントが終了すると、新しいスプリントが開始される。
Sprint Planning	スプリントプランニング	スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業だ。 スプリントが1か月の場合、スプリントプランニングのタイムボックスは最大で8時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。スクラムマスターは、参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。"
Daily Scrum	デイリースクラム	デイリースクラムとは、開発チームが活動の速度を合わせ、次の24時間の計画を作る15分間のタイムボックスのイベントである。前回のデイリースクラムから行った作業の検査と、次回のデイリースクラムまでに行う作業の予想を行う。デイリースクラムは毎日、同じ時間・場所で開催する。これは、複雑にならないようにするためである。
Sprint Review	スプリントレビュー	スプリントレビューとは、スプリントの終わりにインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。
Sprint Retrospective	スプリントレトロスペクティブ	スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
Sprint Stop	スプリントストップ	スプリントを中止する
Product Back Log Refinement	プロダクトバックログリファインメント	中・長期のProduct Back Logを考える。 次のSprint以降の話をする。今のSprintは変えない。 （スクラムをやると未来が見えなくなると言う人がいるが、大抵これをやっていない）
Product Back Log	プロダクトバックログ	プロダクトバックログは、プロダクトに必要なものがすべて並べられた一覧であり、プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。
Sprint Back Log	スプリントバックログ	スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、開発チームが作成するインクリメントに含まれる機能と、その機能を「完成」インクリメントにして届けるために必要な作業の予想である。
Potentially Shippable Increment	出荷判断可能インクリメント	インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを組み合わせたものである。スプリントの終わりには、新しいインクリメントが「完成」していなければならない。つまりインクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。
Impediment List	インペディメントリスト	“スクラムからみた課題・障害・リスクを管理するリスト。 例：セレモニーが長い チームが安定してきたが、出荷できない
Acceptance Criteria	受け入れ条件	プロダクトオーナーがスプリントレビュー時にプロダクトを受け入れる条件を明記したもの。Prodcut Back Logに記載する。
Definition of Done	完了の定義	プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。

その上で「スクラムの奴隷になるな」だと思います。
ただ、私が思うに、上記19の要素は全て必須だと思いますし、透明性・検査・適応という原則を守ろうとすると必然的についてまわる要素だと考えます。

スクラムは、非常に楽しいですが、反面、非常に大変です。
１スプリント２週間の場合、
まるで隔週連載のマンガ家になった気分だとチーム内から声が上がったことがあります。うーん、確かに。
２週間で動くものを作りこむプレッシャーたるや相当のものだと思います。
ただそれが、チーム、人間の限界ギリギリの能力を発揮してくれるのかも知れません。締め切り効果というやつです。

スクラムは適切に運用されればチームの力をかなり向上させ、顧客、チーム内においても透明性を確保し、コミュニケーションを増大させてくれると確信しています。
そして、それは非常に楽しく、厳しいです。
チームのメンバーの素養としては、Mでないとやっていけないかも知れません。（嘘

楯野川-TATENOKAWA- 直汲み

またしてもヒット。 香りも良く、すごいフルーティー（グレープフルーツっぽいというか）で、あっという間にごくごく呑んでしまいます。 雑味、クセがなく、白ワイン好きな方にもお薦めできる日本酒です。

昭島の長塚酒店さんの、2016年現在私の中ではBEST3に入ります。

時給を把握せよ

「藤原先生、これからの働き方について教えてください。」　を読んだ。

まずはじめに、年収ではなく、時給を把握せよ、とのこと。

時給を多くもらっているビジネス・パーソンこそが真の意味で生産性が高いのかもしれない。
よく学び、よく働き、よく休む（と言っても共働きで子育てをしている場合、家ではほとんど休めない。会社のほうが全然楽である）
これができていないと、人生の後半戦で優れた功績が残しづらいだろうと思う。

では、私の時給はいくらか。
年収はさすがに公表したくないが、１年にどれくらい働いているか、はデータがある。

私は生産性を非常に意識して働いている。DRY原則はかなり重要だ。

qiita.com

達人プログラマーに出てくる、消極的・積極的コードジェネレーターを双方必ずと言っていいほど利用する。基本的にはコードは手で書かかないで、ほとんどの場合、「コードを書く」コードを書く。

続いて、自分自身ももちろんだが、チームの生産性も上げる必要がある。

１日８時間が労働時間である。
１ヶ月で平均して５時間程度残業がある。残業と言っても、基本的には17:30にさっと帰る。朝が8:45-なのだが、7:45-8:45の間ではじめる。たいてい8:30からだ。これでだいたい月５時間程度。
残業代はつかない。

2015年度は、稼動日が245日。
私は年休を23日分取得していたので、稼動日は245-23=222日。
１日８時間として222*8=1776時間。月平均５時間残業なので、5*12=60時間を足す。
1776+60=1836時間。
年収÷1836 ≒ XXXX円。（年収わかっちゃいますので、伏字にしました。4桁の数値です。）

時給はXXXX 円だった。
おそらく普通のサラリーマンであろう。

脱線するが、これに自宅での家事・育児が入ってきたらどうであろうか。収入は0だが、働いている時間が滅法長くなる。

人間は、学習時間１万時間で熟練するという考え方がある。
１万時間は、１日３時間で約１０年。

20代、30代、40代で10年づつ何かを極めていき、

３つの得意領域の三角形の面積を広げていくことにより、希少性が高まるということだ。
「藤原先生、これからの働き方について教えてください。」では、
希少性が高ければ高いほど、稼げる人になるという。

私の場合は、プログラミングを10年ほどやっているので、これはもうかなりの領域なのかもしれない。自分ではそう思っていないが。でも時々神様が降りてきたりもするので(笑
ここ数年はリーダーシップやマネジメント、アジャイル・スクラム、コミュニケーション、組織どうするみたいないことを考えている。もう６年。となると、あと４年は続けたい。
あと４年考え続けたら確かに何かモノになりそう。

ここで懐疑的な質問があって、プログラミングはいいのだが、リーダシップだのその辺が三角形の頂点に成り得るか、ということだ。
おそらく成り得る。なぜなら、ここで学んでいることはソフトウェア開発以外の仕事でも活かすことが可能だからだ。
スクラムは何もソフトウェア開発のために存在するプロセスではない。アジャイルの考え方は、プログラミングとは絶妙にマッチする、しかし、他の職種でも十分に通用するといえる。

となると最後の頂点は一体何を始めるべきか。
また少し時間はあるので、気長に模索しようと思う。

やっぱり時給８万ぐらいいきたい。
でも８万ってすごいな。働く時間が今と同じなら、年収が今よりY0倍になる計算だ。(※Y0 = Yは1以上の数値が入る)
働く時間を半分に減らしても良いが、その場合は年収はY0/2倍になる。年収がY0/2倍になって働く時間も減るってのはすごいな。
働く時間が減れば減るほど、どこかの頂点を極めるのが速くなるかもしれない。そうすると相乗効果でさらに年収も上がり…
モチベーションさえ続けばまさに正のループにハマる。そうなると人生すごい充実するんだろうな。
自分の時間も上がり、収入も上がる。好きなことを極め続けられる。

今のままの仕事を続けていては、年収がY0倍になることはないだろう。
やはり、知識労働なので、コンサルタントをする必要があるのかもしれない。必要ないかもしれない。
それも含めて模索が必要だ。
停滞は後退。
動き続けろ…

Nokia Test ノキア・テスト Scrumスクラムが健全に運営されているかのチェックリスト

2016/4/8  LeSSの翻訳会に参加させていただいて、色々勉強になりました。そのうちの一つに、Nokia Testがありました。

 

どれだけScrumが健全に運営されているかのチェックリストがあるとのことで、

Nokia Test。ノキアテスト。

 

訳が無いとのことで、訳してみました。

 

http://www.sierra-charlie.com/download/SB023-The%20Nokia%20Test.pdf

 

Q1.イテレーション

 

イテレーションが存在しない	0
イテレーションが６週間より長い	1
イテレーション毎に変わるが、６週間以内	2
6週間のイテレーション	3
５週間のイテレーション	4
４週間かそれ以下のイテレーション	5

 

Q2.スプリントの中のテスト

 

品質を意識していない	0
単体試験(自動UT)がされている	1
機能試験がされている	5
機能試験が完了するとすぐに実施されている	7
受入試験にソフトウェアがパスしている	8
ソフトウェアがデプロイされている	10

 

Q3.アジャイルな仕様

 

要求がない	0
大きい要求仕様書が存在する	1
貧弱なユーザストーリーが存在する	4
良い要求がある	5
良いユーザストーリーが存在する	7
必要十分な仕様がある	8
必要とされている仕様が束ねられた良いユーザストーリーが存在する	10

 

Q4.プロダクト・オーナー

 

プロダクト・オーナーがいない	0
スクラムを理解していないプロダクト・オーナーが存在する	1
チームを邪魔する(ディスる)プロダクト・オーナーが存在する	2
チームを伴わないプロダクト・オーナーが存在する	2
プロダクト・オーナー がスプリント・プランニングの前にチームによって見積もられた明確なプロダクトバックログとプロダクト・オーナーが存在する。	5
チームのベロシティを基準としたリリースロードマップとプロダクト・オーナーが存在する	8
チームを鼓舞するプロダクト・オーナーが存在する	10

 

 

Q5.プロダクト・バックログ

 

プロダクト・バックログがない	0
複数のプロダクト・バックログがある	1
一つのプロダクト・バックログがある	3
スプリント・プランニングの前にROIを基に優先順位付けされた明確なプロダクトバックログが存在する	5
プロダクト・オーナー がスプリント・プランニングの前にチームによって見積もられた明確なプロダクトバックログとプロダクト・オーナーが存在する。	5
ベロシティを基準としたリリース日とリリースバーンダウンを持ったプロダクト・オーナーが存在する	7
プロダクト・オーナーは現実の予算、ストーリー・ポイント毎のコスト、または他のメトリクスを測定可能である。	10

 

Q6.見積もり

 

見積もられていないプロダクトバックログが存在する	0
チームによって見積もりがされていない	1
プランニング・ポーカーによって見積もりがされていない	5
チームによるプランニング・ポーカーによる見積もりがされている	8
見積もりエラーが10%より小さい	10

 

Q7.スプリント・バーンダウン・チャート

 

バーンダウンチャートが存在しない	0
チームによって更新されていないバーンダウンチャートが存在する	1
仕掛中のタスクが考慮されていないバーンダウンチャートが存在する	2
Doneの場合のみがトラッキングできるバーンダウンチャートを利用している	4
ストーリーがDoneになった場合のみバーンがダウンする	5
チームがチーム自身のベロシティを知っている	+ 3
これまでにわかったベロシティを基にしたリリースプランをプロダクト・オーナーが考えている	+ 2

 

Q8.チームの混乱

 

マネージャーまたはプロジェクト・リーダーがチームを混乱させている	0
プロダクト・オーナーがチームを混乱させている	1
マネージャー、プロジェクト・リーダーまたはチーム・リーダーがチームに何をするか指示している	3
プロジェクト・リーダーとスクラムの役割が存在する。 つまり、スクラムをやっているのにかかわらず、PMが存在したりする。	5
スクラムにおける役割のみが存在する(スクラム・マスター/プロダクト・オーナー/チームのみ)	10

 

Q9.チーム

 

スプリントプランニングの間にタスクは個々にアサインされる	0
チームメンバーは彼らの専門領域以外をカバーしていない(クロス・ファンクショナルな意識がない）	0
リーダーシップが存在しない。1人以上のチームメンバーが指示されたことしかしない	1
チームが、スクラムチームに求められるコンピテンシーを保持していない	2
チームはスプリント・ゴールとバックログにチーム全員でコミットしている	7
チームメンバーはチーム全員でスクラムの阻害要因に対して健闘している	9
チームはすさまじい改善能力を持っている	10

 

形式的なノキアテストスコア

※訳注　下記リストはイマイチ意味がわからなかったため、直訳っぽくなっています。ご注意を。

 

・認定スクラムマスターであれば平均4.0ぐらいのスコアで運用する

・１ヶ月あれば、6.0ぐらいのスコアまで上げることが可能

・こうすれば控えめに言っても20%ぐらいはベロシティを上げることが可能。

・１チーム、１ヶ月に100000ユーロ。コスト削減は20％。

・初年度の最低の費用対効果は220000ユーロ。スクラムマスターを取得するには2000ユーロ。

・初年度のROIは11000%より大きい。

 

 

いまだ人間を幸福にしない日本というシステム

いまだ人間を幸福にしない日本というシステム
を読んだ。

「人間を幸福にしない日本というシステム」
タイトルにインパクトがあります。でも私たちは心の底で実はそれを理解してもいる。何かが根本的にイケナイんだろう。
だから夢も希望もありゃしないのさ、無気力・無関心・無感動と、やや古いがそんな言葉が流行ったときもあった。

内容が難しいのと、速く核心を知りたいので、さっと流し読みしてしまいました。

結局何が原因かというと、「官僚」。
実際、私は官僚に知り合いがいないし、どういう仕事をしているかもほとんどイメージ出来ないから、全くもって腑に落ちないが、官僚がイケナイらしい。
官僚が日本を牛耳っているらしい。

ほとんどの政治家は、官僚に操られているにすぎないと。

ただ、日本を根本的に変えるには、官僚を変革する必要があるらしい。

官僚を変革するには、官僚内のボトムアップは無理で、やはり政治家の力が必要らしい。

小沢一郎はその力をもつ政治家であったが、結局干された（…のかよくわからないが、うまくいかなかった）

結論としては、官僚を変革するために、官僚に依存しない力のある政治家を国民が選ぶ必要がある、
そのために、もっと政治に関心を持とう、ということでした。


そうか、官僚か。そうなのかな。
確かに官僚には、選挙で選ばれなくてもなれる。有名大学を優秀な成績で卒業すれば、なれる確率が高い。
実務家じゃない人が多いのかな。
割りと淡々と仕事をするのかな。
確かに何をやっているのかはわからない。正確にいうと、わかろうともしていなかった自分。

www.asahi.com

とか読むと、やはり出る杭は打たれるような感じ。

ただ、多分個々人は一生懸命やってるんだと思う。
だから、おそらく、
「官僚」がイケナイんじゃなくて、「官僚というシステム」がイケナイんじゃないだろうか。
それをぶち壊せる政治家が必要なんじゃないだろうか。

…と悶々としています。

SORACOM（ソラコム）のビジネスモデル

SORACOM Airのビジネスモデルをピクト図解してみました。

一言でいうと、対機器向けのMVMO業者ですね。

他のMVMO業者も同じような感じですけど、特徴的なのはAWSを利用しているのと、機器の個数に対してサービスを提供しているところ。
他のMVMO業者だと、スマホ1台1台に限られるので、基本的には人間1人=スマホ1台だから、人間の数に縛られるけど、SORACOMは機器の数が母数だから、
他のMVMOより儲かる確率は必然的に高くなる。
これは確かに期待できるなぁ。ワクワク感が半端ない。
IoT機器は2020年までに全世界で300億台といわれています。母数が人間の非じゃないですね。

bdm.change-jp.com

ただ、国内だけだと契約台数は限られてくる気はします。
日本だとドコモ回線で、どこでも電波が繋がりやすい。
海外で同じモデルが通用するかは疑問が残ります。
(NTTドコモのところが入れ替わる形になる。ただそうなるとSORACOMとしては現地にサービス提供する場所が必要になる）
以下の記事を鵜呑みにするならば、欧州より、アメリカ、アジア向けが良さそうですね。まずはアメリカだろうなぁ。

www.itmedia.co.jp