「ビジネスに刺さったか」まで見届ける。ＳＯＭＰＯのアーキテクトが語る、技術と事業をつなぐ面白さ
自分たちが選んだ技術や設計は、現場でどのように役立っているのか。実際に使うユーザーの声を聞くことで、設計時には見えていなかった課題に気付くこともあります。そのような反応を次の改善に生かし、事業に役立つ仕組みを考えつづけることも、ITアーキテクトの仕事と言えます。
損害保険、生命保険、介護などの事業をグループで展開するＳＯＭＰＯホールディングス株式会社では、各社のデータを活用するべく、グループを横断した基盤づくりを進めています。その設計を担うITアーキテクトは、技術の選定にとどまらず、事業の目的や現場の使い勝手を確かめながら、導入後の運用にも関わっているとのことです。
グループ各社の要望をどう整理し、どのように製品を選び、現場で使われる仕組みへと落とし込んでいるのか。今回は同社のITアーキテクトに、「ビジネスに刺さるかどうか」を軸とした仕事の進め方と、自ら選んだ技術の結果まで見届ける仕事の面白さについて伺いました。
目次
プロフィール
デジタル・データ戦略部 データプラットフォームアーキテクトチーム 課長代理／ITアーキテクト
現場の生の情報がプロダクトづくりと結び付いている点に惹かれた
―― まず、学生時代から現在までの歩みを教えてください。
森下：大学ではメカトロニクス工学を専攻し、いわゆる制御システムについて学びました。キャリアの初期は、変電設備システムのフィールドエンジニアとして、電力の制御に関わる仕事を5〜6年ほど経験しました。
学生の頃に学んだことを生かせる仕事だったので楽しかったのですが、動く設備に触れるうちに「どのようなロジックで動いているのだろう」と、中身にも興味を持つようになりました。また、ちょうどスマートフォン登場の時期とも重なり、ITの分野に進みたいと考えました。そこで、未経験から挑戦できるSES企業に入り、システム開発の上流から下流まで3〜4年ほど担当しました。その後、SIerを経て、外資系コンサルティングファームへ進みました。
―― フィールドエンジニアと比べて、扱う領域も大きく変わりそうですね。前職では、どのような領域を担当していたのでしょうか？
森下：主に顧客接点に近いCRMの領域で、証券会社の営業支援や保険会社のコールセンター、電力、ガスなど、金融からインフラまで幅広く担当しました。IT知識に加えて各案件にまつわる業務知識も必要だったので、当時は仕事の傍ら、通勤時間なども活用して1日6時間ほど勉強していました。
―― その後、事業会社へ移ろうと考えた理由を教えてください。
森下：自分が携わったプロダクトに関して、「エンドユーザーの反応を直接受け取れる場所で働きたい」と感じたのが率直な理由です。コンサルティングやSIの仕事では、どうしてもクライアントやエンドユーザーのリアクションを把握しづらいと感じていました。
―― 様々な事業会社があるなかで、ＳＯＭＰＯホールディングスを選んだ決め手は何だったのでしょうか？
森下：当時展開されていた「egaku（エガク）」という、介護リアルデータプラットフォームが面白いと感じたことが大きかったです。「egaku」は、例えば排泄のタイミングや尿量、ベッドのセンサーから得られる情報など、介護現場のデータをリアルタイムで集め、日々のケアに生かそうというプロダクトです。ケアスタッフやケアマネジャーが、ご家族と相談しながらケアを考える際に役立つ情報です。
特に惹かれたのは、現場の生の情報がプロダクトづくりと結び付いている点でした。当時私はデータの専門家だったわけではありませんが、AIを活用することでデータの価値がさらに高まるだろうという思いもあり、2023年にデータを扱うアーキテクトとして入社しました。
グループ全体への影響や将来の運用まで見据えて判断する
―― 現在のチームの役割を教えてください。
森下：現在は「データプラットフォームアーキテクト」というチームで、大きく2つの領域で活動しています。一つは、グループ各社に散在するデータを集約し、AIで活用しやすい形に整えたり、データ基盤を構築したりする仕事です。もう一つは、介護に関わる方を支えるウェルビーイング領域のサービスに向けた、AI機能の開発です。
―― 前者のデータ基盤構築のお仕事について、グループ各社から要望を受ける際に意識していることを教えてください。
森下：グループ会社の方々が、それぞれの事業で 「ビジネス価値を生み出す仕事」に集中できる環境を整えることです。そのために、チームで大切にしているのが「正しいことをする」という考え方です。
業務部門の要望は、十分に言語化されていなかったり、部門単位での最適化を前提に考えられていたりすることもあります。それらの要望に順番に応えるだけでは、それぞれの会社にとっては便利だとしても、グループ全体では仕組みが複雑になり、技術的負債につながることもあります。だからこそ、まずは「なぜそうしたいのか」「何に困っているのか」「どのような制約があるのか」を丁寧に聞くようにして、グループ全体への影響や将来の運用まで見据えて判断することが大切だと考えています。
―― 相手の要望を尊重しながら、こちらの考えも率直に伝えるのは難しそうですね。
森下：社内でのコミュニケーションには、本当に難しさを感じます。コンサルティングの仕事での感覚のまま接していると、社内でも「依頼する側」と「依頼を受ける側」のような関係になってしまうことがあるんです。ですが、私たちは同じ事業の目標に向かう仲間なので、何を実現すべきかを一緒に考える必要があります。そのためにも、こちらの考えを率直に伝え、相手の反応を見ながら対話を重ねています。
また、話す相手も、保険の実務を担う方、グループ会社を支援する方、エンジニア、事業や収支を考える方など様々です。立場によって関心を持つポイントも違うので、話している中で「この説明では伝わりにくいな」と感じたら別の切り口から説明するなど、相手に合わせて進め方を変えるようにしています。
―― 要件の整理から実装まで、幅広い工程に関わるのですね。開発はどのような体制で進めているのでしょうか？
森下：私たちＳＯＭＰＯ側でアーキテクチャを設計し、内製実装をしながら、大手コンサルティングファームやSIerのパートナーには、システム構成の提案や開発、テストなどを担っていただくワンチーム体制で進めています。ＳＯＭＰＯとして実現したいことをチームで共有しながら、提案や成果物の内容をレビューし、技術選定でも、その仕組みや採用する理由を、自分たちの言葉でしっかりと説明できるまで理解を深めるようにしています。
―― 実際に検証する際には、どのような点を重視していますか？
森下：「ビジネスに刺さるかどうか」です。処理の仕組みや画面の使いやすさ、ログインの手順まで含めて、ユーザーが本来の仕事に集中できるものになっているかを確認します。中には、「本当にその方法で進める必要があるのか」「そもそも新しいシステムを入れる必要があるのか」と、手段そのものを問い直すこともあります。事業側のKPIや、社内で利用できるソリューションの制約も踏まえながら、現場の課題を解決するために適切な方法を考えるようにしています。
移行が失敗すると、どんなに良いプロジェクトでも失敗になる
―― 入社してから担当されてきたプロジェクトについて教えてください。
森下：入社後は、先ほどお話しした「egaku」を1年ほど担当し、その後は損害保険関係のプロダクトに携わりました。事故受付後の担当者の割り当てや不正の検知などを、データを活用して自動化する取り組みです。それらが一段落し、現在は、全社データ基盤の構築、介護に関するAIシステム構築、BI基盤のクラウド移行という3つのプロジェクトに取り組んでいます。
―― 現在取り組まれている3つのプロジェクトについて、まずは「全社データ基盤の構築」について教えてください。
森下：グループの損害保険事業、生命保険事業、介護事業が持つデータを集約し、AIやBI（Business Intelligence）で活用できるようにする基盤を構築しています。会社ごとに異なるIDで管理されている顧客データの名寄せや、音声・PDFなどの非構造化データをデータベースで扱える形に整える作業などに取り組んでいます。
具体的な活用方法としては、例えばコールセンターに寄せられた意見の音声をテキスト化して取り込み、どのような意見が、いつ多く寄せられているのか、その背景にどのような課題があるのかを分析します。その分析結果を、商品などの改善に生かすことを想定しています。
―― データを整える工程にも、AIを使うのでしょうか？
森下：はい。音声やPDFなどの内容を要約・整理する工程で、積極的にAIを活用しています。もちろん、AIは間違えることもあるため、AIの処理結果のうち、確認が必要なものを人が判断する仕組みを設計しています。
―― 続いて、「介護に関するAIシステム構築」は、どのようなプロジェクトなのでしょうか？
森下：こちらは、先ほどお話ししたウェルビーイング領域のサービスに向けたAI機能の開発です。介護に関わる方のお悩みに対して、その方の状況や介護の段階に合わせ、次に取り組むことを一緒に考えるAIの仕組みを作っています。AIだけで完結させず、人による相談と組み合わせることも考えています。
一人ひとりの状況に合わせて支援することに加え、ケアスタッフへの相談など、現実のサービスとの接点も作りたいと考えています。グループの損害保険や生命保険のサービスを通じて、相談者の課題を解決できる可能性もあります。オンラインで相談に応じ、その先にあるサービスの利用まで支えることを想定したアプリですね。
―― 最後の「BI基盤のクラウド移行」は、現場への影響も大きそうですね。
森下：そうですね。グループで使われているBI基盤を、自社で運用しているサーバーからクラウドサービスへと移す取り組みで、今は移行方針を検討している段階です。
―― データ移行は細心の注意を要する仕事だと感じます。特にグループ全体で使うBI基盤となると、相当大きな規模のプロジェクトだと思いますが、どのようなことを重視されていますか？
森下：どんなに良いシステムを作っても、移行がうまくいかなければプロジェクト全体の失敗につながると考えています。まずは移行対象のデータを1つも欠落させないこと、そして、これまでできていたことが移行後も同じようにできることを重視しています。
当然、業務は移行中も続くので、最初にデータを移した後に追加・更新された分をどのように反映していくかも考えなければなりません。また、クラウドへの移行によって集計が遅くなることのないよう、実際の処理速度を確認することも大切です。ベンダーの説明を受けるだけでなく、自分たちでも確かめる姿勢が大切ですね。
「攻め」と「守り」を、自分たちの判断で設計できる
―― 特に達成感を得られたエピソードを教えてください。
森下：いくつかありますが、特に印象に残っているのは、全社データ基盤のアーキテクチャを自分たちのチームで考え、経営会議で承認を得られたことです。
それまでは特定ベンダーの製品を前提に構成を考えることが多かったのですが、製品には適材適所があります。グループ全体を見たときに、その製品にどのような役割を担わせ、データを集約・管理するためにどのような基盤を別途整えるべきかを整理しました。まだ構築中で課題もありますが、自分たちが考えた構成で進められることに、大きな達成感があります。
―― 適材適所の製品構成を考えるにあたって、主にどのような論点があったのでしょうか？
森下：論点として大きかったのは、データの権限管理をどう徹底するかという点です。グループ全体で使うには、権限管理を1ヵ所に集約し、誰がどのデータを見られるかを統一する必要がありました。そこで、金融グループとして必要なセキュリティを確保できるよう、基盤全体の設計を見直しました。
具体的には、権限管理をデータ基盤に集約する設計にしました。また、ユーザーが複数のIDを使い分けていると、誰がシステムにアクセスしているのかを把握しづらくなるため、IDも統一することにしました。
閲覧できるデータの範囲は、部署だけでなく、その中での役割によっても変わります。例えば、同じ部署でも管理職だけが見られるデータが必要な場合もありますよね。そこで、タグを使い、所属や役割に応じて閲覧範囲を制御できるようにしています。
―― 安全に使うための統制と、日々の使いやすさを両立するわけですね。
森下：セキュリティを高めるために手順を増やしすぎると、使ってもらえなくなったり、運用が形骸化したりすることがあります。そのため、実際の業務で無理なく使える方法まで考える必要があります。
例えば、データを扱うために専用の環境へ入ってもらう方法だけでなく、普段使っている端末から、必要なセキュリティ条件を満たしたままで利用できる方法も考えます。そうした使い方まで含めて、自分たちの判断で設計できることが面白いです。
―― アーキテクトがそこまで踏み込んで提案できるんですね。
森下：私の持論ですが、事業会社のアーキテクトには「ビジネスに刺さる」ための設計が必要です。システムの構造を考えることに加えて、現場で使ってもらうための工夫にも価値があります。データを事業に生かす「攻め」と、安全に扱うための「守り」を両立させるところが、この仕事の楽しさですね。
―― 設計の自由度だけでなく、何を実現すべきかという判断にも関われるということですね。
森下：はい。AIや外部ベンダーからの提案を、どのような基準で評価するかも自分たちで考えられます。なぜその仕組みが必要なのか、事業にどう役立つのかを説明できなければ、「作らない」という判断もできるんです。
例えば、新しいシステムを導入するより、今使っている表計算ソフトを使いこなすための研修を行うほうが、コストも含めて適切かもしれません。これはあくまで例ですが、手段を決める前に、事業や現場にとって本当に必要なことは何かを考えられる点も魅力だと思っています。
「秘伝のタレ」のような状態にしないことが大切
―― 設計や技術選定の理由は、どのように共有していますか？
森下：「ADR（Architecture Decision Record）」の考え方を取り入れ、何かを決めるたびに、その背景や理由を記録する仕組みを整えています。例えば、なぜこの技術を選んだのか、なぜこの設計にしたのか、などですね。
以前関わったプロジェクトでは、どのような経緯でその設計になったのかをたどれないことがありました。担当者が変わったときに、過去にした判断の理由が分からないと、改修や移行の際に調査や確認の手間が増えますし、思わぬトラブルにつながる恐れもあります。判断の背景を残しておけば、後から加わった人も経緯を理解でき、共通の認識を持って議論できます。
特定の人しか中身を知らない「秘伝のタレ」のような状態にしないことが大切です。記録の形式にこだわるよりも、後から「なぜそう決めたのか」をたどれるようにしたいと考えています。
―― 記録が増えても判断の背景をたどれるように、どのような工夫をしていますか？
森下：まず、ユーザーが何に困っていて、どのような状態を望んでいるのかを、ユーザーストーリーとして整理します。その上で、それをどのようなアーキテクチャで実現するのか、さらに、その設計を基にどのようなプロダクトを開発したのかをひも付けていきます。具体的には、ドキュメント管理ツールを使ってユーザーの課題や要望、アーキテクチャ、プロダクトのつながりを確認できるようにしています。そうすることで、「この機能は誰の、どのような課題を解決するために作られたのか」がたどれるようになります。
―― 技術の選択肢も増え続けています。選定に向けた情報収集で大事にしていることも教えてください。
森下：特定の製品やサービスだけでなく、複数の選択肢を比較して考えるようにしています。例えば、Microsoftの製品に加えて、AWSやGoogle Cloud、そのほかのSaaSについても知っておきたいですし、オンプレミスでの構築も選択肢になります。
同じことを実現するにも、方法は何通りもあります。その中から事業に合うものを選ぶためには、自分が知っている技術やサービスの範囲を広げ続ける必要があると考えています。
―― とはいえ、すべての情報を追うのは難しいですよね。候補はどのように絞り込んでいるのでしょうか？
森下：結局のところ、地道に調べていますね。知識が古くならないように勉強を続けながら、各プラットフォーマーとの関わりも大切にしています。
また、機能そのものだけでなく「事業で使いつづけられるか」という観点でも確認します。例えば、問題が起きたときに対応してもらえる体制があるか、SLAやSLOで示されているサービス品質が求める水準に合っているか、データセンターがどのリージョンにあるか、などです。良い製品はたくさんありますが、自分たちの事業に導入できるかは、このような条件も含めて見極める必要があります。様々な情報を集めて比較しながら、実際に導入できるかどうかを判断しています。
自分が選んだ技術や設計が「ビジネスに刺さったかどうか」まで見届ける
―― 業務部門の現場からはどんなフィードバックが届きますか？
森下：好意的な評価をいただくこともありますし、「使いづらい」といった厳しい声が直接届くこともあります。想定していなかった質問を受けて、こちらが重視していたことと、現場の方が気にしていたことの違いに気付くこともありますね。いろいろな進め方や想定問答を用意していても、予想外の反応には驚かされますし、まずは認識にズレがあったことを受け止める必要があります。
―― そうしたズレに気付いたときは、どのように対応するのでしょうか？
森下：一度立ち止まって、相手が今どのようなことを気にしているのかを改めて聞きます。こちらだけが先へ進んでしまっていたなら、相手の視点に立ち戻って、認識を合わせるところからやり直します。またその際は、お互いの役割を明確にすることも心がけています。「ここは私たちに任せてください」「ここは皆さんの力を借りたいです」と。お互いに見直すべきところを認め、歩み寄りながら進めることが大切だと考えています。
―― 森下さんのようなアーキテクトの成果は、どのように評価されるのでしょうか？
森下：チームとしては、プロジェクトを進めるための仕組みや体制を整え、軌道に乗せて、リリースまで導けたかどうかが評価されます。定量的な指標に加えて、当初めざしていた状態を実現できたか、そもそも必要な取り組みだったのか、そして、プロダクトが実際に現場で使われ、社内で重要な役割を果たしているかという点などが見られます。
―― 今後、チームとして力を入れていきたいことを教えてください。
森下：私たちの役割や、チームで大切にしている「正しいことをする」という考え方を、社内でもっと伝えていきたいです。今は、技術的に妥当かどうかを確認するための相談をいただくこともあります。もちろん、その問いには答えますが、私たちとしては、なぜその質問が出てきたのか、事業で何を実現したいのかまでを理解したいんです。技術選定の前提となる課題や目的から一緒に考え、プロジェクトを進めていける関係を、社内に広げていきたいです。
―― ありがとうございます。それでは最後に、Qiita読者へのメッセージをお願いします。
森下：私が大切にしているのは、自分が選んだ技術や設計が「ビジネスに刺さったかどうか」までを見届けることです。そのためには、システムを使う人の仕事や事業の目的を理解し、立場の異なる方々の意見を聞きながら、何を優先すべきかを考える必要があります。
地道に意見をすり合わせる大変さはありますが、その過程で、システムとビジネスの両方を見渡して判断する力が養われます。その泥臭さも含めて、この仕事の魅力だと感じています。現場の声を受け止め、自分たちの判断で設計し、実際に使われた結果まで関わりたい方と、ぜひ一緒に仕事ができたらうれしいです。
編集後記
インタビュー後の写真撮影中、改めて仕事の面白さを尋ねると、「プロジェクトの目標を達成した瞬間ですね。残り99％はしんどいことばかりですけど（笑）」という答えが返ってきました。冗談交じりの言葉でしたが、目標にたどり着くまでの苦労も感じられ、印象に残っています。「ビジネスに刺さったかどうか」まで見届けるには、現場との地道な対話や、移行・運用を支える細かな判断が欠かせません。そうした積み重ねの先に、システムが実際に役立つ手応えがあるのだと感じました。設計から現場での運用改善まで関わる姿勢は、アーキテクトとして次の挑戦を考える方にとっても、ヒントになるのではないでしょうか。
取材／文：長岡 武司
撮影：法本 瞳
提供：ＳＯＭＰＯホールディングス株式会社