個人開発を7年以上続けて分かった技術選択のコツ
技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな
『エルデンリング』＆『Vampire Survivors』開発者、“なぜ売れたかわからない”。邪念になるので考えない - AUTOMATON
『Vampire Survivors』と『エルデンリング』、2022年に目覚ましいヒットを遂げた2作には奇妙な共通点が見られる。いずれのタイトルの開発者も、なぜ成功したか理由が「わからない」と述べているのだ。 左：『Vampire Survivors』、右：『エルデンリング』 『Vampire Survivors』は、poncleが手がける見下ろし視点アクションゲームだ。プレイヤーは任意のキャラを選び、攻撃しながらフィールドを移動。攻撃手段を増やしたり強化したりするのだ。プレイヤーと共に敵も強化され、やがて敵は大群になっていく。そうした大群を自分だけのビルドで撃破し生き残るのだ。 本作はSteamで2021年12月17日に早期アクセス配信開始され、昨年10月に正式リリース。記事執筆時点でSteamユーザーレビューは12万件以上寄せられ、そのうち98％が好評とする「圧倒的に好評」のステータス
「納期コミットのオーダーは結果的に納期を遅らせること」を逆手にとる - @i2key のBlog
これは Recruit Engineers Advent Calendar 2022 - Adventarの13日のエントリーです。（書いているのは21日です。） 1. 納期コミットのオーダーは結果的に納期を遅らせる 先日、興味深いエントリーを読んだ。 bufferings.hatenablog.com これにつてはほぼ同じようなことを社内のtimesチャネルでも会話しており、スケジュールへの向き合い方についてメタ的理解に昇華させたい。 我々が納期をコミットしなさい、確実に守れる日を教えてと言われたときにやることは、、、 確実に納期を守れるように、余裕をみる。である。 ------------------------------------------------------------ ■：実作業日（問題なければできそうな工数） □：バッファ日（例えば50％の確率で問題おきたときに使う予
ゲーム開発者らが「初めてゲームを制作する人への、もっとも大事なアドバイス」をSNS上に続々投稿。“ある意見”だけダントツで多い - AUTOMATON
近年は、UnityやUnreal Engine、GameMakerなどをはじめとして、無料で使い始めることができるゲームエンジンがさまざま提供され、ゲーム制作のハードルはかつてより下がったといえる。そうしたツールを使って、ゲームを作ってみようという人も増えているかもしれない。初めてのゲーム作りに挑み、分からないことだらけの方も多いだろう。 インディーゲームイベントIndieCadeの公式Twitterアカウントは9月12日、「初めてゲームを制作する人への、もっとも大事なアドバイス」を、現役のゲーム開発者から募集。数多くの投稿が寄せられているため、本稿ではいくつか紹介したい。 まずid Softwareにて『DOOM』や『Quake』などを手がけたことで知られるゲームデザイナーJohn Romero氏は、小規模な作品から始めるようアドバイス。完成までやり遂げることができる規模のものを、まずは
とあるゲーム制作現場で『素人感覚こそ正義』という人が口を出し始めた結果…
生田美和 @shodamiwa ゲームシナリオには、「矛盾や違和感を潰していく」チェック工程がある。ところが稀に「魔法なんて現実には存在しないですけどね」というレベルで、ジャンルそのものを否定されるチェック体制になることがある。どういうことかというと、「ゲームを遊ばない素人感覚こそ正義」という方針のため。 2022-04-12 11:46:29 生田美和 @shodamiwa 「奪われたら世界が困るようなアイテムを、キャラ個人が持ってるってどうなんでしょうね？」「なんでここでバトルになるんですか？ふつうは上司に確認してからですよね？」等など…ゲームを遊ばない人間による「現実とは違う」という指摘に対処していたら、ゲームのスタイルからかけ離れていく。 2022-04-12 11:47:12 生田美和 @shodamiwa 例えば、ドラマやアニメのシナリオに。「一人のキャラが話しはじめたら、ほぼ
システム開発からバグがなくなることはない | 株式会社アクシア
人間が作る以上ミスは必ず発生する ソフトウエアは人間の手によって開発されます。人間はミスをする生き物です。ソフトウエアを人間が作る以上は、バグが混入する可能性はゼロになることはありません。 COCOAに対して「たった一つの障害も許さない」という勢いで意見を述べている人もSNSにはいます。開発の現場にも時々そういう人いますよね。そんな人々に向けてこんなツイートをしました。 COCOAの「不具合は永久になくならない」という発言を受けて、そんなシステムは怖くて使えない！とか言っている人たちは、しょっちゅうWindowsアップデートで不具合修正しているからWindowsは絶対使っちゃダメだぞ。もちろんiPhoneもAndroidもダメだぞ。 — 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) February 20, 2021 これに対しても、OSと単一機能に近いCOCOA
「技術のスペシャリスト」になれないエンジニアのキャリアを考える - paiza times
StartupStockPhotosによるPixabayからの画像 こんにちは。倉内です。 エンジニアになったころは「とにかく手を動かし続けたい」「技術力で勝負したい」という方が多いのですが、実際ある程度働いてみると技術力だけで突破していくのは結構難しいことに気づきます。 尖った技術を武器にいわゆるスペシャリストとして生きていくことができる人はそう多くはなく、paiza利用ユーザー様からも「将来自分はどうすればいいだろうか…」という悩みをいただくことがあります。 エンジニアとしての市場価値を高めるには技術を磨くこと以外に、できることの幅を広げる、サービスやプロダクトの成長にフォーカスする、エンジニア経験を生かして転職する…など他の選択肢もあることを覚えておいてもよいでしょう。 そこで今回は、技術に全振りしないエンジニアのキャリア選択について考えてみたいと思います。 技術力オンリーで生きてい
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
「気づいた人がやる」は害悪でしかない話 - ゲームプランナーの技術ブログ
ゲームの開発中には、たくさんの予期せぬ問題が発生するものである。 策定した仕様が他の仕様と矛盾していたり、突如、新たな仕様を策定する必要が出てきたり、致命的なバグが発生したりといったことである。 そして、それらの問題を解決するにあたり、様々なタスクが発生する。 そのタスクの担当を決める際に、その問題に「気づいた人がやる」という実に日本的な悪しき習慣にもとづいているプロジェクトが未だにある。 今回は、「気づいた人がやる」という方針がいかに害悪があるかを考えていく。 スポンサードリンク 害悪①：気づいている人に仕事が集中する 害悪②：得意な人が対応できない 害悪③：やらかしている人間が成長しない 害悪④：「気づく人」はいなくなる まとめ 害悪①：気づいている人に仕事が集中する 問題に気づいた人ばかりがどんどん新たな仕事を抱えることになり、気づかない人に仕事がまわらなくなる。 気づく人にタスクが
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
