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つのポイントでは、どうすれば「使えるプロセス」の実現につながっていくのでしょうか?私たちが現場で支援してきた経験から、次の3つの要素が重要と考えています。  “現場の負担感”を最初に測る多くの組織で失敗する理由の一つは、「改善が現場にとってどれくらい負担になるか」を考えずにプロセスを設計してしまうことです。私たちが見てきた成功事例では、プロセス導入前に「どこで手間が増えるか」「どの作業が嫌がられるか」をヒアリングし、その負担を減らす工夫を優先的に組み込んでいます。  “小さな成功体験”を早く作るプロセス改善は、一気に全社導入しようとすると失敗しやすいです。私たちが支援した企業では、まず一部のチームで試し、短期間で「便利になった」「手戻りが減った」という成功体験を作るようにしています。この小さな成功体験が口コミで広がり、自然と他のチームも「やってみたい」と動き出します。以下に、実際にあった小さな成功体験の事例をご紹介します。 ある自動車部品メーカーでは、全社標準プロセスを導入したものの、現場からは「手間が増えるだけ」、「結局、アセスメント対策でしょ」という声が上がっていました。そこで、まず一部のチームだけに改善を適用することを提案しました。 対象:納期遅延が多かった小規模プロジェクト改善テーマ:“レビューの抜け漏れ防止”に絞る新しいプロセス:既存ツールに簡単なチェックリストを追加する“だけ” 結果、レビュー抜けによる手戻りを想像以上に減らすことができ、チームからは「これなら負担にならない」、「むしろ楽になった」という声が出ました。この成功体験が社内で共有され、他のチームからも「うちでもやりたい」という声が自然に広がっていきました。  “プロセスを変える理由”を語り続ける現場がプロセスを嫌がる要因として、What(何を変えるか)は伝えているものの、Why(なぜ変えるのか)が伝わっていないケースが多いようです。「規格対応だから」「監査で必要だから」では、モチベーションは上がりません。成功している企業は、「このプロセスで残業が減る」「レビュー制度が上がり、品質問題が減る」といった現場にとってのメリットを、繰り返し伝え続けています。 ❖ものづくりの主役は『人』プロセスづくりも、ものづくりも、すべては私たち『人』が為せる業です。その『人』が変わるためには命令や指示だけではなく、3つのポイントで挙げたような人の想いや意識にアプローチする取り組みも必要です。その上で、改善に関わる経営層、EPG(Engineer Process Group)、現場が一体となり、血の通ったプロセスをつくり、運用することが、すべての課題解決の根底にあると考えます。とはいえ、何もかも自分たちで計画を立てて体制を作り上げていくのは至難の業です。私たちは、その改革に加わり、一緒に手を動かし、皆様と一緒になって課題解決をすることを得意としています。まずはお気軽にご相談ください。 お問い合わせはこちら(弊社コンサルタントがご相談を承ります)https://www.bgarage.co.jp/contact/ (長澤克仁)

コラム

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

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

コラム

プロセスモデリング ~ プロセス文書化のテクニック

