先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。大まかな概念としてはひとまず終えた。次は、ブロックチェーンの概念設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。
愛記システムのシステム評価について
システム評価とは、つまりは、このシステムを導入して成功だったか失敗だったかという効果検証という意味だ。概念設計をする上で必ず抑えておくべきポイントということだ。それには各項目があり、それぞれの項目を見ていくことで、その結果が得られる。そのシステム評価項目を1つずつ見ていきたい。
システム構築の品質評価のポイント1：理解可能性（Understandability）
システム構築の品質評価のポイント2：完全性（Completeness）
システム構築の品質評価のポイント3：簡潔性（Conciseness）
システム構築の品質評価のポイント4：移植性（Portability）
システム構築の品質評価のポイント5：一貫性（Consistency）と構造化の度合い
システム構築の品質評価のポイント6：保守性（Maintainability）
システム構築の品質評価のポイント7：試験性（Testability）
システム構築の品質評価のポイント8：ユーザビリティ（Usability）
システム構築の品質評価のポイント9：効率性（Efficiency）
システム構築の品質評価のポイント10：セキュリティ（Security）
システム構築の品質評価のポイント5：一貫性（Consistency）と構造化の度合い
品質アップには多くの人たちの協力が必要だが、そこに一貫性がないとコストも非常にあがりトラブルにもなりやすくなる。システム構築において高評価を得るためにはある程度のルールを開発集団に認知させてから開発させないとソースコードが読めないと言った単純な問題が多発してしまう。この解消にはかなりの時間がかかるのでそれだけでロスも増える。
操作部品の位置の一貫性
操作部品の位置の一貫性については、たとえばATMの取消ボタンの位置などが以前は画面ごとに違う場所に表示されることがあったが、さすがにこういう目立った問題は最近では無くなったようだ。GUIではないけれど、エレベータの扉の開閉ボタンについては、これまで経験したエレベータのすべてで開くが左、閉じるが右となっていて、工業会の規格があるのかもしれないが、ともかくエラーを犯してしまう心配はない。ボタンの位置など、画面については他のシステムとの一貫性を十分に考慮せねばならない。
色の一貫性
色の一貫性については、交通信号に電球を使っていた時代には青が緑っぽかったり青っぽかったりすることがあり、さらに経年劣化で色が変化することもあったが、現在ではLEDランプとなり、安定した色表示が行われている。いわゆる色弱のドライバーにとっては、緑っぽい青信号は赤信号と混同しやすいので、これは良い方向に変化してきたと思う。リモコンのボタンのうち、電源のオンオフを割り付けられるボタンは右上にあり、赤色である、というのが一般的だ。このような一貫性も気を遣う必要がある。
方向の一貫性
方向の一貫性は、公共インタフェース、特に地下鉄の通路やビルのエスカレータの設置においてきちんと設定されていない。人は右、車は左、という道路交通法のある日本で、歩行者間の通行方向にいつ、どのような形でルールができたのか知らないが、東京都内の駅や地下道、あるいは階段では、歩行者同士では左側通行がデフォルトのようにすら感じられるほどだ。要するに、向こうからやってくる歩行者は自分の右側を歩く、ということだ。歩道を歩いていてもそういう場合が多い。自生的に生じたものなのか、鉄道会社が誘導したものか分からないが、ともかく左側通行に完全に一貫させるならそれでもいい。
しかし問題は「ここでは右側通行」のような例外が結構あることだ。基本的にこうした場面では人の流れにのって歩くから、大きな問題は発生していないようだが、なんとかして欲しいと思っている。またエスカレータも、登りが左側の時と右側の時が混在している。これは視覚障害者にとっては危険に直結する大きな問題だろう。建築家が何を考えているのか知らないが、ちゃんと方向の一貫性についても配慮をして欲しい。ともかく一貫性の欠如はユーザの混乱をまねき、ユーザエラーを引き起こし、時には安全にも関わってくるので、少なくともこうした外面的な一貫性については、厳密なルール化をはかり、違反事例をなくすようにしていくことが大切だ。愛の行動評価でも、リアルな行動が絡んでくるので、システム設計によるリアルへの影響もしっかりと考慮せねばならない。
-
評価基準の一貫性:
- 評価基準は公開され、期間ごとに変更がある場合は利用者に通知する。
- 例: "愛の行動"の定義や詳細な評価ポイントをユーザーガイドや利用規約で明示的に示す。
-
フェアネスの確保:
- 愛貨の報酬は、同じ行動に対して異なる地域や文化背景の利用者にもフェアに分配される。各地域の文化や経済的背景、社会状況を詳細に調査し、評価する。これには言語、慣習、価値観などが含まれる。
- 例: 地域ごとに異なる文化に対応するため、報酬計算に地域補正係数を導入する。日本の場合、基準係数が1であれば、米国が1.2、インドが0.8といった具体的な補正係数を設定するという具合だ。
-
透明性の確保:
- 利用者は自身の評価結果や報酬の計算がどのように行われたかを個別に確認できるダッシュボードを提供する。
- 例: 利用者専用のダッシュボードに、愛の行動履歴や報酬の詳細を表示する機能を実装する。
-
検証プロセスの確立:
-
トランザクションの発生:
- 利用者が愛貨を送信したりするなどの行動がトランザクションとして発生する。
-
トランザクションのブロードキャスト:
- 発生したトランザクションはネットワーク上にブロードキャストされ、各承認者に通知される。
-
競争的な承認プロセス:
- 承認者は、ブロードキャストされたトランザクションを含む新しいブロックを作成し、そのブロックをネットワークに伝える。
- PoSの場合、保有している愛貨の量に応じて承認の権利が与えられる。
-
ブロックの採用:
- ネットワーク上で最初にブロックを作成した承認者のブロックが他のノードによって採用され、トランザクションが確定する。
-
報酬の付与:
- ブロックを採用した承認者は、報酬として愛貨が減額される。この報酬はトランザクション手数料である。
- この競合的な承認プロセスにおいて、最初に問題を解いたり、一定の条件を満たしたりする承認者がトランザクションをブロックに組み込み、それがネットワーク上で採用されることでトランザクションが成立する。このようなプロセスにおいて、ブロックの生成や報酬付与の一貫性を確保することが重要である。
-
-
不正行為への対処:
- 不正行為が疑われる場合、特定のプロトコルに従って適切な対処を行う。
- 例: 不正行為の種類に応じたペナルティを定め、不正が確認された場合にはペナルティを科す。
-
改善サイクルの実施:
- 利用者からのフィードバックを積極的に受け付け、定期的なアップデートや改善を行う。
- 例: 利用者フィードバックを募り、新しい機能の提案や改善点を逐次システムに組み込む。
これらの具体的なルール化の案は、一貫性の確保や利用者の信頼構築に寄与する。ただし、具体的なルールはシステムの要件や利用者のフィードバックに基づいて調整する必要がある。
バージョン間の一貫性
さて、ここではこのバージョン間の一貫性の問題を強調したいのだが、特にソフトウェアの場合、バージョンアップによって一貫性が損なわれてしまうことがある。外面的な一貫性が空間的な変動に関するものであるのに対し、こちらは時間的な変動に関する一貫性の話である。もちろんハードウェアの場合も時間的な変動はあるけれど、同じハードウェア製品を立て続けに買うことはあまりないので、次の機種でインタフェースが変化してしまっても、あまり大きな問題にはならない。しかしソフトウェアの場合には、同じパソコンでソフトウェアのバージョンアップをして使い続けることは多い。したがって、そこに一貫性の欠如があると、確実にユーザを混乱させ、解決までに長い時間をロスさせることになる。
こうしたバージョン間の一貫性の欠如を見つけようとすることは結構困難である。評価者が旧バージョンを熟知していた場合には、その変化を見つけることは比較的容易だろうが、新バージョンをいきなり提示されて、それを評価してほしいといわれても、旧バージョンを知らなければ一貫性欠如の問題を見つけることはできないし、旧バージョンとの比較を丁寧に実行している評価者がどれだけいるかという問題もある。
以下はDApps側の愛記システムにおける一貫性の確保やアップデートの際の考慮事項である：
-
スマートコントラクトのテスト:
- DAppsをアップデート前にスマートコントラクトのテストを慎重に行い、予期せぬ問題を事前に発見する。
-
スマートコントラクトのアップグレード手順:
- スマートコントラクトをアップグレードする際、その手順やプロセスを文書化し、開発者や利用者が変更内容を理解できるようにする。また、アップデートが行われる際には、旧バージョンとの互換性や一貫性を確認するためのスマートコントラクトのアップグレードプランを検討する。
-
ユーザビリティテスト:
- DAppsの新しいバージョンを利用者が適切に使用できるかどうかを確認するユーザビリティテストが重要である。これにより、ユーザーが新しい機能や変更点を理解しやすいかを確認する。
-
ブロックチェーンの互換性:
- DAppsが利用しているブロックチェーンプロトコルやネットワークにおいて、アップデートが互換性を保っているかを確認する。特に、ハードフォークが必要な場合は、ユーザーコミュニティとのコミュニケーションが不可欠。ハードフォークは、プロトコルやルールの大規模な変更を伴うため、十分な認識、理解、合意がコミュニティ内で得られていることが不可欠である。
-
コミュニケーションプラットフォームの活用:
- ユーザーコミュニティとのコミュニケーションは、フォーラム、チャット、ソーシャルメディアなど様々なプラットフォームを活用して行う。コミュニティメンバーとのオープンかつ双方向の対話が重要である。
-
提案の発表と説明:
- ハードフォークの提案を発表し、変更の詳細や影響を分かりやすく説明する。技術的な側面だけでなく、変更がもたらすメリットや目的も伝える。
-
ユーザーフィードバックの収集:
- コミュニティメンバーからのフィードバックを積極的に収集し、提案された変更に対する意見や懸念を理解する。これにより、ユーザーの期待に合った変更を行うことが可能である。
-
テストネットの導入:
- 変更が本番環境に影響を与えないかを確認するため、テストネット（テスト用のブロックチェーンネットワーク）上で変更を導入し、ユーザーコミュニティにテスト参加を呼びかける。
-
トークンホルダー投票やコンセンサスの確認:
- プロジェクトにトークンホルダーが存在する場合、トークンホルダーによる投票を行い、コンセンサスを取ることがある。これにより、ハードフォークの実行について広範な意見を反映させることができる。
-
スムーズな移行の計画:
- ハードフォーク実行のスケジュールや移行プランを発表し、コミュニティメンバーがスムーズに変更に適応できるようサポートする。
-
以上の手順により、ユーザーコミュニティとのコミュニケーションが確立され、変更が透明かつ理解されやすい形で行われることが期待され、ハードフォークの成功の可能性が向上する。
-
ドキュメンテーションの整備:
- 変更点やアップデートに関する情報をわかりやすく文書化し、利用者や開発者が参照しやすくする。適切なドキュメンテーションは一貫性を確保する上で不可欠である。
DAppsの分野では、変更が不可逆的かつ分散化された環境で行われるため、アップデートや変更点の評価が特に慎重に行われる必要がある。コミュニティとの密な連携や透明性も、一貫性を保つ上で重要である。
愛記システムの場合、一貫性を考慮する際に以下のような事項が考えられる。
- 愛の行動の記録方法: ユーザーが愛の行動を記録する際の手法や形式を統一する。
- 愛の行動のカテゴリー: 愛の行動を分類する際のカテゴリーやタグの一貫性を保つ。
- 愛貨の評価基準: 愛貨の評価基準を明確にし、一貫性を保つ。
- 愛貨の交換方法: 愛貨の交換方法や手続きを一貫させる。
- 愛の行動報告の形式: 愛の行動報告書の形式や内容を統一する。
- 愛貨の使用方法: 愛貨の使用方法や目的を一貫させる。
- 愛貨の管理: 愛貨の管理方法やシステムを一貫させる。
- 愛の行動報告の頻度: 愛の行動報告の頻度やタイミングを統一する。
- 愛の行動報告の公開範囲: 愛の行動報告の公開範囲や方法を一貫させる。
- 愛の行動の受取人: 愛の行動を誰に対して行うかを一貫させる。
- 愛貨の有効期限: 愛貨の有効期限や利用期限を統一する。
- 愛貨の交換レート: 愛貨の交換レートや換算方法を一貫させる。
- 愛の行動の種類: 愛の行動の種類や内容を統一する。
- 愛貨の利用先: 愛貨をどこで利用できるかを一貫させる。
- 愛の行動の報告方法: 愛の行動をどのように報告するかを統一する。
- 愛の行動の効果測定: 愛の行動の効果をどのように測定するかを一貫させる。
- 愛貨の受取方法: 愛貨を受け取る方法や手続きを一貫させる。
- 愛の行動の範囲: 愛の行動の範囲や対象を一貫させる。
- 愛貨の利用規約: 愛貨の利用規約や条件を統一する。
- 愛の行動の報告項目: 愛の行動を報告する際の項目や情報を一貫させる。
これらの事項を考慮することで、愛記のシステム全体が一貫性を持ち、ユーザーにとって使いやすく理解しやすいものとなる。具体的なルール化に関して以下にいくつか案を示す。ただし、具体的なルールはシステムの特性やコンセプトにより異なる可能性がある。
愛の行動報告の公開範囲
愛の行動報告の公開範囲や方法を一貫させるためには、以下のような具体的な方法や仕組みを導入することが考えられる。
-
公開範囲の設定:
- ユーザーが愛の行動報告を公開する範囲を選択できるようにする。例えば、全体公開、友達限定、自分だけなどの設定が可能である。
- 設定した公開範囲に応じて、他のユーザーが閲覧できる範囲が異なるようにする。
-
公開方法の統一:
- 愛の行動報告を公開する方法を統一する。SNSへの自動投稿や、特定のページに表示するなどの方法を提供する。
- ユーザーが公開方法を選択できるようにすることで、柔軟性を持たせる。
-
公開内容の一貫性:
- 公開される愛の行動報告の内容を一貫させる。報告内容には、行動の種類（寄付、ボランティア活動など）、対象者、場所、日時などが含まれる。
- 公開される情報のフォーマットを統一し、利用者が簡単に理解できるようにする。
-
公開期間の設定:
- 公開される愛の行動報告の期間を設定できるようにする。期間が経過すると自動的に非公開となる仕組みを導入する。
- 期間を設定することで、一時的な情報の公開や、期間限定のキャンペーンなどを行うことが可能である。
-
非公開化の手続き:
- ユーザーが公開した愛の行動報告を後から非公開にする手続きを提供する。公開範囲の変更や削除などの機能を用意する。
- ユーザーが誤って公開した情報をすぐに修正できるようにすることで、情報の誤解や問題を防ぐ。
-
利用者への通知:
- 愛の行動報告が公開された際に、他の利用者に通知する機能を提供する。通知方法や内容は利用者が設定できるようにする。
- 通知を受け取ることで、他の利用者の活動に参加したり、支援を行ったりすることができる。
これらの方法を組み合わせることで、愛の行動報告の公開範囲や方法を一貫させることができる。利用者が安心して愛の行動を報告し、共有できる環境を整えることが重要である。
愛貨の利用先
愛貨の利用先を一貫させるためには、以下のような具体的な方法や仕組みを導入することが考えられる。
-
愛貨の利用先の明示:
- 利用者が愛貨を利用できる具体的な場所や団体を明示する。例えば、寄付先の団体や支援プロジェクト、公開されている”ゆらぎ”などを示す。
-
一貫した利用条件:
- 愛貨を利用する際の条件（利用可能な場所、個人や団体、レート、有効期限など）を一貫させる。利用条件は明確でわかりやすく設定する。
-
レートの一貫性:
- 愛の行動を愛貨に交換する際のレートを一貫させる。例えば、愛の行動Lv1：協力する、という愛の行動は100愛貨など、明確なレートを設定する。
-
利用先の情報提供:
- 利用者が利用できるサービスや団体、場所などの情報を提供する。Webサイトやアプリ内で情報を公開し、利用者が容易にアクセスできるようにする。
-
利用者への通知:
- 利用者が愛貨を利用できる新しいサービスや団体、場所などが登場した際に通知する機能を提供する。通知方法や内容は利用者が設定できるようにする。
-
利用先の多様性:
- 利用者が選択肢を持つために、様々な分野や業種のサービスや団体を利用先として提供する。例えば、飲食店、ホテル、企業内、イベントなどを含める。
-
交換手続きの簡略化:
- 愛貨を利用する際の手続きを簡略化し、利用者がスムーズに利用できるようにする。オンラインでの交換や利用申請、QRコード決済などの方法を導入する。
これらの方法を組み合わせることで、愛貨の利用先を一貫させ、利用者が円滑に愛貨を利用できる環境を整えることができる。
愛貨の利用規約
愛貨の利用規約や条件を統一するためには、以下のような具体的な内容を考えることができる。
-
利用可能なサービスや団体:
- 愛貨で利用可能なサービスや団体を明示する。例えば、利用できるサービス、ヘルプしてほしい企業や団体を列挙する。
-
交換レート:
- 愛の行動を愛貨に交換する際のレートを定める。これは時価レートであり、10種類の愛貨の時価を公開することで、レートとする。
-
有効期限:
- 愛貨の有効期限を設定する。利用者が一定期間内に愛貨を利用しなかった場合の取り扱いについても規定する。
-
利用条件:
- 愛貨を利用する際の一般的な条件を定める。例えば、年齢制限、利用回数制限、不正利用禁止などの条件を設定する。
-
手数料:
- 愛貨を利用する際に課金される可能性のある手数料を明示する。例えば、トランザクション承認手数料や利用手数料などを定める。
-
取り扱い注意事項:
- 愛貨の適切な取り扱いに関する注意事項を記載する。例えば、他者への譲渡方法、盗難や紛失時の対応方法などを示す。
-
紛争解決手続き:
- 利用者との紛争が生じた際の解決手続きや方法を定める。例えば、調停や裁判所への申し立てなどの手続きを明記する。
-
利用規約の変更:
- 利用規約の変更に関する条件を設定する。変更があった場合に利用者への通知方法や変更の有効期限などを定める。
-
規約違反への対処:
- 利用者が利用規約に違反した場合の対処方法や制裁措置を示す。例えば、警告、利用停止、法的措置などを明記する。
-
契約解除:
- 利用者が愛貨の利用契約を解除する際の手続きや条件を定める。例えば、解約手数料や解約の有効期限などを示す。
-
その他特記事項:
- 特定の利用条件や制限、重要なお知らせなど、利用者が知っておくべき事項を明示する。
以上のように、利用規約を具体的かつ網羅的に記載することで、愛貨の利用に関する一貫性を保ち、利用者とのトラブルを未然に防ぐことができる。
いかがであろうか、システム評価の一貫性について記載した。システム開発中の開発者たちでの一貫性だけでなく、バージョンアップ時の一貫性もそうであり、ユーザビリティの一貫性もしかり、すべてを考慮して設計していかねばならない。一貫性という項目もまた極めて重要な要素であることが良く分かる。