Forkwell Press

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

進化を続ける、色んなRuby!Ruby開発者・まつもとゆきひろさんに聞く、エンジニア気になリスト【一問一答】

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


あと少しで mruby がメインストリームになる(かも)

Q: mruby を始めた経緯と動機は何ですか?

A: 5年後に備えて今から頑張ろう、という発想でした。

mruby は、経済産業省の地域イノベーション創出研究開発事業として2010年に開発が始まり、2012年度にオープンソースで公開しています。
2010年の時点で、5年たったらマイクロコントローラー等の記憶容量や CPU パワーが十分高くなって、ソフトウェア開発をするのが大変になるだろうと予測していました。C とかアセンブラではなくて、もっと高級言語で開発したくなる需要が見込まれたので、そのときに備えて技術を提供できるように、今からがんばりましょう、という発想でしたね。

実際問題として、5年たって mruby がメインストリームになるほどマイクロコントローラーの性能とか記憶容量はそこまで上がらなかったので、万々歳ではないですが、そのうち予測通りになるかな、と思っています。
GMOペパボさんが HTTPサーバに組み込んでコントロールに使ったり、あるいはゲームに組み込んだりする例が出てきているので、思っていたのとは違うのですが、使われつつはあるのかな。と感じています。

Q: 既存の Android とか ITRON に不満はありますか?

A: そもそも OS と言語ではレイヤーが違うので、不満はありませんが…

mruby はあくまで言語なので、ITRON の上でも、Android の上でも動かせます。ですので、OS 上でプログラムの可能性を高める言語機能を組み込む事が目的です。
Webサーバーを設定する言語機能を、Apache や Nginx に組み込む。ゲームで言うとしたら、キャラクターの思考ルーチンや設定などの適切な箇所を、言語機能をゼロから開発せず Ruby で書くことによって、毎回全てをコンパイルせず済むようにして生産性を高める。このような事が主眼になります。

CRuby もあるじゃん、という話もありますが、CRuby はもともと Ruby でアプリケーションを書くためのバーチャルマシーンなので、他のアプリケーションに組み込むことがあまり想定されておらず、CRuby のルーチンから Ruby を扱う API が弱かったりします。
また、mruby は比較的メモリ消費量が低く、アプリケーションに与える影響が相対的に低い。アプリケーションに組み込むことにかけては mruby を使う方がずっと楽です。

Q: 次期の Ruby において、C# の LINQ(統合言語クエリ)のような機能を提供する予定はありますか?

A: 現時点ではないです。Rails の ActiveRecord でいいのでは? と思います。

私はあまり LINQ が好きではないですね(笑)なぜかと言うと、LINQ を使っている所だけ C# じゃないですよね?
似たような事をやっているのは、Ruby on Rails の ActiveRecord で、Ruby のコードで、SQL の様な問い合わせを書くという。 個人的には、そこだけ違う文法が現れる LINQ よりも、Ruby の文法のままで問い合わせを書く事ができる、ActiveRecord の方が好きです。

なので、現時点では言語仕様として追加する予定はないですね。ActiveRecord でいいじゃん、と思います。

Q: コーディングを通して慈善活動をしたいが何ができるか?

A: 今思いついたものでいうと、「教育」は結構いいんじゃないですかね?

これからプログラミング少年団のようなものが各地で開かれることが、政府の方針として出つつあるみたいで、プログラミングを教えてほしいというニーズは増えていくと思います。富裕層向けの児童プログラミング教室だけではなくて、野球少年団のような感じで、普通の児童も学べるような枠組みへの需要は高まっているみたいです。そういうことをやっているNPO等のお手伝いをする、とかですかね? 松江市では Rubyプログラミング少年団というのがだいぶ前からあって、公民館で教えたりしていますね。

あと、ものすごく広い意味でいうと、オープンソースソフトウェアに関わってみることは、人類の便利さの総和を若干増やすという意味でも慈善活動といえるかもしれませんね。

プレーンテキストで送り直せ!!

Q: ドキュメント管理はどうしていますか?

A: ほとんど GitHub Issue で管理しています

特に私の周りには Microsoft Office 商品撲滅運動のようなものがあって、Excel で送ると「プレーンテキストで送り直せ!」なんて事もあります(笑)。そうすると、GitHub は相性がいいですね。特別なフォーマットを使わないで、なるべくテキストで表現する。ドキュメントはマークダウンで書くとか。実際は GitHub でだいたい収まっています。ですから、特別なファイルサーバーを仕事で使うことは無いですね。

個人レベルでは Dropbox を使っています。いろいろなファイルをデバイスで共有するためには便利ですが、本音を言えば特定のフォーマットでやりとりするのを避けたいというのが正直なところです。他の人と Word や Excel のファイルをやりとりしないと話が出来ない事が、Dropbox を使う理由なので。

メインが Windows ではないので、よくある「会議の日程を添付のエクセルに書き込んでメール返信してください」というような時は、無視して「午前中は OK」とかプレーンテキストで返信します(笑)。

人間がプログラムを書いて、AIがテストしてくれたら最高

