私は、もともとコミュニケーションが得意な人間ではありません。

本音を言えば、一人で黙々とプログラムを書き、それが思った通りに動くことを楽しんでいたいタイプです。

若い頃は、仕事でも人との関わりを必要最低限にしたいと思っていたわけではありません。

むしろ、新人の頃は、

「分からないことは聞かなければ」

「進捗は報告しなければ」

と思っていました。

でも、先輩や上司は忙しそうに見える。

話しかけたら邪魔ではないか。

今聞いていいのだろうか。

そんなことを考えて、遠慮してしまうことがありました。

そして経験を積み、中堅になってくると、今度は別の問題が出てきました。

できることが増え、知識も増える。

すると、

「これくらいなら自分で判断できる」

「必要最低限だけ相談すればいいか」

「人に説明するのも面倒だな」

という気持ちが出てくる。

振り返ると、これは自分への過信と油断でした。

私自身、これまで経験した不具合の根本原因を振り返ると、技術力が足りなかったというより、

「自分なら大丈夫だろう」

という過信や、

「ここまで確認しなくても大丈夫だろう」

という油断があったことが何度もあります。

20年以上エンジニアとして仕事をし、さらに人や組織を見る立場になった今、私は自分自身にこう言い聞かせています。

「技術より人を見ろ」

技術を軽視しろ、という意味ではありません。

私は今でも技術が好きです。

でも、どれだけ技術力が高くても、一人だけで良い製品や強い組織を作ることはできない。

そう気づくまでに、私は何度も失敗しました。

新人の頃は「遠慮して聞けない」が失敗の種だった

新人の頃は、分からないことがたくさんあります。

当然、先輩や上司に聞かなければ仕事は進みません。

私も頭では分かっていました。

それでも、忙しそうにしている先輩や上司を見ると、話しかけることをためらってしまうことがありました。

「これくらいは自分で調べた方がいいのではないか」

「こんなことを聞いたら、できない人だと思われないだろうか」

「今は忙しそうだから、もう少し後にしよう」

そうやって遠慮しているうちに、確認が遅れる。

報告も遅れる。

その結果、もっと早く聞いていれば簡単に済んだことに時間を使ってしまう。

今、年齢を重ねて逆の立場になった私は、若手にはむしろ話しかけてほしいと思っています。

分からないことがあるなら聞いてほしい。

違和感があるなら報告してほしい。

もちろん、人によっては忙しいときに話しかけられてイライラすることもあるかもしれません。

それでも少なくとも私の経験では、遠慮して問題を抱え続けるより、早めに相談してもらった方が仕事は進めやすいと感じています。

そして今は、

若手が話しかけやすい雰囲気を作ることも、上の立場の仕事の一つだ

と思うようになりました。

新人の頃の自分には、

「遠慮するな。聞いた方が仕事は早く進む」

と伝えたいです。

中堅になると「遠慮」が「過信と油断」に変わった

ところが、経験を積めばコミュニケーションの問題がなくなるかというと、そうでもありませんでした。

むしろ私の場合は、別の形で悪化しました。

仕事が分かるようになる。

似た製品の開発経験も増える。

トラブルも経験する。

そうすると、自分の中に、

「これは経験したことがあるから分かる」

という感覚が生まれます。

もちろん、経験は大切です。

経験が増えるほど、判断できることも増えます。

でも、その経験がいつの間にか、

「誰かに聞かなくても大丈夫」

「自分の判断で進めればいい」

という過信に変わることがありました。

さらに、人に説明したり、レビューをお願いしたりするには時間もかかります。

忙しいと、

「今回はいいか」

「必要最低限でいいか」

という油断も出てくる。

私自身、振り返ると、不具合の背景にはこうした過信や油断がありました。

新人時代は、

遠慮して聞けなかった。

中堅になると、

自信がついて聞かなくなった。

理由は違いますが、結果として人の視点を借りなくなっていた点では同じでした。

品質は、一人の頭の中だけでは守れない

製品を開発するときには、実現したい機能があります。

