うだうだ記事を書く。あんまりブロガーさんのように、懇切丁寧に説明する意識はない。うざかったら途中で離脱推奨です。

とある理由で、本番のデータを修正することになった。休日だったので僕が対応したのだが、その部分のデータ修正の経験がなかったので、ソースコードから調べて依存関係を解決するSQLを書き、Slackを通じてコードレビューをお願いして、無事修正タスクは完了した。

所要時間は、作業開始から40分。

日常的にソースコードをいじっていて、データ構造を熟知しているメンバーなら、５分もかからないで終わる作業だろう。もしそうならば、８倍の速度差が生まれている。

その８倍の速度差が顧客満足度に影響をおよぼすのであれば、その人は、僕よりも8倍速で得られる顧客満足度の分だけ、仕事ができると評価ができる。

その人材がいれば5分、いなければ40分。この差はとても大きい。その差が大きいと思うのであれば、そういう人材には高い評価を与えなければならない。

これは○○という言語を知っていることや、☓☓というフレームワークを知っていることとは全然違う別軸の評価軸とも言える。

業務知識や、サービスへのコミットメントは、可視化しにくい。

「わかりやすい商品を出すための」メディアや、「わかりやすい評価指標を必要とする」転職市場などを中心とした、インターネットメディア上のエンジニアの評価は、今のところ、汎用的な技術知識を持っているか否か、関心があるや否かに偏りがちである。

特に、githubを通じて開発プロセスやWAF、開発技術が標準化されつつある昨今、ある種のコピペコードに近しい形でのライブラリ知識などが重用される。メディアはそのような技術の方がPVを稼ぐことができるし、流用性が高い情報は、みんな欲しがるので、そこに関心を持っているエンジニアがより有名になって、序列の源になっていく現状がある。

それが故に、「チームにとってハッピー、お客様にとってハッピー」な技術よりも「知らない誰か響く知識」の方が高く評価されがち。

そういう人が素敵なことを否定する意図はない。そうではなく、その序列に対してエンジニア自身が、そのための時間を費やせないことに苦悩しているという実情もある。

休日に勉強するというのは、大切なことだし、僕もついついそう言ってしまいがちが、全員が全員、それが趣味として好きなわけではない。

そもそも仕事という長期マラソンにとって必要なのは、毎日出社し、仕事に取り組むことが第一であり、それを長期的に継続するために必要なのが休養の時間である。逆に、その部分で無理されて、無理やり勉強したあげく睡眠不足になったり体調を壊して、会社に来れなくなる方がよっぽどよくない。やるなら楽しく、ワクワクした活動じゃないとダメだ。趣味なんだから。

Webの業界自体が勃興期からそんなに時間が経ってなくて、技術を触るのが好きな人が優位性を得る現状だからこそ、休日を趣味のように費やすという価値観が、この業界において望まれる反面、業務知識に富み、顧客を第一にできるコミットメントを持った人材が、評価されにくい上に、そこに自信が持てていない、というのがインターネット業界全体における損失を内包している。

（注釈：
X軸を汎用知識、Y軸を自社の業務知識とした場合、X軸特化が評価されやすいのがネットで、Y軸特化型を評価する言葉がない、ということを問題にしています。
それ故に、技術も好きじゃない、サービスにも興味がない、という４象限目は、この話からは無視してください。）

この両者は、共存するべきである。そりゃそうだよね。

ちゃんと自分たちのロジックを理解し、サービスに関心を寄せている人がいなければ、冒頭に書いたことが解決できないんだから。

ちょっと前に、伊藤直也さんがSoR , SoEに関する資料をアップされていた。ここで上げられている、SoEは、どちらかというと、趣味と実益が一致しているネット文化で、SoRが、どちらかというとSI方面で、僕が書いている後者の人材に近しいタイプとも言える。

しかし、それが故に、一言で言えば「めんどうくさい作業」「つまらない作業」と言われがちな、「お客様のハッピーを実現する仕事」がないがしろにされている価値観がある部分も、この業界において、どこか否めないかなと思うところは、正直言ってある。

サービスが落ち着いたら新しいことができなくなるので、素敵な言語をやってるところ、新しい技術にチャレンジしている会社に転職するのがギーキーなエンジニアのキャリアパス、、、、に見える。

これ自体は別にいいと思うのだ。その人の人生なのだから。

…思うのだが、問題は、メディアがそこを重視して乗ってしまっていることも含めて、「それ以外の人達が報われていないで悶々とする」という方の図式をどうにかしたい。

例えば、そのギークな人が辞めた後に、サービスを維持している人達は、どうなんだ、という話でもある。

