Slackアプリで始める業務日誌（その１）- 基本操作 -

1. はじめに

先日、業務日誌について書いた投稿がこちらになります。

/blogs/2026/01/06/businessdiary/

ただ、

ここは技術ブログなので、記事だけだと片手落ちな気がする。
自分は技術者なんだから、せっかくだから何か作りたい。

と思いましたので、業務日誌を題材にアプリを作りました。
（あくまで学習用のサンプルアプリになりますが）

また、最近、社内研修で要件定義、設計、文章の書き方などを
学びましたので、練習を兼ねてこれらも実施しました。

そこで、本記事では、業務日誌アプリを題材に
要件定義〜設計をどのように整理したかを中心に紹介します。
私と同じようにアプリを作成するエンジニアの方向けに、設計の良し悪しではなく、作業の過程について共有できればいいなと思っています。
なお、実装したアプリそのものについては、本記事では割愛し、別記事で公開したいと思います。

2. アプリを開発する

まず、今回のゴールとしては、業務日誌を作成するアプリの必要最低限の機能のみを開発します。
前回のブログでSlackを使用して業務日誌を作成していることに触れていることも踏まえ、
今回はSlackのアプリを作成してみます（技術要素は別途、以下で整理します）。
開発は以下の手順で進めます。
1. 要件定義
2. 設計
3. 製造・テスト（ブログ上では詳細割愛）

2-1. 要件定義

本記事で中心となる内容で、少し記述量が多くなってしまいましたが、
よろしければお付き合いいただければと思います😓
要件定義では、要望→要求→要件→仕様の順に作成していきます。

2-1-1. 要望を書いてみる。

まず、要望ですが、要望とは「システム（今回はアプリ）で実現したいこと」となります。
とりあえず、業務日誌アプリでできそうなことを思いつくまま書き出してみます。

Information

業務日誌を自動で作成してほしい。
手書きは面倒なので、アプリで自動生成してほしい。
業務日誌を自動で報告してほしい。
Slackのチャネル投稿するなど、報告を自動化したい。
決められた時間に業務日誌を作成・報告してほしい。
定時前などスケジュールに基づいて業務日誌を作成・報告してほしい。
業務日誌の体裁を調整したい。
業務日誌のテンプレートを作成して、日誌の体裁を整えたい。
作業は随時登録したい。
業務日誌に記載する作業は、業務中につど登録したい。
（日誌を作成時に考えるのは、効率的ではないので、事前に登録しておきたい）
作業の状況を管理したい。
作業状況が分かるようにしたい。
登録した作業は保管しておきたい。
アプリを停止、再開した後も作業が参照できるようにしたい。
作成した業務日誌は保管しておきたい。
アプリを停止、再開した後も業務日誌が参照できるようにしたい。
業務日誌の要約したい。
作成済みの複数日の業務日誌を要約して、週報、月報、あるいは、評価面談用の資料としたい。
フィードバックがほしい。
作成した業務日誌の内容についてフィードバックがほしい。
（AIとかにレビューさせるとかできるかも）

2-1-2. 要求を書いてみる。

次に、要求ですが、要求とは「要望の内、実現するものとして採用されたもの」となります。
今回は、業務日誌アプリとして必要な最低限な要望のみを要求として選択します。
よって、要求は以下のとおりとします。

Information

作業を登録したい。
業務中に実施する作業を登録できるようにします。
登録した作業を確認したい。
登録した作業が確認できるようにしたい。
作業のステータスを設定したい。
登録済みの作業に対して、作業ステータスが設定できるようにします。
作業ステータスは、以下のとおりとします。
- 未着手
- 作業中
- 完了
業務日誌を作成したい。
登録済みの作業から業務日誌を作成します。
業務日誌には「当日実施した作業一覧」と「翌日実施する作業予定一覧」が登録されています。
登録した作業を保存しておきたい。
登録した作業が消失しないようにします。
作成した業務日誌を保存しておきたい。
作成した業務日誌が消失しないようにします。

