注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Palantir プラットフォームを使って組織に価値を生み出すには、プラットフォーム全体を活用し、業務上の意思決定プロセスを支えるツールを構築する必要があります。ユースケースとは、専任チームが特定の意思決定プロセスを支援するために、期間を定めて取り組む活動です。ユースケースは、プラットフォーム上で対象ユーザーに新しい機能を提供するうえで中心的な役割を果たします。
データの選択や意思決定の自動化に先立ち、目的と影響を受ける関係者を明確にします。プライバシーに関するベストプラクティスとして、この段階でプライバシーと市民的自由を考慮することが挙げられます。これにより、ユースケースで不要なデータを最小限に抑え、適切なアクセスを確立し、重要な場面で人間による監督を維持できます。実践的なガイダンスについては、プライバシーと市民的自由の実践を参照してください。
Palantir プラットフォームのユースケースには、次のような幅広い活動やワークフローが含まれます。
ユースケースに取り組むには、新しい考え方や用語を理解するとともに、プラットフォーム上での構築を体系的かつ十分に検討されたアプローチで進める必要があります。ソリューション設計の方法論の詳細、導入事例、リファレンスアーキテクチャについては、ユースケースのライフサイクルセクションを参照してください。
データサイエンティスト、品質分析担当者、組立ラインの作業員、経営幹部が、日々のコミュニケーションの言語としてデータを使う世界を想像してみてください。Palantir は、次の方法でデータをコミュニケーションの言語へと変えます。
このコラボレーションのビジョンが、Palantir プラットフォームの原動力です。
Palantir プラットフォームは、同僚や共同作業者と足並みを揃えながら、組織全体にデータ駆動型のループを作り出すために構築されました。データを使って意思決定を行い、その決定を記録し、時間の経過とともにその影響をデータで評価するというループです。メールでやり取りするスプレッドシートや静的な分析に頼るのではなく、同僚とリアルタイムでデータを直接扱いながら共同作業できます。
Palantir プラットフォームでプロジェクトを成功させるには、創造性と十分な検討が必要です。分析上の問い、組織のワークフロー、業務上のニーズには、多くの場合、いくつかの解決策があります。適切な進め方を選ぶには、望む成果、利用可能なデータ、プラットフォームのツールという3つの要素のバランスを取る必要があります。
プロジェクトを分解して考えるときは、成果に至る手法よりも、成果そのものを考えることが重要です。たとえば、営業ダッシュボードを作る必要性から出発するのではなく、その取り組みによってどのような意思決定や成果が可能になるかを理解することを目指します。たとえば、望む成果は、営業リージョンごとに時間とリソースを配分する意思決定に関するものなのか、それとも別のものなのかを考えます。
このような理解を得るには、プロジェクトの開始時により多くの作業が必要になる場合があります。特に、ほかの人が使うツール、レポート、分析を作る場合はそうです。現実的な目標に向けて進めるよう、成果を中心に据えた捉え方を検討します。
柔軟性を持ち、状況に適応することが、Palantir のプロジェクトを成功に導く助けとなります。成果を中心に据えた明確な目標を定めると、プロジェクトを小さな論理的ステップに分解しやすくなります。プロジェクトでは多くの場合、複数のデータソースといくつかのプラットフォームツールを連携させる必要があるため、このように問題を分解することは重要なスキルです。
プロジェクトに必要な適切なデータを見極めることは、難しい作業に感じられるかもしれません。ただし、成果を中心に据えてプロジェクトを小さなステップに分解すれば、その成果から逆算して必要なデータを特定しやすくなります。
組織で Palantir プラットフォームをしばらく使用している場合、必要なデータはすでにプラットフォームに存在するかもしれません。データカタログで整理されたデータセットや、Object Explorerのオブジェクトとリンクを探索してみてください。前述の成果の例では、営業担当者、営業担当エリア、製品、個々の売上に関するデータが必要だと判断できるかもしれません。これらのオブジェクトはそれぞれ、オントロジー内に主要な表現を持つ必要があります。
必要なデータの種類ごとに主要なデータセットを特定できない場合は、プラットフォーム管理者に連絡してください。場合によっては、オントロジーを拡張して組織の新しいオブジェクトを含めたり、すでに存在するオブジェクトに新しいプロパティを追加したりする必要があります。後述するように、データ統合レイヤーのツールを使って外部データソースに接続し、新しいデータを Palantir プラットフォームに取り込むことができます。
各アプリケーションは、プラットフォーム全体の一部として動作するように設計されています。プラットフォームのさまざまな機能や、特定の作業に最適なツールを理解するには時間がかかります。
プロジェクトの成果と必要なデータを理解すると、各ステップを特定のツールに対応付けやすくなります。たとえば、プロジェクトの中で、リージョンごとに新しい営業メトリクスを生成するサブプロジェクトが必要だとわかったとします。このサブプロジェクトでは、次のステップが追加で必要になります。
これらのステップはそれぞれ、プラットフォーム内の異なるツールに対応し、適切なツールはプロジェクトの成熟に伴って変わる可能性があります。たとえば、まず Contour でトランスフォームやメトリクスのプロトタイプを作成する方法があります。Contour は、ポイントアンドクリックで分析やデータ変換を行うアプリケーションです。Contour を使うと、データの形式を簡単に理解し、チャートやメトリクスを生成できます。これらのメトリクスをダッシュボードに追加し、営業チームからフィードバックを得るための簡易プロトタイプを作成できます。営業リソースの配分プロセスで意思決定を後押しする新しいインサイトを提供する、よく練られた数個のダッシュボードが、このプロジェクトの優れた到達点となるかもしれません。
より大規模なプロジェクトや本番利用を重視するプロジェクトでは、ロジックを Code Repositories のパイプラインに変換できます。そこでほかの技術系ユーザーと共同作業し、堅牢なプラットフォームツールを使って、データを定期的に更新するようスケジュールできます。より用途に合ったユーザーエクスペリエンスを作るには、Object View を設定するか、Workshop または Slate でカスタムアプリケーションを構築します。これにより、営業チームはダッシュボードでデータを閲覧するだけでなく、意思決定の内容をシステムに記録することもできます。
プラットフォーム上の多くのプロジェクトでは、ここまで複雑な構成は必要ありません。それでも、プロジェクトの捉え方を定め、分解することが、成功に必要なデータやツールの特定にどう役立つかを理解しておくと有用です。