当事者が自分で作らずに誰かに任せたら、まったく同じような状況になる気がします。
どれだけ丁寧に説明しても誤解はありますし、どれだけ細かく確認したつもりでも、思い至らなかった領域が存在するものですね。
依頼主が言及していない部分を一つひとつ確認しながら作ると時間もかかってもどかしいので、専門家が判断して処理する部分がかなり多いのですが、その部分がことごとく揉め事の種になるのだと思います。
それはそれとして、SI企業にあまり痛い目に遭わされてこなかったようで、うらやましいです。

 

はは、まったくもう
Slackでこの内容を見て誤字かと思って見に来たのですが、なんと誤字じゃなかったんですね(笑)とても面白く楽しく読ませていただきました。細かい説明もありがとうございます。
余談ですが、TeslaやX、StarlinkアプリのUIには、どこか一貫した好みが見える気がしますね……

 

Clineも一度体験してみたいですね!

 

Hacker Newsもかなり年齢層の高いコミュニティだったんですね。
さまざまな意見があって面白いです

 

www まさにこれですね

 

タイトルと内容が一致していませんね。だまされた。

 

スターリンクを使ってみたいとは思っていましたが、こうして海外旅行のときに持って行って使ったという投稿を見ると不思議ですね。
やはり未発売の国で購入して、料金プランを開通?すること自体が関門なんですね。
興味深く読みました。

 

このすべての波が過ぎ去ったとき、後世はこの時代をどのように記憶するでしょうか

 

インターネットが絶対に必要だったというよりは、携帯電話の電波が入らない僻地へ行くついでに、一般消費者でも使える衛星インターネットサービスを一度ぜひ使ってみたかった気持ちのほうが大きかった気がします。笑

 
tensun 2025-05-11 | 親コメント | トピック: ビジネス書は戦略的ツールではなく娯楽 (theorthagonist.substack.com)

教科書が陳腐だとしてもその権威を無視したり、その代替が教科書に取って代わることが難しいように、よく知られたビジネス書はそれ自体が経営学やスタートアップ学の土台、あるいはその核心になります。
スティーブ・ブランク教授の代表作である顧客開発方法論はその土台としてリーンスタートアップの理論となり、これに参加した学者や先駆者たちがビジネスモデル・キャンバスやリーン・キャンバスなどの効果的なツールを作り、大衆化させたのだと思います。
これをおとしめたり、本来の目的を忘れて万能薬のように考えるのは、その本来の目的をきちんと理解していないからだと思います。

 
alvarez34 2025-05-11 | 親コメント | トピック: ビジネス書は戦略的ツールではなく娯楽 (theorthagonist.substack.com)

百戦錬磨の多国籍企業の役員層ですが、例外はダグ・ゴールドマンだけだという点には完全に同意します。この手のジャンルの本は本当に時間と紙の無駄です。それよりも、歴史、経済、人文学系の本のほうがはるかに役に立ちます。

 

Trivyで調べてみると、jsのNPMやJavaのMavenよりもhighやcriticalがはるかに少なくて安全なのに、Rustを使って何を主張しようとしている文章なのでしょうか?

 

Webページのリンクを渡すだけで要約してくれるサービスはないでしょうか?

 

Michael Lopp が運営する、技術リーダー向けの Slack があります。
RLS - Rands Leadership Slack
興味のある方は一度参加してみてください。現在 36,000 人以上が参加する巨大な Slack です。
参加するには、上のリンクの内容をよく読んで、Lopp にメールを送れば大丈夫です。
名前 / 職業 / なぜ参加したいのか / どこで RLS について知ったのか / 自分の LinkedIn や Twitter などのアカウント

 

Rustだけの問題ではありません。
共用パッケージリポジトリと推移的依存関係をサポートするパッケージマネージャーがある、あらゆる言語に共通する利点であり、潜在的な問題点でもあります。
結局のところ、持ってきて使う側がうまく使わなければならないのですが……
Node&npmのleft-pad騒動があったにもかかわらず、何も変わっていません。

 
aer0700 2025-05-11 | 親コメント | トピック: ビジネス書は戦略的ツールではなく娯楽 (theorthagonist.substack.com)

同じ文脈で、顧客企業や投資家や上司に提出する文書を作るときも、売れそうな何かを作るという観点からアプローチすることが重要なように思います。man page は非常に優れていますが、そのフォーマットをベンチマークして投資説明資料を書いたら失敗するでしょう。

 

大規模AI開発時代に合わせて、小さな単位で単一責任として実装することが必須だという点には同意します

 

スタートアップでも、マイクロサービスには多くの利点があると思います。まず、モノレポを使う利点は本当におすすめです。

  • プロダクトの方向性が修正されたとき、マイクロサービスはモノリシックよりも修正すべき箇所が明確で少ないです。私はこれが本当に大きいと思います。
  • AI開発の時代において、マイクロサービスの小さな単位はAIを使って開発しやすいです。(モノリシックではできないという意味ではありません)
  • CI/CDの負担は認めますが、方向性を固める段階で整理されるサービスもあります。最終的に方向性が固まった段階で構築しても、ほぼコピペレベルなので1週間以内に構築可能です。
  • 言語ごとに強みのあるオープンソースは明確です。SecurityとビジネスロジックはJavaで、AIはPythonで、という形で、マイクロサービス構成ではできるだけ多くのオープンソースを活用できます。