ローコードでアプリ開発するときの3要素を考えてみた

# はじめに
**ノーコード / ローコード** でアプリケーションが開発できるツールは、国内外問わず、いっぱい出ていて、実運用も一巡してるように観測できてる。ITの専門家ではない人が、マウス操作を中心に必要なアプリケーションを作ることができるというのは、とても素晴らしい。開発者が不足している現状において、優れたアプローチのひとつだと思う。

その使用が広がって、**民主化**しつつあるからこそ、成功例以上に失敗例が増えているのもまた事実だと思う。

- **「簡単にできるって言ってたのに、全然使えないよ...」**
- **「なにが数時間でできる、だよ。1週間やってるけど、まともに動くものが作れないぞ」**
- **「頑張って作って社内に展開したけど、フィードバックというより、文句やこれできないの？あれできないの？って追加要望ばっかり...こんなことなら展開しなければよかった...」**

こんなことを感じていませんか？
あるいはこんな声が聞こえてきませんか？

なぜ自社では成功しないのか？
なんで、事例で見たようにできないのか？

そんなことを感じている人も少なくないのではないかと思います。
世の中に出てくる事例というのは**成功例**です。失敗例はまず出てきません。失敗例は事例にならないのです。本当は**「失敗は成功のもと」**なのに...

本記事では、**そんな方に技術的な要素ではなく、いま一度立ち止まって、考えてみて欲しいこと**をお伝えします。私が思うに、**失敗の原因は担当者のスキル不足や習熟不足だけではない**と思うからです。それ以前の考え方を一度見直してみてはどうでしょうか？という一つの提案です。

# アプリケーションの3要素
まずは私が考える、**ノーコード / ローコード** ツールでアプリケーションを開発する際に考えるべき**3つの要素**をお伝えします。ちなみに ノーコード / ローコード といちいち書くのは面倒なので、ここからはローコードで統一します。厳密には ノーコード と ローコード は分類可能ですが、本記事にはあまり関係がないので、一律、コーディングが極めて少なく済む**「ローコード」**と表記することにします。

## 3つの要素

- アプリの目的
- データ定義
- ユーザーの定義

私が考えるアプリケーションの3要素とは上記の3つです。
これらについて順に説明していきます。

# アプリの目的
アプリの目的を考えるには、**「アプリ」とは何ぞや？**ってところから考える必要があります。

## アプリって何？ - What is "App" ?
3つの要素を説明する前に、考えて欲しいことがあります。

**質問：「アプリって何の略ですか？」**

この質問、過去にセッションやセミナーで何回も聞いてみたのですが、これまで**誰ひとり正解を答えた人はいませんでした**。プロの開発者や IT の専門家でも答えられませんでした。

**ちなみに「アプリケーション」だと思われた方、間違いです。**

プロでも間違えてしまう理由は**「アプリ」**という言葉がもはや老若男女、誰でも知っている言葉になっていて、当たり前になっているからだと思います。つまり**「民主化」**しているから、ということですね。民主化していること自体はとてもいいことです。かつて、1990年代 ～ 2000年代 においては、アプリケーションというのは専門家が作るもので、使う人も専門家だったということができます。ゆえに普通の人にとっては**「なにそれ？おいしいの？」**状態でした。もちろん知らないところで、実は使っていたわけです。駅の券売機、銀行の ATM、ECサイトなど、日常生活に IT が溶け込み始めた時代ですから、気付かないうちに使っていたことはれっきとした事実です。それを民主化させた大きなきっかけのひとつは、私の記憶が確かならば、**docomo** の **iアプリ** です。iアプリとは、iモード対応携帯電話上で動作するソフトウェア（プログラム）でした。嘘か本当かはわかりませんが、よく聞く有名な話に、かのスティーブ・ジョブズは iアプリ を参考にして、iPhone のアプリを考えたとか。そう、世界で初めて、携帯電話上で電話とは関係ないアプリケーションを動作させ、民生品としてリリースしたのは日本なのです。

さて、質問の回答に戻りましょう。**アプリとは何の略か？**
わざわざ質問をしているということは「アプリケーション」でないことは容易に想像できるかと思います。そう、「アプリケーション」では、足りないのです。英語で **application** とは名詞で**「申し込み」**や**「適用」**などの意味があります。その動詞形は **apply** で、**「適用する」**という意味になります。どこにも私たちがイメージするコンピュータ上で動作するアプリ的な意味を持っていないのです。

私たちが現在**「アプリ」**と言っているモノは、元は**「アプリケーション ソフトウェア」**や**「アプリケーション プログラム」**と呼んでいました。これが正解です。それが縮まって、後ろのソフトウェア（プログラム）がなくなり、**アプリケーション**となるのですが、それでもまだ長い！ということで、さらに短くなって、**アプリ(App)** となったのです。言葉はこうしてどんどん進化していきます。余談ですが、これはテレビで流れる **CM** という言葉にとてもよく似ていますね。**CM** とは **コマーシャル** の略だと思っている人が多いですが、実際は**「コマーシャル メッセージ」(Commercial Message)**の略です。

