2017.07.05 水.

まつもとゆきひろ氏×寺本昌弘対談【後編】企業とエンジニアの関係について

RubyMatzまつもとゆきひろRubyistmruby企業
2017年7月5日、福岡県東総合庁舎5階Rubyコンテンツ振興センターにて行いました、Rubyの生みの親である、まつもとゆきひろさんと、Vareal株式会社 代表取締役 寺本昌弘の対談の模様を2回に渡りお届けします。 今回は、企業とエンジニアの関係性、採用問題、受託開発のメリット・デメリット、海外の企業と国内企業の比較など多岐にわたってお話を伺いました。
まつもとゆきひろ

Ruby開発者
まつもとゆきひろ

プログラミング言語「Ruby」の生みの親。1993年頃からRubyの開発に着手し1995年にフリーソフトとして公開。NPO法人軽量Rubyフォーラム理事長を始め、株式会社ネットワーク応用通信研究所フェロー、一般社団法人「Rubyアソシエーション」理事長、米Heroku Chief Architectなど、肩書多数。三女一男一匹の父である。温泉好き。鳥取県出身、島根県在住。牡牛座。O型。

寺本昌弘

Vareal株式会社代表取締役社長
寺本昌弘

京都大学工学部工業化学科卒。2006年05月に京都市左京区にてVareal株式会社を創業、設立。2011年02月 福岡市に本店を移転し、2014年04月にはRubyに特化した開発を開始。東京・福岡を中心にICTコンサルティング、ICTソリューションの提供、システム・ソフトウェア開発などの事業を展開している。美味しいもの、日本酒、ワインが好き。好きな言葉は「今やらねばいつできる、わしがやらねばたれがやる(平櫛 田中)」。福岡県北九州市出身。

企業がエンジニアに求めること


「いい人が欲しい」の「いい」って、割と未定義で外部化されていない。

寺本昌弘寺本

それでは少し話題を変えまして、エンジニアについてお話いただけたらと思います。
先ほども申し上げたように、現在多くの企業で課題となっているのは、欲しい人材がなかなか見つからない、マッチングしないというところだと思うんですよね。
例えば採用なんかでも、そういうエンジニアたちを募集する場合に、アピールをして募集をかけているわけですけれども、そう言った魅力的な…

まつもとゆきひろMatz

(RubyistBizのランディングページを見ながら)Rubyのいいエンジニアいないかなぁって書いてある(笑)いないかなぁ(笑)。

...

寺本昌弘寺本

なかなかいないんですよ(笑)。まぁ、そう言った素晴らしいエンジニアを迎え入れるためには、会社として、どういうポイントに気をつけたらいいのかなとか、もしあればお教えいただけたらいいのかなと思うんですけど。

それは、つまり、松本さん自身がプログラマであり、プログラマというのはこういう気質だよというお考えがあるかなと思うんですが、そう言ったポイントがあれば…

まつもとゆきひろMatz

え〜っと…なんでしょうね、あの…割とね、人が欲しいっていうのってすごい漠然としてるんですよね、「いい」人が欲しいって。でも、「いい」ってなんか、割と未定義ですよね(笑)。

寺本昌弘寺本

(笑)

まつもとゆきひろMatz

だから、こんな人が欲しいっていうような言い方をしてそれが十分に定義されていると、それに対して準備するんじゃないかなという気はするんですよね。

寺本昌弘寺本

なるほど。

まつもとゆきひろMatz

だから、レギュレーションっていうか、これこれの条件を満たしているってことがちゃんと言えれば、それに向けて準備するんじゃないかなぁと。

働きたいって言ってきてる人もいるんですよね。応募してくる人もいて、なんだけど、その人は、結局、良くないって言われてるわけ(笑)。

応募者が0だからというわけではなくて、応募者がいるんだけど、その中にクオリファイしてる人が少ないっていうことのように聞こえるんですよね。実際面接とかしてないから分からないけど(笑)。

ていうことは、経営者または採用担当をしている人の頭の中にはあるんですよね、これこれの条件を満たしてる人が欲しいというのが。

でも、それってあんまり外部化されない気がするんですよね。

最近の傾向として、コミュニケーション能力を重視する企業が増えている。

寺本昌弘寺本

