ITアーキテクト岡大勝氏・鈴木雄介氏と大成建設 田辺要平氏が語る 7万人が利用する巨大システム刷新を支えた「チーム力」のリアル

[PR／ITmedia]

PR

　企業が大規模なDXに挑むとき、どんな壁が立ちはだかるのか。そして、どうやって乗り越えるのか。そういった課題に直面し、基幹システム刷新を社内外の「チーム力」によって成し遂げたのが、大成建設だ。協力会社を含む約7000社7万人が利用するシステム構築の裏側で何が生まれていたのか。企画・設計に携わった社内外の関係者に話を聞いた。すると、DXを目指す企業が陥りがちな考え方や、同社がそれを乗り越えられた理由が見えてきた。

AzureのPaaSをベースとしたバックエンドサービス「X-grab」開発

　大成建設は2003年に建設業向けのSaaSを導入し、約7000社の従業員などが利用するシステム「作業所Net」を運用してきた。建設プロジェクトで使用する図面や写真、3Dモデルなどの工事情報を管理・共有する基幹システムだ。今回のプロジェクトでは、このシステムを刷新し、Microsoft AzureのPaaSをベースとしたバックエンドサービス「X-grab」を開発。19年から企画し、22年5月にサービスの運用を開始した。

　「作業所Netは、1990年代に日本企業で始まったOA化の集大成として導入したシステム。紙の書類を電子ファイルに置き換え、効率化することが目的でした」と、同社建築本部 企画戦略部 企画室 ICT業務改革推進担当 チームリーダーの田辺要平氏は振り返る。そのシステムを次の時代を見据えたものへと変える必要があった。「社会はOA化からIT化へと移り、その先にDXがあります。業務の主体をファイルからデータへ、シームレスに移行するための基盤が必要です」（田辺氏）

　データを業務の主体として扱うためには、柔軟性の高い設計が必要となる。多様なユーザーがデータを扱えることに加え、将来の建設プロジェクトを見据えた多くの機能を利用できることが求められる。そういった要件から、建設プロジェクトの立ち上げ、現場の安全管理などのフロント機能を個別に開発できるようにした。X-grabはデータ管理のプラットフォームだ。フロント機能に必要なデータやファイルは、データボックス（箱）という仮想の箱に入れてX-grabに格納する。データボックスはタグによって制御され、権限を持ったユーザーやシステムだけに閲覧や編集を許可。フロント機能は、データの管理をX-grabに任せることで権限管理やデータ連携機能を開発する必要がなくなるため、より機能そのものに特化した素早い開発が可能になる。

　このシステムを開発するために、マイクロサービス・アーキテクチャの手法を採用。小さなチームが各機能を開発し、それを組み合わせて大きなシステムを構築する。大成建設としては、アジャイル開発も含めて、マイクロサービスによる大規模システム開発への初めての挑戦だった。

　このチャレンジを成功させるために欠かせなかったのが、社外の専門家との連携だ。田辺氏は「モノをつくるということは、関わった人たちのパーソナリティーやバックグラウンドにある知識の掛け算。専門性が高い人とどう関係を築き、その知識や表現力を生かしていくかが重要です」と話す。今回のシステム設計に携わったのは、ギックス Chief Technologist 兼 Chief Architectの岡大勝氏と、Graat（グロース・アーキテクチャ＆チームス）社長の鈴木雄介氏。田辺氏を含む3人に、お互いの関係性の構築やX-grabの企画・開発の裏側を振り返ってもらった。3人の語りによって、それぞれがどんな立場でどんな役割を果たしたかを明らかにする。DXに挑む際の“考え方”の参考にしてほしい。

信頼は100％でないと意味がない

――建設業界の大企業が、経験のない手法で開発に挑むにあたって、考え方を変える必要はありましたか。

田辺：　レガシー企業がマイクロサービス化されたシステムを開発するためには、大胆なマインドチェンジが必要でした。本プロジェクトの企画段階の意識としては、われわれはだいたい5周分くらい周回遅れの状態でした。それくらいモダンなIT技術に対する認識にギャップがありました。まずは、私を含む数人が岡さんのもとでマインドチェンジすることから始めました。

岡：　従来型のシステムは巨大かつ複雑で、メンテナンスに手間も時間もかかるのが当然でした。その構図が変わったのがモダンなITの出現です。いわゆるクラウドネイティブのテクノロジーが実用化されて、大きなシステムも分割して扱いやすくなりました。その一例として、例えばTwitterなど皆さんがご存じのシステムを例に挙げて、クラウドネイティブ技術が生み出された背景や、サービス停止せずにメンテナンスやアップデートができる仕組みの解説などをしました。

田辺：　そういった知識を取り入れながら、まずは岡さんに今回の開発のビジョンや構想について青写真を描いてもらいました。しかし、われわれも従来システムの知識と経験があるため、提案されたシステム設計に対して、どうしても否定的な感覚を持ってしまいます。

