はじめまして。
当方いわゆるSIerで、プログラム書いてシステム作ったりkintoneアプリ作ったりしています。

私の感覚になってしまいますが、
NSAS平野様が書かれていらっしゃるようにER図はあったほうが便利だと思います。
図でアプリの全体像が把握できるのは視覚的にも捉えやすいですしね。

他の仕様書はアールスリーインスティテュート様が提供されている
gusukuが大変役に立つかと思います。
https://docs.gusuku.io/features/appspec/

現在、仕様書として残したい項目をアプリのフィールドで
設定しようとしているように見受けられますが、
スタンダードコースを利用中の場合は
マークダウン記法（Wikiみたいな感じ）を使って記録する方法もあるかと思います。
この場合、フィールドで設定するよりも自由度が高くなりますので、何を記載するかを事前に決める必要があります。
https://cybozu.dev/ja/kintone/tips/development/customize/validation-and-assistance/make-documentation-easier-with-marked-js/

後々のことを考えると仕様書を残すことは大事なのですが、
仕様書の中身が多すぎるとアプリを手直しした際に
手直しが必要な箇所が増えることにもなり、
次第に仕様書がメンテナンスされなくなる＝アプリと仕様書にズレが出る
というよろしくない状況を招く一因にもなってしまいます。
このあたりも踏まえて「何を仕様書として残すか」を決められるとよいかと思います。

弊社、アプリ開発をやっておりますので
お客様向け納入物件として
添付のような設計書をおさめております。

基本的には弊社で作成したツールにて
アプリ構築後、kintoneより設計書を後追いですが
作成しております。
サンプルは
・スペース情報
・アプリ関連図情報
・アクセス権情報
・プロセス管理情報
・アプリ項目定義表
その他情報も出力できますが、アプリの設計書情報として
サンプルをご参考に！

その他カスタマイズ情報、プラグイン情報等も必要でしょうね。

こんにちは。普段、製品やサービスの取扱説明書、マニュアルと呼ばれるものを作ってる人です。
ざっくりとこんな感じの進め方かと思います。
参考になればうれしいです。

●アプリが何のために、誰のために作られているのか、作った人に（場合によっては使う人にも）聞いてみる。
●仕様書がどんな風に使われるのか、どこまで必要としているのかを調査して具体化する。
対象がエンジニアだと、一文字ちがってても資料として使えない場合もあるので（結果として信用されるかどうかも含めて）どこまで書くか、記法なども含めて、書く前に書き方を決めておきたいです。マニュアル制作の領域では「執筆ルール」と言ったりします。
→ここまででざっくりとまとめて、アプリの対象者や意図、簡単な使い方を「アプリの説明」欄に入れるとみる人もわかりやすいと思います。

●仕様書がどのような内容なのか「例」を書く&描く。
　対象が初心者だと、どんな場面でどんな風に使う資料なのかが掴みきれない可能性があります。難しく書く必要はなく、文でも絵でも動画でも、伝えたい内容をシンプルに表現するのがいいと思います。
●他社も含む他のサービスの例を参考にする。仕様書として必ず掲載している項目とかあったりします。
●生成AIに聞いてみる（あくまで参考程度に）。
●作った後に検証して、過不足を補う。

こんにちはー！

kintoneアプリストアに「kintoneアプリ管理」というアプリが用意されているので、
それを基に考えると考えやすいかもしれないですね！

私も今後のことを考えると仕様書等残さないとな・・・と考えているところです。

私が思うのは「なぜこのアプリが存在するか」です。
どんな業務のどんな課題を解決するためにこのアプリが存在するのか、を残しておくのはどうでしょう。
目的を達成するためにアプリを改修することはとても重要なことなので、
そんな時にもこういったことがあるとわかりやすいかなとは思います。