イントロダクション
Odooでは“モデル”がデータの設計図です。受注や顧客、プロジェクト、タスクといった業務データはすべてモデルに沿ってデータベースに格納されます。
モデルの仕組みを理解することは、開発者だけでなく業務側のコンサルタントにも不可欠です。モデルはOdooのデータ設計の根幹で、フィールド定義、他モデルとの関係、業務ロジックをここで決めます。Odooの各モデルは共通の設計パターンに従って構築されています。
本稿はOdooで重要な役割を果たすモデルのひとつ、project.project に焦点を当てます。カスタムモジュールの開発、外部システム連携、プロジェクトワークフローの設定いずれの場合でも、このモデルに触れることになります。
project.project モデルとは何か
project.project モデルはOdoo上の“プロジェクト”を表現します。タスクやマイルストーン、コラボレーションを包含するコンテナとして振る舞い、プロジェクトごとに1レコードが存在します。
Projectアプリを使ってプロジェクトを作成すると、内部的には project.project のレコードが生成されます。タスクは task_ids を経由してそのプロジェクトに紐づけられ、プロジェクト側でステージやチーム、閲覧ルールなどが定義されます。
project モジュールがコア定義を持ち、他モジュールは継承で機能を追加します。Saleはプロジェクト請求、Timesheetは時間計上、Project Planningはガントチャートといった具合に、各モジュールはコアを再定義せずに必要機能だけを付け加えます。
project.project と project.task の関係を理解することが重要です。プロジェクト側は共通設定やチーム構成を保持し、タスク側が個別の作業単位を管理します。両者の連携がOdooでのプロジェクト管理の中核です。
モデルで押さえておくべき主要フィールド
以下は project.project における代表的なフィールドです。これらを把握しておくと、プロジェクトを効果的に扱えます。
1. name
型: Char。プロジェクト名を格納します。各種ビューで表示される主要な識別子です。
2. create_date
型: Datetime。レコード作成日時を自動保存します。レポートや監査で役立ちます。
3. write_date
型: Datetime。最終更新日時を自動保存します。データの更新履歴確認に利用します。
4. active
型: Boolean。論理削除フラグです。Falseにするとアーカイブされ、標準表示から隠れますが物理削除はされません。
5. sequence
型: Integer。並び順を制御するための数値です。リスト表示や選択時の順序付けに使います。
6. color
型: Integer。表示色のインデックス。カンバンや一覧で視覚的に区別するために使われます。
7. user_id
型: Many2one (res.users)。プロジェクト責任者（マネージャー）を指します。デフォルトの担当者表示などに用いられます。
8. company_id
型: Many2one (res.company)。マルチカンパニー環境でどの会社に属するかを示します。
9. partner_id
型: Many2one (res.partner)。プロジェクトに関わる顧客や取引先を紐付けます。請求やレポートで利用されます。
10. description
型: Html。プロジェクトの説明文です。HTMLが使えるため、ブリーフやメモをリッチに保存できます。
11. date_start
型: Date。プロジェクトの開始日を示します。計画や集計に使います。
12. date
型: Date。終了予定日や締切日を示します。進捗管理に重要です。
13. task_ids
型: One2many (project.task)。そのプロジェクトに属するタスク一覧です。プロジェクトとタスクの主要な結びつきです。
14. task_count
型: Integer。task_ids から計算されるタスク数です。表示やフィルタリングに用いられます。
15. type_ids
型: Many2many (project.task.type)。プロジェクト固有のタスクステージ（例: 未着手→進行中→完了）を定義します。
16. tag_ids
型: Many2many (project.tags)。プロジェクトに付与するタグ。分類や検索に便利です。
17. privacy_visibility
型: Selection。プロジェクトの閲覧範囲を制御します。招待ユーザーのみ、社内全員、ポータル招待を含める等の選択肢があります。
18. collaborator_ids
型: One2many (project.collaborator)。プロジェクトにアサインされたチームメンバーです。作業可能なユーザーを定義します。
19. favorite_user_ids
型: Many2many (res.users)。ユーザーが「お気に入り」登録したプロジェクトの一覧です。ダッシュボードでの即時アクセスに使います。
20. allow_task_dependencies
型: Boolean。タスク間の前後関係（依存関係）を許可するかどうかのフラグです。工程計画に使います。
21. allow_milestones
型: Boolean。マイルストーンを有効にするかのフラグ。主要な成果物をマイルストーンで管理できます。
22. milestone_ids
型: One2many (project.milestone)。そのプロジェクトに紐づくマイルストーンの一覧です。重要な納品物を追跡します。
23. rating_active
型: Boolean。顧客による評価機能を有効にするかのフラグです。顧客フィードバック収集に使います。
24. task_properties_definition
型: Text (JSON)。プロジェクト固有のタスク追加プロパティをJSONで定義するためのフィールドです。タスクに拡張属性を付けられます。
25. access_url
型: Char。顧客がポータル経由でプロジェクトにアクセスするためのURLです。コラボレーションに利用されます。
26. access_token
型: Char。ポータルアクセスのセキュリティトークンです。認可されたユーザーのみが参照可能にするために用います。
27. alias_id
型: Many2one (mail.alias)。プロジェクト用のメールエイリアス。送信されたメールから自動でタスクが作成されます。
28. activity_ids
型: One2many (mail.activity)。このプロジェクトに予定されたアクティビティ（フォローアップ等）の一覧です。リマインダー管理に使われます。
29. activity_state
型: Selection。アクティビティの状態概要（今日、期限切れ、予定）を示す計算フィールドです。
30. activity_date_deadline
型: Date。次に予定されているアクティビティの期日です。活動計画に役立ちます。
31. message_ids
型: One2many (mail.message)。プロジェクトのチャターメッセージを格納します。内部コミュニケーションに使用します。
32. message_follower_ids
型: One2many (mail.followers)。プロジェクトをフォローしているユーザー。通知を受け取ります。
33. create_uid
型: Many2one (res.users)。レコードを作成したユーザーを指します。Odooが自動設定します。
34. write_uid
型: Many2one (res.users)。最終更新を行ったユーザー。自動設定され、変更履歴確認に使います。
このモデルが業務フローで果たす役割
1. プロジェクト作成と管理
営業やプロジェクトマネージャーがプロジェクトを作る際は、名前・責任者・日付・公開範囲などを設定します。これらの設定は project.project に保存され、そこにタスクを紐づけて運用が始まります。
2. タスクのワークフロー
タスクは project の type_ids で定義されたステージを移動します。マネージャーが担当者を割り当て、プロジェクト側でワークフローやチーム構成を保持します。
3. 顧客向けポータル
privacy_visibility がポータル閲覧を許す設定だと、顧客は access_url を通じてタスクやマイルストーンを確認できます。access_token によってアクセスが保護され、クライアントとの共同作業が可能になります。
4. タイムシートと請求連携
Timesheet モジュールが入っていれば、プロジェクトと工数入力が紐づきます。Sale モジュールと組み合わせればプロジェクト単位での請求も可能です。partner_id は顧客連携で重要な役割を果たします。
5. メール連携
プロジェクトのメールエイリアスに送られた受信メールは自動的にタスクに変換されます。alias_id を正しく設定しておくことで、メールからのタスク起票を効率化できます。
開発者はどうやってこのモデルを拡張するか
開発者は複数の手法で project.project を拡張します。Odoo のモデル継承が基本の仕組みです。
モデル継承の使い方
モデルを拡張する際は _inherit = 'project.project' を使います。これにより新しいフィールドの追加、メソッドの上書き、制約の追加などが可能になります。元コードを直接変えずに別モジュールとして変更を保持できるため、将来のアップグレードにも強くなります。
フィールド追加のポイント
継承モデルに新しいフィールドを定義します。適切な型（Char／Many2one／Boolean／Integer／Text／Selection）を選び、マルチカンパニー環境では company-dependent に配慮してください。
Pythonでの拡張
create、write、unlink 等をオーバーライドして業務ロジックを注入できます。必ず super() を呼び出し、計算フィールドの依存関係に注意して実装してください。
Odoo Studio の活用
Odoo Studio を使えばコードを書かずにフィールド追加ができます。短期的なカスタマイズには便利ですが、複雑なロジックや長期運用を見据える場合はカスタムモジュールでの管理が望ましいです。
導入・運用のベストプラクティス
- 実務上の設定例: user_id はプロジェクトマネージャーの設定に使います。責任者を明確にすると運用が安定します。
- 各プロジェクトで type_ids を設定して、実際の業務フローに合わせたステージを用意してください。
- privacy_visibility の設定を誤ると情報漏えいにつながるため、社内・外部アクセスの要件に合わせて慎重に設定しましょう。
- API連携の際は XML-RPC や JSON-RPC を使って project.project を操作します。外部システムと紐づける場合は外部IDのマッピングに注意してください。
- カスタムフィールドを作る際は x_ プレフィックスやモジュール接頭辞を付けて、将来のOdooバージョンとの衝突を避けるようにします。
よくある失敗とその回避法
- プロジェクトに紐づけずにタスクを作成すること。タスクは必ず project_id を持たせるべきです。
- type_ids を設定し忘れると、プロジェクトにステージがなくタスクがワークフローで動かなくなることがあります。
- 公開設定を誤って public にすると、機密情報が社内外に見えてしまうリスクがあります。
- コアメソッドをオーバーライドして super() を呼ばない実装は、他モジュールや将来のアップグレードで不具合を引き起こします。
- 必須のカスタムフィールドを追加して既存レコードにデフォルト値を与えないと、アップグレード時にバリデーションエラーが発生します。
まとめ
project.project はOdooのプロジェクト管理における中核モデルです。プロジェクト定義、ステージ、チーム構成などの情報を保持し、各モジュールが必要な機能を継承で追加していきます。このモデルを理解することで、設定・カスタマイズ・連携作業が格段に楽になります。
機能担当者がプロジェクトを設定する場合でも、開発者がカスタムモジュールを作る場合でも、project.project の理解は作業効率の向上とトラブル回避に直結します。
Odoo導入の支援が必要ですか？
Dasolo は企業のOdoo導入・カスタマイズ・最適化を支援しています。API連携や開発に強みを持ち、project.project のようなデータモデルに関する実務経験が豊富です。
Odoo の導入支援やカスタム開発、外部連携の相談があればご連絡ください。 デモを予約する プロジェクトについて詳しくお話ししましょう。