良いって聞いてたけど読めてなかった「岩田さん」を読んだ。マネージャーとか、チームでコラボレーションして何かを成し遂げたい人には刺さる本だと思った。
印象に残った言葉
一番印象に残ったのは「プログラムの経験が会社の経営に活きている」のところの内容。
プログラムというのは、純然たる、純粋なロジックなので、そこに矛盾がひとつでもあったら、そのシステムはちゃんと動かないんですね。
機械のなかで間違いは起こらないんですよ。間違いは全部、機械の外にある。だから、システムが動かないとしたら、それは明らかに自分のせいなんです。
...
人と話してうまくいかなかったら、「わからない人だな」と思う前に、こっちが悪かったんだろうと思う。うまくいかないのならば、自分が変わらないといけない。この人に合ったやり方を、こちらが探せば、理解や共感を得る方法はかならずある。
ここを読んで、実際こういう考え方でコミュニケーション取っていくとうまくいくこと多いなと思って納得しかけたんだけど、引っかかるところがあって、ちょっと考えた。
うまくいかないといけないのか
人と話してうまくいかないとき、別にうまくいかなくてもいいよと頑張らないときもあるよなと。関係を良くしていく必要性のない間柄だったらそれでいいのではと思った。
ただし、該当箇所は会社の経営について書かれているので、相手は同じ会社の仲間とか、仕事で関係する人で、うまくいくことで価値が得られるような状況の話をしていると思った。確かにそういう時は頑張ってもいいかなと。
自分が変わらないといけないのか
俺悪くないよ、これについては絶対相手が悪いもん、って思うことはないかと問われたら、あるな。 プログラムの話でいくと、どうにも説明つかなくて、これ絶対環境の問題だわーって思っちゃうことあるある。大抵は思い違いで、最終的には自分の書いたところに原因があるとわかるんだけどw
とはいえ、レアケースではあるものの、自分が書いた部分以外にシステムが動かない原因があることもあって、使っているライブラリだったり、言語処理系だったり、あるいはハードウェアに起因するケース。自分自身そういった状況に遭遇したことも何度かある。
そういう時、できれば原因箇所を直したいと考えはするものの、ハードはもう製造しちゃったからとか、そこを直すスキルがないとか、そこ直すと他にも影響が出ちゃうからとか、納期が…とか色々な理由で、原因箇所とは違うけど、自分が変更できる部分で対処することが割とあった。自分の目的である価値を届けることを優先すると、原因がどこかなんてどうでも良くて、システムがうまく動かないことを回避して価値を届けられればいいわけで。*1
コミュニケーションの話に戻ると、そちらも目的はうまくいくことなのであって、原因箇所がどこかなんてどうでもいい。自分が変わるという手段を取ってうまくいくならそれでOK。なので、自分が変わらないといけないというわけではないけど、自分が変わればうまくいくはずって思う戦略を取るという話だと受け取った。
何とかできることをひろげる
相手がシステムでも人でも、自分と相手との間でうまくいかないことが出てきたとき、もしそれを何とかしたいなら、問題は相手の側にあり変えられないと諦めるんじゃなく、まずは自分の行動や考え方を変えて何とかなると信じてやってみる。それを繰り返していって自分で何とかできることがひろがっていくといいな。
本の半分がWebで公開されていた
上で引用した所は無料公開分に含まれているけど、刺さりそうな人はぜひ買って全体を読むといいと思う。
*1:可能なら後から原因箇所に対してもフィードバックおくと良い。バグ報告出すとか修正提案するとか。
