愛記システム概念設計:システム構築の品質評価のポイント1 理解可能性③ | 続・ティール組織 研究会のブログ

続・ティール組織 研究会のブログ

ティール組織が話題になっているが、具現化するにはどうしたらよいか?
その研究を続けるにあたり、さらに次の形態である、続・ティール組織なるものまで視野に入れ、具体的な施策・行動内容を研究・支援する会。

先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。大まかな概念としてはひとまず終えた。次は、ブロックチェーンの概念設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。

◆愛記システムのシステム評価について

システム評価とは、つまりは、このシステムを導入して成功だったか失敗だったかという効果検証という意味だ。概念設計をする上で必ず抑えておくべきポイントということだ。それには各項目があり、それぞれの項目を見ていくことで、その結果が得られる。そのシステム評価項目を1つずつ見ていきたい。

システム構築の品質評価のポイント1:理解可能性(Understandability)

システム構築の品質評価のポイント2:完全性(Completeness)

システム構築の品質評価のポイント3:簡潔性(Conciseness)

システム構築の品質評価のポイント4:移植性(Portability)

システム構築の品質評価のポイント5:一貫性(Consistency)と構造化の度合い

システム構築の品質評価のポイント6:保守性(Maintainability)

システム構築の品質評価のポイント7:試験性(Testability)

システム構築の品質評価のポイント8:ユーザビリティ(Usability)

システム構築の品質評価のポイント9:効率性(Efficiency)

システム構築の品質評価のポイント10:セキュリティ(Security)

 

システム構築の品質評価のポイント1:理解可能性③(Understandability)

波動レベルを知る

波動レベルは、ボディ側:発達課題のレベル、意識側:意識レベル、意志側:愛の行動レベル、を総合的にみて決める。

1.発達課題は受け取る愛の行動レベルだけでなく、生命体の次元レベルも関係してきて、高次元の生命体がきちんと動いているかがポイントになる。

2.意識レベルは、チャクラの開放、愛貨の保有量と関係があり、愛貨の保有量が各次元でどれほどあるかにより、保有が多いほど高い評価となる。

3.愛の行動レベルは、相手に受け取ってもらえたかどうかは別として、愛の行動をした量が評価される。

 

波動レベルの決定にはボディ側(発達課題のレベル)、意識側(意識レベル)、意志側(愛の行動レベル)が関与し、それぞれが総合的に考慮されるが、以下にそれぞれの要素について詳細に説明したい。

◆意志側(愛の行動レベル)

意志側のレベルを測定することは最も容易だ。ブロックチェーンにて愛の行動の都度、科目として保存されていくので、後々にDApps側で抽出し評価していけば良いだけなのだから。以前にも、個人の評価項目などで愛の行動分析なるものを記載してきたので、そちらと同じような分析になる。愛記システムにおいて、愛の行動にはレベル1から10までの科目があり、その愛貨のやりとりを仕訳としてDApps側に保存していく仕組みを構築する。以下に、その仕組みの基本的な設計アイデアを再度示す。

  1. 愛の行動の科目とレベルの定義:

    • 各レベルごとに複数の科目を定義する。例えば、レベル1では「笑顔」「挨拶」など、レベル10では「慈善活動」「奉仕活動」などの高度な愛の行動を設定する。
  2. トランザクションの仕組み:

    • ユーザーが愛の行動を行うと、それに対応するトランザクションが発生する。トランザクションにはユーザーID、行動の科目、行動のレベル、タイムスタンプなどの情報が含まれる。
  3. スマートコントラクトの実装:

    • ブロックチェーン上にスマートコントラクトを実装し、トランザクションの受け入れと処理を担当する。スマートコントラクト内で、トランザクションを受け入れたユーザーに対して愛貨の増減を行う。
  4. 愛貨の増減ロジック:

    • 各科目とレベルに対して、愛貨の増減ロジックを定義する。例えば、レベル1の「笑顔」は10愛貨、レベル10の「慈善活動」は100愛貨などといった具体的な設定を行う。
  5. DApps側のデータ保存:

    • DAppsのサーバーサイドやデータベースを使用して、トランザクションのデータを保存する。ユーザーの行動ログ、愛貨残高などの情報を管理する。
  6. 愛貨の取引履歴の表示:

    • ユーザーがDApps上で自分の愛貨の取引履歴を確認できるようなインターフェースを提供する。これにより、ユーザーは自身の行動履歴や愛貨の増減を透明に確認できる。