なるほど。
私が感じているのは、企業がそういったプログラマなりSEなりを求める時に、最近の傾向として、もちろん開発能力はあるというのが大前提なんですが、コミュニケーション能力をすごく乞うている会社さんが多いように見えますね。

まつもとゆきひろMatz

(手で膝を打って)はい!

寺本昌弘寺本

その背景が20年前であれば、1つのある程度大きなプログラムを作ろうと思えば、最低数人のプロジェクトを組む必要があったところが、最近は、例えばAWSなんかのクラウドのサービスが発展していたり、あるいは、SaaS(ソフトウェアアズアサービス)で簡単に連携できるようになっている。一人のプログラマ、エンジニアに対する要求が非常に高くなってきている。そこで求められているのは、もうワンストップで、じゃ、君やってよと。
具体的には、ビジネスの要件を伝えて、こういうものが欲しい、みたいな感じ。その人が考えて、こんな感じですかね、と。要件定義をして、設計をして、プログラミングしてっていう、本当に多種多様な能力を一人に求められているような気がしています。

まつもとゆきひろMatz

「求められている気がする」、んじゃなくて、求めているんですよね?(笑)

寺本昌弘寺本

そうですね、求めていますね(笑)

...

まつもとゆきひろMatz

寺本さん求める側だから(笑)

寺本昌弘寺本

そうなんですよ(笑)あんまり言い過ぎちゃうと、それは求め過ぎでしょって怒られちゃうんで。

まつもとゆきひろMatz

そりゃ、求めるのは当然っちゃ当然ですけど、それがいないって話なんですよね。

寺本昌弘寺本

そうなんですよね。そこまで歌って踊れる、エンジニアだとどこでも引っ張りだこで、数も当然少ないんで。
それじゃ、どこまでのラインまでだったらという、妥協ではなく、特質を生かして採用を考えるかっていうのが大事なんですかね。
スーパープレイヤーはいない。ではどうするか。

まつもとゆきひろMatz

スーパープレイヤーはいないところにどうするかっていうことを考えていくのが組織の力だと思います。いないなら、方法は、育てるか、チームでやるかのどっちかしかないですよね。そうすると、要求してるものもまた変わってくるっていう感じですね。
それは外部化しないといけないと思うんですよね。
だって、なんとなく「僕、Rubyできるんです。寺本さん雇ってください」って言いに来ますよね。

寺本昌弘寺本

はい。

まつもとゆきひろMatz

その時に話をしたら、「なんかちょっと俺が求めているものと違うからごめん」ていうわけですよね。じゃ、求めてるものなに?って私だったら聞きたい!いや断られるにしても聞きたい!(笑)。
そしたら、「次回、再チャレンジしますから」って言えるじゃないですか。そこを伸ばすために勉強して来ますって。でもなんか、「いや、なんかちょっと違うから」って言われた時に、「今後の活躍をお祈りします」って言われると、「い、いや、お祈りされても…」って(笑)。

...

現在の知識レベルがどうかというより、自発的に学習、成長できるか。

寺本昌弘寺本

これは弊社の話ですけれど、採用する時の基準で重要視しているポイントが複数あるんですが、一つは、先ほど申し上げたコミュニケーション能力なんですね。
他の特質としては、自分自身で学習できるかどうか、というところをポイントに見ています。現在のレベル、知識がどうかというより自発的に学習、成長してくれるようなところを押さえています。
最初数ヶ月間、ちょっとわからないし、時間がかかるかもしれない。でも、もう3ヶ月、4ヶ月経ってくると、実際開発しているアプリケーションの領域においては、充分知識を身につけてくれるかな、というような感じはあります。
それでお客さんから求められる時に、我々のビジネスで課題にもなっているのですが、社内で開発している時は、そうやって、経験が浅くても育ってくれるのでいいとしています。
でもお客さんはいきなり、2年、3年経験者じゃないとダメ!と言われる会社さんが多いんですね。
まぁ、気持ちはわかるけれども、そこのギャップを埋める方法を、まぁ、なんとか、業界全体、あるいは、我々サイドで考えていかないといけないのかなというところがあります。

まつもとゆきひろMatz

