並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 547件

新着順 人気順

アジャイルの検索結果41 - 80 件 / 547件

  • 「これぐらいのことはできていて」は勝手な期待 観察・考察・選択のサイクルで相手の力を引き出す「誰も嫌な思いをしない変化」

    「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。2回目は、誰も嫌な思いをしない変化のために実践したことについて。前回はこちらから。 誰も嫌な思いをしない変化のために「相手に期待しない」 椎葉光行氏:その頃の自分と、今の自分でいろいろと変わったとは思うんですけど、大きくこの2つかなと思います。 「相手に期待をしなくなった」それから「相手の気持ちを考えなくなった」です。 言葉にすると、人としてどうなのという感じがしますけど(笑)、でもこの2つが自分の中でけっこう大きな軸になっています。 何年か前に、娘が「2桁のかけ算教えて」っ

      「これぐらいのことはできていて」は勝手な期待 観察・考察・選択のサイクルで相手の力を引き出す「誰も嫌な思いをしない変化」
    • 「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか

      *文字かすれ修正しました Developers summit 2022 発表資料です。 元ネタはこちらのnoteです。 https://note.com/miz_kushida/n/n103a7da460c5 Twitter https://twitter.com/miz_kushida

        「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか
      • エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく|mtx2s

        組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ

          エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく|mtx2s
        • 社内勉強会で専門的技術力を高めるには

          ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯(ヤフー内のスキル任命制度/ネットワーク・セキュリティ)に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書

            社内勉強会で専門的技術力を高めるには
          • 現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ

            この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです(これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE)。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出

              現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
            • 目標設定の基本

              NTT Com Open TechLunch #7「エンジニアリングマネージャー と 目標設定」の登壇資料です。20分くらいの短いセッションなので網羅的ではありません 2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2

                目標設定の基本
              • ゲーム企画コンテストPERACONにおける審査員の問題 - じじいのプログラミング

                注意点 「CEDEC2020のPERACONが参加人数が多すぎて、提出物の質が低くなった」という問題については、書いてません。あくまで審査員の質についてだけを書いています。*1 記事を書くにあたって、審査員は匿名で書きたかったのですが、 審査員全員の名前が公開されていて、中途半端に匿名にしても無意味なこと。 根本的な問題では、反省はしてなさそう。 審査員にも責任があるべきといっていること。 なので、審査員の実名を出しました。ただ、悪い部分だけをピックアップすることはないように、できるだけ多くのデータを出し、客観的に判断するように心がけました。 はじめに CEDECというゲーム業界のカンファレンスで、PERACONというゲーム企画コンテストがあります。今年からはCESAというゲーム業界最大の団体の人材育成部会で引き取って、毎年人材を育成するという目的で行っていくことになったようですが、これか

                  ゲーム企画コンテストPERACONにおける審査員の問題 - じじいのプログラミング
                • 「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に

                  Search, watch, and cook every single Tasty recipe and video ever - all in one place! News, Politics, Culture, Life, Entertainment, and more. Stories that matter to you.

                    「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に
                  • 『リングフィット アドベンチャー』ゲームとフィットネス、混ぜるな危険のゲームデザインが成立するまでの苦労【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com

                    2020年9月2日~4日、初のオンライン開催というかたちで行われたCEDEC 2020。本稿では、最終日の9月4日に行われた、任天堂の河本浩一氏と松永浩志氏による“『リングフィット アドベンチャー』~混ぜるな危険! ゲームとフィットネスを両立させるゲームデザイン~”の内容をリポートする。

                      『リングフィット アドベンチャー』ゲームとフィットネス、混ぜるな危険のゲームデザインが成立するまでの苦労【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com
                    • 問い合わせ率が3年間で半分になった

                      こんにちは。カンムで業務部長してます平湯(ひらゆ)です。 カンムは現在、Visaプリペイドカードの「バンドルカード」と手元の資産形成に活用できるクレカの「Pool」の2つの事業をやっています。今回はバンドルカードのお話です。 2022年末に過去の問い合わせ率を集計したところ、一番多かった時期と比べると問い合わせ率が半分になってました。(問い合わせ率 = 問い合わせ数 / 稼働会員数) 良きタイミングなので頑張ってきたことを振り返ってみます。 どんなことをやったか一次情報から課題特定 →問題提起 →オペ整備 →リリースのサイクルを回した結果です。何よりも一次情報の取得が大事です。時間がかかるし、単純作業なので苦しいんですが、生の声を読むことで感情や背景が頭に染み込みます。問題により深く入り込めているという感じでしょうか。 この課題の解決策をエンジニア・デザイナー陣と考えていきます。カンムはエ

                        問い合わせ率が3年間で半分になった
                      • エンジニアのための自己管理入門 - Qiita

                        はじめに 社内でTodo管理の勉強会を実施した際に作成した資料があったのですが、今回自分の中の考えをまとめるせっかくの機会だと思い、字面で書き起こすことにしました。 意外と世の中では語られることのなく、『あたりまえ』として扱われてしまう『自己管理』について自分が半年間運用し、週ごとにカイゼンを続けたどり着いた、現時点でのHowを多くの人に伝えられればなと思っています。 もちろん最適解がこの形とは言いませんし、自己管理は人の数分だけ最適解はあると思っています。「みんな正しい、ただし部分的に」ということを念頭に、楽しんで読んでいただければ幸いです。 タイトルを付けた理由としては、かなりシステマチックな内容になってしまっていると感じてしまったため、「運用レベルが高い」人物を想定した結果、このタイトルになりました。 概念篇 『自己管理』を行っていく上で、確実に「ここは飛ばしてはいけない」と思ったた

                          エンジニアのための自己管理入門 - Qiita
                        • 現代的システム開発概論

                          2023年度リクルート エンジニアコース新人研修の講義資料です

                            現代的システム開発概論
                          • 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience

                            2022-12-21 技術的負債の返済から改善する開発者体験 - Techmee vol.5 https://timeedev.connpass.com/event/268296/ 動画 https://youtu.be/tQ3BGgnvMwQ

                              技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
                            • 学びのススメ vol.3:IPA 独立行政法人 情報処理推進機構

                              学び続けている実践者の方からお話を伺いました。 ご自身の組織や個人としての学びのご参考になれば幸いです。 岩手県釜石市出身。株式会社翔泳社 取締役。日本最大級のITエンジニアイベント「Developers Summit (通称:デブサミ)」を、2003年の第一回より10年以上コーディネートし、異種の技術領域に携わるエンジニアが一堂に会することのできる、中立かつオープンで多様なイベントの開催を支えたことにより、楽天テクノロジーアワード2012 ルビー賞を、自宅の倉庫に置いた箱庭ライブラリの運営に対し、本を通じた人と人とのつながりを生み出し、地域にも貢献する活動として、大阪府立大からマイクロ・ライブラリーアワード2018を受賞。コンピュータ出版販売研究機構会長を2016年4月~2020年9月まで務め、コンピュータ書の棚分類コードの整備やこどもプログラミング書籍の棚作り、小学校への推進を行った。

                              • アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021

                                アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか? という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応

                                  アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021
                                • 僕たちはリモートワークに振り回されていた。Gatherを使うまでは。|shikajiro

                                  最初の金曜日「今までの働き方ではだめだ」代表からそんな発表があった。業績は上向いている。利用者も右肩上がりで増えている。でもだめだ。この程度じゃだめだ。誰しもがそう考えざるを得ないのは分かってたし、みんな壁にぶつかっていたのも分かっていた。もっと圧倒的スピードで成長しなくてはいけないのに、今までのように息を吸うようにコミュニケーションして前に進むことができない。うまく噛み合わない。すれ違う。伝わらない。誰かの失敗と同じ過ちを別の誰かが再現してしまう。会社に重りを結び付けられたかのように思うように進めない。これは一体何なのか。その正体にみんな薄々気づいていた。それは リモートワーク中心によるコミュニケーション不全 という大きな重りだった。 Ubieは決してコミュニケーションを疎かにしているわけではない。必要なミーティングであれば密に行う。スクラムを導入しメンバー間でコミュニケーションを取り、

                                    僕たちはリモートワークに振り回されていた。Gatherを使うまでは。|shikajiro
                                  • やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手

                                    2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか?要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった! ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ

                                      やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
                                    • 質とスピード / Quality and Speed

                                      質とスピード 初演: 2019/10/31 @ EOF2019

                                        質とスピード / Quality and Speed
                                      • 市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ

                                        エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて?どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗

                                          市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
                                        • 都の行政手続き98%をデジタル化へ 元ヤフー社長の東京都宮坂副知事の戦略 withコロナで変わる国のかたちと新しい日常㉔|FNNプライムオンライン

                                          新型コロナウイルスの感染拡大で、私たちの生活、国や企業のかたちは大きく変わろうとしている。連載企画「withコロナで変わる国のかたちと新しい日常」の第24回は、コロナを機に変わる自治体のデジタル戦略だ。 東京都では3月4日に「新型コロナウイルス感染症対策サイト(以下サイト)」を立ち上げた。自治体のものとは思えない見やすさと利便性の高さが一躍話題となった、このサイトの開発を主導したのがヤフー元社長で昨年9月に副知事に就いた宮坂学氏だ。 6月5日、都庁の副知事室で、ラフな黒いTシャツ姿の宮坂氏に話を聞いた。 東京都副知事宮坂学氏は、元ヤフー社長という異色のキャリアの持ち主 この記事の画像(4枚) サイトは3ヶ月で1千件以上改善している サイトの開発には「オープンソース」という、これまで行政で見られなかった手法が導入された。プログラムのソースコードを公開し、世界中のエンジニアがサイトの修正を提案

                                            都の行政手続き98%をデジタル化へ 元ヤフー社長の東京都宮坂副知事の戦略 withコロナで変わる国のかたちと新しい日常㉔|FNNプライムオンライン
                                          • コロナウイルスにかかったら飲んではいけない薬:フランスの厚生大臣が発表(今井佐緒里) - エキスパート - Yahoo!ニュース

                                            フランスの厚生・連帯大臣Olivier Veran。神経科医で39歳という若さだ(写真:代表撮影/ロイター/アフロ) 【注!】慢性疾患で、医師の処方でイブプロフェンを服用している人は、勝手に中断せずに、必ず医者に相談してください。あるいは、具合が悪くなってきているのに自己判断で飲み続けないで、必ず医者に相談してください。これはフランスでも盛んに発せられている注意です! フランスの厚生大臣オリヴィエ・ヴェラン氏が、新型コロナウイルス感染症に関して、イブプロフェンを服用しないほうがよいと推奨した。 イブプロフェンとは、非ステロイド性の抗炎症薬(NSAID)に属する。これは、炎症や痛みなどを抑え、熱を下げるために使われるものだ。しかしこの薬は、既にかかっている感染症を悪化させ、合併症を伴わせる可能性があるのだという。(筆者注:イブプロフェンは市販の薬に使われている) 参照記事:非ステロイド性抗炎

                                              コロナウイルスにかかったら飲んではいけない薬:フランスの厚生大臣が発表(今井佐緒里) - エキスパート - Yahoo!ニュース
                                            • Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録

                                              はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解

                                                Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
                                              • 要はアジャイルは行き当たりばったりってことですか?

                                                回答 (10件中の1件目) 逆に「行き当たりばったらない」進め方ってどんなのだろうなって考えてみると少しわかるかもしれないです。 「あれ?おかしいな?こんなはずじゃなかったんだけどな?まあいいや、予定通り進もう」 こんな感じのプロジェクトでしょうか。ヤバい予感しかしません。 アジャイルを計画を立てないことの免罪符として使う人が非常に多い(個人の感想です)ので、こうした質問はよく聞く気がします。 特にマニフェストに書かれている、 > 計画に従うことよりも変化への対応を アジャイルソフトウェア開発宣言 より ってあたりを曲解して、計画がないから進捗は常にグリーンなのだ!くらい...

                                                  要はアジャイルは行き当たりばったりってことですか?
                                                • "言われたことしかやらないのはダメ"という日本の考え方は独特→海外委託で衝突する原因やマネジメントの機能の話へ

                                                  syacyo @syacyo_twit みずほの件がお昼のニュースで取り上げられてたけど『言われたことしかやらないような担当者の意識を改革する』って言ってた。 これは日本独特の考え方。日本以外の作業者は普通は言われたこと以外はやらない。なので欧米はマネジメント層が優秀だし高給。 syacyo @syacyo_twit 日本は精神論、根性論を盾にマネジメント層が圧力をかけて作業者がなんでもかんでも気を利かせて動くように強要する文化ができあがってしまっている。 本来はマネジメントする側が綿密に各自の作業内容を分担して、それ以外はやるな、とまで指示するのが正しい姿なのよ。 syacyo @syacyo_twit だからオフショア開発で外国勢に作業依頼したときに成果物が酷くてなぜ◯◯していないんだ、と問い合わせると オフショア『それは指示されていない』 と普通に返ってくる。 これで怒る日本人は自ら

                                                    "言われたことしかやらないのはダメ"という日本の考え方は独特→海外委託で衝突する原因やマネジメントの機能の話へ
                                                  • 同期エンジンの心臓部を書き換える

                                                    0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン(コードネーム「Nucleus」)をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着

                                                      同期エンジンの心臓部を書き換える
                                                    • 良いコードとは何か - エンジニア新卒研修 スライド公開

                                                      株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575

                                                        良いコードとは何か - エンジニア新卒研修 スライド公開
                                                      • さよならアーキテクチャ議論|Seiji Takahashi@ベースマキナ

                                                        ポエム。 つまり?予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

                                                          さよならアーキテクチャ議論|Seiji Takahashi@ベースマキナ
                                                        • Henry 🤡🦊🐵 on Twitter: "スクエニが公開したPM講座。 著者は2011年当時CTOだった橋本善久氏。 氏はこの後、酷い初代FF14の立て直しに貢献し成功に導いている。 10年経っても色褪せておらず、プロジェクト管理に携わる方は必読。 画像は抜粋したも… https://t.co/qGRAg2n5q6"

                                                          スクエニが公開したPM講座。 著者は2011年当時CTOだった橋本善久氏。 氏はこの後、酷い初代FF14の立て直しに貢献し成功に導いている。 10年経っても色褪せておらず、プロジェクト管理に携わる方は必読。 画像は抜粋したも… https://t.co/qGRAg2n5q6

                                                            Henry 🤡🦊🐵 on Twitter: "スクエニが公開したPM講座。 著者は2011年当時CTOだった橋本善久氏。 氏はこの後、酷い初代FF14の立て直しに貢献し成功に導いている。 10年経っても色褪せておらず、プロジェクト管理に携わる方は必読。 画像は抜粋したも… https://t.co/qGRAg2n5q6"
                                                          • ただの思い付きを「価値あるアイデア」と思い込む人が分かっていないこと

                                                            先日、こんな記事を拝読しました。 ゲーム会社の「アイデアの押し売り」への防衛策が注目集める。一方的に送りつけられたゲームのアイデアが行き着く先とは この条項は一見すると、メーカーがファンのアイデアを奪おうと考えているようにも見えるかもしれない。しかし真意としては別にあり、アイデアを送付した人から“権利主張”されないように、そのように記述することがあるのだという。 そうした人は、何らかのかたちでアイデアのスケッチやイラストをメーカーに“一方的”に送りつけており、実際には開発陣は目を通していなかったとしても、自分のアイデアが勝手に使われたとして権利を主張してくるのだという。 なるほど。頼みもしないのにファンから「アイデア」が送りつけられて、しかもそれを後から「パクられた」などと主張されない為に予防線を張っておく必要がある、という話ですね。 一昨年に起きた京都アニメーションへの放火事件でも、犯行

                                                              ただの思い付きを「価値あるアイデア」と思い込む人が分かっていないこと
                                                            • Noを伝える技術 #pmconf2021

                                                              mROS 2: yet another runtime environment onto embedded devices

                                                                Noを伝える技術 #pmconf2021
                                                              • 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023

                                                                4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という…

                                                                  「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
                                                                • こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba

                                                                  最近、毎日のようにEMのいくおさん( @dora_e_m )とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う(ふだんから

                                                                    こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
                                                                  • 質とスピード(2020春版) / Quality and Speed 2020 Spring Edition

                                                                    質とスピード(2020春版) 2020/02/13 @ デブサミ2020

                                                                      質とスピード(2020春版) / Quality and Speed 2020 Spring Edition
                                                                    • 【翻訳】外注したら約400万円かかるシステムを、コーディングなしで自前でつくったお話|__shinji__

                                                                      前回に続きまして、今回もNoCode(ノーコード)に関するお話です。 今回は、Nadim El-Asmar(@nadimelasmar)氏の「How we manage our short-term rental business with no code」という記事を、本人の許諾を得た上で、タイトルを少し変えて翻訳・掲載しています。 本記事は、民泊などたくさんの短期契約の賃貸物件を管理している会社が、いかにしてNoCodeでシステムを構築し、ビジネスを進めているかという内容です。日本ではNoCodeの事例がまだまだ少ないですが、海外ではたくさんの起業家が実際にビジネスに取り入れています。 どんなNoCodeツールをどのように組み合わせて使っているか参考にしてもらえると幸いです。 下記から翻訳記事になります。 ----- はじめに NoCodeツールを使っておよそ150の賃貸物件を管理する

                                                                        【翻訳】外注したら約400万円かかるシステムを、コーディングなしで自前でつくったお話|__shinji__
                                                                      • 質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition

                                                                        質とスピード(2022春版、質疑応答用資料付き)

                                                                          質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition
                                                                        • 不安とストレスから解放される見積りとスケジュール方法

                                                                          はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを考えてしまうので「不安」に満ちたものになりがちです。 また、不安なものに取り組むというのは大きなエネルギーが必要です。試験勉強をしている時などに、部屋の掃除をしたくなってしまって、気が付いたら時間がなくなっていたという経験を多くの人が体験したことがあるのではないでしょうか。人は、不安なものを直視することを無意識に避けてしまうクセがあるのです。 本稿では、プロジェクトにおける不安とはなんだろうか?を考え、できる限り不安を最小化させるということを主眼に置いたスケジュ

                                                                            不安とストレスから解放される見積りとスケジュール方法
                                                                          • 【資料公開】マネジメント向けアジャイル開発概要

                                                                            みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 (スライドはこちらからもご覧いただけます:https://slide.meguro.ryuzee.com/slides/101) 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし

                                                                              【資料公開】マネジメント向けアジャイル開発概要
                                                                            • テストコードを書き始める前に考えるべきテストの話(2021年版) #scrumosaka / scrum_fest_osaka_2021

                                                                              以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…

                                                                                テストコードを書き始める前に考えるべきテストの話(2021年版) #scrumosaka / scrum_fest_osaka_2021
                                                                              • 品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中

                                                                                ※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理(Quality Control)、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです: 法規制対応、標準化対応、その他公的なガバナンス要求へ

                                                                                  品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中
                                                                                • 約束は開発を遅らせる - Mitsuyuki.Shiiba

                                                                                  観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな?」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない?もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

                                                                                    約束は開発を遅らせる - Mitsuyuki.Shiiba