これまでの連載では、プロジェクトの本質、構成する要素、プロジェクト化する技術といった、プロジェクトマネジメントの基礎の基礎を解説してきました。 今回のエントリでは、プロジェクトの基本的な流れを説明することで、一般的なプロジェクトがどのように始まってどのように完了するのかといった部分を理解していただければと思います。 プロジェクトの流れプロジェクトは大きく下記の流れで進めます。 プロジェクトの準備 キックオフ 戦略の確定 アクションの確定 タスクへの落とし込み 日々の管理 節目ごとの管理 完了 それぞれにつき説明してきます。 プロジェクトの準備ここでは主に、プロジェクトの4要素のうち「目的・現在地」を明確にし、ドキュメント化していきます。これらの情報には、誰が読んでも疑問が出ない程度の明確性が求められます。 また、インセプションデッキやコンセプトシートなどのフレームワークを使うことで、これら

昨日、参院選が終わった。この選挙によって、もしかしたら日本や世界がちょっとでも良くなるのかもしれない。 だけれども、ビジネスの世界では私たちは見捨てられたままだし、それはこれからも変わらないだろう。 企業の多くは「世界をより良くしたい」と公言し、事業を行なっている。 とはいえ、事業を行うにあたって一番大切なことは「お金を稼ぐこと」だ。そのために必要なことは「お金を払ってくれる顧客」を手に入れることだ。この当然の前提をもとに、多くの企業は「よりお金払いが良い顧客」を常に探し続けている。 例えばBtoB サービス業界においてはその傾向が顕著で、各企業が「よりお金払いが良い顧客」を求め続けた結果、いつの間にか大企業相手のサービスばかりになってしまった。 このこと自体は経済合理性から考えるととても正しく、その結果として売上が伸びている企業も多く、株主価値の最大化を考えるのであれば当然の帰結であるし

先日、ここ一年半ほどかけて開発してきた「個人事業主向けクラウド会計ソフト Shiwake」をリリースしました。 会計ソフトという大きな何かを個人開発するというのはなかなか大変だったのですが、そんな会計ソフトの開発を行う中で考えてきたことを書いていきたいと思います。 [こんな人に向けて書いています] - プロダクト作りにおける「コンセプト」や「進め方」に興味がある人 - ソフトウェア開発における「プロジェクトマネジメント」に興味がある人 最初の課題感をブラさないプロダクトをつくるにあたっては、なにかひとつ「軸」となる考え方があることが望ましいです。多くの場合、それは「プロダクトにおける課題感」となります。 Shiwake の場合、下記のような課題感を最初に定義し、機能を考える際は常に頭の片隅に置きながら開発を行っていました。 freee さん、ごめんなさい。freee に課金したくなくてサー

いろいろな企業を支援している中で、事業全体の戦略がどうこうというよりも、「プロジェクトマネジメントが出来ていないがゆえに上手くいっていない」という例を数多く見かけています。 他方、「プロジェクトマネジメント」という言葉は多義にわたり、その本質部分を把握できている人は多くありません。PMBOKも知らなければ、ガントチャートを書くことがプロジェクトマネジメントだと勘違いしている人もたくさんいます。 そこでこのエントリでは、プロジェクトマネジメントの本質部分について簡単に書いていこうと思います。 [補足] プロジェクトマネジメントの誤解 プロジェクトマネジメントについて調べていると、「プロジェクトをどのように進めれば成功するのか、詳しく計画を立て、管理していくこと」といった定義が散見されます。 これはこれで正しいのですが、なぜプロジェクトマネジメントが必要なのかという点について一切答えておらず、

Twitterで煽られたので、隠居済み無職にも関わらずタイミーさんになってみました。このエントリはその記録と感想です。 [中の人について] 昔は大企業とかスタートアップとかでプロダクトマネージャーとか事業開発とか色々やってた人。働く理由が特になくなったので、ほぼ隠居しながらたまに人のお手伝いをして細々と生計を立てています。都内の話です。 経緯よく行く飲食店でも「タイミーさん」を見かけることも増えてきたので一回くらいやってみたいと思いつつ、知らない人に会ったり知らない職場で働くことのストレスから避けていたところ、Twitterで知人に煽られたのでその勢いでタイミーに登録し、即日働きに出かけたのでした。 タイミーでしたことないバイトしてみたい気持ちと、それによるメンタルの消耗で三日くらい死ぬ気持ちで、大体後者が勝つ — きゅーい🥳 (@library_fit) November 19, 20