そんなこと言うところは断ったらいいじゃないですか(笑)
結局信頼してないわけですよね。
黙ってたら、新人だけでクオリティの低いソフトウェアを納品されるかもしれない、と思われてるからそう言うわけなんですよね。
だけど、少なくとも受託っていうケースを選ぶ場合には、「技術のことがわからないから我々に開発をお願いするわけだから、技術のことは任せといてください、いいようにしますから」っていうポジションに持っていかないと辛いんじゃないかと思うんですよね。
その時に、Ruby1.xを使ってくださいとか、Rails2.xを使ってくださいとか、あるいはJavaじゃないとダメだとか指定をするのは、そもそも信頼されてないわけですよね。信頼関係がない時に良いプロダクトは作れないと思うんですよ。
こっちにしては制約しかないんですよね。
せっかくあなたのために私たちの持っている技術の全部を使って良いプロダクトを作ろうと思っているのに、足枷をかけるとはどういうことよっていう風に言うべきじゃないかと僕は思っているんです。

寺本昌弘寺本

なるほど。まぁ確かに。

受託開発について


受託は対立関係になりやすい。

まつもとゆきひろMatz

受託ってすごい対立関係になりやすいんですよね。
お客様はできるだけ安い値段で色々やってほしいって思っているわけです。受ける側は、できるだけ高い値段で、できるだけ楽に、お客さんが満足するプロダクトを納品して、お金をいただければ一番いい、って思ってるわけです。
できるだけ仕事をしたくない人と、できるだけ仕事させたい人との間に対立の構図が発生しやすい構造、これが一番問題なんだけど、その時だけど、じゃ、一緒にいいもの作ろうねって言う信頼関係があったら、一番いいものが作れるわけじゃないですか。
一番いいものを作るために、じゃぁ、仕様はちょっとこっちで考えますよとか、お客様に言えるし、一番良いものを作るために一番良い技術選択肢ができるように、我々の持ってる技術を提供しますよって言う話になる。
その時に、お客さんが制約をかけるってことは、もう、邪魔をしてるわけですよね。我々開発する側が、一番いい技術を提供したいのに、Rubyのバージョンでサジェストできないとか、自分の持ってるリソースの内に無駄が出るような、新人は使えないってことだから、新人の育成するお金出せないわけですね。
そう言うその、足枷をかけるってことはお前とはいい仕事はしたくないと、お前をできるだけ安くこき使いたいと言っているのと同じですよね。
そういう人といい仕事はできないと思うんですよね。(笑)

...

解決策として導入した準委任という契約形態

寺本昌弘寺本

最近多いのがですね、まぁ、おっしゃる通りで、受託は本当に対立関係になりやすいので、準委任と言う形でプロジェクトを進めることが増えて行ってはいます。
と言うより、お客さんにオススメしています。
それで理解してくださるところは、開発の経験値が高い企業が多いですね。
プロジェクトの途中で、要件は変わるし、機能追加・改修あるいは「あぁ、やっぱりこっちがいいね」っていうものが入る。
他の外部要因、内部的な要因も含めてプロジェクトは遅延していく可能性があるので、そういった契約に縛られない、いつまでにこの料金でという形で準委任契約での形が増えている気がします。

まつもとゆきひろMatz

そうですね。そっちの方向に進むので、妙な制約をかけるお客さんは、その制約や注文はお客さんのためになりませんよと言うことを伝えて、それでもわかっていただけないならやっぱり切るって言うことにならざるを得ないんじゃないかなと思っていますけどね。一緒に仕事しませんって。(笑)
まぁ、僕は経営したことないですけれど、経営者の立場に立って考えたら、せっかく来ている仕事を断るってすごい嫌だと思います。だけど長い目で見たときにはやっぱり、条件合わなければ断るってことも必要じゃないかと思うんですよね。

寺本昌弘寺本

あの、一応お伝えしますと、これはですね。RubyistBizという、クライアントさんが見るようなコンテンツなんです(笑)

まつもとゆきひろMatz

僕は言いますけれどね(笑)業界全体のためにならないので(笑)

寺本昌弘寺本

(笑)わかりました。(笑)ちょっとオフレコの部分が(笑)

まつもとゆきひろMatz

あの、適当に編集してください(笑)それはお任せします(笑)割とホイホイ、時々過激なこと言うんで(笑)

寺本昌弘寺本

ははは…(笑)わかりました。ありがとうございます(笑)

...

