――技術に合わせて自分が変わるのではなく、自分に合わせて技術を変えるのです

私の職場にもいますが、新しい技術が流行り出すと「これからはこの技術がくるから、早く乗り換えよう」と言い出す人が必ずいます。そして、半年とか場合によっては数年もかかる壮大な移設計画を持ち出して、それにチーム全体を駆り出そうとします。しかも、その間のサービスに関わる重要なアップデートは、移設の妨げになるという理由で拒否しようとします

そういう人は、そうやって虫の息になりながら導入した技術も、せいぜい1,2年したら「この技術はオワコンだから」といって、また別の技術に乗り換えようとするか、それが叶わないと分かると、さっさと転職していってしまいます

そもそも導入に(半年ならまだしも)数年もかかるという時点で、それはその技術の欠陥です。そして欠陥があるなら、それは私たちの力で取り除かねばなりません。つまり、私たちにとって導入しやすく、使いやすい技術を、自らの手で作るしかないのです

流行りの技術というのは、例えばGoogleのような、一つの組織(あるいは個人)の中で上がった課題を解決する目的で作り始められます。それが発展する過程で、少しずつ多くのユースケースに対応できるように汎用化されていき、ある時点で広く世に公開されます。

ここでよく考えていただきたいのは「あなたはGoogleと同じ課題に直面するほど、恵まれた環境で仕事をしていますか?」ということ。大抵そうではありません。解決したい課題に合わない技術を導入しても、何の効果も得られません。流行りの技術から考え方や整った実装を学ぶことは大事ですが、結局、最も重要なことは、他人ではなく自分の目の前にある課題に対して、最適な解決を提供することです

流行りの技術が、自分たちの課題にうまく合わないということはよくあります。そんなときは、俗世間的な常識や先入観を捨てて、自ら考え、手を動かして「技術を作る」ということが必要なのではないでしょうか?

――目標って何?

新卒の頃は目標設定って何書けばいいの? と良く分かっておらず、毎回ポエムをテキトーに書いて提出していたのですが、最近その答えが自分なりにまとまってきたので、書いていきます

そもそも目標とは何か? これを理解するには、組織とは何か? をまず理解しなければなりません。組織に所属して仕事をする以上、その組織が健全な事業を行い、社会に貢献し、事業を継続してもらわなければなりません。そして、組織が社会に貢献した結果として、事業を継続する元手となる利益を得ることができます

この利益をいくら上げないと事業が継続できないから、これだけ利益を上げることを目標にしましょう、というのが組織全体の目標になります

では、その組織に所属する個人の目標はというと、組織の目標から逆算して立てる必要があります。極端に言うと、組織の目標とする利益の額を社員で割った額が、あなたの生み出すべき(目標とすべき)利益の額になります

ところが、この個人の利益というのは、実は計測不可能です。組織全体の営業利益は決算報告書で確認できますが、その利益のうち自分は何%に貢献しているか? これを算出することはできません。本来であれば、組織の中で働く一人ひとりが一事業者であり、他の個人と価値交換をしているはずなのですが、組織内部のやりとりでAさんの仕事をいくらで仕入れて、Bさんに売る、みたいな勘定をしている人はいませんね

ですが、この個人が創出した利益(仕事の価値といってもいいかもしれません)を近似的に示すKPIを作ることはできます。たとえば営業であれば、自分の顧客からの売上額で近似できるし、開発エンジニアであれば、自分の開発した機能を使った顧客の売上額とか、営業から個別対応の依頼をされたら、その案件で上がった利益の50%は営業ではなく自分の上げた利益としてカウントしておくとか、工夫できますね

直接、顧客に関わらない役割であれば、社内の何人の人からの仕事を解決したか、自分の深く関わった人がいくらの利益を上げたか、などで間接的に自分が上げた利益に近い数値を算出することができます

そういった組織内部の見えない価値交換を、自分なりに洞察してみて自分は「社内の誰々さんに、こういう価値を提供する」という感じに目標を立てると、単なるポエムに終わらない目標設定ができます。自分の中から出てくるものというよりは、自分の外、つまり他者から求められる価値にどう応えるか、ここに目標設定のポイントがあります

――個人開発における技術戦略を考察してみました

大学在学中から、ずっと空き時間を利用して個人開発をしてきて、最近ようやく自分の求めるスピード感で開発ができるようになってきた(気がする)。その経験から、個人開発において採用すべき(と私が考える)技術戦略について書いてみようと思います

結論から言うと、個人開発においては(チーム開発は知らん)、フルスクラッチが一番です。それはなぜでしょうか?

