こどおじがAndroidアプリ作ってたらGoogleに子供部屋を追い出された話 - Qiita
自己紹介 皆様は個人開発をやっておられますでしょうか。私も億万長者を目指して日々スマホアプリ開発をしております。 代表作は安倍晋三エクスプローラー/聖帝エクスプローラー、最近力を入れているアプリはガチ有能AI助手です。他にもいくつかのアプリを個人で開発し、AppStore/GooglePlayで公開しています。 私はこれらのアプリを実家の自室で開発していました。10年以上実家暮らしをしていた筋金入りの子供部屋おじさんです。 なお、ガチ有能AI助手ではバックエンドで使用しているCloudRun、Firebase、Algolia、Suno、Huggingfaceでそれなりに運営費用が発生しています。そのためIn App Purchaseを使用してアプリ内から寄付ができるようにしています。 IAPを使用した寄付機能(iPhone) IAPを使用した寄付機能(Android) GooglePlay
Google Playの住所公開に開業届で対応する
こんにちは。趣味グラマのNobu(@nm_aru)です。 Google Playから以下のタイトルのメールが来ていましたが、身分証の提出ぐらいだろうと甘く考え、期限ギリギリまで放置しようと思っていました。 時間が出来たので内容を見てみると、何と個人開発者は自宅住所をストアに公開するための対応依頼でした・・・。 名前の公開はまだ良いとして、流石に住所公開はハードルが高いので、Playストアでのアプリ公開はもう諦めようかなと思いもしましたが、以下の3点から開業届を出して対応する事にしました。 利用してくれているユーザーがいる iOSのみになるとFlutterを使っている意味がほぼ無くなる 開業届のハードル（手続き、費用面）が低くなった という訳で、ここには備忘録を兼ねて今回の対応を残しておきたいと思います。
プロダクトマネジメントクライテリア
プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。 🎉 プロダクトの成功 プロダクトの成功には2つの要素があります。 ユーザー価値と事業収益がバランスを取りながら最大化している状態ビジョンが実現できている状態この2つを満たしたプロダクトの成功を実現するプロダクトマネジメントについて定義します。 🔄 プロダクトマネジメントのフロー 👆🏻2つのテーマ、5つのカテゴリプロダクトマネジメントには大きく2つのテーマがあります。 🎁 A. プロダクトをつくる仕事 👩👩👧👧 B. プロダクトチームをつくる仕事 そして、「🎁 A. プロダクトをつくる仕事」には大きく4つのカテゴ
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。Read less
解決！OSSコンプライアンス
「OSSはただの無料ソフト」「うちの会社に関係ない」。まだ、こうした考えを持っている企業は多い。だが、ソフトウェアをビジネスの武器にしようとしている企業は、OSSの利用を避けることはできない。利用を適切に管理しないと、思わぬ法的トラブルに巻き込まれる可能性がある。 この連載ではOSSコンプライアンスに関する具体的な課題と解決策をひも解いていく。
事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選｜Shin
プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。 しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。 今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。 プロダクトマネージャー向けフレームワーク4選1. Product Prioritization Frameworkhttps://www.product-frameworks.com/Gusto-Product-Prioritization.htmlこちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。 expected：期待値の大き
設計を歪める認知バイアス - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
2021年度リクルート エンジニアコース新人研修の講義資料です
カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
時雨堂を支えるビジネスモデル
shiguredo_model.rst 時雨堂を支えるビジネスモデル 更新:2023-12-08 作者:@voluntas バージョン:2023.2 URL:https://voluntas.github.io/ タイポなどは Twitter の @voluntas までお願いします。 概要 定期的に更新している 株式会社時雨堂 を作って、 自分が選択したビジネスモデルで充分な利益を上げられるようになったので雑に書き出していく。 時雨堂がどんな会社なのかは 時雨堂コトハジメ を見てほしい。 前提 IT 系零細パッケージメーカー で、ここ最近はパッケージをクラウド版として運用をセットで提供するビジネスも始めている。 主力製品はパッケージソフトウェア製品と、パッケージソフトウェア製品のクラウド版の２つ。 ライセンス契約モデル 時雨堂は自社開発ミドルウェアのライセンス契約モデルで利益を出している
書籍『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』が発売 #voyagebook - CARTA TECH BLOG
こんにちは。技術広報の丹野です。 2020年8月7日、『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』という本が ラムダノートさん から出版されます。 テスト駆動開発でもおなじみの 和田(@t_wada)さん が、VOYAGE GROUPに在籍する主要なソフトウェアエンジニアにインタビューし、その内容をラムダノートの 鹿野(@golden_lucky)さん の協力のもと本としてまとめていただきました。 VOYAGE GROUPにおけるビジネスとソフトウェア開発の在り方を濃縮した1冊に仕上がっていると思います。 Engineers in VOYAGE 事業をエンジニアリングする技術者たち 書影 さて今回は、この本ができた経緯や内容、雰囲気についてみなさんに伝えたいと思い、 和田さん と ラムダノートさん の許可を得て「はじめに」の内容を以下に掲載します。ツイー
技術的負債と戦わずにマネジメントする - Qiita
技術的負債とどうやって戦うか - Qiita こちらを読んで、思ったことを書いてみようと思いました。 記事についての感想 ほとんど同意です！ 凄くまとまっていて読みやすかったです。 ここに書くのは引用記事の別視点での自分の解釈になります。 技術的負債はいつ生まれるか？ 残念ながらアプリケーションのコードを書いた瞬間に技術的負債は生まれます。 どんなに綺麗に書いても、レビューをしても消えることはない闇です。 つまり技術的負債は生み出さないようにするものではなく、コントロールするべきものなのです。 そして、引用元タイトルでは戦う！となっていましたが、 僕は戦い続けて疲れてしまったため、マネジメントすることにしました。 (やることは変わりません) 技術的負債を許容する 技術的負債を細かく返すことは賛成。 ただ、開発者はスケジュールと戦っているため、スケジュール内に必要な機能を提供することが最低限
【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「作ってから売る」と「売ってから作る」と「売れるようにしてから作る」 ～技術の社会実装のための『開発』～