はじめに

このドキュメントは、Nablarchを使ってシステムを開発するエンジニアに対して、開発開始前・開発中になにをすべきか、なにを参照すれば良いかを示すものです。Nablarchを使ったシステム開発に必要と考えているアクティビティについて、多くのプロジェクトで最適と思われる進め方を記載しています。 多くのNablarch利用プロジェクトの特性を踏まえて、開発プロセスはウォーターフォール開発を想定しています。 プロジェクト本格開始前にこのドキュメントを一通り確認して、開発をどのように進めるか検討してください。

このドキュメントのねらい

このドキュメントは以下の項目を達成することをねらいとしています。

  • Nablarchで提供しているコンテンツ（開発標準やチェックツールなど）が有効活用されること
  • Fintan、Nablarchのコンテンツを組み合わせた最適な使い方が明示されていること
  • Nablarchの得意領域である外部設計～PGUTについては最適な進め方が明示されていること
  • Nablarchとしてのテストの有効なやり方を明示できていること
  • Nablarchの未経験者（アプリ開発の経験あり）が迷わず最短経路で開発準備と開発推進を実施できること
  • 他のフレームワーク（Xenlon、Seaser、Spring）の利用経験がある人がNablarchの使い方を間違わないようにガイドされていること

このドキュメントの対象読者

Nablarchを使ったシステム開発を始めようとしているエンジニア（特にITアーキテクト、プロジェクトマネージャー）を対象としています。

読み方の注意点

このドキュメントには多くのリンクが存在します。最初に読み進める段階でリンクを追っていくと、リンク先のドキュメントも多いため、 全体像をつかみにくくなります。最初はあまりリンク先に飛ばず「こんなリンクがあるんだな」くらいの認識で、このドキュメントを最後まで読むようにしてください。

全体像

プロジェクト開発で必要となる成果物やタスクは多岐にわたります。 以下に挙げるのは、中規模のシステム開発を想定したサンプルプロジェクトにおける開発の流れを示した図です。 プロジェクトの開発の流れを検討する際の参考にしてください（最初は図の要素全てを理解する必要はありません。工程毎に成果物やタスクがあることを掴めれば十分です）。

プロジェクト計画

ウォーターフォール開発に必要な作業を漏らさないことを目的として役割分担を決めるシートです。担当間の認識の相違をなくし、リスクの早期発見、問題拡大の未然防止を図ります。

要件定義工程

要件定義

業務/システム要件定義の進め方、成果物、活用技法、ノウハウを体系的かつ実践的なレベルにまとめたガイドラインです。

実践的な要件定義知識やテクニックを解説した資料です。

非機能要件

性能要件やセキュリティ要件などの非機能要件が固まっていない状態で方式設計を行っても、方式設計は完成しません。 非機能要件定義には、IPAから提供されている非機能要求グレードを参考にしてください。

方式設計

方式設計は、以下のサンプルを参考にして行います。

ただし、プロジェクトの非機能要件を方式設計に落とし込んでいく必要があるため、このサンプルを修正して方式設計完了としてはいけません。サンプルをコピー、修正して方式設計書を完成させるというやり方をすると、必要な非機能要件を漏らす、不要な方式設計を記載してしまう、というミスが発生します。

サンプルをコピーするのではなく、サンプルから流用できる箇所、参考にできる箇所を抽出し、プロジェクトの方式設計書へ持ってきて完成させるようにしましょう。プロジェクトの非機能要件を元に方式設計の見出しを作成し、サンプルを参考にできる箇所は参考にし、プロジェクト固有の要件で検討が必要な箇所は検討結果を記載し、プロジェクトの方式設計書を完成させます。

特に、性能やセキュリティについては上記サンプルではカバーしていないので、特に注意が必要です。 方式設計サンプルの記述に追記するか、別冊として「方式設計書（セキュリティ設計）」のように別途作成するなどします。

