こんにちは、情報システム部エンジニアの大河原です！
弊社技術顧問：まつもとゆきひろ氏との勉強会（通称：Matz会）について、11月度、12月度と記事を書いてきました。
今回は1月度のMatz会についてレポートします。年明け一発目、1/9の開催です。
新年のあいさつと新メンバー2名の紹介を行ったあと、いつものように「メンバーがLTを行い、それに対してコメントをいただく」という形式で進めました。
今回のテーマはこちらです。
- Ruby歴1年の僕が逃げに逃げ続けたProc/lambdaに立ち向かう話
- システムエンジニアに求められてるスキル
詳しいレポートは「続きを読む」より。
Ruby歴1年の僕が逃げに逃げ続けたProc/lambdaに立ち向かう話
優秀なインターン生から最近業務委託に変わったばかりのメンバーが、初LTをしてくれました。
人生初の技術LTをRubyのパパにぶつけられる人もなかなかいないのではないでしょうか笑
最初にProc/lambdaが難しいと感じた理由は、「目線が行ったり来たりするから」。
つまり、処理を定義している場所と実行される場所が離れており、かつ、名前が付けられない（Procインスタンスを変数に入れたとしても、yieldの近くに名前がない）からです。
結局、Proc/lambdaを理解しなくてはならない状況になって、行ったことは3つ。
- ブロックとProcの違いを理解する
- ブロックは単体では存在できないが、Proc.newでオブジェクト化ができる
- Proc.newとlambdaの違いを理解する
- 引数の数が定義と異なる場合に、Proc.newではnilを補完/無視されるが、lambdaはエラーになる
- returnすると、Proc.newでは呼び出し元メソッド自体から抜けるが、lambdaは呼び出し元メソッドに戻る
- 目線の移し方に慣れる
です。
なぜ書き方が複数ある？
Proc/lambdaについては表現方法が複数あることも混乱のもとだったのですが、まつもとさんによると「複数あるのは歴史的経緯」とのこと。
Proc.newはもともと引数としてブロックを定義できなかったため、Procインスタンスを渡していた時代の名残なので、今は使う理由がないそうです。
lambdaについても、今は-> {}（矢印ラムダ）だけ使えば良い、とのこと。
Proc/lambdaの使いどころ
続けて、「Proc/lambdaの使いどころ」についても回答いただきました。
基本は「他言語のコールバックや高階関数をイメージするとわかりやすい」とのアドバイスでした。
また、両者の微妙な違いは「ループとして使いたいときと関数として使いたいときとで欲しい振る舞いが異なる」ため、使い分けを意図して設計したものだそうです。
ループでは、
- 引数が欲しいときと欲しくないときを使い分けたい
- ループの途中でreturnする場合はループを内包しているメソッドごと抜けたいケースが大半
一方、小さい関数として使いたいときは、
- 引数の過不足があれば正しく動かないケースが多いのでエラーが欲しい
- 関数なので、returnする場合はその関数を抜けたい
このような意図で、前者にはブロック、後者にはlambdaを使うのを推奨しています。
システムエンジニアに求められてるスキル
CTOの孫が皆のキャリアの積み方について説いてくれました。
システムエンジニアはプログラマーではなく、
- コミュニケーション能力
- クライアントのニーズを抽出する能力
- 他の開発メンバーとの役割分担
- 課題解決能力
- 「どのように」実装するかではなく、「何を」実装するかを決める
コードを書けるのは当たり前として、上記のスキルも身につける必要がある。
現在ITエンジニアの雇用市場は加熱しているが、技術発展のスピードを考えるとコーディング不要の時代は遠くないのではないか。
少なくとも、ITエンジニアの求人数が大幅に減ることは十分にありうる。
上記のスキルがあれば暗い未来に直面することはないし、ましてや「35歳定年説」は関係ない。
このような発表でした。
システムエンジニアとは？
これに対し、まつもとさんは「おおよそ同意するが、システムエンジニアという単語が気になる」とコメントされました。
システムエンジニアというのは「設計と実装が分かれている組織で、設計に携わっている人を指すときによく使われる言葉」だと指摘されました。
そのような組織では設計と実装の担当者のあいだに何故かヒエラルキーがあることが多いのだが、それは「問題解決という本質を見失っている」とのこと。
ソフトウェアの振舞やデータ構造の設計も小さなバグの修正も問題解決には違いなくそれが会社としてのミッションのはずなので、権威に差があるのは本来おかしい、とおっしゃっていました。
また、「そのような、本質を見失った地に足のついていない開発は失敗する確率が高いため、『システムエンジニア』という単語を積極的に使っている会社からは危険な臭いを感じる」とも付け加えておられました。
プログラミングは必要なくなるか？
また、発表において「コーディング不要の時代は遠くない」とありましたが、これについては「今の延長線上で考えれば、その時代は来ないと思っている」とコメントされていました。
自動プログラミングというのはマジックワードで、プログラムが勝手にプログラミングを行う、という夢は50年以上期待外れのまま終わってきている。
まつもとさんの見解では、「実現するにはもう1段か2段のブレイクスルーが必要ではないか」とのことでした。
逆に、枠組みを素早く作る・書こうとしていることのサポートをする、という形での自動化はまだまだ進むだろうともおっしゃっていました。
つまり、Railsのように「煩雑な実装を簡単にできるようになる」だとか、多くのIDEのように「サジェスト機能の確度が上がる」などの方向、ということです。
おっしゃる通り、「1時間以内にプロトタイプが作れる」というのは昔からすれば自動でコードが書けているようなもの。
また、昨年のRubyKaigiの基調講演でAIについて言及する際にサジェスト機能には触れておられました。
Ruby自身も、その方向に発展させていく目算があるということなのでしょう。
まとめ
Ruby自身の機能の話と、今後の業界とキャリアについての話でした。
1人目の発表者がチームで最年少、2人目の発表者がCTOだということで、特に若手エンジニアにとっては実りある会となりました。
社外の駆け出しエンジニアの方にもぜひ届いて欲しい内容です。
Matz会レポートも3回目、遅れていましたが徐々に追いついてきました。2月分も書きますので乞うご期待。
We Are Hiring!!
リンカーズでは、上記レポートにある月例LT会の他、毎週月曜に前島真一（@netwillnet ）氏との読書会を行うなど、社内勉強会に力を入れています。
ビジネスマッチングに興味のある方、Railsエンジニアとしてキャリアアップしたい方、どなたでも以下のリンクからお問い合わせください。
今後も、更新を継続していく予定です。ご期待下さい！
