「アプリ開発」の記事 - Crieit

【個人開発】アイデア出しから公開・プロモーションまでまとめ(Nuxt3、Cloudflare、GooglePlay)

2023-07-29T05:35:55+09:00

1. はじめに

個人開発の大体の流れがつかめるように、アイデア出しから公開・プロモーションまでをまとめました。

1-1. 作ったアプリ

About	List	History

	基本操作
① リスト作成 ② 買い物完了でチェック ③ チェック済みを削除 ※これらの手順だけで簡単操作

『買い物リスト・メモ - Lisble リスブル』

iOS,PC	Android

iOS,PCの方は、PWAの為、メニューから｢ホーム画面に追加｣をお願いします。	このアプリは Google Play で入手できます。

2. 0から公開までの流れ

2-1. アイデア

1番大事だけど一番頭を悩ませました。
新しいものか、既存のサービスでの差別化の二択で、はじめてということで後者にしてしまいました。
これからもアンテナをはって次につなげたいです。

アイデアの出し方
* とにかく紙に書く
* 不満・面倒・悩み・困っていること
* 人間観察(周りの人)・他業種の業務課題
* 真似 → シンプル化・別分野へ応用・既存のサービスの不満解消
* 海外のサービス調査
* ニッチ・マニアック(自分の強み・趣味)
* 合体・逆

既存のサービスの発展系か、何かの組み合わせか
思いついたらメモ 📝

参考サイト
アプリ開発でアイデアが浮かばないあなたへ。独創的なアイデアの出し方
 ポートフォリオや個人開発で使えそうなアイデア

2-2. 要件定義

①要件(こうだったらいいな)
* 出来る、出来ないを考えずあげていく

②要件の為の機能
* ここで出来る、出来ないを考える
* 最低限必要な機能を絞る
* 実装方法が思いつかない機能は省略

出先で「あれあったかな❓」を解決したい → 買い物履歴を残して最近買ったものをわかるようにする機能
在庫の把握・重複購入を減らしたい → 買い物履歴から同じ単語入力時に色の変化で知らせる → 入力中に知らせることにより在庫を思い出すきっかけにもなる
etc...

③出来ればマネタイズも考える
1. 広告：アフィリエイト､AdSense(web)､AdMob(アプリ)
2. 課金：広告削除､追加コンテンツ､アイテム
3. 寄付
4. 有料：買い切り
5. サブスク：月額制

とにかく一連の流れを経験したく、マネタイズまでの道のりが見えたのが本アプリ案で、結果Amazonアソシエイト､AdSenseになりました。
AdSenseは受かりませんでした。継続して挑戦します。

④利用技術
🔑 ログイン・ユーザー登録無し、、広告も可でとにかくお金をかけずにを優先して、SPAで制作することにしました。
- GooglePlay Developer 申請・登録25ドル(当時3,352円)
- 独自ドメイン Xserverドメイン初年度のみ1円
- 更新、移管はCloudflare予定

アイデア・デザイン
Xmind(マインドマッピング)
Figma
コード
Nuxt3(Composition API)・TypeScript・Tailwind CSS
インフラ
Cloudflare
開発環境
VSCode・Git、GitHub

参考サイト
【5ステップ】初めてのオリジナルアプリの作り方！アイデアの出し方も公開

2-3. 設計

①画面設計
1. 必要なﾍﾟｰｼﾞ列挙 ➡ 階層・整理
2. ワイヤーフレーム(紙手書き)下書き
3. ワイヤーフレーム(figma)清書

参考サイト
ワイヤーフレーム(画面設計)の作り方
 Web画面設計の手順と重要なポイント

デザインの４原則
1. ｢近接｣：関連する要素をグループ化
2. ｢整列｣：関連する要素を見えない線で整列
3. ｢反復｣：要素の一貫性、デザインの統一
4. ｢対比｣：要素の優先度を強弱で示す

参考サイト
お役立ち知識：デザインの4原則 - デザインパートナー

②データ設計(構造)
* データの設計図

2-4. 開発

設計通りに作る
最低限の機能
制作途中で機能の追加案を我慢して、とにかく完成させることに集中する(追加の機能を制作してしまいました。なのでここに残しておきます。)

①工夫した機能
- 並べ替え(D&D)・スワイプ機能をライブラリ(Vue.Draggableは､思うような機能にならなかった)を使用せずに作成
- ↳シンプル化のため､同じ発火点で､参考サイト様(Trello風タスク並び替えドラッグ&ドロップクローン(Vue.js利用))を参考に､【マウス、タッチ、処理回数削減、d&dとswipeの融合、グループ間並べ替え、d&d中の上下の画面端scroll】ロジックを考え自作しました。

並び替え機能	スワイプ

	←色 →削除※ﾀｯﾁﾃﾞﾊﾞｲｽのみ

スマホとPCの挙動の違いなど(ENTER､終了時の処理...)
日本､世界の日時の表示形式(履歴)
Amazonアソシエイトの各国の設定(OneLink)
アニメーション(数字のドラムロール、追加削除時...)etc...

②多言語化(i18n)
@intlify/nuxt3使用
日/英で単語の長さの違いによる表示崩れに注意

未解決問題
日本語で検索時、検索結果が英語サイトのtitleとdescriptionになってしまう問題(同じURLで日/英にしたい)

確認
meta tagの設定(title、description等)日/英切替時にきちんと切り替わっている。

↓ためしたこと↓
- Nuxt.jsのi18n多言語対応したら、日本語で検索した時の検索結果が英語になってしまった。解決できたので対応方法を記載します。
- @intlify/nuxt3 で detectBrowserLanguage: false,にあたる設定がない??
- sitemapの設定 (hreflang属性)
- Google Search Consoleに日/英を認識させる方法??...
- (2023年7月) Nuxt3での多言語化はまだ開発中らしいので情報待ち🍥 → intlify/nuxt3: Nuxt 3 Module for vue-i18n-next

③プライバシーポリシー
参考サイト
プライバシーポリシーとは何か？必要性、記載事項をわかりやすく解説

④テスト
- 個人情報を扱っているなら､徹底的に安全確認
- 例外処理

2-5. 公開

①(SPA SSG) 静的ファイルホスティングサービス【無料】
1. GitHub Pages
2. Firebase Hosting
3. Netlify
4. Vercel
5. Cloudflare Pages

無料プランの枠・サイトのパフォーマンス・商用利用可でCloudflare Pages

参考サイト
Cloudflare Pages・Vercel ・Netlify の違いや使い分けをまとめる
 NetlifyからCloudflare Pagesに引っ越しました

②Google Play Store 配信方法
PWA → TWA
* TWA変換ツール「Bubblewrap CLI」使用
* Lighthouse で 80 以上のパフォーマンススコアが必要(↓に記述)

参考サイト
信頼できるWebアクティビティ
 【TWA】完全開発ガイド＝超簡単にPWAをPlay Storeで配信しよう
 PWA対応サイトをAndroid APK（AAB）に変換する

③Lighthouse のパフォーマンス改善(リファクタリング)
- cssの最適化 → 読み込み順､削除､animation(transform,opacity...)etc...
- googleFonts, Analytics → GTM使用､読み込むタイミング､読み込み方､文字の限定etc...
- 【2022年3月】Google Fontsのパフォーマンス比較＆ハリー・ロバーツ方式の勝手に改良版
- Google Fontsを簡単にサブセット化する方法
- Web Worker → 並列処理 Web Workerの使い方
- requestAnimationFrame() → 「60fps」 requestAnimationFrame の使い方
etc...

Mobile :arrow_down:

Desktop :arrow_down:

2-6. リリース後

①掲載用スクリーンショット、画像作成
* figma制作
* サイトにより、サイズ、比率、枚数、が異なる

②登録サイトに投稿/掲載依頼
当たって砕けろ、チャレンジ精神で色々掲載依頼を出してみた結果です。
個人開発者に告ぐ！「告知＝恥ずかしい」を脱却しよう～実例データから重要性を解説

登録or掲載 → 🎉
メール・問い合わせ反応待ち → 📧
更新が止まっているサイトが多い

日本
- Appliv → 🎉 レビュー、とても丁寧な対応 :thumbsup:
- APPLION → 🎉 ランキング
- 放課後ｱﾌﾟﾘ部 →🎉 登録
- Applishow → 🎉 登録
- AppRoom → 🎉 登録 アプリ記事掲載
- SeekUps → 🎉 登録
- ロケットリリース → 🎉 登録
- Appstimes → 🎉 登録
- AnyMake → 🎉 登録
- makepost → 🎉 登録
- MITSUKARU! → 🎉 登録
- DevHaunt! →🎉 登録、とても丁寧な対応 👍
- 個人dev → 🎉 登録
- アプリゲット → ゲームのみ
- AppBank → 📧
- Applision → 📧
- ツクログ → 📧 クリエイター登録済み､まだ作品は掲載されない(2度投稿)
- octoba → 📧
- NewLaun-ch → 📧
- appllio → 📧
- appnavi → 📧
- Androライオン → 📧条件:レビュー
- AndroRank → 📧条件:レビュー
- Androidアップス → 📧
- Androidコレクション → 📧
- マイナビニュース → 📧
- ITmedia → 📧
- ITmedia ねとらぼ → 📧
- AndRock → 📧
- AppVIP → 📧
- AppLink → 📧
- GAPSIS → 📧

海外

Product Hunt → 🎉 登録から１週間待つ必要がある
AlternativeTo → 🎉 登録
app store apps → 📧
AppCraver → 📧
arttechnica → 📧
Apps Review → 📧
community → 📧
App Log → 📧
Get Android Stuff → 📧
Android Guys → 📧
androlib → 📧
APKMirror → 📧
PCMag → 📧
NEWSREPORTS → 📧
iFanzine → 📧

※上記以外で無料で宣伝できるサイト、方法があれば教えていただけると嬉しいです。

③記事を書く
- Qiita
- 【Nuxt3】はじめての個人開発「買い物リストアプリ」開発記録
- Zenn
- Nuxt3で初めての個人開発記録【買い物リストアプリ】
- Crieit
- シンプルな買い物リストアプリ「lisble リスブル」の紹介
- 【個人開発】アイデア出しから公開・プロモーションまでまとめ(Nuxt3、Cloudflare、GooglePlay)
- note
- 値上げ対策！買い物リスト作成で節約
- シンプルな買い物リストアプリ「Lisble リスブル」のご紹介
- Medium(英語記事)
- Price increase measures! Save money by making a shopping list

④Twitter(日本語/英語)
- Twitter日本語ver.：@arieight_8
- Twitter英語ver.：@Lisble_en
- 登録or掲載 → つぶやく
- 機能一覧、設定一覧、動画(gif)でツイート
- 開発中からつぶやいた方が良い

参考サイト
個人開発したWebサービスをリリースした後にやったこと / やり続けていること

3. 気付き・反省点・まとめ

開発を0からして、初めてコードをさわって新しい概念にふれた時くらい勉強になり、とても知見が広がり良かったです。
プログラミング以外の作業が初だったので「プログラミング：他＝ 3：7」くらいの感覚でした。様々なデザインが予想より大変でした。
一番面白いと感じた作業は、ロジックを考えて形になった時でした。
アイデア → 紙やXMindに思いつく限りまとめたのですが、総合的な判断で結局既存のサービスに追加機能の方向になってしまいました。マネタイズまで含めたアイデアが難しいです。どうせやるなら一通りやってみたかったので次回以降にしました。常にアンテナをはって知見を広げていいこうと思いました。
要件定義 → 運用費がかからない、個人情報は扱わない、AdSense以外のマネタイズまで考える､などを考慮してアイデアを絞り、考え、すでにあるサービスと見比べ、アイデアと要件定義をぐるぐるしていました。
AdSenseは、コンテンツ不足でwebアプリは受かりづらいらしいです。
利用技術 → 平凡なアイデアだったので初めて挑戦する技術(Nuxt3､TypeScript､etc...)を使用してしまいました。
デプロイ先など、お金をかけずに運用していくための他の効率の良い方法やサービスを引き続き調査していきます。(Firebaseをﾃﾞｰﾀﾍﾞｰｽ等)
設計 → 画面デザインは、UI足したら引き算・データ設計は構造整理
開発 → 追加の機能を制作してしまいました。最低限の機能でまず完成を目指すべき
工夫した機能 → ToDoの変化型アプリで平凡なアプリで非常に多く数があるため、機能にこだわりました。
多言語化して作業が増えた。[Amazon設定､時間形式､表示崩れ､metaタグ､etc...]
テスト → 多視点が重要
公開 → 運用費をかけないにこだわる
パフォーマンス改善 → 良い学習
マネタイズ → Amazonまでの導線が弱い要検討
著作権・プライバシーポリシー・DDoS対策etc...
プロモーション → Twitterは開発中から・アイデア段階でSNSを考慮したサービス・地道にor金をかけるか・個人の場合限られるので勉強段階からブログや記事など書いておけばまた違ったかも
「告知＝恥ずかしい」があったので、経験せずにはわからないからできることは全部しようと思いました。

作る前に想像していたよりコード以外の作業が多いとうことに改めて気付かされました。
制作中、何度も宇宙兄弟のセリフが脳内再生してました。ありがとうございました。

「また積めばいいよ」
「次はもっと上手く積めるようになってるよ」

出典: 『宇宙兄弟』17巻小山宙哉（講談社、2012年3月23日第1発行）

購入履歴が残せるシンプルな買い物リストアプリ 『買い物リスト - Lisble リスブル』 です。メモ、ToDoアプリとしても機能します。
購入履歴の保存機能により、無駄な重複購入を防ぎ、在庫の備忘録にもなります。
ログイン・ユーザー登録不要、無料ですぐにご利用いただけます。
もしよかったら、触ってみてください。

『買い物リスト・メモ - Lisble リスブル』

iOS,PC	Android

iOS,PCの方は、PWAの為、メニューから｢ホーム画面に追加｣をお願いします。	このアプリは Google Play で入手できます。

Twitter:＠arieight_8

Google Play および Google Play ロゴは、Google LLC の商標です。

自作アプリをバズらせるために８年間やったこと

2023-07-05T08:29:04+09:00

モーショングラフィックスアプリ9VAeをはやらせようと８年間実施したことをまとめました。
https://qiita.com/danjiro/items/3004b6993d3e93e0d3fb

Android 虎の巻　API31対応するための修正

2022-03-07T14:42:49+09:00

