作って終わりにしない、という前提

設計、開発、導入、運用。四つの局面を別々の会社に分けると、
たいてい何かが落ちます。Dexallは一つのチームで担い、落ちない形をつくります。

PROBLEM

要件定義の時点で、ずれは始まっている

システムが現場で使われない原因として、よく挙げられるのは「要件の不足」です。しかし実際には、要件は足りているのに、解釈がずれていることが多くあります。

業務の言葉と、実装の言葉。この二つを行き来できる人がいないまま設計が進むと、完成した画面は業務の順番と噛み合いません。Dexallは、業務を理解したエンジニアが設計に入ることで、このずれを小さくします。

加えて、既存システムとの接続、データの持ち方、現場の端末環境といった制約を、設計の最初に確認します。

変えてはいけない手順を、先に合意する。帳票の順番、承認のタイミング、慣れた操作。ここを動かすと、どれだけ合理的でも現場は離れます。

DESIGN

業務の境界	どの業務をシステムに寄せ、どこを人の手に残すか。確認工程の位置を含めて決めます。
データの流れ	情報がどこで生まれ、どこで参照され、どこに残るか。重複と手入力を減らす構造を設計します。
外部連携	既存システム、基幹系、外部サービスとの接続方式と、障害時の振る舞いを決めます。
運用の前提	誰が監視し、誰が修正するか。運用側の体制を設計に含めます。

BUILD

画面と業務の流れを、動く形で早めに確認します。

確認済みの範囲から実装し、短い間隔で共有します。

データ移行と並行運用を設計し、現場の負荷を抑えます。

運用手順とドキュメントを整え、内製化できる状態にします。

開発の途中で方向を修正できることが、結果として品質を上げます。完成物を見てから判断する進め方では、修正コストが大きくなりすぎます。

そのため、画面の試作と業務手順の確認を、実装より先に置きます。合意した範囲から実装し、次の範囲を決める。この反復を基本にします。

OPERATION

CONTACT

既存システムと運用体制を確認したうえで、最初の範囲を提案します。