00:06
9月26日、火曜日ですね。
時刻は朝9時35分になりました。
昨日の配信なんですけど、
ツイッター書でできてたんですけど、
録音、収録の方ですね。
僕はクイックタイムプレイヤーで収録をしてるんですけど、
昨日は収録ボタンを押し忘れて、
昨日の配信のアーカイブが残ってなかったっていう、
僕はやらかして、
うわーってなっている今朝です。
はい、おはようございます。
himehimeのkeethことくわはらです。
まあでは、本日もはたかた始めていきたいと思います。
今日のタイトルは、
昨日話しましたかね、最後の方に。
ちょっとFirebaseをほげほげみたいな話をしてたと思いますけど、
Firebaseで結構使っている方っていうのが今周りに多くて、
特に僕が採用イベントとかに、
新卒採用のイベントに参加することが多くて、
Firebaseって無償で使えるんですよね。
もちろんユーザー数とかトラック数とか増えれば、
重量課金的にお金が増えるんですけど、
基本的には無料で、ある程度のことは使えますし、
ちょっとだけ課金すればほぼほぼフルで使えるみたいなところがあって、
使い勝手は本当にいいですし、入門的にも優しいというか、
触りやすいサービスではあると。
特に学生さんがやっぱりですね、
クラウドサービスってAWSとかGCPとかっていうのを
がっつり使うほどのリソースとお金がないと。
そこまでがっつりと学ぶほどの時間もなかったり、
結構難しかったりするんですよね。
取っかかりは結構難しかったりするものなので、
そういう意味でいくとFirebaseはすごく使いやすいんですよね。
ほんとに簡単に触れますし、
ストレージ機能もありますし、
いわゆるデータベース的なやつですね。
ノーSQLですけど、ファイヤーストアとか、
リアルタイムデータベースとかあったりはしますし、
アナリティクス機能もあったりとかですね。
一番嬉しいのはあれですよね、認証周りのところも
Firebase OAuthっていう機能があったりとか、
メッセージング機能もありますよね。
プッシュ通知を実装したくても、
Firebaseからの通知を送るみたいな設定もできたりなので、
だいたいWebでやりたいこととか、
Webというかフロントエンドですね。
Webフロントエンドもそうですし、
アプリのほうですね、ネイティブアプリのほうでも、
側のほうでやりたいなっていうことは、
だいたいFirebase使えばできるというところですね。
リレーショナーじゃないデータベースなので、
スケールするには結構大変かもしれないですけど、
簡単なものとか、スタート的な小さいアプリケーションであれば、
全然Firebaseのこと足りるんですよね。
というのもあって、
Firebaseを使っている学生さんはほんと多いなと思いますし、
ハッカソン参加すると結構な割合で、
学生さんをFirebaseに頼っているなっていうイメージはあります。
とはいえ、でも最近はちゃんとマイスケールとか
POSグレーを触っている学生さんも結構増えてきてて、
ドッカー環境で環境開発とか構築とか
さらっとやってますねみたいな人も全然たくさんいらっしゃると思います。
ドッカーハーブにイメージがとりあえず上がってますので、
とりあえず引っ張ってきて、実行すれば
少なくとも環境をすぐ作れますのでね。
この辺ほんと便利になったなってつくづく感じますね。
で、学生さんが使ってますけど、
でも最近の学生さんでも、
リレーショナルデータベースで触っている方も結構増えたって感じですね。
前回の昨日のイベント、ギーク10イベントでも、
03:01
誰かオーロラ触ってた気がしますね。
そこまで行くっていうところですね。
オーロラ触るのはいいんですけど、
お金大丈夫ってちょっと心配はありつつも、
というところもあったりするので。
学生に至ってはコンテナ管理するんだったら、
その後デプロイとかもコマンド一発で一元管理したいよねっていうので、
Kubernetes使っている学生さんもいたりとか。
CICDはやっぱりまだまだGitHub Actionsが一強と言っていいほど、
みんなCICDはGitHub Actions使ってるっていう印象はありましたけど、
それはウェブを作ってるからであって、
アプリケーションとか全然別のものだったら、
Nativeだったりすると、名前忘れました。
iOS、Android、それ用のビルドツールとかあったりするので、
その辺を使うとは思いますけども。
学生でももうKubernetesでコンテナ一元管理してるみたいなところは、
結構びっくりしましたね。
もうそこまで進んだんだっていうところがあって。
知識自体は全然インターネットに転がっているのでいいんですけど、
とはいえ、そこまでいかない学生さんとかは別に分かってはいるし、
理解はできているけど、
今回作るアプリケーションとして別に使う必要はなかったっていうので、
Firebase使ってるみたいな学生さんも結構いらっしゃったっていう感じですね。
とにかく入門として、
なんかやっぱりバックエンドとかクラウド、
データベースだったり、認証周りだったりっていう、
いわゆる非機能要件に近いところと連携するような機能だったり、
アプリケーションを作りたい、でもリソースなかったり、
サクッとやれるようなものがしたいと。
であればやっぱりFirebaseっていうのは選択肢に出てくるのは当然だと思っているんですけど、
以前も話したかちょっと覚えてないですけど、
弊社のカジュアルメンダーにお越しいただいた中途採用の方ですね、
フリーランスで今お仕事されている方が一人だけいらっしゃったんですけど、
その方は、いわゆるプロトタイプとか、
要件定義フェーズから既にサクッと目的にFirebaseを使って、
簡単に画面でそれっぽい感じで動くプロトタイプっていうのをバンバンに作って、
要件定義してその本開発に進むみたいなプロジェクトの進め方をしているフリーランスの方がいらっしゃったんですけど、
その方のプロトタイプのスピード感がめちゃくちゃ速かったんですよね。
それを裏付けているというか支えているのがやっぱりFirebaseだったんですね。
いくらプロトタイプとはいえやっぱりデータが欲しいわけなんですよね。
そのデータとかもプロタイプなのである程度のデータの共通化とか共有はできるような設計にはしているらしくて、
そのアプリケーションによって全然プロトタイプを作るものは変わるんですけど、
とはいえ所詮プロトタイプなのでデザインも凝っていたわけでないし、
機能がたくさんあるわけでもないし、要件定義スタートぐらいのところなのでまだふわっとしている。
というのがあるといわゆるボイラーアップデート的にいくつか作っておいて、
データもそこでFirebaseのデータを共有して動くようにしておけば、
要件定義の時にすでに紙とかホワイトボードで書いたり付箋で書いたりとかじゃなくて、
もう手で動かしながらこれってこうですよねとかいうのを目で見ながら要件が詰められるっていうのはとても体験が良いっていうので、
その人はフリーランスですけどめちゃめちゃ売上が高いらしくて、
かつすごい爆速に開発進められるというか、要件定義をクオリティー高くかつ超高速に進められるっていうところが、
ものすごい評価をされているっていうことらしくてですね、びっくりしました。
こんなすごい人いるんやと思ったけど、
そのFirebaseは上手いこと活用しているっていうその活用事例の一つとしてとても参考になりましたし、
06:03
このスピード感を出せるんだったら企業も同じことできるよなと思っていて、
きっちり要件を話し詰めるのはすごく大事ではあるんですけど、
ものを進むためには見えるものがあって進めるほうがやっぱり楽というか早いんですよね。
いくらテキストとかホワイトブルーとか付箋とかで書いたりああとこうだっていうのも、
全然それもワークショップ的な体験はすごく良いですし、
同じ情報共有と認識の底がないようにっていうところがすごくいいんですけど、
百聞は一見しかんで、ベラベラ書いたりペタペタ貼ったものよりも、
軽く動いてくれるモックアップだったりプロトタイプがあるほうが理解は早いし、
次の話がボンボンイメージしやすいんですよね。
人間はテキストより画像とか絵のほうが理解は早くかつ発想が浮かぶんですよね。
ということを考えると、その方はいかにプロトタイプを早く作ってお客さんに見せて、
物事の話を進めるかってところに注力をしてFirebaseを活用されていたってところなんですよね。
これは本当だからびっくりしましたけど、
そういう使い方をするっていう意識を持ってFirebaseを導入するのは結構ありかなと。
僕としては反省しましたね。
私は一応フロントエンドの仕事、今はほぼほぼしないですけど、一覧系かかってますけど、
要件提言のときにFirebaseそことこだけ入れて、ほぼほぼ無料のまま要件提言終わって、
本開発はちゃんとRDS使うとかっていうアーキテクトは考えるんですけど、
進める段階だけでもFirebaseを入れるっていうのは全然ありだなと。
すごく反省をしましたね。
アーキテクチャーとか技術選定をするっていうのは、
そのプロタクトが今後長く続くためにやると思いますし、
今回のプロジェクトをいかに早く、かつクオリティ高く作り上げる、
実現するためにこの技術を使いましょうっていう選定を僕らはしていくんですけど、
本当のユーザーのためを考えると、早くリリースすることのほうが最優先じゃないので、
その後にユーザーからのフィードバックだったり、
A、Bテストをしてブラッシュアップをしていって、
どんどん改良していくっていうことを考えると、
本当にビジネスで求められるのは、
クオリティの高さもそうですけど、
バランスを取ったスピードも欲しいよねっていうのがあるわけですよ。
そのスピードの根幹って要件定義のスピードと、
そこの質だとは思うんですよ。
要件定義が詰め切れてなかったりとか、
そこの議論が浅かったりすると、
後でどうだこうだっていう確認だったり、
変更だったりっていうのがどんどん増えるんですよね。
アジャイル的にはそれを含めた上で進めるっていうのが結構アジャイルだったりしますけど、
それはそれで一つありですけど、
後ほど発生するコミュニケーションの数を増やさない方が早いよねっていうことが、
その方がおっしゃっていて、
まさにその通りだと僕は思ってて、
プロジェクトとか開発のところで一番時間食うのは人の時間なんですよね。
特にコミュニケーションの時間と認識速度の時間がとにかく食うと。
開発もやっていけば詰まったりとか、
設計困ったりとか、実装でほぎほぎみたいな話は全然出るんですけど、
それ以上に人と話す時間とかの方がよっぽど時間食われるんですよね、
プロジェクト全体として。
なのでそこをなくすようにやっぱりスタートのところの要件詰めっていうところのクオリティーを上げるっていう意味で、
プロトタイプがそこにあるだけでそれが飛躍的に上げられるっていうのが、
09:02
その方のおっしゃっているのがすごく参考になったっていうのはそういう話ですね。
はい。
なのでもし皆さんの現場でも、
やっぱ最初プロジェクト開発スタートのところで話するときに、
いわゆるホワイトボードだったり、
今最近Miro使うんですかね。
あとはFigma使ったりとかで、
多少は可視化はするんですけど、
本当に手でポチポチ触っていけるっていうプロトタイプがある無しっていうのは結構差が出るんだろうなっていう感覚は、
僕としてもやっぱりありますし、
自分が発注する側になったときに、
じゃあいざ要件定義で、
僕らが作ったアプリケーションはこうだよねって説明するときに、
こんな感じですかってプロトタイプ出てくるとやっぱり感触違いますよね。
その本気度とかスピード感出てくるんだっていうので、
この人にもっともっと頼りたいというか、
この人信頼できるなっていうような感触がすごくあると思うんで、
そういう意味でのファイアベースの使い方っていうのは一つ全然ありかなと思いました。
全然本プロジェクトで使うという設計はしなくていいと思います。
ただ使う用途とかタイミングは、
選べばいくらでもファイアベースのポテンシャルを持っているなっていうのがすごく感じたっていうのが、
ここ最近ずっと思っているところで、
改めてファイアベースを使いこなせるレベルで、
僕はしっかり理解し直したいかなと思ったりはしましたがね。
それは僕の感覚ですし皆さんの感覚はちょっとわからないですけど、
そういうことをちょっと思ったっていうお話です。
参考になれば幸いです。
皆さんの方でも逆にこういう使い方してますよとか、
こういうフェーズでファイアベースを投入して業務改善だったり、
プロジェクトに活用してますみたいな事例があったら、
すごくそれは聞いてみたいと思いますので。
なので、特にまとまりはないですけど今日はそういう話でした。
というので終わっていきたいと思います。
それでは終了します。お疲れ様でした。
