パネルディスカッション：先達に聞くこれからのエンジニア像 2016（前編） エンジニアサポートCROSS 2016

昨今の急速な技術進歩の中で、技術者はどのような生存戦略をとって成長していくかべきか。こうしたことをテーマにしたパネルディスカッション「先達に聞くこれからのエンジニア像 2016」が、2月5日に横浜で行われたイベント「エンジニアサポートCROSS 2016」で行われました。

スピーカーは 楽天 よしおかひろたか氏、Increments 及川卓也氏、ICTトラブルシューティング実行委員会 伊勢幸一氏。司会はニフティ 森藤大地氏。

リーダーとしてチームメンバーをどうしたらモチベートできるのか？ イノベーションを起こすヒントとは、そしてコミュニティとどう付き合うのかなど、スピーカー3人の経験談や意見が語られています。

セッションの内容をダイジェストで紹介します。

与えられた環境でどうすればパフォーマンスを出せる？

森藤　今回は、スピーカーのみなさんが若かった頃、予算やメンバー、責任など、与えられたリソースの範囲で最高のパフォーマンスを出すためにどういう働き方をしてきたのか。チームを任されたときに。そのチームを率いるために、メンバーを巻き込んでいくためにどのような将来像や世界観を見ていたのか。

そして最後に、現在オープンソースソフトウェアの世界が広がっている中で、オープンソースやコミュニティへの関わり方についてもお伺いしていきたいと思います。

森藤　まずは最初のテーマなのですが、みなさんが若かった頃、与えられた環境の中でベストのパフォーマンスを出すためにどんなことを考えていたのでしょうか？

伊勢　20代の頃はやっぱりペーペーだったので与えられた環境なんてなくて、これをやれと言われたら、ヘイとサーバーを小脇に抱えてお客様のところへいく、という、そんな感じで、深く考えていたことはなくて。もうつねにベストを出さざるを得なかったと。

ただそのあと少し歳をとると、条件や予算などが与えられるんじゃなくて、自分から提案するようになるんです。そこで、自分が100％やればこれくらいできるかなというのにマージンを乗せて、それで上司やお客様を説得する、といったことをしていたと思います。

森藤　サーバを小脇に抱えていた頃、自分のスキルセットをどう考えていたのでしょうか。

伊勢　20代の頃はベンチャーにいたこともあって、会社でどう評価されるかより、顧客にどう思われるかを気にしていました。

吉岡　私が大学を卒業したのは1984年なので30年以上前なんですね。その頃の話をしても役に立たないかもしれないけど、この30年でやっと気がついたのは、世界はソフトウェアでできていると。

伊勢　それ、このテーマとどういう関係があるんですか？（笑）

吉岡　それって与えられたコンディションでベストを出すというのは時代の背景があって、私は新卒でハードウェアのベンダに入りましたけれど、いまはハードウェアの会社ってほとんどなくなっちゃって。

いまこの会場だと、SIerの会社にいる人は？（ほとんど手が挙がらず）、じゃあWeb系の人（あちこちで手が挙がる）。やっぱりCROSSはWebの人が多いですね。どんな会社を選んでもいいけど、Web系の会社を自分で選んでいるという意味で、今日の会場にいる人はいいことなんじゃないかなと思いました。

及川　吉岡さん、飲んでます？（笑）

創造性は制約を好む

及川　これは上司に言われた言葉なんですが、「及川君、リーダーというのは与えられた条件で最大のパフォーマンスを発揮して、結果を出さなくてはいけないんだよ」と。

僕の最初の会社は吉岡さんと一緒でDECで、マイクロソフトがWindows NTを開発しているときにDECが作っていたプロセッサへの移植プロジェクトのリーダーとしてマイクロソフトのレドモントに派遣されたんですね。

ところが行ってみると問題が山積みで、ハードがないとか詳しい人がいないとか。日本と電話会議があるたびに、あれが足りないとかこれが足りないとか言ってたんですが、言ったからといって解決するわけでもないんですね。新しいプロセッサだからハードもまだほとんどないですし、詳しい人もいないのは当たり前で。

それで上司が言ったのが、及川君が言っていることはわかるけれども解決する見込みもないわけだし、そのなかでどうするかを考えることであなたはリーダーになるんだよと。確かにそうだなと思いました。

もう1つ話をすると、前職でGoogleという会社にいたんですが、そこで今はYahoo!にいるマリッサ・メイヤーという人が「Creativity loves Constraints」、創造性は制約を好むと言ったんですね。

ふつうにやっていたら解決しないような強い制約の中で、エンジニアやデザイナーからすごいイノベーティブなアイデアが出てくる。

私がChromeを担当していたときに、Chrome OSを作るというのがあったのですが、Chrome OSチームはノートPCのフタを開けて電源を入れて10秒でユーザーにGmailなりを使ってもらえるようにしようと考えていました。

これは、例えばノートPCの起動に1分かかる時間を40秒にしたからといってイノベーションは起きないんですね。これを10秒にするという制約条件が厳しいほど、普通のやり方では作れないからイノベーションが起きる。

この考え方はソフトウェアの開発でヒントになるけれど、人間のリーダーシップも同じで、ハードも足りないし詳しい人もいない、そういうときにどうするか考えていけば何かアイデアが出てくるし、おそらくそこにリーダーとしてや人としての成長もあると思います。

及川　いやー、すごいきれにまとまったね。（笑）

相手にそれを言わせるのがいい

森藤　こうしたらチームの結束が高められたとか、そういう経験で印象に残っていることがあれば、みんなの参考になると思うので教えてください。