プログラマの成長を加速させる方法とは


寺本昌弘寺本

それでは最後に、エンジニアの「育成」について。この言い方を僕はあまり好きでなくて、外部からその人を無理やり引き上げようとしているんで。成長と表現すればいいですかね。
エンジニアが成長する上で、プログラマとしてそれを加速させる方法ってあったりしますか?

みんなが同じ方向を向いて、理不尽のない組織で伸びる。

まつもとゆきひろMatz

理不尽なことがないといいな、と思ってるんですよ。
仕事してても、なんでなんだよ!って叫びたいことって結構あるわけですよね。特にそれがマネージャーの都合になることがすごく多くて。
そういうのがない体制って、(エンジニアが)理不尽な目に合うと、萎縮したりとかするわけですよね。
最近読んだのは、人は叱られると60%生産性が落ちるっていう話聞いて。
叱られるっていうのは、ミスしたときに非常に怒られるんだけど、仕事上のミスってミスなんだけど、怒っても改善しないんですよね。
そりゃ怒ってるのは、マネージャーが迷惑を被ったから怒りをぶつけてるだけなんで、別に仕事的になんのプラスにもならないんですよね。
かつ怒られた方の生産性が60%下がったら会社にダメージがきてるわけなんですよね。
それはトータルして見るとすごい理不尽なんです。
マネージャーが納得したいために、開発者に何とかを強いるみたいな、非常に細かい手法を求めるとか、レポート書いてる時間で開発時間の半分奪われたみたいなことは平気であるわけですよね。
そういう理不尽って積み重なっていくと、その全体の生産性を下げていったりとか、あるいは、モチベーションを下げたりとか、トータルで会社全体としての生産性を下げることに繋がっているように思いますね。
逆に、自分のやってることと、会社の目指してることと、あるいはその、会社の目的の一つは、やっぱり良いプロダクトを作ることだと思います。例えば受託でも、自社でサービスの開発でも、良いものを作るっていうことに対して、開発者も、デザイナーも、マネージャーも、プロダクトオーナーも、あるいは経営者も、同じ方向を向いていたら、違う方向を向いてるんだけど一緒の方向ってどっち?っていうことを話し合う余地があるんだったら、のびのびと働くことができるし、伸びる余地もあると思うんですよね。
そういう意味で、理不尽のない組織っていうのが伸びるところなんじゃないかなと思うんですよね。

...

寺本昌弘寺本

うーん、なるほど。

まつもとゆきひろMatz

同じ方向を向いてたら、じゃ、このレポートはその、良いプロダクト作るのに本当に有効ですか?っていう観点で、誰でも発言できるわけじゃないですか。
だけどそれは、じゃぁ、途中のそのプロジェクトマネージャーの進捗管理の線を引くために必要なんだけど、「その線って本当に生産性に貢献してる?」っていったら、「いや、してないよ」って言ったら止められるわけですよね。

寺本昌弘寺本

なるほど。だから、そのプログラマが置かれてる環境を、マネージャーの方から、「形が決まってるんだから、これでやれ」とかじゃなくて、むしろ、その制限を取っ払ってあげるような、まぁ、もちろん、プロジェクトとしてはちゃんと進行させないといけないので…

まつもとゆきひろMatz

もちろんね。終わらないプロジェクトに良いプロダクトはないので(笑)

寺本昌弘寺本

ですよね。だからその、効率を上げる方法を一緒に考える、と。

海外企業にみる「いい組織」とは


自社サービスを作っているところは同じ方向を向きやすい。

寺本昌弘寺本

なるほど。
まつもとさんは海外も含めていろんな会社を見られてると思います。
「この組織はよかったな」というのはありましたか?

まつもとゆきひろMatz

全般的にいうと、自社サービスを作ってるところは同じ方向を向きやすいんですよね。
KPIとかも、そのサービスを使ってるお客様はこういう風なことをしたらプラスとかいって、出されるので、じゃぁ、そうするためにはどうしたらいいですか?っていうのを開発者から、みんなが同じ方向を向いて開発しやすいというとこがあるんですね。
受託開発のところは、 その分だけ対立の構図があちこちで発生しやすいんで、それを克服するために、より多くの努力が求められると思いますね。
契約によって、クライアントと会社との間に対立が起きる、契約を取る営業とそのプロジェクトマネージャーの間で対立が起きる。それで、管理をするプロジェクトマネージャーと管理される実質開発者の間での対立が起きる。あらゆる間で対立が起きやすいですね。
これを何とかして、同じ方向に向けるっていうのが、受託における非常に大きな課題になると思います。

