2023年2月21日、AnityA(アニティア)・Darsana(Darsana)主催のオンラインイベント「システム負債が『手遅れ』になる前に 中小企業でも実装できる『データとプロセス最適化』の現実解」が開催された。前半はトライバルメディアハウスの河野氏と薄井氏より、同社が過去に断行したシステム・プロセス改革の背景や経緯、その効果や反省点などについて紹介してもらった。
これらの内容は別途「『システム負債を残さない』アーキテクチャ設計、企業規模が小さいうちに——トライバルメディアハウスが挑んだ「データとプロセスの最適化」で紹介しているので、ぜひご参照いただきたい。
後半はこの内容を受け、同社の菊池氏およびAnityA 代表の中野を加えた4人によるフリーディカッションが行われたほか、本イベントの視聴者から寄せられた質問に登壇者が答えるQ&Aセッションが行われた。
業務現場では誰も自分たちの仕事の目的を理解していない
中野: 先ほどの河野さんのプレゼンテーションは、多くの視聴者の方にとって身近に感じられる内容だったと思います。河野さんがトライバルメディアハウスに入社した当初は、やはり社内の状況や課題を把握するのに苦労されたのではないでしょうか?
河野: たしかに大変でしたね。初めのうちはシステムの状況も業務の流れも全然わかりませんでしたから。ただし、たとえそこで課題が見付かったとしても、いきなりそれを指摘して社員の方々のこれまでの働きを否定するようなことはしたくなかったので、かなり気をつかっていました。従って、入社して最初の1年間はかなりおとなしくしていました。
中野: 一見すると負債にしか見えない業務やシステムも、それが設けられた当時はベストな選択だった可能性もありますからね。ちなみにその後、システムや業務の状況を把握するために、やっぱりいろんな人たちにヒアリングして回ったのでしょうか?
河野: 管理部門やシステム部門の人たちからいろいろ話を聞きながら、少しずつ状況を把握していきました。でも「この業務は何のためやっているの?」と聞いても、明確な答えが返ってくることがほとんどなかったんですよね。まぁ、これに関しては、どこの会社でも大体事情は一緒なんですが。
中野: 自分がやっている仕事の目的や理由について考えなくてはならない職種って、意外と少ないですからね。
河野: ただ幸いなことに弊社の社員はいい人ばかりで、皆「会社を良くしたい」という思いを共有しているので、最終的には快く協力してもらえました。そういう文化がもともと根付いていたことは、改革を進める上でとても有利に働いたと思います。
中野: 企業文化は非常に重要ですね。社員や組織同士が互いに疑心暗鬼になっている会社では、改革を進めようにもなかなか協力を得られないですからね。またそういう組織は得てして、セクショナリズムにも陥りがちです。
河野: 弊社でもセクショナリズムは若干あったかもしれません。例えば業務委託で来ていただいている方のアカウントを人事部門が管理するのか、それとも事業部門で管理するのかといった議論があったりしました。でも幸いなことに私自身が管理部門のトップを務めていたので、そうした部門同士の見解の相違も直接自分の手で調整することができました。
中野: 全社規模の改革を進めるためには、やはりそうやって経営陣が全体最適の観点から組織間の利害調整に積極的に取り組んでいくことが重要ですね。
社内規定にメスを入れることで改革の障壁を取り除く
中野: こうした改革に着手した結果、システム部門の現場ではどのような変化がありましたか?
菊池: それまで運用してきた旧システムは、主に特定の担当者の要求に従って開発されたもので、実際の業務現場のニーズとはかけ離れている面が否めませんでした。でもシステム部門からはなかなか声を上げづらい状況だったのです。それを河野さんが「これはちょっとおかしいのではないか?」とはっきり指摘してメスを入れてくれたおかげで、私たちもかなり動きやすくなりました。
薄井: 単に現状のやり方を否定するのではなく、「ここがおかしいから、このように是正すればこう改善できますよね」と解決策まで提示してくれたので、一気に改革の機運が高まりましたね。
中野: 経営の立場から全体を見渡して大きな方針を立てて、さらにそれをどういうアーキテクチャに落とし込んでいくか——という順番で進めていったということですね。システム系の人は、どうしてもいきなりアーキテクチャに着目しがちですが、やはり最初に大きな方針を立ててきちんと言語化しておくのはとても重要だと思います。これがないと、異なる組織の人たちを束ねて同じ方向に向かせることはできません。
河野: ただ、どの会社でも今回やったような改革が可能だとは思いません。やはりトライバルメディアハウスの文化や社長の性格、会社の規模感といった条件がうまく揃ったからこそ可能になったのだと思います。
加えて、「社内規定を変えられたこと」がとても大きかったと思います。「目的や意味が分からないけど皆が従っている規定」というのはどんな会社にも多かれ少なかれあると思いますが、それが障壁となって改革が頓挫することがままあります。でも今回は、管理部門を統括する立場として、そういう社内規定に直接メスを入れることができたのが成功の秘訣だったと思います。
中野: おかしなルールに合わせてプロセスやシステムを構築すれば、おかしなプロセスやシステムが出来上がるのは当たり前ですからね。特にシステムはそうした歪みの影響を最も受けやすいですから、システムを統括する立場の方が経営の一員としてルールメイキングに直接携われることの意義は非常に大きいと思います。
共通の価値観の共有」が改革の前提条件
菊池: 私たちシステム部門のメンバーから見ても、「河野さんと握っておけば大丈夫」という安心感がありましたし、経営の立場でありながらシステムにもプロセスにも精通しているので、とても話が通じやすくてスムーズに仕事を進めることができました。
薄井: 物事を決める際の「責任と権限の範疇」が明確になった点も大きかったと思います。私はトライバルメディアハウスに入社してから10年経つ古株なのですが、かつては小さな会社だったので意思決定も「皆で何となく合意形成して決める」という感じで行っていました。でも、河野さんが入ってきてからは、物事を決める際に「誰の責任のもとに、誰が何を行うか」を明確に決める習慣が根付いたと思います。
中野: ジョブやロールを明確化するということですね。これもかなり重要な改革だったと思いますが、こうした施策は河野さん以外の経営陣も前向きにとらえていたのでしょうか。
河野: 社長は分かってくれていたと思います。こういう改革の重要性については、こと細かに説明せずとも感覚的に理解してくれていました。それに社長だけでなく、会社全体として「この方向性は正しいはずだ」という認識が共有されていたと思います。
中野: そうやって本質的な価値観を皆で共有できていると、やはり改革は進みやすいですね。一見すると先ほどの「ロールの明確化」という話と矛盾するようにも聞こえますが、価値観が共有できていないままロールや組織を分けても、組織ごとの部分最適化が進んでいくばかりで改革からは遠ざかってしまいます。
薄井: たしかに社員同士の会話の中で「トライバルっぽい」というキーワードはよく出てきますね。きっと皆が考える「トライバルっぽい舞台」の上で各人に役割をしっかり振った上で、皆で揃って踊り出した、ということなんだろうと思います。
中野: うまくいっている会社の多くは、そういう共通の価値観を自然と共有できているんですよね。それがないと組織間のパワーゲームになるか、あるいはコストと経済合理性だけに従って意思決定がなされることになります。それでも能力が高いリーダーが会社全体を引っ張っているうちはうまくいくこともあるでしょうが、そういう会社は得てしてリーダーが去ってしまうと途端に空中分解してしまいます。
データ設計を疎かにすると後々になって泣きを見る
河野: 今日のイベントのメインテーマの1つである「システム負債」については、正直少し課題が残りましたね。初期のシステム設計を疎かにすると、後々のメンテナンスやシステム更改時に泣きを見ることになりますから、私たちも今回の基幹システム刷新ではデータ設計を一からきちんと行いたかったのですが、実際は旧システムの仕様に引きずられてしまって、ある程度妥協せざるを得ませんでした。
中野: スタートアップ企業のシステムは、構築当初のデータ設計が後になってビジネスの足を引っ張ってしまうことが多いですね。
菊池: 今回の基幹システム開発では旧システムのデータを引き継がなくてはならない関係上、やむを得ない面があったと思います。それに先ほど中野さんがおっしゃった通り、今となってはシステム負債としか思えないような旧システムのデータ構造も、構築当時は必然性があったのかもしれませんし。
中野: 先ほどの薄井さんのプレゼンで「本当はウォーターフォール開発で一からきちんとデータ設計を行いたかった」という話がありましたが、その気持ちはとても良く分かります! あともう一点、とても興味深かったのが「API」についてのお話ですね。API周りの実装で苦労されたとのことでしたが、具体的にはどの辺りが大変でしたか?
菊池: 自分たちで実装したAPIは幸いなことに大きな問題は発生しなかったのですが、今回基幹システムのコア部分に採用したSaaSアプリケーションのAPI仕様をきちんと把握しきれなかったばかりに、開発中に何度かつまづく場面がありました。
河野: あと、API連携する外部のクラウドサービスのAPI仕様がある日突然変わってしまったり、予告なしにメンテナンスに入ってしまったことで、こちら側のシステムの動作がおかしくなってしまうこともありました。
中野: これは外部サービスとAPI連携する際にありがちな問題ですね。世の中的には外部サービスとAPIを介して疎結合するアーキテクチャを無条件に是とする風潮がありますが、さきほどおっしゃったようなさまざまなリスクをきちんと運用でカバーできる体制を整えないまま本番運用に突入してしまうと、往々にして痛い目に遭います。やはりアーキテクチャと運用体制は常に両輪で考えることが重要ですね。
リーダーの強力な権限とリーダーシップのもとにスピーディーに遂行
中野: 視聴者の方から幾つか質問をいただいているので紹介したいと思います。まず1つ目は、「素朴な疑問ですが、当時のベストプラクティスが今の負債になってしまうというのは、やはり事業環境の変化が大きな原因なのでしょうか? それとも当時の技術的な限界があったということでしょうか?」という質問です。
薄井: 10年前と現在とを比べると技術の選択肢はかなり増えましたが、やっていること自体は基本的に同じWebサービス開発なので、技術的な限界よりもやはり事業環境の変化の方が影響が大きいですね。
例えば開発当時は会社の規模がまだ小さくてユーザー数も限られていたので、アクセス権限の機能はさほど厳密に設計する必要はありませんでした。しかし企業規模が大きくなってユーザー数が増えた現在の環境で使うとなると、アクセス権限の弱さがやはり負債ととらえられてしまいます。
中野: そのような環境変化は事業が成長している証でもありますから、決して悪いことではないんですよね。問題なのは、そうした変化にシステムを追随させるためのリファクタリング作業を想定していなかったことです。従って、システムの開発当初から環境変化に追随できる運用体制やビジネスモデルをきちんと設計しておくことが重要ですね。
次の質問は「プロセス、アーキテクチャ、データ構造などを一貫性をもって設計しようとすると、そもそもの目的を含めて関係者間の認識合わせに膨大な時間がかかり、合意までに疲弊してしまいます。トライバルメディアハウス様ではどのような体制で上記の協議を進めたのでしょうか。特に最終的な意思決定プロセスがどのようなものだったのか教えてください」というものです。
河野: この点については、弊社はとても恵まれていたと思います。というのも、社長や経営陣からは完全に一任されていましたし、設計もほとんど私一人で行うことができましたから。実際にプロジェクトを進める際も、薄井さんや菊池さんなど現場のエンジニアと直接やりとりできたので、社内の合意形成に苦労した覚えがまったくないんです。
中野: 一般的な企業で何か意思決定を行う際は、得てして社内のいろんな立場の人が自身の存在感をアピールするためだけに余計な口出しをしてきて、そのために膨大な時間と労力が浪費されるのが常です。でも本来は今回のトライバルメディアハウスさんのケースのように、経営が強力な権限とリーダーシップを発揮して、スピード感もって遂行していくべきですよね。
河野: その点弊社は、社長が余計な口出しを一切せずに任せてくれたので本当に助かりました。加えて現場の社員の人たちも、今回入れた新システムは決して万全の出来とは言えなかったものの、それでもポジティブにとらえて一生懸命使いこなそうとしてくれました。そういう前向きな文化が根付いてたからこそ、今回の試みも成功したのだと思っています。
優れたアーキテクチャを描くコツは「会社全体を俯瞰する」こと
中野: 「業務担当者がなかなか業務改革に踏み切れなかったり、業務の仕様をなかなか決めきれなかったこともあったのかなと推察します。そのような際には、河野さんの側である程度仕様を決めて、それを担当者に受け入れてもらえるよう理解を求めたのでしょうか。あるいは業務担当者が自ら決められるよう働きかけたのでしょうか」という質問もいただいています。
河野: そういう場合は、私の方で方針をバシッと決めてそれに従ってもらいました。もともと業務担当者の人たちはこちらの方針に従ってくれることに合意してくれていましたから。まあ、私自身の「押しの強さ」もあったのかもしれませんが……。
薄井: 河野さんが言うこと自体は筋が通っていましたし、相手の意見ももちろん聞いていましたから、現場との衝突のようなものはなかったと認識しています。
河野: ひょっとしたら言わないだけで、我慢してくれていたところもあったのかもしれませんが。ただ、一度だけ妥協してしまったことがあって、それは今でも後悔していますね。現場から「この部分に関しては別システムとして用意してほしい」という要望が上がっていて、それをのむとシステム構成が複雑化してしまうので拒否するつもりだったんですが、なぜかいつの間にか通ってしまっていました。結果的にやはりシステムが無駄に複雑になってしまったので、やっぱり大事な方針決めに関しては折れてはいけないんだとあらためて肝に銘じました。
中野: 最後に「優れたアーキテクチャを描くためには、何を学び実践することが望ましいでしょうか? やはり小さくとも自身でアウトプットを出す機会を愚直に続けていくことが近道なのでしょうか?」という質問が来ています。
河野: これはなかなか答えづらい質問ですね……。
中野: 私もときどきこういうことを聞かれるのですが、やはり答えるのは難しいですね。強いて言えば自身が直接携わっている業務だけでなく、会社全体のことを常に俯瞰した上で打ち手を考える習慣を付けるのがいいのではないでしょうか。
河野: そうですね。そうやって会社全体のプロセスやシステムを俯瞰して、それを絵に描いてみるのはとても有効だと思います。その上で、会社全体を見渡せるポジションに就けるよう、会社側に働きかけてみてはどうでしょうか。大きな会社ではなかなか難しいかもしれませんが。
中野: 逆に規模が小さすぎる企業も、プロセスや体制が多少いい加減でも何とかなってしまうのであまり勉強にならないかもしれません。社員数100〜500人ぐらいの規模が会社全体を俯瞰できるギリギリのサイズだと思うので、個人的にはそういう会社で経営企画やシステム企画などを経験してみるのをお勧めします。ただし、そういう会社は得てして仕事がきつい割に給料はそんなに高くないので、その辺りは覚悟しておいた方がいいでしょう。