Updates

新着情報

コラム

ソフトウェアテストのプロセス改善を支える国際標準～Test SPICE～

 はじめに ソフトウェア開発において、テストは品質保証の要です。しかし、テスト活動そのものの成熟度やプロセス品質を体系的に評価・改善する枠組みは、長らく十分に整備されていませんでした。そこで登場したのが Test SPICEです。今回はTest SPICEの概要について解説します。  Test SPICEの位置づけ Test SPICEは、ISO/IEC 330xxシリーズの一部として策定された、ソフトウェアテストに特化したプロセス評価モデルです。従来のSPICE（Software Process Improvement and Capability Determination）モデルをベースに、テスト活動の特性に合わせて設計されています。 国際ソフトウェアテスト資格認定委員会（ISTQB）のシラバスに基づき、長年にわたるソフトウェア/システムのテストに関する世界中の有識者の経験を体系的にまとめ、テストプロセスの共通フレームワークを提供しています。 「検証サービスプロバイダ」 に求められる組織能力を可視化し、プロセス改善による組織能力向上を図ることを目的としていますが、テスト資産の再利用や回帰テストの自動化など、ソフトウェア開発組織のテストプロセスの改善にも有益な内容になっています。  構成と特徴 Test SPICEは、以下のようなプロセス群で構成されています： ビジネスライフサイクルプロセスカテゴリー： テスト計画、設計、実行、評価などテスト運用に使用されるプロセスで構成されています。 技術ライフサイクルプロセスカテゴリー： テスト環境管理、テストデータ管理、テストの自動化など、テストを技術的に有効利用するプロセスで構成されています。 テストリソース合意プロセスカテゴリー： テストを実施するための人的・物理的リソースを調達または供給するプロセスで構成されています。検証サービス、テスト資産、テストツールなどテスト実施のために取引されるあらゆるものが含まれます。 アジャイル拡張プロセスカテゴリー： Test SPICEのコアプロセスではありませんが、テストプロセスをアジャイルに実行するためのプロセスが定義されています。各プロセスは、Automotive SPICEと同様に、目的・成果物・ベースプラクティスが定義されており、能力度レベル（Level 0〜5）に基づいて評価されます。  Automotive SPICEとの違い 範囲の違いとしては、Automotive SPICEがシステム・ソフトウェア開発全体を対象とするのに対し、Test SPICEはテスト活動にフォーカスしています。両者を組み合わせることで、より精緻なプロセス改善が可能になります。 また構造的な違いとして、Test SPICEでは、各プロセス群に「包括プロセス（Overarching Process）」と「詳細プロセス（Detailed Process）」が定義されています。Automotive SPICEでは、プロセス群には単にプロセスが定義されていますが、Test SPICEでは、包括プロセスと詳細プロセスが親子関係をもって定義されています。包括プロセスの各BPに対応するように詳細プロセスが定義されており、より詳細な評価指標を定義しています。 Test SPICEを用いたアセスメントを計画する際には、包括プロセスを対象とするのか、詳細プロセスを対象するのかを明確に決定することが求めれています。両者を混在させることは推奨されていません。迅速かつ大まかな分析を行う場合は、包括プロセスとそれらのBPを使用し、より詳細な分析を行う場合は、詳細プロセスとそれらのBPを使用することが期待されています。 各ライフサイクルプロセスカテゴリーで定義されている包括プロセスと詳細プロセスは下図のようになっています。   例えば、技術ライフサイクルプロセスカテゴリーにあるテスト自動化プロセス群（TAU）の包括プロセスと詳細プロセスの関係について見てみましょう。 包括プロセスとして定義されている「TAU テスト自動化プロセス」には、6つのBPが定義されています。6つのBPは、テスト自動化のための要件定義・設計・実装・テストケース実装・自動化実施・使用状況の監視に関するプラクティスになっています。これら6つのBPに対応する形で詳細プロセスが定義されています。各詳細プロセスには、包括プロセスが定義しているBPをより詳細にしたBPが定義されています。 大まかに何をすればよいのか知りたいときは包括プロセスを参照し、具体的に何をすべき把握したいときは詳細プロセス参照すると良いですね。  Test SPICEを覗いてみよう もう少し理解を深めるために、「TAU テスト自動化プロセス」がどんな内容になっているのか見てみましょう。 先に述べたように、包括プロセスである「TAU テスト自動化プロセス」では、テスト自動化のための要件定義・設計・実装・テストケース実装・自動化実施・使用状況の監視に関する6つのBPが定義されています。これら6つのBPに対応する形で詳細プロセスが定義されています。 これを図示すると以下のような作業の流れになります。  TAU.1：テスト自動化のニーズと要件の抽出プロセス 包括プロセスのBP1に対応した詳細プロセスです。 組織におけるテストに対する思想を記述したテスト方針に基づいて、テスト自動化に対する共有理解を得るために要件仕様書とアーキテクチャ設計書を作成します。 また、どのようにテスト自動化を実現していくのかを記述した、テスト戦略と計画書も作成します。 TAU.2：テスト自動化の設計プロセス 包括プロセスのBP2に対応した詳細プロセスです。 テスト自動化の実現手段を明確にするために、TAU.1の成果物をインプットに、テスト自動化の設計書を作成します。 使用するツールもここでリストアップしておきます。 TAU.3：テスト自動化の実装プロセス 包括プロセスのBP3に対応した詳細プロセスです。 テスト自動化の基盤を構築するために、TAU.2で作成した設計書をインプットに、リストアップしたツールを利用して、自動化ソフトや実行に必要な構成ファイル、サンプルスクリプトなどを作成し、動作を確認します。 TAU.4：テストケースの実装プロセス 包括プロセスのBP4に対応した詳細プロセスです。 実際にテスト自動化を実行するために、TAU.3で準備したソリューションを使用して、テストケースをテストスクリプトに変換し、実行に必要なテストデータやテスト手順も作成します。 TAU.5：テスト自動化の実施プロセス 包括プロセスのBP5に対応した詳細プロセスです。 ここで実際にテスト自動化を実行し、テストログやテストレポート、不具合報告を生成していきます。 TAU.6：テスト自動化プロセスの監視プロセス 包括プロセスのBP6に対応した詳細プロセスです。 実際にプロジェクトでテスト自動化の使用状況を確認し、意図した利用ができているか、組織として当初目指していた、コスト削減や製品品質の均一化に対する妥当性を評価します。 「テストの自動化はコストにも品質にも良いのはわかるけど、何からやったらよいの？」「テストは自動化できたけど、かえって手間が増えてしまった気がする」 こんな悩みや困りごとをお持ちの方は、有益なヒントが詰まっているTest SPICEを参照すると良いと思います。 他にも「テスト仕様書だけじゃなくて、テスト環境も上手く再利用したい」方や「そもそも、どんなテストが自分たちの製品に有効なのか改善したい」方など、少しでもテストに関する悩みがある方は参考していただけると良いと思います。  さいごに いかがだったでしょうか。Test SPICEは、Automotive SPICEと同様に、組織的な品質文化の醸成や教育・研修の教材として活用できますが、テストプロセスに特化した可視化や標準化だけでなく、テスト資産の再利用やテスト自動化など具体的な改善にも活用することができます。 興味のある方は一度Test SPICEのPAMを参照してみてください。  内山哲三 

