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

LinkersのシステムはRuby。なのでアドバイザーはまつもとゆきひろ氏が就任

去る2017年4月20日（金）。
弊社Linkers技術顧問まつもとゆきひろ氏による、社内の技術者向けの講演会と、お酒も入った交流会が行われました。島根在住で多忙なまつもと氏ですが、今後Linkersでは毎月のスカイプによる打ち合わせのみではなく、実際に来社していただき今回のような技術者相談会や交流会を定期的かつ高頻度で開催する予定です。

まずはその先駆けとして「優秀なエンジニアは、スピードとコストと品質をどうやって共存させているのか」をテーマに講演をしていただきました。本記事では、講演後に行われた濃い内容の質疑応答とあわせて、講演の模様を徹底レポートしようと思います。

パート１：講演編

講演テーマ：
「優秀なエンジニアは、スピードとコストと品質をどうやって共存させているのか」

こう見えて会社員です。フリーランスではないです。

（拍手）

まずは簡単に経歴から。
私は島根に家族4人で住んでいる、Rubyの人です。もともと、鳥取県出身で田舎者なのであまり東京で働きたくないなと思っていたのですが、今から20年ほど前に知人が島根で起業する際に誘われ、これ幸いと、家族を説得して移住しました。

最初は普通にエンジニアとして働いていたのですが、だんだんとRubyの知名度も上がってきて、もうかれこれ10年くらいは受託の開発は行っておりません。今はオープンソースの活動をメインに行っています。よくフリーランスですか？と聞かれますが、私は会社員です！本業はサラリーマンですね。
しかも、株式会社ネットワーク応用通信研究所とHeroku（SalesForceの子会社）の2社の正社員という不思議な状況です。

「言語のデザイン」なんて、ほとんどの人はしようとは思わない

普通の人はプログラム言語を使って何を作るか？を考えると思いますが、私は高校生くらいの時から「どんなプログラム言語を作ろうか？」と思い続けてきました。その時は、まだ今のようにインターネットが普及している時代でもないので、その考えの自分がマイノリティだと知る機会もないまま、気づいたら「言語デザイナー」という者になっていました。「誰か普通じゃないって教えてくれよ」という感じですね（笑）

では、言語デザインの本質は何か？というと「言語をデザインする事とは、決断する事」と私は考えます。Rubyというプロダクトがどうあるべきかの意思決定をする「プロダクトマネージャー」である。というのが私の正体です。言い方を変えると、Rubyというプロダクトのオーナーである。
つまり、例え実際にコードを書いていなくとも、Rubyに対しての責任をとる立場であるという事でもあります。

責任者と言っても、クレームを受けるなど悪い事だけではなくて、Rubyの一貫性やRubyの哲学を守り、Rubyというコミュニティのコミュニティリーダーとして、方向性を示す。「希望」を提示する。技術者としての立場を守りながら、リーダーシップを発揮するという事でもあります。

スピードとコスト。そして生活の両立。むしろ人件費を「上げる」意識が経営者にも開発者にも必要

コストについて、私が考えてきたのは、一般的に言われる「コスト＝時間×人件費」という考え方が私は好きではないという事です。コスト削減を目標とした時に、「人件費(給料)」を下げるという事になりかねませんから。一人当たりの人件費は下げてはいけません。むしろ上げる意識が経営者にも開発者にも必要だと思います。

経営者は、より高い人件費を提示して、優秀な人材を確保する事で一人当たりの生産性を上げる方法を考えるべきですよね。逆に開発者は、より高い結果、技術を提示して、経営者を認めさせなければなりません。両者が「下げる(給料)」のではなく、「上げる(生産性)」事を考えなければ良い製品は作れないと思います。

品質について、最初にやらなければならないのは「最終的なプロダクトがどんなものであればよいか定義する」事です。一貫した基準を定義しておけば、メンバーが同じ方向をみる事ができ、制作過程で起きる様々な問題が回避されるからです。

例えば、受託開発の場合、発注側が開発側に希望要件だけ告げて、任せきりにしてしまうといったケースがあります。そうすると、同予算・同期限であれば、発注側はより多くの機能を盛り込む事を考え、逆に開発側はいかに仕事を減らすかを考える。これでは利益相反が起きてしまい、プロダクトが失敗してしまうかもしれません。
両者が一貫した基準を共有し、同じ方向をみていれば、こういった問題は回避できるはずです。また、無駄な駆け引きをする必要がなくなりますから、生産性が高まり、より良い品質の製品を作る事ができると思います。

生産性はほとんどの問題を解決する

生産性を高めると、だいたいほとんどの問題を解決できます。私もサラリーマン生活が27年くらいになりますが、そんなに真面目な方ではなかったのですが、幸い手が早かったので生産性が高く、ちゃんと結果も出していると、上司はあまり文句を言わない。すると、

• 発言権が上がる
• 自由度が上がる
• お金も上がる
• 使える時間も上がる
• できた時間で、家庭の問題も解決

と、生産性は人生のだいたいの悩みを解決できるんですね！全部じゃないですけど（笑）そのためには明確な基準を設ける必要があります。

