ID:75351さん

## プロジェクト概要 個人開発として、夜尿症患者向けiOS / Androidアプリ「おねしょカレンダー」を2024/04/14にリリースしました。 iOS: https://apps.apple.com/jp/app/id6480280974 Android: https://play.google.com/store/apps/details?id=com.kourokuroom.bed_wetting_calendar&pcampaignid=web_share 2026/03/27現在、アプリ評価はAndroid: 4.26★(245ユーザーが評価)・iOS: 4.9★(188ユーザーが評価)と、高い評価を受けております。 総ダウンロード数(first_open)は39,155人、月額課金者数は319人、アクティブユーザー数（過去28日間でアプリを起動したユーザー数）は4,159人と、個人開発としては高い人気を得ております。 南アフリカの夜尿症ガイドライン（2024年）にアプリ名が掲載されるなど、医学的な観点からも評価を得ております。 https://pubmed.ncbi.nlm.nih.gov/39514747/ https://journals.co.za/doi/full/10.7196/SAMJ.2024.v114i11.2790#:~:text=Bed%20Wetting%20Calendar ## チーム体制 * 開発者：1名 ## プロジェクトにおける自分の役割 個人開発のためすべて担当しています。 ## 業務内容 * 企画 * 設計 * コーディング * テスト * 運用/保守 * ランディングページ作成 * マーケティング（SNS運営・コラボ依頼等の連絡・カスタマーサポート） ## 実績・取り組み ### 技術選定 フリーランスとして活動する際に、この程度のアプリであれば作成できますという実績が必要と考え、何かしらの個人開発を行おうとスタートしたものとなります。 最初の技術選定においては、スキル向上の意味も込めてSwiftUI / Jetpack Composeについて調査を行っていましたが、やはり個人で収益を上げるためにはクロスプラットフォームなフレームワークを採用するのが必須だと考え、クロスプラットフォームの調査に切り替えました。 当初はKotlinの学習も含めKotlin Multiplatformでの開発を行っていましたが、UIロジックなどAndroid / iOS向けのコード部分も書く必要がありクロスプラットフォームとして全て省略できる訳ではないことに気づき、最終的にはより省略できるコード部分が多いことやフレームワークの人気度を考えFlutterを採用する形となりました。 ### 評価の高さ アプリページの評価が高いほど、「おっ、なんだか凄そうだ」と実績として評価されやすくなります。 その評価を実現するために、以下のことを考えていました。 * 強い競合アプリが少ないほど、自アプリを触った時に「あのアプリは◯◯できたのに / ◯◯のデザインが良かったのに」というネガティブな気持ちが湧きづらい。 * 強い競合アプリが少ないジャンルを調べることで、少なくとも最初は自アプリに好感を抱きやすくなる形を目指しました。 * アプリ内にアプリ評価の機能を実装するが、不満点を持つ人はフィードバックへの遷移へつなげる。 * 自分もそうですが、アプリで★5以外をつける場合は「もっとここがこうなればいいのに！」というユーザーの想いが存在することは間違いありません。 そのため、アプリを継続的に利用した方にのみ「アプリの使い心地はいかがですか？」と問いかけるダイアログを表示し、不満点がなく★5評価したい！というユーザーにのみ評価への遷移を実装することで、高い評価を得ることができました。 もちろん、不満点があるユーザーにはフィードバック画面への遷移を行うことで、ユーザーの細かな不満点までキャッチアップできる状態を作り上げることもできました。 ### 個人開発の強みを活かす 複数人が関わるプロジェクトだと、最初に「〇〇なアプリにしたい」という要件があり、それを実装するために調査を行うというフローになってしまいます。 今回は個人開発で自由に作れるという強みを活かすため、まずはFlutterのライブラリ一覧(Pub.dev)をじっくりと眺めました。 そうすることで、見ていて楽しいUIライブラリや、開発に便利なライブラリを認識しておくことで、もしアプリに組み込むことができるならアプリ設計は〇〇という形にしておいて、もし組み込まない場合でもこのクラス単位で分離しておけば外しやすいという見込みを建てながら設計を始めることができました。 これにより、個人開発というリソースが限られた状態でも、リッチなUI/UXのアプリとしてリリースすることが可能となりました。 当初はクリーンアーキテクチャを意識した設計を行う予定でしたが、Flutterにおいてはライブラリの恩恵を活かせる構造にしづらいというデメリットがありました。 個人開発の限られたリソースでボイラープレートコードの作成作業が大量に発生してしまうことは避けたいこともあり、4層のレイヤードアーキテクチャ(application / data / domain / presentation)を各機能毎に作成するような設計となりました。 ### アプリの開発からリリース、営業まで全工程の担当 個人開発のため、アプリの作成だけでなく、リリース作業、全世界でアプリ内課金を実装するために必要な書類提出・GDPR対応、Google AdMobによる広告収益を得るための申請やメディエーションのための各広告企業様へのご連絡、アプリと実商品コラボのご提案を企業様に行うなど、実装以外の様々な処理も行いました。 アプリをより魅力的にするため、世界中のイラストレーターにお声がけさせていただき、現在イラストレーター7名(内、英語圏1名)のイラストをアプリに搭載する作業も進めています。 また、アプリとコラボした企業様のみが宣伝できる独自の広告枠「コラボ広告」という機能を実装しており、その広告枠の販売を海外の企業様へご提案させていただくことも経験しております。 このように、アプリリリースに関する知識だけでなく、日本語や英語を用いた諸連絡や仕様書作成など、運営に関する様々な知見も得ております。 ### 採用をご検討されている方へ こちらのアプリは個々人の疾病が関わる事柄ですので、「私がこのアプリを開発している」という情報を社内メンバーへ共有する際は選考に関わるメンバーのみにしていただいたき、可能な限り知っている人数を少なくしていただけますと幸いです。

