「良いものを作れば広まる」は嘘ではないが真実でもない まつもとゆきひろ氏が語る、“30年”の経験の中で感じたこと
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここでプログラミング言語Rubyの生みの親であるまつもとゆきひろ氏が登壇。まずは、「成功するソフトウェア」における「成功」について話します。 Rubyは30年間生き延びたソフトウェアプロダクト まつもとゆきひろ氏（以下、まつもと）：それでは発表をさせてください。「成功するソフトウェアの作り方」と題しまして、Rubyのまつもとが発表します。先ほど「Heroku」の発表がありましたが、私は元Herokuなので、すごく懐かしく聞いていました（笑）。 （スライドを示して）こんなアイコンでふだん活動しています。 英語圏ではMatzという名前を使っています。Rubyを作った人として知られ
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
プロダクト開発チームの分断に立ち向かう - yigarashiのブログ
先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を
Agile and Requirement : アジャイルな要件定義について考える
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
技術的負債は開発者体験を悪化させる - mtx2s’s blog
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
スクラムに「うーん、、、」て感じた時なんか役にたつ"かもしれない"3行アドバイス - Qiita
この投稿は ミライトデザイン Advent Calendar 2021 の 25日目最終日の投稿です。 本稿の内容 スクラム開発を取り入れてみたけどいまいち機能してない。いまいちメリットを感じない。 失敗はしていないけど成功もしていない。みたいな経験がありませんか？ 本稿ではそんなときに改めてさっと見返して役に立つことを目的とした「3行くらいのアドバイス」を書きたいと思います。（あくまで"くらい"なのでたまに超えるかも） また、個人的意見も多分に入ってますのでそこはご了承ください。 前提 まずはスクラムチームの意識を合わせましょう。 スクラム開発ではスプリントごとに「プロダクトに対してインクリメントを積み重ねていく」事を目的とします。 この大前提を見失ってはスクラム開発のどんなプロセスを踏んでも価値を得る事は難しいでしょう。 インクリメントとは、プロダクトに出荷可能な形の価値を積み重ねる事
プロダクト開発のコミュニケーションをなめらかにする10の概念 - ドクターズプライム Official Blog
こんにちは、ドクターズプライムの高橋（id:kyosu-ke）です。ドクターズプライムでプロダクト部門と管理部門の担当役員をやっています。 インターネットではTwitterを中心に@kyosu_keというアカウントでやっています。ユーザーIDにアンダースコアを使えるサービスが好きです。 普段は About Productという個人ブログで割と硬めで気取った文章をポストしています。ゆるいテンションで書こうと思ったのですが、途中から個人ブログ向けに書いてると錯覚してしまい、割と重い文章に仕上がりました。 これはなにか 今回はドクターズプライムで取り入れている、「プロダクト開発のコミュニケーションをなめらかにする10の概念」を紹介するポストです。 プロダクト開発に携わる職種の方はもちろん、プロダクト開発職種と関わる非開発系職種の方にも読んでいただけると、プロダクト開発系職種のメンバーとのコミュニ
「早くリリースして、早く改善しよう」の落とし穴―― 開発畑のプロダクトマネージャーの失敗から学べ
はじめに はじめまして。ゆずたそ（@yuzutas0）と申します。私はソフトウェア開発者からプロダクトマネージャーへ役割を変更した後、多くの失敗を経て「マインドセットを切り替えること」の重要性を痛感しました。 この連載では、私が学んだ「プロダクトマネージャーのマインドセット」を解説します。 想定する読者・提供価値については、2つのパターンを想定しています。1つ目は「同じように失敗した経験のある人」です。自分の経験を振り返りながら「こうすればよかったのか！」と考える機会になるはずです。2つ目は「これから失敗を経験するであろう人」です。これから起きる課題について「こうすればいいのか！」と考える機会になるはずです。 注意・免責 ①本連載の内容は、筆者の個人的な見解にもとづきます。適宜ご自身の立場に置き換えて、読み進めていただければと思います。万が一、誤りや不快な点がありましたら、どうぞ筆者個人宛
【翻訳】 図解 プロダクトづくりの構造 - ykmc09 blog
訳者注 本記事は、Dan Schmidt 氏のブログ記事「A Visual Vocabulary for Product Building」をご本人の許可のもと日本語訳したものです。 ninjinkunさん、Koshiro Kumikoさんにレビューにご協力いただきました。的確かつ、建設的で思いやりのあるアドバイスとフィードバックに感謝します。 同一著者の関連記事としてこちらもぜひ合わせてご覧ください：【翻訳】プロダクトマネジメントトライアングル 以下、翻訳本文です。 プロダクトビルダー（訳注：プロダクトをつくる人たち）が自分のプロダクトに当てはめられるような、成功するプロダクトをつくる方程式はありません。これは、プロダクトが置かれている常に変化するコンテキストに、プロダクトづくりの詳細が大きく左右されるからです。あるプロダクトで成功した戦略が別のプロダクトではまったくあわないこともありま
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
プロダクト作りにはさまざまな「罠」がある。機能の開発とリリースに集中してしまい、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況のことを「ビルドトラップ」と言い、プロダクトを開発する組織において陥りやすい「罠」の一つだ。なぜこの問題が起こるのか。どうすれば、本質的なプロダクト作りに立ち戻れるのか。『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』の訳者であり、アジャイル開発や組織改革のトレーニングなどを行う専門家、吉羽龍太郎氏が語った。 大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師と
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
リーダブルテストコード - Qiita
はじめに よく言われるように、ソースコードというものは書かれることよりも読まれることの方が多く、それゆえ読みやすいコードを書くということが非常に重要です。それはテストコードにおいても同様であり、プロダクトコードと同等に資産として扱う必要があります。 テストコードは具体的な値を用いて記述し、また複数の変数の値の組み合わせでテストケースを起こすため、プロダクトコードと比べて冗長になりがちです。 書籍『リーダブルコード』の14章でもテストコードの読みやすさについて触れられていますが、本稿では読みづらいテストコードをリファクタリングして読みやすくするためのテクニックを紹介したいと思います。 なおサンプルコードはJavaScriptで記述されており、そのテストコードはJest1を用いて書いています。 ソースコードはGitHubにあります。 リファクタリング(その壱) 以下の、決して読みやすいとはいえ
スクラムガイド2020を読んで自分たちのスクラムをふりかえりました。
この記事は GMOアドマーケティング Advent Calendar 2020 24日目の記事です。 こんにちは。GMOアドマーケティングのT.Mです。 はじめに 2020年11月下旬くらいだったでしょうか、スクラムガイド2020が発表されました。 スクラムガイド2020を読んでみて、いま自分たちが行っているスクラムとどう違うのか考えてみました。 昨年のアドベントカレンダーではスクラムを始めた事を書きましたが、 ちょうど1年経ったようです。 ※スクラムを始めてからは1年半経ちました。 スクラムガイドについて スクラムガイドは、20ページ弱の短い文章でスクラムの定義、理論が記載されています。 理論的な内容なので具体的な実践方法は各種書籍の方が詳しいです。 2017年版から久しぶりの改訂版が出ました。 2020年版はこちら。 スクラムガイド2017と2020の違い 3年ぶりに改定されました。
「エンジニアは高過ぎる意識を捨てよ」と言われたスマニューPMたいろーさんの「サービス改悪」回避法 - エンジニアtype | 転職type
2020.10.14 スキル 「良いサービスやプロダクトを作って、より多くの人に使ってほしい」 アプリなどのWebサービス開発に携わるエンジニアであれば、きっと誰もがそう思うはず。 しかし、実際には新機能をリリースしても利用率が伸び悩んだり、UIを変えても「使いにくい」というネガティブな反応が出てきたり、作り手の意に反してユーザーがプロダクトから離れてしまうことは少なくない。 作り手の善意が、ユーザーの期待に応えられないケースは、なぜ起きるのだろうか？ ーー実は、その原因は「人間観のズレ」にあるかもしれない。 そう主張するのは、スマートニュースのエンジニア部門でTech PMを務める、たいろーさんこと森山大朗さん。以前、森山さんが発信した以下のコメントが、Twitter上で話題になった。 ＞＞元ツイート そこで森山さんに、「人間観のズレ」を見直す必要性を強く感じたエピソードや、ズレを放置し
サイボウズの「開発・運用組織」で働く環境 @ 2020 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは〜！リングフィットアドベンチャーを6ヶ月ほどやっているのですが体重の変化がない開発本部所属の hokatomo です💪💪 2016年に ymmt さんが「サイボウズエンジニアの職場環境 @ 2016」を公開しました。 あれから変わった面があるのと、2019年1月に中途入社した者として「こういう制度や文化があるんだ！」と驚いた部分があったので、忘れないうちに2020年度版を書きます:) この記事で、「サイボウズの開発や運用で働くってどんな感じ？」と気になってくれている方に、少しでも様子が伝わったら嬉しいです。 筆者である私はエンジニアではなく、開発本部所属で社内コミュニケーションの部分を担当しているので、その目線で書いています。 目次 働く場所・時間は自分で決める、コアタイムなし 書籍購入、勉強会参加支援、コミュニケーション支援他さまざまな制度 開発組織を横断して支える、たくさ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
強くてニューゲームなプロダクト開発 / Product development in new game plus
カネとAgile（大企業新規事業編） #rsgt2021
開発組織マネジメント勉強会レポート 番外編「仮説検証型アジャイルのすすめ」 - DMM inside