1.-4.はいいかと思います。5.6.はちょっと違うような気もしますが、いったんよしとします。
登録と永続化って大抵はセットなので、どこかで1つにしたほうがいいとは思うのですが。

2-1-3. 要望のうち、要求に含めないもの。

要望として挙げたもののうち、要求としないものについても、一応明記するようにします。

Information

業務日誌の自動生成
業務日誌の生成はアプリの機能としますが、生成処理の起動は手動で行うこととします。
業務日誌の自動報告
報告は手動で行うこととします。
業務日誌のスケジュール生成
必須機能ではないので、対象外とします。
業務日誌のテンプレート
今回は業務日誌のテンプレートは決め打ちとします。
業務日誌の要約
必須機能ではないので、対象外とします。
業務日誌へのフィードバック
必須機能ではないので、対象外とします。

2-1-4. 要件を書いてみる。

続けて、上記の要求を基に要件を定義してみます。
要件とは「完成したシステムが実現することを定義したもの」となります。

Information

ユーザーは、アプリの画面から作業が登録できなければならない。
ユーザーは、アプリの画面上で、登録した作業の一覧を確認できなければならない。
ユーザーは、アプリの画面から、登録済みの作業に対して、定義された作業のステータスを設定できなければならない。
ユーザーは、アプリに業務日誌の作成を指示できなければならない。
アプリは、登録済みの作業を基に業務日誌を生成し、その内容をユーザーに提示しなければならない。
ユーザーがアプリを停止、再開しても、停止前に登録した作業が参照できなければならない。
ユーザーがアプリを停止、再開しても、停止前に作成した業務日誌が参照できなければならない。

2-1-5. 仕様を書いてみる。

最後に、仕様を定義してみます。
仕様とは「網羅的に記述された要件」となります。

Information

作業の登録

ユーザーは、画面から作業内容を入力する。
アプリは、ユーザーが入力した作業内容に加え、以下の内容を合わせて登録する。
- 作業ID
- 登録日
- 作業ステータス
作業IDは、作業を一意に特定できる識別子とする。
登録時点の現在日を登録日として登録する。登録日の書式はyyyy/MM/dd とする。
登録日は、ユーザーが作業登録を実行した時点の日本標準時（JST）に基づく日付とする。
また、作業のステータスを未着手として設定する。
作業内容は必須入力とし、前後の空白文字を除去した結果が空文字列となる場合は無効とする。
作業内容が未入力の場合、アプリは登録が失敗した旨のメッセージを表示して、処理を終了する。
作業内容として入力可能な文字数の上限は100文字とする。この時、全半角は考慮せず、どちらも1文字として扱うこととする。

作業の一覧確認

ユーザーはアプリへ登録済みの作業の一覧を表示するように指示する。
アプリは画面上に登録済みの作業の一覧を表示する。
一覧は登録した順序（作業ID）の昇順で表示する。
一覧には作業内容、登録日、作業ステータスを表示する。

作業ステータスの変更

ユーザーは、対象となる作業を指定し、作業ステータスを変更できる。
作業ステータスは、未着手、作業中、完了の3つとする。
ユーザーが存在しない作業（作業ID）を更新しようとした場合、アプリは設定が失敗した旨のメッセージを表示して処理を終了する。
ユーザーが規定のステータス以外に更新しようとした場合、アプリは設定が失敗した旨のメッセージを表示して処理を終了する。
アプリはユーザーが入力した作業IDと作業ステータスで指定された作業のステータスを更新する。
ステータス間の遷移に制約は設けないこととする。ユーザーが指定したステータスを必ず設定するようにする。

業務日誌の生成

