Updates

新着情報

コラム

同じ失敗を繰り返さないプロジェクト管理 ─ 再発防止の実践ポイント

■なぜ、あの失敗は何度も起きるのか?開発プロジェクトの合間に、こんな会話を耳にすることがあります。「この前も同じような問題があったよね?」「気を付けていたつもりだったけれど…また再発してしまった」こうした状況は決して珍しくありません。多くの開発現場では、重大な問題が発生した際に「過去にも似た状況があった」と振り返るケースが少なくないと言われています。もちろん、プロジェクトで起きる問題の形や影響はさまざまで、個別の技術的課題や外的要因によるトラブルも存在します。それでもなお、現場を振り返ると、同じような状況や判断の迷いが重なった結果として問題が再発しているケースが見受けられます。では、なぜ似たような失敗は繰り返されてしまうのでしょうか。 ■同じ失敗が起きる主な要因とは?ある車載ECU開発プロジェクトでの出来事です。当初のプロジェクトの目的は「画面表示の起動時間を短縮する」ことでした。ところが開発途中で、「起動時にロゴアニメーションを入れたい」「警告メッセージの表示仕様も変更したい」「診断ログも取得できるようにしてほしい」といった要望が追加され、チームは「せっかくなら対応しよう」と順次取り込みました。しかし、誰も「起動時間短縮が最優先なのか、それとも新機能追加なのか」を明確に整理しないまま進めたため、「あるメンバーは表示品質を優先」「別のメンバーは起動速度を優先」「別の担当は診断要件の網羅性を重視」と、目指すゴールが少しずつズレた状態で開発が進んでしまいました。その結果、統合テストの段階で「起動時間が目標を満たさない」「ログ取得時に表示が遅延する」といった問題が同時に発覚し、大きな手戻りが発生しました。さらに、スケジュール遅延の兆候は早い段階で見えていたにもかかわらず、「どの時点で誰に相談するか」「何を優先的に削るか」が決まっていなかったため、対応は常に後手に回りました。このような問題は以前にも何回か起きていたようです。 同じ失敗が繰り返される背景には、・目的と優先順位が共有されていない・問題発生時の動き方が決まっていないといった構造的な要因が背景にあるケースは少なくありません。目的が揃わないまま進めると、メンバーごとに判断基準がばらつき、問題が起きても対応の優先度や対処方針が統一されません。さらに、初動対応やエスカレーションのルールが明確でない場合、対応は場当たり的となり、問題の影響が拡大しやすくなります。その結果、納期や目先の対応を優先した暫定対処で収束させてしまい、根本原因が解消されないまま次のプロジェクトへ持ち越されます。そして同様の条件が重なったとき、類似したトラブルが再び発生する可能性が高まります。 ■成功するプロジェクトが共通して実践している取り組み前述の例のように、失敗の原因は個人の注意不足だけでなく、目的の共有不足や優先順位の不明確さ、問題発生時の対応ルールの欠如といった“進め方の仕組み”に起因しています。では、同じ状況に直面しても手戻りを最小限に抑え、着実に成果を出し続けるチームは、どのような工夫をしているのでしょうか。私の経験を基に、実際に効果のあった取り組みの一例をご紹介します。 1. 要求分析と優先順位決定プロセスを機能させる要求が増え続けること自体は珍しいことではありません。問題は、優先順位を判断する基準や変更時の意思決定プロセスが明確でない場合、チーム内で判断軸がばらつくことです。成功している組織では、 最優先事項を判断する基準を定める 要求変更時に影響範囲(品質・性能・日程)を確認する 優先順位を見直す意思決定ルールを設けるといった仕組みによって、要求分析プロセスが機能する状態を維持しています。例えば、変更要求が出た際に「最優先目標に影響しないか」を確認するチェック項目を設けるだけでも、判断のばらつきを抑えることができます。 2. 問題の早期解決を支える支援・エスカレーションの仕組みプロジェクトは計画通りに進まない状況が発生することを前提に運営する必要があります。重要なのは、問題が顕在化した際に 誰が・どの段階で・どこへ相談するのか が明確になっていることです。とある組織では、進捗管理・課題管理・リスク管理といった基本的なプロジェクト管理プロセスは整備されています。そのうえで、現場だけでは判断が難しい状況に備え、経験豊富なPMや技術リーダーが横断的に支援する仕組みを設けています。現場ではこれを通称「駆け込み寺」と呼んでいます。この仕組みの目的は属人的な助言ではなく、 進捗遅延や品質リスクの早期検知 判断に迷う局面での意思決定支援 問題対応の優先順位整理 組織としての対応方針の統一といった、プロジェクト運営プロセスを補完・強化することにあります。このような支援体制は大掛かりな組織でなくても導入可能です。例えば、 PM経験者が週1回相談枠を設ける リスク顕在化時の相談ルートを明文化する 重要課題をレビューする横断ミーティングを設けるといった小さな仕組みから始めることもできます。 3. 振り返りを“教訓化”につなげる仕組み振り返りの重要性は多くの現場で理解されています。しかし実際には、「事実の整理で終わってしまう」「個人の反省に留まる」「次のプロジェクトに活かされない」といったケースが少なくありません。効果的な振り返りを行う組織では、 結果の整理 原因の特定 再発防止策の決定 次回の実行ルールへの反映をセットで行います。例えば、再発防止策をチェックリストや標準手順に反映し、次プロジェクト開始時に確認する仕組みを設けることで、経験を組織の資産として蓄積できます。 ■あなたのチームでは、同じ兆候が起きていませんか?失敗の再発は偶然ではなく、進め方の仕組みに起因することが少なくありません。そして、その仕組みを整えることで、同じ問題が繰り返される可能性は大きく減らすことができます。ここまでお読みいただき、「自分たちの現場にも当てはまる」と感じられた方も多いのではないでしょうか。例えば、次のような兆候は見られませんか?☑ チーム内の意思疎通に不安がある☑ 課題が何度も再発し、改善が定着しない☑ プロジェクト管理が“実態と合っていない”と感じる☑ 組織としてのプロセスを整えたいが、どこから手を付けるべきかわからないもし一つでも思い当たる点があれば、それは個人の努力ではなく、仕組みを整えることで改善できる余地があるというサインかもしれません。 「自社ならどこから手を付けるのが最短か」を整理したい場合は、1~2週間のクイック診断からご支援することも可能です。小さく始めて、現場に無理なく定着させる改善をご一緒に進めていきます。まずは、現状の困りごとや課題をお聞かせいただくだけでも構いません。 ご相談・お問い合わせはこちらから→https://www.bgarage.co.jp/contact/ (長澤克仁)

