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

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

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

ここ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はダメでしたが・・・

 

ネガティブ思考でも努力はし続けられる、戦略的に自分を過小評価する話

今日気づいたんですが、どうやら自分の努力するときの思考パターンは独特なようです。
メモしておきます。

 

 

ポジティブ思考の努力

ポジティブな人が何かを頑張ろうとする時というのは、ジャンプの主人公のような思考形態を取ると思います。「海賊王に俺はなる!!(ドン!!)」みたな感じです。
これは初手で大きな目標(ポジティブイメージ)を持ちます。
この方法の肝は

  • どれだけ大きな目標を掲げられるか
  • どれだけ困難に直面しても萎えずに目標を持ち続けられるか
  • 萎える前に目標達成できるか

です。
我々はルフィではないので、困難や現実を見るとどんどん萎えます。
下図のように。

 

f:id:otihateten3510:20201026223602p:plain

 

ネガティブ思考の努力

私の思考形態は圧倒的にネガティブです。
大きな目標は持ちますが、できない理由をあげつらって「こんなの絶対できない」と言い出します。
でも誤解してほしくないんですが、私はそこから一個ずつできない理由を潰していく行動を取ります。

無意識でやってました。

この方法の肝は

  • できない理由をどれだけ潰せるか
  • ストレスが行動の源
  • ストレスに潰されずに行動し続ける
  • 「できそう」と思わない
  • できそうになった時に最後の踏ん張りが必要

 

ポジティブ努力のメリット・デメリット

  • 夢に向かってる時はとにかく楽しい
  • エネルギーが不足すると飽きて終わる
  • 現実との乖離が大きすぎると具体的な行動につなげにくい
  • 達成できない時は落差で落ち込む
  • 大きな目標を持てれば、及第点に達しても更に努力ができる
  • 上手くいくと自慢ばかりになる(「俺はこんなもんじゃない」)

 

ネガティブ努力のメリット・デメリット

  • 楽しくない
  • 長期戦に向いている
  • 自尊心がどんどん傷つく
  • 夢はない、あるのは課題
  • 課題が無くなると行動できなくなるから、目標が及第点止まり
  • 上手くいくと嫌味な人になる(「俺なんて大したことない」)

 

ポジティブ努力もどき、ネガティブ努力もどき

大きな目標を持って気持ちよくなって行動しないのはポジティブ努力もどきです。
悪いところをあげつらって憂鬱になって行動しないのはネガティブ努力もどきです。

 

ポジティブ努力もネガティブ努力も誤解される

ポジティブ努力は「口だけだろ」と思われがちですね。
ネガティブ努力は「また愚痴言ってる」と思われがちです。

 

ポジティブ努力を上手くやるポイント

頭のネジを外す

 

ネガティブ努力を上手くやるポイント

自分よりすごい人に会いまくって劣等感をたくさん得る

 

思考形態をチェンジできるか?

相当難しいのではないかと思います。
だって例えば「俺は大企業の社長になる!」とか大真面目に思い込んだ上できちんと行動できると思いますか?私は無理です。

 

 

 

また何か考えたらまとめたいと思います。