00:04
3月4日土曜日ですね。時刻は朝9時7分になりました。
昨日、一昨日とまた寝坊してしまいましてですね。
起きたら全然朝活の時間が終わってしまっていまして、
スキップしました。ごめんなさい。
おはようございます。ひめめきーっすことくわはらです。
では、本日はちゃんと朝活を始めていきたいと思います。
本日はですけども、前回に引き続きですね、
You Will Never Be A Full Stack Developerっていう記事ですね。
タイトルに書いてある通りですけど、
フルスタックディベロッパーになれないよって、
なれないかもしれないねっていうような記事です。
これサブタイトル的に、
Our Career Advice for the Working Web Devっていうふうに書かれてあるので、
その辺の話をダラダラ読んでいたんですけど、
3日前ですかね、前半分読んでたんですけど、
後半ですね、今日は読んでいきたいと思いますが、
どこまで読んだかというと、
Specification is Essentialっていうところですね。
本質のシンプル化みたいなところですね。
を読んでいて、それが3つ項目があるので、
その3つのうちの1つ目を読んでたって感じですね。
なんか前回と訳が違う気がするな。
簡略化は必須と訳されましたけどね。
いろんな前提の話をザッと読んでいたんですけど、
その中でシンプルにすることがすごく大事だって言ってて、
そのスタックを簡素化、シンプルにするっていうお話ですね。
そのシンプルにする方法が3つあるよってところで、
1つ目はスタンダラリゼーションですね。
やはり標準化って言われるところをした方がいいよっていうところでした。
今日はその2つ目、パッケージングからいきたいと思います。
レノアさんですね。
おはようございます。ご参加いただきありがとうございます。
今日はダラダラと読んでいきます。
ちょっと技術的な記事じゃないので、
耳の友として聞いていただければなっていうところですね。
じゃあいきましょう。
パッケージングですね。2つ目はパッケージングです。
物事を単純化するもう1つの方法っていうのは、
同時に必要になることが多いものをまとめてパッケージ化して、
シームレスに連携させることですよと。
ストライプとかがその恒例ですね。
銀行、クレジットカード会社、LLC、不正検知メカニズム、
サブスクリプション管理など、
結構考えられなければいけないことって山ほどあるんですけど、
しかしストライプではそれらのすべてを同時に利用することができ、
その結果開発者が好む根本的にシンプルになった
エクスペリエンス、体験というのを得ることができますと。
私の愛するNPMのようなパッケージマネジャーは、
自らパッケージングを行うのではなくて、
何百万もの作者が機能をパッケージ化するための
メカニズムを提供しているんですけど、
現在開発者がソフトウェアを統合する方法というのは
圧倒的にパッケージなんですよということですね。
NPMだけじゃなくて、他の言語のやつもそうですよね。
コンポーザーであったり、PIPだったり、その辺ですけどね。
本当好きに全世界のディベロッパーの方々がツールを作って
そこにアップして、みんながそこにアクセスすれば、
誰でも世界の英知とか世界の技術にアクセスし、
利用することができるというのはすごくいいお話だと思いました。
結局はパッケージなんだというところですね。
あとはAWSや他のクラウドプロバイダーもですね、
主にパッケージングゲームに参加しています。
AWSは仮想化ソフトウェアを発明したわけではなくて、
03:02
それを本当に簡単に購入できるようにしただけだという風に
この方はおっしゃっていますと。
新しいデータベース、サーバー、処理プロジェクトなど、
すぐに普及するものは全てAWSでホスティングされたバージョンになります。
いくつかの顕著な例外というのを除いて、
彼らは新しい技術を発明しているのではなくて、
それを非常に効率的に販売しているだけなんですよということですね。
それも本当そうだよね。
結局パッケージングが必要というか、世の中のニーズにあるよということですね。
では続いて3つ目ですね。
3つ目はアブストラクションですけども、いわゆる抽象化ですね。
増え続けるスタックを乗り切るための最後の方法というのは、
詳細を抽象化することになります。
汎用的なツールを使って特定のユースケースを選び、
足場やガードレールを設置することでやるべきことを減らし、
考えるべき選択肢を少なくして、
特定のユースケースの構築を容易にするんですよと。
この3つの間の境界線というのは結構曖昧になります。
一般的な抽象化というのは標準化されます。
優れたパッケージングはいくつかの詳細を抽象化する傾向があります。
パッケージングする時点でそれはそうだよね。
多少抽象化しないとパッケージングできないんじゃないかなと思います。
しかしこれらの3つのレンズというのは、
物事のあり方を考える上でとても有用になります。
注意しなければならないのは、
簡略化には必ずコストがかかるということですね。
標準を選ぶと時間を節約しツールを得ることはできますけど、
ユースケースのために特別に設計されたソリューションから得られる
潜在的な効率性というのを失うことになります。
パッケージソリューションを選ぶと、
ベンダーに文字通りのコストを支払うことになることがもちろん多い。
ほとんどの場合、自分と問題の間に
コードのレイヤーを追加することになり、
リソースの効率をある程度失うことになります。
単純化にはトレードオフが絶対につきものですよということですね。
シンプルってコストが絶対かかるんですよね。
どこのコストを支払うかというのを
トレードオフを考えることですね。
こう言っちゃあれですけど、
金で殴るみたいな話はあると思っていて、
そういう意味でいくと、ベンダーにコストをかけないといけないけど、
パッケージソリューションを選ぶというのはすごくいいかもしれないですね。
それを今までのWebの世界ではやってきたという感じがします。
その選択肢が一番多かったんじゃないかなというところですね。
昨今、内製化の話が結構増えていたりしていて、
皆さんが内製化を、
自社のリソースを使ってやりたいこととか、
システムを作るという話が結構進んできていると思っているので、
そういう意味でいくと、
パッケージングの選択肢は実はちょっとずつ減ってくるのかなと思います。
実際の開発現場では、
NPMだってパッケージを利用することはそこは変わらないんですけど、
組織的なところから、ビジネス的な観点での
パッケージソリューションを選ぶことは
ちょっとずつ減ってくるんじゃないかなというところですね。
とはいえ、何を使うかというのは結構難しいんですけど。
一応、シンプルにする方法は3つ。
06:01
抽象化、パッケージング、
そして標準化ですね。
というところでした。
続いては、シンプルにすることはコストに見合うという話をしています。
ウェブ開発者が寄せられる不満の多くというのは、
このようなトレードオフに価値がない、
もしくは少なくとも全ての選択肢を十分に検討せずに
トレードオフしているという感覚から来るものになります。
これは結構僕も過去の体験で
わかりまして共感することが多いですね。
でもその通りである場合ももちろんありますけど、
それ以上に問題を考える必要がないという事実が
潜在的な利点を上回っていることが多いんですよね。
新しい開発者はスループットと効率を最大化するための
HTTPサーバーの完璧な構成を見つけ出すのに
何年も費やすかもしれません。
あるいはデフォルトのまま明日出荷して
それについて考える時間を全く与えないかもしれません。
増え続けるスタックにおいて理想的なソリューションは
あるレイヤーを完全に考慮から外すことができるものであります。
と言ってます。
難しいところですよね。どこまで時間を使うかという感じですけど
完璧を求めるのはあれですね。
エンジニアとして完璧を求めればやりがちというか
そこは理想ではあるんですけど
その完璧が果たして何のための完璧かというところが
根本にあるといいなと思いました。
ビジネスにおいてその完璧は実は必要がなかったり
ある程度のところでやりたいことが担保していて
他にもっともっと実現したいことがたくさんあるんだったら
今見ているものの完璧はぶっちゃけ
不要な構図になるのでやらないほうがいいんじゃないかという気はするので
そういう意味でシンプルにするというのは
コスト的な観点での価値があるのは本当そうだなと思います。
問題を考える必要がないという事実が潜在的な利点を上回っていることが
多いよというのは確かにこの観点はすごく大事ですよね。
これでも開発者技術者というのは
完璧を知ってはいるけど
選ぶ選択肢としてはそこを求めるかどうかというのを
選べる開発者というのが
優秀な開発者になるんだろうなという気はしますね。
ちゃんとビジネスのことを考えられる開発者というのが
すごく大事だとは思いました。
結局何のための技術、何のための開発みたいなところの観点に
立脚できているかというのがその本質なんだろうなと思いますね。
では次で
シンプリフィケーションイザ
セルフパーペチュアリングサイクルですね。
簡素化というのは自己増殖のサイクルでありますよと言っています。
僕が英語慣れてなくて読めなくて申し訳ない。
シンプルにすることの推進がもたらす
副次的な効果ですね。というのは
フィードバックグループを生み出すことになります。
私たちのアプリを作りやすくすることで誰もがアプリを作りやすくなるのですと。
その結果ウェブソフトウェアの品質が常に向上することになります。
消費者の期待に応えることができるようになり
シンプル化を実現するための圧力がさらに高まりますよと。
良い好循環が生まれるということですね。
まさしく自己増殖ということですね。
09:01
これはシンプルにすること
だから一回やると
副次的にどんどん良いフィードバックグループが生まれる可能性が高いので
シンプルにすることが本当にメリットあるのか
どれだけビジネスインパクトあるのかを検討するのは
すごく大事なことではあるのですが
検討ばかりに時間を使って結局早く回していった方がいいという
ケースも往々にあり得ると思うので
ここは難しいですよね。
体力と腕力を持って永夜で導入していくという選択肢で
もしできるんだったらしてもいいかもしれないですね。
やってみて微妙だったらすぐにやめれば
ダメージは小さいし
なおかつ今の現状、今のチームとか環境で
こういうソリューションを目指したシンプル化は
うまくいかなかったという知見がたまるわけですからね。
お金としては失って時間も失うんですけど
ノーリターン化というとそんなことは全然ないと思うので
組織として失敗の経験値が詰めて
次回それをやらなくてよいというようなことが起き得るので
やっていいと思うんですよね。
シンプル化というのはどこか永夜でやる必要があるんじゃないかなと思いますね。
検討ばっかりしていって物事を進まない方は
頭でっかちになっても仕方がないですからね。
でも次者は何でもかんでもやればいいかというのはもちろんそんなわけじゃないですね。
やった結果、会社の今年の
お金の計算をしていて大蔵省の
インパクトが結構あるって言うんだったら話は別ですからね。
次者のお金をどれだけ使ってしまうみたいな話は出てくると思うので
ケースバイケースではあるんですけど
ちゃんと議論した結果がいけるんだったら
最後は議論を突き詰めるんじゃなくて永夜でやっていくっていうのがいいんじゃないかなというところですね。
では続いていきましょう。
明らかに私のスタックの中で消えていくレイヤーというのは
本当に消えていくわけじゃないよと言っています。
開発者たちはハードウェアやネットワーク、オペレーティングシステムの開発に
以前にも増して取り組んでいます。
毎日新しいマイクロチップを設計してとんでもない額のお金を稼いでいる人たちがいます。
しかしそのようなことを全く考えていない
より上位の開発者たちに圧倒的に劣っていますよと。
そしてここが重要なところなんですけど
それはそれで良いことだと言っています。
タイトルと内容があまりリンクしなかったんだけど。
ハードウェア、ネットワーク、オペレーティングシステム
いわゆる低レイヤーの開発に以前にも増して取り組んでいる開発者。
毎日新しいマイクロチップを設計してとんでもない額のお金を稼いでいる。
低レイヤーになればなるほど
使うユーザーというのは圧倒的に増えていきますからね。
レイヤーが上がればよりニッチなところ
ピンポイントのところの開発の話になってくるので
そりゃそうだよね。レイヤーが低ければ低いほど
それはとんでもないお金を稼ぐっていうのはそうですけど
リスクとエネルギーコストが要りますよね。
技術力も必要になってくると思うので
なかなか大変ではあるんですけどね。
ただそんなことを全く考えていない
上位の開発者たちに圧倒的に劣っているっていうんですね。
何が劣っているのかはちょっと気になりますけど
12:02
単純にお金の話かな。見えないところでの開発をしているよりも
クライアント量を見える範囲で仕事をする方が
やっぱ目に見える分ちゃんとそこってやっぱ大事だったな
っていうふうに納得してもらえる確率は高いので
お金稼ぎがついてもそういう意味の上の人たちの方が
勝っているというお話なのかなって気になりましたけどね。
ちょっと読んでみましょうかね。
続いてはThe Stack is Too Big to Learnって言ってますね。
タイトル的にはあれですけど
結局物事を進めていくとそこに知見と
皆さんの学びが進んでいくので
より効率的になり
スタートするよりはどんどん安くなっていくっていうのは
それは良い話だと思うんでね。
最初は投資ですよね。
することは結構大事だと思います。
全部を学ぶことは不可能なので
自分なものを身につけたり分かってきて学ぶと
やっとその時にスタックを学びきれるっていう可能性はもちろんありますけど
ウェブ技術の全てを学ぶことはもちろんできないので
結局分担するのが良いんだろうなって思いますけど
それが結果効率的になっていくので
そうなるためにはやっぱり
チーム開発っていうところが
ポイントになってくるんじゃないかなと思います。
続いて
What does this mean for me?
これは私にとってどういう意味があるのかっていう話ですけど
このようにスタックについて考えることで
いくつかの教訓を引き出せると思っています。
いくつかの教訓ですけど、合計3つありますが
まず1つ目は
追いつくために常に走っているような感覚になるっていうところが1つ目だそうです。
これが1つの教訓だと。
エンジニアは常に学び続けるっていうところですよね。
だから常に走っているという感覚になると思いますけど
そんなことは想像していないはずです。
常に新しいことを学んでいなければ
常にスタックの下に流れていくことになります。
あなたが知っていることはどんどん価値が下がっていくでしょう。
人々はあなたが知っていることでない基準に落ち着くかもしれません。
あなたの専門領域は簡単に購入できる単一の製品にパッケージ化され
誰もあなたにゼロから構築することを覚えてもないかもしれません。
それはそうだと思いますね。
今日あなたが理解することで
価値を提供している詳細や微妙な点は
明日には抽象化されたものに包まれてしまうでしょう。
本当そうなんですよね。
学び続けなければならないというのは
自分の市場価値的な話もあるので
学び続けなければならないという良い教訓でした。
2つ目の教訓です。
専門性を高めるという選択肢もありますが
2つ目の教訓だそうです。
チップの設計者やオペレーティングシステムを書く人
ネットワークスタックのスペシャリストはまだまだ存在します。
もしあなたがスタックの重要なレイヤーを得意とするのであれば
いつまでもそこに留まり
待機を稼ぐことももちろん可能でしょう。
しかし懸命な選択もしてください。
15:02
自分の得意分野が標準規格によって排除されたり
抽象化が十分に進んで誰も反復する必要がなくなったりすると
仕事の機会が減ってしまうことはなりません。
要は常にアンテナを張っておいてくださいというのと
いざ自分の持っているスタックが
ニーズがなくなってしまった。
もしくは抽象化されてしまって
少なくとも前みたいにお金を払うことがなくなったという現実が起きた時に
自分が次どういうアクションを取るか
それを取れる選択肢を自分が持っているかというのが重要です。
そのためのアンテナを張っておくか
1と繋がりますが、何か新しい分野
ちょっと隣の分野であるか
もしくは全く関係ない分野でもいいですので
知見を得ておいてそっちの世界に
すぐに移れるようにしておくことが結構大事なことだと思います。
続いて3つ目です。
3つ目の教訓は常にスタックをかけ上がることはできますが
注意してください。
結構さっきのと似た話だと思いますが
スタックを選んで落ち着くという選択肢は
常にスタックを上げていき最新で最も価値の高いものを学ぶというものになります。
一般的に上層に行くほど
スタックに取り組む人が多くなるため
デフォルトではほとんどの人がここに行き着くことになります。
しかし行き過ぎには注意が必要です。
次の大きなものが何であるかは必ずしも明確ではないですし
誰も使わない新しい抽象化を何十個も学ぶことになったりとか
競合他者に追い越されたパッケージソリューションに
取り組む可能性もあります。
自分のフィールドや立ち位置にも気を付けてください。
2番と一緒な気がしますが
学ぶものは何かというと
市場のニーズがなかったり価値がなかったり
大きいお金を稼ぐことがなかったり
そこはニーズがないということですが
実はいっぱい学んでいました。
自身としての選択肢が増えたとはいえ
何十個も学んでしまっても
自分にとっての市場の価値はなくなるということです。
ここも結構大事ですよね。
スタックを書き上げることは本当に良い話ではあるのですが
書き上げているそれが本当に必要性があるか
それが本質的に大事なのかはちゃんと見たらいいと思います。
では続いて
そろそろ結論の話ですね。
This is fine. これでいいんだということです。
画像が2枚貼られていて
犬の画像ですね
ワンちゃんが椅子に座って帽子をかぶっている
人間的な生活をしているのですが
火事が起きている家で椅子に座ってのんびりコーヒーを飲んでいます。
そのワンちゃんが
This is fine. と言っている画像が貼られているのですが
いいんかい本当にという感じです。
説明もあるので読んでいきましょうか。
コーヒーカップを持つ犬
まさにその画像です。
Web デベロッパーのキャリアについてこのような解釈をすると大変なことだと思われるかもしれません。
Web デベロッパーは飽きることのない仕事です。
18:02
Web 開発という職業は
終わりがないし進化も変化もしていくので
飽きることは絶対ない。
あるツールやフレームワークを10年間も使い続けることになることもないでしょう。
多分ないと思いますが
Web サーバー
レイヤーが下がれば
10年間使い続けることは
全然あり得ると思います。
一概にはないでしょうとは言えない気がしますが
アプリケーションレベルまで上がっていく
レイヤーが第4層まで行くんだったら
全然あり得る。
10年間も使い続けることはまずないでしょう。
努力をかけても今年作った作品は
一昨年作った作品よりも必ず良くなっているはずです。
効率的とは言えないかもしれませんが
より洗練されユーザーから高く評価されるようになります。
そしてそのスタックのシンプリフィケーション
シンプリフィケーションはそれを可能にするものです。
シンプルにすることで
前回よりもより効率的より洗練されることが可能です。
最後は結論です。
この記事はすでに長すぎるため
ここで終了しましたが
このトピックについてはさらに探求したいことが
3つあります。
1つ目は現在のスタックはどこへ行くのか
まだ到着していない新しいレイヤーは何なのか
既存のレイヤーのうち消滅する運命にあるのは何でしょうか
今ニーズのあるものは何か
どこが次のニーズになるのか
また何が消滅するニーズなのか
というところを探求しています。
これはすごく大事な話だと思います。
続きが
このスタックのモデルはこの分野のどの技術やどの企業が成功し
どの企業が失敗するかを知る手がかりになるでしょうか
ネタバレとしては結局はいと言っている
この必至者の企業は成功することを知っているのかな
最後3つ目です。
スタートアップの一つや二つは隠されているのか
隠されているかもしれませんね
スタートアップのアイディアがスタックから生まれる可能性はある
という話をしています。
スタックは技術スタックの話です。
スタックからアイディアが生まれるという
結構面白い話です。
市場や社会を見てからアイディアが生まれるのはよくある話だと思いますが
スタックから生まれるというのはなかなか考えたことがなかったです。
目的が技術になってきてしまうのでどうなんだろう
という気がします。
でもそういう探求の道はあるということです。
本記事は締められておりました。
さっきのThis is fineがこの記事の結論だったということです。
とにかく常に学び続けていくということです。
かつ常にシンプルにしていく、中小化していくという話が
なんとなく読んでいってこの必至者の方の
主張にあるような感じがしました。
アブストラクションがより広範囲かつ
21:02
長い目線で使える選択肢ではないのかなと
僕は読んでいて感じました。
でもビジネスの話が関わってくると選択肢として
一概にアブストラクションだけが正解というわけでは
もちろんないと思いますし
スタンダラリゼーションも大事な話ですからね。
営利組織ではスタンダラリゼーションはすごく重要な話ではあるので
ここも追い求めていきたいというのはあるので
頑張っていけるようなデベロッパーになりたいと思いつつも
やっぱりちゃんと自分のスタックを書き上げることももちろん大事なので
いろいろアンテナ張って常に学び続けるデベロッパーで
ありたいなと思いますね。
このような方法化すると多分フルスタックデベロッパーになれるのかな
どうなんでしょうね。
タイトルがYou will never be a full stack developerって書いてあるので
なれませんよって言ってますね。
なれませんよってなれないかもしれませんねって言ってますけど
フルスタックが大事かって言うとそういうわけではなかったりしますからね。
専門特化の人たちがいたりとか
自分の主軸はここにありますけどそのちょっと左隣のところは
他のメンバーに任せるみたいなことがあってもいいと思って
それをチームで解決するっていうのもいい話だと思いますのでね。
もちろんできることに構わないし
話ができるぐらいのレベルを知っておくっていうのがすごく大事なことだと思いますけど
本数なんなのかっていうのを結局常に考え続けていきたいなと思いましたね。
というところで最後余談が過ぎましたけど
これで朝活は終了したいと思います。
いかがだったでしょうかね。
僕はこれ読んでて面白かったしいい記事だと思うので
皆さんの方でも改めて読んでいただければなと思います。
じゃあ今日の朝活はこちらで終了したいと思います。
改めてですねレノアさん土曜日の朝からご参加いただきありがとうございました。
明日もなんか緩く読んでいきたいと思いますのでご参加いただければと思います。
僕がもし起きてればちゃんとやります。
じゃあ土曜日ですね。ゆっくり休んでいただければなと思います。
それでは終了します。お疲れ様でした。
