検索対象

並び順

ブックマーク数

期間指定

  • から
  • まで

agileの検索結果(絞り込み: 3 users 以上)18444 件中 1 - 40 件目

  • 米国でソフトウェアエンジニアになる方法

    1on1やメールでご相談を受ける最頻出の話題が 「どうすればアメリカでソフトウェアエンジニアになれるでしょうか?」 というものです。これは後述しますが、いくつかの点で中々ひと言では回答の難しい質問です。ただし、本当にアメリカでソフトウェアエンジニアになりたいなら、そのための確度を大幅に上げる方法はいくつか思い当たります。 筆者について実際に米国で2年ほどではありますがソフトウェアエンジニアをしていました。現在も米系企業の日本法人でソフトウェアエンジニアとして働いています。留学経験もなく、3流大の文系出身で、30代になってから「正攻法で」米国に渡りました。そういう点で非常に現実的な経験をシェアできると思います。筆者について詳しいことは次のnoteにまとめました。もしご興味のある方はお読みいただければ幸いです。 本当に米国に行きたいですか?冒頭の質問に対して僕がまずお聞きするのは 「本当に米国

    米国でソフトウェアエンジニアになる方法
    • デイリースクラムいらなくなくなくなーい!?

      CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again

      デイリースクラムいらなくなくなくなーい!?
      • 「社員は優秀だけど楽しそうじゃない」、パナソニックHDはアジャイル道場で覆せるか

        「もう仲間だから正直に言いますね。社員は優秀ですごく頑張っているのに、楽しそうじゃないんですよ」――。パナソニック ホールディングス(HD)でグループCIO(最高情報責任者)を務める玉置肇執行役員は2022年春、大阪府守口市にある本社ビルの一室でこう語った。 語りかけた相手はリアルとオンラインで参加したパナソニック オペレーショナルエクセレンス(PEX)らの社員数十人。皆、同社のアジャイル推進組織「PEXアジャイルセンター」が主催する「アジャイル実践塾・道場」に参加する塾生や事務局関係者である。 PEXは2022年4月の持ち株会社制への移行に伴い発足し、ITや生産技術、品質管理、調達、知的財産、人事、経理、ブランドマネジメントといった各分野にわたり、グループの各社・各部門の仕事を効率化・高度化する企画やそれを具現化したサービスなどを提供している。事業会社としてパナソニックグループの経営方針

        「社員は優秀だけど楽しそうじゃない」、パナソニックHDはアジャイル道場で覆せるか
        • イーサリアムの開発エネルギーの凄さと他分野での再現性|中村 龍矢 | LayerX 執行役員 兼 PrivacyTech事業部長|note

          (みんな思い思いのツイートをしてましたが、私は本プロジェクトの実質PMのDanny Ryanの長年の思いが詰まった下記のツイートが気に入りました。バランスの取れたリーダーであり、フランクで良い人でした。) PoS移行の大変さを要約すると、 ・失敗したら数十兆円吹き飛ぶ可能性があり、世界中に迷惑をかけるどころではない ・完全にパブリックなネットワークであり、世界中のハッカーから常に攻撃対象(攻撃すると儲かるため) ・使われている技術は全くもって枯れておらず、実装以前に理論研究段階から必要 ・基礎研究を終えて本格的に始動してから5年近くかかった という感じです。(ここで終わりではなく、他にも色々な技術的アップデートが予定されています。)私がEthereumの研究や開発をしていたのは2018-2020年の短い時間でしたが、一部だけでも関わることができたのは貴重な体験でした。 私はEthereum

          イーサリアムの開発エネルギーの凄さと他分野での再現性|中村 龍矢 | LayerX 執行役員 兼 PrivacyTech事業部長|note
          • バックエンド開発の基本を理解するために必要な10の知識 2022年版

            はじめに バックエンドエンジニアは、プログラミングの中で特にイメージがわきにくい分野である。簡単に言えば、バックエンドエンジニアはユーザから見えない部分にあるシステムである。(例えば、ユーザ認証やデータベース設計・操作・運用などが例として挙げられる) 例えば、ECサイトを運用する際に、ユーザから見えるUIだけを作っても作動しない。バックエンドになるシステムの構築も必要なのだ。 今回はバックエンド開発を理解する上で必要な10の知識を徹底解説する。その中で、個人の見解に過ぎないが初心者にオススメのバックエンドのフレームワークを3選紹介する。あくまで一個人の見解に過ぎないが、今回の記事を通してバックエンドの学習方法またはその魅力を十分に理解していただければ非常に幸いである。 本題に入る前に、本記事における「バックエンド」はあくまで認証やデータベースなどシステムやソフトウェアの裏側で動作しているも

            バックエンド開発の基本を理解するために必要な10の知識 2022年版
            • OKRはツリーではない

              組織内でバリュー・ストリーム・マッピング(VSM) の宣教師をやってみてわかった、 VSMを組織に広める3つのポイント

              OKRはツリーではない
              • サポート一覧

                オフショア開発アカデミーでは、オフショア開発に関する基本的な情報を学びます。そのため個別のプロジェクトやオフショア開発を利用する企業の状況に合わせた対応方法は、サポートにて対応しています。 無料で様々なサポートを利用することが出来ます。 ぜひサポートを活用して、オフショア開発に役立ててください。

                サポート一覧
                • オフショア開発の依頼前に作成するデザインモック

                  オフショア開発会社に依頼をするために、プロジェクトの概要や予算、デザインのイメージなどプロジェクトの情報を伝えるために情報を整理し、資料を作成する必要があります。 デザインは、視覚的に伝えることができるため、情報を共有する手段として非常に有効です。 デザインモックを作成するだけでなく、オフショア開発の全般で使用する内容になりますので、しっかりマスターしてください。

                  オフショア開発の依頼前に作成するデザインモック
                  • オフショア開発ラボ型講義一覧

                    オフショア開発ラボ型講義一覧 失敗しないオフショア開発アカデミー / 失敗しないオフショア開発アカデミー講義一覧 / オフショア開発ラボ型講義一覧 現在準備中 REGENESIS Inc All Right Reserved

                    オフショア開発ラボ型講義一覧
                    • オフショア開発とは

                      今回からオフショア開発について一緒に勉強していきます。頑張っていきましょう。 まず始めにオフショア開発とはなんでしょうか? 今回はオフショア開発について、大まかなイメージを理解していきます。

                      オフショア開発とは
                      • ソフトウェア開発者に必要な考え方 / Necessary mindset for software developers

                        目指すべきソフトウェア開発と 今日から始める最初の一歩 / First step for good development

                        ソフトウェア開発者に必要な考え方 / Necessary mindset for software developers
                        • Masanori Kusunoki / 楠 正憲 on Twitter: "よく中抜き構造に対する批判を聞くけれども、表裏である雇用規制をどうすべきかにまで考えが及ぶ人は少ない。必要に応じて直接雇用してプロジェクトが終わったところで解雇できれば理論的には内製できる。実際そうではないから要員を充足できるとこ… https://t.co/cBgO9nMaAg"

                          よく中抜き構造に対する批判を聞くけれども、表裏である雇用規制をどうすべきかにまで考えが及ぶ人は少ない。必要に応じて直接雇用してプロジェクトが終わったところで解雇できれば理論的には内製できる。実際そうではないから要員を充足できるとこ… https://t.co/cBgO9nMaAg

                          Masanori Kusunoki / 楠 正憲 on Twitter: "よく中抜き構造に対する批判を聞くけれども、表裏である雇用規制をどうすべきかにまで考えが及ぶ人は少ない。必要に応じて直接雇用してプロジェクトが終わったところで解雇できれば理論的には内製できる。実際そうではないから要員を充足できるとこ… https://t.co/cBgO9nMaAg"
                          • Agile and DevOps の歴史をチェリーピック

                            Transcript アジャイルとDevOpsの 歴史をチェリーピックして 勝手にふりかえりながら 仙人と語らうためのスライド 川口 恭伸 かわぐち やすのぶ Twitter: @kawaguti アギレルゴコンサルティング株式会社 シニアアジャイルコーチ 株式会社ホロラボ シニアアジャイルコーチ 一般社団法人スクラムギャザリング東京実行委員会 代表理事 一般社団法人 DevOpsDays Tokyo 代表理事 研修やってます アギレルゴアジャイル研修 検索 前段で勝手なことを話しておけば だまって聞いてる仙人がウズウズして しゃべりたいことがたくさん出てくる だろうという戦術 仙人 勝手なことを 話してる 市井の人 ITバブル崩壊 2009年 リーマンショック 2001年 まことに勝手なる歴史観 ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 De

                            Agile and DevOps の歴史をチェリーピック
                            • VSCode に WakaTime を導入してコード編集時間を可視化する - Qiita

                              WakaTimeとは? WakaTimeは、エディタと連動してコード編集の作業時間を可視化できるサービスです。 編集したコードのプロジェクト(リポジトリ)、言語、ブランチを自動的に検出してダッシュボード化してくれます。 エディタ操作が一定時間止まると自動的に計測停止してくれます。自分でタイマー開始・停止する必要はありません。 たいていのエディタは対応しています。 https://wakatime.com/plugins この記事では、VSCode に WakaTime を導入してダッシュボード確認するまでの手順を説明します。 WakaTimeアカウント登録 https://wakatime.com/signup からサインアップしてください。 APIキー発行 https://wakatime.com/settings/account からAPIキーを発行できます。 VSCode と Wak

                              VSCode に WakaTime を導入してコード編集時間を可視化する - Qiita
                              • とあるカンファレンスにでてきた「ソフトウェアはなにもしないと壊れる」という言葉に深くうなずく皆様「これは名言」「なににでも言える」

                                安川要平/Yohei Yasukawa @yasulab #RubyKaigi 2022 という国際カンファレンスのトークで出たお話しです!こういったトークも聞ける #RubyKaigi、2023年は松本で開催予定なのでぜひ遊びに来てください!!ね!!!💎✨ RubyKaigi 2022 rubykaigi.org/2022/ 2022-09-10 19:23:45

                                とあるカンファレンスにでてきた「ソフトウェアはなにもしないと壊れる」という言葉に深くうなずく皆様「これは名言」「なににでも言える」
                                • たまくわ on Twitter: "エンジニアの人たちね、まあ頭が良いということなんだろうけどもね、例えばなんだけど「Aを使ったBがしたい」と言うと、そのAとBになった背景を聞くのね。 これは全然良いんだけど、最終的に「それならCがいいよ」って結論を出してくるの。相手はAを使ったBがしたいって言ってるのに。"

                                  エンジニアの人たちね、まあ頭が良いということなんだろうけどもね、例えばなんだけど「Aを使ったBがしたい」と言うと、そのAとBになった背景を聞くのね。 これは全然良いんだけど、最終的に「それならCがいいよ」って結論を出してくるの。相手はAを使ったBがしたいって言ってるのに。

                                  たまくわ on Twitter: "エンジニアの人たちね、まあ頭が良いということなんだろうけどもね、例えばなんだけど「Aを使ったBがしたい」と言うと、そのAとBになった背景を聞くのね。 これは全然良いんだけど、最終的に「それならCがいいよ」って結論を出してくるの。相手はAを使ったBがしたいって言ってるのに。"
                                  • 事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering

                                    Transcript ࣄۀՁ஋ͱ� &OHJOFFSJOH ࠇాɹथ גࣜձࣾϦΫϧʔτ� ɹΞϓϦέʔγϣϯιϦϡʔγϣϯϢχοτ� ɹ%JWJTJPO�0⒏DFS� ࠇాɹथ ▪ܦྺ 2004೥ɹେखSIerɹ৽ଔೖࣾ 2011೥ɹגࣜձࣾϦΫϧʔτ ೖࣾ 2018೥ɹגࣜձࣾϦΫϧʔτςΫϊϩδʔζɹΤϯδχΞϦϯά෦ɹ෦௕ ɹɹɹɹ ݉ גࣜձࣾϦΫϧʔτδϣϒζ 2019೥ɹגࣜձࣾϦΫϧʔτςΫϊϩδʔζɹHRྖҬΤϯδχΞϦϯάϢχοτɹࣥߦ໾һ ɹɹɹɹɹɹɹɹɹɹɹɹɹɹɹɹɹɹɹɹɹΦϑγϣΞιϦϡʔγϣϯ෦ɹ෦௕ ɹɹɹɹ ݉ גࣜձࣾϦΫϧʔτδϣϒζ ɹɹɹɹ ݉ גࣜձࣾϦΫϧʔτΩϟϦΞ 2021೥ גࣜձࣾϦΫϧʔτɹΞϓϦέʔγϣϯιϦϡʔγϣϯϢχοτɹDivision Officer Sierʹͯ׭ެிܥγεςϜͷΤϯδχΞɺΞϓϦέʔγϣϯΞʔΩςΫ

                                    事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
                                    • ソフトウェアエンジニアとしての姿勢と心構え / Software Engineer's Survival Guide

                                      事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering

                                      ソフトウェアエンジニアとしての姿勢と心構え / Software Engineer's Survival Guide
                                      • 株式会社リクルート エンジニアコース新人研修の内容を公開します!(2022年度版)

                                        こんにちは!2022年度エンジニア新人の太田です。毎年反響を頂いているエンジニアコースの研修内容を、今年は受講者の立場から紹介させていただきます。 研修概要 リクルートの新卒エンジニアコースでは、入社した新人を対象に技術研修を行っています。その内容は、実際の開発業務に活かせる技術を扱う「本当に必要な生きた知識・技術」を取り入れたものとなっています。 特筆すべき点として、研修の資料はほとんどが内製であることが挙げられます。そのため、講義中の質疑を通してより深い知識や、開発の現場で培われた経験に触れることができます。 フロントエンド、モバイルアプリ、バックエンド、インフラ、データ分析、セキュリティなど幅広いテーマが扱われるため、知識のインデックスを張ることにもつながります。またハンズオンや競技形式の演習も取り入れられており、実際に手を動かすことで印象に残りやすく、エラーへの対処も学ぶことができ

                                        株式会社リクルート エンジニアコース新人研修の内容を公開します!(2022年度版)
                                        • 言いにくい・無関心・おもしろくないから内職… フィードバックが出てこないスプリントレビューを改善した「ファシリテーション改革」

                                          言いにくい・無関心・おもしろくないから内職… フィードバックが出てこないスプリントレビューを改善した「ファシリテーション改革」 チーム全員で盛り上げるファシリテーション 「開発PM勉強会」では、今後のキャリアを考えるプロダクトマネージャー、プロジェクトマネージャー、エンジニアと共に、プロダクト開発事例の共有やシステム開発上流工程の相互学習の場を提供しています。第13回目は、プロダクト開発、プロジェクト管理とは切り離せないスクラムイベントや会議の進行「ファシリテーション」技術について話しました。ここで登壇したのは、株式会社グロービスの久津佑介氏。ファシリテーション改革によりスプリントレビューを改善した事例について話しました。 グロービス社・CPO兼法人開発チームのPMを担当 久津佑介氏:それでは、「チームで盛り上げるファシリテーション」とタイトルに変えて、お話しします。よろしくお願いします。

                                          言いにくい・無関心・おもしろくないから内職… フィードバックが出てこないスプリントレビューを改善した「ファシリテーション改革」
                                          • ひさてるさん on Twitter: "ソフトウェア開発で「正確な工数見積はできない」というのは、新規なんてやってみるまで何ひとつわからないという怠慢の肯定ではなくて、過去の経験からだいたいカンでこれぐらいかなと予測した数字は出せるけど、そんなものの足し算で長期計画のケツを約束する愚行をやめようという意味なのよね"

                                            ソフトウェア開発で「正確な工数見積はできない」というのは、新規なんてやってみるまで何ひとつわからないという怠慢の肯定ではなくて、過去の経験からだいたいカンでこれぐらいかなと予測した数字は出せるけど、そんなものの足し算で長期計画のケツを約束する愚行をやめようという意味なのよね

                                            ひさてるさん on Twitter: "ソフトウェア開発で「正確な工数見積はできない」というのは、新規なんてやってみるまで何ひとつわからないという怠慢の肯定ではなくて、過去の経験からだいたいカンでこれぐらいかなと予測した数字は出せるけど、そんなものの足し算で長期計画のケツを約束する愚行をやめようという意味なのよね"
                                            • 深津 貴之 / THE GUILD / note.com on Twitter: "珍プロダクトといえば。我が家の家宝の100徳ナイフ。 便利な10徳ナイフも11, 12, 13... と機能を増やしていくと、どこかで詰むのです。 自分がアプリを作るときの心の師。このナイフをプレゼンに持ち込むと、99%の確率で多… https://t.co/UnaVf4A2q6"

                                              珍プロダクトといえば。我が家の家宝の100徳ナイフ。 便利な10徳ナイフも11, 12, 13... と機能を増やしていくと、どこかで詰むのです。 自分がアプリを作るときの心の師。このナイフをプレゼンに持ち込むと、99%の確率で多… https://t.co/UnaVf4A2q6

                                              深津 貴之 / THE GUILD / note.com on Twitter: "珍プロダクトといえば。我が家の家宝の100徳ナイフ。 便利な10徳ナイフも11, 12, 13... と機能を増やしていくと、どこかで詰むのです。 自分がアプリを作るときの心の師。このナイフをプレゼンに持ち込むと、99%の確率で多… https://t.co/UnaVf4A2q6"
                                              • いかにして GraphQL を組織に導入するか (新規開発編) / how we introduce GraphQL on scratch development

                                                いかにして GraphQL を組織に導入するか (新規開発編) / how we introduce GraphQL on scratch development GraphQL Tokyo #18 Lightning Talks https://www.meetup.com/ja-JP/graphql-tokyo/events/286913987/ Links: [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architectu

                                                いかにして GraphQL を組織に導入するか (新規開発編) / how we introduce GraphQL on scratch development
                                                • 新卒で飛び込んだフロントエンド刷新プロジェクトが学びだらけだった話 - Cybozu Inside Out | サイボウズエンジニアのブログ

                                                  こんにちは、kintone フロントエンドリアーキテクチャプロジェクト (フロリア) に所属している 21 新卒の西川 (@nissy_dev) と左治木 (@sajikix) です。 フロントエンド刷新プロジェクトへの配属から約 1 年が経ち、プロジェクトに関わる中で多くの学びがあったので振り返ってみました。 目次 自己紹介 西川です 左治木です kintone フロントエンドリアーキテクチャプロジェクト(フロリア)とは 配属されてみて実際どう? プロジェクトから学べたこと 小規模なチームでのスクラム開発 Testing Trophy を意識した QA とのテスト設計 アクセシビリティを考慮した UI の開発 現在取り組んでいること いきなり刷新プロジェクトに配属されるのってどう? チームに任された裁量が大きく、新卒でも技術選定やより良い設計の提案をしながら開発できる 新規開発した機能に

                                                  新卒で飛び込んだフロントエンド刷新プロジェクトが学びだらけだった話 - Cybozu Inside Out | サイボウズエンジニアのブログ
                                                  • アジャイルやスクラムでも遅い? TeslaやSpaceXがイノベーションを生み出せる理由

                                                    アジャイルやスクラムでも遅い? TeslaやSpaceXがイノベーションを生み出せる理由:マネジメントはソフトウェアが代替 イノベーションで世界の注目を集めるTeslaやSpaceXは、ソフトウェア開発の現場で広まっているアジャイルやスクラムの考え方を製造現場に適用し、現在はその先を目指そうとしているという。2022年7月に開催された「Agile Tech EXPO 2022」でアジャイル導入支援の経験を持つJoe Justice(ジョー・ジャスティス)氏が、その「凄さ」を紹介した。 「アジャイルやスクラムはソフトウェア開発に適用するもの」というイメージが強いかもしれない。しかし、イーロン・マスク氏が率いるTeslaやSpaceXでは、電気自動車やロケットというハードウェアにもアジャイルやスクラムの考え方を取り入れ、これまでのモノ作りでは考えられないような短期間で新しいバージョンの製品をリ

                                                    アジャイルやスクラムでも遅い? TeslaやSpaceXがイノベーションを生み出せる理由
                                                    • すべてがXPになる ─ エクストリームプログラミングで見える開発風景(セミナーレポート) - Agile Journey

                                                      アジャイルソフトウェア開発を企業が導入する際に、スクラムと並んで名前が挙がる開発手法にエクストリームプログラミング(XP)があります。ガイドブックや研修が存在するスクラムに対して、ペアプログラミング(ペアプロ)やテスト駆動開発といったプラクティスをエクストリーム(極限的)に実践しようというXPの導入には、どこから始めればよいのかと戸惑う開発組織もあるようです。 2022年6月に開催されたユーザベース主催の勉強会「エクストリームプログラミングで見える開発風景」では、XPの提唱者であるケント・ベックの著作などの翻訳者として知られる角征典さんと、XPを導入しているユーザベースのソフトウェアエンジニアである野口光太郎さんが講演したのち、XPの始め方やエンジニア以外との体制づくりなどについて、視聴者の質問をもとにパネルトークが行われました。 本記事では、組織にXPをどのように導入するか、またスクラム

                                                      すべてがXPになる ─ エクストリームプログラミングで見える開発風景(セミナーレポート) - Agile Journey
                                                      • スペシャリストになれなくても成長する方法 #scrumsendai / How to grow even if you can't become a specialist

                                                        スペシャリストになれなくても成長する方法 #scrumsendai / How to grow even if you can't become a specialist 2022/08 スクラムフェス仙台でプレゼンテーションしたスライドです。 https://confengine.com/conferences/scrum-fest-sendai-2022/proposal/17013/5000dai ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。 ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信を

                                                        スペシャリストになれなくても成長する方法 #scrumsendai / How to grow even if you can't become a specialist
                                                        • アジャイルであり続けるために技術スキルと向き合う

                                                          これから始める人のためのデータベース超入門 / A super introduction for Database beginners.

                                                          アジャイルであり続けるために技術スキルと向き合う
                                                          • 【資料公開】スプリントプランニング Deep Dive

                                                            みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに

                                                            【資料公開】スプリントプランニング Deep Dive
                                                            • 実践! ユニットテスト入門

                                                              PHPカンファレンス沖縄2022の登壇資料です。 発表時間の関係で収まりきらなかった内容を大幅に加筆しています。 以下プロポーザルの内容を転記。 ---- テスト書いてますか? テストを書く理由と実際のテストコードを紹介する実践編に分け、TDD を3年間実践してきた経験に基づいてお話しします。 テストを書いたことのない方が、テストを書いてみたいと思ってもらえることを目指します。 サンプルコードは PHP + PHPUnit ですが、他言語でも通用する考え方を紹介します。 ■ 概要 ・なぜテストコードを書くのか ・レガシーコードとは、テストのないコード ・テストはコストが安いフィードバックループである ■ 実践編 ・テストケースは日本語で書こう ・いろんな assertion を知ろう ・arrange / act / assertion のテストコード実装パターン ・set up / te

                                                              実践! ユニットテスト入門
                                                              • 金融の基幹システムを1年半かけて.NET 6に移行した話

                                                                はじめに 本稿は「.NET 6移行祭り! C# Tokyo」イベントで発表した「金融の基幹システムを1年半かけて .NET 6に移行した話」の内容を文書化したものです。 [2022.08.28追記] さて、はじめにおことわりを。 おもったより大きな反響があって、想定より多く読まれており、とくに正しく伝えられていない箇所があると思い、少し補足を入れました。 ここで基幹システムといっていますが、金融の勘定系システムという意味ではありません。 基幹システムというとCore Systemという意味(これは勘定システムでしょうね)と、Mission Critical Systemの2つがあると思います。 本稿の対象は後者で、システムのお客様が、Mission Critical Systemと判断されて基幹システムとして扱われています。 金融の勘定系とは規模や複雑性、クリティカルな度合も異なりますが、

                                                                金融の基幹システムを1年半かけて.NET 6に移行した話
                                                                • 全関係者の相関図をまず作れ、「聞いてない」は手戻りに直結

                                                                  書籍『誰も教えてくれなかったアジャイル開発』(日経BP)では、ウオーターフォール型開発が主流の「日本企業」で試行錯誤しながらアジャイル開発を成功に導いてきたコンサルタントたちが、自ら経験を体系化している。本書から抜粋し、アジャイル開発のポイントを紹介する「実践編」から、“抵抗勢力”への対策について解説する。(技術プロダクツユニットクロスメディア編集部) ここではプロジェクト関係者、とりわけステークホルダー「全員」をリストにまとめて可視化する。プロジェクト開始時に直接プロジェクトに参加する人たちの体制図はつくるものの、間接的に影響を与える可能性のある人たちについては各自の頭の中にあるだけで、積極的に洗い出したり可視化したりはしないプロジェクトが多い。 ステークホルダーの可視化が不十分だったプロジェクトで起こったトラブルを紹介しよう。営業活動を可視化し、業務効率向上と働き方改革を支援することを

                                                                  全関係者の相関図をまず作れ、「聞いてない」は手戻りに直結
                                                                  • 段取りとマイクロマネジメントとスクラム - yigarashiのブログ

                                                                    仕事ができるエンジニアはだいたい段取りがうまい。達成したいゴールがあるときに、AとBとCをやる必要があって、Bはわからないことが多いから先にやろうとか、AとCは並行してできるからCを誰かにお願いしようとか、とにかく目標を達成するための道のりをうまく計画できる人が多い。こういう作業をそつなくこなせるかが、ジュニアと一人前を区別する重要な指標のひとつと言える。そしてこの段取りをうまくできない人に対して、細かい計画を立ててあげて指示をするのがマイクロマネジメントだと思う。 スクラムにおけるスプリントプランニングは、この段取りをチームでやると思うとよく腹落ちする。達成したいゴールとしていくつかのプロダクトバックログアイテムを置いて、その達成に必要な作業を半日から1日で終わるサイズのタスクにみんなで分解して、不明点を一緒に洗い出して、どういう順番でやっていくか計画を立てる。まさに段取りだ。これがスク

                                                                    段取りとマイクロマネジメントとスクラム - yigarashiのブログ
                                                                    • スクラムマスターの役割とは何か? チームと環境の変化で“変わる”取り組みと“変わらない”原則

                                                                      2001年の「アジャイルソフトウェア開発宣言」から20年以上が経過し、アジャイル開発の認知や実践は大きく広がりを見せています。一方で、社会や環境の変化に適応するように、その実践の形も、姿を変えながら進化を続けています。今回は、スクラムマスターを務めるヤフー 田原慎也氏とChatwork 粕谷大輔氏に、「リモートでのスクラム」「大規模スクラム」など、アジャイル開発、特にスクラムにおける、ホットなトピックについて語っていただきました。 ともに複数チームでプロジェクトを推進する2人のスクラムマスター 田原:ヤフーの田原です。スクラムマスターを務めるようになったのは1年ほど前からで、まだ初心者です。今回は、自分のこれまでの取り組みをお話しして、エキスパートである粕谷さんに、いろいろと突っ込んで、教えていただければと思っています。 粕谷:Chatworkの粕谷です。こちらこそ、よろしくお願いします。

                                                                      スクラムマスターの役割とは何か? チームと環境の変化で“変わる”取り組みと“変わらない”原則
                                                                      • arton on Twitter: "まともなソフトウェア開発は「職人」によって行われる(当然、「属人」的である)と、ついに断言した、とても良い本。 https://t.co/D1fDceeheN"

                                                                        まともなソフトウェア開発は「職人」によって行われる(当然、「属人」的である)と、ついに断言した、とても良い本。 https://t.co/D1fDceeheN

                                                                        arton on Twitter: "まともなソフトウェア開発は「職人」によって行われる(当然、「属人」的である)と、ついに断言した、とても良い本。 https://t.co/D1fDceeheN"
                                                                        • スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO

                                                                          はじめに みなさんこんにちは、CX事業本部Delivery部のかみとです。 受託開発のプロジェクトをスクラムで始める際、アジャイル開発やスクラムのフレームワークに対する認識がお客様とベンダー間で一致していることが望ましいのですが、アジャイルやスクラムの経験有無、理解度の違いなどによって異なった認識のままプロジェクトが開始してしまうことで、後々プロジェクトの進行に影響を及ぼしてしまうことがあると思います。 これがただの小さな認識のズレで、プロジェクト進めていく中で調整可能なものであればいいのですが、そもそもの前提が違うくらいの大きな認識相違となってしまった場合、プロジェクトとしてはもちろんお客様との信頼関係にも悪影響を与えかねません。 そういった状況を避けるためにも、なるべくプロジェクト開始前にお客様との間でアジャイル開発にまつわる、よくある誤解を解消しておくのはとても大切なことだと思います

                                                                          スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO
                                                                          • 「やらないことリスト」をまず作れ、アジャイル開発で必ず役立つ

                                                                            書籍『誰も教えてくれなかったアジャイル開発』(日経BP)では、ウオーターフォール型開発が主流の「日本企業」で試行錯誤しながらアジャイル開発を成功に導いてきたコンサルタントたちが、自ら経験を体系化している。本書から抜粋し、アジャイル開発のポイントを紹介する「実践編」から、前回に続いてポイント(5) 「やること」よりも「やらないこと」をまず決める、を掲載する。(技術プロダクツユニットクロスメディア編集部)

                                                                            「やらないことリスト」をまず作れ、アジャイル開発で必ず役立つ
                                                                            • プログラミングに必要なブレイクスルー

                                                                              Yoyo Code (Matyáš Racek's blog)より。 ソフトウェアの開発方法を劇的に変えるには、いくつかのブレイクスルーが必要だと感じています。ブレイクスルーといった場合、それは大きなブレイクスルーを意味します。例えば、「構造化プログラミング」のブレイクスルーのようなもので、プログラミングに対する私たちの考え方を完全に変えてしまうようなものです。ここでは、それに関するいくつかの見解とアイデアを紹介します。 グルーコードや定型文を書くのは無駄だ 私が書くコードのほとんどは、面白いことはするわけではなく、定型文か、サブシステム同士を繋ぐための糊のようなものです。この種のコードは、すでに何度も書かれていて、これからも何度も書かれるような気がします。それなのに、なぜまた書かなければならないのでしょうか? 問題は、コードがかなり異なっていることで、通常は既存のコードをそのまま使うこと

                                                                              • あなたが学んだアジャイルとテスラの手法は何が違うのか? 認定スクラムトレーナーが語る、テスラの真の凄さ

                                                                                「Agile Tech EXPO(あじゃてく)」は、社会をちょっと良くするテクノロジーを学び、ちょっと先の未来の話をする無料オンラインコミュニティです。Keynote Speakerとして登壇したのは、ビル・ゲイツ氏、ジェフ・ベゾス氏、イーロン・マスク氏の下で働いた経験があるジョー・ジャスティス氏。テスラ社の急成長を支える、アジャイルハードウェア開発について話しました。全2回。前半は、イノベーションの加速のポイントとなる「スプリントの長さ」と「プロジェクトの同時進行」について。 テスラのアジャイル文化を12のステップで紹介 ジョー・ジャスティス氏:本日はありがとうございます。アジャイルハードウェアディロップメントとして、アジャイルをいかにハードウェア開発に適用していくかということを、今回お話しします。 私の経験ですが、マイクロソフトのビル・ゲイツや、スペースカンパニーやAmazonをやって

                                                                                あなたが学んだアジャイルとテスラの手法は何が違うのか? 認定スクラムトレーナーが語る、テスラの真の凄さ
                                                                                • コンウェイの法則の反転現象 - 余白

                                                                                  発見したつもりだが、すでに周知のことかもしれない。が、少なくとも私には知られていなかった。全文はScrapboxに。 scrapbox.io TL;DR システムの構造を変更するほうが組織の構造を変更するよりも困難である場合、組織の構造はむしろシステムの構造から優越的に影響を受ける 「コンウェイの法則の反転現象」と呼ぶものについて システムの構造と組織の構造がミスマッチしたとき、システムの構造を変化することが容易でなければ、組織の構造のほうが適応してしまう システム開発能力の養成が不十分なまま内製化を進める組織においては、この反転現象が起こりやすい また、ソフトウェア開発現場のアジャイル化はこの現象をさらに促進するだろう アジャイルな組織とは変更容易性の高い組織であるため、相対的に必然的に組織の構造のほうが適応しやすい この現象によって、逆コンウェイ戦略を狙ってシステム構造の改善をめがけた

                                                                                  コンウェイの法則の反転現象 - 余白