建設業界の変革を目指すマッチングプラットフォームを3ヶ月で刷新
ユニオンテックが挑んだレガシーからの脱却、キモは技術選定と役割分担
2月23日に開催された「JAWS DAYS 2019」のX-Tech枠でセッションを行なったのは、建設業界をテクノロジーで変革するユニオンテックの井上心太さん。「レガシー化したアプリケーションをAWSを使って3ヶ月で刷新した話」というタイトルで、自身の体験に基づいたシステム刷新プロジェクトを説明した。
ユニオンテックの井上心太さん
50兆円規模の建設業界を変革するユニオンテックとSUSTINA
ユニオンテックは、今年20年目の建設会社。創業者の大川祐介氏（現会長）は職人として長らくクロスや床の仕上げといったオフィスや飲食店の内装を手がけていたが、昨年からは建設×ITのテック企業を指向しつつある。その結果、設立20年目にして、米国のベンチャーキャピタルから約10億円の資金調達を実現。「業界の常識を変革し、再編する社会的存在意義の高いリーディングカンパニーへ」をビジョンに、オフィス内装を手がける「UT-SPACE」に加え、建設会社向けのマッチングプラットフォーム「SUSTINA」、個人と職人のマッチングプラットフォーム「CraftBank」を手がけている。
こだわりのオフィス内装を提供するUT-SPACE
井上さんは会社と事業の概要に続いて、同社がマッチングプラットフォームを手がける背景となった建設業界の説明に進む。建設業界は国内2位となる約51兆円の市場規模にもかかわらず、IT化が遅れているという。「発注先と受注先の情報の非対称性がすごく顕著な業界。発注元は発注先がないと言い、受注先は次の仕事がないと言っているので、そもそもマッチングがない。10年前に他の業界に起こったことが、建設業界では普通に起こっている」と井上さんは語る。
こうした情報の非対称性は、「14次請け、15次請けまである」（井上さん）という建設業界内での多重下請け構造と、知り合いづてで仕事を受発注しているオフラインでのやりとりが問題だという。これらの情報の非対称性を解消するのが、前述したSUSTINAとCraftbankという2つのマッチングプラットフォームだ。
非効率な工事手配が最大の課題となる
工事業者同士をマッチングさせるSUSTINAは、登録者数がすでに7300社に達し、検索サービスや地図アプリ、ニュース配信など周辺サービスを13個も作ってしまったため、安定稼働が難しくなってきたという。昨年、ジョインした井上さんがプロジェクトを調べてみると、「度重なる仕様変更と短い納期で増え続けた拡張性のないコード」と「最大1000社が利用することを想定したインフラ」という2つの原因が課題だったという。「外注先が雑に作ったわけではなく、今できることを積み重ねた結果として動かないところまで来てしまったのかなと思う」と井上さんは語る。
そのため、井上さんはCTOとしてSUSTINAシステムの作り替えを宣言。「スケール可能なアプリケーションインフラを最速で構築する」というフォーカスを定めて、技術選定と役割の明確化を行なったという。
目的に対してオーバーテクノロジーな技術選定にならないよう
まずは技術選定。意気込んだシステムの作り替えということで、当初は「React＋ReduxでSPAにして、Next.jsでSSRできるようにして、PHP7でAPI作って、いい感じにAWSでインフラ作るか。なんならk8sとか使ってみたい」くらいの妄想していたが、あきらかなオーバーエンジニアリングだった。「今回作り替えるのはB2Bのマッチングプラットフォームなので、そんなにエッジの効いた技術を使う必要はない。フォーカスに基づいて技術選定をし直しました」（井上さん）。
技術選定はオーバーテクノロジーにならないように
その結果、選んだのがPHPのフレームワークである「LARAVEL」を採用した。「設定ファイルを書くだけで、AWSと容易に連携できる。考えることをなるべく減らすために、インフラの構築や運用の作業を小さくしたかった」（井上さん）というのが理由だ。また、同じ理由でコンテナもDockerを採用することにした。
この2つが技術として決まったことで、サービスの選定はスムーズになった。まずコンテナ管理をAWSに任せるべく、試用の結果ECS＋Fargateを採用。また、既存システムのレスポンスを引き上げるため、データベースとしてAmazon Auroraを使うことにした。
結果的に1週間でインフラの構築が完了した。とはいえ、継続的インテグレーション（CI）に関してはCodeBuildを用いてコンテナごとにリリースを分けることが難しく、結局Jenkinsを用いたという。サービス選定も決定にこだわることなく、試用しながら最適なものを選んでいったという。
1人1役を徹底！開発、DB移行、仕様策定を3人で実現
もう1つ重要だったのは、役割の分担だ。有名なブルックスの法則では「遅れたプロジェクトは、あとから人を追加しても早くならない」という法則がある。これは人数が増えるとコミュニケーションコストが増えることに起因しているという。
そのため、「1人1役、最低限の人数」を目標に、開発1人、DB移行1人、仕様策定1人という役割を決めて、3人でプロジェクトを動かした。トラブルがなかったわけではないが、「開発はボリュームがあって大変ではあったけど、すりあわせたあとは範囲が明確」ということで、結果的によかったという。また、13あったサービスは本体のみ作り直し、残りは思い切ってクローズや事業整理し、きちんと断捨離した。
1人1役で最低限の人数。3人でプロジェクトを動かした
新SUSTINAは約1ヶ月前の1月30日にオープン。当初は多少の不具合はあったが、現在は安定してサービスを提供している状態。「10秒くらいという最近のWebサイトとしてはあり得ないレスポンスだったのですが、300ミリ秒まで短縮できました」（井上さん）とのことで、刷新の効果はきちんと得られた。安定稼働が実現したことで、現在では定期的な機能追加も行なっているという。
最後、井上さんは技術選定について「AWSに任せられるところは任せ、シンプルに作る。目的に応じて使いたいものを使う方がよい」、役割の分担に関して「役割も人数もしぼって、作るモノと目的も絞りましょう」とまとめた。
週刊アスキーの最新情報を購読しよう