寺本昌弘寺本

なるほど。

日米の企業の違い


そのプロジェクトのためにプログラマを雇ってプロジェクトチームを作り、プロジェクトが終わったら契約終了。受託開発じゃないので対立の構造が起きづらい。

寺本昌弘寺本

日米の会社を色々ご覧になってると思うんですが、日米間での差で何か感じられることはありますか?

まつもとゆきひろMatz

私の知ってる範囲内だと、例えば大きな企業でシステムを開発しますっていうときに、海外だと受託開発っていうケースを取らないことが多いんですよね。
そのプロジェクトのためにプログラマを雇って、プロジェクトチームを作りますと。社内は、みんな社員なわけなんですね。
社内で、この社内システムを開発するためにみんな一丸となって頑張りましょうって言って、そのプロジェクトが終わったら、大多数のソフトウェア会社は、プロジェクト終わりました、契約も終わりました、あなたはもう正社員じゃありません。じゃ、次の職場にどうぞ。っていう感じです。それで、メンテナンスのために一部の人が社員として残るっていうケースが多いですね。
そうすると、受託開発じゃないので、さっき言ったような対立の構造が起きづらいっていうのはある。これはアメリカの話ですけど。

寺本昌弘寺本

なるほど。
人材の流動の仕方っていうのが全く違いますね。

...

まつもとゆきひろMatz

そうですね、日本だと雇った人を簡単に辞めさせられないんで、その辺でも採用するのも大変です。バッファーとしての人材、開発者人口を確保するのも大変なので、そのための、受託開発する企業ってのは、まぁ最近の企業ではたくさんあるっていうのは産業構造の違いが結構大きいと思いますね。
だけど、その分、大きなチャレンジを受けてる、あるいは言い方を変えるとハンディキャップを受けているってのは確かにあると思います。

自社サービスの会社においては継続・発展が第一。
受託の会社は新しいプロジェクトにアサインし、新規の技術に関われる。

寺本昌弘寺本

その辺の話しで一つ思うのは、あるブログで読んだんですけども、自社サービスをやってる会社においては、サービスの継続・発展が第一なんです、と。
それで、我々、受託の方って、毎回新しいプロジェクトにアサインして新規の技術に関われることって多かったりするんですね。
この場合、僕らの視点は、あくまで技術・開発なんで、そこにフォーカスしやすい理由・メリットも実は技術者に対してあると感じてるところがあるんですよね。
ただ、先ほど仰ったように、お客さんも選ばないと、Ruby1系、Rails1系でやってくれみたいなことになって、大変な目にあったんですけどね。
でも実は、そういった初期の技術に触れやすいというメリットはあったりするんですよね。

まつもとゆきひろMatz

そうですね、さっきまで受託をボロクソに言ってたような気がするんですけど(笑)
でも僕が所属している、ネットワーク応用技術研究所っていう松江の会社も受託の会社だし、受託そのものが全く問題があって撲滅すべきだって思ってるわけでもないんですよね。
例えばすべての企業がIT企業になるって言われつつも、すべての企業が自社で開発できるわけではないので、そのギャップはどうにかして埋めないといけないわけですよね。
日本の雇用形態上、アメリカのようにプロジェクトの時だけ雇います。みたいな形態が取れない現状において、受託っていうのは、ITが必要なんだけど自分で開発することができない人の助け船としての存在意義ってのは確かにあると思うんですよ。
ただ、そういう社会的な意義があっても、その産業構造上、対立が発生がしやすくて、難しい、チャレンジを受けているっていう風なことを自覚していらっしゃらない方が多いんで、自覚してないと、問題には巻き込まれるのは間違いないんで、危ないところをね、気をつけもせず走ったら事故するのは当たり前なんで、そこは自覚的に気をつけてやりましょうねってお話になると思うんですね。

エンジニア一人当たりに求められることがどんどん増えている。
コンサルティング要素も求められている。

寺本昌弘寺本

