"事業開発"投稿一覧

大橋桃太郎

プロジェクトマネジメント

売上に関連する指標を目的にチームでプロダクトづくりをすることは難しいと認識しており、売上の原因となる顧客状態を目的にするべきだと思います！

xx円, CVR xx%, etc... からはそれをかなえるユーザー体験を描きにくいなと

北野勝久

エンジニア

執行役員として会社の経営チームに参画しているものです。すでに回答されているIshiiさんの考えを拝読し、いっしょに開発しているメンバーと、先のことを話す機会をもっとたくさん増やさないとな、とあらためて感じました。

一点だけ追加でアイデアを共有するとすれば、「一貫したプロダクトバリューは存在しない」、ということでしょうか。
これはもとフリークアウト 佐藤裕介氏の考えに... 続きを見る

北山 淳也

エンジニア

「ミニマムに作って（捨てる）」ということを癖づけることで作業開始〜リリースまでの心理的ハードルを下げることかなと思います。最低でも月に１本くらいのペースで何かを作る→デプロイしてWebに公開する/アプリをビルドしてエミュレータや端末で動かせる状態にする（可能ならストアに出す）みたいなことをやり続けていれば、少なくともその流れに試したいものを載せることは簡単に感じるはずです。

... 続きを見る

Haruka Ishii

プロジェクトマネジメント

BtoB SaaSの会社を経営しています！以下、何かの参考になれば幸いです！

サービスの将来像の共有は
・最終的な絵図（5-10年後に実現したいあるべき世界線）
・ロードマップ（足元〜3年間）
の2つに分けて共有するようににしています。

「最終的な絵図（5-10年後に実現したいあるべき世界線）」に関しては
・弊社の... 続きを見る

大橋桃太郎

プロジェクトマネジメント

事前にアジェンダや資料の共有とかできるのがベストではあると思うんですが、多忙だとその準備が〜とか、みんな多忙で準備したところで〜という状況もあるかなと。自分や周りがそうなんですが、①論点とそのゴールをクリアにしておくこと ②その会議のアジェンダではないことが話題にあがってもその場で議論せず、別会議としてセットすること（可能ならその場ですぐに別会議をセット） ③できるだけ会議ごとに一つのアジェンダに... 続きを見る

Shinichi Kogiso

デザイナー

ちょっとした小技ですが、例えば1時間の会議なら15分削ることを宣言して、その時間の中で会議の目的を達成する...というものがあります。
パーキンソンの法則というものがありますが、第一の法則の中で「仕事の量は、完成期限までに与えられた時間を全て満たすように拡大する」と述べられています。MTGもまさしくそうで時間いっぱいギリギリ使うような働き方になりがちです。

であれば... 続きを見る

Takashi Iwato

デザイナー

前日までに、MTGのアジェンダを時間単位で決めておき、
事前に資料を配布しておく。

それだけでも違うし、オンラインの時は「音聞こえますでしょうか。」の
無駄な接続確認やテスト時間を省略するために、
「オンラインMTG事前準備の簡易マニュアル」を配布し、メンバーに共有しておくだけでも
効率化は図れそうです。　IT利用やPCの知識や環境にバ... 続きを見る

jun

エンジニア

参加人数と会議時間を反比例させるルールを作ってしまうなどですかね。
ただ会議を減らすとか時間節約という発送に至る前に、会議や合意形成がなにをもたらすのかなど開発活動をメタプロしてみるのが本質的なんじゃないかと思います。

北野勝久

エンジニア

会議の冒頭に読む時間を入れることでしょうか。
会議の性質にもよるとは思いますが、共有や目線合わせの意味合いがつよい会議体だと、議事録をある程度埋めておけば、冒頭に読む時間を設けることで気になったところだけを深堀り議論できるので、スッキリ終わらせられることが多い気がします！

kentaro haneda（jumbo）

エンジニア

・最初に目線を合わせること
・おさらいから始めること
・合意形成なのかディスカッションなのかなど目的を明確にすること
・些末でも良いのでドキュメントは必ず用意すること

