NTTデータ 様 開発プロジェクトを見える化、データドリブンな運営のためのデータ分析

ポストコロナのシステム開発ではリモートワークが中心となり、従来のオフィスでの働き方では自然に得られていたチームメンバーの様子・活動状況が見えにくくなりました。その一方で、チャットなどのコミュニケーションツールのログ、レビューデータなどがデジタルデータとして蓄積されるようになったため、これらのデータを使用して開発プロジェクトの定量的評価がしやすい環境が整ったという一面もあります。

NTTデータの技術革新統括本部では、システム開発の現場にデータサイエンスやデータ活用を取り入れ、より良い開発プロジェクトマネジメントを行うための研究に取り組んでいます。データドリブンな開発プロジェクトマネジメントのための分析基盤開発と、実際の開発プロジェクトデータの分析を通じた検討を行っているチームの担当者にインタビューしました。

• 「GitLab」https://about.gitlab.com/ja-jp/

データドリブンな開発プロジェクト運営を目指して

取り組みの背景と目的について教えてください

山本　 一言で言うと、システム開発の現場にデータサイエンスやデータ活用を持ち込みたいというのが目的です。DX が叫ばれて久しいですが、開発現場の中でデータを活用する営みには劇的な変化はなく、特にマネジメントの領域では、報告された情報に基づくマネジメント、熟練 PM の KKD（経験・勘・度胸）によるマネジメントが行われている現場が未だ多いです。ここにもっとデータドリブンな考え方を持ち込むことで、より良いプロジェクトマネジメントを行うことができるようにしたいと考えています。

私は元々、NTTデータ全社のプロジェクト実績データを収集・蓄積・分析する業務、データを検索する社内システムの開発を担当しており、分析結果は見積り・比較評価・第三者検証・施策検討に活用していました。この分析をシステム開発の現場に持ち込みたいと考えたのですが、そのままでは下記のような課題がありました。

• 多くのプロジェクト実績データはプロジェクト完了時に取得されるものなので、プロジェクト期間中の改善や現場での振り返りには使いにくい
• 実績データは工期、規模、プロジェクト属性などの粒度の粗いデータのため、具体的なプロジェクト改善への示唆が得にくい
• 人がデータを投入する仕組みが中心であったため管理コストが高くなり、投入するデータの粒度を細かくする施策がとりにくい

リアルタイムに具体的な改善施策を提案できるようにするために、最近は開発者行動や成果物等の一次情報にフォーカスしています。 「ノイズ」が少ない生のデータを見ていくことが、プロジェクトの真の実態を明らかにすることになると考えています。プロジェクトの成功には、デジタルな三現主義（現場・現物・現実）が大事だと考えています。

平野　 人手でデータ入力すると、データの入力ミス・欠損・データ入力者の趣味嗜好など、いろいろなバイアスが「ノイズ」となります。さらに、昔ながらの進捗管理だと基本的には報告を信じるという形にならざるを得ず、解釈・誇張・隠すなどの「ノイズ」も入る余地が生まれます。SI業界に限らず「物を作る」という生業においては生産工程の履歴が残るはずであり、その履歴を一次情報として直接確認したほうが「ノイズ」が少ないデータとなると考えています。

どのようなデータが分析に使えるのでしょうか？

山本　 「開発によって生じる一次データはすべて分析に使うデータになり得る」がコンセプトです。その中で、課題や目的に即してデータを選択することになります。例えば「GitHub」[2] 等のGitホスティングサービスで開発する場合は Git のコミットログに加えて Issue の議論の情報であったり、「Microsoft Teams」[3]（以下、Teams）を使う場合は、Teams のチャネル上でやり取りしているオープンなコミュニケーションの情報であったりします。

平野　 コミュニケーションツールを例にとっても、Teams、「Mattermost」[4]、メールとチームの運営方針によってメインで使用しているものは異なります。ですので、われわれの分析・可視化基盤をそういった様々なプロジェクトで使用していただくために、汎用化させる方向で取り組んでいます。

• 「GitHub」https://github.co.jp/
• 「Microsoft Teams」https://www.microsoft.com/ja-jp/microsoft-teams/group-chat-software
• 「mattermost」https://mattermost.com/

プロジェクトデータ分析への取り組み

コミュニケーション状態の可視化を行ったそうですね

山本　 Teams 上でのチームのコミュニケーションの状態を可視化するツールを作成しました。リモートワークなどの多拠点業務では、直接顔を合わせられないためチャットツールなどがコミュニケーションの軸になりますが、この中でのコミュニケーションが円滑に行われているのかを確認できるようにしたいと考えました。SI業界ではコロナ禍前からもオフショア業務等で行われていましたが、コロナ禍ではリモートワークという形で他の業界でも一気に広がり、このテーマの重要性がより高まっています。