上のようなアニメがつくれるフリーソフト9VAeきゅうべえを開発してます。
現在、Googleアプリストアに登録するには、Android API30 以上が必要ですが、次のバージョンに対応するために、AndroidStudio の build.gradle(Module:) を、31 に変更すると、ビルドエラーがでます。

android {
    compileSdkVersion 31 <--30 から 31に変更
    defaultConfig {
        minSdkVersion 24
        targetSdkVersion 31 <--30 から 31に変更
        versionCode xxx
        versionName "x.x"
     }
}

AndroidManifest.xml に「android:exported="true"」を追加するとビルドできるようになるみたいです。

Dartを使った大規模なアプリ開発

2022-01-20T19:00:13+09:00

こんにちは、Quireです。

Quireは、Dartで開発された初めてのWebアプリケーションではありませんが、クライアントとサーバーの両方でDartをふんだんに使ったものとしては、初めてかもしれません。

動作の軽い、徹底して階層構造のタスク管理ツールです。このプロジェクトはDartコードで合計53992行、1620 KB。コミュニティーからのオープンソースライブラリも使っています。

私たちについて

このプロジェクトを開始するまで、私たちはRikuloというDartファンの集まりでした。Rikuloはこれまで、UIフレームワークやUIライブラリ、Webサーバー、メッセージサーバー、DBクライアントなどのDartライブラリをリリースしています。
Dartが2011年に初めてリリースされたとき、すぐに将来性を感じ、さっそく小規模のプロジェクトに着手。その後、ほとんどDartで書かれた大規模アプリの開発へと進みました。今回はそのときの経験をお話しします。Dartによる開発に興味を持っていただければ幸いです。

なぜDartか

私たちがDartを選んだ理由はたくさんありますが、以下に大きなものを挙げてみます。
- 強く型付けされていて、無数の小さなミスを防ぐことができる。公式IDEのDart Editorは、タイプミスへの即時フィードバックやオートコンプリート機能を備えており、トラッキングも容易。
- 継承がクラスベースで、プロトタイプベースよりも直感的に使える。
- クライアントとサーバーの両方で同じ言語が使えて、データモデルやコードベースを共有できる。
- JavaScriptの問題点をほぼ解消。完全ではないが、以前にあった問題の99％には対応している。
- JavaScript Harmonyで人気の特徴をいくつか備えている。例えばFuture（Promise）パターン、矢印関数など。
- 強力なチームの後ろ盾があり、ハイクオリティーな公式ライブラリや使いやすいAPIを利用できる。まだ開発途上ながら、仕様はすでにかなり安定している。
- サーバーサイドではマルチスレッドではなくイベントループ方式で、好みだった。
- JavaScriptへのコンパイル時にTree Shakingできる（下記参照）。

もちろんデメリットもあります。以下に挙げてみます。

コミュニティーがJavaScriptよりも圧倒的に小さい。
DartとJavaScript間の通信が自明でない。
強い型付けなので、APIのPolyfillが面倒。
Dart Editorの性能が（今のところ）大規模プロジェクトに適さない。

強い型のサポートにより、書くプロセスがJavaScriptよりもずっとロバストです。また、Javaよりもシンプルで、Vanilla JavaScriptと比べてもシンプルなことがあります（関数の書き方など）。全体的にDartは扱いやすい言語ですが、以下のような例外はあります。

コンストラクタのボディよりも先にイニシャライザでFinalフィールドを初期化する必要がある。
ミックスインの仕様が使いにくく、2.0まで改善されそうにない。
ジェネリック型パラメータがクラスにしかなく、関数宣言にない。（そのためコンパイラの負荷が増す）。

クライアントサイド

Dart VMがChromeに統合される日まで、JavaScriptにコンパイルして作成することになります。JavaScriptにコンパイルする言語はたくさんありますが、Dartには以下のような独自のメリットがあります。

私たちは開発時、Dart VMを内蔵したChromiumベースのブラウザー、DartiumでDartをネイティブに実行している。このイテレーションではコンパイルが不要で、スムーズに進めることができる。
テストとプロダクションの段階でJavaScriptにコンパイルし、すべてのメジャーなブラウザーで実行する。このとき使用するコンパイラがTree Shakingを行い、不要なコードを除去するため、JavaScriptのコードサイズを小さくできる。

サーバーサイド

サーバーサイドについてはあまりコミュニティーで話題になりませんが、私たちは以下の理由から、Dartはサーバーサイドのプログラミング言語に入ると考えています。

Webサービスは本質的に非同期なため、イベントループ方式と相性がいい（マルチスレッドと比べて）。
クライアントサイドよりもサーバーサイドのほうが、よりロバストで安全なコードが必要。強い型付けの言語はこの点において有利。

サポートライブラリ

Quireは約30のライブラリをインポートしています。そのうち10ライブラリはコミュニティーからで、残りはDartからリリースされたものです。Dartに詳しい方ならAngularDARTとPolymer.dartがあると思うかもしれませんが、実はどちらも使っていません。

AngularDARTを使わない理由は、以下のとおりです。

DOMを細かく制御したい。
私たちはクライアント構造の構築に独自のアーキテクチャガイドラインを使用しており、そのパラダイムがAngularのロジックと異なる。
AngularDARTについて調べたとき、コンパイルされたJavaScriptのコードサイズにかなりのオーバーヘッドが生じた。ただし、これはその後かなり改善された。

私たちは以下の理由から、Polymer.dartも使っていません。

カプセル化とイベントリターゲティングのため、ShadowDOMはBootstrapのようなセレクター指向のフレームワークと併用できない。
ShadowDOMの外部からスタイルを適用できない。サードパーティーのコンポーネントセットがPolymerで作成されている場合、ユーザーが見た目や感じを変えることは不可能に近い。(更新：2013年12月時点で、内部のスタイルを外部から変更可能。Shadow DOM 201を参照。)

DQuery＆Bootjack

私たちのクライアントサイドスタックの基盤は、Rikuloリリースのオープンソースプロジェクト、DQueryとBootjackです。
- DQueryはjQueryの一部、特にイベントデリゲートの仕組みの部分をDartに移植したものです。
- BootjackはBootstrap 3の完全な移植で、CSS およびAPIとほぼ同じです。

このようにアプリケーションスタックを構築して、JavaScriptについて知っていること、できることを活用しています。

Stream

私たちのWebサーバーは、Dartのみで書かれ、ルーティング、フィルター、サーバーサイドMVCなどを備えたStreamです。イベントループ方式とシームレスに連携して動作します。リクエストハンドラーも、ノンブロッキングのルーチンをつなげるだけで書くことができ、従来のマルチスレッド方式よりも生産的かつ快適に仕事ができます。私たちは、Webサービスをスケールし、nginxでHTTPSを処理し、Streamにリクエストをデリゲートしたりもしています。このアーキテクチャによりDart VMを個別にSpawn／Despawnでき、サーバーのアップグレードもユーザーの使用を妨げずに実施できます。

終わりに

Dartは使い勝手の良い言語です。この記事がDartコミュニティー成長の一助となることを願っています。最後に、Dartで何ができるか興味のある方は、ぜひQuireを試してみてください。

Flutterベースのモバイル向けタイムラインの作成

2022-01-07T16:19:06+09:00

Quireタイムライン（モバイル向け）の構造を初公開

2018年に初めてFlutterベースのアプリを作ったときは、とても楽しく興奮しました。それから3年経ち、Quireアプリもかなり充実して、従来のモバイル向けプロジェクト管理アプリの域を超えるまでになりました。Quireモバイルアプリの現行バージョンは、階層表示、ボード表示だけでなく、タイムライン表示にも対応しています。

モバイルアプリ向けのタイムライン表示の作成を決めたときは、簡単にできるとは思いませんでした。当時は類似の既成コンポーネントもなかったためですが、驚いたのは、インターネットでタイムライン表示の構造についての情報も見当たらなかったことです。そこで、いちかばちか、自分たちで作ってみることにしました。

Quireモバイルアプリ用のタイムラインでは、以下を計画していました。

横方向への無限日付スクロール
レンダリングオンデマンド（ROD）。ビューポートにあるときのみ実行されるWidgetのState
任意の位置に素早く配置
操作がかんたんで使いやすいインターフェースと、スムーズなユーザーエクスペリエンス

数週間で初期開発が完了し、以下のような構造になりました。

タイムラインペインのコアベース（週、週末のセクションなど）
タスクリスト（階層構造のタスクリスト）
タイムラインペインのビューポートベース双方向リスト
1ペインのみのとき、2ペインにまたがるときの両方に対応した期間の横棒
期間の横棒上の固定ラベル

上図のように、タスクごとにタイムラインペインが割り当てられ、すべてのタイムラインのスクロール位置は互いに同期されます。

インデックスベースのスクロールビュー

Google Flutter Widgetに似たインデックスベースのスクロールビューを作るために、Centerに引数のあるカスタムスクロールビューを使用します。実装すると、任意の位置まで素早くスクロールできるようになります。スクロール中のどの時点でも、各位置とインデックスを表示できます。

イメージ的には、少しスクロールした時点で、新しいCenterの引数でタイムラインをリロードしてビューポートの外に移し、またスクロールするとビューポート内に配置される、という感じです。

タイムラインペイン

タイムラインをスムーズに使えるように、インデックスベースのスクロール表示と似た発想で、横方向にスクロールできるカスタム「無限双方向スクロールビュー」を実現しました。実装すると、タイムラインをなめらかにスクロールできます。

無限双方向スクロールビューには、Flutterの強力なViewportの考え方を活用しました。そして、Backwardリストのインデックスを-1から始まる負の数に変更しました。Index 0に当たる日付が分かるようにフラグも設定して、任意の日付まで素早くスクロールできるようにしました。

Widget forwardList = SliverList(
  delegate: SliverChildBuilderDelegate((BuildContext context, int index) {
    return cellBuilder(context, _getIndex(forward: true, index: index));
  })
);

Widget backwardList = SliverList(
  delegate: SliverChildBuilderDelegate((BuildContext context, int index) {
    return cellBuilder(context, _getIndex(forward: false, index: index));
  }),
);

Scrollable(
  viewportBuilder: (BuildContext context, ViewportOffset offset) {
    return Viewport(
      offset: offset,
      center: forwardListKey,
      slivers: [
        backwardList,
        forwardList,
      ]
    );
  },
)

2ペインにまたがるときの問題と解決方法

ビューポートには無限のリスト2つがスクロールされるため、期間の横棒が2つのリストにまたがることもあります。そこで、どちらのリストにも完全に同じ期間の横棒を作成し、ぴったり重ねて、リストがビューポートの外に移動してもリスト内のアンカーが壊れないようにしました。

固定ラベルで解決

モバイル機器の小さい画面ではプロジェクトのどこを見ているかが分かりにくく、使っていると混乱してきます。この問題は、できるだけ多くの情報を提供することで軽減できます。そこで便利なのが固定ラベルです。

最初はとにかくシンプルにするため、スクロールビューのスクロール通知に従って、位置を取得してから配置されたラベルに設定していました。固定ラベルを各タイムラインペインの開始位置に表示するには、期間の横棒の現在位置の計算がベースとなります。

しかし、新しく配置されたラベルは次のフレームまでしか更新されず、スクロールビューと同じ時間枠で同期されないため、ずれて見えてしまいました。

幸いFlutterコミュニティーが、レンダリングレイヤー固定ヘッダーというすばらしい解決方法を教えてくれました。つまりレイアウトのタイミングによる方法です。レンダリングレイヤーにすべてのWidgetをサイズとともに入れるだけでなく、そのピクセルすべてを計算する必要があります。最後にlocalToGlobal関数を、スクロール位置、および2ペインにまたがるときのペイン切り替えに基づいた演算操作と置き換えて、パフォーマンスを向上させました。

始まりはこれから

今は大変な時代ですが、だからこそテクノロジーの分野で貢献したいと考えています。タイムライン表示の作成でまず考えたのは、どうやってFlutterの強力なフレームワークを活用して、ビューコンポーネントを一から作り直すことなく、軽く安定したゴージャスなUIを実現するか、ということでした。

各日付単位はインデックスとして、FlutterのSliverに組み込まれています。ほとんどのものはWidgetレイヤーの高レベルの開発概念に留まり、固定ビューのときのみレンダリングレベルに移動します。

Quireアプリをインストールして、Flutterベースのモバイルアプリを使ってみませんか。Quireタイムラインについて気になることは、コメントを投稿するか、@quire_ioでツイートしてお知らせください！

※転載許可済み: https://zenn.dev/quireteam/articles/2b2c44c3e49fac

モバイルアプリ開発フレームワーク

2021-04-13T16:45:08+09:00

現在、40億人を超えるモバイルユーザーがいるため、モバイルでオーディエンスとつながることができなければ、あなたは存在しません。人々はスマートフォンの使用をとても楽しんでいるので、技術のない日を過ごすために自分自身に挑戦する必要があります。スマートフォンは、電話、テキストメッセージ、メールのチェック、さらには娯楽まで、必要なものをすべて提供できます。そのため、モバイルアプリフレームワークが実現します。
このような陰謀的なアプリケーションの舞台裏には、何千ものモバイルアプリ開発フレームワークがあります。ただし、モバイルアプリをうまく作るには、適切なモバイルアプリ開発フレームワーク、関連技術、プラットフォーム、データベースが不可欠です。とはいうものの、あまりにも多くの選択肢があり、どれかひとつに絞るのはこれまで以上に難しい状況です。そこでこの記事では、iOSとAndroid両方のプラットフォームで最も人気の高いモバイルアプリ開発フレームワークについて説明します。その前に、効率的なモバイルアプリ開発フレームワークとはどのようなものかを簡単に見ていきましょう。

1. React Native
React Nativeは、AndroidアプリとiOSアプリの両方向けに構築された非常に人気のあるフレームワークです。特に、モバイルアプリの開発者は、より短いビルドサイクルでより高速なデプロイ時間で高性能アプリをビルドでき、予算にやさしいオプションです。さらに、React Nativeは、ビュー、テキスト、画像など、プラットフォームに依存しないネイティブコンポーネントのコアセットを提供し、すべてプラットフォームのネイティブUIビルディングブロックにマップされます。また、フルスタックに必須のJavaScriptもサポートしています。

