IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→法人化済)

技術的負債ならぬ、仕様的負債について

技術的負債っていう話、プログラマーは大好きです。
こいつらはコーディングの邪魔をし、プロジェクトを遅れさせ、残業を増やします。
だから皆嫌いなので技術的負債をどうにかしようと議論します。

技術的負債 - Wikipedia

 

ただし、概ね技術的負債を減らす術を身に着けてくると、それでもコードの複雑性が解消されないことに気づきます。
リーダブルに作っても、疎結合に作っても、SOLIDで作っても、どうしてもコードがぐちゃぐちゃになり、相当頭がいい人でないと全体を理解できない代物に成っていくでしょう。
あるいは新しく参画した、優秀なプログラマーたちによって作られたプロジェクトのコードが理解できずに悩むことで気づくかもしれません。

技術的負債の他に敵がいるということに。

 

その一つは仕様側の複雑性の問題です。
多くのプログラマーが気づくけど、中々手を出せず、それどころか議論にすら成りづらい仕様的負債について考えます。

 

f:id:otihateten3510:20210323081658p:plain

 

仕様的負債がどのように発生するか

このテーマだけで論文が書けそうなくらい重い話ですが。
今回は単純に「なぜ仕様が複雑化するか」の話を考えたいと思います。
私の観測範囲から見えてくる原因は、大体次のとおりです。

  • やろうとしてることがそもそも複雑
  • 市場最適のし過ぎ
  • 状態数を増やしすぎ
  • 施策の取り下げができていない
  • 環境の場合分け
  • 例外の作りすぎ

ちょっとずつ説明していきます。

 

やろうとしていることがそもそも複雑

Webサービスだと例えばECだとか決済だとか予約とかSNSだとか、あるいは国内向けのEMSだとかCSMだとかCMSだとか金融システムだとか、ああいうのはそもそもどう足掻いても複雑です。
複雑だからこそそれだけで仕事として成り立っています。導入に何億円もかかったり、それだけの機能を持った単一サービスが生まれたり。

これらは一回関わってみるとわかりますが、どれだけ単純化しようにも限界があります。ちなみに似たようなことが複雑性保存の法則で言われているらしいです。

 

市場最適のし過ぎ

例えば会社向けに導入するシステム開発などでよく言われますけど、会社側が自分達の仕事のフローの変更をせず、システム側にその複雑性を要求するとシステムがとんでもなく複雑になり工数が多くなります。

別の例で、最初にシンプルに作っていたサービスでも、売上が伸び悩んできて個々のユーザーに最適になるようにあれこれやってるとどんどん複雑になってきます。

 

状態数を増やしすぎ

例えばUserが1Modelとして存在していればいいんですが、UserをCustomer、Providerのように2Modelとして扱うと複雑度がかなり増します。
リボン型ビジネスとかそうですね。例えば売り手と買い手が居るようなシステムとか。
これに更に売り手、買い手、仲介のように3Modelにするともっと複雑度が増して工数が爆発します。

別の例で、Userを初回ユーザー、未ログインユーザー、ログイン済みユーザー、お得意様、のように分けていくとどんどん複雑になっていきます。

もっと小さいトランザクションレベルのところでも、送信前、送信中、送信後で3状態ですが、2つのトランザクションを組み合わせると3状態x3状態で最大9状態になります(ここは少し仕様的負債よりも技術的負債に近い気がしますが、2つのトランザクションを同時にやらなきゃいけない状況というのは仕様的負債だと思います)

こういう一見小さな状態数の増加で実はシステムの複雑度は爆発します。

 

施策の取り下げができていない

サービスをもっとよくしようとしてあれこれ入れたもので、あまり効果がなかったものが取り下げられていないケースです。これは謎の機能として邪魔をし続けますが、リファクタリングなどで解決できるものではありません。

以前見かけたのが、AppleGoogleに「新機能を入れたらアプリを目立たせてあげるよ」みたいな取引に応じた機能が放置されていたケースです。2,3社で見ました。

 

環境の場合分け

例えばiOSだと、iOSバージョン14,13,12,11,10,9で使えるみたいなアプリが有りましたがそこそこ地獄でした。
バージョンごとに書き方が異なるケースがあり、複雑度が上がっていました。
またはスマホだけじゃなくタブレットでも専用のレイアウトがあるだとか、小さい端末の時と大きい端末の時で処理を変えるとか、そういうケースがあります。

 

