はじめに
ノーコード / ローコード でアプリケーションが開発できるツールは、国内外問わず、いっぱい出ていて、実運用も一巡してるように観測できてる。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 等で共有していただけると、幸いです。
ありがとうございました😊👍