kintone Advent Calendar 2025

私がkintoneアプリを作るときに気を付けていること

kintone

Last updated at 2025-12-23Posted at 2025-12-22

本記事には、読み手によっては少し強めに感じられる くだけた表現 が登場します。
すべて ネタとして楽しんでいただくこと を目的としたもので、特定の誰かを傷つける意図はありません。

読み進める前に、次の点だけご理解いただけますと幸いです。

書かれている表現は、ユーモアとしての 軽い言い回し です。
もし、少しでも苦手に感じられそうな場合は、無理をせずご自身のペースで読み進めてください。
気軽にクスッと笑っていただければうれしいです。

それでは、リラックスしてお楽しみください。

今の日時、 2025.12.22 21:39

こちらは kintone Advent Calendar 2025 シリーズ2 23日目の記事です。

みなさんこんにちは！株式会社ウィルビジョンの住田です。

~~期限2時間前に何してるんだい？~~

気づいたらもうこんな時間、サクッと書き上げないと。

最近こんなのばっかなんですよね。 kintone のアプリを作るときも、時間に追われながらパパッと作らないといけなくて。それでいて、誰でも分かりやすく使いやすいものにしないといけなくて。

他の人に「このフィールド一覧でアプリ作っておいて」ってお願いすると、みんな個性のある配置をしてきて、たまに分かりづらそうなところがあるから指摘して。趣味が過ぎてしまうこと多々あり……。

ということで、今回はそんな 私が kintone アプリを作るときに気を付けていること 、いわゆる フィールドの配置ルール についてお話ししたいと思います。

今まではちゃんと言葉にしてこなかったけど、これから誰かに伝えるときに使えるように、誰に見せても恥ずかしくないように、整理して記そうと思います。

恥ずかしくないようにね。

気を付けていること

結論から言いましょう。私が気を付けていることは、ズバリ……

...

『起詳展尻(きしょうてんけつ)』を意識する です！

...

真面目な話ですよ？

どういう意味なのか

お察しの通り、これは「起承転結」をもじった当て字です。この間考えました。

よく、物語を考える際に「起承転結を考えろ！」と言われることがありますが、これ結構大事なことで。

順番が前後するだけで、同じことを説明しているはずなのに、核心を捉えるのがとても難しくなってしまう。

kintone のアプリも同じ。同じフィールドのはずなのに、配置する順番によってどこに注目すればいいか分からなくなってしまう。入力するフィールドを探すのが大変で、効率が落ちてしまう。

そうならないために、フィールドの順番には気を付けましょうという話です。

「起承転結」をそのまま適用しようとすると拡大解釈と無理強いがすごいので、逆に言葉自体を無理やり変えてしまおうと。そうして出来上がった言葉が 「起詳展尻」 です。

この「起」「詳」「展」「尻」の順番になるように縦に配置していくだけで、簡単に分かりやすいアプリを作ることができると思います。

それでは、各文字の意味を説明していきましょう。今回はサンプルとして「パーソナルジムの会員管理」を想像して作ったアプリを使って解説していきます。これは今作りました。

💡まずは「起」

初っ端から、当て字にしたはずなのに変わっていない？
仕方ないじゃないですか、最後まで思いつかなかったんだもの！

「起」は ユーザーがそのレコードを識別できる (=気づく¹/起点となる) 情報 のことを指します。

例えば「会員名」とかは最たる例で、一番上に持ってくるべき情報です。これが目立つところに無いと困ります。

「会員コード」はどうなの、というと、実はユーザーの要望によって位置が変わります。

例えば「会員コードで覚えている」事務員がいるとか、「会員券に書かれている会員コードで検索する」必要がある場合は一番上に持ってくるべきです。

逆に「会員コードは全然見ない」「機械的なコードだから運用には必要ない」という場合は、一番上に持ってくるべきではありません。この場合は後述しますね。

めｔｔｔっちゃかみ砕いて言えば 普段の検索条件に使用する情報 は「起」にあたります。

🔍つづいて「詳」

「詳」は レコード詳細画面を開いて確認するような情報 (=詳細) をまとめる部分 のことを指します。