例外の作りすぎ

これは分かりやすいですよね。
実際のビジネスは例外のオンパレードです。ECサイトで「明日まで3000円以下の商品は送料無料」とか、状態数増やしてる上に例外を増やしています。
期限付きの例外とか注意しないと負債まっしぐらですよね。

 

仕様的負債が発生する理由(複雑度が上がる理由)

  • ビジネスがそもそも複雑
  • 構造が少し複雑になるとシステムは爆発的に複雑になるということに気づいていない
  • 人間の思考はプログラム的ではない
  • 工数が増えると嬉しい人達が居る
  • 非エンジニアの複雑度に対する危機感の薄さ

こんなところでしょうか?

 

仕様的負債が事業に及ぼす影響

  • どんな機能追加もひたすら遅くなる
  • バグが増える
  • バグかどうかの判断が付かない
  • 仕様を全部把握できる人が居なくなる
  • 優秀で高給な人しか改修できなくなる

どこでも起きてます。

 

仕様的負債を避ける方法

  • 複雑な仕様を安易に受け入れない(技術者サイド)
  • 単純な仕様を検討する
  • 使ってない仕様を破棄する

まあほとんどできてる所無いんですけどね。

 

エンジニアができる仕様的負債に対するアプローチ

現実問題これってあり得るんでしょうか。
仕様的負債の解消というのは技術的負債の解消よりも影響範囲も大きくどうなるか分からない部分もあります。イメージとしては盆栽の剪定作業のような感じですが、コア事業のために何かを捨てるとか変えるわけですから、そこへの責任が発生しますし、非エンジニア組織への説明やユーザーへの説明も発生します。

世の中どちらかと言えば、とにかく気にせず複雑にしてしまい、誰も触れないくらいになるんだけど、最終的に東大卒のエンジニアが長い時間をかけてちょっとずつ変更できるカタツムリのようなスピードで何とかやっていく、みたいな企業が多い印象です。それができないところは停滞していくという。

ライブラリーの開発など見ると、結構スクラップ・アンド・ビルドを繰り返しているので、ああいう風にできたらいいのにと思う一方で、ユーザーとしては「前と全然仕様が違う!」と苛つくこともあるのでどっちが良いんだろうと未だに答えが出ていません。

あと、すごくシンプルにした結果自分らの仕事がなくなるというケースも、いやそれはないか。やることは沢山ありますからね。

自分がこれからPOになることがあったらそこらへんの課題感を持ってやってみたいと思います。

非機能性って大事だよねって話、あと反省

ここ1年は非機能性に触れる機会に多く恵まれました。

ファッションモデルさんと仕事したり、インスタ映えを目撃したり、ブランディングの仕事をしてる人と話したり、表参道やら青山やらをウロウロして、美意識高い人に出会ったり、ダイエットしたりエステしたり、紅茶飲んだりコーヒー飲んだりカフェ行ったり、花に囲まれて仕事したり、コミュニケーションを円滑化する仕事してる人と話したり。女子かな?

これまでだって色んな業界でシステム開発をしてきましたけど、これまでの人生とはダイブ毛色の違う1年で、色んな意味でエキサイティングでした。

 

これまでと価値観がだいぶ違う人が多く、まるで深海生物が浅瀬まで来てその生態系の差にカルチャーショックを受けてるような気分でした。
それで気づいたんですけど、我々エンジニアって相変わらず非機能性を軽視していますよね。いや我々とか言ったら主語がデカイと怒られるので「私」としておきたいですが。

 

エンジニアは機能的な生き物なのでしょうがないんです。酸素を吸って二酸化炭素を吐き出す生き物なのでしょうがないんです、というのと同じです。
そっちの方が得意だし、非機能性が不得意なので見たくないんです。
服とか見た目とかコミュニケーションとか人脈とか、デザインとか花とかマーケティングとかブランディングとか、そういうのって苦手なので「本質的じゃない」って言って目を背けたくなるんですが。もう昨今のエンジニアは「デザインの力」とか「非機能性の力」とかそういったもが死ぬほど重要だということを仕事を通じて百も承知なんですよね。
Viewの表示速度やボタンの触り心地や、色や優しいエラーコメントとかチュートリアルとか、そういうのが大事だってもう知ってます。

 

