並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 406件

新着順 人気順

agileの検索結果81 - 120 件 / 406件

  • アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268%も高いことが判明

    ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268%も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「

      アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268%も高いことが判明
    • アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース

      アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか? そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH(以下、スタサプENGLISH)』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発

        アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース
      • Broken Ownership

        Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,

          Broken Ownership
        • ひどい。。サービスリリース発表と同時にサービス終了のお知らせ。こんなに見事にハシゴを外されるのをみたことない。

          fx1jp @fx1jp1 ひどい。。 サービスリリース発表と同時にサービス終了のお知らせ。 こんなに見事にハシゴを外されるのをみたことない。 沖電気、「LINE Pay かんたん送金サービス」と連携できるソフトウェア開発キット発表→同日、日本国内における「LINE Pay」サービス終了に関するお知らせ pic.twitter.com/SnKeWvotWk 2024-06-13 18:47:17

            ひどい。。サービスリリース発表と同時にサービス終了のお知らせ。こんなに見事にハシゴを外されるのをみたことない。
          • Web API設計実践入門──API仕様ファーストによるテスト駆動開発

            2024年7月25日紙版発売 柴田芳樹 著 A5判/208ページ 定価2,860円(本体2,600円+税10%) ISBN 978-4-297-14293-3 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Amazon Kindle honto この本の概要 本書は,著者が1993年から約30年間経験してきたAPI仕様の作成,2003年から20年間経験してきたテストファースト開発/テスト駆動開発の知見をまとめたものであり,一般的なソフトウェア開発者が習得することが容易ではない事柄を,本書を通して学び,実践してもらうことを目的としています。 本書が提唱する「API仕様ファースト開発」はWebサービスにおける大域的なテスト駆動開発の実現に必要なものであり,また,API仕様ファースト開発を実現するにはテスト駆動開発が必要です。API仕様ファースト開発とテスト駆動

              Web API設計実践入門──API仕様ファーストによるテスト駆動開発
            • トヨタはハードウェアアジャイルをどう強みにしているか? 自動車開発におけるスクラムとモブの実践 - Agile Journey

              アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS(トヨタ生産方式)」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。 一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品(ユニット)のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。 そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024(Regional Scrum Gathering T

                トヨタはハードウェアアジャイルをどう強みにしているか? 自動車開発におけるスクラムとモブの実践 - Agile Journey
              • スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines

                循環する学び~現場とコミュニティの境目で考える~/Learning Cycle between a team and a community

                  スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
                • タスクに「〜対応」という名前をつけるのを避けたい理由 - kymmt

                  先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが

                    タスクに「〜対応」という名前をつけるのを避けたい理由 - kymmt
                  • プロジェクト管理はNotionしか勝たん!MLチームのスプリント管理を改善した話 - LayerX エンジニアブログ

                    こんにちは、バクラク事業部のMLチームでソフトウェアエンジニアをしているTomoakiです。 今回はMLチームのスプリント管理におけるタスク・プロジェクト管理にNotionの新概念であるProjectを導入してみたら嬉しいことがたくさんあったので、それらを紹介したいと思います。 イントロダクション Notionの2.30リリースでプロジェクトという概念が登場し、プロジェクトの管理のテンプレートが公開されるなど大きなアップデートがありました。 www.notion.so 本記事でも紹介しますが、このリリースで紹介されているテンプレートが優秀すぎるので、まだみてない方は是非見てみてください。 MLチームでは5月末ごろから、ちょうどスプリント管理に課題感を感じており、早速NotionのProjectを取り入れて6月中に運用してみましたかなり良かったので、本記事では我々目線でのその効果を紹介したい

                      プロジェクト管理はNotionしか勝たん!MLチームのスプリント管理を改善した話 - LayerX エンジニアブログ
                    • 開発生産性、上から見るか 下から見るか / development productivity and cognitive science

                      Another works社が主催した Developers Meetup 急成長ベンチャーが向き合う「開発生産性」 というイベントでの登壇資料です https://anotherworks.connpass.com/event/294517/ SmartHR基本機能というプロダクトにおいて取り組んできたことを認知科学の観点から見てみる、というお話でした。

                        開発生産性、上から見るか 下から見るか / development productivity and cognitive science
                      • 【catnose】Zennを生んだ個人開発者に聞く、プロダクト開発の美学

                        個人開発者 catnose ソフトウェア開発者・デザイナー。 個人開発者として、Webデザイナー向けメディア「サルワカ」、ポートフォリオ作成サービス「RESUME」、技術情報共有サービス「Zenn」、簡単にAIサービスがつくれる「だれでもAIメーカー」など、数々のプロダクトを世に送り出す。家族は妻、娘、犬、猫。 個人開発者として、ポートフォリオ作成サービス「RESUME(レジュメ)」や技術情報共有サービス「Zenn(ゼン)」、入力欄や選択ボックスを組み合わせるだけで簡単にAIサービスがつくれる「だれでもAIメーカー」など、数々のプロダクトをヒットさせてきたcatnose(キャットノーズ)さん。現在も複数の開発案件に関わりながら、新たなプロダクトを開発中だといいます。 今回はそんなcatnoseさんのこれまでの作品を振り返りながら、個人開発者として培った開発哲学や、30代になるとともに起きた

                          【catnose】Zennを生んだ個人開発者に聞く、プロダクト開発の美学
                        • プロダクトが大きくなると、なぜ生産性は下がるのか? 『Team Topologies』から読み解く、「認知負荷」という考え方

                          株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。1回目は、開発の生産性に大きく影響する、「チームの認知負荷(Team Cognitive Load)」について。 名村卓氏のキャリア変遷 大谷旅人氏(以下、大谷):それでは本日のメインの名村さんのお話に入りたいと思います。LayerX 名村さん、ご登壇よろしくお願いします。 名村卓氏(以下、名村):はい、よろしくお願いします。LayerXの名村と申します。今、LayerXでEnabling Teamという、Enablementをやっている組織にいるのですが、今日はそこでの経験と諸々含めてお話できればと思っていま

                            プロダクトが大きくなると、なぜ生産性は下がるのか? 『Team Topologies』から読み解く、「認知負荷」という考え方
                          • WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が

                            WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が整っているわけではないです。 徳丸先生は、一般的な開発者には最低限どのレベルのセキュリティ知識を求められていますか? 回答の難しい質問ですが、ここは本音をさらけ出したいと思います。 私が「安全なWebアプリケーションの作り方(通称徳丸本)」を出したのが2011年3月でして、それから13年以

                              WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が
                            • 「なんちゃってスクラム」に気づくためのコツ

                              こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、開発手法として、スクラム開発に取り組んでいます。 今回は、「なんちゃってスクラム」に気づくためのコツ、というトピックで話していきたいと思います。 自分自身数年にわたり、他社の方から「スクラム開発やってる?」と聞かれたときに、「なんちゃってスクラムですかねぇ」と言い続けてきました。長らく「なんちゃって」状態だったのですが、最近個人的にそれを脱するタイミングを味わったので、その話をさせてください。 ※ そもそもスクラム開発をよく知らないという方にもわかるように、適宜スクラム開発自体の説明もしていきます。 この記事の対象読者 現在進行形で、スクラム開発をやっているが、なんか違いそうと感じている方 (前職などで)1度スクラム開発をやった経験はあるが、いまいち

                                「なんちゃってスクラム」に気づくためのコツ
                              • アジャイルについてマネージャーが知るべき97のこと

                                1. アジャイルについて マネージャーが知るべき 97 のこと 株式会社アトラクタ 取締役CTOアジャイルコーチ 吉羽龍太郎 (@ryuzee) 2. イントロダクション 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2

                                  アジャイルについてマネージャーが知るべき97のこと
                                • 2023-08-14 10年勤めたfreeeを辞めて零細企業を作った - waka.dev

                                  日記です。 タイトルの通り10年勤めたfreee株式会社を退職して、自分で会社を作ってやっていくことにした。 freee最終出社でした、10年間ありがとうございました!(ビルを見上げる写真撮り忘れた) 次回作にご期待ください! — yo_waka (@yo_waka) June 16, 2023 やってきたことはこの辺のスライドによくまとまっている。 https://speakerdeck.com/waka/da-kinapurodakutofalseyu-tefang 社員5人から1000人になったり、ARRゼロ円からARR200億円になったり、ヤバかった品質をどうにか底上げしたり、開発本部長の立場で上場を経験したり、普通では経験できないことを濃度高く経験できて楽しく過ごせた10年だった。 freee会計という業務系Webサービスを10年間機能面/パフォーマンス/品質面共に育ててきた経験

                                    2023-08-14 10年勤めたfreeeを辞めて零細企業を作った - waka.dev
                                  • フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話

                                    https://dev-productivity-con.findy-code.io/ 株式会社SODAのセッション資料です。

                                      フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話
                                    • 「アジャイルソフトウェア開発という概念」の源流は日本なのか 〜『日本企業はなぜ「強み」を捨てるのか 』を読んで〜 - bonotakeの日記

                                      夜中におもむろに書評を書き出す第2段。 日本企業はなぜ「強み」を捨てるのか~増補改訂版『日本“式”経営の逆襲』~ (光文社新書) 作者:岩尾 俊兵光文社Amazon この本自体はとても面白いし首肯できる部分も多いが、1箇所だけイチャモンをつけたい。 そもそもアジャイルソフトウェア開発という概念自体、マニフェスト(注:アジャイルソフトウェア開発宣言のこと)の発表よりも3年早く、1998年に日本の研究者から提案されている。 南山大学の青山幹雄教授による一連の研究である。 (同書より引用) ここで紹介されている「1998年」の「提案」とは、おそらくICSE1998で青山先生が発表した論文 "Agile Software Process and Its Experience" のことだろうと思う。Agile Software Process(ASP)という、実際に富士通の社内で実践されたソフトウェ

                                        「アジャイルソフトウェア開発という概念」の源流は日本なのか 〜『日本企業はなぜ「強み」を捨てるのか 』を読んで〜 - bonotakeの日記
                                      • GitHub Copilotは開発者の生産性をどれだけ上げるのか?ZOZOでの全社導入とその効果 / How Much Does GitHub Copilot Improve Developer Productivity? The Company-wide Implementation and Its Effects at ZOZO

                                        2024/2/16 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215 ■ ZOZOエンジニア向け会社説明資料 https://speakerdeck.com/zozodevelopers/company-deck ■ GitHub Universe 2023 https://githubuniverse.com/ ■ Universe 2023: CopilotがGitHubをAIを駆使した開発者プラットフォームへと変貌させる https://github.blog/jp/2023-11-09-universe-2023-copilot-transforms-github-into-the-ai-powered-developer-platform/ ■ GitHub Universe 2023 o

                                          GitHub Copilotは開発者の生産性をどれだけ上げるのか?ZOZOでの全社導入とその効果 / How Much Does GitHub Copilot Improve Developer Productivity? The Company-wide Implementation and Its Effects at ZOZO
                                        • 受託開発におけるアジャイルに限界を感じた私が、「納品のない受託開発」を始めるまで - 倉貫義人の「はじめてのアジャイル」 - Agile Journey

                                          Agile Journeyをご覧のみなさん、はじめまして。株式会社ソニックガーデンの代表をしている倉貫義人と申します。 私はもともと大手システム会社でプログラマとして働いていました。そのとき出会ったアジャイル開発に魅了され、これこそ自分にとって理想の姿であると確信し、それ以来アジャイル開発を広めるための様々な活動を社内外で行ってきました。 最終的に、本当に自分の理想とするソフトウェア開発と、それを実現する組織をつくるためには、自ら会社を経営する立場になるしかないと考え、起業することになりました。そうしてできたのが株式会社ソニックガーデンです。 ソニックガーデンでは「納品のない受託開発」というサービスを提供しています。従来的な受託開発から、そもそものビジネスモデルを見直したことで、今では「アジャイル開発」を意識せずとも、自然とそれに取り組める組織として機能しています。 思い返すと、私のアジャ

                                            受託開発におけるアジャイルに限界を感じた私が、「納品のない受託開発」を始めるまで - 倉貫義人の「はじめてのアジャイル」 - Agile Journey
                                          • 変更容易性と理解容易性を支える自動テスト(2024/02版) / Automated Test Knowledge from Savanna 202402 YAPC::Hiroshima edition

                                            YAPC::Hiroshima 2024

                                              変更容易性と理解容易性を支える自動テスト(2024/02版) / Automated Test Knowledge from Savanna 202402 YAPC::Hiroshima edition
                                            • アジャイル開発は本当に必要なのか、何を解決するのか

                                              AWS Dev Day 2023 Tokyoの登壇資料です。

                                                アジャイル開発は本当に必要なのか、何を解決するのか
                                              • 経験に複利を効かせろ!ふりかえり研修2024

                                                Tangible, Embedded and Embodied Interaction - Lecture 9 - Next Generation User Interfaces (4018166FNR)

                                                  経験に複利を効かせろ!ふりかえり研修2024
                                                • Gitのブランチの役割を考える | フューチャー技術ブログ

                                                  Gitのブランチ戦略にはいくつかあります。 GitフローGitHubフローGitLabフローチームの戦略を考えるときにどれかを参考にしつつカスタマイズするときにいろいろ不都合が生じてしてきて複雑になってしまうことってありますよね?社内でブランチの管理の議論をする中で、ブランチの役割を明確にした上で、どのブランチがどのような役割を持っているのかを明確にした方が混乱が少なくなるのではないか?というのを考えていました。 特に、プロジェクトごとに同じ名前でも役割が違うなー、というのとかもあり、ブランチ名=役割ではなく、ブランチの上位概念として役割を考えて、それを実際のブランチとの対応づけを行う必要があるのではないかな、と。 CI/CDと組み合わされることで、releaseブランチ==ステージング環境となってしまい、ステージング環境を使いたいリリース前のブランチと、ホットフィックスの検証のブランチの

                                                    Gitのブランチの役割を考える | フューチャー技術ブログ
                                                  • Sprint Planning をやめた話 - スタディサプリ Product Team Blog

                                                    小中新規開発グループ (a.k.a. tara チーム) の qsona です。 tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。 tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。 スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである「学習コアチーム」において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。 なお、本

                                                      Sprint Planning をやめた話 - スタディサプリ Product Team Blog
                                                    • IPAマンガでわかるソフトウェア開発データ分析38編.pdf

                                                      マンガでわかる ソフトウェア開発 データ分析 データ分析事始め データ分析FAQ (参考)アジャイルメトリクスFAQ 1 独立行政法人情報処理推進機構 超合本版38編 データ分析事始め 目次 データ分析基礎編 01 データ分析ってなんなの? データ分析 02 信頼幅の線、気になる 信頼幅 03 箱ひげ図のひげ、かわゆくない 箱ひげ図 04 散布図はぜんぜんばらばら 散布図と箱ひげ図 05 どれが本命なの? 中央値と平均値 分析データ観察編 01 生産性は性癖が出る? 生産性 02 バグを愛したソース 信頼性(不具合密度) 03 改修・保守が好き過ぎる 開発プロダクトの種別 04 規模はアンバランスでアンビバレント ソフトウェア規模 05 開発期間は短くて長くて短い 開発期間(工期) 06 ウォーターフォールってつおい? ウォーターフォール型開発 07 ここはツールでしょ 開発ツール 08

                                                      • Ruby on Railsはどのように生まれ、発展してきたのか[前編]。作者DHH氏やコアチームが語る動画「Ruby on Rails: The Documentary」が公開

                                                        「1999年か2000年頃、私は37signalsというWebデザイン企業を経営していました。2人のビジネスパートナーとWebデザインを受注していたのです」(Fried氏) Fried氏は本業とは別に再度プロジェクトとしてオンライン書籍データベースの開発に取り組んでいました。開発はPHPで行っていたものの、Fried氏はプログラミングでつまづきます。 当時はまだStackOverflowのような技術的な質問に答えてくれる掲示板などなかった時代。Fried氏はブログに「誰かこの問題を解決する方法をご存じですか?」と書き込みます。 するとデンマークからメールが届きます。メールを書いてきたのがDHH氏でした。 「私は(37signals社の)Signal vs. Noiseというブログを以前から熱心にフォローしていました」とDHH氏。 「ブログで彼の質問を見て、私は『おお、この答えを知っているぞ

                                                          Ruby on Railsはどのように生まれ、発展してきたのか[前編]。作者DHH氏やコアチームが語る動画「Ruby on Rails: The Documentary」が公開
                                                        • スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide

                                                          Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ! https://agile-monster.com/profile/ https://agile-monster.com/contact/

                                                            スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
                                                          • 「いらない機能はさっさと消したい」負債解消の初手「消す」を組織全員で実践する方法【Sansan西場正浩】 レバテックラボ(レバテックLAB)

                                                            「いらない機能はさっさと消したい」負債解消の初手「消す」を組織全員で実践する方法【Sansan西場正浩】 2024年1月16日 Sansan株式会社 執行役員 VPoE/VPoP 西場 正浩 大学院で数理ファイナンスの博士号を取得後、大手銀行で数理モデルの開発に従事。その後医療系IT企業でエンジニアやプロダクトマネジャー、事業責任者、採用人事などを幅広く務める。2021年にSansan株式会社へ入社。技術本部研究開発部でマネジメント業務に当たり、現在はVPoEとしてエンジニア組織の整備と強化を、さらにVPoPとして、営業DXのためのSaaS「Sansan」のグロースを担う。 X(@m_nishiba) note 多数のビッグプロダクトがローンチから10周年を迎える昨今、技術的負債は多くの開発チームにおいて巨大な課題となっています。積み重なった負債の影響で開発生産性が下がり、返済しようにもリ

                                                              「いらない機能はさっさと消したい」負債解消の初手「消す」を組織全員で実践する方法【Sansan西場正浩】 レバテックラボ(レバテックLAB)
                                                            • プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita

                                                              はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ

                                                                プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita
                                                              • 優先順位が口癖になる危機感 - ジンジャー研究室

                                                                開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。(なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない) 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは3ヶ月後だ。そして3ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。3ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する

                                                                  優先順位が口癖になる危機感 - ジンジャー研究室
                                                                • スクラムマスターやマネージャーのための信頼構築につながる傾聴の技術

                                                                  Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp

                                                                    スクラムマスターやマネージャーのための信頼構築につながる傾聴の技術
                                                                  • 「『50%の時間を技術的負債返済に』はぜんぜん駄目だった」 カミナシ社・原トリ氏が語る、試行錯誤の過程

                                                                    「負債にも50パーセントの時間を使ってください」は機能しなかった 西村賢氏(以下、西村):最初にやったことに価値がありました。そして、次は第2段。 原トリ氏(以下、原):この説明会やった時に、6月は一回止めますと(話しました)。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村:これ、カミナシの歴史で初めてですね。 原:たぶん、初めてだと思います。 西村:そこは「大丈夫なのかな?」とかなかったんですか? 原:「この1年大きい機能、出てないよね?」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村:なるほど。なにか技術的にうまくいっていないというのがあった。 原:そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力

                                                                      「『50%の時間を技術的負債返済に』はぜんぜん駄目だった」 カミナシ社・原トリ氏が語る、試行錯誤の過程
                                                                    • 組織のコード品質を向上させる “レビューシステム”の取り組み

                                                                      dmm.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/

                                                                        組織のコード品質を向上させる “レビューシステム”の取り組み
                                                                      • 個人分担性がスタートアップの成長を殺す �〜協働でチームがめっちゃ進化する話〜

                                                                        ※ スクラムフェス仙台2023 で登壇した際の資料です。 スタートアップでの開発形態は、ウォーターフォールに依存しがちなJTCと違って、プロダクトバックログやカンバンぽいものを使ったアジャイル風の開発をしていることが多いです。 しかし一方で、そういったスタートアップにはプロダクトバックログはあっても、たいていPBIの1つ1つがやたらでっかくて、1つ1つにしっかり担当者がアサインされてて、何ならデッドラインまで記されています。 これを引き起こすのは、スタートアップ特有の個人分担制です。 多くのスタートアップ企業はたいてい、エンジニア1〜2名からスタートし、個々のエンジニアの馬力で開発をこなしていくところから始まります。このときのバリバリ個人開発なノリが、エンジニアが増えても継続してガチガチの個人分担制に移行しがちです。 このセッションでは、個人開発をこじらせたスタートアップ企業がどうやって個

                                                                          個人分担性がスタートアップの成長を殺す �〜協働でチームがめっちゃ進化する話〜
                                                                        • フロントエンドを Vue.js から React にリプレイスしたお話 (前編) - NTT Communications Engineers' Blog

                                                                          はじめての方、はじめまして。久しぶりの方、お久しぶりです。 イノベーションセンターの何縫ねの。(@nenoMake)です。 普段の業務ではソフトウェアエンジニアとして Node-AI という WEB アプリケーションの開発をしています。 パブリックな活動としては、好きな言語である C# 関係の OSS 開発や技術ブログの投稿、登壇などをしています。 ですが、今回は C# ではなくフロントエンドのお話をします...! この記事では今まで Vue.js 2.x で開発されていた Node-AI の WEB フロントを完全に捨て去り、React にリプレイスしたお話をつらつらとしていきます。 まずは前編ということで、リプレイスプロジェクト発足時の課題感からはじめ、プロジェクトの進め方や選定技術などについてお話しします。 後編には内部の設計などのより技術的なお話をしたいと思います。では前編スタート

                                                                            フロントエンドを Vue.js から React にリプレイスしたお話 (前編) - NTT Communications Engineers' Blog
                                                                          • 『晩餐歌』が爆発的ヒット tuki. 15歳の等身大インタビュー完全版 音楽活動は「ゆる~く趣味として」 | めざましmedia

                                                                              『晩餐歌』が爆発的ヒット tuki. 15歳の等身大インタビュー完全版 音楽活動は「ゆる~く趣味として」 | めざましmedia
                                                                            • アジャイル勘違い集 (2024) | Agile Studio

                                                                              DXの流れも相まって、アジャイル開発に取り組む会社が増えてきています。自社にも取り入れてみたいけれども不安がいっぱい、取り入れてはみたもののうまく行かない、そんなことありませんか?正しいアジャイルって...

                                                                                アジャイル勘違い集 (2024) | Agile Studio
                                                                              • アジャイルを導入したものの続けられなかったあなたへ 誤解や理解不足で起こる“もったいない”を解消するヒント

                                                                                アジャイルの「理論」や「理想」だけではない、 実際に実践したからこそ見えてきた「現実」に役立ったヒントを紹介したのは、マネジメントソリューションズ社の渡会氏。「Rebuild our Agile!」をテーマに掲げた「Agile Japan 2023」で、アジャイルのRebuildについて発表しました。全2回。前半は、「選択肢のRebuild」と「ロールのRebuild」について。 開発の考え方をウォーターフォール→アジャイルにRebuild 渡会健氏:みなさん、こんにちは。マネジメントソリューションズの渡会と申します。これから、「アジャイルで実際に困ったからこそアジャイルをRebuildした話」ということで講演させていただきたいと思います。よろしくお願いいたします。 (会場拍手) 最初に、私の自己紹介。この自己紹介の中にも、けっこうRebuildしたことが入っています。 最初の20年は、プ

                                                                                  アジャイルを導入したものの続けられなかったあなたへ 誤解や理解不足で起こる“もったいない”を解消するヒント
                                                                                • エラーや非同期処理をより安全に扱うための TypeScript ライブラリ Effect-TS

                                                                                  TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性(concurrency):Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ(composability):小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理(resource-safety):処理が失敗したとしても、安全にリソースを開放する 型安全性(type-safety):TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理(error handling):構造化された信頼性の高い方法でエラーを処理する 非同期性(asynchronicity

                                                                                    エラーや非同期処理をより安全に扱うための TypeScript ライブラリ Effect-TS