
こんにちは、ジムリンです!
実は、読者の方からいただいた質問をいただきました。
ボクもまだまだ経験が浅いのでわからないことも多いですが、一緒に考えてみたいと思います!
目次
備品購入申請システムを作りたい!
📩 読者からの質問
ジムリンさん、はじめまして。
製造業で総務を担当している者です。
kintoneを使い始めて数ヶ月経ちますが、まだまだ勉強中です。
最近、各部署から備品の購入申請が増えてきて対応に追われています。現在は申請書を印刷して手書きで提出してもらっているのですが、申請内容の確認や承認フローが煩雑で困っています。
申請する側も毎回備品名や単価を書くのが大変そうなので、よく使う備品を備品マスタに登録しておいて、そこから選択するだけで申請できるようにしたいと考えています。
やりたいことをまとめると、こんな感じです。
- よく申請される備品を備品マスタに登録
- 備品マスタから選択すると申請フォームに情報が自動入力される仕組み
- マスタに未登録の備品にも対応したい
- 金額に応じて承認者を変えたい(1万円未満は課長、それ以上は部長承認など)
今困っているのは、備品マスタから申請アプリを立ち上げる具体的な方法がわからないことです。
どのような手順で作れば良いでしょうか?
ボクがやるとしたら、まずある程度データを入れた備品マスタを作って、備品購入申請アプリを作ります。
そして、アプリアクションを使って備品マスタから備品購入申請アプリを立ち上げられるようにします。
ジムリン、ちょっと待って!
アプリを作る前に「想定される使い方」を整理しよう!
ジムリンが考えたアプリ、実際に使ってみたらどうなると思う?
え!備品マスタを眺めながら、欲しいものをクリックして購入申請ができると思います……
欲しい備品が複数あったらどうするの?
むむ……。
それは、マスタから1つずつ探して、申請してもらう形かな?
本当にそれで現場の負担は軽くなるの?
「紙のほうが楽でいいや!」ってならない?
う……、たしかに……。
紙に書いたほうが早いかも(゚Д゚;)
ね。
kintoneでありがちなのが、アプリにフォーカスした結果、使い始めてから「もっとこんな機能が必要だな」と気づくこと。
そうならないように、まずは要件を整理したいよね。
だから、まずはユースケース図を描いてみよう!
ユースケース図で「想定外」を減らせる!
コーさん、ユースケース図ってなんですか?
ユースケース図は、ユーザーの目線から「このシステムで何ができるのか」を明確にする図だよ。
アプリの機能を考える前にこの図を描くことで、現場運用での「想定外」を減らせるんだ。
ユースケース図を描くことで、こんなメリットがあるよ。
【ユースケース図を描くメリット】
・ユーザー視点でシステムを設計できる
・必要な機能が見えてくる
・複数のパターンや分岐が明確になる
なるほど!さっそく描いてみます!
ユースケース図の描き方|押さえておきたい4つのポイント
描いてみました!
こんな感じでどうですか?
うーん、惜しい!
がんばって描いたのはわかるけど、いくつか直したほうがいいポイントがあるよ。
1.体言止めはNG!動詞を使おう
「備品検索」「購入申請」って書いてあるけど、これは体言止めだね。
ユースケースは動詞で終えるのが基本だよ。
動詞を使うことで、システムを使う人たち(アクター)の具体的なアクションが明確になるよ。
なるほど……。
「備品検索」は「備品を検索する」
「購入申請」は「備品の購入を申請する」
というようになるんですね!
2.具体性を持たせよう
今回は「備品」と言っているからある程度想像できるけど、「何を購入するのか」「何を検索するのか」によってやることが変わるよね。
ジムリンが考えている備品っていうのは、具体的には何のことなの?
コピー用紙や安全ヘルメットなどの消耗品を考えていました!
うんうん。
ここに「工場で使う材料」などが入ってくると、購入フローが変わってくるはずなんだ。
今回は事務所や工場で使う「備品」にフォーカスする。
それは、たとえばコピー用紙や安全ヘルメットなどの消耗品のこと。
ここまで具体化することで、より実態に即したユースケース図を描けるはずだよ。
3.アクターを見直そう
ここに描いてくれている「現場の作業員」や「総務」といった登場人物のことを、ユースケース図では「アクター」と呼ぶよ。
今回のアクターは、本当にこの2種類でいいの?
たとえば、コピー用紙の購入を申請する人は現場の作業員だけじゃないんじゃないかな?
たしかに(゚Д゚;)
あんまり考えていませんでした……。
事務所のみんなのほうが申請しますよね。
そうだよね!
今「現場の作業員」となっているアクターは、もっと広く捉えたほうがいいね。
4.5W1Hで考えよう
ユースケースは、利用シーンをはっきりとイメージできるようにすることが大切なんだ。
だから、できるだけ5W1Hを明確に書くことをおすすめするよ
・誰が(Who)
・どこで(Where)
・いつ(When)
・何を(What)
・なぜ(Why)
・どのように(How)
ってことですよね?
そうそう。
ユースケースを具体化すると、本当に必要な要件が見えてくるからね。
ただし、ユースケースで明確にしたいのは「そのシステムで何がやりたいのか」であって、目的なんだ。
要は、システムでできることを整理したいので、5W1Hすべてを書き出す必要のないときもあるよ。
たとえば、How(どのように)はユースケースというよりは、システム設計寄りの要素だよね。
また、今回はWhere(どこで)に大きな変化がないので、なくても大丈夫そうだよ。
つまり、利用シーンを具体化するときは5W1Hで整理するのが基本。
ただし、すべての要素を丁寧に洗い出すというよりは、そのシステムの目的がわかるように、必要な要素を書き出すってことですか?
そうだね!
各要素には優先度があるよ。
以下はなるべくマストで書き出してみて!
・誰が(Who)
・いつ(When)
・何を(What)
・なぜ(Why)
| No. | 誰が(Who) | いつ(When) | 何を(What) | なぜ(Why) |
|---|---|---|---|---|
| 1 | 申請者(従業員) | 備品を探すとき | 備品を検索する | 購入したい備品を見つけるため |
| 2 | 申請者(従業員) | マスタに備品がある場合 | マスタから備品を選んで申請する | 登録済み備品を簡単に申請するため |
| 3 | 申請者(従業員) | マスタに備品がない場合 | マスタにない備品を手入力で申請する | 新しい備品も購入できるようにするため |
| 4 | 申請者(従業員) | 申請が差し戻されたとき | 申請内容を修正する | 指摘された内容を訂正するため |
| 5 | 申請者(従業員) | 修正が完了したとき | 申請を再提出する | 再度承認を得るため |
| 6 | 承認者(総務担当者) | 申請が提出されたとき | 申請内容を確認する | 購入の可否を判断するため |
| 7 | 承認者(総務担当者) | 申請内容が適切なとき | 申請を承認する | 購入を許可するため |
| 8 | 承認者(総務担当者) | 申請内容に問題があるとき | 申請を差し戻す | 修正や追加情報を求めるため |
| 9 | 承認者(総務担当者) | よく使う備品を登録するとき | 備品マスタに未登録備品を登録する | 申請時の入力を簡単にするため |
| 10 | 承認者(総務担当者) | 申請が承認されたとき | 承認済み備品を発注する | 実際に備品を購入するため |
いいね!今回、Whereはすべて備品購入申請アプリになるから、不要という判断だね。
情報量が多くなってかえってわかりにくくなるからHowも不要。
この表を見て、何か気づくことはある?
いろいろありますね!
たとえば、備品を検索したあと「マスタに備品がある場合」と「マスタに備品がない場合」で分岐があります。
そういえば最初にコーさんに指摘されたことですよね。
また、申請が差し戻されたあとに「申請内容の修正」と「申請の再提出」が必要そうです。
最初のシンプルな図だけでは、これらのパターンが見えていませんでした!
表を作る前よりも具体的なシーンが見えてきたでしょ?
特に「いつ(When)」のところで分岐が明確になったね。
今回みたいな流れもいいけれど、先に表で整理してからユースケース図に落とし込むという方法もあるよ。
この内容を反映した詳細なユースケース図を描いてみよう。
具体化したユースケースを図に落とし込もう
表をもとに、詳細なユースケース図を描いてみました!