コラム

「テスト頼み」からの脱却──レビュー文化が品質を変える

※本コラムでは「品質保証」を、SQAによる監査に限定せず、設計段階から品質を作り込むためのレビュー活動や不具合予測・分析など、開発プロセス全体における品質向上の取り組みとして広く捉えています。 なぜ“テスト頼み”では不十分なのか？製品開発における品質保証は、テスト工程に偏りがちです。多くの組織では、テストで検出された不具合をもって品質を評価し、設計工程でのレビュー指摘は記録されない、あるいは品質活動の一部として認識されていないことがあります。しかし、品質は本当に“テストだけ”で保証できるのでしょうか？テストは重要な工程ですが、あくまで後工程であり、設計段階での不具合をすべて検出できるわけではありません。特に組込み系開発では、タイミング依存や環境依存の不具合が多く、テストだけでは限界があります。設計段階での不具合を未然に防ぐには、レビューによる“作り込み”が不可欠です。 レビューで防げる不具合──“作り込み”の力実際の開発現場では、テストでは検出が難しく、設計レビューによって未然に防げる不具合が少なくありません。たとえば、割込み処理において、ある特定の条件下でのみ発生するフラグのクリア漏れによる不具合があります。これは、割込みが連続して発生した際に、ある処理パスでフラグのクリア処理が抜けてしまい、制御が意図しない状態に陥るというものです。こうした不具合は、テスト環境では再現が難しく、実機での長時間運転試験中に偶然発覚することもあります。しかし、設計レビューの段階で割込み処理のフローや状態遷移を丁寧に確認していれば、「特定条件下でフラグのクリア処理が抜けている」という設計ミスを早期に指摘・修正できた可能性が高いのです。他にも、周期処理の遅延、初期化漏れ、状態遷移の不整合、インタフェース仕様の不一致など、テストでは見逃されがちな不具合があります。これらは設計レビューで仕様と実装の整合性を確認することで、早期に対応可能です。このような事例からも、レビューは設計段階から品質を“作り込む”ための、実効性の高い活動であることが分かります。レビュー文化が根づいている組織の取り組みある開発組織では、レビュー工程を品質保証の中心に据え、設計やコードの段階で不具合を早期に検出・記録・分析する文化が根付いています。レビュー指摘はテスト不具合と同様に品質データとして扱われ、工程ごとの不具合予測と実績を比較することで、品質計画の達成度を定量的に評価しています。たとえば、「今回の開発規模からは30件の不具合が作り込まれると予測されるため、テスト前までにその6割、18件以上をレビューで検出する」といった計画が立てられ、レビュー活動が品質保証の仕組みとして機能しています。このような組織では、レビューはチェックリストの確認に留まらず、設計の妥当性を議論し、知識を共有する場として活用されています。レビューが活かされない現場の課題品質保証がテスト中心になっているレビュー工程を品質保証の中心に据える文化が十分に定着していない組織も少なくありません。レビュー活動自体は行われていても、その成果が品質向上に十分に活かされていないケースが多く見られます。 レビュー指摘が品質データとして活用されていない品質保証の仕組みがテスト結果中心に設計されていることが一因です。レビュー指摘は「コメント」や「改善提案」として個別に修正されることはあっても、品質データとして体系的に扱われることが少なく、品質指標に反映されていないケースが多く見られます。 記録方法が分析に適していないレビュー指摘を品質データとして記録・分析すれば、品質リスクの傾向を把握し、戦略的な品質保証活動につなげることができます。しかし、指摘内容が個人のメモやメール、Excelファイルなどに分散していたり、記録項目が統一されていない場合、後から集計・分析することが困難になります。 組込み系開発特有の制約特に車載ソフトウェア開発では、ハードウェアとの密接な連携や制約が多く、設計変更の影響範囲が広くなる傾向があります。このため、レビュー対象が多岐にわたり、限られた時間内で全てを十分に議論するのが難しい場面も少なくありません。 実験文化によるレビュー軽視「動かしてみて確認する」という実験文化が根強く残っていることも関係しています。設計段階でのレビューによる品質の作り込みよりも、実機検証による問題発見に重きが置かれる傾向があり、レビューの位置づけが弱くなりがちです。しかし、レビューには、テストでは検出が難しい不具合を未然に防ぐ力があることは、すでに述べた通りです。だからこそ、レビューを単なる形式的な確認作業に留めず、品質保証の中核として位置づけることが重要です。まとめ：レビューが品質を変える第一歩レビューは品質保証の起点であり、設計段階から品質を高めるための重要な仕組みです。その価値は、実際に仕組みとして活かされて初めて実感できるものです。「レビューって本当に意味があるの？」「チェックリストを増やすだけでは？」そんな疑問を感じたことがある方こそ、一度立ち止まって見直してみてはいかがでしょうか。レビューの質と成果を可視化し、現場に根づかせる工夫次第で、品質保証のあり方は大きく変わります。そして、レビュー指摘を品質データとして活用することで、継続的な改善と品質の安定化にもつながります。レビュー文化を育てることが、持続的な品質向上への第一歩です。もし、レビューの活用に課題を感じているようでしたら、ぜひお気軽にご相談ください。あわせて、レビュー運用の改善に役立つトレーニング情報もご紹介します。「ソフトウェアレビュー技法トレーニング〜ソフトウェアレビュー技法と​効果的な実施・運用のポイント〜」（安部宏典）