前回のコラム(プロセスとは何か?)では、開発プロセスについて考察し、プロセスを文書化する際のヒントと注意点についてお伝えしました。今回は、プロセスを文書化する際のモデリングのテクニックについてご説明いたします。 プロセス文書は、どのような用途で使われるのか?簡単に言うと、プロセスは2種類の使われ方に分類されます。 「組織標準プロセス」として全プロジェクトがプロセスを使う場合 このケースでは、扱う製品や開発ライフサイクルの異なるプロジェクトが、標準プロセスを自分のプロジェクト用にテーラリングして使用することになります このため、プロセスは各プロジェクトの用途に合わせた柔軟な選択や、つなぎ合わせが可能な形式で表現することがポイントです プロセスはフォーマルな形式で文書化される必要があり、Automotive SPICE 能力レベル3で求められるプロセス状態にもっともフィットした形式と言えます 「プロジェクト内のルール」として同じプロジェクト内でプロセスを使う場合 このケースは、同じプロジェクト内の業務フローや作業手順をプロジェクト内で共有する使い方です このプロセスを他のプロジェクトが使用することはありませんので、プロジェクトの中で自由な方法で文書化すればよく、形式的な制約もありません プロセスモデリングの考え方ここでは、フォーマルな形式でプロセスを文書化していく場合に有効な「プロセスモデリング」の考え方をご紹介します。 プロセスは、3つのレベルを用いて定義すると、プロセスの組み換えや、その後発生する改善が容易にできるとされています。すなわち、次のような3階層に分けることを念頭にプロセスの各要素を定義していくことが推奨されます。 抽象的なレイヤープロセスモデリングでは、Universal Process Modelと表現され、上位レベルの概要を提供し、方針を具体的に表現するレイヤーです。例えば、「すべての作業はベースラインに統合される前にインスペクションを受けること」のように、基本方針を定義することになります。 現実的なレイヤープロセスモデリングでは、Worldly Process Modelと表現され、上位レベルの方針を実現するための手順を確立するレイヤーです。具体的には、作業者の作業順序をガイドし、作業に必要な条件と結果を定義し、詳細な手順や成果物のテンプレートなどは、適宜下位レイヤーの文書を参照することになります。例えば、「いつ、だれが、どのようにSQA監査を実施する」のような作業レベルの手順を定義することになります。 詳細なレイヤープロセスモデリングでは、Atomic Process Modelと表現され、極めて詳細な手順を確立するレイヤーです。成果物を作成する手順やテンプレートなどが該当します。例えば、「アーキテクチャ設計の設計技法」、「アーキテクチャ設計書テンプレート」などを定義することになります。 プロセスアーキテクチャ設計の事例 プロセスモデリングの考え方を参考に作成したプロセスアーキテクチャ設計の事例をご紹介いたします。  本事例では、4階層のプロセスアーキテクチャを設計しましたが、手順はおおむね次の通りです: プロセスの階層を決定する 各階層で作成するプロセス文書を決定する プロセス文書のフォーマットを決定する プロセス文書を作成する 作成したライフサイクルにプロセス部品を当てはめプロセスを作成するここで注意していただきたいのは、プロセスアーキテクチャはプロセスの静的な構造であるということです。プロセスの動的な側面では、ここで作成したプロセス文書(アクティビティ、タスク、プロセス資産など)をプロセス部品として捉え、プロセスは部品を連結して作成するという前提に立っているということです。この考え方は、いわゆるオブジェクト指向のアプローチを踏襲しています。OMG(Object Management Gruop)から、SEPM(Software and System Process Engineering Metamodel)が発行されているので、興味のある方は参照してみてください。  さいごに:Automotive SPICE 能力レベル2のプロセス文書今回は、Automotive SPICE 能力レベル3で必要となるフォーマルな形式による組織標準プロセスの作成に焦点をあてて説明してきました。最後に、Automotive SPICE 能力レベル2で求められるプロセス文章の形式について簡単に触れておきます。能力レベル2の要点は、計画的に作業を進めることです。作業の計画を立てるには、何らかのプロセス文書は必要でしょう。しかしながら、今回説明したような部品を結合してプロセスを作成するようなことは求めていません。どのような形式であろうと、作業ルールがプロジェクト内に周知できるレベルの文書があれば問題ありません。最初から難しいレベルを求めず、まずは必要最低限のルールを決めて、計画的な作業ができる環境を整えてください。(日吉 昭彦)

コラム

アセスメントを活かす!改善を定着させる4つのポイント

