テックブログ

効果的なアーキテクチャレビューボードを構築する

本ブログはJoe Castroが寄稿した記事を抄訳したものです。 原文 ”Tips for an Effective Architecture Review Board” はこちらからご覧いただけます。

 

Tech-Blog-Images_6-768x480

 

あなたの会社ではSalesforce環境に他のシステムを統合していますか?VisualForceのカスタムページやLightningコンポーネントを活用していますか?トリガーやクラスにどのくらいApexを使用していますか? 開発を扱う部署は複数存在しますか?Salesforceの担当部門で行うカスタマイズが有用な機能を開発し、他方、そのカスタマイズが会社の事業目標や技術戦略と矛盾しないようにするためには、アーキテクチャレビューボード(ARB)の設置は検討に値する選択肢です。ARBはさらに、本質的に異なるワークストリームが複数存在する場合、方向性の共有やコラボレーションを促進する一方、機能の衝突や重複を避けるための中継地としても機能します。ARBなくしては、共通のデザインパターンや開発標準の活用を徹底させることは容易でなく、結果、技術的負債を蓄積させることにもなりかねません。要するに、ARBは社内で現在実装中の機能を見える化するための効果的な方法となりうるのです。

 

しかしながら、実際のARB運用は簡単な話ではありません。以下によくある問題を掲げます。

  • 未処理の案件が多いとARBが決済用の“ゴム印”のようになってしまう。
  • IT部門と事業部門が同じ目標を共有できないとARBが衝突を引き起こしてしまう。
  • ARBの審査案件で未処理が発生すれば、結果的に、開発サイクルの中では実装するにはもはや遅すぎる提言が行われることになる。多くの場合、これは技術的負債の増加につながる(そして返済はほぼ期待できない)。
  • 運用上の問題。開発部門が持ち出さない限り、ARBは審査すべき案件が存在することさえ知らずにいる。

 

上述の課題を克服するためにARBができることを以下に提案します。

ARBはまず、審査の指針と開発標準を定義、公開し、開発部門がARBの承認を要する案件とそうでない案件とを判別できるようにする必要があります。指針や標準の定め方は組織によって異なり、変容する組織のニーズに適応するため、継続的に見直さなければなりません。例えば、設置当初のARBは非標準のUI(VF/Lightning コンポーネント)をすべて審査の対象とするかもしれません。この組織が「ピクセルパーフェクト」のコミュニティを新しく作る場合、SLDS、Bootstrap、SlickGridを活用したコミュニティUIに対応するために標準を更新することもあるでしょう。一般的に、ARBはインテグレーション案件、データサイズの大きいオブジェクトに触る案件、脆弱なコード、複雑なコード、古いコード、基幹業務の遂行に不可欠なビジネスプロセスの審査をしたがるものです。

さらに、ARBの審査を必要とする案件(例えば、VFページ、Apexクラス、Apexトリガー、検証ルールなど)の抽出は自動化すべきです。新規のファイルや変更したファイルを特定するにはソースコントロールが有効でしょう。私自身、SalesforceのTooling APIとメタデータAPIを活用し、新規の案件と変更した案件をUPSERTでMetadata Artifactカスタムオブジェクトに抽出したことがあります。ただし、この方法で抽出する案件は数が多すぎて個別に審査できない場合があります。このため私はArtifact Groupカスタムオブジェクトを作成しました。Artifact Groupに焦点を当てて審査をすれば、例えば2つのVFページ、14のApexクラス、2つのトリガーを伴うカスタマイズを一気に処理することができます。審査する案件をさらに絞るには、“Ignore Until”で承認年月日を設定し、それまで無視してよい案件を指定します。この設定を行うと、Metadata Artifactに変更をUPSERTするプロセスは承認済みの案件と無視してよい期日内の案件を無視します。その他の案件にはARBによる審査が必要な案件としてフラグが立ちます。(「カスタマイズを監視してSalesforce組織を保護する方法」については次回のブログでご紹介します。)

ARBの規模は意志決定の権限を有する必要最低限の人数に制限するのが望ましいと考えます。事業部門とIT部門の代表者には必ず参加してもらいましょう。事業への影響を正しく評価せずに、カスタム開発に関する意思決定を行うのは困難です。ARBの委員が6人から8人を超える場合は、審査委員会を(地域別あるいは事業部門別に)分けて、他の地域や部門に影響しない案件の審査を任せ、全体を統括するARBが連絡役を担うことも検討しましょう。地域別・部門別のARBは審査の指針と開発標準を整備するため、定期的に集合するようにしましょう。

ARBが行う個々の意志決定は指針に反映させることが重要です。将来の開発部門がARBの承認を得られるタイプの案件とそうでない案件を理解できるようにするためです。また、望ましくない前例を作らないことも重要です。どうしても必要な機能の開発を認めるために譲歩を要するなら、例外を許した文脈や理由、あるいは承認に際して設けた条件があるならその条件も含め、これらを周知させなければなりません。例えば、ポイントツーポイントのインテグレーションを、今現在利用できるミドルウェアがないという理由で承認するとします。であれば、これはミドルウェアの評価と調達サイクルが完了し次第、修正を要する「技術的負債」として承認すべきでしょう。

 

以下に効果的なARBを要約します。

  1. 開発部門が参照するための指針と開発標準を公開し、定期的に修正する。
  2. ARBのプロセスを自動化し、その無効化を防ぐ。
  3. 案件のグループ化や絞り込みにより、審査する案件数を抑制する。
  4. 事業部門とIT部門から適任者を任用し、必要最低限の人数で構成する。

皆さんのARB構築がうまくいくように祈ります。引き続き、ARBに関する投稿にご期待ください。

 

About Appirio

Appirio

アピリオはクラウドコンサルティングのグローバル企業で、ITサービスを提供するウィプロの一員です。お客様の次世代のワーカー・エクスペリエンスおよびカスタマー・エクスペリエンスの実現を、最新のクラウドテクノロジーを活用して支援します。アピリオの自由な発想を持つコンサルタントは、実用的な戦略の立案、迅速な成果の提供、そして消費者のエクスペリエンス主導で急速に変化する今日のビジネス状況において企業がいかに早く適応できるかを支援することで、比類のない顧客価値を提供します。これは、世界最大級のクラウドソーシングコミュニティであるTopcoderのパワーと、数千からなるプリビルトされたソリューションを駆使することで実現します。アピリオはYP, Cardinal Health, Coca-Cola, eBay, Facebook, Home Depot, Sony PlayStation, Moen, IBMなどの世界最大ブランドから信頼されるパートナーです。

Appirio