1000年アーキテクチャー(08)

設計工程について考えてみたいと思う。設計工程は各アウトプットを分かりやすくするためにウォーターフォールモデルでの開発を想定して考える。

リリース程について考えてみる。この工程は開発されたシステムが、システムがシステムを開発する人から、システムを提供する人に引き渡され、システムの利用者に公開されることになる。この段階ではシステムを開発する人が抜けるため、システムの詳細な作りに関する知識が失われることになる。1000年アーキテクチャを考える場合、システムの寿命は人間よりも長くなるため、新たに開発する人が参加した場合でも、システムの機能追加や更改が可能となることが重要である。

そのためには、これまでの工程の成果物で、システムを利用する人に向けた設計、設定が明確にわかる必要がある。こうすることによって新しいメンバーであっても、システムの利用者に向けた機能を踏襲理解して開発することが可能となる。システムを提供する人やシステムを開発する人に向けた機能は無理に踏襲する必要はなく、その時代に合わせて見直したほうがよいと判断できるようになる。

このようにリリースの工程では、単にシステムが稼働し引き渡されるだけでなく、維持されるべき利用者に向けた機能と、時代に会わせて見直すべき提供者、開発者に向けた機能が識別しやすい状態で管理されていることを確認できればよいこと考える。

1000年アーキテクチャー(07)

設計工程について考えてみたいと思う。設計工程は各アウトプットを分かりやすくするためにウォーターフォールモデルでの開発を想定して考える。

詳細設計工程及びテスト工程について考えてみる。詳細設計工程は採用される製品やフレームワークに依存する内容が多くなる。ここで製品ごとに設計する内容が、システムを使う人、システムの提供する人、システムを作る人の誰が利用するための機能か明確にする必要がある。そうすることにより、製品の入れ替えが発生した際、システムの利用者(ユーザ)に影響がある機能が限定できるだめ、継承しなくてもよい機能が増え、選択の幅を広げることができる。システムを提供するひとや作る人は、製品にあわて利用方法を改めて学習すればよい。

テスト工程も同様で、各テスト項目が、どの人の操作を想定した項目なのか明確化する必要がある。それにより、システムを使う人を対象とした試験項目は今後も再利用するべき試験項目となる。また、システムを作る人を対象とした試験項目は、システムとしての挙動が確認できればよいようは試験項目もあるため、事前に机上で試験結果の期待値を整理するのが難しい場合がる。このように試験項目が誰が使用することを想定しているのか明確にすることにより、試験の準備や、再試験の効率が良くなるばずと考える。

1000年アーキテクチャー(06)

設計工程について考えてみたいと思う。設計工程は各アウトプットを分かりやすくするためにウォーターフォールモデルでの開発を想定して考える。

基本設計工程について考えてみる。この工程ではシステムの外部から見た形を明確にする必要がある。システムの構成要素や、要素間のつながりを明確にする。通常の設計では、採用する製品の機能を軸に、システムの作りを具体化していくのではないかと思う。1000年アーキテクチャーでは、人に着目してシステムの作りを具体化する。要件定義工程で明確にした、システムの利用者がシステムを通して受けている価値と、システムの提供者が生み出している価値がシステムの機能とどのように結び付いているのかを具体化する。こうすることで、システムの自身の価値と製品に求める役割を明確にできる。すると、システムに採用した製品で利用すべき機能と不要な機能の選定が容易となる。そうすることによって、利用目的の不明な機能や、ほとんど使われない機能の実装を抑制し、無駄の削減できるのではないかと思う。また、製品に求める要求が具体的になることから、製品の入れ替えが可能となる。その結果、システムのアーキテクチャーや価値を損なうことなく、製品(物理機器)は変更可能となる。アーキテクチャーと言う考え方が製品や物理機器から独立し、製品や物理機器を入れ替え(新陳代謝)ながら運用できるシステムとすることで、製品や物理機器のライフサイクルに依存しない長期間生存するシステム設計が可能となる。

1000年アーキテクチャー(05)

設計工程について考えてみたいと思う。設計工程は各アウトプットを分かりやすくするためにウォーターフォールモデルでの開発を想定して考える。

工程の定義は色々あるが、細かいいことは気にせず、要件定義工程について考えてみる。

要件定義工程では、機能要件と非機能要件を定義する工程で機能要件では、システムが何するものなのかを定義し、非機能要件では、性能、稼働率、セキュリティなどシステムの堅牢性を定義する。ここまで1000年アーキテクチャーでは、システムを使う人、システムの提供する人、システムを作る(または改修)人に注目するとことを考えてきた。この要素をこの工程に追加する(と言うか比重をおく)と、以下のようになるのではないか。

システムを使う人は、どのような欲求があるのか、システムを利用することでどのような価値を得られるか。

システムを提供する人は、どのような能力を持ち、どのような価値をシステムを通して提供するのか。

システムを作る人はどのような対応が、どの程度の頻度で発生するのか。

これらを事前に定義しておくことで、システムのTCOも予想しやすくなりそうだ。また、システムを提供する人がシステムを通して提供する価値をSDGsと結びつけておくと、システムの存在意義の説明がしやすくなるかもしれない。

1000年アーキテクチャー(04)

これまで2つの例を用いて1000年続くものは何かを考えてきた。これからのシステム設計の考え方に投影していくに当たり、今の時点の理解を一度まとめたい。コトガラに対して、コトを提供する人、コトを利用する人、コトガラの仕組みを作り維持する人が存在する。これらの人の関わりが続くとこによってコトガラが活き続けているのではないだろうか。システム設計で考えると、サービスを提供する人、サービスを受ける人、システムを構築・修繕する人がいて、それらの人とシステムの関わりを中心に考えることで、活き続ける(スクラップ化しない)システムを定義することができないだろうか。そして技術は時代に合わせて変わっていく。そのためシステムで採用される技術はその時代に合わせて置き換えられるものと考えておく。こうすることでテクノロジーの流行りに翻弄されることなく、時代に合わせてブラッシュアップできるシステムが作れるのではないかと考えた。僕たちSEは、最新のテクノロジーを勉強し、(メーカーの推奨する)テクノロジーの効果的な活用方法を常に考え、実装することが価値提供するだと思っていた。しかし、これでは技術の流行り翻弄され、時間と共に老朽化していくシステムの更改に疲弊してしまう。システムの中心を最新テクノロジーの活用におくのではなく、人とシステムの関わりかにおくことで、価値が残り維持できるシステムを作ることができるのではないかと思った。