コラム

使えるプロセス vs 使われないプロセス：決定的な違いと成功事例

「うまくいくときもあれば、失敗するときもある」プロセス改善は、こうした属人的な開発から脱却し、誰がやっても一定の品質・納期・コストを再現できる仕組みをつくるための重要な取り組みです。しかし近年、開発の複雑化や規格対応の厳格化により、品質問題や納期遅延のリスクはますます高まっています。その一方で、監査や認証取得を目的に整備された“形だけのプロセス”が現場で使われず、改善が止まってしまうケースが増えているのも事実です。良いプロセスも、現場で使われなければ意味がありません。では、なぜプロセスは使われなくなるのか？どうすれば現場で本当に役立つプロセスになるのか？このコラムでは、私たちの現場支援の経験をもとに、成功のヒントをいくつかご紹介します。 ❖プロセスを定義することがゴールになっていませんか？Automotive SPICEやCMMIなどの規格に基づいて開発プロセスを構築することは、多くの組織で採用されている一般的なアプローチです。しかしそこには落とし穴があります。それは、開発上の問題を解決するためのプロセス構築だったはずが、いつしか「プロセスを定義すること」に目的がすり替わってしまうことです。その結果、どのような状態になるのか――以下の現象が多くの組織で共通して見られます。 -プロセス文書は立派だが、現場ではほとんど参照されない-「監査対応のために作っただけ」という空気が漂っている-改善どころか、プロセスが更新されないまま放置されている そこには認証取得が強い動機になっていたり、目に見えるプロセス文書自体の完成度で改善を評価する文化がそうさせているのかもしれません。しかし、こういった結果を引き起こすと、せっかく時間とコストをかけて作ったプロセスが“使われないプロセス”として資産化されてしまい、いわゆる宝の持ち腐れになってしまいます。そして、顧客や経営層が期待した「品質向上」「効率化」「リスク低減」といった投資対効果が得られず、一過性の活動に終わってしまうのです。 ❖使えるプロセスに共通する特徴一方で、現場で「使えるプロセス」を実現している組織には、共通する特徴があります。私たちが支援してきた成功事例を振り返ると、次の4つがキーポイントとなっているようです。  改善の場にプロセスを使う現場も参加している本来、プロセスは開発現場で活用されるために存在します。そのため、現場の担当者はプロセス改善を「自分たちの業務を助けるための取り組み」として、前向きに捉えています。そのため、当事者である現場の担当者もプロセスづくりに積極的に関与しています。 規格用語ではなく、利用者の言葉でプロセスを定義している規格の表現をそのままプロセス文書へ転記することは否定すべきものではないのですが、規格の意図を理解して自分たちの表現でプロセスを定義することで、より明確に作業イメージができ、結果として「使ってみよう」という意識につながっていきます。 プロセスが日々アップデートされているプロセスの定着が成功している現場では、「プロセスが定義されてからが本当のスタート」と認識しています。そのため、現場が使えるプロセスにするためにプロセスの使用状況をよく観察し、“もっと良いプロセス”を常に追求し続けています。 プロセスのサポーターが現場の近くにいて、相談できる環境がある現場にとって今までとは異なるプロセスを適用することは、少なからず抵抗感や煩わしさを伴います。そんな時に、プロセスの意図や具体例を教えてくれるサポーターが近くにいることで安心感を生んでいます。その安心感が現場のプロセス定着を後押ししています。 ❖その状態を作るための３つのポイントでは、どうすれば「使えるプロセス」の実現につながっていくのでしょうか？私たちが現場で支援してきた経験から、次の3つの要素が重要と考えています。  “現場の負担感”を最初に測る多くの組織で失敗する理由の一つは、「改善が現場にとってどれくらい負担になるか」を考えずにプロセスを設計してしまうことです。私たちが見てきた成功事例では、プロセス導入前に「どこで手間が増えるか」「どの作業が嫌がられるか」をヒアリングし、その負担を減らす工夫を優先的に組み込んでいます。  “小さな成功体験”を早く作るプロセス改善は、一気に全社導入しようとすると失敗しやすいです。私たちが支援した企業では、まず一部のチームで試し、短期間で「便利になった」「手戻りが減った」という成功体験を作るようにしています。この小さな成功体験が口コミで広がり、自然と他のチームも「やってみたい」と動き出します。以下に、実際にあった小さな成功体験の事例をご紹介します。 ある自動車部品メーカーでは、全社標準プロセスを導入したものの、現場からは「手間が増えるだけ」、「結局、アセスメント対策でしょ」という声が上がっていました。そこで、まず一部のチームだけに改善を適用することを提案しました。 対象：納期遅延が多かった小規模プロジェクト改善テーマ：“レビューの抜け漏れ防止”に絞る新しいプロセス：既存ツールに簡単なチェックリストを追加する“だけ” 結果、レビュー抜けによる手戻りを想像以上に減らすことができ、チームからは「これなら負担にならない」、「むしろ楽になった」という声が出ました。この成功体験が社内で共有され、他のチームからも「うちでもやりたい」という声が自然に広がっていきました。  “プロセスを変える理由”を語り続ける現場がプロセスを嫌がる要因として、What（何を変えるか）は伝えているものの、Why（なぜ変えるのか）が伝わっていないケースが多いようです。「規格対応だから」「監査で必要だから」では、モチベーションは上がりません。成功している企業は、「このプロセスで残業が減る」「レビュー制度が上がり、品質問題が減る」といった現場にとってのメリットを、繰り返し伝え続けています。 ❖ものづくりの主役は『人』プロセスづくりも、ものづくりも、すべては私たち『人』が為せる業です。その『人』が変わるためには命令や指示だけではなく、３つのポイントで挙げたような人の想いや意識にアプローチする取り組みも必要です。その上で、改善に関わる経営層、EPG（Engineer Process Group）、現場が一体となり、血の通ったプロセスをつくり、運用することが、すべての課題解決の根底にあると考えます。とはいえ、何もかも自分たちで計画を立てて体制を作り上げていくのは至難の業です。私たちは、その改革に加わり、一緒に手を動かし、皆様と一緒になって課題解決をすることを得意としています。まずはお気軽にご相談ください。 お問い合わせはこちら（弊社コンサルタントがご相談を承ります）https://www.bgarage.co.jp/contact/ （長澤克仁）

