レガシーシステムがネックになり、将来のためのIT投資が進められない
という事象が多くの現場で発生しています。

  • システムの老朽化・複雑化・ブラックボックス化
  • 既存のシステムがネックで本格的なDXが困難
  • 既存のITシステムがビジネス・プロセスに密に結合しており刷新できない
  • 運用・保守コストの増加(負債の増大)
  • IT人材をプロフィットセンターに入れることができない

レガシーシステムからの脱却は、ビッグバン(一足飛び)での実現は不可能だと言えます。
業務ドメインごとに段階的移行の道筋を立てる必要があります。

移行戦略:ビックバンではなく段階的な移行

マイクロサービスを導入するとともに、
切り分けたドメイン単位での開発チームを組成することで、システムのブラックボックス化を防ぎ、ビジネスニーズへの柔軟でスピーディな対応を実現。

アプリケーション視点

  • 【課題】ブラックボックスで肥大化し改修が困難になっている
  • 【結果】技術が古くノウハウの継承が困難で開発コストが高い
  • 【目指す姿システムの透明性が高く改修しやすいアーキテクチャ
  • 【目的ノウハウの継承が容易で開発コストが低い

インフラストラクチャー視点

  • 【課題】モノリシックなシステムに最適化された標準化が定着
  • 【結果】テクノロジーの変化に適した開発・運用プロセスではない
  • 【目指す姿小さい単位で頻繁に改修ができる基盤の確率
  • 【目的ノウハウの継承が容易で運用コストが低い

マイクロサービスアーキテクチャ導入

システムの堅牢性・回復性向上

システムがマイクロサービスに分解されることで、特定ドメインのシステムがダウンした場合でも、他ドメインへの影響を限定的に抑え込める。
システム復旧も最小単位で実施できるため、回復にかかるリードタイムを最小化できる。

ドメイン単位での開発チーム組成

チームの自律性向上

チームの責任範囲が明確になるとともに、チームがカバーする技術領域が広がることで、各チームがそれぞれのドメインに適した設計・技術が選択できるようになる。
※チームメンバーが必要なスキルセットを獲得している前提

ビジネス機能のスピーディな開発

ビジネスニーズの変更、システム要求の変化が発生した場合、担当ドメインのチームのみで即座に開発、テスト、リリースまでが実施可能。この時、システムとドメインが重なっていることで、他チーム・ドメインとの調整が基本的には発生しない。

ドメイン分割、データ連携、組織改革を絡めながら、
将来のために必要なIT戦略の達成が可能なシステム・体制を実現。

業務ドメインに合わせたマイクロサービスアーキテクチャ導入
切り分けたドメイン単位での開発チーム組成
システム移行に関わる開発やシステム運用

提供サービスのポイント

case.01

ゴール=システム開発内製化

リスキリング、アジャイル開発導入の内製化支援を軸に、顧客企業内での人員再配置を前提とし、投資対効果の改善と社内チーム立ち上げに寄与。

<大手製造業様事例>

長年活用している基幹システム(AS400・COBOL)を刷新したいが、社内に適したスキルをもった社員がいない。
ユーザの役に立つものを開発するため、アジャイル開発で進めたいが、知見がない。

アジャイルコーチ、エンジニアが伴走する形でのアジャイル開発導入支援。内製化のために必要になるスキルセットの定義、スキル習得のためのトレーニング。

ユーザーの真のニーズに沿った開発の実現に向けたきっかけ作り。顧客メンバーによる業務システム開発が実施可能な体制構築。

case.02

圧倒的なスピードでの価値提供

アジャイル開発が得意なメンバー+各技術の専門家の支援により、プロジェクト開始からファーストリリースまでのリードタイムを短縮。

<デンソー様事例>

外部ベンダーが提供するパッケージ製品を導入したものの、業務ニーズの変更に対応できなかった(改善要望→納品まで半年など)
自動車業界全体が変革期を迎えており、市場の変化が激しくついていくことが難しかった。

顧客メンバーと弊社メンバーが共同のアジャイル開発チームを構築し、既存パッケージ製品のリプレイスを推進。
クラウド、OSS、コンテナといった先端技術の導入にあたっては、各専門家が開発をサポート。

プロジェクト開始から3ヶ月でMVPをリリース。ユーザーからのフィードバックに対する迅速な対応を実現。