1. フレームワークやライブラリは、バージョン管理に時間がかかる割に、その作業は一銭にもなりません。特に個人開発の場合、売上額の少ないプロダクトを何個も積み上げて利益を確保することが多いので、よりバージョン管理のコストは増大する傾向があります

オープンソースで公開されているコードというのは、世界中のあらゆるユーザのユースケースを想定して、バージョンが上がる毎に、内部実装は抽象化され、オプションパラメータが増大し(デフォルト値もしばしば変更され、挙動が変わる)、複雑化します。その一つひとつの変更に対応するには、膨大な時間と労力がかかります

2. フルスクラッチのコードであれば、一度書いてしまえば、変更しない限り安定して動き続けてくれる上に、自分に取って必要ない機能は実装する必要がないこともあり、コストパフォーマンスが良いです。副業で開発をしている場合などは、そもそも開発に使える時間が限られているので、利益にほとんど影響しないリファクタリングなどの作業は、可能な限りやりたくないことでしょう

3. 個人開発では、人と仕様や設計情報の共有、すり合わせをする必要ないので、独自性の強いコードを書いてもコミュニケーションコストがかからないというのも、フルスクラッチの採用を後押しする理由となるでしょう

以上のように、徹底的にメンテナンスコスト(ランニングコスト)をおさえることで、売上が軽微でも利益を確保できるというのが個人開発においては重要です。実際このブログもフロントエンドもサーバサイドともHTML,CSS,JavaScript(Node.js含む)のみで開発されています

そうはいっても、ReactとかVue、あるいはFlutter、TypeScriptなどなどを自作するかというと、それは現実的ではないですけどね(ちなみに私は、偉そうなことを言っておきながら、個人開発で利益が出たことは一度もありません)

――The first post

最近、仕事をしていると、今の職場のことや日本のITエンジニア市場のこと、IT業界のことを思って感傷的になることが多く、そのときの出来事や感情、それについて本を読んだり調べたりした情報や、私の個人的な意見などを書いていくことにしました

エンジニアに限った話ではないとは思うのですが「こうあるべき」とか「こうしなければならない」という盲目的な正義感を持った方から「お前はここが駄目だから、こう直せ」といった類のことをよく言われ、そのたびに腹が立っています

「便利なサービスがあるのに、車輪の再発明はするな」とか「モダンな技術を取り入れないなんて、こんなレガシーな技術を使いつづけるなんてありえない」とか......皆さんも一度は聞いたことがあるのではないでしょうか?

ここで、もう一つ深く掘り下げて考えたいと思います。「その便利なソフトウェアやサービスは、どうやって作られたでしょうか?」「どれもはじめは、うまくいく確証のない中で、常識とは違った方向に突き進んだ人たちによって作られたのではないでしょうか?」

さらに問いたいと思います。「その便利なソフトウェアやサービスを作った人は、開発の際に、あなたと同じ問題意識を持っていたでしょうか」「あなたの解決したいことと、開発者の解決したいことは同じでしょうか?」

どこにどう問題を感じるかは人それぞれ。だからこそ他人と違う解決方法を思いつく人がいて、違うからこそ既存のものより良くなる可能性があるわけです。そういったものの中から次のイノベーションが生まれるのではないでしょうか?

Appleの製品は、ノートPCでもスマートフォンでも、競合製品より高価なのに売れます。それは他とは明確に異なる独自のデザインによって、一種の独占的な市場を形成しているからでしょう

人まねをするだけなら、ちょっと勉強できれば誰にでもできます。しかし、そのやり方の先に待っているのは、自分と似たり寄ったりな量産型の人材との骨身を削るような厳しい競争市場です

しかも、そういうことを言う人に限って「使っている技術の制約上、その機能は実現できません(導入した自分は悪くない)」と、簡単に顧客からの要望を突っぱねてしまいます。そのシステムで問題が起こっても「技術がいけてない(技術選定した自分は悪くない)」と何の反省も改善もありません

技術の子守をするためにエンジニアをしているのでしょうか? 少なくとも私は違います。顧客のためにエンジニアをしています。だからといって顧客の要望を鵜呑みにしろというわけではありません。顧客自身も気づいていない要望に気づかせてあげる(その結果、自分たちも楽になる)、そういう提案も必要です。ですが足枷になるような技術ならモダンもレガシーも関係なく使うべきではないのでは? 既存の車輪が使えないなら、自分たちにとって使いやすい車輪を再発明すべきでは? と思うのは極端すぎるでしょうか

流行の技術に使われるだけの量産型のエンジニアに、私は絶対なりたくない。私が技術を使うのであって、技術に使われるのではありません(※私は別にApple製品は好きではありません)

――This is a test post.

This is

a Test

Page.