業務システムの画面仕様をコードベースで書けるようにして開発者体験を爆上げした話

はじめに

• 業務システムの要件定義をする際に、開発者体験を向上させる取り組みとして「Javaのコードで定義し、画面仕様（画面モック）とソースコードのひな形が出力できる」というコンセプトを試したくて、実現するツールを試作しました。
• 注意点として、BtoCのような自由度の高い画面仕様を検討するものではなく、BtoBで業務でのみ利用する用途におけるシステムの画面仕様定義といったシーンに限られる感じです。過度にUI/UXを求める場合は、向いてないと思います。
• このコンセプトが開発者体験をどの程度向上されるのか、実プロジェクトに適用して検証してみた結果を報告します。

画面仕様をコードベースで書くとは何か？

業務システムの要件定義において、重要な要素として 「画面仕様を決める」 があります。
いざ、画面仕様を書くとなるとパワーポイントで書いたり、エクセルで書いたり、最近だと、詳しくないですが、Adobe XD とかで書くのでしょうか？

パワーポイントやエクセルでの限界は、差分管理（把握）やコンポーネントの再利用には難があります。一方、Adobe XD はこの点良さそうですが、私自身非デザイナーのため、ツールのハードルが高いです（あと、有料ツールは避けてしまいがちなのと、単に食わず嫌いでしょうね ）。

そこで、エンジニアの端くれとしては、「コードで書ければいいんじゃないの？」っていう結論に至ります。
そんなわけで、Javaのコードを書くと画面仕様書とアプリケーションのひな形を作ってくれるツールを試作し、このコンセプトを検証することにしました。

全体構成と具体例

試行ツールの全体イメージは下記の通りです。画面仕様をJavaのソースコード定義を書くと、画面仕様書の生成やソースコードのひな形生成ができます。また、チェックツールを通して、仕様の中身を検証できます。

次に、具体的なコードと生成された画面を見ていきます。

Sample.java

        // 画面仕様の基本を定義
        FreeStyleView freeStyleView = new FreeStyleView("サンプル");
        List<RowGridSystem> gridSystemList = new ArrayList<>();

        // 検索条件
        InputText inputText = InputText.buildSimply("テキスト");
        SelectOne productSelect = SelectOne.buildSimply("候補選択");
        productSelect.addSampleData("候補1", "候補2", "候補3");
        Button add = Button.buildSimply("絞り込み");

        // テーブルの作成
        DataTable dataTable = DataTable.buildSimply("テーブルサンプル",
                List.of("項目1","項目2", "項目3", "項目4", "項目5")
        );
        dataTable.setPaging(false);
        dataTable.addSampleData(
                List.of(
                        List.of("項目1サンプル", "項目2サンプル", "項目3サンプル", "項目4サンプル", "項目5サンプル"),
                        List.of("項目1サンプル", "項目2サンプル", "項目3サンプル", "項目4サンプル", "項目5サンプル"),
                        List.of("項目1サンプル", "項目2サンプル", "項目3サンプル", "項目4サンプル", "項目5サンプル"),
                        List.of("項目1サンプル", "項目2サンプル", "項目3サンプル", "項目4サンプル", "項目5サンプル"),
                        List.of("項目1サンプル", "項目2サンプル", "項目3サンプル", "項目4サンプル", "項目5サンプル"),
                        List.of("項目1サンプル", "項目2サンプル", "項目3サンプル", "項目4サンプル", "項目5サンプル")
                )
        );

        // グリッドシステムに倣って、12分割でコンポーネントを配置
        gridSystemList.add(new RowGridSystem(RowGridSystem.create(productSelect, 3), RowGridSystem.create(inputText, 3),RowGridSystem.create(add, 1)));
        gridSystemList.add(new RowGridSystem(RowGridSystem.create(dataTable, 12)));
        freeStyleView.addSection(new DefaultViewSection("セクション1", "section1", gridSystemList));

↓　のように変換されます。

※ 画面仕様を定義するAPIには、ボタンを押した際のイベント定義などを記載できるI/F等、様々なI/Fを用意していますが、割愛しています。

プロジェクトへの適用

• 実際のプロジェクトに適用し、約74画面程をこのツールで定義し、仕様確認＆ソースコードひな形生成を実施しました。
  • 生成した画面仕様を利用して、顧客と共に仕様確認および仕様の確定を実施しました。
  • 生成したソースコードひな形をベースに、アプリケーションの構築を実施しました。

　開発者体験が向上したポイント