セキュリティ設計については、IPAの「安全なウェブサイトの作り方」を参照してください。 「セキュリティ実装 チェックリスト」の全項目が「根本的解決」となるように設計します。
セキュリティ設計を補助するために、チェックリストの項目がNablarchで提供される機能で対応可能かどうかを「Nablarch機能のセキュリティ対応表」として示します。プロジェクトではNablarchで提供される機能が有効になるよう設定するとともに、機能が提供されない項目について対応を検討してください。
また、IPAの「安全なウェブサイトの作り方」と重複はありますが、「OWASP Top10」も参考となります。

Nablarchパターン集

Nablarchでよく使われるパターン、および、やってはいけない（がやってしまいがちな）アンチパターンを紹介します。 使い方を誤って設計、プログラミングをすると、大きな手戻りや性能不良、最悪の場合は本番障害となる恐れがあります。 設計開始前に本項を一読しておくことをお勧めします。

プロジェクト成果物の確認

Nablarchをプロジェクトで使用した経験がない場合は、ここでサンプルプロジェクトを参照し、 実際のプロジェクト成果物を確認しておきましょう。 特に以下の点に着目して参照すると効率が良いです。

  • プロジェクト用に作成した開発ガイド
  • プロジェクト用にカスタマイズした単体テスト仕様書
  • 設計書とソースコードとの対応関係

これらを確認することで、今後の作業のイメージが湧きやすくなります。

サンプルプロジェクトに関する注意事項

サンプルプロジェクトの成果物を、何の検討もせずに流用してはいけません。

サンプルプロジェクトの成果物は、サンプルプロジェクトの要件と特性を踏まえて、Nablarchの設計標準をカスタマイズ、または独自に作成したものです。

プロジェクトの要件や特性が同じということは無いので、 何も考えずにコピーして流用すると、必ず自身のプロジェクトと合わない箇所が出てきます。 この場合、以下のような問題が発生します。

  • プロジェクトに不要なルールが含まれており生産性を落としてしまう
  • プロジェクトに必要なテスト観点が漏れており十分な品質が確保できない
  • 不明な記述があるが誰も理由や経緯を答えられない。

必ず、自身のプロジェクトの要件と特性を踏まえた上で、標準化やガイドを新規で作成するようにしてください。 その際、サンプルプロジェクトは、コピー元としてではなく、参考用途に使用してください。

テスト計画

アプリケーション開発プロジェクトの、全体テスト計画で検討すべきトピックを解説したコンテンツです。

アプリケーション開発で使用可能なテストの種別と観点を整理したカタログです。

テスト方針の検討

一般に、テストにおいて品質とコストはトレードオフの関係にあります。
プロジェクトの特性にあわせてテスト方針を検討する必要があります。

Nablarch Testing Framework を活用するテスト方法（以下、重厚型と呼称）には、テストデータ作成やメンテナンスが高コストである課題がありました。
サンプルプロジェクトでは、品質を極力犠牲にせずに自動テスト整備の工数を削減できる軽量なテスト方式を採用しています（以下、軽量型と呼称）。

「重厚型」と「軽量型」のどちらをプロジェクトで採用するかは、システム規模や変更量に応じて検討する必要があります。

■重厚型
テストクラス、テストデータを作成し自動テストを実行します。
データベースやファイルだけでなく、ログ出力やリクエストスコープ等、システム内部の状態まで細かく確認できます。
ただし、作成する成果物や確認ポイントが多くなる分、変更が発生した場合の修正量が多くなります。
【重厚型に適した条件】
  • 大規模
  • 変更が少ない
  • 粒度の細かい回帰テストが必要
ほとんどのパスを自動テストで実行できるため、確度の高いリグレッションテストが求められる場合に適しています。
特に大規模プロジェクトで、フレームワークやライブラリ、ミドルウェア等のバージョンアップ時の回帰テストに有効です。重厚型のテストについては以下を参照ください。

■軽量型

手動テストで確認する点については、できるだけ自動テストを省略して省力化を図っています。
一般に、自動テストが減少すると回帰テストのコストが高騰してしまいますが、
少ないコストで回帰テストを整備できる仕組みを用意しています。
手動のブラウザ操作記録をもとに回帰テストを実行できます。

【軽量型に適した条件】
  • 小中規模
  • 変更が多い