私が、最近感じてるのが、一人当たりに求められることがどんどん増えてるっていう話しましたが、まぁ突き詰めると、コンサルのような形になっていく部分もあるかなと感じているんですね。

まつもとゆきひろMatz

いや、まさにそうですね。

寺本昌弘寺本

はい。なので、受託の開発の方向としては、一人一人の能力を高めて、開発能力があって、更に上から、これまでの経験を生かしてコンサルティングをする。
こういうものが作りたいんだったら、こういうやり方はどうか、提案含めてできるようになっていくのが、一つの姿なのかなと思ってます。

まつもとゆきひろMatz

うん。…というポジションを目指さないといけないんで、例えば、コンサルタントが自分の会社に来た時に、じゃぁ、あなたが、うちの経営分析をするときの手法はこれこれの手法を使わないといけません、と注文つけるなんて無いじゃないですか。
それと同じぐらいのポジションを得たら、こういうやり方でやれって向こうから注文してくるのはおかしいって話になるじゃないですか。
つまり、受託を受けている企業そのものは、自分たちに対する信頼度を上げないといけないし、信頼してもらえないお客さんとは付き合えないってお話にならないと、筋通んないんじゃないかなと思ってます。

寺本昌弘寺本

うーん、なるほど。ありがとうございます。

AIの発展とプログラマの仕事の領域


寺本昌弘寺本

最後にですね、ちょっとこれ、私が個人的にまつもとさんに前から伺いたいなと思ってたんですが、現在、プログラマは当然ながらプログラムを書いていますと、こういう世界です。
一方で今、そのアルファ碁(AlphaGo)のようなAIがすごく発展・進歩していますよね。機械学習の世界というのは、その、もちろんコード上で動いてはいるものの、そこの論理的な回路は、プログラマがそのコードで書く領域でない、そこは、ブラックボックス化されるような、コードで明示的に書くようなものでないところの領域が、要するにAI、機械学習が、プログラマの仕事の領域を置き換えていくところがどんどん増えていくると思うんですが、その辺りについてはどう思われますか?

まつもとゆきひろMatz

近い将来については心配しなくてもいいんじゃないかなと思いますね。コンピュータに任せることができなかった仕事ができるようになるっていう以外のことについてはあまり考えなくていいんじゃないかと思いますね。
実際問題として、Ruby使ってる人がみんなRubyの中身を知ってるかっていうとそうではないですよね。
ガービッジコレクタがどう動いてるかっていうのは、一応ソースコードは見れるけど、誰も見ないので、ブラックボックスがある点ではあんまり変わらないですよね。
人工知能が、すごく強い碁の手を打つのと、ガービッジコレクタがなんかイイ感じでゴミを集めてくれるっていうのと、やってることは変わらなくて、自分の知らないところで行われてて、っていうのはあまり変わらないと思ってますね。
当分は、アルファ碁(AlphaGo)は、すごい強い碁だけど、彼が、例えば、僕は碁が好きだから碁をやろうと思ったわけではなくて、って…彼って何?(笑)

...

寺本昌弘寺本

(笑)

まつもとゆきひろMatz

アルファ碁(AlphaGo)っていう人工知能が思ったわけじゃなくて、プログラマが、じゃ、お前は碁をやるんだよ、碁っていうのはこういうルールで、これとこれの対局から学習するんだよって言って、碁を強いプログラムを作ったわけじゃないですか。
結局その自発的に選んだわけじゃないじゃないですか。本人はね。そういう弱い人工知能の間はそんなに心配しなくてもいいんじゃないかなと思います。

寺本昌弘寺本

なるほど。ちなみに、その時間的スパンはどのくらいの間隔ってお考えですか。

まつもとゆきひろMatz

あ、全然わかんない。
僕は内心は、強いAIは起きないんじゃないかと思ってるんだけど、この業界でできないって、大体できるので(笑)

寺本昌弘寺本

なるほど(笑)そういうことですね(笑)
わかりました。ありがとうございます。
本日は非常に、興味深い発言と示唆をいただきました。

まつもとゆきひろMatz

はい、なんか全然Rubyと関係ない話で終始しましたけど(笑)

寺本昌弘寺本

本日はどうもありがとうございました。

まつもとゆきひろMatz

ありがとうございました。

...

【後編】はここまで。
こちらも併せてご覧ください。