「無駄に働きたくない」

人によっては、それを怠惰と言いますが、勤勉は毒ですから（笑）結果を出した上なら、怠惰でいいはずです。よく必死に働くと言いますが、

「必」ず「死」ぬ

ですからね。死ぬのはまずいですよね（笑）

そもそもソフトウェアエンジニアの仕事は、人間がやるべき事をPCに任せて仕事量を減らすというのがミッションなわけですから、自分は長時間労働でもよいと考えるのは間違いですよね。賢く働いて無駄を無くし、より生産性が高く、より効果的な仕事をするべきだと思います。

ちなみに、海外にも同じ問題意識があるらしく

Work smarter, not harder

などと言うようです。

みなさん是非、生産性を高めて、結果を出して、今よりもっと怠惰になってください！

（講演終わり）

ここまでで、前半戦の40分の熱い講演は終了。休憩中には、和やかに写真撮影が行われました。

パート2：質疑応答編

引き続いて、後半戦ではLinkersエンジニア陣と、まつもと氏の質疑応答が行われました。以下からは、その様子をQ&A方式でを書き起こします。 具体的なRubyの内容についてや、そうでない事も含めた諸々の質問のやりとりから、Linkersエンジニア陣のリアルと、まつもと氏の考えを感じとっていただければと思います。

Q: まつもとさんにとってのエンジニアの理想的なキャリアパスとは？

A: 「プロダクト」マネージャーというのもアリです

プログラマー＞エンジニアー＞チームリーダー＞マネージャーのような予算・人員・進捗を管理するいわゆる"プロジェクト"マネージャーと言われる様な立場を目指す事は、自分は望んでません。
課題解決や技術的実現の可能性など技術的判断から離れていない"プロダクト"マネージャー、もしくはプロジェクトオーナーになる事がより経験を積んだエンジニアのキャリアパスとして理想ではないでしょうか。
今後は、そういう管理業以外のキャリアパスの実現も、一般的になってくればうれしいなと思います。

Q: 仮に、プロダクトオーナーが死んだらどうしますか？

A: 死んだ事ないので、最善の方法はわからないですね（笑）

私もRubyのプロダクトオーナーですが、死んだ事ないもので…（笑）ただ、案外なんとかなるもんだと思っています。ある程度進んでいるプロジェクトは、誰かがいなくなっても自走してくれるものですから。

それで言うと、ありがちな話として、全ての人員を交換可能にしておくという危険な発想はありますね。標準化、文書化、マニュアル化など色々ありますが、個人的には、案外人員とうものは、実際はそんなに交換可能ではなく、人員を部品扱いすると、たいてい生産性は下がります。
私の世界観だと、生産性を下げるのは絶対悪なので、多少リスクがあっても、生産性を優先するべきと思います。

自分が優れたエンジニアであると認めてもらう

Q: プログラマーとしての市場価値を高めるにはどうしたらいいですか？

A: 自分の実力より少し上の立場に、自分を放り込んでみる

自分が優れたエンジニアであるという事を人に認めてもらいましょう。知名度はお金になりますので、ブログを書いて発信したりするのもいいですね。
あとは、立場が人を作ると私は思っているので、自分の実力より少し上の立場に自分を放り込んでみるといいです、私のようにあとから立場に見合った実力がついてきますよ。

Q: ワークライフバランスについて教えてください。

A: 平日の生産性を上げるべき

平日に技術的なネタも含めてキャッチアップして、土日は好きな事をやっています。
もし、好きでやっているのではない業務の事で土日も使っているのであれば、平日の生産性を上げて、土日は別の楽しみに使うのが一番いいと思います。

Q: １日何時間くらいパソコンの前にいますか？

A: 8～9時間くらいです

日によって違いますが、移動のない日は8～9時間くらいですね。たいした事はしてないですが（笑）コンパイルを待っている間にSNSを読んだり。仕事している時間は、本当は3時間くらいかもしれないですが（笑）

Q: 今も自分でもコードは書きますか？

A: 書きます

小さめのプロジェクトでは手を動かします。mrubyでは、リードプログラマーをやっています。

抽象化は武器。下のレイヤーを気にしない未来が理想

Q: Rubyの仕様でやっぱり入れない方が良かったっていうものありますか？

A: $変数と、多重代入です

$変数と、特に多重代入はいらなかったかもしれないです。当時も今も仕様がルーズな気がして、もう少し考えて作れば良かったなあと思っています。

Q: Rubyがコンパイル型言語じゃない理由は何でしょうか？

A: 理由は２つあります

一つは、単に面倒だからですね。

1. バイナリをコンパイル
2. 出来たバイナリを実行

の、コンパイル型の言語での２ステップが、早く結果が見たいプログラムの書き手としては嫌だな。と思ったのが理由です。

もう一つの理由は、CPUごとに最適化されたバイナリを吐くみたいな事が、私の興味の範囲外だったからです。むしろ、「どういう文法にするか？」、「ランタイムはどうするか？」といった方に集中したかったからです。
ちなみに、Rubyも内部的にはコンパイルはしているのですが、外からは、それを意識させない実装になっています。

