「Webサービス」の記事 - Crieit

SmartHRと連携して人事データを可視化するツールを作ってみた

2023-04-11T23:29:51+09:00

個人開発でSmartHRと連携したレポーティングツールを作成してみました。

人事データ簡易分析ツール

概要

このツールはSmartHRと連携してAPI経由でデータを取得して可視化を行うためのレポーティングツールです。

SmartHRではフリープラン、労務管理プランでは分析レポートの利用が有料プランに切り替えるなどの対応を行わないと利用できません。

オプション機能として提供されていますが、そこまで細かく分析するほどでは無く現状の人事情報を可視化したい、みたいな緩い使い方でも許容できるユーザーさんを対象に簡易的なグラフ出力を提供します。

利用にはテナントIDとアクセストークンを利用しますが、サイト内にも記載がある通りこのツールはテナントIDやアクセストークンを保存したりはしません。データ取得時のみに利用します。

そのため画面をリロードしたりするともちろん情報は失われます。

再度表示したい場合は都度テナントID、アクセストークンはをもう一度入力していただく手間はありますが…

技術構成

React
rebass
styled-component
recharts
TypeScript
Vite
VItest
Axios
CloudFlare Pages

レポート出力結果

出力結果は以下のような感じでシンプルに出力しています。

もしご興味あれば是非使ってみてください。

次にテナントIDとアクセストークンについて簡単に説明します。

テナントIDについて

テナントIDはSmartHRのURLに含まれている以下の部分の文字列です。

