プロジェクトは「価値」まで管理できているか　ー ISO 56001の視点で考える価値起点のマネジメント ー

日本企業では、毎年多くのプロジェクトが立ち上がっています。基幹システムの刷新、DX推進、新規事業開発、業務改革、組織変革、生成AI活用、サプライチェーン再構築など、そのテーマは多岐にわたります。しかし、これらのプロジェクトの多くは、予定通りに完了したにもかかわらず、経営成果につながらないという問題を抱えています。

• システムは稼働したが、業務効率は大きく変わらなかった
• DXプロジェクトは完了したが、新しい収益は生まれていない
• 新規事業の検討は進んだが、実際の事業化には至らなかった
• 現場は忙しくなったが、顧客価値は高まっていない

このような状況は、決して珍しいものではありません。むしろ、多くの日本企業で繰り返されている構造的な課題です。

その原因は、プロジェクト管理の手法が不足しているからではありません。日本企業は、進捗、予算、課題、品質を非常に丁寧に管理しています。問題は、それらの管理が「価値の実現」に結びついていないことです。

プロジェクトは予定通り終わった。予算も大きく超過しなかった。大きな障害もなく稼働した。にもかかわらず、経営的には成果が乏しい。これは、プロジェクト管理としては成功していても、価値創出としては失敗している状態です。

このような課題を捉え直すには、プロジェクトを「何を作るか」ではなく「どのような価値を実現するか」から設計する視点が必要です。

この視点を取り入れるうえで重要な枠組みとなるのが、ISO 56001です。この規格は、イノベーション・マネジメントシステムの国際規格です。一般には、新規事業開発や研究開発、イノベーション活動のための規格として捉えられがちです。しかし、その本質は、単にアイデアを生み出すことではありません。組織が価値を定義し、その価値を実現するために、戦略、プロセス、資源、意思決定、評価、改善を一貫して運用するためのマネジメントシステムです。

この意味でISO 56001は、プロジェクト管理にも大きな効果を持ちます。なぜなら、プロジェクトとは本来、何らかの価値を実現するための活動だからです。

多くの企業では、プロジェクト開始時に目的が設定されます。たとえば、基幹システム刷新であれば「老朽化したシステムを刷新する」「業務効率を高める」「データ活用を進める」といった目的が掲げられます。DXプロジェクトであれば「デジタル技術を活用して業務を変革する」「顧客接点を強化する」といった言葉が並びます。

しかし、プロジェクトが進むにつれて、当初の目的は徐々に薄れていきます。代わりに前面に出てくるのが、既存業務の維持です。

• この帳票はこれまで通り出せるのか
• この例外処理は残せるのか
• 現場の運用は変えなくて済むのか
• 既存システムと同じ画面にできないか

こうした要望は、現場にとっては極めて自然なものです。現場の担当者にとって最大のリスクは、将来の価値が実現しないことではなく、明日の業務が回らなくなることだからです。そのため、プロジェクトが具体化するほど、議論は価値から業務へ、未来から現状へ、変革から維持へと引き戻されます。

ここで重要なのは、これを現場の抵抗や意識不足として片付けてはいけないということです。これは人間と組織の合理的な反応です。現場は自分たちの業務を守ろうとします。部門は自部門の効率や責任範囲を守ろうとします。管理者は失敗を避けようとします。その結果、プロジェクトは当初掲げた価値創出の目的から離れ、既存業務を安全に置き換える活動へと変質していきます。

多くのプロジェクトには、進捗管理・予算管理・課題管理・スコープ管理があります。しかし、価値管理はほとんど存在しません。

つまり、プロジェクトは「作業」としては管理されていても、「価値」としては管理されていないのです。

この問題が最も顕著に表れるのが、業務システム刷新です。

日本企業の大規模システム刷新では、多くの場合、既存業務を前提に要件定義が進みます。現行システムで行っている処理、帳票、承認ルート、例外対応、部門ごとの独自運用を洗い出し、それを新システムでも再現しようとします。

一見すると、これは丁寧な要件定義に見えます。しかし、ここに大きな落とし穴があります。現行業務の中には、顧客価値を高めている業務もあれば、過去の事情で残っているだけの業務もあります。部門の都合で作られた運用もあれば、誰も使っていない帳票もあります。過去の制約によって生まれた例外処理が、いつの間にか「必要な業務」として扱われていることもあります。

これらを区別せずにすべて新システムへ移植すると、何が起きるでしょうか。新しいシステムの中に、古い業務の複雑さがそのまま持ち込まれます。標準機能では対応できず、カスタマイズが増え、開発コストが膨らみます。テスト項目が増え、移行リスクが高まります。運用開始後も、保守が複雑になります。

