――自己紹介していく
アイコン(熊)
名前
Mjusui(読み方: えむ じゅすい)
生い立ち
1990年、都内で生まれる。子供時代は主に草むらで虫を捕って遊ぶ日々。小、中学校では成績は中の上くらい。運動もまあまあできる方だった。高校に入ってからは勉強せずに遊び呆けていた。この頃から東京事変が好き。
浪人時代(国公立文系志望だった)に図書館でマルセル・デュシャンの作品集を見て衝撃を受ける。一浪して本意ではない電子情報系の大学に入学するも、デュシャンの衝撃と受験に失敗した経験から、自分の将来について考え始める。大学の成績は平均点ぎりぎりだった。講義を抜け出して1人読書する時間が多かった。この時期から仏教に強く影響を受けはじめる。
卒業してデータセンターの会社に入社。インフラエンジニアとしてのキャリアをスタートする。プライベートではHTML,CSS,JavaScriptでWebサービスを作ることにハマる。上司との戦いに敗れ、アドテク業界に転職。引き続きインフラエンジニアをする。裁量労働になり、時間に余裕ができたことで、趣味のWebサービス作成を本格化する(起業を目指し始める)。並行して経済学、経営学、マーケティング、宗教、歴史、哲学と多岐に渡る書籍を乱読する。
GoogleやAmazonのような巨大資本がエンジニアのスキルを画一化し、創造性を奪っていくことに絶望し休職する。アドラー心理学、進化心理学に出会い、少し救われる。休職があけてから、巨大資本に対抗するべく社内の新規事業の立ち上げに協力するも、会社の方向性に疑問を持つ。巨大資本に支配されたクラウドはもうダメだと思い、オンプレで利用されるNW機器のメーカーに転職するも1年もたずに辞めてしまう。
現在はWeb系の会社でSREをやりながら、趣味でほそぼそと、自分の好きなものを、好きなやり方で作る日々を送っています。
興味・関心・趣味
昨今のITトレンドには、もうほとんど興味がないです(仕事では勉強するんだけども)。UbuntuとNode.jsとVivaldiブラウザが動く環境があれば十分。
もともと文系志望だったこともあり、人文・社会系の学問全般に興味があります
- 歴史: 特にヨーロッパの経済史と美学美術史。日本の宗教史と近代史もまあまあ
- 宗教: 仏教、天道思想と陽明学。ユダヤ教とキリスト教も少し
- 哲学: サルトル、実存主義
- 心理学: アドラー心理学、進化心理学、ギフテッド
- 経営学: エフェクチュエーション、ラグジュアリー戦略、組織行動論
- 経済学: オーストリア学派、行動経済学
- 人類学: 経済人類学
- 法学: 知的財産権、税に関すること
趣味は、特定のタイトルしかやらないけどゲーム。
- ポケモン本編。マイナーパでランクマ頑張る
- 世界樹の迷宮。新作を待ってる
過去に作ったもの
ポートフォリオ的なWebページがあるので、良かったら見てください。
Twitterで更新通知とかしていく
――機械が人を脅かすなら、そんなものは捨ててしまえ!
この記事は多くの人が「要件定義」というプロセスでおかす間違いを完全否定するものです
マーケティングの世界では常識ですが、顧客は「自分が本当に欲しいものが何か」分かっていません。スマートフォンが登場するより前から「スマホ欲しい」なんて言っている人いませんでした。スティーブ・ジョブスがiPhoneを世に紹介してはじめて「手のひらにおさまるサイズで、ソフトウェアキーボードが画面の状況に応じて出たり消えたりして画面を広く使える電話兼パソコン」が欲しかったのだと、自分の内に隠されていた欲望に気づくのです
SIの世界では、開発の初期段階に、要件を定義するためのヒアリングというものがあります。顧客にいくつか質問をして、その答えをもとに要件を決める工程です。しかし上述したとおり、顧客は自分が欲しいものを知らないので、顧客の回答にもとづいて定義された要件というのは大抵、間違っています。間違った要件にもとづいて開発されたものも、当然、間違った結果しか生まず、開発以前に顧客が期待していた効果も得られません
しかしソフトウェア開発に携わるほとんどのエンジニアは「要件といえば顧客に聞くもの」という勘違いをしています。これはSIerだけではなくWeb業界でさえ、その傾向が見られます。仕様決定に行き詰まるたびに、営業に質問しに行くプログラマーがなんと多いことでしょう!
顧客に質問してはいけません。エンジニアにできることは、顧客が欲しいと思ってくれそうな物を、想像して、いち早くプロトタイプを発表することです。それを見てはじめて顧客は、その良し悪しを教えてくれます
このことは、狩りにたとえると分かりやすいかもしれません。獲物を捕まえるために罠を仕掛けるとき「ここにこういう罠を仕掛けたら、踏んでくれますか」なんて、獲物にいちいち質問しませんね。獲物を捕りたければ、どう動くかを想像して、獲物が通りそうな道に罠を仕掛けるしかないのです
――獲物にことわってから罠を仕掛けるバカはいません
この記事は多くの人が「要件定義」というプロセスでおかす間違いを完全否定するものです
マーケティングの世界では常識ですが、顧客は「自分が本当に欲しいものが何か」分かっていません。スマートフォンが登場するより前から「スマホ欲しい」なんて言っている人いませんでした。スティーブ・ジョブスがiPhoneを世に紹介してはじめて「手のひらにおさまるサイズで、ソフトウェアキーボードが画面の状況に応じて出たり消えたりして画面を広く使える電話兼パソコン」が欲しかったのだと、自分の内に隠されていた欲望に気づくのです
SIの世界では、開発の初期段階に、要件を定義するためのヒアリングというものがあります。顧客にいくつか質問をして、その答えをもとに要件を決める工程です。しかし上述したとおり、顧客は自分が欲しいものを知らないので、顧客の回答にもとづいて定義された要件というのは大抵、間違っています。間違った要件にもとづいて開発されたものも、当然、間違った結果しか生まず、開発以前に顧客が期待していた効果も得られません
しかしソフトウェア開発に携わるほとんどのエンジニアは「要件といえば顧客に聞くもの」という勘違いをしています。これはSIerだけではなくWeb業界でさえ、その傾向が見られます。仕様決定に行き詰まるたびに、営業に質問しに行くプログラマーがなんと多いことでしょう!
顧客に質問してはいけません。エンジニアにできることは、顧客が欲しいと思ってくれそうな物を、想像して、いち早くプロトタイプを発表することです。それを見てはじめて顧客は、その良し悪しを教えてくれます
このことは、狩りにたとえると分かりやすいかもしれません。獲物を捕まえるために罠を仕掛けるとき「ここにこういう罠を仕掛けたら、踏んでくれますか」なんて、獲物にいちいち質問しませんね。獲物を捕りたければ、どう動くかを想像して、獲物が通りそうな道に罠を仕掛けるしかないのです
――できる人は自力で習得し、できない人は他人に要求します
できない人ほど、何でもかんでもドキュメントに残せ、情報共有しろと言う割に、結局は読まないか、読んでも分からないといって、すぐ人に聞くことになります。属人化を糾弾するくせに、他人の仕事に興味を持って、自分で憶えようともしません。人に聞くのは悪いことではありませんが「俺に分かるように書かれてないのが悪い」というようなことを平気で言う人がいます。それは、あなたに理解力が足りないだけではないでしょうか?
ドキュメントを書くにも、それなりに工数がかかります。場合によっては実作業よりもかかることもあります。たしかに100人のチームでドキュメントを書けば、99人が必要な情報にスムーズにアクセスできるようになり、価値があります。しかし、5人以下のチームでは、ドキュメントを書いてもせいぜい4人にしか情報共有できません。後から新しく95人がチームに参加する予定でもあるなら別ですが、チームの規模が小さいうちは、ドキュメントを残すことの効果はむしろ低いです。情報共有に工数をかけても割に合わないのです
そもそもIT業界において、ドキュメントというのは補助的な役割しかありません。ソフトウェアの動作は、最悪コードを読めば解読できるし、仕様もユーザの気持ち次第で明日には変わっていることが多いです。書かれた情報の有効期限は非常に短いので、プロダクトの変化に合わせて副次的な情報を更新していく作業は、非効率で二度手間と言わざるを得ません
世界中の人が利用するOSSであれば、公式のドキュメントは何千、何万といった人から読まれることになりますが、まだ開始したばかりの無名のプロジェクトでは、書いたドキュメントは読まれないばかりか、その情報はすぐに古くなり使えなくなります。そんな中でドキュメントを揃えることに異常に執着するような人は害悪になります。チームがその時、本当に取り組むべき課題を遅れさせ、プロジェクトを頓挫させてしまうからです
この情報共有を絶対視して、属人化を徹底的に排除する風潮は、おそらく人的リソースを売買するSESや業務委託契約を逆手に取って、安くて何でも言うことを聞く人員を求めて、頻繁に人を入れ替える会社が増えたことが要因でしょう。こういう現場では年中、業務の引き継ぎが行われるので、特定の人に知識やスキルが偏っていることは、人員の買い手からすると都合が悪いのです。能力のある人に支えられていたプロジェクトを、能力が低く安い人員に落とし込むことを仕事にしている人もいますから、この業界は本当にたちが悪いですね
できない人ほど、理解できないことがあるたび不安になり「俺は不安で不安でしょうがないから、早く俺の不安を解消しろ!」と言って、割に合わない要求を突きつけて、他人に当り散らします。こういうエンジニアには絶対になりたくないし、こういう人は甘やかすとつけあがるので、毅然とした態度で臨むべきでしょう
――技術に合わせて自分が変わるのではなく、自分に合わせて技術を変えるのです
私の職場にもいますが、新しい技術が流行り出すと「これからはこの技術がくるから、早く乗り換えよう」と言い出す人が必ずいます。そして、半年とか場合によっては数年もかかる壮大な移設計画を持ち出して、それにチーム全体を駆り出そうとします。しかも、その間のサービスに関わる重要なアップデートは、移設の妨げになるという理由で拒否しようとします
そういう人は、そうやって虫の息になりながら導入した技術も、せいぜい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.