### プロジェクト概要 ラーメンを自動調理し提供する自動販売機へ搭載するAndroidアプリの開発プロジェクトに携わりました。 海外で既にサービス展開を行っており、日本で新たにサービス展開するために自動販売機構造および内部アプリを刷新するというものでした。 そのため、ベースとなる海外版アプリはあったものの、ほぼフルスクラッチするようなプロジェクトとなりました。 試作機に向けた開発（フェーズ1）、正式稼働に向けた開発（フェーズ2）の両方に参加しました。 ### チーム体制 * PM：1名 * フェーズ1 エンジニア：2名 * フェーズ2 エンジニア：5名 ### プロジェクトにおける自分の役割 フェーズ1,2エンジニア ### 業務内容 * 要件の実装可否調査 * フェーズ1,2開発 * テスト ### 実績・取り組み #### AOSP ボックスで使用できる権限の調査 自動販売機にはAOSPのボックスを搭載する予定だったため、通常のAndroidアプリでは実行できない権限の処理を行うことが可能な状態でした。 そのため、特権権限アプリ(priv-app)をインストールした際に利用できる権限を調査し、不正な操作を行わせないために対策可能なアプローチを調べる作業および実装作業を行いました。 ※他テストアプリとの兼ね合いで当時はDevice Owner機能を用いない形としていました。 * プロセスが永続的に生存し続けるための実装(persistent対応) * 起動中アプリのタスク情報を取得し(REAL_GET_TASKSパーミッション対応)、他アプリが最前面となっている場合に自アプリを最前面にするための実装 * 通知ドロワー（画面上部から下にスワイプすると現れる画面）を開くことができないようにするための実装 など。 上記作業を通じて、通常のAndroidアプリでは実行できない処理に関する知見は他の方よりもあると自負しております。 #### リッチなUIのコーディング 自動販売機という性質上、画面UI/UXは購買欲を刺激するようなリッチなものである必要がありました。 UI/UXデザインは別のデザイナー会社様が作成したものをコーディングするという形だったため、通常のアプリよりもレイアウトや動画再生が複雑なものとなりました。 しかしながら、実装の前段階で処理が複雑になりそうな箇所の洗い出しを行い、実装可否の調査や大きな見た目の変更を伴わないご提案を早い段階から行っておくことで、遅延もなく実装を進めることができました。 （例：『ラーメン動画の上に湯気動画を再生するような複数アイテムを重ねて再生する箇所』が『端末スペックでスムーズな再生ができるかどうか、そもそも透過動画を重ねて再生できるかどうかの調査』を事前に行い、早い段階で『2動画を重ねる代わりに湯気を含んだ動画として提供可能かどうかのご提案』を行わせていただいた、等）

### プロジェクト概要 アプリで撮影した写真・動画・音声・メモをウェブ上からGPS座標とともに確認できるシステムの開発プロジェクトに携わりました。 役所等の道路維持管理状況の調査などにご活用いただけるアプリとして開発しました。 ### チーム体制 * 企画・要件定義エンジニア：1名 * サーバーエンジニア：3名 * Androidエンジニア：2名（ランディングページ作成も担当） ### プロジェクトにおける自分の役割 Androidエンジニアのリーダー・ランディングページ作成のリーダー ### 業務内容 * 設計 * コーディング * テスト * ランディングページ作成 ### 実績・取り組み #### Androidアプリの新規開発 Androidエンジニアのリーダーとしてアプリに関する設計からテストまでほぼ全タスク見ていました。 プロジェクト開始時には企画と要件しか存在しない状態だったため、アプリ全体の設計から作成を行いました。 今回のプロジェクトでは、デザインパターンとしてFacadeパターンを採用し、最初は大まかな画面遷移とFacadeのモック応答を作成しました。 それにより、他Androidエンジニアへ各部の詳細実装を振り分けやすい形になり、各機能の大まかな実装期間の推測も行いやすい形にできました。 UIについては、機能としての指定はあったものの画面デザインは明確には決まっていない状態だったため、当時の流行だったニューモーフィズムを採用しました。 まずはFigmaにて仮デザインを作成し、社内でフィードバックを貰いつつアプリへ落とし込む作業を行いました。 今回は業務用アプリという性質上、ニューモーフィズムを完全採用すると操作ボタンが分かりづらくなるため、あくまで雰囲気のみ取り入れつつも操作ボタンは縁色を付けることで見つけやすくなることを心がけました。 #### ランディングページの作成 広報活動としてランディングページ・資料請求フォームが必要というところまでは決まっていましたが、社内にWebページ作成に関する知見を持った者が少なく、手探りで技術選定から行う必要がありました。 調べれば情報が出てきやすく、作業者が他の人へ移った場合でも技術習得が容易なように、AWS Lightsail + WordPressで作成を行う形に決定しました。 WordPressでのページ作成には、企画者の「〇〇のサイトにある△△みたいなアニメーション・デザインを設置したい」という要望があったため、デザイン拡張性のあるElementorプラグインを用いて作成する形に決めました。 具体的なデザインについては、このタイミングで作業担当者が増えたため、Figmaで仮デザインを個々人で作成し、企画者に選定してもらうという社内コンペを実施し、私の作成したデザインが採用されました。 結果として、技術選定・WordPress構築・サイトデザイン・問い合わせページ作成・構築手順や編集手順をまとめた書類作成など、ウェブページに関する作業はほぼすべて自分が行いました。