2. Flutter
FlutterはGoogle が作ったオープンソースのネイティブアプリケーション開発フレームワークです。Dart という共通言語で開発を行います。詳しいデバッグができるので React Native で感じる「隔靴掻痒」感は少ないです。
Flutterを使うことで同一のコードベースからAndroidやiOSアプリを構築でき、その見た目もネイティブアプリです。FlutterはGoogleによる導入が2015年でしたが、2018年12月の公式リリースまではベータ段階にとどまっていました。
Flutterのユーザーは、携帯電話、テレビ、タブレット、ウェアラブルデバイス、スマートディスプレイ用のアプリを作成できます。
ちなみに Flutter Studio は Flutter の UI 作成のために使えるサイトです。ビルドのためのものではありません。Flutter を採用するなら使うことになるのではないかと思われます。Flutter ではそれぞれの Native パートをプロジェクト含めることができる。

3. Ionic
Ionicは、クロスプラットフォームアプリケーションとともにインタラクティブハイブリッドおよびPWAを構築するのに役立ちます。このオープンソースフレームワークは、アプリケーションを作成するためのプレミアムサービスを提供します。さらに、Ionicは、Web、Android、およびiOS用のアプリケーションの構築をカバーしています。さらに、Ionicで作業している間は、常にアプリケーションを作成して、展開可能な場所に出荷できます。すぐに使用できる機能を備えているため、アプリケーション開発に最適です。

まとめ
以上挙げた３つのフレームワーク以外、他にもモバイルアプリ開発フレームワークがあります。どのフレームワークを選択するかは、要件、予算、技術的要件、そして短期的または長期的な成功の可能性に応じて、最も適したものを選ぶと良いでしょう。

個人開発アプリを有料プレスリリース（3万円）で宣伝してわかったこと

2021-03-20T21:39:06+09:00

2021年2月半ばに２本目となる英語学習とクイズゲームを組み合わせたアプリ『英語学習クイズ！アメリカンドリーム』をiOSでリリースしました。

法人名義で出していますが、実態は個人（せいぜいチームレベル）で企画からユーザー獲得の宣伝までなんでもやらないといけない状況です。リリース後の1ヶ月ぐらいの間にやってみたことを何回かに分けて書きますが、今回は主に「有料のプレスリリース」を使ってみた感想と結果、その周辺のやり方をまとめてみました。

▼以下のようなクイズゲームのアプリです

本当はもっといろいろ書きたかったのですが長くなったのでテーマを絞りました。このシリーズ記事は以下のような似た境遇の人に役立てるように書いたつもりです。

●個人開発、小規模なチーム開発でアプリ / ゲームをリリースする予定の人
●カジュアルゲームから中規模なアプリをリリースする予定の人
●大手のように宣伝にかける潤沢な資金があまりない（だからといってすべてを無料で済ませる気もない）
●アプリ/サービスのユーザー数を増やしたい
●どんな宣伝方法があって、何が効果的なのかよくわからない
●やれることはなんでもやりたいがそもそも何ができるのか？
●規模の大小を問わずプレスリリースを書こうとしている人

あわせて私が参考にさせてもらったブログ記事などもご紹介します。先人たちの書いた記事に助けられ勇気をもらったので、少しでも続けるようにしたいと思います。

この記事を書いている時点でやった手法が爆発的に成功したわけではなく、ユーザーにつながる広告宣伝のチャンネルを開拓しているといった感じが実情なので「これをやったらうまく行きました！」みたいな記事でもありません。

初めてのアプリは2014年の終わりに出した、ゲームではない英語学習のアプリ『ざっくり英語ニュース！StudyNow』で現在は120万ダウンロードになっています。

基本的なスタンスは質の良いサービスを作って、そこに効果的な宣伝が重なってダウンロード数 / ユーザー数が増えていくという考えです。そもそも低品質のサービスをチート技でブーストさせる手法はあまり好きではないので、前提としては「一過性ではない、長く使われる質の良いアプリ・サービスを作る」です。

2014年と2021年ではアプリを取り巻く環境も違い、大手が展開する高品質な競合が多くなって、相対的に資金力・開発力のないアプリやウェブサービスの運営が難しくなっているのが肌感覚としてわかります。

2014年の年末に「ざっくり英語ニュース！StudyNow」を出した時はちょっとしたいざこざ炎上があって、その爆発力がダウンロード数に直結するといった再現性のないラッキーがありました。結果、初動で2万ダウンロードあり、好意的に紹介して応援してくれる人も多かったです。

今回の『英語学習クイズ！アメリカンドリーム』はそういった手法が使えないので、コツコツ地味に正統派の宣伝を試しています。よっぽど特殊で面白い販促宣伝が思いついたり札束を投下できるなら別ですが、そうでないなら時間がかかって地味な宣伝しかないのかなぁと思います。

この記事以外にもいろいろ試してその結果をフィードバックしていく予定です。

アプリやサービスを改善する２つの方向性

サービス全体のダウンロード数を獲得して成長させるには、大きくわけると手法としては２つの方向性があると考えています。

ASO（App Storeの最適化）にあたるストアの文章やスクリーンショットの見栄えを整える、そもそものアプリのサービスの質やUI / UXを改善する、グロースハックといった「内部に対する施策」も当然のように重要です。内側を見る行為です。

内部のUX / UIに関しては別の機会に書きたいのですが、軽く読む感じでは以下の記事が参考になりました。

売れるアプリにするコツ100個書きます(吐血)

個人製作アプリのダウンロード数を少しでも増やすためにやったこととその成果

今回は開発者が「制作でやるだけのことはやった！さあ、どうやって宣伝しようか」みたいな状況です。外側に対するアプローチです。その中でも「プレスリリース」を使った告知、宣伝についてだけまとめています。

有料（3万円）のプレスリリースを使ってみた結果

有料のプレスリリース仲介の相場は1回3万円ぐらいで、複数回セットなら1回あたりの金額が安くなる料金体系です。大手だと「PR TIMES」や「＠Press」なんかが有名です。おおざっぱな仕組みは以下の通りです。

一般的には自分で書いたプレスリリースは画像素材と一緒に「PR TIMES」や「＠Press」のような仲介をする配信ポータルを通して送付されます。受け取るのはテレビ局、ラジオ局、雑誌からAppBank、ねとらぼのようなウェブ媒体など登録されている大小さまざまなメディア媒体です。

もちろん自分のサービスを告知するにふさわしい相性の良いジャンルや媒体はある程度は選ぶことができます。「ロケットニュース24」「ねとらぼ」といった送付する媒体の指名は可能ですが、１つ１つ選定はしていられないので英語学習クイズならば「ゲーム系メディア」「教育系メディア」「WEB媒体」「アプリ情報系」みたいなざっくりしたくくりで決めます。

受け取った媒体はそれを元にニュースを書くので「こちらからニュースにしてくれとネタを提供する行為」だと考えていいと思います。その情報を見た媒体の記者が独自取材のうえで書き直すケースもあれば、機械的にそのままの文面（誤字も含めて）素通りで掲載されるケースもあります。

今回は「＠Press」を使い、5年前には「PR TIMES」を使いました。料金は3万円でした。それぞれ数百社以上の媒体が登録されています。以下は自分で書いた実際に配信したプレスリリースです。

本格的な4択クイズゲームで英語学習ができる無料アプリ『アメリカンドリーム』iPhone版をリリース！

成果にあたる数字は後半に書きましたが、結果的にはこのプレスリリースそのものがダウンロード獲得につながっているかといえば、そこまで大きな影響はありませんでした。同時期に出た「ウマ娘プリティーダービー」ぐらいの話題作なら取り上げてくれるメディアもありますが、なかなか個人開発レベルのサービスを積極的に取り上げてくれるメディアも少ないです。

ゲーム系アプリならAppBankや4Gamerのような大手にもいちおう送付されますが、日々多くのプレスリリースが送られてくるのは予想できるので掲載される可能性は少ないです。

せいぜい文面そのままを自動で取り上げてくれるようなニュースサイトに掲載されるぐらいで、人が見ている感じでもありません。「少しはSEOに効果があるのかなぁ…」といった程度です。

なかなか単発のプレスリリースが掲載される可能性は少ないそうで、継続的に話題を作ってプレスリリースを定期的に打つのが良いと＠Pressが言っていました。これは複数回の契約につながる営業トーク込み込みの話だと思います。

そういった過剰な期待をしない前提で、どこを使えばいいかといえば、どこでもいいと思います。有料ならば使い勝手もわかりやすい最大手の「PR TIMES」が無難です。PR TIMESにはスタートアップ向けの支援サービスがあって、創業2年以内なら無料で配信できます。

PR TIMESスタートアップチャレンジとは？（PR TIMES）

「＠Press」は担当者がついてくれて文章の校正やアドバイスをくれます。二重敬語のチェックなど、文章を客観的な目で見てもらえる点ではいいと思います。あくまで校正レベルのチェックであり、コピーライティング的なアドバイスをくれるといった感じでもなさそうでした。ツイッター拡散オプションなど入れていけばけっこう値段があがります。

どこか試してみたい！というならば使い勝手の良さ（インターフェイスや分析ツールなど）も含めて「PR TIMES」でいいんじゃないかと思います。

尖ったサービスなら取り上げてもらえる可能性もあるので、完全に無駄だとは言い難いですが、それでも大手に掲載されるのは難しいレベルだと思います。しかし、宝くじは買わないと当たらないし、プレスリリースは送らないことには掲載されないもんだと思います。

個人開発者にとって有料のプレスリリースって無駄なのか？

ダウンロード数という意味ではさほど影響はありませんが、プレスリリースを書く利点としては、自分の作ったサービスをもう一度見つめなおす機会ができることでしょうか。

どこに自分のサービスの長所があって、どんな売り文句・キャッチコピーを考えようか、誰がメインターゲットなのか、どんな画像がいいのかなど、3万円もかけて配信するので多少なりとも緊張感を持って臨めます。

また整理されたプレスリリースをWEB上に１つ用意しておくことで、今後さまざまな宣伝や説明の機会の際には「概要はここのプレスリリースにあるので見てください。素材はご自由にお使いください」と伝えられます。

そういう意味では、有料配信を使うかは別として、少し時間をかけてプレスリリースだけは使っておいて損はないと思います。後に紹介する個別の媒体への手動配信でも使えます。

プレスリリースの書き方みたいな記事はけっこうあります。タイミングも重要で「新規リリース」は「新卒」みたいなカードなので有効に使ってください。

個人開発者、Steamでゲームをリリースしたが初週で10本も売れなかったと悲しむ。情報を発信する難しさ

穴埋めで作る、インディゲーム開発者のための簡単なプレスリリースの作り方

【ゲーム系プレスリリースの基礎】ゲームメディアに掲載されるためのポイントを徹底解説！

それでも「3万かぁ…」みたいな気持ちもよくわかるんですよね。

光本勇介さんに教えてもらったプレスリリースの使い方

2014年にオンライン学習サービスの「Schoo」に当時のSTORES.jpの代表だった光本勇介さんがPR戦略について語っている授業を見ていました。今でも視聴可能です。

『STORES.jp』に学ぶ、WEBサービスローンチ後のPR戦略（Schoo）

光本勇介さんの経歴については割愛しますが、他の授業も含め今でもPR戦略について学べる面白い内容です。いい思い出ですね。個別のメール送信など、けっこう泥臭いことをやっているなぁといった印象でした。

そこで質問する機会があったので「有料のプレスリリースって効果ありますか？」と聞いてみたけれど、答としては個別の記者との信頼関係のほうが重要だといっていました。

一斉にマスで伝えようとする有料のプレスリリースは中小、個人開発のサービスには相性が悪いのもわかります。そこでポイントになるのが手間はかかりますが次のようなやり方です。「汗をかく」「足をつかう」みたいな発想の延長だと思います。

個別にニュース媒体に送る（送付先リスト）

「PR TIMES」や「＠Press」を通せば大手主要なメディアにはプレスリリースが配信されますが、ここの配信リストにのっていない媒体も多いです。だいたいメディアにはプレスリリースの窓口があるので、手間はかかりますがそこに個別に送付できます。

ゲーム系のアプリでいえば、個別のプレスリリースを受け付けてくれるサイトは以下の記事がまとめてくれています。実際にこれを見て１つ１つ私も送りました。

スパムと違うのは少なくとも媒体はプレスリリースを使った情報提供を求めている点です。

個人開発ゲーム（PC）向けプレスリリース送付先まとめ ※日本限定

2019年12月版：ゲーム系のプレスリリースを受けているメディアの連絡先一覧+レビュー依頼先一覧

レビュー依頼できるiPhoneアプリ紹介サイトまとめ【随時更新】

上のリストを見ながら１つ１つ送って、基本的にはコピペにはなるけれど、少なくとも「〇〇〇（媒体名）編集部」とか冒頭の宛名など、変更できる部分は変更して送りました。

また個別のお問い合わせフォームは文字数に制限があったり、媒体独自のフォーマットの指定があってめんどくさい部分もあります。正規で作ったプレスリリースとは別に「ショート版・ミニ版」みたいなものを作っておくのも便利です。

先に紹介した光本さんは、各テレビ局の各番組ホームページのお問い合わせフォームから定期的に送信していたそうです。

基本的にはそれでもなかなか取り上げてはくれないし、PR TIMESのようなポータルを通すのとさほど変わりません。掲載されたとしても自動的にプレスリリースの内容をそのまま掲載するタイプの媒体が多いです。アクセスやダウンロード数もさほど期待できません。

しかし、中にはプレーした後でレビューを掲載してくれるサイトもあります。スマホゲームCHさんは記者の方による詳細なレビューの上で、情報を掲載してもらいました。

英語学習クイズ！アメリカンドリー‪ム‬をじっくり遊んで徹底レビュー！（スマホゲームCH）

結果的に『英語学習クイズ！アメリカンドリー‪ム』については高評価をいただいたので幸いです。レビューに関しては口出しできませんが、客観的に評価をしてもらえたのがすごく収穫でした。自分の思っていた長所が見落とされていたり、ユーザーは何が楽しくてどこがうけているのかといった開発者にはありがたいレビューがもらえました。

宣伝は自分たちが言うよりも、他人の口から言ってもらったほうが効果あります。他者からの評価は今後の宣伝に使える強力な武器になるので財産だといえます。

１つ書いてもらえれば今後、自分のアプリを紹介するときに「これはスマホゲームCHさんの記者がプレーしたアプリの感想と評価です」と伝えたほうが客観的に魅力的に伝えることができます。