その機能は開発の中心なので、当然、

「意図した通りに動くか」

をしっかり確認します。

いわゆる正常系です。

でも、本当に難しいのは異常系です。

ユーザーは、開発者が想定した通りに使ってくれるとは限りません。

予想もしなかった順番で操作するかもしれない。

想定していない条件が重なるかもしれない。

だからこそ、多くのパターンでテストし、想定外の使われ方にも耐えられるか確認する必要があります。

ここで大切なのは、

そのパターンを一人ですべて出し切ろうとするのは、現実的ではない

ということです。

どれだけ経験があっても、自分には自分の考え方の癖があります。

過去の経験が豊富であればあるほど、

「以前もこうだったから、今回も大丈夫だろう」

という思い込みが入ることもあります。

だからこそ、チームメンバーをはじめ、多くの人に意見を出してもらう。

別の経験を持つ人に見てもらう。

違う視点から、

「こういう使い方をされたらどうなる?」

と考えてもらう。

私は、その方が結果として品質を高めやすいと考えています。

私は過去に似た製品の開発経験があるからと、

「今回は自分で十分考えられている」

と思い、人に意見を求めることを省いてしまったことがあります。

そういうときほど、後になって、

「あのパターンを考えていなかった」

ということが起きます。

不具合が起きた後に、

「あの時、誰かに意見を求めていれば」

と思っても、時間は戻せません。

ここから私は、

人に意見を求めることは、自分の技術力不足を認めることではない

と考えるようになりました。

自分にはない経験。

自分にはない専門性。

自分にはない視点。

それを製品に取り込むために、人の力を借りる。

技術力があるから一人でやるのではなく、

良いものを作りたいから、人に聞く。

今はそう考えています。

後輩や部下に、自分の答えを押しつけたこともある

人との関わりで失敗したのは、製品開発だけではありません。

特に後輩や部下とのコミュニケーションでは、自分の未熟さを感じることが何度もありました。

若手の中には、自分の考えを言葉にすることが苦手な人もいます。

何を言いたいのか、すぐには分からない。

説明を聞いても、話があちこちへ行ってしまう。

そんなとき、私は徐々にイライラしてしまうことがありました。

さらに期限が迫っていると、焦りも加わります。

「もういい。こうすればいい」

「自分の考えの方が正しい」

と、自分の意見を答えとして押しつけてしまう。

相手の考えを十分に理解する前に、自分の思うように仕事を進めようとしてしまうことがありました。

今振り返れば、これは私が現在目指している采配型のマネジメントとは真逆です。

相手がうまく説明できないなら、

こちらが理解できるまで時間をかけるべきだった。

言葉を待つ。

質問する。

何を考えているのか、一緒に整理する。

それができていれば、相手自身が考え、自分で決め、主体的に動くことができたかもしれません。

そうすれば、その人自身の成長にもつながったでしょう。

結果として、仕事の生産性も高くなっていたのではないか。

今ではそう考えています。

コミュニケーション能力というと、

「分かりやすく説明する力」

を想像しがちです。

もちろん、それも大切です。

でも、

相手の話を理解しようとする力

も同じくらい重要なのだと思います。

相手が話すのが苦手だからといって、自分の答えで上書きする。

それでは、人を見ることにはなりません。

「人を見る」の意味は、立場によって変わっていった

私にとって「人を見る」という意味は、キャリアとともに変化してきました。

若手の頃は、

誰が何を得意としているのか。誰に頼ればよいのか。

を見ることが中心でした。

中堅になると、

誰が責任者なのか。誰が決定権を持っているのか。そして、自分は誰を助けられるのか。

という視点が加わりました。

管理職になってからは、

自分より二つ上の役職者ならどう考えるか。経営層や各部署のキーマンは何を見ているのか。

と、見る範囲が自分のチームから会社全体へ広がっていきました。

私はこうした、人の得意分野、役割、権限、関係性を頭の中で整理することを、

「人間マップ」

と呼んでいます。