ピンク色の部分が、今回増えたところです。
「備品の購入を申請する」だけだったアクションが2つに分かれて、より具体的になりました。
また、「申請を再提出する」という独立したアクションが追加されています。
素晴らしい!
ユースケース図を段階的に掘り下げることで、必要な要件が見えてきたね。
たとえば最初は考えていなかった「マスタにない場合の対応」や「差し戻しフロー」が見えてきたでしょ?
本当ですね!
いきなりアプリを作り始めていたら、あとで「このフローも必要だった!」とやり直しになっていたかもしれません。
ちなみに、ユースケースを出すのってすごく難しいんだよ。
何十年も開発をやっている人でも「ユースケースって大事だよね」って言うくらい、奥深いものなんだ。
ジムリンが作ったものも完璧だとは言えないけれど、最初よりもずっとよくなったよ。
ユースケース図から見えたこと
・備品マスタを作る
・備品購入申請アプリを作る
・備品マスタからアプリアクションで備品購入申請アプリを立ち上げる
これで、「よく使う備品を備品マスタに登録しておいて、そこから選択するだけで申請できるようにしたい」という部分は解決できます。
しかし、実際にユースケース図を描いてみると、それだけでは利用者のニーズを満たせないことがわかりました。
たとえば、備品マスタに未登録の備品の購入を申請したい場合、申請者か承認者のどちらかがマスタに登録する必要があります。
現場の負担を軽くしたいというのであれば、登録は承認者側で行うのが無難でしょう。
そうなると、マスタから備品を選んで購入を申請するパターンと、マスタにない備品を自由記述で申請するパターンに対応する必要がありそうです。
だから、ボクが言ったアプリアクションだけでは根本的な解決になっていないということですね……。
具体的なアプリ構成や必要な機能は、あらためて質問者さんにも考えてもらおうよ。
まずは自分自身でユースケース図を描くことが大切。
そうすると、これまでは見えなかったことが見えるからね。
具体的なアプリ設計は、環境や運用によって変わるんだ。
だから、ジムリンが考えた設計が必ずしも質問者さんの環境にフィットするとは限らないよ。
なるほど!
だったら、今回はユースケース図を描くというヒントをもとに、質問者さんにもう一度アプリ設計を考える段階に立ち返ってもらったほうがよさそうですね。
今回、ボクが教えてもらったユースケース図の描き方を参考に、質問者さんもユースケース図を描いてみてください。
そうすると、足りない部分が見えてきて、全体的に必要な要件がはっきりするはずです!(^^)!
まとめ:ユースケース図は描いた?kintoneのアプリ設計で悩んだらユースケース図に立ち返ろう
アプリ設計で悩んだときは、まずユースケース図に立ち返ることが大切です。
もし、ユースケース図を描かずにアプリを作り始めていたなら、一度手を止めて要件整理からやり直してみましょう。
すると、今やっていること、考えているがそもそも間違っていることに気づく場合があります。
ボクも、ユースケース図を描いてみて、最初の考えだけだと利用者のニーズを満たせないことに気づけました(;゚ロ゚)
今回いただいた質問に対して、こんな方法もあるよ!というアドバイスがあれば、ぜひボクに教えてください!
また、こんなアプリを作りたいんだけどジムリンならどうする?という質問も募集しています。
まだまだ経験の浅いボクですが、みなさんと一緒に考えながらレベルアップしていきたいので、気軽にメッセージをくださいね!