結果として、莫大な投資をしたにもかかわらず、実現されるのは「新しいシステム上で動く古い業務」です。これは刷新ではなく、過去の業務構造をデジタル上に保存している状態です。

特に注意すべきなのは、経理や人事などの間接業務と、販売管理や顧客接点に関わる業務を同じ思想で扱ってしまうことです。経理、人事、勤怠、経費精算などは、多くの企業に共通する業務であり、SaaSや標準パッケージを活用する合理性が高い領域です。一方、販売管理、見積、契約、価格設定、納期回答、顧客別対応、アフターサービスなどは、競争力や顧客への価値提供に直結する中核的な仕組みです。

ここを単なる業務処理として捉え、安易に標準化やクラウド移行の対象にしてしまうと、自社の競争力を支える仕組みまで外部の標準に合わせることになります。販売管理とは、単に受注を登録する仕組みではありません。「どの顧客に、どの価値を、どの条件で、どの価格で提供するのか」を決める、企業の価値実現エンジンです。

この認識がないまま「クラウドへ移行する」「SaaSに置き換える」「標準機能に合わせる」といった判断を行うと、短期的には効率化できたように見えても、長期的には差別化の源泉を失うリスクがあります。

ISO 56001の重要な点は、イノベーションを単なる発想や技術導入として捉えていないことです。この規格の中心には「価値の実現」という考え方があります。新しいアイデアを出すことそのものが目的ではなく、そのアイデアや活動を通じて、顧客、社会、組織、関係者にどのような成果や効果をもたらすのかが問われます。

この考え方をプロジェクト管理に適用すると、プロジェクトの出発点が変わります。

従来型のプロジェクトでは、最初に「何を作るか」「どのシステムを導入するか」「どの業務を対象にするか」が議論されがちです。しかし、ISO 56001型のプロジェクトでは、最初に問うべきことは次のようになります。

• このプロジェクトは、誰にどのような価値を提供するのか
• その価値は、経営戦略とどのように結びついているのか
• どの価値を高めるために、どの業務を変えるのか
• 何を残し、何をやめるのか
• このプロジェクトによって、競争優位はどのように強化されるのか

この問いを明確にしないままプロジェクトを始めると、途中で必ず業務起点に戻ります。なぜなら、価値は抽象的ですが、業務は具体的だからです。抽象的な価値が文書化され、判断基準として機能していなければ、具体的な業務要望に押し流されるのは当然です。

したがって、プロジェクト開始時には、いわば「価値憲章」と呼べるものを定義する必要があります。これは、単なる目的文ではありません。プロジェクトが実現すべき事業成果、対象とする顧客や利用者、競争優位への貢献、やめる業務、やらない範囲、価値を測定する指標を明文化したものです。

この価値憲章を経営が承認し、プロジェクト期間中の最上位の判断基準として扱うことが重要です。これにより、途中で発生する業務要望や追加要求に対して、「それは価値実現に貢献するのか」という問いを立てることができます。

プロジェクトを業務起点に戻さないためには、要件定義の方法を変えることが重要です。特に重要なのは、価値要件と業務要件を分けることです。

業務要件とは、業務を遂行するために必要な機能や処理です。承認、入力、検索、出力、連携、帳票、通知などが該当します。一方、価値要件とは、その業務やシステムによって実現すべき成果を示すものです。

たとえば、販売管理システムであれば、単に「見積書を作成できること」は業務要件です。一方、「顧客ごとの購買履歴や契約条件を踏まえ、最適な提案と価格判断を短時間で行えること」は価値要件です。

「受注登録ができること」は業務要件です。一方、「受注情報をもとに需要予測や在庫計画へつなげ、欠品や過剰在庫を減らすこと」は価値要件です。

「問い合わせ履歴を登録できること」は業務要件です。一方、「問い合わせ情報を分析し、顧客満足度の向上やサービス改善につなげること」は価値要件です。

この二つを混同すると、プロジェクトは業務機能の積み上げになります。価値要件を明確にしたうえで業務要件を定義すれば、不要な業務や過剰な機能を削減できます。つまり、要件定義は「現行業務を漏れなく集める作業」ではなく、「事業成果を実現するために必要な業務を選び直す作業」です。

プロジェクトが進むにつれて、変更要求や追加要望は必ず発生します。これは避けられません。重要なのは、それらをどう判断するかです。

従来型のプロジェクトでは、変更要求は主にスケジュール、コスト、技術的実現性で判断されます。しかし、ISO 56001型のプロジェクトでは、それに加えて価値への影響を評価します。

• この変更は、顧客価値を高めるのか
• 競争優位に貢献するのか
• 将来の事業成長につながるのか
• 業務の複雑化に見合う成果があるのか
• 一部の部門都合ではなく、全体最適に寄与するのか

このような評価軸を持つことで、プロジェクトは単なる要望処理の場ではなく、価値を守る意思決定の場になります。