以下は、簡単なスマートコントラクトの一部と、DApps側でのトランザクションデータの保存例である。これはあくまで概念的な例であり、実際の実装にはセキュリティやパフォーマンスの向上などを考慮する必要がある。

 

 

○スマートコントラクト(愛の行動の偏りチェック):

use std::collections::HashMap;

struct DimensionEvaluation {
    dimension_actions: HashMap<String, u32>,
    dimension_difficulty: HashMap<String, u32>,
}

impl DimensionEvaluation {
    fn new() -> Self {
        let mut dimension_difficulty = HashMap::new();
        dimension_difficulty.insert("太陽系".to_string(), 10);
        dimension_difficulty.insert("地球".to_string(), 9);
        // 他の次元も同様に追加

        DimensionEvaluation {
            dimension_actions: HashMap::new(),
            dimension_difficulty,
        }
    }

    fn add_action(&mut self, dimension: &str, count: u32) {
        self.dimension_actions.insert(dimension.to_string(), count);
    }

    fn evaluate(&self) -> (bool, f64, f64) {
        let total_actions: u32 = self.dimension_actions.values().sum();
        let num_dimensions = self.dimension_actions.len() as f64;
        let average_actions = total_actions as f64 / num_dimensions;

        let variance = self.dimension_actions.values().map(|count| {
            let diff = (*count as f64 - average_actions).powi(2);
            diff
        }).sum::<f64>() / num_dimensions;

        let std_deviation = variance.sqrt();

        let imbalance_threshold = 1.5; // Adjust as needed
        let is_imbalanced = std_deviation > imbalance_threshold;

        (is_imbalanced, std_deviation, average_actions)
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add_action() {
        let mut evaluation = DimensionEvaluation::new();
        evaluation.add_action("太陽系", 0);
        assert_eq!(evaluation.dimension_actions.get("太陽系"), Some(&0));
    }

    // Add more tests as needed
}

 

○DApps側のデータ保存(Python/Flask例):

from flask import Flask, request, jsonify

app = Flask(__name__)

# データベースに関連するライブラリやモデルのインポートが必要

@app.route('/record_love_action', methods=['POST'])
def record_love_action():
    data = request.get_json()

    user_id = data['user_id']
    level = data['level']
    subject = data['subject']

    # データベースにトランザクションを保存
    # ここでデータベースのモデルやORMを使用して保存

    return jsonify({"message": "Love action recorded successfully"})

if __name__ == '__main__':
    app.run(debug=True)
 

実際にDApps側である愛記システムにおいて、愛の行動レベルの評価をしたい。具体的には、相手に愛貨を受け取ってもらえたかどうかは別として、相手への愛の行動をしたというデータを集計して、どのレベルの愛の行動が多いかなどを評価して、総合的な愛の行動レベルを算出したい。スマートコントラクトはデータ処理のみを担当し、評価制度のロジックはDApps側のPythonで実装するというアプローチである。以下に、DApps側のPythonでの評価制度のロジックを簡単に示す。

 

from collections import Counter
from web3 import Web3

# Web3の初期化などが必要

def get_love_level(user_address):
    # スマートコントラクトのアドレスとABIが必要
    contract_address = "0x1234567890123456789012345678901234567890"
    contract_abi = [...]  # スマートコントラクトのABI

    # スマートコントラクトとの接続
    web3 = Web3(Web3.HTTPProvider('http://localhost:8545'))
    contract = web3.eth.contract(address=contract_address, abi=contract_abi)

    # ユーザーの行動履歴を取得
    user_actions = contract.functions.userActions(user_address).call()

    # レベルごとの頻度を集計
    level_frequency = Counter(action['level'] for action in user_actions)

    # 最も頻度の高いレベルを求める
    most_frequent_level = max(level_frequency, key=level_frequency.get)

    return most_frequent_level

if __name__ == '__main__':
    user_address = "0xuseraddress"
    love_level = get_love_level(user_address)
    print(f"User's love level: {love_level}")


この例では、PythonでWeb3を使用してスマートコントラクトとの連携を行い、ユーザーの行動履歴から最も頻出するレベルを求めている。この評価ロジックは、DApps側での実装例となる。具体的な評価基準やビジネスルールに合わせてもっと詳細なロジックを構築していくことにはなるのだが。

 

 

いかがであろうか、これで意志側:愛の行動レベルが取得できる。次回は、意識レベルについて記載していきたい。