image

image

image

NoCodeに関して、新しく書かれるプログラムの集合を頭に浮かべて「NoCodeでできることは一部に過ぎない」「NoCodeではカバーできないようなものがある」みたいな話を見たけど、これは視野が限定的だと思う。

「新しくプログラムを書くことによって解決される問題」だけに視野が狭まっている。

  • image
  • 「NoCodeでカバーできることは一部に過ぎない」という見え方をする

顧客が解決したい用事(Job)のうち、新しくプログラムを書いて解決されるものは一部に過ぎない

  • image
  • 大部分の用事は既存の道具を組み合わせて片付けられてる。
    • 紙とペンだったりExcelと電子メールだったり
    • もともと「新しくプログラムを書く」ではない選択肢がある
    • ここに新たなNoCodeツール(N)が加わることは、顧客視点では何も特殊なことではない。
      • image
    • 顧客は自分の用事を片付けるのに便利な道具があれば使う

技術的には、NoCodeツールを使うことによって解決できる問題は、プログラムを書くことによっても解決できる。

  • つまり、NoCodeが解決しようとしているのはそもそも技術的問題ではない。
  • 多くの顧客企業に、現時点でプログラムを作ることなく処理している用事がある
    • これを支援するプログラムがあれば生産性が向上する
    • しかし自社内で作ることができない
    • プログラムを外注すれば解決できるが、その費用が期待する効用に比べて高すぎるので外注しない
  • NoCodeはこの領域を取りに行く。

NoCodeツールがクラウド上にあってAPIリッチである場合、プログラムを書くことで用事の自動化ができる

  • これがプログラマにとって興味深い点
  • 用事全体をこなすプログラムを書くよりも圧倒的に少ない作業量で自動化できる
  • この領域(LowCode)は、この領域を生み出すことに自覚的なNoCodeツールの普及によって作り出される。
    • 具体的にはAPIの整備、サンプルコードの公開など
  • 顧客視点ではNoCodeも用事をこなすための一つの手段に過ぎない。
    • 顧客視点では「紙とペン」や「APIのないアプリ」もNoCodeツールも「用事をこなすための道具の一つ」に過ぎない
    • プログラマはNoCodeツールを使ってもらった方が価値の提供がしやすくなる
  • この「LowCode領域が作り出されること」がプログラマ視点では面白いんだけど、顧客視点ではピンとこない人が多い。
    • 長期的に見ると「用事の自動化」が入手しやすくなる効果がある
    • まだまだ認知に手間と時間をかけないと認知してもらえない感じ
  • image
    • この図はイマイチだと思う、定義域が不明瞭
    • NoCode普及後に生まれる仕事が同じ図に書かれてるのがおかしい
    • image
      • こうか