フェアネスと快・不快

大学で常盤先生が心理学の授業中にこんな話をしている夢を見たw

  • フェアネス*1は意識上での認識。
  • 快・不快*2は無意識上での認識が部分的に意識上に伝達されるもの。*3
  • 『言動とフェアネス』は組みで、『事象と快・不快』も組で、記憶に蓄積される。*4*5*6
  • フェアであることが最も重要であり、快・不快はそれに従属する。*7
  • 『フェアネスと快・不快』という視点を生かす方法は、フェアかつ人の気持ち理解できる人間になることのみ。

*1:公平さや信念としての正しさのような広い意味の日本語が見つからないので英語のfairnessを取り込んでフェアネスと表記している。

*2:一般用語としてではなく、心理学用語としての快・不快を指しています。

*3:無意識化での快・不快の強さと、意識への伝達度合いは常に比例するわけではない点に注意。ちょっとした違和感を掘り下げていくと大きな快・不快に変化する可能性もあるし、掘り下げることにより些細な問題となることもある。無意識下で複数の快・不快が関連を持っていることもある(高度な暗示や一部の神経症など)。

*4:言動とフェアネスの組と、事象と快・不快の組は、個別に記憶される。

*5:自分自身への影響という点では、自分で決めたことを破った場合、自分の行動がアンフェアであったという言動とフェアネスと、事象としてはサボったこととサボれたのでラクチンという事象と快・不快が記録される。結果として、自分はサボる人間だということが自己の恒常性に刻み込まれ、サボり癖がつき、サボると快感を得られるという記憶がそれを助長するようになる。

*6:他人への影響という点では、たとえば、AさんのBさんに対する悪口にあなたが迎合した場合、Aさんの頭の中では、あなたが悪口に迎合したという事に対する言動とフェアネス(今回の場合はフェアでない人物と認識される)と、悪口に迎合したという事象と快・不快(今回は快の感情)が、個別に記録される。結果として、あなたはAさんにとって、人の悪口を言う時には気持ちの良い相手としてそういう飲みの席などには呼ばれるようになる。しかし、信頼のおける友人やビジネスパートナーとしては扱われなくなる。

*7:フェアであり快であるということを常に成立させることはできない。たとえば、コンクールの審査では、審査員は参加者全員に優勝者と同じ快を与えることはできない。この時に重要なのはフェアであることと、可能な限り不快にさせないこと。そうすることが、審査員と参加者全員が最も幸せになれる方法。

ThinkPad Compact Bluetooth Keyboard with TrackPointの接続が切れるようになった時のメモ

Windows 10 で ThinkPad Compact Bluetooth Keyboard with TrackPoint(ThinkPad Bluetooth ワイヤレストラックポイントキーボード)の接続が切れるようになった時のメモ。

結論

ThinkPad 側のアップデートで IntelBluetooth ドライバをアップデートしたら治ったっぽい。(2017-08-18現在では全く問題がない)

過去の状況

2017-07-30現在では、どうにも動きが不安定で因果関係がよくわからない。数秒で切れたり(一番多い)、ディスプレイの切り替えがあると止まったり(これは再現性が高い)、ディスプレイの切り替えをやっても止まらないが翌日には止まっていたり(ほとんどない)、そんな感じ。

メモ

  1. 試してみたけど無関係だった設定その1
    • バイスマネージャー
    • Bluetooth
    • インテル(R) ワイヤレス Bluetooth(R)
    • 電源の管理
    • 『電源の節約のために、コンピューターでこのデバイスの電源をオフにできるようにする(A)』のチェックを外してOKを選択。
  2. 試してみたけど無関係だった設定その2
    • バイスマネージャー
    • ヒューマン インターフェイスバイス
    • Lenovo BT Interface Device(HID)
    • 電源の管理
    • 『電源の節約のために、コンピューターでこのデバイスの電源をオフにできるようにする(A)』のチェックを外してOKを選択。

人生がRPGだったら