[https://[テナントID].smarthr.jp/](https://[テナントID].smarthr.jp/)

アクセストークンについて

アクセストークンは管理画面より作成を行うため以下に手順を載せておきます。

SmartHRにログインした後、右上のユーザー名の部分をクリックするとメニューが表示されます。

その中の「共通設定」をクリックしてください。

次に左側メニューから「外部システム連携」をクリックします。

API連携より「アクセストークン」をクリックします。

「新規発行」をクリックします

「アクセストークン名」を入力します。利用する用途を名前にしておくと良いです。

例えば「分析レポート」とか…

必須項目の入力が埋まると「登録」ボタンがクリックできるようになるので登録するとアクセストークンが払い出されます。

これらのテナントIDとアクセストークンを利用して本ツールにて入力して「出力」ボタンをクリックしてもらうとレポートが出力されます。

まだまだ表示がおかしい部分があったり、追加したい機能等があるので引き続き開発を進めていきたいと思います！

採用計画や人事データを活用して分析を行いたい方は是非活用してみてください。

初のSaaSが12月で1周年なので振り返ってみた

2022-12-05T05:35:35+09:00

※これは個人開発 Advent Calendar 2022のカレンダー2/5日目の記事です。

個人開発でいろいろ作ってきたけど、
去年の12月にはじめてSaaSをリリースしました。

ちょうど1年経ったので、少し振り返ってみる。
12月はいろんな記事が出てくるので、少し触発されました(´ω｀)

GoogleスプレッドシートのJSON API化サービス

https://sssapi.app/

どんなサービス？

スプレッドシートのJSON APIをつくれるごくごくシンプルなサービス。

スプレッドシートのURLを登録すると、
中身をJSONで受け取れるAPIを作れます。

検索・絞り込み・ページングなどAPIでよくつかう機能や、
ネストオブジェクトへの変換などいくつか変換機能、
外部API呼び出しやGitHub Actionsとの連携機能などなども用意。

どうして作ったの？

β版リリース時の記事でもいろいろ書いたけど、
スプレッドシートをJSON化する方法はいくつか既存のサービスでは少し使いにくいな。。と思うことがあった。

既存のサービスでの課題

ちょっとしたJSON APIを作る方法はいくつかあるけど、
実際のサービスで利用しようとした場合、すこし気になることが。。

GAS
- レスポンスが遅い/同時実行数などの制限がある
- シートごとに準備が必要/どこで使ってるかわからなくなる
- リッチな検索の実装がめんどくさい
ヘッドレスCMS
- 個人・小規模・開発初期では手を出しにくい価格
- 機能がリッチだけど、初期ではなくていいものも多い
スプレッドシートDB関連サービス
- 必要な権限が多い
- プライベートなAPIは作れない

資金が潤沢であればヘッドレスCMSがよい選択だけど、
試作段階で、いきなり手を出すのはなかなか厳しいお値段。。

GASやスプレッドシートDB関連サービスは、
個人利用なサービスや学習用ではよいけど、
実サービスではなかなか厳しい制約。。

もう少しお手軽で実サービスでも利用できるものがほしいと思い、
このサービスを作りはじめることに。

スプレッドシートをDBにするときの懸念

多くの競合サービスは直接スプレッドシートに接続しているけど、
実際にスプレッドシートをDBにすることを考えたときに、
いくつか気になる点が。。

トランザクションがない -> データ壊れる可能性
編集中のリクエストも受け付ける -> 不正なJSONを返すの可能性
Sheets APIが必要 -> 実サービスだとつらい遅さ

作ったサービスが(万が一でも)大ヒットしたときに、
データが壊れたり、意図しないレスポンスになるのは、
かなりつらい。。

そのため、任意のタイミングのスプレッドシートでAPIを更新でき、
読み込み専用のAPIのみとする、いまの方針になりました。

1年やってみてどうだった？

予想以上に利用されてた!!
エンジニア以外の人の利用が多い!!
企業での利用が多い!!

自分と同じような個人開発者をイメージしていたので、
かなりびっくり。。うれしい悲鳴。。(*´ω｀*)
年プランの購入もあり、黒字で運営できてる。ありがたい。。(*´ω｀*)

CloudFlareの障害のときは気が気じゃなかった。。

マッチするユーザ

アンケートやインタビュー、利用データを見ていると、こんな感じに(*´ω｀*)

スプレッドシートを介したコラボレーション
- エンジニア以外がデータを操作しやすい
お知らせなどを極小のコンテンツをあとづけしたい
- 単純なものを素早く作れる
スキーマが決まってない開発初期
- データからスキーマが作成できる

特に、スプレッドシートは多くの人が見慣れているので、
データを作る人に管理画面の操作方法を説明しなくてもよく、
共有も共同編集も簡単にできるというのが強みのよう。

また、スキーマをあらかじめ用意しなくてよく、
列を追加すると自由に変更できるのでプロトも素早くできる。

マッチしないユーザ

逆にマッチしないユーザとしては、
スプレッドシートをDBとして使いたいエンジニア。

やはり、書き込みができない、すぐに反映されないのは、
かなりネックなため、刺さらない感じだった。。

とはいえ、DBとして使う懸念があるので、
妙案が出るまで少し難しいことを思っている。。

振り返り(というなの後悔＆反省)

うれしかったことも多かったけど、
「こうしとけばよかった。。」の日々(´・ω・｀)

ユーザとのコミュニケーション

機能の開発はずっとやってきたけど、
マーケティングは考えていなかった。。

リリースしたはいいものの、フィードバックを受けたり、
何かを個別に伝えたりというのが難しい状態に。。

以下のようなものが必要だと感じた。
さらにサイト上とメールなどのサイト外でやり取りできるとよい。

運営 -> 全体
- サイト内: お知らせ・更新履歴のページ
- サイト外: メーリングリスト
運営
- サイド内: フィードバックフォーム
- サイト外: お問い合わせフォーム/メール
運営 -> 個別
- サイト内: (現状なし。例:個別のお知らせ)
- サイト外: メール
運営個別
- サイト内: (現状なし。例:チャット)
- サイト外: メール

当たり前のことだけど、機能の開発が優先になってしまっていた。。
機能は最低限でもいいけど、
ユーザとやり取りできる部分はあらかじめ用意できていると良かった。。

統計データの収集

これもマーケティング関連。

リリースして終わりではなく、なにを改善すべきかを把握する必要があるが、
こんなに利用される想定ではなかったので、かなり後回しに。。

最低限でも仕込んでおけば、かなり改善を早く回せた気がする。

特に、Twitterでのコメントと、実際の利用データとはかなりの乖離があるので、
もっとはやく実データを見て判断できる基盤を用意しておけばよかった。。

個人利用の想定

想定ユーザが自分自身であったので、
複数人でがっつり利用されるのを想定しなかった。。

フタを開けてみると、企業での利用や、
エンジニア/非エンジニアとのコラボレーションが多い。

そういった場合、プロジェクトやワークスペースみたいな、
複数人で共同編集できる構成が必要。

そうしておくことで、メンバーを招待したりもできるので、
バイラル効果も期待できる。

特にSaaSの場合はマルチテナントな構成で組んでおけばよかった。。
(新機能として実装中...)

料金プラン設計

個人利用の想定も絡んでいるけど、
アカウント単位のシンプルな3プランだけにしていた。
(しかもかなり手を出しやすい価格...)

この設計の場合、なかなか収益を増やすのが難しい。。
ランニングコストがかかるリッチな機能も開発しにくい。

また、APIがたくさん作りたい人と行数をたくさん増やしたい人がいて、
ニーズにあうプランがないことも多い。

今回のサービスの場合は、ある程度、好きなプランにできるよう、
ユーザがカスタマイズできる構成で組んでおけばよかったと思う。

とはいえ、ユーザが無駄に費用をかけなくていいように、
無料で試せて、小さくはじめて、大きく伸ばせる、
みたいな仕組みにしておくと個人的にはとっつきやすい。

その他もろもろ

書きはじめるときりがないけど、ほかにもいろいろと。。

より積極的なインタビュー/事例収集
大きな更新よりも小さくても定期的な更新＆お知らせ
UIフレームワークは利用を控える/移行つらい
広告は少額だと微妙かも/ある程度の金額なら効果的
記事募集やクーポン配布は効果薄いかも

はやく小さくリリースするのも大事だけど、
こういったサービスの場合には、
マーケティング関連や共同利用の想定ももっと想定しておけばよかった。。

今後は？

まずは後悔している部分の対応と使い勝手を向上していく。

あとはNuxt3がリリースされたので、Buetfyを剥がしつつ、
すこしずつ移行している感じ。

シンプルさを保ちつつ、よりサクッと便利なサービスになるよう、
少しずつでも長く運営できるようがんばります(*´ω｀*)!!

ご興味がある方も無い方も一度はぜひぜひ〜(*´ω｀*)

GoogleスプレッドシートのJSON API化サービス
https://sssapi.app/

ブラウザだけで複数コピペ保存・共有が出来るWebサイト

2022-06-26T21:18:47+09:00

個人的に困っていた事を解消するサイトを作ったので紹介させて下さい。

コピのすけとは

ブラウザだけでパソコンやスマホ間で、複数コピペの保存・共有が出来るサイトです。
入力内容は保存及び共有時に暗号化されます。

コピのすけ

困っていた事

ちょっとしたコピペの繰り返しや、他の端末(パソコンからスマホ等)に送りたい時、
アプリや連携サービスを使うまでも無いのになと、少し手間に感じていました。

このちょっとした手間を解消するために「コピのすけ」サイトを作成しました。

機能

複数テキスト枠でのコピー機能

テキスト枠が複数あり、それぞれの内容を「コピー」ボタンでクリップボードにコピー出来ます。

こだわりポイント

スマホを考慮し、ボタン配置や操作性などの対策を行っています。
テキストエリアがコピーする内容に応じて自動調整します。
セキュリティを考慮し、暗号化対策を行い、安全性を高めています。

同じ事でお困りな方がいましたら、ぜひご活用下さい。

コピのすけ

気分が落ち込んだ時に、自動で周囲の人に通知するアプリを作りました

2022-04-09T22:40:57+09:00

こんにちは！

「metnal」というアプリを作りましたので、ご紹介させてください。

metnalとは

metnelは、「気分が落ち込んだ時に、自動で家族や友人、パートナーなどに通知することで、周囲の人の助けを受けることをサポートする」アプリです。

特徴として、
1. 手軽に始められるように、LINEでのみログイン可能。メールアドレスやパスワードでアカウントを管理すると、アカウントを紛失したり、ログインが面倒になったりすることで、離脱してしまうリスクがあります（多くの人がアカウントを紛失した経験があると思います笑）。
2. 機能は非常にシンプル。その時の気分をつけるだけで、独自のスコアリングに基づき、自動で気分のスコアが表示されます。
3. 周囲の人に、気分のスコアを共有できます。また周囲の人が登録することで、スコアが極端に低くなった時（気分が落ち込んだ時）にLINEのbotを通じて自動で通知されます。

となっております。
このアプリが十分に機能した場合、周囲の人の落ち込みを即座に発見できることが期待されます。

利用方法

こちらをご覧ください！

利用技術等

qiitaにまとめてみました。
一読して頂ければ幸いです！

【個人開発】踏破した都道府県を日本地図でシェアできるWebサービス「日本踏破図🗾」を作りました

2021-12-27T23:20:34+09:00

はじめに

「日本踏破図🗾」というWebサービスをNuxt × Vuetifyで個人開発しました！

日本踏破図🗾

どんなWebサービスか

踏破した都道府県を日本地図でチェックすることができ、自分が今までに日本をどれだけ踏破したかをみんなにシェアできます👍
以下のように日本地図上で都道府県をチェックできます。これをシェアボタンでシェアすると・・・

以下のようなOGP画像でシェア可能です！地図のカラーも好きな色に変更することができます。

使用したフレームワーク・インフラなど

NuxtJS（Nuxt Bridge）
Vuetify
vuex（vuex-module-decorators）
PWA
Vercel（Serverless Functions）

主なものになります。多機能なWebサービスではないのでそんなに色々使ってはいません。
よく使うNuxtとVuetifyでフロントを構築して、NuxtのNitroエンジンを使ってVercelのServerless Functionsへデプロイしています。

当初はSSRにするつもりはなかったのですが、動的OGPを実装するために色々試行錯誤した結果SSRにしました。ただ、Nuxt3／Nuxt Bridgeから使えるようになったNitroエンジンのおかげで高速&ゼロコンフィグでVercelを利用できます。

苦労したところ

動的OGPをどう実装するか

正確に言うと「いかに簡単かつ無料で実装するか」に苦労しました。
検索するとfirebaseを使ってmetaだけSSRしたものを返してリダイレクトさせる等々、実現方法自体は色々でてきます。

ただ、正直なところこの規模・機能のWebサービスにそこまでしたくなかったんですね（できるだけシンプルな作りにするということも最初に決めていました）

最終的に実装した方法は以下です。

OGP画像を生成して画像を返すServerless Functionsを用意する
Functionsへ画像生成に必要な情報(チェック済みの都道府県、地図カラー)を渡す

必要な情報をURLパラメータに持ち、それを利用してmetaタグのog:imageのエンドポイントを作っています。
そのためサービス自体はSSRする必要がありますがVercelを使えば十分な無料枠でServerless FunctionsでSSRできます。

個人的には下手にhackyな方法をとるよりも、SSRが必要な場面ではおとなしくSSRしておいた方が良い気がします🤔
（結局のところTwitter・Facebookのクローラーのためだけにあれこれやりたくない）

ちなみにNetlifyにPrerenderingという機能があるのですが、これを有効にすることで事前レンダリングされたHTMLを返すことができます。
SPA構成にしてPrerenderingを試してみたのですが、どうもPrerenderingの対象はUserAgentを見ているだけらしくTwitterクローラーであればNetlify Functionsのエンドポイントも問答無用でPrerenderingされるみたいでした。
なのでOGP画像を返すはずのFunctionsがTwitterクローラーの時はPrerenderingされてHTMLを返すようになってしまい、OGP画像が表示されず使えませんでした。。

まぁ、NetlifyのPrerenderingはキャッシュ時間(24〜48時間)もコントロールできないし、なによりBETAなのでまだ実用的ではないですね。。

サイトデザイン

デザインというのはセンスだと思っています。つまるところ、それを磨くためには多大な時間・努力が必要ということです😉
私はデザイナーではないのでそこについて時間をかけて勉強するのは得策ではありません。
悩み・試行した結果、全体的にカードベースのデザインになりました。

また、根本のデザインはいわゆるUIフレームワークに頼るわけですが今回はよく使うVuetifyを利用しました。Vuetifyのコンポーネントを使うことで何も考えずそこそこきれいなサイトができあがります。

https://vuetifyjs.com/ja/

ただ、今回は個人的にやってみたいと思っていたGlassmorphism（グラスモーフィズム）チックなデザインを実装しました。
これが間違いで、Vuetifyはマテリアルデザインを実装するフレームワークなんですね。それに対してマテリアルデザインからかけ離れるようなものを実装すると色々と歪みが生じます🙃

importantを使ってVuetifyのcssを上書きして実装しましたが、こういうことをする場合はTailwind CSSを利用するべきでした。。

https://tailwindcss.com/

運営コストについて

現状、ドメイン代オンリーです。
上の方でも少し書いていますが個人開発においては無料で運営できることにこだわっています。

まぁ、お金はかからないに越したことはないし、お金がかかってくるとちゃんとメンテしなくちゃとか、マネタイズ考えないと！とか思ってしまうわけですが無料であればひとまず放置で問題ないですからね。

ちなみに、このWebサービスでは最初からマネタイズは一切考えていません。機能的にサービス自体がマネタイズにつながるものでもないですがアドセンス等の広告等も一切はらないと決めて開発をスタートしました。

サイトパフォーマンスについて

使っている技術からもわかるかと思いますが、パフォーマンスは問題なく良いです。
特にSSRするとやっぱり初期描画のパフォーマンスがすごいです（コールドスタート時以外）

いくら無料のインフラにこだわっているかといってパフォーマンスを犠牲にしたらお話にならないですからね😉

機能の説明

日本踏破図🗾でできることを改めて説明させていただきます。

日本地図で踏破した都道府県をチェック

日本地図上の都道府県を選択することができます。選択状況した数によって日本をどれくらい踏破したかがわかります。
また、シェアボタンから踏破した都道府県をシェアすることができます❗

日本地図のメニュー

地図メニューから、それぞれの機能を利用できます。

地図をリセットする（都道府県の選択状態・色をリセットする）
地図の色を変える（日本地図の色を変更できます）
日本を踏破する（すべての都道府県を選択状態にします）
コピー（日本地図をクリップボードへコピーします）
ダウンロード（日本地図をpng画像としてダウンロードします）

チェックボックス

日本地図上から都道府県を選択する以外に、チェックボックスでも選択することができます。チェックボックスで選択すれば連動して日本地図上の都道府県も選択状態になります。

ソースコード

日本踏破図🗾のソースコードはMITライセンスで公開しています👉

https://github.com/k-urtica/traverse-japan

さいごに

登録ログイン不要で使えるのでぜひ使ってみてください。
よろしくおねがいします！

🌐 サイト：https://traverse-japan.dev/
👀 開発：K
🚩 ソース：https://github.com/k-urtica/traverse-japan

おまけ

Web ToolBoxというブラウザで無料で使えるツール集を公開しています。
こちらもよろしくおねがいします。

https://web-toolbox.dev/

個人開発ふりかえり ver.2021年

2021-12-05T00:06:11+09:00

この記事は個人開発 Advent Calendar 2021の5日目の記事です。

今年ずっとつくってたサービスも無事正式リリースできたので、
個人開発について振り返ってみようかなと。

はじめたころからすると目的もだいぶ変わってきてるけど、
こんなに長く続けられる個人開発ってたのしい(*´ω｀*)

2021年につくったもの

振り返ってみると4つも作ってた(*´ω｀*)

4月: ウマ育ノートをリリース
ゲーム・ウマ娘のお助けアプリ
7月: CoCoガチャをリリース
カレーのトッピングをガチャで決めるネタアプリ
Crieitのweb1weekへの投稿作
10月: PRESS-DONEをリリース
プレスリリースの送付記録サービス
12月: SSSAPIを正式リリース
GoogleスプレッドシートのAPI化サービス

あと、積読ハウマッチもちょこちょこアップデート

ほぼ、SSSAPIをがんばっていた年。
ほかの3つのアプリもSSSAPIを使ってるので、ほぼ一色に。

SSSAPIについてはこちらの記事にまとめたので、もしよければ！
・スプレッドシートをWeb APIにできるサービスを作ってみた - Qiita

目的の変化

かれこれ8年くらい個人開発をしてるけど、
目的がだいぶ変わってきた気がする。

はじめはストレス発散

いま思うと、ストレス発散だったとかも。

だんだんコードを書く機会がなくなって、
コードを書けないストレスの発散する場所だったかもしれない。

なので、「コード書ける〜たのし〜」という感じで、
コードを書くこと自体が目的だった。

新しい技術を試す場所

新しい技術とかはフィードを見ているくらいだったけど、
いろんなライブラリや言語などを個人開発で試すように。

記事を読んだり、サンプル動かすだけだと身につかないけど、
実プロジェクトで試せるので、理解も深くなる。

「個人開発で試す」→「本業で導入する」
という、このサイクルがとてもよくて、
新しめ技術でも自信を持って提案できる気がする。

「個人開発＝新しいものを試したり、訓練する場所」
という感じだったかも。

新しい領域へのチャレンジ

このサイクルにも慣れてきて、自由に作れるようになると
「あわよくば、これで暮らしていきたい。。」
という気持ちが湧くように。。ほんと、人間は欲深い。。

そうなると、広報とか営業とかQAとか
いままでの開発以外にも力を入れていくことが大事。

なので、今は開発以外も含めて、
どう運営していくのがよいかを考えることが多くなってきた感じ。

本業だと別の領域にチャレンジできる機会は、
なかなかないので、これも個人開発のいいところ。

個人開発はたのしい

なんでこんなに長く続けてるんだろう？
と考えてみると、この3つなんじゃないだろうか。

なにもかも自由
フィードバックがダイレクト
個人でもひとりじゃない

(もちろん、個人開発ドリームもあるけど(*´ω｀*))

なにもかも自由

独立してフリーランスになったときも、
自由だと感じたけれど、それ以上に自由。

作りたいものも、使いたい技術も自由に選べるのがいい。

仕事となると、作るもののテーマは大体決まっているし、
安定している枯れた技術やチームにあう言語など、
いろんな制約を考えて決めたりする。

個人開発なら、そんな制約も無いので、
「ぼくがかんがえたさいきょうの構成」
なんてのもOK。

上で書いたとおり、目的すらも自由なので、
心のままに楽しめるのがいい(*´ω｀*)

フィードバックがダイレクト

なにもかも自由である反面、
すべての責任があるのも醍醐味の一つ。

いいこともわるいこともあるけど、
ストレートにフィードバックが来るのは刺激的。

本業だとほめられることが少ないけど、
9対1くらいでいいフィードバックなのでたのしい。

わるいフィードバックも改善点の指摘なので、
どちらのフィードバックもとってもありがたい(*´ω｀*)

個人でもひとりじゃない

自分でそういう情報を追っていっているというのもあるけど、
意外と個人開発者はたくさんいて、コミュニティや勉強会/もくもく会も多くある。

ぼくも運営者ギルドというコミュニティに参加させてもらってるけど、
・リリース前のサービスにバグ出し/アイデア出しするバグバッシュや
・ 1ヶ月の活動内容を報告する月報
なんてのも開催されていて、それをみると「がんばるぞ！」って気持ちになる。

コードを書くのは一人だけど、コミュニティやTwitterを見てても、
がんばっている同志がたくさんいる感じなのが、続けられるのかも。

それと、フィードバックがダイレクトな効果なのか、
ユーザさんと一緒に作ってる感じがすごく強い。

最初のプロトくらいまでは自分だけだけど、
いろんなフィードバックを取り込んでいくうちに、
「自分だけで作ったサービスじゃない感」が出てくる。

ユーザさんが増えていくたびに、
気づかなかったことや自分にない視点が増えていくのがたのしいし、
より喜んでもらえるようにとやる気が出るからかもしれない(*´ω｀*)

おわりに

振り返ってみて思ったけど、目的すら自由な個人開発ってすごい(*´ω｀*)

【PR】SSSAPIをリリースしました！!

スプレッドシートをWeb APIにできるサービスをリリースしました🎉
・ 1件取得/フィルタリング/ページング/ソートもできるAPIを簡単作成
・ドメインやアクセストークンによるアクセス制限もOK

「お知らせとかリリースノートを作りたいけど、
毎回ビルドするのも、管理画面をつくるのもめんどくさい。。」

ってときに便利です!!　スプシが管理画面になっちゃいます!!
無料枠もあるので、ぜひぜひ遊んでみてください(´ω｀)

GoogleスプレッドシートのAPI化サービス
「SSSAPI」

＼㊗️正式リリース㊗️／#SSSAPI の正式版を公開しました🎉開発開始から9ヶ月...無事リリースを迎えられました😭β版でのご協力、ありがとうございます🙇‍♂️まだまだ不便なところもございますが、より一層便利になるよう改善がんばります💪💪💪#拡散希望RTお願いします https://t.co/znp6CJGZEs
— 【公式】SSSAPI / GoogleスプレッドシートのAPI化サービス (@sssapi_app) November 30, 2021

【Twitter連携サービス】連続ツイートをスレッドまるごとダウンロードできるWebサービスを公開しました

2021-11-26T13:02:23+09:00

Twitterを見ていると、とても参考になる連続ツイートをしている人がいらっしゃいます。

私はそういうツイートを見つけるとブックマークしておき、後でいつでも見返せるようにしていました。

ただ、そういう有益なツイートも、もしツイートしたご本人がツイ消ししたり、アカウント自体が消えてしまったりすると 後で見れなくなってしまいます。

そこで、連続ツイートをWordファイルとしてダウンロードしておけるWebサービス を開発いたしました。

「ツイスレバックアップ」 というサービスです。
https://twibackup.com/

作ったきっかけ

個人開発者界隈で有名（と私は勝手に思ってる）な方が、先日個人開発について参考になる連続ツイートをされていました。

https://twitter.com/sesere115/status/1459167602094133254

「ヒトリッター」というサービスを土日に開発しながら、サービスをリリースしていく中で考えるべきことを連続ツイートする内容です。

定期的に読み返したいような内容だったのですが、ふと「もしせせりさんがツイ消ししたら見れなくなるよな…」「念のため手元にずっと残しておきたいな」と思いました。

そこで、連続ツイートをスレッドまるごとダウンロードする、つまり手元にバックアップしておくためのサービス「ツイスレバックアップ」を開発しようと思い立ちました。
（※せせりさんはよくツイ消しする人、という意味ではありません。）

なぜWordファイル？

PDFファイルでのダウンロードも考えたのですが、以下の理由によりWordファイルでのダウンロードにしました。

画像もWordファイル内に入れ込めるので便利。（これはPDFでも出来ますが）
あとで自分でメモを追記できる方が便利。（PDFだとメモしずらい）
なんならそのままマニュアル化しても良い。

このサービスを使うと何が嬉しい？

このサービスを使うと、やはり一番は 「いつ連続ツイートが消える（見れなくなる）か分からない不安」 から開放されるのが嬉しいですね。
自分で開発して、自分で使ってます笑

あと、Wordファイルでダウンロードしておけば仲間内での共有等も格段にしやすくなりますね。

今後の展開

今後はPDFファイルでのダウンロード等、ニーズに合わせて機能追加していきたいと思います。

なにか欲しい機能があれば教えてください！

QnQ開発日誌 SNSからSlack寄りのツールへの移行を模索中

2021-11-02T08:57:05+09:00

まだ続けていたのかと思われそうだけれどまだ続けていた。

Search | QnQ

今何をしているのかというと、SNS的な使い方を諦めて、SlackとかTeams寄りに方向性を変えている。あと使い勝手が悪すぎるので、少しでもUXを上げようと細かい修正。

具体的には、「チーム」みたいなものを作って、そのチーム内でのみ閲覧・書き込みできるような体制にしようとしている。

言い方としては、SlackやTeamsの感じで使う掲示板、って感じかな。あるいは、グループチャットしかないLINEとか？

SNSはキツイしもういらんかな、と

元々SNS的な使われ方を考えて作っていたサービスだけれど、「もうSNSはいいんじゃない」、という話に。評価経済だのなんだの、もう十分でしょ、っていう。

というのは表向きの理由で、実際は「この手のサービスって流行るところまで持っていくのがたいへんすぎるし無理だね」っていう実質的な理由のほうが大きい。特に最近はもうコンテンツさえ作ればGoogleが拾ってくれる時代でもなくなっているし。時代は変わっている。

それでまぁ、それよりも今あるリアルの課題として、「オンラインコミュニケーションの難しさ」があるけれど、それを解決するものとして使えないかな、という話でまとまっている。

イメージはSNSとSlackとかTeamsの間の子くらい

リモートワークでSlackとかTeamsとか使っていると思うけれど、なかなかみんな書き込まないよねとか、すぐ流れちゃうよね、とかいう話をしていて、本サービスの二次元チャットで、ある程度その問題を解決できるんじゃないか、と。

というのも、二次元チャットは言ってしまえば「すべてのレスがリプライ待ち」なので、「話題に遅れる」ということがないし、比較的のんびりしたコミュニケーションにも向いているからだ。このへんの話は、もうちょっと時間をかけてどこかで書きたい。

実際の機能的には、SNSや掲示板とチャットサービスの間くらいの位置づけになるかなぁと思う。開発ではTreeと呼んでいるスレッドをたてるのは掲示板チックだけれど、閲覧権限がチーム。

画像のとおり、「チームの選択」なるものがある。この場合は「qq」としたチームのみで閲覧できるツリー（スレッドみたいなもの）をポストすることになる。ちなみにqqは開発者チームのことで、publicを選ぶと全体公開になる。このへんの名前はわかりやすくしたほうがよさげ。

この機能を、どうつたえるのが一番わかりやすいだろうか。SlackやTeams感覚で使う掲示板。グループチャットしかないLINE。スペースしかないTwitter。そんな感じ？

なので、まだ画面にはフォローとかフォロワーの機能が残っちゃっているけれど、これは完全に撤廃する予定。

なお、まだテスト段階で肝心の「チーム作成機能」はまだ実装していなかったりする。現状、チームは開発者が直接登録する形だ。なので、普通にサインアップすると「全体公開」しか相変わらずできなったりする。

地味なUXの改善

あとはとにかくUX改善しなきゃねっていうところで、本サービス最大の特徴である「二次元チャット」の操作性の向上も少しずつやっている。

友人がしれっと入れた「Ctrl(Cmd) + Enter」での投稿機能は、以前から「あればいいね」くらいの気持ちだったんだけれど、いざ使ってみたら相当便利で、やっぱりUXは実際に入れてみないとわからんなぁと思った。

他、SNSからチャットツール的な使い方を想定=スマホよりPCと割り切ったことで、Macのトラックパッド対応なども。このへんは主に友人が頑張って入れていた。僕はチーム周りの設計などを今メインでやっていて、フロントまわりはあまり絡んでいない。そろそろフロントも真面目にやらんとなぁ、とは思っているけれど中々。

しつこく続ける

ということで、しつこく開発を続けている。まぁこの開発自体が、僕の数少ない友人とのコミュニケーションになっている、というのも大いにあるかもしれない。

FirebaseとSSSAPIでプレスリリースを送ったサイトを記録できるWebサービスを作ってみた

2021-10-05T17:05:54+09:00

開発しているGoogleスプレッドシートのAPI化サービス「SSSAPI」をβ版リリースしたときに、
プレスリリースをいろんなメディアに送ってみてた。

せっかく調べてまとめたし、次も使う機会があるだろうと思ったので、
Nuxt/Firebase/SSSAPIの構成でWebサービス化してみた。

プレスリリースを受け付けてるサイトを調べるのは大変なので、
どこに送れるのかな〜と思った方は使ってみてもらえるとうれしいです(´ω｀)

作ったサービス

https://press-done.memory-lovers.com

送付するプレスリリースごとに、どのサイトへ送ったかの状態管理ができます。
それだけのシンプルなWebサービス。

システム構成

基本構成はこんな感じ。

フロントエンド: Nuxt+Buefy
認証: Firebase Authentication
ユーザデータ: Firestore
マスターデータ: SSSAPI

ユーザが更新しないマスターデータはSSSAPIを利用している感じ。

メディアサイトのデータをFirestoreに入れておく形もあるけど、
Firebaseコンソールで追加や編集するより、
スプレッドシートを更新するほうが楽なので、この形にしている。

スプレッドシートの中身はこんな感じ。

SSSAPIはこんなJSONを返してくれる。

[
  {
    "id": 1,
    "サイト名": "TechCrunch Japan",
    "サイトURL": "https://jp.techcrunch.com",
    "送付方法": "メール",
    "isActive": true
  },
  {
    "id": 2,
    "サイト名": "日経クロステック",
    "サイトURL": "https://xtech.nikkei.com",
    "送付方法": "メール",
    "isActive": true
  },
  {
    "id": 3,
    "サイト名": "ITmedia",
    "サイトURL": "https://www.itmedia.co.jp/",
    "送付方法": "メール",
    "isActive": true
  },
]

※「行数をIDとして追加」オプションを使ってるので、idが自動で付与されています。

このスプレッドシートは登録依頼のGoogleフォームと連動しているので、
追加依頼があったら内容を確認してisActiveをtrueにすれば反映されます。

こういった構成は割と多く、本の貸し出し管理と備品管理とかでも使える。
Webサービスからスプレッドシートを編集できないので、
管理者権限とか不要なので、その分フロント側も楽に作れた(´ω｀)

プレスリリースってどこに送れるのかな〜と思った方は、
ぜひ使ってみてもらえるとうれしいです(´ω｀)

https://press-done.memory-lovers.com

SSSAPIはβ版ユーザを募集しています!!

β期間中はプレミアムプランの内容を無料で使えるのでお得！
ぜひぜひ、この機会にお試しいただければ！

わからないところやこんなのあったらいいなぁ〜などあれば、
Twitterやお問い合わせなどからお気軽にご連絡ください〜

GoogleスプレッドシートのAPI化サービス
『SSSAPI』
Twitter: @sssapi_app

https://sssapi.app

開発の励みや記事を書くモチベにもなるので、
いいねやシェア、はてブなどしてもらえるとかなりよろこびます!!

QnQ開発日誌チームで使う作業メモの共有的な使い方を考える

2021-09-13T02:57:17+09:00

開発っていうか、まぁこのままじゃ一生誰も使わないよね、ということで、どうしたもんかな、と話していた。

結論的には、チームで作業メモを残して共有するような用途に使えないかな、という話になっている。それに向けて、具体的な作業を明日から始めて、来週の連休には実証できるような状態にしたい。

なんちゃってもくもく会

時間をかけて作ったWebサービスは、相変わらず僕の独り言か、あるいは友人との交換日記くらいにしか使われていない。

なんだけれど、アクセス解析を見ると、どうも10人くらいはそれなりに見にきてくれている人がいると思われる。個人ブログを購読しているような感じなんだろうか。不思議だ。まぁユーザー10人って、個人ブログにしてもあまり流行っていない規模だけどね……マンネリ化して久しい僕のブログのほうがよっぽど人が多い。

まぁでも、見てくれる人がいることは有り難い。が、書き込みまではいかないし、このまま続けても書き込まれる未来が見えないので、いい加減ちょっと方向性考えないとね、という話を友人としていた。

話しているうちに、ユースケースとして、チームで開発経過を残し、共有する用途はどうだろうか、という話になった。というのも、現在、僕と友人は「もくもく会」と称して、毎日に近い割合で、日々の作業をサービス上で共有しているのだ。ちょうど50回を迎えた。

もくもく50 2021-09-12 | QnQ

tamaは僕で、yuが友人なのだが、それぞれの枝に分かれて、自分の作業を書き残しているような感じ。で、時々相手の枝にレスしたりしている。

これを、チームの開発に使えないかな、というわけだ。

作業報告、雑談、軽いコミュニケーション

このコンセプトは悪くないんじゃないか、と思っている。

リモートワークが盛んになって、よく言われる問題として、「雑談がなくなった」「寂しい」「他の人が何をしているのかわかりづらい」というのがある。

原理的には、SlackなりTeamsなりで個々人が自分の作業を報告しあえればいいんだけれど、SlackにせよTeamsにせよ、そういう用途を想定して作られたわけではなく、ちょっとやりづらい。

まぁやるとすれば、自分の作業用のスレッドを作って投稿していく、というスタイルが考えられるだろう。というか、昔職場でそんなようなことをしていたこともあった。

あれは悪くなかったんだが、他の人のスレッドって、なかなか見に行こうと思わないと見に行かないんだよね。その点、このサービスなら、特に意識せずとも相手の状況を把握できる。なにかエラーなどでハマっているようであれば、力になれることがあるかもしれないし、逆に助けてもらえるかもしれない。また、仲間のやっている仕事は、けっこう参考になるものだ。

ということで、リモートワークが盛んになり始めた今の時代に即したサービスだと考えられて、中々面白いんじゃないかと思っている。

まー、使ってもらう、というのが一番むずかしいんだけどさ。ただまぁ、目的が明確なら、誰かを誘ってやってみる、ということもできないことはないはずなので、そこはまぁ、頑張るしかない。

技術よりも広報が難しい！！

つくってるWebサービスのユーザ数が15倍になったときにやった5つのこと。

2021-08-29T17:21:16+09:00

先日、開発中のサービスのオープンβ版を公開したら、4日でユーザ数が15倍に。。
想像以上の反響だったので、どんなことをやってたかをまとめてみました。

リリース後のプロモーションはいつも困っているので、、
これから何かを作ろう、リリースしようとしている人の一助になれば。

※注意※
・元のユーザ数が少ないのですごく増えた感あり。運要素が強めです。
・実際のユーザ数やデータはちょっとはずかしいので有料にしてます
　(Crieitの有料記事機能を使ってみたかったって理由も)

実際にやったこと

LPや事前登録サイトを公開
運営者ギルドでバグバッシュしてもらう
PR TIMES等でプレスリリースを公開＆ツイートする
Zenn/Crieit/Qiita等で記事を公開＆ツイートする
RTされやすそうな時間帯にセルフRTなどする

実際のやったときの流れ

7/6(火): 事前登録サイトの公開&PR TIMESでプレスリリースを公開
7/10(土)-7/12(月): 運営者ギルドでバグバッシュ
8/24(火): PR TIMESでプレスリリースを公開
- → プレスを元にした記事をデジタルシフトタイムズさまから公開
- → この記事がはてなブックマークのテクノロジーでホッテントリに!!
- → ホッテントリに入ったので、Discoverで表示(Google砲)!!
- → つられて、SSSAPI自体もホッテントリに!!
8/25(水): Zennで記事を公開
- Firestore最高だけど、初期データとかマスタデータ管理がめんどくさいので、スプレッドシートをAPI化サービスを作ってみた
- → トレンド入りし、トップページに表示される!!
8/26(木): Qiitaに記事を投稿
- GASでもできるけど、スプシをAPI化するサービスを作ってみた。そして、そのときハマったこと。 - Qiita
- → トレンド入りし、トップページに表示される!!

それぞれ記事を投稿したら、朝/昼/夜くらいでセルフRTなどしてました。

(フィードバックやいいね/RTで拡散で協力してくれた方、ほんとありがとうございます!!)

1. LPや事前登録サイトを公開

まずは、トップページのみの事前登録サイトを作って公開してました。
事前登録の受付は、Googleフォームの簡易的なサイト。

事前登録のプレスリリースを打つためもありますが、
サービス名を検索するとヒットするように、あらかじめ用意していました。

ツイートへの反応や登録者数なども、ウケそうかのどうかの判断材料に。

2. 運営者ギルドでバグバッシュ

運営者ギルドは、Webサービス運営者が集まっているコミュニティ。
すごい人ばかりで、Slack内も知見がすごいですが、
その中のイベントの一つ、バグバッシュをしてもらいました。

バグバッシュは、「リリース前にみんなにさわってもらってバグを見つけよう！」
という活動なのですが、バグだけでなく、どこがわかりにくい？なども聞けることも。

みんなそれぞれ運営しているので、いろんな視点のフィードバックが集まり、
自分では気づけないポイントのコメントを多くもらえました。。！

そのフィードバックを踏まえ、改善＆ブラッシュアップ。

3. PR TIMES等でプレスリリースを投稿

PR TIMESにプレスリリースを投稿すると、
各種メディアに掲載され、露出が増えるので、活用しています。

配信のタイミングは、以下の記事を参考にしていて、
火曜日の朝10時10分にしました。
・プレスリリースの配信タイミングは？曜日・時間を戦略的に決定して効果を最大化させよう

また、会社設立日から2年は無料枠がもらえる、
スタートアップチャレンジを活用しています。

・スタートアップチャレンジ｜PR TIMESプレスリリース無料配信プログラム

4. Zenn/Crieit/Qiita等で記事を投稿

なにか作ったら各種サイトに記事を書いてます。
今回はZennとCrieitとQiita。
(Zennはずっと投稿したかったけど、ネタがなかったけど、初Zennできてよかった(´ω｀))

それぞれトレンドに掲載されると露出が増えるのもあるけど、
LPやトップページには書ききれないことを記事で補足している感じ。

今回は、以下のテーマでそれぞれ書きました。
・Zenn ... なんで作ろうと思ったかの理由と経緯
・Qiita ... システム構成や技術要素
・Crieit ... PRのためになにをしたか(この記事)

特に、Crieit独自の機能である、カノニカルが設定できるのが好きで、
Zennなどに投稿するときは合わせてクロス投稿しています。

いいね等が集計時に5〜10くらいつくとトレンドに乗れるっぽいので、
記事書いて、ツイートして、RTして、たくさん祈ります🙏

Qiitaは毎日5時/17時に更新されるので、
集計対象の時間が長くなるよう、その時間くらいに投稿がよさそうです。

5. RTされやすそうな時間帯にセルフRT

プレスリリースや記事を投稿したときもそうですが、
Twitterで伸びる曜日と時間帯というツイートを見てから、
なるべくこのときに投稿するように意識しています。

【データから見るTwitterのツイートが伸びる曜日と時間帯🔥】◼︎平日・5:00、11:00、15:00、20:00◼︎休日・8:00、12:00、14:00、16:00→多くの方が通勤時間帯や夜間がユーザー数が多い為、良いと考えているが、実はタイムラインの流速が早くツイートが流れてしまう可能性が高い。#デジプロ pic.twitter.com/JHIT9Nv6QK
— デジプロ🔥＠デジタル広告のプロを育てる学習サービス (@digimapro) August 13, 2019

◼︎平日 ... 5:00、11:00、15:00、20:00
◼︎休日 ... 8:00、12:00、14:00、16:00

一日に何回かあるので、他の時間帯にセルフRTを活用。

セルフRTは結構抵抗があったけど、
昔、とあるマンガ家さんが

ツイートしただけではダメ。
何度もセルフRTしない届かないし、見てもらえないよ。

的なことをいってたツイートを見てから、
見てほしいツイートはなるべくRTするようがんばってる。
(イラスト系だと昼あげ/夜あげとかみるので同じ感じ。)

運要素多いけど、やさしいフォロワーさんが
いいね/RTで拡散してくれるので、ほんとありがたすぎる。。

まとめ

こんな感じで、なるべく露出が増えるよう、
サービスを知ってもらえるような活動をしていました。

LPや事前登録サイトを公開
運営者ギルドでバグバッシュしてもらう
PR TIMES等でプレスリリースを公開＆ツイートする
Zenn/Crieit/Qiita等で記事を公開＆ツイートする
RTされやすそうな時間帯にセルフRTなどする

トレンド→はてブのホッテントリ→Google砲、
などのコンボが決まると広く拡散しますが、
0いいねなどよくあるので、いつも運ゲー。。

地道にサービスを改善しつつ、
記事などのコンテンツを増やしつつ、
最後は天にまかせて、がんばっています！

リリース後のプロモーションはいつも困っているので、
これから何かを作ろうとしている人の参考になれたらうれしいです😊

SSSAPIでは、β版ユーザを募集中です！

β期間中はプレミアムプランの内容を無料で使えるのでお得！
ぜひぜひ、この機会にお試しいただければ〜！

GoogleスプレッドシートのAPI化サービス
『SSSAPI』
URL: https://sssapi.app
Twitter: @sssapi_app

記事を書く励みにもなるので、
よかったら、いいねやシェア、はてブなどもよろしくおねがいします!

はてなブックマークはこちらから

※以下、有料コンテンツです※

以下のデータを公開しています。
ちょっとはずかしいので、おもしろいと思ってくれた方は、
コーヒー一杯差し入れるくらいの気持ちで見てもらえれば〜

Google AnaliticsのPV数/流入元
PR TIMESの統計情報
SSSAPIの登録者数とAPI作成数
(おまけ) Twitter広告を試してみた結果

Firestore最高だけど、初期データとかマスタデータ管理がめんどくさいので、スプレッドシートをAPI化サービスを作ってみた

2021-08-25T05:47:03+09:00

開発しているGoogleスプレッドシートのAPI化サービス「SSSAPI」。
無事にオープンβ版を公開できたので、なんで作ろうと思ったかを書いてみた。

http://sssapi.app

なぜ作ろうと思ったか

個人開発が好きで、いろんなものをちょこちょこ作ってる。
今は、Nuxt.jsとFirebaseがお気に入りで、
小さなものを含めると20サービスくらい作ったと思う。

ちょっとしたものを作ることも多く、
「もっと楽に作ることはできないかなぁ？」
といろいろ考えたりしていた。

その時同時に考えていたのが、ゲーム攻略のサービス。
マスタデータが多く、更新も早いので、どうしようかなと。

とりあえず、初期データが必要なので、
スプレッドシートにまとめていた。

データを集め終わって、いざつくろうとしたときに、
「このままJSON APIにできれば楽なのにな〜」
というのが最初だった。

最初はJSONファイル

ゲームの攻略サービスを作っている途中だったので、
まずは、スプレッドシートAPIでJSON化して、
JSONファイルをソースに含める形で開発。

これだけでも割とよく、
とりあえずJSONファイルで開発するのは良い感じだった。

データの項目が足りなくても、
スプレッドシートなら列を追加するだけなので、
データ構造を検討している初期はスムーズに進んだ。

ただ、JSONファイルをインポートしてるので、
ビルドサイズは大きくなるし、
データを更新したいときはビルドしないといけないので、
めんどくさいな思うようになり、API化は必要だなと作りはじめた。

Firestoreで初期データをめんどくさい

今まで作ってきたものを振り返ると、
割とこういうことが多い感じだった。

過去に作ったものでも、カテゴリやお知らせなど、
こちらが用意するデータは、JSONファイルで用意していたり、
JSONファイルの内容をFirestoreに登録するスクリプトを書いていた。

Firestoreは便利なんだけど、
管理画面は自分で用意しないといけないので、
マスターデータを扱いたいときは、めんどうな部分があった。

1つ項目を追加するのにも、JSONファイル＆ビルドだったり、
追加用のスクリプトを書かないといけない。。

SSSAPIであれば、スプレッドシートを管理画面にでき、
そのままAPI化できるので、かなり楽になるな〜と。

実際、楽になって、crieitのweb1weekの企画へ
参加したときに作ったWebサービスは1~2日で開発できた。

他のじゃダメだった？

いざ作るとなると、時間が必要なので、
既存のものはないかな〜と見てみた。

見てみたのは、GAS、ヘッドレスCMS、競合サービスの3種類。

GASは？

一番よく見るのはこれかなと思う。
Google Action ScriptでWebサービスとして公開するパターン。

記事も多くコードもあるので、便利で昔使っていた。

ただ、シートごとにGASの設定が必要だったり、
どれが設定したスプレッドシートか忘れてしまうので、
一元管理ができればな〜と思ったりする。

SSSAPIであれば、毎シートにGASを設定する必要はないし、
登録してあるスプレッドシート=API化しているなので、
一元管理も簡単にできるようにした。

ヘッドレスCMSは？

次によくみるのはヘッドレスCMSかなと思う。
スキーマも柔軟に設定できて、管理画面もリッチ。

ただ、内容がリッチすぎたり、
個人開発だとお高めの価格設定なので、手が出せず。。

「多くのサービスを楽に作りたい!!」と思うと、
無料枠の制限では心もとないなと。。
また、アクセス制限などは有料プランぽいので、断念。

SSSAPIでは、機能は限定的だけど、
個人開発でも使いやすい価格帯になるようにがんばってる。
無料のプランでもドメイン制限を使えるようにしている。

競合サービスは？

今まで聞いたことがなかったけど、調べてみたら、
6つくらい競合のサービスがあった。

もちろん、ヘッドレスCMSよりも安めだけど、
Googleドライブやスプレッドシートへの全権限を許可しないといけない。。
もしくは、全員がアクセスできるように共有設定を変更する必要がある。

Googleドライブやスプレッドシートへの全権限を許可は、
割とこれが強くて、個人情報や機密情報を入れているアカウントだと使えない。

API化したいスプレッドシートのデータ自体も財産なので、
オープンにはしたくないときも多い。

SSSAPIでは、権限を共有するのではなく、
システムアカウントを共有設定に追加してもらう形にし、
共有設定されているシートのみ参照できる方法にしている。

すこし手間ではあるけど、安心・安全のため。

ドメイン制限やアクセストークンによる認証も用意しているので、
APIのURLがわかっていても、アクセスできない仕組みを用意している。

使ってみてどうだったか？

利便性・価格・セキュリティの面から、
作ったほうがいいなぁと思って、開発を進めてみた。

使っているのが、マスターデータが多いものに偏っているけど、

スプシが管理画面になる
ビルドしないで更新できる
ドメイン制限できるので守れる

と、かなり便利に。

他のサービスのお知らせやリリースノートなども、
順次、SSSAPIに置き換えている。

ユーザが作成するデータは、今までどおりFirestoreを使っている感じだけど、
プロトタイプ開発のときやテストデータ作成なんかでも活躍してるので、
最初に思っていた「ちょっとしたものを早く楽に作れる」ようになった気がする。

スプレッドシートで管理するのつらいな。。という規模になってきたら、
JSON APIの結果をFirestoreに突っ込めばよいのもいい。

β版なので、まだまだ足りないところはあるけど、
ユーザさんからのフィードバックとドックフーディングをして、
よりよいものにしていければと思う。

SSSAPIでは、β版ユーザを募集中です！

β期間中はプレミアムプランの内容を無料で使えるのでお得！
ぜひぜひ、この機会にお試しいただければ〜！

GoogleスプレッドシートのAPI化サービス
『SSSAPI』
Twitter: @sssapi_app

🌟🌟オープンβ版の公開開始🌟🌟フィルタリングやページングなど機能を強化し、より便利になりました😊β版はプレミアムプランの内容を無料で利用できます🙌ぜひ、この機会にお試しください‼️‼️GoogleスプレッドシートのAPI化サービスhttps://t.co/fKUGVFeQR7 #拡散希望RT協力お願い致します pic.twitter.com/O2rjs35BZD
— 【公式】SSSAPI / GoogleスプレッドシートのAPI化サービス (@sssapi_app) August 24, 2021

http://sssapi.app

QnQ開発日誌開発したWebサービスは俺の日記帳になった

2021-07-26T02:59:19+09:00

こんにちは。二次元掲示板、「QnQ」の開発日誌でございます。

前回の記事「開発中のWebサービスは友人との交換日記と化した – 或る阿呆の記」では友人との交換日記と言ったが、最近は友人も忙しいのか書き込み頻度がめっきり減ってしまい、最近は書き込みの多分9割くらいが僕の独り言と思われ、交換日記どころかもはや「俺の日記帳」みたいになってしまった。まぁTwitterのタイムラインを汚さずに、いいたいことをネットの虚空に向かってペラペラとしゃべっているとでも言えばよいだろうか。

長らくそんな状態だったのだが、本当に「みんなの日記帳」的な方向に開発が進みそうだ。

俺の日記帳

ここまでに大きな変化もあり、発起人である友人は元々の目論見が外れたということで、ユースケースに悩んでいるようだった。まぁ悩んでいるのは、僕が散々「このサービスは結局なんなんだ」とつっついたせいもあるかもしれない。

というと肝心なところを人任せかという感じだが、それは彼が発起人でありプロジェクトでいえばリーダーに相当するからであって、別に責任を押し付けているわけではない。実際、僕も僕なりにサービスの可能性は模索していて、冒頭に書いたとおりもはや書き込みの9割……多分言い過ぎじゃなくそれくらいが僕の独り言みたいな状態になっているほどだ。

そして僕の現在における結論、というよりは現状が、「俺の日記帳」なのである。

具体的には、普段の開発や勉強の軌跡を綴ったり、YouTubeでやっているアニメ美味しんぼの実況をしたり、気になるニュースについて徒然と語ったり、といった具合である。

まぁ正直、Twitterのタイムラインを汚さずに好き勝手言えていいな、程度の感じである。ここから記事化したのもあるので、まったくもって全部無駄というわけではない。

二次元掲示板の使い道

現状のUXから、このサービスの本質を一言で言えば、「二次元掲示板」になるだろう。時系列、あるいは人気順などで書き込みを並べる通常の掲示板と違って、このサービスは書き込みの流れを二次元的に表現している。

個人的にはこのUIだけで面白いものだと思うし、本当を言えばいろいろな人たちの雑談や議論に使われてほしいと思う。二次元掲示板は、常に文脈が強烈に意識されるため、単発の言いっぱなしになりづらいのである。これはTwitterなどで実りのない応酬にしんどみを感じている人たちなんかには特に有効だと思われる。

ただまぁ、そのためには人を集める必要があるのだがそれも難しく、結局ソロユースでの使い道ばかりになってしまった、というのが実際のところだ。これはこれで個人的には可能性があるものだとは思ってはいるので、とりあえず当面はソロでぼちぼちやっていくつもりだ。

と、いう決意を固めていたわけではなかったのだが、今日の話し合いでもまずはソロで地道に使っていくのが現実的かもね、という話になってしまったので、晴れてチームとしても方向性が「俺の日記帳」ならぬ「みんなの日記帳」サービスになってしまったかもしれない。

僕もそうするより他ないんじゃないの、なんて言いながら、正直言うと本当にそれでいいのかなぁ、とか思ったりする気持ちはないでもない。かといって他にアイディアがあるわけでもない。

サービスを使ってもらうってのは難しいなぁなんて思いながら、つくづくTwitterとかnoteはすげぇなぁと、感心するばかりだ。

開発中のWebサービスは友人との交換日記と化した

2021-05-16T18:36:44+09:00

友人が発起人になって、一緒に開発したWebサービスがある。

QnQ

これはまぁ、一言で言うと二次元チャットみたいな感じ。二次元チャットってなにそれ意味分かんないと思われるが、Twitterのツイートツリーが分岐する様子が可視化されたもの、といえば少しイメージがわくだろうか。たとえば以下のような感じだ。

二次元チャット

ブログとnoteの使い分け | QnQ

僕がnoteを本格的に書き始めたのはここ10日ばかりのことだが、もともとブログをやっていた僕は、その使い分けをどうしたものかと考えていた。で、それについて考えた軌跡である。僕の考えがツリー上に展開されているのがわかるだろうか。

これは僕の独り言状態だが、ログインしていれば誰でもコメントをつけることが可能だ（上記のURLについては、既にクローズしているのでコメントはつけられない）。で、見切れているが友人もコメントしてくれている。

多分今までにないフレームワークで、けっこう面白いと思う。

ちなみに、当初かなり意識高い系で売ろうとしていた。友人がnoteに公開記事を書いている。

質問に質問で返されるドM向けQ&Qサービスを公開｜adnyer｜note

ちなみに僕も自分のブログに紹介記事を書いた。

質問に質問で返されるドM向けQ&Qサービス、QnQを公開・開発中です – 或る阿呆の記

タイトルは似ているが、内容は僕と友人の性格的な違いがけっこう出ている。

さて、このサービスだが、公開して半年ほど経過するものの、たいへんなことに現在定着したユーザーは0である。マジで。使ってくれた人もいるが、定着した人はいなかった。

その理由については色々思うところありつつ、せっかく作ったので僕と友人は使っている。その結果、長い時間をかけて作られたこのサービスは現在、僕と友人の交換日記状サービスになっている。交換日記ならまだマシで、僕の独り言コーナーになっていることもよくある。

それでも開発を続けているのは、実際面白いサービスだと思っているのと、まぁ数少ない友人との繋がりだから、みたいなのもある。後はまぁ、自分でサービスを開発して運用しています、というのは今後転職する時にも使えるだろう、というのもある（今の職場にはそれなりに満足しているので、転職予定はない）。

とはいえ、さすがに僕と友人の交換日記状態が延々と続くのは余りにも悲しいし虚しい。使ってもらえないのはサービスとしての魅力がないからなんだが、僕にはどうしても本質的に面白さのあるサービスだと思えてならない。自分の子供だから可愛く感じるんだと言われればそうかもしれないんだが……。

どうにも諦めるには惜しい気がするので、もうちょっとちゃんと作り直し、都度宣伝もしていきたいと思っている。

noteは始めたばかりだが、SNSとして非常に参考になるところがあるので、色々考えて反映し、なんとか使ってもらえるような、魅力あるサービスにしていきたい。定期的に開発日誌をつけていくつもりだ。がんばろう。

制限の少ない自由なSNS　～Ammot～

2021-04-14T20:37:19+09:00

初めに

この度Ammotというwebアプリを開発しました。
「制限の少ない自由な投稿を」がコンセプトで文字数が6000字まで、画像・動画・PDF・音声は同時に10個まで投稿可能です。
「ツイッターは文字数制限がきつい、ただfacebookは実名制だしデザインがごちゃごちゃでいや」
という声を聴いたので作ってみました。

https://ammot.net/

qiitaのほうでも宣伝したのでよかったら見てください（ちょい違う内容です。）
https://qiita.com/UTOG/items/d5e6194aaa31b54e97c9

どんなサービスか

↑これがログイン後のトップです。フォローしたユーザーの投稿がHOMEに流れて、
サイドバーにはおすすめの投稿と現在人気のタグを表示しています。

文字数制限が6000字まで、画像・動画・PDF・音声は同時に10個まで投稿可能です。

先ほどサイドバーにおすすめを表示していると書きましたが
実はサイドバーはおすすめ機能などなくランダムで表示してるだけです。。。
おすすめ機能（レコメンド）を実装できなかったというのもありますが、僕自身レコメンド機能が結構嫌いなんですよね。同じ、似たようなものばかり出てきて飽きてきますしたまには普段と全く違うものを見たい時もあるでしょう。
だからタイムライン（home)には好きな投稿が流れるようになっていてサイドバーは完全ランダムにしました。

