内製化企業が語り合った、「サイロ化」「ブラックボックス化」「ナレッジロスト」への対応の現在損保ジャパン、KDDI、トライアルの子会社が語る内製化(3)

内製開発で先行する企業によるパネルディスカッションの内容を3回に分けてリポートする本連載。今回は最終回として、、開発のサイロ化、ブラックボックス化、ナレッジロストについて話し合われた部分をお届けする。

» 2022年11月24日 05時00分 公開
[谷崎朋子@IT]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 パネルディスカッション「DX ルポライターが先行企業に訊く、内製開発のポイントと課題」の様子を紹介してきた本連載も、3回目となる本稿が最終回。今回は、開発のサイロ化、ブラックボックス化、ナレッジロストについて話し合われた部分をお届けする。

 登壇者は前回に引き続き、DX最前線を取材するノンフィクションライターで同ディスカッションのモデレーターである酒井真弓氏、内製化を進めるauコマース&ライフの山田豊氏、SOMPOシステムズの関谷雄太氏、Retail AI Xの辻隆太郎氏の4名だ。

内製化チームのサイロ化に「チームトポロジー」で対応

 酒井氏は、内製化チームを作るためのポイントについて辻氏に質問した。

モデレーターを務めたノンフィクションライターの酒井真弓氏

 辻氏は、以前プロジェクト単位でチームがひも付けされており、技術的にサイロ化してしまう状態にあったと前置きし、サイロ化を回避しながら平準化を図るべく、「チームトポロジー」を取り入れたと述べた。

 チームトポロジーは、より大きな価値を創出し、提供できるよう、チーム連携のサポート体制を組んでプロジェクトを回していく仕組みだ。チームは、価値の創造から顧客への提供までの流れ(バリューストリーム)に沿ってプロジェクトを推進する「ストリームアラインドチーム」、インフラや内部サービスを提供する「プラットフォームチーム」、チームの能力ギャップを埋める特定技術のスペシャリスト集団「イネイブリングチーム」、専門性が求められる部分の開発や保守を担当する「コンプリケイテッド・サブシステムチーム」の、4チーム。ストリームアラインドチームがより高いバリューを出していけるよう、他のチームがサポートする。

Retail AI X開発部 部長の辻隆太郎氏

 辻氏によると、チームトポロジーを採用したきっかけは、プロジェクトがサイロ化され、技術面で差異が生じ始めたことだったという。「チームトポロジーに基づき体制を整えることで、例えばフロントエンドの技術スタックを持っているメンバーのギルドや、バックエンドのサーバーサイドに関する知識を持つギルドの、どのギルドから誰をストリームアラインドチームにアサインしても、滞りなくバリューを出せる状態を目指した」(辻氏)

 各チームは専任でアサインされるのではなく、例えばコンプリケイテッド・サブシステムチームでバックエンドの共通APIを開発しているメンバーがどこかのストリームアラインドチームにアサインされるなど、1人に複数のアサインメントが割り振られるイメージだと辻氏は説明する。

ブラックボックス化はどうしても生まれる、ではどう対応するか

 話題が一段落したところで、登壇者同士の質問タイムが始まった。

 最初に質問したのは、auコマース&ライフの山田氏だ。質問の内容は、担当者が退職や人事異動などで業務から離れたとき、その業務内容やプロセスを周囲が把握しておらず、ブラックボックス化してしまう問題だ。

 SOMPOシステムズの関谷氏はこの課題について、「その担当者しか分からないような、匠(たくみ)の技のようなものについては、正直すくいきれないのが実情」と明かしつつ、そうしたリスクを極力抑えるために引き継ぎのためのフォーマットを用意して、技術や情報を共有し、品質を担保できるようにしていると回答した。

SOMPOシステムズ アーキテクト本部 クラウドアーキテクチャグループ 課長の関谷雄太氏

 Retail AI Xの辻氏も、「自社で全てやるからこそ生じる緩みのようなものがある」と、同じ会社の社員であるがゆえのなれ合いが生まれがちであることを指摘。「これくらいのクオリティーでも使えるからいいよ」といった判断を、つい人間関係の中でしてしまうことがあると述べた。

 だが、そうした属人的な判断がドキュメントに残っていることは少ない。結果、その担当者が退職するなどで現場からいなくなったとき、引き継ぎで入った人は不明箇所を前に混乱することになる。実際、Retail AI Xではそんな状態が何年も続き、特に同社は開発拠点が中国にあったこともあり、ブラックボックスが生まれやすい環境にあったと辻氏は言う。

 そこで同社は、問題を解消するには仕組みを変える必要があると考え、上記のチームトポロジーに基づいて組織構成を改編。また、「Behavior Driven Development」(振る舞い駆動開発:ユーザー視点の振る舞いをテストシナリオに起こし、テストで得られた実行可能な仕様に基づいてコードを書く、プログラム開発手法の1つ)を採用し、テストは必ず自動化すると決定。人間の“さじ加減”で仕様が揺らぐ、そんな曖昧さを極力排除した。さらに、中国側の開発チームがプルリクエストをした際は、日本側の開発チームが必ずレビューする流れも徹底。誰も中身が分からないブラックボックス状態のプログラムを作らない、放置させない仕掛けを施した。

 この他、タスクがどの程度の難易度か、どのような仕組みかを他ギルドに所属する同じ職能のメンバーに説明することも義務付けた。これにより、タスクをアサインされたメンバー以外の人がタスクで何をやろうとしているのかを理解できるだけでなく、「最終的に投げるプルリクにはタスク番号が記載されるので、それを見た他メンバーは、あのとき説明してくれたタスクがこのプルリクの内容なのだなと分かってくれる」と辻氏は説明。開発業務に自然な形でナレッジを共有する工程を組み込み、ブラックボックス化の防止を図っているという。

