愛記システムの基本設計：DApps側である愛記システム 要件定義について | 続・ティール組織　研究会のブログ
AmebaAmeba 20th Anniv.ホームピグアメブロ
芸能人ブログ人気ブログ
新規登録
ログイン

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

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

愛記システムの基本設計：DApps側である愛記システム 要件定義について

先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。概念設計としてはひとまず終えた。次は、フェデレーションモデル全体の基本設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。そして、それにつながるDApps側である愛記システムを、Pythonプログラムで開発していきたい。

 

愛の行動のPL,BSを決算書として、個人単位、市町村単位、で公表するような愛記システムというものを考えている。愛の行動のデータベースはブロックチェーンのプログラムであり、日々の愛の行動による愛貨の移動を決算書にまとめていきたい。なお、市町村のブロックチェーンのプログラムは以前にも記載している。その市町村のブロックチェーンのプログラムにつながる愛記システムを、DApps側であるPythonプログラムとして設計したい。その場合、基本設計をどのような手順で進めていけばよいか、詳しく見ていこう。

 

愛記システムを設計するための基本手順を以下に示す。このシステムは、Pythonを用いて市町村のブロックチェーンと連携し、個人および市町村単位での愛の行動のデータを収集、記録し、決算書（PL、BS）として公表するものである。

基本設計手順

1. 要件定義

機能要件:

  • 愛の行動の記録:
    • 各ユーザーが行った愛の行動を詳細に記録する。具体的には、行動の内容、行動レベル、行動に関与したユーザーID、行動のタイムスタンプなど。
  • 各愛貨の時価取得：
    • ”愛貨”を10種類に分けてやり取りさせることを考えたい。 Lv1：AIR（Root） Lv2：AIS（Sacral) Lv3：AIP（solar Plexus) Lv4：AIH（Heart) Lv5：AIT（Throat） Lv6：AII（ThIrd Eye） Lv7：AIC（Crown) Lv8：AIU（Universal) Lv9：AIE（Earth Star) Lv10：AIM（solar Matrix)
      これらの愛貨を時価取得するように設計する。
  • 愛貨の移動の記録:
    • 愛貨がどのユーザーからどのユーザーに移動したかを記録する。具体的には、送信者と受信者のユーザーID、移動した愛貨の量、移動の理由（行動内容）、タイムスタンプなど。
  • 決算書の生成:
    • 個人および市町村単位でのPL（損益計算書）とBS（貸借対照表）を生成する。具体的には、各ユーザーの愛貨の受領と贈与、未使用愛貨の残高、市町村への申告額、純資産の評価などを含む。
  • 個人および市町村単位でのデータの集約:
    • 個々のユーザーの取引データを集約し、市町村単位で集計する。これにより、地域全体の愛貨の流通状況や経済活動の状況を把握する。
  • データのブロックチェーンへの記録と取得:
    • 取引データを安全に保存するためにブロックチェーン技術を使用する。データの記録、取得、検証プロセスを管理する。

非機能要件:

  • セキュリティ（データの保護、暗号化）:
    • 取引データやユーザー情報を暗号化して保存し、不正アクセスから保護する。
  • 可用性（システムの稼働率）:
    • システムが高い稼働率を維持できるように設計し、障害時にも迅速に復旧できる仕組みを整える。
  • パフォーマンス（取引の処理速度）:
    • 大量の取引データを迅速に処理できるように、データベースとブロックチェーンの処理能力を最適化する。

2. アーキテクチャ設計

システム構成:

  • DApps（フロントエンドとバックエンド）:
    • フロントエンドはユーザーインターフェースを提供し、ユーザーからの入力を受け付ける。
    • バックエンドはデータ処理を行い、ブロックチェーンとのインターフェースを提供する。
  • 市町村ブロックチェーン:
    • 取引データの保存と検証を行うためのブロックチェーンネットワーク。
  • メインチェーン（大陸ごと）：メインチェーン側への要求を検証

コンポーネント設計:

  • フロントエンド:
    • ユーザーインターフェース: 取引の記録画面、データ表示画面、決算書の生成画面。
  • バックエンド:
    • データ処理: 取引データの集約、分析、決算書の生成。
    • ブロックチェーンとのインターフェース: データの記録と取得。
  • 市町村ブロックチェーン: 取引データの保存、検証
  • メインチェーン: 市町村ブロックチェーンからのデータ集約と処理を検証

