「システム負債を残さない」アーキテクチャ設計、企業規模が小さいうちに——トライバルメディアハウスが挑んだ「データとプロセスの最適化」


 成長著しい中小企業やスタートアップ企業が往々にして陥る落とし穴に、「未整備なシステムがビジネス成長の足を引っ張る」というものがある。せっかく本業が急成長しているのに、システムがそれに付いていけずにビジネスチャンスを逃してしまったり、コンプライアンス上の問題を引き起こしてしまうことが多々ある。


 こうした事態に陥ることをあらかじめ回避し、事業を順調に伸ばしていくためには、なるべく早いタイミングで将来の成長を見越したシステム整備を行っておく必要があるが、急成長している企業ほどシステム設計やBPRに十分なリソースを割くことなく放置しているケースが散見される。


 そんな中、企業規模がまだ比較的小さい段階から大胆なBPRとシステム刷新を断行したのが、大手企業の広告宣伝・PR・マーケティング部に対するデジタルマーケティングやソーシャルメディアマーケティングの支援実績を持つトライバルメディアハウスの情報システム部門だ。


 2023年2月21日、Darsanaがオンラインイベント「システム負債が『手遅れ』になる前に 中小企業でも実装できる『データとプロセス最適化』の現実解」を開催。トライバルメディアハウスでこれらの改革活動をリードした管理部門管掌取締役 兼 情報システム統括 の河野多香子氏と、実装を担当した同社開発部長 兼 基幹システム運用責任者の薄井庄治氏、基幹システム開発責任者の菊池耕路氏をゲストに招き、ビジネス面とシステム面の双方から活動の背景や経緯、裏話などについて赤裸々に語ってもらった。
※役職は登壇当時

無駄だらけの業務とバラバラのシステム

 本イベントの冒頭には、トライバルメディアハウス 管理部門管掌取締役 情報システム統括 河野多香子氏が登壇し、同社の改革の取り組みについてその背景や経緯、成果を紹介した。

トライバルメディアハウス 管理部門管掌取締役 情報システム統括の河野多香子氏

 河野氏はデータベース系のエンジニアとしてキャリアをスタートさせ、現パナソニックの子会社で経理系システム開発に従事した後、2001年からはヤフーにおいて広告システムの開発や情報セキュリティシステムの構築プロジェクトを率いてきた経歴を持つ。その後、2015年からバリューコマースにおいてCIOの要職を務めた後、2020年にトライバルメディアハウスに入社。現在は取締役としてシステム施策だけでなく、同社のコーポレートガバナンス全般を取りまとめる立場にある。


 なお同氏がトライバルメディアハウスに入社した当時は、同社が親会社との資本関係を解消して独立したばかりだったこともあり、システムもガバナンスも会社の実態から乖離した状態だったという。


 「子会社だったころは、何も考えずに親会社のガバナンスに相乗りしていました。独立を目指して数年前に自前の管理部門を設けたのですが、従来の方針をただ引き継いだだけだったので自社の実態に合っておらず、監査の際にガバナンスの体裁だけを取り繕っているような状態でした」(河野氏)


 また全社のガバナンスやシステム施策を部門横断で取りまとめる組織もなかったため、各部門でばらばらにシステムを導入・運用しているうちに、会社全体で見ると多くの無駄が発生するようになっていた。非効率な「紙の業務」がいまだに多く残っていたり、システム開発時に「声の大きな人」の意見が優先的に盛り込まれ現場の声が反映されなかったり、仕様書も設計書も残っていなかったりと、課題が山積していた。


 インフラやセキュリティに関しても、親会社のインフラを間借りして利用する範囲に限っては親会社が定めたガバナンスに従っていたものの、自社で独自に導入したシステムについてはほぼ何も考慮されていない状態だったという。

