Blueのカスタム権限エンジンの構築

Blueエンジニアリングチームが、AIを活用した自動分類とタグ付け機能をどのように構築したかを解説いたします。

効果的なプロジェクトおよびプロセス管理は、あらゆる規模の組織にとって極めて重要でございます。

Blueでは、シンプルで強力、柔軟性があり、すべての方にとって手頃な価格の最高のプロジェクト管理プラットフォームを構築することで、世界の仕事を整理することを使命としております。

これは、弊社のプラットフォームが各チームの独自のニーズに適応する必要があることを意味いたします。本日は、弊社の最も強力な機能の一つであるカスタム権限機能について、その舞台裏をご紹介いたします。

プロジェクト管理ツールは現代のワークフローの基盤であり、機密データ、重要なコミュニケーション、戦略的計画を収容しております。そのため、この情報へのアクセスを細かく制御する能力は、贅沢品ではなく必需品でございます。

カスタム権限は、特にプロジェクト管理ツールにおけるB2B SaaSプラットフォームにおいて重要な役割を果たしており、コラボレーションとセキュリティのバランスがプロジェクトの成功を左右することがございます。

しかし、Blueが異なるアプローチを取る点がここにございます：エンタープライズグレードの機能は、エンタープライズサイズの予算のためだけに確保されるべきではないと弊社は考えております。

AIが小規模チームを前例のない規模で運営できるようにする時代において、なぜ堅牢なセキュリティとカスタマイゼーションが手の届かないものでなければならないのでしょうか？

この舞台裏の解説では、弊社がカスタム権限機能をどのように開発し、SaaS価格ティアの現状に挑戦し、あらゆる規模のビジネスに強力で柔軟なセキュリティオプションをもたらしたかをご紹介いたします。

大きな夢を持つスタートアップでも、プロセスを最適化しようとする既存企業でも、カスタム権限により、これまで知らなかった新しい使用事例が可能になります。

カスタムユーザー権限の理解

Blueのカスタム権限開発の旅を掘り下げる前に、カスタムユーザー権限とは何か、そしてなぜプロジェクト管理ソフトウェアにおいて極めて重要なのかを理解する時間を取らせていただきます。

カスタムユーザー権限とは、ソフトウェアシステム内の個々のユーザーまたはグループのアクセス権を調整する能力を指します。固定された権限セットを持つ事前定義された役割に依存する代わりに、カスタム権限により管理者は組織の構造とワークフローのニーズに完全に適合する非常に具体的なアクセスプロファイルを作成できます。

Blueのようなプロジェクト管理ソフトウェアの文脈では、カスタム権限には以下が含まれます：

詳細なアクセス制御: 特定のタイプのプロジェクトデータを誰が閲覧、編集、または削除できるかを決定すること。
機能ベースの制限: 特定のユーザーまたはチームに対して特定の機能を有効または無効にすること。
データ機密性レベル: プロジェクト内の機密情報へのアクセスレベルを様々に設定すること。
ワークフロー固有の権限: ユーザーの能力をプロジェクトワークフローの特定の段階または側面に合わせること。

プロジェクト管理におけるカスタム権限の重要性は過大評価することができません：

セキュリティの強化: ユーザーに必要なアクセスのみを提供することで、データ漏洩や不正な変更のリスクを削減します。
コンプライアンスの向上: カスタム権限により、組織はデータアクセスを制御することで業界固有の規制要件を満たすことができます。
コラボレーションの合理化: 各メンバーが不必要な制限や過度の特権なしに自分の役割を実行するための適切なレベルのアクセスを持つとき、チームはより効率的に働くことができます。
複雑な組織への柔軟性: 企業が成長し進化するにつれて、カスタム権限により、ソフトウェアは変化する組織構造とプロセスに適応できます。

「YES」に到達する

弊社が以前に書いたように、Blueのすべての機能は、構築を決定する前に強固なYESでなければなりません。弊社には何百人ものエンジニアという贅沢はなく、顧客が必要としないものを構築して時間とお金を無駄にすることはできません。

そして、Blueにカスタム権限を実装する道のりは直線的ではありませんでした。多くの強力な機能と同様に、それはユーザーからの明確なニーズから始まり、慎重な検討と計画を通じて進化しました。