（ちなみに、スター選手が作り上げた特殊コードをなくすことに時間を費やして苦労する、という話はよく聞く。それが良いことか悪いことかは知らない。どっちが正義なのかはケースバイケースだろう。でも、コミットしてる人材がいなくなったコードというのは、遅かれ早かれ死にゆくことになるので、そんなもんなのかもしれない。だったらオープンソースの方が良いよね、という理屈もあるので、生殺与奪をコミュニティと、その人の関心に依存するオープンソースに委ねるのはいい塩梅なのかもしれないね。）

これらについて、うまく整理したらいいのかなーと漠然と思いつづけている。

いずれにせよ、全てがバランスした会社が一番ステキなんだろうなと思うが、あんがい、そんなところってないですよ、というのが現実だと思っているので、理想論に走って満足はしたくない。

その上で、まだ完璧ではないが、一つの仮説として、

その人は、「誰と一緒に働いているのか？」という一つの仮説を考えてみた。

これはスコープ定義の話なので、少しビビッド過ぎる表現を書いてしまうので、怒られてしまうかもしれないが、

ギーク寄りの人材で、趣味に近しい形で、技術を追求し、外で情報を共有することでプレゼンスをあげるという行為は、実は会社は、一つの収入源であり、自分の技術の売り先だという仮説。

ほぼ個人事業主に近いので、転職も簡単にできる。誰と仕事をしているのか？というと、「ネット業界」「○○業界」などという「グローバルなコミュニティと仕事をしている」という価値観。

これは、今のエンジニア業界で憧れられている人材像だ。

24時間世界が動いているので、どちらかというと会社よりも、世界の動きが気になってしまう。人間のアテンションは一定なので、ものすごいエンジンがパワフルな人じゃなければ、会社の外ばかり見ている人もいるという話も聞くことがある。

それに対して、社内のサービス、顧客へのコミットを重視する人材は、「会社のメンバー全員と働いている」。それがエンジニアチームだけでなく、CSだったり、営業だったり、当然、お客さんを見て仕事をしている。だから、休日は仕事のことを忘れる時に、技術からも遠ざかることができる。技術は道具だからだ。

両方の属性を持った人材がスーパーマンだとして、どっちかに偏っている場合、マネジメントサイドとしては、どう言う人材を重視していくべきか？

当然、両方、重要なのだと思う。

両方バランス良くできる人材が一番スペシャルなのは、間違いない。しかし、半分は趣味みたいなところがあるので決して、業務を通じて育てることはできないし、あったとしても良い出会いの産物だという部分はあるだろう。

そもそも、そっちは人材市場では評価されているのでサービスコミット度をどのようにあげるか？に悩めばよいのだろう、問題はサービスコミット度の方が圧倒的に高い人材を、どのように評価し、かつ、どのような成長ラインに持っていけば、もっと、よりよい形に成長するのだろうか？というあたり。

（もっと簡単に言えば、どういう評価軸であれば、もっと給料が上がっていくのだろうか。何故かと言うと市場連動型の人事評価をする会社は少なくないから、市場価値があがることは重要なのだ。）

今のところ思っているのは、

会社コミット、サービスコミット型人材は、継続的改善であったり、継続的なイノベーション、つまり大企業が脈々とやっているような、長期的な進化戦略に重要な役割を示す。

何せ、冒頭に書いたとおり、自社の製品について熟知している必要がある。仮に目の前にあるコードがクソコードだったとしても、そのことにのみ悶々とし、改善もできずに転職しているエンジニアでは、この事で評価される状況にはなりえない。そのような状況で、転職するエンジニアが無条件に正になるのはよくない。（そんなことはないと思うけどね）

それに対して、汎用的な技術力重視人材は、世界の技術動向に併せて、未来への羅針盤になる。特に、非連続的な進化をもたらす事ができる。

継続的な進化がなければ、非連続的な進化はできないし、非連続的な成長も求めないと、継続的な進化が報われない。

その両方がバランス良く、切磋琢磨しあえる組織であると理想的に継続的な進化ができるかもしれない。

昔の製造業なら、事業部門と研究部門みたいな話なのかもしれない。製造業における研究部門は、日本においては成功しているのか否かはよくわからないが。

p.s. githubで日本在住と識別できるアカウントで、リポジトリに100以上のstar/watchがついてる人って、全体の2%しかいないので、すごい人に憧れるのはいいんだけど、残り98%を評価できないと、ホント、みんな自信もてないし、無駄が多いなーと思ってるわけです。

【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください