Updates

新着情報

コラム

DX時代にPMOはどう進化するべきか？

はじめにDX（デジタルトランスフォーメーション）は、単なるITシステムの導入や業務効率化にとどまらず、企業のビジネスモデルや業務プロセスを抜本的に変革し、競争力を高める取り組みです。こうした変革を推進するDXプロジェクトは、これまでのプロジェクトの管理とは異なる性質を持っています。では、組織横断でプロジェクトを支援するPMO（Project Management Office）は、どのように対応すべきでしょうか？ DXプロジェクトとはまず、「DX」ということばの意味するところを再確認してみましょう。2022年9月に経済産業省が発表した「デジタルガバナンス・コード2.0」の中で、DXを以下のように定義しています。 「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化、風土をも改革し、競争上の優位を確立すること」 つまり、デジタル技術を活用して企業のビジネスモデル、業務プロセス、顧客体験を抜本的に変革し、競争力を高める取り組みです。その目的は、単なるITシステム導入ではなく、ビジネス価値創出や新しい働き方の実現にあります。 では、DXのイメージをより明確にするため、DXプロジェクトの具体例を挙げます。例①：業務プロセス自動化プロジェクトRPA、AI-OCR活用した紙書類を扱う業務プロセスの自動化＜DXとしてのポイント＞単なるIT導入や効率化の場合：・既存業務をそのままシステム化するだけ。（例：紙の請求書をExcel入力からシステム入力に変える）・業務フローや役割は基本的に変わらない。・効果は「作業時間短縮」程度。DX要素：・RPA導入時に「どの業務を自動化するか」「どの業務を廃止するか」を検討し、業務フローを抜本的に見直す。・定型業務を自動化することで、人員を戦略業務や顧客対応にシフト。人材のスキル再配置や教育も必要。・AI-OCRで紙書類をデジタル化し、RPAで処理、さらにBIで分析するなど、業務のデジタル化と意思決定の高度化を一体化。 例➁：クラウド移行型プロジェクト製造業の基幹システム（在庫管理・生産計画）をオンプレミスからクラウドに移行し、API連携を実施＜DXとしてのポイント＞単なるIT導入や効率化の場合：・クラウドに移すだけなら「インフラコスト削減」のみで終わる。DX要素：・API連携でサプライヤーや販売店とリアルタイム情報共有 → サプライチェーン全体の最適化。・クラウド基盤を活用し、新しいビジネスモデル（サブスクリプション型サービス）を開始。 このようなDXプロジェクトは、次のような特徴を持っていると言えます。・デジタル技術（クラウド、AI、IoT、RPAなど）を活用・ビジネスモデルや業務プロセスの変革を伴う・顧客価値・体験の向上を重視・スピードと柔軟性（アジャイル開発、DevOps）を求める・組織文化や人材スキルの変革が不可欠 PMOの進化と果たすべき新しい価値一方、プロジェクト管理の機能を持つPMOは、DXプロジェクトに対してどのような進化が必要になるのでしょうか？組織全体のプロジェクト成功率を高めるために、PMOは一般的には、以下のような役割を担います。・標準化：プロジェクト管理プロセスやツールの整備・統一化・ガバナンス：品質、リスク、コンプライアンスの監視・リソース管理：プロジェクト間の資源の最適配分・進捗・コスト管理：計画対実績のモニタリング・ナレッジ共有：成功・失敗事例の蓄積と再利用・ステークホルダーコミュニケーション：経営層や顧客への報告 DX時代のPMOは、上記の基本的な機能だけでなく、新たな「価値創出の推進者」として、次のように進化する必要があると考えられます。 DX推進戦略策定（新たな役割）DX推進のための戦略策定（またはその支援）が、新たな役割としてあげられます。技術選定方針、クラウド方針、AI活用ロードマップなどの策定し、標準化、ガバナンス、投資判断などを一貫化させる。さらに、DXの成果を事業戦略に反映し、新規事業創出のロードマップを描くようなことにも対応していく必要があります。 標準化：スピードと柔軟性の両立アジャイル開発やDevOpsを前提とした標準化が求められます。スプリント計画やCI/CDパイプライン、クラウド設計基準など、スピードと柔軟性を両立する仕組みが必要です。つまり、伝統的なライフサイクルではなく、スピードや柔軟性に対応した、開発手法の標準化に対応していかなければなりません。 ガバナンス：新リスク領域への対応クラウドセキュリティ、データプライバシー、AI倫理など、新たなリスク領域が追加されます。スピードを損なわない軽量的なガバナンスと継続的な監査の仕組みが不可欠である一方で、組織のセキュリティポリシーや倫理観に抵触しないように、統制を図ることも必要になります。 リソース管理：スキル戦略によるリソース最適化人員や予算の最適配分だけでなく、クラウド、データ、UXなど専門スキルの保有状況の把握と配置が必要になるため、スキルマップ管理やスキルアップの計画、複数プロジェクト間での能力プール管理などが重要になります。さらに、専門的な人材だけでなく、ツールやライセンスに関する予算計画も不可欠です。クラウド利用料、CI/CDツール、AIプラットフォームなど、DX基盤を支えるリソースを総合的に管理する必要があります。 進捗・コスト管理：価値指標を用いた管理伝統的なQCD管理だけでなく、提供した価値を重視するため、DORA指標や顧客価値KPI（NPS、ROI）を追加し、短期間の開発に対応した仮説検証サイクルを支援する必要があります。 ナレッジ共有：データ駆動型のナレッジ共有データカタログ、MLOps知見、UX実験結果など、開発現場へのフィードバックのスピードを上げつつ、日進月歩の技術進化に対応したナレッジ共有が求められます。さらに、得られた知見を活用し、新しいサービスや事業アイデアを生み出す基盤へ進化させることが重要です。 ステークホルダーコミュニケーション：双方向・即時性の高いコミュニケーション経営層や顧客への定期報告だけでなく、ダッシュボードによるリアルタイム報告や、チェンジマネジメントを含むコミュニケーション計画が必要です。顧客体験改善や業務自動化の価値を共有することも重要になります。 まとめDXプロジェクトの成功には、開発現場だけでなく、PMOもこれまでの枠を超えた進化が必要です。PMOは「プロセスやQCDの番人」から「価値創出の推進者」へと役割を変え、組織全体のDXを支える中核となるべきでしょう。  [用語解説] 顧客体験（CX：Customer Experience）：顧客が企業やサービスと接するすべての体験の総称。製品やサービスの品質だけでなく、購入プロセスやサポート対応なども含む。 DevOps：開発（Development）と運用（Operations）を統合し、継続的な改善と迅速なリリースを実現する文化・プロセス・ツールの総称。 CI/CD（Continuous Integration / Continuous Delivery）：継続的インテグレーションと継続的デリバリーの略。コードの自動ビルド・テスト・デプロイを行う仕組みで、開発スピードと品質を両立する。 UX（User Experience）：ユーザーが製品やサービスを利用する際の体験全般。使いやすさ、デザイン、感情的満足度などを含む。 DORA指標（DevOps Research and Assessment Metrics）：DevOpsのパフォーマンスを測る指標群。代表的なものは「デプロイ頻度」「変更のリードタイム」「サービス復旧時間（MTTR）」「変更失敗率」。 NPS（Net Promoter Score）：顧客ロイヤルティを測る指標。「このサービスを他人に勧めたいか？」という質問に基づき、推奨者と批判者の割合から算出。 ROI（Return on Investment）：投資対効果を示す指標。投資額に対してどれだけ利益を得られたかを測る。 MLOps（Machine Learning Operations）：機械学習モデルの開発から運用までを効率的に管理するための仕組みやプロセス。モデルの学習、評価、デプロイ、監視を自動化し、継続的改善を可能にする。DevOpsの考え方を機械学習に適用したもの。 （佐藤 崇）