IDaaSとゼロトラストをベースにしたインフラに刷新

 こうした状況に陥ってしまった原因について、河野氏は「経営者が、『プロセスを最適化する』という考えに至らず、現場任せにしてきた結果、プロセスの全体最適や身の丈に合ったガバナンスについて考える立場の人が出てきませんでした。そのような状態が続くと、現場はどうしても自分たちの業務しか顧みなくなり、それぞれが業務を個別最適化していってしまいます」と分析する。


 当時、既に将来の上場を視野に入れていたこともあり、こうした個別最適化による「無理・無駄・むら」のある状態は決して放置しておくべきではない。そう考えた同氏は、同社のシステムおよび業務プロセスの抜本的な改革に乗り出した。まずはインフラ・セキュリティの改革のために投じる予算を策定。その際には、インフラ刷新によって従来と比べてインフラコストを7割程度にまで抑えられるプランを立てた。

 次に、従来の境界型セキュリティモデルを前提としたネットワーク構成から、ゼロトラストを前提として社内ネットワークを最小限に抑えた構成へと転換する全体方針を立てた。この方針に基づき「アカウント管理」「端末管理」「ログ取得」の3つのポイントでセキュリティ対策を講じるインフラ構成を策定するとともに、これまで親会社の借り物だったセキュリティ規定を、あらためて自社の実態に即したものに作り直すことにした。

 こうして検討を重ねたていった結果、最終的にクラウドベースのID管理サービス「Okta」を中心にシステム全体のセキュリティおよびガバナンスを集中管理する構成を定めた。メールやカレンダー、共有ストレージといったインフラサービスにはGoogle Workspaceを採用し、社内のコミュニケーションツールとしてslackやZoomといったクラウドサービスを導入することにした。その他のシステム機能に関しても基本的にはSaaSアプリケーションを採用することにしたが、自社の基幹業務を担う受発注システムに関しては内製する方針とした。

 加えて、得てして軽視されがちな運用業務についても、あらかじめきちんと設計した上で各部門に割り当てておくこととした。

既存業務をそのままシステム化するのはNG!

 受発注システムを内製するに当たっては、まずは社内に存在するデータおよびプロセスとシステムとの関係を洗い直すところから始めた。業務で扱うさまざまな「情報」をすべて洗い出した上で、それらが最終的に財務諸表とどのように結び付いているかを図に描いてデータの全体像を把握するよう努めた。また各部門で行われている業務プロセスも洗い出し、それらがシステムとどのように関わって最終的にどのインタフェースを通じてどこに対してアウトプットされるかも整理した。

 ここまでの点をあらかじめきちんと整理できたら、次にシステム化の方針を定義した。具体的には「納期」「証跡の取りやすさ」「データ構成と蓄積」などの要件に高い優先順位を与える一方で、ユーザーインタフェースについては工数との兼ね合い上優先順位を落とし、ある程度割り切った仕様とすることにした。

 システムの具体的な実装方法に関しては、当初はパッケージ製品を使うことも検討したものの、「弊社のビジネスモデルでは納品と請求のタイミングがずれることが往々にしてあるのですが、これに対応できる受発注パッケージ製品が見付かりませんでした。またワークフロー機能に関しても弊社の業務フローに対応できるパッケージ製品ががなく、やむなく内製するしかないとの結論に至りました」(河野氏)という。


 なおフロントのユーザーインタフェース部分に関しては、極力開発工数を抑えるためにノーコードツールを使って開発することにした。こうして節約した工数を業務プロセスおよびロジック部分の開発に投入したが、その際には既存業務をそのままシステム化するのではなく、それぞれの業務の意味や目的をきちんと理解した上で、そこから抽出したロジックをシステム化するという方針を徹底したという。


 加えて、こうして開発したシステムを現場にしっかり根付かせるべく、社内説明会を開催してユーザーに利用方法をなるべく丁寧にレクチャーするよう心掛けた。

