第 6 章: walk-with-ai 流・実践シナリオで解くビジネス課題

AI/DX コンサルティングの現場で実際に遭遇するビジネス課題を Cypher で解決

これまでに学んだ知識を総動員し、AI/DX コンサルティングの現場で実際に遭遇するであろう具体的なビジネス課題を、Cypher を使って解決する体験をします。これらのシナリオを通じて、グラフ思考がどのように実践的な価値を生み出すかを体感してください。

6.1 シナリオ 1：最適なプロジェクトチームの編成

ビジネス課題

新規の「AI チャットボット開発」プロジェクトが発足する。このプロジェクトには、「Python」スキルを持つ人材 1 名と「機械学習」スキルを持つ人材 1 名が必須である。候補者を見つけるだけでなく、チームの相性を高めるために、過去に同じプロジェクトで協業経験のあるペアを優先的にリストアップしたい。

グラフモデル

この課題は、(Employee)-[:HAS_SKILL]->(Skill) と (Employee)-[:PARTICIPATES_IN]->(Project) という関係性を用いて解決します。これは、従業員、スキル、プロジェクト間の関係性をモデル化する人事領域の知識グラフの典型的な応用例です。

解決アプローチ

1. 「Python」スキルを持つ従業員（dev1）を全員見つけます
2. 「機械学習」スキルを持つ従業員（dev2）を全員見つけます
3. dev1 と dev2 が別人であるペアを生成します
4. 各ペアについて、過去に同じプロジェクトに参加したことがあるか（協業経験）を OPTIONAL MATCH を使って調査します
5. 協業経験のあるプロジェクト数をカウントし、その数が多いペアを上位に表示します

実装クエリ

// 新規AIチャットボット開発プロジェクトのチーム編成最適化

// まず新しいプロジェクトを作成
CREATE (newProject:Project {
  name: "AIチャットボット開発",
  status: "計画中",
  budget: 15000000,
  requiredSkills: ["Python", "機械学習"],
  priority: "高"
})

// ステップ1 & 2: 必要なスキルを持つ従業員を見つける
MATCH (dev1:Employee)-[:HAS_SKILL]->(s1:Skill {name: 'Python'})
MATCH (dev2:Employee)-[:HAS_SKILL]->(s2:Skill {name: '機械学習'})

// ステップ3: 同一人物が選ばれるのを防ぎ、ペアの重複を避ける
WHERE id(dev1) < id(dev2)

// ステップ4: 過去の協業経験を任意で検索
OPTIONAL MATCH (dev1)-[:PARTICIPATES_IN]->(p:Project)<-[:PARTICIPATES_IN]-(dev2)
WHERE p.status = "完了"  // 完了したプロジェクトでの協業のみカウント

// ステップ5: 各候補者の詳細情報も含めて分析
WITH dev1, dev2, count(DISTINCT p) AS collaborationCount, collect(DISTINCT p.name) AS collaboratedProjects

// 追加分析: 各候補者の他のスキルも評価
OPTIONAL MATCH (dev1)-[:HAS_SKILL]->(skill1:Skill)
OPTIONAL MATCH (dev2)-[:HAS_SKILL]->(skill2:Skill)
WITH dev1, dev2, collaborationCount, collaboratedProjects,
     collect(DISTINCT skill1.name) AS dev1Skills,
     collect(DISTINCT skill2.name) AS dev2Skills

// 総合評価スコアを計算
WITH dev1, dev2, collaborationCount, collaboratedProjects, dev1Skills, dev2Skills,
     // 協業経験スコア（0-10点）
     CASE WHEN collaborationCount >= 3 THEN 10
          WHEN collaborationCount = 2 THEN 7
          WHEN collaborationCount = 1 THEN 4
          ELSE 0 END AS collaborationScore,
     // 経験値スコア（0-10点）
     round((dev1.experience + dev2.experience) / 20.0 * 10) AS experienceScore,
     // スキル多様性スコア（0-10点）
     round(size(dev1Skills + dev2Skills) / 10.0 * 10) AS skillDiversityScore