軽量型のテストについては以下を参照ください。

プロジェクト用の開発ガイド作成

開発者がプロジェクトを進めるために必要な情報を集約したガイドを作成します。 作成例はサンプルプロジェクトの以下をご覧ください。

設計工程

各工程の開始に間に合うよう、標準化作業を進めます。 以下の標準をベースにして、プロジェクト用にカスタマイズします。

特にアプリケーション開発標準を参照してください。

ここにはDB設計標準やUI標準等、重要な設計標準ドキュメントが含まれています。

特にUI標準については、設計工程が本格化する前に展開しておく必要があります。 標準が無い状態で設計を進めてしまうと、画面レイアウト等のUIが設計者やカウンターのお客様ごとに異なってしまいます。 （例：ボタンの配置位置、確認画面や完了画面の有無、必要以上にリッチなUI機能） これらは、後で統一するためにお客様承認が必要となる場合や、横並び修正が発生する場合があります。 一度提示してしまったUIを撤回できないこともあり、この場合、PGUT工程で個別の作り込みが必要となり工数オーバーするといったリスクがあります。
参考：UI標準のカスタマイズ

カスタマイズ例はサンプルプロジェクトの以下をご覧ください。

アプリケーションのパッケージ構成については「パッケージ構成検討」を参照してください。

単体テスト標準

どのようなテストを実施するかは、プロジェクトの特性によって大きく変わります。 テスト標準作成の際には、以下の項目を参照してください。

アプリケーション開発標準配下の「単体テスト標準」は大規模向けに重厚型(*1)のテスト方針を採用しています。
一方、サンプルプロジェクトは軽量型(*1)のテスト方針を採用しています。

*1: テスト方針の検討を参照。

PGUT工程

Nablarchプロジェクト初期構築

Nablarchを使ったプロジェクトの初期構築を行います。 こちらを参照してください。

チーム開発環境構築

Gitリポジトリやチャット等、チームで開発するための環境を構築します。

開発環境構築ガイドの作成

アプリケーション開発者向けの環境構築ガイドを整備します。

開発標準の整備

PGUT工程の開発標準を整備します。 以下のドキュメントを参考にしてください。

品質、生産性、保守性の向上を目的とした、プログラマーが遵守するべきコーティング規約です。

PG・UT作業の完了条件を開発者が確認するためのチェックリストです。

コーディング規約違反などの単純なコーディングミスをしていないかを開発者自身が確認するためのチェックリストです。

結合テスト工程

結合テスト準備（疎通確認）

結合テスト開始前(PGUT工程)に、結合テスト環境向けの設定変更および疎通確認を行います。

PGUT工程でのローカル開発環境から結合テスト環境に移行する際、多くの差異が発生します。 （例:ファイルパスの違い、モックの使用有無） このため、余裕を持って結合テスト環境用の設定を行う必要があります。 結合テストまでに十分な疎通確認ができていない場合、 テスト開始直後に基盤部分でエラーが頻発し、テスト全体の進捗を遅らせる要因となります。

まず、方式設計書からケースを抽出します。 例えば「認証」に関する記述があれば、認証機能が動作することを確認するケースを上げます。 次に、環境ごとに、前工程での環境差異があるかどうかをチェックします。

以下に例を示します。

観点 UT->IT IT->ST ST->本番 説明
認証 有 無 有 IT工程からシステム全体の共通テストデータを使用
帳票出力 無 有 無 ライセンスの都合上、帳票出力はSTから実施
ファイル入出力 有 無 無 OS差異により、パス指定方法が異なる
ファイル転送 有 有 有 環境毎にIPアドレスの変更が必要
バッチ 有 無 有 IT工程からシェルスクリプトを使用
　 　：

差異が発生する部分は、その環境に応じた設定変更等を行います。

差異が発生する箇所を中心に疎通確認を行います。 特に、テスト全体への影響が大きい機能(動作しないとテストができないような機能)を優先的にテストします。

システムテスト工程

(プロジェクトからのフィードバックを受けて拡充させていく予定です)

保守運用

(プロジェクトからのフィードバックを受けて拡充させていく予定です)