こういうのはアクセスやダウンロード数に直結しなくとも積み上げていくつもりで獲得していきます。

StudyNowが雑誌に掲載されると、雑誌経由のダウンロードよりも「雑誌に掲載された」というステータスのほうが長期的にみると財産になっているのと似ています。

専門媒体にプレスリリースを送ってみる

ゲームという縛りで考えると、上で紹介したゲーム系のメディアに送付することになり、そこは激戦区です。プレスリリースの記事そのままであっても取り上げてもらいにくいのが実情です。

しかし、ゲームを作っていてもゲームメディアというしばりから一歩抜け出せば、さまざまな専門媒体があります。

例えば『英語学習クイズ！アメリカンドリー‪ム』はクイズゲームであり、英語学習教材でもあります。そこには「クイズ」「e-Learning」「ゲーミフィケーション」「米国」のような切り口が可能で、それぞれの分野のインフルエンサーやYouTuber、有力団体、メディアがあります。

クイズ専門情報サイト　QUIZ BANG（クイズバン）

GDX News（ジーディーエックスニュース）

EdTech Media: 教育ニュース、ICT教育のメディア

GDX Newsはゲーミフィケーションやデジタルトランスフォーメイションを扱うニュース媒体です。こういったメディアに個別に送ると掲載してもらえました。

例えば「釣り」をテーマにしたゲームならば、ゲームで考えると埋もれがちですが、「釣り」でとらえればまた別の専門の媒体や有名人の存在があります。アイコンが鳥だから野鳥関係の団体を攻めるとかなんでもいいと思います。

私は大阪府の東大阪市の出身ですが、東大阪の地域サイトに「東大阪で開発されたアプリ」みたいな切り口をつくれば、そこには新たな宣伝のルートが開設できます。受け入れるかどうかは相手が決めることで、こっちが考えることじゃないと『嫌われる勇気』に書いてました。

自分の作ったものが何かのジャンルを横断できないか、自分や自分のアプリはどんな属性を持っているのかを考えてみると、新しい切り口や突破口が生まれる可能性があります。

登録サイトに登録してみる

プレスリリースの受付ではないけれど、自社のサービス、自薦の登録を受け付けてくれるサイトがあります。クリエイター系の相互支援サイトもあります。

個人開発したWebサービスをリリースした後にやったこと / やり続けていること

これも例えば『英語学習クイズ！アメリカンドリー‪ム』でいえば英語学習教材としても登録できるレビューサイトがありました。

みんなの英語ひろば

ひと昔前のインターネットはCGIで作った「登録サイト」がけっこうありましたが、リンクファーム的なサイトになんでもかんでも登録するのはSEOスパムっぽくなりそうなのでご注意ください。

登録サイトに登録するときも、プレスリリースで書いた情報を使いまわせるので便利です。

記者・ブロガーに直接プレスリリースを送る

結局はここに行きつきますが、マスで一斉に送信するよりは個別の記者、担当者に送るほうが効果的です。「あなたにだけお知らせします」と言われたほうが、記者もオリジナルの記事を書きやすくなります。

そんな知り合いの記者なんていねえよ、という話になりますが、それはよくわかります。東京を拠点にしていないと、なかなかメディア関係者と知り合いになる機会もありません。

私の場合は５年も運営している「StudyNow」があり、過去にPRESIDENTやGetNavi、Aera Englishに掲載されたこともあって、その当時のやり取りをたどって、そこの担当者の方にメールで案内を出しました。

また「StudyNow」もブログやYouTubeで紹介してくれていた人もいたので、そういった方に送信しました。メールを見返して過去の遺産を掘り返すのも手ですが、それでも取り上げられないケースは山のようにあります。

どうやったら広めてくれるのか？（モンゴルマン理論）

程度の差はあれ結局は知った情報を広めてくれるかどうかは、人間関係の上に成り立っている部分も大きい気がします。知らない人から知らないサービスを宣伝してくれと言われても抵抗感あるのが当然です。

もちろん、作ったサービスが斬新で話題性もありメディア取材が殺到するパターンも世の中には存在します。こういうのはよっぽど尖った内容か、大手が開発する話題性のあるサービスの場合です。

小規模なサービスの場合は、宣伝をお願いできたり、少しでも取り上げてもらえる人間関係を日頃から構築しておくことがポイントじゃないかと思います。それは友達であれ、ツイッター上であれ、知り合いの記者相手でも同じです。応援してくれる人や広めてくれそうな人を増やしておく、別の表現では「根回し」みたいな感じです。程度の差はあれナチュラルにやっていることを、もう少し意識して取り組む感じでしょうか。

知らない人からテンプレートで送られてくるプレスリリースの情報よりも、個人あてに送付するリリースメールのほうが採用される可能性が高いです。それより可能性が高いのはLINEで直接お願いすることです。距離が近いほど依頼も通りやすくなり、もっと成功率が高くなるのは会っていうことで、究極奥義はセックスしながらお願いすることです。

StudyNowの時はある切っ掛けで当時のテッククランチのライターさん（岩本さん元気ですか？私は元気です！）知り合いになりました。その縁で当時のテッククランチの掲載してもらいましたが、キラ星のごとく斬新なスタートアップのプロダクトが並ぶ中で当時の「StudyNow」が光っていたかといえば、どうだろうと今となっては客観的には思います。

そんな中でも知り合ったことで、それを補ってプロダクトを直接PRできる機会を得られたし、そこから伝わる思いもあったのだと思います。「モンゴルマンは1000万パワーはないけれど、それをおぎなう1000万の技があるから2000万パワーズに入れる」みたいな理論と一緒で、プロダクトがまだ未熟であっても、それを補えるものがあれば広めてくれる可能性が生まれてきます。

世の中にはお問い合わせフォームにある「press@...」「info@...」で始めるメールアドレスに送っても響かない内容でも、コミュニティの内側に入ってメールをゲットして「tanaka@...」からなら同じ内容でも響いてくれるケースがあります。

コミュニティの内側に入りこんで内部から届かせる努力、人間関係の構築はそれなりに必要なんだろうと思います。

ある媒体に掲載されているアプリやサービスを見ると、アプリの質みたいなもので掲載されたり話題になってるように感じますが、多くは実はもっと政治力が働いた結果のような気がします。

StudyNowはゲームではありませんが、たまたまAppBankのライターさんがアプリで英語学習をしてTOEICの高得点を目指す企画をやっているのを知って、そのライターさんに直接「StudyNowやってみてください！」と宣伝したら、後日AppBankに掲載してもらえました。AppBankには「プレスリリース受付フォーム」からも宣伝していましたが、そっちは撃沈してライターさんに直接いったほうは掲載にいたったことになります。日ごろからアンテナをはっておくのはいいと思います。

それでも、そんなことは難しく頼める相手がいない、チャンスもないなら「費用をかける（有料広告）」になります。以下の記事も有料の広告宣伝に対する考え方としては面白かったです。

宣伝費をケチる個人アプリ開発者にお灸を据える

有料のプレスリリースの結果とダウンロード数

＠PRESSで2月16日の13時に以下のプレスリリースを打ちました。

本格的な4択クイズゲームで英語学習ができる無料アプリ『アメリカンドリーム』iPhone版をリリース！

このリリースと同時にいろんな宣伝を開始しました。先に紹介した個別の媒体へのメール送付なんかも、この＠PRESSのリリースを出してから送りましたので、下の数字にはそれら行動の成果が含まれていると考えてもいいと思います。

以下はプレスリリース後の２週間ぐらいの実際のダウンロード数です。

日付 / ダウンロード数
2/16 273
2/17 136
2/18 84
2/19 45
2/20 68
2/21 53
2/22 25
2/23 48
2/24 37
2/25 37
2/26 31
2/27 31
2/28 45

自分のツイッターでの告知や、他の宣伝も少しやっているし、関係者のダウンロードも入っているので、純粋なプレスリリースの影響力ではありません。むしろこの数字に占めるプレスリリースの影響力ってかなり少ないと思います。

３月に入ってから爆発したとかもないです…。このままじわじわ滑空するように下がっています。やべえよ、やべえよ。

もちろん書いたプレスリリースの内容の良し悪しもあって、個々のケースで効果は違うと思います。プレスリリースを検討されている方は、どう応用して使うか？といった話になるので、プレスリリースを３万円払って配信したら自動的に集まるといったような、それ単体での過度な期待をしないほうがいいかもしれません。

この記事が役に立った方はぜひ「いいね」していってね。iOSしかありませんが、アプリも無料なんでクイズで遊んでください。

▼App StoreのURL
英語学習クイズ！アメリカンドリーム

▼5年前に出したアプリ
ざっくり英語ニュース！StudyNow

ほかにも「ツイッターの公式アカウントをゼロから運用してみた」「友達にダウンロードお願いしてみた」「自社サービスで宣伝してみた」「オウンドメディアで宣伝してみた」とか実験中のものや、ゲームはそもそもはじめてつくったので、どう作ったのかといった話、売上公開とかもやってみたいと思います。応援よろしくお願いします。

新作Flutterアプリ「IdeaShuffleMemo」を広めるために考えている戦略

2020-07-03T14:57:19+09:00

こんにちは、YuKiOです。

7月にFlutterアプリ開発を始めて2作目のアプリ、アイデアを発想するためのメモアプリ「IdeaShuffleMemo」をリリースしました。

■AppStore
https://apps.apple.com/jp/app/id1517535550

■Google Play
https://play.google.com/store/apps/details?id=com.IdeaShuffleMemoApp&hl=ja

1作目はとりあえずリリースすることを目的に作成しましたが、今回は「自分が欲しいもの」というテーマで作成しました。

さらに今後のアプリ開発を含めて、機能やアプリの露出方法についても挑戦的に戦略を考えています。

このアプリのトライアンドエラーの経験を、次回につなげていければと思っています。

機能については、Qiitaに書いています。
https://qiita.com/YuKiO-OO/items/283f44da64d304a6228e

crieitでは、どうやって露出させていくか？考えていることを、書いていきたいと思います。

全体の戦略

アプリの収益化

せっかくアプリ開発をするのだから、お金を稼げるようになりたいです。なので、収益を得る方法として、「広告」と「サブスクリプション」の２つを用意しました。

サブスクリプションも採用した理由は、コロナの影響もあり「広告」落ち込んでいたこと、広告収入という方法が今後変化する可能性が高く、安定したものではないからです。

単発の課金のほうが難易度が探るかもしれませんが、長期的にみて、開発の継続、安定した収益を目指す上ではサブスクリプションがいいと判断しました。

最終的に「お金を払ってでも使ってもらえるものを作る」というのが最終的な目標もあり、かなり苦労しましたがサブスクリプション機能を追加しました。

アプリの多言語化

日本のアプリ市場は世界的に見ても大きいほうだとは思います。
ただ、１国で月1万円稼げるレベルのアプリだったとして、日本だけにリリースすれば、1万円しか稼げません。もし全世界に配信することが出来れば、市場も広がるので、稼げるチャンスは増えるはず。（そこまで単純なものではないと思いますが）

なのでアプリは、最初から多言語化を意識して作りました。
初めから７カ国ご対応は辛いので、英語と日本語の２つに対応をさせました。

それに合わせて、アプリのキャプチャーや紹介文も英語で用意も。

英語圏でも反応が少しでれば、クラウドワークスなどを使って、ネイティブにPRできるような文章を作り込んでいきながら、対応できる言語を増やしていくつもりです。

まずは英語と日本語圏で収益を出せるかで、継続の判断をしていきたいと思います。

アプリのターゲット

アプリのターゲットユーザーは、主にアプリやサービス開発者、ビジネスマン、経営者、起業を考えている人です。
まずは、自分と近い範囲のアプリやサービスの開発者に広めたいなと思っています。

アプリの具体的な露出戦略

■国内での露出

・ツイッター

まずは自身のツイッターアカウントで告知します。ただこれは、Webサービスの時と同様あまり期待はしていません。フォロワー数が少ない、インフルエンサーでもないので、よほどインパクトがあるサービスでなければ、「リリースしました」のような広告っぽい投稿は敬遠されて反応がでません。

ただ少しでも反応を出すために、審査の間でPR動画を作ってみました。（Appleぽさを意識しながら、最後はメタルギアを意識している裏エピソードがあります。）

カメラなど映像も趣味なので、別の趣味がいかせて良かったです。

Webサービスやアプリ！斬新なアイデアをひらめきたい人に！アイデアを発想するためのメモアプリ✍️IdeaShuffleMemoをリリースしました！■AppStorehttps://t.co/gEPzEEJ7mt■Google Playhttps://t.co/w0vTiOanGE使ってみてください😁#駆け出しエンジニアと繋がりたい #プログラミング pic.twitter.com/gQ0dOMNgGB
— YuKiO | 個人開発&Flutter (@oo_forward) July 2, 2020

「#駆けだしエンジニアと繋がりたい」「#プログラミング初心者」のタグは、タグ検索をしているユーザーが多いのでつけています。

ただ、特に内容を見ずにいいねを押しているユーザーもいるので、いいねの割りには反応は薄かったりします。

まあ、固定ツイートなどの時の見た目として、いいねとリツイートが多い方がいいので、この方法を採用しました。

・Qiitaに投稿

これはアプリの露出と、アプリ制作でお世話になった数多くの方々への恩返し、自分自身への備忘録&技術の精査の意味も含まれていますが、Qiitaに技術記事がメインで、説明の一貫としてアプリの紹介をするのは問題ないかなと思ってます。

第１弾は、アプリ開発で使ったパッケージを紹介、それ以降はパスワードロック、データのバックアップ、サブスクリプションなどの、Flutter開発で情報が少なくて困った内容を書いていこうと考えています。

■第１段「おすすめのパッケージ」
https://qiita.com/YuKiO-OO/items/283f44da64d304a6228e

おかげ様で、現時点で1100viewにはなっているので、それなりに露出としては成功しているかなと思います。

・Crieit

もちろん開発者のコミュニティであるこちらにも投稿。他が技術的な内容になっているので、ここではこのようにアプリを露出させる方法として、内容ががぶらないようにしています。

・自分のブログサイト

自分のブログ記事は、アプリの紹介ページのような位置付けで書いています。
今後はアプリのQandAなどを追加して、情報を充実させていきたいと思います。

予算とアプリの反響によっては、こちらも多言語対応できれば理想ですね。

・プレスリリース

