Graatが大成建設のDX基盤「X-grab」の設計を担当
大成建設様では7000 社 7 万人が利用する基幹システムを刷新を進めており、その基盤となる「X-grab」においてGraatが全体のアーキテクチャ設計を担当しました。
以下の記事から、一部を引用して紹介します。
- 大成建設が 7000 社 7 万人が利用する基幹システムを刷新! Azureが支える「建設DX の本質」とは
- ITアーキテクト岡大勝氏・鈴木雄介氏と大成建設 田辺要平氏が語る 7万人が利用する巨大システム刷新を支えた「チーム力」のリアル
X-grabの要件はデータ管理における安全性と柔軟性の両立でした。
1 点目は大成建設だけではなく、グループ会社や取引先各社、さらに海外など、さまざまなユーザーが利用することです。ユーザーの認証情報のソースが複数でありながら、認証そのものや認可は大成建設が一元管理する体制が求められました。2 点目は、認証認可によって図面、写真、3 D モデルなどのデータに対する複雑な制御が必要だったことです。建設工事にはさまざまな関係者が関わるため、現場での情報管理に厳しい統制が必要です。制御は、ユーザーの所属組織だけではなく、そのプロジェクトに関わる立場や役割から決定され、さらに手動での任意設定も可能にする必要がありました。
3 点目は、将来的に建設プロジェクトを推進するための多くの機能が必要だったことです。プロジェクトの提案、立ち上げ、業者の管理、建設現場の安全管理、竣工後の管理など、さまざまな機能が存在しています。それらのフロント機能は時代によって変化していくため、バックエンドとも切り離し個別に開発できるようにする必要がありました。
これらの要件を叶えるためにGraatが提案したのが「認証とデータの管理機能をプラットフォームとして提供し、その上に業務システムを段階的に整備する」という構成です。
この設計を進めるにあたり以下のような進め方をしました。
まずは現状を把握するため、数週間かけて従来システムの動き方などをひたすら整理していきました。サービスブループリントに落とし込むことで、システムとデータの関係性がどうなっているのか分かってきます。その絵を描いた上で、次はToBe（理想像）を描いていきます。図に新しいデータ基盤などを差し込んでいき、実現可能かどうか検証していきました。意見を聞いて、ケースごとにサービスブループリントを描いて実験を繰り返しました。複雑なものをストーリーに分解して理解するのです。ITアーキテクト岡大勝氏・鈴木雄介氏と大成建設 田辺要平氏が語る 7万人が利用する巨大システム刷新を支えた「チーム力」のリアル
ところが、この時点では、この進め方を信じられていなかったといいます。
田辺： 実は私はこの段階で、「いつものように無駄になる作業だな」と思っていました（笑）。このような業務の流れを整理する手法は、これまでも他社に散々付き合わされて、役に立ったためしがなかったからです。特に今回は特定の業務を実現するシステムではなく、プラットフォームとして機能するフレームワークなのですから、なおさら意味のない作業に感じたのです。ITアーキテクト岡大勝氏・鈴木雄介氏と大成建設 田辺要平氏が語る 7万人が利用する巨大システム刷新を支えた「チーム力」のリアル
しかし、工程が進むにつれ、X-grabのコンセプトが明確になっていくことに驚きを感じていただきました。
田辺： ＜中略＞その後、鈴木さんの“すごさ”を実感することになりました。彼はそこまでで作ったAsIs（現状）の膨大なサービスブループリントをもとに、シンプルな概念図を描いて見せてくれました。「これからやりたいことはこれでできる」と。その図はシンプルながら、抜けや漏れが見当たらず、システムを発展させていくための自由度も高かったのです。岡： サービスブループリントを描く過程が、鈴木さんの頭の中に現状をインストールする作業でした。そして、それらの複雑な業務やデータを抽象化しつつ、将来の仕様変更なども見据えて、シンプルな概念を見いだす。鈴木さんは、そのようなセンスが優れています。
ITアーキテクト岡大勝氏・鈴木雄介氏と大成建設 田辺要平氏が語る 7万人が利用する巨大システム刷新を支えた「チーム力」のリアル
その上で、基盤の構築にはアジャイルとマイクロサービスを採用して進めていくことにしました。対象が巨大な基盤であるからこそ、こういった選択をすることが必然だと判断したためです。
「方針やビジョンが明確になっても、どう具体化していくかについては不明瞭なこともたくさんありました。当然ながら、そのまま残る既存システムもあり、再構築するシステムもあり、新しく作られる機能もあります。メンバーの人数も限られますので、それらすべてのシステムの設計・開発を擦り合わせることを一度に行うことは不可能だと感じていました。そこで、アジャイル開発を採用し、段階的に明確にしていきながら、対応するようにしたのです」（鈴木 氏）。
「7000 社 7 万ユーザーが利用するシステムの刷新を 1 つのプロジェクトでやるほうが怖いです。巨大なシステムを完全にコントールできる人はいませんし、事前設計が極めて正確でなければなりません。今日の巨大化する業務システムについて、正確に事前設計することはムリなのです。マイクロサービスも巨大化したシステムをどう管理するかという課題を解消するための現実解として始まったものだと考えています。僕はエンタープライズこそ、小さなチームが有機的に連携してサービスを開発する体制に移行すべきだと考えます。小さなインテグレーションによりチェックポイントも多くなり、大問題になる前に対処できるようになります。リスクコントロールとしてはむしろ安全なんです」（鈴木 氏）。
こうした新しい進め方は内製化という点でも大きな成果を生み出しています。
「これまでの開発では、社内の開発標準に則りある程度決まったやり方でアプリケーションを開発し、運用標準に沿って安定的に運用してきました。しかし今回は、バックエンドサービスと小さなフロントのサービスをいくつか作り『やってみてだめなら考えよう』という発想で取り組みを進めていきました。それを繰り返していった結果、リソースも自分たちの手で簡単に作ることができるようになり、例えば『テスト環境が必要だ』となっても即座に対応が可能となりました。これまでに実際に作ったリソースを数えたら 1000 を超えていたほどです。今まで経験のない環境構築を達成できたからこそ、新しい技術を取り入れることのハードルが下がりました。今までやったことないからやめようではなく、こんないいものがある。じゃあ試してみよう、やってみよう、というマインドに変化したんです」（安部 氏）。
X-grabはすでにローンチされており、一部の業務機能が移設され、稼働しています。並行して、さらなる機能追加に向けて日々概念や考え方を土台に議論をしており、今後、さらなるX-grabの進化に関わっていくのは、弊社としても楽しみです。