WITH dev1, dev2, collaborationCount, collaboratedProjects, dev1Skills, dev2Skills,
     collaborationScore, experienceScore, skillDiversityScore,
     collaborationScore + experienceScore + skillDiversityScore AS totalScore

RETURN
    dev1.name AS pythonDeveloper,
    dev1.title AS dev1Title,
    dev1.experience AS dev1Experience,
    dev2.name AS machineLearningSpecialist,
    dev2.title AS dev2Title,
    dev2.experience AS dev2Experience,
    collaborationCount AS pastCollaborations,
    collaboratedProjects AS collaborationHistory,
    totalScore AS teamFitScore,
    collaborationScore AS collaborationBonus,
    experienceScore AS experienceValue,
    skillDiversityScore AS diversityBonus,
    dev1Skills AS pythonDevSkills,
    dev2Skills AS mlSpecialistSkills
ORDER BY totalScore DESC, collaborationCount DESC, dev1.experience + dev2.experience DESC

ビジネス価値

このクエリにより、HR 部門とプロジェクトマネージャーは以下の価値を得られます：

• 客観的な評価: 過去の協業実績に基づく定量的なチーム編成
• リスク軽減: 初回協業によるコミュニケーションリスクの最小化
• 時間短縮: 手動でのマッチング作業から解放
• スキル可視化: チーム全体のスキルポートフォリオの把握

6.2 シナリオ 2：サプライチェーンの影響範囲分析

ビジネス課題

当社が製造する「製品 X」は「部品 A」を必要とし、「部品 A」は「サプライヤー A」から供給されている。さらに、「サプライヤー A」は「供給元 Z」から「原材料 Z」を調達している。もし「供給元 Z」の工場が生産停止した場合、当社のどの製品に、どのような経路で影響が及ぶのか、その全体像を即座に把握したい。

グラフモデル

この課題は、(Supplier)-[:SUPPLIES]->(Component)-[:USED_IN]->(Product) のような依存関係の連鎖としてモデル化されます。これは、グラフが「何が何に依存し、それがさらに何に依存しているか」という再帰的な問いに答えるのに非常に優れていることを示す典型的な例です。

サプライチェーンデータの準備

// サプライチェーンのサンプルデータを作成
// 供給元
CREATE (supplier1:Supplier {name: "供給元Z", location: "中国", reliability: 0.85})
CREATE (supplier2:Supplier {name: "供給元Y", location: "韓国", reliability: 0.92})

// 原材料
CREATE (material1:Material {name: "原材料Z", type: "レアメタル"})
CREATE (material2:Material {name: "原材料Y", type: "プラスチック"})

// サプライヤー
CREATE (vendor1:Vendor {name: "サプライヤーA", speciality: "電子部品"})
CREATE (vendor2:Vendor {name: "サプライヤーB", speciality: "機械部品"})

// 部品
CREATE (component1:Component {name: "部品A", category: "CPU"})
CREATE (component2:Component {name: "部品B", category: "メモリ"})
CREATE (component3:Component {name: "部品C", category: "ケース"})

// 製品
CREATE (product1:Product {name: "製品X", category: "スマートフォン"})
CREATE (product2:Product {name: "製品Y", category: "タブレット"})
CREATE (product3:Product {name: "製品Z", category: "ノートPC"})

// 依存関係を作成
// 供給元 -> 原材料
CREATE (supplier1)-[:PROVIDES {leadTime: 30, cost: 100}]->(material1)
CREATE (supplier2)-[:PROVIDES {leadTime: 14, cost: 50}]->(material2)

// 原材料 -> サプライヤー
CREATE (material1)-[:USED_BY {quantity: 100}]->(vendor1)
CREATE (material2)-[:USED_BY {quantity: 200}]->(vendor2)

// サプライヤー -> 部品
CREATE (vendor1)-[:SUPPLIES {leadTime: 21, cost: 500}]->(component1)
CREATE (vendor1)-[:SUPPLIES {leadTime: 14, cost: 300}]->(component2)
CREATE (vendor2)-[:SUPPLIES {leadTime: 7, cost: 80}]->(component3)