Webサービスではやったことがないのですが、プレスリリースにも挑戦しています。プレスリリースの難しいところは、個人を受け付けてなかったり、有料で、さらに１回に数万円と高額な場合があったりと、個人開発レベルでは手が出しづらい所です。

本業ではプレスリリースを使っているのですが、無料の場合はやはり無料レベルに留まることがおおく、あまり期待はできません。

ただ、今回は１アカウントお試して無料でできる、value pressさんを使いました。
https://www.value-press.com/

無料では配信できるメディアなど限られますが、有名なメディアや、ターゲットが好みそうなメディアも多いのが選んだ理由です。

ただ、記者は開発者ではないので、アピールする部分を少しヅラすことを意識しました。

ターゲットを、コロナ禍で厳しい環境にたっていて、何か変えたいと必死で考えている人向けとすることにして、コロナとは言葉に出していませんが、プレスリリースタイトルは、それを強くい意識した内容になっています。

ここで少しでも反応がでれば、ある程度お金をかけてもいいかなと思っています。

個人での注意点ですが、電話やメールアドレスが公開されます。勧誘メールが届くようになったりと、色々大変です。

公開しても良いメールアドレスや、格安のIP電話を契約して、それを公開するようにしましょう。

・ツイッター・フェイスブック広告

これはちょっと迷ってます。今回は実験ですが、それなりに広告費用をかけてみようと思います。
これまでもツイッター広告をつかっているのですが、あまりパフォーマンスがよくありません。

もしやるとしたらフェイスブック広告を出してみようかなと思っています。

ブログ記事であったり、いくつかの反応を見てから、実行する予定です。

■海外戦略

・Div

海外のQiitaのようなサイトを探してみたのですが、stackoverflowが紹介されていましたが、なんとなく質問コーナーという感じで、技術ブログのようなものではありませんでした。

Divはそこそこライトな感じの投稿が多そうだったので、こちらに投稿してみました。
英語は得意ではありませんが、Google翻訳を活用しながら、自分で書いたQiitaの記事を抜き出し、翻訳しました。

https://dev.to/oo_forward/flutter-recommended-package-used-in-the-developed-memo-application-15dl

Flutterに記事や、iOSの記事についてそこまでいいねがされていたりする記事がなかったり、どれぐらい動いているのか分かりませんが、２時間まえくらいに投稿した時点で、２件くらい「いいね！」がもらえているので、動いているのは動いているっぽいです。

・producthunt

https://crieit.net/posts/7
この記事で紹介さていたのでしりました。

https://www.producthunt.com/founder-club/benefits

仕組みがよくわかってないのですが、プロダクトを紹介するというサイトのようです。
紹介にあたってYoutubeの紹介動画が必要ぽいので、せっかくなら海外用のPV動画も制作して乗っけようと思っています。

正直あまりよくわかってない感じですが.

・Hacker News

上記の記事でproducthuntとの連携で紹介されていました。
まだ深くは理解できてないですが、このあたりも挑戦していきたいなと思います。

・Medium

Flutter初めてからみるようになったのですが、技術系のブログのようですね。
かなり膨大な投稿量らしいので、Qiitaのよう書いたからといってすぐに反応がでなさそうですが、起点として考えた方がいいなと思います。

どんな内容で買えば良いか、ちょっと考えています。

せっかく英語で書くなら、日本人として特色も入れられないかなと考えています。

■ASO

サイト検索順位ならぬ、アプリ検索順位の最適化ASOについて。
正直、軽くしか調べてられてませんが、リリースした直後は、評価も何もないので、ダウンロードしてくれそうなユーザーが検索しそうなキーワードを入れるくらいしか、できないのではないかと考えています。

SEOと同じ観点でユーザー主義でいくのであれば、ストア内の内容だけは順位が関係しないと勝手に思ってます。

例えば、

アプリの有料化率
外部リンクからのアクセス数
多言語への対応
アプリの定着率など。

AppleやGoogleどちらも、アプリのサブスクリプションが長く続く方がいいわけなので、結局SEO同様にアプリをよくしていくこと以外に方法はないと思っています。

まとめ

今回人生で２回目のアプリをリリースしました。アプリ開発って、アプリのコードを打ち込んで組むだけだと思いがちですが、本気でPRをやろうと思うとやることいっぱいだなと実感しています。個人開発の大変さも実感しています。

この方法がうまくいくとも分かりませんし、アプリ自体に需要がなければ、どんなにPRしても難しいと思います。

人事を尽くして天命を待つ

これも一つの実験で、うまくいかなければ別の方法を試していきたいと思います。

ツイッターもやってますので、ぜひフォローください。
https://twitter.com/oo_forward

■AppStore
https://apps.apple.com/jp/app/id1517535550

■Google Play
https://play.google.com/store/apps/details?id=com.IdeaShuffleMemoApp&hl=ja

GASで「農作業記録アシスタント」LINE bot作った（技術・設計編）

2020-02-29T14:25:03+09:00

はじめに

制作したLINE botの紹介を前回の記事で書きました。
GASで「農作業記録アシスタント」LINE bot作った（紹介編） - Crieit

今回はそのために活用した技術や設計に関することをまとめてみます。
具体的なコードの中身やLINE botの制作手順などについては割愛させてもらって、考えてきたことやどんな風に実装したか、また残っている技術的な課題や個人的反省について整理してみました。紹介編と合わせてご覧いただけたらと思います。

使用技術等

言語はGoogle Apps Script（Rhinoランタイム：Javascript1.6がベース）
LINE messaging API
サーバーレス

制作期間

約１ヶ月くらい（要件定義から制作まで）
GASの基礎学習を少しずつUdemyで学習（２週間くらい？）

（１）設計に関して

技術の解説に入る前に、アプリ制作のために構想したことを。
カッコつけて設計とは言ってみたものの、不十分だったり設計とは呼ばない内容かもしれませんがご容赦ください。またこんなにはっきり文章化して作り始めてはいません。

①簡易ペルソナ

農作業の現場作業をしていて記録を簡単に取りたい人。仕事終わりにじっくりと記録をとるのがなかなかめんどくさい人。細かい情報を記入する必要はなく、休憩時間などにちょちょっと記録してちょちょっと見返したり、圃場に出かけた際に簡単に過去の記録を見返したりしたい、というニーズのある自分自身や身近な農業者。

②競合アプリの比較・考察

既存のWEBアプリやスマホアプリは色々あり、農場の認証取得向けのしっかりした大規模なもの、資材管理なども同時にできるもの、農薬の散布制限なども自動で計算してくれるものなど。また個人向けのものや簡単入力ができるものもあるが、ただどうしても入力のところで課題を感じる。

どんなにシンプルなものでも入力のステップが多い
- 毎日・複数回行う入力作業だが、そのステップがどうしても多くなってしまう。最短でもスマホを手に取ってから、①アプリを開いて　②入力ボタンを押して　③フォームに入力して　④投稿を押す
- ものによってはフォーム入力で空欄があると投稿が出来ないものもあったり、画面遷移があるものも。
- プルダウンによる入力も選択肢が多いとかえって不便なことも

入力を習慣づけるのが難しい

初期設定が多く導入のハードルが高いものも
- 初期設定で圃場や所有機械の情報を入力したり使用する資材を入力しておくと便利！というものも多いが、まずそれを設定しないと入力ができないなど導入のハードルが高い。

このようなアプリはしっかり管理したい人にはメリットは多い。ただサクッとメモしたい程度の使い方をするにはストレスを感じる。

一方で既存アプリで参考にしたい点も
- 出力面で、カレンダー表示やカテゴリ毎の表示は必須
- 作業記録のテンプレートをユーザーが用意できて使いまわせるものもあり、それはすごく良い

③このアプリの特徴

入力の手間をとにかく排除
- ①LINEを開いて　②トークルームを開いて　③タップしたら指示に従って選択・入力、の３ステップ。あとは自動で投稿される。
- サクッとメモしたものがそのまま記録される、くらいの手軽さ。twitter投稿くらいの感覚。

日常で使用するツールを使用することで習慣づけがしやすい
- LINEは毎日コミュニケーションツールとして開くし、Googleカレンダーも普段の予定管理に活用しているのでこれらを活用。

シンプルさを保つためにデメリットも
- 画像の登録はできない
- 入力と出力以外の機能が無い（在庫管理などができない）

（２）技術に関して

①GAS(Google Apps Script)とは

GASとはGoogleが提供するサーバーサイドのスクリプト言語です。Javascriptをベースにしており、Javascriptに既に触れている方や学ぶ予定がある人には習得しやすいかなって思います。（「プログラミング言語」という認識でいるのですが、合ってるのでしょうかね？もし違っていたらご指摘お願いします）
古いJavascriptのバージョンにしか対応していなかったのが難点ですが、つい先日、2020/2/6にはV8ランタイムというものをサポートしたことでECMAScriptに対応し、より現在のJavascriptとの互換性が増したようです。（参考リンク１）

Google Apps（Googleドキュメント、スプレッドシート、カレンダー、Gmailなど）と簡単に連携することができるので、これらを活用したちょっとしたツールが作りやすいです。Webアプリも作れます。また開発環境のインストールもいらず、Web上でコードを書いて操作するだけで簡単に公開して実行することもできます。

制限はありそうですが「ある程度ならなんでも簡単にできる」という印象で、仕事や趣味・生活などで「自分やチームで使うツールをちょっと作る」というのには最適かなって思います。

②LINE Messaging APIとは

今では「LINE公式アカウント」でクーポン情報などを流すお店や企業が増えてますが、アレを作ることができるAPI（Application Programming Interface）です。様々な言語で活用できて、LINEを介して双方向のコミュニケーションをとることができるものを作ることができます。
LINE botとして有名どころでLINEで女子高生AIと会話ができる「りんな」とか。面白いですね。

（３）実装内容

今回のLINE botで実装した内容からいくつか簡単に紹介します。

①[GAS] LINEからの入力に対応

バックエンドの処理はGASで記述し、実際にユーザーが使う部分は基本的にLINEになります。この点でまず僕自身でUIを考えてコーディングする必要がなく、機能を制作することに集中することができました。

LINEでユーザーがフォローしたりメッセージを送ったりと何か反応があったら、まずdoPost関数が実行されます。そこからLINEアクションの種類（followだったりmessageだったりpostbackだったり）によって処理を分岐します。

GASでGoogleサービス以外の外部のWeb APIを使うためには、UrlFetchサービスのfetchというメソッドを活用します。これによりHTTPリクエストを送信してWeb APIを叩くことができます。

またLINEでの日報入力の際にユーザーが段階的に入力できるようにするために、GASのキャッシュサービスを活用しています。１つ処理を行ったらCacheオブジェクトに一時的にデータを保存しておくことで、ユーザーからのアクションをフラグで管理して分岐するようにしています。

②[GAS] 日報をGoogleカレンダー・スプレッドシートへ書き込み

GASではGoogleの各サービスにアクセスするためのクラスが用意されています。
- GmailAppクラス：Gmailを操作操作する
- DocumentApp：Googleドキュメントを操作する
- Spreadsheetクラス：Googleスプレッドシートを操作する
- CalendarAppクラス：Googleカレンダーを操作する

これらは先程の外部APIとは違ってGASから使える内部サービスのため、何の準備なしに使うことができます。
これらを利用して日報を専用のカレンダーとスプレッドシートに書き込む処理を作りました。

注意点としては、自分のGoogleアカウントに紐づいているGoogleカレンダーとしか連携できないことです。つまり、僕のアカウントでスクリプトを作成して、そのスクリプト上で他のユーザーが制作したカレンダーに書き込むことができないのです（スプレッドシートなら可能な様子）。

③[GAS] カテゴリをユーザーがカスタマイズ：Webアプリの作成（HTML Service）

毎回の入力の手間を省くために「作業カテゴリ」というものを用意しています。
LINEから日報を入力する際にが選択肢（LINEのクイックリプライ機能）として選べるようにしたのですが、この内容をユーザーが自由に編集できるようにしました。

データの保管場所としてスプレッドシートでセルを用意しており、そのデータを取得することで作業カテゴリを配列で取り出せるようにしています。

またユーザーがカテゴリを編集しやすくするために、その部分だけWebアプリとして制作してみました。要件定義の段階では特に作る気はなく、スプレッドシートから直接編集できるからいいやと思っていたのですが、スプレッドシートに慣れていないユーザーだと編集しずらいだろうなと考えたためです（初期設定のハードル）
これにはGASのHtmlServiceを活用して、最低限のHTMLの知識があれば簡単に制作することができます。

Webページには編集フォームとスプレッドシートに設定されている作業カテゴリが表示されているだけのシンプルなものです。
WebページにアクセスするとまずdoGet関数が実行されます。またフォームで作業カテゴリを編集して送信した場合はdoPost関数が実行されます。doPost関数ではLINEからのアクションなのかWebからのカテゴリ変更処理なのかをイベントオブジェクトeの中身から判断して、Webからの場合なら送られてきた内容をスプレッドシートの作業カテゴリのセルに上書きする、というような処理を行っています。

④[LINE] リッチメニューの作成

LINE messaging APIで一番理解が難しかったのが、LINE messaging APIを活用したリッチメニューの制作方法でした。

リッチメニュー制作にはLINE公式アカウントからの設定方法とmessaging APIを活用する方法の二種類があります。
リッチメニューを使う | LINE Developers

LINE公式アカウントからの制作はとても簡単で、画像を用意さえしておけばブラウザ上で操作するだけで簡単にリッチメニューを作成してLINE botで活用できます。プログラムを書かなくとも誰でも直感的に作ることができるのですが、メニューボタンの配置を細かく決めることができなかったりアクションの種類が限られていたりと、できることに制限があります。

それでもちょっとしたものなら十分なのですが、LINE messaging APIを使うことでもうちょっと手の込んだ、例えばゲームコントローラーのようなボタン配置などをプログラムに落とし込んで作ることができます。

最初に公式アカウントで制作したところ一瞬でできて感動したのですが、魔が差してmessaging APIを活用する方法で実装し直すことにしました（コードで完結できればメンテナンス性も高い？という考えも）。ところがhttpリクエストやRESTの理解が浅かったため自力で実装するのが困難でした。
この実装にはこちらのHASEKATSU様のnote（参考リンク２）を参考にさせていただきました。
一応実装はできましたが、どう言う仕組みで実装できているのかまだちゃんと自分の言葉で説明できないので課題です。