コラム

日本と欧米におけるソフトウェア開発アプローチの違い

1. アーキテクチャ設計の扱い日本のOEM（自動車メーカー）は、ソフトウェア開発においてサプライヤーにアーキテクチャ設計を明確に要求しない傾向があります。OEMが、「機能単位で仕様から設計、検証までを一貫して確認する」ことを重視するため、サプライヤーの開発プロセスも世界標準とは異なる建て付けになっていることが多いようです。これは、従来の製品開発における「現場で調整しながら完成度を高める」すり合わせの文化であり、全体構造を俯瞰する仕組みが不足しがちです。 一方、欧米では工学論を前提とした開発文化が強く、システム全体のアーキテクチャを明確に定義することが基本となっています。アーキテクチャは、機能の分割や責務の明確化、再利用性の確保、将来的な拡張性を担保するための基盤となります。この違いは、開発の透明性、効率性、そしてグローバルな分散開発への適応力に大きな影響を与えています。  こうした背景が、日本においてAutomotive SPICE（ASPICE）への対応を困難にしている要因となっていると考えます。Automotive SPICEは、プロセスの体系化やアーキテクチャ設計を前提とした評価モデルであるため、個別車両ごとの擦り合わせを重視する日本型の開発文化とは根本的にアプローチが異なるのです。 2. ソフトウェア品質基準の違い日本と欧米では、ソフトウェア品質の考えかたや、管理指標の定義にも大きな違いがあります。 日本の自動車業界では、まだまだ品質管理の発想が工業製品の品質保証の延長線上にあるようです。具体的には、バグ密度やリリース時の不具合件数といった「完成品の品質」を測る指標が重視されています。これは、製造業で長年培われた「最終検査で品質を保証する」という文化がソフトウェアにも適用されているためです。結果として、開発プロセスの途中で品質を作り込むというよりも、完成後に不具合を検出し、修正することに重点がおかれがちです。 しかし、近年では完成後に不具合を検出するのでは遅いという認識を持つ組織も増えています。そのため、各開発工程でレビューを行い、品質を定量的に評価する取り組みが進んでいます。ただし、その際に用いられる指標は、依然として工業製品の品質管理の延長線上にあることが多いのが現状です。例えば、レビューで確認するのは「不具合件数」や「修正率」といった結果指標が多いようです。また、ISO 26262対応で「設計の複雑さ」、「カバレッジ」などを導入しているケースもありますが、これらの指標が閾値を超えた場合の対応が甘く、計測はしているが活用できていないことが多いようです。つまり、日本のアプローチは、レビューを導入しても、根本的な品質保証の思想が「完成品の品質を検査で保証する」文化から脱却しきれていないのです。 一方、欧米では、品質を設計段階から作り込むべきものと捉えています。ソースコードの複雑度やモジュール間の依存関係、テストカバレッジなど、コードメトリクスを活用した定量的な評価が一般的です。これにより、開発の初期段階から品質リスクを把握し、構造的な問題を未然に防ぐことが可能になります。欧米のアプローチは、プロセス品質を重視する「工学的な品質保証」であり、Automotive SPICEやCMMIといった国際的なプロセスモデルとも親和性が高いのが特徴です。この違いは、単なる指標の差ではなく、品質に対する哲学の違いです。日本は「レビューを導入しても工業製品的な品質管理」の文化であり、欧米は「設計品質をプロセスで保証する」文化となります。このギャップが、グローバル開発における摩擦や、日本企業の国際標準対応の難しさを生んでいます。 3. ビジネスモデルの違いこれらの考え方は、ビジネスモデルそのものにも強く影響をおよぼしています。 日本の自動車業界では、車両ごとにOEMとサプライヤーが詳細な擦り合わせを行い、膨大な工数を投入することで品質を担保するモデルが一般的です。この方式は「一車種一設計」に近く、結果として非常に高い品質を実現します。しかし、その裏側では、開発コストと期間が膨らみやすく、再利用性が低いという構造的な課題を抱えています。車種ごとに設計を積み上げるため、開発スピードや効率性の面でグローバル競争に不利になりやすいのです。 一方、欧米の自動車業界は、標準化されたアーキテクチャや共通プラットフォームを開発し、複数車両への展開で生産性を高めるモデルを採用しています。このアプローチでは、基盤となる設計資産を維持しながら、差分開発で新機能や車両特性を追加するため、開発スピードとコスト競争力を両立できます。さらに、標準化によって品質保証の仕組みも統一されるため、グローバルな分散開発に適応しやすいという利点があります。 日本でもOEMの標準モデル開発の導入が進められています。しかしながら、サプライヤーの立場として見た場合、OEMに依存しないサプライヤー独自の製品（部品）アーキテクチャを持つことが重要です。そのうえで、複数OEMの要求に軽微な変更で対応できる仕組みを作ることが、グローバル市場で勝ち残るために必要ではないでしょうか？この違いは、単なる開発手法の差ではなく、産業構造の競争力に直結する問題です。日本の方式は、品質を高めるために「人と時間」を投入するモデルであり、短期的には高品質を実現できますが、長期的には持続可能性に疑問が残ります。過去に家電や携帯電話産業で見られたように、製品ごとに個別設計を行うモデルは、グローバル競争に敗れた歴史があります。同様の構造的リスクが、自動車ソフトウェア開発にも潜んでいるのです。さらに、SDV（Software Defined Vehicle）時代の到来により、ソフトウェアの比重は急速に高まっています。SDVでは、車両機能の多くがソフトウェアによって定義され、OTA（Over-The-Air）更新や機能追加が前提となります。車両ごとに個別対応するモデルでは、複雑化する機能やセキュリティ要件に追従することが困難になり、開発の遅延や品質リスクが増大する可能性があります。標準化と再利用性を軸にしたビジネスモデルへの転換は、日本企業にとって避けられない課題といえるでしょう。   4. 今後の課題と方向性現行の方法論は、国内市場や従来型の集中開発には一定の適合性がありました。しかし、他拠点開発や分散開発があたりまえになる時代において、日本の従来手法は限界を迎えつつあります。生産性の向上と品質の確保を両立するためには、製品アーキテクチャを確立し、設計書をマスター文書としてベースライン化することが不可欠です。これにより、設計の一貫性を維持しながら、品質と開発効率を大幅に向上させることができます。 さらに、ベースライン化された設計文書に変更を加える際には、変分仕様書を作成し、変更前と変更後を明確に示す差分開発の仕組みが必要です。この差分管理により、設計レビューの品質確保が容易になるだけでなく、再利用性を損なわずに新機能や改修を効率的に実施することが可能となります。こうしたプロセスを導入することで、再利用性・品質・開発スピードの三立が現実のものとなります。 今後、日本企業が競争力を維持・強化するためには、国内OEMの要求に応えつつ、欧米型の工学的アプローチを積極的に取り入れることが不可欠です。弊社では、プロダクトライン開発の実践経験を豊富に有しております。今回のコラムで取り上げた品質管理の課題や差分開発型の導入に関心をお持ちの方は、ぜひ弊社までお問い合わせください。 （日吉昭彦）