ふと思いついたのでメモしておく。

  • パラメータ
    • 体力(HP)
      • 体力の原資。時間経過・行動・外部からの刺激などにより変動する。0になると死ぬ。上限は体質改善で可能だが通常の肉体は年齢の影響を大きく受ける。
    • 精神力(MP)
      • 精神的な原資。時間経過・行動・外部からの刺激などにより変動する。0になると行動不能になる。上限は変化せず。*1
    • 信頼(TST)
      • 相手が自分をどれだけ信頼しているか。相手(個人や組織)が個別に自分に対して持つパラメータなので、自分と相手の組み合わせによって値が決定する。
    • 技術(SKILL)
      • 自分の持つ技術。
    • 才能(GIFT)
      • 天性の資質。ゲーム内の隠しパラメータとして多くに影響を与えるが、値として確認することができず、値は固定。*2
  • パラメータに関するルール
    • 時間経過や行動は多くの場合HPとMPを消費するが、睡眠のように回復を伴う行動もある。
    • 時間経過・行動・外部からの刺激などに伴うHPおよびMPの変動量は様々な要因によって変化する。
      • 個人の嗜好:『快』と『不快』の感情により消費量が変わる。*3
      • 自己の状態:自己の状態が『快』と『不快』の感情に大きく影響し、結果としてMP/HP消費量が変わる。*4
      • 外部環境:何らかの行動をする場合、周囲からの期待、監視の目、強制力、などがHP/MPの消費量に影響を与える。*5
  • エス
    • 他人や組織からの依頼や任務。クエストの大きさは TST に大きな影響を受ける。クエストの達成は独力でも人からの協力を得てもよい。*6
    • エストの達成は TST 向上に大きく貢献する。

*1:上限が変化しないという点が重要。これは、精神力という漠然とした1つの力の存在を否定している。どれだけきつい修行に耐えられる格闘家でもピーマンが食べられないとか、どれだけ仕事ができるビジネスマンでも自分の部屋が片付けられないとか普通にあり得る。心理学的にもほぼ定説と言える(あがり症や高所恐怖症などの神経症は漠然とした精神力というものでは説明できない)。

*2:特別な理由がない限り、GIFTの影響が強いと思われるものを変更するのは避けたほうが無難。例えば性格を変えようとか、どれだけ努力しても人並程度すら程遠い運動競技への固執とか。

*3:『快』と感じることを増やし『不快』と感じることを減らすのがHP/MPの消費量を下げることにつながる。

*4:例えば、歩くという行為は、足を怪我している時は痛みなどにより不快感が増しMP消費量が増加するし、傷口が開いたり出血すればHP消費量も増加する。

*5:例えば締切り前の漫画家の場合、一人で原稿を上げるだけのMPが無くても、編集からの催促やホテルへの缶詰めなどによるMP消費低減策により原稿の上がる可能性が増す。アシスタントを増やすという方法は、自身の行動量を減らした結果として自身のMP消費が減るだけであり、行動に対するMP消費の低減とは異なる。

*6:自分個人で自分に対してクエストを発行することはできない。

java や kotlin でもポインタを扱いたい件

多角的に検証してないけどとりあえず思い付きをメモしてみた。

状態を持つ Session オブジェクトを UI から操作する場合を考えてみる。

Session が単一の interface を持つ場合は、特定状態では実行不可能なメソッドを叩くと実行時例外がスローされるように作ることが多い。

しかし、そもそも実行不可能なメソッドを叩けなくするというアプローチもある。状態遷移を起こすメソッドの戻り値を状態遷移イベントにして、その中に次の状態用のインタフェースを入れておくとか。

この場合、状態用のインタフェースの参照を UI が保持してしまうと、Session 側で破棄されても UI 側で使えてしまう。もしそれがポインタであれば、Session 側で ポインタの値を null にするなり新しい値にしておけば、古い参照を使用することが不可能になる。