だけど未だにそういった非機能性の強いものを受け入れられない気持ちがある。そういう非機能性の高いものは機能的に劣っていて欲しいという気持ちもある。美男美女は性格がクズであって欲しいと願っている。コンプレックスなんだと思います。
一部の人は全然違うんですけど。私の中には多分ありましたし今でもきっとあります。

 

でも世の中のプロダクトをたくさん見ると、機能的にクソで見た目もクソなものもあれば、機能的に良くて見た目も良いみたいなものもあります。別にトレードオフではない。
そして今の世の中ってもう機能的には充足していて当たり前な時代ですから、非機能性を高めていかなきゃいけないんだと思います。言い方を変えればようやく非機能性に力を注げる時代に成ってきたんだと思います。サービスもそれ以外も。

 

だから私のような機能性の生態系の中に居る深海生物も、非機能性の世界に積極的に触れていかなきゃならないんだろうな、と思いました。
どっちも勉強していかなきゃならない。
そこでは私のような者が無意味と思っていたような「花」が、実は人の心にプラスの効果を与えていたり、コミュニケーションを生んでいるという「機能的存在」だったりします。そういうところを見にいって発見していかないといけない、特に機能性に強い人ほどその生態系から出たがらないと思いますが、今後それではジリ貧なんだと思いました。まあ死にはしないんですけどね。

 

あとこんだけ言っておいて、未だに仕事人間なので有言実行できていないですが。とりあえず気づきましたという段階。

 

そういえばこういう事象の分解みたいな話まえもしたな、と思ったんですがサブスクの話で書きましたね。

 

otihateten.hatenablog.com

 

 

近況 2021/03/14

世間は今どんな感じなんでしょうか? 私はここ1年大きな変化があったおかげで、周囲の変化が掴みづらいです。

先月1件仕事を失って、今月から2件仕事が増えて、もう1件増える余地もある、そんな状態です。

どうやらここ1年で新規アプリを3件リリースできそうで、ポートフォリオが更に充実してきそうです。こうなると案件は探すものというより向こうから来るようになってくるのですが、じゃあそれらの依頼をどこまで引き受け入れるかという線引きが更に難しくなってきそうです。

こういう状態って、もしその仕事を誰かに振れるような類のものなら人を増やしていくとどんどん儲かるというステージになると思うんですが、あいにく人に振れるような仕事ではないので限界があります。

不思議なことに引き合いが多くても単価の方は相場を脱さないので、どれだけポートフォリオが充実しようが年間2500万円を超えるのが厳しいと思います。普通に働くなら1200万円も超えません。フリーランスエンジニアの上限感があります。

もちろん優秀な若手を仲間に入れたら私も仕事を振れるようになるんでしょうけど、IT業界は会社間の人材の奪い合いが激しく、何かしらスペシャルな物を持っている会社でなければその奪い合いに負けると思います。私は余裕で負ける自信があります。

 

だから一番いい選択肢は「仕事が安定したのでこれからは私生活を充実させていこう」なんでしょうけど、そんな器用なことが自分にできるのか疑問です。いややっていかなきゃいけないんですけど。

結局やっぱり自社サービス持ちたいよね、という話になるのですが、ポートフォリオが充実したことによって目先の売上を取りに行った結果時間がなくなるという本末転倒な自体に陥ります。

ってこれ、多くの受託会社で起きてることを1人でやってるだけですよね。ここを脱せるかどうかが一個の試金石になるとは思います。

あとは大きな受託会社と仲良くする手もあると思うんですが、そんな良い会社あるんですかね?信じて任せられる会社、思いつかないです。

 

そう言えばFlutterがついにWebも対応したみたいですね。

ポジショントークをすれば、良いような悪いような微妙なところです。勉強していかないといけない気もするんですが、やはり時間がないので後回しになってしまいますね。

そもそもそれ言ったら英語勉強して外資と絡みたいというモチベーションもあるんですけど。英語は更に時間がかかる。

転職後2ヶ月目に高確率で揉める説

わかりやすく転職と書きましたが、正確にはジョイン後です。私の場合はフリーランスなので入場と言ったほうが良いですね。
すでに動いているプロジェクトに中途で入った場合、2ヶ月目か3ヶ月目あたりにそこそこな確率で1回喧嘩になり、その後一定の割合でそのまま退場するという法則に気づきました(揉めるけど退場しないケースもあります)
これって私だけですかね?私だけかもしれませんが、他の人でもある気がしてます。
かれこれ10社以上やってきて見えてきた法則です。もう何回これで辞めたことか。

 

