コールドテスト

保険UIのコールドテスト — 損保査定・契約・支払・生保引受・営業ポータル

自動車保険の保険金請求・査定、損保契約と代理店ダッシュボード、保険金支払と精算、生命保険の引受査定、生保営業のライフプランナー活動ポータル。AmountBreakdown が 3回確認に到達し、実装翌回で別 cold AI に自力発見された5枚です。

保険 の cold test、10 画面のまとめ。

なぜ保険UIは難しいのか

保険は「金額を構造で説明する」場面が常時並びます。査定の認定額・過失相殺・免責・既払・支払額の連鎖、保険料の構成、引受審査の BMI / 血圧 / 既往の ReferenceValue、高額案件の2人確認 CoSign、確定の SignedRecord、契約者と募集人の関係を見る代理店ビュー。同時に、後半の営業ポータルでは消費者寄りの作法(パイプライン Kanban、目標 Meter、要対応 Alert)も同居します。観測の核は明確で、「金額導出ブロックが3回目の手組みになれば、その場で実装する」でした。

動く見本:架空の保険会社の業務アプリ

この業界で実際に何が組めるのかを、読むだけでなく触って確かめられるように、架空の保険会社の業務アプリを1本用意しました。契約管理、保険金請求・査定、保険金支払・精算の3画面がこのサイトの上でそのまま動きます。UIコンポーネントはすべて @gunjo/ui のものだけを使っています。

群青損害保険架空のデモ

損害保険会社の社内と代理店の仕事を、契約の管理から保険金の支払まで一続きで見られます。一覧の絞り込み、詳細への掘り下げ、承認の流れ、金額の内訳まで実際に操作できます。

見本を開く

これは架空の保険会社「群青損害保険」のデモです。実在の会社・商品とは関係なく、保険の勧誘ではありません。

ここで群青に加わったコンポーネント

保険5枚で 3回確認を満たして実装に到達した、または実装翌回で自力発見されたコンポーネントです。