自社に適した仕組みを「自分たちの手で」作り上げる

 こうして内製開発した受発注システムを実際に業務に適用してみたところ、それまで約4人月かかっていた受発注管理作業を1人月でこなせるようになるなど、業務効率の大幅な向上が達成できた。また悪い意味での個人の裁量がなくなり、監査や審査で必要とされる証跡が確実に取得できるようになったことで、ガバナンスのレベルも大幅に向上した。


 さらに副次的な効果として、この新システムの運用を通じて貴重な経営データがシステム内に蓄積されるようになり、これらを分析することでデータを基にした正確かつ迅速な意思決定を下せるようになったという。

 こうして同社は事業や経営の実態に即したシステムや業務、ガバナンスを手に入れることができたが、これを可能たらしめた要因について河野氏は次のように考察する。


 「まずは経営がトップダウンで取り組みをリードすること。その上で既存業務をそのまま自動化するのではなく、現状のプロセスをしっかりひも解いた上でシステム設計を行うことが大事です。また部門の垣根を超えたデータ・プロセス設計を行うことも重要なポイントです。そして何よりも大切なのは、他所から持ってきたポリシーやシステムではなく、自社の企業規模やフェーズ、事業リスクに適した仕組みを自らで考えることだと思います」(河野氏)

SaaSアプリケーションと独自開発システムを連携

 続いて同社 ソリューション開発部 薄井庄治氏が登壇し、受発注システムを内製開発した経緯やその結果、当時を振り返っての反省点などを説明した。

トライバルメディアハウスソリューション開発部の薄井庄治氏

 この受発注システムの全体構成は、大まかにバックエンド部分とフロントエンド部分の2つに分かれている。バックエンド部分は主にデータベースの管理や入出力インタフェースを担っているが、この部分についてはSaaS型の販売管理アプリケーションをベースに開発した。そして主にユーザーインタフェース機能を担うフロントエンド部分に関しては別途AWS上で一から機能を実装し、こことバックエンド部分とを連携させることによってシステム全体を形作っている。


 バックエンド部分に採用したSaaS型の販売管理アプリケーションは、ノーコードでデータベースを簡単に構築でき、かつデータベースにデータを入力するためのフォームも容易に開発できるようになっている。また条件分岐やAPI呼び出しといった簡単な処理もノーコードで実装できる「自動処理機能」と呼ばれる機能も備えており、これらを有効活用することで効率的な開発が可能になったという。

 しかしその一方で、ユーザーインタフェース関連の機能はあまり充実していなかったため、この部分に関しては別途AWS上で一から開発することにした。SaaSアプリケーションが備えるAPIを通じて毎分データを取得してデータベースに保存し、その内容を「プロジェクト一覧」「受発注状況一覧」などの形で表示させたり、月次の会計処理を行う機能などを実装した。


 さらには、契約書のデータを外部の電子署名サービスと連携させたり、工数管理を行うために外部の勤怠管理システムから勤怠データを取得するなど、外部システムとデータを連携させるためのAPI群も独自に設計・実装した。

ノーコード開発のメリットとデメリット

 なおSaaSアプリケーションを選定する際には複数の製品を比較検討し、「短納期に対応するために開発工数をなるべく抑えられること」「自社独自の受発注ルールに柔軟に対応できること」といった要件に合致する製品を最終的に選定した。


 選定した製品は前述の通り、ノーコードで効率的に開発でき、かつ外部サービスのAPIを呼び出せるなどさまざまなメリットがあった一方で、実際に開発作業を始めてみると製品選定時には気づかなかったさまざまな制約にも直面したという。


 「ノーコードで手軽に開発できる分、どうしてもかゆい所まで手が届かないため、場合によってはあの手この手で機能不足を補完する必要がありました。また自動処理機能はとても便利でしたが、実際に使ってみるとループ処理に対応していないことが分かるなど、後になってから制約が多いことも判明しました。今から思えば、製品選定時にもっと入念に技術検証を行っていればよかったかもしれません」(薄井氏)


 なおフロントエンド部分に関しては先述の通りAWS上で独自に実装したが、同社はもともとAWS上でのWebアプリケーション開発案件を数多く手掛けており、AWSに関するスキルを豊富に有していたことから、今回の内製開発でもインフラ構築で苦労することはほとんどなかったという。


 ただしSaaSアプリケーションの外部連携APIの仕様に一部制限があり、外部サービスと直接データをやりとりできないケースもあったため、それを補うためにいったんフロントエンド部分でデータを受け取り、これを独自開発したAPIを介して外部サービスとやりとりするという回避策をとった。そのために追加の開発工数が必要になったものの、この一連の仕組みを実装したことで基本的にどんな外部サービスとも柔軟にデータを連携できるようになったという。

