- 現場で撮った写真の整理が大変
- 写真やメモを簡単にチームで共有したい
- 事務所に戻ってから報告書を書いている
- 要件定義について知りたい
はじめに
現場で設備や製品の不備を発見した時、写真を撮って、ノートにメモして、事務所で報告書を作成して・・・と手間のかかる作業をしていませんか?
写真の整理も大変で、共有サーバにアップロードするのも面倒。
気を抜くとどの写真が何を撮ったものかわからなくなることもあります。
今回は、このような写真付き報告業務を改善したいと思います。
第2弾の今回は、前回検討した解決の方針を基に要件定義をしていきたいと思います。
前回のおさらい
前回の業務課題整理編では、現行業務の課題を洗い出し解決の方向性を検討しました。
方針として挙がったのはこちらの4点です。
- 方針① 写真とメモを残すときにエリアやカテゴリーの情報も登録できる
- 方針② 写真とメモをセットで登録できる
- 方針③ 情報をデータ化する
- 方針④ データを一覧表示し検索やステータス管理を容易にする
方針を眺めてみると「なんらかのITツールを使って業務効率化したい」という方向性が見えてきましたね。
これらを基に、要件定義をしていきます。
要件定義とは何か
そもそも要件定義とは何でしょう。
何のために要件定義が必要なのでしょうか。
要件定義を一言で表すと「業務改善の道しるべ」です。
「最初に作ろうとしていたモノと仕上がったモノがまったく違うものになっていた」なんてことはあるわけないと思いますか?
いいえ、そんなことはありません。
むしろこの「ありえないこと」が頻繁に起きてしまうのが業務改善の難しいところです。
想定外のものが仕上がってしまう原因にはいくつかあると思います。
- 作りながら周囲の要望を取り入れているうちに本来の目的を見失った。
- 気づいたら「ITツールを導入すること」が第一目標になってしまいニーズからずれたものができた。
- 便利機能をたくさん入れたけど実際は使わない。
ここに挙げたものは一部ですが、現場では「あるある」のことばかりです。
ですから一番最初に「何を実現するか」という要件を詰めておく必要があるのです。
利用シーンの整理
要件を決める前に、利用シーンを整理します。
今から導入しようとしているITツールは「いつ」「どこで」「だれが」使うものなのか、詳細を確認していきましょう。
今回の場合に当てはめてみます。
| いつ | 設備や製品の不具合を発見したとき |
| どこで | 現場で |
| だれが | 現場リーダー |
| いつ | 不具合の処置ステータスを知りたいとき・過去事例を検索したいとき |
| どこで | 事務所 |
| だれが | 現場管理者・現場リーダー・現場作業員 |
| いつ | 処置ステータスが変わったとき |
| どこで | 事務所 |
| だれが | 現場管理者・現場リーダー |
整理することで要件を決めやすくなります。
例えば「登録は現場でするからパソコンではなくスマホの方が使いやすそう」「閲覧は事務所だからパソコンでOK」といったぐあいです。
あらゆるシーンを想定して洗い出してみましょう。
利用シーンを整理しないと機能要件を決められないということがご理解いただけると思います。
機能要件
ここまできてようやく機能要件を整理します。
機能要件は「必須機能」と「あったら便利な機能」に分けて考えます。
- メモ登録
- 写真登録(複数枚登録することも)
- エリア登録
- 不具合カテゴリー登録
- 登録内容一覧表示
- 登録内容検索
- ステータス編集
- データ登録時に関係者へ通知
- データ更新時に関係者へ通知
- 承認機能
- 類似案件自動分類
「必須機能」と「あったら便利な機能」に分けて整理する理由は、スコープを絞るためです。
現場の業務改善は「現場の業務」という本業の傍ら、無理やり時間を作って進めていくことが多いと思います。
つまり、時間も予算も人手も限られた状況の中で実施しなければなりません。
あれもこれもと言われるがままに手を付けていれば、運用開始までに時間がかかってしまいます。
後で迷わずに着実に「使えるモノ」を導入するために、最初にしっかりと「必須機能」と「任意機能」に分けておきましょう。
大事なのは「何をやるか」ではなく「何をやらないか」です。
非機能要件
次は非機能要件を整理します。
非機能要件とは、文字どおり「機能ではない要件」のことです。
例えば、ツールを使う端末だったり、どのくらいの人数が一度にアクセスするかであったりです。
今回はこのように整理できました。
- 登録時の利用端末はスマホ
- 閲覧・検索時の利用端末はパソコン
- 登録用ツールは現場管理者がアクセスできるように
- 閲覧・検索用ツールは現場管理者・現場リーダー・現場作業員がアクセスできるように
- ステータス編集用ツールは現場管理者・現場リーダーがアクセスできるように
- 権限管理は不要(誰でも閲覧可能)
- 想定利用人数は30名程度
- データの保存先はSharepointリスト
- 登録用ツールはPower Appsで市民開発する
- 閲覧・検索用ツールはデータの保存先であるSharepointリストをそのまま使用する
非機能要件は最初は取っ付きにくいと思いますが、あまり難しく考えずに思いつくままに書き出してみましょう。
開発方針
機能要件と非機能要件が整理出来たら、開発方針が決まります。
「具体的にどのITツールを使って業務改善を実現するか」ということです。
各ツールの比較検討をするプロセスもここで実施します。
| 利用シーン | 機能 | ITツール | その他要件 |
|---|---|---|---|
| 登録用 | ・メモ登録 ・写真登録(複数枚登録することも) ・エリア登録 ・不具合カテゴリー登録 | Power Apps (データ保存先はSharepointリスト) | ・利用端末はスマホ ・現場管理者がアクセス |
| 閲覧・検索用 | ・登録内容一覧表示 ・登録内容検索 | Sharepointリスト | ・利用端末はパソコン ・現場管理者/現場リーダー/現場作業員がアクセス |
| ステータス編集用 | ・ステータス編集 | Sharepointリスト | ・利用端末はスマホ ・現場管理者/現場リーダーがアクセス |
ここまで来ると、最終形のイメージがかなりクリアになってきました。
画面スケッチ
今回は登録用ツールのみPower Appsで市民開発をすることにしたので、登録用ツールの画面スケッチを作ります。
画面スケッチの作り方に特に決まりはありません。
ExcelやPower Pointを使ってもいいですし、手書きでも問題ありません。