ツイッターのいやなとこ

文字数制限
編集ができない（個人的にめちゃ嫌）

facebookのいやなとこ

制限はないがデザインがぐちゃぐちゃ
実名制はなんかいやだ

この二つSNSの問題を解決するのがAmmotです。

工夫した点

無料プランにこだわった

こういうものはバズらない限り、すぐには成功しません。使用者が全くいなくても１年は公開しようと思います。
でも使用者がいないのに月数百円も取られるの馬鹿馬鹿しいじゃないですか。だからドメイン以外はすべて無料です。
ただherokuの無料プランだとドメインを設定できないのでCloudflareを使い設定しました。

参考記事：
https://qiita.com/serinuntius/items/f7f08b2221f5ad068f5d

しかし、やはりSNSは速度が非常に重要なので少しだけ批判を受けました。自分はもう少しユーザーと投稿が増えてきたら有料のサーバーにしようと思います。

デザインとUIにこだわった（つもり）

フィットスクロール？だったり投稿画面のポップアップだったり
今まで使ってこなかった手法を使ってみました。
自己満になってるかもしれない

ちなみにデザインを参考にしたサイトはtumblrです。
比べればまぁまぁ似てると思います。

機能性

最初にも書きましたが画像・動画・PDF・音声の投稿とプレビュー機能を実装しました。
これにはいろんな記事がありましたが