何年もの間、弊社の顧客はユーザー権限に対するより詳細な制御を要求しておりました。あらゆる規模の組織がますます複雑で機密性の高いプロジェクトを扱うようになるにつれて、弊社の標準的な役割ベースアクセス制御の限界が明らかになりました。

外部クライアントと協働する小規模スタートアップ、複雑な承認プロセスを持つ中規模企業、厳格なコンプライアンス要件を持つ大企業、すべてが同じニーズを声にしました：

ユーザーアクセス管理におけるより多くの柔軟性。

明確な需要にもかかわらず、弊社は当初、カスタム権限の開発に着手することを躊躇しておりました。

なぜでしょうか？

弊社は関わる複雑さを理解していたからです！

カスタム権限は、ユーザーインターフェースからデータベース構造まで、プロジェクト管理システムのあらゆる部分に触れます。弊社は、この機能を実装するには、コアアーキテクチャへの大幅な変更とパフォーマンスへの影響の慎重な検討が必要であることを知っていました。

状況を調査した結果、弊社の競合他社の中で、顧客が要求するような強力なカスタム権限エンジンの実装を試みた企業は非常に少ないことが分かりました。実装した企業も、しばしばそれを最高ティアのエンタープライズプランに確保していました。

理由が明らかになりました：開発労力は相当であり、リスクも高いのです。

カスタム権限を incorrectly に実装すると、重要なバグやセキュリティ脆弱性が導入され、システム全体が危険にさらされる可能性があります。この認識により、弊社が検討していた挑戦の規模が浮き彫りになりました。

現状への挑戦

しかし、弊社が成長し進化を続ける中で、重要な認識に到達しました：

強力な機能をエンタープライズ顧客のために確保するという従来のSaaSモデルは、今日のビジネス環境においてもはや意味をなさない。

2024年において、AIと高度なツールの力により、小規模チームは大規模な組織に匹敵する規模と複雑性で運営することができます。スタートアップは複数の国にまたがる機密クライアントデータを扱っているかもしれません。小規模なマーケティング代理店は、様々な機密要件を持つ数十のクライアントプロジェクトをこなしているかもしれません。これらのビジネスには、どの大企業と同レベルのセキュリティとカスタマイゼーションが必要です。

弊社は自問しました：なぜ企業の労働力や予算の規模が、データを安全に保ち、プロセスを効率的にする能力を決定すべきなのでしょうか？

すべての方へのエンタープライズグレード

この認識により、現在Blueでの弊社の開発の多くを推進するコア哲学に導かれました：エンタープライズグレードの機能は、あらゆる規模のビジネスがアクセスできるべきです。

弊社は以下を信じております：

セキュリティは贅沢品であってはならない。 規模に関係なく、すべての企業がデータとプロセスを保護するツールに値します。
柔軟性がイノベーションを推進する。 すべてのユーザーに強力なツールを提供することで、業界を前進させるワークフローとシステムを作成できるようにします。
成長にプラットフォーム変更は必要ない。 顧客が成長するにつれて、ツールも彼らと共にシームレスに成長すべきです。

この考え方により、弊社はカスタム権限の挑戦に真正面から取り組むことを決定し、より高いティアプランの顧客だけでなく、すべてのユーザーが利用できるようにすることをコミットしました。

この決定により、慎重な設計、反復的な開発、継続的なユーザーフィードバックの道のりが始まり、最終的に今日弊社が誇りを持って提供するカスタム権限機能につながりました。

次のセクションでは、この複雑な機能を実現するために弊社がどのように設計と開発プロセスにアプローチしたかを詳しく見ていきます。

設計と開発

カスタム権限に取り組むことを決定したとき、弊社は巨大なタスクに直面していることを素早く認識しました。

一見すると、「カスタム権限」は簡単に聞こえるかもしれませんが、これは弊社のシステムのあらゆる側面に触れる、騙されやすい複雑な機能です。

この挑戦は困難でした：弊社は、カスケード権限を実装し、オンザフライでの編集を許可し、大幅なデータベーススキーマ変更を行い、弊社のエコシステム全体 – Web、Mac、Windows、iOS、Androidアプリ、さらにはAPIとウェブフックにわたってシームレスな機能を確保する必要がありました。

複雑さは、最も経験豊富な開発者でも立ち止まらせるほどでした。

弊社のアプローチは、2つの重要な原則に中心を置きました：

機能を管理可能なバージョンに分解すること
段階的なシッピングを受け入れること

