メルマガ登録
執行役員 ソリューションユニット副統括の紺谷幸弘です。
3編に渡りお届けした、「データサイエンティストの強みをどのようにビジネス価値につなげていくか~キーワードは「2つの実コウ性」~」では、DXを推進する上で、ビジネス価値の高いプロジェクト成果物を得るためにデータサイエンティストの協力を仰いだり、データサイエンティストのマネジメントをしている方に向け、データサイエンティストのモチベーションやキャリア構築を考えるヒントの提供を目指しました。
その中で、データサイエンティストのキャリアを論じるにあたり、高難度化しやすい「大規模/複合型プロジェクト」を簡単にご説明しましたが、この特別編では、前後編の2部構成にて大規模・複合型プロジェクトが難しい3つの理由について、より踏み込んで論じたいと思います。
前編では、「大規模/複合型プロジェクト」が高難度化する第1の要因である「PoCフェイズにおける2つの不確実性」についてお話します。
「【後編】データサイエンティストの強みをどのようにビジネス価値につなげていくか~キーワードは「2つの実コウ性」~」の内容の繰り返しになってしまいますが、本稿では、「大規模プロジェクト」を、「プロジェクトの成果物(ソリューション)の検証や実装に加え、利用・運用に関与する部署やレイヤー、人数が多岐に渡るプロジェクト」を指すものとして論を進めたいと思います。典型的なものとしては特定課題に対する機械学習システム実装や運用が成果物となるようなプロジェクトが挙げられるでしょう。
次に複合型プロジェクトですが、「階層構造や並列構造にあるプロジェクトが折り重なり、全体でひとつのプロジェクトを構成している」ようなものを想定しています。
一例として下図のような構成を示します。
大規模/複合型プロジェクトはいずれも、その解消に臨もうとすると関連部署が多岐に渡るような「壮大な課題」の解消を目的としたプロジェクトであることが多く、プロジェクト内の課題選定フェイズにて、ゴールに貢献すると思われる課題を設定し、その目的達成のためにより具体化された課題の解消を目的とした複数の子プロジェクトにより構成されるようなケースがよく見受けられるという点も別記事「【後編】データサイエンティストの強みをどのようにビジネス価値につなげていくか~キーワードは「2つの実コウ性」」でお話した通りです。
以降、「【後編】データサイエンティストの強みをどのようにビジネス価値につなげていくか~キーワードは「2つの実コウ性」~」で取り扱ったサンプルプロジェクトを用いてお話できればと思います。
上の記事で触れたサンプルプロジェクトの概要は以下のようなものでした:
問題解消に向けたプロジェクト群の一例として、以下のようなものが考えられます。
※ なお、下表は上記のプロジェクト群を高い具体性を持ってイメージしていただくためのものであり、実際のプロジェクト群の組成は個々の状況に応じて行われるものであることから、実態に即していない可能性がある点にご留意ください。
本題に入りましょう。大規模・複合型プロジェクトはなぜ難しいのでしょうか?
考え方や評価の軸として様々に考えられると思いますが、本稿執筆時点の著者の周囲の例に基づきお話させていただくならば、以下の3つの要因の影響が大きいと考えています:
実は、上記の1.と3.は、大規模・複合型プロジェクトに限らず、小規模な分析プロジェクトにも含まれる要素です。大規模・複合型プロジェクトの場合、上記の要素がプロジェクトの進行上、甚大な影響を及ぼしやすいというのが重要な違いであると著者考えています。
本稿では、上記の3つの要因のうち、第1の要因である「PoCフェイズにおける2つの不確実性」についてお話したいと思います。
大規模・複合型プロジェクトを高難度化させる第1の要因は、「PoCフェイズにおける不確実性」です。
この要因は小規模の分析プロジェクトにおいても同様に存在するものですが、大規模・複合型プロジェクトでは、PoCフェイズやプロジェクト全体に対する影響が甚大になる点で大きく異なると筆者は考えています。
詳しくは「【中編】データサイエンティストの強みをどのようにビジネス価値につなげていくか~キーワードは「2つの実コウ性」~」で述べていますが、PoCフェイズではプロジェクトの成果物(ソリューション)のコンセプト、すなわち、プロジェクトの目的を達成するためのアプローチについて、主に「実効性(有用性、有効性): ビジネスの現場で実行・運用されたときに効果がある(と期待できる)こと」の観点から検証を行います。その過程において、大小の差はあれ、多くの場合、下図のようにコンセプトの再設計と検証の試行錯誤のプロセスが含まれます。
皆さんにイメージを掴んでいただくために、上述のサンプルプロジェクトの子プロジェクトB「在庫適正化を実現する製造計画ロジック策定プロジェクト」を例に、上の図のプロセスを紹介したいと思います。
子プロジェクトBの目的は「必要な期間分の将来の需要・在庫収容力・生産能力などを踏まえた製造計画策定体制の構築・運用の実現・維持」でした。そこで、最初のコンセプト(1次コンセプト)として「将来需要分などを踏まえた製造計画策定ロジックおよびその運用体制の構築」とし、まず、「製造前の各製品の需要予測」と、そこに生産・在庫管理能力を加えた3つの要素を制約条件とする「製造計画の最適化」の実現可能性について検証することにしました。
ところが、様々なアプローチを試してみたものの、「製造前の需要予測」の精度を実務上必要な水準まで高めることが難しいことが分かりました。どうやら最初のコンセプトを実現するのは難しそうです。
そこで改めて製造プロセスを見直してみたところ、以下のことが分かりました:
上記の事実から、2次加工品を十分な量「作り置き」しておいて、欠品リスクの高いもののアラートを上げることでも欠品・納期遅延を防ぐことが実現できる可能性があります。そこで、「各製品の欠品・納期遅延アラーティングロジック」によって親プロジェクトの目的を達成することにしました。これが2次コンセプトとなります。検証の結果、子プロジェクトBの目的も含めた更新となっている点も重要なポイントです。
上記の図に対応付ければ以下のようにまとめられるでしょう。
PoCフェイズについて理解を深めていただいたところで再度、PoCフェイズに関する不確実性に話を戻しましょう。PoCフェイズの中で行われるコンセプトの検証・再設計のプロセスには、大きく以下の2つの不確実性が存在します。
こちらの不確実性については、そもそもPoCフェイズの目的が実効性の検証であることから自明と言えますが、大規模・複合型プロジェクト、特にビジネス実務の担当部署が複数にまたがっていたり、規模が大きい場合に特有の問題があります。それは、PoCフェイズのリード担当部署がプロジェクトを進めようとする際、現実的に、実行面の制約の実態の把握・理解が逐次的にならざるを得ないという点です。実際、最終的に採用されるかどうか不明なコンセプトを設計するために、事前に関連する実務全ての内容を理解・把握する進め方は費用対効果の観点から選択しにくいでしょう。
この問題が深刻なのは、PoCフェイズが進むにつれて期待される実効性の程度が逓減する可能性が高いからです。この「期待実効性の逓減してしまう」という事象は、コンセプトを実現するアプローチを設計するにあたり、実務の理解が深まるにつれて実行面から受ける制約が緩和されるよりむしろ、厳しくなる方が多いことに起因しています。
以上のように、コンセプトの実効性の水準の不確実性は、「検証してみるまで分からない」という本来の意味での不確実性と、「実行面の制約の実態が事前の想定以上に厳しく、期待実効性が当初より逓減する」という2つの要因が大きな懸念要因となります。
こちらの不確実性は少し分かりにくいかも知れません。
これは、上の図に表しているように、コンセプト設計と実装・検証の試行錯誤のプロセスを経た結果、最終的に有望なコンセプトとしてどんなものが残るかを事前に把握できないという不確実性です。上記のサンプルプロジェクトの例で言えば、PoCフェイズの開始時に2次コンセプトの内容を把握することが出来ないということです。
「(1)検証対象となるコンセプトの実効性の水準の不確実性」が顕在化しない、例えば検証の結果、当初のコンセプトにおいて十分な水準の実効性が見込める場合や、事前に想定される範囲でしかコンセプトを変更しない(必然的に撤退条件も厳密に決まることになります)という前提であれば、この不確実性が顕在化する可能性は低いでしょう。
この不確実性が悩ましいのは、コンセプトをブラッシュアップしていくプロセスにおいて、当初想定されていた実行上の制約の範囲(業務プロセスや利用設備、利用可能なデータソースや利用可能になるタイミングなどの実行を考える場合に重要な制約)を逸脱する可能性があり、これがプロジェクトの進行・成功可否に大きく影響するためです。
上記のサンプルプロジェクトの例で言えば、当初のコンセプトにおける実行面への影響は
の2つに留まっていたのに対し、2次コンセプトでは以下のように範囲が変わっています:
最終的に、アラーティングシステムをビジネス上に実装・運用しようとすると、上記の対応を行わなければなりませんが、その実施コストは決して小さいものではないこと、そしてそのコストが事前に想定されていないことが、プロジェクト進行にどんな影響をもたらすかについては直感的にご理解いただけるのではないでしょうか。
一般的には、このような実行面における制約の変更は、以下のような観点でプロジェクト進行への影響を与えます:
実行担当部署がPoCフェイズのリード部署と別の場合には、PoCフェイズにおいて発生するコストも決して小さくありません。特に、実行担当部署が多岐に渡ったり、実行担当者が多い場合には、実行面の制約は複雑・膨大になることから、制約の緩和可否の理解や判断・調整のコストは大きくなります。
先程のサンプルプロジェクトにおける2次コンセプトの例にてご説明したように、本格適用や運用準備フェイズにおけるコストは特に大きく、関連部署の多さに依存して膨れ上がり、プロジェクト上に大きな影響を与えます。実行面の制約の中でも業務プロセスの変更・追加は、プロジェクト進行に大きな影響を与える顕著な例と言えます。現行の業務プロセスの変更・追加を難しくさせる要因としては以下のようなものがあるでしょう。
前述のように「事前に想定される範囲でしかコンセプトを変更しない」とすれば、上記の不確実性がプロジェクト全体の進行に与える影響を小さくできます。とはいえ、実際にどのコンセプトを採用するかは、例えば以下のような表で期待できる実効性と実行面への影響の大きさのバランスによって決めるというのは自然な発想でしょう。
難しいのは上記の図がPoCフェイズに先立って得られない、という状況の方が一般的だということです。より具体的に言えば、上記の表においてコンセプトの列が事前に列挙できず、これによって必要な調整コストの列が不明になるということです。
このような事態が起きるのは、上記のPoCフェイズで行われるコンセプトの再設計と検証の試行錯誤のプロセスの時系列に由来しています。以下はコンセプトがブラッシュアップされるプロセスを、コンセプトの設計と検証前後に見積もられる実効性の大きさ、実行面への影響の大きさの評価の時系列に従ってまとめた図です。
上の図から以下のことが読み取れます:
1. 検討しているコンセプトの実効性が事前に分からないこと(1の不確実性)がPoCフェイズ全体の長さや必要コストに影響している
2. コンセプトの更新が行われるプロセスの中で、実効性の向上に検討される制約の緩和条件が変更・追加されていく
ここまで何度か繰り返してお話している通り、2.の不確実性は、実行面の制約の緩和を想定する際に顕在化し、プロジェクト進行に最も大きな影響を与えます。
PoCフェイズへの影響に話を戻し、本稿をまとめましょう。
このまとめから、PoCフェイズの不確実性の影響が大きくなる要因が、実務上の制約面に関する調整や交渉にあることが読み取れます。これらの要素に関わるのが、第2の要因である「プロジェクト進行に必要となるコミュニケーションの大きさ」と第3の要因である「「重視される実コウ性」のシフト」です。後編では、この2つの要因について深掘りしてお話したいと思います。
この記事の続きはこちら
【後編】大規模・複合型プロジェクトが難しいワケ~コミュニケーションコストの大きさと「重視される実コウ性」のシフト~
あなたにオススメの記事
2023.12.01
生成AI(ジェネレーティブAI)とは?ChatGPTとの違いや仕組み・種類・活用事例
2023.09.21
DX(デジタルトランスフォーメーション)とは?今さら聞けない意味・定義を分かりやすく解説【2024年最新】
2023.11.24
【現役社員が解説】データサイエンティストとは?仕事内容やAI・DX時代に必要なスキル
2023.09.08
DX事例26選:6つの業界別に紹介~有名企業はどんなDXをやっている?~【2024年最新版】
2023.08.23
LLM(大規模言語モデル)とは?生成AIとの違いや活用事例・課題
2024.03.22
生成AIの評価指標・ベンチマークとそれらに関連する問題点や限界を解説