実際問題として正しいコードを書く分にはポインタがあろうがなかろうが関係ないのだが、assertion のコストが全然違う。UI側が古い参照を叩いてしまうというバグについては、ポインタが使える場合はヌルポで落ちるだけなので何もしなくてもよいということもある。しかしポインタが使えない場合は古いものを叩いた時に実行時例外をスローするような仕組みが必要となり、それを入れないとエラーと気づかないまま間違った動作をしてしまう可能性がある。

現状だと開発者に対するルールで縛るしかなさそうな気がする、、、。

Database Answers

Database Answers というサイトがあった。

50以上の業界と1500以上のデータモデルが含まれているらしい。

特定業界向けのシステム開発をする際のデータ構造や命名の参考になるかもですね。

interface 仕様をコードで記述する

とりあえず絵の餅を描いてみるw

interface 上に定義されている関数について、document に仕様を記述し、実装クラスに実装するというのは結構普通に行われるが、その仕様がほぼ純粋に複雑なロジックだった場合、以下のような問題がある。

  • ドキュメント中に書かれた自然言語によるロジック説明が非常にわかりづらい上に曖昧。
  • ドキュメント中のロジックが正しい保証が得られない。
  • 複雑なロジックであればあるほど、ドキュメントとコードが乖離する可能性が高まる。また、乖離したかどうかを確認する機械的な手法が無い。
  • 疑似コード方式でロジックを検討するにしても、疑似コードは実装フェーズの成果物である実装クラス上で行うものなので、要求開発時には行えない。要求開発時に行うためにモジュールの外部インタフェースのドキュメントとして記述するとしても、実装との乖離が無いように保守する必要があり、また、どれだけコストをかけても実装との乖離が無いことを証明する方法がない。*1

上記のような問題を扱う工数をかけるより、kotlin であれば interface 上にソースコードを書いてしまうほうがラクチンな気がする。以下案:

  • 仕様レベルに属する interface のロジック仕様を記述する抽象クラスを作成する。
  • 仕様インタフェースレベルのドキュメントには概要を記述するが、ロジックは一切記述せず、抽象クラスへのリンクを見せるだけにする。*2
  • 抽象クラスは Xxx を implements して XxxBase という命名で統一。(Xxx は仕様レベルに属する interface の名前)
  • 抽象クラスに疑似コードを記述するという作業を全てのモジュールインタフェースに対して行い、その後、仕様レベルのロジックのみ実コードに置き換えていく。*3
  • 仕様レベルで決定する必要が無いロジックは TemplateMethod として実装クラスに丸投げする。*4
  • 切り出したいロジックがある場合は、必要に応じて別関数として切り出す。*5

上記の成果物までを要求開発フェーズの後半に含めることにより、低コストかつ高精度で要求開発の精度が上がるんじゃないだろうか。予想可能な一定の工数を支払う代わりに予想不可能な実装フェーズでの手戻りを減らせるという効果が期待できるかも。特に、開発後期に大人数を投入してリードタイムを削減する場合、設計への手戻りコストが非常に高くつくので、この方法は有効な気がする。

絵に描いた餅おしまいw

*1:そもそも、このような保守は、進捗と品質のトレードオフという概念が存在する組織では成り立たない。品質の全責任を負い、品質以外の一切の責任を持たず、開発部門の全権限を上回る権限を持つ品質管理部門が無い限り無理。

*2:意味的に結合しているので依存しても問題ない。っていうか依存させるべき。

*3:疑似コード作成者はその疑似コードに対する実コードを書いてはいけないというルールがあるといいかもですね。同一の人物やペアが実装することが常態化すると疑似コードの品質維持が難しい気がする。もしくは、レビュー参加者からランダムで実装者を選ぶということにすれば、全レビュー参加者が気を抜けなくなる気がするw

*4:例えばソートする必要がある場合など、ソートアルゴリズムは非機能要件さえ満たせれば何でもいいので仕様記述に含める必要が無い。っていうか含めちゃいけない。