皆様の中には、Automotive SPICEなどのモデルに基づいたアセスメントをした、もしくは受審した経験のある方が多くいらっしゃるかと思います。では、そもそも何のためにアセスメントをするのでしょうか?レベル獲得をアピールするためでしょうか?商権獲得の条件になっているからでしょうか?確かにそういった事情もありますが、その事情に固執しすぎるとその一瞬のためだけにプロセスを整備する、いわば一過性の取り組みになってしまう場合があります。そこで今回は、アセスメントの本来の目的とアセスメントの有効な活用事例についてご紹介したいと思いますので、ご一読ください。 ■ アセスメントの本来の目的とは?Automotive SPICEやCMMI等のモデルに基づくアセスメントは、プロジェクトの現状を客観的に可視化し、次の改善につなげるための有効的な手段です。しかし、現場ではアセスメントが“イベント化”してしまい、評定や弱点ばかりに注目される傾向が見受けられます。その結果、アセスメントが一過性の取り組みとなってしまい、継続的な改善につながらないケースが多くなっています。皆様の現場では、アセスメントが継続的な改善に活用されていますでしょうか?様々な組織でお話を伺う中で、特に国内では”アセスメントのイベント化”の傾向が強いように感じています。 ■ 目標達成がゴールになってしまう落とし穴アセスメントの目的が「能力レベルの獲得」にすり替わると、達成した時点で改善活動が止まってしまいます。このような状況下ではプロセスの更新が行われず、最悪の場合、改善前の状態に戻ってしまうこともあります。数年前のことになりますが、私が過去にプロセス改善を支援した開発現場へ何年かぶりに訪れた際、そこで見たものは、以前定義したはずのプロセスが改善前の状態に戻っており、時間をかけて築いてきたプロセス資産や知見の多くが失われていた姿でした。その時は大きな虚無感と同時に、あるべき姿を”維持”できなければ意味がない、と感じた瞬間でもありました。そういった意味でも、アセスメントという、いわば「プロセス診断」を継続的に実施し、常に改善を前に進める取り組みが必要だと改めて感じています。 ■ アセスメントによる改善を定着させる4つのポイントここからは、アセスメントによる改善の機会を自組織に根付かせるための4つのポイントをご紹介します:① まずは小さく始めてみる 10数プロセスを一度のアセスメントで実施する必要はありません。 主要なプロセスや、その中の一部のベースプラクティス(BP)に絞って実施し、小刻みに改善を繰り返す方法も効果があります。② 現場と一体で進める 開発・QA・マネジメント層が一体となって推進することで、組織全体の意識を高めることができます。 改善活動の体制を構築する際には、影響力のある人材の選任が重要です。③ 質の高いフィードバック アセスメントによって問題の本質となる指摘・弱みを抽出することで、改善の方向性を明確にすることができます。 よってアセッサーは、関係者全員が改善の方向性に納得できるよう、根拠のあるフィードバックをする必要があります。④ 成果の可視化 コスト削減、納期短縮、品質向上など、改善によって得られた成果をプロジェクトや管理者層が実感できるようにします。 成果の大小にかかわらず、改善結果を共有することが重要です。このような取り組みを通じて、アセスメントは組織にとっての“生活必需品”となり、日常的な改善活動の一部として定着していきます。 ■ 私たちが支援できること改善が停滞する主な原因として、以下の2点が挙げられます。  改善の目的が「レベル獲得」へとすり替わってしまうこと 現場にとって改善の効果が実感しづらいこと こうした状況を打開するためには、まず「アセスメント」という手法を活用し、問題の本質を客観的に可視化することが重要です。質の高いアセスメントは、課題の核心を捉え、改善の方向性を明確にする力を持っています。さらに、アセスメントを一部の専門家だけの取り組みに留めるのではなく、開発・QA・マネジメント層が一体となって継続的に推進することで、その効果を最大限に引き出すことができます。 私たちは、以下のような支援を通じて、高品質なアセスメントの定着と改善活動の加速に向けたサポートをしています: 組織にメリットのあるアセスメントが提供できる、社内アセッサーの育成 アセスメントとプロジェクトが共存・共栄する仕組みづくり SEPG(Software Engineering Process Group)と連携したプロセス改善支援 アセスメントでプロセスを最速改善したい、改善を組織に根付かせたい、という思いのある方は、ぜひ弊社コンサルタントへお気軽にご相談ください。 こちらの関連記事もぜひご覧ください。[コラム]Automotive SPICEを使って業務は改善されているのか?https://www.bgarage.co.jp/news/1240/ [コラム]Automotive SPICEの活動を効率良く進めるためにhttps://www.bgarage.co.jp/news/1031/ (長澤克仁)