YouTube

【Webinar動画公開】第５回 Webinar　～ SPICE で読み解くモデリング＆シミュレーションの品質基準 ～

先日開催した、「第5回 SPICE で読み解くモデリング＆シミュレーションの品質基準」の Webinar動画を、弊社公式 YouTube に公開しましたのでお知らせいたします。ぜひ、ご視聴ください。 ▼ご視聴はこちらから：https://youtu.be/AFSfxJX5JHA▼タイムライン  00:00 オープニングModeling & Simulation SPICE 概要と構造02:54 M&S SPICEとは何か 05:31 M&S SPICE開発の背景10:25 M&S SPICEの文書構成と参照モデル 14:14 M&S SPICEの構造 プロセス概要 17:27 信用できる決定プロセス群（DEC）の構成 18:39 モデリングおよびシミュレーションエンジニアリングプロセス群（MSE）の構成19:56 信憑性保証プロセス群（CRD）の構成21:12 【サンプル】DEC.1 エンジニアリングおよび決定タスク分析23:22 【サンプル】MSE.2 シミュレーション設定要求分析 25:03 【サンプル】CRD.1 重要度特定 Automotive SPICEとの関係とModeling & Simulation SPICE を取り巻く動向 27:23 Automotive SPICEとの関係 31:45 M&S SPICEの利用シーンとは？37:56 EOMの利用方針は？ 39:51 開発現場ではどんな活用をすれば良い？43:25 Q&A