最近のスタートアップのプロダクトを見ていると、エンタープライズ向け（大企業向け）のプロダクトがとても増えたように思う。それ自体はビジネスを考えると当然のことで、儲かる領域で事業を展開したというだけである。 事業の目的は究極的には儲けることであり、そのためには儲かるための市場選択が必須であり、としたときに現状の日本ではエンタープライズ向けが最右翼にあがる。課題解決がしたくとも儲からなければ持続可能性はないし、それを考えるならば致し方がない選択だともいえる。 とはいえ過去におけるスタートアップがテーマとしていたものの多くはエンタープライズ向けではなかった。古くはホンダや松下、近年でもメルカリやラクスルといったように、どちらかといえばコンシューマー向けの課題解決としての起業が中心を占めていた。 その風向きが最近は大きく変わったように感じている。コンシューマー向けのものよりもエンタープライズ向けの

プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり

チームマネジメントが苦手だという人と話すと、チームマネジメントの本質を間違って捉えているなと感じることが多い。このエントリでは私の考えるチームマネジメントのキモの部分を書く。 なぜチームで知的労働を行うのかチームで知的労働を行う理由を問うと、1 + 1 = 2 ではなく、人と人の化学反応を起こして 1 + 1 = ∞ にする、、、といった漫画の世界の話をする人もいるし、人材の適正配置を実現すればよりよいアウトプットが出るという人もいる。それらが完全に間違いだとは思わないが、ズレているなと思う。 チームで知的労働を行う理由はただ一つで、「考える頭の数を増やす」というだけである。 つまり、三人寄れば文殊の知恵を実現することが知的労働におけるチームの存在意義だと私は考えているが、何故かそれとは程遠いチームマネジメントをする人が多い。 そうなってしまう原因と思われることをここからは書いていく。 人

データ分析という言葉に身構えてしまう人は多いのですが、実際はそんなに怖いものではありません。一般的な業務内であれば専門的な知識が必要とされるケースは少ないですし、四則演算が出来れば大体対処できます。 このエントリでは、データ分析に苦手意識がある人やデータ分析の初心者の方に向けて、データ分析の基礎となる部分を解説します。 ※ このエントリは若手ビジネスパーソン向けに行ったデータ分析の講義をもとに書かれています [対象読者] - データ分析に苦手意識が強い人 - データ分析のタスクを依頼されたが、何をやればいいかわからない人 - スキルアップしたい若手ビジネスパーソン - 数学が嫌いすぎてデータを見ることすら嫌な人 [得られること] - データ分析の基本的な考え方 - 簡単なデータ分析の手法 データ分析が難しいと感じてしまうワケデータ分析というと、複雑なデータを難しい数式をこねくり回してさらに

[ これはなに ] 個人開発でWebサービスを作るときに、その作り手が何を考えているのかをまとめたものです。本職はPMの時代があった、現無職が書いています。 こんにちは。私はたまにひとりでWebサービスを作っているのですが、そのときに何を考えているのかについて聞かれることが多かったので、そんなことを簡単にまとめてみることにしました。 個人開発とチーム開発では考える観点が少し違うのですが、その違いも楽しみながら読んでいただけると嬉しいです。 今回作ったサービスはこちらです。このエントリではこのサービスを題材に、サービスを作るときに作り手（ひとり）が何を考えているのかを書いていきます。 ちなみにこのサービスは、検討開始〜実装やデータ生成〜リリースまでの流れを大体3週間くらいで終わらせています。 作りたいことが降りてくる私が何かのサービスを作るときは、特にこれといった理由がないことが多いです。な