## アプリケーション・ソフトウェアって何よ？
アプリケーション・ソフトウェアとは直訳すれば、**「適用されたソフトウェア」**ということになります。
そう聞くと、**「え？何に適用されたの？？」**って思いますよね。
そう、ですから正確には**「特定用途に向けて適用されたソフトウェア」**ということになります。

つまりアプリには、**必ず何らかひとつの目的（特定用途）**があるということです。
ということは、ですよ。ということは、アプリを開発するには**「特定用途」**を考えなければなりません。**ひとつの目的です。2つじゃないです。ひとつです。**

## ローコードツールで作るアプリの目的はひとつに限定する 
ローコードツールでアプリを作り始めると、マウスによるドラッグ＆ドロップによって、思っていた以上に簡単にアプリが作れることがわかります。そうすると、**人はあれもしたい、これもしたい、とひとつのアプリでいろんなことをしようと試みます。**仮に、思い付いた機能を全部入れることができたとしても、ふと我に返ったとき、次の自問に答えられないことになります。

**「このアプリって何をするアプリだったっけ...？」**

この状態に陥っているかどうかを知るためのバロメーターがあります。

**「アプリに名前を付けてください」**

と言ってみてください。

もし、すんなり名前が付けられたら、おそらく特定用途に向けられていることでしょう。でも、**もし名付けに迷うようなことがあれば、複数の目的を詰め込んでしまっている**可能性がとても高いわけです。ローコードツールで作成するのは業務アプリでしょうから、出来上がったら組織内に共有するはずです。その際に、アプリの名称はとても大事なものになります。**共有された人がその名称を見て、何のためのアプリか、即座に理解できる**必要があります。名称に説明が必要になるなんてのは愚の骨頂です。

**経費アプリ、出退勤アプリ、稟議アプリ、タスク管理アプリ...**

こんな**単純な名前が好ましい**ですよね。こうやって作っていくと、アプリが増えて収拾がつかなくなっちゃうと思われたそこのあなた。そういう状況になったら、次のフェーズに進んでいるということです。そうなったら、**グルーピング**を考えてみましょう。あるいは**入り口を整理**するのもいいですね。

グルーピングとは、関連する業務のアプリを**ワークスペース**や**フォルダ**などに分類しておくことです。各ローコードツールにはそういった**グルーピングの機能**が必ず用意されています。サービスごとに名称は異なるかもしれませんが、必ずグルーピングができる機能が存在しますので、うまく考えて使ってみてください。

入り口を整理するというのは、複数のアプリを呼ぶことができる**ランチャーアプリ**を別途作ることを意味します。考え方はグルーピングと同様です。いかにユーザーが簡単に該当のアプリに辿り着くことができるか。これを考えましょう。

# データ定義
**データ定義**とは、私が個人的に得意としていることです。
**アプリを作るのに、データ定義が必要なんですか？**と思われた方もいるでしょう。はい、**絶対に必要**です。ここでいうデータ定義とは、2つに分けられます。

既にデータが存在している場合は、**その定義を読み解くこと**です。つまり、**列数、列の名称、データ型**をアプリに教えてあげる必要があります。
データが存在していない場合は、**データ定義を作ることから始めなくてはいけません。**場合によっては、アプリを作成しながら、データを定義していくことになるでしょう。

**Power Apps** にしろ、**kintone** にしろ、**AppSheet** にしろ、アプリを作ろうとすると、最初にデータを決めることからスタートしますよね。**kintone** だけは、ちょっと違くない？って思うかもしれませんが、**Excel** や **CSV** からアプリを作る際は使用するデータを定義することからスタートします。じゃあ、画面をいきなり作る場合は当てはまらないのかというと、そうではなくて、画面項目を定義すると、裏側でデータの入れ物が定義されていきます。データベースでいうところのテーブルの列を画面項目と同時に定義しているイメージです。

**Power Apps** は既存のデータソースをひとつ選んで、その接続を作成して、**CRUD (Create:作成, Read:読み込み, Update:更新, Delete:削除)** ができるアプリを作ることができます。データソースはひとつに限定されておらず、ひとつのアプリで複数のデーターソースに接続することが可能です（=**マルチデータソース**）。データソースを選ばなくても、アプリを作り始めることができます。画面の項目が必ずしもデータと紐づいていなくてもいいというのが、特徴かもしれません。ですが、業務アプリを作る場合は、画面項目がひとつもデータと紐づいていないなんてことはないでしょうから、やはり、**データの入れ物が必須**ということになります。

**AppSheet** も最初にデータを用意して、接続して、画面を作っていくことで、アプリを構築していきます。

それぞれのサービスで違いはありますが、共通しているのは、**アプリを作成するのにデータが付き物**だということです。**データが存在しないアプリはない**わけです。ただ、アプリを作りたいと思っている人が最初からデータを意識しているかというと、必ずしもそうではないでしょう。私が思うに、これは **Excel** が悪く影響しているのだと思います。

