このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。
「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何？という方は第1回でご紹介していますのでそちらを参照してください。
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①
今回はアジャイル宣言の背後にある原則その11「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」についてです。
ITアーキテクチャ構築の主導者は誰か
ITアーキテクチャの主導権は必ずユーザ企業が握ることが重要です。当たり前のことのように聞こえるかもしれませんが、ITベンダーへの依存度が高い日本のユーザ企業ではITアーキテクチャにかかわる思想すらベンダー任せになっていることも珍しくないように思います。
実際、「ユーザサイド支援として入ってもらっているのに坂口さんはベンダーサイドの仕事までやっているのでは？」とお客様に言われたこともあります。私としては“本来”ユーザがやるべき役割分担をやっていたつもりなのですが、今までベンダーにお任せしてきたユーザ企業の担当者からすると“自分たちの担当外”に見えてしまったのかも知れません。
しかしITベンダー任せでは、最良のアーキテクチャを構築することは出来ません。ITベンダーが把握しているのは自社が構築・運用を担当しているシステムに乗っかっている業務プロセスと、（良くて）その周辺くらいです。マルチベンダーであったり、一部業務をBPOしていたりする状態で、ベンダーが最良のアーキテクチャを提案できるはずがありません（ITベンダーの問題ではなくユーザーの期待値の誤りです）。最良のアーキテクチャを構築する、守っていくことは、ユーザ企業が主導する必要があります。
ITアーキテクチャの検討の実例
「ITアーキテクチャ」と言われてもイメージしにくいという方もいるかも知れませんが、具体的な検討内容としては例えばアプリケーションアーキテクチャで言えばどのアプリケーションにどのビジネスプロセスを担わせるか？を考える、特にシステム間連携時にどこまでを前側システムでやり、どこからを後側システムでやるか？を考えるということもひとつの要素ではないかと思っています。
例えばあるお客様は疎結合に近いアーキテクチャを持っていて、システム間のデータ連携は各システムのハブとなるDB（これを共通DBと呼びます）を中継する仕組みとなっています。この場合、前側システムから共通DBに連携する際にどんな変換処理を行い、共通DBから後側システムに連携する際にどんな変換処理を行うのか？という切り分けがなければ処理ロジックが分散し、仕様の複雑化を招くことになります。
こういう場合、アプリケーションアーキテクチャを考える際の原則があればいちいち悩むことはなく、シンプルな設計に落とし込むことができるのではないかと思っています（例えば単純なコード変換などは前側→共通DBでやり、演算処理は共通DB→後側システムでやる、など）。
実際は毎回頭を悩ませながら「ここまではSAPがやり、ここから先は連携先システムでやろう」といったことをチームで議論しながら決めているのですが、少しずつ共通認識を持つことで今回のケースはこういう切り分けになるよね、ということが判断できるようになってくるといいなと思っています。
第9回はアジャイル宣言の背後にある 原則その11「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」 について、アーキテクチャ構築の主体はユーザサイドであることと、アーキテクチャ構築にあたっての実例をご紹介しました。
次回はその7「動くソフトウェアこそが進捗の最も重要な尺度です」について書くつもりです。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
