プログラムの設計思想には、全体的なものと部分的なものがあるっていう話（その1）
前と別軸の話。
これも来年に向けて一つのテーマにしたいです。
設計には全体に及ぶ設計（喩えるなら戦略？）と、部分に適用できる設計（喩えるなら戦術？）があります。
この2つは非常に性質のことなるものですが、なぜか世間では同じく「設計」とかそういう類の言葉で同一視されてしまいます。
全体的な設計は、支配的な設計
全体に適用できる思想というのは大体の場合たかだか１つです。
移行期に複数の設計が混ざるケースもありますが、理想的には１つです。
なのでチーム開発の場合、誰かが適当に変更して良いものでは有りません。
中間的な設計ものもある（支配度・影響度）
ある一部分に適用するだけだけど、結果的にその影響が全体に及ぶみたいな設計もあります。
私はこの尺度を「支配度」「影響度」「感染力」などと勝手に呼んでいたりします。
もちろんこれは密結合のときの方が起こりますが、疎結合にしてもなお影響度の高い設計というのは生じてしまうものです。
（例えばModelの設計を変えたら全体がガラッと変わってしまいます）
研究課題
- 支配的な設計の悪いところ
- 支配的な設計との付き合い方
- どのように支配的な設計を評価するか
- ある変更の影響度はどの程度かを分かるようにする
- 設計思想を部分に留める方法
- 支配によるチーム開発の制御法
- 引き継ぐときに必要な情報
ここらへんですね。
プログラムの設計思想には、収束型と発散型があるっていう話（その１）
毎年新しいアーキテクチャーや設計手法が生まれては消えていきます。
毎回新しい案件に入るごとに、モヤモヤする設計を目の当たりにします。
そこでどうにも2つの大きな思想の違いがあることにようやく気づき始めることができました。
おそらく優秀な層の方々は数年前か、もっと前にそこにたどり着いているはずなので、この話は今更かもしれませんが、備忘録的にまとめていきたいと思います。
まだ頭の中でとっちらかってるので、今回は基本事項だけです。
- なぜ気づいたか、きっかけ
- なぜ「２種類」なのか
- 発散型と収束型（仮名）
- 喩えとか
- オブザーバーパターン、KVO、リアクティブ、マイクロサービスあたりは発散型
- 発散型が流行りつつある
- 発散型の欠点
- 今後の研究課題
なぜ気づいたか、きっかけ
リアクティブやRxの思想、あるいはデータバインディングという新しい方法を知る中で、彼らが何をしたいのか考える中で気づきました。
プラスアルファで、そういうったものを導入した時に、却って困る事象が起きた時に、既存コードの優位性を考える中で気づきました。
と言ってもこの考え方自体そもそも古典的な感じがします。
なぜ「２種類」なのか
ぶっちゃけ私がリアクティブ周りの思想を全部把握できないから、せいぜい2種類しか観測できないっていうだけです。
リアクティブシステムが注目を集める理由 | Think IT（シンクイット）
あっあっあっ（脳が壊れる音）
難しすぎる。
でもこういうパラダイムを作るときって、色んな複数の思想がゴチャ混ぜで導入されて意味不明になりがちなので、結局どんな差があるの？と限界まで削ぎ落とす分析は重要だと信じています。じゃないと私の矮小な頭では理解できません。
発散型と収束型（仮名）
収束型（コールバック型、中央集権）
これまで皆がやってきたプログラミング方法。
メインとなる処理の流れがあり、関数に処理を投げて結果を受け取る。
メインとなる処理の流れが基本的に全てを取り仕切る。
発散型（通知型、分散型、リアクティブ？）
関数に処理を投げるがコールバックは受け取らず、投げっぱなし。
反応的（何かが起きたら、別の何かが起きる）
各モジュールが自分の責任範囲について処理を取り仕切る。
喩えとか
会社に喩えると
収束型は「このタスクやっといて、終わったら報告してね」
発散型は「このタスクやっといて、終わっても報告はいらん」
（思いついたら追記します）
オブザーバーパターン、KVO、リアクティブ、マイクロサービスあたりは発散型
例えばマイクロサービスが分かりやすいです。
これは１個のモノリシックなサービスを作るんじゃなく、複数の独立したサービスに分割しようという話です。
発散型が流行りつつある
発散型に該当しているキーワードを見ると、スタイリッシュで次世代チックな感じがしないでしょうか？
実際これらは流行りつつあると思います。
理由はおそらく「非常に疎結合に作れる」故に「テストコードが書きやすい」あたりです。悪言い方をすると意識高い界隈で流行ってますね（毒吐き）。クソ真面目界隈でも良いですけど。
発散型の欠点
ただこれらには欠点もあるようで、それに気づかず安易に導入して苦しい思いをしている人やその煽りを食らっている人（私）もいるようです。
問題なのは、疎結合という部分です。
WebAPIの例が分かりやすいと思います。
一つのシステム内で完結する場合に比べ、例えば「アプリーWebAPI」のようなシステムが分断している場合では、対応しなければならないことが非常に多くなります。WebAPIはどういうリクエストが来ても内部を正しい状態にしなければなりません。
「処理を投げっぱなしにしていい」という状態を作るには
ような状態を作らなければならないのです。
つまり、１個のモジュールとして完璧でなければなりません。
これが非常に困難かつコストが高いのが問題です。
プログラムとしては理想的かもしれませんが、プロジェクト的には理想から程遠くなるかもしれません。
対して収束型と言うのは、言ってしまえばモノリシックなコードを見やすく分割しただけに過ぎず、しばしばモジュール化が甘くなります。
ただし代わりに全てのリクエストに対応する必要はなく、仕様上存在する有限個のパターンに対応できていればシステムは動きます。
プログラム的、テストコード的には理想的ではないにしても、プロジェクト的には正解であることもあります。
今後の研究課題
最近考えてる内容です。書かないと忘れそう。
- 発散型、収束型に適したシステムはそれぞれどのようなものか
- 発散型、収束型に適したプロジェクトはそれぞれどのようなものか
- それぞれの得意分野はどこにあるか
- 発散型、収束型は混ぜることは可能か
- 発散型、収束型が適していない場合どのような自体になるか
- 発散型、収束型が適していない場合、経験的に修正に非常にコストがかかるがそれは何故か（両立はやはりできないのか？）
- 発散型、収束型の利点と欠点
- 発散型、収束型の具体的な処理の流れ
- 収束型でテストコードは書けないのか
- それぞれの理想的な設計とは
- うっかり別の思想を導入してしまいがちなシーン
少なくともモバイルアプリについては、発散型が適していないと感じています。
一部の先進的な会社は確かに発散型を導入しているのですが、元々モバイルアプリに適していないのを理解した上でそれでも余りある理由があるから導入していると思うんですが、どうも他のプロジェクトでその文脈が無視されがちなのでは？と疑っています。
本件、中途半端ですが。
来年いっぱいくらい掛けて考えていきたいと思います。
いつまで「シリコンバレーでは」をやるの？
こういうのいつまでやるんですかね？
もちろんこういう「煽り記事」を書くとバズるのでメディアとしては有りなんでしょうけど、日経あたりがやってるとガッカリします。
「安いニッポン」というテーマは良いと思いました。世界的に円高かつ物価が高かった90年代に比べて、最近は相対的に安くなってきた。それはなぜか、またどういう影響があるか？というテーマだと思います。
上はこちら。
そういった時に、もちろん比較としてあげるべきは「他の先進国」ですし、もしくは「人材流出がどのくらい進んでいるか」という話でしょう。
決して「世界最高峰の地域ではこんだけ高い給料が出ていて1400万円なんて低所得者だ」という話では有りません。そういうのは週刊誌とかネットの隅でやる話です。
シリコンバレーITや中国ITは特殊となった
経緯を書くと長くなりそうですが、御存知の通りこの2地域は特殊な状態です。
アメリカや中国国内から見ても特殊です。
果たして日本や他国のIT業界と比べられるのかは慎重にならなければなりません。
もちろん比較対象としては不適切です。
「特殊地域とどう戦うか」というテーマなら有り
例えば日本国内において「地方はどう東京と戦うか」という話があると思います。
それと同じような話はできるはずですが、もちろんその話をするなら実際にどのくらい流入出があるのか、生活費や税制面でどういう差があるのか、働き口はどのくらいあるのかなど、多角的に分析するのが普通でしょう。
決して「都内で600万円は低所得〜」なんて記事にはならないはずです。
というか金額だけの比較は優秀な人をバカにしていない？
A社よりB社の方が高いからそっちに行く、というのは普通にありますが、それは他の条件が揃っている場合です。
仕事の内容、国や地域、自分がどういう雇われ型をするのか、など条件が揃って初めてお金の話になります。
「きっと優秀な人はさっさとこんな国なんて捨ててアメリカや中国に行くんだろうなあ」っていうのはどうもバカにしてる感じがします。
実際向こうに行ってる人の経歴を見ても、よりよい仕事がしたいとか、家族の都合とかの経緯がメインで、高いからそこに行くという人はまだ見たことが有りません（中国に一瞬絡んで儲かったという話はちょいちょい見たことがありますけど）
何がしたいんでしょうね。こういうゴシップ記事って。
努力の正体と、努力の方法
これ読みました。
努力2.0面白そうです。
「努力はもうしてる、でもまだ足りない、じゃあどうする？」という話は前に書きました。
「じゃあどう努力すればいいの？」について考えをまとめたいと思います。
- 頑張れる時間は有限
- どう努力すればいいのかという問題
- 「努力」の正体
- 努力が具体化されると努力という言葉が消える
- 目標到達のための方法がわからない
- 努力すれば何でもできる、わけはない
- 努力の方法が見つかってしまうと、何だか行けそうな気がしてしまう
- 前人未踏の目標はどうする？
- 「目標達成方法」はイノベーションの方法が一番近い
- 努力の方法＝目標達成のための行動の基本
- 正しく努力しても目標達成できない場合がある理由
- 良い行動案を見つけるには？
- 思いついた行動を、既に誰かやってるかもしれない
- 才能とはなにか
- 才能に努力で打ち勝つ方法
- 目標設定を上手くやって才能に打ち勝つ
- あとがき
頑張れる時間は有限
何か高い目標に対して頑張れる時間・機会というのは有限です。
これは、人によっては部活のときに、あるいは受験の時に、あるいは仕事を通して気づく事が多いと思います。特に競争が絡むと有限を感じるかもしれません。他の人も頑張ってるから、自他の差が出ず、努力してる／してないでは勝敗がつかなくなります。
どう努力すればいいのかという問題
実はこれ、問題設定がまずいと思います。
努力という言葉は非常に抽象的で、一般化するのは難しいはずです。
eスポーツ選手なのか、受験生なのか、社会人なのか、様々な状況で具体的な行動はガラッと変わってくるでしょう。
「努力」の正体
「努力」を一段階具体化すると「目標に到達するための行動」となると思います。
なぜこれほどまでに「努力」という言葉が多用されるのかといえば、その話題が出てくる前提状況として「目標に到達できていない」があるのだと思います。
この感情から生じる言葉の代用現象（今命名）というのは外でもあります。
例えば「金がほしい」は本当に欲しいものは金じゃないはずです。「死にたい」は大体の場合本当に死にたいわけではないはずです。
これらと同じように「努力」という言葉が飛び出す時は大抵「目標に到達したい」が根底に有り、しかしその方法がモヤモヤしてるから「努力」という言葉が出てくるわけです。
努力が具体化されると努力という言葉が消える
感情から生じる言葉の代用現象というのは、大抵その解決策が具体化されるとその抽象的な言葉は出てこなくなります。
金を得るには仕事をすればいい、となれば「金欲しい」が「仕事したい」になります。
死にたくなくなるためには恋人がいればいい、となれば「死にたい」が「彼女欲しい」になります。
例えば山登りを考えると、登頂のための手段は「歩いて登ること」です。
じゃあ「あなたは登頂のために歩くという努力をしているのですね？」と言われると、何かしっくり来ません。「登頂のために色んな道具を用意するなんて、努力家だなあ」と言われても、しっくり来ません。
単に目標達成のために普通にやってるだけです。
目標到達のための方法がわからない
努力という言葉が出てくるシーンでは、目標到達のための方法が分かっていないわけですから。まず、
「どう努力すればいいか」は
「目標達成のために何をどれくらいすればいいか」に置き換えましょう。
そちらの方が具体的です。
努力すれば何でもできる、わけはない
先程の登山の例を再び使うと
「歩くという努力を重ねればいずれ登頂できるか」
という話になります。
これはもちろん山次第です。「たしかにそうだ」という山もあれば、「んなわけあるか！」という山もあります。
これと同様に、目標次第で「努力でどうにかなるか」は変わってくるはずです。
努力の方法が見つかってしまうと、何だか行けそうな気がしてしまう
これは人間の悪い癖なのかもしれません。
登山ならそんなことないと分かるでしょうが、方法論がわからなかったものが分かるようになると、途端に目標達成できるような気がしてしまいます。
- 努力しているか／していないか
- 努力方法がわかってるか／わかっていないか
- 努力で目標到達可能か／可能じゃないか
- 実際にやるか／やらないか
この順で議論されるべきですが、どうしても1,2に終止してしまいます。
前人未踏の目標はどうする？
努力を考えた時、既に方法が確立されているかいないかは大きな違いがあります。
既に方法が確立されているものは、たしかに努力しているか／していないかが重要なウェイトを締めるのですが、そういったものは言葉がより具体化される（例えば「勉強してるか」）ので、努力で悩むのは結構「方法が確立されていない方」だったりします。
それで努力＝「目標達成のために何をどれくらいすればいいか」で悩むわけですね。誰に聞いても教えてくれないので。
「目標達成方法」はイノベーションの方法が一番近い
前人未到の目標に対して邁進している人は誰がいるか、世の中を見渡してみると、実はスタートアップ企業がそれに非常に近いです。
努力の方法は彼らから学ぶところが大きいと思います。
努力の方法＝目標達成のための行動の基本
企業がどのように目標達成していっているか、というのは語るととんでもない量になってしまいますが、基本的にやってることは変わらないと思います。
目標の明確化
行動の選択
定期的に振り返り
※目標が非常に遠い場合はそれを分割する。
※選択できる行動がなければ前もって調査する。
「行動」実は最初はあくまで仮説です。
「この行動をしたらこういった効果があり、目標に到達するはずだ」
これが実際どうだったかを振り返りでジャッジして、結果その行動を続けるのか、他の方法を試すのかを決めます。
何のことはない、試行錯誤です。
正しく努力しても目標達成できない場合がある理由
- 理論上不可能
- 良い行動仮説が見つからない
- 行動ができない
- リソースが足りていない
- 振り返りの失敗
色んな原因があります。むしろ失敗のほうが多いですね。
特に広大な未踏ゾーンから短時間で目標に達しようとするほど、結果は確率的になります（要は運）
1万人の努力家の中で1人が達成したとして、それはその1人が優れていたのか、運だったのかは実際のところ分からない事が多いです。
良い行動案を見つけるには？
一番手っ取り早いのは模倣です。
しかし模倣した時点で、模倣対象が確信を持ってその行動をしているかどうかはわかりませんし、その行動が自分に効果あるかどうかはわかりません。
例えば教科書を読んで理解できる人もいれば、理解できない人も居ます。「教科書を読む」という行動を模倣しても、自分が理解できない場合は別の手を探さなければなりません。
なので、世の中に対して模倣できそうな対象はたくさん見つけなければならないし、そのために日々観察が必要になります。
思いついた行動を、既に誰かやってるかもしれない
その行動を1回実行するのに5年かかるとしたら、それが成功するかは極めて運次第になります。
その運要素を下げるには、その行動を既に行った人を探して観察・ヒアリングする方法があります。
先輩の話を聞くとかがそれに当たりますね。
才能とはなにか
ある行動仮説を実行した際に、どのくらい良い効果があるかの平均を才能と呼べると思います。
才能のある奴というのは、どの行動を選択しても一定の成果を上げてしまうし、才能のない奴というのは、どの行動を選択しても効果が上がらないため、目標達成難易度に非常に差が出ます。
才能に努力で打ち勝つ方法
- 無駄行動をしない（リソースの節約）
- 行動の選定眼を養う（これも才能っぽいですが）
- 上手くやってる人を沢山見つける
- 目標設定をうまくやる
これらを上手くやるのは所謂「努力の天才」で、領域によってはそちらの方が重要なものもあります。
まあ今度は「努力の天才に勝てない」で苦しむんですけどね。
目標設定を上手くやって才能に打ち勝つ
戦ったら負けそうなシーンで逃げるという選択肢が有りなら、目標設定は非常に重要です。
自分ができない程度の目標を掲げてしまうと、如何に天才だろうが失敗してしまいます。失敗は非常に多くのリソースを無駄にします。
才能に自信がないなら、自分ができることを着実にやったほうが結果的に多くの目標を達成できると思います。
では目標設定はどのようにうまくやるかと言えば、
- 取りうる行動のボリュームと精度
- 模倣できる対象のボリューム
- 制限されているリソース（例えば締め切り）
- 自分の努力の才能
からある程度見積もれるはずです。
なので「自分がどのくらい精度良く努力できるのか」というメタ的な認識は非常に重要で、これは才能を使わずに何度目標達成してきたかに依存します。レベルアップするわけです。
結果的に「やらない」選択が増えて「チャレンジしないおっさん」になるリスクもありますけどね。
あとがき
思ったほどまとまりが悪い文章になってしまいました。
そのうち書き直したいです。
ちなみに前回の話と結構似ています。
ここらへんが似てる気がしますね。
所謂プログラミング的思考がそれだと思うんですが。
フリーランス4年目、年収と成長率。あと反省
去年
12月に入ると今年の分確定しちゃいますね。
- 年収・年商と成長率
- 2019年、変わったこと
- 年収・年商、平均時間単価、労働時間
- 通勤時間の圧縮
- 去年のコメントを振り返る
- 年商1500万円は目指すべきなのか？（一般論）
- 複業は有りか無しか
- 来年どうしよう？
- 注意事項
年収・年商と成長率
1495万円
前年比34％増
所感：
1500万円あたりいったのは良かったけど、税金と家賃が高すぎて上がった感じがしない。
諸々反省や抱負はまた別途書きたいです。年末年始の暇な時（あるのか？？）
2019年、変わったこと
サービス開発を一旦止めて、複業化しました。
今年のテーマは複業化でした。どこまで単価上げられるかとか、リモート案件をどう探すかとか。
記事まとめようかと思いましたが、今年は半分以上それっぽい話だったのでやめました。2019年の過去の記事がそれです。
年収・年商、平均時間単価、労働時間
働きすぎ問題
所感：3300時間とかいうわけのわからない数字。これ下半期はもっと稼働高いです。280時間〜400時間。ちょっと無理だなって感じがしました。いや分かってたんですが、一応試してみようかと思って。
この時より働いています。
実録・年1000時間残業するとどうなるか - IT業界で気づいたことをこっそり書くブログ
平均単価上がったのは良かったです。平均4300円（税込）くらい。今は4830円（税込）です。ここ1年の単価は飛び値を除けば税別2500円〜6000円です。ブレ過ぎ。
リモート案件が安いですね、3割位やすい。リモートOKで高くしてくれる優しい会社を探しましょう（希少すぎる） 半リモートだと割と単価維持できます。地方民には厳しい。
エージェント3社使いました。リモート案件は意外なことに「減少気味」だそうです。リモートが上手くいっていないそうです。オフショアと同じですね多分。
今年携わった案件は10案件です（意味不明）
通勤時間の圧縮
なぜここまで働けているかといえば、通勤時間を圧縮したからです。代わりに家賃に跳ね返ってきています。辛い。
365日で割って9.4時間働いているって言うことはつまり・・・？？？
年中無休コンビニ人間ですね。
ﾋｬｯﾊｰ
実際年休は30日くらいだと思います（主に疲れで脳死してぼーっとしてた日）
去年のコメントを振り返る
2019年は、とりあえず現状維持で1200万円はいくので、それプラス個人でサービス開発を継続していきたいです。
個人・・・サービス・・・開発・・・うっ、頭が！！
いや、上半期はネタ考えて結構途中まで作ったんですよ。下半期で死にました。
時間を捻出しなければと思います。
まあどちみちマネタイズを考えてないネタなので、来年もガリガリ働く必要があります。
年商1500万円は目指すべきなのか？（一般論）
無いですね案外。1500万円は。
体壊すほどに無茶するか、相当優秀かじゃないと無茶です。
今年ピークが190万円だったので、12ヶ月続ければ2200万円なんですが、1年持たずに命が危ないと思います。
あとやっぱり複数案件やると、炎上遭遇確率は上がるので、常にアレです。辞めたほうが良いです。
もし目指すなら、とにかく１案件は超安定状態を維持する必要があると思います。
複業は有りか無しか
技術的には少し安定してくるので有りだと思います。
遭遇する課題が非常に網羅的になってきます。
Firestoreも触ったし、ローカルキャッシュも触ったし、RxSwiftも触ったし、一人案件から上場企業までやったし、新人に教えたりもしたし、経験値はかなり得られます。
それでも見積もりミスするからもう嫌だ・・・
来年どうしよう？
もう1年同じ稼働を続ければ1700万円まではいける気がするんですが、それより個人サービスに切り替えていきたいんですよ。
でも税金怖いので結局稼働増やしちゃいそうな。
年明けまでに考えよう思います。
注意事項
なお金に余裕はありません
「わからない」を「わかる」にする方法の話
こちらによく書く話に近いんですが、今回はQiitaに書きました。
13000字・・・・・・
言語化して、色々気づきが合ったので良かったと思います。
わからないことをわかるようにするプロセスは案外ルーチンワーク化できるかもしれません。
- エンジニアリングにおける「わかる」ためのフロー
- 「わかる」とはどういう状態か
- 目的が生じたときの解決プロセス
- プログラム、開発で考えると理解しやすい
- 新人はどのようにしてプログラミング的思考に到達するのか？
エンジニアリングにおける「わかる」ためのフロー
はこういう感じだと思います。
よくもまあこういうフローを無意識で普段やってますよね。人間って不思議。
「わかる」とはどういう状態か
は下図のようなんですが
似たことはずっと考えてました。
ここらへん子供の頃から考えてる気がします。
目的が生じたときの解決プロセス
も言語化できてよかったです。
案外シンプルなんですが、ここに気づくのに結構時間がかかる気がします。
ちなみに現実の業務だと要素が増えます。例えば納期とか予算とか。
プログラム、開発で考えると理解しやすい
面白いのは、現実の複雑な振る舞いやプロセスを、プログラムという仮想上で再構築しているので、現実の複雑な振る舞いやプロセスを理解するのに、プログラムで考えると理解しやすいということです。
プログラムもそうだし、開発業務そのものもそうです。
科学的手法というのは残った理想と現実とのギャップを埋めるための最後の武器という感じがします。
プログラミング的思考って多分ここらへんの話ですよね？これを誰かに教えるというのは非常に骨が折れそうです。
例
新人はどのようにしてプログラミング的思考に到達するのか？
こういう技術は高校生までは「小賢しさ」として認識されると思います。
既に体系化された知識を学ぶ勉強・暗記が是ですから。その思想に誰であれ多かれ少なかれ毒されます。
それでもあまり毒されず、科学的手法・実験的手法が好きな小賢しい奴らがプログラマーになってるのではないかと思います。つまりプログラマーになってから覚えてる人は少ないのでは？という疑いがあります。
でもそういう曖昧な部分ってプログラミングという文脈では悪ですよね。詳らかにしていけたほうが良いと思うんですが、如何せんここの領域に興味を持ってる人が少ない感じがします。たぶん新人はまだまだ苦しむのではないでしょうか？
まずこれらを体系化できたとして、新人がマスターできるのかはよくわかりません。どうなんでしょうか。
NoCodeはさほど伸びないし関わらない方が良いと思う理由
ノーコードがバズってるみたいですね。何度か複数の記事を見ました。
ノーコード系の記事を読むとすごく良さそうに見えてきますが、個人的にこれ系がユーザー企業以外には上手くワークしないのではいうのは数年前から思ってました。私の認識を書いておきます。
・・・
とやる気を出してみたは良いものの、ちょっとこの話だるいですねこれ。
「SaaSもそろそろ頭打ちだしエンジニアが絡んでもしょうがないでしょ、PaaSならともかく」で全部済むと思うんですがどうでしょうか？（投げやり）
- サービス界隈はどうなっているのか？
- SaaS文脈のNoCodeはエンジニアの介在する余地がない
- そもそもSaaS規模が大きいわけでもない
- 新しい◯◯業界は見つかるか？
- EC業界はそもそも特殊
- PaaS文脈でのNoCodeはどうか？
- 誰にとってNoCodeは有益か
- ユーザー事業者にとってNoCodeは有りなのか？
- 新ジャンルのNoCodeをモックや価値検証に使うのは良いのでは？
- NoCode+マイクロサービスがこれからの流行りだろ？
- 使いみちをもっと考えてみる
- まとめ
サービス界隈はどうなっているのか？
大体１個のサービスの形を想像してください。例えばEC、SNS、出会い系、ブログ、人材系、もしくはツールだと写真加工とか、メモ帳なんかでもそうです。
それらをカオスマップにすると大体は以下のようになっています。
少し分かりづらいですが、該当サービスを使いたいユーザー企業が10万あったとして、どこにぶら下がるかという話です。完全フルスクラッチは自分たちで運営するパターン。生成系サービスは自分たちで運営するけど、フルスクラッチではないパターンです。完全フルスクラッチと、生成系サービスの間に実はCMSのようなものがあります（WordPressとかEC-CUBEがわかりやすい）
EC業界が非常に分かりやすいです。
昔はこの「完全フルスクラッチ」が多かったのですが、徐々に汎用の方に流れていきました。要は戦国時代で淘汰された感じです。
歴史的に見ると、ITバブルが専用全盛期、2010年前後が半自動生成の全盛期（CMSのような、数十万円で導入するもの）です。
アプリが登場してからは一気にALLジャンルが増えて、その後徐々にニッチジャンルが増えてきて（というか、規模的に会社が成立するくらいに市場が成長してきて）という感じです。生成系は2010年頃から徐々にという感じですね。スマホ登場後くらいからです。
なので「え、今更NoCodeの領域がバズるの？」という感じで困惑します。なんか遅くない？
って、よく考えたらNoCodeってSaaSみたいなもんですよね、名前を変えただけかもしれません。
SaaS文脈のNoCodeはエンジニアの介在する余地がない
敷いて言えばデザイナーなら介在余地があるかもしれませんが、エンジニアを排除して安く早くあげようって時にエンジニアの存在は邪魔です。
もしやるとすると導入コンサルという立場になります。
そもそもSaaS規模が大きいわけでもない
ここが分かりやすいです
楽天３兆円、Amazon２兆円、ヤフオク１兆円、メルカリ4000億円
みたいな状態で、SaaSであるMakeShopが1600億円、BASEが210億円です。
大体ニッチジャンルの１社２社と流通規模が同じくらいじゃないでしょうか。minneは１つのニッチジャンルですが120億円です。
これらは流通総額なので、手数料ビジネスだと売上はその2％〜10％というところです。規模感的にわかりますか？ 流通総額100億円だと、スタッフ数40人とかそのくらいですし、1000億円だとスタッフ数は数百人だと思います。
海外を見ると大きいように見えますが、やはり他の会社と比較するとさほどでもないです。
新しい◯◯業界は見つかるか？
あるとすればEC業界ではない、未成熟な新ジャンルのサービスのNoCode（SaaS）領域に乗っかることですが、未成熟な新ジャンルが無いんです。
そんな物ないというのは、もう投資家や起業家が何年も頭を悩ませていることです。新しいサービスは出せるかもれませんが、新しいジャンルはおそらく数十年に一度の革命的な出来事なのだと思います。
EC業界はそもそも特殊
いやいや、いろんなサービスが色々出ているじゃないか、と思われるかもしれません。それはそうなんですが、違うんです。「大量のサービスが存在していて良いジャンル」が無いんです。
例えば、ECサイト、メディア、ブログ、コーポレートサイト、くらいですかね？ツール系を除けばだいたいそのくらいです。大体のジャンルは勝者総取りで、すぐに淘汰されてしまうのです。
するとエンジニア的にはその会社しか無いので困りますし、SaaSなんて要らないわけです。位置づけ的にはSaaSとその1社が同じ立場ですね。ユーザー企業相手の商売です。
パターン化できなければNoCode（SaaS）にもできません。
パターン化できるサービスが有るなら、アプリ開発の仕事はもっと多かったと思います。ECサイト構築とかHP制作と同じ文脈でアプリ開発を何となくやって火傷した人の何と多いことか。
PaaS文脈でのNoCodeはどうか？
もっと引いて俯瞰で見ると、サービス界隈はこうなっています。
各ジャンルを全部束ねているのがAppleやGoogleで、支援している会社や、開発のためのツールを提供しているような会社があります。
ここにNoCodeの介在する余地は確かにあるんですが、それってAWSとかGCPみたいな話で、ちょっと今話題になってる文脈とずれますよね。
こっちはもちろんそこそこに伸びると思いますが、お手軽とは程遠いですよね。あれ、めっちゃむずい・・・
もちろんもう少しSaaS寄りで、お手軽に問い合わせフォームを作るとか、ビデオチャットを作るとか、そういうのは増えてる感じがしますがそれもうコーディングしてます。
誰にとってNoCodeは有益か
投資家
確かに収益の増加率は良いんです。そういう時代ですから、あと5年くらいは伸びるんじゃないかと思います。
投資家なら注目していいと思います。
ですがNoCodeの提供側にならない限りエンジニアとしては旨味がありません。
NoCode提供側
これはわかりますよね。
今の時代、会社選びをする時に、選択肢としては
- Allジャンルの会社（大抵大企業、吸収合併が多い）
- ニッチジャンルの会社（小粒だが安定してたりする）
- NoCode（SaaS）提供会社（少ない）
- PaaS, laaSの会社（もっと少ない）
のどれかです。
デザイナー・コンサル
開発以外に強みがある人は、導入支援を仕事にするのもありかもしれません。
でも予想以上に覚えることとか多い印象があります。
あとEC-CUBEとかWordPressのように、わかりやすい一個の市場として確立されていない感じがします。かといって全部覚えるのは無理です。
ユーザー事業者にとってNoCodeは有りなのか？
価値検証するならまずはAllジャンルかニッチジャンルで試した方がいいと思います。ユーザーを連れてくるのが本当に大変です。
例えば物販なら楽天とAmazonとメルカリに出して、売れるようなら独自で出店するで良いと思います。その後でより拡大しようといった際に、NoCodeなのか、ニッチジャンルなのか、となってくるでしょう。
ちなみにオールジャンルで目立つと、ニッチジャンルサービスから直接アプローチがあると思います。「うちでも販売しませんか？」みたいに。
他のサービスでも似た感じです。
新ジャンルのNoCodeをモックや価値検証に使うのは良いのでは？
まず、新ジャンルをNoCodeで作れない可能性が高いと思いますし、ジャンルとして確立された頃には既に市場における価値検証は終わって淘汰が始まっていることが多いのではないでしょうか？
NoCodeで機能作成ができるということはそういうことなんですよね。
たとえば、ある種のトリガーがあって、ヨーイドン！でいち早くサービスを作った人が勝ち、みたいな状況で、たまたまNoCodeで適合するものがあればいいですが、あるんですかね？
また、これがすごく難しいんですが。NoCodeでサービスを作って上手くユーザーが付かなかった時、ちゃんと価値検証できてる自信あるでしょうか。機能追加してまた試したくなりませんか？これまで色んなプロジェクトで色んな起業家を見てきましたが、とてもじゃないですがやめそうになりです。価値検証のパラドックスと言うか、「試し」は大抵の場合その人にとって9割確信があるんですよね。じゃあ二度手間にしかならないのではないでしょうか。
どうにも、上手く使い所がありそうで、本当に使える人は一握りなのではないかと疑っています。
NoCode+マイクロサービスがこれからの流行りだろ？
そこまで行くと設計が必要なので専門性が必要なのではないでしょうか？
NoCodeのPaaSですよね。
使いみちをもっと考えてみる
自分の不得意なデバイスでなにか作りたいときに使うのはどうか？
色々考えましたが、これは有りかもしれません。
例えば私はiOSアプリ開発者ですが「このサービスを作るなら先にWebがあって、その後にアプリだな」というときに「よし両方作ろう」は無理です。
Webの方は凡庸だけど、アプリだと自身がある。でもWebのランディングページが必要！みたいなシーンだと使えるかもしれません。どうなんでしょうか？レア過ぎます？
Laravel覚えるかNoCode覚えるかで迷うことになるんですね・・・うーん。
ファウンダーが動くレベルのモックを作る
これも有りかもしれません。
起業家志望の方がたまにWebを勉強するためにスクールに通っていたりしますが、それよりなら動くレベルのモックアップを作って、「これに機能追加したものを作ってくれ」と依頼を出せば非常にスムーズです。α版として公開してしまうのも有りですね。そんなことできるのかわかりませんが。
企業が超低予算でとりあえず動くものを作る
自社に強みが有り、そのサービスを出せば結構行けると思うけど、稟議が通らない！じゃあ一旦出して反響が多いことを証明しよう、そして稟議通して予算もらってフルスクラッチしよう。
みたいな話では有りかもしれませんね。
社内向けツールとして活用する
あっ、これ結局SaaSの利点一覧だ！
要は
- 採算がさほど見込めない
- 技術者が居ない
- とりあえず作りたい
こんな状況ですか？
まとめ
誤解されそうなので念の為に書くと、もちろんこの領域は適切なユーザー企業が適切な事業ステージで使うには素晴らしいモノだと思っています。
別に新しい概念ではない＋エンジニアが介在できないってだけです。
「新しい概念でない」っていうのは、いつものやつです。
１．既存の上手くいってる概念をグルーピングして、新しい名前をつける
２．それに属するモノだから上手くいきますよ！と喧伝する
１で取り上げられるのは古くからあるサービスだし「今これから来る」と言う説得材料にはなりません。利用するのはいいですけど、技術者的にはニッチの細道に突入する感じになるので、死なないように程々に。
これは一見すると非常によく見えるので、これからどんどん持ち上げ記事が出ると思います。おっさん連中は面倒くさいから見て見ぬ振りするんですよね。
＿＿＿＿＿＿＿＿＿＿
蛇足追記：
SaaSカオスマップを見てみよう
https://thebridge.jp/2019/09/smartcamp-saas-market-report-2019
ガチのNo-Code Developmentの例 kissflow
https://kissflow.com/no-code-platform/
こういうのはもはや「お手軽」「技術者以外が」って文脈は消えて、新言語に近いですね。これは純粋に宗教戦争になりそう。
もう少し中間のNo-Codeの例
https://techcrunch.com/2019/11/04/microsoft-launches-power-virtual-agents-its-no-code-bot-builder/
あ、何で流行ってるか少しわかりました。
これはRPAとかワークフローオートメーションが流行ったから、それをひっくるめてNo-Codeという概念が作られ、案の定言葉の定義が曖昧だから妙なバズワードになってる感じかもしれませんね？
ってなると、やはり基本は業務効率化の方に使うことを意識したほうが良いんじゃないでしょうか？？
まあそっちは伸びるかもしれないですよね。
サービス開発に使うっていうのは応用なのでは？
ちなみにLow-Codeという概念もあるそうです。