（４）技術的な課題

紹介編にも書いたのですが、データベースの一意性がありません。これはほぼ自分用とはいえかなりの欠陥。
一度入力した日報をスプレッドシートやカレンダーから修正できるのですが、それがもう一方に反映される仕組みが作れていないのです。誤って日報登録してしまうことも多々あるので、一度登録したものを安心して編集・削除できる仕組みが必要なところ。

この部分を解決するためにまず一番最初に考えたのが、Webアプリとしてスプレッドシートの内容を取り出して編集できるようにするというやり方。ところがこれ以上Webアプリ部分に力を割くのは、手間がかかる割にはどうにもGASで制作する意味が薄いように感じます(PHPやRubyでデータベースを用意して作る方が発展性がありそう)。

手軽さとGoogleのサービスとの連携が簡単というGASの良さを引き出すなら、スプレッドシート上で編集するのが良さそうです。と思って調べてみると、値の変更があった際に発動するトリガーがGASで設定できるとのこと。スプレッドシート上の日報履歴が編集・削除されたら、対応したGoogle Calendarのイベントを書き換える…ということが理論上できそうです（Calendarのイベント固有のIDでデータベースを管理する）。

一方でGoogleカレンダーの方で修正したいこともあるのですが、こちらがなんだか一手間二手間かかりそうです。これもGASのトリガー機能を使うことで、カレンダーの編集があったらスプレッドシートにもデータが反映されるようにすれば可能かなと思えたのですが、それにはGASのCalendarAppサービスだけでは出来ない様子。calendar APIという外部APIを使えうことで、なんとかできなくもなさそうな感じです。

というわけで、技術的な課題は現状あるもののクリアできそうです。

おわりに

今回の制作では、初めて念願のAPIというものを活用することができました。
RailsでWEBアプリ開発を学んでいた時には、エラーの対処やフロントエンド作り、環境構築などでいっぱいいっぱいでしたが、デバッグの感覚を学び、今回は比較的とっつきやすい技術を選んで目標を最小限にしたことで、余裕を持って制作できたと思います。

反省としては、GASやLINE botの仕様を把握出来ていなくて、ユーザーに活用してもらうにあたり移行作業に手間がかかったことです。
自分以外のアカウントのGoogleカレンダーへの書き込みが出来ないことに完成間際で気づいて、どうやって他ユーザーに使ってもらうかを考え直すことになりました。結局身近で興味を持ってくれた仲間限定ということで、僕が新規作成したカレンダーを共有して使用してもらう方法をとることに。
また、人数分のLINE botを用意しなければならずそれに対応した使い回しのきくスクリプトに書き換える作業が発生してしまいました。
完成したぜ！という段階からだいぶうだうだやってたのがもったいない。

今後の方針としては、もうちょっとGASでこのアプリの改善と日常で必要なアプリを作りつつ他のAPIの活用のやり方も学んでみたいなーと思っています。

MEMO

僕の過去記事でGASとLINE messaging API学習に役立った教材・ブログをまとめてあります。
もしこれから取り組む方がいましたら参考にしていただけたら嬉しいです！
GAS & LINE messaging APIの学習便利帳 - Crieit

参考にしたサイト

参考リンク１
祝！Google Apps Scriptが「V8ランタイム」をサポート！モダンなECMAScript構文が使えるようになった
参考リンク２
Postmanでリッチメニューを設定する方法【LINE Messaging API×GAS】｜HASEKATSU｜note

またこちら、本文には特記してないのですが、使用言語としてGASを検討する際の参考に。
GASを使うべきか否かの判断材料 - Qiita

GASで「農作業記録アシスタント」LINE bot作った（紹介編）

2020-02-26T12:37:47+09:00

はじめに

エンジニアでもなんでもないただの畑作農家が、普段の農作業の記録を簡単に記録するためのLINE botを作りました。
今回はその紹介編です！

（2020/2/29追記）技術編もまとめました。
GASで「農作業記録アシスタント」LINE bot作った（技術編） - Crieit

農家にとって細かく作業の記録を残しておくことは大事で、作業ごとに把握しておくべき項目が多いのです。
例えば種蒔き。年に１回（ほんの数日間）しか行わない作業ですが、種子を落とす量・肥料の銘柄と量・それに合わせた機械のセッティングと走る速度など、細かな調整がその年の収量（＝収入）を左右します。

また複数の作物を管理していると、定期的に農薬を散布するなど天気を見ながら計画を立てることになるので、前回いつ・どんな薬を撒いたか、などを把握しておくことが大事になります。数年前の記録を引っ張り出してきたい時もあります。

メモしておかないと、だいたい１年経つと全て忘れます＼(^o^)／

ただ、メモするのがめんどくさいんですよね。
紙の日誌だと多く情報を残せますが、検索性に欠けるし。
必要な時に必要なものだけちゃちゃっと記入して、必要な時に必要なものだけちゃちゃっと取り出せる、そんなツールが欲しいなあと思っていました。

皆さんおそらく同じように悩まれていることで、農作業日誌アプリにはスマホアプリやWEBアプリが既に多々存在します。農家の経営を助けるために、いろんな方がいろんな想いを込めて作ってくれています。
ところが、僕にはどうも上手く使いこなせないのでした。実際に使ってみても中々しっくりくるものがなかったというのが正直なところで。

まあ、そんなんで、作りました。
自分が普段メモ書きなどでも使っているLINEと予定管理に使っているGoogle Calendarに着目して、入力の手間を極限まで省いた農作業記録アプリをLINE botで作成。

こんなアプリ

LINEを開いてメニューをタップしたら入力開始。メッセージに従って「日時」「作業カテゴリ」を選択した後にチャットで作業内容を入力。

入力した内容は指定のGoogleカレンダーとスプレッドシートに自動で登録されるので、それらのツールで登録した記録を見返すことができます。

（１）LINEを開いて簡単に今日の作業日報を入力

作業の日報入力を専用のアプリでやるのではなくLINEで入力するというのが肝。
コミュニケーションツールとしてLINEを開かない日は無い、という人が多いかと思います。LINEを立ち上げる度に嫌でもこのbotのアイコンが目に入るため、思い出した時にちゃちゃっと入力をしてやればいいのです。

↓メニューの左「日報を入力」をタップすると、日報登録のボタンが出てくる

↓日時を選択して登録できるので昨日の記入忘れも安心

↓作業カテゴリは選択肢を選ぶだけ

↓作業内容を入れる時だけテキスト入力が必要

↓登録できました！

また、LINEを使うと過去にあげた日報の履歴がLINE上からも参照できるというのは何気に便利。コピペしてきて文面を使い回して使用しても◎

ただ、LINEからの一度登録した予定の編集・削除は現状備わっておりません。手動でカレンダーとスプレッドシートで編集する必要があります。

（２）Googleカレンダーに記録して見返す

こちらも日常使いのツールをそのまま使用。
予定管理を全てGoogleカレンダーで行なっているので、スマホのウィジェットとして登録しておくことで、作業履歴もそこに表示してくれることになります。
他のカレンダーアプリにGoogleカレンダーを連携して使うこともできそうですよね。僕の周りでは「Time Tree」を予定管理に使っている人が多いのですが、どうやら連携が可能そうです（僕自身使ってないので正確にはわからず）。

（３）スプレッドシートでも記録を管理

これはおまけというか、主にパソコン上で過去の履歴を一覧にして参照したい時があるので、そのために作りました。ここは比較的アナログ感が強いのですが、参照したい時はスプレッドシート上で操作をします。フィルタで特定の作業カテゴリのみを一覧表示にしたり、全体を検索をかけたり。ここをWEBアプリでもうちょっとしっかりすると良い感じがします。

（４）作業カテゴリをユーザーがカスタマイズ

日報入力時に作業カテゴリを選択肢として出るようにしているのですが、これはユーザーによって色々変わってくると思います。専用のWEBアドレスにアクセスすると、そこからユーザー自身でカテゴリの編集を行えるようにしています（ここはWEBアプリ）

現状の課題とこれからの展望

あくまで自分が欲しいものを作ったのですが、その延長で「人に使ってもらいフィードバックをもらう」ところまでは今回ずっと考えて作ってきました。身近な同業者に使ってもらえることになったので、反応が楽しみです。

ひとつ大きな課題としては、データの編集・削除に問題があります。
カレンダーとスプレッドシート両方を編集する必要があるので、単に不便なだけでなくデータの一意性が保てていません。ここはもうちょっと考える必要あり。

自分専用で使うなら最低限の機能を持ったアプリが完成した感じなので、これで満足といえば満足です。
仮に発展が望めるなら、別言語でサーバーを準備して本格的にWEBアプリ化？スマホアプリ化？

もうすぐ春から本格的に始まる農作業で実際に活用しつつ、使ってもらえる方の反応を聞きながら、今後の展開を考えていきたいと思います。

おわりに：農作業記録アシスタントLINE botを使ってみたいという方へ

残念ながら一般公開はできません。ただ、もし「使ってみたい！！！」というアツいお方がもしいらっしゃいましたら、是非ぜひお声がけいただけたら嬉しいです。システム的には農業に限らず業界関係なく使用できると思います。また、

Googleアカウントが必要（Gmailアドレス）
自分専用（複数人での使用は登録処理がおそらく無理。カレンダー共有は可）（とは言いつつも少人数のメンバーが固定してるグループならLINE botを人数分立てていけるのかも）
登録情報の秘密性には欠ける（僕の方で参照・編集することができてしまう）

この点だけご注意を願いします。テストユーザーとして色々遊んでもらって、使い勝手などご意見いただきたい気持ち。
LINE botを個別に作成する必要があるため多くの対応は難しいですが、まあそんなことはないと思うので、何か気軽にお話いただけたらとても喜びます。

MEMO

使用技術等はこんな感じ（別記事で詳しく書く予定です）
- 言語はGoogle Apps Script(GAS)
- LINE messaging API 使用

サーバーレス。
Googleカレンダーとスプレッドシートを連携。WEBアプリ部分はGASのHTML Serviceを活用して作成。

また、今回のLINE botのアイコンイラストは、こちらの「ねこぺんね」様の素材を使用させていただいてます。ありがとうございます！
顔つき野菜イラスト - No: 1624420／無料イラストなら「イラストAC」

【GAS】家族で使えるゴミ出しリマインダ LINEチャットボットを作った

2020-01-24T17:37:21+09:00

はじめに

日常のゴミ出しって難題ですよね。

「今日燃えるゴミの日なのに、ゴミ出し忘れた！！」
「プラごみ出し忘れて今日で１ヶ月…また２週間後まで出せない…」

いや、できるのが普通当たり前のことなのかもしれないのですが、自分のような日常生活に支障をきたす程度の面倒くさがり＋曜日感覚のない人間にとっては、ゴミを定期的に出すというのはかなりのハードルです。
一人暮らしの時にはアパートの入り口は基本ゴミの山。
結婚してからも自分の力でゴミ出しができた試しがなく妻には頭が上がらない。

男女問わずこんな~~ダメ人間~~多忙なビジネスパーソンが多いと僕は信じています…。

ともあれ、そんなやっかいなゴミ出し問題を解決するために、家族や夫婦で活用できるアプリを制作しました。

「ゴミ出し日の前日にリマインドしてくれるLINEチャットボット」

一人暮らしで活用してもよし、旦那さんが奥さんのために率先してゴミ出ししてもよし、夫婦で共有してもよし、子供にゴミ出しを意識づけさせるために使ってもよし。

使用した技術

GAS（Google Apps Script）
LINE Messanger API

１．チャットボット詳細

改めて、このチャットボットで出来ることはとてもシンプルで、このLINE botアカウントと友達になっておくことで
「ゴミ出し日の前日夜9時にリマインダが送られてくる」
というものです。ただそれだけ。

曜日によって送る情報を変えることができるので、自分の地域のゴミ収集曜日を入れておくことでそれに応じてリマインドしてくれます。

↓いろいろ通知してくれるLINE bot 「にゃんこ通信」

↓こんな感じに勝手にチャットが飛んできてお知らせしてくれます。うんこうんこ

３．色々な情報をグローバルで定義しておく

Line Developersのチャンネル作成やプッシュメッセージの登録などが必要ですが、
今回はコードのみ紹介。

//チャンネル情報・ラインユーザー情報の取得
var CHANNEL_ACCESS_TOKEN = 'ここにアクセストークンを入力';
var USER_ID_M = 'ここにラインユーザーIDを入力';
var USER_ID_L = 'ここにラインユーザーIDを入力';

まず、チャンネルアクセストークンと、リマインダメッセージを送りたいラインのユーザーIDを変数に入れます。

これらはプログラム中で変更することがないので定数constに入れたいなあと思うのですが、どうやらconstはグローバルでは定義できないようです（参考リンク１）
（定数は関数内でプライベートでのみ定義）
頭に書いておきたいので変数varで定義しておきます。

チャンネルアクセストークンと自身のLINEユーザーIDについては、LINE Developersのチャンネル情報で見れるので、それを利用します。

ちょっと手間がかかるのが複数人でこのbotを共有する場合。
僕の場合は妻とbotを共有したいので、メッセージの送り先として妻のLINEユーザーID（ラインで友達検索に使うラインIDとは別物です）を設定しなければなりません。

ところが、調べているとこれが簡単に取得できないことが発覚。
一旦置いておいて次項で。

//ユーザー入力項目
var weekday = ["日", "月", "火", "水", "木", "金", "土"];
var garbageCalendar = {
  "日":"",
  "月":"燃やすゴミ",
  "火":"",
  "水":"資源ゴミ",
  "木":"燃やすゴミ",
  "金":"",
  "土":""
};

次にユーザー入力項目ですが、
このgarbageCalendar変数に、オフジェクトでゴミ収集の曜日とゴミの種類を入れておきます。
地域のゴミ収集カレンダーから持って来ましょう。

３．他人のラインユーザーIDの取得

これには参考サイト１をそのまま活用させてもらいました。

取得したユーザーIDをグローバル変数に入れておきます。

４．リマインダのメイン処理

次に、リマインダのメッセージなどを記述して送信するためのgarbageReminder()関数というものを作ります。

