公開日：
こんにちは。システム開発グループの大澤です。
kintoneは、「誰でも簡単に業務アプリが作れる」として多くの企業で導入が進んでいます。実際、ドラッグ＆ドロップでフィールドを並べて保存すれば、すぐに業務で使えるアプリが完成します。
この手軽さから、「わざわざ仕様検討フェーズなんて入れなくても、作りながら考えればいいのでは？」と思う方も少なくありません。
たしかに、単純なアプリや個人利用レベルの管理ツールであれば、思いついたまま作っても十分機能します。しかし、企業で使う業務システムとしてkintoneを開発する場合、話は少し違ってきます。
弊社の「キミノマホロ」でも、仕様検討にあたる「ロ-1 kintoneを使った実現イメージ検討」など、お客様と仕様の認識合わせをするステップを定義しています。
今回は「仕様検討で何をするのか」「なぜ必要なのか」について、実際の開発経験を踏まえて解説します。
そもそも「仕様検討」とは？
システム開発をベンダーに依頼すると、多くの場合は以下のような流れになります。
この中で「仕様検討」は、要件を具体的な動きに落とし込む工程です。
「どんなアプリを作るか」を決めるのではなく、「そのアプリがどんな条件で、どんな処理をするのか」を明確にする段階です。
たとえば、
- どのアプリがどのようにデータをやり取りするのか
- 承認や通知のルールはどうなっているのか
- 権限設定は誰がどう管理するのか
- エラーや例外ケースではどう振る舞うのか
といった内容を、図やフロー、ドキュメントの形で整理します。
ここをきちんとやっておくことで、後から「思っていた動きと違った」というトラブルを防ぐことができます。
kintoneはすぐに作れるのに、なぜ仕様検討が必要？
たしかに、kintoneの最大の強みは「すぐにアプリが作れること」です。フィールドを置いて保存すれば、あっという間にアプリができます。
だからこそ、「実際に作って見せた方が早いよね」と思うのも当然です。
しかし、kintoneの開発でよくある誤解がここです。「アプリを作って見せれば、仕様が伝わる」わけではないという点です。
単体アプリで完結するような単純な業務なら問題ありません。けれど、複数のアプリが連携するような業務、たとえば「案件管理」「見積管理」「請求管理」が連動するような仕組みになると、どこでどんな処理をしているのか、アプリを見ただけでは把握しきれません。
アプリだけでは伝わらない「細かい動き」
たとえば、「見積書を確定したら、自動的に請求アプリにレコードを作成する」という連携があったとします。
そのとき、こんな疑問が出てきます。
- 見積書を修正した場合、請求データは自動で更新される？
- キャンセルになったら請求レコードは削除される？
- 担当者が複数いる場合、誰が承認する？
こういった細かい挙動は、アプリを作って見せるだけでは明確になりません。開発者が「おそらくこうだろう」と実装してしまうと、後になって「いや、そうじゃなかった」という手戻りが発生します。
結果として、開発コストが増えるだけでなく、運用中の混乱にもつながります。
運用後の「ここどういう動きだっけ？」問題
運用が始まってしばらくすると、利用者や管理者から「この画面ってどういうルールで動いてるんだっけ？」という質問が出てきます。
そのときに仕様書がなければ、開発者は実際のアプリ設定やJavaScriptコードを追いかけて調べるしかありません。
これは非常に非効率です。詳細はコードで確認するとしても、大枠の動きや考え方、なぜこのような動きにしているかは整理しておくべきです。
また、システムを別の担当者に引き継ぐ場合、ドキュメントがないと何もわからないという状況にもなります。
後からマニュアルを作るときにも、「どの動きを前提に説明すればいいのか」がわからず、二度手間になります。
つまり、仕様検討フェーズでの整理は、開発前だけでなく運用後のためにも重要なのです。
仕様検討時にまとめておくべきこと
仕様検討では、以下のようなドキュメントを整理します。
- アプリ間のデータ連携図（どのアプリがどの情報を使うか）
- 処理フロー（どのタイミングでどんな処理をするか）
- 承認ルートや通知条件の定義
- 権限設定・操作範囲のルール
- エラーや例外時の動き
- マニュアルや操作手順のもとになる仕様
形式にこだわる必要はありません。スプレッドシートでも、図でも、kintone上のドキュメントアプリでも構いません。
重要なのは、「後で見返して分かる形で残すこと」です。
「作りながら考える」ほうが向いているケースもある
もちろん、すべての開発に重たい仕様検討が必要なわけではありません。業務がシンプルで、利用者と開発者が近い距離でやりとりできる場合は、アプリを作りながらブラッシュアップしていくスタイルのほうが向いています。
一方で、関係者が多い、想定ケースが複雑、運用ルールが厳密に決まっているようなシステムでは、事前に仕様を整理して、認識を合わせておくことが欠かせません。
つまり、「作りながら考える」が向くシステムと、「事前に仕様を固める」が向くシステムがあるのです。その見極めを誤ると、後からの修正コストが大きくなります。
仕様検討は“無駄”ではなく、“後悔しないための準備”
kintoneはたしかに「すぐ作れる」プラットフォームです。しかし、それは「すぐ作ってすぐ直せる」という柔軟性があるからこそ、
どこまでをアプリで再現し、どこまでを仕様で明文化するかのバランスが重要になります。
仕様検討フェーズは、単にドキュメントを作る作業ではありません。開発者と利用者が同じイメージを持ち、後で「思っていたのと違う」を防ぐための認識合わせのプロセスです。
小さなアプリなら不要かもしれません。でも、業務全体を支えるようなkintoneシステムを作るなら、最初に少し時間をかけて仕様を整理しておくことが、結果的に一番の近道になります。
まとめ
今回は、私の経験からkintoneシステム開発の仕様検討についての考え方をご紹介しました。
アールスリーは、お客様に長く使っていただけるシステムをつくることを大切にしています。そのために、業務の流れや目的を丁寧に理解し、システムごとに最適な形をお客様と一緒に考えていきます。
キミノマホロ for kintone
アールスリーでは業務改善・システム開発を行うサービスを「キミノマホロ for kintone」として提供しています。
「キミノマホロ for kintone」は業務改善のプロセスをイロハで3つのフェーズに分け、フェーズごとに作業をメニュー化しています。
【イ】業務改善の始まり：業務改善の方向性を決める
【ロ】業務改善に必要なkintoneアプリ作成：業務改善を実現するための仕組み（kintoneアプリ）を作る
【ハ】業務改善の実行サポート：業務改善を進める
システム開発グループではkintoneに関するお悩み相談をお受けする「kintone駆け込み相談室」を随時開催しています。kintoneのシステム開発でお悩みの方がいらっしゃいましたらぜひお申し込みください！
必要なものを、必要なだけ。
業務改善の新しいカタチ。
kintoneを活用した業務改善・システム開発サービス
kintoneを活用した業務改善・システム開発サービス
投稿者プロフィール
- システム開発グループ マネージャー
最新の投稿
kintone2025年11月14日kintone開発の仕様検討って何をするの？- kintone2025年10月17日業務改善アシストをうまく使っていただくために必要なこと
- kintone2025年9月19日kintoneシステムの保守どうしてますか？
- Uncategorized2025年8月15日「シンプル」なシステムを作るために必要なこと
