役割はプロジェクトに属する

Snappy PM の権限を設計していたとき、一見とてもシンプルな問題に出会いました。

Who is the Project Manager?

考えを進めるうちに、この問い自体が十分に正確ではないと気づきました。

ある人は会社では Operator かもしれませんが、Project A では Project Manager、Project B では購買担当にすぎず、Project C ではプロジェクトの内容を一切見るべきでないかもしれません。

だから私たちは最終的に、2つのことを分けました。

Identity belongs to the company.

Role belongs to the project.

Owner と Operator は、人と企業の関係を表します。

Project Manager、Designer、Site Engineer、QS は、その人が具体的なプロジェクトで何を担当するかを表します。

この2つの概念は混ぜるべきではありません。

さらに重要なことに、私たちは Snappy PM に固定の役職表を設計しませんでした。

家具企業にはこう必要かもしれません。

Project Manager / Designer / Purchaser / Installer

コンサルティング企業にはこうかもしれません。

Project Lead / Consultant / Accountant

これらは企業自身の言葉を使うべきです。

そして Role で本当に重要なのは、何と呼ばれるかではなく、

What can this person do?

です。

顧客の見積を確認できるか？

Change Scope できるか？

Expense を追加できるか？

Delivery を処理できるか？

Financial の書類を見られるか？

だから Snappy PM では、Role は最終的に、非常に具体的な操作権限とファイル権限のセットに対応します。

これは、多くの小さな企業の実際の管理方式を思い出させます。

社長は往々にして、複雑な Organization Chart を作りたいわけではありません。

ただこう言いたいだけです。

「このプロジェクトは George に任せる、彼が実行を担当する。購買は Ahmed にやらせる。財務書類は現場の人間に見せるな。」

ソフトウェアは、こんなシンプルな一文を直接表現できるべきです。

そしてプロジェクトが終わったら、次のプロジェクトは完全に新しくアレンジできます。

企業の組織構造は長期的かもしれませんが、

Projects are temporary organizations.

すべてのプロジェクトが、一つのことを成し遂げるために人の集まりを組み直すのです。

だから私たちは、Snappy PM の権限システムも Project から出発してほしいと考えています。

最初に問うのは、

What is your title?

ではなく、

What are you responsible for on this project?

です。

これはおそらく、小さな企業の本当の働き方に近いのではないでしょうか。

SnapLedger, your life easier.