まともに動きかつ一番簡単でコードもシンプルなこの記事を参考にするのをお勧めします。
https://qiita.com/0thefool/items/5af0f17f0075e7e0e013

マークダウン

他SNSとの差別化も含めマークダウンに対応しました。
文字の大きさやフォント？も自由に変えれます。

使用した技術

rails6
ruby2.7
postgresql
heroku free
aws s3

gem 'ridgepole'
gem 'slim-rails'
gem 'html2slim'
gem 'pry-rails'
gem 'devise'
gem 'kaminari'
gem 'activeadmin'
gem 'rack-attack'
gem 'rails-i18n'
gem 'devise-i18n'
gem 'devise-i18n-views'
gem 'carrierwave'
gem 'rmagick'
gem 'rinku'
gem 'fog-aws' 
gem 'dotenv-rails'
gem 'omniauth-google-oauth2'
gem 'omniauth-rails_csrf_protection'
gem 'redcarpet'
gem "rouge"
gem 'redis-rails'
#一部抜いてます

まとめ

今回の開発は今までやらなかったことにめちゃ挑戦できたので楽しかったです
苦手なjquery・javascriptもプレビュー機能のおかげでちょっとわかった気がしてます。

文字数制限や実名制で不便を感じたことのある人はぜひAmmot使ってください！お願いします。

