Forkwell Press

エンジニアの生き様をウォッチするメディア

良いプログラマーは人生の成功者になれるはず!! Ruby開発者・まつもとゆきひろさんに聞く、プロダクト天国よもやま話

※ この記事は、リンカーズ株式会社 様の社内イベントレポートです。


脱同期処理で集中タイムを守る!

割り込まれやすいけど、割り込みに弱い。それが我々の仕事

Q: チャットは何を使っていますか?

A: ほとんど使っていないです

Slack のアカウントはあるんですけど、ほとんど使っていないです。

そもそも、リアルタイムコミュニケーションがあまり好きではありません。プログラマーなら分かると思うんですけど、あの貴重な集中タイム(ゾーン)に入った時に邪魔をされるとやる気が下がっちゃいますよね。チャットは返信も早いから無限に時間が吸い取られるというか…。

我々の仕事の場合は常に PC の前にいるので、割り込まれやすいのにも関わらず割り込みに弱いという(笑)。だから、「無視できる状況でしかリアルタイム通知は受けない」事にしています。

リアルタイムコミュニケーションは、開発者にとって良くないかも

チャットのやりとりは同期的な処理だったりしますし、その間は他の作業ができなくなってしまうので返信してほしいならメールとかがいいですね。私の場合は、まとめて見て、まとめて返す。という事をしています。 そして「見ない時は見ない!」。
そう考えると、開発者にとっては非同期処理的なコミュニケーションがいいですね。リクエストをプッシュしておくと、いつか返ってくるみたいな(笑)まあ、ふつうのチャットでも運用次第でそうできるでしょうけど。


脱ユーザー!?

Ruby とは何か? を決めるのが役割

Q: プロダクトオーナーとして、自分たちの理想が移り変わってしまったらどうしますか?

A: 移り変わったときにどうするか、を決めるのもプロダクトオーナーの責任です

私も、Ruby に対して日々いろいろな要求をいただいていますが、「他のものが間違っている!」とするのもポリシーですし、「自分たちのものを作り変える」のもポリシーです。その場合は、Rubyの定義を考えなければいけません。哲学・デザインポリシーという言い方もします、要は独り責任者ですね。

どこまで要求に応じて直したら Ruby で無くなってしまうのか? は曖昧な問題ですが、プロダクトオーナーである私にとっては、もっと曖昧だったりします。教科書に書いてるのが Ruby です! と言ってしまうのもいいですけどね(笑)。

Q: Ruby が特化している業界は?

A: 一番競争力があるのは Webアプリケーションです

要は、Ruby on Rails のようなものが実現しやすい柔軟性を持っていたと思います。Ruby on Rails を使えば、ゼロから Webアプリケーションを作る事をしなくていい。
例えば httpリクエストを解析して…等の面倒なところは全部任せて、ロジックなど自分の好きな部分だけに集中できる。そういった物事の難しいところを隠して簡単に書けるのが Ruby の良いところだと思います。

Q: mruby は Webサービスを使っている企業で使うとしたら、どのようなユースケースが考えられるでしょうか?

A: 一番多いのは ngx_mruby みたいな形です。

例えば、 mod_rewrite のような表側で見せているパスと、実際に裏側でクラウドのノードに渡すパスを変換しなくてはいけない時に、正規表現で書いたパターンマッチを並べていると時々辛くなったりします。そんな時は、ロジックを Ruby で書ける ngx_mruby とかはいいと思いますね。

また、GMOペパポさんは画像のサイズ変換をフロントで行っています。リクエストが画像変換だと思ったら、直接 ImageMagick のプラグインを叩いて画像を変換して送り返すみたいな。そういう形でオフロードしています。

あと、別の例としては Heroku があります。Herokuコマンドという、Ruby で書いてあるコマインドラインツールを提供していて、そのツールを使うには Ruby をインストールしないといけないんです。そうすると、その Ruby を動かすためにインタプリンタやらライブラリなど、大量のファイルをインストールする必要がある。

ですが、そこで mruby-cli というツールを使うとシングルバイナリにできて Dockerイメージも付いているので、 Docker のコマンドリクエストで Windows用、Mac用、Linux用のコンパイルまでできます。Ruby で書きながらシングルバイナリにできるので、そういう使い方をしている人たちもいますね。

みんなにある程度「NO」を言うのは大事