若手の頃は「誰に助けてもらうか」が中心だったマップも、経験を積むにつれて、

「誰を助けられるか」

「誰と組めばより良い成果が出せるか」

という視点が加わっていきました。

この人間マップについては、
職場の「人間マップ」を作る|仕事は誰に頼るかで変わる
で詳しく書いています。

2020年頃、仕事の対象が「製品」から「組織」に変わった

2020年頃から、私は現場の開発から手を引き、本格的にマネジメントをするようになりました。

それまでの私は、製品を作ることで価値を出していました。

これまでの製品を開発現場でのお話はコチラ
「技術派遣からメーカーへ転職した理由」「このままでいいのか?」から始まった決断

しかし、立場が変わると、求められるものも変わりました。

自分が良い製品を作るのではない。

組織を強くし、その組織が継続的に成果を出すことで利益に貢献する。

それが自分の仕事になりました。

では、どうすれば強い組織を作れるのか。

この問いには、分かりやすい正解がありません。

技術を磨けばよい。

ツールを導入すればよい。

制度を変えればよい。

そんな単純な話ではありません。

私はここ数年、この問いを考え続けてきました。

成功したこともあります。

失敗したこともあります。

課題もあります。

悩みもあります。

そして正直に言えば、

今でも、強い組織を作るための正解が分かったとは思っていません。

それでも、確実に言えることが一つあります。

強い組織を考え続けて、最後は「人」に戻ってきた

組織も、結局は人の集まりです。

組織を強くするためには、そこにいる一人ひとりが成長し、力を発揮できる状態になることが欠かせません。

どれだけ良い戦略を考えても、それを実行するのは人です。

どれだけ良い仕組みを作っても、実際に使い、改善していくのは人です。

どれだけ高い技術を持っていても、人同士がうまく力を合わせられなければ、大きな成果にはつながりません。

成果は、最終的には人の判断や行動、関係性に大きく左右されます。

ここ数年のマネジメントを振り返り、過去の開発時代の成功や失敗まで思い返してみると、私は最近になって、

結局、仕事は人に行き着くのだ

と感じるようになりました。

そして、それを自分自身への戒めとして一言で表すなら、

「技術より人を見ろ」

になります。

これは、

「技術なんて重要ではない」

という意味ではありません。

私は根本的には技術者です。

新しい技術を見ると今でもワクワクします。

技術の勉強も続けています。

でも、20年以上仕事をしてきて思うのは、

技術だけを見ていてはいけない

ということです。

誰が何を得意としているのか。

誰に助けてもらえばいいのか。

誰を助けられるのか。

誰が困っているのか。

誰が決める人なのか。

相手は何を考えているのか。

自分より上の立場の人は何を見ているのか。

技術と同じくらい、人を見る。

むしろ、技術に集中しすぎる自分だからこそ、

「技術より人を見ろ」

くらい強く言い聞かせないと、また同じ失敗をする。

だから、この言葉は読者への命令ではありません。

私自身への戒めです。

あなたは、周りの人を見ることを後回しにしていないでしょうか

エンジニアにとって、技術を学ぶことは大切です。

私もそう思っています。

でも仕事では、自分一人では解けない問題が必ず出てきます。

そのとき、

「もっと技術力があれば」

と考えるだけではなく、

「誰の力を借りれば、もっと良い答えに近づけるだろう」

と考えてみる。

それだけでも、仕事の進め方は変わるかもしれません。

私自身、もっと早くそれに気づいていればと思うことが何度もあります。

だから今も、

技術より人を見ろ。

そう自分に言い聞かせています。

今日の一歩

今、自分だけで判断しようとしている仕事を一つ選んでみてください。

そして、

誰か一人に意見を聞いてみてください。

自分とは違う経験を持つ人。

違う専門性を持つ人。

少し違う立場からその仕事を見ている人。

人に聞くことは、自分の力が足りないと認めることではありません。

より良い成果を出すために、自分一人では持てない視点を借りること。

まずは、そこからでいいと思います。