↓URL
https://ammot.net/

↓僕のAmmotのアカウント
https://ammot.net/user/yamada

↓僕のツイッターのアカウント
https://twitter.com/yamada1531

過去に思いついたWebサービス/アプリのアイデアを吐き出す

2020-12-09T12:01:40+09:00

僕はWebサービスを作るのが好きなのだが、ZennというWebサービスを開発しているため、しばらくは実際に作ることが難しい。そこで、アイデアを書き出しておくことにする。中にはすでにサービスとして存在するようなアイデアもあると思われる。

画像出力前提のTwitter用ブログサービス

Twitterと連携することを前提としたミニブログ投稿サービス
ツイッターでちょっとした長文を書きたいときに使う
書き終えると「タイトル」1枚 + 「本文」最大3枚の画像が出力されるので、この画像をTwitterに流せる
- よく長文をメモアプリとかのスクショで投下する人がいるが、あれをもっとやりやすく最適化したイメージ
- Twitterでちょうど見やすいように画像サイズや文字の配置などを調整する
Twitter APIを使って、自動で4枚の画像をツイートできるようにする
- 「こういうツイートがされます」と公開前にプレビューを分かりやすく表示できるのがポイント
画像では読みにくい人のために本文はサービス上で読めるようにする
- Twitter APIで投稿する場合は、本ツイートへのリプライで「全文はこちら」というリンクを自動で貼るようにする