平野　 今回は、数十人規模のウォーターフォール開発のプロジェクトにご協力いただき、そのマネージャに直接ヒアリングを行いながら取り組みを進めました。このプロジェクトでは、プロジェクト全体の推進チームのもとで、さまざまな業務チームの方も一緒に働いています。本可視化ツールの目的は、マネージャが以下を把握・検討できるようにすることです。

1. 新規メンバがコミュニケーションの輪に入っているか？
2. ある特定のメンバに業務が集中していないか？
3. コロナ禍以後のリモートワーク主体の勤務で各メンバのエンゲージメントの差が大きくなっているように見える。これを可視化することで、よりよいチームマネジメントを実施できるようにしたい。

まずは「1.」についてです。一般的に、ウォーターフォール開発においては、ピラミッド型の体制図に沿ってコミュニケーションが行われます。このため、推進チームのマネージャ層にとって、個別の業務チーム内での新規メンバのコミュニケーションの状況というのは見えにくくなってしまいます。本可視化ツールには、Teams のコミュニケーションを下図のようにグラフ化する機能を盛り込み、プロジェクト全体の様子を見通せるようにしました。

このグラフにおいては、紫がプロジェクト全体の推進チームのメンバでその他の色が各業務チームのメンバを意味します。これにより、コミュニケーションで課題がある場合には早めに検知できるようになりました。

次に「2.」についてです。このチームでは、推進チームのあるリーダ（以下「リーダA」）に業務が集中しているというマネジメント上の課題がありました。リーダAはプロジェクト立ち上げ期から中心人物として活躍している方で、リリースに関わる重要な話題からそれ以外まで一手に引き受けてきました。推進チームにはプロジェクト立ち上げ期からメンバが他に2名います。この2名はリーダAに比べて、業務上の話題にほぼ関与できておらず、リーダAの業務にあまり貢献できていないという課題がありました。以下は、リーダAの投稿推移とメンバ2名の投稿推移の平均を比較したものです。

マネージャは、リーダAの業務を減らすために2021年8月に推進チームに新規メンバ（以下「メンバB」）を投入しています。マネージャはメンバBに対し、「参画直後から立上がり、1～2か月後にはチームの中心人物として活躍して欲しい」という期待を持って投入したのですが、メンバBはその期待通りに活躍しました。

この施策の振り返りにもこの可視化ツールが役に立ちました。以下は「メンバB」の投稿推移を可視化したものです。実際、メンバBは「参画直後からプロジェクトの推進に関わる話題に積極的に関わっている」という点が確認できます。

「3.」についてですが、チーム固有のドメイン知識(例: 難易度の高い業務はこれですよ、と先方にラベリングしてもらう)を用いて、高いエンゲージメントを持って働いているメンバを可視化しました。

分析やツール開発において意識したポイントはありますか？

平野　 分析という観点では、仮説立案ベースで調査を進めることが重要だったと考えています。対象とする課題が「活躍」とか「モチベーション」とかといった漠然としがちなテーマなので、データの概要を眺めてまず仮説を立てたうえで、その仮説を検証できる可視化ツールになっているかどうか先方にヒアリングを重ねながら検証するという点に留意しました。今回の例で言うと、「活躍のパターンの一つは、ある重要なトピックで素早く中心人物になることだ」と仮説立てするところに一つハードルがあり、その仮説を分かりやすく可視化するところにもう一つハードルがある、と考えています。

山本　 注意しないといけないのは、「活躍」の仕方は今回の事例でのような「ある重要なトピックで素早く中心人物になる」以外にもいろいろなパターンがありうるということですね。今回私たちが得た仮説に拘りすぎて他の「活躍」のパターンを見過ごしてしまう恐れがあるからです。さまざまな「活躍」のパターンについては、今後 PoC 先と連携して調査してより理解を深めていきたいと考えています。

平野　 ツール開発という観点では、先方に「わかりやすく」使ってもらえるような形で提供することを意識しました。最終的には分析基盤として提供することを目指していますが、「わかりやすく」というのは、この分析基盤からプロジェクト担当者自身が何らかの知見を得て、そのうえで何らかのアクションを検討できる、ということです。例えば、Teams分析「2.」での「新規メンバ投入」について、（山本さんやわれわれを介さずに）プロジェクトマネージャ自身で振り返りできる、というところを目指しました。

山本　 様々なチームに導入しやすくするために、ユーザ自身で簡単にセットアップ・メンテナンスして動かせることにも留意して開発しています。本分析基盤は当社の開発者にとってはなじみの深いツールである「ELK Stack」[5]と「Python」[6] を使用して構築しており、コンテナ化して提供しています。

• 「ELK stack」https://www.elastic.co/jp/what-is/elk-stack
• 「Python」https://www.python.org/

他の取り組み内容についても教えてください。

開発業務のボトルネック分析・改善戦略提言

