同僚からお勧めされたので読んでみたが、難しくて理解できなかった部分がある。自分に取って身近な話題であるソフトウェア開発と対比させつつ、整理してみる。
課題の分離（たぶんわかったところ）
使っているソフトウェアがうまく動作せず、問題の切り分けをしているとしよう。
うまく動作しない原因としては
- 自分の使い方が間違っている場合
- そのソフトウェア自体の不具合を踏んでいる場合
があり得る。ソフトウェア自体の不具合の場合には、自分の使い方が悪いのかといくら悩んだところで無駄 1 で、まずはこれらのうちどちらなのかを切り分けるのが大事である。
そして、使い方の問題ではないと判断したら、そこから先を深追いしないと決めることは無責任な態度ではない。
自身が解くべき課題は、そのソフトウェアを使って何かしらの問題を解決することであり、その不具合を直す事ではないのだから。手立てとしては、
- そのソフトウェアを使うこと以外の方法で解決する
- 不具合の報告をして、直してもらう
などがあるだろう。後者で行く場合には、現象と期待動作、再現手順の情報を整理して、開発者に上手く伝えることまでは自分の課題であり、報告した結果、それを直してもらえるかどうかは自身がコントロールできることではない。2 場合によっては並行して他の方法を探すことも責任ある振る舞い。
「課題の分離」で書かれていることは、コヴィーの「7つの習慣」で出てくる「影響の輪」に集中せよという話と同じだな。
承認欲求に寄らない貢献感（わかってない気がするところ）
オープンソースソフトウェアの不具合を見つけて、手元で修正してプルリクエストを送る場面を考える。
プルリクエストを送る時に考えていることは、自分が見つけた不具合を、誰か他の人が踏むこともあるだろうし、将来の自分がまた踏むかもしれないから、それが直ったら気持ちいいなとかそういうことかな。
送ったプルリクエストは取り込まれることもあれば、違う修正方法のがいいと却下されて別の修正がされたり、それは不具合じゃないよと単に却下されることや、あるいは反応が得られないこともある。
修正が取り込まれなかった場合に自分はそれぞれどういう考え方をしてるか。
別の修正がされた場合は不具合自体は直っているので、報告したことで役に立ったと思える。不具合じゃないよと答えてもらったらそのことは記録に残るので、後で不具合なのかどうなのかと悩む人が減るかもしれない。3 反応が得られないとしたら、そのパッチ当てたらローカルでは不具合回避できることが後から来た人にもわかるし、あるいはあまり活発にメンテナンスされていないんだという事実がわかるようになったりするので、まぁ良いかなと思ってる。
結果がどうあれ、自分の行動は誰かの役に立ってるんじゃないかなと思ってるけど、それが承認欲求に寄らない、自分の主観によって得られる貢献感と考えていいのかな？
役に立つ先の「誰か」が将来の自分ってこともよくあるので、そういう時は昔の自分に感謝したり、昔の自分やるじゃんと自画自賛するし、開発者や他で同じ問題にはまってた人からありがとうって言われることもあって、そういう時はうれしい気分になるし、次もやろうって気になる。それって承認欲求に依存してしまってないのかな？
