ゲーム開発者から見た PlayStation のヤバさ｜EIKI`
という話題がありました。 この数字の信憑性はさておき、少し前から開発者サイドから見て PlayStation というハードには色々思うところがあって、何人かで集まると「最近プレステってヤバイよね」という話がぽつぽつ出てきたりします。 デベロッパーからしてみれば当然全ハードでゲームが売れてくれるのが一番好ましいわけですが、素直に「SIE 頑張って！応援してるよ！！」とは言えないくらいの状況になっていることは確かで（そしてそれを招いたのは他ならぬ SIE なわけで）、そういうモヤッとした気持ち、もっと言えば危機感を共有するために主観的な話をしたいと思っています。でも、ネガキャンしたいわけじゃないんですよ。この気持ちのせめぎ合いをわかってほしい。 というわけで、PlayStation に対する今の思いを一つ。 ＊画像は DALLE2で出力したサイバーパンクシティにたたずむ犬です。 開発しづらい
45歳になって今更プログラミングを勉強して覚えて何ができるの？って、言われました。何が出来ますか？
回答 (72件中の1件目) スキルを固定的であり限定的であり、自分の可能性を信じず行動しないことは 正直市場から見ればこれほど価値のないことはないんです。 その質問の裏には、勉強はいっぱいしたくない、自分の時間はめっちゃ重要なんだという気持ちが見え隠れします。 残念ながらそんな人間に高い価値はつきません。矛盾してるようですが、役に立たないものに投資できる人間に高い価値がつきます。 あなたはどちらがわにつきますか？？目に見えるものだけ追う猿と、目に見えないものを考える人間 どちらになりたい？？？ 前者になりたいのなら、そう言われて傷つき迎合するといい。後者になりたいのなら、その人の...
良いコード／悪いコードで学ぶ設計入門の感想と注意点
「良いコード／悪いコードで学ぶ設計入門」という本がとても売れているようです。私の所属している開発チームでも、何人か購入した人がいたので、私も購入して一通り読んでみました。 結果として、いくつかの考えが整理され、私としてはこの本によって考えが深まり、本を読んで考えた事自体は有意義であったと思いました。ただし一方で、あまり知識がない状態で（自分の中での判断軸が無い状態で）この本を読むと、色々と誤解が生まれるのではないか？という事を感じました。 一つの技術書がこれだけ売れるという事はそんなに多くはない事だと思うので、つまり、 その内容が改善されるとその効果は相対的に大きい という事になります。そこで、私が本を読んでいて思ったことや、この本の内容で正しいこと、現在も賛否両論とされること、事実として認識が間違っているであろうこと、この本で触れられていないが設計において大事なこと、などについてまとめて
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
サンフランシスコに移住して、新しいサービスを開発しています！｜小川楓太
「このサービスを日本でやるなら、エンタープライズに寄り添ってカスタマイズしていくことになるよ。まずは髪を黒く染めてスーツ着るところから。でもそんなこと小川くんはやりたくないでしょ？ だったらアメリカ行った方がいいと思うよ。」 「そうですね。うん、アメリカ行きます。」 2022/03/31に東京を離れ、サンフランシスコに移住したBlack Inc.というスタートアップを始めてから3年になる。 コロナ禍で解約した渋谷・桜丘オフィスの屋上。いまは離れたメンバーも何人かいる。ほとんどの時間を、クラウドゲーミングプラットフォーム「OOParts」というサービスをゼロから立ち上げて企画・開発・運営するために使ってきた。 そもそもクラウドゲーミングをゼロからやっているスタートアップなんて、技術的ハードルが高すぎて世界中を見渡しても数えるほどしかいないのに、ビジュアルノベルというディープなジャンルのゲーム
入社後10年の節目に｜Yuta Sawa
はじめに2012年2月20日に現職に就職してから10年が経ちました。だからなんだと言う気もしますが、ある種の節目として何かを書いておくこともまあ大事かなと思うので書こうかと。学会云々の話だけが書かれてるnoteというのもいかがかと思うし。 10年前から思えば、よく10年生き抜けたなあというのもありますが、ここ数年は生き抜くだけならそこそこ楽、という思いもあります。この辺の感覚もどう変わっていくのかなあというのは楽しみでもあり、怖くもあり。思い起こせば現職に就職するきっかけなんかもちゃんと書いた記憶は無いですし、それらも含めて一度整理しておこうかと思います。 とか言いながら年始にちょくちょく書き始めたんですけど、書いていったら思いの外長文になってしまいました。かといってなにか実りのあることが書かれてるわけでもないです。おんなじようなことを繰り返してるところもあります。 あと、なんか期待してる
プロダクト開発における納得感 - Konifar's ZATSU
これを読んだ。 medium.com とてもよかった。特にココ。 エンジニア出身ならわかると思いますが、企画はもちろんデザインナーエンジニアも、「なぜつくるのか」「今後どうするのか」ということはとても関心のあることで、そこの納得感はチームのパフォーマンスに直結するといっても過言でないです。 わかる。自分も納得した上で作りたい。納得感なくても素早く作ればええやんと思われるかもしれないが、ふとした時につらくなるし何か起きても提案する気も起きなくなる。特に小さい組織だと納得感重要。 自分でもちょっとしつこいなと思うくらい納得できるまで質問することがある。「この機能なんで最初のリリースに入れるんでしたっけ？」とか「これをつける目的は○○で合ってますか？」とか。相手を信用していないわけではなくて、納得して取り組みたいので気になったところを質問するのだ。聞き方をもっと工夫すればよかったと後で反省するこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
