はじめまして。株式会社PRUMでエンジニアをしている人見です。
日々、プログラミング学習や実務の中で、つまずきやすいポイントや、
仕事で起きやすい“ズレ”について整理して発信しています。
誰かの助けになれば幸いです。
9割のエンジニア未経験者がつまずく『最初の壁』 それでもアプリを作りたい -ボタンの裏側で起きていること-
はじめに
前回は、Google Apps Script（GAS）を使って出欠確認アプリを作りました。
名前を入力する → 「参加」・「不参加」を押す → 結果が保存される → 一覧が表示される
ここで少し考えてみてください。私たちは、入力してボタンを押したら、
結果が保存されたように見えます。でも実は、アプリとのやり取りは
ボタンを押す前から始まっています。
今回は、前回作ったアプリを題材に、
アプリの裏側では何が起きているのか
を少しだけのぞいてみましょう。コードをたくさん書く回ではありません。
「ボタンを押したら保存される」の裏側で、画面とアプリがどんなやり取りを
しているのかを見ていきます。
実は、URLを開いた瞬間から会話している
前回作ったアプリって、最初に何をしましたか？
参加ボタンを押した？
実は違います。その前に、アプリのURLを開いています。
当たり前すぎて意識しませんが、ここで最初のやり取りが発生しています。
利用者は、アプリに対して、
画面を表示してください
とお願いしています。するとGASは、
はい、どうぞ
と画面を返しています。
イメージとしてはこんな感じです。
私たちは何気なくURLを開いていますが、実はこの時点で、
アプリとの会話が始まっているんです。
Webアプリは「お願い」と「お返事」でできている
Webの世界では、この「お願い」と「お返事」に名前があります。
お願い → Request（リクエスト）
お返事 → Response（レスポンス）
なんだか難しそうな言葉ですが、やっていることは会話です。
例えばレストランなら、
ハンバーグください
↓
承知しました
↓
お待たせしました
ですよね。アプリも同じです。
URLを開いたときは、
画面をください
↓
画面を返します
という会話をしています。そして、ボタンを押したときは、
また別のお願いをしています。
参加ボタンを押したときも会話している
前回の出欠確認アプリでは、参加ボタンを押した瞬間にも、
もう一度会話が発生しています。今度のお願いは、
画面を表示してほしいというお願いではありません。
「ひとみん」さんが「参加します」をクリックしました。
この内容で保存してください。
というお願いです。それに対してGASは、
保存しました。
一覧を更新します。
とお返事します。
でも実際に裏側では以下の図のような動きをしています。
これが、Webアプリの基本的な動きです。
ボタンが保存しているわけではない
ここで少し視点を変えてみます。保存しているのは、参加ボタンでしょうか。
もちろん違います。ボタンは、あくまできっかけです。
ボタンがやっているのは、
この内容で保存してください
とお願いすることです。実際に保存しているのは、GAS側のプログラムです。
画面
↓
Request
↓
GAS
↓
保存処理
↓
Response
↓
画面
つまり、
ボタンを押したから保存された
というより、
ボタンを押したことで、GASに保存のお願いが送られた
という方が近いです。
ここが分かると、アプリの見え方が少し変わります。
画面は利用者が操作する場所。GASは裏側で処理する場所。
スプレッドシートはデータを保存する場所。それぞれに役割があります。
リクエストには、データが入っている
では、参加ボタンを押したとき、GASには何が送られているのでしょうか。
例えば、画面で次のように入力したとします。
名前：ひとみん
回答：参加
この状態で参加ボタンを押すと、GASにはざっくり言うと、
こんな内容が届きます。
名前は「ひとみん」です。
回答は「参加」です。
この内容を保存してください。
つまりリクエストは、ただの合図ではありません。
必要なデータを持って、裏側の処理へ渡しに行っています。
そのデータを受け取ったGASが、スプレッドシートに書き込みます。
だから、あとから一覧で確認できるようになります。
今回はスプレッドシートに保存している
前回の出欠確認アプリでは、保存先としてスプレッドシートを使いました。
ブラウザ
↓
GAS
↓
スプレッドシート
利用者が画面から入力する。GASがその内容を受け取る。
スプレッドシートに保存する。保存した結果を画面に返す。
流れだけを見ると、とてもシンプルです。でも実は、
かなりWebアプリらしい動きをしています。
本格的なWebアプリでは、データベースに保存する
一般的なWebアプリでは、保存先にスプレッドシートではなく、
データベースを使うことが多いです。
例えば、
- LINEのメッセージ
- Amazonの注文履歴
- Instagramの投稿
こういった情報は、データベースへ保存されています。
イメージとしては、こんな構成です。
並べてみると、役割はかなり似ています。
| 役割 | 本格的なWebアプリ | 今回のGASアプリ |
|---|---|---|
| 画面を表示する | ブラウザ | ブラウザ |
| 処理する | アプリ側のプログラム | GAS |
| 保存する | データベース | スプレッドシート |
もちろん、本格的なWebアプリはもっと複雑です。セキュリティ、
権限、データ設計、サーバー構成など、考えることはたくさんあります。
ただ、最初に理解したい大きな流れは同じです。
入力する
↓
リクエストを送る
↓
裏側で処理する
↓
保存する
↓
レスポンスを返す
↓
画面に表示する
今回のアプリは、本来データベースが担当する保存先を、
スプレッドシートで代用しています。だから環境構築をしなくても、
Webアプリの基本的な流れを体験できます。
じゃあ、スプレッドシートを直接編集すればよくない？
ここで、こう思う人もいるかもしれません。
だったら、最初からスプレッドシートをみんなで編集すればよくない？
確かに、それで足りる場面もあります。でも実際に運用してみると、
意外と小さな困りごとが出てきます。
- どこに入力すればいいか分からない
- 入力形式が人によってバラバラになる
- 間違えて他の人の行を消してしまう
- スマホだと操作しづらい
- 欲しい情報がぱっと見つからない
スプレッドシートは便利です。でも、利用者全員に直接編集してもらうには、
少し扱いづらい場面もあります。
そこで、入力する人には必要な画面だけを見せます。
名前を入力する
[参加]
[不参加]
利用者はこれだけ見ればいい。裏側では、GASがスプレッドシートに
整理して保存してくれる。管理する人は、一覧で確認できる。
これだけでも、かなり便利になります。
小さくても、ちゃんとアプリになっている
今回作った出欠確認アプリは、大きなサービスではありません。
でも、次のような流れがあります。
URLを開く
↓
画面が表示される
↓
入力する
↓
ボタンを押す
↓
裏側で処理する
↓
保存する
↓
結果を返す
これは、Webアプリの基本的な考え方です。
もちろん、しっかりしたサービスを作るなら、もっと丁寧な設計が必要です。
でも最初から全部を理解しようとすると、なかなか手が動きません。
まずは、
画面と裏側が会話している
入力したデータが裏側に渡る
裏側の処理が保存している
この感覚を持てるだけでも、アプリ開発はかなり身近になります。
おわりに
最初は、
ボタンを押したら保存される
と思っていました。でも実際には、その前から会話は始まっています。
URLを開く。画面を表示する。ボタンを押す。データを送る。
GASが処理する。スプレッドシートへ保存する。結果を返す。
普段は見えないだけで、アプリの裏側では、
こうしたやり取りが繰り返されています。
今回の出欠確認アプリは、とても小さなアプリです。
でも、誰かの入力を受け取り、裏側で処理し、保存して、
結果を返しています。
それだけでも、立派に「誰かの作業を楽にする仕組み」になっています。
いきなり大きなアプリを作る必要はありません。
まずは、身近な人のちょっとした困りごとを、
少しだけ楽にするところからで十分です。無料で、環境構築も少なく、
ここまで体験できるのはGASの良いところだと思います。
次回は、この出欠確認アプリをもう少し実用的にするために、
「使えるアプリ」に近づけるには何が必要かを考えていきます。
PRUMのエンジニアの95%以上は未経験からの採用です。
もし弊社にご興味あれば覗いてみてくださいね。