社内で使っている LINE WORKS の「タスク」と「カレンダー」を、
Androidアプリ・PHPサーバ・Roomデータベースで一つのタイムラインにまとめた社内向けダッシュボードです。
OAuth2で安全にログインし、LINE WORKS APIと自前のPHPスクリプトで束ねたタスク群をローカルDBに保存。
いつでもどこでも「やること」と「入っている予定」を一望できることを目指しました。
仕事では「タスク管理」と「カレンダー」が別々のサービスになりがちで、
結局は紙のメモや口頭で補ってしまうことが多くあります。
このミズホアプリは、LINE WORKS のタスク機能とカレンダー機能を API 経由でまとめ、
「案件・カテゴリごとにタスクと予定を紐付けて眺められる」ことをコンセプトに作りました。
Android 側では OAuth2 認証でアクセストークン・リフレッシュトークンを取得し、
PHP サーバ上の syncTasks1.php に JSON を投げることで、
社内ルールに沿ったタスク束（カテゴリ＋タスク＋紐付いた予定＋紐付いていない予定）を一括取得します。
結果は Room データベースに保存し、オフラインでもカテゴリツリーとして閲覧できます。
Android（Jetpack Compose）・LINE WORKS API・PHPサーバ（syncTasks1.php）・ MySQL/Room データベースの関係をまとめた構成図です。 スマホ上の「ミズホアプリ」が認証と同期のハブになっています。
LINE WORKS の OAuth2 で access_token / refresh_token を取得し、
SharedPreferences に保存しています。
API呼び出し前には ensureAccessToken() を必ず通し、
有効期限が切れていれば refreshAccessTokenBlocking() でリフレッシュ。
「気付いたら全部401で落ちていた」を避ける作りにしました。
タスクAPIとカレンダーAPIをそのまま叩くと、フロント側での突き合わせが大変です。
そこで PHP 側に syncTasks1.php を置き、
TaskSyncResponse > CategoryBundle > TaskBundle > TaskEvent
というツリー構造に整理してから返す設計にしました。
Android ではそのまま Room に保存し、
Compose 側では CategoryWithTasksAndEvents として展開して表示します。
同期結果は CategoryEntity, TaskEntity, EventEntity
の3テーブルに分けて保存し、
@Relation を使って
CategoryWithTasksAndEvents としてツリーで取得できるようにしました。
アプリ起動時はまず Room から読み込み、必要に応じて同期ボタンでサーバと揃える「オフラインファースト」な設計です。
UI はすべて Jetpack Compose で記述。
CategoryAccordionItem でカテゴリ単位の折りたたみ、
TaskItemRow でチェックボックス付きタスク行を実装しました。
新規タスク・新規予定はそれぞれ NewTaskScreen / NewEventScreen として
画面を分離し、入力完了後は LINE WORKS API に POST します。
実際に社内 LINE WORKS アカウントでログインし、カテゴリ・タスク・予定の同期とツリー表示を確認しました。
タスク行のチェックボックスを ON/OFF すると、
即座に tasks/{taskId}/complete /
tasks/{taskId}/incomplete を叩き、
サーバ側のステータスも連動することを確認しました。
現状は「クライアント側から手動同期」を前提にしていますが、
実運用では定期同期や差分同期、二重起票の防止など、もう一段階踏み込んだ運用設計が必要です。
また、syncTasks1.php で扱う MySQL テーブルも暫定設計のため、
取引先コード変換表などを含めて再設計する余地があります。
認証→同期→カテゴリ展開→タスク完了チェック→新規タスク作成までをまとめたデモ動画です。
PHP サーバ側では、どのユーザがいつ同期したか、 どの calendarId を対象にしたかをログとして残し、 後から運用上の問題を追いやすい形にしています。
今は「カテゴリ × タスク × 予定」という構造ですが、
実際の業務では「案件」「取引先」「担当者」など、別の軸からも眺めたい場面が多くあります。
今後は MySQL 側の取引先コード変換表と組み合わせて、
「〇〇社の案件だけを絞り込んだ週次ダッシュボード」のような粒度で見られるUIに発展させたいと考えています。
このアプリの開発ロードマップを、 認証・同期基盤・UI改善・サーバ側整備の4つに分けて整理しました。
LINE WORKS API、OAuth2、Room、PHP、MySQL……と技術スタックは盛りだくさんですが、 実際に会社のタスクや予定が自分のアプリに流れてきたとき、 「ああ、自分のコードが現場とちゃんとつながったな」と実感しました。
・OAuth はドキュメントが長くて何度も心が折れかけたけれど、
・一度フローを理解してしまえば、他のサービスにも応用できる強い武器になると感じました。
・「ただ動けばいい」ではなく、「運用したときにどうなるか」を考えながら設計する練習にもなりました。