Q: クライアントごとにプロダクトに対する要望の差が少しずつある場合、どう対処しますか?

A: 基本的にはどちらにも泣いてもらいます

全てのお客様の要求を満たす事はそもそも無理ですし、必ずしも良い事ではないと思います。ソフトウェアとしては、個別のクライアントの要求に振り回されるよりも、想像を越えるすばらしいツールでクライアントを感動させるのが、あるべき姿ではないでしょうか。ヘンリー・フォードの「人々に尋ねたら(車ではなく)速い馬がほしいと言われるだろう」という言葉の通りですね。

例えば、何千人という顧客がついたときに一人一人のリクエストを現実的には答えられないでしょう。「私たちのやり方でソフトウェアを使えば、生産性があがりますよ」というものを作るのが理想です。
ただ日本の場合、ソフトウェアの開発はカスタマイズが中心なので難しいかもしれませんが、そこは本質にフォーカスさせるように、確固たる意志を持って欲しいですね。


色んなエンジニアがいるけど、私の要求は低い

人種も様々。それがエンジニア

Q: 新しい言語が出ると気になりますか?

A: 元々プログラミング言語好きなので、背景は知りたくなります

新しい言語が出たら、とりあえず仕様書は読むようにしています。特に背景部分は気になるのでその仕様について考えたりはしますね。なんでこのデザインにしたんだろう? とか、ちょっと変わった機能があるけどなんでだろう? とか。
あわよくば何か貰ってこようかなと思ったりもしますよ、それができた事はあまり無いですけど(笑)。

Q: 新しい言語を書いたりはしますか?

A: あまり書く事はないです

書いてみる事もありますけど、私は仕様書を読んだ時点でほぼ満足する事が多いんですよね。
仕様書は英語か日本語で書いてあるものを読むだけなので、簡単じゃないですか。でも直接書くとなると、セットアップをしてコンパイルする所まで持っていくのが時々大変だったりするんですよ。だからその手間を思うと、仕様書やサンプルプログラムを読んで満足してしまいます(笑)。

Q: プログラミングするモチベーションについてどう思いますか?

A: 色んなモチベーションがある。と思っています

多くのプログラマーの人はプログラムをしてみて楽しかった、とか、やりたい事ができた、とかそういった事からモチベーションを保っていると思います。例えば、私自身も BASIC のプログラムを正しく実装できただけでモチベーションになったりしました。「動いた、動いた」って(笑)。

ですが、最近社会人向けのプログラミング教室の話を聞いたのですが、脱落率がかなり高いと聞きました。仕事終わりの夜に学ぶ教室だと、最後まで通う人は約2割以下。「なんとなくプログラミングをしてみようかな」といった気持ちで始めても、モチベーションが保てなくて脱落してしまうんですよね。

でもこの教室はフルタイムでプログラムを教えているコースもあって、そこは朝から夕方までずっとやるんです。その分教える事も深い。フルタイムのコースに参加する人はみんな平日の昼間に通うために、だいたい仕事を辞めて来るそうです、プログラミング経験は無いけれど、これからスキルを手に入れて新しいキャリアを身につけたい、みたいな人たち。

面白いのは、このフルタイムの教室に通う人たちの脱落率は低いんですよ。背水の陣というか、決意の強さの差と言うか。8割から9割は最後まで通うそうです。
この人たちのモチベーションっていうのは、キャリアに対する希望とか、将来に対する希望とか、我々がプログラミングを始めたころとは違うモチベーションなんですよね。私はそれはそれで良いと思います。ちょっと人種は違うけど(笑)。違うモチベーションを持った人たちで一緒に開発をするのは良い事だと思います、多様性もありますし。

ただ気をつけないといけないのは、この人たちは元々プログラミングが好きでプログラムを始めた人たちではない、という事を頭の隅に置いておく必要がある。もちろんこれはスキルやモチベーションの高さとはまったく関係ないんですけど、違うモチベーションの人たちが仲間にいる、というのを理解する事は必要だと思います。

Q: まつもとさんにとっての理想のエンジニア評価制度は?

A: 何がいいのかはよくわからないし理想もあまりないけど

他と比べて、十分に高い給料が安定して貰えたらいいと思いますよ。あと、年功序列のようなものは好きじゃないので、パフォーマンスの良し悪しで評価が少しずつ上がったり下がったりすればいいかなと思います。

