「作ってから売る」と「売ってから作る」と「売れるようにしてから作る」 ～技術の社会実装のための『開発』～UNITT (大学技術移転協議会) アニュアルカンファレンス 2023 の講演資料を基にした、研究所向け & 技術起点のスタートアップ向けの資料です。『標準化』に関するセッションだったため、ルールメイキング等についても言及しています。
エンタープライズ向けサービスのMVPはこうして失敗する。｜大平 裕介/ CEO at リーナー
どうもエンタープライズ企業の調達を刷新したい企業、Leanerの大平です。 エンプラSaaSの雄である会社の創業メンバー兼役員の方と、オンラインランチの機会があり、示唆深かったので許可をいただきメモ公開します。 ※この記事ではエンタープライズ企業は略称としてエンプラと書きます エンプラ向けにサービス開発している方の参考になったら嬉しいです！ 拡散していただけると次回のやる気になるのでそれも嬉しいです（重要）！ "SMBのMVP"と"エンプラのMVP"一緒にすんな当然だが、SMBとエンプラでは、業務のオペレーションや目標・ミッションなどすべてにおいて、個社性がまったく違う。 比較的、SMBでは、個社性が低く。エンプラでは、個社性が高い。 だからこそ SMBは、MVPが「画一的」で許される。 一方、エンプラは、MVPに「個別性」が求められる。 SMBは、MVPが「境域な要件」で許される。 一方
SaaS系スタートアップのリアルなAWSアーキテクチャ設計
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ
Paul Graham からのスタートアップへのアドバイスまとめ - 🐴 (馬)
Paul Graham のエッセイを読んで、自分なりにまとめたものです。今でも見返すと示唆があるので、読みやすくなるようブログでも書いておくことにしました。Paul Graham のエッセイの翻訳はこちらでリストになっています。ぜひ原文も当たってください（文末に参照先を書いています）。 昔書いたスライドからの転載です。 Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス（スタートアップが迷った時に読む Paul Graham からのアドバイス） from Takaaki Umada www.slideshare.net 原則 Make something people want 「人々の欲しいと思うものを作ろう」 スタートアップにとって一番難しいのは、人々の欲しいと思うものを作れるかどうかである（二番目は資金調達）。人々の欲しいと思うものを作れるま
リーンキャンバス（Lean Canvas）とは？作り方を事例ベースでわかりやすく解説｜Goodpatch Blog グッドパッチブログ
今回はビジネスモデルキャンバスを原型に作られた、リーンキャンバスというフレームワークをご紹介します。リーンキャンバスは事業やプロジェクトの立ち上げにおいて、ビジネスモデルを検証し、改善する際に役立ちます。初心者の方でもトライできる作成例もあるので、ぜひ参考にしてみてください。 Goodpatchでは、新規サービスの立ち上げやサービス・プロダクトの改善のご相談も受けております。 ⇒【資料ダウンロード】事業アイデアを素早く検証できる「デザインスプリント」とは？ リーンキャンバスは、リーンスタートアップという著書で有名な起業家のエリック・リースから応用されたビジネスモデルを一枚の図にまとめたフレームワークです。シリコンバレーでは毎年数多くのスタートアップが誕生しています。その中で事業を成功させるためには、ビジネスモデルに何か問題があったらすぐに軌道修正し、素早くアップデートすることが重要。リーン
アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第１回 概要~ - selmertsxの素振り日記
2019年8月にAzitに入社して4ヶ月。 私はSREとしての役割を期待されてAzitに入社したけれども、気がつけばバックエンドエンジニア兼スクラムマスターをやっていました。 バックエンドエンジニアとしては、AWSインフラ環境の完全な作り直しとTerraformによるコード化、Railsの負債解消、監視設定のコード化などを行っていました。 スクラムマスターとしては、初期の3ヶ月はアジャイル開発(スクラム、XPを組み合わせたもの)、そして12月からの1ヶ月はリーン・スタートアップ開発の導入等を行いました。 ここでは、スクラムマスターとして考えた開発プロセスについて資料にまとめます。 なおこの文章は、0-1 の開発フェーズではなく、すでにリリースされたサービスに途中で加わったスクラムマスターの目線で書かれており、対象とする読者も私と同じような境遇にあるスクラムマスターとなっています。 この開発
顧客フォースキャンバスによる解決に値する課題の見つけ方 by Ash Maurya
以下は、Ash Mauryaによる「Find Better Problems Worth Solving with the Customer Forces Canvas」の翻訳です。本人の許可を得て掲載します。顧客にとって「正しい」ソリューションを構築する前に「正しい」課題を理解する必要があります。私の最初の著書『Running Lean』では、解決に値する課題を明らかにする「課題インタビュー」の台本を紹介しました。本記事では、改良した課題インタビューの台本を紹介したいと思います。 課題/解決フィットの探索は、モデル（なかでもリーンキャンバスを使ったビジネスモデル）を構築するところから始まります。これは「科学的手法」の影響によるものです。リーンキャンバスでは、顧客と課題の仮説が明確になるように推測します。それから建物の外に出て、以下の台本のテンプレートを使いながら、仮説が有効または無効であ
スタートアップの強みはストラテジーと実装の一致 | 矢本 真丈 (@yamotty3)
本稿は先日ツイートした「スタートアップの本当の強みは意思決定の早さではなく、ストラテジーと実装の一致」について、掘り下げ、補足したものになる。 スタートアップの本当の強みは意思決定の早さではなく、ストラテジーと実装の一致 — Yamotty👨👩👦👦 | 矢本真丈 (@yamotty3) November 9, 2019 意思決定の早さが命、の正体は？ スタートアップにおいて「意思決定の早さが命」というのは一つの定説として語られるが、早さが命 = 同じ精度であれば早いほうが良い」と捉えるのは危険。 スタートアップの存在価値は「産業の未来を構築すること」。産業が現時点でその未来に到達できていない理由は明白で、産業内に複数のトレードオフが存在するから。 例えば金融機関や個人間でのシームレス・低価格な送金を阻んでいるのは規制、中央システム、行動心理などに複数のトレードオフが存在するか
スタートアップのためのコンテナ入門 – 導入編 | Amazon Web Services
AWS Startup ブログ スタートアップのためのコンテナ入門 – 導入編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 今回はコンテナのお話です。今日、多くのスタートアップのお客様が本番環境でコンテナを採用し、ビジネスに活かしております。その一方で、「そろそろコンテナやった方がいいか？」「なんとなく使い始めたけれどこれでいいのか？」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といったご相談も数多く頂いております。 本記事ではコンテナ技術のサービス利用を検討されている方向けに、AWS 上でどうコンテナ化を進めていけばいいのかをお話致します。 目次 コンテナとは コンテナオーケストレーション コンテナ利用時・検討時によくある誤解 コンテナへの移行ステップ コンテナとは まずはじめに改めてコンテナ技術についての復習です。
Web 系の MVP / プロトタイプの作り方の一例
「東京工業大学エンジニアリングデザインプロジェクト」では、単に思いついたアイデアを発表するだけでなく、プロトタイプの実装まで含めて実践しています。「プロトタイプ」といっても、ひとつだけ作ればいいわけではなく、段階に応じて複数個作ってもらって… スタートアップの最初期に検証したい仮説（学びたいこと）の一つは「顧客にニーズがあるかどうか」と、もう一つは「製品が提供するアウトカム（顧客にとってのプログレス）が価値を持つかどうか」です。 後者の検証をする場合、ベータ版ぐらいまで作りこまなくても仮説の検証が可能な場合があります。そこでこの記事では、いくつかの MVP と、2019年に使えるツール群、その探し方について解説します。 一部手作業型 MVP（オズの魔法使いMVP）この MVP はランディングページ（LP）や注文表面だけを作り、裏側の処理は手作業でやる、といったものです。 例えば Zappo
カルチャー崩壊と再構築。 Goodpatchが取り組んだ組織デザインの2年間 - 後編｜Naofumi Tsuchiya / Goodpatch
Goodpatchの組織とカルチャー崩壊からの再構築までのストーリーを描く記事、後編です。前編をまだ読んでない方はこちらから。 流れを変えた17年新卒カツキのプレゼン2018年に入りましたが、まだ会社には閉塞感が残っていている状況でした。そんな時に会社でオースティンであるSXSW2018への参加資格を掛けて、希望者が自分の持つデザインノウハウのプレゼンをして、全社員の投票でオースティンに行けるメンバーが決まるという社内企画がありました。 SXSWに行くために6名のメンバーがプレゼン大会に参加したのですが、そのプレゼンの場に出た当時の新卒1年目のカツキのプレゼンは組織の流れを変えていく大きなキッカケとなりました。 「僕は経験も少ないし、ノウハウのプレゼンもできないけど、このGoodpatchの事が大好きです！僕はこの会社を世界で一番有名なデザイン会社に成長させたいです！SXSWでGoodpa
カルチャー崩壊と再構築。 Goodpatchが取り組んだ組織デザインの2年間 - 前編｜Naofumi Tsuchiya / Goodpatch
会社組織を運営していく上で企業文化の重要性は多くの経営者が理解している事かと思います。僕ももちろん起業前から企業文化が一番の差別化ポイントになると理解し、会社運営をしておりました。 創業期から毎日の朝礼、朝礼ではLTと英語でのカンバセーション、毎週月曜日のプロジェクトレビュー、オープンでフラットなコミュニケーション、グローバルコミュニケーション、チームでデザインする、デザインに対してのディスカッションなど、多くのカルチャー醸成のために多くの取り組みを行ってきました。 しかし、僕の経営するGoodpatchは約2年半ほど前に組織とこれらのカンパニーカルチャーがほぼ全て崩壊するという事態に陥りました。 この2年間は自分にとってGoodpatchの失われたカルチャーを取り戻し、再構築するために奮闘した期間でした。 組織の急成長フェーズに起こる事例だと思うので、起業家やこれから組織を作っていく人達
Day One | 矢本 真丈 (@yamotty3)
2017年12月20日に生まれて初めてプレスリリースを出し、いくつかのメディアから取材記事も公開していただいた。 PR TIMES プレスリリース TechCrunch THE BRIDGE このブログは上記で伝えきれなかった自分の思想を、ポツポツと、とりとめもなくまとめたものになる。また性懲りもなく長いため、お時間のある際に読んでいただければ嬉しい。 Make Something People Want 僕は「人が欲しがるプロダクトを創ること」に人生をかけたい と思っている。 毎日新しいプロダクトとの出会いを求めて、とにかくいろんなものを手にとって触る習慣がある。リアルプロダクト、アプリ、Web、IoT、コモディティ、証券など、なんでも。毎日、必ず、新しいものを触る。そして手に取ったプロダクトを通じて、作り手のビューを想像する。「このプロダクトは、誰の、何を解決するものなのだろう？」と。
「SmartHR使い物にならない問題」をどう解決したのか？ VPoEが語る、ピンチを乗り越える開発チームの作り方
2018年4月17日、明日の開発カンファレンス実行委員会が主催する、開発リーダーのためのイベント「明日の開発カンファレンス 2018」が開催されました。開発の効率化に取り組むリーダーたちが一堂に会して、現場で学んだ知見を共有する本イベント。第2回となる今回も、さまざまな経験を積んだエキスパート達がプレゼンテーションを行いました。トークセッション「クラウド労務サービス『SmartHR』を支える開発チームの作り方」では、株式会社SmartHRのVP of Engineeringである芹澤雅人氏が登場。急成長を続けるSmartHRの開発の舞台裏を語ります。 面倒な労務管理の現状 芹澤雅人氏：あらためまして、私は芹澤雅人と申します。SmartHRという会社で「SmartHR」というサービスを作っております。前職で社会人になって以来、ずっとWebエンジニアとしてのキャリアを歩んでおります。 2015
エンジニアが採用人事になって3ヶ月が経った｜Taku Unno
2019年の年が明けてから社内で異動して採用人事の仕事を始めた。 厳密に言うと、採用人事以外にも全社エンジニア組織の改善施策の運用を広く推進するうえでの中心的な施策が採用業務なのだが、業務の8割くらいは採用に結びついているので、採用人事と名乗ってもそんなに嘘ではない。 振り返ってみると、一筋縄ではいかないというのが率直な感想だった。3ヶ月ですぐ成果は出ないものの、やはり数字で成果を振り返ると焦るときもある。そもそも自分が異動したところですぐ結果が出るなら、本職の人事の人たちは苦労してないよね。 さて、タイトルの通り、自分はもともとエンジニアなのだが、この3ヶ月採用人事として働くことで気づいたことなどを少し書き残しておこうと思う。これがきっかけで採用に興味を持つエンジニアが増えてくれたらとても嬉しい。 異動したきっかけ 今の会社に勤めて2年半くらい経った頃、一つのWebメディアのエンジニアリ
新規事業のつくりかた 〜デザイン編〜｜Yusuke Kondo
本記事では、コンセプト設計からクリエイティブ制作、リリースに至るまでのデザインプロセスを、0→1の効率的な進め方と注意すべきポイントなどを中心にまとめたものです。デザイン制作に関連するもので、事業作りの実務的なものは割愛します。 🚀0→1を高速で作り上げるデザインのポイント🚀 ・ 全行程を平行して進め、作っては壊すを繰り返す（プロトタイピング） ・ アイディアは発散させて、とにかく数を出すことに注力 ・ クリエイティブはコンセプトを軸としてジャッジする ・ クリエイティブ制作時は見本を3つ足して3で割ったものにエッセンスを加えると早い ・ クリエイティブは作り込まず、最終段階で磨いていくデザインのメインパートは1~4で、ここに時間と労力の大半を割きます。集中してアウトプットしていく5~7はスピード優先で進めていきます。今回かけた工数は、1~4は10人日、5~7は3人日くらいでした。それ
学生起業でAIスタートアップを1年間やってみてわかったこと - Qiita
自己紹介 東京大学大学院在学中で 株式会社Lightblue TechnologyというAIスタートアップの代表取締役をしている園田亜斗夢です。 この記事の目的 起業して1年が経って、起業を考えている友人から相談されることが増えたから。 起業に至った経緯 研究とビジネスの垣根が非常に低いから 大学院では計算社会科学といったデータサイエンス的な研究をしています。特にニュースメディアの推薦システム周りについてやっています。この分野は、企業との共同研究によるデータの提供が非常に重要です。企業でのインターンでやる内容と研究室でやっていることの内容がほとんど変わらなかったりします。 それなら、ビジネスしないのはもったいないと言うわけです。 独立するということ エンジニアにとって技術に集中できる状況は重要です。財務諸表を作るのは苦手ですし、営業で人に会うのも疲れます。価値が最大化されるのはコーディング
考え直そうーーRuby on Rails生みの親でBasecampの創業者がスタートアップに贈る言葉【寄稿】 - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
Ruby on Railsの生みの親、Basecamp（旧 37signals）のファウンダーでCTOのDavid Heinemeier Hanssonさんによる寄稿記事です。著書に、ニューヨーク・タイムズの�ベストセラー「REWORK」と「REMOTE」。「ル・マン24時間レース」のクラス優勝者。Davidさんの活動は、ご本人のWebサイト、またTwitter（@DHH）でフォローできます。本記事は、Mediumに投稿された記事をDavidさんから許可を得て翻訳したものです。元の英語記事もどうぞ。 *記事は、「Web Summit 2015」のDavidさんの講演内容を起こしたものです。 #WEBSUMMIT2015 12年前、僕はBasecampというスタートアップを共同創業した。月額制のシンプルなコラボレーションツールで、チーム間のプロジェクト進行を後押ししてくれる。 それがあること
スタートアップのアイデア(翻訳)
この記事は2012年11月にポール・グレアムが自身のBlogへ投稿した『How to Get Startup Ideas』というエッセイの翻訳記事だ。 November 2012[[[ The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself. The very best startup ideas tend to have three things in common: they're something the founders themselves want, that they themselves can build, and that few others realiz
自社製品で食べていけるようになるまでやったこと
ミドルウェアのパッケージ製品で食べていけるようになるまでやったことを自分のメモ代わりにまとめておきます。 製品の事業計画を明確にしない自分が想定したとおりに行くことが少ないこともあり事業計画を書いたりしません。日々の状況を見ながら判断をしていくということをしています。そのため中長期的な計画は品質の向上くらいにしておき、機能追加に関してはその度々に考えて実装していくのが一番です。 変化が早い分野でもあるので、事業計画を用意するメリットが零細企業にはないと考えています。 リリース前の開発進捗を共有するステルスはデメリットが多いと判断し、今開発しているもの開発中の状況などを共有しました。これは「製品をステルスで開発して、出したとしても買ってもらうまでの時間がかかる」と考えたからです。 それよりはあの会社があんなの作ってるそろそろ出るらしいと思ってもらえたほうが検討してもらいやすくなります。 今、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
