課金術
有償ソフトウェアを売る方法分かんなすぎるから、気軽に相談できる人欲しくなってきた...。 ・寄付募集型か、有料で一部の機能を解放する型か ・価格設定 ・有料で一部の機能を解放するなら、どこまで有料にするか ・買い切り型か、月額サブスクリプション型か とかとか、考えること無限にある。。 — Cside (@Cside_) October 2, 2023 個人開発ではないが、課金については仕事で結構やってきてまぁまぁの知見を得た。かつて自分も情報を得ようとネットで探してみたが、極めて情報が少なかった。ソフトウェア開発についてのノウハウは結構ネットに転がってるが、値付けなどについての情報は少ない。エンジニアとマーケッターでは文化が違うのかもしれないが、そもそも値付けに関しては商材（ソフトウェア）によって様々なので定石がなく、結局のところ自分で試してみないと正解がわからないのではないかと思う。そう
不便になるインターネット
ソーシャルメディアやニュースサイトに毎日新しいコンテンツが次々に投稿されるので、インターネット上の総情報量は増えていっているはずだが、 20 年前と比べてアクセスできる情報の種類は減っているのではないかと感じる。いま何か情報を得ようとしたときに Google は以前ほど便利ではなくなってきている。 Google がキュレーションした情報にしかアクセスできないからだ。誰にもフィルタリングされていない生の情報にアクセスしようとしたら Twitter 検索の方がよっぼどよいと感じるくらいだ。 昨年末、 40L の登山用バックパックをニュージーランドのショップから購入した。日本でも売っていた商品だが、国内の正規取扱店では売り切れてて個人輸入で購入するしかなかった。商品名で Google 検索しても日本語のページしかヒットしないし、在庫ありとして表示される楽天や Amazon のページには怪しい業者
プロダクトマネジメント私記
2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。 Table of Contents プロダクトマネージャーになった理由 プロダクトマネージャーの役割 1. 何がユーザーの問題かを特定する 2. その問題を解決する製品を定義する 3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる 4. 製品が「正解」であったかの評価を行う 実際になってみてのギャップ プロダクトマネジメントの認知度が原因？ 一体型
プレーンテキスト Markdown 時代の終焉
なぜ Day One は Markdown を捨てたのか Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。 Day One がクソになった Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレー... portalshit.net 自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する1という戦略は疑問だった。 ひとむかし前の WYSI
プログラミングをしなかったリリース
今週、 YAMAP でブラウザーでコースタイム付きの地図を表示し、自由に印刷できる機能をリリースした。 開発の経緯 ユーザー要望が開発の起点だった。 YAMAP には Google Maps のようにウェブブラウザー上で登山道や登山口情報などを見る機能はなく、無料でダウンロードできる画像形式の地図は提供していたが、以下の課題があった。 磁北線・縮尺の欠如 任意の範囲を切り取っての拡大印刷はユーザー任せ 地図の更新（コースタイム、山頂データなど）には画像データの書き出しが必要（アプリ内で使う地図に比べて更新サイクルが遅れる） 切り取り拡大の課題を解決するためにサポートチームが画像編集ソフトの使い方を教えたり、サポートスタッフ自身が地図を編集・加工して渡すことがあり、非常に負荷が高かった。 Google Maps のようにブラウザーで地図を閲覧できて、任意の範囲を自由に印刷できれば問題が解決す
ジュニアを採用しない連中はシニアに値しない - portal shit!
Twitter で DHH が共有していた記事が面白かったので著者の許可を得て翻訳します。 "If you don't hire juniors, you don't deserve seniors", spot on! We've had phenomenal success hiring junior developers at Basecamp. @jasonfried first tech hire was particularly junior at the time 😂https://t.co/QczMtsou4J — DHH (@dhh) September 21, 2018 ジュニアを採用しない連中はシニアに値しない、というもの。 If you don't hire juniors, you don't deserve seniors (2023) • Isaac Lym
AWS をどう使わずにおくか - portal shit!
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
Kaizen Platform という会社について
Qiita:Team エントリのレベルが高い CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。 SRE （インフラチーム）のレベルが高い インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。 yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA （総務部門のドン）やってるし、 glidenote さ
Kaizen Chat リリースのお知らせ
Kaizen Chat とは Kaizen Platform 内でユーザー同士がコミュニケーションを取ることができるサービス。 Kaizen Platform のユーザー カスタマー Kaizen Platform と契約し、 A/B テストツールや Growth Hacker によるサイト改善のデザイン案を募集 Growth Hacker 募集に応じてカスタマーサイトのデザインを改善するデザイン案を投稿 Kaizen Platform 社員 カスタマーと Growth Hacker の間の調整役 Kaizen Platform 内のユーザーが外部のツールや電話を利用して行っていた伝言ゲーム的なコミュニケーションを置き換えて、直接コミュニケーションを取ってもらうようになることが目標。 サーバーサイド 2.5 人、フロントエンド 2 人で 2 ヶ月くらいで作った。 構成 数多く存在しているマ
良いエンジニアの定義
今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。 良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。 技術力に加えて、プロジェクトマネジメントのスキル（以下プロマネ力と省略）も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかも
YAPC::Asia Tokyo 2015 を観覧
YAPC に行ってきた。ちなみに去年は嫁さんに↓のように言われて行けなかった。 俺「東京であるプログラミングのイベント（YAPC）に行っても良いでしょうか？」 妻「あんたには中身がない。社長になりたい、起業したい、金持ちになりたいと言ってる高校生と同じでスカスカ。何をやるかがはっきりしてない。そんなんでイベントに行っても意味ない」 — 清貧太郎権左右衛門 (@morygonzalez) August 20, 2014 今年は YAPC 最後なのでどうしても行こうと思って無理矢理チケット申し込んで飛行機と宿とって行った。帰ってきて嫁さんに感想を聞かれて、詳細を話しても意味わからないだろうから「がんばろうという気持ちにさせられた」と話したら、「えー、それだけ？ 何も学んできてないわけ？」と言われた。 一日目 一日目の方は業務の一環として参加させてもらった（チケット代とか飛行機代とかは自腹）。
会社を辞めた
会社を辞めた。3年半在籍してた。 ペパボに入る前は凄いブラック企業で働いてて、 Subversion やめて Git 使いたいと言ったら会社辞めろと言われたりしてた。そんなときに蜘蛛の糸のように目の前に垂らされたのが Dazaifu プロジェクトの求人で、藁にもすがる思いで応募し入社したのだった。この辺は過去のエントリに適当に書いてあるので読みたい人は読んで下さい。 前働いていた会社の思い出と近況 いまの会社は労働環境よいんだけど、前働いていた会社がとてもつらかった。どのくらいつらかったかというと、もう辞めてしばらく経つのに、いまだに前の会社にいたころの夢を見てうなされて夜中に目が覚めるく... portalshit.net ペパボは働きやすくて、毎日18時になったらみんなさっと帰るし、21時過ぎに会社出ると最終退出者であることもしばしばだった。家庭の事情にも理解があって、育児休業をさせて
死んでしまったサービスの供養
この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。 2011 年の 10 月から FANIC という音楽配信サービスの開発に携わっていたのだけど、サービスを成長させることができず、 2013 年の 8 月にサービス終了した。 サービスが死ぬのは技術者がクソだということだけではないと思う。市場とか外部環境に左右されるし、企画とか売り方がダメなことの方が多いと思う。しかし現実に自分はプログラマーとして FANIC というサービスの死に荷担してしまった。弔いになるか分からないけど、 FANIC で何がよくて何が良くなかったのかを書いてみたいと思う。 FANIC とは FANIC は主にアマチュアのミュージシャンをターゲットにしたホームページ作成＆音楽販売サービスで、アーティストは自分の公式ホームページを簡単に作
GitHub で Pull Request を Merge したらコードが消えた話
会社で使ってる GitHub のプライベートリポジトリで master ブランチに対して出てる Pull Request を Merge したらコードが消えるという珍事があった。ファイルを削除する commit とかないにもかかわらず、全消しされてしまった。ちなみに同じ Merge を手もとでやるとコードが消えたりはせずちゃんと Merge された。極めて謎な現象だった。 master ブランチが空になるとデプロイができなくなって不都合があるので（ Webistrano 上でデプロイするとき master ブランチからしかデプロイできないようなレシピになってる）、コードが消滅したブランチを bukkowaremaster にリネームして手もとで Merge したブランチを force push してしのいだ。 GitHub に問い合わせてみたところ、ぬるい感じの一次返信が来たので原因教えて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