岡：　今回の場合は“集中から分散への変革”が必要でしたが、当初は理解してもらえませんでした（笑）。大成建設側から、システムをこう運用したい、という抽象度の高い要望を受け取って、本質的な技術の組み合わせを提案し、理解してもらうセッションを続けました。理解できるまで根気強く真剣に向き合ってくれた結果が、今につながっていると思います。

田辺：　私たちが学んだのは、専門家の提案を否定したり、部分的にしか受け入れなかったりすると、プロジェクトは失敗する可能性が高くなるということです。自分たちでは手が届かないものを手にするためには、「本当にそうか？」と思いながらも相手を信じなきゃいけない。信頼は100％でないと意味がないのです。新型コロナウイルス対策で報道されていた、政府と専門家の関係も同じですよね。専門性を備えた人との関係をどうしていくか。単なるアドバイザーではなく、全面的に信頼して自分たちが学ぶ姿勢を貫き通せるのか。その時、主体はあくまで私たち大成建設側でなければならない……そこが下手なプロジェクトが多いのではないでしょうか。

大成建設の田辺要平氏

シンプルさがプロジェクト運営の“法律”

――システムの構想を描き、それを具体的な設計に落とし込む段階で、鈴木さんが参加されたのですね。

鈴木：　まずは現状を把握するため、数週間かけて従来システムの動き方などをひたすら整理していきました。サービスブループリントに落とし込むことで、システムとデータの関係性がどうなっているのか分かってきます。その絵を描いた上で、次はToBe（理想像）を描いていきます。図に新しいデータ基盤などを差し込んでいき、実現可能かどうか検証していきました。意見を聞いて、ケースごとにサービスブループリントを描いて実験を繰り返しました。複雑なものをストーリーに分解して理解するのです。

岡：　これまで描いてきた抽象アーキテクチャを具象アーキテクチャに落とし込んでいく作業でした。仮説をもとにシステム構造を作って利用シナリオをぶつけて検証する、という基本的な作業ですが、アーキテクチャとして定義した構造が適切なのか検証できるとともに、その構造を使ってシステムがどう動くのかをあらためて理解できます。

田辺：　実は私はこの段階で、「いつものように無駄になる作業だな」と思っていました（笑）。このような業務の流れを整理する手法は、これまでも他社に散々付き合わされて、役に立ったためしがなかったからです。特に今回は特定の業務を実現するシステムではなく、プラットフォームとして機能するフレームワークなのですから、なおさら意味のない作業に感じたのです。しかし、すでに私たちは岡さんを信頼し、従来のやり方を引きずってしまう葛藤に打ち勝っているわけです。その岡さんが、鈴木さんの能力を信頼している。振り返るとそれが唯一のよりどころだったと思います。

　そしてその後、鈴木さんの“すごさ”を実感することになりました。彼はそこまでで作ったAsIs（現状）の膨大なサービスブループリントをもとに、シンプルな概念図を描いて見せてくれました。「これからやりたいことはこれでできる」と。その図はシンプルながら、抜けや漏れが見当たらず、システムを発展させていくための自由度も高かったのです。

岡：　サービスブループリントを描く過程が、鈴木さんの頭の中に現状をインストールする作業でした。そして、それらの複雑な業務やデータを抽象化しつつ、将来の仕様変更なども見据えて、シンプルな概念を見いだす。鈴木さんは、そのようなセンスが優れています。一方で、大成建設側には、その概念をきちんと理解し、現在・未来の業務との整合性を確認することが求められます。

田辺：　私たちもその点で鍛えられました。開発を進める中で、常に概念に立ち戻ることを繰り返しました。その中では整理しきれず、ダメだしされたこともあります。

鈴木：　検討を進める過程でデータの持ち方について口論になることもありましたね（笑）。「こうしたい」と言われても、別の観点、例えば保守性や性能から見て「それはできない」と主張するなど、議論を重ねました。

岡：　マイクロサービスベースのシステムは、サービス間の役割や関係性をあいまいにした瞬間から崩壊が始まります。シンプルな概念図は、巨大なチームを適切に動かすための“法律”として機能します。雑に矢印を書き加えたり方向を変えたりして関係を崩してしまうと、やりとりが増えて一貫性が取れなくなり、結果としてプロジェクトは破綻に追い込まれる。

田辺：　実装段階になると、自分たちの都合で概念図を無視しがちです。一見すると、概念図に反することを実装しないといけないように見えることは多々あります。システム連携図に対して、無邪気に新たな矢印を追加してしまいがちなのですが、そうするとシンプルさが失われていきます。その誘惑に負けてしまうと破綻するという感覚に、今では私も強く同意できるようになりました。

構想段階から携わっている岡大勝氏

「知らないことが何なのかを知る難しさ」を実感

――つい陥りがちな部分なのですね。一方、マイクロサービス化はメリットも大きいのでしょうか。