3. データベース設計

テーブル設計:

  • users テーブル（ユーザー情報）:
    • id, name, email, public_key, private_key
  • transactions テーブル（取引記録）:
    • id, user_id, action_id, amount, timestamp, signature
  • actions テーブル（愛の行動）:
    • id, description, level, category
  • token_prices テーブル（各愛貨の時価情報）

フィールド設計:

  • users:
    • id: ユーザーの識別子
    • name: ユーザーの名前
    • email: ユーザーのメールアドレス
    • public_key: ユーザーの公開鍵
    • private_key: ユーザーの秘密鍵
  • transactions:
    • id: 取引の識別子
    • user_id: 取引を行ったユーザーのID
    • action_id: 行動の識別子
    • amount: 移動した愛貨の量
    • timestamp: 取引のタイムスタンプ
    • signature: 取引の署名
  • actions:
    • id: 行動の識別子
    • description: 行動の説明
    • level: 行動のレベル
    • category: 行動のカテゴリ
  • token_prices: 
    • token_type, price
  • データベースモデル（例）
    from sqlalchemy import Column, Integer, String, Float, DateTime, ForeignKey
    from sqlalchemy.orm import relationship
    from database import Base

    class User(Base):
        __tablename__ = 'users'
        id = Column(Integer, primary_key=True, index=True)
        name = Column(String, index=True)
        email = Column(String, unique=True, index=True)
        public_key = Column(String)
        private_key = Column(String)
        transactions = relationship("Transaction", back_populates="user")

    class Transaction(Base):
        __tablename__ = 'transactions'
        id = Column(Integer, primary_key=True, index=True)
        user_id = Column(Integer, ForeignKey('users.id'))
        action_id = Column(Integer, ForeignKey('actions.id'))
        amount = Column(Float)
        timestamp = Column(DateTime)
        signature = Column(String)
        user = relationship("User", back_populates="transactions")

    class Action(Base):
        __tablename__ = 'actions'
        id = Column(Integer, primary_key=True, index=True)
        description = Column(String)
        level = Column(Integer)
        category = Column(String)
        transactions = relationship("Transaction", back_populates="action")

4. API設計

エンドポイント:

  • POST /transactions:
    • 取引の記録を行うエンドポイント
  • GET /transactions:
    • 取引の取得を行うエンドポイント
  • POST /users:
    • ユーザーの登録を行うエンドポイント
  • GET /users:
    • ユーザー情報の取得を行うエンドポイント
  • GET /token_prices: 
    • 各愛貨の時価の取得を行うエンドポイント

API仕様:

  • POST /transactions:
    • リクエストボディ: user_id, action_id, amount, signature
    • レスポンス: status, transaction_id
  • GET /transactions:
    • リクエストパラメータ: user_id
    • レスポンス: transactions
       
  • APIエンドポイントの実装（例）
    from fastapi import FastAPI, HTTPException
    from sqlalchemy.orm import Session
    from database import SessionLocal, engine, Base
    from models import User, Transaction, Action
    from schemas import UserCreate, TransactionCreate

    app = FastAPI()

    Base.metadata.create_all(bind=engine)

    @app.post("/users/", response_model=UserCreate)
    def create_user(user: UserCreate, db: Session = Depends(get_db)):
        db_user = User(name=user.name, email=user.email, public_key=user.public_key, private_key=user.private_key)
        db.add(db_user)
        db.commit()
        db.refresh(db_user)
        return db_user

    @app.post("/transactions/", response_model=TransactionCreate)
    def create_transaction(transaction: TransactionCreate, db: Session = Depends(get_db)):
        db_transaction = Transaction(user_id=transaction.user_id, action_id=transaction.action_id, amount=transaction.amount, signature=transaction.signature)
        db.add(db_transaction)
        db.commit()
        db.refresh(db_transaction)
        return db_transaction

    @app.get("/transactions/{user_id}")
    def read_transactions(user_id: int, db: Session = Depends(get_db)):
        transactions = db.query(Transaction).filter(Transaction.user_id == user_id).all()
        return transactions

5. ブロックチェーンインターフェース

トランザクションの記録:

  • 取引データをブロックチェーンに保存する。

トランザクションの取得:

  • ブロックチェーンから取引データを取得する。

