MUITにおける開発プロセスモダナイズの 取り組みと開発生産性可視化の 取り組みについて デジタルイノベーション本部 髙橋 博実 2025年7月 

目次 MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の 取り組みについて 1: はじめに～弊社におけるシステム開発保守 に対する課題と対応について～ 02 2:開発プロセスモダナイズの取り組みについて 17 3: メトリクスの選定方法と運用 27 4: おわりに 46 2 

はじめに ～弊社におけるシステム開発保守に 対する課題と対応について～ 3 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 4 MUITってどんな会社？ 4 三菱ＵＦＪ銀行、並びにＭＵＦＧグループ各社の IT・デジタル戦略を先導する、「金融×IT」のプロフェッショナル集団 三菱ＵＦＪフィナンシャル・グループ（MUFG） 三菱ＵＦＪインフォメーションテクノロジー（ＭＵＩＴ） 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 会社紹介 １８１百万円 （三菱ＵＦＪ銀行 ８５．５％、三菱ＵＦＪﾌｨﾅﾝｼｬﾙ･ｸﾞﾙｰﾌﾟ １４．５％） 資本金 従業員 ２,１７６名（2025年4月1日現在） 事業内容 主として三菱ＵＦＪ銀行、並びに三菱ＵＦＪフィナンシャル・グループ 各社の業務等に関する、システムの企画・設計・開発・保守・運用 設立 １９８８年６月 本社 東京都中野区中野4-10-2 中野セントラルパークサウス 5 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 髙橋 博実 三菱UFJインフォメーションテクノロジー（MUIT) デジタルイノベーション本部 シニアテクニカルリード これまでのお仕事 市場リスク計算に 関するアプリ開発 ※銀行合併対応 アプリケーション フレームワーク （骨組み/土台）開発 スマートフォン アプリ開発でのスクラムマスター (Scrum アジャイル開発) 6 R&Dの実施、アジャイル含めた、 より良いアプリ開発等の コンシェルジュ活動 開発プロセスモダナイズ施策推進 外部への活動 Java関連イベント （JJUG CCC）登壇3回 （直近では2024/10に登壇） 日経SYSTEMSへのJava 関連寄稿1回 アジャイル関連イベント（AgileJapan2021および2022、 AgileTechExpo、ふりかえりカンファレンス2022)登壇 MUIT YouTube 技術テーマ解説 JakartaOne Livestream – Japan2022登壇 https://jakartaone.org/2022/japan/ 6 他社との技術交流会の企画、運営 （金融アジャイルMeetup、個社との定例共同勉強会） MUIT テックブログ運営・執筆 https://zenn.dev/p/muit_techblog 自己紹介 6 $ ¥ € 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 金融系のIT会社である弊社における開発プロセス・ツールに関するモダナイズ、改善 の状況について、同様の課題をお持ちの方への情報の一助としていただきます。 実例としては、金融システムを対象としているが、他の業種・ドメインであっても活用で きるように説明させていただきます。 本講演の狙い 7 本日の説明内容について 7 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 8 金融システムに関する特性、特徴 金融サービスは社会インフラのため、高い品質やセキュリティ、安定した保守性は必須 金融サービス、商品については長期ライフサイクルのものが多い • 定期預金の預入期間は1ヵ月から10年まで • 住宅ローンの借入期間は最長35年 • 50年の社債 社員だけでは開発・保守要員不足のため、他社へ開発・保守を委託していることが多い その委託先会社が得意とする商用フレームワークや、開発ツールなどを使うこともあった （社内標準は定めているものの、案件事情を鑑み採択されることもある） • 特定委託先や技術にロックインしないよう、 社内標準としては複数の選択肢を構えておく 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. アーキテクチャやシステム開発プロセス、ツールの見直し機会を作れておらず 保守性や、機能追加・修正の際の開発生産性の低下が課題になってきた。 9 長寿命システムを多く持っている状況での課題 長年のシステムへの機能追加により アーキテクチャ観点、開発プロセス・ツール観点 の両面が古いままになってしまっていた。 また、金融システムという特性上、 セキュリティの恒常対応は必須。 製品の最新へのバージョンアップ、 セキュリティパッチあてした際の無影響確認の 負荷も課題になってきていた。 アーキテクチャ観点の刷新 → 古い技術の刷新、API化、クラウド活用、 コンテナ活用など、セッションの対象外 開発プロセス（CI/CD、テスト自動化）、 ツール環境の刷新 → 本セッションのメイントピック 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 生産性とは、以下のような考え方で数字で表せられるもの 生産性 ＝ 産出（アウトプット） ÷ 投入（インプット） 物的生産性（効率） : チームが所定の期間内で作れるモノの量。純粋なアウトプットの量。 付加価値生産性（効果） ： チームが所定の期間内で生み出せる価値の量。 プロダクトマネジメントの分野ではアウトカムとも呼ぶ。 物的生産性を指すのか、付加価値生産性を指すのかは認識相違が起こることが多い。 ステークホルダーとの会話、掘り下げが必要になるので注意。 システム開発における開発生産性の場合は後者を前者に近づけることが重要。 10 開発生産性の前に、生産性について整理 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. ～再掲～ 物的生産性（効率） : チームが所定の期間内で作れるモノの量 付加価値生産性（効果） ： チームが所定の期間内で生み出せる価値の量 開発するもの＝価値のあるものの場合は問題ないが、、 11 物的生産性と付加価値生産性の差分について 作ったもの ＝ 価値が あるもの 作ったもの ＝ 価値が ある もの 価値 が ない もの ＋ 物的生産性＝付加価値生産性となって いるため、しっかり大量に作っていくフェーズ →上流工程がうまくいっている 物的生産性≠付加価値生産性となって いるため、正しいものを作っていくことが大事 なフェーズ →上流工程がうまくいってないor不確実性 が高いものを作っている 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 12 生産性を上げるということへの基本的な考え方 AIに仕事が奪われる、といった話ではないが開発生産性を上げると、 仕事が無くなって自分の価値が無くなるという不安を覚えるという声が 時々あがるが、そうではない。 開発者目線では、過去にやった類似の仕事は効率的に行うことで楽してこなし、 空いた時間で、新しくチャレンジングな仕事、成長に資する作業を行うという目線、目的 を合わせることが重要。 開発生産性を上げる ＝自分・自チームの仕事が奪われるものではない 過去に やった 仕事 新しい 価値の ある仕事 一 人 （ 一 チ ー ム ） あ た り の 仕 事 量 過去 類似の 仕事 いかに ここを大きくするか というマインドを持つ 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. Java関連のツール開発を行うGradle社によって研究、 発表されているもの。 Developer Productivity Engineeringは開発者のツールチェーンの 効率を高め、フィードバックサイクルを迅速化することを目的としたエンジニアリングアプローチ。 ソフトウェア開発のビルド時間を短縮し、エラーの早期発見を促進するため、以下のような指標 を計測、改善していくことを推奨している。 ビルド時間の短縮、テストの成功率、フィードバックサイクルの時間、MTTR(平均修復時間）、デプロイメントの頻度、開発者 の生産性として完了したタスクやストーリーポイント数、CI/CDパイプラインの効率性、エラー検出率、開発者満足度 最近のソフトウェア開発では、効率性と生産性が競争力を左右する要素として単なるツールの 導入だけではなく、開発プロセス全体を継続的に改善するアプローチであると強調している。 毎年DPEのカンファレンスが開催されており、今年は9月にサンフランシスコで開催される。 そちらへ情報収集と海外エンジニアの意見・動向を探るため参加予定。 海外ではDeveloper Productivity Engineering（DPE）という言葉がある 13 海外での取り扱い 引用：https://gradle.com/developer-productivity-engineering/ 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 定量化 ＝ 数字として表現するというところがポイント ◼ メトリクスの役割 • 状況の可視化：組織やプロジェクトの状態を数字やデータとして可視化することで 直観や感覚に頼るのではなく、客観的な判断が可能となる • 問題の特定：パフォーマンスの低下や問題点を明確にし、 どこに焦点を当てるべきかを特定する助けになる • 目標の設定と追跡：適切なメトリクスを設定することで、プロジェクトの目標や 基準を明確にし進捗を測定しながら軌道修正を行える • 改善の促進：データに基づいた改善アクションを取ることができる →改善の結果についてもメトリクスで確認し、効果実感を得る ことができるというメリットもある メトリクスとは、様々な活動を定量化し、その定量化したデータを管理に 使えるように加工した指標のこと 14 メトリクスとは？ 可視化した先に 何をするかを 見越すことが 大事 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. メトリクスを分かりやすい形で可視化する手段として、ダッシュボードの作成、活用も広がってきている。 また、ダッシュボードをより高度化させたBI(ビジネスインテリジェンス）も過去からあり 直近ではよく使われるものとなっている。 • メトリクス: ビジネスパフォーマンスを評価するための定量的な指標を示す。 • ダッシュボード:ユーザーが一目で重要な情報を把握できるように設計されており、グラフ、チャート、 テーブルなどを用いてデータを視覚化する。ダッシュボードはリアルタイムで更新されることが多く、 経営者やマネージャーが迅速に意思決定を行うためのツールとして利用される。 • BI（ビジネスインテリジェンス）:データの収集、統合、分析、報告を行うためのソフトウェアやアプリ ケーションの総称。BIツールは、データウェアハウスやデータマートからデータを抽出し、複雑なクエリ を実行してデータを分析し、結果をレポートやダッシュボードとして提供される。データの可視化だけ でなく、データのトレンド分析、予測分析、データマイニングなどの高度な分析機能も提供される。 Tableau、Power BI、QlikViewなどがある。 15 メトリクスとダッシュボード 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 最終的に確認したいものは成果であり、それを測定したいと考えるのが自然ではある が、その手前の周辺因子から適切な指標を考えていくことも多い。 • 成果指標：成果そのものを測る 例：売上 • 成果予測因子：成果の起因になるものを測る 例：MAU(月間アクティブユーザー） 成果予測因子を何とするかが難しい。その因子が成果に結びつくのに時間がかかるも のもあるためである。そのため、成果予測因子を先行指標、成果指標は遅行指標と分 類される。 ダイエットにおける 先行指標の例： 接種カロリー、消費カロリー 遅行指標の例： 体重、体脂肪率 16 先行指標と遅行指標 引用：先行指標と遅行指標 https://www.servantworks.co.jp/posts/leading-indicator-vs-lagging-indicator/ 