Q: テスト駆動開発(TDD)について、推進派か反対派かどちらですか?

A: 正直テストは書きたくないです

テストそのものはもちろん書いたほうがいいので書く事が多いですが、正直に言うとテストは書きたくないです。
なぜかというと、(TDD における)テストというのはそのプログラムがどのように動くかという事を記述するので、DRY(Don’t Repeat Yourself)じゃないんですよね。

テストの本質は、解くべき問題をコードの形と、答えを確認するための形の2種類の方法で書いて、同じ結果が出たら合っているに違いない。というアプローチですよね? でも、プログラマーの性として同じ事は2回も書きたくない。テストを書かされていると「もう書いたじゃん」ってなりますよね? 関心があるのはコードで、コードを書きたい。コードで問題解決をしたい。 テストは問題解決に寄与しないですよね?
ですから、テストファーストはあり得ない。仮に私が超天才で、書いたコードが全部正しく動くのであれば、テストはいらない。でも、残念ながら私は超天才ではなく間違いも犯すので、テストが必要になる。残念ながら人類はまだプログラムの正しさを検証する方法をテスト以外に持っていないので、仕方なくテストを書いている。というのが今の私の気持ちです。

将来的には AI が間違いを直してくれるのが理想ですね。プログラムを書く楽しさは人類から奪って欲しくないので、人間がプログラムを書いて、AI がテストしてくれたら最高ですね。


ウォーターフォール開発は、だいたい後悔

Q: アジャイル開発について思う良い点と悪い点を教えて下さい

A: あんまりアジャイルやったことないから多く答えられないけど

仕事としてはあまりアジャイル開発をした事はないので多く答えられませんが、ウォーターフォール開発はやったことがあって、だいたい後悔してきましたね。クライアントは要件定義書読まないですし(笑)でも、出来上がってきたら違うと言うし…。

そもそも事前に全部を決めることなんて出来ないですし…でもこれは人間の性であって、仕方ないと思います。いずれにせよ見積もりや計画は狂うものです。未来は分からないし変更は当たり前、という前提を織り込んだ開発スタイルが求められた結果のアジャイル開発でしょうから、そう考えるとアジャイル賛成派です。ただスクラムを組んでいる中で開発した経験は無いので、なんとも言えないですが。

ちなみに、XP (Extreme Programming) の中でペアプログラミングだけは苦手です。2回ぐらいやったのですが、もうあまりやりたくないなーと思うくらい疲れました。レビュアーだとすごくもどかしいですし、ドライバーだとレビュアー置いてけぼりな仕事をしちゃうしで、あまり上手くいきませんでした。効果が無いとは全然思っていませんので、合う/合わないがあると思いましたね。

ソフトウェア開発には、対立にフォーカスしたマネジメントを

Q: チーム開発のときに KPT のような管理手法で実際に取り入れてよかったものがあれば教えて下さい

A: あんまりチーム開発でマネジメントは経験がなくて…

オープンソースは勝手にやれって感じになりがちで、そんなにチーム開発とかはしてないですね。マネジメント系とかの経験もあまりなく、良いことも言えませんが、普通の人が思うマネジメントと違う形もありうるかもしれない、と考える機会は最近ありました。

そもそも、ソフトウェア開発ってものは対立構造になりやすいんですね。

  • 開発チーム(少ない人数で高いお金がほしい) VS クライアント(短い期間で安く済ませたい)
  • 営業 VS 開発
  • 設計 VS 実装

ありとあらゆる所に対立の火種がある。対立にフォーカスして、トラブルを自動的に小さくできるやり方。これが理想のマネジメントに近いのでは? と思います。

Q: 趣味でコードを書いていて徹夜したことは?

A: たくさんあります(笑)

最近は後に響くのでしないようにしています。遅くても25時ですね。

Q: 遅くまでプログラム書いてると脳が覚醒して寝れなくないですか?

A: それもありますね

それもありますが、逆に寝ようと思った時にバグの解決法を思いついたりもしますね。

3大バグが見つかるタイミングというのがありまして、

  1. 犬の散歩をしているとき
  2. お風呂に入っているとき
  3. 寝る前

の3つです。

情報の入力だけだと答えは出ないことが多いですが、リラックスして気持ちを切り替えた後に、発想が生まれたりします。

プログラム言語の進化で、生産性は向上していく

Q: 色々な言語がありますが、生産性は向上しているのか?

A: 全体的にいうと進化傾向です

言語はあまり消滅しないのでどんどん増えていますが、それぞれの言語が設計された時期によって強調される特徴や言語機能が変わっていくという意味で一種の流行はあります。
2010年代であれば静的型をもってる言語が流行りましたね。1990年代に作られた言語の JavaScript の進化版が、静的型をもってる TypeScript と言えるでしょう。

ただ何が正しいかは一方的には決まらないので、今のものが未来で流行っているかどうかは断定できませんし、昔流行った言語の人気がぶり返したりもします。全体的にいうと少し書いてたくさん仕事ができるように進化している傾向はあります。



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



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