本格的なカスタム権限の複雑さに直面して、弊社は重要な質問を自分自身に問いました：

この機能の最もシンプルな最初のバージョンは何でしょうか？

このアプローチは、最小実行可能製品（MVP）を提供し、フィードバックに基づいて反復するアジャイル原則と一致しています。

弊社の答えは驚くほど簡単でした：

プロジェクトアクティビティタブを隠すトグルを導入する
フォームタブを隠すもう一つのトグルを追加する

以上でした。

装飾も複雑な権限マトリックスもありません – ただ2つのシンプルなオン/オフスイッチです。

一見すると物足りなく見えるかもしれませんが、このアプローチは以下のような重要な利点を提供しました：

迅速な実装: これらのシンプルなトグルは迅速に開発・テストでき、基本的なカスタム権限バージョンを迅速にユーザーの手に届けることができました。
明確なユーザー価値: この2つのオプションだけでも、弊社は有形の価値を提供していました。一部のチームはクライアントからアクティビティフィードを隠したいかもしれませんし、他のチームは特定のユーザーグループのフォームへのアクセスを制限する必要があるかもしれません。
成長の基盤: このシンプルなスタートは、より複雑な権限のための基盤を築きました。最初から複雑性に巻き込まれることなく、カスタム権限の基本インフラストラクチャを設定できました。
ユーザーフィードバック: このシンプルなバージョンをリリースすることで、ユーザーがカスタム権限とどのように相互作用するかについての実世界のフィードバックを収集し、将来の開発を情報に基づいたものにできました。
技術的学習: この初期実装により、弊社の開発チームはプラットフォーム全体で権限を変更する実践的な経験を得て、より複雑な反復に備えることができました。

そして実際のところ、何かに対して巨大なビジョンを持ちながら、そのビジョンのほんのわずかな割合でしかないものをシップするのは、非常に謙虚なことでした。

これらの最初の2つのトグルをシップした後、弊社はより洗練されたものに取り組むことを決定しました。弊社は2つの新しいカスタムユーザー役割権限に着手しました。

1つ目は、ユーザーを自分に特別に割り当てられたレコードのみを表示するように制限する能力でした。これは、プロジェクトにクライアントがいて、彼らのために作業しているすべてではなく、特別に彼らに割り当てられたレコードのみを見せたい場合に非常に有用です。

2つ目は、プロジェクト管理者がユーザーグループが他のユーザーを招待することをブロックするオプションでした。これは、「知る必要がある」ベースで確実に留めたい機密プロジェクトがある場合に良いです。

これをシップした後、弊社はより多くの自信を得て、3番目のバージョンでは列レベル権限に取り組みました。これは、特定のユーザーグループが表示または編集できるカスタムフィールドを決定できることを意味します。

これは非常に強力です。CRMプロジェクトがあり、そこに顧客が支払う金額に関連するデータだけでなく、あなたのコストと利益マージンもあることを想像してください。コストフィールドとプロジェクトマージン式フィールドをジュニアスタッフに見られたくない場合、カスタム権限によりそれらのフィールドをロックして表示されないようにできます。

次に、弊社はリストベースの権限の作成に移りました。プロジェクト管理者がユーザーグループが特定のリストを表示、編集、削除できるかどうかを決定できるものです。リストを隠すと、そのリスト内のすべてのレコードも隠されるため、これは素晴らしいです。なぜなら、プロセスの特定の部分をチームメンバーやクライアントから隠すことができるからです。

これが最終結果です：

技術的考慮事項

Blueの技術アーキテクチャの中核にはGraphQLがあり、これはカスタム権限などの複雑な機能を実装する弊社の能力に大きく影響した重要な選択です。しかし、詳細に入る前に、一歩下がってGraphQLとは何か、そしてより従来のREST APIアプローチとどのように異なるかを理解しましょう。

GraphQL vs REST API：分かりやすい説明

レストランにいることを想像してください。REST APIでは、固定メニューから注文するようなものです。特定の料理（エンドポイント）を注文すると、すべてが欲しいかどうかに関係なく、それに付いてくるすべてを手に入れます。食事をカスタマイズしたい場合、複数の注文（API呼び出し）をするか、特別に準備された料理（カスタムエンドポイント）を要求する必要があるかもしれません。

