ビジネススクールで受講した「テクノベート・シンキング」の学びを全12回でまとめるシリーズ、その8。
第4回の前半がレポート提出（前回の記事で書いた）で、後半はガラッと雰囲気が変わる。テーマは「テクノベート・シンキングによる問題解決プロセスにおける実装手法」──ノーコードをはじめとする、さまざまな実装手段を学ぶ回だ。
Scratchで論理的に考える力を鍛えてきた。じゃあ実際にビジネスで何かを形にしたいとき、何を使えばいいのか。この問いは、テクノベート・シンキングの後半戦に入るための重要な転換点だった。
Scratchで「考え方」を学んだ、次は「作り方」
ここまでの授業でScratchを使ってきたのは、プログラミングの「考え方」を体験するためだった。変数、リスト、条件分岐、ループ、フローチャート──論理設計の基礎部品を手で触って理解する。
Scratchの良さは、構文エラーの心配がないこと。ブロックを組み合わせるだけで動くから、「ロジックに集中できる」。環境構築もいらない。ブラウザさえあれば動く。プログラミング未経験者にとっては理想的な入門ツールだった。
しかし、実際のビジネスで何かを作ろうとしたとき、Scratchでは限界がある。データベースとの接続、Web APIの呼び出し、ユーザー認証──ビジネスアプリに必要な要素は、Scratchでは実現できない。「じゃあ何を使って実装すればいいのか？」──その問いに答えるのが第4回後半の内容だった。
実装手法の選択肢は思った以上に広い
授業では、実装手法をいくつかの層に分けて紹介された。
ノーコードツール：コードを書かずにアプリを作る
プログラミング不要で、画面操作だけでアプリやワークフローを構築できるツール群。代表的なものにAppSheet、Bubble、Adaloなどがある。
AppSheetはGoogleスプレッドシートをデータソースにしてモバイルアプリを自動生成できる。業務の在庫管理や日報入力のような「データの入力・参照・更新」が中心のアプリなら、数時間で形になる。Bubbleはもう少し複雑なWebアプリを構築でき、ユーザー認証やワークフローも視覚的に組める。Adaloはモバイルアプリに特化していて、UIのカスタマイズ自由度が高い。
ノーコードの強みは圧倒的なスピードだ。アイデアを思いついた翌日にはプロトタイプが動いている、ということが本当に起きる。一方、弱みは「ツールが想定していない処理」に弱いこと。複雑な計算ロジックや独自のアルゴリズムを組み込もうとすると、ノーコードの枠内では厳しくなる。
ローコードツール：必要なときだけコードを書く
基本はビジュアルに構築しつつ、必要に応じてコードを書き足す──ノーコードとフルプログラミングの中間に位置するアプローチ。Microsoft Power AppsやOutSystemsが代表格だ。
ローコードの利点は、ノーコードの手軽さを保ちつつ、必要な箇所だけカスタマイズできること。たとえばPower Appsで基本画面を作り、特定の入力バリデーションだけExcel関数に似たPower Fxの式で書く。ノーコードよりは自由度が高く、フルプログラミングよりは開発工数が少ない。
企業でよく使われるのは、既存の業務システムと連携する場面。既にMicrosoft 365を使っている組織なら、Power AppsでSharePointやTeamsと連携するアプリを短期間で作れる。この「既存の環境との親和性」がローコードの大きな強みだ。
API連携・自動化ツール：既存サービスをつなげる
Zapier、Make（旧Integromat）に代表される自動化ツール。新しいアプリを「作る」のではなく、既にあるサービス同士を「つなげる」ことで価値を生む発想だ。
たとえば「Gmailに特定の件名のメールが届いたら、添付ファイルをGoogle Driveに保存し、Slackに通知する」という処理。手作業でやっていたことを、ノーコードで自動化できる。
この手法の面白さは、組み合わせの発想にある。「どのサービスとどのサービスをつなげれば、どんな業務が楽になるか？」を考える力は、まさにテクノベート・シンキングだ。技術を知っている必要はないが、「何が自動化できるか」を構想する力は必要になる。
フルプログラミング：完全な自由と引き換えに
Python、JavaScript、Swift──プログラミング言語を使って完全にゼロから構築するアプローチ。自由度は最大で、ノーコードでは実現できないような複雑な処理も、AI連携も、独自アルゴリズムの実装もできる。
ただし、学習コストと開発工数は桁違いに大きい。簡単なCRUDアプリ（データの作成・読取・更新・削除）を作るだけでも、ノーコードなら数時間で済むものが、フルプログラミングだと数日かかることもある。
フルプログラミングが必要になるのは、高度なカスタマイズが必要な場面、大規模なユーザーを抱えるサービス、セキュリティ要件が厳しい場面など。「全部プログラミングで作るべき」ではなく、「プログラミングでしか解決できない場面がある」という理解が重要だ。
選択肢の判断基準：何をもとに「何で作るか」を決めるか
ここで重要なのは、これらは優劣ではなく選択肢だということ。「ノーコードが簡単で初心者向け、プログラミングが上級者向け」ではない。解くべき問題に対して最も効率的な手段を選ぶのが正解であり、それぞれのツールには「得意な場面」と「不得意な場面」がある。
判断基準として考えるべきは、大きく4つだと感じた。
1つ目は、問題の複雑さ。単純なデータ入力・参照アプリならノーコードで十分。複雑なビジネスロジックが絡むならローコード以上が必要。独自のアルゴリズムが核になるならフルプログラミングが適切。
2つ目は、スピード。「来週までにプロトタイプが欲しい」ならノーコード一択。「半年かけて本格的に作る」ならフルプログラミングも選択肢に入る。ビジネスでは「完璧なものを遅く出す」より「80点のものを速く出してフィードバックを得る」ほうが価値が高い場面が多い。
3つ目は、拡張性とスケーラビリティ。利用者が10人のチーム内ツールなら、ノーコードで十分運用できる。数万人が使うサービスなら、パフォーマンスやセキュリティの観点からフルプログラミングのほうが適切なことが多い。
4つ目は、チームのスキルセット。エンジニアがいないチームでノーコードを使えば、自分たちで業務改善が完結する。エンジニアチームがいるなら、彼らの技術力をフルに活かせるフルプログラミングのほうが成果が出やすいかもしれない。
「論理設計は人間が、実装はツールが」の意味が深まった
テクノベート・シンキングの基本思想は「大量データ・繰返し処理はコンピューターが、論理設計は人間が」。ここまでの授業でその前半を体験してきたが、ノーコードツールの話を聞いて後半の実感が初めて湧いた。
ノーコードツールを使えば、プログラミングの詳細を知らなくてもアプリを作れる。でも、「何をどういうロジックで処理するか」の設計は人間がやる必要がある。ツールが肩代わりしてくれるのは実装の手間であって、設計の頭ではない。
AppSheetで在庫管理アプリを作る場合を考えてみよう。画面のレイアウトはツールが自動生成してくれる。でも、「在庫数がしきい値を下回ったら自動発注する」というビジネスルールは、人間が定義しなければならない。しきい値をいくつにするか、発注先をどう選ぶか、例外ケースをどう扱うか──これらの判断はツールにはできない。
Scratchでフローチャートを描き、条件分岐を設計し、データの流れを考えた経験が、ノーコードツールを使うときの「設計の土台」になる──これが第4回後半のメッセージだったと理解している。
IT畑の私が感じた「ツール選定」の共通点と温度差
ツール選定の話は、IT畑で長くやってきた身として、すごく馴染みのあるテーマだった。
共通点：判断軸の構造は同じ
インフラ設計でも「クラウドかオンプレか」「マネージドサービスか自前構築か」を判断する場面がある。そのとき考えるのは、コスト・スピード・カスタマイズ性・運用負荷のバランスだ。ノーコード vs プログラミングの判断軸も、本質的には同じ構造をしている。
たとえばクラウドの「マネージドデータベース」は、ある意味インフラのノーコードだ。DBのチューニングやバックアップをクラウドベンダーが肩代わりしてくれる代わりに、細かいカスタマイズは制限される。利便性と自由度のトレードオフ──この構造は、ノーコード vs プログラミングの関係と同じだ。
温度差：何を最優先にするかが違う
ただ、インフラの判断は「安定性・セキュリティ」が最優先になりがちだ。システムが止まったら業務全体が停止するし、セキュリティ事故は取り返しがつかない。だから「実績のある枯れた技術」を選ぶことが正義とされる場面が多い。
一方、アプリ開発の判断では「スピード・ユーザー価値」が優先される場面が多い。市場の変化に追随するために、完璧さよりもスピードを求められる。ユーザーのフィードバックを早く得て、改善サイクルを回す。
この温度差は、部門を超えて仕事をするときに意識しておくべきだと思った。インフラチームが「まだ検証が十分じゃない」と言い、アプリチームが「もう市場に出さないと遅い」と言う──この対立は、どちらかが間違っているのではなく、優先する価値観が違うだけだ。両方の視点を理解している人が、チーム間の橋渡しをできる。
ノーコードが「勝てる」場面と「厳しい」場面
授業の内容と自分の経験を合わせて、ノーコードが特に力を発揮する場面と、逆に厳しくなる場面を整理してみた。
ノーコードが勝てる場面：
- 社内の業務改善ツール（日報、在庫管理、承認ワークフロー）
- プロトタイプ・MVP（最小限の機能で市場検証したいとき）
- データの入力・参照が中心のアプリ
- エンジニアリソースが限られていて、ビジネス部門が自走したいとき
ノーコードが厳しい場面：
- 独自のアルゴリズムや複雑な計算処理が核になるサービス
- 大規模なユーザーを抱えるBtoCサービス（パフォーマンス・スケーラビリティ）
- 高度なセキュリティ要件がある金融・医療系システム
- 他システムとの複雑な連携が必要な場面
重要なのは、「ノーコードが厳しい場面」で無理にノーコードを使おうとしないこと。ツールの限界を正しく理解しているからこそ、適切な選択ができる。そして、その理解のベースにあるのが、Scratchで培った「プログラミングの考え方」だ。
「開発の民主化」がもたらすもの
ノーコード・ローコードの普及は、しばしば「開発の民主化」と呼ばれる。これまでエンジニアにしかできなかったアプリ開発が、ビジネス部門の人にもできるようになる。
この流れは、私はポジティブに捉えている。なぜなら、業務の課題を一番よく知っているのは、その業務をやっている人自身だから。課題を知っている人が自分で解決ツールを作れるなら、「要件をエンジニアに伝える」というコミュニケーションコストが丸ごとなくなる。
ただし、民主化にはリスクもある。ガバナンスの問題だ。各部門がバラバラにアプリを作ると、データの整合性が崩れたり、セキュリティホールが生まれたりする。自由に作れる環境を整えつつ、全体の秩序を保つ──この両立が、組織としてノーコードを活用するときの課題になる。
これもまた、クラウド導入時の「シャドーIT」問題と同じ構造だ。便利だから勝手に使い始める人が出て、情シスが把握しきれなくなる。ツールの民主化は技術の話だけでなく、組織マネジメントの話でもある。
Scratchの経験が「設計基盤」になるという実感
この授業を通じて強く感じたのは、Scratchで手を動かした経験が、あらゆる実装手法を「評価する目」を養ってくれたということ。
ノーコードツールの画面を見たとき、「ここで条件分岐を設定しているんだな」「このワークフローはループ処理だな」と構造が読める。API連携ツールの設定画面を見ても、「このトリガーが入力で、このアクションが出力で、間にフィルタ条件がある」と理解できる。
これはScratchでブロックを組み立て、フローチャートを描き、変数やリストの挙動を体験したからこそ持てる視点だ。プログラミングの「考え方」を知っているからこそ、プログラミング以外のツールも正しく評価できる。
逆に言えば、プログラミングの考え方を知らないままノーコードツールを使うと、「動くけどなぜ動いているか分からない」状態になりかねない。それでは、トラブルが起きたときに対処できないし、ツールの限界を見極めることもできない。
学び：「何で作るかを選べる」のがリーダーのスキル
第4回後半の学びを一言でまとめるなら、ビジネスリーダーに求められるのは「自分で全部コードを書く力」ではなく、「何で作るかを適切に選べる力」だということ。
そのために必要なのは、プログラミングの基礎的な考え方（変数・条件分岐・ループ・データ構造）を理解していること。それがあれば、ノーコードツールの画面を見ても「ここで何が起きているか」がわかる。エンジニアとの会話で「それは技術的にどのくらい大変か」が肌感でわかる。
そしてもう一つ大事なのは、技術の選択を「上下関係」で捉えないこと。「ノーコードは初心者向け」「プログラミングが上級者向け」という思い込みは捨てるべきだ。プロのエンジニアがノーコードを選ぶこともある。それは彼らが能力不足だからではなく、その場面ではノーコードが最適解だと判断したからだ。
Scratchで散々手を動かした経験が、ここでつながった。プログラミングを「体験した」からこそ、プログラミング以外の選択肢を正しく評価できる。これはテクノベート・シンキングが目指す、テクノロジーを「使いこなすリーダー」の姿そのものだと思う。
次回：AI Coachアプリを自分で作ってみた話
第5回の事前課題は「自分のビジネスや生活に役立つアプリケーションを、何らかのツールを使って実装する」。ノーコードツールとAI APIを組み合わせて、自分専用の「AI Coach」アプリを実際に作ってみた話を次回書く。今回学んだ「何で作るかを選ぶ力」を、いよいよ実践で試すことになる。
今回参考にした書籍