40字制限のTwitter

140字って意外と書けるよね。だから意識高いこととか書いちゃう
- 僕もTwitterに意識高いこと書いてるよ。もう後戻りできないよ
40字制限にすれば意識高いことを書きづらくなり、みんな「にゃーーん」とかしか言えなくなるのでは
代わりに投稿に対するリアクションでSlackみたいに色々使えるようにするといいんじゃないかな

TwiPicks

News Picksのコメント欄をツイートに代替したもの
APIで自動でツイート取得。
記事（URL）ベースでアグリゲーション
よく考えたらこれニュートピがやってることか
UIの工夫次第では時間を潰せる場所になりそう

でぶレシピ

ファミチキを買ってきて米の上にのせてマヨネーズとベビースターラーメンかけて出来上がりです！みたいなデブための簡単レシピだけを集めたサイト
全部のレシピの手順をTwitterであるあるな感じにする「騙されたと思ってさ…ごはんの上にファミチキのせて、ベビースターラーメンとマヨネーズぶっかけてみて…。悪魔みたいな旨さになるから…」。ひたすらこういうのがサイトに並んでるというカオスな感じ。
- はてぶ民に嫌われそう
Twitterで拡散されることを前提にサイトを作る

保護犬の良さみを広めるためのwebメディア

これは僕がやりたいだけ
保護犬はいいぞ。みんなペットショップで犬を飼おうとする前に保護犬を探してみたらどうだい？
全国の保護犬を飼ってる人たちにインタビューして胸アツエピソードとか残していきたい
ページビューが増えたら、犬を保護しているNPOとかと連携して、保護が必要な犬の情報も載せる
Twitterで拡散されやすいようにうまく設計できれば、もしかすると不幸なワンコたちを減らしていけるかも？

OSSのアイデア

オープンソース絵文字

これはWebサービスではなくただのアイデア
現状だとサービスに導入しやすいオープンソースの絵文字はTwemojiくらい。でもTwemojiってあまり映えない絵文字が多かったりする。
イラストを練習がてら全種類の絵文字を描いて、オープンソースとしてGitHubに公開する
- イラストが綺麗で統一感があれば、多分ものすごくStarがつく。僕もつける
- SVGとPNGの2種類が必要だと思われる。SVGだけでもいいかも
世界的に普及すればFontAwesomeっぽいビジネスが可能かも

macho.css

茶色っぽいゴリゴリでテカテカのWebサイトを作るためのCSSフレームワーク
キャッチコピー「Light weight and well built CSS frame work that lift up your website.」
コンポーネント
- ボタンはとても立体的に隆起したテカテカしたものを
- チェックボックスやラジオボタンなどのフォーム部品も思わず押したくなるような筋肉みたいなテカテカしたものを
- 「style--thin」とか「style---well-built」とか筋肉を想起させるようなクラス名にする
サイトのフッターに「Buy me protain」という寄付を募るリンクを貼る

他にもありますが、力尽きたのでこんなところで。

プログラムコードを販売できるサービスまとめ

2020-10-18T18:32:30+09:00

今回はプログラムコードを販売できるサービスをまとめました。

code-sell

code-sell

宣伝です...。僕が1週間くらい前に作ったサービスです。なるべく簡単に販売・購入できるようにしました。
いま僕が今まで作ったwebアプリのコードをすべて無料で公開しています。

piecex

piecex

おそらく一番メジャーで人気のあるサービスです。
AIを搭載していて最適な価格がわかるそうです。

osadasoft

osadasoft
コード一つ一つが高額です

補足

sourcegene
は登録ができませんでした。最新のコードも2018年なのでおそらくサービス終了しているんだと思います。

まとめ

今回はプログラムコードを販売できるサービスをまとめてみました。とりあえずいえるのは
code-sell使ってください。

【1週間】Web ゲームを爆速で開発するために実践したこと🐧個人開発向け

2020-06-23T09:37:52+09:00

(内心)
作ったゲームを沢山の人に触ってもらってリアクションが欲しいなぁ～
そうだ、記事投稿して宣伝しよう！

といった下心で書いた記事です。すみませんでした遊んでください😆

Web Game 処女作🎉シンプルでストレス発散になるゲームが爆誕！敵さんを吹っ飛ばして 1,000 G 以上を目指してみてね😆https://t.co/h8w574aGGQ★アドバイス急募★『こうしたらもっと面白くなる』など、ご意見ご感想を頂けると嬉しいっす(〃´∪｀〃)ゞ#今日の積み上げ #100DaysOfCode DAY 21 pic.twitter.com/HJvFj87zTf
— hikaru🐧#100DaysOfCode! (@hikaru_firecamp) June 17, 2020

ペンギンがサメさんを倒すゲーム
敵さんを吹っ飛ばして 1,000 G 以上を目指してみてね😆
https://games.westa.io/

0⃣ 結論 / 爆速で開発するために実践したこと

１週間のカウントダウンタイマーを設置する
適当な企画書を作って全体を把握しならが作業する
新しいことは１個までに制限して知っているものを使う
こだわりたい部分を絞り他を捨てる覚悟を持つ

1️⃣ この記事の対象読者

この記事では１週間で Web ゲームを作る為に何を考え何をしたのかを書きました。
以下に当てはまる人達に参考になれば嬉しいです。

好きなことへのこだわりが強くいつまでも作品が完成しない人
いつもダラダラ期限を伸ばしてしまう人
このゲームがどんなライブラリ使っているか知りたい人
奇特な人

2️⃣ なぜ１週間なの？

個人開発の一番の敵っていかにモチベーションを保つかだと思いませんか？

私の場合１ヶ月もたてば他に興味あることが出てきてしまうのでモチベーションが移ってしまいます。
でも、１週間なら全力で頑張れるちょうどよい長さかな～と考えました。

(それと、１週間ならクオリティ低くても言い訳になるかなと)

3⃣ １週間という短い期間で終わらせるために意識したこと

(1) １週間のカウントダウンタイマーを設置する

いつもズルズル伸ばしてしまう癖があるので Twitter で公開日を宣言しました。
そして公開日までのカウントダウンタイマーを常に目に入る位置に設置しておきました。

次に出す Web アプリのリリース日を 6/17 12:00 頃に決めました🎉メリハリ付けるために中途半端でもこのタイミングで出します写真はちょうどいいカウントダウンタイマーが無かったので作ってみました▪コードはこちらhttps://t.co/HiGjiROP4R(8,9行目を編集すれば自分用に使えるよ！) pic.twitter.com/HnjXxktDLb
— hikaru🐧#100DaysOfCode! (@hikaru_firecamp) June 8, 2020

このカウントダウンタイマー、すっごく効果があったように思います。度々目に入るので程よい緊張感と無機質な圧力をくれます。
さらにシレっと周囲の人たちに公開日を宣言できるのでかなりお勧めです。

⚠ 補足 ⚠
さも予定を守ったように言ってますが結局半日ほど遅く公開してしまいました
ほんとすみませんでした 😗

(2) 適当な企画書を作って全体を把握しならが作業する

企画書などが無い状態でコーディングすると目に付いた場所から手を付けてしまいがちで視野が局所的になりやすく作業の優先度決めが難しくなります。

簡単なものでも全体像を把握できるものがあると、次にどの部分を実装するか考えるときに『最低でもここを実装しないとだから優先度高めで』みたいなスケジュール管理が容易になります。

今回は以下の様な簡易仕様書をあらかじめ書いておりました。

これから作るミニゲームの簡易仕様書！よくあるクリックゲームですが、ちゃんと作りきれるか不安😇１週間がんばります〜(あ、奇しくも一人 web1week みたいになってる)全然関係ないけど最近 iPad でお絵描きの練習始めました！スマブラやったことあればピンとくるはず😎 pic.twitter.com/oVo5xAUeBe
— hikaru🐧#100DaysOfCode! (@hikaru_firecamp) June 9, 2020

これのおかげで実装段階での仕様変更が減り、一直線にゴールに向かって実装できるので結構大切なものだと思います。

(3) 新しいことは１個までに制限して知っているものを使う

初めて使う道具が多いと勉強することが増えたり些細なことにはまったりして時間を消費しがちなので、使い慣れた開発環境と使った事のあるライブラリを中心に選定しました。

使い慣れたもの

VS-Code ... 開発環境
TypeScript ... 開発言語
UIKit ... UI コンポーネント

以前から実験レベルで遊んでいたもの

Three.js ... 3D 描画エンジン
Cannon.js ... 3D 物理エンジン

初めて使うもの

Audio API ... BGM や効果音の再生

今回は遊べる Web ゲームを短期間で作ることが目的だったので冒険をしない制約を設けましたが、完成度が低くても未知なる技術を沢山学びたいならどんどん新しい技術を使ってみたらよいと思います。

目的次第でやり方を臨機応変にすることが大事なのかなと😎

(4) こだわりたい部分を絞り他を捨てる覚悟を持つ

こだわりが強いと味のあるイイものができるけど、その代わり完成が遅くなる傾向にあると思います。

今回は『ローポリキャラ達が物理演算で予想外の挙動をする』部分だけこだわりましたが、操作 UI の見た目などはブラウザ標準のプログレスバーを使っていたりと大部分はかなり適当です。

