前回、スタートアップにおけるCFO採用という記事を書いたので、今回はその続編ということでCTO採用について書いてみたいと思います。 テクノロジーを競争力の源泉とする昨今のスタートアップにおいて、CTOは必須の重要ポジションとなっています。 CTOがいなければ良いアイデアがあってもうまくプロダクト化することができず、またVCからの資金調達でも優れたCTOが経営チームにいるかどうかで評価が大きく変わってきます。 しかし、技術のバックグラウンドがないCEOの場合、CTO採用は困難を極めます。CFO採用と同様に、CTOも距離が遠いポジションですよね・・・。 さらに、優秀なエンジニアは人材市場において超売り手市場。エージェントへの紹介フィーはどんどん高騰し、カジュアル面談という名のゼロ次面接が当たり前となり、有名スタートアップからメガベンチャー、大手までの熾烈な争奪戦となっている状況です。 シード・
メルペイでプロダクトマネージャをしてます、さとじゅんです。 メルペイでto B向けプロダクトの開発をしてます。なので、主にto B向けプロダクトについての話になります。 たまに思うこと突然ですがPMは新しい機能を作る時は仕様書を書くことが多いですよね。 PRD(プロダクト要求仕様書)とかですね。 「Why」とか「What」とか「How」とか書きますよね。 それでリリースして運用していくと思うのですが、運用中にいろんな課題をこなしていくうちにひとつの事に気づきます。 「もう少しビジネスとシステムとオペレーションがひとつのつながりで理解できる資料が欲しいな」と。 to C向けのプロダクトに比べ、to B向けのプロダクトにはセールスやオペレーションのチームなど1つのプロダクトに関わる人が多くなる特徴があると思います。 PLGという考え方もあると思いますが、だいたいのto B向けプロダクトがto
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用(難しい人というラベリングを特定個人に適用する使い方)が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40%低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
kdmsnr さん訳の『アジャイルレトロスペクティブズ』邦訳出てます!(紹介おくれました) http://www.amazon.co.jp/dp/4274066983/ この本はぼくが大好きな洋書の翻訳です。なぜ好きかといいますと、 「ソフトウェア開発プロジェクトという現場を、人生の時間をすごすのにふさわしい有意義な場にしたい」 という願いが、著者の二人の共通の動機だからです。私もその趣旨の活動を行っているつもりですし、少しずつ、これらの活動がまとめられて、形になり利用されていくようになることで、現実が変わって行くのだと思っています。 縁あって、本書日本語版の前書きを書かせていただきましたので、引用します。 日本語版へのまえがき チームをもっと活気づけたい、チームの会議をうまく進行したい、問題続きのプロジェクトをなんとか変えたい、チームの改善活動を推進したい、チームのメンバーにもっと笑顔を
短期間のイテレーションを繰り返して成果物を作り続けていくアジャイル開発。なぜアジャイル開発は短期間で開発を行うのでしょうか、ここでは品質という切り口で、アジャイル開発の本質について解説していきます。アジャイル開発の概要についてはこちらのコラムをご参照ください。 また、ここで解説する内容は、XP(eXtream Programing)なども含めて、いわゆるアジャイル開発手法と呼ばれるものに共通の考え方ですが、用語などについてはスクラムフレームワークのものを使用しています。スクラムについては、巻末に記載しています参考文献の『スクラムガイド』をご参照ください。 もくじ アジャイル開発の考え方 「QCD」を固定して扱う 「S」を調整する ウォーターフォール開発の懸念点 開発期間が長いほど工数の見積もりに差異が出やすい リリースできる品質になるまで対応必須の事態に 開発期間を短くし見積もりの際を減ら
プロジェクトの成功率を高める検証手法として、心理学者であるゲイリー・クラインが提唱した事前検死(pre-mortem)についてまとめる。 ※本記事は自身が執筆した記事を転記したものです。 事前検死(pre-mortem)とは 事前検死(pre-mortem)とは、プロジェクトの開始前に「プロジェクトは失敗した」という想定で、チーム内でその原因を検証することをいう。 「pre-mortem」は、医療の改善などのために遺体の検死や解剖を行うことを意味する「post-mortem」に由来しており、絶対に失敗が許されない場面において絶大な威力を発揮するとされている。 事前検死を行う4ステップ 当然だが、前提として事前検死の目的はプロジェクトを中断ではなく、強化することにある。 ここでいう強化とは、主に目的/目標達成の達成確率を高めることを指す。 0. 失敗を許容する文化形成 これは事前検死を行うた
目標を立てることの大切さは、手を変え品を変え、あらゆる場面で語られてきました。目標をたて、その達成に向けて最大限の努力をすれば、たいていの目標は達成できる。そのような言葉を聞いたことがある人は多いと思います。とはいえ、私たちは日々多くの失敗を経験するもの。そのたびに、失敗はある程度仕方ないことなのではないかという気分にもなりますね。 しかしながら、世の中にはミスが許されない人々も存在します。たとえば、医療関係者や軍の指揮官。彼らは、非常に強いプレッシャーの中で正確な意思決定を下すプロです。たしかに彼らは、ミスをしにくい能力を持っているのかもしれません。その一方で、ミスを防ぐためのノウハウというものも存在するのです。今回の記事では、ミスを確実に防ぎ、成功を導くための方法論を紹介していきます。 失敗から逆算する、「プレモータム・シンキング」という方法 失敗を確実に防止する方法として今回紹介する
プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。 しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。 今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。 プロダクトマネージャー向けフレームワーク4選1. Product Prioritization Frameworkhttps://www.product-frameworks.com/Gusto-Product-Prioritization.htmlこちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。 expected:期待値の大き
こんにちは。株式会社プラハCEOの松原です。 弊社は主にスタートアップの新規事業に特化してデザイン・開発をするものづくり集団です。 最近改めて「プラハでエンジニアとして働く上で最低限必要なスキルって何よ?」という話になったのでリスト化してみました。 ついでにそれらにまつわる知識をうまくまとめてくれている情報源を追記しておくので、何かしらの学習素材として使っていただけると幸いです。 前提 前提として弊社が相手にしているスタートアップや新規事業の開発においては とにかく速く仮説検証し続けること が重要なので、継続的に機能改修しやすい柔らかなソフトウェアを作ることに重点が置かれています。他の事業であれば他のスキルが重視されますし、これらが新規事業の開発において絶対の指針だと言うつもりは全くないので 「あ〜新規事業の開発を主に手掛けているプラハっていう特定の会社(N=1)ではこんなスキルが求められ
Good & New とは Good & New(グッドアンドニュー)とは、3~6名程度のグループに分かれて、24時間以内にあった「良かったこと(Good)」や「新しい発見(New)」を全員で共有し、拍手をするという取り組みです。 組織やチームの活性化、アイスブレイクを目的に、アメリカの教育学者ピーター・クライン氏によって開発されました。 部署をまたいだ信頼関係づくりや、会社全体にポジティブな思考や雰囲気を生み出す効果があり、企業の朝礼に使われるケースが増えてきています。 Good & New という言い方以外にもいくつか呼び名があり、「Happy & New」などがあります。 Good & New のルール・手順ルール ・ランダムに選ばれた10名以下のグループで集まる ・ボールなどを手渡しして渡された人が話す ・基本的には24時間以内にあった「いいこと」や「発見」について話す (※土日な
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった!記事、プレゼン、さらには本(Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが)にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。(正しい指摘である) この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 1つ目の例:not like
こんにちは、One Capital の三好(@saas_penguin)です。 最近ライフハックに関する本を読んだのですが、やはり ”何をするか” と同じくらい ”何をしないか” が重要なんだなあと改めて痛感しました。何かを捨てなければ、何かは得られない。全集中ですね(よくわからない)。 SaaS をはじめとする成長企業だと、どうしてもトップラインだけに目が行きがちですが、コストに関しても同じくらい重要です(赤字がまずいという訳ではなく、適切な範囲での投資ができているかという意味です)。今回はコスト、S&M(セールス&マーケティング費用)について考察していきたいと思います。 SaaS 企業の原価率と販管費率ってどのくらい? 日本に上場する SaaS 企業は22社ありますが、各社の営業費用(原価および販管費)を比較してみました(直近四半期 単独、Wantedly 社は原価を開示していないため
Wantedly のエンジニアには、課題発見からリリース、そして結果分析までの一連の改善ステップを、オーナーシップを持って進めることが期待されます。その中のフロントエンドの実装において、プロダクトデザイナーと上手くコミュニケーションをとって協働することは、改善スピードを上げるためにも、またプロダクトの品質を上げるためにも重要なスキルになります。 本章では、Wantedly のエンジニアとして、プロダクトデザイナーとのコミュニケーションのあり方や、プロダクトをスムーズに開発するために気をつけることを説明します。前半では、一般的にデザイナーと協働するために心得ておくと良いことを、後半では、スムーズに仕事を進めるための心得について、リリースまでの全体像を説明した後、各ステップごとに気をつけるべきことを説明します。 デザイナーと上手く協働するテクニックは色々とあると思います。また、一緒に働く人によ
こんにちは、クックパッドデザイナーの久保坂美咲(@misaaa09)です。 クックパッドでは先日、iOSアプリの起動画面のリニューアルを行いました。 クックパッドの開発は1~2週間ほどで検討・リリースを行うことも多いですが、このプロジェクトは検討からリリースまでに約3ヶ月ほどかかり、関わったメンバーも約20名程と、やや大きめのプロジェクトでした。 今回このプロジェクトで私は、デザイナーとしてだけでなく、はじめてプロダクトマネージャー(以下:PdM)としての役割も担当したので、 本日は、影響範囲が大きく、関わるメンバーも多いプロジェクトを進める上で、PdMとして取り組んで良かった事について紹介します。 なぜ起動画面をリニューアルしたのか今回クックパッドのiOSアプリの起動画面をリニューアルしたのは、以下の2つが大きな目的でした。 1.クックパッドの利用シーンを増やし、アプリの利用頻度を増やす
この記事は 弁護士ドットコム AdventCalendar2021 の10日目の記事です。 昨日は@michimaniさんの「AWS Step Functions を使った翻訳ワークフローを AWS CDK v2 (TypeScript)で構築してみた話」でした。 はじめに弁護士ドットコムの林(@taka_piya)です。 新規事業の「弁護士ドットコム 業務システム」を立ち上げのためにデザイナーとして入社し3年になりました。 入社から今までプロトタイプを作ることにこだわって活動してきましたが、実際の取り組みについて紹介します。 アイデアの価値は誰にもわからないので、時間がかかるサービスはいつも誰かのアイデアからはじまります。 しかし、最初はアイデアを思いついた本人すら「誰の、何を解決しそうのか」はわかっていません。 そこから、メンバーを巻き込むにはアイデアを分析する必要がありますが、ユーザ
本記事は、Engineering Manager Advent Calenderの1日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
かっちゃん(id:katzchang) の記事を読んで思ったことをつらつらと書く。 medium.com 前提 今はオミカレという婚活パーティーのポータルサイトのWebサービスをメインにしている会社でCTOをしている。 CTOといっても会社の人数は15人未満でエンジニアは自分を入れても8名しかいない。 だから厳密なマネージャ職はおらず、CTOと名が付いているけども自分がCode書くなどのプレイヤーの仕事をしながらエンジニアやプロジェクトのマネージメントを兼任してる。 オミカレ party-calendar.net 婚活パーティーやお見合いパーティー、街コン、趣味コンといったイベントのポータルサイト。 自社でイベントなどは行わずに、主催されている方々からの情報提供を受けてサイトに掲載している。 そもそもプレイングマネージャーはアンチパターンでは? これは常日頃から思う。 何をマネージメントす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く