OutSystems CoEチームの技術的サポート

2025/07/07 OSUG Tokyoセッションスライド。
「各開発チームで対応するには厳しく、CoEなどの専門知識を備えたチームに集約して対応した方が効果を得られそうな領域」について経験にもとづき共有。

Transcript

1. OutSystems CoEチームの技 術的サポート OutSystems東京開発者コミュニティ 2025/07/07 OutSystems MVP 渡部 潤司 : https://qiita.com/jyunji_watanabe : https://twitter.com/JyunjiW : https://www.linkedin.com/in/watanabejyunji/ Qiita X LinkedIn
2. 本日の内容 これまでの経験と知識から、 「各開発チームで対応するには厳しく、CoEなどの専門知識を備えたチームに集約して対応した 方が効果を得られそうな領域」 について、話します。 ただし、時間的な制約から、技術を深掘りするような領域を対象とし、統制を効かせるような内容 （開発標準策定、レビュー等）は今回は対象外とします。
3. 本日の内容 1. 部品作成 2. 調査・検討 3. トラブルシュート 4. プロジェクトに対する技術的支援
4. 1. 部品作成
5. 基盤的な部品開発 • 多くのアプリケーションから参照される、影響範囲の大きい部品であるため、OutSystemsに 詳しいメンバーでパフォーマンスや保守性に気を配りつつ開発したい • 認証、ログ • Custom Application Template: 文字通りアプリケーションのテンプレート。必要な部品、 標準的なUI、標準的な実装パターンを組み込んでおく事で、開発者の手間を省き、チームご との実装方法のぶれを減らす • スタイルガイド: Theme、標準UI部品、UI実装のガイドなどをまとめたもの。必要ならその動 作するドキュメントとして、Live Style Guide
6. OutSystems外の知識が必要な部品開発 • OutSystemsの開発プロジェクトなので、OutSystems外の、かつ主要業務から離れる開発 については、リソースをCoEに集めて開発 • C#開発:サーバーサイドのロジックを作るには、C#でExternal Logicを作成する（例: ExcelやWordを操作する部品） • JavaScript開発:クライアントサイドで動作するロジック、UI部品等はJavaScriptで部品作 成する（例:JavaScript部品を組み込んでリッチテキストエディタ作成など） • 外部連携:Data Fabric、場合によってはC#開発。オンプレミス連携が含まれるなら Private Gateway利用も考慮した連携を行う
7. Forgeコンポーネント調査 • 一部統制的な話題でもあるが、OutSystemsのOSSレポジトリであるForgeからコンポーネン トを探したり、見つけたコンポーネントの調査を行ったりする • 内部でライセンスが必要なライブラリを使っていないとは限らない • セキュリティ的な観点でのチェック（OutSystems・C#・JavaScript等で複雑な実装を行っ ていることもあるので、それを踏まえて） • 使い方の調査
8. 2. 調査・検討
9. 新機能 • プラットフォームが、追加してくる新機能について、使い方・効果・制限を調査する • そもそもその環境で使えるのか? • 使うとなったら、部品やルールの整備、使い方のガイドを用意する • 例:最近のODCの新機能でいうと、Group単位のIP Filter、Mentorの生成AI機能など
10. 特定テーマについて、OutSystemsでの実現方法を検討 • CI/CD、自動テスト（ユニット、E2Eテスト）など、特定テーマについて、OutSystemsで実 現可能か、可能ならその方法と制約などについて調査する • 例えばユニットテストの自動化であれば、Forgeにあるいくつかのコンポーネントを調査することに なる。基本的には公式で推奨されているBDDFrameworkを使うが、開発負荷・実行速度 ともに一般の開発言語のユニットテストよりも劣る。それを踏まえても利用する価値があるかも 検討する
11. 3. トラブル対応
12. 障害対応 • 内容はタイトル通りなので、厄介なエラー例をいくつか • Global Exception Handler配置漏れによる未処理例外発生時のエラー • 厄介なタイミングでのタイムアウト発生によるエラー • Reactive Web Appのサーバ側での無限ループで止まらなくなる • Extensionに含まれるdllが競合を起こす • 特殊条件でApplication Poolがクラッシュする
13. パフォーマンスチューニング • 個別性が高いので、これも例をいくつか • Server ActionにCache in Minutesを設定することで、複雑な計算を要するが同じパラメ ータならしばらく同じ結果を返しても大丈夫な処理にキャッシュを効かせる • Cache in Minutesはフロントエンドサーバーのメモリにキャッシュさせるが、代わりにEntityにキ ャッシュする方法もある • Server Request Timeoutに収まらないリクエストを非同期化することで正常終了させる • C#処理が時間がかかりすぎ、エラーになってしまう問題
14. 4. プロジェクトの技術的な支援
15. 設計・実装方法のガイド • AI Mentor Studio・Code quality指摘事項がわかりにくいとき、理由や回避方法の説明 を行う（例:Client Actionに複数のサーバー呼び出しがあるときの指摘について、説明や回 避策の説明を行う） • 実現したい要求を聞いて、OutSystemsの標準機能・ベストプラクティス・共通部品で実装で きるか検討し、説明を行う。場合によってはサンプルを作ったり、調査を行う
16. 一部機能の実装 • ベストプラクティスや内部の標準に従った設計・実装例の提供 • 共通部品にするほどの需要はないが、特殊な知識が必要な部分の担当（C#で提供されて いるライブラリを要する開発だが、他のプロジェクトでは需要がなく共通部品化される見込みは ないような場合。CoEからプロジェクトに参加して部品開発をすることもある）
17. まとめ
18. まとめ • 経験上、開発プロジェクトのメンバーで個別に対応するより、CoEメン バー等が対応した方が良い可能性のある領域を見てきました ◦ 部品作成 ◦ 調査・検討 ◦ トラブル対応 ◦ プロジェクトの技術的な支援
19. 以上