例えば「住所」とかはここに入ります。今回のケースが会員なので、まあ会員になってる人をわざわざ住所で検索しないでしょうと。

あとは「アンケート結果」とかもそうですね。会員アプリに持たせるべきかは謎ですが、まあこのあたりに入れておきましょう。

サブテーブルとかもこのあたりに入るでしょう。「明細」とも言われますしほぼ「詳細」ですし。

逆に「都道府県」は、実は「起」に入れても良いケースがあります。営業管理とか、テレアポ管理とか。エリアで絞り込むことが日常茶飯事なのであれば一番上に持ってくるほうが良いこともあります。

ここもユーザーの要望に合わせて調整するべき部分ですね。

🔭実は難しい「展」

「展」は そのデータに繋がっているデータ (=展開) を表示 (=展望) する部分 です。

今回のケースで行くと「家族一覧」とか「契約ロッカー」とかが想像できますね。かみ砕いて言えば 関連レコード のことです。

レコード画面の上の方にも下の方にも関連レコードが散らばっていると、とても見づらいです。行の高さがまちまちになるし、明らかに上の方の関連レコードが注目されて、下の方の関連レコードに目がいかなくなります。

かといって、何も考えず下のほうに設置すればいい、ということを言いたいのではありません。下に設置することでスクロールに時間がかかり、情報にたどり着くまで時間がかかります。

伝えたいのは 関連づいたデータは「詳」の情報より優先度が低いことが多い ということです。

例えば会員のレコードを開いたときに、「家族一覧」より本人の「住所」のほうが情報として使うことが多いはずです。「アンケート結果」も同じです。使う頻度、使う目的を考えれば、そのデータ自体の情報ではない関連レコードなどは「詳」より下でよいはずなのです。

逆に言えば そのデータ自体の情報として扱いたい関連レコードは「詳」にあるべき とも言えます。キー文字列だけあって関連レコードで各アプリを繋げているポータルアプリや、その人の家族情報を管理しているアプリなんかは、関連レコードがメインコンテンツと言っていいでしょう。その場合は「展」ではなく「詳」に関連レコードを設置すべきです。

他にも、ルックアップ代わりの関連レコードとか、入力支援のための関連レコードとかも、わざわざ「展」のエリアに持ってこなくても良いと思います。

関連レコードは kintone ならではの機能なので、工夫に工夫を重ねて使い倒されているのを結構見かけます。そうした工夫については、このルールに無理に当てはめる必要は無いと考えています。

あくまで、そのデータ自体の情報ではない、関連づいたデータはここにまとめるべき、という話です。

🩲最後に「尻」

「尻」は ユーザーが利用する際のノイズになるものは隠す という意味です。

例えば「会員コード」があるのに「レコード番号」をわざわざユーザーが使うことはありません。「作成日時」も「更新日時」も、独自にフィールドを作って管理したほうが運用上便利な場合はたくさんあります。

だけど kintone の仕様上、アプリに追加しておかないと色々不便なことがある。カスタマイズを作るときに困ってしまう。だから仕方なく、システムの都合上追加する……。正直、ユーザーからは無駄なフィールドが増えているだけです。

そうしたフィールドは グループで隠しましょう 。

私はよく「システム情報」というグループをレコードの一番下に作成して、その中に「レコード番号」「作成日時」「作成者」「更新日時」「更新者」を設置しています。ほかにも、ユーザーが使うことのない「条件分岐用計算フィールド」や「行数カウント」といった、カスタマイズ上でしか使わないフィールドもそのグループに含めるようにしています。

「更新日時」や「更新者」とかは一番上にあったほうがいいじゃん、と思われる方もいるかもしれません。誰が更新したか一目でわかるようにとか、不正な更新にすぐ気づけるようにとか。でも実際のところ、ユーザーがレコードを開いたときに「このレコードの更新日時はおかしい」って気づくことなんて稀です。よっぽど普段から更新日時をチェックしているようなユーザーでないと、その変化には気づきません。

この場合、「最近更新されたレコード」みたいな一覧を用意して、それを確認するようにしたほうが効率的です。わざわざレコードの一番上に設置しておく必要はありません。

ユーザーが使わないものは隠す。それが「尻」です。