StandardとSpecific
Standard
標準。汎化されたもの。
つくるのに手間がかかる
つくるのが難しい
役に立たない標準(特化させづらい)か、標準になってない標準(特化の域を出ていない)になりがち
もちろん質が低いと使い物にならない
期待値も高くなりがち
現場は即効性のあるものを求めている
勉強して、自分の現場に当てはめて、試行錯誤して……みたいなことはしたくない
Specific
現場の成果物。特化されたもの。
何も考えないと、基本的にこれになる
他の用途に活かしにくく、他の人には使いにくい(ともすると本人でさえも)
あと機密情報が入るので共有しづらい(ないしできない)
エンジニアリングの文脈でsecret keyとかそのまま書いちゃう問題と一緒
関係
Standard単体では役に立たない
Specific単体では他に生かせない
Standardを使うには、その現場向けのSpecificに落とす必要がある
情報共有の戦略
Ideal Standard
理想の標準
自分たちでつくるか、権威が整備しているものを使う
Realistic Standard
現実的な標準
現場からSpecificを集めて、それらを元にStandardをつくる
Shareing of Specific
特化のシェア
現場からSpecificを集めて、共有エリアに置くことで、誰でも自由に使えるようにする
Summary of Specific
特化の要約
現場からSpecificを集めて、それらを分析して「有用なパターン」を取り出し、後悔する
---
雑多に
情報共有を阻む壁
現場がSpecificを出さない・出せない問題
Specific=(または≒)顧客の納品物、であり機密保持契約があるから
あえて皆のために出すインセンティブがないから
Specific(に詰まってる)ノウハウを漏らしたくないから
Specificの中身が醜くて(未熟で恥ずかしいなど)漏らしたくないから etc
Standard部隊が現場のドメインを知らない問題
ドメイン知らないので、現場が使えるStandardをつくることができない
そもそもドメインを部外者が学ぶのは難しい
効果が測定されていない問題
そもそも(この業界や界隈やプロジェクトやチームにおいて)Standardは本当に役に立つのか?
Standardを使ったチームのうち、役立てることができた率はどれくらいか?またそのためにはどれだけ学習・鍛錬・試行錯誤したか?
そもそもあるプロジェクトAのSpecific-Aは、別のプロジェクトBでも通用するのか?
たとえばSIはオーダーメイド気味である
ある案件のオーダーメイドな成果物は、そもそも他の案件で使えるに値するものなのか?
etc
---
測定されていないから、使うチームや人が人柱になるしかない