とりあえず2ヶ月目クライシスとでも名付けましょう。

 

 

似たような記事

 

ベテラン技術者が新しい環境で大失敗した話 - Speaker Deck

 

2ヶ月目に揉める原因

大体がこれです。
期待されるキャッチアップの速度と、実際のキャッチアップの速度に大きな乖離があること。

 

f:id:otihateten3510:20210301003359p:plain

 

即戦力がほしいのは分かります。当然私も1つの技術に対してのプロなつもりですが、そのプロジェクト特有の諸事情を飲み込むには2,3ヶ月では足りないことが多いのです。
ひょっとしたら私の地頭が悪いのかもしれません。それは認めます。ただ、そういった期待度のスピードについていける人は稀なのではないでしょうか?と疑問です。

 

もう一つ原因があるとすれば、特にフリーランスが入るシーンというのは何かが間に合っていなく、そもそも鉄火場であるケースが多いことです。人月の神話に代表されるような話で、「人を増やせばタスクを巻けるだろう」という期待が裏切られるのが大体2ヶ月目という感じです。

人月の神話 - Wikipedia

また、特にそういうシーンでは面倒くさくて後回しにしたタスクが残っていたりします。入った瞬間に難題を振られるんです。仕様等のキャッチアップが遅れる中でそれを対応するとなると非常にパフォーマンスが落ちてやはり揉めます。

 

ベテランでも発生する

むしろベテランの方が発生する気がしました。
ベテランに対する期待値は高いんですけど、キャッチアップというのはどちらかというと経験値よりも地頭の良さが求められるものなんですよね。ベテランだからといってそのプロジェクト特有の仕様とか、そういったものを理解する速度は上がりません。
なのに期待値ばっかり高くなります。

あと揉めた経験というのも次に活かされることは特にありません。

 

2,3ヶ月目を脱すれば徐々に安定していく

図を見れば分かると思いますが、半年できれば安定すると思います。
半年いけば1年堅いというのが最近の私の中のイメージです。

 

問題は揉めた時の対応

これはお互いにですが、揉めた時というのは人の性格や組織力が出ます。そこでやっていけそうかどうかというジャッジが入ることが多い印象です。

お互い失望してからがスタートみたいな。皆そんな感じですよね?

 

2ヶ月目クライシスで辞めるのってもったいなくない?

エンジニアガチャのリセマラしてるような会社ありますけど、もったいなくないですか?
とは言えそういう会社ほど当然声が掛けれらる確率は上がるので、市場原理的に言っても意味ない気がしますけど。
難しい案件、難しい技術を使ってる案件、仕様が複雑な案件などで多発しました。私の場合。

 

とりあえず心構えをしておこう

どうせ次も1回揉める。
2ヶ月目脱すればあとは安定する。
そう考えておけば心が楽かもしれません。

ちなみに新規立ち上げプロジェクトでは2ヶ月目クライシスは発生しません。もっと後の、リリース直前のリスケあたりで発生します。

モバイルアプリ開発におけるクラウド選定の主流と歴史的経緯、あとFirebaseって何やねんという話

注意:社内勉強会用にあまり調べず超ざっくり書いたものですので、厳密には違う場合があるかもしれません。

ゴール1:何でAWSとFirebaseが混ざってるのか理解する
ゴール2:AWSやFirebaseでよく使うやつを覚える

 

クラウドサービス

クラウドサービスといえばファイルを保存しておくサーバーと言うイメージが一般的だと思いますが、サービス開発者におけるクラウドサービスも似たようなものです。
情報・ファイルを保存したり、そもそもWebサイトがそこに入っていたり、APIサーバーを置く場所だったりします。見え方としては昔からあるレンタルサーバーと大差ありません。何かすごい機能がいっぱいついたレンタルサーバと言ってもさほど問題有りません。

補足:スケーラブル

一応違いを書くと、スケーラブルかどうかという点が大きいです。ユーザーが100人なら100人分のリソースを使い、ユーザーが1億人なら1億人のリソースを使ってくれるという部分がクラウドサービスの革新的な部分です。

補足:オンプレミス

自分でサーバーを用意することをオンプレミスと言います。個人的には自鯖の方がしっくり来るんですが。

