はじめに
こんにちは、NTT東日本デジタル革新本部のTamaちゃんです。
2025年度に入社、現在はOutSystemsを用いた社内業務システムの開発に携わっています。
OutSystemsはローコード製品のなかでもアジリティや品質を高く開発できるため、開発ドキュメントについて何を残すべきか課題になることが多いと思います。
実際に私が参画したシステムの追加開発プロジェクトでは、ドキュメント作成が後回しで機能拡張が繰り返され、ほぼ設計書が存在しない状態でした。そんな中、開発体制拡大に向けてリバースエンジニアリングを行い、ドキュメント化に取り組んだため、その際のノウハウを共有いたします。
この記事は OutSystems Advent Calendar 2025 の 20日目の記事です。
利用環境
- OutSystems11
- Service Studio 11.55.36
課題：ドキュメントがないとなぜツライ？
新規参画者がツラい
OutSystemsは画面・ロジック・データが強く結びついています｡Service Studioから分かる通り、GUIで単一処理を追いやすいことが特長といえます。一方で、設計の全体像を掴もうとすると､
- 画面を開く
- フローを1本ずつ追う
- 依存関係を自力で頭の中で整理する
という｢読むコストの高い作業｣が発生します｡
結果として､第三者にとって設計の見通しが良いとは言えないと感じました｡
影響調査がツラい
開発規模が大きくなると、
- このロジックはどこから呼ばれているのか
- このエンティティを変えると､どの画面に影響するのか
といった全体の影響範囲を特定するなど、自身が開発していない部分含めて全体を見て対応することが求められます。
スクラム開発ではスプリントごとに小さな変更を積み重ねますが､影響範囲が見えにくい状態では､変更判断の心理的コストが高いと感じました｡
対応①：ドキュメント作成で全体像を可視化
私が参画したプロジェクトではまさに開発体制が拡大するタイミングだったため、追加開発前にリバースエンジニアリングをして以下のドキュメント化に取り組みました。
- エンティティ定義書
- ER図
- 機能設計書
エンティティを俯瞰できる資料
ER図はService Studioから参照できるEntity diagramを使用しました｡
画像としてのダウンロードも可能なため簡単に転用が可能でした｡
また、今回エンティティ定義書の作成基盤として、forgeに公開されていたOutdocを使用しました｡
- 良かった点： Excel 方式で動的エンティティの基本情報がダウンロードが可能
- 課題： 静的エンティティは未対応、Excelの文字制限で正式名称が取得できない
処理の意図が言語化される資料
ボタンやリンクをクリックして内部を覗きに行ける直感的な操作は便利ですが､
- 階層が深い
- SQLに依存する設計が多い
となると、自分が今どこの何の設計を見ていたのか？を見失いやすかったです｡
そのため、Service Studioだけではなく、処理を言語化した資料の必要性を感じました。
機能設計書の作成により、新規参画者にとって処理の意図の把握が容易になると考えます。
対応②：便利機能でリバースエンジニアリング効率化
ドキュメント化のためのリバースエンジニアリング時に用いたService Studioの便利機能たちを紹介します。
- ダブルクリック
- とにかくLogicの追跡にはこれ
- 右クリック
- ダブルクリックで辿れなくなったと思ったらこれ
- Entity/Actionの呼び元をたどる
- ショートカット
OutSystems公式ショートカット集↓
特に私がよく使っていたのは以下です。
- Ctrl+F：検索
- Ctrl+R：検索置換（画面中央にポップするのが好みで検索としてよく使った）
- Ctrl+F12：Find Usages
まとめ
- 開発体制の大きさに伴い、ドキュメンテーションの重要度は上がると考えます。今回はあくまでも一例なので、組織の特性に応じてドキュメント戦略を考えてみるのも良いと思いました。
- OutSystemsの開発者支援機能に助けられ、新規参画者でもリバースエンジニアリングはなんとかやりきれましたが、設計の思想が統一されていない部分では苦労もしたので、第三者も理解できるきれいな設計が何より大事なことも学びになりました。
- OutSystemsでリバースエンジニアリングが必要になった時には、この記事をぜひ思い出していただければと思います。
※記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。