一方、GraphQLは、何でも準備できるシェフとの会話のようなものです。欲しい材料（データフィールド）とその量を正確にシェフに伝えます。そうすると、シェフは要求したものを正確に – それ以上でもそれ以下でもなく – 準備した料理を作ります。これは本質的にGraphQLが行うことです – クライアントが必要とするデータを正確に要求でき、サーバーはまさにそれを提供します。

重要なランチ

Blueの初期開発の約6週間後、弊社のリードエンジニアとCEOがランチに出かけました。

議論のトピックは？

REST APIからGraphQLに切り替えるかどうかです。これは軽く取るべき決定ではありませんでした – GraphQLを採用することは、6週間の初期作業を破棄することを意味しました。

オフィスへの帰り道で、CEOはリードエンジニアに重要な質問をしました：「5年後にこれをしなかったことを後悔するでしょうか？」

答えが明確になりました：GraphQLが進むべき道でした。

弊社は、柔軟で強力なプロジェクト管理プラットフォームのビジョンをどのようにサポートできるかを理解し、この技術の可能性を早期に認識しました。

GraphQLを採用した弊社の先見の明は、カスタム権限を実装する際に配当を支払いました。REST APIでは、カスタム権限のあらゆる可能な構成に対して異なるエンドポイントが必要になったでしょう – 迅速に扱いにくく保守が困難になるアプローチです。

しかし、GraphQLにより、弊社はカスタム権限を動的に処理できます。その仕組みは以下の通りです：

オンザフライ権限チェック: クライアントがリクエストを行うとき、弊社のGraphQLサーバーはデータベースから直接ユーザーの権限をチェックできます。
正確なデータ取得: これらの権限に基づいて、GraphQLはユーザーのアクセス権内にある要求されたデータのみを返します。
柔軟なクエリ: 権限が変更されても、新しいエンドポイントを作成したり既存のものを変更したりする必要がありません。同じGraphQLクエリが異なる権限設定に適応できます。
効率的なデータフェッチング: GraphQLによりクライアントは必要なものを正確に要求できます。これは、ユーザーがアクセスすべきでない情報を潜在的に露出する可能性のあるデータの過剰フェッチをしていないことを意味します。

この柔軟性は、カスタム権限のような複雑な機能にとって重要です。パフォーマンスや保守性を犠牲にすることなく、詳細な制御を提供できます。

課題

Blueにカスタム権限を実装することは、それなりの課題をもたらし、それぞれが弊社にイノベーションとアプローチの改善を促しました。パフォーマンス最適化が重要な懸念として素早く浮上しました。より詳細な権限チェックを追加するにつれて、特に多くのユーザーと複雑な権限設定を持つ大規模プロジェクトでは、弊社のシステムを遅くするリスクがありました。これに対処するため、弊社は多層キャッシュ戦略を実装し、データベースクエリを最適化し、GraphQLの必要なデータのみを要求する能力を活用しました。このアプローチにより、プロジェクトが拡大し、権限の複雑性が増しても、素早い応答時間を維持できました。

カスタム権限のユーザーインターフェースは、もう一つの重要なハードルを提示しました。弊社は、より多くのオプションを追加し、システムの複雑性を増すにつれても、管理者にとってインターフェースを直感的で管理可能にする必要がありました。

弊社のソリューションには、複数回のユーザーテストと反復的デザインが含まれました。

弊社は、管理者が異なる役割とプロジェクト領域全体で権限を素早く表示および変更できる視覚的権限マトリックスを導入しました。

クロスプラットフォームの一貫性を確保することは、独自の課題セットを提示しました。弊社は、Web、デスクトップ、モバイルアプリケーション全体でカスタム権限を均一に実装する必要があり、それぞれが独自のインターフェースとユーザーエクスペリエンスの考慮事項を持っていました。これは、ユーザーの権限に基づいて機能を動的に隠したり表示したりする必要のあるモバイルアプリでは特に厄介でした。弊社は、APIレイヤーで権限ロジックを集中化し、すべてのプラットフォームが一貫した権限データを受け取ることを確保することでこれに対処しました。

その後、弊社は、これらの権限変更にリアルタイムで適応できる柔軟なUIフレームワークを開発し、使用されるプラットフォームに関係なくシームレスなエクスペリエンスを提供しました。

ユーザー教育と採用は、弊社のカスタム権限の旅における最後のハードルを提示しました。このような強力な機能を導入することは、ユーザーがカスタム権限を理解し効果的に活用するのを助ける必要があることを意味しました。