システム数が増えたときのナレッジロストの解決法とは

 続いて質問を投げかけたのは関谷氏だ。先ほどの山田氏の質問で、属人的な知見がその人の退職などによって失われてしまう問題について、開発ライフサイクルの自動化やシステム化は一つの解決策としつつ、「もしもそのシステムが10桁台、100桁台の規模にふくれ上がった場合、運用・保守の観点からすると、むしろ足かせになってしまいそうだ」と疑問を述べた。「リポジトリも、100や300などの単位になると、チケットでひも付けるにしても規模が大きすぎて、追い切れなくなる。こうした規模の問題が発生したときの良い解決策があれば、ぜひ教えてほしい」(関谷氏)

 この質問に深くうなずいた辻氏もまた、同じ課題に直面していると吐露。以前は1つのリポジトリを少人数で運用するモノリス思考の管理体制だったものが、今はプロジェクトごとに複数のリポジトリを管理するマイクロサービスへとトレンドが移り変わった。しかし、プロジェクトが増えるたびに管理対象のリポジトリは増える。修正やテスト、レビュー、デプロイなど各種作業も、数の分だけ必要となる。その結果、運用は複雑かつ煩雑になり、負担となって担当者にのしかかってきた。

 そうした中で、この「ポリレポ/マルチレポ」(複数レポジトリ)の状態を「モノレポ」(単一レポジトリ)にする動きがある。代表的な事例として、Googleが挙げられる。同社は全てのコードを1つのリポジトリで管理しており、リソース管理の効率化などを実現している。

 もっとも、共通コードの変更で全体に影響が及ぶこと、コードベースが巨大化(Googleは20億行以上)しているために影響範囲が読めないことなどの課題もある。その点も加味しつつ、「Retail AI Xでは、サービスのドメイン単位ではモノレポで対応できるようにして、変更時などの影響が小さく収まるように設計して管理している」と辻氏は話し、「これが正解というのではなく、苦肉の策でこうなっている」と苦笑いする。

auコマース&ライフ DX本部長 執行役員の山田豊氏

 両氏の話を聞きながら、山田氏も「関谷氏のところほど複雑ではないにせよ、似たような課題はある」と発言。「内製化の途中ということもあり、APIで連携している表面的な依存度だけは管理できているが、基本的にはアナログで対処している」とし、詳細を詰めていくのはこれからの作業になるため、両氏の意見を参考に取り組みたいと述べた。

内製化に焦りは禁物、少しずつステップアップしていこう

 最後に、DXや内製化に取り組む企業に向けて、登壇者の3人からメッセージが送られた。

 「DXや内製化は、取り組むにはかなりハードルが高く感じるかもしれない。でも、小さな箇所からアプローチして、順番に進めていくうちに、必ず何らかの成果が出てくるはず。顧客に価値が届く活動だと信じ、とにかく諦めず、段階的に取り組んでもらいたい」(山田氏)

 「DXや内製化には、まさに生みの苦しみというものがある。正直、短期間では答えが出ないと思う。1年なのか、それとも2年なのかは分からないが、ある程度の期間をかけて推進できれば、価値は必ず得られる。まずは最初の一歩を踏み出してほしい。もしかして、壁は思っていたよりも低いかもしれない」(関谷氏)

 「DXを推進するとき、内製化は避けては通れない課題だ。内製化するにあたって大切なのは、フェーズを踏みながら進めることだ。最初から全てを内製化しようとすると、ハードルは高くなりがちだ。だから、最初は大枠の部分だけを内製化して、個別の機能は、例えばマネージドサービスやオープンソースを活用する。こうして、徐々にコンポジッタブルな部分も内製化に着手していけば、いずれは自社に最適化された形で内製化の仕組みを構築できるのではないか」(辻氏)

 内製化に対して先進的に取り組んでいる企業も、日々さまざまな課題にぶつかって悩み、乗り越えようと試行錯誤している。内製化を始めた企業もそうした姿を見て、少し勇気づけられたのではないかと酒井氏は述べ、本パネルディスカッションから何かヒントを得られたのであれば幸いだとして話を締めた。

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。