この記事は、LayerX Tech Advent Calendar 2024 の ６ 日目の記事です。 tech.layerx.co.jp ▼ 今回お話しすること こんにちは！バクラク事業部 ソフトウェアエンジニアの @minako-ph です 🐱 弊社では全社的に Notion を活用し、申請・経費精算チームではスクラム開発を採用しています。2週間ごとのスプリントを回す中で、Notionを使った進捗管理や作業効率向上に取り組んでいます。 1年前に執筆した Notionでスプリントのあれこれをダッシュボードで可視化する という記事では、Notionを活用したスクラム管理の仕組みを紹介しました。今回は、1年間運用して得られた学びをもとに、「ストーリーポイント管理」と「チームのダッシュボード」についてお話しします。 特に以下の3点を中心に解説します： 🔥 スプリントで消化可能なストーリーポ
個人開発しているアプリ、minto(ミント)が2024年5月で5周年、累計50万ユーザーを突破しました。 そこで、なぜアプリを作ったか？から現状のアプリのことまで1記事でまとめました。 とても長いですが興味ある部分だけでも読んでいただけると嬉しいです。 きっかけ個人アプリを始める前に、会社の新規事業部で新規アプリの開発担当として働いていたのですが、どのプロジェクトも成果を上げることができませんでした。会社から給料をもらいながら開発費を垂れ流す身になるのはとても辛い思いがありました。同時に「自分が1から企画してプロジェクトをスタートしたらうまくいく自信がある。チャレンジしたい」という欲求がふつふつと湧いてきました。 なぜmintoちょうどその頃、同僚から家族のTODOをSlackで共有している話を聞き、ハックまでして解消したいペインがあるのなら、それをアプリにして広く大衆が使えるようにすれば
この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな！ ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください！ 【追記】 上記に対して「有料記事がダメって事？」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います！そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ
WBSは、プロジェクトを管理するためによく使われる手法の一つです。 特にWeb制作やシステム開発などでよく使われます。 ただ、WBSという名前は知っていても、詳しくは知らないという方も多いかもしれません。 本記事では、WBSについてメリットや作り方・ポイントなどを解説します。 システム開発だけではなく、さまざまなプロジェクトで生かせるのでぜひ参考にしてください。 WBSとは？ 導入の目的 WBS（Work Breakdown Structure：作業分解構成図）とは、プロジェクトのタスク（作業）を分解して、構造化したフレームワークです。 WBSでは、プロジェクト全体を、まずは大まかなタスクに分解します。 その分解の粒度をどんどん細かくし、最終的には小さなタスクの集合体にしていき、そのタスクをツリー図にまとめたものがWBSです。 WBSはプロジェクトの計画・管理に欠かせないものです。 プロジ
こんにちは！ 2019年11月に入社し、プロダクトマネージャーをしている竹村（@juntakemura_pdm）です。 今回が初ブログになります。 先月から開幕したプロ野球ですが、このブログを書いている時点で東京ヤクルトスワローズが単独首位に立っています。 スワローズファンの私としては非常に気分が良い日々を過ごしております。 滅多にないことなので記念に書かせていただきました。 さて、本題に入りますが、私は入社してから「転職ナビ」という転職サイトに携わっております。 転職ナビに関しては、以下のエントリで触れられているのでそちらもご覧ください。 lab.astamuse.co.jp PMとしてプロダクト作りに関わる中で、MVPに関する学びを多く得たので、今回はそれについてお話ししたいと思います。 前半はMVPに関する一般的な話となりますので、既に知っている方は読み飛ばしても構いません。 MVP
紙の本が売り切れていたので手をつけていませんでしたが、ようやく全部揃ったので読みました。 まず前提として「桜井さん凄いなあ」というのはあるんですが、気になったのが、このエッセイは国内のゲーム開発手法の課題を再生産しているのではないか？ということです。 桜井さんのエッセイには繰り返し登場する課題がいくつかあります。 ・新しいディレクターが育たない、現れない ・桜井さんが忙しい ・シリーズもののゲームが増えるなど、ゲームの新奇性が減っている このうち「新しいディレクターが育たない」ことと「忙しい」ことは同一の問題で「権限の委譲が進まない」という、多くの組織に見られる問題と言えます。 しかし、エッセイで紹介されている開発手法を見ると「そりゃ、育たないのでは？」と思わざるを得ません。キャラクターの操作感を決めるパラメータは重要なので自分が担当する、企画は初期の企画書にすべて落とし込むなど、ものすご
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
2024年4月18日紙版発売 WEB+DB PRESS編集部 編 B5判／128ページ 定価3,300円（本体3,000円＋税10%） ISBN 978-4-297-14156-1 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 本書のサポートページサンプルファイルのダウンロードや正誤表など 『WEB+DB PRESS』全号のバックナンバーを収録 Webアプリケーション開発のためのプログラミング技術情報誌「WEB+DB PRESS」は，2000年から2023年までの23年間という長きにわたり，現場で活躍するWeb開発者の方々に向けた技術情報を提供してまいりました。そして2023年8月発売のVol.136をもって，隔月刊誌としては休刊いたしました。 本総集編には，WEB+DB PRESSVol.1から隔月刊最終号となるVol.136までのバックナン
はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
ガジェット全般、サイエンス、宇宙、音楽、モータースポーツetc... 電気・ネットワーク技術者。実績媒体Engadget日本版, Autoblog日本版, Forbes JAPAN他 エクストリームスポーツを効果的にマーケティングに取り込んできたエナジードリンクのレッドブルが新たに公開したのは、レッドブル・レーシングのF1マシンを世界最速のカメラ搭載ドローンでぴったり追跡する空撮映像です。 F1世界選手権の2024年シーズンは今週末に開幕します。昨シーズンはレッドブル・レーシングF1チームのマックス・フェルスタッペン選手が圧倒的な強さを見せつけて世界チャンピオンの座を防衛し、先頃行われたシーズン前の合同テストでも、圧倒的な安定感とスピードを誇示していました。 そんな自動車レースの頂点に立つレッドブルのF1マシンと世界チャンピオンを追いかけ回すドローンパイロットとして選ばれたのは、Dutch
この記事はなにか最近知った「エフェクチュエーション（Effectuation）」という経営理論が、自分の中でとてもしっくりいくものだったので、自分なりの解説も兼ねて、記事として残しておきたいなと思いました。 エフェクチュエーションは、狭義的に見れば経営上の理論ですが、実際にはより広い範囲に適応可能な、「不確実性の高い環境に置かれた人の行動全般に関する理論」と言えるのではないかと思います。例えば、以前、新しい職場に転職するなどで見知らぬ環境に置かれることになった場合にどのように適応するかについての自分なりの考えを、"新しい環境でバリューが出せずに悩んでいる場合の解決法"という記事で紹介しました。当該記事の執筆当時はエフェクチュエーション理論は知りませんでしたが、今振り返って読み返すと、かなり共通する要素があるように感じます。 また、ここ数年、自分自身が、これまでとは全く新しい環境に身を置き、
こんにちは！estieでビジネス部門の責任者をしている束原です。 2024年になりましたね。estieは決算月が12月なのですが、毎年期初に「今年こそが勝負の年だ」と言っている気がしており、それに対して「ガハハ」と笑い合えるメンバーで仕事ができているのが最高に楽しいなと日々痛感しております。 さて、こちらは事業の立ち上げ（事業開発）に関する記事です。 この記事に書いてあること estieでは「仮説検証」をやめようと思っている話 事業開発の成分の8割は営業だという話 かなり極論が並んでいますが(笑)、事業開発を進める上でとても重要だと考えているので、ご興味のある方は少しお付き合いください。 to Bスタートアップは仮説検証をやめようという話 「仮説検証って言葉が嫌いなんすよねー」と、確か弊社の事業責任者の齋藤だったか代表の平井だったかが以前社内で言ってました。 1年前くらいまで私は、その発言
こんにちは。SALESCOREのCTOの成澤です。 今日は、Webサービス開発に携わる方向けに「要望を正しく聞くのは大事だよ」という話を、飲食店の例え話で紹介します。 「うちの店でカレーを出したい」と言われたら飲食店のオーナーから「うちの店のメニューにカレーを加えたい。カレーを作る体制を整備してほしい」と相談されたとします。 敏腕料理人のあなたは何を考えるでしょうか？ 普通に考えたら「野菜と肉とルーを仕入れて、あとは鍋と包丁を用意して…」と考えるでしょう。 カレー作りに知見がある人なら「スパイスから手作りした方が美味しく作れる！スパイスを独自ルートで調達しよう！」なんてことも考えるかもしれません。 しかし、ここであなたがするべきことは、オーナーへの追加ヒアリングです。 どんな店なのか？ → 喫茶店かも 店内の調理設備は？ → 狭い厨房がちょっとあるだけ。調理器具もほとんどない スタッフの体
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
1. はじめよう! 要件定義 ~ビギナーからベテランまで（難度：★☆☆） 1-1. 本のポイント 要件定義のプロセスが平易な言葉で解説されている 内容がコンパクトで図解も多いため読みやすい 中級～上級エンジニアが初心に帰るためにも最適 1-2. 本の特徴 本書は、初学者向けにざっくりとした内容を具体的なアウトプットとともに学ぶことができる。 184ページとボリュームに物足りなさを感じそうだが、要件定義のプロセスと、プロセスごとの勘所がコンパクトにまとまっている。 ちなみに、本書は「要件定義のプロセスと勘所を知れる」という点で独立した書籍だが、著者が書いた下記2冊と合わせると、理解をより深められる。 ・はじめよう! プロセス設計 ~要件定義のその前に ・はじめよう! システム設計 ~要件定義のその後に 本書が有益だと感じた読者は、ぜひ上記2冊にも目を通していただきたい。 1-3. 本を書いた
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 1年前の入社4年目の私は、開発チームのリーダーの経験はなく、また、スプリントの計画も立てたことが無いような状態でした。 そんな状態で、突然リーダーとしてプロジェクトの意思決定をすることになりました。 自分に務まるかとても不安で、恐怖すら感じていました。 実際にやってみると、これまでいかに作業者視点で物事を考えていたか、プロジェクト全体が見えていなかったのかを痛感しました。 現在では、マネージャーが休みや出張で不在の場合でも、私がいればうまくチームメンバと協力して開発を進めてくれると言っていただけるまでになりました。 それ
【月間総括】残念な結果のFF16が引き起こすスクエニの組織改革と，PS5で年間2500万台を目指すSIEの目標 今月は決算について述べていきたい。 先月の連載ではソニーと任天堂の話をメインに据えていたが，スクウェア・エニックスやファイナルファンタジー（FF）に対する関心の高さをうかがい知れたと感じているので，まずはスクウェア・エニックスについて話そうと思う。 先般開催された決算説明会では，（1）FF16は想定内の上限か下限かであれば，もうひと伸び欲しかった，（2）FF16がもうひと伸び足りなかった背景にはPS5の普及率の低さがあり，普及率に合わせた施策を打つ，（3）開発費は全額計上したので今後は利益になる，などが語られた。 会社側としては，FF16は相当に頑張ったもののPS5の普及率が壁になり，今一つだったということだろうと東洋証券としては認識している。 そのうえで，第1四半期決算に関して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
