はじめに
技術を学ぶというのはすごい個人差のあることだと思います。
個人特性もあるし、興味の向く対象も違う。
組織にはいろんな人間がいる。
そんな中、いくら「技術力を学ぼう！」と啓蒙しても、
響かないことってありませんか。
最終的には人それぞれの問題にはなってくるのだけれど、
それって、現場ロックインが一因なのではないかなと思う。
現場ロックインの定義
「特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象」をベンダーロックインという。
(Wikipediaより引用)
現場ロックインは僕の思いついた単なる造語で、
「特定のプロジェクトに特化した技術や顧客の事情を重視しており、
その他の現場に移動しても殆ど役に立たないローカルルールに依存している現象」を指す。
会社に対しても同様のことが言えると思う。会社ロックイン的な。
ベンダーロックインは確かに汎用性が無くなるし、困るのだけど、
最終的にはそれしか知らない人ばかりがいるっていうのが一番困る。
ってことで現場にロックインしてる人が一番やばい気がする。
会社にロックインしてる人も。
なぜロックインするのか
考えられる理由をいくつか挙げてみる。
とりあえず、このフレームワークとORMはなんなく使えるし、このプロジェクトあと何年か続くし大丈夫だな。
技術はプログラマが学ぶものでチームマネジメント専門だ！という人
困ったらあの人に聞けば良いから勉強しないでいいや
出世することしか考えてないから、会社からうまいこと評価されれば良い、と。
他のところで使われているものを覚えるより、今使っているもの覚えたい。
感じるのは技術軽視とマネージメント偏重というところ。
更に言うと、技術とシステム開発に直接的な結びつきが無いと
考えている人さえいそうな気がする。
ロックインの問題点
問題点もざっと考えてみる。
さらなる改善を考えない、ということは絶対的に現状が正しいっていう危うさがあると思う。
無駄を無駄と気づかない。新しい情報がないから、こうやればもっと楽なのにを知らない。
ずっと洗濯板で洗濯するのかよ、みたいな。
これは推測だけど、ロックインされているものというもは情報共有が難しいので
引き継ぎもしにくいんじゃないかなとか。
出世=正しい。技術なんか無くて良かったのだ！みたいな結論。ありそうで怖い。
人間はどうやら自分にある情報から解決策を生み出すようなので、
単純にその情報量が少ないと解決策は少ない。
貧しい発想しか出にくいんじゃないかと思う。
もちろん、顧客折衝もスケジュール調整も予算管理も全て大事だし
それなしではシステムは成り立たないと思うけど
技術的な判断一つで工数もチームもガラッと変わると思う。
そうならないために
新しい情報を仕入れることは大事。
プログラマであっても、PMであってもGMであっても
CTOであっても。それぞれ何を学ぶかは同じではないけど。
more betterを考え続けるということが大事だと思う。
自分の使っているものを分からないまま使っている人も多い。
バイナリから理解しろとか極端なこと言ってるのではなくて、
何故動いてて、どういうところが良くて、どういう悪いか。とか。
普段のやり方、会話が他のプロジェクトでそのまますんなり受け入れられるか
それが1つの尺度になるのではと思う。
安易な決定をしない。コストとメリットを考える。
何を実現するか考える。
まとめ
思いつきでつらつらと、どういう事象があって問題点があって
それをどう解決するか考えてみました。
本当に思いつきの仮説程度に思っていただければ良いです。
僕が働く中でなんとなく感じている空気がそうかな～と思うので。
それを文章に出力してみたかっただけです。
一方で、新しい技術にかぶりつくのも危ないなあと思います。
「カッコイイ」とか「イケてる」とか「ダサい」とかその直感は大事だけど
それを理由にして選んではいけないというか。
ロックインする流れとか枠組みを是正することもひとつ、技術力を
上げるために必要じゃないかなぁとか思いました。
たまーに、自分はロックインされてるんじゃないかなって考えると
いつも焦るので、それがモチベーションになったりもするのですが笑
0 件のコメント:
コメントを投稿