補足:ホスティングサービス

レンタルサーバーと似た意味

現代のサービスはほぼクラウドサービスを使っている

流行り始めたのは2010年前後だったと思います。

Web系サービスではアクセス量が桁違いに増減するケースが多く、それに対応できないとサーバーが落ちるといったトラブルに見舞われることになります。そのためインフラエンジニアがスケール部分を担っていましたが、それがクラウドサービスの登場で激変しました。

スケーラブルなサービスはすごい

半自動的に来たユーザーの分だけリソースが確保されるというのはとても都合の良いものでした。
これはリアル店舗を想像するとわかりやすいです。お客さんが大量に来たらお店が大きくなり、来ないときは小さくなるようなイメージです。コストが浮きますし機会損失も減ります。

3大クラウドサービス AWSGCP、Azure

AWS:アマゾン
GCPGoogle
Azure:マイクロソフト
です。
世界的なシェアで言えばAWS>Azure>GCPという感じですが、日本ではAWS一強のような感じです。

スクリーンショット 2021-02-13 18.03.02

補足:クラウドサービスではなくホスティングサービスにすると3大ではなくなります。もっと上が居るらしい。

AWSGCP、Azureのモバイルアプリ開発における位置づけ

AWSドキュメントがクソ分かりづらい、しかし使うしかない、実務経験者は多いけど全部使いこなせる人は稀、サポートが有料でめちゃ高い
GCPドキュメントは分かりやすいけど流行ってない、実務経験者が少ないから使えない、後発組、AIには強いという噂
Azure:海外で流行ってるらしい

モバイルアプリ開発でも基本的にAWSを使います。個人的にAWSじゃなかった案件はほとんどありませんでした。

AWSでよく使う機能(サービス)

あくまでモバイルアプリ開発でよく話題に上がる機能(サービス)です。
名前が死ぬほど覚えづらい

EC2(重要)
ホスティングサーボスそのもの。ぶっちゃけこれだけしか使わないことがよくある。laaSとかいうやつ。

Lambda
何かイベントがあった時に、特定の処理を実行する。
例えば画像をアップロードした時に、同時にサムネイル用の画像を作っておくとか。

S3(重要)
ファイルを置く所

RDS
普通なデータベース。
注意したいのは、EC2の中にデータベースを含むことができるので、最初はこいつの存在意義が謎だと思います。私は2回くらい教えてもらいましたが忘れました。

DynamoDB
NoSQLなデータベース
所謂サーバーレスという開発手法で使うやつ。詳細は別の機会に。

CodeDeploy
自動デプロイするやつ。Githubなどと連携して、masterにpushしたらデプロイするみたいな感じで使うらしい(使ったことはない)

IAM(重要)
AWSにあるものへのアクセスを管理する仕組み。鍵。

Cognito(重要)
認証機能。サインアップとかログインの機能を実現できるやつ。

AWSサービス多すぎ問題

これだけあります。1個覚えるのに数日、極めるのには数ヶ月は掛かります。
しかもドキュメントは分かりづらいしググっても情報があまり出てこない。

スクリーンショット 2021-02-13 18.41.33

AWSの学習コスト問題

AWSにありがちですが、1個のAWS機能を使用すると、自ずと他の機能も使わなければならないという状態になり、雪だるま式に学習コストが上がっていくという問題があります。
モバイルアプリ開発者的には「サクッとこの機能を実現したい」のに、気づけばAWSの泥沼にハマっていてどこかで諦めるということが多いです。

AWSの機能は汎用的に作られているため、ピンポイントで機能を実現できるものではなくなります。そのためAWSを極めるか諦めるかという選択になり、最終的に「EC2に全部入れてしまえ(普通のサーバーとして扱う)」ということによくなります(最近はそんなことないか)

Firebaseってなんやねん

FirebaseはGoogleモバイルプラットフォームです。モバイルに特化しています(Webでも使えます)
これはモバイルアプリ開発でよくある要望をピンポイントで独立した機能として提供しているため、開発者に受け入れられました。

結果「AWS使ってるのに、何かFirebaseというGoogleのサービスも使っている」とか、「cognito使わずにFirebase Authenticationを使う」ということになります。

Firebase Authentication