//リマインダのメイン処理
function garbageReminder() {
//翌日の日時を取得
  var date = new Date();
  date.setDate(date.getDate() + 1);
//翌日の曜日を取得して、ゴミの種類を取得
  var dayNum = date.getDay();
  var day = weekday[dayNum];
  var garbageType = garbageCalendar[day];

//明日がゴミ収集日にリマインドメッセージを送信
  var message = "【ゴミ出し通信】\n";

  if(garbageType != ""){ 
    message += " 明日は${day}曜日、「${garbageType}」の日です。\n出すゴミをチェックしよう！".replace('${day}',day).replace('${garbageType}',garbageType);
    sendToLine(message);
  }else{

  };
}

前半では、今日の日付から曜日を取得してわちゃわちゃして翌日のゴミの種類を判別してます。

new Date()でまず今日の日付情報を取得できるので、その変数にdate.setDate(date.getDate() + 1);とすることで、翌日の日付情報を取得しています。
その取得した日付情報dateにgetDay()メソッドを使うことで曜日を取り出すことができます。曜日は数字になっているので注意。
曜日からゴミの種別を取ってくるときは、グローバルで定義しておいた配列とオブジェクトを使用します。

後半は、メッセージを送信する処理になります。
翌日がゴミ出し曜日の場合にのみ、変数messageに曜日やゴミの種別が入った文字列が入ります。
変数を文字列として送るときはreplaseメソッドを活用。
また改行を入れたいときは\n(記号はバックスラッシュ)を使います。

最後にsendToLine(message)という関数（次項に記述）を利用して、先ほどの変数
messageの値をラインに送信しています。

５．ラインに送信する処理

前項の最後の、実際にラインに送信するための色々な情報を記述する
sendToLine()関数を作ります。

//ラインに送信する処理
function sendToLine(message){
//色々なパラメータを設定
  var url = 'https://api.line.me/v2/bot/message/multicast';
  var headers = {
    'Content-Type':'application/json; charset=UTF-8',
    'Authorization':'Bearer ' + CHANNEL_ACCESS_TOKEN
  };

  var data={
    "to":[USER_ID1,　USER_ID2],
    "messages":[{
      "type":"text",
      "text":message
    }]
  };

  var options = {
    'method':'post',
    'headers':headers,
    'payload':JSON.stringify(data)
  };
//LINE messanger APIを叩く
  UrlFetchApp.fetch(url, options);
}

最後のUrlFetchApp.fetch(url, options);がGASでAPIを叩く命令となります。
かっこの中は「どこへ、どの情報を送る」というイメージです。

そのために必要なものをその前に変数に入れて記述しています。
詳しくはLINE Developersの公式ドキュメント(Messaging APIリファレンス)を参照。

var urlにはHTTPリクエストを送るURLを記述します。
このurlの末尾をmulticastとしていることで、送り先を複数に設定しています。
この実際に送るのがvar dataのtoに配列で複数設定しているユーザーIDになっています。

例えばこのbotを自分だけが使用できれば良いという場合は、
HTTPリクエストを送るurlの末尾をpushにして、var dataのtoには自分のユーザーIDだけを指定しておけば良いですね。

詳しい説明は省いてしまいますが、このようにLINEのmessaging APIを叩くための諸々のパラメータをurl,headers,data, optionsに入れているわけです。

ここまでできたら、トリガーを登録することでリマインド機能が完成です！

課題

LINEのユーザーIDを調べる方法をコピペで実施しているので、コードを自分の頭で書いて理解してみようと思います。
というか、そもそもLINEユーザーIDをいちいち入れなくてもいい可能性はないか…？

おわりに

普段使っているラインを入り口にして色々できないかなーと考えるようになって
日常生活で欲しかったちょっとしたものを実際に作ってみた次第です。

これに夫婦で使いたい機能をちょっとずつ付け足していきたいと思っていて、
家計の金銭管理とか、買い物リストとか、直接ラインでやりとりするのは少し手間だったり精神的負担があったり…というようなほんと些細なことをツールで出来るようにしたいなーと思っています。

いずれリッチメニューなんかも作れるようになりたいですね。

夫婦中がちょっとだけアップするアプリを目指します。笑

参考にしたサイト

参考１
Google Apps Script - Google Apps Scriptでグローバルな定数を定義できない｜teratail
参考２
Google Apps Script試行錯誤Blog: LINE BOTでuserId, groupId, roomIdを取得したい
LINE Developers公式ドキュメント（プッシュメッセージ）
Messaging APIリファレンス

MEMO

Githubに全体のコードをあげています。
書き方はあまりスマートでない部分もあるかと思うので、その点はお手柔らかに。

LINEbot-for-life/push.gs at master · Massasquash/LINEbot-for-life · GitHub

また、LINE botのアイコンの画像はこちらのものを使用させていただいてます。感謝。
勉強猫 | 無料イラスト素材｜素材ラボ

作業日誌アプリ「Workdiary」説明書

2019-12-31T22:28:48+09:00

Workdiary

初めて制作してきたWEBアプリです。
日記とその日にやったワークの登録を行う作業日誌アプリで、農作業を想定していますがどんなジャンルの作業でも（おそらく）使えるような内容になっています。

GitHubリポジトリはこちら

初アプリとはいえ未完の部分が多く、クオリティ的には課題が山積み。
お時間のある時になんとなくいじってみてもらえたら嬉しいです。

アプリの使用イメージ

自身の農作業の記録を目的として制作してみました。
勉強の記録などに使ってもいいかもしれません。

(1)やった作業を入力する
農作業をやっていて、一段落ついた休憩時とかその日家に帰ってお酒飲みながらでも、スマホをポチポチやってその日にやった作業内容を登録。この時にメモしておきたい数量や機械のセッティング内容などを簡単に入れておきます。

(2)必要なときに調べる
その後「このセッティングって前回どうしていたっけ？」という時に、スマホをポチポチやって以前に入力した内容を確認します。

特徴としては「テンプレート機能」というものをつけてみました。
作業内容の定型文（テンプレート）をユーザーが事前に作っておくことで、やった作業の記録を簡単に記録できるようにしています。

アプリの使い方

（１）サインアップ・ログイン

サンプルアカウントでログインしてみてください。
初期値でフォームにサンプルアカウントが入っているのでそのまま「ログイン」をクリックすると入れます。
任意のメールアドレスとパスワードでユーザー登録（サインアップ）することもできます。
メールアドレスは架空のものでOKです。現状の設定では実際にメールは届きません。

（２）ナビゲーションバー

ログインしたら画面上部にナビゲーションバーが登場し、アイコンをクリックすると画面遷移します。左から、

ダイアリー一覧：ダイアリーとワークを一覧表示します。
ワーク一覧：ワークをカテゴリごとに一覧表示します。（未実装）
検索：日記・ワークを文字列検索できます。（未実装）
編集：カテゴリとテンプレートを編集できます。
アカウント：ログイン状況の確認とログアウトができます。

（３）メインページ（「日記一覧」画面）

ログインしたら最初にこの画面が表示されます。
ここでは既に登録された「日記」と「ワーク」が一覧で表示され、それらの作成もできるこのアプリのメインページになります。

日記の作成
- 「ダイアリーを書く」から今日の日記を投稿します（画像では「日記を書く」）。
- 投稿できる日付は今日に限らず過去でも未来でもプルダウンで選択できます。
- ダイアリーは日付あたり１つのみ作成できます。

ワークの作成
- ダイアリーを作ったら、そのダイアリーに紐づいたワークが作成できるようになります。日付の横にある「ワークの追加から作成します。
- カテゴリ、作業名、作業内容を入力して登録します（写真はフォームのみで未実装）。

その他
・ダイアリー一覧の日付をクリックすると日記の詳細画面に映ります
・登録したダイアリー・ワークの編集と削除もできます
・「メモする」をクリックすると、ワークに対してメモを１つ追加することができます。後から気づいた点を追記したい場合などに活用できます。

（４）「カテゴリ」について

ワークに対してカテゴリを登録しておくことで、後からカテゴリごとにワークを一覧表示できるようにするものです。

ワーク入力時に「カテゴリ」をプルダウンで選択します。
事前に「＋カテゴリ追加」から自分でカテゴリを作っておく必要があります（画面遷移します）。
ナビゲーションバーの「編集」ページでカテゴリを編集・削除することができます。
カテゴリを削除したら、該当するワークからはカテゴリが外れてしまいます。

（５）「テンプレート」について

ワーク入力時にテンプレートを選択することで作業内容に定型文を入力できます。例えば「決まった一連のワークがあって、その作業内容の定型文を作っておいて数値のみ変えて登録する」といった活用なんかを想定しています。

ワーク入力時に「テンプレート」をプルダウンで選択するとその下の作業内容フォームにテンプレートの内容が自動で入力されるので、それを書き換えるなどして投稿することができます。
事前に「＋テンプレート追加」から自分でテンプレートを作っておく必要があります（画面遷移します）。
ナビゲーションバーの「編集」ページでテンプレートを編集・削除することができます。

↓テンプレートをプルダウンリストで選択すると……

↓このように作業内容のフォームに反映されます

（６）ログアウト

ナビゲーションバーの「アカウント」ページよりログアウトできます。

......以上、最低限のアプリの説明書でした。

開発に使用したスキル

言語とフレームワーク
- HTML, CSS
- Ruby, Ruby on Rails
- 一部、Javascript, JqueryでAjax化

開発環境等
- AWS cloud9
- Heroku

またRailsで使った主なgemとしては
- Bootstrap4（デザイン）
- Font Awesome （アイコン使用）
- Devise（ログイン機能）

デザイン周りはほぼBootstrapを活用しています。
一部機能にjQueryを使用してAjax化していますが、ちゃんと理解して使えていないというのが正直なところ。
ログイン機能のメール認証に関しては実際の認証は外した状態です。

今後の実装予定と課題

制作期間が間延びしてしまいモチベーション的にも厳しくなってきたので、これで一区切りして次に移ろうと考えてますが、やはり未消化でモヤモヤする部分もあります。

ワーク一覧表示画面、検索画面の作成
（完了！）パンくずリストをつける
（完了！）アラートメッセージの表示方法と日本語化
ワーク登録時に写真を追加できるようにする
ワーク登録時のカテゴリ・テンプレート新規作成をモーダルウィンドウで入力しやすくする
日付をカレンダーから選べるようにする

この辺りは時間を見つけてもうちょっと取り組んでいきます。
また公開したことによって細かい部分で自分で気付けなかった問題やバグが出てくると思うので、そういったデバッグ作業から今後の学びにしていきたいと思います。

例えば現状でも、ダイアリーやワークの登録に文字数制限をかけておいたりすべきかなーとか、UI的にダイアリーやワークの作り方がわかりづらいなーとか手間がかかるなーとか、色々見えてきますね。

今回一度公開することで、友人に見せてみることができたのが良かったです。何人かに見てもらったのですが、皆さんまずは「どう使えばいいかわからない」と口を揃えて言っていただけます。。。
これを実感するだけでも公開した意味があったなーと感じます。

このアプリは僕の処女作としてしばらく公開を続けてみて、いろんな方にサンドバッグにしていただきたい所存です。
とはいえぜひお手柔らかにお願いします！（よわい）

自作クソアプリを無謀にもドヤ顔で晒す…

2019-12-14T07:00:08+09:00

クソアプリ紹介記事を開いていただき本当にありがとうございます。高田と申します。

どんなクソアプリなの？

ズバリ。「福笑い」でございます。
https://portrait.piggy3.com/ja/index.html

遊び方

１．サイトにアクセスする

トップ画面が開いたらやることは１つ。「似顔絵を作成する」を押しましょう。

【クソポイント】
・ログイン機能の実装で挫折
・なのに英語対応（英語力はクソ）
・さらに独自ドメイン取得

２．遊びたい絵を選択

これは！と感じた絵を選びましょう。

【クソポイント】
・素材の追加で挫折
・このためだけに契約したPhotoshopに月々980円を払い続けている
・もうすぐお正月だから素材を充実させたい気持ちもアリ

３．自由にパーツを配置

ここだ！と感じた場所にパーツをドラッグ。「位置を確定して次へ」を押すと次のパーツの配置に進みます。この繰り返し。

【クソポイント】
・操作が直感的ではない
・「位置を確定して次へ」ボタンいらなかったかも…ドラッグして離したら自動で次のパーツに進むようにすれば良かった
・でも修正する気ナシ

４．タイトルを設定

これだ！というタイトルを付けてあげましょう。あえて未設定も可。心の準備ができたら「確定」を押します。

【クソポイント】
完成した絵を確認する前にタイトル付けを強要

５．完成！

おめでとうございます！完成した作品のURLをコピーしてSNSにシェアしましょう！

【クソポイント】
・SNSのシェアボタンではなくURLコピペスタイル

最後に作者の自己紹介

ここまでお読みいただき本当にありがとうございます。

お仕事ではOffice 365などのクラウドサービス導入支援・利活用サービス提供を生業としております。最近は営業寄りの活動が中心になっており仕事上では技術に触れる機会が激減中です。

本クソアプリはAWSのサーバーレスに興味があり趣味の範疇で手を出してみた結果です。Web開発で飯を食う目標は持っていませんが、自分でやってみることで本格的なサービスを開発しているエンジニアの皆様の凄さをより理解できるようになりました。なにより、モノづくりの過程であれこれと勉強している時間が本当に楽しかったです（ある程度形になると飽きっぽさが出てしまいます…）。Udemyの動画教材でAWSを契約するところから学んだのですが、ついつい楽しくて徹夜をしてしまったこともあり。仕事の合間に短期集中で１か月くらいの期間で作成しました。

最後の最後にクソアプリの構成だけ載せておきます。

AWSサービス名	役割
Lambda	・サーバー側処理の実行（Pythonを使用）
S3	・htmlやjsなどの静的コンテンツ配置・Lambdaで生成した画像データ保管
DynamoDB	・システム用レコード管理・ユーザー作成の画像データに紐づくプロパティ情報保管
API Gateway	・Lambdaの処理をREST APIとして提供するための設定
CloudFront	・キャッシュ管理（CDN）・S3/API Gatewayのコンテンツにユーザーがアクセスするためのマッピング設定
Route53	・ドメイン管理・S3/API GatewayをCloudFrontにマッピングするための定義

デザイナー向けのタスク管理アプリDesignBoxを作りました

2019-08-28T00:11:53+09:00

みなさん、こんにちは！タカフミです！

実は今月でフリーランスを始めてからちょうど1年になりました！この1年の間で色々な方とお会いして、今まで経験したことないようなお仕事をたくさんさせていただきました。この場を借りて、皆々様に深く御礼申し上げます。