コラム

設計意図が伝わる仕様書へ──自動車開発に必須の“文書品質”改善術

自然言語による“解釈違い”がもたらすリスク製品開発における技術文書──要求仕様書、アーキテクチャ設計書、分析報告書、議事録。これらは最新の設計技法（Simulink、SysMLなど）を併用しても、最終的には自然言語による定義が必要です。なぜなら、仕様の目的、設計判断の背景、制約や前提、意図や理由といった情報はモデル図だけでは表現しきれないためです。しかしその自然言語は、“曖昧さ”という最大の弱点を持っています。その”曖昧さ”により、たった一つの文章を読み手が誤解釈しただけで、 重大不具合 作業の手戻り 予定外のレビュー追加 顧客指摘による信用低下など、プロジェクトに多大な影響をもたらします。実際の現場では、「仕様の解釈違い」「ドキュメントの不整合」「設計意図の不明瞭さ」が後工程で頻発し、そのたびにコストの増大やスケジュールの圧迫、品質低下を生み出してしまいます。 増え続ける読み手が誤解釈を拡大させている私たちが数多くの開発プロジェクトを支援する中で日々痛感するのは、“文書を読む人が増えているのに、書き方のルールは昔のまま”というギャップです。文書を読み手は後続設計者のみならず、 評価チーム 品質保証 顧客 サプライヤ マーケティング担当など、日々増加しています。にもかかわらず、「読めば理解できるはず」「長年の付き合いだから行間を読んでくれるはず」という前提で書かれた文書が、いまも多くの組織で量産されています。その結果──“書き手には正しいが、読み手には不完全”な技術文書が増え続け、今まで想定しなかった読み手に誤解を与えることによって、思いもしない領域で誤解が発生してしまうわけです。 意図が伝わる技術文書のウソ・ホントここでは、読み手に意図を正しく伝える技術文書にするためのポイントを、”ウソ・ホント”形式でご紹介します。 ① 「設計の意図や変更理由は書くべきである」→ ホント！設計した理由が書かれていないと、読み手は推測に頼ることになります。推測は解釈違いを生み、後工程でトラブルになる原因となります。自動車のワイパー制御を例にすると、書き手は「雨量センサーの反応を少し鈍くする」仕様に変更した際、「小雨時に過剰に動いてしまったため」という理由が明示されていなかったとします。すると読み手は、「反応が鈍くなるなら大雨に対しても感度を少し鈍くする」と誤解釈してしまうことが考えられるわけです。そうならないために、仕様項目の直下に「Purpose（意図）」欄を追加する、または“なぜこの案を選んだか・他案を却下した理由”を検討記録などに残しておくとよいでしょう。 ② 「全体像は文書内で示すべきである」→ ホント！読み手がまず知りたいのは、「この文書は何の話で、どこまでを書いているのか？」です。全体像がない文書は、読み手が迷子になり、レビューが長引きます。例えば文書の冒頭にシステム構成図がなく、説明が断片的なアーキテクチャ設計書が出来上がった場合、レビューで「そもそもこの機能の位置づけは？」「どこと通信する？」「この構成で要求仕様を満足できる？」という議論が何度も発生し、レビューが3時間超え、といったことが起きます。よって、読み手の理解を助けるために、設計書の冒頭に1枚の全体像（コンテキスト図・ブロック図）を必ず入れるようにすることをお勧めします。 ③ 「例外ケースは後で考えればよい」→ ウソ！例外ケースの未定義は、現場で不具合を生みやすいポイントです。例えば、正常系の仕様だけが定義され、異常時の挙動が“未定義”の場合、実装担当が独自判断で処理を追加してしまい、結果として顧客環境で意図と異なる動作になってしまうケースです。そうならないためには、各仕様に「Boundary（境界条件）」と「Exception（例外）」欄を追加する、または「この条件のときは、この仕様は適用されない」と定義するなど記述の工夫が必要です。 文書作成はセンスではなく“技術”である技術文書が伝わらない本当の理由は、文章力が低いからではなく、“構造化されていないから”である場合が少なくありません。文書は、 意図（Why） 理由（Reason） 相関（Relation） 全体像（Overview）の4つが揃えば、劇的に読みやすくなります。弊社では、項目の標準化、テンプレート改善、“意図を書く技法”の教育、レビュー基準の整備、文書作成プロセスの改善、などを通じて、文書品質を“組織として”底上げする支援を行っています。皆様の組織で、次のような状況はありませんか？ 仕様の解釈違いが多い 手戻りが頻発している レビューが形骸化している 文書が読みにくく、説明に時間がかかるこれらは書き方を改善することで解決できるケースがほとんどです。「既存の仕様書を簡易診断してほしい」、「3文書だけレビューしてほしい」といった軽いご相談もお受けいたします。まずはお気軽にご相談ください。 お問い合わせはこちらhttps://www.bgarage.co.jp/contact/ （長澤 克仁）

