チームプレーで成果を上げよ

みなさんは「システム開発の仕事」と聞いて、どのようなイメージを持つだろうか。

「一人で黙々と作業する仕事」「周囲とのコミュニケーションが少ない仕事」といった印象を持っている人もいるだろう。

事実、このイメージばかりが先行して「なるべくコミュニケーションを取りたくない」という理由でソフトウェアエンジニアを目指す人もいる。

しかし、JobPicksに寄せられたロールモデル投稿を見ると、「ソフトウェアエンジニアの仕事はチームプレーである」、つまりコミュニケーションが重要視される職業だとする声が非常に多い。

DMM.comの奥野慎吾さんは、チームで働くことの重要性を次のように指摘している。

イメージとは裏腹に、社会で活躍するソフトウェアエンジニアのロールモデルたちは、自分たちの仕事を「チームで働く職業」だと捉えているようだ。

では、どうしてチームプレーが求められるのだろうか。その詳細を見ていこう。

「自分で調べる」は通用しない

GoogleでChromeブラウザのAPI開発などに携わった安田絹子さんは、チームプレーが求められる理由を次のように語っている。

ソフトウェア開発の最重要スキルとは？グーグルのエンジニアに聞く

2008年にリリースされたChromeは、改善と進化を重ねながら、今まで90回以上のメジャーアップデートを行ってきました。

コードの行数は膨大で、全てを把握している人は1人もいないと言えるほど複雑なシステムになっています。

多くのエンジニアが毎日コードを変えているので、ある時期に把握していた仕様が、後日見たら大きく変わっていたということも日常茶飯事です。

だから、分からないことがあったら、今、一番詳しい人に聞くしかない。「自分で調べて」と言っても、無理があるんです。

エンジニアリングは技術の進歩が非常に早く、かつて正解とされていたものがいつの間にか廃れてしまうということが少なくない。

また、システム開発が大規模になるほど、その全貌を1人で把握することは難しくなるため、自ずとチームメンバー全員で協力して最善を尽くすことが求められる。

Googleのような大企業になるとその傾向は顕著で、チームプレーを意識しなければ、そもそも仕事にならない状況になってしまうようだ。

また、アトラエのTagamiShogoさんによると、たった一つの機能を開発するだけであっても、考えるべき要素が膨大にあるのだという。

これまでの話を受け、ソフトウェアエンジニアは個人プレーの職業ではなく、チームプレーの職業だということが、よく理解できたと思う。

ただ、それだけではない。

ソフトウェアエンジニアが仕事で成果を上げるには、同じ職業だけでなく、異職種とのコミュニケーションも大切なのだそう。

ギフトパッドの小林梨沙さんは、ランディングページ（LP）を作成する際、異職種と一緒に仕事を進めた経験を以下のように語っている。

成果を上げるためにチームプレーが必須なら、良いチームであればあるほど、出せる成果も大きくなっていくだろう。

自分よりもチームに意識を向ける

では、良いチームをつくるために、メンバーができることはなんだろうか。

BASE BANKの東口和暉さんは、「目の前の仕事に追われるのではなく、周りを見渡して、同僚の仕事の状況を押さえる意識」について指摘する。

自分の成長にとらわれるのではなく、常にチームとしての成長を意識する。それによって、やるべきことが整理され、出せる成果の大きさも変化していくのだろう。

また、アトラエの佐藤夢積さんは、「自分の成長ではなく、会社の成長を優先すること」で、結果的に自分が成長できると語っている。

仕事の大局観を持たない若い時代は、良かれと思って自分だけで努力をしてしまうことがある。その気概は大切だが、成果を上げるという意味では、行動を改めるべきなのかもしれない。

「分からない」と発言する勇気

良いチームで、良いチームプレーをするためには、工夫も必要だ。その一つが「期待値のすり合わせ」。

消防士から未経験でエンジニアに転職した川俣涼さんは、期待値のすり合わせの重要性を次のように語る。

消防士からエンジニアへ、究極の「未経験転職」3つのポイント

最初にもっと、周囲との期待値を擦り合わせておけばよかったなと思います。

バリューを発揮できていなかった時期は、ずっと「結果を出さなければ来年で雇用契約が終わってしまうんじゃないか」と焦っていたので......。

正社員入社なので、そんなことがあるわけがないのですが、それくらい思い詰めていました。

今考えれば、消防士からエンジニアに転職して、1〜2カ月ですぐに結果が出るわけがありません。もっと時間をかけてよかったです。

期待値のすり合わせは、仕事をもらう側だけではなく、仕事を渡す側にも工夫が必要だ。

DMM.comの石垣雅人さんは、エンジニアからPMになったばかりの頃、「なぜこの仕事をやるのか？」という説明をあまりせず、「今これが必要だからやってほしい」といったようにお願いしていたそうだ。

しかし、それではチームメンバーがポテンシャルを発揮できなかったため、仕事のお願いの仕方を次のように変えたという。

未経験エンジニアが20代部長に。DMM石垣雅人の成長支えた5つの掟

こういう戦略があって、●●さんのキャリア的にもこういうタスクにチャレンジするのは良さそうですよね、と話すようにしたんです。

チームメンバーは僕より年上の方が多いので、自分から悩みや失敗をさらけ出すのも意識するようにしています。

大上段に構えて事業戦略や技術の話をしても、エンジニアとして僕より経験豊富な方からすると「それは分かってるよ」となってしまいます。

なので、例えば「僕はこう考えているんですけど、●●さんはどう思いますか？」「今これについて悩んでいるんですけど、■■さんはこういう経験ってあったりしますか？」などと、「僕が」チームを頼るというスタンスに変えました。

すると、徐々にですがボトムアップで意見が出てくることが増えたんです。

相手の視線に立って仕事をお願いすることは、当たり前に思えるかもしれない。しかし、日々タスクが積み上がっていく現場でそれを実践するのは、「言うは易く行うは難し」だ。

また、丁寧なすり合わせが行われたからといって、分からないことに突き当たるシーンも少なくない。そのようなときに重要なのが、カジュアルに質問する技術だ。

質問する技術がチームの成果を最大化することは、前出のGoogle安田絹子さんの発言からも伺える。

カジュアルに質問するスキルは、ソフトウェアエンジニアとして働く上でけっこう大事だと思っています。意外とできない人が多いからです。

私自身、若い頃は「自分で調べて問題解決できる人が優秀だ」と思い込んでいました。実際のところ、開発現場では自分で調べる姿勢も強く求められます。

ただし、調べるのに何時間もかけるくらいなら、分かる人に聞いたほうが前に進めます。それに、異なるチームに入った時は、そのチームのやり方を知る努力も必要です。

プログラムや開発の進め方に関して、「分からないことを伝える」ほうが円滑に進む場合があるのです。

これまで挙げてきたコミュニケーション術は、システム開発に限った話ではない。多様なメンバーが集まる仕事全般で役立つものなので、ぜひ明日から実践してみてほしい。

文：安保 亮、編集・デザイン：オバラ ミツフミ、バナーフォーマット作成：國弘朋佳、バナー画像：iStock / Nuthawut Somsuk