注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Palantirプラットフォームを利用してユーザーの組織に価値を生み出すためには、プラットフォーム全体で作業を行い、運用上の意思決定プロセスを支援するツールを構築する必要があります。ユースケースは、特定の意思決定プロセスを支援するための専門チームによる時間制限のある取り組みです。ユースケースは、プラットフォーム上で新たな機能を一連のユーザーに提供するために中心的な役割を果たします。
Palantirプラットフォームのユースケースは、さまざまな活動やワークフローを含むことができ、以下のようなものがあります：
ユースケースでは、プラットフォーム内での構築に構造化された思考的なアプローチと、いくつかの新しいアイデアと用語の理解が必要です。ソリューション設計方法論やケーススタディ、リファレンスアーキテクチャの詳細は、ユースケースライフサイクルセクションで確認できます。
データサイエンティスト、品質アナリスト、組立ラインの作業員、経営者が、データを日々のコミュニケーション言語として使用する世界を想像してみてください。Palantirは次のようにしてデータをコミュニケーション言語に変えます：
この共同作業のビジョンは、Palantirプラットフォームの原動力となっています。
Palantirプラットフォームは、組織全体でデータ駆動型のループを作成するために構築されました。同僚や協業者と同期を取りながら、データを用いて意思決定を行い、行われた決定を記録し、その後、時間をかけて決定の影響をデータで評価します。メールで送られたスプレッドシートや静的な分析に依存するのではなく、あなたと同僚たちはリアルタイムでデータ上で直接共同作業することができます。
Palantirプラットフォーム上でのプロジェクト成功は、創造性と思慮深さを必要とします。分析的な問い、組織のワークフロー、または運用上のニーズに対する解決策はしばしばいくつか存在します。適切な道筋を選ぶためには、目指す結果、利用可能なデータ、プラットフォームのツールの3つの要素をバランス良く考慮する必要があります。
プロジェクトを分解する際には、そこに至る方法よりも結果について考えることがより重要です。たとえば、営業ダッシュボードを作る必要があるところから始めるのではなく、あなたの作業が可能にする意思決定と結果について理解を深めることを探求してみてください。例えば、結果は、異なる営業地域への時間とリソースの割り当てに関する意思決定を行うことなのか、それとも他の何かなのか？
このレベルの理解を得るためには、特に他の人が使用するツール、レポート、または分析を作成している場合、プロジェクトの開始時点でより多くの作業が必要になるかもしれません。現実的な目標に向けて進むのに役立つ、結果志向のフレーミングを考慮してみてください。
柔軟性と適応性は、Palantirプロジェクトを成功させるのに役立ちます。明確で結果志向の目標を特定することで、プロジェクトを小さく、論理的なステップに分解することが容易になります。この問題の分解は重要なスキルであり、プロジェクトはしばしば複数のデータソースと複数のプラットフォームツールの連携を必要とします。
プロジェクトを支える適切なデータを見つけることは、困難な課題となることがあります。しかし、結果志向のフレーミングを持ち、プロジェクトを小さなステップに分解することができれば、その結果から逆算して必要なデータを特定する作業が容易になります。
ユーザーの組織がPalantirプラットフォームを一定期間使用していれば、必要なデータは既にプラットフォーム内に存在するかもしれません。Data Catalogでキュレーションされたデータセットや、Object Explorerのオブジェクトやリンクを探索してみてください。結果の例から、営業チーム、営業地域、製品、個々の販売に関するデータが必要であることを特定するかもしれません。これらのオブジェクトはそれぞれ、オントロジー内に主要な表現を持つべきです。
必要なデータの種類ごとの主要なデータセットを特定できない場合は、プラットフォーム管理者に連絡してください。場合によっては、新たな組織のオブジェクトをオントロジーに追加するか、既存のものに新たなプロパティを追加する必要があるかもしれません。後ほど議論するように、データ統合レイヤーのツールを使用して外部のデータソースを接続し、新たなデータをPalantirプラットフォームに取り込むことができます。
各アプリケーションは、プラットフォーム全体の一部として動作するように設計されています。プラットフォーム内のさまざまな機能と、どのツールが特定の仕事に最適かを理解するには時間がかかるでしょう。
プロジェクトの結果と必要なデータを理解すると、各ステップを特定のツールにマッピングするのが容易になります。例えば、プロジェクトで、1つのサブプロジェクトが各地域の新しい営業指標を生成することを認識したとしましょう。このサブプロジェクトは、いくつかの追加ステップを作成します：
これらのステップはプラットフォーム内の異なるツールにマッピングされ、プロジェクトが成熟するにつれて適切なツールが変わるかもしれません。例えば、初めてトランスフォームや指標をContourでプロトタイピングするかもしれません。これは、ポイント＆クリックによる分析とデータ変換のためのアプリケーションです。Contourを使用すると、データの形状を理解し、チャートや指標を生成するのが容易になります。これらの指標をダッシュボードに追加し、営業チームからフィードバックを得るためのクイックプロトタイプを作成することができます。これがこのプロジェクトの素晴らしい終点となるかもしれません：営業リソースの割り当てプロセスの意思決定を推進する新たな洞察を提供する、いくつかの精巧に作られたダッシュボード。
より大規模なプロジェクトや、本番利用に焦点を当てたプロジェクトでは、ロジックをCode Repositoriesのパイプラインに変換できます。そこでは、他の技術者と共同作業を行い、データを定期的に更新するための頑丈なプラットフォームツールを使用することができます。よりカスタマイズされたユーザーエクスペリエンスを作成するためには、Object Viewsを設定するか、WorkshopまたはSlateでカスタムアプリケーションを作成して、営業チームがダッシュボードでデータを表示するだけでなく、その決定をシステムに戻すことを可能にすることができます。
プラットフォーム内の多くのプロジェクトではこのレベルの複雑さが必要ないかもしれませんが、フレーミングとプロジェクトの分解がどのようにして必要なデータとツールを特定するのに役立つかを理解することは有用です。
最後に、ユーザーロール別の次のステップをご覧いただき、どこから始めるべきかを学んでください。