最初に流行ったのはFirebase Authenticationです。これは「○○でサインイン」というSNSログインの機能を実現するもので、AWSではcognitoのライバルです。ただ非常に使いやすかったため流行りました。cognitoはたぶんweb側で使われていると思います。あとAWSへのアクセスとか(自信薄)

参考:最近の良さげなCognito記事 Cognitoで学ぶ認証・認可 in AWS

スクリーンショット 2021-02-13 18.51.53

Firebaseのよく使う機能

AWSを使っているプロジェクトでも普通に使う機能満載です。

Authentication(重要)
○○でログイン、SNSログインを実現する。

Firestore
NoSQLなデータベース

Storage
ファイル置く所

Crashlytics(重要)
アプリがクラッシュした時にログを送信してくれる

App Distribution(重要)
アプリを配布する
DeployGate、Testflightの仲間

Analytics(重要)
ユーザー分析をする諸々の機能
GoogleAnalyticsの移行先

おわりに

AWSが流行り始めてから10年ちょっと。
Firebaseが流行り始めてから4年程度。
だいぶ早いですね。

 

Web・アプリサービス形態のパターン

改めて脳内にあるものを言語化するためにまとめます。
あまりまとめられている記事をみたことがない印象です。

 

 

サービスのライフサイクル

ざっくり大体こんな感じのイメージです。

f:id:otihateten3510:20210116195139p:plain

コンテンツというのは、色んな形態が考えられます

  • 物的商品
  • デジタル商品
  • 飲食
  • 旅行
  • 記事
  • ゲーム
  • ツール、機能
  • 株・為替
  • 仕事・人材
  • 美容院

などなど


枠に入りづらい形態にSNSやコミュニティのような人にまつわるものがあります。これは右に別途まとめています。繋がってるようで居て独立しています。

コンテンツは1個(1店)であるケース、1種(1ジャンル)であるケース、多種であるケースが考えられます。

このライフサイクルは営業方面でAIDMA・AISAS・SIPSみたいな概念で語られているのを参考にしていますが、それ以外は私のオリジナルです。もっと洗練できるかも。

 

AIDMA・AISAS・SIPS|マーケティングにおける購買行動モデルをおさらい | リクナビNEXTジャーナル

 

現実はもっと複雑ですが、考えやすいようにシンプルに体系立てています。

 

全てを担保するサービスはまだ無い

ユーザーにとって価値がある組み合わせができればサービスは成立します。

しかし、全ての要素を盛り込むと上手く行かないようです。これは色んな要因があると思います。例えば価値(=仕事)を企業間で奪い合うだとか、得手不得手があるだとか、権利の関係だとか。

商世界でも百貨店があったり専門店があったりと、多様な生態系を形作っていますよね。

 

コンテンツが主たる誘引体であり、各項目が副たる誘引体

ユーザーにとって非常に強いモチベーションである対象を誘引体という言葉で表現してみます。飯・金・人・仕事・コンテンツ・エンタメ・情報などが強い誘引体です。

コンテンツは主たる誘引体と定義しましょう。コンテンツはユーザーにとって最高に誘引されるものであり、そのためにユーザーは行動します。例えば旨い飯を食べたくて検索したり予約したりするわけです。そのために機能的なサービスが成立します。

誘引の強さはコンテンツによって差があります
非常に強力なコンテンツは多数のサービスプレイヤーが参画しています。
またコンテンツによって儲かる金額にも差があります。非常に高単価なコンテンツは営業部隊が形成されます。単価が安いが市場規模が大きいものほどITの出番です。

注意したいのは、コンテンツそのものが含まれないサービスというのは、ユーザーにとって中身のないガワでしかないので成立しづらいという事情があります。とはいえ全コンテンツホルダーをまとめ上げることは大抵は不可能なので、ガワだけでどう成立させるかという問題を、全サービスプレイヤーが解いているような状態です。

 

パターン:コンテンツホルダー

f:id:otihateten3510:20210116202010p:plain

コンテンツを持ってる人、作ってる人がこれにあたります。クリエイターでありIPホルダーであり権利者です。これのみで非常に大きな市場が形成されています。
飲食店であれば例えばラーメン屋もそうです。アニメで言えば製作委員会でしょうか。
彼らはしかしサービスを作りません。作ってもほとんど上手くいきません(例外あり)
理由は割愛します。

 

パターン:コンテンツ配信サービス

f:id:otihateten3510:20210116202427p:plain