特に日本企業では、「現場から強い要望が出ている」「これまでそうしてきた」「ないと困ると言われている」という理由で要件が追加されることが少なくありません。しかし、それが本当に価値を生むのかは別問題です。事業成果に貢献しない業務要望をすべて受け入れれば、システムは複雑化し、コストは増え、将来の変更にも弱くなります。

プロジェクトに必要なのは、現場の声を退けることではありません。その要望を、価値の観点から再解釈することです。

従来のプロジェクト管理は、QCD、すなわち品質、コスト、納期を中心に設計されてきました。これは今後も重要です。しかし、それだけでは不十分です。なぜなら、QCDを守っても、価値が生まれるとは限らないからです。

これからのプロジェクト管理では、QCDに加えて「価値」を管理対象にすることが求められます。具体的には、

• プロジェクト開始時に価値仮説を定義し、各フェーズでその妥当性を検証する
• 要件定義では、価値要件と業務要件を分離する
• 設計段階では、競争優位性を生む領域と標準化すべき領域を切り分ける
• 開発・導入段階では、顧客への効果に影響する機能を優先する
• 運用開始後は、当初想定した価値が実現されているかを測定し、必要に応じて改善する

この考え方に立つと、プロジェクトのゴールも変わります。システム稼働やリリースはゴールではありません。価値が実現され、事業成果につながることがゴールです。

ISO 56001は、この考え方を組織的に実装するための枠組みです。経営の意図、戦略、価値、プロセス、資源、評価、改善を結びつけることで、プロジェクトを単発の活動ではなく、価値創出の仕組みとして運営できるようにします。

ISO 56001型のプロジェクト運営において、最も重要な役割を担うのは経営層です。なぜなら、価値を定義し、何を優先し、何を捨てるかを決めるのは経営の責任だからです。

日本企業では、プロジェクトが始まると、詳細は現場やIT部門、外部ベンダーに委ねられがちです。しかし、価値の判断まで現場に委ねることは適切ではありません。現場は業務を知っていますが、全社の競争優位や将来の事業構造を決める立場ではありません。IT部門は技術やシステムを知っていますが、企業がどの価値で勝負するのかを決める立場ではありません。

経営層は、プロジェクトのスポンサーであるだけでは不十分です。価値のオーナーである必要があります。

そのためには、プロジェクト開始時だけでなく、途中の重要な意思決定にも関与することが欠かせません。特に、スコープ変更、大規模な追加要望、業務プロセスの見直し、標準化と独自化の切り分けについては、経営成果の観点から判断を行うべきです。

• 「現場が困るから残す」のか
• 「顧客価値を高めるから残す」のか
• 「差別化につながるから独自化する」のか
• 「競争力に関係しないから標準化する」のか

この判断を曖昧にしたままプロジェクトを進めると、最終的には最も声の大きい部門の要望が残り、全体最適が失われます。

ISO 56001の意義は、イノベーション活動を特別な人材や一部部門の活動に閉じ込めず、組織全体のマネジメントシステムとして扱う点にあります。この考え方は、プロジェクト管理にもそのまま当てはまります。

プロジェクトは、本来、経営戦略を実行するための手段です。しかし実際には、プロジェクトが進むにつれて、経営戦略とのつながりが薄れ、現場業務やシステム仕様の議論に埋没していきます。ISO 56001を取り入れることで、プロジェクトを再び経営の仕組みに戻すことができます。

重要なのは、ISO 56001を単なる認証取得のための規格として見るのではなく、価値を中心にプロジェクトを設計・運営するための実践的なフレームワークとして活用することです。

プロジェクト管理にISO 56001を取り入れることで、次の変化が期待できます。

日本企業のプロジェクトに必要なのは、管理を増やすことではありません。管理対象を「作業」から「価値」へ広げることです。

ISO 56001は、プロジェクト管理に対して新しい視点を提供します。それは、プロジェクトを「作業を完了させる活動」ではなく、「価値を実現する活動」として再定義する視点です。

業務システム刷新、DX、新規事業、業務改革、組織変革。どのようなプロジェクトであっても、問うべきことは同じです。

• このプロジェクトは、誰にどのような価値をもたらすのか
• その価値は、企業の戦略や競争優位とどう結びつくのか
• その価値を実現するために、どの業務を変え、どの業務をやめるのか
• そして、その価値は本当に実現されたのか

この問いをプロジェクトの中心に置いたとき、ISO 56001は単なるイノベーション規格ではなく、経営成果を生み出すためのプロジェクト管理の基盤になります。

これからの企業に求められるのは、プロジェクトを予定通り終わらせる力だけではありません。
プロジェクトを通じて価値を生み出し、事業を進化させる力です。

ISO 56001は、そのための実践的な指針となり得ます。