【前編】三井住友DSアセットマネジメント×スパイクスタジオ｜IT部門ではなく現場に託した、9か月の伴走型DX人材育成
スパイクスタジオは、三井住友DSアセットマネジメント株式会社様におけるDX推進の一環として、ミドル・バック業務を担う現場社員を対象とした9か月間の伴走型デジタル人材育成プログラムをご提供しました。
「自分がアプリをつくるイメージがまったく持てなかった」
そう振り返る参加者が、9か月後には役員の前で30分の発表を行い、自ら構築した仕組みを現場で運用しています。
【前編】では、なぜIT部門ではなく現場のメンバーに託したのか、参加者がどのような課題を抱えていたのか、そして9か月がどう設計されたのかをお伺いしました。
ぜひご覧ください。
【クライアントプロフィール】
- 企業名：三井住友DSアセットマネジメント株式会社
- 事業内容：（1）投資運用業に係る業務／（2）投資助言・代理業に係る業務／（3）第二種金融商品取引業に係る業務
インタビュー参加者
- 土屋裕子氏 三井住友DSアセットマネジメント株式会社 常務執行役員 オペレーション&テクノロジー部門長
- 山本直史氏 三井住友DSアセットマネジメント株式会社 オペレーション企画部
- 置鮎遵子氏 三井住友DSアセットマネジメント株式会社 資産管理部投信管理チーム
- 荒居美穂氏 三井住友DSアセットマネジメント株式会社 クライアントレポーティング部第二チーム
- 角田和美氏 三井住友DSアセットマネジメント株式会社 投信ドキュメンテーション部
- 多鹿秀一 スパイクスタジオ 執行役VP/COS/ビジネス開発ユニット ディレクター
【導入サービス】
- サービス名：DX伴走支援／AI人材育成
- 導入の目的：ミドル・バック業務のデジタル化を主導する人材の育成／現場発の業務改善の実現
- 期間：約9か月間
【事例のポイント】
- IT部門ではなく、業務知識を持つ現場のメンバーを担い手に据えることで、学んだスキルが実際の業務変革に接続する。
- 9か月のうち最も時間を要したのは課題設定。改善効果の大きさと、期間内での到達可能性を両立させるテーマ選定が、成果物が残るかどうかを分ける。
- 参加者3名が全員、期間内に成果物を完成させ、現在も各部署で運用中。デジタルスキルに加え、関係者を巻き込むプロジェクト推進の経験も獲得した。
なぜ、IT部門ではなく現場に託したのか
「同じ人数で業務を回せる構造をつくることが、至上命題でした」
土屋氏数年後を見据えて、会社としての競争力をDXで維持したいというのが大きな目的でした。運用会社のミドル・バック業務は、商品が増えるほど比例して複雑になっていきます。一方で、採用や育成だけで人員を増やして、すべてをカバーするというやり方は年々難しくなっています。
同じ人数で業務を回せる構造をつくることが至上命題だと考えていました。本気で取り組む必要がある、と2年ほど前から思っていました。
本気で仕組みを変えるなら、IT部門だけでは足りない
土屋氏DXやAIをIT部門だけが担う形は、よく見られますよね。でも本気で業務の仕組みを変えるなら、業務知識を持っている現場のメンバー自身がDXの知識を身につけて、業務に組み込んでいくことが重要だと考えました。
だからIT部門に任せるのではなく、まずミドル・バック業務の中核を担っているメンバーに取り組んでもらいました。
持ち帰って落とし込む研修では、業務は変わらない
山本氏目的は、各部署にDXリーダーをつくって、主体的に改善を進められるようにすることです。現場業務を知っている人でなければ、良いツールはつくれません。
一般的なDX研修は、デジタルツールの操作方法を学んで、各自が持ち帰って業務に落とし込む、という形式になりがちです。今回は会社としての本気度も示したかったので、9か月かけて取り組みました。
「必ず結果を出せると思っていました」
土屋氏3人は日々の業務に真摯に向き合って、きちんとコミットしているメンバーです。一方で、自分の業務をどう変えるかを自ら設計する経験は、これまで多くなかったと思います。ただ、そのポテンシャルは大いにあると考えてアサインしました。業務をよく理解していて、真面目に取り組んでいるので、必ず結果を出せると思っていました。
デジタルスキルの有無ではなく、業務をよく知っていること。そして真摯であること。それが選定の基準でした。
3人は、それぞれ何を変えようとしたのか
プログラムは、参加者それぞれが自分の業務課題を設定することから始まりました。3人が起点に置いたのは、いずれも運用会社のミドル・バック業務に共通する課題でした。
目論見書｜「会議中は、メモを取ることに集中せざるを得なかった」
角田氏私は「目論見書」を作成する部署に所属しています。目論見書は原則として半年に1回改訂して、最新で適切な情報を載せる必要があります。改訂の間、ファンドごとにイベントが発生した場合、文言の修正も必要になります。
従来は改訂に影響する情報をファンドごとのExcelファイルに保存していましたが、ファイルは深いフォルダ階層に分散していて、イベント対応も別の資料で管理されていました。そのため確認漏れ・記載漏れが起きやすく、情報を探す時間もかかっていました。
会議で得た情報も転記する必要があって、会議中はメモを取ることに集中せざるを得ませんでした。だから、関連情報を一元管理して、更新も効率化できる仕組みをつくりたいと考えました。
マンスリーレポート｜214本のファンドを、毎月ミスなく作成
荒居氏所属しているチームでは、投資信託のマンスリーレポートを毎月作成しています。チーム全体で約214本のファンドを扱っていて、正確かつ漏れなく作成することが求められます。
外部委託先から受領するデータは、ファンドごとに取得方法も必要なデータも違います。メール・添付ファイルの保存、データ加工、データの整合性チェックなどを手作業で行う場面が多くて、負荷が高いだけでなくミスも起こりやすい状態でした。また、共通のデータベースもなくて、データがファンドごとに分散していて一元管理されていないので、過去データの確認や後続システムとの連携も難しい状況でした。
販売会社からの照会｜月20件、1件1時間。急ぎの案件で通常業務が止まる
置鮎氏資産管理部では基準価額の算出モニタリングを担っているほか、販売会社様からの問い合わせを営業経由で受けることがあります。問い合わせごとに対応方法を調べて、内容に合わせて返信文を考えて、関係先へメールを作成するまでを手作業で行っていました。
当時、販売会社様からの問い合わせ対応は主に2名で担っていました。回答は、丁寧かつ正確であることが求められる業務であり、私が担当する際には、回答内容についてもう一人の担当者に何度も確認を依頼することが多く、負担をおかけしていました。問い合わせは月に約20件、1件あたり約1時間かかっていて、急ぎの問い合わせだと通常業務を中断して対応する必要がありました。
「何かしてしまったのか」── 選ばれた3人が、最初に思ったこと
課題は明確でした。ただ、それを自ら解決する側に立つと告げられたときの受け止め方は、決して前向きなものばかりではありませんでした。
置鮎氏部長・チーム長に呼ばれたときは、何かしてしまったのかと思いました。DXの取り組みへの参加と聞いて、最終的には成果物をつくると教わりましたが、自分がアプリをつくるイメージはまったく持てなくて、「アサインされてもできない」と不安でした。
角田氏私はそれまでDXのような分野を避けて通ってきたので、呼ばれたときは衝撃でした。成果物を必ず出すと最初から聞いていたので、本当にできるのか不安でした。ただ、慣れていない人にも親しんでもらうことが狙いなのだと考えると、だから自分が選ばれたのかもしれないとも思いました。「伴走型」と聞いたことも、「伴走」がどの程度を意味しているのか分からず当初は不安を大きくしました。
荒居氏以前からDXには少し興味があって、やってみたい気持ちはありました。一方で、どの業務が自動化・DXに向いているのか、テーマ設定そのものが難しそうで、期待と不安が半々でした。
DXに向いた人材を探して集めたのではなく、業務を最もよく知る人にDXを届ける。土屋氏が語られた選定基準が、ここではっきり形になっています。
9か月をどう設計すれば、成果物が残るのか
「必ず成果物をつくる」という条件のもと、9か月はどのように組み立てられたのか。運営を担った山本氏にお伺いしました。
ツールを学ぶのは、2番目だった
山本氏第1フェーズでは業務課題を設定して、As-Is分析とTo-Be設計を徹底しました。第2フェーズでは、プロジェクトマネジメント研修・DXコンサルティング研修に加えて、Power PlatformやAIの基礎を学びながら、実現するソリューションを検討しました。第3フェーズでは、参加者自身が手を動かして構築して、伴走支援を受けながら成果物を完成させました。
- 第1フェーズ：業務課題の設定、As-Is分析、To-Be設計
- 第2フェーズ：プロジェクトマネジメント研修、DXコンサルティング研修、Power Platform・AIの基礎、ソリューション検討
- 第3フェーズ：参加者自身による構築、伴走支援、成果物の完成
「最も重要で難しかったのは、最初の課題設定です」
山本氏最も重要で難しかったのは、最初の課題設定です。改善効果がどの程度見込めるか、研修期間内に成果へ到達できるかを見極める必要がありました。最終的に成果を出すことが今回の目的だったので、伴走支援側と話し合いながら、ここには時間をかけました。
効果が大きくても期間内に終わらなければ成果物は残らず、期間内に終わっても効果が小さければ組織は動かない。その両方を満たすテーマを見つけるところに、9か月のうち相当の時間が投じられていました。
「順番は、逆でもよかったかもしれない」
山本氏As-Is分析やTo-Be設計は、参加者にとって初めての経験でした。当初は実践してからインプットしたほうが理解しやすいと考えたのですが、プロジェクトマネジメントやコンサルティングの基礎を先に学んでから実践して、後から復習する順番でもよかったかもしれません。この点は参加者からの意見としてもありました。
なぜ、誠実に取り組むほど苦しくなったのか
第3フェーズに入り、3人は自ら手を動かし始めます。そこで直面したのは、ツールの操作以上に難しいことでした。
100点を一気につくることは、できない
多鹿市民開発では、理想のTo-Beを100点満点で一気につくるのは難しいので、できるところから始めてPDCAを回すことが重要です。参加者の皆さんは誠実に、かつ高い理想を持って取り組んでいたので、うまくいかない時期には苦しい思いもあったと思います。
すべて実現しようとして、期限に間に合わなくなった
荒居氏最も難しかったのは、周囲の意見を取りまとめて、範囲を定めて進めることでした。はじめは求められたことをすべて実現しようとしていましたが、それでは期限内に終わりません。まずは当初設定したゴールを達成することを優先して、追加要望は次の課題として扱うようにしました。
「本当に使いやすいか」と指摘され、設計を白紙に戻した
置鮎氏問い合わせに対するメール文案を作成して、下書きに保存するアプリをつくりました。最初はTeams上で完結する形を考えていたのですが、継続的に使うことを考えたときに、本当に見やすく、使いやすいかという指摘を受けました。
最終的にはPower Appsでアプリを構築しましたが、そこへ至るまでの設計を考え直す過程が最も大変でした。
「同じことを何時間繰り返しても、進まなかった」
角田氏何も分からない状態から始めました。他の参加者の話を聞いて、AIを使ってフローやアプリの構築を試しましたが、同じことを何時間も繰り返しても進まないことがありました。
9か月のうち、この時期がいちばん重かったはずです。3名はそれぞれ、範囲の切り方に、設計のやり直しに、進まない時間に向き合っていました。
そこから、どうやって最終報告会にたどり着いたのか。【後編】では、3名の転換点と、実際につくられた3つの仕組み、そして組織に起きた変化をお伺いします。