Power Appsはローコード市民開発ツールなので、作りながら修正していく方法でもある程度は形になります。
ですから画面スケッチ作成にこだわりすぎず、このぐらい簡単なもので問題ありません。
色も後から決めれば大丈夫です。
データ項目整理
最後に、保管するデータの項目を整理します。
| 項目 | 内容 |
|---|---|
| タイトル | 日付 + 登録者名 |
| 内容 | メモの内容 |
| 写真 | 添付画像 |
| エリア | 不具合発生エリア |
| 不具合カテゴリー | 不具合の分類 |
| 登録者 | 登録者 |
| 登録日時 | 登録日時 |
| ステータス | 不具合処置ステータス |
| 更新者 | 更新者 |
| 更新日時 | 更新日時 |
次回はSharepointリストを作成していきますが、そのために必要項目を洗い出しておきましょう。
要件定義の成果物まとめ
ここまでで要件定義は完了です。
もし成果物として要件定義書を作るなら、これまで整理した情報を含めます。
- 業務フロー図(前回の記事の内容)
- 機能要件
- 非機能要件
- 画面一覧
- 画面スケッチ
- データ項目一覧
部署の中の業務改善であったとしても、何らかの形でこれらの情報は保管しておくと良いです。
次回:Sharepointリスト設計
今回は要件定義を実施しました。
次回はSharepointリストを作ります。
