並び順

ブックマーク数

期間指定

  • から
  • まで

321 - 360 件 / 2056件

新着順 人気順

アジャイル開発の検索結果321 - 360 件 / 2056件

  • 『ユニコーン企業のひみつ』とスケーリングの考えかた / #AgileLounge 20220204

    Agile Lounge #1「大規模アジャイル開発を神話にしない戦略会議」 - connpass https://forkwell.connpass.com/event/235853/

      『ユニコーン企業のひみつ』とスケーリングの考えかた / #AgileLounge 20220204
    • スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO

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

        スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO
      • リモートでアジャイル開発ってどうしてる?〜メルカリ、LINE、クオカードでの取り組みを公開します〜【前編】 - Findy Engineer Lab

        2020年8月26日(水)、Findyが主催するエンジニア向けイベント「アジャイル開発最前線〜メルカリ、LINE、クオカードのエンジニア組織を徹底解剖!〜」がオンライン上にて開催されました。 新型コロナウイルスの影響により、私たちの働き方は大きく変化しました。こうした状況の中で、より良い製品を作り出すためには、単に働き方を変えるだけでなく、多様な働き方に適した組織体制やコミュニケーション、さらにはツール選定など、エンジニア組織や開発手法自体も、時代に合わせて考える必要があります。 今回は、長きに渡ってアジャイル開発を進めてきたゲストの方々をお呼びし、アジャイル開発のこれまでと直近の変化、今後のあり方について語っていただきました。その内容を、前編のパネルディスカッションパートと、後編のQ&Aパートに分けてお届けします。 ■登壇者プロフィール 鎌田 正浩/LINE株式会社 [@iratamak

          リモートでアジャイル開発ってどうしてる?〜メルカリ、LINE、クオカードでの取り組みを公開します〜【前編】 - Findy Engineer Lab
        • 2022年における開発組織のパフォーマンス計測とNewsPicksの取り組みについて - Uzabase for Engineers

          NewsPicksの高山です。 2020年と2021年は「開発生産性」またはほぼ同義の「開発者体験」に注力した2年でした。特に2021年は、自分でも少しウザいぐらいに登壇やブログやインタビューでこの話をしていました。(後半からは「開発生産性」から派生してKotlinの話が主でした) tech.uzabase.com codezine.jp hatenanews.com zine.qiita.com zine.qiita.com tech.uzabase.com hatenanews.com 今回のブログでは、2021年のNewsPicks開発組織のパフォーマンス計測の現状と、界隈の動向についてまとめていきます。 背景 デプロイ頻度の計測 Findy Teams Four Keys まとめ 宣伝 背景 『LeanとDevOpsの科学』によると、一般的にアジャイル開発で良いとされる開発スタイル

            2022年における開発組織のパフォーマンス計測とNewsPicksの取り組みについて - Uzabase for Engineers
          • わかった気になるDDD入門記事まとめ - Qiita

            はじめに こんにちは。はじめまして。tarokamikazeです。 これは、社内勉強会用に参考資料をまとめたものです。 この資料のゴール DDD専門用語について、どんなワードでググったらいいかわかるようになる DDDを知らない人が、戦術的DDD(軽量DDD)だけでもやってみようかなという気になる 前段; MVCの限界 余談ですが、凝集度・結合度の観点からするとRailsのMVCがどう問題があるかをコラムで紹介しています。MVCそれぞれの責務を図示すると、低凝集・高結合になっていることがわかります。 とにかく、凝集度、凝集度なのです。 pic.twitter.com/fDWv1ERJA1 — 松岡@技術書典8Day2え28 / DDDブログ書いてます (@little_hand_s) February 2, 2020 あえて過激に言うと。 ある程度の複雑度を持ったアプリケーションにおいて、M

              わかった気になるDDD入門記事まとめ - Qiita
            • お役所や大企業がIT調達の呪縛から逃れるためには - ku-sukeのブログ

              宮坂さんのTweetを拝見し、僕もここ数年DXだとかFintechだとかよくわからない業界でもがいてきて少し見えてきたことがあるので言語化してみたい。 勉強になった。行政ではIT調達なる言葉を使うが、ソフトウェア/デジタルサービスは「調達」という言葉に馴染まないのではと。サービスが顧客期待に応えるかは事前に積算できず不確実性が。顧客に聞きながら改善するしかない。これが今の予算/調達制度に抜群に相性が悪い仮説。 https://t.co/RUV1HzrDoe— 宮坂学 Manabu Miyasaka (@miyasaka) 2020年9月19日 おさらい。IT調達の呪縛とは まずはじめに、この国の遅れたIT化や、いけてない(ようにみえる)システムがなぜ起きているか、その原因の多くが、システム開発を「モノの調達」と同じフローに載せていることである。 たとえば、コピー機を100台、カラーレーザー

                お役所や大企業がIT調達の呪縛から逃れるためには - ku-sukeのブログ
              • 150社以上・3000人以上のエンジニア・マネージャが受講したアジャイル研修を動画公開 #アジャイル開発の基礎知識 | Agile Studio

                Agile Studio プロデューサー の木下です。弊社の研修である「アジャイル開発の基礎知識」を動画で一挙 22本、公開しました。アジャイル動画のサイトでご覧になれます(以下のURLをクリック)。...

                  150社以上・3000人以上のエンジニア・マネージャが受講したアジャイル研修を動画公開 #アジャイル開発の基礎知識 | Agile Studio
                • アジャイル開発におけるスケジュールを継続的に見直す - Chatwork Creator's Note

                  こんにちは。都志(@louvre2489)です。 これは Chatwork Advent Calendar 15日目のエントリです。 Chatworkではアジャイルを前提に開発を行っています。プロジェクト特性やチームのルールに依って多少特色はありますが、ほぼ全ての開発がアジャイルに行われているのではないでしょうか(詳細は未確認)。 アジャイル開発に慣れてくるとどういう風に開発を進めれば良いかも共通知ができてくるのですが、アジャイル開発を導入し始める時によくわからなくなるポイントの1つとして『スケジュールをどのように可視化するか?』という課題があると思います。 この課題に対して、私の所属しているチームで行っているスケジュール作成の方法を紹介させていただきたいと思います。 アジャイル開発のスケジュールを立てよう 実はこの内容、以前に藤井 (@yoshiyoshifujii) が書いてくれていま

                    アジャイル開発におけるスケジュールを継続的に見直す - Chatwork Creator's Note
                  • よりよい開発体験を求めて─ OSSと本業であるインフラエンジニアの二軸を生かし、自らの力で組織の開発力を向上させる - Findy Engineer Lab

                    ファッション通販サイト「ZOZOTOWN」の開発・運用を担うZOZOテクノロジーズでは、2004年の設立から使われ続けてきたモノリスなアプリケーションをマイクロサービス化するとともに、オンプレミスからマルチクラウドへと大きなシステムのリプレースを進めています。 その中心でMLOpsやSREといった基盤の構築を担う瀬尾直利(@sonots、そのっつ)さんは、インフラエンジニアとして事業にコミットしているだけでなく、CRubyやFluentd、Chainerといったさまざまなオープンソースソフトウェア(OSS)のコミッターという顔も持っています。 一貫して「開発体験の良さ」を追い求めてきた瀬尾さんの中で、プロジェクトの課題を解決する業務と、OSSコミュニティにおけるプライベートの活動はどのようにシンクロしているのでしょうか。キャリアの軌跡を振り返りながら、2つの軸を生かしたソフトウェアエンジニ

                      よりよい開発体験を求めて─ OSSと本業であるインフラエンジニアの二軸を生かし、自らの力で組織の開発力を向上させる - Findy Engineer Lab
                    • エンジニア8人チームで"効果的に"タスクをアサインするために検討した8つの軸 - yigarashiのブログ

                      最近、締め切りのある大きめなプロジェクトでWebアプリケーションエンジニア兼プロジェクトマネージャーとして仕事をしました。一年目なので当然プロジェクト管理の経験はなく、本を読んで知識を得たり、チームメンバーに助けられたりと、だいぶ手探りでの挑戦となりました。その中でもっとも難しかった仕事の一つとして、タスクの効果的なアサインがあります。 エンジニアは最大8人おり、その技術力、ドメイン知識、勤務地などは多岐に渡ります。ウォーターフォール的な開発だったため、タスクは事前に洗い出されており、タスク管理ツール上に無数に登録されていました。適当に人とタスクを辞書順でソートしてアサインするだけなら簡単ですが、現実はそうもいきません。締め切りは厳しく、チームの生産性を少しでも高く維持しなければいけません。メンバーのモチベーションが下がったり、依存の多いタスクが遅れたりといったことはなんとしても避けたいも

                        エンジニア8人チームで"効果的に"タスクをアサインするために検討した8つの軸 - yigarashiのブログ
                      • 【コラム】PMBOK第7版がタスク・マネジメントにもたらす意味とは?(1/3) - VisiWork

                        記事ID:3111 AIサマリー: この記事では、PMBOK第7版がタスク・マネジメントにもたらす影響について説明しています。新しいパフォーマンス・ドメインと開発アプローチ、ライフサイクルの重要性が強調され、複合的な計画視点の必要性が述べられています。また、タスク・マネジメントの導入に際し、バリューデリバリー・システムの概念を理解し、業界や契約形態にかかわらず価値創出を目指す重要性が強調されています。 PMBOKとPMBOK第7版 PMBOKとはProject Management Body of Knowledgeを略したものであり、日本語では、「プロジェクト・マネジメント知識体系ガイド」と言います。PMBOKは、プロジェクト・マネジメント協会 (PMI) が発行しているガイドであり、幅広い分野でのマネジメントに適用されるプロジェクト・マネジメントの基盤を提供しています。 この記事の著者

                          【コラム】PMBOK第7版がタスク・マネジメントにもたらす意味とは?(1/3) - VisiWork
                        • PHP中級者がソフトウェア開発の理解を深めるためのオススメ書籍 約30冊(2020年版) — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something

                          去年末(2019/12)にオススメ書籍をまとめてみたことがあったので、それを少し更新して公開します。 上にある書籍がよりオススメというわけではないです。 対象者は「PHP中級者」です。中級者が何かは難しいですが、初心者、初級者では決してないとは言えます。 改めて一覧にしてみると、かなり偏っているかも知れません(笑 こういうのはコンテキストというのがあるため、それが合わないと「お前は何を薦めているのだ?」となるでしょうね。 キーワードは、「モデリング」「オブジェクト指向プログラミング」「TDD」「デザインパターン」「DDD」「チーム開発」「アジャイルソフトウェア開発」「スクラム」でしょうか。 PHP中級者のイメージ たぶん、PHP中級者であれば、PHPに関することはPHPマニュアルなどを調べて解決できるでしょう。PHPのオープンソースプロジェクトに貢献しており、自分でプロジェクトを持っている

                          • なぜDXは分かりにくいのか? なぜ3種類のDXが生まれたのか? ビジネスパーソンのためのDX入門セミナー【セミナーレポート】 | Aidemy Business

                            Aidemy Business > AI-CAN > なぜDXは分かりにくいのか? なぜ3種類のDXが生まれたのか? ビジネスパーソンのためのDX入門セミナー【セミナーレポート】 この記事は2020年12月23日に開催されたWebセミナー「DXを徹底解説!ビジネスパーソンのためのDX入門セミナー」のレポートです。 ※記事化のために一部を編集しています。 2020年12月23日、“中山ところてん”として知られる株式会社NextInt代表の中山心太氏と、株式会社アイデミーの共催セミナーが開催されました。Aidemy Businessの新講座「ビジネスパーソンのためのDX入門講座」を制作された中山氏が、そのエッセンスを凝縮してお話しくださいました。進行は、アイデミーで開発本部コンテンツ部長を務める登坂直矢です。 中山ところてん(中山心太)氏 株式会社NextInt代表 著書: 『仕事ではじめる機

                            • 「1プロダクトをみんなで作る!」Rettyでの大規模スクラム(LeSS)導入記 - Retty Tech Blog

                              この記事は Retty Advent Calendar 2019 8日目の記事です。 qiita.com はじめに LeSSを選択した背景 LeSS展開のプロセス 1チームスクラム期(4月〜6月) テスト導入期 (7月〜9月) 全社展開期 (10月〜12月) 導入後の状況と今後の課題 おわりに はじめに マネージャーの常松です。 6月に入社して以来、開発プロセスの改善に携わってきました。 今年は大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法が刊行され、アジャイル開発・マネジメントの勉強会でも大規模スクラム(LeSS : Large Scale Scrum、以降LeSSと表記)の名前を聞くことが増えたように感じています。 しかし本だけを参考に自分の組織で大規模スクラムを導入していくのはまだまだ難しいのではないでしょうか? スクラム開

                                「1プロダクトをみんなで作る!」Rettyでの大規模スクラム(LeSS)導入記 - Retty Tech Blog
                              • 【主催イベント】アジャイル開発「スクラム」って各社どうしてる?エンジニア知見共有会 - TECH Street (テックストリート)

                                こちらのイベントレポートは下記のリンクからご覧ください www.tech-street.jp こんな方におすすめ ・アジャイル開発経験を持つITエンジニア その他、本テーマに興味関心のある方 開催概要 アジャイル開発「スクラム」って各社どうしてる?エンジニア知見共有会 ITテクノロジーに関する様々な職種やテーマで「他社・他の人ってどうしてるの?」を学ぶ、 TECH Streetコミュニティ恒例の事例・知見共有勉強会。 今でこそアジャイル開発「スクラム」は様々なプロジェクトで採用され、概念も浸透していますが、具体的なやり方はプロジェクトの数だけ特徴があるかと思います。そこで今回は各社のアジャイル開発「スクラム」に携わるエンジニアが集まり、それぞれの知見を発表し、学びあう勉強会を開催いたします。 今回も質問コーナーをたっぷり設けますので、いろんな「知りたい!」に応えられる会を目指します! イベ

                                  【主催イベント】アジャイル開発「スクラム」って各社どうしてる?エンジニア知見共有会 - TECH Street (テックストリート)
                                • 日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance

                                  先日、アジャイル開発を推進するために大変有意義な資料が公開されています。ESMの木下さんといえば、アジャイル開発の現場にずっと携わってきた著名な方です。 note.com でも、令和2年にこちらの記事が何百もはてブされるのも、おいおいマジかよって思う所がありまして。今までどうやってたのだろうか...。準委任(時間単位のチャージ)以外の選択肢がないやり方だと思っていたので。請負でアジャイルを取りに入れるわけないですよね。一般的なSIerさんでは、どういう理解をされて、どう取り組んで来たのだろう。 アジャイルと受託開発の相性は最悪では ムービング・ターゲットを請負で追いかける自傷行為を誰がやるんだって話と、要件固めて下請けに出せないから誰もやりたがらないよねという話を書き散らしています。 10年前に書いた記事の内容がまだ通用してしまうのも、自分でも少し寂しい気持ちがあります。 gothedis

                                    日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance
                                  • こんなマネージャーと仕事がしたい────カケハシいくおさんインタビュー

                                    2023年末に「こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと」というブログ記事が話題になりました。この記事で注目を集めたエンジニアリングマネージャーは、株式会社カケハシの「いくおさん」こと小田中 育生さん。 今回はそんな素晴らしいマネージャーである、いくおさんに日々意識しているチームコミュニケーションについてお話をお聞きしました。 どうしたらチームメンバーとの強い信頼を築けるのか、良いマネージャーになるにはどうしたら良いのか、気づきが得られる内容になっていると思います。どうぞ最後までお読みいただければ幸いです。 株式会社カケハシ エンジニアリングマネージャー。 2009年に株式会社ナビタイムジャパン入社。研究開発部門に配属。プロダクトや開発プロセスのカイゼンを推し進め、アジャイルとの出会いから社内でスクラムを積極的に導入し、ナビタイムジャパン VPoEを務

                                      こんなマネージャーと仕事がしたい────カケハシいくおさんインタビュー
                                    • 『UNIXという考え方―その設計思想と哲学』を読んだ - 30歳からのプログラミング

                                      UNIX やそのツールはどのような考えに基づいて作られているのか解説した本。 UNIX が開発されていくなかで培われていった文化や考え方について書かれている。 www.ohmsha.co.jp UNIX が具体的にどのように動いているのかではなく、 UNIX はなぜそのように動いているのか、ということが主題。 そのため、 UNIX に限らずソフトウェア開発全般に適用できるような内容になっている。ソフトウェアだけでなく「ものを作る」こと全般に応用できる内容も多いかもしれない。 私も、現時点では UNIX そのものに対する熱意や探究心はあまりないので、 UNIX について知るためではなく開発の参考になる考え方がないかと思って読んだ。 9 つの定理が紹介されているのだが、まず思ったのは、「言うは易く行うは難し」という感じの定理ばかりだなということ。 例えばシンプルに保て、小ささを維持しろ、という

                                        『UNIXという考え方―その設計思想と哲学』を読んだ - 30歳からのプログラミング
                                      • NTTを変えることで日本のIT業界を変えたい。転職ではなく転籍という選択で見つけた「大義」 - Findy Engineer Lab

                                        NTTコミュニケーションズでエンジニアとして勤務する傍ら、ポッドキャスト『fukabori.fm』配信やさまざまなイベント登壇など、幅広く活躍されている岩瀬義昌(@iwashi86)さん。意外にも、新卒でNTT東日本に入社した際は現在のような多忙なキャリアを描いておらず、「無理せず生きていきたい」と思っていたそうです。 入社して5年ほどたったときに成長に頭打ちを感じ、「本当に自分はこの道を歩みたいのか?」と悩んだ岩瀬さん。なぜ転職ではなく、NTTグループ内での転籍という道を選んだのでしょうか。 その選択で得た刺激、デブサミで受けた衝撃、意外な人事部への異動……。「日本のIT業界を変えたい」という現在の思いに至るまでのキャリアについて、お話を伺いました。 「無理せず生きていけたら」とNTT東日本に入社 入社5年で感じた「頭打ち」、キャリアパスへの疑問 プライベートも含めた総合的な判断で選んだ

                                          NTTを変えることで日本のIT業界を変えたい。転職ではなく転籍という選択で見つけた「大義」 - Findy Engineer Lab
                                        • なぜテスト自動化は当たり前にならないのか? アジャイル・DevOps時代のスピードと品質の考え方

                                          本連載では、スピードと品質を両立するためのアジャイルテスティングにおける重要なキーワードである「テストの自動化」について、WebブラウザやAPIレベルのエンドツーエンドテスト(E2Eテスト、この連載でのテスト自動化は主にE2Eテストの自動化を指しています)が求められる時代背景から、戦略や戦術、組織づくり、ノーコード・SaaS型のAIを活用したテスト自動化サービスの進化と具体的な実装、ベストプラクティスを解説します。第1回は、アジャイル開発やDevOpsが当たり前になった時代において求められるテストや品質について、時代背景を追っていきます。 はじめに 技術の進化とともに開発スピードは格段に上がり、システムはより複雑になり、求められる品質も高まっています。アジャイル開発やDevOpsという言葉が一般的になった今、これまで幾度となく議論されてきた「スピードと品質」の問題は、トレードオフではなく、

                                            なぜテスト自動化は当たり前にならないのか? アジャイル・DevOps時代のスピードと品質の考え方
                                          • 「やらないことリスト」をまず作れ、アジャイル開発で必ず役立つ

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

                                              「やらないことリスト」をまず作れ、アジャイル開発で必ず役立つ
                                            • 年収550~800万円台の「転職上手」なエンジニアほど危うい時代に?【久松剛解説】 - エンジニアtype | 転職type

                                              2024.03.08 働き方 新卒SIer久松剛プロフェッショナルお金 案件や給与、残業、勤務地に対する「あなたの希望を叶えます」と謳った、いわゆる“エンジニアファースト”な求人があふれていた時代に終止符が打たれようとしているーー。 そう警鐘を鳴らしたnote「エンジニアファーストを撤回したい企業の思惑」に反響が集まっている。執筆したのは、“流しのEM”として、複数企業の採用・組織・制度づくりに関わり、採用側と求職側の事情に精通している久松 剛さんだ。 今、業界で何が起こっているのか。久松さんに、エンジニアを取り巻く採用市場の変化と今後のキャリア戦略のあり方を聞いた。 博士(慶應SFC、IT) 合同会社エンジニアリングマネージメント社長 久松 剛さん(@makaibito) 2000年より慶應義塾大学村井純教授に師事。動画転送、P2Pなどの基礎研究や受託開発に取り組みつつ大学教員を目指す。

                                                年収550~800万円台の「転職上手」なエンジニアほど危うい時代に?【久松剛解説】 - エンジニアtype | 転職type
                                              • アジャイル開発実践ガイドブック | 内閣官房情報通信技術(IT)総合戦略室

                                                • 【PDF公開】Scrum Starter Guide

                                                  アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) みなさんこんにちは。@ryuzeeです。 以前、「スプリント1を始める前にどんな準備をするか」という記事を公開したのですが、この記事に内容を加筆修正してPDF化したものを用意しましたので公開します。 スクラムは非常に軽量なフレームワークで、Howについてはほとんど触れられていないため、これから立ち上げるときにどんなことをやればよいのか困ってしまう人も多いようです。 何も準備せず、いきなりスプリントで開発を始めようとしたり、逆に何か月もかけて事前準備をしてしまい、ウォーターフォールと変わらないやり方をしている例も見かけます。 本書では、スクラムを始めるときにどんな準備をしてから始めればよいかを整理しています。あくまで筆者の経験

                                                    【PDF公開】Scrum Starter Guide
                                                  • 工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは

                                                    工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは:アジャイル開発における品質管理(3) 少人数、短期間の開発を繰り返すアジャイル開発では、どのようにすれば品質を保つことができるのだろうか。本連載では、アジャイル開発における品質管理の手法を解説する。今回は、スプリント内でのテストと品質保証について、2回に分けて解説する。前編となる今回は要件設定とV&Vについて。 アジャイル開発において、テストをどのように実施するかは難しい問題です。短い開発周期で、設計、実装にしっかり時間をかけようとすると、それに伴ってテストを実施する時間は少なくなります。結果として、テストがスプリント(※)内で収まらず、テストのタスクを次のスプリントに持ち越してしまいます。結果として本来のタスクに着手できず、プロジェクトが停滞してしまうことも考えられます。 (※)アジャイル開発におけ

                                                      工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは
                                                    • DDDを試行錯誤しながら実践するチームの学びをまとめてみた - Gaudiy Tech Blog

                                                      こんにちは!エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドエンジニアをしている椿(@mikr29028944)です。 Gaudiyは、まだエンジニア10名、デザイナー2名ほどの開発チームですが、今年の6月からDDDと呼ばれるドメイン駆動設計を開発に取り入れました。 DDDとは、一言で言うとドメインエキスパートと呼ばれる担当業務やシステム設計に最も詳しい人と、エンジニアが共創してソフトウェアを開発する手法です。 今回は、DDDを実践する中での気づきや学び、躓きやすいポイントをどのように乗り越えてきたかについて、ご紹介してみたいと思います。 DDDを検討しているチームや、導入して間もないチームのご参考になれば幸いです! 1.なぜDDDを導入したのか 2.GaudiyではどのようにDDDを取り入れているか 3.DDDの実践で生じた課題と乗り越え方 3-1.チ

                                                        DDDを試行錯誤しながら実践するチームの学びをまとめてみた - Gaudiy Tech Blog
                                                      • フィーチャーフラグを管理するためのOpenFeature | フューチャー技術ブログ

                                                        はじめにTIG DXユニット真野です。 CNCF連載の2本目はクラウドネイティブなフィーチャーフラグの標準とAPI、SDKを提供するOpenFeatureについてです。 フィーチャーフラグとはフィーチャーフラグとはコードを変更せずに、フラグを使って機能を有効/無効化する開発/デプロイ手法のことです。一般的なユースケースとしては、特定のユーザーに対して再起動とか再デプロイをせずに、新機能を有効化したいといった場合に役立ちます。信頼度が高くなったらより段階的に広範囲に対象を広げていくと安心ですね。この使い方だけであれば、カナリアリリースを想像しますが、他にも次のようなユースケースが考えられます。 初期から契約している特別な顧客(あるいはプレミアムプランに契約している顧客)に向けて開発した機能を提供する バグが見つかったので、該当機能を無効化してアプリの振る舞いをロールバックする 繁忙期にシステ

                                                          フィーチャーフラグを管理するためのOpenFeature | フューチャー技術ブログ
                                                        • Clean Agileを読みました|食べログ フロントエンドエンジニアブログ

                                                          こんにちは。食べログのフロントエンドチーム の荒川です。 先日、「Clean Agile 基本に立ち戻れ」を読みました。 本日はこの本の要約を、私たちのチームの活動を交えてご紹介しようと思います。 著者の Robert C. Martin氏は、アジャイルマニュフェストの創案者の一人で、 国際的なソフトウェアコンサルティング、スキル開発を行っています。 https://agilemanifesto.org/iso/ja/manifesto.html 1章 アジャイル入門 アジャイルの歴史 アジャイルの歴史は5万年以上前、人間同士が協力して、共通の目標を達成しようとしたことが始まりと述べています。ソフトウェア開発においては、アラン・チューリングがチューリングマシンの論文を執筆した1936年の当時や、1946年にACE(Automatic Computing Engine)のために書いた最初のコ

                                                            Clean Agileを読みました|食べログ フロントエンドエンジニアブログ
                                                          • 年収が1000万円以上のエンジニアの求人をまとめてみた - Qiita

                                                            近年優秀なエンジニアに対して報酬を多く支払う企業が増えてきています。 実際アメリがのAmazonも大幅な賃上げを行い、話題となりました。 日本国内でもエンジニアの年収が高い企業を知りたい!と思っている エンジニアの皆様お待たせいたしました。 年収1000万以上の求人をまとめてみましたので、参考までにご覧ください。 フリービット株式会社 【募集ポジション/年収】 エンジニアリングマネージャー候補:1000万円〜1500万円 【求める人材】 当社の Vision に共感いただき、プロダクトの継続的な成長を支える開発体制を実現するため、エンジニア組織の強化を担っていただける方を募集しています。 組織づくりや人員のマネジメントなどの組織拡大を一緒に担っていただける方を探しています。 【具体的な業務内容】 ・エンジニア組織としての課題発見・解決、及び成長戦略の立案・実行 ・開発チームの体制構築と、そ

                                                              年収が1000万円以上のエンジニアの求人をまとめてみた - Qiita
                                                            • アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第1回 概要~ - selmertsxの素振り日記

                                                              2019年8月にAzitに入社して4ヶ月。 私はSREとしての役割を期待されてAzitに入社したけれども、気がつけばバックエンドエンジニア兼スクラムマスターをやっていました。 バックエンドエンジニアとしては、AWSインフラ環境の完全な作り直しとTerraformによるコード化、Railsの負債解消、監視設定のコード化などを行っていました。 スクラムマスターとしては、初期の3ヶ月はアジャイル開発(スクラム、XPを組み合わせたもの)、そして12月からの1ヶ月はリーン・スタートアップ開発の導入等を行いました。 ここでは、スクラムマスターとして考えた開発プロセスについて資料にまとめます。 なおこの文章は、0-1 の開発フェーズではなく、すでにリリースされたサービスに途中で加わったスクラムマスターの目線で書かれており、対象とする読者も私と同じような境遇にあるスクラムマスターとなっています。 この開発

                                                                アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第1回 概要~ - selmertsxの素振り日記
                                                              • 「2022年は生産性も品質も低下した」 『ソフトウェア開発分析データ集2022』から見る結果

                                                                ソフトウェアの開発者・テスト技術者・品質管理/品質保証の担当者の方へJSTQBからの情報を届ける「JSTQB カンファレンス in 2022 Autumn」。ここで五味氏が「DXに求められるソフトウェア品質とその計測」をテーマに登壇。続いて、『ソフトウェア開発分析データ集2022』の内容について話します。前回はこちらから。 定量データの傾向性 五味弘氏:ということで最初の一歩です。前振りがやっと終わりました。 (スライドを示して)私たちは『ソフトウェア開発分析データ集2022』というものを、9月26日に公開しています。昔の名前は「ソフトウェア開発データ白書」で、知っている人が99パーセントいてくれればうれしいなと思うのですが、その後継が「分析データ集」で、2022年版を9月26日に公開したばかりです。今日はこれを紹介したいと思います。 最初に結論です。2年に1回(「分析データ集」を)出して

                                                                  「2022年は生産性も品質も低下した」 『ソフトウェア開発分析データ集2022』から見る結果
                                                                • ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(後編)

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

                                                                    ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(後編)
                                                                  • アジャイルもDevOpsも費用対効果より機会損失で考える DASAアンバサダーが贈るこれからの開発現場へのアドバイス

                                                                    「みんなのPython勉強会」では、Pythonを中心としてプログラミングを様々なシーンに生かす方法を一緒に学んでいます。今回は初級、中級のサーバーサイドエンジニア向けに、開発現場のアドバイザーでもある長沢氏がアジャイルとDevOpsについて話しました。後半はアジャイルとDevOpsをどう取り入れればいいかについてです。 従来の開発計画とアジャイルの計画の違い やっと本題のうちの1つ、アジャイルの話に入ります。アジャイル開発自体の成り立ちの話は今日はしません。今日話しておきたいのは従来型、わかりやすく言うとウォーターフォールに近いものの開発のやり方とアジャイルのやり方はだいぶ考え方が違うというところをお伝えしたいです。 従来の開発の計画の仕方というのは基本的にはすべてのスコープをはっきりさせます。ウォーターフォールは要件定義を最初にやりますよね。要件定義で全部決め、すべての要件が固まって見

                                                                      アジャイルもDevOpsも費用対効果より機会損失で考える DASAアンバサダーが贈るこれからの開発現場へのアドバイス
                                                                    • 「リリース疲れ」を解消するために「リリースレゴ」をやってみた - エス・エム・エス エンジニア テックブログ

                                                                      介護や医療、ヘルスケアなどの領域で、高齢社会に適した情報インフラを提供している株式会社エス・エム・エスの西村直人(@nawoto)です。私は2005年からソフトウェア開発においてアジャイル開発を実践しており、現在はアジャイル開発の考え方を軸にチーム開発の支援などを行っています。 エンジニア組織ではリリースを頻繁にできることが望まれますが、リリースすることに疲れたりしませんか?僕たちは「リリース疲れ」と呼んでいますが、疲れが溜まるようにどんどんリリースが辛いものに感じてきます。エンジニア以外に言ってもあまり理解してもらえませんが……。 そんな悩みを解決するべく、エス・エム・エスの開発チームで行ったのは、レゴを組み立てること。え、なんでレゴ?そんな「リリースレゴ」という取り組みについてご紹介します。 プロダクト開発を継続すると起こる「リリース疲れ」 事業は長く継続していくように構築されているも

                                                                        「リリース疲れ」を解消するために「リリースレゴ」をやってみた - エス・エム・エス エンジニア テックブログ
                                                                      • アジャイルプラクティスマップを公開しました | Agile Studio

                                                                        Agile Studio プロデューサーの木下です。アジャイル開発をはじめるには、基本的な語彙やプラクティスをチームにいる全員が知ることが大切です。また、アジャイル開発を実践していく上ではスクラムのみ...

                                                                          アジャイルプラクティスマップを公開しました | Agile Studio
                                                                        • 無計画に見える計画・チーム感の欠如・とりあえずがんばる文化  “ふりかえりエバンジェリスト”が異動先で直面した組織の課題

                                                                          「スクラムフェス仙台」は初心者からエキスパートまでさまざまな参加者が集い、学び、楽しむことができるアジャイルコミュニティの祭典です。ここで登壇したのは、森一樹氏。ふりかえりを日常とするチームができるまでを「プロダクトオーナー」という観点でふりかえり、それを再現するために必要だった要素について話しました。全4回。1回目は、異動から見えた、内情と課題について。 ふりかえりのエバンジェリスト・森一樹氏 森一樹氏:よろしくお願いします。みなさんこんにちは。 (会場拍手) 現地の方もオンラインの方も、よろしくお願いします。オンラインの方はすみません、私はだいぶ久々に現地登壇をするので、Discordのコメントを拾う余裕がなさそうです。とはいえ、コメントをもらえるとあとから見返した時にすごくうれしいので、ぜひよろしくお願いします。 今日は「プロダクトオーナーのための、ふりかえりが日常に溶けるチームの作

                                                                            無計画に見える計画・チーム感の欠如・とりあえずがんばる文化  “ふりかえりエバンジェリスト”が異動先で直面した組織の課題
                                                                          • グーグルが始めた仕事のシンプル化を取り入れる方法 | Forbes JAPAN 公式サイト(フォーブス ジャパン)

                                                                            7月下旬に、Google(グーグル)は「より良い結果をより短時間で達成」を目指す「Simplicity Sprint(シンプリシティースプリント)」という取り組みを発表した。CEOのスンダー・ピチャイによると、Simplicity Sprintはより明確かつ効率的に仕事をすること、より良い、より速い結果を得るためにどの障害物を取り除けるか、無駄をなくすためにどのように起業的アプローチをとれるかということについて、従業員を巻き込むものだという。 私たちの多くは、何から手をつけていいかわからないので、自分の仕事をシンプルにできないのだ。まず何をシンプルにすべきなのか? また、そのための時間をどのように作るのだろうか? また、形式が決まった企業の仕事と、改変が許される仕事とをどのように見分けるのだろうか? 10年前、書籍『Why Simple Wins』のために世界中の人々にインタビューを始めた

                                                                              グーグルが始めた仕事のシンプル化を取り入れる方法 | Forbes JAPAN 公式サイト(フォーブス ジャパン)
                                                                            • 新人エンジニアが意識すると良いなと思うことまとめ - Qiita

                                                                              はじめに エンジニアになって4年ほどになり、自分がチームを引っ張ることも多くなってきました。 最近ではいっちょマエにアドバイスなんかすることもありますが、自分だって右も左も分からないところからエンジニアとして仕事をしつつ成長してきて今ここにいます。 そんな中で、「こうするともっと仕事がうまくできるよ」というノウハウやマインドセット的なものを自分なりにアウトプットしておきたいなと思ったので、つらつらと書いていきます。 前提 私はエンジニアになってからずっとWeb業界の小規模スタートアップで開発をしてきた人間です。2社経験していますが、2社ともスクラムによる開発手法を取っていました。ここに記す内容もこの環境や手法に影響を受けたものが多いです。 おしながき 1.マインドセット 2.仕事の進め方 3.どうにもならないとき 1.マインドセット 大局を見渡す 自分が着手しているタスクについて、なぜこれ

                                                                                新人エンジニアが意識すると良いなと思うことまとめ - Qiita
                                                                              • MVP(必要最小限のプロダクト) | UX TIMES

                                                                                ユーザーの欲しいものを時間をかけて作っても、使ってみるといらないと言われることがある。ユーザーは使ってみるまでプロダクトの価値が分からない。ユーザーへプロダクトの価値を確かめるための必要最小限のプロダクトをMVPという。 経営コンサルティング会社SyncDevのCEOであるFrank Robinson(フランク・ロビンソン)氏が、2001年にMVPを提唱した。2005年に、起業家であり学者のSteve Blank(スティーブ・ブランク)氏が、そのコンセプトを説明し、2010年に書籍「Lean Startup(リーンスタートアップ)」でEric Ries(エリック・リース)氏によって紹介された。 ユーザーの言う通りに作ってもダメな理由 ユーザーは、欲しい機能を実際にどう操作するか想像していないのに、あれば良さそうな機能も欲しいと言うことがある。 タスク管理アプリであれば、タスクの登録以外にも

                                                                                  MVP(必要最小限のプロダクト) | UX TIMES
                                                                                • OOPに対する問題は誇張されている

                                                                                  Young Coderより(M)。 50年経った今でも、私たちはプログラミングの支配的なパラダイムについて混乱しています。 マシュー・マクドナルド 何人かの敵を引き付けなければ、開発世界を何十年も支配することはできません。そして、オブジェクト指向プログラミングは、新旧数十種類の言語の概念的基盤を提供していますが、確かに敵もいます。 そのためか、私たちはOOPについての終わりのない一連のホットテイクに苦しんでいる理由です。彼らはOOPを、生産性を破壊する災厄であるとか、一連のごまかしのプログラミング・パターンであるとか、貧しいプログラマが無能さを隠すために設計された平凡なツールであるとか説明してきました。OOPは死んだとさえ宣言されたことがありました(14年前ですので、割り引いて下さい)。 OOPの4つの柱 これらすべての暴言に共通しているのは、現代のソフトウェア設計の落とし穴のいくつかを(

                                                                                    OOPに対する問題は誇張されている