山本　 リリースまでのリードタイムを短縮したいという課題に対して、Git等のログから開発業務のボトルネックを分析して、プロセス改善検討から実行までを行いました。具体的には、あるチームのリリーススケジュールに即したブランチ戦略のメンテナンスを行いました。このチームでは、1週間に1回のスパンで機能改修・リリースが行われているのですが、Gitのログから開発フローを可視化することで、想定以上の待ち状態が頻発していることが分かりました。「ブランチ戦略のフローを改善することで待ち時間が短くなる」と仮説を立て、フローの変更を提案しました。

チームや個人の成長の見える化

山本　 上記とは別のチームでは、有識者育成、業務アサインへの活用、日々の業務で困りごとがないか気づきを与えることを目的に、プルリクエストに対するコメントや修正量などの可視化を行いました。このチームではリリース後のその振返り時のメンバの気づきに向けた定量的データとして使用しました。

平野　 今回このチーム内で実施できませんでしたが、「この技術はこの人が得意」とか「この人はこのテーマについてのissueでよくコメントしている」とかといった得意分野があるはずです。その得意分野を可視化し、チーム内での自分の強みがどこにあるか把握できるようにするというのは面白いテーマだと考えています。自分の振り返りという意味でももちろんですが、例えば新規参入者にとっても「チーム参画直後、誰に何を聞けばいいか分からない」いった不安が解消されるという利点があるからです。

今後取り組んでいきたい分析テーマはありますか？

山本　 コミュニケーションに関して、今回の分析ではウォーターフォール開発のプロジェクトのデータを扱いましたが、アジャイル開発のプロジェクトのデータ分析にも取り組んでみたいです。 近年アジャイル開発のプロジェクトが増加していますが、これまで主流だったウォーターフォール開発のプロジェクトと比べて、求められるもの（マインド・プロセス・ツール・ロール等）が異なります。ネットワーク分析の指標として中心性をはじめさまざまな指標がありますが、それらがウォーターフォールとアジャイルでデータの違いとしてどのように表れるのかに興味があります。ウォーターフォール開発のプロジェクトに慣れたチームがアジャイル開発に移行する（組織変革する）際のベンチマークになるかもしれません。

また、上手くいっているプロジェクト、上手くいっていないプロジェクトがそれぞれ複数あれば、共通点の割り出しにも取り組んでみたいです。 複数の開発プロジェクトを横断して分析を行う必要がある点が難しいですね。

平野　 どんなツールを使っているか、どんなプロジェクト運営を行っているか、どんな体制を敷いているか、などが開発プロジェクトごとに大きく異なります。昨年度は、半ば「オーダーメイド」的な形で分析基盤を作ったため、他プロジェクトへの展開という観点では課題の残るものでした。今年度は開発プロジェクト間で汎用的に使えるような分析基盤を作っていきたいですね。また、今年度はプロジェクトの問題予兆検知という課題にも着手中です。

プロジェクトマネジメント分析基盤の展開

今後は実際の開発プロジェクトへ展開していくことになるのでしょうか

平野　 本分析基盤を、今後多くの開発プロジェクトに提供して使ってもらいたいと考えています。今年度も引き続き、NTTデータ社内プロジェクトの多種多様なデータで分析を実施しますが、そこで得られた観点を通じて本分析基盤をブラッシュアップしていきたいです。そしてより汎用的になった分析基盤を、他チームにも提供していけたらと考えています。

山本　 プロジェクトによって開発スタイルは多種多様なので、あるプロジェクトで有用な分析やアプローチは別の組織にとっては有用でない可能性があり、そこが難しいですね。また開発現場にデータ活用を定着させるためには、活用シナリオやプラクティス・事例のさらなる蓄積が重要だと考えています。将来的には、開発プロジェクトデータソースを集約して得られた知見を広く展開することで、マネージャ層といった一部の人だけでなくプロジェクトに関わる全ての人へ恩恵が与えられるような世界が実現できるといいなと思っています。また得られた知見はNTTデータ・NTTデータグループ内に限らず、世の中へ広く発信していきたいですね。

平野　 SI業界以外に拡げられる部分もありそうですね。平たく言えば、「多くの人が集まって何か共同作業をする」場面では大なり小なり応用可能なテーマかと思います。

おわりに

本記事では、開発プロジェクトマネジメントへのデータ分析技術の適用についてご紹介しました。NTTデータでは開発プロジェクトのDX推進、お客様のDX加速を推進しています。
また、NTTデータ数理システムでは、長年培ってきた数理科学の技術を基に、お客様のご要望に合わせたデータ分析や受託開発を承っております。お客様が解きたい課題を弊社技術スタッフが一緒に課題整理を行いながら、ご要望に合わせたご形態で課題解決をサポートします。

本記事のプロジェクトデータ分析に関するお問い合わせでも、それ以外のご相談でも、ぜひお気軽にお問い合わせください。

ご相談はこちら