コラム

構成管理の基本の「き」 ~当たり前なことが難しい~

はじめに システム開発/ソフトウェア開発の現場では、日々多くの変更が行われています。機能追加、バグ修正、設計変更。。。そのすべてがソースコードやドキュメントに影響を与えます。この変化の連続を“管理された状態”に保つための仕組みこそが 構成管理(CM) です。今回は、Automotive SPICEのプロセスの1つである、SUP.8:構成管理の基本について、IEEEなどの国際標準も交えて解説します。 なぜ構成管理が必要なのか 構成管理がうまく機能していない現場では、こんな光景がよく見られます。 “誰が”“いつ”“どこを”“なぜ”変更したのか追跡できない 昨日の動くバージョンに戻したいのに、戻せない ドキュメントと実物が噛み合わず、レビューで混乱 変更したつもりが、別の人の作業で上書きされていたこれらはすべて、生産性と品質を静かにむしばむ“構成管理不足”のサインです。構成管理の目的は一言でいえば、変更の見える化と安定した開発の継続です。 構成管理の主要な4つの活動 1.構成識別(Configuration Identification)まず管理対象となる作業成果物を明確にします。この管理対象を構成品目(Configuration Item:CI)と呼びます。ソースコードはもちろん、設計書、テスト仕様書、ビルド手順書など、作業成果物すべてが対象となり得ます。どこまでを管理するのか最初に決めておくことが、とても重要です。Automotive SPICE v4.0では以下のように解説しています。 構成品目とは、単一の実体として構成管理の対象となる作業成果物または作業成果物一式を指す。 構成品目は、システム、ハードウェア、およびソフトウェアのすべての文書を含むシステム全体から、単一のエレメントまたは文書に至るまで、複雑性、規模、および種類が異なる場合がある。  選定基準は、単一の作業成果物または作業成果物一式に適用してよい。また国際標準である、IEEE 828「IEEE Standard for Configuration Management in Systems and Software Engineering」では、以下のように定義しています。 構成管理のために指定され、構成管理プロセスにおいて単一のエンティティとして扱われる作業成果物の集合体。 構成品目は、その複雑さ、規模、種類が多岐にわたる場合があり、ハードウェア、ソフトウェア、ドキュメントをすべて含むシステム全体から、単一のモジュールやマイナーなハードウェアコンポーネントまで多岐にわたる。プロジェクトの範囲や、標準資産の再利用の考慮等によって、構成品目は様々ですが、必ずしも「1ファイル=1構成品目」である必要がないことは上記からも理解できると思います。「単一の実態として扱われる作業成果物の集合体」が構成品目となります。 2. 構成制御(Configuration Control)構成管理の根幹となる活動は、変更手続きを管理し、変更を追跡することで、製品の構成が常に正確に把握されるようにすることです。構成制御は、ベースラインを完全に識別し、そのベースラインに対して行われたすべての変更を追跡することによって実現されます。Automotive SPICEではベースラインを以下のように定義しています。 1つまたは一連の作業成果物および生成物の一貫性が保たれ、かつ完成した状態であることを識別している。 次のプロセス段階および/または納入のためのベース。 一意であり、変更されてはならない。少しわかりづらいので、再びIEEE 828を参照してみましょう。以下のように定義しています。 正式にレビューされ合意された仕様または製品であり、その後は以降の開発の基礎となり、正式な手順を通じてのみ変更可能である。  媒体を問わず、構成アイテムのライフサイクル中の特定の時点で正式に指定及び確定された、構成アイテムの正式に承認されたバージョンである。 ソフトウェアベースラインとは、ソフトウェアライフサイクル中の特定の時点で正式に指定され、確定されたソフトウェア構成アイテムの集合(1つまたは複数)である。開発ライフサイクルのある時点(たとえば、要件が確定した時点や統合テストを始める時点)で、正式の合意された製品目一式がベースラインであり、以降の開発工程や納入の基となるものです。好き勝手に変更していけないのがベースラインであり、適切にベースライン(構成品目の集合体)を作成&更新していくことが構成管理の根幹となります。この適切な作成&更新を行うためには、正式な変更手順だけではなく、構成品目を格納する「ライブラリ」も重要となります。皆さんの中には既に、作業成果物の格納場所として、Git や Subversion などのツールを利用している方もいると思いますが、国際標準であるIEEE 1042「IEEE Guide to Software Configuration Management」で述べているライブラリの概念が基本となっています。   ダイナミックライブラリ(プログラマーズライブラリとも呼ばれる): 新規作成または変更されたソフトウェアエンティティ(ユニット/モジュール、データファイル、および関連ドキュメント)を格納するために使用されるライブラリ。 これは、作業担当者がコード開発で使用するライブラリで、そのユニットを担当する作業者は、いつでも自由にアクセスできます。 これは作業者の作業スペースであり、作業者によって管理される。 管理ライブラリ(マスターライブラリと呼ばれる): 現在のベースラインを管理し、それらに加えられた変更を制御するために使用されるライブラリ。 これは、統合のために生成された構成品目のユニットとコンポーネントが保持されるライブラリ。 通常は検証後にエントリが認められる。 作業者やその他のユーザーが使用するために、コピーを作成できるが、このライブラリ内のユニットまたはコンポーネントへの変更は、責任部署(構成制御委員会または委任された権限を持つ機関)の承認が必要。 スタティックライブラリ(ソフトウェアリポジトリと呼ばれる): 一般利用のためにリリースされた様々なベースラインをアーカイブするために使用されるライブラリ。 これは、運用のためにリリースされた構成品目一式のマスターコピーが保管されるライブラリ。 これらのマスターのコピーは、要求する組織に提供される場合がある。 3. 構成ステータス記録(Status Accounting)構成管理下にある構成品目(作業成果物)に関する重要な情報を記録し、管理者と作業者に報告し、「構成品目が今現在どんな状態か」を共有することが、この活動の目的となります。IEEE 828では、構成品目のステータス情報は、以下のことに役立つと述べています。 ある期間における、プロジェクト作業の結果を把握し、とある時点での完了見込みを把握する。 例:要件の数と実装済みの数を比較することで、これまでの進捗状況を把握できる。  開発中の製品の安定性と機能の完成度に関する状態を把握する。 例:機能またはコンポーネントに対して、実装済みおよび保留中の変更の数は、安定性または変動性を示している。 構成品目の管理(構成管理活動自体)を検証する。 必要に応じて、外部コンプライアンス監査の要件(例:SOXなど)を満たす。「構成ステータス記録」は、構成管理活動自体を監視するプロジェクト管理機能でなく、あくまで構成品目(作業成果物)の状態を監視するものであることも理解しておく必要があります。 4. 構成監査(Configuration Audit)「管理されているはずの状態」が、本当に実態と一致しているかを確認する仕組みです。 ドキュメントの記載と成果物が一致しているか 承認フローが守られているか リリース物は正しい構成か監査は厳しいものではなく、「間違いが積み重なる前の安全装置」というイメージです。 構成管理はツールではなく「文化」Git や GitHub、Azure DevOps、Subversion などのツールは SCM を支える重要な存在ですが、ツールを導入しただけでは構成管理ができたとは言えません。大切なのは、そのツールを使って一貫したルールとプロセスを回し続ける文化があるかどうかです。例えば: ブランチ戦略をチームで統一する コードレビューをルール化する 変更理由を残す習慣をつける リリース手順を標準化するといった取り組みが、SCMの“文化”を育てます。 さいごに構成管理は、「開発を安定させるための基盤であり地盤」です。目立たない活動ですが、これがしっかりしているチームはトラブルに強く、改善サイクルも回しやすくなります。地盤が安定していれば、どんな大きな建物(=プロジェクト)でも安心して積み上げることができます。  内山哲三 