個人的にはゲームの中にブラウザの DOM を混ぜることに違和感とアレルギーを感じるのですが『こだわる部分を絞って他は適当』と大胆に割り切っちゃいました。

他にも、ペンギン/サメ/コイン/木の当たり判定はすべて立方体(正六面体)で手抜きをしましたが、これは予想に反して『サメさんやコインが地面に刺さってる』ように見えたり『木々があらぶってる』感じになったりヘンテコな世界観の演出に一役買ったように思います。

4⃣ おまけ: 実装 Tips

唐突なおまけの実装 Tips です。

(1) Cannon.js / サメさんの Z 位置(奥行)を固定

Cannon.js は 3 次元物理演算なので XYZ 軸分の動きがあるのですが、サメさん(敵)に関しては奥行方向に動かれると攻撃を当てられなくなるので Z 軸を固定しています。

// CannonJs: サメさんの物理演算用の剛体を生成
const sharkBody = new CANNON.Body({ ＜省略＞ });

// ThreeJs: アニメーションループを開始
renderer.setAnimationLoop(() => {
    // CannonJs: 1フレーム分の物理演算を実行
    world.step(＜省略＞);

    // ★★ サメさんのZ位置を固定する ★★
    sharkBody.position.set(
        sharkBody.position.x,
        sharkBody.position.y,
        0); // Z軸を0に変更
});

(2) Cannon.js / 摩擦設定・反発設定

初期値だとほとんど滑ることは無く、滑らせた方が面白そうだったので摩擦と反発の設定をいじっています。

モデルごとに摩擦係数や反発係数を設定できれば直感的だったのですが、Cannon.js では『モデル１とモデル２に対しての摩擦・反発を設定』といった具合に設定が必要でした。

// 
// 物理演算ワールドを初期化
// 

const world = new CANNON.World();
world.gravity.set(0, -9.82, 0); // m/s²

const floorBodyMaterial = new CANNON.Material(`FloorModel`);
const penguinBodyMaterial = new CANNON.Material(`PenguinModel`);
const sharkBodyMaterial = new CANNON.Material(`SharkModel`);

// 摩擦反発設定: 床とペンギン
world.addContactMaterial(new CANNON.ContactMaterial(
    floorBodyMaterial,
    penguinBodyMaterial,
    {
        friction: 0.01, // 摩擦設定 (ペンギンが床を滑るように)
        restitution: 0.8, // 反発設定
    }
));

// 摩擦反発設定: 床とサメ
world.addContactMaterial(new CANNON.ContactMaterial(
    floorBodyMaterial,
    sharkBodyMaterial,
    {
        friction: 0.05, // 摩擦設定
        restitution: 0.3, // 反発設定
        contactEquationStiffness: 1e8,
        contactEquationRelaxation: 3,
    }
));

// 摩擦反発設定: ペンギンとサメ
world.addContactMaterial(new CANNON.ContactMaterial(
    penguinBodyMaterial,
    sharkBodyMaterial,
    {
        friction: 0.01, // 摩擦設定
        restitution: 2.0, // 反発設定 (攻撃を受けたサメが吹っ飛びやすいように)
    }
));

(3) Three.js / 同じモデルは使いまわして効率化

今回ゲーム内では同じモデルが大量に出現します。その際に毎回モデルをロードしていると実行効率が悪いので、モデル管理クラスが必要になります。

こういった目的の管理クラス系にはシングルトン実装が最適かと思いますが、TypeScript では module を使うと簡単にシングルトン実装が可能です。

/** モデル名の型定義 */
export type ModelName = `PENGUIN` | `SHARK` | `TREE` | `COIN`;

/** 
 * ゲーム内のモデルを管理するモジュール
 *　 シングルトン実装
 * 　モデルをあらかじめロードして、ロード済みのモデルを使いまわすことで効率化
 */
export module ModelManager {
    /** ロード済みのモデルを保持 */
    const modelMap = new Map();

    /** 各種モデルをロードする */
    export async function load() {
        await loadModel(`PENGUIN`, `models/PenguinJumping.glb`);
        await loadModel(`SHARK`, `models/Shark.glb`);
        await loadModel(`TREE`, `models/Tree.glb`);
        await loadModel(`COIN`, `models/Coin.glb`);
    }

    /** モデルを複製して取得する */
    export function getModel(modelName: ModelName) {
        return modelMap.get(modelName)!.clone();
    }

    /** ロード済みモデルを開放する */
    export function dispose() {
        // ThreeJs: ロードしたモデルをすべて解放
        modelMap.forEach((obj3D, key) => {
            GameUtils.disposeObject3D(obj3D);
        });
    }

    async function loadModel(modelName: ModelName, path: string) {
        // ThreeJs: モデル読み込み
        const obj3D = await GameUtils.loadGltfModel(path);

        // リストに追加
        modelMap.set(modelName, obj3D);
    }
}

使い方

// あらかじめすべてのモデルをロードする
await ModelManager.load();

// ペンギンモデルを取得する (内部的にはロード済みのモデルを複製しているので効率的)
const penguin1 = ModelManager.getModel(`PENGUIN`);
const penguin2 = ModelManager.getModel(`PENGUIN`);
const penguin3 = ModelManager.getModel(`PENGUIN`);

最後に

ゲーム開発中に Twitter でいいねやコメントなどでリアクションをくれた方、開発中のゲームを試してヒントをくれた友人方、本当にありがとうございました。
大変励みになりモチベーションになりました、重ねてお礼申し上げます😆

あと、ここまで読んでまだプレイしていない人！！
↓ やってからリアクションをクレクレ厨😗

ペンギンがサメさんを倒すゲーム
敵さんを吹っ飛ばして 1,000 G 以上を目指してみてね😆
https://games.westa.io/

P.S. crieit.net で初カノニカル投稿してみました🎉これ書く側としてはイイ仕組みですね

有料のWebサービスをリリースするまでに取り組んだこと・知見をまとめました【個人開発】

2020-05-17T06:58:19+09:00

1. 作ったサービス

ツイ消し職人 | ツイ消しツールの決定版！
https://twikeshi.net/

ツイ消しツールの決定版！
ツイ消し職人は今までのツイートを全消しできる「ツイート一括削除ツール」です。
3200件を超える大量のツイートを全て削除できます。
無料のツールなどでうまく削除できなかった方は是非ご利用ください。
既存のフォロワーをそのままに、Twitterをやり直すことができます。

2. 自己紹介

こんにちは、ひろと申します。
現在はフリーランスエンジニアとして活動しています。

3. なぜ作ったのか

私は2020年4月にフリーランスとして独立しました。
それに伴い、学生時代から使っていたTwitterアカウントの運用を変えようと思い、今までのツイートを削除してやり直すことにしました。
アカウントを作り直す選択肢もあったのですが、フォロワーを減らしたくなかったため、ツイ消しの道を選びました。
調べてみるとツイートの一括削除ツールがいくつか見つかったため、それを使ってツイ消しをすることにしました。

しかし、既存のツールではツイートの削除ができませんでした。
私の今までのツイート数は19万件で、Twitterアーカイブをダウンロードしたところzipファイルのサイズは31GB。
私がツイ廃だったのが全ての原因です。

普通のツイ消しサービスは、API制限の関係で3,200ツイートが削除の上限となってしまいます。私の19万ツイートに対してはあまりに無力すぎました。

もちろん、API制限を回避するためにTwitterアーカイブをアップロードして削除を行うサービスもあります。
しかし、31GBのzipファイルを送りつけると必ず500エラーが返ってきてしまい、私の試した範囲では、まともに動くものはありませんでした。海外の有料サービスでさえダメでした。(具体的なサービス名は出しませんが、日本円で1,600円払いました。手痛い出費です)

そこで私は、「ツイ廃でもツイートを削除できるサービス」が必要だと思い、ツイ消し職人の開発を始めました。

4. リリースするまでに取り組んだこと

取り組んだ全てのことを記載しています。

一. サービスの命名

最初は「ツイートクリーナー」という名前にしていました。
開発中盤に「ツイ消し職人」という名前を思いつき、変更しました。
ランサーズなどで名前を募集するのも良いと思います。

二. ドメインの取得

ムームードメインでtwikeshi.netを取得しました。
欲しいドメインが埋まっている場合は、twikeshi-app.netのように工夫するのもオススメです。

三. 商標登録

登録しました。
今はToreruなどの便利なサービスがあり、ものすごく簡単に出願できます。
48,000円で5年間有効になります。
商標権の取る取らないを選択するのは自由ですが、後から商標を第三者に取得されて商標権の侵害警告を受けた場合、サービス名やドメインを変えなければならないリスクがあることは認識しておく必要があります。

四. プライシング

海外の同じようなサービスを参考に値付けを行いました。
現在は700円(税込)で提供しています。

その後、プライシングに関する本を3冊読んで(この本とこの本とこの本)考え方が変わったので、そのうち値上げするかもしれません。

間違っても、本来ターゲットでない人を取り込むために値下げするのはやめてください。
例えば、私は友人達に「ツイ消し職人の適正価格はいくらだと思う？」と質問をすると、2人が「100円」と答えました。
しかし、断言しますが彼らは100円でも絶対に利用しません。何故ならば、彼らはこのツールの価値を理解していないからです。ツイ消しをしようと思ったことがない人に相場感を聞いても意味がありません。
逆に、本っっ当にツイ消しをしたくて困っている人からすれば、このツールが例え1万円でも喜んでお金を払うはずです。

五. 技術選定

1. バックエンド

バックエンドはLaravelで開発しました。
Laravelはコードもドキュメントも読みやすいため、使っていて楽しいですね。

役割	技術
PHPフレームワーク	Laravel
データベース	MySQL
Twitterログイン	Laravel Socialite
Twitter APIライブラリ	TwitterOAuth
メール送信	SendGrid

2. フロントエンド

CSSフレームワークにはMaterializeを採用しました。初めて使ったのですが、ドキュメントが分かりやすく情報量も多いのでオススメです。
今回はフロントで処理をする必要が無かったので、基本的にJavaScriptは使っていません。ファイルアップロードの画面は、アニメーションを付けるためにVue.jsを使いました。Vue.jsは以前から使っていたので、特に困ることはありませんでした。
次はNuxt.jsに挑戦するために勉強中です。

役割	技術
CSSフレームワーク	Materialize
JavaScriptフレームワーク	Vue.js
決済	Stripe Checkout

3. インフラ

サーバーにはレンタルサーバーを採用しています。

役割	技術
レンタルサーバー	エックスサーバー

Heroku / VPS / AWS EC2 / GCP App Engineなどの選択肢もありましたが、主にコストと運用の観点から除外しました。個人開発は自分でインフラを選べるのが良いですね。
今後もどんどんサービスを作っていく予定なので、サーバー費がかさむのはイヤだし、サービスを作る度に環境を構築するのも避けたかったのです。

もちろん要件によってはレンタルサーバーが使えない場合もあります(ミドルウェアの設定変更や追加インストールが必要な場合など)。

例えば、FFmpegを使って動画のエンコード等を行う場合です。
まずrootが使えないのでインストールができません。自前でmakeして無理やり手動インストールすることも不可能ではなさそうですが、なるべく避けたいところです。また、動画のエンコード処理はCPUを食うので、運営に利用を停止される可能性があります。

このようにrootユーザーが使えないと困る場合は、状況に応じて各サービスを比較検討しましょう。
サーバーはHerokuだけどストレージにはS3を使って、DBにはCloud SQLを使うといったトリッキーなこともできます。柔軟な発想で最適な構成を作りましょう。

参考に、私の考える主なインフラサービスのメリット・デメリットをまとめておきます。
※App Engineは詳しくないので簡易的な記載になってます

