生き様180. 設計と認知の歪み
仕事初めですね
おはようございます。
皆様の仕事始めはいつからでしょうか？
ほぼカレンダー通りの４日からの人、成人の日を超えて10日からの人、様々でしょう。
特に本日５日から仕事始めとなる方は多いのではないでしょうか？
白栁も、その中のひとりです。
初日は年始朝礼や挨拶回りで作業が進まなくて……。
とはいえ、それらも大切なお仕事。
期末に向けて立て込んでいく仕事に、気持ちも新たに向かうことにします。
そして、毎週木曜日更新で行っている本コラム。
例年のごとく年末年始期間中も変わらず更新をしておりました。
特に年明けには恒例？の旧年の振り返り＆新年の抱負コラムも投稿しております。
今回の記事合わせて、是非ご一読下さい。
レビューを受けて気付いた癖
皆さんの職場では、設計レビュー／コードレビューは行われていますでしょうか？
白栁は教育的なレビューに関わる為、レビュアーとして参加する機会が多いのです。
しかしながら、レビュイー（レビューを受ける側）としての貴重な機会も得ています。
その中で、自らの設計の癖みたいなものに気付くことができました。
具体的には、以下の２つです。
- 外部から受けたデータ（入力・受信）をなんでも残そうとする
- 過剰かつ汎用的な機能で対応しようとする
これらがどういう意味があるか、は今回は脇に置いておきます。
これが正しい設計である現場もあれば、そうではない現場もあるからです。
設計の中にある「経験則」
要件から仕様を起こす際に、よく「経験則」をベースにする人が居ます。
白栁もそのひとりです。
経験則以外の設計要素といえば、
- 技術的な定石
- プロジェクトの設計思想
- DDD・ユースケース駆動などの設計思想
など、多くの要素があります。
これらを全部まとめて「経験則」という人も居ますが……。
アップデートできていないことに対する言い訳に聞こえます。
耳が痛いですね。
今までの経験から得られた知見というものを否定する訳ではありません。
それは、過去の成功体験だけではなく、失敗体験を乗り越えたものでもあるからです。
とはいえ、その全てに価値がある、という訳でもありません。
過去の経験を基とした設計が、プロジェクトの理念に合っているか？
これをレビューの中で検討していく訳です。
そうして、建設的かつ発展的な議論を経て、成果物の品質向上を狙うのです。
経験の中の「認知」と「歪み」
ですが、この「経験」という部分は、個人の「認知」に影響される部分です。
それは、単純な趣味嗜好の部分から、過去の傷まで様々です。
例えば、白栁の「過剰かつ汎用的な機能で対応しようとする」という癖があります。
これは、「こんなこともあろうかと」や「汎用性・拡張性」が大好きという好みです。
その一方で、仕様が定まらない、急な仕様追加・変更がある場合に備えるという面もありました。
後者は、認知の「歪み」となり得る部分です。
プロジェクトでそこまで仕様が固まっていないのか。
仕様変更があった場合、その機能で吸収する必要があるのか。
もっと根本的な変更になるのではないか。etc…
様々な検討をする中で、白栁の中にある杞憂であった、と気付くことができました。
もちろん、これが正しく作用するケースもあります。
他者の経験則を基にした設計だからと、検討をせずに切り捨てるのは早計です。
極論、設計が正しかったかが判るのは、システムの運用が終了した時です。
その時に「問題なく運用ができていた」と評価できて初めて、正しい設計であったという評価ができるものだと考えています。
それまでは「より正しそう」を選択し続けるしかないのです。
認知の歪みと向き合う、心理的安全性
ここからは余談であり、白栁の願いです。
白栁は、産業カウンセラーとして、認知の歪みと向き合う方法を知っています。
しかし、これはとても苦痛と困難を伴うことです。
自分一人でそれと向き合うことは、特別な適正を持たない限りできません。
もしくは、かなりの訓練が必要でしょう。
もし、レビューの中で他者の認知の歪みと出会ったら……。
頭ごなしに否定し、切り捨てるのではなく、しっかりと向き合って下さい。
そして、歪みの存在を受けいられれる場を設けて下さい。
それは、必ずしも限りあるレビューの場である必要はありません。
その枠から外れた場であっても、認知に寄り添うことで次に繋げていく。
そういう、発展的なレビューをして欲しい、と願っています。
それもまた、一つの心理的安全性の形なのだと考えています。
以上！