B'zine

B'zine - 2025年9月号（プロセスモデリング：プロセス文書化のテクニックなど）を発行しました

９月に入ってからもしばらく猛暑日続きでしたが、お彼岸を過ぎて漸く秋らしい涼しい日が訪れました。もうすぐ秋の紅葉シーズン、待ち遠しいですね。 B'zine ９月号を発行いたしました。動画版(約3分)も公開していますので、弊社公式YouTubeより是非ご視聴ください。https://youtu.be/euwjFqSv_w8     B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信（2025年9月号）  B'zine ９月号をお届けします。９月に入ってからもしばらく猛暑日続きでしたが、お彼岸を過ぎて漸く秋らしい涼しい日が訪れました。もうすぐ秋の紅葉シーズン、待ち遠しいですね。 【今月のトピックス】 イベント：Webinar：SPICE で読み解くモデリング＆シミュレーションの品質基準を9月24日に開催しました コラム：アセスメントを活かす！改善を定着させる4つのポイント コラム：プロセスモデリング ～ プロセス文書化のテクニック コラム：進捗計画の精度向上とタイムリーな計画変更を目指して -- 成長曲線適用アプローチの勧め 【イベント】 Webinar～SPICE で読み解くモデリング＆シミュレーションの品質基準～を9月24日に開催しました当日の動画は弊社YouTubeチャンネルで後日公開予定です。公開次第、弊社ホームページでお知らせいたします。 11月Webinar（予定）：～ 生成AIでFMEA作成してみたら ～生成AI（ChatGPT）を活用することで、FMEAの作成期間とリソースを劇的に削減した事例をご紹介します。 【コラム】 アセスメントを活かす！改善を定着させる4つのポイント皆様の中には、Automotive SPICEなどのモデルに基づいたアセスメントをした、もしくは受審した経験のある方が多くいらっしゃるかと思います。では、そもそも何のためにアセスメントをするのでしょうか？レベル獲得をアピールするためでしょうか？商権獲得の条件になっているからでしょうか？確かにそういった事情もありますが、その事情に固執しすぎるとその一瞬のためだけにプロセスを整備する、いわば一過性の取り組みになってしまう場合があります。そこで今回は、アセスメントの本来の目的とアセスメントの有効な活用事例についてご紹介したいと思いますので、ご一読ください。詳細はこちら→https://www.bgarage.co.jp/news/1364/ プロセスモデリング～ プロセス文書化のテクニック  前回のコラム（プロセスとは何か？）では、開発プロセスについて考察し、プロセスを文書化する際のヒントと注意点についてお伝えしました。今回は、プロセスを文書化する際のモデリングのテクニックについてご説明いたします。詳細はこちら→https://www.bgarage.co.jp/news/1399/ 進捗計画の精度向上とタイムリーな計画変更を目指して -- 成長曲線適用アプローチの勧めプロジェクト計画の作成に苦労されているプロジェクトマネージャは多いのではないでしょうか。・ プロジェクト計画書テンプレートに沿って作成しているが、記載事項が多く、作成に想定外の時間を要している。・ プロジェクト計画に対して変更が発生する度に計画書を修正しなければならないので、面倒な作業が増えるので計画作成自体を無駄作業と感じている。プロジェクト管理の基本である進捗計画作成は非常に重要ですので、いろいろな成果物作成や作業の進捗計画を効率的に作成/変更できる成長曲線アプローチを紹介します。詳細はこちら→https://www.bgarage.co.jp/news/1383/

