OutSystemsのサイトからダウンロードできるThe Talent Playbook (Version 1.1 2020/9) を読んで見る。
OutSystemsを使う開発プロジェクトチームを作るために、メンバーを探すプロセスについてまとめたもの。
Part 1、Part 2の2つあり、この記事はPart 2を対象とし、読みながら気になった部分をメモ。
Part 2はPart 1で築いた開発チームをさらに発展させていくための、より高度な機能を果たすCoEメンバーの育成・獲得方法についてまとめたもの。
いくつかの新しい役割が追加されているが、「possible accitional roles（P.5) 」についての話なので、どの会社でも専任の人を割り当てる必要があるわけでなさそう。
Architect (アーキテクト）
（OutSystems利用アプリケーションの）全社的なアーキテクチャ標準を決め、開発チームに守られるようにする人。
この役割をするのに、私の感覚では
- OutSystemsのベストプラクティス・制約事項・アーキテクチャ手法
- その会社の既存のアプリケーションや開発標準、歴史的事情
- OutSystems以外の重要なシステム要素（主にDBやネットワーク等）
の知識とスキルが必要だと思います。会社の規模と歴史にもよるでしょうが、一人で兼ねるのは難しいのではないでしょうか。するとCoEにこれらの要素を持つアーキテクトを何人か確保する必要がありそう。
UX/UI Designer
CoEメンバーとしての、UX/UI Designerということなら、会社全体のTheme (CSS定義のセット）やStyle Guide/Live Style Guideを作っていくことになるのかな？
Style Guide周りはあちこちで言及されるわりに、明確な定義をあまり見ないんだけど、会社・ドメイン・プロジェクト等の単位で、Theme・Patterns (UI部品）・テンプレート・デザインルール等をまとめたドキュメントと成果物、という感じ。
Live Style Guideは各開発者が操作できるアプリケーションとして提供するもの（例えばPatternsであれば利用可能な部品がイメージや実際に動作する形で一覧され、クリックすると使い方が見れたりする）。
業務アプリケーションだと、あまり見た目に力を入れないことが多いと思うので、Themeを頑張ってカスタマイズするのは見かけない。