最近のスタートアップの多くは「スモールビジネス」を行っているように思えている。なぜそう感じるようになったのか、その違和感の原因が言語化できたので簡単に文章にまとめることにした。 仮説検証の粒度仕事や事業を進める中で「仮説検証」という言葉がよく出てくるが、この仮説検証は大きく3つに分かれる。 ビジネスモデルの仮説検証たとえば広告モデルやサブスクリプションモデルなど、いわゆるビジネスモデルの仮説検証を指す。 インターネットビジネスの黎明期には新しいビジネスモデルが次々に開発されていたが、2023年現在においては新しいビジネスモデルはほぼ生まれておらず、もはやビジネスモデルは完全に出尽くしたといえる。 つまり、ここの仮説検証をする必要性は全くなくなってしまった。 ※ もちろん、世の中の大きなパラダイムシフトが起これば別だが、インターネットの普及以降はそれが特に起こっていない。 ニーズの仮説検証そ

採用手法や働き方の多様化など人事に求められる能力やスキルは高くなっています。取り巻く環境が劇的に変化している採用や人事のしごとについて考えていきます。

先日、知人とお話している中で「言語化力を高めるにはどうしたらよいか」という話題になりました。 私はなぜだか言語化力が高い人だと思われていたらしく、その場でいくつかのソリューションを提案してみました。そのウケがわりとよく、これらは万人にとって使える情報なのではという気持ちになったため、ひとつのエントリとして書き出すことにしました。 1. 疑問に感じたことを言語化する

仕事さがしをしていると「カルチャーマッチ」という単語にしばしば出会う。とはいえ、この言葉の意味が私にはよくわからない。 そもそも、カルチャーマッチというからには、 ・組織というものにカルチャーが存在し ・そのカルチャーが新しく組織に入る人とマッチする という二つの前提を持つこととなる。 とはいえこの二つの前提そのものが間違っていると感じている。 カルチャーはそもそも定義できないカルチャーマッチというからには、マッチする対象であるカルチャーがなんらかの形で定義されている必要がある。しかし、組織というものは人の集まりに過ぎず、新しい人が入れば組織の形は変わるし、そもそもとしてそこに所属する人の状態は日々変わっていくものである。としたときに、カルチャーは流動的なものであり、明確な定義を行うことは難しいといえる。（もちろん、スナップショット的にその一瞬を切り取れば定義可能ではあるが） また、マッチ

こちらのエントリを読んでいたら、なるほどとてもわかるとなった。そしてこの問題については何らかの解を持っておくべきだと思ったため、ちゃんと考えることにしたのがこのエントリの趣旨である。 上述のエントリには、ソフトウェア開発者がスケジュールのコミットメントを求められた場合、精緻にスケジューリングするためのタスクやスケジュールに余裕を持たせるためのバッファを積むしかなくなり、結果としてソフトウェア開発が遅くなってしまうという話が書かれている。 ソフトウェア開発を実際に行ったことがある人であればこの話には凡そ同意できるとは思うが、それ以外の人には理解に苦しむ話となる。 それゆえに、現代においても「この機能はいつまでにリリースするの？出来なかったらどうするの？」といった質問が横行し、それに対して特に意味のないスケジュールを答えるという虚無の応答が多くのチームでいまも行われている。 ビジネスサイドの仕

仕事さがしをする流れになってしまったため、いろいろな会社の紹介資料等々を読む機会が増えた。すごく昔に（10年くらい前）に転職活動をしたときは、MVV（ミッション・ビジョン・バリュー）の記載がある会社紹介資料などほとんど存在せず（というよりも、会社紹介資料自体が殆どなかった）、事業内容等々が記載されていただけの記憶がある。 MVVが流行り出したのは2015年前後だったと認識しており、いつのまにか多くのスタートアップではMVVが掲げられるようになっていた。 とはいえ、M（ミッション）とV（ビジョン）というほぼ同じ内容のものが二つに分かれていることが意味不明だったり（ミッションベースのビジョンとビジョンベースのミッションがあるらしく、これも意味不明）、バリューというものの存在が個人的には本当によくわからないのであった。 （お気持ち） 個人的な意見をいえばMVV自体が不要だと思っていて、会社の存在