Q: 好きなエンジニアはどんなエンジニアですか?

A: 書いたコードが信用できるかどうかです

一緒にソフトウェア開発する前提からいうと、そこまでコミュニケーションは重視しないですね。書いたコードがある程度信用できるかどうかと、ちゃんと開発の事を議論できる人かどうかが大事です。そもそも話ができない人じゃつらいですね。割と要求は低いですけど、その要求を満たしてくれない人もいるので、それでいいかなと(笑)。


良いプログラマーは人生の成功者になれるはず!!

人生もプログラムも問題解決と思い込み

Q: プログラムを書いていて、充実している時とかめんどくさい時はいつ?

A: 常にめんどくさいです

「めんどくさい」は口癖なんで、いつも言っては奥さんがに嫌がられています((笑)でも、結局めんどくさい事をなんとかしたくてプログラムを書くわけですよね。Excel 見ながら電卓叩く、とかはやりたくないわけですよ。だから集計するプログラムを書くとか。めんどくさいと思う事そのものは、動機としては良いです。

ただ、問題解決するのもめんどくさいになっちゃうと意味ないですけど。めんどくさい事を、いかにコンピューターに押し付けるかが大事ですね。プログラミングを実行して想い通りに動いてくれた時は、「やったー!これで仕事しなくていい」という充実感が生まれます(笑)。

Q: いろんな書き方があるけどかっこいいコードの書き方ってある?

A: 最初から凝ったコードを書くと後で痛い目に遭います

ビューティフルコード』という本が出ていて、一部私が書いていたりもしますが美しいかどうかは結構主観なんですよね。極端な話だと自己満足なので、正直どうでもいいかもしれません。もし、良いソフトウェアの優先順位があるとすれば(自分ではなく、誰かの言葉なんですけど)。

  1. 動く

まずは、動く事がなによりも大事です。動かないソフトウェアは悪いソフトウェアですよね。

  1. メンテナンスできる

1回書いて終わる事は滅多にないので、書かれるだけでなく、読まれる。を意識しなければいけません。3ヶ月前の自分は他人、という言葉もある通り、他人が見ても分かるような明確なロジックで書くと良いですね。

  1. パフォーマンスが高い

処理が遅い原因は、大抵プログラム全体の1〜5%であるボトルネック部分でしか起こりません。そこは何としてでも高速化しないといけませんが、残りの場所はパフォーマンスをそこまで気にしなくてもいいので、だいぶ優先順位は低いですね。

Q: エンジニアに必要な能力やスキルは?

A: 問題解決能力です

自分の能力で役に立っているな、と思う事は、ソフトウェア工学の知見と問題解決能力です。
そもそも、コンピューターという手段を使って誰かの仕事を楽にしたり、生産性を高めたり、という課題を解決するのがプログラミングですよね。問題とその解決策をブレイクダウンする、という事を積み上げていくのがソフトウェア開発なんじゃないかなと思います。本当の問題は何か?とかこの解決方法はどうか?とか考える事をいとわないのが大事ですね。でもバグが出てしまう(笑)。

あと、だいたいの原因は思い込みですね。思い込みと戦う事もプログラミングにとって大事かもしれません。暗黙のうちに仮定している事があって、その仮定が真実ではない時。“必ず仕様に沿っている入力データ” だけが送られると思い込んでいたら、時々壊れたデータも送られてきたりとか、自分の思い込みが成立しなかったそんな時に、バグが起こりますよね。

よく考えたらこれはプログラムだけじゃなく、会社や家庭でも同じ事かもしれません。問題が起きて、それを解決しなければならないし、時々思い込みで失敗する。プログラミング能力を伸ばすには、人生をうまくやっていくのと同じ能力が必要なんじゃないでしょうか(笑)。
良いプログラマーは人生の成功者になれるはず!!

インタビュアーのコメント:ざっと見渡す限り、そんな事はないですよって思うんですけど)

本来はそうじゃないといけない。プログラマーたる者、そう自覚しなくてはならない(笑)。



コードは非公開でも、技術力はオープンに。
ITエンジニアのスキルを可視化する「Forkwell Portfolio」をお試しください。



リンカーズ株式会社についてはこちら
エンジニア目線で会社を選べるサイト Forkwell Jobs はこちら
エンジニアのキャリア相談・キャリアチェンジ支援は Forkwell Agent