他者の苦労を先んじて奪い過ぎると労苦の総量を増やす

苦労して成功した人は信用しちゃいけない

最近なんかこう変な話なんだけど、橋下さんとかブラック企業の社長さんの物言いとか見てると、「やっぱ苦労して成功した人は信用しちゃいけないな」って思わされちゃうよなあ。本当変な話なんだが。
— あでのい@１７歳女子高生 (@adenoi_today) 2011年11月19日

　たまたま見かけたこのツイートに考えさせられた。確かに苦労して成功すると、他人にも同じ苦労させるのが最善手だと思いがちだし、自身のモチベーションと他人のモチベーションが同じところにあるように勘違いしやすい。

　誰もが圧倒的成長や大きなリスクを求めている訳ではないし、そこには生存バイアスも含まれている。そもそも、当時に上手く行った方法を模倣できるには時代環境が異なっている。むしろ、害悪の方が大きいように思える。

親切すぎるマニュアルの陳腐化問題

　それはそれで正しいし、僕自身の規範にもあるのだけど、必要な苦労まで取り除いてしまいつつあるのが現代なのかもしれないと思ったりもする。例えば丁寧なマニュアルが整備されたり、ネット上のチュートリアルが充実するほどに、作成当時と少しでも違う部分があったらフリーズしてるとか、意味も分からずコピペしたりする人も出てくる。

　マニュアルが整備され続けていれば問題は減らせるのだけど、それをなぞるだけではマニュアルを作る側の人間にはいつまでたってもなれないし、そもそも完全に固定化した手順であれば自動実行できるコード化をしておけば作業者自体が不要となる。状況変化への対応が織り込まれているから仕事になるのだ。

苦労させてあげる余裕がない言い訳

　そんな状況になったら時間をかけて試行錯誤をしながら、手順書をブラッシュアップするような経験を積んでもらった方が良いのではないかと思ったりもするのだけど、時間がかかるようであれば正解を与えてしまいがちだ。

　その場では優しい上司なり先輩だと思うかもしれないけれど、実態的には経験のショートカットが後の負債になってしまうのではないかという危機感と、さっさと人手が欲しい余裕のなさが同居している。魚を与えるか釣竿を与えるかという話だ。

苦労を奪い過ぎても労苦の総量を増やす

　本来的に削減すべきはトイル（労苦）であって、苦労ではない。『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』においてトイル(労苦)は以下に多く当てはまる作業と定義され、その削減ができなければ新しい事ができなくなる害悪だ。

手作業であること
繰り返されること
自動化できること
戦術的であること
長期的な価値を持たないこと
サービスの成長に対してO(n)であること

　しかしながら、試行錯誤の苦労によってなされる成長や変化対応力は長期的な価値を持つし、新しく発生したトイルを自発的に削減する存在にもなっていける。他者の成長を目的変数に加えると、しなくても良い労苦なのかを判断する事こそが難しいのだけど、苦労を奪い過ぎてしまうのも結果として労苦の総量を増やしかねない事は意識したい。