AmountBreakdown は実装翌回(#104 生保引受査定)で、保険料計算という新作法の場面で別 cold AI に自力発見されました。金融の「数の説明」がどれだけ業界を越えるかを最も強く証明した連鎖です。

この業界で要るもの

各回の記事から抜き出した項目です。状態は記事の時点ではなく、コンポーネント側のいまの実測です。

  • 査定額の大きい案件は、担当者がひとり承認しても止まったままになります。もうひとりが承認し、確定が署名として残って、はじめて次の工程に進みます。

    高額案件の承認(自動車保険 保険金請求・査定管理)自分の画面で確かめる 高額の1件を開いて、ひとりの承認だけで支払の工程まで進めてしまわないか確かめてください。

    状態 対応済み
  • 1件の請求が、受付・損害調査・査定・承認・支払のどこまで来ているかが一目で分かり、途中で差し戻すこともできます。

    査定ワークフロー(自動車保険 保険金請求・査定管理)自分の画面で確かめる 差し戻した1件を開いて、いま止まっている工程が画面のどこかに出ているか確かめてください。

    状態 対応済み
  • どの募集人(保険を売る営業担当者)がどの契約を担当しているかが、1行のまとまりとして読めます。

    募集人と担当契約の関係(損保の契約管理 / 代理店ダッシュボード)自分の画面で確かめる 担当者と契約を並べた行を見て、担当する側とされる側の向きが行だけで読めるか確かめてください。

    状態 対応済み
  • 代理店ごとの業績が、数字の羅列ではなく、長さで見比べられるメーターで出ます。

    代理店業績(損保の契約管理 / 代理店ダッシュボード)自分の画面で確かめる 代理店の一覧を開いて、業績が数字を読み込まなくても見比べられるか確かめてください。

    状態 対応済み
  • 今回いくら払うのかが、認定損害額から過失相殺と免責と既払金を引いた道筋ごと読めます。

    支払明細(自動車保険 保険金支払・精算管理)自分の画面で確かめる 支払明細を開いて、合計だけでなく、そこに至る引き算の一段ずつが出ているか確かめてください。

    状態 対応済み
  • 控除の行が、マイナスの記号でも、画面を読み上げるソフト向けの言葉でも、控除だと分かります。色が見えない状態でも取り違えません。

    支払明細の控除行(自動車保険 保険金支払・精算管理)自分の画面で確かめる 画面を白黒にして、控除の行が控除だと分かるか確かめてください。

    状態 対応済み
  • BMIや血圧などの数値が、基準の範囲からどのくらい外れているかまで込みで出ます。

    告知・リスク評価(生命保険の引受査定(アンダーライティング))自分の画面で確かめる 検査値を並べた画面で、値そのものと基準からの外れ方の両方が読めるか確かめてください。

    状態 対応済み
  • 主契約と特約と特別条件を積み、割引を引いて保険料を出します。引受をしない判定のときは、合計が0円として出ます。

    保険料算定(生命保険の引受査定(アンダーライティング))自分の画面で確かめる 引受をしない判定に切り替えて、合計が0円のまま崩れずに出るか確かめてください。

    状態 対応済み
  • 見込みから成約までの段階が、カードを並べた列として出ます。列の並びはボードの枠の内側だけで横にスクロールするので、スマートフォンでもページ全体は横にずれません。

    見込みパイプライン(生保営業(ライフプランナー)の活動ポータル)自分の画面で確かめる 375pxの幅で開いて、パイプラインを横に送ってもページ自体が横にずれないか確かめてください。

    状態 対応済み
  • 今月の目標に対してどこまで来たかが出ます。入れ物がどれだけ埋まったかを示す表示の流用ではなく、目標への近づき方として読めます。

    目標の進捗(生保営業(ライフプランナー)の活動ポータル)自分の画面で確かめる 目標に対する進み方を出したいところに、入れ物の埋まり具合を示す表示を使っていないか確かめてください。

    状態 対応済み
  • 今月の手数料の見込みが、募集手数料とインセンティブを足し、取消や戻入(あとから差し引かれる分)を引いた形で出ます。

    手数料内訳(生保営業(ライフプランナー)の活動ポータル)自分の画面で確かめる 取消や戻入がある月を開いて、引かれた分が控除だと分かる形で出ているか確かめてください。

    状態 対応済み
  • 保険料の内訳、証明書のダウンロード、手続きの一覧、給付の履歴、払込の履歴。契約者が自分の契約を見る画面は、必要なものが一通りそろっています。

    画面全体(生命保険の契約者マイページ)自分の画面で確かめる 契約者が自分の契約を見る画面を開いて、手続きと証明書と履歴が同じ画面から辿れるか確かめてください。

    状態 対応済み
  • 請求が受付・書類の確認・査定・支払のどこまで来たかが、段階ごとの日付つきで出ます。いまどの段階かは画面読み上げソフトにも伝わります。

    出したあとの進み具合(給付金の請求(入院給付金))自分の画面で確かめる 請求を出したあとの進み具合を見る画面を開いて、いまの段階と、それぞれの段階の日付の両方が読めるか確かめてください。

    状態 対応済み
  • 「はい」と答えたときだけ、病名や時期を書く欄が開きます。欄が増えたことは画面読み上げソフトにも伝わるので、目で見ている人だけが変化に気づく、ということが起きません。

    病歴の問い(生命保険の告知)自分の画面で確かめる 答えによって欄が増える画面を読み上げだけで進めて、欄が増えたことが分かるか確かめてください。

    状態 対応済み
  • 事実と違う申告をするとどうなるかを、読み飛ばせないように見せられます。注意書きを読んでくださいと文章で頼むのではなく、読んだという印を付けるまで送信を止められます。

    重要事項の確認(生命保険の告知)自分の画面で確かめる 重い注意書きを置いた画面で、読んだという印を付けないまま先へ進めてしまわないか確かめてください。

    状態 対応済み
  • 更新で変わる項目と変わらない項目が、色ではなく「変わります」「変わりません」という言葉で読めます。保険料が増えることも「増えます」と書きます。

    いまの契約と更新後の比較(定期保険の満期・更新)自分の画面で確かめる 画面を白黒にして、更新で変わる項目がどれか読み取れるか確かめてください。

    状態 対応済み

連載が先につまずいたところ

複数の回で出たものは1つにまとめ、根拠になった回を全部並べています。

  • 同じ承認の画面なのに、ボタンは「次へ進める」「差戻し」と日本語で、状態だけ Pending や In progress と英語で出ました。

    査定ワークフローの状態表示(自動車保険 保険金請求・査定管理)原因 ApprovalSteps の状態ラベルの既定値が英語のままで、同じ仲間のコンポーネントのボタンだけが日本語だったためです。自分の画面で確かめる 承認の画面を開いて、状態の文字とボタンの文字が同じ言語で出ているか見てください。

    状態 対応済み
  • 並べたいKPIのカードが7枚あるのに、1行に6枚までしか置けませんでした。

    KPIの行(自動車保険 保険金請求・査定管理)原因 StatGroup の列数が6までしか受け付けなかったためです。自分の画面で確かめる KPIを7枚以上並べる画面で、7枚目が意図した列に入るか確かめてください。

    状態 対応済み
  • 請求額から過失相殺と免責を引いて査定額を出すところだけ、明細と合計行を手で書くことになりました。

    査定額の内訳(自動車保険 保険金請求・査定管理)原因 ラベル付きの明細、マイナス記号つきで引き算を見せる行、強調した合計、数式の4つをまとめて見せるコンポーネントが当時はまだ無かったためです。自分の画面で確かめる 金額を引き算して出す画面を開いて、合計行と数式を自分で書いていないか確かめてください。

    状態 対応済み
  • やりたいことからコンポーネントを引く対応表で保険料の内訳を探すと、編集用の入力グリッドに案内されました。読むだけの明細に、編集用の作りは合いません。

    ユースケース別の対応表(損保の契約管理 / 代理店ダッシュボード)原因 対応表が、読むための金額導出と、入力するための編集グリッドを分けていなかったためです。自分の画面で確かめる 対応表で「金額の導出」を引いて、読むための明細と入力用のグリッドが別々に出てくるか確かめてください。

    状態 対応済み
  • 隣り合うフィルタで、値の変化の受け取り方が違いました。Select はブラウザ標準の onChange、検索欄は値だけを渡す onValueChange です。

    保有契約一覧のフィルタ行(損保の契約管理 / 代理店ダッシュボード)原因 Select はブラウザ標準の select 要素の書き方をそのまま通し、SearchInput は値だけを渡す書き方にしているためです。自分の画面で確かめる フィルタ行に入力を2つ並べて、変化の受け取り方が同じ書き方で済むか確かめてください。

    状態 未修正・直し方記録済み
  • 横から出すパネルで、外枠(Root)と中身(Content)の2箇所に同じ向きを指定することになりました。既定の幅も、契約の詳細を見るには狭いままです。

    契約を掘り下げる詳細パネル(損保の契約管理 / 代理店ダッシュボード)原因 同じ向きを外枠と中身の2箇所に書かないと見た目と動きが揃わない作りで、既定の幅も 320px と狭いままだったためです。自分の画面で確かめる 横から出すパネルを開いて、向きの指定が1箇所で済むか、幅が詳細に足りるか確かめてください。

    状態 未修正・直し方記録済み
  • DataTable や StatGroup はデータを渡せば描けるのに、Timeline だけ中身を入れ子で書きます。最初に書いた形が通らず、ソースを読むまで気づけませんでした。

    時系列の表示(生命保険の引受査定(アンダーライティング))原因 同じライブラリの中にデータを渡す作法と入れ子で組む作法が混ざっていて、当時はその違いが型名にも、やりたいことからコンポーネントを引く対応表にも出ていなかったためです。自分の画面で確かめる 時系列の表示を、他の一覧と同じようにデータを渡す書き方で組めるか確かめてください。

    状態 対応済み
  • 失効防止や更新や満期や誕生日といった、いま対応が要る項目を深刻度の順に並べるところを、手で書くことになりました。

    要対応アラート(生保営業(ライフプランナー)の活動ポータル)原因 深刻度で並んだ対応待ちの一覧を出すコンポーネントが当時は無く、深刻度と見た目の対応づけを毎回自分で書く必要があったためです。自分の画面で確かめる 朝いちばんに見る画面で、対応が要る項目が深刻度の順に並んでいるか確かめてください。

    状態 対応済み
  • 主契約の下に特約がぶら下がるという保険の構造を、そのまま画面に出せませんでした。がん特約や先進医療特約を、主契約の子として並べる置き場がありません。

    保障内容の階層(生命保険の契約者マイページ)原因 入れ子にできるコンポーネントは、子の行の項目名を1行に切り詰めるうえ、読むだけの契約内容を押せるものとして画面読み上げソフトに伝えるので、契約内容の表示には使えないからです。自分の画面で確かめる 主契約と特約を親子に並べた一覧を開いて、子の行の項目名が1行に切り詰められていないか確かめてください。

    状態 未修正・直し方記録済み
  • 主契約は終身、通院は70歳まで、がんは80歳まで。満了する年齢が違う保障を、並べて比べる図が描けませんでした。

    保障期間の比較(生命保険の契約者マイページ)原因 工程表のコンポーネントは目盛りを日と時間でしか刻めず何十年という保障期間を表せないうえ、1本の帯で期間を示すコンポーネントは何本並べても全部が同じ1行に重なるためです。自分の画面で確かめる 開始が同じで終わりだけ違う期間を4本出してみて、4本が別々の行として見比べられるか確かめてください。

    状態 未修正・直し方記録済み
  • 一生涯続く保障には満了の日付がありません。日付が空のままだと、期限の表示が「未登録」になります。良い知らせが、登録し忘れに見えます。

    保障の満了表示(生命保険の契約者マイページ)原因 期限の表示に「そもそも期限が無い」という出し方が用意されておらず、日付が空なら未入力とみなすためです。自分の画面で確かめる 満了日の無い項目に期限の表示を付けてみて、未入力と読める言葉が出ていないか確かめてください。

    状態 未修正・直し方記録済み
  • 診断書の写真を添えるところが、キーボードだけでは操作できません。前に同じ画面を作ったときは、写真を添えるこのコンポーネントの中身を調べたうえで、使わないと決めていました。今回は、最後まで気づかないままでした。

    書類の提出(給付金の請求(入院給付金))原因 写真を選ぶための入力欄が見えないように隠され、写真をドラッグして置くための枠にもタブキーでたどり着けないためで、目で見る分には動くので気づけません。自分の画面で確かめる マウスを使わずにタブ移動だけで、写真を添える操作が最後まで通るか確かめてください。

    状態 未修正・直し方記録済み
  • やりたいことからコンポーネントを引く対応表で査定の進み具合を探すと、査定する側が操作するパネルに案内されました。そのまま使うと、契約者が自分の請求を承認できる画面になります。

    査定の進み具合(給付金の請求(入院給付金))原因 対応表とコンポーネントの説明に「給付・申請の審査」という業務名が書かれていて、進み具合を見るだけの画面と、判断を操作する画面を分けていないためです。自分の画面で確かめる 利用者に見せる進み具合の画面を開いて、進める・差し戻すの操作が混ざっていないか確かめてください。

    状態 未修正・直し方記録済み
  • 入力フォームの解説ページのとおりに組むと、どのエラーの文がどの入力欄のものかが画面読み上げソフトに伝わらなくなります。しかも何の警告も出ないので、作った側は気づけません。別の業種を扱った回に続いて2回目で、前の回のいきさつを知らないまま作ると、やはり同じところでつまずきます。

    請求内容の入力(給付金の請求(入院給付金))原因 解説ページが主役として扱うのは入力欄をまとめて囲む側のコンポーネントで、読み上げへの結び付きを持つのは入力欄を1つずつ包む別のコンポーネントだからです。自分の画面で確かめる 説明書どおりに組んだフォームでエラーを出して、入力欄とエラーの文が読み上げで結び付いているか確かめてください。

    状態 未修正・直し方記録済み
  • 年齢の欄(18から75まで)に「45」と打つと「75」になります。1文字目の「4」が下限の18に置き換わり、続けて「5」を打つと185になって、上限の75へ収まるからです。

    年齢と入院日額の直接入力(医療保険の保険料試算)原因 数値の入力欄が、1文字打たれるたびに、その時点の数を上限と下限の中へ強制的に収めて確定させるためです。自分の画面で確かめる 下限が2桁以上の数値の欄に、下限より大きい数を2桁打ってみて、打った数がそのまま残るか確かめてください。

    状態 未修正・直し方記録済み
  • 横に滑らせて数を変えるつまみと、数字を直接打ち込む欄。どちらからも同じ値を動かせる組み合わせが無く、一から作ることになりました。住宅ローンの試算に続いて2回目です。

    試算の条件を動かすところ(医療保険の保険料試算)原因 1つの値をつまみと数値の欄の両方から変えられ、つまみ側と欄側で1回に動く量を別々に決められ、読み上げソフトには項目名を1度しか伝えない、という条件をまとめて満たすコンポーネントが無いためです。自分の画面で確かめる つまみと数値の欄を並べた箇所を開いて、同じ項目名が2回読み上げられていないか確かめてください。

    状態 未修正・直し方記録済み
  • つまみを動かすたびに金額が変わる画面では、読み上げが次々に重なってしまいます。それを防ぐ待ち時間を、画面を作るたびに自分で決めることになりました。3つの回で別々に作ってみて、いずれも「操作の手が止まってから0.8秒後に読ませる」という同じ答えに行き着いています。

    毎月の保険料の読み上げ(医療保険の保険料試算)原因 値が続けて変わる表示を、動きが止まってから1度だけ読ませる仕組みが、コンポーネントの側に無いためです。自分の画面で確かめる つまみを続けて動かして、動かした回数ぶん読み上げが次々と流れてしまわないか確かめてください。

    状態 未修正・直し方記録済み
  • 「はい・いいえ」や「完治・通院中・経過観察・分からない」のように、選択肢のまとまりを1つの問いとしてまとめるコンポーネントがありませんでした。

    問いの組み立て(生命保険の告知)原因 フォームの項目のコンポーネントが単一の入力欄を前提にしていて、選択肢のまとまりや、年と月のように2つの入力で1つになる問いに、問い全体の見出しを持たせられないためです。自分の画面で確かめる 選択肢のまとまりを1つの問いとして置いた箇所で、選択肢よりも先に問いの文が読み上げられるか確かめてください。

    状態 未修正・直し方記録済み
  • 入力が済んでいない項目が何件あるかと、それぞれの箇所へ飛べる一覧を出すところを一から書きました。3つの別々の画面で同じものが要ったので、コンポーネントとして作ることに決まりました。

    送信時のエラー表示(生命保険の告知)原因 フォームに、エラーの件数と各項目への案内をまとめて出す仕組みが無いためです。自分の画面で確かめる 必須の項目を空のまま送信して、残りが何件でどこにあるかが1か所に出るか確かめてください。

    状態 未修正・直し方記録済み
  • 急がせない、追い詰めない、分からないと答えてよい。この落ち着いた雰囲気を支えていたのは、コンポーネントではなく、病歴の質問に添えた5つの短い説明文の言葉づかいだけでした。

    画面全体の調子(生命保険の告知)原因 用意されているのは進み具合のバー、いま何段目かを示す表示、画面の下に貼り付く操作ボタンの列だけで、どれも先へ進ませるための道具なので、急がせたくない画面では文章で落ち着かせるしかないからです。自分の画面で確かめる 答えたくないことを聞く画面を開いて、急がせない雰囲気を支えているのが説明文だけになっていないか確かめてください。

    状態 追跡中
  • いまの契約と更新後の条件を項目ごとに並べる表を、既製のコンポーネントを使わず一から組みました。並べて比べる表を一から組むのは、連載でこれが7回目です。

    いまの契約と更新後の比較(定期保険の満期・更新)原因 いまの契約を基準に更新後と2列で並べ、変わった項目に印を付け、増えた分と減った分を出す、という比較のコンポーネントが無いためです。自分の画面で確かめる 前と後を並べる画面で、どの項目が変わったかの印を、毎回自分で書いて付けていないか確かめてください。

    状態 未修正・直し方記録済み
  • カードの見出しと画面の上部バー以外は、文字の大きさと太さと色を毎回自分で書くことになりました。この画面だけで20箇所を超えます。

    画面の中の見出しと本文(定期保険の満期・更新)原因 見出しと本文のコンポーネントが無く、文字の大きさや太さをまとめて決める仕組みがどこにも無いためです。自分の画面で確かめる 画面の中の小見出しを数えて、同じ役割の見出しが同じ文字の大きさと太さになっているか確かめてください。

    状態 未修正・直し方記録済み
  • 金額の内訳は、目で見る分には正しく出ますが、画面読み上げソフトでは項目名が読まれないことがあります。

    更新後の保険料の内訳(定期保険の満期・更新)原因 項目名の側が表のマスとして作られておらず、読み上げソフトからは、行はあるのに中身が片方しか無い表に見えるためです。自分の画面で確かめる 金額の内訳を読み上げソフトで通して、項目名と金額が対になって読まれるか確かめてください。

    状態 未修正・直し方記録済み

保険 の全ラウンド

保険 カテゴリの 10 画面を、ラウンド順に並べています。各カードから cold AI が組んだソース、解説記事、デスクトップ/モバイルのプレビューに飛べます。

AI に保険金査定の画面を作らせてみた — #100で作った「用途から引く索引」が、次の回でもう効いた(やってみた #101) preview
#101スコア 4.5/5
AI に保険金査定の画面を作らせてみた — #100で作った「用途から引く索引」が、次の回でもう効いた(やってみた #101)
/insurance-claims

~90%が組み立て。発見可能性への投資も「翌画面で裏付く」。

AI に保険の契約管理を作らせてみた — 金額内訳がまた手組み、次に作るべきものが見えた(やってみた #102) preview
#102スコア 4/5
AI に保険の契約管理を作らせてみた — 金額内訳がまた手組み、次に作るべきものが見えた(やってみた #102)
/insurance-policies

~85%が組み立て。索引は効く、が「合成コンポーネント」には更新が要る。

AI に保険金支払の画面を作らせてみた — 3回目の手組みで、金額内訳がついにコンポーネントになった(やってみた #103) preview
#103スコア 4/5
AI に保険金支払の画面を作らせてみた — 3回目の手組みで、金額内訳がついにコンポーネントになった(やってみた #103)
/insurance-payments

3回目が発火。3回ルールは「金融の土台」も固めた。

AI に生保の引受査定を作らせてみた — 昨日作ったコンポーネントを、別のAIが翌日もう見つけて使った(やってみた #104) preview
#104スコア 4.5/5
AI に生保の引受査定を作らせてみた — 昨日作ったコンポーネントを、別のAIが翌日もう見つけて使った(やってみた #104)
/insurance-underwriting

法則が1ラウンドで閉じた。「作る」と「見つけさせる」は同じ1ラウンドで裏付く。

AI に生保営業の朝のポータルを作らせてみた — 保険5枚、ほぼ全部が既存コンポーネントで組めた(やってみた #105) preview
#105スコア 4.5/5
AI に生保営業の朝のポータルを作らせてみた — 保険5枚、ほぼ全部が既存コンポーネントで組めた(やってみた #105)
/insurance-agent-portal

「ほぼ手組みゼロ」で締まった。保険は「作り切った」、そして土台はもう一段。

AI に保険の契約者マイページを作らせてみた:「人生の長さ」を描く道具が無かった(やってみた #200) preview
#200スコア 4/5
AI に保険の契約者マイページを作らせてみた:「人生の長さ」を描く道具が無かった(やってみた #200)
/policy-portal

骨格は組めたが、保険という商品の形が描けなかった。「人の一生に関わるもの」を扱う画面が、まだ苦手。

AI に給付金の請求画面を作らせてみた:前の回が見つけた不具合を、今回の AI は素通りした(やってみた #201) preview
#201スコア 4/5
AI に給付金の請求画面を作らせてみた:前の回が見つけた不具合を、今回の AI は素通りした(やってみた #201)
/claim-filing

気づかれなかった。進み具合には、配送追跡の部品が効いた。

AI に保険料の試算画面を作らせてみた:年齢欄に「45」と打つと、75になった(やってみた #202) preview
#202スコア 4/5
AI に保険料の試算画面を作らせてみた:年齢欄に「45」と打つと、75になった(やってみた #202)
/premium-quote

型は緑、目で見ても動く。数字を打つと壊れた。型が緑でも、数字を打つまで出てこない不具合がある。

AI に保険の告知画面を作らせてみた:「構造は正しく出してくれて、温度は全部こちらに残した」(やってみた #203) preview
#203スコア 4/5
AI に保険の告知画面を作らせてみた:「構造は正しく出してくれて、温度は全部こちらに残した」(やってみた #203)
/health-disclosure

構造は出せて、温度は残った。構造は部品が持てる。トーンは、まだ書き手に残る。

AI に保険の更新画面を作らせてみた:前と後を並べる部品が、7回目の手組みになった(やってみた #204) preview
#204スコア 4/5
AI に保険の更新画面を作らせてみた:前と後を並べる部品が、7回目の手組みになった(やってみた #204)
/policy-renewal

画面の中心が、また無かった。同じ部品が、片方では正解で、片方では不正解になる。

この業界が gunjo に残したもの

保険は、「金額導出ブロック」を群青のキャンバスとして完成させ、ApprovalWorkflow・CoSign・SignedRecord・ReferenceValue といった「責任の重い操作」のキャンバスが損保/生保/代理店の全層で 組み合わせで組めることを証明しました。最後の営業ポータル(#105)では、ここまで作ったコンポーネントが「全部 組み合わせで組める」状態に到達し、docs のコンポーネント検索も全部名指しで正解──保険5枚で作り切ったと記録されています。