あたりですかね！

齊藤百花

エンジニア

私は名指しで確認するようにしてしまっています。

会議はオンライン会議が多いので、ミュートになっていたりすると、ちゃんと理解が進んでいるか、わからないときがあります。
なので、皆さんこれで大丈夫ですか？と聞くのではなく、〇〇さんこれでよろしいですか？と聞くようにしています！

山本隼汰

エンジニア

役割によって求める程度には濃淡をつけても良いのかもな、とは思っています。組織全体で、ドメイン知識の最低ラインが整う様にはしていきたいなと。客観と主観のバランスを、今組織のメンバーに求められている水準に合わせて定義しなおす様なイメージです（抽象的ですが）

例えば、ドメイン理解を仮に、「想定している領域の中でどの様な商慣習が存在し、どの様な市場構造で、どんなプレイヤーがどの様な活... 続きを見る

Shoichi Namba

エンジニア

やはりメインの機能以外は作らない、というところだと思います。多少コードが汚くてもuiがぐちゃぐちゃでも無視して使うのに必要な部分だけの道筋を作る感じです。

荘野敬也（bowyer-app）

エンジニア

僕はモバイルアプリの開発をしています。
ミニマムで機能を検証出来る単位でアプリを使って検証するようにしています。


毎回新規でプロジェクトを作ると面倒なので、今後は自分が使うライブラリなどを入れた状態のプロジェクトを作成し、GitHub templateリポジトリとして登録しようと考えてます。

大橋桃太郎

プロジェクトマネジメント

最初期のプロトタイプであれば、実現したいことのコンセプトの表現強度だけを意識して、現実性や整合性を置き去りにすることで、スピードと速度出せるなーと思ってます！(プロトタイピング楽しいですよねえええ)

竹位和也

プロジェクトマネジメント

ドメイン知識の獲得の進め方については、ビジネスモデル、専門性、法律・業界規制、新規性の4つの組み合わせで結構色味が異なってくると思っています。

ビジネスモデル
B2B、B2C、C2Cという大まかなものからロングテールやフリーミアムといったものも含まれます。ビジネスモデルがシンプルだとバリューチェーンもイメージしやすく頭に入りやすいと思いますが逆だとしんどくなります。... 続きを見る

Atsuhiro Teshima

エンジニア

現在動画のサービスを作っているのですがリアルタイムに大量に情報を処理を行う必要があったのでElixirを開発言語に選びました。(Elixir自体は経験がありましたが、RailsやNodeなど他の経験ある言語も検討しました。)

SNSだとタイムラインの更新をWebsocketなどで行うことを考えると、Firebaseなどのツールを使ってそこをするのかNodeのようにWebsoc... 続きを見る

makoto tanaka

プロジェクトマネジメント

オンボーディングについての考え方になるかなと思いますので、
弊社の事例をお話しさせていただきます。

▼共通認識を高めるためのオンボーディング体験の構築

1. 全社オンボーディング
ーMVVの成り立ち、会社の歴史、進めてきた背景、事業・プロダクトについての概況
ー会社のインフラ面の説明など

2. 事業部オ... 続きを見る

Haruka Ishii

プロジェクトマネジメント

1.最初からコードを書かない（モックやデモ、ノーコードで機能にあたりをつける）
2.プロダクトロードマップとチーム体制の変遷のロードマップを作成する（機能の変化・UXの変化を特に）
3.2を踏まえて、可能な限りテックドリブンで進められるようミニマムな仕様にする

とかはやっておいた方がよかった（次のプロダクトでは絶対やる）と思っています。
もちろん... 続きを見る

Shoichi Namba

エンジニア

他の方の回答を見ましたが言語選定からわからなそうだったのでそのあたりの話もさせていただきますと、時々フリーの方などでマイナーな言語やフレームワークを好んで使われている方がいたりします。そういった方にあたるとその後のその言語、フレームワークを使える人材の採用が難しくなり、ある程度事業進めた段階で困る可能性があります。

そのため可能な限りよく使われている言語、フレームワークなどの... 続きを見る