ユーザーは画面上から、アプリに対して業務日誌の生成を指示する。
アプリはユーザーの指示を受け、登録済みの作業から業務日誌を作成する。
業務日誌には以下の項目で構成される。
- 生成日
- 当日実施した作業の一覧
- 翌日実施する作業予定の一覧
生成日は、業務日誌を生成時の現在日を表示する。
生成日の表示形式は yyyy年MM月dd日（WeekDay）とする
※WeekDayは曜日で、月、火、水..といった値となる。
生成日は、日誌作成時点の日本標準時（JST）に基づく日付とする。
当日実施した作業の一覧には、次の条件をすべて満たす作業を含める。
- 当日中に作業ステータスを更新している。
- 作業ステータスが作業中、あるいは、完了である。
翌日実施する作業予定の一覧には、次の条件をすべて満たす作業を含める。
- 作業ステータスが未着手、あるいは、作業中のどちらかである。

作業の保存

ユーザーが作業を登録した際に、アプリは作業を永続化する。
ユーザーが作業の一覧を確認する際に、アプリは作業の一覧を永続化された作業から生成する。
ユーザーが作業のステータスを設定した際に、アプリは永続化された作業のステータスを更新する。

業務日誌の保存

アプリは業務日誌を生成した時に、生成した業務日誌を永続化する。

2-2. 設計

2-2-1. 方式設計

アプリ全体の設計方針について記載します。
設計フェーズなので、具体的な技術要素についても記載します。

Information

アプリケーションはSlackアプリとして実装します。
- アプリにUIが必要ですが、デスクトップアプリを作るのはちょっと大げさだと感じました。
- 業務では、Slackを利用していますので、Slackで業務日誌を作成できると、
  作成→報告が一箇所でできるのでベターかと思いました
- Bolt for JavaScriptフレームワークを使用します。
データを永続化するために、DBを利用します。DBはSQLiteを採用します。
- 今回はローカルで動作するサンプルですので、
  軽量なインメモリデータベースで十分だと思います。
永続化層にO/RマッパーとしてDrizzle ORMを採用します。
- https://orm.drizzle.team/
- これは個人的な好みです。
開発言語はTypeScript（JavaScript）を使用します。
- 前述のBoltフレームワークではPython、JavaScriptが利用できますが、
  あいにく、Pythonは不得手ですので、得意なJavaScriptを使用します。
- Denoは使用しないこととします。
  Bolt for JavaScriptではDenoが利用でき、個人的にもDenoは嫌いではないのですが、
  Denoがそこまで浸透しているかが不明ですので、今回はいったん見送ります。

2-2-2. 機能設計

仕様の5と6、登録した作業、業務日誌の保存（永続化）は
それぞれ、1と４にマージします。
結果として機能が４つとなりますので、それぞれについて記載します。

Information

作業を登録する
1. 作業内容の入力
  1. 作業内容はアプリのDMにメッセージとして入力します。
2. 作業内容の検証
  1. 作業内容が未入力の場合、エラーメッセージを表示します。
    エラーメッセージはアプリからの返信として表示します。
  2. 作業内容が100文字を超過する場合、エラーメッセージを表示します。
    エラーメッセージはアプリからの返信として表示します。
3. 作業内容の登録
  1. 作業内容の登録はSlackアプリのコマンドを実行することで起動します。
  2. 作業内容をDBに保存します。
    保存する内容は、入力した作業内容、登録日、初期作業ステータス（未着手）になります。
作業を確認する
1. 作業一覧を表示する。
  1. コマンドを実行することで作業の一覧を表示するようにします。
    作業の一覧の各項目は、作業内容、ステータス、設定ボタンの4項目とします。
    ステータスは変更できるように、セレクトボックスで表示します。
    ステータスの初期値は登録済みの作業ステータスの値となります。
    作業の一覧は登録順（ID順）の昇順とします。
  2. 作業が未登録の場合は、エラーメッセージを表示します。
    エラーメッセージはアプリからの返信として表示します。
作業ステータスを設定する
1. 作業ステータスの更新
  1. 作業一覧に表示されている、設定ボタンを押下することで、
    作業ステータスの値を選択している値に設定します。
