アイキャッチ

「ただ作る」だけでは足りない。ビジネス価値の最大化に挑む“攻めのシステム開発”の実態

【PR】 働き方

複雑な要件が絡み合い、さまざまな立場のメンバーが関わるシステム開発の現場では、「設計書通りに進める」「言われた通りに作る」といったように、指示に忠実であることが高く評価されやすい。

しかし、受け身なままでは新たな価値を生むプロダクトは作れない。エンジニアはどんな行動を起こすべきなのだろうかーー

この問いに一つの答えを示すチームがある。日本総合研究所(以下、日本総研)のDXシステム本部だ。SMBCグループ各社のデジタルサービスをアジャイルで内製するDXシステム本部では、これまでもさまざまなサービスを世に送り出してきた。中でも、温室効果ガス排出量をクラウド上で可視化するサービス『Sustana』は、累計2,000社超の導入実績を誇る。

「私たちが大事にしているのは単なるツールの開発ではなく、社会課題の解決とビジネス価値の最大化を両立させる“攻めのサービス開発”です」

そう語るのは、ソリューションリードの佐々木 圭さん。「攻めの開発」とは何か。そして、その経験はエンジニアのキャリアに何をもたらすのか。佐々木さんと、Sustanaの開発に関わった3名のメンバーに話を聞いた。

プロフィール画像

日本総合研究所 DXシステム本部
ソリューションリード 佐々木 圭さん

外資系ベンダーにて、エンジニアやプロジェクトマネジャーとして開発・運用保守業務に従事。外資系生命保険会社に転職し、情報システム部門でベンダーマネジメントなどを担当した後、ソフトウエアエンジニア・マネジャーとしてアジャイル開発に携わる。2020年、日本総合研究所に入社

プロフィール画像

ビジネスアナリスト 新井健太さん

2015年に新卒で入社し、プロジェクトマネジャーとしてクレジットカードの基幹システムにおけるインフラ案件を担当。DXシステム本部に異動後は、『Sustana』開発プロジェクトにビジネス企画フェーズから参画。ビジネスアナリストとして、業務分析、要件定義を実施する一方、ソリューションリードとしてAWSをベースとしたアーキテクチャの検討と、SaaSサービスの導入検討等を担当

プロフィール画像

ソフトウエアエンジニア 久保木 宣喬さん

2020年、新卒で入社しDXシステム本部に配属される。『Sustana』のモックアップ作成に携わり、製品開発フェーズ以降はソフトウエアエンジニアとテストエンジニアを担当。現在は開発チームの代表の1人として、他のロールと連携しながらDevOps推進にも注力

プロフィール画像

OPSエンジニア SETTY DEEPAKさん

母国であるインドのシステム会社でメインフレームエンジニアとしてアプリ開発と運用サポートを経験した後、CLMツールを活用したプロジェクトでプロセス改善を担当。日本のソフトウエア会社でAWSネットワーク関連のプロジェクトリーダーを務めた後、2023年、日本総合研究所に入社。『Sustana』サポートメンバーとしてコストとシステム最適化に対応しながら、プラットフォーム向け新機能の導入やAWS関連のアーキテクチャの検討、運用構築のIAC化対応を担当

ビジネス×技術で挑む、攻めのシステム開発

――DXシステム本部では「攻めのシステム開発」を推進しているとのことですが、この「攻め」とは具体的にどのようなものなのでしょうか?

佐々木:要件通りに実装するだけではなく、ビジネスの価値の最大化に貢献できるプロダクトを作ること。これが私たちの考える「攻めのシステム開発」です。

攻めのシステム開発を実現するためには、エンジニアが未来を見据えた最適解を考え、積極的に提案する姿勢が必要不可欠です。そして、ビジネスサイドと開発サイドが密に連携できるが体制を整えることも重要です。

技術のプロであるエンジニアは、システムのアーキテクチャを深く理解しています。ビジネスサイドと議論を重ねる中で「この部分を変更すれば効率的に実現できる」「こうすれば将来的により大きな価値を生み出せる」といった具体的なアイデアを提示できます。ビジネスと技術の両面から最善策を探っていくことで、攻めのシステム開発は成し得ると考えています。

――理想的な体制ですが、ビジネスサイドと開発サイドの連携が思うように進まない企業も多い印象です。その原因は何だとお考えでしょうか?

佐々木:ウォーターフォール型の開発手法が主流の組織では、攻めの姿勢を持つことは難しいかもしれませんね。

ウォーターフォール型は、要件定義から設計、実装までを順序立てて進めるため、作るべきものが明確な場合には適している一方で、柔軟性に欠ける部分があります。新たな価値の創出を目指すプロジェクトでは、途中で要件や仕様に変更が生じることが多いため、柔軟な対応が可能なアジャイル開発が適しているといえるでしょう。

インタビューに答える日本総合研究所の佐々木さん

――DXシステム本部も、アジャイル開発を導入しているとか。

佐々木:おっしゃる通りです。ビジネス的なインパクトを出すためには、スピードが大切ですからね。

