チームに入ってすぐは、周りに相談するばかりで、良いチームほど助けてもらえるけれど、まるでお客様扱い。チーム内で人間関係を築いて相談できる相手を増やすことは大事だけど、それよりも周りの人たちから相談される存在になることの方が本質。チームとは、背中を預けられる同士の集まりでありたい。

一方的に相談したり助けたりする関係でなく、互いの強みを活かして相談しあうことで、チームとしての成果を出せる。そのために出来ることは、飲み会したり仲良くすることだけではない。チーム内で困ったことが起きたときに、声をかけてもらえるようになるには、自ら発信をして存在感を出していくこと。

例えば、チーム内で他の人には負けないと思えるような特定のスキルを身につけ、それに関するノウハウを発信して周りに知られれば、頼られるようになる。もしくは、スキルに自信がなくても、どんな仕事も前向きに受けることを伝えるだけでも、チーム内で困ったら相談しようと思ってもらえるようになる。

チームの一員だから貢献すべきと考えるより、チームの人たちから頼られる存在になれば本人にとって嬉しいし、それに応えて喜ばれると、さらに仕事も楽しくなると考える方が健全だし長続きする。自分に出来ることを探すのではなく、周りから頼ってもらえるようにする。チームワークに対する発想の転換。

プログラマの成長ステージにも 、仲山 進也さんの加減乗除の考え方が適用できそう。加のステージでは、コードを書いたり読んだりする絶対量が必要。書くほどに速くなるし、経験するほど設計と実装の引き出しが増える。ある程度の要件なら、タスクばらしと見積もりできることを目指す段階。

作りたいものが作れるようになったら、減のステージ。いかに効率的に成果を出せるようになるかを意識する。コスパが上がれば、時間に余裕ができるようになり、新しい技術に挑戦できるようになる。また、チームのメンバーとうまくコミュニケーションして、苦手なことを減らし得意なことに集中する段階。

乗のステージでは、ゼロからフルスクラッチで作れる設計・実装・運用の全般的な開発力に加えて、専門的な技術領域を持ち、その分野でリードできる。チーム内でも他の人を助ける場面が増え、多くのプロジェクトで頼られて、複数の案件に関わりつつセルフマネジメントして並列で価値を出していける段階。

技術領域でなく、バイネームで存在感が出せるのが、除のステージ。仕事はプログラミングだとしても、組織で言えば経営の視点や視野を持ちつつ、自分で考えて成果を出す。自分の趣味嗜好でやっていることと、仕事で成果が出ることが一致しているから、使役される労働ではない。「遊ぶように働く」段階。

いかにチームで「問題 vs 私たち」の構図をつくることが大事で、心理的安全性は結果に過ぎない。問題や成果に向き合えさえできれば、対立でなく協力になる。

率直なフィードバックや意見の対立も、相手を負かすためや、自分の意見を通すためではなく、問題を解決し成果を出すことのためという共通認識をつくること。

心理的安全性のような新しいキーワードを自社に取り入れるためには会社や上司に対し「提案より相談」をすること。提案は現状に対する否定と取られかねない。

味方をつくるには相談から入ること。相手に意見を通すのではなく、相手に相談を持ちかければ、共通の問題に一緒に向き合う構図になり、味方になってくれる。

これも「問題 vs 私たち」の構図のつくり方。ものごとをうまく進めたいならば敵を作らない。そもそも敵などいない。向き合うのは解決したい問題だけなのだ。

私たちがしていることは戦争でも競争でもない。問題を解決すること、成果を出すこと、社会を良くすること。その共通認識が心理的安全性の第一歩ではないか。

「納品のない受託開発」だったり、オフィスなくして全社員リモートワークとか、管理ゼロとか、何かをなくしたり、やめてしまうことで、生産性や創造性を高めてる。

「ない」ことは、メディア受けするインパクトがあんまりないし、アワードなどで良さを伝えるのも難しい。ビジュアルに見せられないし、一言で伝えにくい。

「ない」ことは、装飾がなくてゴチャゴチャしてないシンプルな状態だから、本質だけを捉えてるとも言える。どんなことも、本質的であることは大事にしたい。

増やすより減らす方が美しい。いかに増やさずにいられるかを維持したい。これって、メンテナンス性を高い状態に維持するというアジャイル開発の話と同じなのかもしれない。