*5:構文的かつ意味的にも重複しているコードの切り出しは必要だが、それ以外のコードの切り出しは細かく切り出し過ぎないように注意する。メソッドは短いほうが良いというのは過去のプラクティスであり、別メソッドに切り出す理由がメソッドの長さだけであるならすべきではない。選択や反復のブロックも、目視するのに困難なレベルの複雑さ以外の時は切り出すべきではない。

疑似コード(pseudocode)について

ふと思ったのでメモ。

疑似コードをプロジェクトで正式に採用したことはないんだけど、要求開発のツールとしてドメインモデリングを採用する際に、インタフェース設計の後に一段階入れても面白いかも。予想されるメリットは以下:

  • インタフェース設計のみより多くのフィードバックが期待でき、コストもそれほど大きくない。*1
  • リリース後の保守コストがゼロ。*2
  • 工数の見積もりが高精度で立てられ、かつ、この活動によって、工数の読みづらい実装時の手戻りを削減できる。*3
  • ソースコードシンタックスエラーを気にして不必要に細かいところまで考えてしまうことが無くなる。
  • 実装時にソースコード上のコメントを考えることや、実装後に後付けすることが無くなる。結果として、実装に準じるようにうまくコメントを書くという本来と逆の思考により不適切なコメントを書くことを避けられる。
  • レビュー時に、実装技術の細かい話の話になったり、レビュー者が実装技術の細かい点につい意識を持って行かれるようなことが無い。*4
  • ダメな案を抱えてしまうリスクの排除。*5

要検討な点:

  • 疑似コードを利用するかどうかの判断が必要になる。*6
  • 書式をある程度一般化する必要がある。*7
  • 複雑だが本質的なロジックの場合、ソースコードを直接書いたほうが厳密かつ分かりやすいよね。そういう場合にどうするか。*8
  • どこまで疑似コードで掘り下げるかの判断基準が必要。*9

*1:インタフェース設計フェーズを拡張するだけで行けると思われ。

*2:リリース時には疑似コードはすべて実際のコードに置き換わっているため。

*3:固定金利と変動金利スワップのようなもので、リスク管理手法としてはかなりおいしいと思われる。

*4:設計レベルのレビュー時にインデントのスタイルとかスペースの入れ方とかfor/while/forEach等のどれを使うべきかとかを話しても意味がない

*5:コーディングまで完了させてしまうと、心理的にそのコードを捨てづらくなる。数行の疑似コードであれば捨てやすい。

*6:setter/getterなどに作っても意味が無いので。しかし、setterにバリデーションがあったらどうなの?とか考えだすと、かなり明確な判断基準がないと運用が難しそう。っていうか、全部疑似コードを書くと決めてしまったほうが早いかもですね。単純なgetterならお決まりの文を1行入れるだけなのでコストはかからんし、後でバリデーションロジックなどが入るかもしれんし。そもそも疑似コードを書くという行為によって『バリデーションいるんじゃね?』的な気付きを得られる可能性が増すという考えもあるよね。

*7:順次・選択・反復系をどう表すかなど。たぶん、いくつかのパターンの例を示しておく程度でもいい気がする。形式化しすぎると本末転倒だし。

*8:例えば、独自サービスのポイント付与ロジックとか、大半はプログラミング言語の syntax で記述したほうがわかりやすいと思われる。

*9:インタフェースからほぼ自明な処理は疑似コードは書かず、そうでないものはすべて機械的に実装に書き換えられるレベルの粒度まで掘り下げてもいいかも。しかし、ドメインモデルのインタフェース直下ではなく派生したルーチンとかクラスが必要になる場合は要検討だけど、直観的にはそこまではやらんほうがいいと思われる。そこまでやったらもう要求設計フェーズじゃないよねwww。ドメインモデル以外については、臨機応変にやるのがたぶん正解。作業者のレベルや経験値やコード資産の流用などによる影響が大きすぎるので。