Q: 「1.nonzero?」 の返り値わかりますか？(便利なメソッドがたくさんあるけど、言語の設計者はどれぐらい把握しているのだろう？)

A: わかります

把握しています。（※selfが返ります）イコールゼロの時 nil を返し、ゼロじゃない時は self を返します。
何でこういう仕様なのかというと、C言語のstrcmpのような事をやろうとしたが、Rubyでは、nilとfalseを除くすべてのものは真と評価される仕様なので、!による真偽値の反転なども出来ないので、苦肉の策としてこのようなものが生まれました。

Q: 「method_missing」のメリットって何でしょうか？

A: ありとあらゆるメソッドに反応するオブジェクトが作れます

ボイラープレートいうテクニックがあるのですが、「method_missing」をうまく使うと、ありとあらゆるメソッドに反応するオブジェクトが作れます。 使用例としては、HTMLのテンプレートになるようなオブジェクトとかですね。 Smalltalkの、doesNotUnderstandというメソッドの仕様を真似て作りました。

Q: 開発用のフレームワークなどの進化にともない、OSI参照モデルの７階層を理解していないようなエンジニアが増えていますが、心配はありますか？（※意訳しました）

A: 心配はないです

いわゆる抽象化は、数学と共にプログラミングに必要な概念だと思います。対処すべき問題のみに集中するための有用な武器ですね。問題は、抽象化はコストがかかるという事と、どうしても下のレイヤーを触らないといけないケースが、たまに発生する事です。しかし、我々としては下のレイヤーを全く見なくてよくなるように上のレイヤーを改善するのが未来だと思っています。

使う人がハッピーになるかどうかが、アップデートの基準

※以下、弊社アドバイザー「パーフェクトRuby on Rails」の著者、前島真一氏による質問

Q: Rubyにコントリビュートしたい場合、どこから始めるのが良いと思いますか？

A: サブセットから手をつけるのも、一つの方法です

巨大なので難しいですよね。上のレイヤーから手をつけるのがいいと思います。あるいは、私も書いています、もっと小規模のサブセットであるmrubyから手をつけるのも一つの方法です。
GitHub(mruby/mruby)を眺めてもらって、バグ報告などいただけたら、とても喜しいですね（笑）。

Q: Rubyのソースコードを読む場合、どこから読み始めるのが良いでしょうか？

A: 暗黒面以外

パーザーとバーチャルマシンは、Rubyの暗黒面（笑）でめっちゃ複雑なので、そこ以外から見ていくのがいいと思います。

Q: Ruby3で入る予定のsoft typingによってもたらされる具体的なメリットが知りたいです。「コード実行前に型情報のエラーで引数の間違いに気付く可能性ができる」という事なのかと思うのですが合ってますでしょうか？

A: 合っています。

TypeScriptみたいになるのは避けたいと思っています。型を書き始めているうちに「じゃあこれRubyじゃなくていいじゃん」のようになりますからね。 100%じゃなくても、できるだけソースコードの意図を読み取ってくれるようなものがゴールだと思っています。

※前島真一氏による質問ここまで

Q: Ruby 3、Ruby 4はどういう感じになっていますか？

A: 「生産性を上げる」という事をテーマに改善していこうと思っています。

生産性の為に、プログラムの静的解析を導入して、より多くの間違いを見つけられる様にしたいと考えています。
また、DBに解析情報を保存して、IDなどで参照できるようにすれば、コードコンプリーションなどに使用できるのではないかと思います。
さらに、パフォーマンスの向上、メモリ使用量の削減、マルチコアの使用などを検討しています。

Q: 何に重きを置いてRubyをアップデートしていってますか？

A: 使っている人がハッピーになるかどうかです

Rubyはどちらかというと、読むよりも書くのが楽しい言語なのかな。と思っています。言語というのは情緒的なものが好まれますので、自分にとっての楽しさを考えてアップデート内容を選択します。 なので提案を受けても、振る舞いに対するメソッド名がピンとこないからパス！という場合もあります。

Q: Ruby開発のうえで大変な壁ってありましたか？

A: 「いいじゃんやめようよ」の壁

あたりまえですが、最初は誰もユーザーがいませんでした。なので、私が作るのをやめても誰も困る人がいない。Hello Worldを作るのだけでも、結局半年かかったのですが、その間ずっと「いいじゃんやめようよ」と思う心との戦いで、そのハードルを乗り越えるのが一番大変でしたね。

エンジニア天国の様な状況を継続

Q: まつもとさんの今後の目標を教えてください

A: 私をロールモデルとして、同じようにできる人を増やしていきたい

オープンソフトウェアだけでなく、全てのサービスに言える事ですが、シチュエーションが変わると状況に合わず、古いとか使えないとか言われてしまう。Rubyがそうならない様に、テクノロジーやトレンドの変化に対応していきたいですね。
また、「家族を養いつつ、自分の好きな事をする」、このエンジニア天国の様な状況を継続しながら、私をロールモデルとして、同じようにできる人を増やしていきたいと思っています。

Forkwell Press 編集部

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