何か組織で困りごとがあって、改善したくなった時につい、「素晴らしいワークフローを設計しました！この手順書通りにやれば皆さんのタスクが楽になってWin-Winになります！」と設計・整備だけして手離れしたくなる。
でもこのケースは大抵の場合、「手順書見てもよく分からなかった」と言われて上手くワークせず失敗する。実際には疑問を解消するほど時間をかけるものだと思われていないのが失敗の本質で、このケースが成功する例は凄い管理職がいるか、熱心な信奉者がいるパターンしかない。
逆に全然イケてないフローでも鶴の一声で仕組みが変わる事は往々にして存在する。
結局、動機付けと責任の所在が決まらないと誰も動いてはくれない。人間は変化を嫌うというが、そこを変えるだけのエネルギーを持って推進する人がいないと何も始まらないと実感する。人は想像以上に権威主義で「あの人がそこまで言うならやろう」がほとんどの原動力なんじゃないかと感じる時がある。
自分ごとで考えると、プロダクト開発で技術選定にOSSを使うときはそのOSSの信頼性が担保されている事を選定基準に含めている。コントリビューターがOSS品質に責任を持っているから初めて利用するのであって、メンテナがいない謎OSSは使う訳もない。
はじめから完璧を目指したいし、設計が楽しくてつい考えすぎてしまうのだが、人を巻き込む時のやり方としては下策中の下策なんだと思った。
その点、知識や経験を持った人間は初速で確度高く設計して、人を巻き込める点で有利なので、そうなっていきたい。
設計をしたうえで、推進もしなきゃいけないのか...と嫌気が刺すが、「お前がやりたいんだろ？じゃあ、お前がやるんだよ」というメンタリティで動いていこう。