// 部品 -> 製品
CREATE (component1)-[:USED_IN {quantity: 1, critical: true}]->(product1)
CREATE (component2)-[:USED_IN {quantity: 2, critical: true}]->(product1)
CREATE (component3)-[:USED_IN {quantity: 1, critical: false}]->(product1)

CREATE (component1)-[:USED_IN {quantity: 1, critical: true}]->(product2)
CREATE (component2)-[:USED_IN {quantity: 4, critical: true}]->(product2)

CREATE (component1)-[:USED_IN {quantity: 2, critical: true}]->(product3)
CREATE (component2)-[:USED_IN {quantity: 8, critical: true}]->(product3)
CREATE (component3)-[:USED_IN {quantity: 1, critical: false}]->(product3)

影響範囲分析クエリ

// 供給元Z停止時の包括的影響分析

// ステップ1: 影響の起点となる供給元を特定
MATCH impactPath = (supplier:Supplier {name: "供給元Z"})-[*]->(affectedEntity)

// ステップ2: 影響を受ける各レベルのエンティティを分析
WITH supplier, impactPath, affectedEntity,
     // パスの長さで影響のレベルを判定
     length(impactPath) AS impactLevel,
     // 影響を受けるエンティティのタイプを特定
     labels(affectedEntity)[0] AS entityType

// ステップ3: 各レベルでの影響を集約
WITH supplier, impactLevel, entityType, collect(DISTINCT affectedEntity.name) AS affectedEntities

// ステップ4: 影響の総合評価
MATCH (supplier)-[*]->(finalProduct:Product)
WITH supplier,
     impactLevel, entityType, affectedEntities,
     collect(DISTINCT finalProduct.name) AS affectedProducts,
     count(DISTINCT finalProduct) AS productCount

// ステップ5: 詳細な影響経路分析
MATCH detailedPath = (supplier)-[*]->(product:Product)
WITH supplier, impactLevel, entityType, affectedEntities, affectedProducts, productCount,
     product,
     // 各製品への影響経路を詳細分析
     [rel IN relationships(detailedPath) | type(rel)] AS relationshipTypes,
     [node IN nodes(detailedPath) | node.name] AS supplyChain,
     // 総コストとリードタイムを計算
     reduce(totalCost = 0, rel IN relationships(detailedPath) | totalCost + coalesce(rel.cost, 0)) AS totalCost,
     reduce(totalLeadTime = 0, rel IN relationships(detailedPath) | totalLeadTime + coalesce(rel.leadTime, 0)) AS totalLeadTime

RETURN supplier.name AS impactSource,
       supplier.location AS sourceLocation,
       supplier.reliability AS sourceReliability,
       affectedProducts AS affectedProductList,
       productCount AS totalAffectedProducts,
       collect(DISTINCT {
         product: product.name,
         category: product.category,
         supplyChain: supplyChain,
         totalCost: totalCost,
         totalLeadTime: totalLeadTime,
         riskLevel: CASE
           WHEN totalLeadTime > 60 THEN "高"
           WHEN totalLeadTime > 30 THEN "中"
           ELSE "低"
         END
       }) AS detailedImpactAnalysis

ORDER BY productCount DESC

リスク軽減戦略クエリ

// 代替サプライチェーンの分析
MATCH (failedSupplier:Supplier {name: "供給元Z"})-[*]->(product:Product)
WITH DISTINCT product

// 同じ製品への代替供給経路を検索
MATCH alternativePath = (altSupplier:Supplier)-[*]->(product)
WHERE altSupplier.name <> "供給元Z"

WITH product,
     count(DISTINCT altSupplier) AS alternativeSuppliers,
     collect(DISTINCT altSupplier.name) AS supplierOptions,
     avg(altSupplier.reliability) AS avgReliability

