About Juveka

現場の言葉と、
動く仕組みの間をつなぐ。

Juvekaは、業務の困りごとを整理し、使えるWebシステムとして形にするプロジェクトブランドです。大きく見せることより、実際に作ったもの、確認した結果、できないことを明確にする姿勢を大切にします。

Purpose

システム導入そのものを目的にしない。

紙やExcelが悪いわけではありません。件数が少なく、担当者が一人で、変更もほとんどない仕事では、紙やExcelの方が合理的な場合があります。

一方で、利用者が増え、確認者が分かれ、履歴や期限が必要になると、転記・検索・聞き取りに時間がかかります。Juvekaは、その境目を見つけ、必要な範囲だけをシステム化します。

「作れる機能」ではなく、減らしたい手間と守るべき判断から設計します。

分散業務を整理する図
道具を増やすのではなく、情報の入口と判断の流れを整理します。
Principles

開発で大切にする6つの原則

現場の言葉を使う

技術用語ではなく、利用者が普段使う名称と順序で画面を作ります。

役割を曖昧にしない

誰が見る、入力する、承認する、管理するかを分けます。

例外を早く確認する

取消、再開、重複、日付変更、差し戻しを後回しにしません。

小さく作って見せる

長い説明だけで決め切らず、動く画面で名称と手順を合わせます。

結果で品質を示す

「安全にしました」ではなく、対象、方法、結果、限界を記録します。

戻し方を用意する

変更前バックアップ、復元手順、引き継ぎを完成条件に含めます。

What makes the approach different

Juveka Ordersで実際に行ったこと

理念だけでなく、完成した制作事例の中で実行した内容です。

約2週間の反復開発

要件整理、実装、画面確認、権限調整、回帰試験を短い単位で繰り返しました。

本番とテストの分離

本番を直接試験せず、非公開テスト環境と専用DBで書き込み回帰を実施しました。

公開デモの再構築

実データや秘密情報をコピーせず、空スキーマと架空データから別VPSへ構築しました。

Pythonによる自動試験

画面遷移、CSRF、追加、重複防止、退院、再入院等を再実行できる形にしました。

バックアップ復元確認

バックアップ作成だけでなく、復元後のDB構造、関連、HTTPを照合しました。

未確認を成功扱いしない

確認できない項目は断定せず、次に必要な確認と分けて記録しました。

Juvekaの開発の進め方
相談から公開後まで、判断材料と成果物を残します。
Working style

一緒に画面を見ながら、言葉を合わせる。

業務を知る人と、システムを作る人が別々に考えると、完成時に「操作はできるが使いにくい」状態になりやすくなります。Juvekaは、画面や実行結果を共有しながら、名称、順序、権限、例外を一つずつ確認します。

  • 専門用語を使うときは役割を説明する
  • 一度に多くの変更を混ぜず、確認単位を小さくする
  • 成功結果と未確認事項を分ける
  • 秘密情報や実データを通常のメッセージへ載せない
  • 既存本番への変更範囲を明示する
Transparency

信用を作るために、誇張しない。

掲載すること

  • 実際に完成し、確認できた制作事例
  • 試験の対象、件数、結果
  • 使用した技術と役割
  • 安全のために分離した範囲
  • 制限、注意、実運用前の確認事項

掲載しないこと

  • 存在しない顧客や導入実績
  • 架空のスタッフ写真や推薦文
  • 未確認の安全性・法令適合
  • 必ず売上や利益が上がるという保証
  • 実患者、実職員、秘密情報

Juvekaは現時点でプロジェクトブランドとして紹介しています。法人規模、保守体制、正式な問い合わせ窓口など、確定していない情報を大きく見せません。

現場の困りごとを、説明できる仕組みに。

まずは、誰が、どの情報を見て、何を判断し、どこで困るかを整理します。