コラム

要求仕様に関する不具合発生を防止する - 「W字モデル」導入のメリットと課題

はじめに「出荷直前/出荷後に要求仕様通りにソフトウェアが動作しないことが発覚し、その改修作業で想定外の手戻り作業による大幅な出荷遅延と追加費用が発生した。」ソフトウェア開発プロジェクトで上記のようなトラブルを経験したことはありませんか?一般的に、要求仕様に関連する不具合は、最終工程であるソフトウェア検証まで検出できないため、手戻り作業や改修コストが予想以上に大きくなります。要求仕様に関する不具合の原因として、以下のようなケースが考えられます。 要求分析工程で、開発者が誤った(曖昧な/不十分な)要求仕様書を作成してしまった。 検証者は、検証工程で誤った(曖昧な/不十分な)要求仕様書に従って検証仕様書を作成して検証を実施したため、検証検証結果の妥当性の確認が不十分だった。 開発者と検証者間の情報共有不足により、検証工程で検証者が要求仕様書を十分に理解できないまま、誤った検証仕様書を作成して検証作業を実施したため、十分な検証ができていなかった。要求仕様に関する不具合発生の防止策の一つとして、上流工程の品質向上を目的とした「W字モデル」の考え方とプロセスを導入するというアプローチがあります。 1. 「V字モデル」とはまず最初に、ソフトウェア開発で広く採用されている「V字モデル」について簡単に説明します。 ウォーターフォール開発モデルでは、各開発プロセスの上流から下流に向かって、要求分析、設計、検証と各プロセスを進め、基本的に後戻りはしません。 V字モデルは、ウォーターフォールモデルに対して、開発工程と検証工程の各プロセス間の対応関係を明確にした開発モデルです。一般的に、V字モデルにおける開発者と検証者の業務分担は以下となります。   2. 「W字モデル」とは次に、「W字モデル」について、「V字モデル」との違いに着目して簡単に説明します。 W字モデルは Andreas Spillner 氏が提唱した「上流工程で検証計画を同時期に作成することで、開発工程全体短縮(開発効率化)を実現する」 というプロセスモデルに基づいており、開発と検証を交互に繰り返す活動が 「W字」 に見えることから、W字モデルと呼ばれています。 W字モデルはV字モデルを拡張した開発モデルで、開発工程完了後に検証を行うのではなく、開発と検証をリンクさせ、開発段階から検証者が参加して検証準備を同時並行で行うことを特徴としています。W字モデルにおける開発者と検証者の業務分担は以下となります。   3.開発者、検証者の業務分担2章、3章で説明した「V字モデル」と「W字モデル」の違いを、各工程毎の開発者と検証者間の業務分担と実施時期に着目して表形式でまとめてみましたので、参考にしてください。   4.「W字モデル」導入のメリット「W字モデル」を導入することにより、開発作業と検証作業を並行して実施することで、次のような効果が期待できます。 要求仕様書や設計書を開発者と検証者が合同レビューすることで検証の知見が加わり、矛盾/欠陥の検出率向上します(作業成果物の品質の向上)。 早期検出と検証の知見を開発にフィードバックできるため、検証工程まで不具合を流出させた場合の改修費用との比較で、手戻り工数の大幅な削減が期待できます(開発効率化)。 開発/検証チーム間の協業体制が醸成され、プロジェクトメンバーの品質に対する意識が向上します。 5.「W字モデル」導入の留意点「W字モデル」を導入するにあたり、次のような考慮・認識しておくべき留意点があります。 W字モデルを導入するには、検証工程を前倒しにするなど開発プロセス全体に変革が必要で、体制構築と要員計画の見直し、チームのスキルセット向上等、多岐にわたる事前準備が必要となります。 W字モデルでは開発作業と検証作業の連携が密になり、リソース調達やプロジェクト管理が複雑になるので、開発者と検証者間の情報共有の仕組み構築や開発/検証ツール選定も相互連携を考慮して慎重に行う必要があります。 一般に高スキル者数は限られており、開発/検証チーム双方に高スキル者を同時にアサインすることは困難です。 開発段階から検証者が関与するためには、検証者にも開発者と同等レベルの仕様理解力、設計力、コミュニケーション能力が求められますが、プロジェクト管理者は開発チームへの高スキル者アサインを優先すると、開発/検証チーム間の対等な関係構築は困難になります。 W字モデル導入の効果を得るには、組織の開発プロセス(V字プロセス)が十分成熟していることが前提となります。 検証者が検証業務の分析/計画などの活動無しに検証作業を実施している組織では、Wモデル導入効果は期待できません。特にソフトウェア愛初経験豊富な検証者を確保できるかというところがネックとなりがちですので、上記の留意点を踏まえると本格的に「W字モデル」を導入するのは、少しハードルが高いと感じるかもしれません。ソフトウェアアーキテクチャ/詳細設計の設計レビューに、ソフトウェア開発経験が無い検証者が参加しても、お勉強会になりがちですが(勉強の成果は、自ら実施する検証作業の精度向上には役立ちます)、レビュー対象のドキュメントの品質向上効果はあまり期待できません。要求分析工程に限定すれば、評価者に追加要求されるスキルは仕様理解力となり(仕様理解力は文章読解力と同じ)、ソフトウェア設計経験の有無にはあまり関係ないと考えて良いので、「W 字モデル」のアプローチ導入に対するハードルは大幅に低下するのではないでしょうか。 まとめユーザ視点・仕様理解力を持った検証の専門家が要求仕様レビューに参加すれば、検証の知見を発揮して要求仕様の品質向上に大きく貢献できると思います。要求仕様に関する不具合は影響範囲・規模が一番大きいので、これを少しでも削減できれば大きな開発効率化が実現できます。まずは、要求分析工程に対して部分的に「Wモデル」を適用するというスモールスタートをトライしてみてはいかがでしょう。(海農公宏)

