並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 1310件

新着順 人気順

スクラムの検索結果1 - 40 件 / 1310件

スクラムに関するエントリは1310件あります。 仕事開発マネジメント などが関連タグです。 人気エントリには 『2021年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ』などがあります。
  • 2021年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。開発本部 オンボーディングチームの酒井(@sakay_y)です。社内のオンボーディングコンテンツを、どんどん社外へ公開することを夢見ています。 2021年もエンジニア新人研修を行いましたので、軽い紹介と、講義資料および一部講義動画(New!)を公開いたします。 2021年のエンジニア研修について 講義資料公開 Webアプリケーション基礎 HTTP/DNS ソフトウェアライセンス ソフトウェアテスト テスト自動化 アクセシビリティ Docker Chrome Developer Toolsの使い方 サイボウズのアジャイル・クオリティ デザインの役割と関わりかた データベース CI/CD セキュリティ モブに早く慣れたい人のためのガイド ITコミュニティ文化と情報発信に共通する成長と貢献の要素 正規表現 Kubernetesを使った開発入門 モニタリング入門 gRPC入門 日本語話

      2021年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
    • 「時間がない」症候群、その傾向と対策

      2022.05.21 Scrum Fest Niigata 2022 Main Hall 10:00-10:45 Proposal https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16425

        「時間がない」症候群、その傾向と対策
      • 界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】|Miz Kushida

        ・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは(7版からはすごく薄い)。 2021年8月に第7版が発表されると(ただし、日本語版はもっと先)公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5(最高レベル)を運用したりバージョンアップ対応を経験

          界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】|Miz Kushida
        • 2020年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ

          こんにちは。コネクト支援チームの@tignyaxです。 みなさま、夏はどう過ごされたでしょうか? 私は、夏が好きなのに今年は夏らしいことが出来なくて寂しいなぁとなっています。。。 さて、今年2020年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2020年のエンジニア新人研修について 基本的には2019年と同じ形*1での実施となりました。 最初の1週間で必修講義をしたあと、新人の皆さんには2週間ずつ3チームを体験してもらいました。 チーム体験のコンセプトは、新人に「興味のあるチームで実際に業務を体験し、配属希望を決める参考になった。」と言ってもらうことです。 各チーム体験では座学や研修を中心にするのではなく、業務体験が中心です。 チーム体験を通して、配属先を検討する材料にしたり、いろんなチーム/人/業務を知ってもらえる機会となります。 必修講義 誰に: 開発/

            2020年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
          • 中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita

            Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿で

              中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
            • 好きなポッドキャストについてまとめる

              そもそもポッドキャストって何?映像のない YouTube のような存在が ポッドキャストです。 つまり、ラジオのようなものです。 YouTube のように、素人も投稿できる音声 メディアです。 どうやって聞けるの?iOSからであれば、Apple Podcast Androidからであれば、Googleポッドキャスト ※Googleポッドキャストは、YouTube musicに統合の話が出ている 他にSpotify、Amazon music、radikoからも聞けるらしい。 おすすめのポッドキャストヤング日経経済系の番組はおじさんがしゃべっていることが多いが、この番組は若い大学生~大学院生の女の子が最近の経済について 話しており、非常に聞きやすく、軽い気持ちで聞けるのが良い。ポッドキャスト的な流し聞きに向いてる。 日経トレンディ & 日経クロストレンド日経トレンディ及び日経クロストレンドとい

                好きなポッドキャストについてまとめる
              • だれかの進捗をうまく把握できないときのフレーズ集 - Qiita

                Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか? → 進行中です/〜をやっています なにか問題はありますか? → とくにないです 〜までに終わりそうですか? → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーシ

                  だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
                • やさしいMCP入門

                  4/9(水) お昼にYouTubeでも解説します🙌 やさしいMCP入門 & 実践LT会(KAGと学ぼう!勉強会) https://kddi-agile.connpass.com/event/351600/

                    やさしいMCP入門
                  • 【資料公開】目標設定の基本

                    アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標

                      【資料公開】目標設定の基本
                    • ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(前編)

                      ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(前編) アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク(Dmytro Yarmak)氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入

                        ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(前編)
                      • スクラムガイド - Scrum Guide 2020 年 11 月

                        • プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0

                          TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案(やってよかったこと) 1stスクリーニング(やってよかったこと) コミュニケーション チームへのリスペクト(やってよかったこと) 話す <<< 聞く(改善余地あり) 即決する(やってよかったこと) 自分で各論まで見る(やってよかったこと) 発散→収束でディスカッション(改善余地あり) イラストで話す(改善余地あり) 日次ミーティング(やってよかったこと) 議事録を書く(改善余地あり) 得た情報を共有する(改善余地あり) 想定納期を示す(改善余地あり) カレンダー招待&日程確約コメントを転記(改善余地あり) プロセス管理 仮説

                            プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
                          • プログラミング上達したい人に繰り返し読んで欲しい4冊|erukiti

                            プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか(例えばリファクタリング第二版) の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 追記

                              プログラミング上達したい人に繰り返し読んで欲しい4冊|erukiti
                            • 締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;

                              これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの

                                締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
                              • Pythonで仕事をする人のための書籍まとめ2021 - 学習, 業務効率化, アプリ開発からデータサイエンスまで - Lean Baseball

                                2020年も多くの素晴らしい技術書がたくさん出ました. その中でも(昨今のトレンド・流行りも手伝ってか)Python本の多さ・充実度合いは目立つものがあります. (このエントリーを執筆した12/19時点で)Amazonの本カテゴリで「Python」と検索すると1,000件以上出てきます*1. これだと目的の本にたどり着くだけで疲れそうです. このエントリーでは, 主にPythonを学びたい・現在使っている方 手元の業務を効率化したり, RPAっぽいことをやりたい方 エンジニア・データサイエンティストとして業務や趣味・個人開発をされている方 を対象に, 今そして来年2021年に読んでおきたいPython関連書籍(と抑えておきたいサービス) をエンジニアでありデータサイエンティストである私独自の視点で紹介します*2. なおこのエントリーはこのブログで例年執筆している「Python本まとめ」の2

                                  Pythonで仕事をする人のための書籍まとめ2021 - 学習, 業務効率化, アプリ開発からデータサイエンスまで - Lean Baseball
                                • 「なぜ」と聞かずに理由を引き出す!「詰めてる」感を減らす言い換えテク - Qiita

                                  こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに レビューや会議で誰かが「詰められてる」様子、心にきますよね。自分がやられるのはもってのほかですが、周囲で発生するだけでも心がすり減ります。。 特に、何か問題が発生したときや、参加者間の誤解が解消できないときに「詰め」が生じがちです。 質問する側の、焦りや不安から「なぜ?」「どうして?」「つまり?」と質問マシーンになってしまう気持ちも理解できるのですが。 問い詰めてしまい心理的に不安全な状況に陥ると「ミスを隠そう、自分が責められないようにしよう」と回避する力が働きはじめ、結果として「正確な状況がわからない」「適切なアクションが取れない」といったチームとして重大なリスク

                                    「なぜ」と聞かずに理由を引き出す!「詰めてる」感を減らす言い換えテク - Qiita
                                  • ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など

                                    ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 このなかから特に投票の多かった技術書3冊、ビジネス書3冊について、同社が2月17日と18日に開催する「Developers Summit 2021(デブサミ20

                                      ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など
                                    • エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく|mtx2s

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

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

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

                                          「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか
                                        • 目標設定の基本

                                          Tidy First? ―個人で実践する経験主義的ソフトウェア設計著者/訳者:Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ出版社:オライリー・ジャパン発売日:2024-12-25単行本(ソフトカバー):164ページISBN-13:9784814400911ASIN:4814400918 脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック著者/訳者:Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin出版社:オライリー・ジャパン発売日:2024-06-18単行本(ソフトカバー):312ページISBN-13:9784814400799ASIN:4814400799

                                            目標設定の基本
                                          • 現代的システム開発概論

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

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

                                              第三世代が特徴的で、1分単位でスケジュールを管理し、時間に沿って行動をする「電極家」のような存在です。このスケジュールは最初の2日程度であればなんとかこなせる人もいると思いますが、「スケジュールに動かされている」だけであり、「主体的」ではなくなっている可能性があります。 そんな管理方法をしている中で、「自分の人生ってなんだっけ」と問い直すことになり第二世代や第一世代に戻ってしまう、という選択に戻ってしまうのです。だからこそ、第四世代をベースに時間管理を行い、「自分がやりたいことをやる」ために管理していくことが重要なのだと分かります。 Atomic Scrum 株式会社ゆめみの社長である片岡さんが公開している自己管理の資料です(ここでは自己定義も含めて自己実現と言われています) 根本的な考え方は同じであり、自分自身もこの資料がスタートで色々模索し始めた背景もあるので、参考として見ていただける

                                                エンジニアのための自己管理入門 - Qiita
                                              • 学びのススメ 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
                                                    • 市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ

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

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

                                                              "言われたことしかやらないのはダメ"という日本の考え方は独特→海外委託で衝突する原因やマネジメントの機能の話へ
                                                            • 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"
                                                              • こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba

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

                                                                  こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
                                                                • ペアプロが嫌すぎて会社を退職した話 - Qiita

                                                                  📒ペアプロ・モブプロアンケート実施中 🖊️ あなたのご意見をお聞かせください。(2025/1/3 23:59まで) 回答結果は2025/1/6(月)にQiitaで公開いたします。 アンケートはこちらから(1分ほどで終わります) はじめに 巷ではペアプロ、モブプロがホットワードになっており、あたかも開発生産性を向上する特効薬のように取り上げられている印象を受けます。一方、この記事では、ペアプロ、モブプロ開発のネガティブな部分を考え、私の経験から感じたペアプロ、モブプロのアンチパターンとその改善策をご紹介します。 どんなアンチパターンを踏んでいたのか? 勤務時間は100%ペアプロを実施(ソロプロ禁止) ソロプロは悪、ペアプロが最高というチームの雰囲気 フロー効率を過度に重視する姿勢 どうなったか? +) 開発生産性およびデプロイ頻度は上がった +) 4keysなどの数値上の指標はすべてプラ

                                                                    ペアプロが嫌すぎて会社を退職した話 - Qiita
                                                                  • 不安とストレスから解放される見積りとスケジュール方法

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

                                                                      不安とストレスから解放される見積りとスケジュール方法
                                                                    • テストコードを書き始める前に考えるべきテストの話(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
                                                                      • ユニコーン企業のひみつ

                                                                        「ユニコーン企業のひみつ」という本を読んだ。 本旨は、成功したスタートアップ企業、所謂ユニコーンの開発手法や組織は、エンタープライズ系開発を主としている企業とは違うものですよ、という話である。 そしてそれらの企業が具体的にどういうやり方で彼らのプロダクトを開発しているのかを書いている。 ちなみにタイトルにユニコーン企業とあるけれど、別にユニコーン(評価額10億ドル以上の未上場企業)に限った話ではなく小さなスタートアップからGoogleのような既に上場して随分経っている巨大企業まで共通した話だと思う。著者もとくに区別しているわけではなく単にSpotifyで働いた経験から書いたからそのようなタイトルにしたというだけみたいだ(Spotifyもすでに上場しているので厳密にはユニコーンではない)。まあスタートアップは立ち上げのタイミングでは組織も何もないので、タイトルにあるユニコーンというのは、一応

                                                                          ユニコーン企業のひみつ
                                                                        • プロジェクトを計画しすぎてダメにする方法 | タイム・コンサルタントの日誌から

                                                                          「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」 たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画(いわゆる「予算」)、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。 だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登っ

                                                                            プロジェクトを計画しすぎてダメにする方法 | タイム・コンサルタントの日誌から
                                                                          • 受身気質な私がリーダーという役割で実践したこと 4選

                                                                            皆さんこんにちは! 最近、猫様をお迎えし最高な毎日を過ごしていております、塩対応のしおりん(@jamgodtree)です。 はじめに 私はログラスのエンジニアチームにて、2022年8月からリーダーを半年経験してきました。 この記事では、チームパフォーマンスの最大化に向けて行動してきたこと・失敗談について書いていきます。 タイトルにもあるように、私は受身気質であり、先頭を走っていくタイプのリーダーではありません。 その上で、以下のような悩みがある方に読んでもらえると幸いです。 リーダーになる前に何をやったらいいのかわからない人 リーダーになりたてでどうしようか同じように悩んでいる人 また、ログラスに興味がある方も是非参考にしてみてください。 ログラスにおけるリーダーとは? ログラスにおいてリーダーは 「役割」 として定義されています。 「上司」と「部下」ではなく、フラットな関係性を指している

                                                                              受身気質な私がリーダーという役割で実践したこと 4選
                                                                            • 【最新版】有名企業のエンジニア向け研修資料まとめ - Qiita

                                                                              Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回は有名企業で無料で公開しているエンジニア新人研修資料をまとめました。 昨今、新人向けの研修資料を公開する企業が増えています。 クオリティーがかなり高いものが多く、初級者から中級者でも学びがある資料となっています。 資料の作り方も勉強になるので「勉強会で登壇している人」「企業の研修担当の人」にも有益な資料になっています。 この記事の主な対象者 有名企業の研修資料を網羅的に知りたい人 エンジニア初級から中級者の人 独学で学習をしている人 研修思慮の作成担当 MIXI新卒研修2024 まずはじめに紹介するのは、毎年新人向けの研修

                                                                                【最新版】有名企業のエンジニア向け研修資料まとめ - Qiita
                                                                              • 「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball

                                                                                界隈で話題になっている(と私は認識している)「世界一流エンジニアの思考法」を早速読んでめちゃくちゃ良かった, とにかく人に勧めたいぞ! という現役エンジニア(私)による書籍の感想エントリーとなります. 話題の本めちゃ良かったです. このブログを書く数日前にkindleで買って読む→めちゃいいやん!→紙版も買う←今ここ ってぐらいすごく良かったです*1. 世界一流エンジニアの思考法 (文春e-book) 作者:牛尾 剛文藝春秋Amazon 何が良かったか一言で言うと, 「強いエンジニアの習慣がここまでいい感じに言語化されている!!!」 という所ですね, 割と余すところなく詰まっていると思いますし, 一つ一つのTipsは再現性もあると思います(真似できるかどうかは別として真似は可能*2). そんな「世界一流エンジニアの思考法」の感想を手短に書きます, 気になる方はお付き合いください. TL;D

                                                                                  「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball
                                                                                • 準委任契約に基づく報酬請求と善管注意義務違反 東京地判令2.9.24(平28ワ28934) - IT・システム判例メモ

                                                                                  開発は途中で終わった場合でも、準委任契約に基づく報酬請求はできるが、適切な計画立案・実行ができていなかったとして善管注意義務違反が認められた事例。 事案の概要 イベント企画会社Yは、自社の企画するイベントを管理するためのシステム(本件システム)の開発をXに依頼することとした。 平成28年3月にXは開発に着手したが、その時点では契約書が取り交わされておらず、4月になって、X・Y間で以下の内容(抜粋)の契約書が取り交わされた(本件契約)。 1条2項 本件契約は,Xが(中略)業務に従事する技術者の労働をYに対し提供することを主な目的とし,民法上の準委任契約として締結されるものとする。したがってXは,善良なる管理者の注意義務をもって(中略)業務を実施する義務を負うものとし,原則として成果物の完成についての義務を負うものではないものとする。 3条3項 前各項にかかわらず,Yは,Xの本件サービスの業務

                                                                                    準委任契約に基づく報酬請求と善管注意義務違反 東京地判令2.9.24(平28ワ28934) - IT・システム判例メモ

                                                                                  新着記事