闇雲な「JavaじゃなくてKotlinやりたい！」という気持ちが消えた理由
前置き
先日このようなツイートをしたのですが、予想以上の反響を頂いて驚きました。
知的好奇心・エンジニアとしての漠然とした成長の観点から、「JavaよりKotlinやりたい」と思っていたが、現在自分たちが抱えているプロダクトの課題を俯瞰すると、「重大な課題は、プログラミング言語を変えて解決するものではない」という結論に至った。
— つくし 𝕄𝕚𝕤𝕒𝕜𝕚 𝕄𝕒𝕜𝕚𝕟𝕠 (@T5uku5hi) 2018年9月12日
ツイートを読み返し、「この書きぶりだと様々な文脈を憶測できてしまうな」と思い、140字では書ききれなかった文脈の部分を本記事で書き起こすことにしました。
結論
知的好奇心・エンジニアとしての漠然とした成長の観点から、「プロダクトの言語をJavaからKotlinに変更したい」と思っていましたが、
- 「事実・課題・解決策」に対する認知能力の向上
- 言語仕様をトレードオフで考えること
により、「現在自分たちが抱えているプロダクトの重大な課題は、プログラミング言語を変えて解決するものではない」という結論に至りました。
さらに、Javaの素敵な所を自分なりに理解できたので、闇雲な「JavaからKotlinに変更したい」という気持ちが払拭され、漠然とした成長に対する不安を解消することができました。
この記事のゴール
記事を読んでいる方が、
- 「事実・課題・解決策」の違いがわかるようになる
- 漠然とした成長に対する悩みが解消される
という状態になること(なって頂けたら嬉しいなという気持ちです)
「Java = イケてない」の風潮がとても辛かった
私は、
- コンピュータ・サイエンスのバックグラウンド無し
- Javaについては入門書をやった程度
という状態でエンジニアとして就職しました。
いざ研修も終わり、業務でJavaを書いていると、他の言語を使っている人たち(会社内外問わず)から、
と言われて、正直とても嫌な気持ちになりました。
未経験エンジニアとしてのコンプレックスのようなものも相まって反論できず、「そうなんだ...Javaってイケてないんだ...」と感じ、上記の発言を真に受けちゃったんですね。今思うと、「事実確認なしに真に受けていた」だけなのですが。
漠然とエンジニアとしての成長に不安を抱えるようになりました。
だから、事業部で言語選定の機会が与えられたときに「JavaじゃなくてKotlinやりたい！」と強く思いました。
大きな転機１：スクラム開発導入
そんな私にとって大きな転機となったのが、スクラム開発導入です。
スクラム開発自体が大きな転機になったというよりも、「スクラム開発の一つ一つのセレモニーを効率的に進めるにはどうすれば良いのか？」を考えたことが転機になりました。
私達の事業部では8月からスクラム開発を本格導入したのですが、全体で物事を決める際にとてつもなく時間がかかりました。実績としては、
- 2時間で終えるはずの話し合いに丸2日かかった
- 話し合いたいトピックが8つあったのに1つしか話せなかった
が挙げられます。
この状況を打破するべく、まずは現状把握ということで、記録を取ることを始めてみました。議事録と呼ぶには貧相な、「時間と話されている内容と個人的な感想」を簡潔にまとめたメモを徹底的に書きなぐってみたところ、あることに気づきました。
議論がまとまらなくなってくるのは、
- 課題がないのに解決策を言っている
- 事実がないのに課題を言っている
- 事実を課題として言っている
ときでした。どういうことか具体的に見ていきましょう。
1. 課題がないのに解決策を言っている
例: JavaではなくKotlinを導入する
=> 聞き手は、「導入することでどんな課題が解決されるのだろう？なんで導入したいんだろう？」と感じる
2. 事実がないのに課題を言っている
例: JavaではKotlinよりコード量が多くなるため、実装に時間がかかる
=> 聞き手は、「本当にそうなのかな？LombokやIDEの予測変換があるから時間がかかると思わないんだけど。Kotlinの哲学である「簡潔」を言い換えただけなのでは？具体的事実が知りたい。」と感じる
3. 事実を課題として言っている
=> 聞き手は、「ぬるぽが起きたときにどう困るんだろう？」と感じる
...いかがでしょうか。
要するに、聞き手の頭の中に疑問がたくさん浮かぶと、確認したいことが増えちゃうので、本質的な議論の前準備に時間がかかるんですね。
中には「よくよく考えてみたら、課題なんてなかった」となり、議論するものがなくなるケースも。時間をかけたのに悲しいことです。
ちなみに上記の具体例は、脳内会議をしている中で出たものです。
脳内会議の末、「JavaじゃなくてKotlinやりたい！」という闇雲な思いから、
- 本当にKotlinにしたいなら、どんな課題感を持っているのか言語化しよう
- 汎用的課題を言うのではなく、自分たちのプロダクトで実際に起きている課題を言おう
という思いに変化しました。
特に、「汎用的課題」の存在に気づけたのが個人的に大きな成長でした。
汎用的、というのは勝手に名付けてしまったのですが、「世間一般的に言われている」という意味です。
汎用的課題に対する解決策を考えても、プロダクトの真の課題は解決できない可能性があります。
"オリジナル"課題を見つける能力を培っていきたいものです。
大きな転機２：HTMLパーサーの仕組みを知った
もう一つ大きな転機となったのが、HTMLパーサーの仕組みをこちらの記事で知ったことでした。
HTML がより「寛大」な姿勢をとっていることです。追加した特定のタグをうっかり削除したり、開始タグや終了タグを忘れたりしても許容されることがあります。XML の厳密で要求の多い構文とは反対に、全体的に HTML は「緩やかな」構文です。
これはわずかな違いのようでも、話は大きく変わってきます。HTML が広く普及した主な理由はこの寛容性にありますが（誤りが見逃されるため、ウェブ制作者にとっては楽になります）...
HTMLが広く普及した主な理由はこの寛容性にあります
この一行を読むや否や、Javaは寛容な言語なんだ！ と閃き、これまで学んできたJavaの言語仕様が雪崩のごとく脳内に押し寄せてきました。点と点が繋がったような、今までモヤモヤしていたことが晴れたような感覚でした。
特にお伝えしたい寛容ポイントは、null許容です。
null許容
前提として、null許容は言語設計者本人が 10億ドル規模の損失をもたらす過ち と言うくらいですから、私自身も「null許容は様々な問題を引き起こしてしまうので、nullが許されない世界でコードを書きたい」と思っています。しかしながら、
null許容 = プログラマが雑なポインタの使い方をしていても許してくれる
という視点に立ってみたところ、Javaを最初学んだとき、ポインタのことで一切悩まなかったことを思い出しました。余談ですがC言語へ入門を試みたとき、ポインタで諦めてしまいました(今は大丈夫ですｗ)
Javaは内部でポインタ(is-aポインタ)を使っていますが、プログラマは基本的に意識する必要がありません。私の場合は業務でコードを書いた際、クラスを作って、インスタンスを作って...様々なクラスがインタラクションを始めたとき、「ぬるぽで落ちた！ああ、nullの時を考慮し忘れてた！」となり、ポインタを意識するようになりました。
これって、「最初は本質的にやりたいことに集中して、そのあとポインタで悩むことができた」と捉えることもできるのかなと。
そういった意味で、やりたいことの前にポインタで悩む必要がないのは、null許容の良い側面かなと私は感じました。
null許容の他にも、String定数プールやガベージコレクションなど、プログラマが本来ならば考慮しなければならないメモリの難しさを、Javaは巧妙に隠蔽しています。それに気がついて、「Javaってよく考えられた言語だな、素敵だな」と愛しさがこみ上げてきました。
ポインタ扱いに対する寛容さが、多くのプロダクトで使われる要因の１つになったのだと、私は信じています。
High-level ergonomics and low-level control are often at odds in programming language design.
(高レベルのエルゴノミクスと低レベルの制御はしばしばプログラミング言語の設計においてトレードオフの関係になる。)
プログラミング言語Rustの公式ドキュメントにある一文です。
どんな言語でも、その設計の裏側では人間工学と機械制御の天秤を巡った苦悩があるのだと思います。
言語設計者の意図を理解した上で、自分(チーム)にとって、自分が携わっているプロダクトにとっての良し悪しを考えられるようになりたいです。
総括
２つの大きな転機により、気がつけば闇雲な「JavaじゃなくてKotlinやりたい！」という思いが綺麗さっぱり消え、
- 自分が携わっているプロダクトの"オリジナル"課題は何かを特定できるようになりたい
- 言語の仕組み・設計者の意図を理解した上で言語選定できるようになりたい
そういう目標が芽吹きました。
漠然とした成長への不安が、言語化された意思表明に変わった瞬間です。
一歩一歩目標に向かって進んでいきたいと思います。
ここまで読んでくださり、どうもありがとうございました！