コラム

プロセス改善コンサルティング、成功と失敗の分かれ道

Automotive SPICEやCMMIに準拠したプロセス改善を積極的に取り組む設計現場が広がってきている反面、改善の必要性を感じながらも、「本当にコンサルを入れるべきなのか」「また期待外れに終わってしまうのではないか」そんな迷いを抱えていらっしゃる方も多いのではないでしょうか。実際、私たちがこれまでご相談を受けてきた中でも、次のようなお声を耳にしてきました。「過去にコンサルを入れたが、やることだけが増えて楽にならなかった…」「立派な資料は残ったが、現場のやり方は結局変わらなかった…」「コンサルに頼ると、自分たちの力が育たない気がする…」これらは、決して珍しい意見ではありません。そして同時に、「コンサルティングサービスがうまく機能しなかった典型例」でもあります。■見過ごされている2つの「ズレ」プロセス改善コンサルティングが失敗する背景には、主に以下のようなズレが潜んでいます。 ズレその1:目的の不一致「レベル認証を取れればいい」のか、「自律的な改善ができる組織にしたい」のか——この目的が、依頼部門と開発現場で共有されていないケースが非常に多いのです。依頼部門:「認証取得をきっかけに、組織を変えていきたい」開発現場:「とにかく早く認証を取って、元の業務に戻りたい」こうした認識のズレがあると、現場の協力が得られず、形だけのプロセスで終わってしまいます。 ズレその2:アプローチの不一致コンサルティングには、大きく分けて2つのアプローチがあります。【代行型】改善作業を代行し、短期間で認証取得を目指す【伴走型】課題や施策を現場と一緒に整理しながら進め、組織にノウハウを残すどちらが優れているということはありません。問題は、目的に合わないアプローチを選んでしまうこと、そしてこの選択を曖昧にしたままプロジェクトを始めてしまうことです。 失敗の本質は、「誰が悪い」という話ではありません。目的や期待を関係者間ですり合わせる——このステップが抜け落ちたままプロジェクトが始まってしまうことにあるのです。 ■「ズレ」を解消したことで現場が変わった事例では、これらのズレを解消すると、現場はどう変わるのでしょうか。実際の事例をご紹介します。 【依頼時の状況】ある設計現場からご相談をいただいた際、次のような課題を抱えていらっしゃいました。・問題は発生してから初めて共有される・進捗会議では「今どうなっているか」の報告に終始する・遅延や手戻りの原因が、毎回「想定外」「人手不足」で片付けられる・設計者からは「レビュー準備だけで工数を取られる」「成果物のトレーサビリティ維持が負担」という声が出ていた過去にもコンサルを入れたことがあったそうですが、「立派な資料は残ったが、現場のやり方は結局変わらなかった」とのことでした。 【目的の共有】まず私たちが行ったのは、依頼部門と開発現場の責任者の方々と、次の点を時間をかけて対話することでした。「今回の目的は、認証取得だけですか? それとも組織を変えることですか?」結果、「認証取得はあくまで通過点で、現場が自律的に改善を続けられる力をつけたい」という明確な目的を、全員で共有できました。加えて、今回のコンサルの期待として、「なぜこのプロセスが必要なのかという考え方を現場に残してほしい」、「プロジェクトが終わった後も、自分たちで改善を続けられるようにしたい」という期待があることも共有することができました。 【アプローチの選択】目的と期待が明確になったことで、私たちは伴走型コンサルティングを提案し、具体的な進め方について合意しました。・プロセス文書は一緒に作る(現場の実態を反映させる)・「やらされ感」ではなく、「なぜ必要か」を理解しながら進める・ノウハウを組織に残すことを最優先する 【結果】プロジェクトでは、解決策の提示だけでなく、「どのタイミングで、どんな兆候が出ていたのか」「本来、どこで意思決定すべきだったのか」などを、現場の方と一緒に整理しました。その上で、・進捗とリスクを一目で把握できる形に整理し・「問題が起きてから」ではなく「起きる前に気づく」視点を共有し・これまで個人の経験に頼っていた判断を、プロセスとして定義していきました。すると、同じメンバー・同じ工数でも、現場からは「次に何を確認すべきかが分かるようになった」、「認証取得後も、このやり方を続けていけそうだ」といった声が出るようになりました。その結果、手戻りによる追加工数が約3割削減され、プロジェクトの予測精度も向上しました。このような伴走型の支援にご興味がある方、または「自社の状況ではどのアプローチが適しているか知りたい」という方は、ぜひお気軽にお問い合わせください。 ■まずは2つの問いから始めてみましょうコンサルを活用することは、決して自分たちの力を否定することではありません。重要なのは、「何のために」「何を期待して」コンサルを入れるのかを明確にすることです。まず、この2つの問いについて考えてみてください。 問1:皆様の目的は何ですか?まずは認証を取得することが最優先ですか?それとも認証取得をきっかけに、組織を変えていきたいと考えていますか? 問2:コンサル後の姿をイメージできていますか?認証が取れたら終わりですか?その後も自分たちで改善を続けたいですか? もし1つでも不明確な答えがあれば、まずはその整理からご一緒させてください。私たちは、いきなり解決策を押し付けることはいたしません。認証取得の目的は何か、社内の関係者間でその目的は共有されているか、どのようなアプローチ(代行型/伴走型)が適しているか——これらを一緒に考えるところから始めます。目的が明確になれば、コンサルティングサービスは確実に組織の未来を変える力になります。 ▼プロセス改善コンサルティングに関するお問い合わせはこちら(ご相談ベースでも構いません)https://www.bgarage.co.jp/contact/ (長澤克仁)