開発プロセスモダナイズの 取り組みについて 17 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. ”蛇口をひねれば水が出るかのように、常に新しいツールを手に入れ、使いこなせる状態” を目指し、推進中。 開発プロセス・ツール観点の刷新を目的として、2021年より施策開始 18 開発プロセスモダナイズの取り組み 1/2 AS-IS TO-BE ■過去 ・学習コストが高い（情報が遠い） ・個人の裁量範囲が小さい ・組織の裁量範囲が小さい ・ゆえに、圧倒的に経験が少ない （進化するサイクルが生まれない） ■本件後 インフラとして当たり前に水を使えるような 環境にする。 （ITの担い手として、皆が自分自身の 活動のインフラとして使い、各自の持つ プロセスへ組み込んでいける） スピード コスト効率 魅力 Up! Up! Up! 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 19 現在は定着期としての活動中。今後の拡大期に向け準備していく。 開発プロセスモダナイズの取り組み 2/2 事前調査及び整備期 定着期 拡大期 ◼ 開発プロセス、 ツールを見直し フローを整理 ⚫ 開発環境 ⚫ 管理ツール ⚫ レビュー方法 ◼ 対応内容を決め 順次現場利用 できるように整備 ⚫ チケット管理 ツール ⚫ リポジトリ ⚫ テスト自動化 ⚫ CI/CD ⚫ 本番リリースの 高度化 ◼ 開発現場で利用定 着できるような各種 対応を実施 ⚫ 伴走支援 ⚫ 学習コンテンツ 整備 ⚫ 知見、実績の 社内共有 ⚫ マネジメントや BPなど現場社員 以外のメンバー への説明・交流 （マネジメント向け ハンズオン会も実施） ◼ 活用状況をダッシュ ボードで可視化、 改善策検討 ◼ （検討のもの含む） 各現場内で横に広げる 動きを促す ⚫ 現場内のエバンジェ リスト指名、評価 ⚫ 現場課題の吸い上げ、 施策メンバーにて 課題対応 ⚫ 全社KPI化、表彰 ◼ 他施策とのコラボレー ション、相乗効果を狙う ⚫ 既存システムの アーキテクチャ モダナイゼーション ⚫ オブザーバビリティ ⚫ アジャイル運営 など ソースの読み書きは VS Codeを使い、 変更内容はGitに Commitしましょうという 基礎的なところから指南 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. ロナルド・ハイフェッツ氏がアダプティブマネジメント論で組織に対する課題は 技術的課題と適応課題に分類されると論じたもの。 技術的課題・・・ある課題に対して、新たな知識やスキルを身につけることにより、特定の「正解」を導き 出すことができる課題 適応課題・・・自分や組織の価値観や考え方、価値観ではそのままの活用が難しい課題 こんな新しいテクニックやツールがあるよ、と紹介・取り込み解決するのが技術的課題だが うまく組織に広めていくのには、現状の実態とこれまでの背景があるため、そこと向き合って開発現場に 寄り添いながら推進するということが重要。なお、この観点は補完的イノベーション論とも類似点がある。 アダプティブマネジメント、適応課題の観点を含めて推進する 20 開発プロセスモダナイズを進めるための考慮点 ツールを使える 状況にする 現場ごとの 課題を解決する 現場メンバーにうまく 活用してもらい 効果実感を得てもらう 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 本取り組みを行っている途中より生成AIという技術が世に出てきたため 施策間コラボレーションをしながら対応中 21 生成AIと開発プロセスモダナイズの取り組みの関係 MUFG・銀行内でChatGPTを 安全に利用できるように素早く 開発、導入。 ⚫ 生成AIを活用していると CIパイプラインの構築、テストコードの生成 など開発プロセスモダナイズを進めやすくなる ⚫ 開発プロセスモダナイズをして、ソースコードやCI パイプラインのジョブ情報、チケット管理システム上 のノウハウのデータをRAGなどで活用し、良質な 示唆や成果物を得ることができる 弊社採用ホームページより抜粋 https://www.it.mufg.jp/recruiting/fresh/topics/ 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 社内ではメトリクスについて理解を深め いくつか取得しながら運用試行中 22 代表的な開発生産性に関連するメトリクス 経営、ユーザー目線 開発者目線 本番運用中 開発中 デプロイ頻度 変更のリードタイム 障害修復時間 （MTTR) 変更失敗率 ビルド成功率 テストカバレッジ コードレビューの 完了時間 稼働率 新規機能導入率 平均応答時間 顧客クレーム数 セキュリティ脆弱性検出率 技術的負債の比率 プルリクエスト・マージリクエスト のマージ時間 リソース使用率 テスト実行時間 顧客満足度 フレークテスト率 チーム・部署間の依存度 CIパイプラインの 成功率 開発速度・ベロシティ （ストーリーポイント消化数） 凡例 緑背景字：DORA Metrics（Four Keys) 黄背景字：SPACE フレームワーク 青背景字：その他 実装コード量 離職率 ナレッジシェアリング件数 これでも一部。 多くあるので 取捨選択が 大事。 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 開発生産性に関して今最も注目されているメトリクス。 DevOps Research and Assessment(DORA)という組織が統計的・学術的な手法を用いて ソフトウェア開発やデリバリーの状況を改善することを目指す研究プロジェクトから生ま れた4つの指標(次ページにて解説)。 基本的にはアンケート方式であるが、毎年2000社、23000件以上の回答から統計的に 分析して整理されたもの。2013年から毎年「State of DevOps Report」として報告してお り、前のスライドで顔写真を出したDr.Nicole Forsgren氏がリードした研究結果である。 なお、DORAは2018年にGoogle Cloudに買収されているため、Googleクラウドのサイトに 本レポートが掲載されている。 23 参考：DORA Metrics（Four Keys) https://cloud.google.com/devops/state-of-devops 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. Four Keysとは以下４つの指標を計測し、ソフトウェア開発企業としてパフォーマンスが 高いか低いかを表したもの。 質問項目はこちら： https://dora.dev/quickcheck/ 2024年のState of DevOps Reportの調査結果としては以下の通り。 緑部分の攻めの項目と、青部分の守りの項目をバランスよく向上させていくことが ハイパフォーマーと評価されている。 24 参考：DORA MetricsのFour Keysとは（1/2） 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. Four Keys（４つの指標）の定義は以下の通り • リードタイム：変更のコミットから本番環境へのデプロイしユーザーへのリリースする までの時間 • デプロイ頻度：本番環境へのリリース頻度 • 変更失敗率：意図どおり動かないコードをリリースした割合 • MTTR（Mean time to Repair/Recovery）：障害発生から正常に戻るまでの時間 25 参考：DORA MetricsのFour Keysとは（2/2） リードタイムやデプロイ頻度 については、アジャイル開発、 プロダクト志向のように 早くだしてフィードバックを 得て次につなげるという 考え方が反映されている 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. FourKeysのみに着目されてしまうことも多いがCore Modelとして以下のような前後関係も整理されている FourKeysを含めた全体感について 26 FourKeys ※ 最新バージョンとしてはv2.0.0が出ているが、上記図はv1.2.2時点のものを引用 