お知らせ

Automotive SPICE Handbook（v4.0+CS v2.0）を発行しました

2025年7月に Automotive SPICE v4.0に対応した「Automotive SPICE サイバーセキュリティ v2.0 日本語版」が公開されました。皆様にご好評を頂いております Automotive SPICE Handbook（v4.0+CS v1.0）を Automotive SPICE サイバーセキュリティ v2.0 に対応版として、Automotive SPICE Handbook（v4.0+CS v2.0）を発行しました。Automotive SPICE Handbook（v4.0+CS v2.0）は、以下の構成で作成しています これまでのコンセプトを踏襲し、全３８プロセスに対して、各プロセスを４頁構成で統一しました プロセス毎の見開き１～２頁に、「プロセス目的」、「プロセス成果」、「情報項目」および、「情報項目特性」を記載しました プロセス毎の見開き３～４頁に、「基本プラクティス」および、弊社オリジナルの「実作業の流れ」と「プロセス関連図」を記載しました Automotive SPICE v4.0 の３２プロセスと Automotive SPICE サイバーセキュリティ v2.0 の６プロセスの章を分離して解り易くしました Automotive SPICE v4.0 の３２プロセスに記載している「プロセス関連図」も、Automotive SPICE サイバーセキュリティ v2.0 対応に更新しましたご興味のある方は、弊社までお問合せください。ご参考までに、Automotive SPICE Handbook 冊子の表紙と目次、プロセス４頁見開きのイメージを添付します。 表紙と目次 プロセス４頁見開き（SWE.1：ソフトウェア要求分析）

