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

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

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

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

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

（笑）

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

なるほど。

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

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

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

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

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

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

（手で膝を打って）はい！

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

「求められている気がする」、んじゃなくて、求めているんですよね？（笑）

そうですね、求めていますね（笑）

寺本さん求める側だから（笑）

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

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

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

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

はい。

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

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

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

なるほど。まぁ確かに。

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

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

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

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

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

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

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

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

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

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

うーん、なるほど。

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

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

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

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

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

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

なるほど。

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

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

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

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

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

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

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

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

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

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

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

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

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

（笑）

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

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

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

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

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

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

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