MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて / Modernize the Development Process and Visualize Development Productivity at MUIT

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）三菱ＵＦＪインフォメーションテクノロジー（ＭＵＩＴ）

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

髙橋博実三菱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 $ ¥ €

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発生産性に関して今最も注目されているメトリクス。 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

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

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

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

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

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

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

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

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

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

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

34 DevLakeの利用画面イメージ① ソースコード管理ツールであるGitLabと接続させた例

35 DevLakeの利用画面イメージ② CI/CDツールと接続させた例

36 DevLakeの利用画面イメージ③ ソースコードに対する品質や保守性を測定するツールである SonarQubeと接続した例

37 参考： DevLakeで取得、可視化できるメトリクス一覧 1/2

38 参考： DevLakeで取得、可視化できるメトリクス一覧 2/2 https://devlake.apache.org/docs/Metrics/ より抜粋

以下のような形で構築、情報連携することが可能 39 DevLake構築イメージ GitLabへのソースのPushをトリガーに、各種連動してメトリクスを取得

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

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

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

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

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

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

おわりに 46

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

48 不確実な時代だからこそデータ（メトリクス）をうまく味方につけ開発生産性をあげていくそれが未来に向けた次へのステップ

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

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

MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて /...

MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて / Modernize the Development Process and Visualize Development Productivity at MUIT

More Decks by 三菱UFJインフォメーションテクノロジー株式会社

Other Decks in Technology

Featured

Transcript