例えばSpotifyNetflixTverみたいなコンテンツ配信サービスがこれにあたります。
コンテンツホルダーと違うのは、彼らはコンテンツを作っていないというところです(Netflixなど例外あり)

サービスプレイヤーとしては一番手堅く、支配的・天下を取れる形態ではありますが、そう簡単ではないというのは世の中のレッドオーシャン振りを見ると分かると思います。大きな資本と政治力が物を言います。

 

パターン:EC・モール(ジェネレート系含む)

 

f:id:otihateten3510:20210117005742p:plain

ECサービス全般はこんな感じ。
物販というのも基本的に同じですよね。商品の製造者と販売者は分かれていることが多いです。

 

パターン:決済システム

f:id:otihateten3510:20210117010307p:plain

決済は決済単独でサービスたり得ます。
購入・決済・予約は特殊な機能ですね。1個でビジネスが成り立つ。

 

パターン:予約サービス

f:id:otihateten3510:20210116204037p:plain

こちらも分かりやすいサービスです。
予約という機能が非常に重いので、そこを中心としてコンテンツ不在でも成立しています。

 

パターン:レビューサービス

f:id:otihateten3510:20210116204816p:plain

コンテンツの感想サービスです。そこそこありますが、どうしても上場まで行っていないケースが多いですね。
コンテンツ感想サービスの難しいところはマネタイズにあると思います。

 

パターン:ニュースサービス、キュレーション

f:id:otihateten3510:20210116205637p:plain

ニュース、情報がコンテンツになります。
情報をコンテンツと見なせば2重のコンテンツとなり複雑になります。

 

パターン:比較サービス

f:id:otihateten3510:20210117004759p:plain

比較を売りにしたサービスです。価格.comが思いつきますね。

 

パターン:出会い系・コミュニケーション

f:id:otihateten3510:20210116211341p:plain

これは分かりやすいですが、コンテンツが主体となっていないので今回の考え方とは少し変わります。

 

パターン:出会い系+コンテンツ

 

f:id:otihateten3510:20210116211633p:plain

最近ちょいちょい目にするデートプラン追加系サービスです。ワークしてるのかは知らないですが。

こういうのを見ると成立するサービスパターンの模索が進んでいる感じがしますね。

 

パターン:SNS

f:id:otihateten3510:20210116211913p:plain

SNSは非常に複雑怪奇ですね。最初は右側のコミュニケーションが中心だったと思いますが、コンテンツ主体としても見れるようになりました。SNSSNSだけで別の生態系で考えたほうが良いかもしれません。

 

これ以外のパターンは成立しづらい

 

コンテンツがないという所からスタートしたら、どうしても誘引が弱くなりますので、成立するパターンは少ないです。他にもあるかもしれませんが。

 

考察:リボン型ビジネスモデル

リボン型ビジネスモデルは、例えばBtoBtoCの場合はB側、C側に対してそれぞれのパターンを持っているとみなすことができると思います。
マーケットプレイス型のビジネスモデルも同様です。

 

考察:他にもビジネスモデルは大量にある

念の為頭に置いておきたいですが、当然ビジネスモデルはもっと沢山あります。
ただ、Webやアプリでサービスを作ろうとする場合には上記のようなパターンが主に成立するパターンなってくるようです。

 

考察:新しい「コンテンツ」を作る旨味

例えば「飲食」という強力なコンテンツが存在することで、多岐に及ぶサービスが存在しえます。コンテンツによって大規模な市場が形成されるわけです。
近年登場し成長したコンテンツには「ゲーム」があるでしょう。

そのためこのコンテンツ作りという部分でチャレンジするベンチャーも沢山あります。ただしそれは非常に困難なものだと認識しておかなければなりません。未成熟なコンテンツだと成立するパターンはより少なくなります。

 

考察:新しいパターン探し

そういうことをしてる会社もありますが、これも新しいコンテンツ作りほどではないですが難解な作業です。
滅多に新しいパターンは見つかりません。
(機能として盛り込むことはできても、規模を持ってワークできない)

 

私が作りたい新しいパターン

これは蛇足ですが。私も作りたい新しいパターンがあります。

f:id:otihateten3510:20210116221441p:plain

コンテンツの前と後の両方を盛り込んで成立させるというのは難しく、工夫が必要になるんですが、そこをまだ世界は取りきれていない感じがするんですよね。

 

 

 

 

 

 

 