メトリクスの選定方法と運用 27 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 個人の目標管理などの際にも用いられる「SMART」を意識して決めるということが有効。 • Specific（具体的）: 目標は具体的で明確であるべきである。誰が、何を、どこで、いつ、なぜ、どのように達成するのかを明確にする。 • Measurable（測定可能）: 目標の達成度を測定できるようにする。進捗を追跡し、達成度を評価するための具体的な基準を設定する。 • Achievable（達成可能）: 目標は現実的で達成可能であるべきである。自分の能力やリソースを考慮し、無理のない範囲で設定する。 • Relevant（関連性がある）: 目標は自分の価値観や長期的な目標に関連しているべきである。なぜその目標が重要なのかを理解し、 動機付けを高める。 • Time-bound（期限がある）: 目標には明確な期限を設定する。期限を設けることで、計画的に行動し、目標達成に向けた努力を促進する。 28 ゴール（目標）の立て方から工夫する 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 目的ベースでメトリクスを選定するのが基本であるが、目的に対しての問いに答える データがない、ということもよく発生する。 普段から、データとして残す、どこかで活用できるかもしれない、、という考えを常に持 ち業務遂行していくことが大切となる。 29 メトリクスの活用についてのベースとなる考え方：データ志向 データ利活用に向かないもの データ利活用に向くもの 共有フォルダに置かれたExcel チケットベースで管理できるRedmineやJira Excelのフリーフォーマットで 書かれた設計書 マークダウンやPlantUML、Mermaid記法などの 構造化された文書で書き、Gitで管理された 設計文書 手元の環境に置かれたログ 稼働統計などを共通的に管理する 環境へ集約 （参考）データ利活用に向くものへの考え方については、生成AI活用にもつながる 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. ◼ 変更のリードタイム改善の例 • バリューストリームマップを書いてボトルネックを発見 • ボトルネックへの対処：CIの高速化、即レビュー文化でレビューリードタイムの短縮、作業単位と リリース単位を小さくする、フィーチャートグルなどで本番反映と提供のタイミングを分離、QA作 業の軽量化、リリースフローの最適化 ◼ デプロイ頻度改善の例 • 変更のリードタイムの改善を打ちつつ、企画領域（プロダクトマネジメント領域）への改善も行う • MVP(最小価値プロダクト）から始める文化や段階的リリースを計画する State of DevOpsレポートでは各指標を改善させるためのプラクティスも紹介 されている 30 参考：Four Keysの指標を改善するプラクティス（1/2） 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. ◼ 平均失敗率改善の例 • 作業単位とリリース単位を小さくする • 高凝集で疎結合なアーキテクチャ、モジュールの設計を行う • 継続的テスト、コードレビュー、変更を適切に行うための能力獲得（ドキュメント、トレーニング） ◼ MTTR:平均修復時間改善の例 • Observabilityの向上：監視によって障害の予兆や障害状態の通知、ログ、メトリクス、 トレーシングで原因を特定 • ロールバックの仕組みの整備：変更起因の障害を安定にして修復可能となる • 障害対応訓練や障害対応テンプレートの整備 State of DevOpsレポートでは各指標を改善させるためのプラクティスも紹介 されている 31 参考：Four Keysの指標を改善するプラクティス（2/2） 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. メトリクス取得は大量に、定期的に、できるだけリアルタイムに実施することが重要であ るため、メトリクス取得のために人手作業が入ることは極力避ける。 人の手による取得が入ってしまうと、負荷が高くなってしまうことは、取得時のミスなど も発生し、値に正確性が欠けてしまうため、それを避ける狙いもある。 そのためには、共通的にログなどのメトリクスを取れる仕組みや、共通的なツールや開 発用のプラットフォームサービスなどを使うことで、楽してメトリクスを取れるようにする ということを意識して進める。 32 メトリクスはシステム的に取得するようにすべし 例：社内の共通基盤として 整備されたツール群 日常的に 利用 メトリクス参照用のダッシュボードとして 事前に連携・準備しておくことで 利用時の認知負荷を 最小化できる Gitリポジトリ アーティファクトリポジトリ チケット管理ツール 自動で データ 連携 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. • Apache Incubatorプロジェクトとして開発されているOSS • 各種開発ツール(GitLab、SonarQube、Jenkins等)と接続し、データを取得/可視化 • 蓄積レイヤはMySQL or PostgreSQLを選択でき、可視化レイヤはGrafanaで提供 • 上記以外のデータソースとも接続＆データソース間のクロスジョインも可能 33 FourKeysなど各種メトリクスを可視化するOSSであるApache DevLake DevLakeのガイドより抜粋 https://devlake.apache.org/docs/Overview/ 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 34 DevLakeの利用画面イメージ① ソースコード管理ツールであるGitLabと接続させた例 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 35 DevLakeの利用画面イメージ② CI/CDツール と接続させた例 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 36 DevLakeの利用画面イメージ③ ソースコードに対する品質や 保守性を測定するツールである SonarQubeと接続した例 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 37 参考： DevLakeで取得、可視化できるメトリクス一覧 1/2 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 38 参考： DevLakeで取得、可視化できるメトリクス一覧 2/2 https://devlake.apache.org/docs/Metrics/ より抜粋 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 以下のような形で構築、情報連携することが可能 39 DevLake構築イメージ GitLabへの ソースのPushを トリガーに、各種 連動してメトリクスを 取得 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 日々の開発時に回すCIパイプラインについてエラーが発生しそのままに なってしまうと、割れ窓理論のように気にならなくなってしまう。安定性が重要。 40 ユースケース①：CIパイプラインの安定性計測 DevLakeを使う場合は Pipeline run success rateで可視化 CIツールであるJenkins のパイプラインジョブ一 覧の画面でも 確認可能 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. SonarQube->DevLakeで可視化したメトリクスから計画を立てる 41 ユースケース②：保守運用時のコード保守性計測とリファクタリング計画 バグやセキュリティ関 連の指標については 開発案件中に対処 メンテナビリティ （技術的負債指標、重複コード率）に ついては、開発案件中は努力目標にし リリース後の対応を計画する メンテナビリティ （技術的負債指標、重複コード率）に ついては、開発案件中は努力目標にし リリース後の対応を計画する 全てに完璧な状態を 求めてしまうと過負荷に なる。コードの保守性が 悪いので本番リリース延期 とはできないことが多いので バランスをとることが重要 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 既存のチームに新人や中途採用者、協力会社メンバーなどが実際の開発に入れるま での時間を測定するケースがある。 Time to First Commit といい、着任日からソースコードリポジトリへのコミット（格納）ま での時間を測り、受け入れ環境が整っていたか、迅速に開発開始できるチームになっ ているかを測ることが可能。 42 ユースケース③：新規参入者のオンボーディング効率の計測 着任 開発環境のセットアップ タスクアサイン 実装＆コード コミット Time to First Commit （TTFC) 引用：https://bardoloi.com/blog/2018/02/02/time-to-first-commit/ 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. SPACEフレームワークの説明の中でも触れたが、定量的な数字についてはハックして 良い数字となるように誤魔化すという心理が働いてしまうことがある。 「グッドハートの法則（Goodhart’s Law）」は、経済学者チャールズ・グッドハートが提唱した概 念で、「特定の統計的指標が政策目標として使われると、その指標はもはや信頼できるもの ではなくなる」という法則。 つまり、ある指標が目標となると、人々はその指標を達成するた めの行動を取り始めるため、指標自体の本来の意味や有用性が失われるということ。 例：学校にて生徒の理解力の向上を改善するために「テストの点数」を目標の指標にした場合、教師や生徒は 試験対策など「テストのためだけの学習」を行うようになり、本来の物事への理解がおろそかになりやすい。 メトリクスはあくまで尺度であり、その目的を理解して内容を確認、日々の行動に還元して 今後の計画に反映させていくという動きが重要。 グッドハートの法則に陥らないように留意する 43 アンチパターンとして留意すべき点 ✓ ✓ ✓ 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. PDCAと似ている話ではあるが、改善フローを回すと以下のとおり 44 メトリクス取得前後のフロー Fact（事実） Opinion（意見） Problem（問題） Solution（解決策） 結果を検証する 改善アプローチ の仮説を立てる 仮説を運用する （改善活動） 仮説を実装する （改善活動） 設計 計測 仮説検討 仮説を試す 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 45 メトリクス取得前後のフロー Fact（事実） Opinion（意見） Problem（問題） Solution（解決策） 結果を検証する 改善アプローチ の仮説を立てる 仮説を運用する （改善活動） 仮説を実装する （改善活動） 設計 計測 仮説検討 仮説を試す ここの「計測」の 場面でメトリクスを 活用する 計測結果を 検証することにより 次の仮説を 検討する 仮説の結果検証するのも メトリクスというデータを 使い、次の問題の計測、 仮説を立てるのにも メトリクスというデータを 使うようにしています。 PDCAと似ている話ではあるが、改善フローを回すと以下のとおり 

おわりに 46 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 今回は以下の内容でお話させていただきました。 • 各会社の事情、課題ベースで打ち手を自分たちで考えていく必要がある。 • データ利活用時代、データをメトリクス（指標）として活用していくことが重要。 • 取得については、自動的にとれる仕組みがあると導入ハードルが低い。 • クラウドサービスであれば、Findy Team+、OSSであればApache DevLakeなどが ある。 • なんでもデータを取って可視化すればよいというものではなく、目的、ゴールを 定めてメトリクス（指標）を活用していくことが重要。 • 一方、データ活用する際に「そんなデータが無い！」とならないように データ蓄積、利活用の習慣は持っておくと良い。それは今後のAI活用にもつながる。 47 まとめ 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 48 不確実な時代だからこそ データ（メトリクス）をうまく味方につけ 開発生産性をあげていく それが未来に向けた次へのステップ 

Copyright(C) 2025 Mitsubishi UFJ Information Technology Ltd. All rights reserved. 本プレゼンテーションにより、視聴者と三菱UFJインフォメーションテクノロジー株式会社の間には何ら委任その 他の契約関係が発生するものではなく、当社が一切法的な義務・責任を負うものではありません。 本資料は信頼できると考えられる各種データに基づいて作成されていますが、当社はその正確性、完全性を保 証するものではありません。ここに示した全ての内容は、当社の現時点での判断を示しているに過ぎません。 また、本資料に関連して生じた一切の損害については、当社は責任を負いません。その他専門的知識に係る 問題については、必ず貴社の弁護士、税理士、公認会計士等の専門家にご相談のうえでご確認ください。 49 免責事項 49 

三菱UFJインフォメーションテクノロジー株式会社 デジタルイノベーション本部 〒164-0001 東京都中野区中野4-10-2 中野セントラルパークサウス https://www.it.mufg.jp/ MUITにおける開発プロセスモダナイズの取り組みと 開発生産性可視化の 取り組みについて