SAKURUG TECHBLOG

ソフトウェア開発におけるプロセス改善活動の体験談

timestampauthor-name
Masanori

はじめに

以前担当したソフトウェア開発におけるプロセス改善活動について
どのような施策にて対応を行ったかその体験を紹介させていただきます。

担当した業務

立ち位置としてはプロセス改善活動を行う推進チームのメンバーとして参加。
活動を行う上で導入したシステムの導入/運用/改善であったり、データ分析などを
主に担当させていただきました。
他にも改善活動の中で作成した「標準プロセス記述書」の編集にも携わっていました。

プロセス改善活動について

プロセス改善活動を行うにあたり、CMMIアプレイザルの資格をもった方を改善活動の外部顧問として
お招きして、外部顧問による提案をベースに施策を検討し取り組むことになりました。

CMMIとは?

CMMIとはCapability Maturity Model Integration(能力成熟度モデル統合)のことで
組織のプロジェクトマネジメント力を5段階評価で表したものです。

その前身であるCMMではソフトウェア開発請負業者を評価するためのツールと位置づけられており、
ソフトウェア開発契約に基づくプロジェクトを遂行する際に活用することが想定されていました。 
システム工学分野でも適用できるCMMIに発展し、さまざまなプロセスの成熟度の一般的なモデルとして、
広く適用されるようになっていきました。

設定されているレベル

レベル1.初期状態:(混沌とした、いきあたりばったりで、一部の英雄的なメンバー依存の状態)
 成熟したプロセスを導入する際の、出発点のレベル

レベル2.管理された状態:(反復できる状態、プロジェクト管理・プロセスの規則の存在)
 反復してプロセスを実行できるレベル

レベル3.定義された状態:(制度化された状態)
 プロセスが標準ビジネスプロセスとして明示的に定義され関係者の承認を受けているレベル

レベル4.定量的に管理された状態:(制御できる状態)
 プロセス管理が実施され、さまざまなタスク領域を定量的に制御しているレベル

レベル5.最適化している状態:(プロセスを定量的に改善する状態)
 継続的に自らのプロセスを最適化し改善しているレベル

図.CMMIのレベルについて

※Wikipediaより引用
記事:能力成熟度モデル統合

改善活動にて実施した内容

改善目標の設定

開発するソフトウェアの規模と開発期間について改善前の開発効率を算出。
そこから人月あたりの開発規模の設定を設けました。
開発工数の分析を行うにあたり、プロジェクト全体での工程比率についても
理想とする割合のモデルを設定しました。

進捗の定量化およびデータの活用を推進

工数集計システムの立ち上げ

プロジェクトに対する工数データの集計を行うためのシステムを立ち上げました。
工数データをもとに分析データを作成。
プロジェクトに対してフィードバックを行うことでマネジメントに利用いただきました。

不具合管理システムの立ち上げ

開発プロジェクトにて指摘のあがった不具合について管理システムを立ち上げ
指摘から解決までのながれをワークフローを行うと同時に傾向分析にも活用できるようにしました。

プロジェクト管理用ツールとして「MS-Project」の導入

それまでExcelにて個々のセクションで管理していた進捗管理に対してMS-projectを導入。
入力フォーマットをオリジナルに作成し、個々の管理から全体管理とできるように
マクロを使って個別の管理から全体管理を生成できるようにしました。

工数/不具合分析データの活用

改善チームから提示する分析データの内容から、各セクションにおける開発状況の傾向分析と
マネジメントに対してどのように活かすことができるかを外部顧問よりマネージャーへの
説明と議論を定期的に実施し、社内全体での意識改革を行いました。

標準プロセス記述書の作成

それまでの開発では各セクション毎に独自の手法による開発が行われている状態でした。
そこで各セクション毎の手法についてヒアリングを行い、工程毎に分解し、
それぞれの長所をもちより社内共通のプロセス標準記述書を作成し、リリースしました。

改善活動の効果

〇改善目標にしていた開発効率については目標を達成

〇工程比率については活動内では目標未達。。。
 ※後半の工程で不具合発生による作業の後戻りに対する改善に課題が残りました。

図.工数イメージ


〇「標準プロセス記述書」の作成を完遂。社内でのリリースができました。

担当者の苦労(小ネタ)

Excelによる手動集計に苦労

工数分析をExcelによる手動集計を実施していたが当時のExcelシートにおけるレコードの上限が
65536行でした。(当時の集計データとして月平均10万~11万程度であった)
そのため、一月分の工数を集計するの十分ではなかったため、複数シートに分けて集計したものを
マージする必要がありました。
マージを前提にした場合の集計方法については思うようにいかないことが多く、Excelの特殊な使い方を
独自で編み出したりして、個人の作業においても効率化を図りました。
この時に考えた操作/手法についてその後のツール作成だったり、Excelによる作業で活用しています。
(特殊すぎて使える場面が少ないですが。。。)

図.データ集計の工夫


工数集計システムの文化を浸透させるのに苦労

プロセス改善活動を行うにあたり導入した工数集計システムについて、社内でこれまでなかった文化
だったので入力率がなかなか上がらず、毎月のフォローに苦労しました。
これについては個人毎の入力率を計測の上、地道にフォローを続けました。
※基本的に個人に対するメリットを感じないとなかなか浸透しないものです。。。

外部アプレイザルによる活動終了

外部顧問の協力による改善活動については標準プロセス記述書の完成をもって一旦終了し、
社内チームによるデータ集計およびフィードバックの活動を続けることになりました。
ソフト開発の要件変更に伴う開発環境の刷新や開発プロセスの浸透により開発効率などは
その後も向上を見せており、活動が有意義なものであったと実感しました。

記事をシェアする

ABOUT ME

author-image
Masanori
2017年中途入社のお酒とおしゃべりが好きな40代のシステムエンジニア。現在はインフラ系の業務で客先に常駐しています。

© SAKURUG co.,ltd.