No-Code JP 第0回で様々な熱い言葉を聞いて思ったこと

以下は、気になったことのメモとか感想を書いています。
登壇者、発表者、主催企業などの意図とは異なる可能性がありますことをご了承ください。

No-Code JPの設立主旨

私は以下のように受け取りました。

「誰もがシステム開発をする世界を広める」が目的。なので誰もがビルダー。 #nocodejp

— やました (@yamamanx) 2019年4月9日

「クラウド」、「API必須」、「ノーインストール」同意 #nocodejp

— やました (@yamamanx) 2019年4月9日

私の俺のNo-Codeパネルディスカッション

※みなさんの写真撮ったのですが、Microsoft Pixを使い慣れてなくて、撮ったはずが取れてなかったですorz

kintone&gusuku Customineのどりぃさん
技術書店ではコスプレするらしい。
kintoneはサイボウズさんのノーコードサービス。
そしてカスタマインは、kintoneでもJavaScriptを使ったカスタマイズが必要な要件をさらにノーコードでやってしまえるサービス。

LogicAppsの松本さん
オルターブースのデザイナーさん
トリガーとアクションをつなげていくのがLogic Apps。

Power Platformの清水さん
Power BI王子の清水さん
Power Platformとは、エンドユーザーが自分で作るところからできるプラットフォーム。

DataSpiderの築山さん
ノーコード芸人で少し前までメーカーにいたけど最近転職された。
DataSpiderは様々なサービスをつなぐサービス。
DataSpiderは何を使うときもあると便利だと思う。kintone使おうがPowerApps使おうがSalesforce使おうが、何使おうがDataSpiderあると便利。

Salesforceの山田さん
ウフル所属、Salesforce MVPを2019年から拝命されている。
おめでとうございます！

パネルディスカッションの熱い言葉を聞いて思ったこと

自分のTwitterより抜粋。

• 「今までと何が変わるか」→ニーズの変化に対応できる
• 「今までと何が変わるか」→正しいものが早くできる
• 「今までと何が変わるか」→結果的にデータが集中する。
• 「今までと何が変わるか」→自分で作れるから齟齬が減る。
• 「今までと何が変わるか」→作ることによりデータのつながりを意識しだす。結果、データがつながる。
• ノーコードでできないことは、ローコード、そしてコーディングへ。でもできるできないの議論よりも、やるやらないの議論が現場に必要だと思う。
• 「ノーコードとそうじゃないの違い」→これマネージドとアンマネージドのち外にも似てる。運用コストの多い少ないもありそう。
• 「ノーコードとじゃないの違い」→ノーコードはある程度制約の中で作られるから、クオリティが保たれやすい
• 教育は自己選択式で機会をとにかく増やす。自分たちで勉強会をやっても、外部の研修を使ってもいい。会社が機会をとにかく作る。ってのはどうでしょう？
• UIの違いが売上に影響するなら必要ですよね。なので業務アプリは使いやすくて入力が少なくて操作が少なければいいと思っている方です。
• 王子のカレーの例え、わかりやすい。ちょっとアレンジすると、レトルトカレーで充分な要件のに、スパイス混ぜたり煮込んだり、そして混ぜ続けなければならない鍋の管理をしたい人っているのかなあ。ってことも。
• だからクラウドでできることが必要になるんですよね。全員がローカルのあっちこっちで作ってしまうとデータが分散する。
• そもそも、野良ローカルツールとか、野良ノートとか、野良手書きメモとか、野良チェック表とか、野良電話とか、野良承認とか、野良メールとか、野良のりで貼るやつとか、野良コピーとか、野良サインとか、野良押印とか
• 営業部門がSQL書いたほうが早いのと同じ問題
• エンジニアはAPI作りまくって、手元の仕事は各部門が現場内製でやったほうが正しくて早い。自分は事業部門なので手元で必要なものは自分で作りたいし作ってる。社内APIいっぱい欲しい側。
• そんな私は明日から2日間、Pythonのトレーニング講師をするわけですが、「できないよりできる」方がいいし「知らないより知っている」ほうが絶対にいいとうのはぶれてません。

感想

ノーコードなサービスが出てきたことにより選択肢が広がっている。
でもこれが1つの選択肢であるということを忘れちゃいけない。
そしてノーコードサービスではなくノーコードツールはずっと前からあった。つながらなかっただけ。クラウドになってAPIが標準になってサービスになって繋がるようになった。
選んで繋げて組み上げることで、実現できることが増えてきた。
結果、実現できる人も増えることになる。
そして、10数年言い続けていることが、今時点の私の結論でした。
「やる人が作ることが、最も正しく速い方法です。」

最後までお読みいただきましてありがとうございました！

「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第3版」という本を書きました。

「AWS認定資格試験テキスト　AWS認定AIプラクティショナー」という本を書きました。

「ポケットスタディ AWS認定 デベロッパーアソシエイト ［DVA-C02対応］ 」という本を書きました。

「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。