オフショア開発拠点とのコミュニケーションが肝

 なお実際の開発作業は、要件定義と設計を日本で、そして実装をベトナムにある同社の開発拠点で行った。ベトナム現地のエンジニアには基幹システム開発の経験やノウハウがなかったため多少の不安もあったものの、いざふたを開けてみるとベトナム側と日本側の双方に優秀な人材が配置されていたことも幸いし、比較的スムーズに作業が運んだという。


 「日本語のドキュメントをベトナム語に翻訳して現地のエンジニアに伝える役目を担うコミュニケーターの方が非常に優秀だったことに加えて、日本側にも非常に優秀なSEの方がプロジェクトに参画していただいたおかげで、当初抱えていた不安はほぼ払しょくできました」(薄井氏)


 その一方で、SaaSアプリケーションのAPI仕様の制約に振り回されたり、旧システムの仕様を一部踏襲せざるを得なかったために苦労を強いられた場面もあった。また初めて採用した製品だったこともあり、アジャイル的な手探りでの開発にならざるを得なかったが、「今思うとウォーターフォール型で進めた方がよかったかもしれません」と薄井氏は反省点を述べる。


 さらに苦労したのが、旧システムからのデータ移行だった。それまで17年間運用を続けてきた旧システムのデータを今回開発するシステムに移行する必要があったが、旧システムの仕様がブラックボックス化されており、データベース構造を把握して適切なデータを抽出するのに非常に苦労したという。幸いなことに旧システムの開発に携わったエンジニアの協力を仰いで何とか旧システムの仕様を理解することができたが、薄井氏はこのときの経験を踏まえて「やはりシステムを開発する際には、後々のメンテナンスや更改のためにもきちんと設計して、仕様をドキュメントとして残すことが大切だとあらためて実感した」と語る。

ユーザーの業務をイメージしたUX設計が重要

 こうしてさまざまな苦労や紆余曲折がありつつも、新受発注システムは無事本番リリースへとこぎ着けることができた。その結果、先にも紹介したように生産性向上やガバナンス強化などさまざまな成果が得られたが、開発者の目線では幾つかの反省点も残ったという。


 「システムを設計した時点では、ユーザーはこちらが意図した通りにきちんとデータを入力してくれるだろうと勝手に思い込んでいたのですが、実際にリリースしてみるとこちらが想定できなかったさまざまなパターンの入力ミスが発生して、それらの対応に追われました。今、思うと、やはり設計時点でユーザーの利用シーンを十分にイメージできていなかったのだと反省しています」(薄井氏)


 ただし現在では、こうした問題もあらかた解決され、新受発注システムは極めて安定して稼働しているという。同システムの開発の経緯を振り返りながら、薄井氏は今回実現したような「システム化による業務プロセスの自動化」を目指す際のポイントを次のように挙げる。


 「プロセス自動化を実現するためのインフラやツールなどは一通り揃っているので、技術的なハードルはとても低くなっています。一方で業務プロセスやシステムの課題は会社ごとにまちまちなので、唯一正解のメソッドやアーキテクチャというものは存在せず、対象業務をきちんと理解して最適なUXをその都度作り上げるしかありません。そしてその際には、システム化やツール導入はあくまでも手段であり目的ではない旨を肝に銘じて、本来の目的を見失わずに最後まで走り切ることが何よりも重要だと思います」(薄井氏)

執筆

吉村哲樹記事一覧

早稲田大学政治経済学部卒業後、メーカー系システムインテグレーターにてソフトウェア開発に従事。その後、外資系ソフトウェアベンダーでコンサルタント、IT系Webメディアで編集者を務めた後、現在はフリーライターとして活動中。

イベント企画

後藤祥子記事一覧

ITmediaエンタープライズの担当編集長を経て独立。現在はエンタープライズITの変革者に伴走するメディア「Darsana」の編集長として、変革者へのインタビュー、イベント企画、コミュニティ運営を手掛けている。ITとビジネスをつなぐ役割を担っているCIO、IT部門長へのインタビュー多数。モットーは、「変化の時代に正しい選択をするのに役立つ情報を発信すること」

関連記事

関連リンク

トライバルメディアハウス
AnityA(アニティア)