業務日誌を生成する
1. 業務日誌を生成する。
  業務日誌は、文章（テキスト）とします。
  業務日誌には、当日実施した作業の一覧、および、翌日実施した作業の一覧を含めます。
  当日実施した作業の一覧は、作業ステータスが作業中、あるいは、完了となっている作業となります。
  翌日実施した作業の一覧は、作業ステータスが未着手、あるいは、作業中となっている作業とします。
  該当する作業が存在しない場合は、作業の一覧ではなく、テキスト”作業が存在しません”を業務日誌に含めるようにします。
  コマンドを実行することで業務日誌を生成します。
  生成した業務日誌は、アプリからの返信として表示します。
2. 業務日誌の保存
  生成した業務日誌はDBへ保存します。
  登録内容は、業務日誌ID、登録日、業務日誌の3項目とします。

2-3. 図

設計の練習を兼ねて、作図も行います。

2-3-1. ユースケース図

2-3-2. ドメインモデル

2-3-4. ロバストネス図

3. 作成したアプリについて

アプリを作成したので、ここでは動作結果のみを記載します。
※アプリ自体については別の記事で言及できればと考えています。

3-1. 機能の動作確認

3-1-1. 作業を登録する

まずは、作業を登録します。
/task_add コマンドに、引数として作業内容を設定して送信。

登録に成功するとメッセージが返信されます。

3-1-2. 作業を確認する

次に、登録した作業を/task_listコマンドで表示します。
一覧表示は引数なしのコマンドとなります。

一覧が登録順に表示されます。
また、ステータスが更新できるようにステータスをセレクトボックスで表示し、更新処理を実行するためのボタンを配置しました。

なお、動作確認用に３つのタスクを登録しています。

3-1-3. 作業ステータスを設定する

さらにステータスを変更してみます。
３つの作業のうち、１つを作業中に、もう１つを完了に変更します。

アプリ上でステータスを変更して、更新ボタンをクリックすると、
ステータスが更新され、メッセージが返信されます。

3-1-4. 業務日誌を作成する

最後に業務日誌を生成してみます。
こちらは/businessDiary_createコマンドを実行します。

コマンドの受け付けに対して、応答を返した後、
生成された業務日誌が表示されます。
当日の作業一覧に作業中、あるいは、完了の作業が表示されます。
また、翌日の作業予定一覧に未着手、あるいは、作業中の作業が表示されます。

4. まとめ

本記事では、業務日誌を題材に、アプリケーションの要件定義、設計、実装を行ってみました。個人の学習の一環として取り組んだ内容の整理になりますが、
同じように設計に悩みながらアプリを作っている方の参考になれば幸いです。

実際に取り組んでみた所感としては、以下のように感じました。

業務外の作業なので、所々手抜きもあるのですが、
それを別にしても、まだまだ至らない点があるので、こういった作業を通じて、能力向上ができればなと思いました。
また、こういったサンプル程度のアプリでも、実際に要件定義・設計すると、
結構なボリュームになったなと感じています。
ただ、アプリの開発自体は（体感としては）スムーズに進んだようにも思えましたので、こういった要件定義、設計のプロセスというのは無駄ではないと思いました。
以前、ローコードツールを使用した開発を行っていましたが、ツールの「生成した成果物（コード）＝設計書」という思想の影響で、設計を行わずに実装することが多かったです。
ですが、今回のように設計 → 実装の流れで作業すると、ローコードでなくても、事前に設計を実施してから実装に着手したほうが作業が捗るように感じました。理由としては、実装中にトライ・アンド・エラーで作業するよりも、事前に設計を文書化するほうが、仕様をよりよく理解できるためだと思います。

業務日誌アプリについては、今後、技術習得も兼ねて、機能拡張していければと考えています。また、採用した技術要素についても、別途記事として公開できればと考えています。