モバイルアプリエンジニアはFlutterに手を出すべきか? そこらへんの生存戦略

Flutter、伸びてきてます。
数はReactNativeとFlutterを比較しています。Flutterというのは普通に英単語のようなので、Flutterが登場する2017年を基準に補正しています。今年になってようやくReact Nativeを抜き去り、今は少し落ちつたようです。

これは国内でも似たような感じです。

 

f:id:otihateten3510:20201028001902p:plain

 

それでも「React Nativeくらい」レベル

React Nativeの手を出さなかったモバイルアプリエンジニアは、Flutterに手を出す理由がさほどないと思います。
エージェントにも聞いてみましたが、やはりFlutter案件はまだ多くない上に安めらしいです。
ハイブリッドアプリを使うんですからそりゃそうですよね。

 

もちろん自社が採用したらやって良いと思う

一社に所属しているエンジニアと、何社とも取引するフリーランスエンジニアとでは状況がまるで違います。Flutterを採用して1案件あたりの単価を下げ数をさばくという営業方針を会社が取るのであればそれについて行って良いと思います。
まあ会社辞める時ちょっと大変ですけど。それ言ったらRxSwiftしかやってない人とかいましたし。

 

フリーランスの場合は少し慎重さが必要です。

 

おおよそのモバイル案件比率

大体こんな感じです。
iOS案件が100あったら、大体Android案件も100あります。日本特有ですねこれ。
そのうち20くらいがハイブリッド案件で、最近はFlutterが徐々に増えてきています。
残りの80のうち、15くらいが特殊な案件です。例えばRxSwiftを使ってるとか。何かこだわってるやつです。

f:id:otihateten3510:20201028002811p:plain

私が攻めてるのはメインボリュームである「普通のiOS案件」です。
特殊なiOS案件は単価が高いですが色々と無理だと悟りました(詳細は省く)

ハイブリッド案件を狙うのは基本的に悪手

上の図を見てほしいんですが、ハイブリッドの領域を取ろうとするのはAndroidエンジニアとiOSエンジニアの両方です。
注意が必要なのは、
普通のAndroid案件:普通のiOS案件:ハイブリッド案件=65:65:20
だということです。
ちょっと図があれですが、見かけでは大きいように見えて、狙うエンジニアの数からしたらめっちゃ少ないんです。
自ずと需要と供給の関係でエンジニア的には美味しくないですよね。

 

ハイブリッド案件を狙うメリット

それでも狙う理由があります。

  • 基本小規模 → ベンチャーや立ち上げフェーズ → リモート開発
  • Flutter案件が大きくなってきた時、iOSエンジニアは重宝されそう?
  • ハイブリッド卒業する時にネイティブ開発者として関われるかも?
  • 1案件が小さく、色んな案件に関われるかも?

これのどこらへんがメリットなんだろう?と我ながら思うんですが。

私は諸事情で現在フルリモート開発をしていまして、その関係でハイブリッドに手を出すべきなのかなぁと悩んでいます。
フルリモート可な案件にFlutter多いんですよね

また、いずれフルネイティブにしたいと考えてるような場合、おそらくそのままスライドで仕事を取れるでしょう。まあレアケースな気もしますけど。

 

iOS出身のFlutter使いって少なそう

あと私がFlutterに興味を持った理由の一つにこれがあります。

FlutterはGoogle由来ですから、自ずとAndroid出身者が多いと予想されます。プロジェクトでもAndroidファーストでアプリをリリースしたいという時にどうせならとFlutterを選択するケースがあるんじゃないでしょうか?iOSファーストの場合は普通にiOSファーストでやると思います。私が今やってる3つの案件のうち2つはiOSファーストです。Android版まだ出ません。

逆に考えれば、iOSの知識を持ってるFlutter使いってレアなんじゃないでしょうか?予想ですけど。ハイブリッドと言ってもSwift触るところも出てくるらしいですから、Flutter案件でFlutterエンジニアを2人3人抱えるというフェーズではiOS出身者が欲しくなると思います。

 

とりあえず

まあ全部予想だし勘なんですけどね

誰か情報交換しませんか?

 

とりあえず来年に向けて少し勉強してみようと思います。流石にiOS9年Android2年やってるんで理解できないなんて事ないと思うんですが・・・RxSwiftはダメでしたが・・・