トップページ > プロセス改善の基本

プロセス改善の基本

改善の目的は何か?

プロセスを改善する活動は、効率・品質・納期といったQCD (Quality, Cost, Delivery)を向上させるために実施されます。

プロセス改善の目的

QCDが向上すれば、顧客のニーズに応え、さらに企業ブランドを維持・向上させ、結果としてビジネスを成功させることができます。重要なポイントは「プロセス改善は単なる手段であり、目的ではない」ということです。

短納期・高品質を実現する手段=プロセス改善

プロセス改善がQCDの向上に有効な手段である理由を、短納期と高品質の観点からご説明します。

短納期

ソフトウェア開発の受注(または開発の開始)からソフトウェアがリリースされるまでの期間が短いもの。

高品質

ISO/IEC 9126-1に記載されている6つのソフトウェア品質特性(機能性、信頼性、使用性、効率性、保守性、移植性)を満たすもの。あるソフトウェアを使う人が、そのソフトウェアに対して持っている期待に応える割合が高いもの。

プロセス改善の目的
*参考:JIS X 0129-1:2003

今ある限られたリソースで無理なく短納期・高品質を実現するためには、今のやり方を効率化・改善する必要があります。そのため、QCDを達成するための手段としてプロセス改善が有効であると考えられているのです。

改善活動の現状

プロセスの改善活動というと、現場の開発者の方はあまり良いイメージを持っていないのではないでしょうか。マネージャーなどの上位層から改善活動がトップダウンにて命じられるものの、現場では改善活動が思うように進まないことがあります。これには理由があります。

ソフトウェア開発の現場の実態* を以下に記載します。

*参考:IPA/SEC発行 2011 年度 「ソフトウェア産業の実態把握に関する調査」 報告書

これらの実態から以下の構図が推測できます。

マネージャーの視点
開発者の視点

この構図の原因はマネージャーと開発者の役割が異なることにあります。それぞれの役割は以下の図のとおりです。

マネージャーと開発者の役割の違い

マネージャーと開発者の役割

開発者の役割には組織の改善が含まれません。プロセスの改善活動には、設計・実装・テストなどの開発者の業務スキルとは異なる専門のスキルが必要であるにも関わらず、開発者がこのスキルを業務から学ぶ機会はほとんどありません。改善活動がうまく進まない背景にはこのような開発現場の現状があります。

プロセス改善を進めるための3つのステップ

改善活動を進める際は、現在の運用を考慮した上で段階的に改善することをおすすめします。段階は3つあります。第1段階では現在のプロセスを理解・分析します。第2段階では分析したプロセスのうち、着手が容易な開発者の負担を減らせるポイントから改善を始め、本格的な改善を行うための開発者の余裕を生み出します。最後の段階では、プロセスのあるべき姿へ向けた本格的な改善活動を行います。

段階的なプロセス改善

第1段階と第2段階において、現状の正しい理解とできる範囲での効率化を実施し、自律的なプロセス改善へ繋げるための仕組み作りに注力することがプロセス改善を成功させるポイントとなります。

現状分析のポイント1: ソフトウェアの家系図

プロセス改善を行うためには、対象となる組織やチームの業務範囲を明確化する必要があります。ソフトウェア開発を改善させる場合は、まず開発しているソフトウェアの関連を明らかにすることから始めます。例えば、以下のような開発組織があったとします。

ソフトウェアの家系図の例1

このソフトウェアを家系図で表すと上記のようになります。この家系図では、国別>機能別>提供別の優先度により記載されているのですが、この図が現在の開発の現場に即したものになっているかどうかを精査する必要があります。もし、組織が機能ごとにチームを組む体制であった場合、上記の図では不十分となり、以下のように機能を最優先にソフトウェアを分岐させる必要があります。

ソフトウェアの家系図の例2

"作業の負荷が高い"など現場で起きやすい問題を分析する際には、開発ソフトウェアの中の「再生機能」を担当しているチームで、かつ「自社開発用」を担当している開発者に不可が集中している、など家系図を使った形でどの開発に問題があるのかを明確にします。

現状分析のポイント2: ソフトウェアの開発プロセス

現状分析のポイント1にてソフトウェアの家系図を描いた後、開発ソフトウェアの開発プロセスを明確化します。

家系図の中のより具体的なソフトウェア開発チームや体制に即したプロセスを書きだします。、例えば「再生機能のみ、日本、自社開発用」の開発を実施しているチームの開発プロセスの図を記載します。。

開発プロセスの例1

プロセスを書きだす際は、「設計」や「実装」など明確な作業名が存在するものや「担当者が変わる(成果物を別のメンバーへ提供する)タイミング」に着目します。上記の例では、設計、実装、単体テストは開発担当者が連続して作業を行いますが、工程が明らかに区切られている(成果物がドキュメント、ソースコードなど異なる)ため、プロセスを分けて記載しています。開発チームによっては、プロトタイプ作成と設計が同じ工程として扱われることもあります。

上記の例とは異なり、1つのソフトウェアを開発するために、細かくチームを作成し開発を進めているケースも多くあります。このようなケースの開発プロセスを例として以下に記載します。この例では、ソフトウェア開発は3チーム体制で進められています。さらに各チームでは開発プロセスが異なり、チーム2ではコードレビューが無く、チーム3は開発を外部へ委託しています。このように、開発プロセスは開発プロジェクトで単一ではなく、開発チームによって異なるプロセスにより開発が進められることが一般的です。プロセス改善を行うためには、現在のプロセスを事実に即した形でまとめることから始めましょう。

開発プロセスの例2

現状分析のポイント3:現状分析の実施

ソフトウェアの家系図と開発プロセスが揃ったら、この2つを合わせます。

家系図とプロセスを合わせる

合わせた図がソフトウェア開発プロセスの現状を表しています。すべての開発ソフトウェアにおいて、家系図+プロセスの図を作成し、開発組織のプロセスを明らかにします。この図を使って、現在の開発メンバーと共に、開発のどこにどのような課題があるのかを議論しましょう。チーム2が担当しているソフトウェア部品の品質が悪いのであれば、チーム1のノウハウを用いたコードレビューを単体テスト工程の後に追加しても良いかもしれません。

このように、家系図とプロセスを組み合わせることにより、すべての開発ソフトウェアの関連と開発プロセスを明確にし、どのソフトウェアのどの工程で問題が起きているかを容易に理解できるようにします。改善する範囲がチーム内で良いのか、組織全体に関わるのかなども特定しやすくなると共に、改善を行った場合の影響範囲まで明確になるというメリットがあります。

より具体的な改善方法については、開発プロセスや手法ごとに分けて記載をしております。ご興味のある方は下のボタンからご参照ください。

このページのトップへ