開発と実装

仕様策定から統合まで、OTOKO®がアプリケーションを開発し、既存のシステムやプロセスと連携させます。

業務アプリケーション、デジタル製品、社内ツールのいずれであっても、既存システムでは無理なく実現できない業務のためのソフトウェアを開発します。

業務部門との要件分析、脅威モデル、C4モデルに基づく目標アーキテクチャ コードを書き始める前に定めるドメインモデル、データモデル、インターフェース契約 コードレビューと業務部門による検収を伴う、短いイテレーションでの開発 OWASP ASVSに準拠したセキュアな開発、検証済みの依存関係、署名付きビルド ソースコード、アーキテクチャドキュメント、運用マニュアルを含む引き渡し

ソースコードとビルドパイプラインを備えた稼働可能なアプリケーション 脅威モデルを含むアーキテクチャドキュメント ランブックと緊急時対応計画を含む運用マニュアル

現在の業務フローと例外処理の例 業務上の意思決定を行う責任者 既存システム、データソース、運用要件

保守計画はこれまで表計算ソフトで管理されていました。業務アプリケーションが、設備、日程、責任分担、承認を一元的にまとめます。最初の拡張段階では1つの拠点を対象とし、他の拠点は業務面でプロセスを検証してから初めて追加します。

.NET C# Go Rust TypeScript PostgreSQL

出発点となるのは、投資に見合う価値を生む業務フローです。後にそれを使う人々とともに、用語、状態、業務ルールをモデル化します。例えば承認は単なるボタンではありません。代理対応、権限、期限、判断の取り消しが、すべて整合している必要があります。これらのルールは、データモデルとテストの一部となります。 最初のバージョンは、完結して利用できる一つのプロセスに集中します。追加機能は、実際の利用から得たフィードバックをもとに補っていきます。これにより、検証可能な価値を持つ製品が生まれ、未完成の画面の寄せ集めにはなりません。

バックエンド、ユーザーインターフェース、データ管理については、貴社の既存システム環境と今後の発展の見込みに基づいて技術を選定します。既存のスキル、インターフェース、運用要件は、短期的な技術トレンドよりも重視します。現在取り扱う技術には.NET、Go、TypeScriptなどがあり、システムに近い領域のコンポーネントは個別に評価します。 モジュールの境界と責任範囲は、変更の経緯を後から把握できるように定義します。認証情報はソースコードに含めず、業務ルールをユーザーインターフェースだけに置くこともしません。レビュー、自動チェック、バージョン管理されたデータベース変更は、実装の最初から並行して行います。

各イテレーションでは、既知の制約を伴う利用可能な機能を示します。業務上の検収と技術的なリリース判断は、別々に検討します。正しく計算された注文は業務的には正しくても、負荷時の挙動やエラー処理がまだ本番環境に適さない場合があるためです。それぞれの拡張段階で必要な証跡は、共同で定めます。 合意した納品範囲には、ソースコード、再現可能なビルド、ドキュメントが含まれます。本番稼働の開始にあたっては、データ移行、トレーニング、責任分担、障害対応について明確にします。利用権、外部コンポーネント、その後の保守については、引き渡し前に取り決めます。

アプリケーションは、複数の人が同時に同じ在庫を変更する場合にも正しく動作しなければなりません。2件の予約が、気づかれないまま同じ最後の1点を割り当ててしまうことがあってはなりません。そのため、どの変更をまとめて成功させる必要があるか、どの競合が業務上のフィードバックを必要とするかを見極めます。データベースの制約、トランザクション、バージョンチェックは、この課題のさまざまな部分を解決できますが、ユーザーインターフェースだけではこれらのルールを担保できません。 一方、より長い業務プロセスは、単一のトランザクションには収まらないことがよくあります。注文、外部の決済サービス、出荷承認は、それぞれ固有の失敗状態を持ちます。案件は、明確に定義された状態と許可された遷移でモデル化します。繰り返し送信されるリクエストには、適切なトランザクションIDを付与し、接続の切断が自動的に重複した処理を引き起こさないようにします。部分的な失敗が発生した場合には、一律の技術的な再実行ではなく、承認の取り消しなど業務的に定義された是正処置が必要です。

SaaS製品や社内プラットフォームでは、利用者のアイデンティティと、特定のデータに対する権限とを区別します。ログイン済みの従業員が、あらゆる請求書や注文を自動的に閲覧できてはなりません。アクセスはバックエンドで、組織、ロール、案件の各レベルで検証します。エクスポート、検索インデックス、バックグラウンド処理、キャッシュされた結果についても、これらの境界を考慮する必要があります。 テナント識別子を持つ共有テーブル、分離されたデータベーススキーマ、専用のデータベースは、それぞれ分離、移行、復旧に対する要件が異なります。必要な分離度と貴社の運用体制に応じてモデルを選択します。複数のテナントを用いたテストでは、特に不正なアクセスを重点的に検証します。監査ログには、業務上重要な変更を適切な文脈とともに記録します。どのようなデータを含めるか、どのくらいの期間保持するかは、明示的に定めます。

データ構造は、クエリと業務ルールに従って設計します。追加のストレージ技術を導入する前に、典型的なフィルター、並べ替え、集計、書き込み処理を検証します。無制限の結果リスト、繰り返される個別クエリ、大量のデータ転送は、サーバーの負荷がそれほど高く見えなくても、アプリケーションの速度を低下させることがあります。現実的なデータ量での測定によって、インデックス、クエリの変更、ページネーション、あるいは別のタスク分割が有効かどうかが分かります。 キャッシュとは、データの鮮度に関する意図的な判断です。保存された結果がいつ無効になるか、どの利用者がそれを閲覧してよいかを、明確にしておく必要があります。大規模な計算はバックグラウンド処理として実行できますが、その場合は進捗表示、再開機能、失敗状態への対応が必要になります。拡張にあたっては、業務ルールを技術的なアダプターから分離します。自動化されたテストとバージョン管理されたデータベース変更が、こうした境界を担保することで、新しいチャネルや別の事業者を追加してもすべてのモジュールを変更する必要がなくなります。

アプリケーション環境、要件、リスク 業務部門、IT、情報セキュリティ、OTOKO®ソフトウェアアーキテクト 評価済みの案件、棚卸し、セキュリティ・運用要件

アーキテクチャ、テクノロジー、運用モデル 業務部門、アーキテクチャ、データ保護、情報セキュリティ 目標アーキテクチャ、脅威モデル、テスト戦略、運用モデル、マイルストーン