条件分岐を育てると、「条件」と仲良くなれるかもしれない - アールスリーインスティテュート

公開日：2025-12-02

注意

本記事は情報提供を目的としており、本記事の内容は無保証、サポートの対象外です。
サポート窓口、問合せ窓口にご質問をいただいても対応いたしかねますのでご了承ください。

こんにちは。ゆーいちです。

kintone（キントーン）で画面を運用していて、ラジオボタンやドロップダウン、またチェックボックスなんかで、フィールドの表示/非表示を制御したい事、ありませんか？

gusuku Customine(※以下、カスタマインと記載)でこのフィールドの表示制御を実現する場合、この時の「条件」の分岐には、大きく分けると次の2パターンがあります。

それぞれの値に応じたパターンを愚直に書く
表示を全て一旦クリアしてから表示すべき項目だけを表示する

実はサポートの記事でも……

実は、カスタマインのサポートに掲載されている記事でも、それぞれのパターンに合わせた条件分岐を伴う記事があります。

「それぞれの値に応じたパターンを愚直に書く」パターンの記事

フィールド値により表示制御したい

「表示を全て一旦クリアしてから表示すべき項目だけを表示する」パターンの記事

チェックボックスのチェック有無によって、該当するフィールド・グループの表示/非表示を切り替えるkintoneカスタマイズ
 ラジオボタン・ドロップダウンの選択項目によって、フィールド・グループの表示/非表示を切り替えるkintoneカスタマイズ

さて、なぜこの２つのパターンの記事が存在するのでしょうか？
この理由は、実際にカスタマイズを作成し、状況に応じて育てていくとよくわかります。

ラジオボタンとグループフィールドの表示制御を題材に考えてみよう

今回は、「ラジオボタンを選ぶと、それに対応したグループフィールドが表示される（選んでないラジオボタンに対応するグループフィールドは非表示になる）」というカスタマイズを考えてみます。

まずはシンプルな例として、２つのグループ（Aグループ、Bグループ）の制御を考えてみましょう。次のようなアプリを例にします。

2つのグループの場合、次の要件を満たす必要があります。

・Aグループが選択されたときは、Aグループを表示し、Bグループを非表示にする

・Bグループが選択されたときは、Bグループを表示し、Aグループを非表示にする

こういった条件の組み合わせを列挙し、並べて考える時には、パターンが少ない場合は文章で書いても良いのですが、今回はパターンを増やしていくため、「決定表(※ディシジョンテーブルとも呼ばれる)」という表を作成するのがおすすめです。

決定表をあらかじめ描いて整理しておくことで、組み合わせた時の動作のパターンがわかりやすくなり、条件を設定したり、またその内容のテストが客観的に進められるようになります。

決定表（ディシジョンテーブル）って？

まずは、決定表（ディシジョンテーブル）について説明します。

決定表は、複数の条件とそれに対応する処理（アクション）を整理するための表、および表を用いた手法を指すものです。なお決定表はISOだとISO 5806:1984(Information processing — Specification of single-hit decision tables)として、またJISだとJIS X 0125:1986(決定表)として規定されており、JIS X 0125上での用語としての「決定表」の定義は「問題の記述において起こり得るすべての条件と、それに対して実行すべき動作とを組み合わせた表。」となっています。

参考： JIS X 0125:1986 決定表 | 日本規格協会 JSA Group Webdesk

決定表の具体的な要素については、次の４つがあります。

条件（Condition）：判定に使う項目。※例：会員かどうか、金額が5000円超かどうか。
条件記号（Condition Entry）：条件が満たされるかどうかを「Yes／No」などで表す。
アクション（Action）：条件が満たされたときに行う処理。
アクション記号（Action Entry）：そのルールで実行するアクションに「X」などを付ける。

具体的に上の例（２つのグループ（Aグループ、Bグループ）の制御）で決定表を描いてみます。すると、次のようになります。

なお、それぞれの要素は次の箇所に対応しています。

また、この決定表に従ってカスタマイズを作成してみましょう。

すると、次のようになります。

なお、やることは「フィールドやグループを表示する」や「フィールドやグループを非表示にする」、条件は「フィールドの値を編集して値が変わった時」や「フィールド値が特定の値ならば」や「他のアクションの実行が完了した時」を使っています。

カスタマイズをkintoneアプリに反映し、実際に2つのラジオボタンそれぞれを選択すると、それぞれのラジオボタンに応じた表示制御ができている事がわかります。

※正確には画面を初期表示したときに初期値に合わせて初期表示をするアクションも、同様の要領で準備する必要がありますが、カスタマイズが長くなってしまうためこのブログでは省略します

なお、決定表を作成して論理的な組み合わせの設計やチェックを行うと、少し手間はかかってしまうのですが次のようなメリットがあると言われています。

条件分岐を整理できる
漏れや重複を防ぎやすい
ロジックを誰でも理解しやすくできる(引継ぎがしやすくなる)
仕様やテストケースを明確にできる

では実際に、決定表を用いて処理を変更してみる、具体的な例を次節で確認してみましょう。

グループを増やしてみよう

ここまでで、まずは２グループでの表示制御が実現できました。

ただし実運用などにおいても往々にありますが、運用していく過程で 表示制御のグループを増やしたい といった要望が出てくる事があります。

今回はそういった要望があったと仮定し、グループにCグループを追加してみましょう。

３つのグループに対応するように、決定表をまずは描きなおしてみると、次のようになります。

また、この決定表に従ってカスタマイズを作成してみると、次のようになります（アクション２，４は「やること」のフィールドの対象を増やしており、アクション５，６が新たに追加されています）。

実際に3つのラジオボタンそれぞれを動かしてみると、狙った形で表示制御ができている事がわかります。

おわりに

このブログでは決定表についての話と、ラジオボタンをつかった表示制御について、決定表を使った表示制御の設計・カスタマイン上での設定についてお伝えしました。
これだけだと決定表のメリットがすこしわかりにくいのですが、後日公開する予定の、この続きのブログでは、このラジオボタンをチェックボックスにもし変更すると……　どうなる……？　という点を具体的に掘り下げていきます。