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

1000年アーキテクチャのドキュメント体系を考えてみたいと思う。

さて、ここで1000年前以上らか存在して、今も一般的に読まれているものはどのようなもの書物か考えてみたい。

例えば聖書について考えてみる。

聖書にはいくつかの読み方があると言うが、ひとつは歴史を記したドキュメントと言う側面。確かに現存する歴史を記したドキュメントはかなり多く存在するのではないかと思う。

これは、歴史を記録し続け、今に繋がっていることを証明することにメリットがあるのではないかと思う。今に自分たちの状態が、過去から繋がっていることを示すことで、自らの正当性を証明する意味がある、

次に道徳書と言う側面

どうあるべきか、どう行動するべきかをシンプルにキャチーな言葉で示している。これは、多くの人がその内容を参照し、行動に反映させるには記憶にとどめやすくする必用があるため、ボリュームが多くなってはいけない。いつでも気になったときに参照して読み上げられるような分量にする必用がある。細かな条件毎に正、不正を示すようなルールブックでは、ルールを調べる専門家が必用となり、実際の多くの人はルールを確認できず、になんとなく過ごしいくことになる。

もうひとつは、物語としての側面だ。

単純な原理原則が書き連ねられていても内容をイメージしにくく読み進める気すらなくなってしまうかもしれない。内容が身に染みることがなければ、理解するどころか読んでもらうことすら難しい。そこで読んだ人が書かれている内容を共感したり、追体験できたりする工夫が必用になる。これは小さな例え話や物語を使うことで補われている。メッセージを分かりやすく残すためには誰もが共感しやすいような簡単な物語が効果を発揮する。

そこで1000年アーキテクチャーで残すべきドキュメントを考えるにあたって、このけた外れに長寿な書物の要素を参考にしてみる。

現在の正当性を証明する歴史

これは、ドキュメントの更新来歴と言いたくなるとこだが、少し異なる。システムの存在価値は、システム自身の機能に変更がなくても、利用者や利用者数に応じて変化することがある。例えば同じブログであっても芸能人が利用しているものと、学生のみが利用しているものではシステムの社会的な役割が異なる。

そのため、システムの変更点の来歴のみでなく、どんなことがあったのかイベントの年表のようなものがよい。これにより新規の人が参画した時もどのようなシステムかイメージしやすくなる。その観点では、大規模のな変更を試みたが失敗し、結局変更しなかったと言うような情報も役に立ったりする。

道徳書・原理・原則

タイトルからするとシステムの設計ドキュメントというよりは、プロジェクトマネージメント計画書の方が近いかもしれない。1000年アーキテクチャーは、システムとそのシステムに関わる人で定義することを考えてきた。システムそのものとサービスを提供する人、サービスを受ける人、システムを構築・修繕する人だ。これらの人がどのような人で何ができて、どうあるべきかの方針を整理する。そうすることでシステムの価値や意味が定義しやすくなる。システムの表し方としては、実際の構成といよりはシステムを活用することでサービスを提供する人が産み出した価値をどのように変化させて、サービスを受ける人に届けるのかを示すことでシステムの仕組みを表現できるのではないかと思う。

物語

最後に物語だ。これは、あまりエンジニアっぽくない。1000年アーキテクチャーはシステムの寿命は人間より長い。そのため常に関係する人乗り入れ代わりが発生する。そうすると、やるべきこと、やってはいけないことを体感的に理解する必用が出てくる。そのためには過去の運用でうまくいったこと、反省したことなどを物語のように記録することで、読むモチベーションの上がるドキュメントとなる。また、内容を体感的に理解しやすくなるだけでなくシステムに対しての親近感がわくかもしれない。こうすることでシステムと人との距離が近くなり、より強固な関係性となる可能性がある。

このような観点で中心となるドキュメントを考えてまた。

次回は、時代と共に変わっていく構成図や機器のパラメーターについてどのように取り扱うのがよいのか整理してみたい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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