mather's diary

なんか書いてみる

学習コスト論

JVM上のJavaでない言語を使いたい、と主張したところ、こんな返答が返ってきた。

「学習コストが高く、メンテナンスできる開発者が少なくなるようでは困る。これまで使っているJavaでやってくれ。」

これに対して、賛成・反対の立場から意見を書いてみたいと思う。

賛成の意見

「みんなが共通で使っている言語を使うべき」というのは、開発を進める上で理想的であるように思える。
また、Javaなら様々なリソース(本、Web、人的ノウハウ)に頼れるため、開発が進めやすいだろうと予測できる。

僕の主張に関しても、まだ発展中の言語であってリファレンスもそれほど多くなく、Javaの扱う概念より抽象度が上がり人によっては学習すること自体に時間がかかってしまうという可能性が否めないため、導入は難しいと考えるのは妥当であると思える。

反対の意見

学習コストに関していうと、「支払うべき学習コストを払わなかったから、維持管理コスト、運用コストが長期的に絶えない」のだと僕は思っている。
同じJavaでもバグの少ないプログラムというのは当然あるわけで、そうなるための一人ひとりの能力向上はどんな会社でもどんなエキスパートでも常に必要になる。
そうでなければ結局間に合わせで作ったバグの発見しにくいコードを長い間改修するはめになり、「後から機能追加したら自作ライブラリにバグがあったので迂回するコードを書いた」「それぞれがコードを書いて、混ざるのが嫌だから全部別のクラスにした」なんていう自分勝手なコードが生まれることになるんだろう。

メンテナンスできる開発者について、指摘の通り当初は僕一人とか居ても高々数人だと思う。
でも、必要に迫られたらやるでしょう。かつて僕がそうしてきたように。
その際に学習コストが〜なんてことを考えてたのかは甚だ疑問です。

また、言語レベルでプログラムの考え方が抽象化されてるため、

  • コードの量が少なくなる
  • 下手な一時変数などでバグを埋め込む確率が減る
  • クラスや関数に関する考え方がより柔軟になる
  • 処理の並列化が容易

などの大きなメリットがあります。

「いつも使っている」という落とし穴

「探せばすぐに同じようなサンプルコードが見つかる」というのも、実は良くないことだと思うのです。そのままコピーしたり、変数だけちょこっと増やしたりするばかりで、コードを書いた本人も本質的な解決はできていないことに気づかないままかも知れません。

やり方を真似るというのは人間の学習の基本であり、一番わかり易い教育手段です。
しかし、それは特別な問題に関して対処方法を知るだけであり応用が利かないため、解決すべき問題を自分の頭で解釈し分解し具体的な解決に導くまでの道程は自分自身で作って行かなければなりません。
人手ではなく人材として求められるのは、そのような単調な学習で得られるものを超えた柔軟性や困難を乗り越える発想力や新しいサービスに漕ぎ出せるような発展性であり、「やっていれば皆いつかはできる」というものではないはずです。

サンプルコードの読み方として「写経」と称されるものがあります。
同じコードを自分で書いてみて、動かしてみるのです。
その際重要なのはただ丸写しして動いたことに感動するのではなく、「解決しようとしている問題は何か」「何故このコードは動くのか」などを読み解くことや、「自分が書くときの発想も同じコードになっていくのか」「他のやり方はあるのか」「部分的に変更する場合、何が要点なのか」を書きながら試すことだと思います。
写経のように、一字一句自分の中に染み込ませていくのです。

個人的すぎる趣向として

正直なところ、僕はJava言語が余り好きではないし、元々RubyとかCとかFORTRANとかから入ってきた人間なので、オブジェクト指向にもなりきれていないような言語は中途半端すぎると思います。

もちろん、言語として学ぶことは大きく、利用頻度も認知度も世界的に高いことは認めた上で、「JavaJavaだけに頼る開発者を潰していく言語」なんじゃないかと思ったりするんです。

また、新しい言語の抽象度の高さ故、その概念理解に苦労するかもわかりませんが、それこそが「プログラム」に関する考え方を揺さぶり新しい発想を生み出すことになるため、逆にJavaなどの言語でも活かせる理解が得られると思います。

あと、Haskellとか傍目には制限が強く特殊な言語と思われがちですが、やってみると問題解決のロジックが引き締まったり、無駄な処理がわかるようになってきて良いと思います。オススメです。

まとめ

  • やったことがない言語を学習することは、今使っている言語のスキルアップにも役立ちます。
  • デリバリを優先させて、その前に必要なはずの学習コストを払わないなら、その代償は負う事になると思います。ご承知ください。
  • Javaオブジェクト指向ではありません。

プロフェッショナルとは?

先日「あなたにとってプロフェッショナルとは?」と聞かれて、こんなふうに答えてみました。

「責任感」と「可能性の追求」

自分らしいといえば自分らしいかもしれないけど、なんかこれだけでもないような…と言った後に考えていました。
とはいえアレもコレもと追加したところで支離滅裂だし、誤解をまねくことを承知で割り切ることは必要だと思います。

  • 責任感

行った仕事に対して対価となるものをいただく以上、中途半端に終わらせたり勝手に見切りをつけて逃げることは出来ません。
また、「指示があったからやりました」という逃げ口上は自分の仕事が何であるか考えていないということに他なりません。
もちろん初めからすべて納得ずくで始めることは不可能かと思いますが、それでもやると決める意志は自ら示すものです。

その代わり、「なにかがおかしい」「この仕事は必要なのか?」という疑問は、個人的にはきちんと発言するべきだと思います。
以前からのやり方に従うだけになっていたり、ただのルーチンワークに1日取られてしまうようなら、はっきり言って無駄だと認識しています。
「なぜこのやり方なのか」「この仕事は『なぜ必要なのか』『誰が行うべきか』『もっと簡単な代替案はないのか』」という言葉を反芻するようにしています。

  • 可能性の追求

ベンチャーという精神が個人的には好きなのですが、そもそもベンチャーとは何か。
新しい分野の開拓、ある事柄の見方を変えた新しい解決法を模索する、などなどいろいろあると思います。

では、ベンチャー企業と銘打ったあと、「ベンチャーでなくなる」とはどんなことなんでしょう。

僕の提案としては「積み上げたものを捨てる覚悟ができなくなったとき」かなと感じています。
いずれどんなものも時代の変化と共に消えて行き、その速度が分野によって加速している以上、全く同じ物や全く同じやり方では合わなくなるのは必然であり、常に変化と改善に向けた努力を強いられます。
ベンチャーであるということはその変化に一石を投じる挑戦を行うということであり、周りを巻き込んで変化を促すからこそベンチャーだろうと感じています。

しかし、社会が変化した後にその会社はどうなるのかというと、さらに変化を追求するのか、変化してゆく社会に適応していこうとするか、様々だとは思いますが、一時代の観念に根を張ることは正直難しいと思います。

私個人としての考えを述べると、変化を恐れてはいけないし、自ら変化し、周囲の考え方を変化させることを忘れてはいけないと思っています。
もちろん、手当たり次第に変化するのではなく、その意図や意味を理解する努力が必要になると思います。
これからも多くの方々と仕事を共にする以上変化することは必然ですが、その変化を意識的に受け止められるか、また、より良い変化に促すことができるかということは必ずもっと先のステップに繋がることだと思っています。

まだまだ若輩者ですが、こんな考えでプロフェッショナル足りえる仕事をしていきたいと思います。