鈴木：　この手法のメリットの一つは、巨大なプロジェクト組織が不要になることです。システム全体が緩やかな機能の連携で成り立つので、同じように、それらの機能を作るチームも緩やかに連携し、それぞれのペースで開発を進められるようになります。また、機能の特性に合わせて、適切なチームを割り当てることもできます。

岡：　複雑さの局所化ですね。知るべきなのは自分の守備範囲だけです。また、基本的なデータ構造はAPI連携しているため、各チームは必要なデータをAPIから取ってくるだけで開発に使えます。プロジェクト運営のハードルを下げられます。“法律”である論理アーキテクチャ構造に則している限り、鈴木さんの言うように、サービスごとにサービスレベルもチーム編成も柔軟に決められることがマイクロサービスの最大のメリットですね。

田辺：　一方で、プロジェクトメンバー個々の感情とは関係なく、大成建設という企業の立場からみると、マイクロサービス化されたPaaSベースのアーキテクチャで開発する動機は、インフラにかかる費用でした。初期の試算では全てのリソースをVM（仮想マシン）で構築した場合と比較すると、7分の1で済む計算だったのです。これは莫大な金額差であり、新しいことに取り組むのに十分な理由になりました。

――実際の開発では、他の開発メンバーの意識や理解も変わりましたか。

田辺：　「知らないことが何なのかを知る難しさ」を実感しました。今回のプロジェクトは『ガンダム』で例えると、岡さんがアムロ・レイ、鈴木さんがシャア・アズナブルで、この2人が味方についている『Zガンダム』状態といえます（笑）。分からないことはいくらでも質問できます。しかし、何を質問すればいいか分からない。大抵は今行き詰まっていること自体を質問してしまいがちですが、行き詰まるまでの道のりが間違っていないか確認することこそ重要です。「この考え方がそもそも正しいのか」を2人に教えてもらわないと意味がありません。

　そのため、当社側のミーティングでは、課題が出てきたときに、考え方や質問の仕方を軌道修正するようにしました。自分たちが知らないことが何か分からない中で進めるプロジェクトでは、“仲介役”が必要です。私ができる限り仲介役となり、適切な質問ができるように促しました。そして、それは今も続いています。「みんなのマインドセットが変わったから成功した」というのは違う。私自身も含めてずっと変え続けなければならないものです。

システム設計を支援した鈴木雄介氏

――巨大プロジェクトにチーム力は欠かせないですが、まずはそれを支える信頼関係が重要ということですね。

田辺：　このプロジェクトは岡さんへの信頼から始まりました。言葉で説明しづらいですが、著書や選ぶ言葉、そして表現方法から感じ取りながら、信頼を構築していきました。そこに鈴木さんも加わって、新たな信頼関係が増えていくことで、課題を乗り越える根拠ができたのだと思います。このように信頼するに値する方と巡り会うこと自体が奇跡ですし、才能のある2人に本気で取り組んでもらえたことこそが奇跡だと社内メンバーにいつも言っています。

岡：　田辺さんは、私たちを信頼して素直にプロジェクトを進めてくれました。システム開発に限らずどんなことであっても、他の人に理解を委ねた状態で進行することは怖くてできません。自分の理解できる中で完結させようとします。今回のような大規模な試みであればなおさらです。しかし、田辺さんは少年のように純粋に信じて、まず言われた通りにやってみる姿勢で取り組んでいました。後から聞くと、田辺さんの中で腑に落ちた瞬間があり、それ以降はジグソーパズルのピースが組み上がっていくような感覚があったそうです。

　実はそれがとても大事な感覚で、外部の知見を完全に信じることで、自分たちだけでやるよりも何倍も大きな成果が生み出せるのですが、それだけでは最初の成果が上限になってしまう。今回のX-grabのようなマイクロサービスベースの継続的な成長を前提としたシステムの場合、信頼した相手に「任せる」のではなく、主体はあくまで大成建設であり、同社自身が成長し続けなければならないんです。大成建設が私たちと同じ視座を持ち、その上で主体的に取り組んでいただけたことが成功の決め手だと思っていますし、今後成功し続けるための組織的な基盤が構築できたことが最大の成果だと考えています。

鈴木：　田辺さんをはじめ、大成建設の方々と概念や考え方を徹底的に議論し、細かいレベルまで共有できたのがよかったです。システム開発では「機能が動けば、実現するための技術は何でもいい」と言われますが「考え方が何でもいい」わけではありません。筋の通ったポリシーやルールが共有され、その上にシステムを構築していくことで一貫性が生まれます。大成建設とは、この概念や考え方の適用について、全体の機能配置からデータ構成、さらにAPI構成、時には特定の項目の持ち方まで話し合い、設計しました。そこまで一緒にできたからこそ、われわれも本気で取り組めました。サービスはローンチしましたが、一部を具現化したにすぎません。現在も概念や考え方を土台に議論をし、アップデートし続けています。これからもX-grabは進化していくので、そこに関わっていくのが楽しみですね。