RETURN product.name AS vulnerableProduct,
       alternativeSuppliers AS backupOptions,
       supplierOptions AS alternativeSupplierList,
       round(avgReliability, 2) AS avgBackupReliability,
       CASE
         WHEN alternativeSuppliers >= 3 THEN "低リスク"
         WHEN alternativeSuppliers >= 2 THEN "中リスク"
         ELSE "高リスク"
       END AS riskAssessment
ORDER BY alternativeSuppliers ASC, avgReliability DESC

6.3 シナリオ 3：組織内のキーパーソン特定

ビジネス課題

社内の DX イニシアチブを強力に推進するためには、公式な役職とは別に、部門を横断して情報やコラボレーションのハブとなっている「隠れたキーパーソン」を特定することが重要である。

グラフモデル

従業員間の (Employee)-[:COLLABORATES_WITH]->(Employee) や (Employee)-[:MANAGES]->(Employee) といった関係性ネットワーク全体を分析します。これは、ソーシャルネットワーク分析（SNA）の考え方を組織分析に応用するものです。

包括的なネットワーク分析

// より詳細な組織ネットワークデータを追加
// 部門間協業関係を作成
MATCH (e1:Employee), (e2:Employee)
WHERE e1 <> e2 AND rand() < 0.3  // 30%の確率で協業関係を作成
CREATE (e1)-[:COLLABORATES_WITH {frequency: toInteger(rand() * 10) + 1,
                                  lastCollaboration: date() - duration({days: toInteger(rand() * 365)})}]->(e2)

// メンター関係を作成
MATCH (senior:Employee), (junior:Employee)
WHERE senior.experience > junior.experience + 3 AND rand() < 0.2
CREATE (senior)-[:MENTORS {since: date() - duration({years: toInteger(rand() * 3) + 1})}]->(junior)

// 情報共有関係を作成
MATCH (e1:Employee), (e2:Employee)
WHERE e1 <> e2 AND rand() < 0.25
CREATE (e1)-[:SHARES_KNOWLEDGE_WITH {topics: ["技術", "業界動向", "ベストプラクティス"][toInteger(rand() * 3)]}]->(e2)

多次元的キーパーソン分析

// 包括的なキーパーソン分析（複数の中心性指標を組み合わせ）

MATCH (person:Employee)

// 次数中心性: 直接的なつながりの数
OPTIONAL MATCH (person)-[directRel]-(connected:Employee)
WITH person, count(DISTINCT directRel) AS degreeScore, collect(DISTINCT connected) AS directConnections

// 媒介中心性の近似: 異なる部門間をつなぐ橋渡し役の評価
OPTIONAL MATCH (person)-[:COLLABORATES_WITH]-(colleague:Employee)
WHERE colleague.title <> person.title  // 異なる職種との協業
WITH person, degreeScore, directConnections, count(DISTINCT colleague.title) AS bridgeScore

// 影響力スコア: 経験豊富な人々との関係
UNWIND directConnections AS connection
WITH person, degreeScore, bridgeScore, avg(connection.experience) AS avgConnectionExperience

// メンタリング活動の評価
OPTIONAL MATCH (person)-[:MENTORS]->(mentee:Employee)
WITH person, degreeScore, bridgeScore, avgConnectionExperience, count(mentee) AS mentoringScore

// 知識共有活動の評価
OPTIONAL MATCH (person)-[:SHARES_KNOWLEDGE_WITH]->(recipient:Employee)
WITH person, degreeScore, bridgeScore, avgConnectionExperience, mentoringScore,
     count(recipient) AS knowledgeSharingScore

// プロジェクト横断的な活動
OPTIONAL MATCH (person)-[:PARTICIPATES_IN]->(project:Project)
WITH person, degreeScore, bridgeScore, avgConnectionExperience, mentoringScore, knowledgeSharingScore,
     count(DISTINCT project) AS projectDiversityScore

