産総研　包括フレームワーク（FW）のアーキテクチャ

コンサル

先月行われたセミナーの中の説明ではアーキテクチャの位置づけがわかり難かったが、最後に質問して確認したことでしっくりきた。

結論からいうと包括FWをベースにプロジェクトを進める場合はアーキテクチャはほぼ決まっており、決められたアーキテクチャに沿って開発を進めることになる。

要件分析プロセスでアーキテクチャ案の決定というアクティビティがあるので、該当システムとしてアーキテクチャ案を策定するようなことが考えられているようだが、実態としてはあらかじめ決められているアーキテクチャを超えるような要件が出てきたときの対応といったところだろう。

基本設計プロセスではアーキテクチャ設計という作業領域が定義されているが、ここでのポイントは外部設計を進めていくためのルール作りがメインになる。　主なものは以下の３つである。

　・画面・帳票設計ルール
　・データベース論理設計ルール
　・バッチとシステム間連携設計ルール

これらの設計ルールを決めるのがアーキテクトの主要な作業なので、本来のアーキテクチャ設計を行うわけではない。実際にはアーキテクトが包括FWのアーキテクチャを理解しそれをプロジェクトメンバーに説明し、他の作業との関わりや考慮点を伝えることが重要な作業になると思われる。

包括FWではあらかじめアーキテクチャを決めることで生産性の向上と保守性の向上を狙っている。

そして、札幌市の場合はインフラ周りを市側で対応することになっているようなので、なおさらアーキテクチャの固定化が意味をもつ。

極端なことを言えば「発注側が包括FWベースのPaaSを提供するので、その上でシステムを組んでください」といっているようなものである。

これが実現できればプロジェクトの効率は確かにあがる。

そして何よりも大事なのは工程ごとに調達が行われる場合にインフラを誰が担保するのかというのが、大きな問題になる。
その答えの一つが発注側でインフラを管理することである。

では発注者側でインフラを管理するとはどういうことなのだろうか？　　これは様々なことが課題として考えられるそれはまた後日考えてみたい。

工程ごとの調達を考えた場合にアーキテクチャが固定されていることが非常に意味をもつ。
アーキテクチャが明確な方が要件の実現可能性のメドがつきやすい。
逆にアーキテクチャの不明確な段階での要件は実現可能か否かの判断が担当者の感に頼ることになる。

要件を定義する工程と詳細な仕様を詰める段階、そして開発　　それぞれ担当する会社が分かれる場合に、仕様の実現可能性はその後の開発リスクに直結する。
実現可能性が高ければ高いほどリスクが軽減（開発者のスキルは無視したとして）する。

また、アーキテクチャが決まっていることで上流工程のドキュメントも軽くすることができる。

それでは包括FWのアーキテクチャで大丈夫なのか？　　という問いであるが。

それは暗黙のうちに決められている非機能要求があり、それに従えるうちは大丈夫　ということだろう。
包括FWのアーキテクチャが想定する非機能要求が明示されているのかいないのかは開発ガイドラインを見ないと何ともいえないが、もし無ければ不要な混乱を避ける意味でも一旦暗黙の非機能要求を考えてみるのもいいだろう。

たとえば

  • 包括FWは業務系のシステムでかつ既存のシステムを置き換えることをターゲットにしている。
  • 同時に対象システムも市関係の業務としてある程度見えている。
  • 既存システムが汎用機で動いており大量のバッチ機能がある　　
  • なんてことになれば暗黙のうちに２４時間サービス提供は考慮されていないのかもしれない...

とか考える材料は結構ありそうである。

これらのことを踏まえて常識的にいえることをまとめると非機能要求が見えてくる。

どのみち実際のプロジェクトとしての非機能要求を洗い出す中で包括FWで対応できる部分、できない部分を明確にすることが必要になる。

包括FWのアーキテクチャが想定している暗黙の非機能要求を想像することは結構役に立つと思われる。