伊勢　社内初とか世界初とか、そういうプロジェクトに関わるのは魅力を感じるじゃないですか。そう思わせるようなプロジェクトにして、命令されたからとかじゃなくて、一緒に世界初を実現しようとか達成しようとか、そういうチームメイキングをして頑張っていく、というのはよくあったかなと。

及川　伊勢さんが言われたことは大事だと思っていて、与えられたんじゃない、誰かに言われたんじゃなくて、一緒にやりたいとか自分がやりたい、という形にする。

例えば人を指導する立場になった時、ちょっと姑息なんだけど、自分でこれをやりたいなと思った時でも、これをやりましょうって言うんじゃなくて相手にそれを言わせるのがいいと思うんです。

人は「これをやれよ」と言うと反発してしまうけれど、「こういうときどうするか相談に乗ってくれよ」と言って、相手が言葉を発したときにはすごいモチベートされているんですよ。

しかもモチベートされているだけじゃなくて、もしかしたらその人によって違うやり方を見つけられるかもしれないんです。

例えば僕はGoogleでIMEを作っていました。その頃はまだWindowsにも詳しかったしIMEの仕組みも分かっていたので、チームの人間が「こうしよう」と言ったときに「こうしたほうがいいんじゃないかな」というときもありましたけど、あんまりそれは言わないようにしていたんですね。で、結果は失敗しましたということもありましたが、かなりの確率でいい結果になったんですよ。

相手に自分の口から入ってもらうことでモチベーションを持ってもらえるし、新しいアイデアも出るので、チームとかイノベーションのヒントになるかなと思います。

吉岡　昔はひとつの会社に閉じて仕事をするのが多かったのですが、最近では社外の人とのコラボレーションが多くなってきましたよね。

私はDECで文字コードの標準化委員会に出ることがあって、そこでいろんな会社の人たちと仕事をすることがありました。そこで強く思ったのは、標準化の会議で会社の利害がぶつかるわけです。それでも標準化を進めていくには、こういう共通の文字コードがあると便利だよね、という理想があって、それだけは共通のゴールとしてくずさないようにして利害関係を調整するしかないわけです。

やっぱり原理原則というか理想を持って共感を得つつ、技術的に説得力のある提案に収れんしていくのではないかなと思いますね。

伊勢　吉岡さんが言うのはすごく分かって、会社の指図とか言われたことしかできない人たちが100人集まってもすごい結果なんて出せなくて、だけどどんどん提案してくる、自分で考えて積極的に行動できる人たちが集まると10倍の成果も出せる。それがいちばん効果的だと思いますね。

モチベーションだけだと根性論につながる

森藤　いまモチベーションが大事だという話がありました。しかし何もできない人がチームのリーダーとして世界に通用するものを作っていこう、と掛け声をかけても、お前何言ってんだよ、と思われてしまうと思います。

技術者の中で後輩指導のやり方だったりフォローのやり方だったり、みなさんはどうしてきたのでしょうか。

吉岡　モチベーションが重要とよく言われるんだけど、それは、なんでも根性論になってしまう危険性があるんです。だからベースとして技術をしっかり身につける必要があって、チームとしてゴールが明確になっていてそれを全員が理解している必要があって。

そのためにはコミュニケーションが大事で、それは言葉でも行動でも示すことがありますし。基本はモチベーションよりコミュニケーションだと思っています。

森藤　そのコミュニケーションは、吉岡さんはどうやったのですか？

吉岡　例えば毎日10分間、昨日やったこと、今日やること、困っていることをミーティングする。SCRUMですよね。こんな簡単で当たり前のことで、隣の人といままで俺は会話してなかったんだと気がつく。上手なマネージャはそれを本能的に顔色を見て雑談しにくるとか、そういうのをやってるじゃないですか。

及川　Lean開発でいうとMVP（Minimal Viable Product）だったり、チームでプロダクトやサービスに対する世界観を持てているかが大事だと思うんですね。これは昔から言われていることで、今何を作るべきかがきちっと共有されていないと、何を削っていいのか、何を足していいのかがぶれていく。

私は「テーマ」と言っていましたが、例えばGoogleのChromeではテーマは3つのS、SpeedとSecurityとStability、この3つだけです。いまChromeにはいろんな機能が入っていますが、もしスピードが落ちる機能があればボットがいてチェックインさせてくれないんです。

テーマが決まっていて方向性が決まっているのなら、ソフトウェアの開発方法論はなんだっていいと思います。SCRUMだっていいし、ウォーターフォールだって合っていればそれでかまわない。何を作るかという世界観が共有できているかが大事だと思います。

森藤　その世界観は、じゃあ誰がどういう根拠で示すのか気になりますし、その世界観に対して、別の意見を持つ人もチームの中にいると思うのですが、それはどうすればいいのですか。

及川　もう1つ言おうと思っていたのが、リーダーだったりマネージャだったりという人には、その人を信頼できるかどうかっていうクレディビリティが大事だと思います。

ある製品のテーマを3つ考えました、これでいきます、というときに、そもそもおまえわかってねえだろ、とか、どれだけ実績があるんだよ、というのではない。だからそれまでの行動だったり実績がチームマネジメントでも大事だと思います。

でも日本人はそういうの言わないんですよね。日本でLinkedInは不評で、でもアメリカ人はきらびやかに実績を書きまくるわけですよ。そこまでやれとは言わないけど、自分はどういう経験や実績があるのか、そういうのを含めて人としての信頼性が大事だと。

ただし、こんな人がいるチームばかりではないと思います。民主主義だけではなかなか進まないところもありますが、そういうときは全員で考える。そこで決まったことで作っていこう、ということができると思います。

≫後編に続きます。後編では、大きなミスをしたら？ コミュニティとの関わり方は、などについて語られます。