• 画面定義用のコードさえ書けば、画面仕様定義書を自動生成するので画面仕様を作るコストが大幅に下がりました。
• 換言すれば、画面仕様検討に必要な要素に集中して記入できた（定義できた）と言うことも言えます。
• エクセル仕様書を作ると意外と体裁を整えたりする作業に時間が割かれます。。。
• 画面仕様定義に対してのレビューが容易になった。
• 仕様の記入漏れ、日本語の表記揺れなどチェックツールを作成し、発見と修正するのが容易でした。
• アプリケーションのひな形（基本的なhtmlファイル、対応するjavaファイルなど）を作成できるので、初期の開発スピードが加速しました。
• このような自動生成系は、多くのSIer等で昔から実現していることであり、業界的には特段目新しい成果ではありません。
• 新規性という観点では、画面仕様（プロトタイプ）　→　アプリケーションのひな形　とシームレスに繋がる点でしょうか。（類似ツールに似たような仕組みがあるので、新規とも言えないかもですが・・・）
• バージョン管理ツールで、ソースコードとして管理できるので、変更点を共有し易い、複数人での共同作業しやすいという利点がありました。
• エクセルやワードでは差分管理、共同作業はかなり辛いですよね。。。

　開発者体験が向上しなかったポイント（キツイポイント）

• 業務フローや機能概要や要件等から画面仕様を起こしていく際に、コードベースで考えていくと画面の具体的なイメージが沸かなくて辛いです。やはりGUIでコンポーネントをドラッグ&ドロップして画面を作成して行くようなツールの方が、その点は思考がまとまり易いと思いました。
• 簡素な画面（画像）では顧客にとって、業務上の具体的な操作イメージが沸きにくい点がありました。特に業務システムになれていない場合は、その傾向が顕著に出るような気がします。そういった意味では、ハリボテでも良いので、実際の画面の方がイメージ沸き易いのでしょうが、作成コストが高く付きますね。。。

類似ツールとの比較

試作ツールを作る前に少し市場調査をしてみました。優れたツールが沢山ありますが、なかなか無料で使えるものが無い点が痛いです。また、画面モックアップツールを除いては、ツールの習熟コストも高そうです（Adobe XD のように慣れたら早いのでしょうが。。。）。

ちょっと長いので、詳しく見たい方はどうぞ。。。

• 画面モックアップツール WireframeSketcher
• ドラックアンドドロップで画面を作成できます。年間99ドル(次年度以降30ドル位)と安価なので試作ツールを作る前はよく使っていました。
• ボタンを押下した際の仕様などはメモ書きとして付記するしかなく、仕様を作っていく面では少しサポートが弱いと感じます。この試作ツールでは、このドラックアンドドロップで画面を作っていく大切さを実感しました。
• Wagby、WebPerformer、OutSystems、GeneXus等に代表されるローコードツール(ノーコードツール)
• ローコードツールは、要件定義をサポートするツールではなく、要件定義の内容から実物を作っていくスピードを上げるためのツールと認識しています（ここは各ツールによって若干立ち位置が違うかもしれませんが）。テーブル設計が固まっていることを前提として、画面を構成する思想だと認識しています。
• 試作のツールでは、概念テーブル定義と画面仕様を往き来しながら試行錯誤する位置付けです。（これらのローコードツールも、概念テーブルを作りながら画面を作っていくことは不可能では有りませんが、メインとなる機能ではないはずです）
• ローコードツールの値段は、一般的に高いため導入が難しいです。（Wagbyは、他のツールに比べ安価なようですが）
• 上流工程支援ツール XupperⅡ
• 上流工程のあらゆる成果物をツール上で作成することができそうで、良さそうです。
• 導入しているところ含め、大手向き/大規模向きという感じで、高機能で全面的にXupperⅡに優位があると思います。お金があれば導入してみたいです。
• 設計支援ツール
• 設計支援ツールでは、「システム開発の設計書を作成するCADツール SI Object Browser Designer」や「システム設計支援ツール VeraSym System Designer」があります。
• いずれもGUIを用いて画面仕様を作り込むことに留まらず、仕様を作り込むための仕掛けが用意されています。画面仕様をモックアップとして出力したり、画面仕様書としても出力したりすることも、もちろん可能なようです。
• XupperⅡ同様に、有用なツールに間違いないですが、こちらも、いずれにせよ高価で、気軽にポンと導入できるものではありません。。。

まとめ、今後の展開・課題

• 伝統的な？泥臭い（業務フローを定めてシステムを起こしていく様なプロジェクト）、業務システムの現場においては、一定の開発者体験が向上したと感じています。
• 体感値ですが、画面仕様書を手書きで作成したり、仕様漏れなどの手戻りを予め防げたり、コード生成による削減などの効果を含めて、ツールを導入しない場合に比べて、要件定義・設計・実装の工程を含め約3割程度のプロジェクト工数を削減できたのではないかと思っています。
• 今後は、画面定義用のGUIツールを追加開発し、改善していきたいと思います。
• ある程度のものになったらオープンソースとして公開したいなと思います。