Trelloだったりバックログだったりを利用して、いわゆる「チケット（カード）」の形式でチームのタスクを管理することは多いと思います。 とはいえ、最低限のお作法すら守れていないがゆえに、チケット管理が上手く機能していないチームに多々出会いますし、自チームも放っておくと結構辛いことになりがちです。 このエントリでは、10年くらいPMをやってきた中で、PMだけでなくチケット管理に関わるすべての人に守って欲しい最低限のルールを書いていきます。 ※ なお、普段はTrelloを使っているのでチケットではなく「カード」という言葉で書かれていますが、適宜読み替えて下さい 適当なタイトルをつけない これとか、最低なカードですね。 「OGP」とだけ書かれていたら、「書いた時」はそれが何を意味するかわかったとしても、翌日見たときには何のことかサッパリわかりません。 そもそも、なぜチケットでタスクを管理するかと

bosyuというサービスにプロダクトマネージャーとして関わってきたが、紆余曲折あってサービスをクローズすることとなった。 記憶がまだ残っているうちに、どのような関わりをして、その上で何を学んだかを簡単に残しておくことにした。 関わった経緯bosyuはもともとBasecampの坪田さんが作られたサービスで、それを株式会社キャスターが事業譲受したものだ。その当時の私はフリーランスとしてキャスター社に関わっていて、日程調整ツールのbiskettを作ったり、採用代行サービスのCASTER BIZ recruitingのお手伝いなんかをしていた。 bosyuが事業譲渡された時点でもキャスター社に関わっていたこともあり、bosyuについて雑に相談を受けたり、bosyuに関わることになるエンジニアメンバーの面接なんかをしたりしていた。（当時、キャスター社にはほぼエンジニアがいなかったため、代わりに面接等

が、今年はほぼノンストレスで確定申告を終わらせることができたことを、主にfreeeの皆様へ向けての感謝を込めて書いておく。 【前提】 ・Macを利用している ・ICチップが読み取れるiPhoneを持っている ・会計ソフトとしてfreeeを利用している ・日々の記帳は行っている ・マイナンバーカードをちゃんと持っていて、今年電子証明書を更新した ・e-Taxで納税しようという心意気がある ・昨年e-Taxで納税して心が折れたfreeeを使っての確定申告書類作成までここ4年ほどfreeeを使って確定申告を行っているが、毎年地味な改善が繰り広げられており、回を追うごとに楽になっている。ありがたい。 4年前に初めて確定申告を行った際は、源泉徴収された分の登録を手動で行う必要があるというトラップにハマり、「え、、、確定申告するとこんなにお金取られるの、、、無理、、、」となっていたが、提出直前で気付い

[これは何] プロダクトマネージャーの選考に通らないという候補者側と、プロダクトマネージャーの採用ができないという企業側のギャップについて書いた話こんにちは。bosyu / bosyu Jobsでプロダクトマネージャーをやりつつ、Applyで見習い転職エージェントをやっているkoyoです。 自分自身がプロダクトマネージャーということもあって、プロダクトマネージャーの採用に関する相談や、転職に関する相談を受けることも多いです。その中で両者に共通しているのは、「選考が全然通らない」という問題です。 企業側からは「思ったような人からの応募が来ない」がゆえに選考が通らないといった相談を受け、転職したい個人からは「選考を受けても全然通らない」といった相談を受けています。 他方で、プロダクトマネージャーの採用ニーズは年々高まっている印象を受けますし、個人としてもプロダクトマネージャーのキャリアを目指す

bosyuというサービスはフルリモートのチームで運営されています。開発メンバーだけでなく、CSやマーケティング等のビジネスサイドのメンバーも、全てリモートワークで仕事をしています。メンバー同士で顔をあわせることは年に数回程度です。 業務委託のメンバーを含めると現在は15名程度のチーム（開発メンバーは10名程度）と大きいチームではありませんが、メンバーのモチベーション等を含め、非常にうまく回っているチームだと感じています。 このnoteでは、フルリモートチームのプロダクトマネージャーとして働く私が、チームを前に進めるために実践していることを記します。 bosyuのプロダクトマネージャーの守備範囲話の前提を揃えるため、bosyuのプロダクトマネージャーとしての主な仕事を記しておきます。 まだそこまで大きなチームではないこともあり、あまり分業はせずにチーム全体をまるっと見る役目を担っています。そ

