学習コストが高いものほど学べ

芸術家に世界観があり、トレーダーに相場観があるように、エンジニアだって自分独自の感性を持ったって良いのではないかと思う。

日本のエンジニアはコーディングをするにも様々な規約を取り入れるのが大好きだ。そういう印象がある。
自分だって一貫性のある綺麗なコードは好きだし否定はしない。

フリーランスエンジニアだからといって複数人でコードを書く場にいるのなら協調性を持って自分勝手なスタイルでコードを書くのは避けた方が無難だ。

だが、やはりフリーランスのエンジニアとして、「この手法は得意だ」というオハコやスタイルくらいは持っていた方が良いし、それが大多数の人が用いる手法でないにもかかわらず有用なアプローチならなおさら武器になる。

そういったものは往々にして学習コストが高い。
有用なのに皆が使おうとしない理由なんてそれくらいしかない。
特に初心者エンジニアも入り乱れたような開発チームでは、なおさら学習コストが高いものは歓迎されない。

例えば関数型プログラミング。
これが何かを語り出すとブロガーでもない自分は（エンジニアはIDEの補完や様々なサポートがあるおかげであまりタイピングしない）手が腱鞘炎になる程に長くなるのでここでは割愛するがこれは非常に良い例だ。

関数型プログラミングは、もう何年も前から注目され始めてはいたが、自分の周りで「ゴリゴリ関数型指向です」って人はまだいなかった。

そして大抵の人は、習得する前から、オブジェクト指向と比較してデメリットばかりを述べるが、関数型には至って大きな欠点はない。

オブジェクト指向型言語でも、最近は関数型指向風味に記述できるようなのも増えてきている。だが、そういった言語では場合によっては、関数型指向で記述されたコードの実行パフォーマンスが落ちることがあるが、ゲームプログラミングなどで「0.16秒間隔で回してるループの中です」とかでなければ気にするほどでもない。
もとより【純粋関数型言語】として生まれたHaskellのような言語なら動作速度が落ちるも何も、関数型でしか記述出来ないようになっている。

だから「パフォーマンスが落ちる」が欠点になり得るかどうかはケースバイケース、言語バイ言語ではなかろうか。

それに、オブジェクト指向とは競合するものでも対極にあるものでもないので、自分にとっては比較の仕方がわからないのだ。

Cのような手続き型言語のみを覚えたばかりのエンジニア1年生にとって、オブジェクト指向を理解することは難しく感じるだろう。

しかし、周りのエンジニアが最低限の嗜みとして習得しているので、文句を言わず覚えるしかないのだろう。

自分からすれば関数型指向に関してもそうであって欲しいし、そうあるべきだと思う。エンジニアとして最低限嗜んで欲しいものの一つだ。

「有用で、学習コストが高いこと」ほど、無理をしてでも積極的に導入するべきである。
それが、チーム開発なら尚更。

なぜか。

チームの皆が同じ、「学習コストが高く有用な方法」を学んで一つのプロジェクトを遂行する場合、その手法は共通認識の部分になる。

学習コストが高いと言うことは、その技法に関しての学習量が多いと言うこと。
つまり、チーム間でそのプロジェクトのコーディングにおいても言わずもがな共通で理解し合える部分が多くなると言うこと。

その逆はと言うと、そのプロジェクトの開発に携わる上で特筆するべき事項や依存が多くて、膨大なドキュメントもあり、ずっとそのプロジェクトに関わっていた人が抜ければ保守も困難であり、新規で開発メンバーを迎えるにも、最初に非常に長い時間をかけて説明をする必要があるということ。

明確な根拠を示せと言われると困ってしまうので、次の説明に関してはそう思わないのならそれで構わないが、ものごとにはやむをえず発生する必要最低限の【複雑指数】のようなものがあると思う。

例えばプロジェクトAの複雑指数が300だったとする。
そのプロジェクトA特有の考え方や自社フレームワークが占める複雑指数が150だとすると、残り150は一般的なエンジニアリングの知識に由来するものとなる。

このプロジェクトAをとある学習コストが高いフレームワークBを用いて進めることにする。
プロジェクトAの性質は同じなので複雑指数は同じく300。
フレームワークBはプロジェクトAの土台としては少し拡張を加えれば、ほぼプロジェクトAの成果物としての要件を満たす。
フレームワークBの複雑指数が200、プロジェクトA特有の複雑指数が50、そして残り50は一般的なエンジニアリングの知識分とする。

後者の場合、フレームワークBを学習すれば、今後は他のプロジェクトでもその知見は再利用可能だし、都度プロジェクトのためだけに覚えることは圧倒的に少なくなる。

技術者が足りなくて調達する必要がある場合も、フレームワークBの知見がある人を探せば良い。

つまり、皆が汎用的に使える考え方や枠組みを時間をかけて学ぶことは、結果的にプロジェクト固有の独自性を小さくし、汎用不可能な知識やロジックが各プロジェクトから減ることに繋がる。

【複雑さ】を再利用可能なものに押し込める。
知識自体もSDKやフレームワーク同様に再利用可能なものであるのが望ましい。

ただ単に意味もなく複雑だったり学習コストが高いものなんてない。
重ねて言うようだが、学習コストが高いものは、再利用生の高い「複雑」の塊のようなものだ。
だから、「有用で、学習コストが高い」と思うものは背伸びしてでも使って欲しい。

ちなみに、何が有用かはプロジェクト（実現したいこと）によって異なるので、ややこしいだけのものは導入しないで欲しい。