コラム

進捗計画の精度向上とタイムリーな計画変更を目指して -- 成長曲線適用アプローチの勧め

はじめにプロジェクト管理の基本は、プロジェクト計画の作成および計画に基づいたプロジェクト遂行を管理することですが、プロジェクト計画の作成に苦労されているプロジェクトマネージャは多いのではないでしょうか。 プロジェクト計画書テンプレートに沿って作成しているが、記載事項が多く、作成に想定外の時間を要している。 プロジェクト計画に対して変更が発生する度に計画書を修正しなければならないので、面倒な作業が増えるので計画作成自体を無駄作業と感じている。プロジェクトの利害関係者（特にスポンサーと顧客）は、そのプロジェクトが定められた予算、納期、要求品質で完了できることを期待しています。プロジェクトマネージャはプロジェクトが計画通りに進むように進捗管理すると共に、プロジェクト遂行途中で進捗状況を定期的に利害関係者に報告する必要があります。プロジェクト管理の基本である進捗計画作成は非常に重要ですので、いろいろな成果物作成や作業の進捗計画を効率的に作成/変更できる成長曲線アプローチを紹介します。成長曲線適用アプローチを活用することにより、以下の効果が期待できます。 目標成果物に対する作成計画（作業開始日と完了予定日）を指定するだけで、成果物完成までの進捗計画を自動作成できます。 成果物の作成実績を定期的に入力するだけで進捗推移と進捗計画と実績の乖離の可視化できます。 進捗遅れに対するタイムリーな対策発動可否判断が可能になります。 途中で計画自体を変更する場合は、完了予定日を変更するだけで簡単に計画修正が実施できます。１．成長曲線の適用とは成長曲線とは生物の個体数、新製品の販売数、バグ発見数など、当初は少なく中途で大きくなり、その後終息するような現象を表すＳ字グラフを成長曲線といい、代表例としてゴンぺルツ曲線があります。一般的に、プロジェクト進捗も成長曲線と同様な推移を示すことが多いため、進捗管理に成長曲線を適用することで、計画精度向上と計画作成作業の効率化が期待できます。ゴンぺルツ曲線（関数）の概要を以下に記載します。ゴンぺルツ関数を用いれば、管理対象目標値（K）を指定するだけで、時間軸の変数（x）に対する管理対象の累積値（y）が求められます。次に、期間３ヶ月（10月1日～12月31日）、出来高目標値： K＝1 で作成した進捗計画表作成例（管理周期：週）と、進捗管理表からの進捗グラフ生成例を紹介します。 x ：10月1日（開始日）を -3 に、12月31日（完了日）を10 に対応させ、途中区間を管理周期（週）に、x の値を日数比例で計算して進捗計画表に入力する。 出来高目標値： K＝1 を進捗計画表に入力する。 y ：ゴンぺルツ関数を使用して、x 時点の計画値 y の値が自動計算され、進捗計画表に表示される。 週次で出来高実績値を進捗計画表に入力する。 進捗計画表に入力したデータに基づいて、進捗グラフが自動生成される。 進捗グラフに基づいて、出来高計画と出来高実績の経緯と乖離を定量分析し、実施すべき対策を考える。２． 進捗計画変更に対する対応プロジェクト期間中には、要求仕様の追加/変更、リソース調達、予期せぬ問題発生、事業環境の変化、社会情勢の変化、進捗遅れ等の内部・外部要因により、一般的にプロジェクト計画見直しが必要な場面が複数回発生します。よくある事例として、プロジェクト計画書の進捗計画を更新しないまま、現場での臨機応変な対応を優先し、進捗計画は後で更新すれば良いと考えがちになります。一旦この状況に陥ると、後追いで進捗計画を更新するのが億劫になり、結果的には当初作成したプロジェクト計画書が形骸化し、計画との乖離を管理することができなくなってしまいます。進捗計画の変更が必要となる場合は、具体的には殆どの場合出来高目標値（プロジェクト規模見積もり）と期間の変更ですので、ゴンぺルツ曲線を適用した計画作成では出来高目標値K、開始日/終了日の変更となります。これらのパラメータ変更だけで簡単に進捗計画全体の更新ができるので（出来高実績は変更無）、タイムリーな進捗計画変更が可能です。また、初期から進捗計画更新の履歴を保管することで、履歴データ分析による進捗計画自体の品質改善活動にも役立ちます。出来高計画値の変更（ １→ 1.4 ）、進捗遅れ発生（一週間）により、進捗計画を変更した事例を紹介します。 x ：10月1日（開始日）を -3 に、2月4日（完了日）を 10  に対応させ、途中区間を管理周期（週）に、x の値を日数比例で再計算し、進捗計画表の期間を延長する。 進捗計画表に入力済の出来高目標値を、K＝ 1.4 に変更する。 y ：ゴンぺルツ関数を使用して、x 時点の計画値 y が自動計算され、進捗計画表に表示される。 記入済の週次の出来高実績値はそのままの値で変更しない。 進捗計画表に入力した変更後のデータに基づいて、進捗グラフが自動生成（更新）される。 更新された進捗グラフに基づいて、出来高計画と出来高実績の経緯と乖離を定量分析し、実施すべき対策を考える。 ３． ゴンぺルツ曲線 の適用範囲ゴンぺルツ曲線を適用した計画作成と進捗管理は、以下のようなプロジェクト管理のさまざまな場面に適用できます。 プロジェクト全体の進捗計画作成と進捗管理 開発機能毎/開発担当者毎の開発計画作成と進捗管理 開発機能毎/検証担当者の検証計画作成と進捗管理（品質管理） システム/ソフトウェア全体の検証計画作成と進捗管理（品質管理） 問題発生予測作成と進捗管理（品質管理）まとめ成長曲線アプローチを活用した進捗管理について紹介しました。成長曲線に基づいて進捗計画を作成すると、進捗計画の精度は向上します。進進捗計画と進捗実績をグラフ化（可視化）し、乖離を分析して進捗遅れが発生していればその対策を考えて実施することが、のタイムリーなリカバリー対策となります。また、必要に応じて、進捗計画自体を変更する必要があります。プロジェクトマネージャはプロジェクト全体の進捗管理や品質管理に、開発担当者は開発機能の開発計画作成と進捗管理に、検証担当者は検証計画作成と進捗管理にと、成長曲線アプローチを各担当業務に応じてスモールスタートで適用してみてはいかがでしょうか。本コラムでは成長曲線を適用した進捗計画作成の効率化について紹介しましたが、プロジェクト計画作成、プロジェクト見積もり、定量的進捗管理、進捗分析等にご興味あるかたは、ぜひ弊社実践トレーニングの案内をご参照ください。プロジェクト管理トレーニングのご案内はこちら→https://www.bgarage.co.jp/training/281/（海農公宏） 

トップ新着情報

Contact Us

お問い合わせ

お客様のニーズに応じて、最適なサービスを展開しております。
まずはお気軽にご相談ください。

お問い合わせフォームはこちら