// 総合的な影響力スコアを計算
WITH person,
     degreeScore,
     bridgeScore,
     round(coalesce(avgConnectionExperience, 0), 1) AS avgConnectionExp,
     mentoringScore,
     knowledgeSharingScore,
     projectDiversityScore,
     // 重み付き総合スコア
     (degreeScore * 0.25 +
      bridgeScore * 0.30 +
      mentoringScore * 0.20 +
      knowledgeSharingScore * 0.15 +
      projectDiversityScore * 0.10) AS totalInfluenceScore

// 公式な職位との比較
WITH person, degreeScore, bridgeScore, avgConnectionExp, mentoringScore,
     knowledgeSharingScore, projectDiversityScore, totalInfluenceScore,
     CASE
       WHEN person.title CONTAINS "マネージャー" OR person.title CONTAINS "リーダー" THEN "公式リーダー"
       ELSE "一般社員"
     END AS officialRole

RETURN person.name AS employeeName,
       person.title AS officialTitle,
       officialRole,
       round(totalInfluenceScore, 2) AS influenceScore,
       degreeScore AS networkSize,
       bridgeScore AS crossFunctionalConnections,
       avgConnectionExp AS connectionQuality,
       mentoringScore AS mentoringActivity,
       knowledgeSharingScore AS knowledgeSharing,
       projectDiversityScore AS projectInvolvement,
       CASE
         WHEN totalInfluenceScore >= 15 THEN "キーインフルエンサー"
         WHEN totalInfluenceScore >= 10 THEN "重要コネクター"
         WHEN totalInfluenceScore >= 5 THEN "活発メンバー"
         ELSE "標準メンバー"
       END AS influenceCategory,
       // 隠れたリーダーシップの特定
       CASE
         WHEN officialRole = "一般社員" AND totalInfluenceScore >= 12 THEN "隠れたリーダー"
         WHEN officialRole = "公式リーダー" AND totalInfluenceScore < 8 THEN "名目的リーダー"
         ELSE "役職適合"
       END AS leadershipGap

ORDER BY totalInfluenceScore DESC, networkSize DESC
LIMIT 20

DX 推進チーム編成への応用

// DXイニシアチブ推進チームの最適編成
MATCH (influencer:Employee)
WHERE influencer.name IN [
  // 上記分析で特定されたトップインフルエンサーを使用
  "佐藤", "鈴木", "高橋"  // 実際の分析結果に基づいて更新
]

// 各インフルエンサーのネットワーク到達範囲を分析
OPTIONAL MATCH (influencer)-[*1..2]-(reachable:Employee)
WITH influencer, count(DISTINCT reachable) AS networkReach, collect(DISTINCT reachable.title) AS reachableRoles

// DX関連スキルの評価
OPTIONAL MATCH (influencer)-[:HAS_SKILL]->(skill:Skill)
WHERE skill.name IN ["データ分析", "プロジェクト管理", "Python", "機械学習"]
WITH influencer, networkReach, reachableRoles, collect(skill.name) AS dxRelevantSkills

RETURN influencer.name AS dxTeamCandidate,
       influencer.title AS currentRole,
       networkReach AS organizationalReach,
       size(dxRelevantSkills) AS dxSkillCount,
       dxRelevantSkills AS relevantSkills,
       reachableRoles AS influenceSpread,
       // DXチームでの推奨役割
       CASE
         WHEN size(dxRelevantSkills) >= 3 AND networkReach >= 15 THEN "DXリーダー"
         WHEN networkReach >= 20 THEN "変革推進大使"
         WHEN size(dxRelevantSkills) >= 2 THEN "技術エキスパート"
         ELSE "組織連携担当"
       END AS recommendedDxRole

ORDER BY networkReach + size(dxRelevantSkills) * 5 DESC

これらの実践的なシナリオを通じて、Cypher がいかにビジネスの複雑な課題を解決する強力なツールであるかを体感いただけたでしょう。次の最終章では、さらなる学習リソースと、walk-with-ai が提供できる支援について説明します。

---

前へ: 第 5 章: データから価値を掘り出す | 次へ: 最終章: 次のステップへ

関連記事

• 業界別 DX 進展状況比較分析
• PM 向け技術基礎知識

著者: hnish