コラム

なぜ品質要件の問題はテスト段階で表面化するのか ― 品質要件(非機能要件)の考え方と定義方法 ―

1.品質要件の問題は、なぜ見過ごされたまま進むのか組込み・車載ソフトウェア開発では、設計やテストの終盤になってから、 応答時間が間に合わない 負荷が高すぎて処理が破綻する 安全・セキュリティ要求が弱い 必要なログがなく原因が追えないといった問題が表面化することが少なくありません。実務を見ていると、その背景には大きく 2つのパターンがあります。パターンA:そもそも「ここで品質要件が必要だ」と気づけていない機能要求や仕様は要求仕様書に書かれている一方で、 応答時間は? 負荷条件は? 異常時の振る舞いは? ログや診断は?といった品質の話題がほとんど議論されないまま進んでしまうケースです。これは品質要件を後回しにしたのではなく、「ここで考える必要があることに気づけなかった」状態です。パターンB:品質要件は「あるが、疑われていない」過去プロジェクトの品質要求流用や顧客提示の品質要求が、妥当性確認なしにそのまま使われているケースです。その結果、 今回の製品構成でも成り立つのか 対象機能や性能レベルに合っているのか 環境・負荷条件は変わっていないかといった確認がされないまま進み、やはりテスト段階で破綻します。品質要件の問題は、このように「書かなかった」からではなく、「気づけなかった/疑われなかった」ことによって起きているケースが多いと考えます。2.品質要件とは何か?定義の基本的な考え方品質要件(非機能要件)とは、製品・システムがどのレベルで振る舞うべきかを定める要求です。機能要件が「何をするか」を定めるのに対し、品質要件は、 どの性能で どの信頼性で どの安全性で どの容易さで動作すべきかを規定します。問題は、「重要だと分かっていても、どこまで決めれば十分か」が曖昧なまま進んでしまう点にあります。3.品質要件を具体化するための最小チェック(4点)実務で効果が高いのが、次の 4点チェックです。 品質特性を選ぶ性能/信頼性/安全性/保守性/セキュリティ など 観点に分解する例:性能 ⇒ 応答時間、CPU負荷、メモリ 数値化する(測定可能にする)例:応答時間 50ms以内 条件を明記する例:モード、温度範囲、車速、通信負荷などの前提条件この4点を通すだけで、曖昧さ由来の手戻りは大幅に減らせます。4.それでも問題が残る理由―「4点チェック」だけでは足りない4点チェックは、「何を書くか」を整える道具です。しかし実務では、それだけでは防げない問題があります。理由は明確で、「それを書くべきか」「それで妥当か」を問えていないからです。そこで重要になるのが、次の問いです。「この品質要件は、今回の製品・機能・構成でも成り立つか?」 そもそも、ここで品質要件を考える必要はないか 既存の品質要件は、今回も意味を持つか 顧客要求は、システム特性や環境に合っているかこの問いを4点チェックの前に挟むだけで、 気づけなかった品質要件 疑われなかった品質要件の多くが表に出てきます。5.まとめ:品質要件定義を要件分析プロセスにどう組み込むか品質要件の問題は、後工程で突然起きるわけではありません。 必要な場面に気づけなかった 既存の要求を疑わなかったその結果として、テスト段階で表面化します。実務で意識したいのは、次の3点です。 ここで品質要件が必要か?と立ち止まる その品質要件は今回も成り立つか?と疑う 定義するときは、4点チェックで具体化するこれだけで、品質要件の問題はテスト段階で初めて表面化するものではなく、上流での「問いの立て方」によって防げる問題になります。要件分析プロセスでどこに組み込むかここまで述べてきた問いとチェックは、特別な工程を追加するものではありません。実務では、要件分析プロセスの中で次のように位置付けることで、無理なく組み込むことができます。要件抽出・整理の段階「ここで品質要件が必要か?」と立ち止まる要求仕様の具体化段階既存の品質要件や流用要求に対して、「今回の製品・構成でも成り立つか?」を確認する要求記述・レビュー段階妥当と判断した品質要件を、4点チェックで具体化・数値化する この流れを要件分析プロセスの中に組み込むことで、品質要件の問題をテスト段階で初めて発見する、という状況を減らすことができます。品質要件を含めた要求文書の整理や書き方に関するお悩みがあれば、実務に直結する形でのご支援も可能です。お気軽にご相談ください。(安部宏典)