コラム

プロセスとは何か? ~ 開発プロセスについて考えてみよう

この記事を見てくださっている方は、製品の開発プロセス作成に何らかの形で携わっている方だと思います。今回は、「プロセス」という言葉との向き合い方について、そのヒントをお伝えします。  Process という言葉の解釈皆さんは、「プロセス」という言葉の意味を、うまく説明できますか?筆者は、当初なかなかうまく説明できませんでした。プロセスという単語は、そもそもカタカナで記載される単語であり、日本語の解釈が数多くある言葉だと思います。従って開発プロセスとして使う場合は、プロセスという言葉の使用環境を理解して、その解釈の適合性を整理しておくことが、スタートラインだと考えています。 まず、Google 先生に「プロセス」「広辞苑」と入力して聞いてみたところ、下記の回答が返ってきました: 広辞苑における「プロセス」の意味は、「過程」や「工程」と同義で、物事が結果に達するまでの道筋や手順、方法を指します。ビジネスシーンにおいては、業務の進め方や手順、または一連の出来事を指すことが多いです。 広辞苑には「プロセス」という単語そのものの定義は直接記載されていませんが、類語として「過程」、「工程」、「手順」などが挙げられています。これらの言葉は、広辞苑で「プロセス」の概念を理解する上で参考になります。 AIによる概要として、英語の「process」が語源であり、現代では物事の達成までの工程や過程、あるいはその進め方を指す言葉として一般的に使用されています。という説明も出力されました。次に日本語辞書から検索してみると(デジタル大辞泉で検索): 仕事を進める方法、手順。「作業のプロセス」 過程、経過 コンピューターでプログラムなどを動作させる際、CPUが実行するひとまとまりの処理の単位 他の検索ツールにおいても、おおむね同様の説明が得られるようです。結論からすると、外来語である「プロセス」を直接当てはめる日本語はなく、使用用途に応じて適切な解釈をすることの重要性が再認識されます。 では、「開発プロセス」として見た場合、どのように解釈するのが良いでしょうか?ここでは、欧米が発信する世界標準や文献から、Process の一般的な定義を調査してみます。 IEEE Standard Glossary of Software Engineering Terminology:ある目的のために実行される一連のステップCMMI 用語集:互いに関連を持った活動の集合であり、所与の目的を達成するために、入力を出力に変換するものQuality Process Management by Pall, Gabriel:指定された最終結果を生み出すように設計された作業活動に関わる「人、材料、エネルギー、機器および手順」の論理的編成 つまり、開発プロセスとは、「アウトプットを出すために実施している作業ステップ」と考えられます。 プロセスアセスメントのインタビューで、プロセスという言葉を使って会話すると、「残念ながら、私たちにはプロセスはないんですよ」というやり取りになることがあります。プロセスの意味を正しく理解していれば、少しおかしな発言だと思いませんか?言葉の解釈が正しくできていれば、「私たちの作業プロセスは文書化されていません」という回答となるはずです。何らかの作業をしてアウトプットが生成されていれば、そこに「プロセス」は存在するからです。  開発プロセスを文書化する際のヒントと注意点それでは、開発プロセスを文書化する上で重要な点について考察してみます。 現状の作業方法を正しく理解すること これには、「誰が」、「何を入力として」、「どのような方法で」、「何を作成しているか」を含みます そして明確になったことを文書化することこれを第一ステップとして、開発メンバー全員で共有することが重要です。もし、個々人で作業内容が異なる場合は、調整しながら納得のいく手順に修正する必要があります。このステップなくして、プロセス改善 = 「品質や生産性の向上」にはつながりません。 特に、プロセスアセスメントモデルを活用しているケースでは、次のようなことが起こりがちですので注意が必要です: 従来の作業方法を考えずに、モデルをそのままコピーしてプロセスを作成してしまう アセスメントで「○○文書がない」と指摘されたため、モデルに定義されている成果物をそのまま新たに導入してしまう製品開発ができている限り、アセスメントモデルが言及していることと同様の作業や成果物が必ずあるはずです。言葉遣いの相違、成果物の過不足あるいは作業順の違いなどはあって当たり前です。アセスメントモデルは、世の中のベストプラクティスをモデル化しただけですので、順番や言葉遣いは標準化されているからです。 ここで重要なことは: モデルの意図を理解すること 自分たちが従来実施している作業手順を尊重すること もしモデルが言及していることと現作業手順にギャップがある場合、それを変更・追加した際の価値と効果を評価することアセスメントモデルがプロセス能力レベルを定義していることから、ゴールを急ぐことが目的になり、ついつい本質を見失う活動になりがちです。ばくだいな工数をかけてプロセスを変更したにもかかわらず、工数ばかりが増加して誰からも歓迎されない手順になってしまったり、アセスメントの説明以外では誰も使っていない成果物ができてしまうということが実際に起こっています。まずは、自分たちの作業を尊重して作業を進めることを第一ステップとしてください。  プロセスは、段階的に改善していく「現状手順をベースに作業すると、すぐに能力ベルが上がらないじゃないか!」、「上司からは、顧客要求だから1年後に能力レベル3が必達だ!と言われている」という声が聞こえてきそうです。それは、確かにリアルワールドで起こっていることだと認識しています。目標到達までの時間は、現状いる位置により異なりますよね。従って、まずは自分のいる位置をきちんと把握した上で、議論することが必要です。 Automotive SPICEを要求してくる欧州自動車メーカーも、プロセスに関するプロフェッショナルです。発注前のアセスメント結果(サプライヤーの現状の立ち位置)があまりにも低い場合は、無理な要求はしないはずです。それは能力レベルを1段階向上させるために要する時間を経験上知っているからです。言葉を変えると、そのような評価になったサプライヤーには発注しないはずです。ノミネーションに残ったということは、それなりの期間で能力レベルの向上が可能だと判断したということなのです。 現状の立ち位置から目標到達までの改善計画を立案し、自動車メーカー(あるいは会社の上司)と合意しながら進めていくことが最短の道のりとなるはずです。ぜひ、従来の作業方法に自信を持って、アセスメントモデルに翻弄されない活動をしていただけるよう切に願います。 プロセスの可視化のステップのわかりやすい事例が、CMMI関連の技術文書に書かれているので、プロセス能力の向上という観点からプロセスの可視化のイメージをつかんでください。  能力レベルとは、作業(プロセス)の定着度合いを示す指標だと考えてみてください。プロジェクトの経験から得た学びを、継続的に改善を繰り返すことで段階的にプロセス能力の向上が可能となります。この過程では、「プロセスが適切な粒度で可視化」されるようになることで、その粒度でプロセス実績が計測可能となり、結果としてプロセス実績のばらつきが少なくなっていくことになります。  「文書化されたプロセスが使われない」もう1つの要因作成者が苦労して作成したプロセスも、開発メンバーに使ってもらえなければ、まったく意味がありません。残念ながら、数多くの組織やプロジェクトで、このような状況が起きています。もう一度「プロセスの可視性」と「予測される実績」の図を見てください。プロセスが可視化されていても、開発メンバーに浸透していなければ「能力レベル1」の状態と変わりません。たとえプロセスが文書化されていても、そのプロセスを意識せずに各メンバーが思い思いの方法で作業しているのであれば、プロセスは雲の中にある状態と変わらず、実績もついてこないことは容易に想像できると思います。 なぜこんなことが起こってしまうのでしょうか?誰が考えても、この無駄な状況を理解できると思います。ズバリ!日本の文化では、「Process」の必要性を多くの人が感じていないのだと思います。特に、人と人との擦り合わせの中で業務をしていく習慣が強い日本では、その場その場で臨機応変な対応を迫られます。ここが、外来語である「プロセス」の難しいところだと思っています。たとえプロセスを文書化しても、プロセス通りには作業できないことが日常で多く起こってしまうのかもしれません。あるいは作業計画を作成したが、要件変更が日常的に発生し、計画しても意味がないということが日本では多いようです。 一方、日本でも擦り合わせだけではうまくプロジェクトを回せない状況になりつつあります。例えば、Z世代のような若い人たちの考え方の変化、海外を含めた多拠点開発や分業制の必要性など、開発プロジェクトの環境は欧米に近づいてきています。従って、このままの状況を放置していくことは良いことではありません。  では、「プロセス」にはどのように向き合っていけばよいのでしょうか?第一に、プロセスを確立することの目的を明確にし、その価値を共有することです。 プロセス管理の前提は、製品品質や生産性の向上が直接的な焦点ですが、最終ゴールは事業への貢献にあります 従って、プロセスは経営者や上級管理者の事業への思いを実現する手段でなければなりません 欧州自動車メーカーは、Automotive SPICEをプロジェクト要求としてインプットしてきますが、彼らがアセスメントモデルを活用する背景には、プロセス管理の前提を理解した経営層が組織運営しているサプライヤーと幅広く長期間の取引をしたいという目的もあるのです 次に、目的を達成するためのアプローチを経営側面で決定し、段階的に進めながら最終ゴールを目指すことです。 初めから高望みははしない アセスメントモデルで使用される各能力レベルへの到達指標は、その評点に大きな幅(50点から85点)があることを認識してください 最初の目標は50点で良しとし、次の段階で85点以上を目指すようなアプローチが可能になっています はじめから重厚長大なプロセスを作っても、使われなくなるという副作用が増すだけです 能力レベルの評点に大きな幅を持たせているのは、プロセス改善で起こりうる状況を考慮した上で、段階的なアプローチを可能にするためなのです  プロジェクト個別に進めるのか、最初から組織標準を導入するのか? Automotive SPICEのようなプロセスモデルの本質を理解して、アプローチを決定することが良いでしょう アセスメントモデルでは、組織標準の適用段階は能力レベル3であるということを理解しておくことも重要です 経験則的に、プロジェクト内の決め事が徹底できない状況のプロジェクトに、組織標準を適用し浸透させることは至難の業です プロセスの作成に専任リソースを準備するのか、プロジェクトメンバー全員が参加する方法(プロジェクト業務との兼務)で実施するのか? ここには正解はなく、経営者や管理者の思いで体制を構築することが最善策となるでしょう  たとえば下記の2つの考え方は、人によって異なるはずです: 兼務の場合、プロジェクト業務がひっ迫するとプロセス改善活動がおろそかになるため、専任リソースによる活動が望ましい 専任リソースがプロセスを定義すると、プロジェクトの思いとは異なるプロセスができやすく、浸透しにくいため、全員参加が望ましい ここで重要なのは体制ではなく、経営者・管理者が自分の思いで活動を主導することであり、これができる組織は必ず成功しています 最終的なゴールを最初からある程度想定しながら、段階的にゴールを変更していくことも重要かもしれません。筆者は、これまでの経験(自社や他社の取り組み)から、最終ゴールは、「ツール上で日々の仕事ができるようになれば、担当者はプロセス文書を見なくても仕事ができる状態にすること」だと考えています プロジェクト計画書の作成を例に挙げると: 日本では、計画書のテンプレートを準備して、人手により時間をかけて書いていることが大半です 欧米では、日々の作業に必要なWBSタスクや役割分担などをツール上で管理者が定義し、担当者はWBSに従って作業し、実績を入力する方法が一般的です これは、ツール上にある各タスクが日々の作業計画であり、作業記録が進捗状態だという合理的な考え方です プロジェクト計画書を他者に見せる必要がある場合は、「計画書作成ボタン」を押すと、ツール上に組み込まれたテンプレートに必要なデータ要素が組み込まれ、自動で印刷されるような仕組みが導入されています欧米のケースでも、プロセス文書は存在しており、それはツールの設計図という位置づけに加えて、各ツールの機能画面から必要に応じて簡単に参照できるようになっています  さいごに筆者は、全社にCMMIに準拠した標準プロセスを導入するように命じられた時、欧米人を1名プロジェクトに加えてくれとお願いしました。なぜならば、カタカナで分かりにくい内容のものを導入するなら、文化的に「Process」という扱いに慣れた人材の投入が最短だと思ったからです。残念ながら願いは叶わず、プロセス能力が上がるまでに長い時間がかかってしまいました。しかしながら、長い年月をかけて数多くの挫折を経験できたことで、開発現場におけるプロセスとの向き合い方に関するノウハウを得られたことは貴重な体験でした。今回のコラムが、同様の悩みを持たれている方々への一助になれば幸いです。 弊社では、プロセスアセスメントモデルを扱う際に発生する課題や教訓を記載したコラム(Automotive SPICE(アセスメントモデル)の功罪)も発行しておりますので、こちらもご参照ください。 次回は、プロセスを文書化していく際に有効な「プロセスモデリングの原則」を取り入れたプロセスアーキテクチャに関するコラムをお届けする予定です。(日吉昭彦)