令和初の確定申告はe-Taxで行いました。とても大変でした。あまりにも大変だったので、誰かと来年の自分の参考になればと思ってログを記録しておきます。 【前提】 ・Macを利用している ・会計ソフトとしてfreeeを利用している ・（消費税の納税が必要な場合）freeeの上位プランに入っている ・freeeでの確定申告書/消費税等申告書の作成は終わっている ・マイナンバーカードを何故か持っている ・e-Taxで納税しようという心意気がある ちなみに、freeeの「確定申告書作成までの操作」で詰まることはほぼありませんでした。ありがとうfreee。 そのため、ここではfreeeで確定申告書等の作成が完了した後の処理について記載しておきます。 確定申告書作成完了後、申告freeeを使ってみたfreeeを利用している場合、「所得税」の納税についてはfreeeが作っている電子申告用のアプリ（申告fr

こんにちは。フリーランスの立場からキャスター社をお手伝いしているkoyoです。最近、非常に良いシュークリームを見つけました。ベストオブシュークリームを語る、シュークリームの情報交換会がしたいです。 さて、今回のnoteでは、マーケティングとエンジニアリングが双方できると事業と個人のキャリアにとって幸せなことが多いよね、といった話をしたいなと思います。なので、シュークリームの話は出てきません。 （注意）このnoteの結論は人を探している系のnoteです。職探しに少なからずの興味がある人以外には全く刺さらないnoteですので、流れで開いてしまった人はごめんなさい。トカゲの写真で和んだ気持ちで、もしよろしければ最後までお付き合いください。意味のあることも書いています。と、、、その前に、フリーランスの立場でキャスター社に関わって、わりとずっと思っていることを書いておきます。CEOの中川さんとかCO

こんにちは。CASTER BIZ recruitingで雑用係をしているフリーランスのkoyoです。蒸し暑くなってきてそろそろ家から一歩も出たくありません。リモートワーク中心でよかったです、ほんと。 さて、私がお手伝いしているCASTER BIZ recruitingでは、100社を超えるクライアントさんの採用活動を支援させていただいております。私はその中で事業全体のマーケティングや内部で使うツールなどを作ったりしているのですが、CASTER BIZ recruitingのクライアントさんのエンジニア採用の支援もさせていただいていたりします。 他にもキャスタープロダクトチームの採用をごりっとやっていたり、過去には自分の会社で2週間で10人のつよつよマンを採用したことがあったりと、エンジニア採用についての知見が自分の中にわりと溜まっていたりします。 そこで今日は、エンジニア採用を始めるにあた

キャスターでプロダクトマネージャー（PdM）をしているkoyoです、こんにちは。先日買ったカモメファンが可愛すぎて今年の夏は乗り切れそうです。上下左右首振りかつ静音で可愛い扇風機なのでオススメです。 さて、私がフリーランスで関わっているキャスターのプロダクトチームでは、bosyuをはじめとする外部向けのプロダクト以外にも、いくつかの社内向けのプロダクト（それも結構規模の大きいもの）を作っています。 社内向けとはいえ、常時数百人以上が使うものであり、かつ、業務要件もわりと複雑なので、外部に公開しているSaaSと同じくらいの力をかけて作っていたりします。 外部向けのプロダクトの話はよく見かけるのですが、社内向けのプロダクトの話はあまり読んだことがないので、今日は「社内向けのプロダクトを作るときにPdMが考えていること」をお伝えしていきたいなと思います。 事業を形式だけでなく肌で理解する社内向け

みなさんこんにちは。フリーランスとしてキャスターに関わり出して3年くらいが経ったりする松本です。週2くらいでゆるゆるとお仕事を続けていたら、いつのまにか社歴が長くなり、長老扱いされていました。 フリーランスでこんなに長期間関わるのは珍しいと思うのですが、好き勝手やらせてもらっていたり、出勤はそもそもないし、働く時間も自由だし、メンバも増えて色々楽しいフェーズになっていたりして、なんか過ごしやすいなーと思っていたら時間が経っていました。 今日は、キャスターマジで雇用形態関係ねえっていう話を伝えたいなと思って、業務委託で関わる人間がエンジニアチームのブログを書いてみることにしました。 ところで何やってる人？普段はフリーランスでスタートアップのお手伝いをしていたり、自分の会社をごにょごにょしたり、自分のサービスを作ったり育てたりして遊んでいます。 職種的にはプロダクトマネージャー（PdM）をやら