コラム

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/ (長澤 克仁)

コラム

車載システム開発における品質保証の進化──伴走型QAと現場で作り込む品質

車載システム開発におけるアジャイル普及と品質保証の現状近年、車載システム開発でもアジャイル開発(スクラムなど)の採用が進んでいます。しかし、品質保証(QA)は従来型の方法論に留まり、スプリント外で行われる監査やゲートレビューに偏っているケースが少なくありません。この方法論では、品質リスクが早期に共有されず、リリース直前に重大な問題が発覚することもあります。QAが「最後に合否判定を下す役割」として認識され、開発チームとの距離感が生まれてしまうのです。 品質保証の役割とアジャイル開発への適応従来型QAは、品質計画を立て、ゲートレビューや監査で品質基準を満たしているかを確認する役割を担います。これは品質保証の枠組みを維持するために不可欠です。一方、アジャイル開発では短いサイクルで価値を届けることが求められます。その中で、開発と同じリズムで品質を作り込む仕組みが必要です。そこで登場するのが 伴走型QA=Quality Engineering(QE) です。QEは、品質保証担当が担う場合もあれば、開発チーム内に専任を置く場合もあります。いずれの場合も、品質を「後から判定する」ではなく「一緒に作り込む」ことを目指します。QEはスプリントの長さに依存せず、例えば2週間のスプリントでも、計画・レビュー・分析をスプリント内で回すことが可能です。一部の事例では、イテレーション内の最終スプリントを品質保証活動に充てる方法もありますが、QEは全スプリントで品質を作り込む点が特徴です。 車載システム開発の現場で報告されている事例:QE導入による品質保証強化車載システム開発の現場では、QEを導入することで、従来型QAの仕組みがより効果的に機能した事例が報告されています。例えば、ある車載ソフトウェア開発チームの取り組みとして、次のような事例があります: スプリント計画時に品質リスクを洗い出し、優先度を設定し、チーム全体で共有→ リスクを早期に共有することで、対応漏れや後工程での不具合発生を防止 Doneの定義を明確化し、品質基準をチームで共有→ 品質基準の認識ズレが減り、レビュー指摘や手戻りが大幅に減少 スプリントごとに品質指標を振り返り、改善策を次スプリントに反映→ 継続的な改善により、品質課題を早期に解消報告によると、リリース前の重大不具合は半年で約50%削減され、品質リスクが早期に共有されることで手戻り工数も大幅に減少したとされています。この報告は、QAの枠組みとQEの現場適応が組み合わさることで品質保証が進化する可能性を示しています。 QAとQEの役割分担 QA(Quality Assurance)品質計画、ゲートレビュー、監査 → 品質保証の枠組みを維持 QE(Quality Engineering)スプリント内で品質リスク管理、Done定義、品質指標改善 → 品質を現場で作り込む両者は競合するものではなく、補完関係にある「両輪」です。 QEの具体的な関わり方 Doneの定義やチェックポイントの整理「何をもって完了とするか」を明確化し、品質基準をチームで共有 品質リスクの見える化と共有スプリント計画時にリスクを洗い出し、優先度を設定 技術レビューへの参加設計レビューやコードレビューに参加し、品質観点で議論をサポート レビュー指摘の分析スプリント内で発生したレビュー指摘(不具合や改善点)を記録・分析し、品質改善に活用 テスト結果の分析スプリント内で検出された不具合を分類・傾向分析し、次スプリントの品質戦略に反映 リリース判断のための品質情報提供「どこに懸念が残っているか」を可視化し、リリース可否判断に必要な情報を提供 スプリントの振り返りで品質状況を確認し、改善策を次に活かす不具合件数やレビュー結果などを確認し、改善策を次スプリントに反映まとめ品質保証は、もはや「最後に判定する役割」だけではありません。QAが品質保証の枠組みを維持し、QEが現場で品質を作り込む──この両輪で、品質保証はアジャイル時代に適応します。当社では、こうした取り組みを実現するために、品質リスクの見える化やスプリント内レビューの仕組みづくり、品質指標の設計といった仕組みづくりの お手伝い に加え、実際のQE活動における現場サポート(レビュー参加、品質データ分析、改善提案など)も ご支援できます。「QEをどう立ち上げ、QAと連携させるべきか?」とお悩みの方は、ぜひご相談ください。品質保証を進化させる第一歩は、開発とQA/QEが同じゴールを見て走ることです。(安部宏典)