インフラサービス	メリット	デメリット
VPS(IaaS)	・安い・root使える	・借りる度にお金がかさむ・環境構築や設定が必要
EC2(IaaS)	・root使える・マイクロサービス沢山ある	・高い・借りる度にお金がかさむ・環境構築や設定が必要
App Engine(PaaS)	・環境構築不要	・高い・借りる度にお金がかさむ
Heroku(PaaS)	・安い・環境構築不要	・借りる度にお金がかさむ・30秒タイムアウト辛い
レンタルサーバー(ほぼPaaS)	・安い・1台でアプリ沢山動かせる・環境構築ほぼ不要	・root使えない

六. 設計

小規模なサービスなので、ここにはほぼ時間をかけていません。
ワイヤーフレームなどは作らず、実際に画面をコーディングしてレイアウトを決めました。
DB設計もパパッと考えて終わり。
開発の中で必要になったときに都度、テーブルやカラム・画面を増やしていきました。
サービスによっては色々な機能を思いつくと思いますが、まずはスモールスタートでリリースすることをゴールにしましょう。

七. 開発

一番時間をかけたのはこの工程です。
他の仕事が並行していたため正確ではありませんが、全体で2〜3週間はかかったと思います。
伝えたい情報がある場合はコメントを書いています。
有料サービスのみ必要になる項目には「☆」を付けています。

1. サービスの機能開発

一. Twitterログイン

ツイ消し職人では、決済完了時とツイート削除完了時に確認メールを送信しています。
そのため、Twitter AppのAdditional permissionsとして、Request email addressにチェックを入れています。

二. ☆決済

Stripe Checkoutは神。
JavaScriptをちょろっと書くだけで決済を提供できます。返金もボタンポチるだけです。
週次で売上を銀行口座に入金してくれるところも良いですね。至れり尽くせり。
ツイ消し職人はクレジットカード、Google Pay、Apple Payに対応しています。

三. アーカイブアップロード

Twitterが生成したデータを読み取らないといけないので、アーカイブのどのファイルに何の情報があるのかを全て自分で調べました。
そして、ツイートの削除に本当に必要なファイルだけをアップロードさせることで、ファイルサイズを31GB→200MBまで減らすことができました。

アーカイブからはツイートの削除に必要な情報を正規表現で抽出する必要があります。
最初は、JavaScriptを使いフロント側で情報を抽出し、サーバーには最低限のデータだけ送るようにする予定だったのですが、少し時間がかかりそうだったので諦めました。

FileReader.readAsText()に100MBのファイルを食わせるとクラッシュしてしまうことが判明し、ファイルをチャンクして処理する必要が出てきたためです。
コンソールにエラーは出力されず、サイレントでクラッシュするので問題の特定に時間がかかりました。
サーバ側で抽出処理をやっても特に問題はないので、サーバ側で処理するようにしました。

四. ツイート削除

ノーコメント

五. 非同期処理

アップロードされてそのままツイートの削除を行うと、画面がタイムアウトしてしまいます。
そのため削除処理はLaravelのキューを使って非同期にしています。
失敗時の再実行もできるようになるので便利ですね。

六. メール送信

必ずユーザーに到達するようにSendGridを使っています。
返信や問い合わせを受けるためにはメールサーバーの設定が必要なので注意してください。
サーバーが用意できない場合は、G Suiteなどのホスティングサービスを利用しましょう。

七. ログ出力 + Slack通知

本番での例外発生時にはSlackにスタックトレースを飛ばすようにしています。
他にも、ツイート削除処理成功時など、正常系でも重要なものはSlackに通知を飛ばしてます。

ログは、出せる項目をなるべく出すようにしています。
Laravelのログ出力について記事書いてるので興味あったら読んでください↓
【Laravel】ログのフォーマットを変更してIPアドレスやユーザー名などを出力する

2. リリース準備

一. LP(トップページ)作成

ユーザーに効果的に訴求できる文言を考える必要があります。
デザイナーの人は腕の見せどころだと思います。
文字や画像・アニメーションを使っていい感じのレイアウトにしましょう。

ペライチなどのツールを使っても良いと思います。
コンバージョンに直結するので、一番力を入れるべき部分です。外注も考えましょう。

ツイ消し職人のようなツール系のサービスの場合は、そんなに凝らなくても結構コンバージョンします。

二. 利用規約・プライバシーポリシーの制定

この本が大変参考になりました。コピペできるひな形データも付いてくるのでオススメです。

三. ☆特定商取引法に基づく表示の作成

同上。
有料サービスの場合は必須です。
本名や住所、電話番号を晒さないといけないので、ここが一番の難関ではないでしょうか。
私の場合、IP電話アプリ(SMARTalk)を使い050から始まる電話番号を載せています。

四. Googleアナリティクス・Search Console設定

ノーコメント

五. meta description設定

Googleの検索結果でタイトルとともに出るやつです。
meta keywordは不要です。

六. ファビコン設定

GIMPで作りました。
サービスのロゴがある場合はファビコンにも活かせます。

七. OGP設定

GIMPで作りました。
OGP画像を動的に生成するサービスでは、トップページ用の画像を同じ方法で作るのも良いかも。
CTRに直結するので、ここも外注を検討しましょう。

八. サイトマップ設定

Search Consoleで送信します。
sitemap.xml Editorを使うと簡単に作成できます。
サイトが新しく、外部からのリンクが少ない場合はあったほうが良いみたいです。

九. SNSシェアボタンの設置

↓こういうのです。

ユーザーに拡散してもらえる仕組みを作っておくことは重要です。

十. お問い合わせフォームの設置

自分で作るのがめんどくさい場合は、Googleフォームやformrunなどを活用しましょう。
お問い合わせフォームの代わりに、チャットサポートツールを入れるのもオススメです。

3. リリース

一. デプロイ

Laravel + レンタルサーバーの場合はgit pullすればほぼ終わりです。
あとは.env書いてマイグレーションしてキャッシュ系のコマンドを叩くだけです。
もちろん、GitHub ActionsなどのCIを設定するのも良いと思います。

私の場合は、以下のようなデプロイスクリプトを用意しています。

#!/bin/sh

git pull

composer install --optimize-autoloader --no-dev

php artisan config:cache

php artisan view:cache

php artisan route:cache

二. テスト

本番環境で全ての機能がうまく動くことを確認しました。
中規模〜大規模サービスの場合は、検証環境の用意とテスト自動化がされていないと運用がしんどくなります。

八. リリース後

1. 知り合い・友人への拡散

LINE, Twitter, Facebookなどで拡散して使ってもらいましょう。

2. プレスリリースを出す

お金があればPR TIMESなどの有名サイトに出すのがオススメです。
(もしくは、法人ならスタートアップチャレンジの条件を満たすと無料になります)

私はお金がなかったので、valuepressのフリープランで配信しました。
配信は無料ですが、プレスリリースの内容を修正する場合はお金がかかるので気を付けましょう。
3,200件を超えるツイートを一括削除できるツイ消しサービス「ツイ消し職人」を提供開始

3. アプリ紹介サイトに登録

私の場合、AnyMakeやmakepost、Eggineer、Applishowを活用しています。

4. 新聞の広告枠に出稿する

リリース直後にスポーツ新聞の方から電話があり、新聞とサイトに広告を載せないかと打診がありました。
条件が合わなかったためお断りしましたが、人によっては選択肢になり得ると思います。

5. アフィリエイト広告に出稿する

検討しましたが、結局使いませんでした。
お金がある場合は、A8.netなどの大手ASPを使うのが良いと思います。
マネートラックならば初期費用0円・月額費用0円で始められるようです。

6. SNS広告に出稿する

以前利用していました。
私の場合はTwitterユーザーをターゲットにしたサービスなので、Twitter広告と相性が良いです。
月予算は安めでもかなりコンバージョンに繋がったので、広告費は普通に回収できています。

7. リスティング広告に出稿する

以前利用していました。
Twitter広告よりも予算が必要で効果が薄かったため、すぐにやめました。

8. 保守開発

本番環境でのエラーを監視し、新しく発現したバグがあれば修正しましょう。
手元で再現しないエラーは...ユーザー問い合わせを待つしか無い。。

もちろん、機能追加などサービス改善のための開発は怠らないようにしましょう。
大幅リニューアルや作り直しなどの選択肢もあります。

9. ブログなどでの発信

この記事のことですね。
Qiita, Crieit, Zenn, Note, ブログなどの選択肢があります。
サービスを知ってもらうだけでなく、転職活動などでも役に立ちます。

Noteに記事を投稿しているのでこちらも参考にしてください。
たった2週間で作ったWebサービスで月11万円の売上を達成した話

サービスの閉鎖の仕方

2020-04-28T20:39:30+09:00

今日（2020/4/28）サービスを一つ閉鎖しました。記念に残しておいても良かったのですが、GCPの無料クレジットが終わるため、残すのであれば無料運用できるよう構成を変更する作業が必要で面倒だったのと、ユーザーデータを色々扱っているサービスだったのであまり放置しておきたくないなというのがあり削除することにしました。

閉鎖にあたって色々と手順があると思いますので解説していきたいと思います。

と言いつつメインで伝えたいことはこれ一つだけです。

スクショを撮ろう

スクショは記念に撮っておきましょう。

スクショを残しておかないと、将来「こんなサービスを作ってたんだ～」と何かポートフォリオ的なものを残したりする時や、サービス供養サービスなどが現れた時に画像と一緒に登録できず困ることがあります。

ですので適当に主要なページのスクショを取り、プロジェクトにscreenshotsフォルダを作ってそこに入れてコミットしてGitHubに保存しておきましょう。プライベートな情報を過去にcommitしたことが無いのであればpublicにしてポートフォリオ的に残しておいてもよいでしょう。

以上で終わりですが、一応他の作業も話しておきます。

ユーザーに連絡

普段から使っているユーザーがいるのであれば事前に連絡しましょう。特に課金機能がある場合は急に閉鎖するとトラブルにもなります。何ヶ月か前から課金機能終了機能の連絡をしておきましょう。

今回のように誰も使っていないサービスであれば急に削除しても問題ないと思います。とは言え、削除したあとに「あれつかってたのに…！」と言われたこともありました。逆にユーザー視点で、消えてほしくないサービスが有るのであればその旨を普段から開発者に伝えておくと良いでしょう。声を出さないと思いは一切伝わりませんので誰も使っていないと思われているでしょう。

アカウントを削除しよう

公式アカウントや認証用などのために専用のTwitterアカウントを作っていたり、プロジェクト用にAWSやGCPの専用アカウントを作っていた場合には削除しましょう。

Twitterは電話番号の利用回数を消費してしまうため残しておくともったいないですし、各プラットフォームのアカウントも残しておくといつの間にか課金が発生したりしまうこともあります。まとめて全て削除してしまうと安心です。

使っているサービスを削除しよう

自分のアカウントにプロジェクトを作って運用していたりする場合には、アカウントをまるごと消せない場合もあると思います。その場合は一つずつ削除していきましょう。

GCP等の場合はプロジェクトをまるまる削除してしまうのも楽です。それ以外は一つずつ削除していきましょう。

Webサーバー
データベースサーバー
ロードバランサー

クラウドのWebサーバーの場合、固定IPを利用しているのに、サーバーだけ削除するとIPの保有料金だけが発生している場合もあります。そちらも忘れず削除しましょう。

データのバックアップなども必要であればやっておきましょう。

独自ドメインを削除

これも意外と忘れやすいかもしれません。自動更新にしていると使ってもないのに更新されてしまったりします。自動更新を解除しておきましょう。

レアなドメインの場合は売ってもいいと思います。

Gmail、Chromeのユーザーを削除

僕の場合はサービスごとにChromeのユーザーを作って利用しています。

ログインやブックマークも全部独自にできるので便利です。削除するときもこのユーザーを削除すればまるまる関連している全てを削除できます。

また、これに合わせて事前にGoogleアカウントも削除しています。

解析とか

Google Analytics, Search Consoleのプロパティ、Firebaseのプロジェクトなど。登録数制限があるものは削除したほうが良さそうではありますが、残していて支障が出るものでもないので、邪魔でなければ足りなくなった時に削除でも良い気はします。

AdSenseはしばらくこのサイトが使われていませんとか小言を言ってくるので先に削除しておきました。

次のサービスを作る

余裕ができたらやっていきましょう……！！