チーム一丸となり挑んだ、モノリスの巨大化防止と利便性向上の両立

――DXシステム本部では、どのような攻めのシステム開発が行われているのでしょうか。事例をもとに教えてください。

佐々木:私がソリューションリードを担当している『Sustana』を例にお話しします。

Sustanaは、企業活動におけるCO2排出量を算定・可視化するクラウドサービスです。国際的なスタンダードの「温室効果ガス(GHG)プロトコル」を基準に、企業活動によるCO2排出量が把握できます。

ただ、CO2排出量の算定だけでは、現代の脱炭素ニーズには十分に応えられません。企業が提供する製品やサービス単位でのCO2排出量を算定し、削減施策へとつなげるための機能が必要でした。

新井:例えば、パソコン1台の購入によるCO2排出量でも大きな違いがあります。

従来は、環境省が公表しているデータベースを使用し、「パソコン1台のCO2排出量は一律〇〇kg」という形で算定するのが一般的でした。ですがこの方法では、製品ごとの製造プロセスの違いや、メーカーのCO2削減努力が反映されません。すると、環境負荷の少ない素材を採用したメーカーとそうでないメーカーの区別がつかず、脱炭素に向けた競争が生まれにくくなってしまいます。

企業努力を反映することで、CO2削減に向けた社会の実現につなげるためには、自社の製品やサービス単位でのCO2排出量を正確に算定できる機能が必要に違いない。そう考えた結果、追加で実装されたのが「製品算定機能」でした。

ただ、この機能の実装にはいくつかの課題がありました。

インタビューに答える日本総合研究所の新井さん

――具体的には、どのような課題があったのでしょうか?

新井:まず課題となったのは「基本機能への影響を最小限に抑えること」でした。

Sustanaの基本機能は企業全体のCO2排出量を算定するもので、製品算定機能とは必要なデータや計算ロジックが異なります。同じCO2排出量の算定なので似たような仕組みで動くと思われるかもしれませんが、実際には全く別物でした。

基本機能では拠点単位のエネルギー消費や廃棄物量などのデータを用いますが、製品算定機能では拠点単位のデータに加え、部品ごとの素材や製造プロセスのデータを扱う必要がありました。これを同じシステムに統合すると、複雑さが増し、開発スピードや将来の拡張に大きな支障をきたすリスクを否定できませんでした。

そのため、プロダクトオーナー、ビジネスアナリスト、ソリューションリードの三者で「新機能をどのように切り分け、実現するか」を議論しました。その結果、基本機能のドメインから製品算定機能を独立させることが最善策だと判断しました。

久保木:製品算定機能を切り分けることで、巨大モノリス化を防ぐという方針が決まっても、課題はゼロではありませんでした。特に大きかった課題は「基本機能とどう連携させるか」という点です。

製品算定機能は、AWS Lambdaを用いたマイクロサービスとして設計し、既存データの共有は許さず、必要なデータだけ連携する形にしました。ですが、これにはデメリットもあります。既にSustanaには、企業全体のCO2排出量を算定するために多くの機能を実装していたため、機能が分離されることや、データを重複してもたせることで、コードの共通化が難しくなり、今後の開発効率に影響する可能性があったのです。

そのため、どの部分を共通化し、どの部分を独立させるべきかを慎重に議論しました。共通のデータベースにアクセスするメソッドをどう実装するか、といった細かい部分も含めて、チーム全員で検討しました。

インタビューに答える日本総合研究所の久保木さん

佐々木:より良いユーザー体験を提供することも、今回のプロジェクトでこだわったポイントです。

ユーザーがSustanaの基本機能を使いつつ、製品算定機能も直感的に使えるようにするためには、インターフェースの設計も考慮する必要があります。私たちは、ユーザーが混乱せずに新機能を利用できるよう、UXから検討を始めて画面デザインを行っています。

――UI/UXを最適化しつつ、将来的な機能追加や運用をスムーズにするために工夫を重ねたと。

佐々木:はい。具体的な技術選定の段階では、いくつかの案をテーブルに載せ、それぞれのメリットとデメリットを議論しました。

最終的には、AWS Lambdaを使うことで、新機能を独立したマイクロサービスとして構築しました。Lambda はサーバーレスなので、運用コストやインフラ管理の負担を大幅に軽減できます。また、自動でスケールアウトが可能なので、想定以上にリクエストが増加した場合にも柔軟に対応できる点も選定理由の一つです。

DEEPAK:運用面では、Lambdaの特性を最大限活用しつつ、既存システムとどのように統合するかが課題でした。コストや管理の手間を削減できる反面、既存のCI/CD環境がそのままでは適用できない部分があり開発効率に影響があったのです。

そこで、インフラ周りや運用を専門とする私たちOpsチームが中心となって、Lambda専用のデプロイプロセスを新たに構築しました。具体的には、Jenkinsを使ってCI/CDパイプラインを整備し、Lambdaのコードや設定の更新を自動化しています。開発チームがボタン一つで新しい機能をデプロイできるようになり、大幅な時間短縮につながりました。

