前置き
少し前ですが、 cybozu developer network でこんな記事が公開されていました。
アプリの使いにくさが利用者が敬遠する理由になりますよ、
ユーザーニーズを汲み取って使い勝手が良く見やすいものを目指しましょうよ、
そのためこう言った工夫をすると良いですよ、
と、ざっくり言うとそう言った内容です。
kintone アプリ開発に携わる人は必読の内容だと思いますが、この記事の中の
フォーム設定でできる工夫 - その 1：フィールド幅をそろえる
のセクションで カラム の概念に言及されていたため、これについて少し深堀りしてみたいと思います。
カラムとは
多くの読者の皆さんにとってはもはや釈迦に説法かとは思いますが、今日びの一般的な Web サイトはレスポンシブデザインの考え方が広範に取り入れられています。
レスポンシブデザインの肝となるグリッドシステムの文脈の中で登場する「カラム」と言う用語は、横幅を同サイズの列に分割した個々の単位を表します。
Web サイト・Web システム界隈のグリッドシステムでは 12 カラムグリッドが一般的です。
この 12 と言う数字は、2 でも 3 でも 4 でも 6 でも割り切れる数字で、それだけレイアウトの自由度が高い、それでいてレイアウトの統一感を維持できる数字として重宝されています。
ちなみに Copilot さんにこう訊いたら・・・
レスポンシブデザインのグリッドシステムが12カラムであるのはどのような理由からですか？
こう教えてくれました。
レスポンシブデザインのグリッドシステムが 12 カラムである理由はいくつかあります：
柔軟性: 12 は多くの数で割り切れるため、2、3、4、6 カラムなど、さまざまなレイアウトに簡単に対応できます。これにより、デザインの柔軟性が高まります ²。
標準化: 多くのフレームワーク（例えば、Bootstrap）が 12 カラムのグリッドシステムを採用しており、これがデファクトスタンダードとなっています ²。
視覚的なバランス: 12 カラムは、視覚的にバランスの取れたレイアウトを作成するのに適しています。カラムの幅が均等であるため、コンテンツが整然と配置されます ²。
歴史的背景: 印刷物のデザインからの影響もあり、12 カラムのレイアウトは長い歴史を持っています。これが Web デザインにも引き継がれています ²。
このように、12 カラムのグリッドシステムは、デザインの柔軟性、標準化、視覚的なバランス、そして歴史的背景から広く採用されています。
他にデザインに関する質問があれば、どうぞお聞かせください！
ソース: Copilot との会話、 2024/7/30
(1) 第 2 回 グリッドシステムとブレイクポイントを理解する | gihyo.jp. https://bing.com/search?q=%e3%83%ac%e3%82%b9%e3%83%9d%e3%83%b3%e3%82%b7%e3%83%96%e3%83%87%e3%82%b6%e3%82%a4%e3%83%b3%e3%81%ae%e3%82%b0%e3%83%aa%e3%83%83%e3%83%89%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0%e3%81%8c12%e3%82%ab%e3%83%a9%e3%83%a0%e3%81%a7%e3%81%82%e3%82%8b%e3%81%ae%e3%81%af%e3%81%a9%e3%81%ae%e3%82%88%e3%81%86%e3%81%aa%e7%90%86%e7%94%b1%e3%81%8b%e3%82%89%e3%81%a7%e3%81%99%e3%81%8b%ef%bc%9f.
(2) Web デザインのレスポンシブ対応グリッド、基本の使い方徹底 .... https://photoshopvip.net/122332.
(3) 第 2 回 グリッドシステムとブレイクポイントを理解する | gihyo.jp. https://gihyo.jp/design/serial/01/bootstrap3/0002.
(4) CSS グリッドでレスポンシブデザインを実装しよう - ferret. https://ferret-plus.com/9676.
(5) 【Bootstrap】グリッドシステムの解説と設定方法. https://dream-net.org/blog/?p=2574.
kintone のフォームのレイアウトへのカラムの概念の導入
kintone で作成したアプリのフォームは残念ながらレスポンシブデザインではありませんが、この cybozu developer network の記事ではこのカラムの考え方を導入する事で視認性の確保と利便性の向上を図れます、と説いています。
記事中では何らかの基準を設けて 4 ～ 5 カラム程度にするのが良いと勧めています。
それでは、その基準となる 1 カラムはどう定義すれば良いのか？
同じ 4 カラムあるいは 5 カラムでも、そのカラム 1 つ 1 つの幅がアプリごとにバラつきがあればそれはそれで利便性・ユーザビリティの低下に繋がるのではないか？
そう言う疑問から、本記事ではカラムレイアウトを採用する際のある程度の最適解を探っていきたいと思います。
フォームの最大幅を考える
昨今の一般的なノート PC の横幅はよほど小さくなければ 1280px くらいはあると思いますし、外付けモニタなら 1920px や 3840px だったりするでしょう。
筆者がお仕事で使っている PC も 2256 x 1504 の解像度を 150% のスケールで表示しているので、ピクセルに換算すると横幅 1504px になります。
（ブラウザを全画面表示してコンソールで window.innerWidth とすると 1504px と返却されます）
kintone の一般的な利用シーンとしてはアプリのレコード一覧からレコード詳細に入る流れになりますよね。
この際、特にカスタマイズなどの何らかの手当てをしていなければ画面の右側にはレコードコメントの枠が表示されます。
このコメント欄はリサイズ可能ですが、何もしなければ横幅 368px になるようです。
画面の端から端までキッチキチにフィールドを配置するレイアウトだといちいちコメント欄を閉じなければ全ての情報を閲覧できなくなり地味に使い勝手が低下しますので、フォームの最大幅としてはコメント欄が表示される分を差し引いて考えたいです。
もっと細かいことを言うと通知からレコード詳細に遷移する流れもあり、この場合は左側に通知一覧の幅（256px）が確保されるため、ダブルで表示領域を奪われてしまいます。
まあでも通知から遷移のケースはいったん置いておいて、コメント分の 368px には被らないようフォームをレイアウトする事を考えると、もちろん想定する利用者の環境にも左右されますが、最大 700px ～ 1000px 程度の横幅に収めると都合が良いのではないでしょうか。
【 提言 ① 】
フォームの最大横幅は 700px ～ 1000px 程度に収める
なお横幅 1000px は実寸で印刷するとちょうど A4 に収まるくらいのサイズ感になります。
レコード詳細画面の印刷のニーズはもはやそれほど高くはないとは思われますが、頭の片隅に置いておいても良い数字ではあるでしょう。
フィールドの横幅を理解する
横幅の目安は付けましたが、じゃあこれを基準にカラムを・・・と行く前に、いったん様々なフィールドの大きさの初期値を把握しておきましましょう。
フォームの編集において、フィールドを追加した際に確保される横幅はフィールドの種類によって異なります。
文字列（複数行） や リッチエディター などはフォームに配置した直後はいかにも横幅が狭くそのまま使うケースはまずないと思われますが一応初期値を計測します。
また チェックボックス や ラジオボタン は内包する選択肢の数や文字列によって長さが変わるためあまり初期値を知ることで得られるものはないですが、これもとりあえず初期値を見ていきます。
まず、新しいアプリを作成し、各フィールドを 1 つずつ全種類追加してみます。
関連レコード一覧、 グループ、 テーブル は内包するフィールドによりサイズが変わるためこれらは除外します。
ルックアップ など最初に設定が必要なものはよしなにします。
で、フォームを保存。
次は検証コードの実装です。
まず JavaScript の設定で Cybozu CDN から kintone Rest API Client を読み込んでおきます。
次に以下のようなスクリプトを作成し、 フォームのレイアウトを取得する API を利用して情報を取得します。
JSEdit for kintone プラグイン などでやると楽ちんです。
(() => {
"use strict";
/**
* レコード一覧画面表示時処理
*/
kintone.events.on("app.record.index.show", async (event) => {
// REST API クライアントを作成する
const client = new KintoneRestAPIClient();
// フォームのフィールドレイアウト情報を取得する
const result = await client.app.getFormLayout({
app: kintone.app.getId(),
});
console.dir(result.layout);
// レイアウト（行）でループする
let count = 0;
result.layout.forEach((row) => {
// 行内のフィールドでループする
(row.fields ?? []).forEach((field) => {
console.log(
`${++count}, ${field.code}, ${field.type}, ${
field.size && field.size.width ? field.size.width : "--"
}, ${
field.size
? field.size.innerHeight
? field.size.innerHeight
: field.size.height
? field.size.height
: "--"
: "--"
}`
);
});
});
});
})();
こうして導き出した各フィールドのサイズの初期値は以下の通りになりました。
文字列（1 行） と リッチエディター のみ innerHeight プロパティを、スペースのみ height プロパティを持ちますが、それ以外は width のみです。
| フィールド | 幅(px) | 高さ(px) |
|---|---|---|
| ラベル | 74 | -- |
| 文字列（1 行） | 193 | -- |
| リッチエディター | 315 | 125 |
| 文字列（複数行） | 315 | 125 |
| 数値 | 193 | -- |
| 計算 | 193 | -- |
| ラジオボタン | 253 | -- |
| チェックボックス | 253 | -- |
| 複数選択 | 197 | -- |
| ドロップダウン | 196 | -- |
| 日付 | 117 | -- |
| 時刻 | 101 | -- |
| 日時 | 196 | -- |
| 添付ファイル | 207 | -- |
| リンク | 193 | -- |
| ユーザー選択 | 344 | -- |
| 組織選択 | 344 | -- |
| グループ選択 | 344 | -- |
| ルックアップ | 246 | -- |
| スペース | 117 | 66 |
| 罫線 | 135 | -- |
| レコード番号 | 120 | -- |
| 作成者 | 136 | -- |
| 作成日時 | 186 | -- |
| 更新者 | 136 | -- |
| 更新日時 | 196 | -- |
うーん、こうして見るとけっこうバラバラです。
概ね 200px 程度の群（文字列（1 行）、数値、計算、日時、添付ファイルなど）と 344px の群（ユーザー選択など）に分けられそうで、そのどちらにも与しないもの（日付、時刻など）もあります。
いちばん短いのは（内容物により幅が可変の） ラベル で 74px 、次いで 時刻 の 101px 、いちばん長いのは ユーザー選択 などの 344px であるようです。
ちなみにこの、例えば 文字列（1 行） の 193px って言うのはどこの幅なのか？
Chrome のデベロッパーツールで確認してみると、フィールドの左右に 8px の padding があり、ここまで含めて 193px である事が分かります。
つまり複数のフィールドを横並びにした場合、 DOM 側のスタイルをいじらない限りは フィールドの入力部は 16px の隙間が空く と言う事です。
逆に言えば 文字列（1 行） を 4 つ横並びにした場合、 padding まで含めた要素の幅は 正確に 772px（193px × 4）になる と言うわけです。
なおフィールドの幅はフィールド名（ラベル）とフィールド本体（入力部）双方の幅の長い方から決まる値で、つまりとても長いフィールド名を付けると入力部の長さもそれに従い伸びる挙動です。
まあこうやって初期値を洗ってみましたが、先ほども述べた通りこの値にそれほど意味があるかって言うとそうでもありません。
実際のところ 作成者 や 更新者 は初期値だと姓名合わせて 5 文字以上の人だとあっと言う間に 2 行になってしまうためちょっと伸ばさざるを得ないでしょうし。
リンク や 添付ファイル フィールドも、もちろん使い方によるでしょうが初期値の幅のままでは明らかに短いと思えます。
とは言え、どのアプリでも採用できるカラムの 1 つ分の基準としてこれらのうちどれかを選ぶのは良いアイデアではないでしょうか。
【 提言 ② 】
基準となるフィールドを選び、その倍数でカラムを構成する
綺麗なサイズを作りたい
上述通り各フィールドの初期サイズはけっこうバラバラで、しかも 1 の位が 3 とか 4 とか 6 とかでどれか 1 つをカラムの基準として採用すると言うには若干収まりが悪いと感じるかも知れません。
（見た目には特に問題になる部分ではないでしょうが）
もう少し綺麗なサイズを作りたい！ と言う場合は以下のようにすると良いでしょう。
【A】 レコード番号を基準にする
レコード番号 は上述通り初期値が 120px なので、これを 1 カラムの基準にする考えです。
とは言え レコード番号 はフォーム内に 1 つしか設置できません。
そこで レコード番号 と横幅が同じサイズの スペース あるいは 罫線 を配置し、それを 1 カラムとして複製して横並びにします。
6 カラムなら 720px になり、ちょっと狭めではありますがそこそこ良い感じの数字ではないでしょうか。
また 8 カラムだと 960px となり狭すぎず広すぎないサイズ感になるかと思います。
【B】 ラベルを基準にする
ラベル は内包する文字列の長さにより幅が変わるため、ここで良い感じの文字列を入れていい感じの幅を得ると言うアプローチです。
例えば、文字の大きさを「普通」にしてラベルの内容を「-----------」（半角マイナス記号 11 文字）にするとちょうど 100px となります。
8 カラムで 800px を作る事ができます。
同じく文字サイズ「普通」で「|==....」とするとちょうど 80px を得る事ができるようです。
伝統的な 12 カラムで 960px を作る事ができ、いかにも自由度が高そうです。
他にもいろんな文字の組合せで良い感じのサイズを作れそうです。地道なトライ＆エラーですけど。
なおこれは Windows で行った結果です。Mac でやってみるとフォント等の違いでより小さいサイズになってしまうようですので注意です。
【C】 フィールドを組み合わせる
上述のラベルを使ったやり方は OS やブラウザの表示設定等の影響を受ける可能性があるので、違うアプローチも考えます。
上述でまとめたフィールドの大きさの初期値を組み合わせて目的の大きさを得る方法です。
以下は スペース フィールドで説明していますが、 罫線 でも同じやり方になります。
100px のスペースを作成する
以下の手順で実現できます。
① 1 行目に ルックアップ を 2 つ横並びに配置する
② 2 行目に 日時 を 2 つ横並びに配置する
③ ② の 日時 の右に スペース を配置し、右端を ① のルックアップの右端に揃える
これで ③ で作成したスペースは 100px になります。
ルックアップ（246px）と 日時（196px）の幅の差が 50px である事を利用した方法です。
80px のスペースを作成する
同じようなやり方で 80px を得る事ができます。
日付（117px）と 時刻（101px）の幅の差は 16px です。
この差を利用し、
① 1 行目に 日付 を 5 つ横並びに配置する
② 2 行目に 時刻 を 5 つ横並びに配置する
③ ② の右に スペース を配置し、右端を ① の日付の右端に揃える
の手順で 80px が得られます。
60px のスペースを作成する
作成日時（196px）と 作成者（136px）の幅の差はちょうど 60px です。
① 1 行目に 作成日時 を配置する
② 2 行目に 作成者 を配置する
③ ② の右に スペース を配置し、右端を ① の作成日時の右端に揃える
この手順で 60px のスペースが得られます。
120px は上述通り レコード番号 で得られますが、その半分が欲しい場合は活用できるでしょう。
ただ 60px はカラムの基準にするにはちょっと狭すぎ（＝カラム数が多くなりすぎ）、カラムのコンセプトにはそぐわない可能性もあります。
また、 スペース フィールドは仕様上 48px より狭くはできないようなので、スペースを用いてこれより小さい値、例えば 40px などを得るのは難しそうです。
【D】カスタマイズを駆使する
カスタマイズを駆使すればもっと直接的にサイズを変更する事ができます。
フォームのレイアウトを変更する API を利用します。
まず、フォームの任意の場所に スペース を 1 つ配置します。
スペースのフィールドコードは space_elem などにしておきます。（何でも良い）
フォームを保存し、カスタマイズで以下のようにします。
JSEdit for kintone プラグイン などでやると楽ちんです。
(() => {
"use strict";
/** 幅を設定するフィールドコード */
const ELEM_CODE = "space_elem";
/** 設定する横幅 */
const ELEM_WIDTH = 80;
/**
* レコード詳細画面表示時処理
*/
kintone.events.on("app.record.detail.show", async (event) => {
// REST API クライアントを作成する
const client = new KintoneRestAPIClient();
// フォームのフィールドレイアウト情報を取得する
const result = await client.app.getFormLayout({ app: kintone.app.getId() });
console.dir(result.layout);
// レイアウト（行）でループする
const layout = result.layout;
let widthChanged = false;
layout.forEach((row, ridx) => {
// 行内のフィールドでループする
(row.fields ?? []).forEach((field, fidx) => {
// スペースのフィールドコードが指定のものであり、
// かつ幅が異なっていれば幅をセットする
if (
field.type === "SPACER" &&
field.elementId === ELEM_CODE &&
Number(field.size.width) !== ELEM_WIDTH
) {
// フィールドに幅をセットしてフラグを立てる
field.size.width = ELEM_WIDTH;
widthChanged = true;
}
});
});
// フラグが立っていればフォームのフィールドレイアウト情報を変更する
if (widthChanged) {
const result = await client.app.updateFormLayout({
app: kintone.app.getId(),
layout,
});
console.dir(result);
// アプリをデプロイする
await client.app.deployApp({
apps: [{ app: kintone.app.getId() }],
});
// リロードする
location.reload();
}
});
})();
レコード詳細画面が表示されるたびにレイアウトの取得が行われるため、用が済んだらスクリプトは削除しておきましょう。
【E】プラグインを使う！
【A】～【C】は面倒だし【D】はスキル的にちょっと・・・と二の足を踏む方にはより最適なソリューションがあります。
弊社のプラグイン フィールドレイアウト数値指定プラグイン を使えば簡単に設定できます。（宣伝）
カラム 1 つの幅とカラム数を検討する
さて、ここまででいい感じのカラム幅を得る手立てが見出せました。
では実際に１つのカラムの幅をいくつにするか、フォーム全体として何カラムにすると良いかを検討しましょう。
改めて、各カラム幅とカラム数により構成される全体の横幅の関係をまとめておきます。
先ほどフォームの横幅は 700px ～ 1000px 程度に収めるのが良い と判断したため、その点も考慮します。
| カラム幅 | 6 カラム | 8 カラム | 10 カラム | 12 カラム |
|---|---|---|---|---|
| 60px | 360px | 480px | 600px | 720px |
| 80px | 480px | 640px | 800px | 960px |
| 100px | 600px | 800px | 1000px | 1200px |
| 120px | 720px | 960px | 1200px | 1440px |
太字になっているのが推奨フォーム横幅にマッチするサイズ・カラム数になります。
カラムのコンセプトに従い、基本的にフォーム中の全てのフィールドをこのカラム幅の倍数に揃えるレイアウトを敷く事になります。
日付、 時刻、 日時 など入力部のサイズが固定のものはそもそもカラムに合わせることはできないが全体としての幅の調整自体はできるため、その後続に来るフィールドの左端が揃うようにしておけば良いでしょう。
最初の方で言及した通りレスポンシブデザインのグリッドシステムでは 12 カラムが鉄板ですが、kintone はレスポンシブデザインには対応していないため 12 カラムを採用するメリットは薄いと言う点も考慮しておきます。
それでは、実際にこれらのカラムを採用してみたアプリを作ってみましょう。
弊社プラグイン KEIKAK のアプリテンプレートで作成される KEIKAK アプリはいろんなフィールドタイプが登場するので、これを題材にしてみます。
なお、検証用にいくつかフィールドを追加しているほか、カラムを分かりやすくするためにボーダーを入れています。
60px カラムを採用してみる
まずは 60px × 12 カラム = 720px の構成です。
60px は率直に言うと幅が狭すぎると考えます。
実際 1 カラムで収まる要素は 1 つもなく、2 カラムや 4 カラムに渡るレイアウトが多い。
3 カラムや 5 カラムと言った奇数カラムもあまり大きなメリットにはならず、だったら 120px × 6 カラムでも良くない？と言う感じが拭えません。
80px カラムを採用してみる
次は 80px × 10 カラム = 800px の構成です。
ここで目を引くのは 数値 や 計算 です。
これらのフィールドは単位まで含めて考えると 1 カラムつまり 80px で収まる事はあまりないため、2 カラム（＝ 160px）使っています。
こうなるとだいぶ幅を取りすぎている感が否めず、ちょっと微妙に思えます。
また 日時 は 3 カラム使い、右が大きく空いてしまいます。
日付 + 時刻 の構成だと時刻の方が右が少し余りますが日付と同じサイズなのでそんなに不自然ではないですかね。
100px カラムを採用してみる
次いで 100px × 8 カラム = 800px の構成です。
80px ではちょっと微妙に見えた 数値 は 1 カラム幅に収まった結果とても塩梅が良く見えます。
（単位と桁数次第なところはありますが）
日時 は 2 カラムで良い感じに収まりますが、日付 + 時刻 は合わせて 2 カラムには収めきれないため 3 カラム使う事になり、右がかなり余って見えます。
120px カラムを採用してみる
最後に 120px × 8 カラム = 960px の構成です。
A4 印刷を考えると割とちょうどいいサイズですね。
100px カラムレイアウトと同様、数値 は単位を含めていい感じの収まりです。
むしろ 100px よりも多少余裕があり、単位や桁数が長くても余裕がありそうです。
日時 、および 日付 + 時刻 は周辺のフィールドとサイズが合っている事もあり、やや余白は大きくは見えますが許容範囲でしょう。
60px が 1 カラムで収まる要素が全くなく実質 120px カラムとほぼ同義と言うのは全くその通りで、実際 120px × 6 カラムは 60px × 12 カラムと同じ見た目です。
考察
こうして見てみると、どうも 日時、 日付、 時刻、数値 あたりのフィールドがカラム幅選択のカギになって来そうな気がします。
日時 フィールドを使うなら 100px 幅がちょうど良く、日付 + 時刻 なら 120px 幅がちょうど良さそうです（でも 120px での 日時 もそこまで悪いと言うわけではない）。
数値 は想定される最大桁数や単位によってよしなに、って感じですかね。
60px 幅については上述通り結局 120px 幅に収斂する感じがあるのでメリットは微小。
80px 幅も 1 カラムで収まる場面があまりなく、必然的に 2 カラム以上で用いる事になりますが、80px × 2 ＝ 160px となるとそれはそれで少し大きすぎる嫌いがあり、これもちょっと使い勝手が良くなさそう。
そう言う点で、100px 幅と 120px 幅のいずれが程好いのではないか と言う帰結が導かれそうです。
さらに言えば、 120px は 6 カラムあるいは 8 カラムでも破綻なく構成でき、情報量の多寡でカラム数を決めれば良い。
100px にしても情報量が少ないアプリであれば 6 カラムでも事足りる場面はあるでしょう。
まとめるとこんな感じになるでしょうか。
【 提言 ③ 】
利用するフィールドや想定される使い方をもとに
・100px × 6 カラム
・100px × 8 カラム
・120px × 6 カラム
・120px × 8 カラム
のいずれかを採用する
個人的には カラム幅の基準は 120px がオススメな感じがします。
とは言え・・・
ここまで 100px とか 120px とかさんざん言及して来ましたけれども、極端な事を言えば、 アプリ利用者にとってみればこれが何 px 幅かなんて言うのは全く興味がない話 です。
元も子もない事を言うようですが、
- 何かしらの基準を設け、
- その倍数でカラムを構成し、
- それが一貫している
と言うレイアウトを採れればそれで十分なはずなのです。
綺麗な数字を使いたいと言うのはエンジニア的な視点や欲求に過ぎず、決して本質ではない。
そう言う意味では、117px の 日付 や 101px の 時刻、 117px の スペース、 136px の 作成者 などを基準とするレイアウトでも良いでしょう。
次の節でもう少し掘り下げて考えますが、 一貫性があるレイアウト である事が何より重要であり、それは上述の【 提言 ③ 】よりも優先されるべきものなはずです。（もちろん並立もできますが）
アプリ間でのカラムレイアウトの統一を考える
ここまでで、アプリ内でのカラム幅とカラム数については概ね決められてきたと思います。
ではここで決めたルールはどこまで採用すべきか？
アプリごとに入力する項目は異なるのだからアプリ単体で決めればいい？
統一感を出すために環境全体の全てのアプリに貫徹した方が良い？
一般論として、ブラウザのウィンドウを複数横に並べて同時に複数のアプリを使用すると言う利用シーンは稀だと思われます。
あるアプリで作業したら次はそのウィンドウ内で別なアプリに遷移するか、せいぜい別タブで違うアプリを開いて操作すると言った形が一般的でしょう。
そう言う観点から行けば、アプリ同士で厳密にカラム幅が一致していなくとも見た目上は許容できそうには思えます。
ただ、例えばあるアプリ A で記入した内容を別のアプリ B でルックアップで引いてくる、みたいなシチュエーションを考えた場合はどうでしょう。
アプリ A で入力したときのフィールドの大きさとアプリ B で表示されるフィールドの大きさが異なっていたとしたら、これは UX 的によろしくないとは言えそうですよね。
一方では 1 行に収まっている文字列が他方では 2 行に渡っている、と言うのはいかにも混乱を招きそうです。
そう考えると、環境全体に唯一神・絶対神的な位置づけで画一のカラムレイアウトを採用する必要はないけれども、同じような情報を取り扱うとかお互いフィールドや情報を参照し合うような 関連性の高いアプリ同士ではカラムレイアウトを統一しておくべき だと考えられるのではないでしょうか。
そしてこれは前節で言及した 一貫性があるレイアウト の体現でもあるわけです。
【 提言 ④ 】
関連するアプリ間で基準となるカラム幅を揃え、レイアウトの一貫性を確保する
あとがき
と言うわけで、kintone アプリのフォームレイアウトにカラムの概念を導入するにあたっての考慮点・最適解について解説して来ました。
最後にも述べた通り、結局のところ何らかの基準に沿ってレイアウトしそれが一貫している事が重要であり、1 カラムの幅がいくつかなんて言うのは些事に過ぎません。
そのあたりはそれぞれ組織ごとや使い方によってニーズが異なる部分だと思いますので、自分たちならではの基準を定めて運用していって頂けば良いんじゃないかと思います。
その際に綺麗なサイズが欲しいと言うのであれば、この記事を参考にして頂ければと言う事で。
以上、お読み頂きありがとうございました！