YouTube

【Webinar動画公開】第6回 Webinar　～ 生成AIでFMEAを作成してみたら ～

先日開催した、「第6回 生成AIでFMEAを作成してみたら」の Webinar動画を、弊社公式 YouTube に公開しましたのでお知らせいたします。ぜひ、ご視聴ください。 ▼ご視聴はこちらから：https://youtu.be/DaBMzd4mPD4 ▼タイムライン 00:00 オープニング 03:28 お客様からのご相談内容とFMEA作成の課題 06:27 FMEA作成プロセスとやりすぎポイント、生成AIの活用 18:33 生成AIを使って大丈夫？（パネルディスカッション） 25:36 実施内容と成果 30:50 FMEAが仕上がるまで（デモ） 38:38 効果と提供価値 44:08 FMEA以外に生成AIって使えそう？（社内ディスカッション）

B'zine

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

北海道・東北地方では積雪注意のニュースも聞かれますが、温暖化の影響なのでしょうか、関東では街路樹の銀杏がまだ紅葉せずに青々と茂っているところもあります。秋の行楽シーズンも終盤となり、連日のように熊出没情報が出ていますので、十分注意して紅葉狩りをお楽しみください。 B'zine 11月号を発行いたしました。動画版(約3分)も公開していますので、弊社公式YouTubeより是非ご視聴ください。https://youtu.be/3M2FBkmaZB0     B’zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信（2025年11月号） B’zine 11月号をお届けします。北海道・東北地方では積雪注意のニュースも聞かれますが、温暖化の影響なのでしょうか、関東では街路樹の銀杏がまだ紅葉せずに青々と茂っているところもあります。秋の行楽シーズンも終盤となり、連日のように熊出没情報が出ていますので、十分注意して紅葉狩りをお楽しみください。 【今月のトピックス】 イベント：第６回 ビジネスガレージオープンWebinar開催（11/26） イベント：Webinar EARSを活用した要求の書き方（2026年1月開催予定） コラム：Automotive SPICEの前に考える“要求の肥大化”対策 ～ 要求仕様を明確にする3つのポイント ～ コラム：生成AIはシステム開発・ソフトウェア開発をどう変えるのか？ コラム：車載システム開発における品質保証の進化 － 伴走型QAと現場で作り込む品質 【イベント】 2025年11月26日 Webinar～生成AIでFMEAを作成してみたら～のご案内ChatGPTを活用することで、FMEAの作成期間とリソースを劇的に削減した事例をご紹介します日時：2025/11/26(水) 16:00 – 16:50お申込みはこちらから→ https://www.bgarage.co.jp/news/1496/ 2026年1月 Webinar（予定）：EARSを活用した要求の書き方構文形式を利用することで、書き手と読み手の解釈不一致を防止する要求の文書化手法と事例をご紹介します。 【コラム】  Automotive SPICEの前に考える“要求の肥大化”対策 ～要求仕様を明確にする3つのポイント～「最初は小さな追加だったのに、気づけば手がつけられないほど要求が膨らんでいた。」皆様の現場ではこのような事象に遭遇したことはないでしょうか？いわゆる「要求の肥大化」です。今ではアジャイル開発の普及やツールによるトレース管理などが進み、昔に比べると要求の肥大化そのものは抑制傾向にあります。しかしながら、年々技術の高度化・統合化が急速に進むにつれ、リリース直前にもかかわらず五月雨式に要求が発生するケースは少なくありません。当初の想定を超えた要求が増え続けると、スケジュールは遅れ、品質は落ち、チームの士気も下がります。「うちでは起きていない」と思っていませんか？実は、どんな現場にも“要求の肥大化”の芽は潜んでいるのです。詳細はこちら→https://www.bgarage.co.jp/news/1504/ 生成AIはシステム開発・ソフトウェア開発をどう変えるのか？ 近年、生成AI（Generative AI）は私たちの私生活だけなく、仕事の局面においても利用されるケースが多くなってきました。生成AIは、従来のルールベースや機械学習と異なり、コードだけでなく、人が普段使用する自然言語や画像などを生成する能力をもっています。一方開発現場は、仕様書作成や、コードレビュー、テスト設計、教育資料作成など「知的集約型作業」が多く、生成AIの活用余地が大きい印象があります。今回は、生成AIをどのように開発プロセスに導入していくと良いのかを考察してみました。唯一の答えではなく、あくまでひとつの見解として読んでいただけると幸いです。詳細はこちら→https://www.bgarage.co.jp/news/1524/ 車載システム開発における品質保証の進化 － 伴走型QAと現場で作り込む品質近年、車載システム開発でもアジャイル開発（スクラムなど）の採用が進んでいます。しかし、品質保証（QA）は従来型の方法論に留まり、スプリント外で行われる監査やゲートレビューに偏っているケースが少なくありません。この方法論では、品質リスクが早期に共有されず、リリース直前に重大な問題が発覚することもあります。QAが「最後に合否判定を下す役割」として認識され、開発チームとの距離感が生まれてしまうのです。従来型QAは、品質計画を立て、ゲートレビューや監査で品質基準を満たしているかを確認する役割を担います。これは品質保証の枠組みを維持するために不可欠です。一方、アジャイル開発では短いサイクルで価値を届けることが求められます。その中で、開発と同じリズムで品質を作り込む仕組みが必要です。そこで登場するのが 伴走型QA＝Quality Engineering（QE） です。詳細はこちら→https://www.bgarage.co.jp/news/1522/

トップ新着情報

Contact Us

お問い合わせ

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

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