インタビューに答える日本総合研究所のDEEPAKさん

久保木:Lambdaを使った経験はこれまでもあったのですが、ここまで明確にドメインを分離し、マイクロサービス化する取り組みは初めてでした。マイクロサービス化には、開発難易度があがるなどのデメリットもあります。具体的には、どのデータベースにアクセスできるのか、権限をどのように設計するかは、実装していく中で苦労したポイントですね。さらに、障害が発生した場合にどのように検知し、迅速に対応するかという運用面の課題もクリアしなければなりませんでした。

さまざまな課題がある中でも、長期的に価値を提供できるシステムを実現するためには、技術的負債を残さないように開発を進めることが重要です。スピードを維持しつつも、未来を見据えて負債が蓄積されないように進めることが、今回の取り組みの肝だったと思います。

「作る」役割を超えて磨かれる、エンジニアとしてのスキル

――密に連携を取りながら開発を進めている様子がうかがえたのですが、チームビルディングにおいて工夫していることはありますか?

佐々木:DXシステム本部では「オープンフラットカルチャー」を大切にしています。役職や職種に関係なく、全員が対等な立場で議論し、最良のアイデアを出し合える環境です。

チームメンバー全員がアジャイルソフトウエア開発宣言の理念に基づき、プロダクトの価値を最大化するために自律的に動くことを重視しています。

新井:例に挙げた製品算定機能の開発でも、検討の初期段階から全ロールのメンバーが関わるようにしていました。

プロダクトオーナーやビジネスアナリストが要件を整理している段階で、Opsやソフトウエアエンジニアも議論に参加することで、技術的な視点や運用面のリスクも察知できます。これにより、後になって「仕様に合わない」といったトラブルを未然に防げます。

――実装や運用に携わるメンバーからすると、密に連携が取れることで効率も良くなりそうですね。

久保木:そうなんです。例えばソフトウエアエンジニアチームでは毎日朝会をやっているのですが、OpsやUXチームのメンバーも参加しています。

とある朝会で「機能がうまく動かない」という問題が出た際、Opsのメンバーがその場で調査し、数分で解決したことがありました。こうした密な連携のおかげで、開発が効率的に進められています。

DEEPAK:製品算定機能では権限管理がとても重要でしたが、その課題を早期に洗い出せたおかげで、データベース間の通信設計やアクセス権の制限を適切に組み込めました。

全員が同じ目的を共有しているので、相談がしやすいのも良いですね。セキュリティーリスクを抑えるための提案をした際もスムーズにコミュニケーションが取れました。これまでさまざまな企業で働いてきましたが、初めてこのチームに入った時は「まるで海外のチームにいるようだ」と感じました。

日本総合研究所のDXシステム本部の面々

――DXシステム本部が推進している「攻めのシステム開発」の実態がよく分かりました。では、攻めのシステム開発を経験することで、エンジニアはどのような成長や学びが得られるのでしょうか?

DEEPAK:私は、運用するだけでなく開発段階のことも見越した動きができるようになりました。今までは、渡された要件通りに作って終わり……という仕事がほとんどでしたが、DXシステム本部では、コストやリソース、運用監視の最適化まで関わっています。エンジニアとして、学ぶチャンスの多い場所ですね。

新井:プロダクトはビジネスを成功させるためにあるものですが、作る側が「そもそもビジネスの成功って何ですか?」というところからしっかりと参加して意見を言うのはなかなか経験できることではないですよね。

私自身、今回のプロジェクトではプロダクトマネジメントのスキルをすごく伸ばせました。

佐々木:私は日本総研に入社するまでの10数年間、ウォーターフォール型のプロジェクトに携わってきました。仕様⇒設計⇒詳細設計としていくと、どうしても手続き型の処理設計になってしまうことが多く、新しい技術やアーキテクチャを学んでも、実践する場がなかなかなかったんです。

その後アジャイル開発を経験する機会に恵まれ、日本総研で今回のプロジェクトを進めていく中で、今まで学んできたことがぴたりとはまり、アウトプットができた実感がありました。これまでやってきたことは間違っていなかったと思いましたし、プロダクトの価値を高めるための思考力が磨かれている実感があります。

久保木:自分の役割に限らず、さまざまなロールの視点を持ってプロダクトを生み育て、価値を提供していくという意識が持てていると私も実感しています。背景を知ることで、エンジニアの観点からもビジネスに対して提案する経験を積み重ねられていることが大きいですね。

これからは、コーディングするだけならAIでできる時代がやってきます。自分が主戦場としている領域を多角的な視点から見ることで、身に付けた技術を多方面に応用できるよう、これからもメンバーと切磋琢磨できればと考えています。

>>日本総合研究所の求人情報はこちら

文/宮﨑まきこ 撮影/桑原美樹 取材・編集/秋元 祐香里(編集部)

Xをフォローしよう

この記事をシェア

RELATED関連記事

RANKING人気記事ランキング

JOB BOARD編集部オススメ求人特集





サイトマップ