Updates

新着情報

B'zine

B'zine - 2025年10月号（Webinar開催～生成AIでFMEAを作成してみたら～など）を発行しました

10月下旬になり朝晩はめっきり肌寒くなりました。秋の行楽シーズン到来ですが、山奥深い場所や人気のない場所への侵入や単独行動は控え、熊出没注意報にも十分注意して、紅葉狩りをお楽しみください。 B'zine 10月号を発行いたしました。動画版(約3分)も公開していますので、弊社公式YouTubeより是非ご視聴ください。https://youtu.be/DP1UjaROsto     B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信（2025年10月号）  B'zine 10月号をお届けします。10月下旬になり朝晩はめっきり肌寒くなりました。秋の行楽シーズン到来ですが、山奥深い場所や人気のない場所への侵入や単独行動は控え、熊出没注意報にも十分注意して、紅葉狩りをお楽しみください。【今月のトピックス】 イベント：第６回 ビジネスガレージオープンWebinar開催（11/26） コラム：無料相談会（ミニコンサル）11月開催 コラム：使えるプロセス vs 使われないプロセス：決定的な違いと成功事例 コラム：ソフトウェアテストのプロセス改善を支える国際標準～Test SPICE～ コラム：「テスト頼み」からの脱却 ─ レビュー文化が品質を変える 【イベント】 2025年11月26日 Webinar～生成AIでFMEAを作成してみたら～のご案内ChatGPTを活用することで、FMEAの作成期間とリソースを劇的に削減した事例をご紹介します日時：2025/11/26(水) 16:00 – 16:50お申込みはこちらから→ https://www.bgarage.co.jp/news/1496/ 無料相談会（ミニコンサル）11月開催のご案内弊社では、皆様のお困りごとに対する相談会を実施しています。Automotive SPICE/プロセス改善/プロジェクト管理など、お気軽にご相談ください。お申込みはこちらから→https://www.bgarage.co.jp/news/1494/ 2026年1月 Webinar（予定）：EARSを活用した要求の書き方構文形式を利用することで、書き手と読み手の解釈不一致を防止する要求の文書化手法と事例をご紹介します。 【コラム】 使えるプロセス vs 使われないプロセス：決定的な違いと成功事例プロセス改善は、こうした属人的な開発から脱却し、誰がやっても一定の品質・納期・コストを再現できる仕組みをつくるための重要な取り組みです。しかし近年、開発の複雑化や規格対応の厳格化により、品質問題や納期遅延のリスクはますます高まっています。その一方で、監査や認証取得を目的に整備された“形だけのプロセス”が現場で使われず、改善が止まってしまうケースが増えているのも事実です。良いプロセスも、現場で使われなければ意味がありません。では、なぜプロセスは使われなくなるのか？どうすれば現場で本当に役立つプロセスになるのか？このコラムでは、私たちの現場支援の経験をもとに、成功のヒントをいくつかご紹介します。詳細はこちら→https://www.bgarage.co.jp/news/1424/ ソフトウェアテストのプロセス改善を支える国際標準～Test SPICE～ソフトウェア開発において、テストは品質保証の要です。しかし、テスト活動そのものの成熟度やプロセス品質を体系的に評価・改善する枠組みは、長らく十分に整備されていませんでした。そこで登場したのが Test SPICEです。Test SPICEは、ISO/IEC 330xxシリーズの一部として策定された、ソフトウェアテストに特化したプロセス評価モデルです。従来のSPICE（Software Process Improvement and Capability Determination）モデルをベースに、テスト活動の特性に合わせて設計されています。「検証サービスプロバイダ」 に求められる組織能力を可視化し、プロセス改善による組織能力向上を図ることを目的としていますが、テスト資産の再利用や回帰テストの自動化など、ソフトウェア開発組織のテストプロセスの改善にも有益な内容になっています。詳細はこちら→https://www.bgarage.co.jp/news/1464/ 「テスト頼み」からの脱却 ─ レビュー文化が品質を変える製品開発における品質保証は、テスト工程に偏りがちです。多くの組織では、テストで検出された不具合をもって品質を評価し、設計工程でのレビュー指摘は記録されない、あるいは品質活動の一部として認識されていないことがあります。しかし、品質は本当に“テストだけ”で保証できるのでしょうか？テストは重要な工程ですが、あくまで後工程であり、設計段階での不具合をすべて検出できるわけではありません。特に組込み系開発では、タイミング依存や環境依存の不具合が多く、テストだけでは限界があります。設計段階での不具合を未然に防ぐには、レビューによる“作り込み”が不可欠です。詳細はこちら→https://www.bgarage.co.jp/news/1453/

コラム

ソフトウェアテストのプロセス改善を支える国際標準～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/

トップ新着情報

Contact Us

お問い合わせ

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

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