署名の生成と検証:

  • 署名の生成: 取引データを署名して、取引の正当性を保証する（送信者側）。
  • 署名の検証: 受信した取引データの署名を検証して、取引の正当性を確認する（受信者側）。

6. 決算書の生成

PL（損益計算書）の生成:

  • 収益: 愛貨の受領を記録
  • 費用: 愛貨の贈与を記録
  • 純利益: 収益 - 費用

BS（貸借対照表）の生成:

  • 資産: 未使用愛貨を記録
  • 負債: 市町村への申告額を記録
  • 純資産: 自己評価による純資産を記録

7. フロントエンド開発

ユーザーインターフェース:

  • 取引の入力フォーム: ユーザーが取引を記録するためのフォーム
  • 決算書の表示ページ: 決算書を表示するページ

バックエンドとの連携:

  • APIエンドポイントへのリクエストとレスポンスの処理: ユーザーが入力したデータをAPIに送信し、レスポンスを受け取って表示する。

8. テストとデプロイ

単体テスト:

  • 各コンポーネント（フロントエンド、バックエンド、ブロックチェーンインターフェース）の機能テストを行う。

結合テスト:

  • コンポーネント間の連携が正しく機能するかをテストする。

システムテスト:

  • システム全体の動作を確認する。

デプロイ:

  • サーバーにシステムをデプロイし、運用を開始する。

以上の基本設計手順に従って、愛記システムを構築していくことになる。各ステップを詳細に進めることで、愛の行動のデータベースをブロックチェーンに記録し、個人および市町村単位での決算書を生成するシステムを構築することができる。

 

愛記システムによる決算書（例）

愛記の科目は、愛貨のやり取りに基づいた独自の仕訳体系を構築し、価値の増減や愛の行動の評価に基づくシステムとする必要がある。以下に、愛記の仕訳科目の例を示し、具体的な例を用いて、PL（損益計算書）とBS（貸借対照表）がどのように変化するかをシミュレーションしてみよう。

損益計算書 (PL: Profit and Loss Statement)

  1. 収益 (Revenue)
    • 受け取られた愛貨 (Received Love Tokens)
    • 行動による利益 (Profit from Actions)
    • 目標達成による愛貨の受領 (Love Tokens from Achieving Goals)
  2. 費用 (Expenses)
    • 愛貨の送信 (Sending Love Tokens)
    • 行動による愛貨の投資 (Investment of Love Tokens for Actions)
    • 他者への贈与 (Gifts to Others)
    • 未使用愛貨の有効期限切れによる損失 (Loss from Expiry of Unused Love Tokens)