なぜかローコードでアプリを開発するサービスなのに、**Excel** の代替として宣伝しているものがよく見られます。**Excel** は単なる表計算ソフトですが、高機能な故に、画面フォームも作ることができてしまい、あたかも一つの業務アプリケーションとして、利用することができてしまいます。その場合でも考え方は全く一緒で、入力用の画面があって、入力された値がテーブルに書かれることになるわけです。ただ、**Excel** はもともとが表計算ソフトですから、データが**ワークシート**に存在していて、**直に編集できてしまう**という特徴があります。その手軽さは素晴らしいものですが、これがアプリケーションとなると、そうは言えないわけです。**データは高度に隠蔽されて、一度登録されたデータを直に編集することはできません。編集するための画面が必要になります。**

本来は **Excel** であっても、**データ入力用の画面フォームを作成したのであれば、データを直に編集してはいけません。**それをすると、想定外のデータを作成できてしまうからです。**アプリケーションとは、極論、整合性を維持してデータをいじるためのソフトウェア**です。ローコードではなく、プロの開発者によるコーディングでアプリ開発する場合は、画面とデータベースがありますが、すべての人がデータベースに問い合わせるための **SQL** を理解できるのであれば、直接 **SQL** を書いて、データを作成してもいいわけです。ですが、人はミスをします。なので、アプリケーションによって、制限され、整合性が維持されたデータを登録するようにしているわけです。

アプリケーションにとって、データとはそれくらい**大事なもの**です。**アプリを開発する際は、データを定義することから始めるんだ**と認識しておくことが重要です。昨今では、**データの二次利用**も進んでいます。とあるアプリで作成されたデータを別のアプリから利用するといった**データ連携**は、皆さんも既にやられているかもしれません。元のデータはそのアプリが正常に動作をするように定義しなれければなりませんが、業務上、**様々なクラウドサービスを組み合わせる必要がある場合には、二次利用まで考慮に入れたデータを定義する必要があります。**

こういってしまうと、**「気軽にアプリが作れないじゃん...」**と思われるかもしれません。大丈夫です。とりあえず、必要なアプリを作って、**「あ、このデータじゃ、二次利用できないじゃん」**と気付いた時に、考えればよいのです。まずはやってみて、それから考える。**きちんとしたデータ定義は必要ですが、最初からできるものはありません。**逆に言うと、**失敗を重ねることで、どういうデータ定義にしておく必要があるのか、**わかってくるものです。

# ユーザーの定義
そして、最後に考えなければならないのが、**ユーザー**です。**このアプリは、誰が、いつ、どんな状況で、何のために使用するのか？**
これを定義する必要があります。これを定義することで、**UI (ユーザーインタフェース)** が決まります。つまり画面の項目ですね。何かをひとつ選択する場合、**ドロップダウンリスト**がいいのか、**ラジオボタン**がいいのか、**単純なボタン**がいいのか。これは、**ユーザーがどんなデバイスで操作をするか**によって、最適解が変わります。文字の大きさや画面の大きさもそうですね。

**外出中の営業マンがスマホで操作する**のであれば、タップ操作でスマホに特化したアクションが求められます。
**内勤のインサイドセールスやマーケターが終日ずーっとPCで使う**アプリなら、画面は広く使いたいものです。
**役員などの役職者のみが使用する**アプリであれば、できるだけシンプルな操作で、文字は大きく表示したいですよね。アクションを通知してあげることも必要かもしれません。

- 誰が
- いつ
- どんな状況で
- 何のために

使うアプリなのか？

当たり前のことですが、**この当たり前に決めなければいけないことをやらないと、どんなにアプリの出来がよくても、組織において、結果として失敗してしまう可能性があります。**

# 最後に
文字だけの記事を最後まで読んでいただき、ありがとうございます。
私は **BI** の専門家です。なぜ、今回 **アプリ** をテーマに扱ったのかというと、とてもシンプルな理由からです。

アプリケーションが作る結果としてのデータを **BI** は利用します。データがきちんとしていなければ、**BI** を担当する者としてはとても困るのです。今回お話したことは、**実は BI でも全く同じ**です。**BI** ではレポートやダッシュボードといいますが、上記の文章の**「アプリ」**や**「アプリケーション」**を**「レポート」**や**「ダッシュボード」**に置き換えても、意味が通じます。

昨今では **BI** は単なるグラフや表を見るためのモノではなく、**ユーザーが操作をして、インタラクティブにデータが変わるモノ**です。**数百万件のデータがあっても、ユーザーが見たい切り口で即座にデータが表示されるのが BI です。そのユーザー体験 (UX) はアプリケーションと何ら変わりません。**

そういった想いから、本記事を執筆しました。

皆さんからのご意見ご感想をお待ちしております。もしよかったら、皆さんが所属する組織内や SNS 等で共有していただけると、幸いです。
ありがとうございました😊👍