普通でしたらこのあたりで「フリーランスを1年経験してわかったこと！」や「フリーランスを始める前にやっておいた方が良かったこと」などの記事を書きたくなるものですが、そういうものに関してはすでに諸先輩方の有用な記事がたくさんあるので、そちらにお任せすることにします。

この1年のフリーランス期間を通して、いろいろなお仕事をしながらもコツコツ作っていたものがあります。何かというとDesignBoxというフリーランス・デザイナーさん向けの超シンプルなタスク管理アプリです。

DesignBoxという名前はなんとなく語呂がよくて、僕がよく使っているDropBoxとも名前が似ていたの気に入ってつけました笑

今日は僕がフリーランスのデザイナー生活を通して、ある問題に気が付きDesignBoxを作るにあたった経緯についてお話したい思います！

すべては1年前から始まりました

プロフィール文のところに小さく書かれていますが、フリーランスになる前には教育系ベンチャー企業で3年半ほどエンジニア兼デザイナーとして働いていました。アプリやウェブサイトのデザインから開発、CIデザインなども任せていただけて本当にたくさんの経験をさせていただくことができました。名刺やスタンプカードからロゴ、アプリ開発などに関わりなんでも屋さんとして働いていました。長いようであっという間の3年半の間で、一回りも二回りも大きく成長することができました。

僕がデザインしたウェブサイトを見て「この会社で働いてみたいと思ったんです」と言ってもらえたり、何かデザインしたもので周りの人に喜んで貰えることが何よりも嬉しくて、働くことを通してデザインすることの喜びや楽しみを感じられるようになりました。人を笑顔にしたり、喜ばせることが出来る「デザインの力」に気がついた瞬間でもありました。

そこで色々と経験した後、いつしか「他にも自分のデザインを必要としている人がいるのではないか」と考えるようになりました。他にも家庭の事情などもあり、「世界中の人をデザインで幸せにする」をミッションに掲げてフリーランスとして働くことに決めました！

デザインに集中したいのに。。。

フリーランスのデザイナーとしてスタートして、見積もりに請求書や税務など当初は分からないことばかりでした。でも、幸運なことに素敵なクライアントさんに恵まれたおかげで日々楽しく働くことができました。

ただ一方でクライアントさんが増えてくるにつれて、依頼されたお仕事を管理することにストレスを感じるようにもなってきました。デザインすることは楽しいのに、案件を管理するのにうんざりしてしまったのです。

それまではタスク管理ツールとしてWunderlistを使っていました。デザインもシンプルで簡単にタスクを追加、完了できるのでとっても気に入っていました。今でも、個人的なタスクを管理するために使っているほどです。ただ、自分の仕事の用途にはあまり向いていませんでした。

ここで、ちょっと普段のデザイン業務の流れについて説明させていただきます。案件の大小によって若干の違いはありますが、概ね次のような流れになります。

（１）クライアントさんから依頼がくる

クライアントさんからSlackやメールなどを通じてご依頼を受けたら、Wunderllistに依頼内容が分かるようにタスクを追加します。詳細についてはメモ機能があるので、そこに保存をします。

（２）案件用のフォルダを作成

成果物を保存するためのフォルダを自分のコンピュータ上に作成します。このフォルダにはクライアントさんから貰った、画像素材やテキスト情報などのデータも一緒に保管をしています。

（３）数日後になって、デザイン業務に取り掛かる

いいアイデアを思いつくのに時間がかかったり、納期まで余裕があるので他の案件との兼ね合いも見ながら、数日後になっていいアイデアが思いついてからデザイン業務に取り掛かるようにしています。

ただ、ここである問題に気が付きました。

それは何かというと、数日前に作成した案件用のフォルダを見つけるのに時間がかかってしまうということです。クライアントさんの名前別にフォルダを作成して保存はしているのですが、正確なフォルダの位置をはっきりと覚えていないので、フォルダの奥深くまで潜ったり、あっちでもこっちでもないとフォルダを行ったり来たりすることがありました。

最初のうちは辛抱強く探していたのですが、こんな事が1度や2度ではなく何度もあったためウンザリしていました。。あるクライアントさんに「去年作って貰った名刺の背景を変えたものを用意して欲しい」と言われたことがあったのですが、数日前の記憶すら忘れてしまう僕にとっては至難の技でした笑。１時間以上かけてフォルダを探してみたのですが、結局見つからずゼロからデータを作成するなんて事もあったのです。

「デザイン業務に集中したいのに、どうしてフォルダを見つける事にこんな時間が掛かってしまうんだろう。。」もうこれ以上、こんな無駄で楽しくないことはしたくないと感じるようになりました。

解決方法はシンプルなのに、アプリがない。

どうしてこんなことが起きるのだろうと小一時間考えたみたら、すぐに原因がわかりました！

それは、タスクとそれに関連するフォルダとの紐付けが一切ないからでした。よくあるタスク管理アプリではファイルのアップロードやメンバーとのチャット、ボイスメッセージの機能はあるのに僕が必要としている機能はなかったのです。

もしかしたら、僕が知らないだけで不満を解消してくれるものが他にあるかもしれないと思い、出来る限り調べてみたのですが１つも見つかりませんでした。考えてみたら、それもそのはずで一般的なタスク管理アプリは「牛乳を買う」「ゴミ出しをする」などの日常生活でおこる一般的なタスクを管理する人向けに作られていることがほとんどで、デザイナーさんのようにタスクがコンピュータ上のデータと関連するような場合については考えられていないからでした。

「もうフォルダ探したくない問題」に対する解決策はとっても簡単で、あるタスクに対して特定のフォルダを関連づけるシンプルなアプリがあればいいだけでした。「他にアプリはないし、でもこれ以上フォルダを探したくない。。なら自分でつくるっきゃないよね！」ということからフリーランスのデザイナーさん向けのタスク管理アプリを作ることに決めました！

macOSアプリの開発経験は全く無く、なんとかなるだろう精神で完全に見切り発車したのですが、結果的には絶望的に情報量やノウハウが少なくて何度も挫けそうになりました笑

紆余曲折あって出来上がったのがDesignBoxです！

普段の業務で僕はこんな風にDesignBoxを使っています

リリースしたばかりで全くといってユーザーさんがいないので、僕以上にDesignBoxを使っている人は現在いないと思います笑　普段の業務でもガッツリ使っているので、ここではどんな風に使っているのかをお話したいと思います。

1. リストを作成する

新しいクライアントさんからお仕事のご依頼を受けたら、クライアントさんの名前を入力してリストを追加します。リストに付ける名前はクライアントさんの名前だけに限らず、プロジェクトの名前でもいいですし、とにかく自分がわかりやすい名前で付けるのがオススメです。

2.タスクを作成する

リストからタスクを追加したいクライアントさんなどを選択したら、依頼内容が分かるようにタスク名を入力して作成します。大きなメモ帳も用意しているので、そこに依頼内容の詳細情報を入力したり、進捗状況などをメモしたりします。

3. 期限を設定する

納期をしっかりと守れるように期限を設定するようにしています。タスク右上にあるカレンダーアイコンから簡単に設定できます。ちなみに、リスト横にあるバッジの色が期限までの猶予を表しています。青＞黄＞赤の順に納期が迫っていることを教えてくれます。

4. フォルダを作成してワークスペースとして設定する

タスク用のフォルダを作成して、そのフォルダをワークスペースとして設定します。これを設定することで、タスクと特定のフォルダを関連付けることができます。あとは、そのフォルダにクライアントさんから貰った画像やテキストデータなどを移動させるようにしています。

5. やっと業務にとりかかる

やっといいアイデアが思いついたらデザイン業務にとりかかります。リストやタスクの一覧から探してもいいのですが、僕の場合は右上の検索バーにキーワードを入力することが多いです。タスク名はもちろん、メモ帳の内容も検索対象に含まれるのですぐに目的のタスクを見つけることができます。あとは、そのタスクを選択するだけで関連する作業フォルダが自動的に表示されます！！以前の僕ならここですごく時間が掛かっていたので、たったこれだけでも本当に助かります(^^)

6.　タスク完了！

待ちにまった感動の瞬間です。。納品が完了したらチェックボタンをクリックして納品完了です！もっと爽快感のある音に出来ないか現在検討中です。

DesignBoxは現在も絶賛アップデート中です。あれもこれも出来たらいいからと機能を追加することはなく、あくまで「シンプルで簡単」をモットーにデザイン業務に集中できるタスク管理アプリを目指しています！

一人でも多くの人にDesignBoxを使ってもらって、幸せになってもらえたら嬉しいです。アプリのアップデート情報については、DesignBoxもしくは僕のツイッターをご覧ください。

それではみなさん素敵なデザインライフをお楽しみください！

【禅Do】利用しているライブラリについて

2019-06-19T23:27:01+09:00

導入したライブラリについて

とりあえず当時、Carthageの情報が結構出ていて使いやすそうだったので
基本的にCarthageを利用してインストールする方針でやっていた。
その中で対応していないものはCocoaPodsを利用するか、直接ソースを入れる形にした。

Carthageで入れたもの

SwiftDate
- リマインド機能の日付操作の為に導入
Bond
- リアクティブプログラミング的なものを使ってみたかった為
- 全体設計の見通しの良さ向上の為など
Eureka
- 設定画面でリスト型テーブルやForm作成を簡単にするための導入
Log
- 開発用途。デバッグのしやすさ向上の為
Quick
- 開発用途。テストコードを書く為（なおちゃんとテストコード書いてない模様）
Nimble
- 開発用途。テストコードを書く為（なおちゃんとテストコード書いてない模様）

CocoaPodsで入れたもの

firebase-ios-sdk
- （今もかもだけど）当時モバイルのアナリティクスとしてイケてる感じだった為導入
- ユーザ動向を知るため

直接入れたもの

FontAwesome
- 各種アイコンに利用
DatePickerCell
- 設定画面でのCell操作の為に導入

導入ライブラリのアップデート

とりあえず当然ビルドが通らなくなってため、各ライブラリの最新版を利用するように
Cartfileを書き換えてアップデートしてみた。
ただそもそも、Carthageの使い方を忘れていたので、思い出すために下記記事などを参考にした。

Carthage について
 Carthage Tutorial: Getting Started

さらに元々、Carthageディレクトリ以下のBuild/Checkoutsもgit管理下においていたが、
ライブラリアップデートを何回も試してる時に、いちいち削除が面倒になったのと
下記の記事を読んだので、git管理化から外すことにした。

CocoaPods・Carthageでインストールした成果物はバージョン管理に含めるべきか？

アップデート方法

利用しているライブラリのうちほとんどは、Swift3へのアップデート対応等がされていたが
Logライブラリだけはメンテが止まっていたので、forkして対応することにした。
（代替のものを探したが方が良いが、とりあえずビルドを通すのが第一目標なのでそのまま利用）

直接ソースを入れるタイプのものも、Carthage対応されるようになっていたので
Carthageを利用してインストールする方式に変更した。

メンテナンスされているライブラリはバージョン指定を外して
最新版をインストールするようにした。

下記はSwiftのバージョンを3にして carthage update --platform iOS が
問題なく実行できるようになった時点でのCartfile。

# Use libraries
github "malcommac/SwiftDate"
github "SwiftBond/Bond"
github "xmartlabs/Eureka"
github "Quick/Quick"
github "Quick/Nimble"
github "thii/FontAwesome.swift"
github "DylanVann/DatePickerCell" ~> 1.0

# Own repos.
github "stlwolf/Log"

備考

carthageでのインストールが成功するところまで行き、Xcode上でライブラリを
利用しているコードでErrorになってる箇所を修正することができる状態にはなった。
Bondライブラリがアプリに入れた時期から大きな変更が入っているので、利用方法を含めて
再度使い方を調べないと最新版のコードを利用できそうにないことが判明。（ReactiveKitに組み込まれてる？）
公式Docと下記あたりを参考に別途キャッチアップする。
Bond Tutorial: Bindings in Swift | raywenderlich.com
Bond, SwiftBondを使ってみよう！ - Takahiro Octopress Blog

【禅Do】Swift2.3のアプリをSwift5対応にしたい

2019-06-10T13:53:49+09:00

大枠

数年前にSwiftの勉強のために作ったiOSアプリを、リリース後に全く
アップデート対応していなかったので気がついたらSwiftのバージョンも5になってた。

このアプリのWeb版出したりとか諸々やりたいことが出来てきているので
とりあえず最新版のSwiftに対応して一度アプリを
更新リリースするところまでやることにした（頑張る）

前提条件

1,2年ほどiOSアプリ周りを全く触ってなく以下は忘却されている
- Swiftの文法、機能について
- Xcodeでの各種設定について
- リリースまでに必要なりソース、手順について
- 導入したOSSライブラリについて
アプリ自体の機能はかなり控えめなので、コード量自体は多くない
当時リアクティブプログラミングの勉強を兼ねてBondというライブラリを利用している
- RxSwiftとかを入れるほど大した機能はなかったので、機能が控えめなBondを入れた経緯
- ただ当時から大分実装が変わっているようなので、コレの置き換えが一番手間かかりそう

「アプリ開発」の記事 - Crieit

【個人開発】アイデア出しから公開・プロモーションまでまとめ(Nuxt3、Cloudflare、GooglePlay)

自作アプリをバズらせるために８年間やったこと

Android 虎の巻 API31対応するための修正

Dartを使った大規模なアプリ開発

AngularDARTを使わない理由は、以下のとおりです。

Flutterベースのモバイル向けタイムラインの作成

Quireタイムライン（モバイル向け）の構造を初公開

Quireモバイルアプリ用のタイムラインでは、以下を計画していました。

モバイルアプリ開発フレームワーク

個人開発アプリを有料プレスリリース（3万円）で宣伝してわかったこと

新作Flutterアプリ「IdeaShuffleMemo」を広めるために考えている戦略

GASで「農作業記録アシスタント」LINE bot作った（技術・設計編）

GASで「農作業記録アシスタント」LINE bot作った（紹介編）

【GAS】家族で使えるゴミ出しリマインダ LINEチャットボットを作った

作業日誌アプリ「Workdiary」説明書

自作クソアプリを無謀にもドヤ顔で晒す…

デザイナー向けのタスク管理アプリDesignBoxを作りました

【禅Do】利用しているライブラリについて

Android 虎の巻　API31対応するための修正