弊社は最初にユーザーベースのサブセットにカスタム権限をローンチし、彼らの経験を慎重に監視し、洞察を収集しました。このアプローチにより、全ユーザーベースにローンチする前に、実世界の使用に基づいて機能と教育材料を改善できました。

段階的ロールアウトは、弊社が予想していなかった小さな問題やユーザーの混乱ポイントを特定し対処するのに非常に価値があることが証明され、最終的にすべてのユーザーにとってより洗練されたユーザーフレンドリーな機能につながりました。

ユーザーのサブセットへのローンチと、弊社の一般的な2-3週間の公開ベータでの「ベータ」期間により、弊社は安心して眠ることができます。:)

今後の展望

すべての機能と同様に、何も「完了」することはありません。

カスタム権限機能の弊社の長期ビジョンは、タグ、カスタムフィールドフィルター、カスタマイズ可能なプロジェクトナビゲーション、コメント制御にわたります。

各側面を詳しく見てみましょう。

タグ権限

レコードが1つ以上のタグを持つかどうかに基づいて権限を作成できることは素晴らしいと思います。最も明らかな使用事例は、「顧客」というカスタムユーザー役割を作成し、その役割のユーザーに「顧客」タグを持つレコードのみを見ることを許可することです。

これにより、レコードが顧客によって見られるかどうかの一目でわかるビューが提供されます。

これは、AND/OR結合子でさらに強力になり、より複雑なルールを指定できます。たとえば、「顧客」AND「公開」の両方でタグ付けされたレコード、または「内部」OR「機密」のいずれかでタグ付けされたレコードへのアクセスを許可するルールを設定できます。このレベルの柔軟性により、最も複雑な組織構造とワークフローにも対応する、非常に微妙な権限設定が可能になります。

潜在的な応用は広大です。プロジェクトマネージャーは機密情報を簡単に分離でき、営業チームは関連するクライアントデータに自動的にアクセスでき、外部協力者は機密の内部情報にさらされるリスクなしに、プロジェクトの特定の部分にシームレスに統合できます。

カスタムフィールドフィルター

カスタムフィールドフィルターの弊社のビジョンは、詳細なアクセス制御における大きな飛躍を表しています。この機能により、プロジェクト管理者は、カスタムフィールドの値に基づいて、特定のユーザーグループが見ることができるレコードを定義できるようになります。これは、情報アクセスのための動的でデータ駆動の境界を作成することです。

次のような権限を設定できることを想像してください：

「プロジェクトステータス」ドロップダウンが「公開」に設定されているレコードのみを表示
「部門」多選択フィールドに「マーケティング」が含まれている項目への可視性を制限
「優先度」チェックボックスがチェックされているタスクへのアクセスを許可
「予算」数値フィールドが特定の閾値を超えているプロジェクトを表示

カスタマイズ可能なプロジェクトナビゲーション

これは、弊社が既に持っているトグルの単純な拡張です。「アクティビティ」と「フォーム」のトグルだけでなく、プロジェクトナビゲーションのすべての部分にそれを拡張したいと思います。これにより、プロジェクト管理者は焦点を絞ったインターフェースを作成し、必要のないツールを削除できます。

コメント制御

将来的に、弊社は顧客がコメントを誰が見られるか、見られないかを決定する方法について創造的になりたいと思います。弊社は、1つのレコードの下に複数のタブ付きコメント領域を許可し、それぞれが異なるユーザーグループに表示されたり表示されなかったりするかもしれません。

さらに、ユーザーが特別に言及されたコメントのみが表示され、他は何も表示されない機能も許可するかもしれません。これにより、プロジェクトにクライアントがいるチームは、クライアントに見せたいコメントのみが表示されることを確保できます。

結論

これが、弊社の最も興味深く強力な機能の1つを構築するためのアプローチです！弊社のプロジェクト管理比較ツールでご覧いただけるように、このような強力な権限マトリックス設定を持つプロジェクト管理システムは非常に少なく、持っているものは最も高価なエンタープライズプランのために確保し、一般的な中小企業にはアクセスできません。

Blueでは、弊社のプランですべての機能をご利用いただけます – エンタープライズレベルの機能はエンタープライズ顧客のためだけに確保されるべきではないと弊社は信じております！