開発者のためのB2Bサービスづくり徹底入門
こんにちは、普段はプロダクトマネージャをしつつエンジニア界隈にも首を突っ込んでいるku-sukeです。最近では個人や少人数チームでアプリやサービスを使ってリリースする人も増えましたね！その中でも「いままでは個人向けにサービスを作ってきたけど、法人のひとから問い合わせが来た」とか「B2Bって取引金額が大きそうだから興味がある」あとは自分で運営していなくても「B2BのSaaS企業に転職したけどB2Bわからん」という声をちらほら目にしたので、自分が知っている範囲でまとめようと思います。 🔰はじめに。B2Bってなんなん 個人開発者の人からするとこの時点で違和感があるかもですが、Business to Businessつまり事業者間取引のことです。個人の方もビジネスをしている以上は個人事業主ですので立派な事業者です。 これと対比して、個人消費者向けにビジネスする、あるいは広告など個人が使用すること
儲からない個人サービスの作り方と続け方
儲からない個人サービスの作り方 人々が個人サービスを作るときに最も心配になることといえば「もしこのサービスが儲かってしまったらどうしよう」ということだ。 それは、あなたが福沢諭吉や渋沢栄一のことが嫌いだったり、もしくは会社で副業を禁じられていたり、理由は様々だが、とにかく個人サービスで儲かりたくないという気持ちは誰しも持ったことがあるのではないだろうか。 そんな心配性の読者諸兄を安心させるために、儲からない個人サービスの作り方を伝授したいと思う。 広告を貼らない まずいちばんお手軽なマネタイズ手法として「広告を貼る」ということが挙げられる。 逆に言えば広告を貼らないと、おおよそ儲からないのである。 「どうせ大した利用者数にはならないだろうし、広告を貼っても金銭的利益は微々たるものだ。それに広告を貼ったらサービスの美観を損ねる」と思い込んで広告を貼らないと、かなりの高確率で儲からない。 ニッ
Webアプリを作って収益化する、僕の個人開発ルーティン
独学で個人開発を始めて5年が経ちました。これまでには収益化に成功したサービスもあれば、鳴かず飛ばずでお蔵入りになったサービスも数多くあります。それらの経験から、成功したサービスはなぜ上手くいったのか、マーケティングや収益化において押さえておくべきことは何か、その要点が少しずつ見えるようになりました。 今回は私が開発〜集客〜収益化を行うプロセスと、各工程で気をつけているポイントを順を追って書き出してみます。上手く言語化できているか分かりませんが、暖かい目でお付き合いください。 収益化した3つのサービス 私はこれまでにWebサービスを20個以上開発しており、現在はポモドーロタイマー（月間100万ユーザー）やYouTubeのループ再生ツール（月間10万ユーザー）などを運営し、そこからの収入で生活しています。 基本は海外向けのBtoCで、以下のようなツール系が中心です： 収益化済みサービス： Po
"提案"のレベルを上げる - Konifar's ZATSU
組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」
個人開発マネタイズ大全
この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな！ ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください！ 【追記】 上記に対して「有料記事がダメって事？」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います！そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ
チームに無能がいなくなる『メンバー全員で公式ドキュメントを読みあわせる』に感銘をうけた話。 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは、同じエンジニアである妻から聞いた話なのですが、彼女の案件で「メンバー全員で公式ドキュメントを読みあわせる」という取り組みがあったそうです。 で、この方法「チーム全体にとって大きなメリットがあるんじゃないか？」と思ったので、共有させていただきます。 「誰も知らない」から「みんな知ってる」に 私は開発職なので、めずらしいことなのかそうではないのか判断がつかないのですが、その案件では、導入対象の製品について詳しい知識を持っているメンバーが一人もいなかったというのです。 誰もその製品をさわったことがなく、とりあえず強そうなメンバーを入れ
エンジニアが知っておくべき請負契約と準委任契約の違い - Qiita
参考 IT業界では、請負契約と準委任契約がよく使われます。 委任契約はあまり使われることはなく、筆者も見たことがありません。 これは、エンジニアが法律行為を伴う業務を行うことが少ないためです。 請負契約と準委任契約の違い 請負契約と準委任契約は、どちらも業務委託契約の一種ですが、大きな違いがあります。 一言でいうと、請負契約は「成果物を納品することが目的」であり、準委任契約は「業務の遂行自体が目的」です。 請負契約では成果物を納品する責任が発生しますが、準委任契約ではその責任は発生しません。 ウォーターフォール開発で言うと、PoCや要件定義は準委任契約、設計や開発、テストは請負契約になることが多いです。 また、SES（システムエンジニアリングサービス）も準委任契約で結ばれることが多いですね。 PoCや要件定義が準委任契約になることが多いのは、不確定要素が多いため、確実に成果物を納品すること
フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
なぜ、最悪の業績なのに年商の20％にもあたる1億円の売上を手放してまで楽天市場から退店するのか｜鷲尾 岳 / ワシオ株式会社 3代目社長
【はじめに】・自己紹介こんにちは。 今年の1月にワシオ株式会社（以下ワシオ）の代表取締役社長に就任しました、三代目の鷲尾 岳（ワシオ タカシ）と申します。 鷲尾家の次男坊として1991年2月10日に生まれ、小学校5年生までは地元の公立、小６から私立の学校に転校し、中３までは福井県、高校は和歌山県にある姉妹校にて寮生活をしていました。 ここで詳しくは書きませんが、その学校の特徴として、「義務教育は最低限」「校則は生徒が主になって話し合って決める」「1年を通して大半のコマを占める”プロジェクト”という授業で目標を決め、達成に向けて何をするか生徒が決める」「やりたいことは大概やらせてもらえる」などなど、おそらくかなり一般的な学校からかけ離れた環境で多感な時期を過ごしました。 高校を卒業した後、大学で中国語を学んだので、卒業してからは父の伝手を頼って入社後すぐに中国で駐在させてくれる会社さんにご縁
ひとり会社を起業したときにわからなかったこと｜Tetsuya Morimoto
ひとり会社を経営してこの4月から第6期になる。期間として次の12月で創業5年になる。先日、その5年近くの経営の中での失敗からのふりかえりについて書いたところ、多くの人たちに読んでいただいたので嬉しい。 この記事で引用した次の経理の書籍についても多くの人たちが読んでくれているようにみえる。それ自体は素直に嬉しいものの、約4年前の記事であるため、当時の私が起業に関して無知だったり、よくわかっていなかった内容もいくつかある。そこで現時点でのアップデートを含め、いま私が起業するならこうした方がよかったと、自身の経験からわかったことを整理してみる。 起業時に夢も希望もない私自身、先にあげた過去の記事を読み返していて、よい大人がひどい理由で会社を辞めたものだと思う。一方で世の中には既存の社会構造や組織に馴染めない人もいる。自分で会社を経営することは自己責任ではあるが、社会に対して馴染めないなにかを少し
ひとり社長の経理の基本｜Tetsuya Morimoto
2019年12月に自分の会社を設立した。 なんの考えもなく意味なく3月決算にしてしまい、4ヶ月弱で決算を迎え、2ヶ月以内に法人税を納める必要があるので5月に入ってから法人決算を行った。そのときに役立った本の紹介と実際に法人決算をやってみた経験談 (失敗談) を書いておく。 (2024-05-05 追記) 本稿の続編として時間が経ってからわかったことなどをまとめました。 法人設立のきっかけ仕事を辞めようと思ったとき、次にやりたいことはとくになかったし、40歳を超えて年齢的にも雇ってくれる会社をみつけるのは難しいだろうということは容易に予測できた。少し転職活動をしてみたものの、自分自身にやりたいことがないのもあり、あまり手応えを感じなかったので消去法のような流れで起業することにした。 私の場合、会社設立 freee を使って法人設立のための手続きをした。必要な手続きや書類作成など、法人登記まで
IT契約入門〜雇用契約、請負契約から準委任まで - Qiita
この記事は？ 著者は、エンジニアにとって最も大事なものの一つは契約であると考えます。なぜなら、契約によって我々はお金を得ることができ、労働対価を受け取って生きていくことができるからです。プロジェクトにおいてトラブルが発生すると、契約はメンバーを守ってくれるものになります。したがって、雇用契約、請負契約、準委任契約など何の契約であっても隅々まで確認し、不利にならないようにしないといけません。社員であれば誠実に職務に向き合う必要があります。請負契約であれば対価を得るために納品する必要がありますし、準委任契約であれば善管注意義務を背負いプロとして日々業務を行なっていく必要があります。一方で、著者は長くにわたって業務委託契約でパートナーとして参加してくださっているエンジニアたちと長らく協働してきた経験がありますが、ユーザーとしてもベンダーが妨害要素なく働けるように、協力義務を果たす必要があります
チームで仕事をするなら、リアクションし続けよ｜森 一貴（Mori Kazuki）
チームで仕事するとき、みんなもう少し自分の存在、自分のリアクションがチームに与える影響を自覚した方がいい。 例えばミーティングでブレストしているとき、議論が前に進むのは、あるときふと場に出されたアイデアに対して、誰かが"それいいですね"って言った瞬間である。アイデアを出したとき、その人にはふつう、確信なんてほとんどない。僕なんか自分の意見に自信なんかなくて(大体みんなそうなのだ)、言ってみて、まわりの反応を見て、あ、なんか良さそうだ…と思ったときにやっと前に進むことができる。みんな、自信なんてないのだ。だからアイデアは、場に出されたときはまだ、波際の砂のお城のようにやわらかである。 しかし、あるアイデアに対して、それいいね、と声をもらったとき。いい顔が見えたとき。姿勢が前のめりになってくるとき。そのときとあるアイデアは、はじめて光るのだ、形になる可能性を見せるのだ。 * 逆に言えば、議論に
外部からいきなりCTOとして就任する時に気をつけていること｜BTO
おはこんばんちは!!尾藤 a.k.a. BTO です。 私は今はオープンロジでCTOをしていますが、オープンロジを含めて今まで4社でCTOをしています。CTOとしての実績と経験を積み重ねてきた結果、今ではある程度開発組織が大きくなった会社からCTOのオファーをいただくことが増えてきました。 いわゆるパラシュート人事というやつです。パラシュート人事は非常に難しく、私が今まで見てきた中でもパフォームしていないマネージャーはほとんどが外部登用でした。逆に現場上がりのマネージャーはうまくワークしており、微妙な人は少数でした。 このように失敗する可能性の高いパラシュート人事で入社する場合は、いろいろ気をつけないといけません。CxOとまではいかずとも、みなさんの中にも転職をきっかけに何らかの責任者としてのポジションを期待されて入社することもあるかと思います。そういった方に私の気をつけていることが参考に
中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
社内ヘルプデスクのチケット管理システム、みんな何使ってるんですか？→有益すぎる情報が集まる
依頼仕事の最適化 〜未完了をいかに完了にするか〜
集中して作業する技術/how_to_work_deeply
なぜレッドオーシャン化する前にサービスを グロースできなかったのか？ - フリマアプリ編 - @yutadayo