貸借対照表 (BS: Balance Sheet)

  1. 資産 (Assets)

    • 未使用愛貨 (Unused Love Tokens)
    • 目標達成による利益 (Profit from Goal Achievements)
    • 行動による受領愛貨 (Love Tokens Received from Actions)
    • 他者の目標達成による贈与 (Gift from Others' Goal Achievements)
    • 他者からの行動による受領愛貨 (Love Tokens Received from Others' Actions)

  2. 負債 (Liabilities)

    • 市町村への申告愛貨 (Declared Love Tokens to Municipality)
    • 未実施行動による債務 (Liabilities for Unperformed Actions)
    • 目標未達成による債務 (Liabilities for Unachieved Goals)
    • 愛貨の借用 (Borrowed Love Tokens)

  3. 純資産 (Equity)

    • 愛貨による自己評価 (Self-Evaluation by Love Tokens)
    • 他者からの評価 (Evaluation from Others)
    • コミュニティ貢献度 (Community Contribution)
    • 長期未使用愛貨 (Long-Term Unused Love Tokens)

例: 個人Aの1週間の取引

1日目

  • 朝、隣人Bを助けてゴミ出しを手伝う。Bから5愛貨を渡す（収益）。
  • 午前中、地域の清掃活動に参加。市町村に10愛貨を渡す（収益）。
  • 昼食後、友人Cに愛貨を10送信して、お互いの目標をサポート（費用）。
  • 夕方、隣人Dに花を贈るために3愛貨を使用し貰う（費用）。

2日目

  • 朝、友人Eの引っ越しを手伝い、Eから8愛貨を渡す（収益）。
  • 午後、地域の公園整備に参加。市町村に5愛貨を渡す（収益）。
  • 夕方、隣人Fに愛貨を5送信して、目標達成をサポート（費用）。

3日目

  • 朝、友人Gの子供を預かり、Gから7愛貨を渡す（収益）。
  • 午後、老人ホームでボランティア活動。市町村に7愛貨を渡す（収益）。
  • 夜、友人Hに愛貨を5送信して、目標達成をサポート（費用）。

4日目

  • 朝、隣人Iの庭仕事を手伝い、Iに6愛貨を渡す（収益）。
  • 午後、地域の環境保護活動に参加。市町村に6愛貨を渡す（収益）。
  • 夕方、友人Jに愛貨を6送信して、目標達成をサポート（費用）。

5日目

  • 朝、友人Kの子供の宿題を手伝い、Kに4愛貨を渡す（収益）。
  • 午後、地域の健康増進活動に参加。市町村に5愛貨を渡す（収益）。
  • 夕方、隣人Lに愛貨を4送信して、目標達成をサポート（費用）。

6日目

  • 朝、友人Mの仕事を手伝い、Mに9愛貨を渡す（収益）。
  • 午後、地域の文化イベントに参加。市町村に7愛貨を渡す（収益）。
  • 夕方、友人Nに愛貨を7送信して、目標達成をサポート（費用）。

7日目

  • 朝、隣人Oの買い物を手伝い、Oに6愛貨を渡す（収益）。
  • 午後、地域のスポーツイベントに参加。市町村に8愛貨を渡す（収益）。
  • 夕方、友人Pに愛貨を8送信して、目標達成をサポート（費用）。

1週間のPLとBS

損益計算書 (PL)

収益

  • 受け取られた愛貨
    • 隣人B：5愛貨
    • 市町村：10愛貨
    • 友人E：8愛貨
    • 市町村：5愛貨
    • 友人G：7愛貨
    • 市町村：7愛貨
    • 隣人I：6愛貨
    • 市町村：6愛貨
    • 友人K：4愛貨
    • 市町村：5愛貨
    • 友人M：9愛貨
    • 市町村：7愛貨
    • 隣人O：6愛貨
    • 市町村：8愛貨
  • 合計収益：93愛貨

費用

  • 愛貨の送信
    • 友人C：10愛貨
    • 隣人D：3愛貨
    • 友人F：5愛貨
    • 友人H：5愛貨
    • 友人J：6愛貨
    • 隣人L：4愛貨
    • 友人N：7愛貨
    • 友人P：8愛貨
  • 合計費用：48愛貨

純利益

  • 収益 - 費用：45愛貨

貸借対照表 (BS)

資産

  • 未使用愛貨：45愛貨（純利益として計上）

負債

  • 市町村への申告愛貨：なし（例では未申告）

純資産

  • 愛貨による自己評価：45愛貨（自己の行動による利益として計上）

評価

1週間の取引を通じて、個人Aは45愛貨の純利益を得た。これは、愛貨の取引が個人Aの社会的貢献や行動の成果を反映していることを示している。PLとBSを用いることで、個人の愛貨の収支状況を詳細に把握でき、どのような行動が最も効果的であったかを評価することが可能となる。また、この仕組みを用いることで、個人Aがどれだけの愛の行動を行い、どれだけの愛貨を受け取ったか、またどれだけの愛貨を他者に贈与したかが明確になる。これにより、愛貨を活用した新しい評価システムが構築され、個人やコミュニティ全体の愛の行動の推進に寄与することが期待できる。

 

では、個人Aの1週間の取引に基づいて、具体的なPL（損益計算書）とBS（貸借対照表）を作成する。愛貨の場合、費用と収益、資産と負債が逆になることを考慮して、PL（損益計算書）とBS（貸借対照表）を作成する。

個人Aの損益計算書（PL）

個人Aの貸借対照表（BS）

まとめ

個人Aの1週間の取引に基づいて作成した損益計算書（PL）と貸借対照表（BS）では、愛貨の取引による収益と費用、純利益が明確に示された。PLは収益と費用の差額である純利益を示し、BSは未使用愛貨としての資産、負債がない状態、そして純資産としての愛貨を示している。このシステムを使えば、個人Aがどのように愛貨をやり取りし、どれだけの社会貢献を行ったかが明確に把握できるだろう。

 

 

いかがであろうか、愛記システムの基本設計において、まずは全体像を示し、そこから一つずつ各項目の設計をしていくことで、愛記システム構築を目指していきたい。