並び順

ブックマーク数

期間指定

  • から
  • まで

201 - 240 件 / 276件

新着順 人気順

プロジェクト管理の検索結果201 - 240 件 / 276件

  • なぜPMが25人も必要なのか - SmartHR Tech Blog

    こんにちは、CPOのadachiです。 この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿しています。 この企画にも関連するのですが、最近社外の方から「SmartHR、PM多!」という感想をいただくことが増えてきました。もしPMが多い = 裁量が小さくてつまらない環境、と思われていたら心外すぎる……許せねぇ…… そこで本稿では、なぜSmartHRには25人もPMがいるのか、一体なにを作っているのか、仲はいいのか、今後どういったオポチュニティがあるのか、といったことについて説明していきたいと思います。オポチュニティは言いたいだけです。 25人は多い? 結論、そんなに多くないと思っています。 先日「SmartHRがARR150億円を突破、前年比150%で成長」というプレスリリースも出ましたが、私たちは現在ARR 150

      なぜPMが25人も必要なのか - SmartHR Tech Blog
    • 君たちはどうコードをレビューする (される) か / 大吉祥寺.pm

      大吉祥寺.pm https://kichijojipm.connpass.com/event/314917/ https://blog.utgw.net/entry/2024/07/15/135648

        君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
      • エンジニアのための最小コミュニケーション術 - Qiita

        はじめに こんにちは。元ガチプログラマーのプレイングマネージャです。 できれば、プログラムをカタカタ打ってPC画面に向かって「いい感じのコードを書いちゃったなぁー」と独り言だけを言っていたい人間だったのですが、それだと仕事にならないなあと。 ということで最小限のコミュニケーションで仕事をする方法について考えたことをまとめておきたいと思います。 最小コミュニケーション術 『プロジェクトのゴールに対する』自分や相手の課題を解決できるようにコミュニケーションをとることが、コミュニケーションを最小にする方法と考えます。 相手の課題を解決するために自分となんらかの調整が必要なケースでは、相手の課題が解決するまではコミュニケーションが継続されますし、自分の課題についてもまたしかりです。 相手の質問の裏には、相手のプロジェクト上の課題が必ず存在します。相手の質問にそのまま答えても相手の課題が解決しなけれ

          エンジニアのための最小コミュニケーション術 - Qiita
        • 「『自由ソフトウェア』の開発にDiscordを使わないで」という主張

          オープンソースソフトウェアの開発プロジェクトで連絡用プラットフォームとしてDiscordを用いる例が多くあります。しかし、自由ソフトウェア(FOSS)の推進者であるドリュー・デヴォールト氏は「『自由ソフトウェア』の開発プロジェクトにDiscordを使うべきではない」と警鐘を鳴らしています。 Please don't use Discord for FOSS projects https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS.html Discordはユーザーが「○○というゲームについて話し合うサーバー」「○○愛好会のボイスチャット用サーバー」「GIGAZINEの公式サーバー」といったように自由にサーバーを作ることができるコミュニケーションアプリで、各サーバーではテキストや音声で会話できるほか、ファイルをアップロードした

            「『自由ソフトウェア』の開発にDiscordを使わないで」という主張
          • 技術者も知っておくべきプレゼン資料作成術:社内研修会レポート - Insight Edge Tech Blog

            Introduction こんにちは、データサイエンティストの善之です。 Insight Edgeの分析チームでは、有志が技術テーマについて1時間枠で講義し、チーム内でディスカッションを行う「技術研修会」を不定期に実施しています。 先日の研修会では、チーム内でのアンケート結果から最も希望が多かった「プレゼン資料作成術」をテーマに実施しましたので、そのレポートを行います。 技術とは少しテーマがズレますが、他の技術的テーマよりも希望が多く、他部署(開発チーム・管理部)からも参加希望があるなど、皆さん関心の高いテーマだと感じました。 今回は私の前職(コンサルティングファーム)での経験をもとに、プレゼン資料作成術についてお話ししました。 slackでのアンケート結果 目次 講義内容 ①全体のストーリーライン&各スライドのメッセージを作る ②各スライドのチャートを作成 ③ページをレイアウトする ④見

              技術者も知っておくべきプレゼン資料作成術:社内研修会レポート - Insight Edge Tech Blog
            • 【資料公開】価値創造と開発生産性

              みなさんこんにちは。@ryuzeeです。 2024年6月28-29日に開催の開発生産性Conference 2024で登壇しましたので、資料を公開します。 最近「開発生産性」という言葉を耳にする機会がすごく増えたような気がしますし、自分でもあるメディアの取材で「開発生産性」という単語を使ったのですが、なんとなくスッキリしない感じを抱えていました。 僕自身は「生産性」という単語の不透明さをさけるべく「開発生産性」を使ったのですが、これでも不透明さは残ったままだったわけです。 ということで、「開発生産性」が何を指すのかを深堀りした上で、この単語とどう付き合っていくべきなのかを整理したのが、このセッションです。 スライド全部を読む時間のない方もいると思いますので、以下に結論を書いておきます。 「開発生産性」に関心を持つ理由も、「開発生産性」の定義もさまざま 重要なのはコンテキスト 数字だけで全て

                【資料公開】価値創造と開発生産性
              • 朝会にファイブフィンガーを導入したらみんなの調子がわかりやすくなりました - Qiita

                これは何 自分の所属しているグループではスクラムを導入しているのですが、ある時メンバー間で業務を調整するためのコミュニケーションをもっと取っていきたいよねという話になりました。 具体的には、「重いレビューと重いタスクが重なってしまって余裕がない」、「ミーティングが多くて時間が足りない」、「体調不良で思うように働けない」などなどの個別の事情をもっと共有しあってチームで調整したいよねという内容です。 元々グループで毎日朝会を実施していて、そこに「困ったこと」を書くセクションを設けてはいました。 しかし、ちょっとした困りごとは「頑張ればなんとかなるし..」「わざわざ共有するほどでもないかな」といった感じで共有されづらい状況でした。 そんな時に以前『カイゼン・ジャーニー』で読んだ「ファイブフィンガー」を思い出し、チームに導入してみたら、些細な困り事が共有されるようになりました。 ファイブフィンガー

                  朝会にファイブフィンガーを導入したらみんなの調子がわかりやすくなりました - Qiita
                • 入社して1年半の間に先輩が5人育休に入った話 - Sansan Tech Blog

                  自己紹介 こんにちは。名刺メーカーDevグループの伊藤惇です。 私は2022年4月にSansanに新卒として入社して、現在に至るまで名刺データの作成および印刷発注をするサービスの開発に携わっています。 名刺メーカーDevグループでは、偶然タイミングが重なったこともあり、私が入社してからこれまでの間に5人が育児休暇を取得しました。 そうした中で感じた育休に対する考え方の変化を振り返りたいと思います。 なお、本記事はSansan Advent Calendar 2023の14日目の記事です。 名刺メーカー育休スケジュール 名刺メーカーDevグループの規模感 チームの人数やプロダクトのフェーズによっても育休のインパクトが変わってくるので、私が所属する名刺メーカーDevグループの規模感について補足しておきます。 チーム人数 後述するAさん、Bさん、Cさんの育休取得時は約15人ほどのチームでした。そ

                    入社して1年半の間に先輩が5人育休に入った話 - Sansan Tech Blog
                  • ラピダスから振り返る日本の国家プロジェクト

                    日本がラストチャンスとばかりに開始した「日の丸半導体」ラピダスに多大な公費が追加されていることが話題を集めている今日この頃。 心無い専門家たちからは必ず失敗するだの金ドブだの批判殺到中だが、本当に日本(経済産業省)主導の国家プロジェクトは今まで成功しなかったのだろうか? この記事では主に経済産業省、旧・通商産業省が中心となって始めた国家プロジェクトを振り返る。 超LSI国家プロジェクト(1976年)結論:成功簡単に:半導体製造の基礎研究に成功 大規模集積回路(LSI)の研究、特に基礎研究に力を入れた国家プロジェクト。 当時、半導体弱小国であった日本で700億円以上の金を基礎研究に投資するのは挑戦的であったが、電子ビーム露光技術などの研究レベルのアイディアを実用・量産レベルに持ってくることに成功。 よく「日本は半導体生産はダメだが、生産機械はまだシェアがある」というが、この40年前の国家プロ

                      ラピダスから振り返る日本の国家プロジェクト
                    • 昔、プロジェクトリーダーさんが、とある数百件のデータに差異があるか確認するのに、ウィンドウを左右に並べて目で確認していた話→「WinMergeを知らなかったのだろうか?」「ケースバイケースかな」

                      あや@ほわほわ @aya_howa 昔、プロジェクトリーダーさんが、とある数百件のデータに差異があるか確認するのに、ウィンドウを左右に並べて目で確認していたのです。その後PMに「センスがない!」と叱られていましたが、根気があってマメな人なんだろうなぁ…と面倒臭がり&自分の目を全然信用していない私は思ったものでした。

                        昔、プロジェクトリーダーさんが、とある数百件のデータに差異があるか確認するのに、ウィンドウを左右に並べて目で確認していた話→「WinMergeを知らなかったのだろうか?」「ケースバイケースかな」
                      • ボーイングの飛行機ドア脱落事故の調査で「監視カメラ映像が上書きされて重要情報が消えていた」ことが判明&社員が「安全より納期を優先する社内体制」を告発

                        アメリカの国家運輸安全委員会(NTSB)は、2024年1月6日に発生したボーイング737MAX9の壁面パネル脱落事故に関する調査を続けています。新たに、NTSBが提出した報告書によって「事故機のメンテナンス作業を記録した監視カメラの映像が上書きされている」ことが明らかになりました。さらに、ボーイングの現役従業員を名乗る人物が匿名掲示板Redditに登場し、ボーイングの内部事情を告発しています。 Senate Committee on Commerce, Science and Transportation on Boeing 737-9MAX Door Plug Blowout - Letter to Senate Committee on Commerce, Science & Transportation on Boeing 737-9 MAX Door Plug Blowout.pd

                          ボーイングの飛行機ドア脱落事故の調査で「監視カメラ映像が上書きされて重要情報が消えていた」ことが判明&社員が「安全より納期を優先する社内体制」を告発
                        • 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」が公開
                          • 「旧統一教会で人生を狂わされた」被害を訴える人々が待つ解散命令請求 一方教団は広大な土地を購入し“巨大プロジェクト”敢行【報道特集】 | TBS NEWS DIG

                            検討が続く旧統一教会への解散命令請求。内閣改造で教団と接点のある議員4人が新閣僚に就任する中、被害を訴える人々は早期の解散命令や献金の返還に不安を覚えています。9月13日、内閣改造を行った岸田総理。記者…

                              「旧統一教会で人生を狂わされた」被害を訴える人々が待つ解散命令請求 一方教団は広大な土地を購入し“巨大プロジェクト”敢行【報道特集】 | TBS NEWS DIG
                            • マネジメントの「もぐら叩き」からいかに抜け出すか。ミドルマネージャーが心得ておくべき「問いのデザイン」の新原則とは?|安斎勇樹

                              経営層の方針をチームに伝え、実行に移すミドルマネジメントの現場において、「問い」のデザインがますます重要になってきていると感じます。 本記事では、2023年10月に開催し、大変好評だったウェビナー「チームを覚醒させる「問い」のデザイン:新時代のミドルマネジメントの真髄」の内容より、「問い」を活用したミドルマネジメントの新原則について、ケーススタディとともにご紹介します。 『問いのデザイン』の大幅アップデートを目指して2020年に刊行した『問いのデザイン』の出版から4年近くが経ち、内容の改訂を検討しはじめています。特に組織の課題解決を担うミドルマネジャーに向けてコンテンツを肉付けし、アップデートに取り組んでいるところです。 きっかけは、2023年10月に開催したウェビナーでした。2023年6月にはじめて開催した一般向け大型ウェビナー「新時代の組織づくり」が非常に好評だったことを受け、その第二

                                マネジメントの「もぐら叩き」からいかに抜け出すか。ミドルマネージャーが心得ておくべき「問いのデザイン」の新原則とは?|安斎勇樹
                              • プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita

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

                                  プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita
                                • 「どうしてAngularは流行らないのか」と言われて思うこと | Marginalia

                                  最近に限らず、ここ数年ずっと目にするし、聞かれることもあるこの話について、いくつかの思うこと、ぼやきを書いておく。あとで参照できて便利なので。 1. あなたが使い始めれば少なくとも昨日よりは広まりますよ好きなら使えばいいと思うので僕には気持ちがわからないのだが、好き・気になるけど流行ってないから使わないという心理があるらしい。企業での判断ならわかるが、個人でそれはまったくわからん。仮にそれがマジョリティだとしたら、使われなければ流行らないのに流行らないと使われない、デッドロックで詰みです。 あなたが使ってみてそのことを発信すれば、少なくとも昨日より世界で一人分は使用者が増えます。その積み重ねでしか普及しません。ですので、流行って欲しいと思うならまず自分から使って周りに広めてください。 2. そもそも「流行っている」とは?僕が思うに、「流行っている」ということと「広く普及している」ということ

                                    「どうしてAngularは流行らないのか」と言われて思うこと | Marginalia
                                  • マネジャーが得意な日本人、リーダーになりたがるアメリカ人 イノベーションを生む、マネジメントとリーダーシップの割合

                                    リーダーシップとマネジメントの違い 井上和幸氏(以下、井上):前半で話があった自律型4.0は、今日聞いておられるみなさんはたぶん好まれる方が多いと思うのですが、一方で、自律型では自分で決めていくことが求められたり、方向づけを自分でしないといけないとか、概ねすべてについて自責になります。 それは人によってはしんどいことで、どちらかというとまず「こうしていきなさい」と言ってもらったほうがやりやすい人はいると思います。 小杉俊哉氏(以下、小杉):そうですね。 井上:小杉さんもあると思うんですけど、僕らも次世代役員研修の時に一番根幹テーマになるのが、これまではあえて言えば1.0もしくは1.Xだったけど、「いや、それじゃ駄目だ」と。それを転換する役員陣になってほしいみたいな話は多いですね。 先ほど名前が挙がった会社もそれを継いでくれる1.0のリーダーが出てくればいいけど、たぶんほぼ無理です。 小杉:

                                      マネジャーが得意な日本人、リーダーになりたがるアメリカ人 イノベーションを生む、マネジメントとリーダーシップの割合
                                    • 個人的におすすめしたいFeature-Sliced Designというフロントエンドアーキテクチャ設計方法論

                                      Feature-Sliced Designというフロントエンドアーキテクチャ設計方法論をプロジェクトに導入してみたところ、 個人的には良いと感じているので、どのような設計方法論なのか、具体的にどのような部分が良いと感じたかを紹介していきたいと思います。 Feature-Sliced Designとは? Feature-Sliced Designは、フロントエンドアプリケーションを対象としたアーキテクチャ設計方法論です。公式サイトでは、「コードを整理するためのルールと規約の集大成」と記載されています。 Feature-Sliced Designの設計方法論 Feature-Sliced Designでは、プロジェクトはLayerで構成され、各LayerはSliceで構成され、各SliceはSegmentで構成されます。 Layer Feature-Sliced Designの第一階層をLay

                                        個人的におすすめしたいFeature-Sliced Designというフロントエンドアーキテクチャ設計方法論
                                      • FMV同梱「エアホッケー」がブラウザ版で復活した経緯とは?ソースコードもない状態からの移植秘話 レバテックラボ(レバテックLAB)

                                        FMV同梱「エアホッケー」がブラウザ版で復活した経緯とは?ソースコードもない状態からの移植秘話 2024年5月7日 ダットジャパン株式会社 「エアホッケー@GAMEPACK」ブラウザ版 開発ディレクター/プロジェクトマネージャー 新田 大手ゲーム会社にて約7年ゲーム開発に携わった後、2020年に、建設分野を中心にソフトウェア開発を手がけるダットジャパン社に入社。エンジニアとしての知見やスキルを生かし、プロジェクトマネジメント・営業・マーケティングなどを幅広く担当。今回は「エアホッケー」の主人公である「ゆうた」のアイコンにて出演。 ダットジャパン株式会社公式サイト 2000年ごろから2010年代にかけて、富士通・FMVシリーズのパソコンには購入時のバンドル(同梱)ソフトとして「GAMEPACK(ゲームパック)」というミニゲーム集が付属していました。中でも「エアホッケー」は、現在でもYouTu

                                          FMV同梱「エアホッケー」がブラウザ版で復活した経緯とは?ソースコードもない状態からの移植秘話 レバテックラボ(レバテックLAB)
                                        • 変更履歴を記録する

                                          Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian

                                            変更履歴を記録する
                                          • 食べログの大規模販売管理システムを財務会計SaaSシステムに置き換えた話 - Tabelog Tech Blog

                                            目次 目次 はじめに 1章 課題の認識とZuora導入の決断まで 販売管理システムの課題 何を最初にやるべきか 実情を知る 理想像を固める 何を作り、何を作らないか どのSaaSを使うか 2章 Zuora導入設計 Zuoraプロジェクトチーム体制 Zuoraを知ろう! Zuoraプロジェクトにおいて何を開発するのか Zuoraの管理画面を使うか、それとも内製で作るか 新設機能のモック作成 食べログとのマッピング 3章 Zuora移行 データ移行 データ検証 突合バッチによる検証 データプールの副産物 最終的なシステム構成 データ切り替え 4章 Zuora運用 財務突合 Zuoraへの切り替え Zuoraでの運用開始 5章 結論 最後に はじめに こんにちは! 食べログ開発本部飲食店システム開発部でマネージャーをしている新井です。 2018年に食べログに入社し現在は販売管理チームに所属してお

                                              食べログの大規模販売管理システムを財務会計SaaSシステムに置き換えた話 - Tabelog Tech Blog
                                            • Google Cloud案件を1年半程度経験してみてAWSと比較しながら違いを整理してみた - NRIネットコムBlog

                                              本記事は 【Advent Calendar 2023】 15日目の記事です。 🎄 14日目 ▶▶ 本記事 ▶▶ 16日目 🎅 はじめに 想定している読者 一覧 まとめてみて 参考 はじめに クラウド事業推進部の小野内です。昨年5月にキャリア入社してから早1年半以上が経ちました。 入社以降、AWS、Google Cloud のデータ分析基盤の開発・運用に関わっておりますが、現在はGoogle Cloud メインでやってます。 試行錯誤の毎日ですが、Google Cloud案件をどんどん盛り上げていきたい所存です。 1年ほど前の投稿記事では、 Google Cloudの学び方について触れましたが、本記事ではGoogle Cloud案件を1年半程度経験してみて、 AWSと比較しながら、Google Cloudの主要なサービスについて、違いを整理しました。 想定している読者 AWS案件に半年以

                                                Google Cloud案件を1年半程度経験してみてAWSと比較しながら違いを整理してみた - NRIネットコムBlog
                                              • 出荷目安アイコンを改善するのに9か月もかかって辛かったので、システム分割を爆速で進めてリードタイムが9分の1になった話 - MonotaRO Tech Blog

                                                こんにちは。2019年に初々しい記事を書いていた山本です。今でも元気にモノタロウで働いております。 この記事では、社内カンファレンスで私が業務部門向けに行ったプレゼンテーションを基に、マイクロサービス化に踏み切ったエピソードを紹介します。モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス と被る部分もありますが、同じ内容でも今回は易しめに解説していますので、空き時間にでもさらっとお読みください。 -- --まさか共通化されてないなんて 2022年の暮れに、こんな改修依頼を受けました。私はプロジェクトの開発リード担当でした。 出荷目安アイコンとは、当社商品が何日で出荷されるかを表すアイコン群のことです。 正確な値を表示するように工夫していますが、モノタロウでは自社在庫を含む様々なパターンの出荷があり、当時拡大が進んでいた「サプライヤ在庫連携」では特に出荷

                                                  出荷目安アイコンを改善するのに9か月もかかって辛かったので、システム分割を爆速で進めてリードタイムが9分の1になった話 - MonotaRO Tech Blog
                                                • 作業者じゃなく開発者でありたい - id:onk のはてなブログ

                                                  自分がこうありたいというメモ。 作業者と開発者の違いとして、問題解決への寄与だとか、創意工夫の余地があるかというのがありそう。 これは今 GPT-4 に聞いた。 Q: 作業者と開発者の違いを100文字ぐらいで教えて。 A: 作業者は指定されたタスクや手順を実行する人を指し、特定のルーチンや手順に従って作業を進めることが主な役割です。一方、開発者は新しい製品やソフトウェアを設計・構築する人を指し、創造性や技術的なスキルが求められます。作業者は指示に従い行動し、開発者は新しいアイディアや解決策を生み出します。 単なるタスクの遂行でなはく、より多くの責任とリーダーシップを求めている コードを書くだけではなく、問題解決や創意工夫の余地が多くあるタスクが欲しい 自分のアイディアをベースとして、形にすることで、プロジェクトを完遂したい そもそも何が問題なのかを明らかにするだとか、最適な解決策を見つける

                                                    作業者じゃなく開発者でありたい - id:onk のはてなブログ
                                                  • OpenAI創業者も認めたタスク管理ツール「Linear」が評価額4億ドルに | Forbes JAPAN 公式サイト(フォーブス ジャパン)

                                                    人工知能(AI)やフィンテック関連を含む数多くのスタートアップが利用するプロジェクト管理ツールが「Linear」だ。4年前、同社CEOのカーリ・サーリネン(Kaari Saarinen )がLinearをリリースすると、開発者を中心に2カ月で1万人が登録した。その1年後に一般公開されたときには、すでに1000社以上が利用していた。 同社のウェブサイトには、顧客企業としてAIユニコーンのCohere(コヒア)やRunway(ランウェイ)、フィンテックユニコーンのRamp(ランプ)など、飛ぶ鳥を落とす勢いのスタートアップの名前が記載されている。 Linearは今、大企業の顧客を獲得しようとしており、その実現のためにシリーズBラウンドで3500万ドル(約52億円)を調達した。このラウンドは、ベンチャーキャピタルのアクセルが主導し、テック企業の創業者らが多く参加した。関係者によると、Linearの

                                                      OpenAI創業者も認めたタスク管理ツール「Linear」が評価額4億ドルに | Forbes JAPAN 公式サイト(フォーブス ジャパン)
                                                    • ベンダー社員過労死の遠因はユーザー企業にもあるのか

                                                      ベンダー社員過労死の遠因はユーザー企業にもあるのか:「訴えてやる!」の前に読む IT訴訟 徹底解説(111)(1/2 ページ) 仕様確定が遅れ、プログラム数が大幅に増え、スケジュールが2カ月以上遅れ、しかも納期順守を求められたプロジェクト。そこに従事するエンジニアがある日、遺体で見つかった――。 連載目次 IT業界でバブル景気が生き残っていた1990年代、ソフトウェアエンジニアの長時間残業は常態化していた。金融機関向けシステム開発に従事していた私も、月の残業が100時間を下ることがなかった。 もっともそんなのは序の口で、私の周囲には、土日もほとんど休まず平日も徹夜で、残業が200時間をはるかに超えるエンジニアもいた。こうした長時間労働が元で心身に異常を来し、残念ながら命を落としてしまう人もいた。IT業界ではこうしたことがままあり、本連載でも以前、システムエンジニアの死をテーマにした記事を書

                                                        ベンダー社員過労死の遠因はユーザー企業にもあるのか
                                                      • 複数プロジェクトのカニバリを避け成果を最大化するために “プログラムマネジメント” を導入した話 - MonotaRO Tech Blog

                                                        こんにちは、モノタロウの EC サイト開発グループに所属している田上といいます。 モノタロウには 2019 年に中途で入社し、入社以来ずっとフロントエンドまわりのことに携わっています。最近は開発業務ではなくプロジェクトマネジメントなどのマネジメント業務をすることが多いです。 さて、どんな企業でも、新規事業の立ち上げや既存事業の改善など、複数のプロジェクトが並行で進むことはよくあることかと思います。 しかし、それらを推進していく中で、 A プロジェクトの成果として改善した ○○ の指標が、B プロジェクトの結果によって相殺されてしまった! △ さんがいろんなプロジェクトで引っ張りだこになって、結局どのプロジェクトもその方がブロッカーとなりうまく進まなかった! みたいな事態に遭遇したことはないでしょうか? こういった「複数のプロジェクト間で目標や成果、リソースのバッティングが発生して成果が最大

                                                          複数プロジェクトのカニバリを避け成果を最大化するために “プログラムマネジメント” を導入した話 - MonotaRO Tech Blog
                                                        • Slackにプロジェクト管理機能が追加、「Slackリスト」正式リリース。タスクリストなどの作成と共有が可能に

                                                          Slackにプロジェクト管理機能が追加、「Slackリスト」正式リリース。タスクリストなどの作成と共有が可能に セールスフォースはSlackの新機能として、プロジェクト管理機能を実現する「Slackリスト」の正式リリースを発表しました。 Introducing Slack lists Manage projects from start to finish, directly in Slack Take on tasks as a team, right where you’re already working Automate and triage requests with workflows in lists https://t.co/KDiiDiC9T6 pic.twitter.com/mAZbwaTBZ7 — Slack (@SlackHQ) June 6, 2024 Slack

                                                            Slackにプロジェクト管理機能が追加、「Slackリスト」正式リリース。タスクリストなどの作成と共有が可能に
                                                          • フロントエンドを 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
                                                            • ソニーにおけるプロダクトマネジメント スマホアプリ事例紹介

                                                              「吉羽龍太郎さんとソニーが語るプロダクトマネジメント」 イベントの資料です。 イベント概要 https://sony.connpass.com/event/319013/ 動画 https://www.youtube.com/live/Y7gFsorBO6c

                                                                ソニーにおけるプロダクトマネジメント スマホアプリ事例紹介
                                                              • 要件定義の目的とゴールとは - TRACERY Lab.(トレラボ)

                                                                TRACERYプロダクトマネージャーのharuです。 「要件定義とは何を目的としたプロセスなのか?なにが出来たら完了なのか?」 はじめて要件定義する人は、ここで詰まってしまうことが多いようです。 要件定義は、設計や実装に比べて、具体的な作業がイメージしにくいプロセスです。 そのような背景もあってか、2023年4月のBPStudy#188〜要件定義を学ぼう。ChatGPTを添えてに私が登壇した時の以下のスライドには、945個のはてなブックマークをいただきました*1。 speakerdeck.com 945というブックマーク数は、要件定義というものを具体的にイメージしにくいと感じている人が世の中に多いことの現れかもしれません。 そこで「要件定義とはそもそも何か」について、何回かの記事に渡って説明します。 この記事では要件定義の目的とゴールについて説明します。 プロジェクトの数だけ存在する開発プ

                                                                  要件定義の目的とゴールとは - TRACERY Lab.(トレラボ)
                                                                • 最近出社して対面で会話することが多くなった結果、生産性に繋がりそうな会話があった話3選

                                                                  みなさんこんにちは。 都内のIT企業でフロントエンドエンジニアをしてますSakuです。 ここ1、2ヶ月くらいオフィスに出社して仕事をすることが多かったのですが、そこで、「あれっ…意外と仕事が捗るな…」と感じることがあったので、そこで感じたことを整理するため言語化してつらつら書きたいと思います。 その発端としては、最近新しいプロジェクトが始まり、その開発のチームリーダーという役割もあったため、まあ折角だしオフラインでチームビルディングやどういうプロダクトにするかなどをエンジニア・ビジネスサイドのメンバーと話し合うのも良いかなと思い、軽い気持ちで他のメンバーにも声をかけて出社の機会を作ってもらったのが始まりです。 それから週に何日かは出社して仕事をしていたのですが、ある時ふと思ったのが、冒頭で感じた意外と仕事が捗る感でした。 本題に入る前に、話は4年前に遡ります。 コロナ禍で生活が変わった 昨

                                                                    最近出社して対面で会話することが多くなった結果、生産性に繋がりそうな会話があった話3選
                                                                  • アジャイル勘違い集 (2024) | Agile Studio

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

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

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

                                                                        アジャイルを導入したものの続けられなかったあなたへ 誤解や理解不足で起こる“もったいない”を解消するヒント
                                                                      • Vite ってよく聞くけど何なんですか? あれは

                                                                        初めに Vue.js の学習をしているとよく「Vite」という単語を目にすると思います。 一体全体あれはなんなのでしょうか?? なんだかよく分からないコマンドを打つと、いつの間にかプロジェクトが作成されていたり、 ファイルを編集するだけでブラウザで動くようになっていたりします。 そもそも読み方も良くわかりません 😵‍💫 (ヴィテ...? ヴァイト...?) この記事では、Vite についての基本的な情報をまとめてみます。 発音? 発音の仕方は「ヴィート」です。こちらは公式ドキュメントにも書かれています。 Vite(フランス語で「素早い」という意味の単語で /vit/ ヴィートのように発音)は、 しかし、実はこれにはやや表記揺れがあって、「ヴィット」と表記されているところもあります。 例えば、話題になった Kawaii ロゴではそのように表記されています。 まぁこれらはカタカナ表記の限界

                                                                          Vite ってよく聞くけど何なんですか? あれは
                                                                        • ヒアリングを超えていく、デザインの初期対応|大﨑 優|CONCENT

                                                                          ヒアリングに行くのではない。最初から価値を与えること。これは、プロジェクトの初期対応でデザイナーが取るべき基本的な態度です。 今回のテーマは、デザインの初期対応。その効果的な動き方を紹介します。 デザインプロジェクトのスタートは、他者から依頼を受ける場合と、デザイナー側から提案を始める場合の2つのパターンがありますが、今回はそのうちの「デザイナーが依頼を受けるパターン」について。 初期対応の時点で、デザインの成果の半分は決まってしまいます。それくらい重要なものですが、なせかデザインの世界ではあまり論点化されていません。自分の経験が何かの役に立てばとの期待を込めて。どうぞ。 ヒアリングじゃない。ディスカッションだ。依頼や問い合わせを受けてデザイナーが初期対応すること。これをヒアリングと呼ぶこともありますが、それには注意が必要です。 最初に関係性が固定されるヒアリングに行く。情報を聴きに行く。

                                                                            ヒアリングを超えていく、デザインの初期対応|大﨑 優|CONCENT
                                                                          • 結局のところ、エンジニアリングマネージャーとは何者なのか|dora_e_m

                                                                            はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象

                                                                              結局のところ、エンジニアリングマネージャーとは何者なのか|dora_e_m
                                                                            • 【虎の穴ラボ】根っから小売文化の組織がエンジニアファーストに生まれ変わるまでの一部始終

                                                                              虎の穴ラボ株式会社 CEO 野田純一 大学卒業後、受託開発の会社に入社。その後DeNAにてゲーム開発に関わったのち、GMOへ入社。アドテク開発や研究に取り組む。2016年に虎の穴ラボの前身であるユメノソラHDに入社し、当時新規事業だったFantiaの開発の傍ら、開発組織の環境整備やエンジニア採用に取り組む。2019年10月、ユメノソラHDのエンジニア組織が「虎の穴ラボ株式会社」として分社化し、CTOに就任。2023年9月より現職。 美少女のイラストに「エンジニア採用!」「今後もずっとフルリモート!」の文字が踊る。一度は目にしたであろう、あの個性的な採用広告の広告主は「虎の穴ラボ」。同人誌通販「とらのあな」を運営するユメノソラホールディングス株式会社から分社したエンジニア・クリエイター組織です。 現CEOの野田純一さんは元GMOのシニアエンジニア。ユメノソラにはエンジニア組織の立ち上げ・拡大

                                                                                【虎の穴ラボ】根っから小売文化の組織がエンジニアファーストに生まれ変わるまでの一部始終
                                                                              • 「Asana、Jooto、Wrike……、無料で使えるカンバンボードを徹底比較!」――急遽テレワークを導入した中小企業の顛末記(172)【急遽テレワーク導入!の顛末記】

                                                                                  「Asana、Jooto、Wrike……、無料で使えるカンバンボードを徹底比較!」――急遽テレワークを導入した中小企業の顛末記(172)【急遽テレワーク導入!の顛末記】
                                                                                • 年間一億円削減した時系列データベースのアーキテクチャ改善~不確実性の高いプロジェクトへの挑戦~

                                                                                  「Developers Summit 2024 Summer」での発表資料です。

                                                                                    年間一億円削減した時系列データベースのアーキテクチャ改善~不確実性の高いプロジェクトへの挑戦~