プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
今回は高校生の私たちが公開した投票サイトが三日で１万PVを記録したので、その経緯をサイトの紹介も含め、全て公開します。 qiitaで後日談を書きましたので、よかったらお読みください リンクはこちらです サイトの内容 名前はAICEVOTE(アイスボート) リンクはこちら ----> aicevote.com(大量アクセスで現在サーバーが不安定な状況です。ご了承ください。) このサイトを一言で言うとこんな感じです。 "投票用紙を氷に見立てた次世代のリアルタイム投票サイト" AICEVOTEとは 普通の投票とAICEVOTE（アイスボート）の違い 普通の投票 普通の投票では、投票箱A/Bに最終的に投票された票の数の比で結果が決まります AICEVOTE AICEVOTEでは投票用紙の代わりに氷を投票します。 それぞれの投票箱の底は網目になっています 時間が経てばあなたが投票した氷は少しずつ溶け
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
ここでいうおじさんSEとは、主にSIerに生息する、 ・30歳以上で ・モダンな技術を知らない ・レガシーな技術しか知らない ・主に設計書などのドキュメント類を弄っており、コーディングをしない ・現状から変わる気がない（キャリアアップに対し具体的なアクションがない） 人たちを指す。 決して単に妙齢のエンジニアを一括りにしているわけではない。 「おじさんSE」より良い呼び方があれば、ぜひご提案いただきたい。 第1章 おじさんSEの仕事内容 おじさんSEは、コードを書くことはほぼ無い。 これは現場にもよるので、全く無いというわけではないが、 多くのおじさんSEはコーディングはしない。 ではおじさんSEは何をやっているのかというと、 ・内部設計書、外部設計書、詳細設計書の記述 ・結合試験以降の試験項目票の作成 ・試験結果のレビュー 大抵はこの3つになる。 99.9％はウォーターフォール型である。
世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ
顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み 新PdM組織での顧客解像度の上げ方 植木氏の自己紹介 植木遼太氏：私からは「新PdM組織で実践した顧客解像度の上げ方」というテーマで発表します。簡単に自己紹介をしてから本題に移らせてください。 私は植木遼太と申します。先ほどの紹介にあったように、今現在は「楽楽精算」のPdMをしています。約2年前に入社しています。キャリアとしては2010年に新卒からインフラエンジニアとしてスタートして、その後、プロジェクトマネージャー、プロダクトマネージャーと役割を変遷させていったかたちのキャリアを歩んできました。 顧客解像度向上のための取り組みBefore／After では本題に移ります。先ほどのテーマにあったように、「顧客解像度の向上って」という話があります。発表の流れとしては、「そもそもこの
設計書・仕様書の書き方が分かる！
弊社では開発工程の上流である「要件定義、基本設計、詳細設計」において必要となるドキュメント標準が定義されております。本稿では「ドキュメント標準」の一部をご紹介しますので、是非ご参考にしてください。 各工程で必要なドキュメントを定義しましょう 下記のように工程ごとにドキュメント成果物、内容を定めております。 どの企業でも必要なドキュメント成果物になりますが、必要に応じて追加・削除頂ければと思います。 ※業務系のシステム開発に照準を当てております。 要求分析（要件定義） システム開発は要求分析（要件定義）というプロセスから始まります。要求分析（要件定義）は、顧客の要求を把握してシステム要件を確定することです。主に以下のような事項をまとめます。 要求概要 システムの目的 現状の課題と改善案 基本要件と優先順位 到達目標 システムの実現手段 システム化の範囲 概略費用 効果（定性／定量） 体制図
メルペイでプロダクトマネージャをしてます、さとじゅんです。 メルペイでto B向けプロダクトの開発をしてます。なので、主にto B向けプロダクトについての話になります。 たまに思うこと突然ですがPMは新しい機能を作る時は仕様書を書くことが多いですよね。 PRD（プロダクト要求仕様書）とかですね。 「Why」とか「What」とか「How」とか書きますよね。 それでリリースして運用していくと思うのですが、運用中にいろんな課題をこなしていくうちにひとつの事に気づきます。 「もう少しビジネスとシステムとオペレーションがひとつのつながりで理解できる資料が欲しいな」と。 to C向けのプロダクトに比べ、to B向けのプロダクトにはセールスやオペレーションのチームなど1つのプロダクトに関わる人が多くなる特徴があると思います。 PLGという考え方もあると思いますが、だいたいのto B向けプロダクトがto
デザインドックで学ぶデザインドック | フライウィール
エンジニアの太田です。 皆さん、デザインドックはご存知でしょうか？いわゆる設計書ですが、エンジニアによって書かれ、書いた本人またはチームによって実装される点と、技術的な詳細を明確にし技術的な議論をすることにフォーカスがある点が特徴です。他人に開発を依頼するための設計書や、既存のシステムを解説するための文章とは性質が異なります。 デザインドックを書くことの利点としては以下のような点があります。 開発を始める前に全体のシステムを考察する機会を得る文章化することで、曖昧な部分が明確になる早い段階でチームメイトや専門家、関係者からフィードバックを得る機会を得るシステムの設計について明確な承認を得られる新しいメンバーがシステムの概略を理解する手助けになる弊社でもすでに多くのデザインドックを利用しており、エンジニア間での議論の活発化を担っています。 具体的にどのような内容を書けばいいのでしょうか？今回
意識高い系のいかにも仕事できなそうで職場や案件たらいまわしにされてるの丸わかりの増田とか、使えなさ過ぎて業界から追い出されてシコシコ技術ブログとか書いてるんだろうなっていう元ITエンジニアって肩書のブロガーとか自称業界人の皆様たちのおかげで、絶賛20代30代がいなくなり、40代50代の脳みそ壊れたオッサンオバサンばかりと少子高齢化のあおりを受けまくってるIT業界 そんな彼らが「IT業界がダメになったのは国や社会の責任だ！」と鼻息荒く早口でよく責任転嫁をしているが、彼らに「じゃあ昔のIT業界ってどんな風な仕事の仕方だったの？」っていっても口が裂けても答えてくれないことが多いのは周知の事実だと思う だから、これから運悪く新卒でブラックにあたって職歴に傷がついているからIT業界に仕方がなく来るしかない、という第二新卒の方々や、IT業界に来たいんだ！という奇特な新卒やダ学生の増田向けに、まだ日本が
こんにちは。エムスリーでプロダクトマネージャーとして働いている岩田（@a___iwata）です。 最近、弊社山崎が各所で「ホームランを打つ」ということについて言及しています。 anchor.fm エムスリーでは「ホームラン」と呼べるような事業が多数立ち上がっています。 最近では、後払いによる会計待ち時間ゼロ、使いやすい予約と問診、QRでのチェックインといったスマートな診療を実現するデジスマ診療が例として挙げられます。 digikar-smart.jp ここでは、そんなホームランを打てる人が多数在籍している環境に身を置くことでどんなことが分かったのかを振り返っていこうと思います。 ホームランバッターと同じ環境で働けると何が嬉しいのか？ という問いの答えになれば幸いです。 ホームランを打つ、とは何か "アイデアこそ全て"症 良いプロダクトは、自然に広まる ---- 本当に？ プロダクトのアイデ
ここでいうおじさんSEとは、主にSIerに生息する、 ・30歳以上で ・モダンな技術を知らない ・レガシーな技術しか知らない ・主に設計書などのドキュメント類を弄っており、コーディングをしない ・現状から変わる気がない（キャリアアップに対し具体的なアクションがない） 人たちを指す。 決して単に妙齢のエンジニアを一括りにしているわけではない。 「おじさんSE」より良い呼び方があれば、ぜひご提案いただきたい。 第1章 おじさんSEの仕事内容 おじさんSEは、コードを書くことはほぼ無い。 これは現場にもよるので、全く無いというわけではないが、 多くのおじさんSEはコーディングはしない。 ではおじさんSEは何をやっているのかというと、 ・内部設計書、外部設計書、詳細設計書の記述 ・結合試験以降の試験項目票の作成 ・試験結果のレビュー 大抵はこの3つになる。 99.9％はウォーターフォール型である。
ARR100億円を超えたSmartHRの新CEOが、非公式チームで自らもコードを書き、自社プラットフォーム上でプロダクトを動かし、あわよくば販売しようとしている話 - 宮田昇始のブログ
Nstock CEO / SmartHR 創業者の宮田です。 「SmartHR はもうスタートアップではない」 創業者の私は、ここ1〜2年そう考えていました。 しかし、それは誤りでした。SmartHR は規模こそ大きくなりましたが、そのカルチャーは今もスタートアップそのものでした。いえ、もしかしたら昔よりもスタートアップしているかもしれません。 新 CEO の芹澤さんが3人だけの非公式チームをつくり、自らもコードを書き、社内課題を解決するプロダクトを自社プラットフォーム上で動かしている。 プロダクトはその出来の良さから、社内で自然と流行り、なんなら製品化して顧客に販売することも考えはじめています。 昨日のブログで芹澤さんはあえて「新しい大企業」という言葉を使ってはいましたが、こんなにスタートアップらしいエピソードは、創業期の SmartHR にもあまりなかったような気がします。 今回は、S
こんにちは、はじめまして。先日SmartHRにジョインした@kgsiです。 この記事はいわゆる入社エントリーになります。 プロダクトデザイングループの6人目のメンバー、初のデザインエンジニアとして2020年6月にリモート入社しました。 ジョインしてそろそろ1ヶ月半経ちましたが、今回私からはSmartHRのデザインエンジニアの働き方と役割を探したお話をします。 自己紹介自分のキャリアを鑑みると「開発もできるUIデザイナー」に分類されるのではないかと思っています。 元々出自はグラフィックデザイナーですが、大学時代にWebの世界に魅入られ転身、Webデザイナーから始めてマークアップ業務にも関わり、さらにはエンジニア（主にフロントエンド）を兼任し... そんなこんなで、かれこれ10年以上この界隈をさまよっています。 SmartHR入社前のキャリアとしては、大手サーバー事業会社でサーバーコントロール
2019年10月に、ブレインパッドのサテライトオフィスが目黒の駅ビルにオープンし、チームの本拠地が目黒になりました。 すると、1階にファミリーマートが入っていることからファミマに行く頻度が急増しました。時間が無い時には小腹を満たしたり、コーヒーを買ったりと何かとファミマにお世話になる生活に。 3食すべてをファミマで食べても耐えられるのか？ふと思ったわけです。ファミマにはものすごい種類のサンドイッチ、おむすび（ファミマでは＂おにぎり＂ではない）、お弁当やが並んでいます。全種類を食べたら一体何食分になるのか。 健康に気を使ったお惣菜もたくさんあるし、これは3食をコンビニで過ごしても食生活は成り立つはず。でも、なぜか「コンビニは時間のない時の非常手段」という感覚がこびりついて離れません。 アルゴリズムに献立を考えてもらおうなんてことを考えながらファミマを覗いてみると品数が多すぎて、献立を考えてた
はじめに 前編では、開発プロセス設計のうち、図３の２番目のソフトウェア開発ライフサイクルを決めるところまで説明しました。後編では、ここで決めたライフサイクルに基づいてソフトウェアプロセスを決め、ソフトウェアプロセスの各活動、成果物をテーラリングする考え方について説明します。 また、設計したプロセスの実装及び改善方法、並びに、アジャイル開発において重要なマインドセットの位置づけについても簡単に触れます。 ③ソフトウェアプロセスを決める ソフトウェアプロセスでは、基本的には、以下を決定します。 ソフトウェア開発ライフサイクルの各フェーズで当該フェーズのゴールを達成するために、どのプロセス／活動をどの順番で行うか 各活動についての詳細（誰が行うか、入出力成果物は何か、どのように行うか等） プロジェクトやプロダクトの特性に合わせて開発プロセスを適応させることをテーラリングと呼びます。ソフトウェア開
謎水騒ぎを仕様書と契約の観点から解説【自衛隊】
『陸自練馬駐屯地がニセ科学に騙されかけたと聞いて！』 ＼PR!／ 陸自練馬駐屯地にて、謎水なるニセ科学製品の入札公示と急きょ公示取消しがあったようです。 ニセ科学はともかく、役務調達要求仕様書と契約制度の問題が結構あるなあ・・・ 図１ 謎水？ 引用URL:https://www.irasutoya.com/2019/03/blog-post_927.html 似たようなものは私の現職時代も結構持ち込まれたりしています。 まあ大抵指揮官クラスが、トップダウンで持ち込むんですよね～！ （前回記事）：『KN-23がウクライナで使われるとは！【世界情勢】』 ＼こちらもご参考に！PR／ （１）謎水入札公告と公示取り消しまで 2024年1月22日に、有志の手で練馬駐屯地の地方調達にて謎水の入札公告が発見されました。 図２ Twitter 引用URL:https://twitter.com/konami
なぜSaaS組織に分断が起きるのか？「PLG Loop」で打破するセクショナリズムの壁｜kota_sasaki@SmartHR
SmartHR PMMの佐々木です（@kosasaki7） 昨年末、PMMの交流を目的とした「PMM Night」を初開催し、100名を超える方々にご来場いただきました。 本記事では、当日話せなかった内容や会場の質問に対するアンサー記事として、PdM×PMMの協業モデルと各領域の取り組みをまとめてみました。 SaaS組織間の連携を考える上で、ご参考いただけますと幸いです。 イベントの内容は、@CAREER_HACK さんに全3本で特集していただいた、「PMM」ってなに？ をご参照ください。 なぜSaaS組織にセクショナリズムが生まれるのか？セクショナリズムとは、集団・組織内部の各部署が互いに協力し合うことなく、自分たちが保持する権限や利害にこだわり、外部からの干渉を排除しようとする排他的傾向のことをいう。官僚制における逆機能の一つとして指摘されたもので、組織内部の専門性を追求しすぎた結果起
イチから全部作ってみよう（9）ジャンケンで理解する要求仕様書作成の難しさ：山浦恒央の“くみこみ”な話（178）（1/3 ページ） ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第9回は、「ヒアリング」した内容をまとめる「要求仕様書作成」について、情報工学専攻の大学3年生でも悩む「ジャンケンの要求仕様書」を例にその難しさを解説します。
プロダクトマーケティングマネージャー（PMM）について、プロダクトマネージャー（PdM）との違いについて聞かれることがしばしばあります。 この記事では、PMMの役割について、PdMとの役割分担に着目して説明をしてみたいと思います。 その上で、PdMとして活躍されている皆さまが、新しいキャリアとしてPMMを検討していただける一助になりましたら幸いです。 はじめに筆者は現在SmartHRという会社でPMMをしています。前職はtoCの企業でPdMだったため、PdMバックグラウンドの人間から見たPMM、という観点でこの記事を執筆しています。 そもそもPMMとは？PMMとは、プロダクトをマーケットに投入するにあたって必要となるプロセス全体を指揮するとされています。 たとえば、新規顧客に対しては、マーケティングチームやセールスチームと協働してプロダクトのメッセージをつくり、発信・販売していく。 また既
はじめまして。 SmartHR プロダクトマーケティングマネージャー（PMM）のshigeです。 PMMという職種に聞き馴染みのない方も多いかと思います。興味のある方はぜひ、先日SmartHR代表の宮田が書いたブログをご覧ください。PMMのポジションができた経緯がわかります。 私は、2019年9月にSmartHRにPMMとしてジョインしました。 入社から2ヶ月たち、会社やPMMというポジションについての理解も深まってきたところで、SmartHRにおけるPMMの役割をブログを書こうと思い立ったのですが、情報発信のための適切な媒体がなかったため、今回noteでマガジンを新設しました。 これからSmartHRのPMMだけではなく、PM、カスタマーサクセス、セールス、マーケティングなど、各グループからの情報を発信していければと思っています。 自己紹介まずは簡単に私の紹介をさせてください。 9月に入
はじめまして。ReproのProduct Planning Team というチームのマネージャーをしている正木と申します。元々はReproのユーザーでしたが、なんやかんやあってReproに入社しCSを経て現在はPMMを担当しています。 今後、Product Planning Teamからはこれまであまり発信してこなかったReproというプロダクトの企画のお話や、デザインの話、作った機能のGo To Marketの話などをしていこうと思っていますので、よろしくお願いします。 今回は初めての投稿ということもあり、そもそもReproのプロダクト企画チームって何をやってるの？という話をしようと思います。 プロダクトの企画に関わる方（主にPdMやPMMなど）の組織作りや、今後関わりたい方の何かの参考になれば幸いです。 Reproのプロダクト企画 Reproではプロダクト企画チームが2022年から開発
今回は、要求仕様フェーズを進める時の問題点を解説します。ソフトウェア開発の全ての悪は、要求仕様書から生まれます。「パンドラの箱」のようなものですが、ちゃんと「希望」も残っています。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2．要求仕様フェーズでは何をするのか 図1に、新しいソフトウェアのアイデアを思い付き、それを製品化するまでの流れを示します。 2.1 要求仕様フェーズ ソフトウェア開発の最初の工程が「要求仕様フェーズ」で、頭の中のアイデアを具体的に記述する工程です。製品にできることや機能を細かく書いた要求仕様書を作ります。「要求仕様書」と聞くと、「大統領所信表明書」のように物々しく感じますが、電気製品を買うと付いてくる「製品取扱説明書」と完全に同じものです。 取扱説明書は、一般ユーザー向けのドキュメントで、そこには「（1）以下の部品がそろっていることを確認してください……、（
楽楽精算PdMの業務内容を紹介します - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに 昨今 書籍や各社Blog記事などでプロダクトマネージャー(以下PdM)の業務内容について記載された媒体が多数でている状況です。 ですが、複数の媒体を参照された方は、こう思われることが多いと考えております。 「見るものによって役割、業務内容違くないか？」 実際、企業・プロダクト・チームといった単位で、PdMの業務内容は変わっていると私も考えております。 弊社ラクスにも、以下のようにさまざまなプロダクトがございますが、各プロダクトによってPdMの業務内容は異なっています。 その中でも今回は、「楽楽精算」のPdM業務内容をご紹介します。 スコープ はじめに プロダクト体制 楽楽精算のPdM業務内容 事業KPI貢献に沿った優先順位 PRD(要求仕様書)作成 今後の展望 ラクスのPdMとして活躍してみませんか? プロダクト体制 さっそくPdMの業務内容を説明したいところですが、 まずは楽楽
小城久美子が勧める、事業サイドからプロダクトマネージャーになる人向けのPM本5選 2024年6月12日 プロダクトマネージャー 小城 久美子 プロダクトづくりの知見の体系化を試みるプロダクトマネージャー。書籍『プロダクトマネジメントのすべて』共著者であり、日本最大級のプロダクトづくりコミュニティ「プロダクト筋トレ」の主催者。 経歴は、ソフトウェアエンジニア、スクラムマスターなどの開発職を経験後、プロダクトマネージャーに転身し、現在は現場でのプロダクトマネジメントの傍ら、プロダクト戦略の構築や仮説検証の伴走を実施している。 1. 『アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット』森一樹 著 2. 『アジャイルサムライ ー達人開発者への道』Jonathan Rasmusson 著、近藤修平・角掛拓未 訳、西村直人・角谷信太郎 監訳 3. 『プロ
Design Docの書き方
背景、目的 (Why?) 検討した別の方法 (alternatives considered) トレードオフ (Why not?: なぜ別の方法にしなかったのか？) 設計、アーキテクチャ (How?) メンバー (担当者やレビュワー) (Who?) セキュリティやプライバシーについての考察など 他プロジェクトとの関連性 テスト，モニタプランなど 基本的には、ソースコードを見てもわからない部分をDesign Docに書いて、議論するのが一般的のようです。 Design Docは、Googleに代表される最先端の技術企業で取り入れられている設計ドキュメントのスタイル。 単にドキュメントの書式だけを指すのではなく、書いた後の使い方までを含めた『開発のやり方』につながっているドキュメント方式。 アジャイルなどの現代的なソフトウェア開発スタイルにフィットしているため、シリコンバレーのスタートアップ企
SmartHR社のPMMチーム 昨今のカスタマーサクセスの盛り上がりがすごいですね。毎日のように何かしらの記事や、イベントを目にします。 これは持論なのですが、いまカスタマーサクセスで起こっているような盛り上がりが、2〜3年後くらいに「PMM（プロダクト・マーケティング・マネージャー）」でも起こると思っています。 4年前のカスタマーサクセス いまから4年前の2015年11月、SmartHRを公開した当初、日本には「カスタマーサクセス」という言葉はほぼ存在していませんでした。 当時からSmartHRの株主だった前田ヒロから「SaaSはカスタマーサクセスが重要。カスタマーサクセスができる人を早めに採用しよう」と言われました。 言葉もはじめて聞いたし、Googleで「カスタマーサクセス」と検索しても日本語のブログや記事は見当たらず、かろうじてSalesforceさんの求人ページが引っかかるくらい
オブジェクトモデリング入門編！SmartHRでOOUIワークショップを開催しました｜Goodpatch Blog グッドパッチブログ
先日、GoodpatchはSmartHRさんのオフィスでワークショップを開催しました！ OOUIの基礎知識をインプットできる座学、オブジェクトモデリングワークショップをUIデザイナー、PMの皆さんに体験していただきました。本記事では開催の背景から当日の様子をご紹介します。 今回ワークショップを実施したSmartHRさんが提供するクラウド人事労務ソフト「SmartHR」のUIデザインは、2018年9月まで1人のデザイナーによって作られていました。デザイナーやプロダクトの機能が増えるにつれて、様々な課題が出てきたそうです。その一つとしてUIデザイナー佐々木さんのnoteにはこのように綴られています。 現在のSmartHRでは情報の見せ方がタスクベースであることに引っ張られてしまったことで、同じオブジェクトであるはずのものが画面によって名称が別のものになってしまったり、正しく定義できていないなど
イチから全部作ってみよう（1）ソフトウェア開発の大まかな流れを把握する：山浦恒央の“くみこみ”な話（170）（1/3 ページ） ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第1回は、イントロダクションとしてソフトウェア開発の大まかな流れを説明する。 1．はじめに 前回まで、16回にわたり「業務効率化の道具箱」と題して、業務効率化に関するトピックを取り上げました。少しでも皆さんの業務改善の役に立っていれば幸いです。 今回からは新シリーズ「イチから全部作ってみよう」が始まります。筆者が実際に関わってきたECサイトを題材として、入門者向けに、企画の立案、要求仕様書の作成、設計、コーディング、デバッグ、テスト、保守（新機能の追加を含む）まで、プログラマーとしてソフトウェア開発の全工程を学びながら、実際に体験もできるようにします。 さらに
「【SmartHR/カケハシ/リクルート】複雑化する開発体制におけるエンジニアの社内巻き込み術 ‐プロダクト成長をリードするエンジニアたちの試行錯誤‐」は、成長プロダクトの開発をリードするエンジニアたちの試行錯誤に触れ、社内巻き込み術や改善のステップなどのノウハウを紹介するイベントです。ここで株式会社SmartHRの大谷氏が登壇。チーム人数の増加によって生まれた課題と、その課題にどう対処したかを紹介します。 みなさんはこういった経験をしたことがありますか？ 大谷洋生氏：では僕の発表を始めようかなと思います。「エンジニア主導の仕様検討：はじめの一歩を踏み出す」というタイトルで、話をさせていただきたいと思います。よろしくお願いします。 まず自己紹介ですね。SmartHRから来ました。エンジニアをしています。大谷と言います。ふだんはRailsを書いたりReactを書いたり、あとはFlutterを
開発優先順位とかロードマップの作成どうしてる？ 急成長プロダクトのPdMが語るケーススタディ - TECH PLAY Magazine
急成長しているSaaSプロダクトでは、ユーザー拡大による既存プロダクトの機能拡大や新機能の開発など、様々なタスクが日々生じている。そこで、急拡大中のSaaSを開発するLayerX、Ubie、Chatwork、オープンエイトの4社に、意思決定のプロセスやロードマップ作成のポイント、PdMとして意識していることを語り合ってもらった。 登壇者プロフィール 株式会社LayerX 花村 直親氏 2020年6月LayerXに入社、バクラク請求書のプロダクトマネージャー兼エンジニアを担当。WEB開発・コンサル・データ分析などで一貫してB2Bに携わってきた経験を活かしてSaaS立ち上げに注力。B2Bの世界でコードを書くことがもっと重要と思われるように日々努力している。 Ubie株式会社 松村 直樹氏 2019年10月にUbie株式会社に入社。事業開発メンバーとして、病院向けカスタマーサクセスの立ち上げ等を
大規模スクラムで見えてきたマルチPdM体制の面白さと難しさ【SmartHRのPdM連載第1弾】 - SmartHR Tech Blog
はじめに みなさん、こんにちは！SmartHRでプロダクトマネージャー（PdM）をしています岸（@kissy）です。 SmartHRでは2020年1月から大規模スクラムのフレームワークであるLarge-Scale Scrum（LeSS）を採用しており、 現在、LeSSに属するスクラムチームは4チーム、PdMは私を含めて総勢4名（10月から5人に増えました！）という体制で開発をしています。 そこで本記事では、「大規模スクラムで見えてきたマルチPdM体制の面白さと難しさ」についてお話し、 SmartHRのPdMは日々どんなことを考え、どのようなことをやっているのかをお伝えできればと思います。 「SmartHRのPdM」連載については 「SmartHRのPdM」連載をはじめます をご覧ください。 tech.smarthr.jp 現状の SmartHR の開発体制について SmartHRはプラット
commmuneの｢プロダクト開発サイクルの今｣を公開します! - Commune Engineer Blog
はじめに こんにちは、コミューンでプロダクトマネージャー(PdM)を担当している東です。 今回は、コミューンにおけるプロダクト開発サイクルについて、概要をまとめて公開してみたいと思います。 コミューンについて少しでも興味を持ってくださっている方や、他社事例を見てみたい方などにご覧いただけると幸いです。 commmuneについて 弊社は、｢企業とユーザーが融け合う社会を実現する｣をビジョンとして掲げ、現在｢commmune｣と｢SuccessHub｣の大きく2プロダクトを提供しています。 ｢commmune｣は、オンラインコミュニティプラットフォームをノーコードで作成できる、いわゆるBtoBSaaSです。SaaS形式でツールをご提供しつつ、カスタマーサクセス(CS)がコミュニティの戦略策定･実行支援を丁寧に行い、コミュニティの成功に向けて伴走しています。toB･toC問わず、スタートアップか
自分もデザインドキュメントを始めようと思ったので、デザインドキュメントとは何かを知るために情報収集した結果と簡単な自分の考えのまとめ。 デザインドキュメント概要 [2007-06-01] Software Engineer in Google - Google Developer Day Tokyo 2007 Googleのソフトウェアエンジニアがどのように開発しているのかという発表で、プロダクト開発の流れの中でデザインドキュメントを利用していることが説明されている Why(背景や目的)、How(おおまかな設計、コードを見てわかることは書かない)、Who(メンバ、誰にコンタクトすればそのプロダクトについて知れるか)、セキュリティやプライバシーに関する考慮、テストやモニタリングをコーディング前に記述する。開発を進める中でできるだけ乖離しないように修正する。 この発表内容に関する聴講者のメモ:
【俺流】仕様書の書き方（要求仕様～客先稟議用資料）
先日、知人に「仕様書ってどうやって書けばいいの？」と聞かれたので、私がサラリーマン時代に書いていた仕様書関連資料についての書き方をシェアします。 組織や人によって仕様書の書き方は千差万別なので、参考程度に読んで頂けると嬉しいです。 最初に私の作っていた書類の名称と役割を簡単に説明しておきます。 （プロジェクトによって作らなかったり内容が変わったりする資料もあります） 【要求仕様書】 クライアントへヒアリングを行い、最初に作成する資料です。 「そもそもどんな話だったんだっけ？」というような時に見直す資料となります。 【要件定義書】 要求仕様書の内容を基に、必要な機能を洗い出し、納期や費用や納品方法等の細かい内容を記述した資料です。 この後の資料作成のベースとなる資料で、ここがあいまいだと高確率で炎上します。 【 客先稟議用資料 】 クライアント側での稟議を通すために、極力シンプルに情報を絞っ
オフショア開発、すっかりメジャーになってきましたね。 ベトナムは日本からのオフショア開発で熱い日々が続いてます。（ちなみに、ベトナムは位置的に熱帯だから、そもそも暑いんですけどね！）毎日暑いか、すごく暑いしかないホーチミン、雨期は40度近いです。 さて、オフショア開発はいろいろなメリットやいい話を聞く反面、問題点もたくさん話題になりますよね。よくあるのが「外国籍SEと考えがあわない」とか「想像より品質が低い」とか。 確かに日本人の考えをそのまま海外に適用すると、「えー！！思ってたんと違う！！」になりがちです。日本でならなんとなくうまく行っている気がすることも、意思疎通が取れずにグダグダに業務が滞って遅延してしまうこともしばしば。 相手を思いやって「忖度」して、積極的に「空気を読む」のは日本人のいい面であり、同時によくない面でもあることが浮き彫りになるのがオフショア開発の一面なんです。では「
「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、west-cです。 業務にて要件定義を行う機会があり、その成果物である要求仕様書の書き方を学ぶために『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術』という書籍を読みました。今回はその内容をご紹介します。 【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？ 作者:清水 吉男技術評論社Amazon ◆ 関連ブログ 仕様書 とは 【まとめ】 おすすめの読者層 要求仕様書の目的・ゴールが曖昧な方 自身が作成した仕様書において、仕様漏れや仕様の衝突が後工程で発生したことがある or 発生しないか不安を抱えている方 依頼者から要求を引き出す方法の糸口を掴みたい方 要求仕様書とは 書籍では、要求仕様書を「要求について、関係者がその内容について認識を特定できている文章」と定義しています。 要求（今回の機能で実現したいこと）は曖昧なものを含
3つのパネルテーマ 向井毅男氏（以下、向井）：では、さっそく本編に入っていきたいと思います。あらためて、本日はMoTとカウシェでプロダクトマネージャーを務めている総勢4名の方から、それぞれ3つずつアンチパターン、失敗談を共有してもらいながら、いろいろな知見とかをみなさまに共有できればと思っています。 （スライドを示して）本日のパネルテーマは大きく3つあります。1個目、2個目がアンチパターンを理解する上でのいろいろな部分の背景を、みなさまに共有しながら触れていきたいと思っています。主に3個目です。ここがたぶん一番盛り上がると思います。ここに触れていきたいと思っています。 カウシェの軌跡 向井：まずは1個目のパネルテーマです。共に順調に成長をしているサービスですが、これまでいろいろな歴史があったので、そこの部分をみなさんに共有してもらえればと思っています。じゃあ、まずカウシェからお願いします。
『ようこそ不確実な世界へ』DeNA新卒エンジニア研修の設計方針 | BLOG - DeNA Engineering
こんにちは CTO室の kocchi です。 今年も4月から新卒入社したエンジニアの皆さんに向けて研修を実施しています。 本記事は、 4月から働き始めたエンジニアの皆さん DeNAのエンジニア研修に少しでも興味を持っていただいている方 に向けて、エンジニアの学習について何が重要だと考えているのか、それをもとにどう研修設計をしているのかをお伝えします。すこしでも今後の活動にお役に立てれば嬉しい限りです。 はじめに 本記事を執筆時点で、22卒の新卒エンジニアの皆さんは研修中です。例年は、研修後にレポートという形で記事を出しています。（ こちら も興味があれば是非ご覧ください） 本記事は設計についてフォーカスし、結果どうだったのかはまた後日お伝えいたします。 研修のゴールイメージ エンジニアとして学ぶことは無限にあり、今後も変化し続けます。一回学んで終わりではなく、常に学び続ける必要があります。
第2次世界大戦直前、ドイツは前線で用いる偵察機を欲しました。その要求に対する答えは、なんと従来の航空機の概念を根本からひっくり返す奇抜なものでした。性能的には優れていたものの採用されなかった理由を追います。 役所の要求通りに作ったらこうなった 第2次世界大戦中、ドイツは様々な航空機を開発し、実戦投入しました。広く知られるものとしては、世界で最も多く生産された戦闘機であるBf109や、世界初のジェット戦闘機Me262、世界初のロケット戦闘機であるMe163などです。 それらとは別に、ドイツには「異形の単発機」と呼ばれるBV141という偵察機があります。どこが異形なのかというと、コクピットが胴体にありませんでした。 拡大画像 BV141偵察機の俯瞰写真。右主翼にゴンドラ状に付いているのが乗員室（画像：ドイツ連邦公文書館）。 そもそも、航空機を思い描こうとすると、コクピットを含む乗員室が機体中央
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高校生がリアルタイム投票サイトを公開したらいきなり1万PVを記録した話 - Qiita
SIerに生息する「おじさんSE」の生態を知る - Qiita
サブスクリプション課金システム開発ケーススタディ - inSmartBank
顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み
PMによる仕様書では補えない運用フェーズに強いドキュメント作り｜さとじゅん
終わり切ったIT業界の今と昔の仕事の仕方の違い～SIからweb系まで～
ホームランバッターと同じ環境で働けると何が嬉しいのか？ - "アイデアこそ全て"症 - エムスリーテックブログ
SIerに生息する「おじさんSE」の生態を知る - Qiita
入社したら仕事がなかった！？SmartHRにおけるデザインエンジニアの役割と働き方｜こぎそ
食生活をアルゴリズムにゆだねてみる 〜コンビニで健康的な食生活は送れるのか？｜せきぐちともひろ
アジャイル開発プロセスの本質（後編） 〜ソフトウェア・エンジニアリングの基本から理解を深める〜
イチから全部作ってみよう（9）ジャンケンで理解する要求仕様書作成の難しさ
プロダクトマネージャーの次のキャリアとしてのプロダクトマーケティングマネージャー｜shige
なぜSaaSにプロダクトマーケティングマネージャー（PMM）が必要なのか？｜shige
Reproにおけるプロダクト企画を担うチームとは？ - Repro Tech Blog
イチから全部作ってみよう（3）MINORIに学べ、全ての悪は要求仕様書から生まれる
小城久美子が勧める、事業サイドからプロダクトマネージャーになる人向けのPM本5選
SaaS業界で「PMM」は次の「カスタマーサクセス」になると思う - 宮田昇始のブログ
イチから全部作ってみよう（1）ソフトウェア開発の大まかな流れを把握する
「仕様検討のボトルネック化」「技術的な手戻り」にどう対処する？ ポジティブな変化とうれしい誤算を生み出した、はじめの1歩
デザインドキュメントを知るための参考リンク集 - Qiita
オフショア開発は効率が悪い？現地でテストしちゃえば解決ですよ！ | SHIFT ASIA Works
各社で微妙に異なる「MVPの定義」の捉え方 MoT・カウシェの「toB・toCプロダクト」が位置付けるMVP
異形すぎて不採用 ドイツ偵察機「BV141」 要望どおり作ってなぜそうなった？ | 乗りものニュース